From 40e5a5811c6ffce9b0974e93cdd927cbcf60c157 Mon Sep 17 00:00:00 2001 From: Joe Hunkeler Date: Tue, 11 Aug 2015 16:51:37 -0400 Subject: Repatch (from linux) of OSX IRAF --- doc/README | 1 + doc/_doc.hd | 7 + doc/aixiraf.ms | 629 +++ doc/aosvsiraf.hlp | 384 ++ doc/bsdiraf.ms | 711 ++++ doc/bugs.v25 | 1471 +++++++ doc/clman.ms | 1287 ++++++ doc/clman_toc.ms | 110 + doc/cluser.ms | 1177 ++++++ doc/cluser.tex | 5354 ++++++++++++++++++++++++ doc/cluser_toc.ms | 52 + doc/crib_title.ms | 31 + doc/decnet_iraf.txt | 365 ++ doc/doc/biblio84.hlp | 344 ++ doc/doc/bugs.v28 | 889 ++++ doc/doc/crib83.hlp | 1217 ++++++ doc/doc/doc.hd | 9 + doc/doc/doc.men | 10 + doc/doc/expressions.hlp | 149 + doc/doc/news.v28.hlp | 1269 ++++++ doc/doc/notes.v28 | 3849 +++++++++++++++++ doc/doc/pkg84.hlp | 282 ++ doc/doc/pmmatch.hlp | 259 ++ doc/doc/spp83.hlp | 1722 ++++++++ doc/doc/v28revs.ms | 1247 ++++++ doc/dsuxiraf.ms | 653 +++ doc/em4010.ms | 279 ++ doc/imexpr.ms | 739 ++++ doc/iraf.ms | 1779 ++++++++ doc/iraf92.tex | 625 +++ doc/iraf92f3.eps | 519 +++ doc/irixiraf.ms | 632 +++ doc/mancl.hlp | 20 + doc/manx.hlp | 19 + doc/news.old.hlp | 199 + doc/news.v29.hlp | 867 ++++ doc/newsfile | 8008 +++++++++++++++++++++++++++++++++++ doc/notes.solaris | 514 +++ doc/notes.v210 | 9642 +++++++++++++++++++++++++++++++++++++++++++ doc/notes.v211 | 7769 ++++++++++++++++++++++++++++++++++ doc/notes.v212 | 2219 ++++++++++ doc/notes.v214 | 1645 ++++++++ doc/notes.v215 | 602 +++ doc/notes.v23 | 4955 ++++++++++++++++++++++ doc/notes.v25 | 6367 ++++++++++++++++++++++++++++ doc/notes.v27 | 2848 +++++++++++++ doc/notes.v29 | 2502 +++++++++++ doc/pac_title.ms | 25 + doc/pac_toc.hlp | 84 + doc/packages.hlp | 1986 +++++++++ doc/pkgreorg.ms | 107 + doc/ports/README | 23 + doc/ports/alliant_86.doc | 589 +++ doc/ports/aos_ctio.doc | 233 ++ doc/ports/aos_port.doc | 223 + doc/ports/aux_port.doc | 978 +++++ doc/ports/notes.aix | 456 ++ doc/ports/notes.convex | 761 ++++ doc/ports/notes.dsux | 282 ++ doc/ports/notes.freebsd | 215 + doc/ports/notes.i386 | 1124 +++++ doc/ports/notes.irix | 158 + doc/ports/notes.linux | 325 ++ doc/ports/notes.mips | 398 ++ doc/ports/notes.osf1 | 409 ++ doc/ports/notes.solaris | 514 +++ doc/ports/notes_orig.hp | 657 +++ doc/ports/notes_v22.st | 1185 ++++++ doc/ports/nsoport.hlp | 193 + doc/ports/sun2_032786.doc | 152 + doc/ports/sun2_042386.doc | 141 + doc/ports/sun2_062486.doc | 134 + doc/ports/sun2_102885.doc | 190 + doc/ports/sun2_skyfpa.unc | 168 + doc/ports/sun3_042586.doc | 250 ++ doc/ports/sun3_062486.doc | 202 + doc/ports/sun3_f77Obugs.doc | 1666 ++++++++ doc/ports/sun4_sep87.doc | 296 ++ doc/ports/sun_f77bugs.doc | 15 + doc/ports/unix.isi | 87 + doc/ports/vms_jan85.st | 994 +++++ doc/ports/vms_oct85.st | 786 ++++ doc/ports/vmsbugs.doc | 328 ++ doc/ports/vmsport.doc | 1271 ++++++ doc/pset.ms | 433 ++ doc/rev1.ms | 305 ++ doc/rev2.txt | 7524 +++++++++++++++++++++++++++++++++ doc/revsfile | 251 ++ doc/sgi.ms | 570 +++ doc/spp_title.ms | 20 + doc/spp_toc.hlp | 119 + doc/std.ms | 2200 ++++++++++ doc/std_gl.ms | 571 +++ doc/std_toc.ms | 134 + doc/suniraf.hlp | 199 + doc/suniraf.ms | 692 ++++ doc/sunsmg.ms | 1606 +++++++ doc/template.ms | 16 + doc/unixiraf.hlp | 833 ++++ doc/unixiraf.ms | 1004 +++++ doc/unixsmg.ms | 1432 +++++++ doc/v210revs.ms | 3460 ++++++++++++++++ doc/v211revs.hlp | 1199 ++++++ doc/v212revs.hlp | 1152 ++++++ doc/v29revs.ms | 826 ++++ doc/vmsiraf.hlp | 681 +++ doc/vmsiraf.ms | 2375 +++++++++++ doc/vmsiraf.ms.v25 | 1466 +++++++ doc/vmsiraf.ms.v29 | 2673 ++++++++++++ doc/vmsprog.hlp | 572 +++ doc/vxuxiraf.ms | 631 +++ 111 files changed, 126776 insertions(+) create mode 100644 doc/README create mode 100644 doc/_doc.hd create mode 100644 doc/aixiraf.ms create mode 100644 doc/aosvsiraf.hlp create mode 100644 doc/bsdiraf.ms create mode 100644 doc/bugs.v25 create mode 100644 doc/clman.ms create mode 100644 doc/clman_toc.ms create mode 100644 doc/cluser.ms create mode 100644 doc/cluser.tex create mode 100644 doc/cluser_toc.ms create mode 100644 doc/crib_title.ms create mode 100644 doc/decnet_iraf.txt create mode 100644 doc/doc/biblio84.hlp create mode 100644 doc/doc/bugs.v28 create mode 100644 doc/doc/crib83.hlp create mode 100644 doc/doc/doc.hd create mode 100644 doc/doc/doc.men create mode 100644 doc/doc/expressions.hlp create mode 100644 doc/doc/news.v28.hlp create mode 100644 doc/doc/notes.v28 create mode 100644 doc/doc/pkg84.hlp create mode 100644 doc/doc/pmmatch.hlp create mode 100644 doc/doc/spp83.hlp create mode 100644 doc/doc/v28revs.ms create mode 100644 doc/dsuxiraf.ms create mode 100644 doc/em4010.ms create mode 100644 doc/imexpr.ms create mode 100644 doc/iraf.ms create mode 100644 doc/iraf92.tex create mode 100644 doc/iraf92f3.eps create mode 100644 doc/irixiraf.ms create mode 100644 doc/mancl.hlp create mode 100644 doc/manx.hlp create mode 100644 doc/news.old.hlp create mode 100644 doc/news.v29.hlp create mode 100644 doc/newsfile create mode 100644 doc/notes.solaris create mode 100644 doc/notes.v210 create mode 100644 doc/notes.v211 create mode 100644 doc/notes.v212 create mode 100644 doc/notes.v214 create mode 100644 doc/notes.v215 create mode 100644 doc/notes.v23 create mode 100644 doc/notes.v25 create mode 100644 doc/notes.v27 create mode 100644 doc/notes.v29 create mode 100644 doc/pac_title.ms create mode 100644 doc/pac_toc.hlp create mode 100644 doc/packages.hlp create mode 100644 doc/pkgreorg.ms create mode 100644 doc/ports/README create mode 100644 doc/ports/alliant_86.doc create mode 100644 doc/ports/aos_ctio.doc create mode 100644 doc/ports/aos_port.doc create mode 100644 doc/ports/aux_port.doc create mode 100644 doc/ports/notes.aix create mode 100644 doc/ports/notes.convex create mode 100644 doc/ports/notes.dsux create mode 100644 doc/ports/notes.freebsd create mode 100644 doc/ports/notes.i386 create mode 100644 doc/ports/notes.irix create mode 100644 doc/ports/notes.linux create mode 100644 doc/ports/notes.mips create mode 100644 doc/ports/notes.osf1 create mode 100644 doc/ports/notes.solaris create mode 100644 doc/ports/notes_orig.hp create mode 100755 doc/ports/notes_v22.st create mode 100644 doc/ports/nsoport.hlp create mode 100644 doc/ports/sun2_032786.doc create mode 100644 doc/ports/sun2_042386.doc create mode 100644 doc/ports/sun2_062486.doc create mode 100644 doc/ports/sun2_102885.doc create mode 100644 doc/ports/sun2_skyfpa.unc create mode 100644 doc/ports/sun3_042586.doc create mode 100644 doc/ports/sun3_062486.doc create mode 100644 doc/ports/sun3_f77Obugs.doc create mode 100644 doc/ports/sun4_sep87.doc create mode 100644 doc/ports/sun_f77bugs.doc create mode 100644 doc/ports/unix.isi create mode 100644 doc/ports/vms_jan85.st create mode 100644 doc/ports/vms_oct85.st create mode 100644 doc/ports/vmsbugs.doc create mode 100644 doc/ports/vmsport.doc create mode 100644 doc/pset.ms create mode 100644 doc/rev1.ms create mode 100644 doc/rev2.txt create mode 100644 doc/revsfile create mode 100644 doc/sgi.ms create mode 100644 doc/spp_title.ms create mode 100644 doc/spp_toc.hlp create mode 100644 doc/std.ms create mode 100644 doc/std_gl.ms create mode 100644 doc/std_toc.ms create mode 100644 doc/suniraf.hlp create mode 100644 doc/suniraf.ms create mode 100644 doc/sunsmg.ms create mode 100644 doc/template.ms create mode 100644 doc/unixiraf.hlp create mode 100644 doc/unixiraf.ms create mode 100644 doc/unixsmg.ms create mode 100644 doc/v210revs.ms create mode 100644 doc/v211revs.hlp create mode 100644 doc/v212revs.hlp create mode 100644 doc/v29revs.ms create mode 100644 doc/vmsiraf.hlp create mode 100644 doc/vmsiraf.ms create mode 100644 doc/vmsiraf.ms.v25 create mode 100644 doc/vmsiraf.ms.v29 create mode 100644 doc/vmsprog.hlp create mode 100644 doc/vxuxiraf.ms (limited to 'doc') diff --git a/doc/README b/doc/README new file mode 100644 index 00000000..2ba0fb04 --- /dev/null +++ b/doc/README @@ -0,0 +1 @@ +DOC -- Miscellaneous documents pertaining to the IRAF system as a whole. diff --git a/doc/_doc.hd b/doc/_doc.hd new file mode 100644 index 00000000..23cd24d8 --- /dev/null +++ b/doc/_doc.hd @@ -0,0 +1,7 @@ +# Root help directory for the DOC branch of the help database. + +$docdir = "./doc/" + +doc sys = README, + hlp = docdir$doc.men, + pkg = docdir$doc.hd diff --git a/doc/aixiraf.ms b/doc/aixiraf.ms new file mode 100644 index 00000000..034ab441 --- /dev/null +++ b/doc/aixiraf.ms @@ -0,0 +1,629 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +IBM AIX/IRAF Installation Guide +.AU +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +August 1992 +.br +Revised November 30 1992 + +.AB +This document describes how to install or update IRAF on an IBM RS/6000 +workstation or server running the AIX operating system. Both standalone and +networked, multiple architecture configurations are described. Only those +issues which one must understand to install AIX/IRAF are discussed +here; a companion document, \fIUNIX/IRAF Site Manager's Guide\fR, deals with +other issues such as interfacing new devices, configuring the IRAF +networking system, adding layered software, and so on. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling AIX/IRAF\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Install the files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Installing from a network distribution\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing from tape\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Configuring the BIN directories\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.3.\h'|0.9i'Merge local revisions back into the new system\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.4.\h'|0.9i'Run the INSTALL Script\l'|5.6i.'\0\06 +.sp +3.\h'|0.4i'\fBSystem Checkout\fP\l'|5.6i.'\0\08 +.sp +\fBAppendix A.\0A Complete Example\fP\l'|5.6i.'\0\09 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Before installing AIX/IRAF on a RS/6000, one must 1) obtain an appropriate +AIX/IRAF distribution, e.g., from the IRAF network archive on +\f(CWiraf.noao.edu\fR (or by ordering a tape distribution from NOAO), 2) +select the server or node on which the system is to be installed and arrange +for sufficient disk space to hold the system, and 3) set aside sufficient +time to do the installation. If these directions are followed carefully and +mistakes are avoided the basic installation should only take a half hour or +so. Additional time may be required to customize the system, to configure +the local tape drives and other devices, set up IRAF networking, and so on. +.PP +This Installation Guide is intended primarily for sites installing IRAF on a +RS/6000 running AIX 3.2 or later. Other popular UNIX systems for which IRAF +is available, e.g. SunOS, Ultrix, IRIX, HPUX, A/UX etc., have their own +system specific IRAF installation guides. + +.NH +Installing AIX/IRAF +.PP +Although the details of how AIX/IRAF is installed or updated depend upon the +type of distribution and the desired local system configuration, the basic +procedure is always the same. First one obtains the distribution files, +then one follows the procedure outlined below to install the system. Most +of these steps should be performed while logged in as IRAF; superuser +permission is required in the final stages of the installation, to run the +\fIinstall\fP script. +.PP +System managers familiar with the installation of typical UNIX programs +should beware that IRAF, being a large system in its own right and not a +UNIX program, does not always follow to the usual conventions. It is wise +to read and adhere to the installation instructions to avoid problems. +.XS +\fR# Prepare the root IRAF directory.\fP +if new installation + create iraf account +else if updating an old installation + save locally modified files; delete old system + +\fR# Install the files.\fP +login as iraf +unpack the core system distribution +configure the BIN directories + +\fR# Merge local revisions into new system.\fP +if updating an old installation + merge locally modified files back into new system + +run the iraf install script to complete the installation +checkout the new system +.XE +.PP +If problems should arise during the installation help is available via the +IRAF HOTLINE (602-323-4160), or by sending email to \f(CWiraf@noao.edu\fP. + +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation then you will be replacing +IRAF by the new version, and IRAF should already have an account and root +directory on the desired host system. You should save any locally modified +files and delete the old system, e.g., login as IRAF and enter something +like the following. +.XS +% cd $iraf\(dg +% tar -cf /scr0/oiraf.tar local dev unix/hlib +% /bin/rm -rf * +.XE +.FS +\(dg\0\(CW$iraf\fP symbolizes the UNIX pathname of the root IRAF directory. +If no "iraf" environment variable is defined just supply the actual pathname. +.FE +.PP +There are many possible variations on this, e.g., you could use \fImv\fR to +move the above directories to someplace outside the main IRAF directory +tree. Although it is probably simplest and safest to save entire +directories as in the example, in practice only a few files are likely to +have been modified. These are the following. +.XS +dev/graphcap +dev/hosts +dev/tapecap +dev/termcap +hlib/extern.pkg +hlib/login.cl +hlib/zzsetenv.def +local/.login +.XE +.PP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. It is important to delete the old system first to +avoid creating junk files or directories when the new system is installed +(due to file or directory name changes or deletions). Once the new system +has been restored to disk, do \fInot\fR merely restore the files saved above, +as you will need to carefully merge local changes into the versions of the +files supplied with the new IRAF release (more on this later). +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set +up a new account for the user `\f(CWiraf\fP'. This is necessary for IRAF +system management, which should always be done from the IRAF account. The +IRAF account has special login files which set up a custom UNIX environment +for IRAF system management. Having an IRAF account provides a convenient +place (the IRAF system manager's login directory) to keep scratch files +created during system configuration. +.PP +The location of the IRAF root directory is arbitrary. Our practice here is +to locate the software in a system file storage area separate from the +AIX system files (to simplify AIX upgrades), and then use a symbolic +link such as /iraf or /usr/iraf to point to the actual root directory. This +makes life simpler if IRAF is NFS mounted on several machines and it is +later necessary to move the IRAF files. Try to keep the path to the +physical IRAF root directory short to avoid filename truncation problems +when IRAF is run. +.PP +The login directory for the iraf account should be $iraf/local (e.g., +/iraf/iraf/local), rather than the IRAF root directory $iraf as one might +expect. This is done to provide a work area for local files separate from +the main IRAF directory tree, to simplify updates and make it easier to keep +track of what has been locally added and what is standard IRAF. In any +case, make sure that when the IRAF account is set up the login directory is +set correctly, or the IRAF environment will not be set up properly, and +later problems are sure to result. +.PP +A typical IRAF installation consists of the main IRAF release, a number of +BIN directories (the IRAF binaries), and additional directories for layered +software such as STSDAS, PROS, and so on. If sufficient disk space is +available to keep everything in one area the following directory structure +is recommended. +.XS +/iraf/iraf \fR# iraf root directory ($iraf)\fP +/iraf/iraf/local \fR# iraf login directory (~iraf)\fP +/iraf/irafbin \fR# iraf BIN directories\fP +/iraf/irafbin/bin.rs6000 \fR# RS/6000 binaries - iraf core system\fP +/iraf/irafbin/noao.bin.rs6000 \fR# RS/6000 binaries - iraf NOAO package\fP +/iraf/stsdas \fR# layered package\fP +/iraf/xray \fR# layered package\fP + \fI(etc.)\fP +.XE +.PP +For the purpose of this example we assume that the IRAF files are stored in +/iraf; as we say this might be a link and the actual directory is +arbitrary. Given this directory the IRAF root $iraf would be "/iraf/iraf/" +and the login directory for the IRAF account would be /iraf/iraf/local. The +binaries for the core IRAF system would be in /iraf/irafbin/bin.rs6000, +with a link $iraf/bin.rs6000 pointing to this directory (more on this +later). +.PP +Given the above directory structure the \f(CWpasswd\fR file entry for the +IRAF account would be something like the following. +.XS +iraf:!:312:101:IRAF system login:/iraf/iraf/local:/bin/csh +.XE +.PP +Do not worry about configuring the environment files for the new account as +these will be created when the iraf system is later restored to disk. + +.NH 2 +Install the files +.PP +If you are installing from tape skip forward to \(sc2.2.2. If you are +installing from a network distribution (i.e., from disk) continue with the +next section. +.NH 3 +Installing from a network distribution +.PP +AIX/IRAF is available over the network via anonymous ftp from the node +\f(CWiraf.noao.edu\fR, in the subdirectory \f(CWiraf/v\fInnn\fP/AIX3\fR, +where "\f(CWv\fInnn\fR" is the IRAF version number, e.g., subdirectory +\f(CWiraf/v210/AIX3\fR for V2.10 AIX/IRAF for the RS/6000. +.PP +If IRAF is being installed from a network distribution all the architecture +independent IRAF files for both the core IRAF system and the NOAO packages +will be in the distribution file \f(CWas.aix3.gen\fR. This "file" is stored +in the network archive as a directory wherein the large distribution file +has been split into a number of smaller pieces, e.g., +.XS +% ls as.aix3.gen +CHECKSUMS as.aix3.gen.Z.12 as.aix3.gen.Z.26 +FILES.Z as.aix3.gen.Z.13 as.aix3.gen.Z.27 +as.aix3.gen.Z.00 as.aix3.gen.Z.14 as.aix3.gen.Z.28 +as.aix3.gen.Z.01 as.aix3.gen.Z.15 as.aix3.gen.Z.29 +as.aix3.gen.Z.02 as.aix3.gen.Z.16 as.aix3.gen.Z.30 +as.aix3.gen.Z.03 as.aix3.gen.Z.17 as.aix3.gen.Z.31 + \fI(etc.)\fP +.XE +.LP +Assume that the directory \f(CWas.aix3.gen\fR as shown above has been +recreated somewhere on the machine on which IRAF is to be installed. +We can restore the main IRAF source tree as follows. +.XS +% whoami +iraf +% cd $iraf +% cat /\fIpath\fP/as.aix3.gen/as.* | uncompress | tar -xpf - +.XE +After the above finishes the root IRAF directory should appear as follows +(this is for V2.10). +.XS +HS.AIX3.GEN bin.generic doc math pkg unix +IS.PORT.GEN bin.rs6000 lib mkpkg sys +bin dev local noao tags +.XE +The file \f(CWbin.rs6000\fR is a symbolic link to the BIN directory containing +the RS/6000 AIX/IRAF binaries, which probably does not exist yet. +Configuring the BIN directories is discussed in section \(sc2.2.3. +.NH 3 +Installing from tape +.PP +If you have not already done so, log into the IRAF account so that the files +when restored will belong to IRAF. Mount the distribution tape, which may +be a cartridge tape, a 6250 bpi 9 track tape, a DAT tape, an Exabyte, or +whatever. +.PP +IRAF distribution tapes consist of multiple files separated by tape marks, +with a TOC (table of contents) file as the first file on the tape. To find +out what is on the tape, rewind it and read out the TOC file as follows (the +actual device name will likely be different than that shown in the examples). +.XS +% mt -f /dev/rmt0.1 rew; cat /dev/rmt0.1 +.XE +This should cause a TOC file to be listed similar to the following, except +for the file names which will vary depending upon what type of distribution +you have (the file sizes may vary from what is shown). The example below is +for a distribution of AIX/IRAF for the RS/6000, including the RS/6000 binaries. +.XS +0 Table of Contents + +1 AS.AIX3.GEN 65.0Mb IRAF, NOAO packages and AIX HSI sources +2 IB.AIX3.RS6 31.7Mb RS/6000 binaries for IRAF system +3 NB.AIX3.RS6 30.6Mb RS/6000 binaries for NOAO packages +.XE +.PP +Here, the first column is the file number on the tape, the TOC file being +file zero (the first distribution file is number one), the second column is +the name of the tape file, the third column is the file size in megabytes +(this tells you how much space will be needed to unpack the file on disk), +and the last column is a description of the file contents. +.PP +There are three types of tape files in the example shown: the \f(CWAS\fR +file, which is all the IRAF sources (the core IRAF system, NOAO packages, +and the AIX host system interface), the \f(CWIB\fR files, or IRAF core +system binaries, one for each architecture, and the \f(CWNB\fR files, or +NOAO package binaries. The NOAO package sources are included in the +\f(CWAS\fR file since most people requesting IRAF are expected to want the +astronomical reduction software, although IRAF can be configured without +this if desired. All of the file objects are UNIX \fItar\fR format files, +with the exception of the TOC file which is a simple text file. The +distribution files may be compressed if this was necessary to fit all the +files on a tape. +.PP +In the above example, the \f(CWAIX3\fR in the file names indicates that +these files are for IBM AIX systems. A Sun version 4 distribution is +indicated by a \f(CWSOS4\fR in the file names, and a DECstation Ultrix +distribution is indicated by a \f(CWDSUX\fP, and so on. In principle a +given distribution tape may contain any combination of these files. +.PP +The following commands would suffice to restore the main IRAF system to +disk, given the distribution tape described by the TOC file in our example +above. Once again, the tape device file and possibly the block size will +likely have to be changed to whatever is needed for the actual tape device +used. +.XS +% whoami +iraf +% cd $iraf +% mt -f /dev/rmt0.1 rew; mt -f /dev/rmt0.1 fsf 1 +% tar -xpf /dev/rmt0.1 +.XE +.PP +After the above tar file read operation, the tape is left positioned to +\fIjust before the EOF of the file just read\fR, since \fItar\fP stops +reading the file data before reading the physical EOF. Hence, an +\fImt\0fsf\fR will be required to position to the next file on the tape. +Any combination of \fIfsf\fP (forward skip file) or \fIbsf\fR (backward skip +file) operations may be used to position to a file on a 9 track tape. On a +some tape drives, it is safest to plan things so that only forward file +skips are used, using a rewind and forward skip if it is necessary to +position to an earlier file on the tape. +.PP +Once the main system, containing only sources, is installed it is possible to +create one or more empty BIN directories for the executables, then compile +and link the full system. More commonly one will merely read the precompiled +executables off the distribution tape, as we discuss in the next section. +.NH 3 +Configuring the BIN directories +.PP +In IRAF all the files specific to any particular software or hardware +architecture are contained in a single directory called the BIN, or +"binary", directory. To run IRAF you must install not only the \f(CWAS\fR +(all-sources) directory tree, but the BIN directory for each architecture +you wish to be able to run on. The IRAF core system and the NOAO packages +have separate BIN directories. +.PP +The BIN directories for the IRAF core system or a layered package (such as +NOAO) are located, logically or physically, in the root directory of the +IRAF core system or layered package. Every layered package has its own set +of BIN directories. In the distributed V2.10 system you will find the +following BIN files (directories or symbolic links) at the IRAF root. +.XS +link bin -> bin.generic +directory bin.generic +link bin.rs6000 -> ../irafbin/bin.rs6000 +link noao/bin.rs6000 -> ../../irafbin/noao.bin.rs6000 +.XE +.PP +If the IRAF directory structure is set up as described in \(sc2.1.2, with +$iraf located at iraf/iraf and the BIN directories stored in iraf/irafbin, +then these links will not have to be modified. If a different directory +structure is used you will have to modify the links accordingly. +.PP +The \fIbin\fR link and the \fIbin.generic\fR directory are required for the +correct operation of the IRAF system software (\fImkpkg\fR) and are +maintained automatically by the IRAF software management utilities. +\fIUnder no circumstances should "bin" or "bin.generic" be modified or +deleted\fR. It is a common error to manually delete the bin link and +manually set it to bin.rs6000 or some other architecture. The bin.rs6000 link +can be modified as desired but bin and bin.generic should be left alone. +.PP +Assume that the bin.rs6000 directory has been created somewhere (e.g. in the +iraf/irafbin directory) and that the \f(CWib.aix3.rs6\fR distribution files +for the core IRAF system RS/6000 binaries have been downloaded from the +network archive. We can restore the RS/6000 binaries with the following +commands. +.XS +% cd $iraf/bin.rs6000 +% cat /\fIpath\fP/ib.aix3.rs6/ib.* | uncompress | tar -xpf - +.XE +Similarly, to restore the NOAO package RS/6000 binaries: +.XS +% cd $iraf/noao/bin.rs6000 +% cat /\fIpath\fP/nb.aix3.rs6/nb.* | uncompress | tar -xpf - +.XE +This process is repeated for each architecture. In the case of a RS/6000 +system the standard IRAF distribution supports only the RS/6000 architecture +as illustrated in the above examples. +.PP +The procedure for restoring a BIN directory from a tape distribution is +similar to that described in \(sc2.2.2 for the core system. For example, +.XS +% cd $iraf/bin.rs6000 +% mt -f /dev/rmt0.1 rew; mt -f /dev/rmt0.1 fsf 2 +% tar -xpf /dev/rmt0.1 +.XE +would restore the core system bin.rs6000 directory from a cartridge tape +containing an uncompressed \f(CWib.aix3.rs6\fR as file 2 on the tape. + +.NH 2 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure to not replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF.\(dg +.FS +\(dgThe UNIX utility \fIdiff\fP is useful for comparing files to see +what has changed. +.FE +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each +site to maintain their own custom LOCAL package external to the core IRAF +system. The core system LOCAL is now only a \fItemplate-local\fR to be +copied and used as the starting point for a custom LOCAL layered package. +The layered software enhancements, and the procedure for building a custom +LOCAL, are discussed further in the \fIUNIX/IRAF Site Manager's Guide\fR. + +.NH 2 +Run the INSTALL Script +.PP +Once all of the IRAF files have been restored to disk the AIX/IRAF +installation script must be run to complete the system installation. The +install script modifies the system as necessary to reflect the new root +directory and new default image storage and local bin directories, checks +the mode and ownership of a number of files, installs a small set of IRAF +commands in UNIX, and so on. +.LP +To make a trial run of the install script, enter the following commands: +.XS +% setenv iraf /\fIpath\fP/iraf/ +% cd $iraf/unix/hlib +% source irafuser.csh +% ./install -n +.XE +and answer the questions (don't forget the trailing `/' in the "setenv +iraf"). The "-n" argument tells install to go through the motions without +actually doing anything, so that one can see what will be done before +committing to it. +.PP +Installing IRAF requires a few changes to be made to system directories +outside the IRAF directory tree. Two fifo device entries are made in /dev. +A symbolic link "iraf.h" is created in /usr/include. A number of links (cl, +mkiraf, etc.) are made in /usr/local/bin or some similar directory which +most users can be expected to have in their search path. The tape +allocation task alloc.e is made suid root (there are no known security +loopholes, although we cannot make any guarantees). A symbolic link +imtoolrc is created in /usr/local/lib. +.PP +Following one or more trial "no execute" ("-n") runs to see what the install +script will do, the install script should be run without the "-n" to +complete the installation. This must be done by the superuser as superuser +permission is required to carry out the necessary additions to UNIX. +.PP +It is necessary to run the install script separately on each node from which +IRAF will be used. If a single version of IRAF is installed on a server and +NFS mounted on one or more clients, the install script must be run first on +the server and then on \fIeach\fR client (when installing on a client there +will be warnings about insufficient permission to make changes to files on +the NFS mounted partitions, which can be ignored). To install IRAF on a +diskless client it may be necessary to run the install script \fIon the +server\fR to do the install for the client, since the client's /usr/include +and /dev directories may only be writable by root on the server. On some +systems /usr is mounted read-only, and must be unmounted and remounted +read-write before doing the installation to allow an entry to be made in +/usr/include. Once the installation is complete the default mount access +mode may be restored. +.LP +The exchange with the install script will be along the lines of the +following. +.XS +% ./install -n +new iraf root directory (/iraf/iraf): +default root image storage directory (/d0/iraf): +local unix commands directory (/usr/local/bin): +install iraf for machine type rs6000 +old iraf root = /usr/iraf, old imdir = /d0/iraf +installing iraf at /iraf/iraf, imdir=/d0/iraf, lbindir=/usr/local/bin +proceed with installation? (yes): +.XE +.LP +The "iraf root directory" is the value of $iraf (minus the trailing `/'in +this case). The "root image storage directory" is the default place to put +image data for users; the program may prompt with /tmp if it cannot find any +likely looking data storage areas on your system, but /tmp is not a good +place to put image data as the contents are deleted whenever the system +reboots. The value entered should be the path to a public iraf subdirectory +of a designated data or scratch disk on your system. Lastly, the "local +unix command directory" is where the UNIX callable IRAF startup commands +will be defined. This should be a UNIX directory which is in the default +path of anyone who might want to use IRAF; /usr/local/bin is the most common +value. +.PP +After answering with "yes" or hitting return in response to the "proceed with +installation" query, the script will issue a series of messages as it checks +the system and performs the installation, possibly answering additional +questions in the process. + +.NH +System Checkout +.PP +The basic IRAF system should be usable once the files have been restored to +disk, the binaries have been configured or generated, and the install script +has been run. To verify that the basic system comes up and runs +successfully, login as iraf and startup the CL (IRAF command language) from +the iraf account. You should be able to login as IRAF and type "cl" to +start IRAF, using the login files which come with the distributed system. +.XS +% login iraf +% cl +.XE +.LP +To more thoroughly test the installation it is a good idea to test IRAF from +a user account. To do this you login to a user account and run the +\fImkiraf\fR task to set up the IRAF login files. This will create or +initialize the user's \f(CWuparm\fP (user parameter) directory, and create a +new \f(CWlogin.cl\fP file. It may also be desirable to edit the +user's \f(CW.login\fP file to modify the way the environment variable +\f(CWIRAFARCH\fP is defined. This variable, required for software +development but optional for merely using IRAF, must be set to the name of +the desired machine architecture, in this case \fIrs6000\fR. +.XS +% mkiraf +Initialize uparm? (y|n): y +Terminal types: xterm,gterm,vt640,vt100,etc." +Enter terminal type: xterm +A new LOGIN.CL file has been created in the current directory. +You may wish to review and edit this file to change the defaults. +.XE +The \fIcl\fR command should now start up the CL, which will clear the screen +and print out a startup message. The standard test procedure included in +Volume 1A of the \fIIRAF User Handbook\fP should be run to verify the +installation. + +.bp +.SH +Appendix A. A Complete Example +.PP +Assume we are installing IRAF for the first time on a RS/6000 running IBM +AIX 3.2.x or greater. The IRAF directories will be located at /u3/iraf +using a symbolic link /iraf to point to this location. We will configure +only rs6000 binaries, locating the BIN directories in the directory +/iraf/irafbin. The local user commands will be placed in /usr/local/bin. +We will be installing from a network distribution with the distribution +files located in /scr0. +.PP +The first step is for the superuser to create an account for the fictitious +user `\f(CWiraf\fP', with home directory /iraf/iraf/local and shell +/bin/csh. The /u3/iraf directory is created owned by IRAF, and pointed to +by the link /iraf. We then login as IRAF (a warning message will be printed +since there is no login directory) and proceed as follows. +.XS +% whoami +iraf +% +% setenv iraf /iraf/iraf/ \fR# set root directory\fP +% mkdir /iraf/iraf +% +% cd $iraf \fR# unpack main IRAF distribution\fP +% cat /scr0/as.aix3.gen/as.* | uncompress | tar -xpf - +% +% cd /iraf \fR# create BIN directories\fP +% mkdir irafbin +% mkdir irafbin/bin.rs6000 +% mkdir irafbin/noao.bin.rs6000 +% +% cd $iraf/bin.rs6000 \fR# unpack core bin.rs6000\fP +% cat /scr0/ib.aix3.rs6/ib.* | uncompress | tar -xpf - +% +% cd $iraf/noao/bin.rs6000 \fR# unpack NOAO bin.rs6000\fP +% cat /scr0/nb.aix3.rs6/nb.* | uncompress | tar -xpf - +% +% cd $iraf/unix/hlib \fR# run the INSTALL script\fP +% source irafuser.csh +% ./install -n +% su +# ./install +# exit +% +% cd +% source .login \fR# read new .login\fP +% rehash \fR# pick up new iraf commands\fP +% cl \fR# verify that the CL runs\fP +.XE +.LP +This will fully install IRAF on a server or a standalone system. If this +version of IRAF will be accessed via NFS by client nodes then the IRAF +install script must be run on each client node as well. Installing IRAF +does not allow one to access local tape drives, printers, and so on. +Refer to the \fIUNIX/IRAF Site Manager's Guide\fR for information on how +to configure IRAF for the local site. diff --git a/doc/aosvsiraf.hlp b/doc/aosvsiraf.hlp new file mode 100644 index 00000000..6976e117 --- /dev/null +++ b/doc/aosvsiraf.hlp @@ -0,0 +1,384 @@ +.help install Sep87 "AOSVS/IRAF Installation Guide" +.sp 3 +.ce +\fBAOSVS/IRAF Installation and Maintenance Guide\fR +.ce +(draft) + +.ce +Skip Schaller +.ce +September 11, 1987 + +.nh +Introduction + + This document is a collection of notes for the installation of IRAF +under AOSVS. It is not a complete guide, as is available for UNIX or VMS. +Please refer to the UNIX or VMS guides for more information. These notes +basically describe things unique to the AOSVS installation. + +.nh +System Installation + + The following steps should be used to install the IRAF system under AOSVS. +Since the AOSVS version is distributed as a Load and Go tape, there should be +very little other configuration steps to do. See the UNIX or VMS installation +manuals for reference. + +.nh 2 +Create an IRAF Account + + The first step is to set up an account for IRAF. Become a superuser and +use the PREDITOR to create a user profile called IRAF. A sample profile +appears in the appendix to this document. Users who wish to use IRAF will +need at least these privileges, too. Note that 100MB of disk quota is given. +About 70MB are necessary to hold the full system, including sources. (This +will be much less when a shared library version of AOSVS/IRAF is developed +under AOSVS revision 7.) If necessary, the system may be stripped down to +only runtime files, which will take up about 24MB. To do this, see the UNIX +installation manual. +.ks +.nf + + cl> help doc$unixiraf.hlp fi+ | lpr + +.fi +.ke + +.nh 2 +Choose a root directory for IRAF + + The root directory for IRAF should be a subdirectory of an LDU. This +is done for two reasons. First, the shortest pathname to the root +directory will speed up pathname resolution. Second, this will avoid +the maximum directory depth limit of AOSVS with IRAF's deeply +nested directory tree. So, create a CPD called IRAF, with a 100MB limit. +.ks +.nf + + *) defacl iraf,oware +,re + *) dir :ldu + *) create/dir/max=200000 iraf + *) dir iraf + +.fi +.ke + +.nh 2 +Read the Distribution Tape + + The system is distributed on one or more DUMP format tapes. +The order in which the tapes are read is not important. If you requested +1600 BPI, you will get two tapes, and you should type the following to load +each tape. +.ks +.nf + + *) load_ii/density=1600/buffersize=8192 @mtb0:0 + +.fi +.ke +If you requested 6250 BPI, you will get one tape, and you should type the +following to load the tape. +.ks +.nf + + *) load_ii/density=6250/buffersize=32768 @mtb0:0 + +.fi +.ke + +.nh 2 +Set up the Host System Environment + + You now must install some links so that users may gain access to IRAF. +To do this, run the following CLI script to install the links. Examine +the script carefully before you run it, so that you understand what it does +and to make sure that it doesn't conflict with something locally installed. +.ks +.nf + + *) dir aosvs:hlib + *) install_links :ldu :util + +.fi +.ke +The first argument to install_links should be the pathname of the directory +or LDU containing the IRAF root directory "IRAF". The second argument can be +the pathname of any directory on the users' default searchlist. + + Note that the filename, IRAFDIR, is a reserved symbol, and should not be +used anywhere else in the AOSVS system. + + If your system doesn't already have one, you will probably want to set +up a scratch directory called :TMP. + + Edit the following command into your system UP.CLI macro, near the end: +.ks +.nf + + irafdir:aosvs:hlib:upiraf/nonet + +.fi +.ke + This will setup the IRAF magtape allocation facility. Edit the file +:iraf:aosvs:os:util:remop.cli to set the ACL of the file @magtape.defacl +according to your wishes. An ACL of +,WARE will allow non-IRAF users +to use the magtapes without allocation. A null ACL will require non-IRAF +users to use the macros ?MT, AMT, and DMT to access the tape drives. +You should edit +:iraf:aosvs:os:util:?mt.cli to reflect you own tape drive configuration. +If you use the /noremop switch, the IRAF magtape allocation facility +will not be setup. + + If you do not use the /nonet switch, you will get the TCPIP networking +facility for IRAF. You must have previously configured TCPIP, of course. + +.nh 2 +Configure the IRAF Environment + + You may now log in as user IRAF to check that certain configuration +files reflect your site. Edit them as necessary. The first directory to +check is :IRAF:DEV. The most important file here is DEVICES. Edit this +file to reflect your local complement of magnetic tapes. Check the other +files in this directory. See the UNIX installation manual for reference. +Possible changes would be to edit TERMCAP and GRAPHCAP to support other +terminals, to cache these entries for efficiency, to edit HOSTLOGIN, HOSTS, +& UHOSTS for networking, or to link in your CALCOMP library. + + Next check directory :IRAF:AOSVS:HLIB. The most important files here are +ZZSETENV.DEF and LOGIN.CL. You may also want to look at DISKSPACE.CL, +GRIPES.CL, and SPY.CL. If you ever wish to rebuild any IRAF libraries, and +you don't have MV/UX, IRAF will not be able to topologically sort the libraries +and you will need to use the "-t" switch for LFLAGS in the file MKPKG.INC. +You might also want to check the files IRAFCC.CLI, IRAFF77.CLI, IRAFLINK.CLI, +IRAFMASM.CLI, and IRAFSPP.CLI to make sure that they are pointing to the +correct directories for the compilers. You may also want to check the batch +queue definitions in IRAFQBBATCH.CLI, IRAFQBDEFER.CLI, IRAFQBFAST.CLI, and +IRAFQBSLOW.CLI. Finally check IRAF.CLI, MKIRAF.CLI, and UPIRAF.CLI. + + Finally check the file, :IRAF:AOSVS:HLIB:LIBC:IRAF.H. You may want to +edit the values of IRAF, HOST, or TMP, but this is not necessary. You can +edit the pathnames of the include files, but this is also not necessary, as +they all go through a symbolic link. + +.nh 2 +Log into IRAF + + The system is now ready for users to log into the IRAF system. Log in +as a normal user and create an IRAF HOME directory. I recommend that this +be a control point directory immediately below your system home directory. +Move to that directory and run MKIRAF. Answer the questions. Taking the +default is recommended. Note that you may redefine your "imdir" later. +Make sure that the name of your terminal appears in dev$termcap. You may +now enter the IRAF system by typing "iraf". After this initial setup, +you may enter IRAF just by moving to this IRAF home directory and typing +"iraf". Note that you must start up IRAF from this same IRAF home directory. +For example: +.ks +.nf + + ) dir :udd:skip + ) create/dir/max=999999999 iraf + ) dir iraf + ) mkiraf + ) iraf + +.fi +.ke + Note that to use IRAF on a Visual 500, you must display BOTH alpha and +graphics planes, use 3/4 graphics scaling, and graphics trailer code #001=013. +Also note the following different definitions of keyboard keys as opposed +to other IRAF systems. The keyboard interrupt (abort) is either ^C^A or +^C^B instead of just ^C. The End Of File key is ^D, not ^Z. Available +editors are SED, VI, and EMACS. The OS escapes are: +.ks +.nf + + ! for CLI commands + !! for sh commands + !!! for csh commands + +.fi +.ke + The following background options are available: +.ks +.nf + + & (default) = child process at the same priority as your cl + &bkg = child process at the same priority as the batch queues + &batch = batch queued jobs + +.fi +.ke +Unlike other systems, if you logout of IRAF, you will kill your background +child processes (first two options). If you use a batch queued job, you may +logout of IRAF, and even logout of AOSVS. Due to restriction of AOSVS, IRAF +will not work in CPU time limited batch streams. +.nh +System Maintenance + + Extensive system maintenance should not be necessary at other sites. The +following is included just in case. The procedures are similar to those for +UNIX. See the UNIX installation manual for further reference. +.nh 2 +Bootstrapping + + Bootstrapping the system recompiles and links the host system interface, +the kernel libraries and bootstrap utilities. To do this type the following: +.ks +.nf + + ) dir :iraf:aosvs + ) mkboot + +.fi +.ke +.nh 2 +Sysgen + + The sysgen procedure recompiles and links the portable part of the system. +Certain files must be precompiled to avoid compiler optimization problems. +Then you will probably want to go back and rebuild the bootstrap utilities +with full filename mapping. Type the following: +.ks +.nf + + ) dir :iraf + ) :iraf:aosvs:precomp + ) mkpkg + ) dir :iraf:aosvs + ) rmlib + ) mkpkg + +.fi +.ke +.nh 2 +Relinking the System + + A relink of the system is done to force all the executables to be +relinked to incorporate any changes in the libraries. Type the following: +.ks +.nf + + ) dir :iraf + ) mkpkg update + ) dir :iraf:aosvs + ) mkpkg + +.fi +.ke +The last command may not be necessary if there are no changes to libos.a. +.nh 2 +Bringing the system up to date after loading it from tape. + + Since AOSVS does not properly restore the time last modified of the +files you read from the distribution tape, you may wish to bring the +IRAF libraries up to date without having to recompile everything. To do +this, follow the instructions for the -u option of mkpkg in the online help. +.nh 2 +Multiple versions of IRAF on the same computer. + + Multiple versions of IRAF may be maintained on the same computer system, +and may be selected at will. Simply load the entire new IRAF directory tree +at any desired IRAF root directory, and change the link :IRAFX (or :IRAFO) +to point to that new IRAF root directory. To get the new version, you must +type IRAFX (or IRAFO) before typing MKIRAF or IRAF. Of course, this can be +put into your login startup CLI script. Any equivalent operation is OK, too. +IRAFX is used for new (experimental) versions of IRAF. IRAFO is used for +older versions than the current default system. +.nh +New Graphics and Image Devices + + New devices are usually very easy to add to the system. See the UNIX +installation manual for full details. +.nh 2 +Graphics Terminals + + A new graphics terminal can be interfaced by simply installing its +entry into dev$graphcap. See the GIO documentation. +.ks +.nf + + cl> help gio$doc/gio.hlp fi+ | lprint + +.fi +.ke +.nh 2 +Hardcopy Graphics plotters + + A new hardcopy graphics plotter can be interfaced most easily through +the Simple Graphics Interface (SGI). This requires designing a graphcap entry +as above and writing a very simple metacode translator host program. See +the above mentioned documentation and the SGI manual. +.nh 2 +Image Display Devices + + See the UNIX installation manual. +.ks +.nf + + APPENDIX + +A) Sample user profile for IRAF (owner of IRAF system files) and/or potential +users of IRAF. + +INITIAL IPC FILE [:MACROS:USER_SIGNON.IPC] +PROGRAM [:CLI.PR] +CREATE WITHOUT BLOCK [YES] +USE IPC [YES] +USE CONSOLE [YES] +USE BATCH [YES] +USE VIRTUAL CONSOLE [YES] +ACCESS LOCAL RESOURCES FROM REMOTE MACHINES [YES] +CHANGE PASSWORD [YES] +UNLIMITED SONS [YES] +CHANGE PRIORITY [NO] +CHANGE TYPE [NO] +CHANGE USERNAME [NO] +ACCESS DEVICES [NO] +SUPERUSER [NO] +SUPERPROCESS [NO] +MODEM [YES] +CHANGE ADDRESS SPACE TYPE [YES] +CHANGE WORKING SET LIMIT [YES] +PRIORITY [2] +MAX QPRIORITY [0] +DISK QUOTA [200000] +LOGICAL ADDRESS SPACE - BATCH [-1 SYSTEM DEFAULT] +LOGICAL ADDRESS SPACE - NON-BATCH [-1 SYSTEM DEFAULT] +MINIMUM WORKING SET SIZE - BATCH [-1 SYSTEM DEFAULT] +MAXIMUM WORKING SET SIZE - BATCH [-1 SYSTEM DEFAULT] +MINIMUM WORKING SET SIZE - NON-BATCH [-1 SYSTEM DEFAULT] +MAXIMUM WORKING SET SIZE - NON-BATCH [-1 SYSTEM DEFAULT] +USER COMMENT [] + +.fi +.ke +.ks +.nf + +B) AOSVS Bugs. + +.fi + The current DG release of C has a bug which hangs up IRAF if the file +:ETC:PASSWD does not exist or is not setup properly. This file comes +with MV/UX. If you are running MV/UX, and you keep the file up to date, +you should have no problem. Otherwise, you should create the file and +enter the following as a minimum. Ideally, you should add one line for +each user in the system. +.nf + +bin::2:2::/usr/bin: +iraf::89:::/udd/iraf: +lp::6:2::/usr/lib: +mail::8:::/usr/spool/mqueue: +op::0:::/udd/op: +root::0:::/udd/root: +uucp::5:1::/usr/spool/uucp:/usr/lib/uucp/uucico + + +.fi +.ke +.endhelp diff --git a/doc/bsdiraf.ms b/doc/bsdiraf.ms new file mode 100644 index 00000000..95c74120 --- /dev/null +++ b/doc/bsdiraf.ms @@ -0,0 +1,711 @@ +.RP +.TL +BSD-UNIX/IRAF Installation Guide +.AU +Doug Tody +.AI +Central Computer Services +.br +.K2 "" "" "\(dg" +.br +July 1989 + +.AB +This document describes how to install IRAF on a BSD-UNIX system, or update +an existing installation. Both standalone and networked, multiple architecture +configurations are described. Only those issues which one must understand +to install BSD-UNIX/IRAF are discussed here; +a companion document, \fIUNIX/IRAF Site Manager's Guide\fR, +deals with other issues such as interfacing new devices, +configuring the IRAF networking system, adding layered software, and so on. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling BSD-UNIX/IRAF\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Install the files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Distribution tape format\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing the main system\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Configuring the BIN directories\l'|5.6i.'\0\05 +.br +\h'|1.5i'2.2.3.1.\h'|2.2i'BIN directories under the IRAF root.\l'|5.6i.'\0\05 +.br +\h'|1.5i'2.2.3.2.\h'|2.2i'BIN directories outside the IRAF root.\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.2.4.\h'|1.5i'Network software distributions\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.3.\h'|0.9i'Merge local revisions back into the new system\l'|5.6i.'\0\07 +.br +\h'|0.4i'2.4.\h'|0.9i'Run the INSTALL Script\l'|5.6i.'\0\08 +.sp +3.\h'|0.4i'\fBSystem Checkout\fP\l'|5.6i.'\0\08 +.sp +\fBAppendix A.\0A Complete Example\fP\l'|5.6i.'\0\10 + +.bp +.NH +Introduction +.PP +Before installing BSD-UNIX/IRAF, one must 1) obtain an appropriate +BSD-UNIX/IRAF distribution from the IRAF project, 2) select the machine on +which the system is to be installed, and arrange for sufficient disk space +to hold the system (approximately 65 Mb for BSD-UNIX/IRAF), +and 3) set aside sufficient time to do the installation. +If these directions are followed carefully and mistakes are avoided 1-2 +hours should suffice to do the installation. +.PP +This Installation Guide is intended primarily for sites installing IRAF on +a VAX running Berkeley UNIX 4.3, although it may be used as a general guide +when doing ports to BSD-like systems. +Other popular UNIX systems for which IRAF is available, e.g. SunOS and Ultrix, +have their own system specific IRAF installation guides. +.PP +The device and system configuration tables in the standard IRAF distribution +come configured for the NOAO systems on which the distribution tapes were made, +and will have to be modified once the system is installed. +These modifications are discussed in detail in the companion document +\fIUNIX/IRAF Site Manager's Guide\fP. +To simplify the installation process as well as future upgrades, we have tried +to isolate the site dependent files to the minimum number of directories, i.e., +\f(CWdev\fR, \f(CWhlib\fR (a subdirectory of \f(CW$iraf/unix\fR), and +\f(CWlocal\fR. +The remainder of the system should not require any modifications. +.PP +In IRAF V2.8 local additions to the system are no longer installed directly +in IRAF; the \fIlayered software\fP enhancements allow maintainance of a +custom LOCAL package outside IRAF. Sites which had previously maintained their +own IRAF software in \f(CW$iraf/local\fR will have a one-time conversion job, +discussed in the Site Manager's Guide; in future releases only a single file +will need to be edited to reinstall the local additions. +.sp +.TS +center; +cb s s +l l l. +IRAF HOTLINE +.sp +telephone \f(CW(602) 323-4160\fP +internet \f(CWiraf@noao.edu\fP +span/hepnet \f(CWnoao::iraf\fP (noao = 5355) +uucp \f(CW{arizona,decvax,ncar}!noao!iraf\fP or +uucp \f(CWuunet!noao.edu!iraf\fP +bitnet \f(CWiraf@noao.edu\fP (through a gateway) +.TE +.PP +Issues such as interfacing new graphics terminals, plotters, or image displays +are also described in the Site Manager's Guide. Help is available via the +IRAF Hotline if any problems should arise while installing the system or +interfacing new devices. + +.NH +Installing BSD-UNIX/IRAF +.PP +Installing BSD-UNIX/IRAF on an actual BSD-UNIX system is straightforward. +First one obtains a distribution, +usually by writing to NOAO and requesting the normal tape distribution, +then one follows the procedure outlined below to install the system. +Most of these steps should be performed while logged in as `iraf'; +superuser permission is required in the final stages of the installation, +to run the \f(CWinstall\fP script. +.DS +# Prepare the root IRAF directory. +\f(CWif (new installation) then + create `iraf' account +else if (updating an old installation) then + save locally modified files + delete old version of iraf +endif\fP + +# Install the files. +\f(CWuse the `tar' program to unpack the distribution files +configure the BIN directory for each supported architecture\fP + +# Merge local revisions into new system. +\f(CWif (updating an old installation) then + merge locally modified files back into new system +endif\fP + +# Run the INSTALL script (as superuser). +# Checkout the new system. +.DE +.LP +It is important to realize before beginning the installation that IRAF is not +an isolated program or collection of programs, but a complex system in its own +right, providing a full programming environment, support for the addition of +layered software (including locally added software), and so on. +Someone who is familiar with the usual installation +procedures for UNIX add-on programs will get tripped up if they try to follow +similar procedures for installing IRAF, without first reading these +installation instructions carefully. A complete example for the simplest +type of installation is provided in Appendix A. + +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation then you will be replacing +IRAF by the new version, and IRAF should already have an account and root +directory on the desired host system. You should save any locally modified +files and delete the old system, e.g., login as `\f(CWiraf\fP' and enter: +.DS +\f(CW% cd $iraf\fP\(dg +\f(CW% tar -cf /tmp/SAVE.tar local dev unix/hlib +% /bin/rm -rf *\fP +.DE +.FS +\(dg\0$iraf symbolizes the UNIX pathname of the root IRAF directory. +.FE +.LP +There are many variants on this, e.g., you could run \f(CWfind\fR to determine +which files need to be saved and later merged back in, and you could copy +these files to some other directory, rather than making a full tar backup. +Although we suggest saving the entire directories listed above, in practice +only a few files are likely to have been modified, e.g., +.DS +\f(CWdev/devices +dev/hosts +dev/termcap +dev/graphcap +hlib/extern.pkg +hlib/login.cl +hlib/zzsetenv.def +local/.login\fP +.DE +.LP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. Note that it is essential to delete the +old system as described above to avoid creating junk files or +directories when the new system +is installed (due to file or directory name changes or deletions). +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set up +a new account for the fictitious user `\f(CWiraf\fP'. This is unconventional +but is recommended for the following reasons: +.DS +.IP \(bu +All IRAF system management should be performed using some derivative of the +environment provided by the "." files in the \f(CWiraf\fP login directory. +If this is not done important environment definitions may be missing which +are required for the correct execution of the software (this affects only +IRAF system management, not normal runtime usage). +.IP \(bu +Multiple people may need to be IRAF system manager. Having a separate account +avoids the need for one user to know another user's password. Even if there +is only one site manager at your site, it may be necessary to give login +information to the IRAF Hotline personnel to allow them to investigate a +problem. +.IP \(bu +Having IRAF owned by root is not a good solution as then anyone who needs to +serve as IRAF site manager would require the root password. +.DE +.LP +The common practice on most BSD systems is to locate the IRAF root at +\f(CW/usr/iraf\fP, although any other directory would do (try to keep the +path to the root short to avoid later filename truncation when IRAF is run). +Note that the \fIlogin\fR directory for the iraf account should be +\f(CW$iraf/local\fR (e.g., \f(CW/usr/iraf/local\fP), rather than the more +conventional \f(CW$iraf\fR or root directory, as we want to keep all the +locally modified files in subdirectories off the iraf root, to simplify +site management. If this point is missed the iraf environment will not be +set up properly, and later problems are sure to result. +.PP +It is not necessary to place the entire system on the same disk; the binary +files and external packages like \f(CWnoao\fP may be located on a separate +disk from the core system if desired; see \(sc2.2.1 for the sizes of the +different components. +.PP +Do not worry about configuring the \f(CW.login\fP or other environment +files for the new account as these will be created when the iraf system +is later restored to disk. + +.NH 2 +Install the files +.PP +If you have not already done so, log into the iraf account so that the files +when restored will belong to iraf. Mount the distribution tape, which might +be, for example, a 1600\(dg or 6250 bpi 9 track tape, or a TK50 cartridge tape. +.FS +\(dgDistributions for a 1600 bpi tape require two tapes. Instructions for +reading in IRAF from two tapes are contained in a separate cover letter. +.FE +.PP +If you are installing IRAF on a system which has a local tape drive you can +skip what follows and go to \(sc2.2.1. +.PP +If the tape drive is on a remote node connected via the network +then it is simplest to copy the files to a temporary disk on the remote node, +e.g., with the unix utility \f(CWdd\fP, then use \f(CWrsh\fR and \f(CWcat\fR +to pipe the remote file into the standard input of \f(CWtar\fR to unpack it +on the local node. If you have NFS, do not use it to access the remote file +on disk directly, +as NFS is not an error corrected transfer protocol and data corruption can +result if there are any problems with the networking interfaces on your +systems (using \f(CWrsh\fR is also more efficient). +.LP +For example, if +.DS +\f(CW% tar -xpf /dev/nrmt8\fP +.DE +would be used to unpack a tarfile from tape to disk on the local node as in +\(sc2.2.1, then +.DS +\f(CW% dd if=/dev/nrmt8 of=file.tar bs=10240 # remote node +% rsh \fInode\fP "cat file.tar" | tar -xpf - # local node\fR +.DE +will accomplish the same thing using the network and an intermediate disk +file. The block size shown is for a standard tar file on a 9 track tape. +It is also possible to execute \f(CWdd\fR remotely to read directly from +the tape, eliminating the disk file, if you are certain of the current file +position of the tape. +.NH 3 +Distribution tape format +.PP +Beginning with IRAF version 2.8, distribution tapes consist of multiple +files separated by tape marks, with a TOC (table of contents) as the +first file on the tape. To find out what is on the tape, rewind it and +read out the TOC file as follows (the device name required for your site +may vary from that shown): +.DS +\f(CW% mt -f /dev/nrmt8 rew; cat /dev/nrmt8\fP +.DE +This should cause a TOC file similar to the following to be +listed for a normal BSD-only distribution; the sizes of the files will +change for different releases: +.DS +.ps -2 +\f(CW0 Table of Contents +1 AS.VBSD.GEN 44.9Mb IRAF, NOAO packages and VAX/BSD sources +2 IB.VBSD.VAX 9.9Mb IRAF system binaries for VAX/BSD +3 NB.VBSD.VAX 12.3Mb NOAO packages binaries for VAX/BSD +.ps +.DE +.LP +Here, the first column is the file number on the tape, the TOC file being file +zero, the second column is the name of the tape file, the third column is +the file size in megabytes (this tells you how much space will be needed +to unpack the file on disk), and the last column is a description of the +file contents. +.PP +There are three types of tape files in the example shown: the \fBAS\fR file, +which is all the IRAF sources (core system, NOAO packages, and VAX/BSD host +system interface), the \fBIB\fR file, or IRAF core system binaries, +and the \fBNB\fR file, or NOAO binaries. The NOAO sources +are included in the AS file since most people requesting IRAF are expected +to want the astronomical reduction software, although IRAF can be configured +without these if desired. All of the file objects are UNIX \f(CWtar\fR +format files, with the exception of the TOC file which is a simple text file. +.NH 3 +Installing the main system +.PP +To install the main IRAF system, login as \f(CWiraf\fR, set the current +directory to +\f(CW$iraf\fP, and read and unpack the \f(CWAS\fR file from the tape, e.g., +for a nine track tape, given the example TOC file shown above, where the +\f(CWAS\fP file is file 1 on the tape: +.DS +\f(CW% mt -f /dev/nrmt8 rew; mt -f /dev/nrmt8 fsf 1 +% tar -xpf /dev/nrmt8\fP +.DE +If the last operation performed on the tape was to read the TOC file, the tape +will already be positioned to file 1 (which is the \f(CWAS\fP file in our +example), and the rewind/forward-skip step can be omitted. After reading and +unpacking the tape file the current directory should be listed to verify that +the correct tape file was read. If the correct tape file was read, the tape +file name (e.g., \f(CWAS.VBSD.GEN\fP) will appear as a zero length file in the +current directory after the unpack operation. +.PP +After either of the above tar file read operations, the tape is left +positioned to \fIjust before the EOF of the file just read\fR, +since \f(CWtar\fP stops reading the file data before reading the physical EOF. +Hence, an \f(CWmt\0fsf\fR will be required to position +to the next file on the tape. Any combination of \f(CWfsf\fP (forward skip +file) or \f(CWbsf\fR (backward skip file) operations may be used to position +to a file on a 9 track tape. +.PP +Once the main system, containing only sources, is installed it is possible to +create one or more empty BIN directories for the executables, then compile +and link the full system. More commonly one will merely read the precompiled +executables off the distribution tape, as we discuss in the next section. +.NH 3 +Configuring the BIN directories +.PP +The executables for a software product such as the IRAF core system or the +NOAO packages are contained in a single directory, the so-called BIN directory. +In some cases the system object files and libraries may also reside in the BIN, +e.g., to support software development for multiple architectures. +In the rest of this document, we will assume a single IRAF system, supporting +only the VAX/BSD architecture both for the runnable system and for software +development. A system configured for multiple architecture support will have +multiple BIN directories, one for each architecture. +Further information on multiple architecture support is given in the +\fIUNIX/IRAF Site Manager's Guide\fP. +.PP +For the default VAX/BSD-only configuration, two BIN directories will be +required: one for the core system, and one for the NOAO packages. +Since a BIN can be fairly large one may want to +locate the BIN directory somewhere outside the IRAF directory tree, to provide +maximum flexibility in allocating the remaining free space in the available +disk partitions. A BIN may be located either in the root directory of the +system to which it belongs, or in an external directory, replacing the entry +in the package root directory by a symbolic link. The procedures for +configuring the BINs in each case are outlined below. +.NH 4 +BIN directories under the IRAF root. +.PP +Go to \(sc2.2.3.2 if you want the binaries outside the IRAF root. +If the executable files are to reside in the same directory tree as the +rest of IRAF, it is necessary first to remove the \f(CWbin.vax\fP link +just created when the \f(CWAS\fP file was read in, create a new \f(CWbin.vax\fP +subdirectory, enter it and read the BIN contents from tape. +Assuming the vax BIN is file 2 on the 9 +track distribution tape and we have just unpacked tar file 1, leaving the +tape positioned to just before file 2, the following commands would suffice +to read the BIN (tape file \f(CWIB.VBSD.VAX\fP) onto disk: +.DS +\f(CW% cd $iraf +% rm bin.vax # remove old symbolic link +% mkdir bin.vax # create real bin directory +% cd bin.vax +% mt -f /dev/nrmt8 fsf 1 # position tape to IB.VBSD.VAX +% tar -xpf /dev/nrmt8 # read iraf binaries\fP +.DE +Alternatively we could have rewound the tape and done an \f(CWfsf\02\fP to +get to tape file 2. Now read in the NOAO binaries. +.DS +\f(CW% cd $iraf/noao +% rm bin.vax # remove old symbolic link +% mkdir bin.vax # create real bin directory +% cd bin.vax +% mt -f /dev/nrmt8 fsf 1 # position tape to NB.VBSD.VAX +% tar -xpf /dev/nrmt8 # read iraf binaries\fP +.DE +.LP +You are now finished reading the tape and may proceed to \(sc2.3 (or 2.4 for +a new IRAF installation). +.NH 4 +BIN directories outside the IRAF root. +.PP +Let's assume we have a directory \f(CW/u3\fR with sufficient +space for our 10 Mb vax BIN. Assuming the vax BIN is file 2 on the 9 +track distribution tape and we have just unpacked tar file 1, leaving the +tape positioned to just before file 2, the following commands would suffice +to read the BIN (tape file \f(CWIB.VBSD.VAX\fP) onto disk: +.DS +\f(CW% mkdir /u3/bin.vax +% cd /u3/bin.vax +% mt -f /dev/nrmt8 fsf 1 +% tar -xpf /dev/nrmt8\fP +.DE +Alternatively we could have rewound the tape and done an \f(CWfsf\02\fP to +get to tape file 2. Now read in the NOAO binaries. +.DS +\f(CW% mkdir /u3/noao.bin.vax +% cd /u3/noao.bin.vax +% mt -f /dev/nrmt8 fsf 1 +% tar -xpf /dev/nrmt8\fP +.DE +.LP +The next step is to tell IRAF where the new BIN directories are: +.DS +\f(CW% cd $iraf +% rm bin.vax # remove old link, if any +% ln -s /u3/bin.vax bin.vax +% cd noao +% rm bin.vax # remove old link, if any +% ln -s /u3/noao.bin.vax bin.vax\fP +.DE +.NH 3 +Network software distributions +.PP +Although most IRAF installations or updates will be made from a distribution +tape, it is also possible to install IRAF from compressed disk tar files +acquired via FTP from the IRAF network archive. The procedure followed is +very similar to installing IRAF from a tape, except that the file objects are +stored in the FTP archive rather than on tape, and the content of the +distribution files is slightly different. Most significantly, the binaries +outside the HSI +are omitted hence if a network installation is attempted it will be necessary +to recompile the full system. +.PP +The main difference between the distribution tape and the network archive is +that the \f(CWAS\fR (all sources) file object is gone, being replaced by the +following files, which one has to manually combine to produce the equivalent +of the \f(CWAS\fP. +.DS +.IP \f(CWHS.VBSD.GEN\fR 20 +The host system interface (HSI) for VAX BSD-UNIX, including the HSI binaries. +.IP \f(CWIS.PORT.GEN\fR +The IRAF core system sources (for any system). +.IP \f(CWNS.PORT.GEN\fR +The NOAO package sources (for any system). +.DE +.PP +The \f(CWIS\fP and \f(CWNS\fP (core system and NOAO sources) are portable and +may be combined with the \f(CWHS\fP for any host machine to produce an IRAF +for that host. These files are stored in the +IRAF network archive in compressed form, hence the actual file names will have +a \f(CW.Z\fP appended and will have to be uncompressed with the UNIX program +\f(CWuncompress\fR before being unpacked with \f(CWtar\fP. +.PP +To build \f(CWVBSD\fP IRAF using the network file objects, +starting from an empty root directory belonging to IRAF, with the compressed +archive files stored in \f(CW/tmp\fP: +.DS +\f(CW% cd $iraf +% uncompress < /tmp/IS.PORT.GEN.Z | tar -xpf - +% uncompress < /tmp/HS.VBSD.GEN.Z | tar -xpf - +% mkdir noao; cd noao +% uncompress < /tmp/NS.PORT.GEN.Z | tar -xpf -\fR +.DE +After running the INSTALL script to configure the programming environment +(see \(sc2.4), one should then configure an empty \f(CWvax\fP BIN +directory and start a SYSGEN. This should be done from the IRAF account. +The following assumes that the BIN is to be placed in a subdirectory +rather than being a link to a remote directory (see \(sc2.2.3). +.DS +\f(CW% cd $iraf +% mkdir bin.vax +% ln -s bin.vax bin +% mkpkg >& spool\fR +.DE +This would compile all the binaries. To do the same for the NOAO packages, +one could configure the empty bin and then compile the system as follows. +.DS +\f(CW% cd $iraf/noao +% mkdir bin.vax +% ln -s bin.vax bin +% mkpkg -p noao >& spool\fR +.DE +As we see, the commands are the same except for the root directory and the +additional argument required to tell \f(CWmkpkg\fP the +name of the non-core system package being compiled. +.PP +At the present time, anyone wishing to access files from the IRAF network +archive should first contact the IRAF group to determine the status of the +archive and how to access it. In addition to the standard release products, +various updates, bug fixes, and add-on packages may be retrieved from the +archive without having to wait for a major release of the full system. + +.NH 2 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure not to replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF.\(dg +.FS +\(dgThe UNIX utility \f(CWdiff\fP is useful for comparing files to see +what has changed. +.FE +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each site +to maintain its own custom LOCAL package external to the core IRAF system. +The core system LOCAL is now only a \fBtemplate-local\fR to be copied and +used as the starting point for a custom LOCAL. The layered software +enhancements, and the procedure for building a custom LOCAL, +are discussed further in the \fIUNIX/IRAF Site Manager's Guide\fR. + +.NH 2 +Run the INSTALL Script +.PP +Once all of the IRAF files have been restored to disk the IRAF install +script (\f(CWhlib/install\fP) must be run to complete the system installation. +The install script modifies the system as necessary to reflect the new root +directory and new default image storage and local BIN directories, +checks the mode and ownership of a number of files, installs a small set +of IRAF commands in UNIX, and so on. +.LP +To make a trial run of the install script, enter the following commands: +.DS +\f(CW% setenv iraf /\fIpath\fP/iraf/ +% cd $iraf/unix/hlib +% source irafuser.csh +% ./install -n\fP +.DE +and answer the questions. The "\f(CW-n\fP" argument tells \f(CWinstall\fP to +go through the +motions without actually doing anything, so that one can see what will be done +before committing to it. +.PP +Following one or more trial "no execute" ("\f(CW-n\fP") runs, the install script +should be run without the "\f(CW-n\fP" to complete the installation. +This must be +done by the superuser as superuser permission is required to carry out the +necessary additions to UNIX. +.LP +The exchange with the install script will be along the lines of the +following: +.DS +.ps -2 +\f(CW% ./install -n +new iraf root directory (/iraf/iraf): /usr/iraf +default root image storage directory (/tmp2/iraf): +local unix commands directory (/local/bin): /usr/local/bin +install iraf for machine type vax +old iraf root = /iraf/iraf, old imdir = /tmp2/iraf +installing iraf at /usr/iraf, imdir=/tmp2/iraf, lbindir=/usr/local/bin +proceed with installation? (yes):\fP +.ps +.DE +.PP +The "iraf root directory" is the value of \f(CW$iraf\fR. The "root image +storage directory" is the default place to put image data for users; the +program may prompt with \f(CW/tmp\fR if it cannot find any likely looking +data storage areas on your system, but \f(CW/tmp\fR is not a good place to +put image data as the contents are deleted whenever the system reboots. +The value entered should be the path to a public iraf subdirectory of a +designated data or scratch disk on your system. Lastly, the "local unix +command directory" is where the UNIX callable IRAF startup commands will +be defined. This should be a UNIX directory which is in the default path +of anyone who might want to use IRAF; \f(CW/usr/local/bin\fR is the most +common value. +.PP +After answering with "yes" or hitting return in response to the "proceed with +installation" query, the script will issue a series of messages as it checks +the system and performs the installation, possibly answering additional +questions in the process. + +.NH +System Checkout +.PP +The basic IRAF system should be usable once the files have been restored to +disk, the binaries have been configured or generated, and the install script +has been run. To verify that the basic system comes up and runs successfully, +login as \f(CWiraf\fP and startup the CL +(command language) from the iraf account. +.PP +Before starting up IRAF from the iraf account, following the installation of +a new system, it will be necessary to execute the \f(CWmkiraf\fP task. +This will (optionally) initialize the \f(CWuparm\fP directory for the iraf +account, and create a new \f(CWlogin.cl\fP file. +.DS +.ps -2 +\f(CW% mkiraf +Initialize uparm? (y|n): +Terminal types: gterm=ttysw+graphics,vt640=(vt100+retrographics),etc. +Enter terminal type: vt640 +A new LOGIN.CL file has been created in the current directory. +You may wish to review and edit this file to change the defaults. +.DE +.LP +The default terminal type option (\f(CWvt640\fP in the example) is very +site dependent and you will probably want to enter a different value +from that shown. Look in the file \f(CW$iraf/dev/termcap\fP to see what +terminals are supported. Instructions for interfacing new terminals are +given in the \fISite Manager's Guide\fP. The \f(CWstty\fP task may be +used to display or change the terminal type after logging into the CL. +A graphics terminal must be specified to be able to run IRAF tasks which +use interactive graphics. +.LP +Once \f(CWmkiraf\fP has been run to initialize the IRAF environment +the CL may be started, e.g.: +.DS +\f(CW% cl # \fRstartup IRAF\fP +.DE +.LP +This should startup the CL, which will clear the screen and print out a +startup message. The standard test procedure included in Volume 1A of the +\fIIRAF User Handbook\fP should be run to verify the installation. + +.bp +.SH +Appendix A. A Complete Example +.PP +Here we present a complete sample IRAF installation for a VAX running Berkeley +UNIX. This is the simplest possible installation, i.e. it is a new +installation, the BIN directories are located under the IRAF root, +and the archives are read sequentially off a 9 track distribution tape. +.PP +The first step is for the superuser to create an account for the fictitious +user `\f(CWiraf\fP', with home directory \f(CW/usr/iraf/local\fP and shell +\f(CW/bin/csh\fP. The directory \f(CW/usr/iraf\fP should exist, but that +is all that is needed. We then login as iraf (a warning message will be printed +since there is no login directory) and proceed as follows: +.sp +.RS +.nf +.ps -1 +.vs 8 +\f(CW% setenv iraf /usr/iraf/ +% cd $iraf +% +% whoami +iraf +% +% mt -f /dev/nrmt8 rew +% cat /dev/nrmt8 + +0 Table of Contents +1 AS.VBSD.GEN 44.9Mb IRAF, NOAO packages and VAX/BSD sources +2 IB.VBSD.VAX 9.9Mb IRAF system binaries for VAX/BSD +3 NB.VBSD.VAX 12.3Mb NOAO packages binaries for VAX/BSD + +% +% tar -xpf /dev/nrmt8 # unpack AS.VBSD.GEN +% +% rm bin.vax # remove old symbolic link +% mkdir bin.vax # create actual directory +% cd bin.vax +% mt -f /dev/nrmt8 fsf +% tar -xpf /dev/nrmt8 # unpack IB.VBSD.VAX +% +% cd $iraf/noao +% rm bin.vax # remove old symbolic link +% mkdir bin.vax # create actual directory +% cd bin.vax +% mt -f /dev/nrmt8 fsf +% tar -xpf /dev/nrmt8 # unpack NB.VBSD.VAX +% +% cd $iraf/unix/hlib # run the INSTALL script +% source irafuser.csh # pick up environment defs for install +% ./install -n +% su +# ./install +# exit +% +% cd; pwd +/usr/iraf/local +% source .login # read .login now that we have one +% rehash # pick up new iraf commands +% mkiraf # initialize iraf environment +% +% cl # verify that the CL runs\fP +.ps +.vs +.ke +.RE diff --git a/doc/bugs.v25 b/doc/bugs.v25 new file mode 100644 index 00000000..38045227 --- /dev/null +++ b/doc/bugs.v25 @@ -0,0 +1,1471 @@ +# BUGS.V25 -- Known bugs in the frozen IRAF Version 2.5. (start 7 July 1987) +# +# Record Format: +# +# NUMBER: record number, decimal, sequential. +# MODULE: package.task or library.procedure or 'unknown' or ... +# SYSTEM: versions of iraf in which bug was present +# DATE: date bug logged, unix format date string +# FROM: user login name +# BUG: description of the bug +# STATUS: 'fixed in V2.X', 'unresolved', etc. +# +# New records are added to the tail of the bugfile. Left justify field labels, +# indent text to the first tab stop, one blank line between bug entries. +# ---------------------------------------------------------------------------- + +NUMBER: 1 +MODULE: images.imheader +SYSTEM: V2.5, V2.4, V2.3 +DATE: Wed Jul 8 21:10:54 MST 1987 +FROM: tody + +BUG: When listing the header of an image where the pixel file has been + created in the same directory as the header file using the imdir=HDR$ + syntax, the pixel file status is always given as [NO PIXEL FILE] + regardless of whether or not the pixel file exists. This is of course + due to the HDR$, which is a special syntax significant only to IMIO + and which does not correspond to an actual FIO logical directory. + +STATUS: This has been known about for some time, but is not serious and was + overlooked in preparing V2.5. The workaround for the moment is to + simply list the directory containing the image header file. If there + is a pixel file (extension .pix, same root name as the header file) + it will appear in the directory listing. + +NUMBER: 2 +MODULE: system.deallocate +SYSTEM: V2.5 Ultrix/IRAF +DATE: Fri Jul 10 13:21:01 MST 1987 +FROM: rooke + +BUG: In Ultrix/IRAF, if a TK50 tape cartridge on a MicroVAX is physically + removed from the tape drive before executing DEALLOCATE, and one + subsequently attempts to execute DEALLOCATE, either from the same or + another process, that process hangs and has to be killed from outside. +STATUS: To be investigated when time permits. + +NUMBER: 3 +MODULE: cl +SYSTEM: V2.5 +DATE: Fri Jul 31 14:53:14 MST 1987 +FROM: tody + +BUG: This bug affects CL SCRIPTS which access the CL global parameters + i,j,k, x,y,z, etc. The bug is more likely to occur the shorter the + parameter name. The bug occurs when the CL searches for a parameter + specified using the simple form of the parmeter name "param" rather + than "task.param". When a parameter name is specified in this way, + and the named parameter is not defined locally to the task being + executed, then the CL must search all pfiles in the search path for + the named parameter. + + The problem would occur when the parameter name given was an + abbreviation for one or more of the local parameters of the task. + If the parameter name was an ambiguous abbreviation the task would + abort with the misleading error + + ERROR: task `' has no param file + + If the parameter name given was an unambiguous abbreviation then + the LOCAL parameter would be referenced rather than the global CL + parameter, which is probably not what was intended. + + For example, if the task had a local parameter "xmin", the assignment + statement "x = 1" would assign 1 to "xmin". If the task had a second + local parameter "xmax", the same assignment statement would result in + the above error message. + +STATUS: The bug has been fixed in V2.6. The workaround for older versions of + the CL is to define all local variables locally (this is more sensible + and more efficient in any case), and always spell out parameter names + fully. When referencing a parameter belonging to another task, use the + unambiguous form of the parameter name, i.e., "task.param". + +NUMBER: 4 +MODULE: onedspec - combine, dispcor, rebin +SYSTEM: V2.2 - V2.5 +DATE: Wed Aug 5 15:11:39 MST 1987 +FROM: valdes + +BUG: The specific bug leading to the change was when combining three + spectra with identical wavelength scales but with some spectra + having zero values to indicate missing data the zero value data + was not ignored in the average as intended. This occured because + of two factors. First, COMBINE always rebins the data even if + all the wavelength scales are the same. In this process the + output grid was very slightly different from the input grid + due to truncation errors. This allowed the interpolation to + pull the point with zero value next to a valid nonzero value + pixel slightly away from zero. When combining only points + which are exactly zero are ignored. Thus, the combined + point with input values of 9, 9, and 0 had rebinned values of + 9, 9, and 0.0001 and an averaged value of 6 instead of 9. + +STATUS: The fundamental problem is failure to properly propagate the + missing data value during rebinning. This problem should be + thought out careful in a revision of the ONEDSPEC package. The + immediate fix made was to 1) ignore the interpolation + if the output rebinning grid is close to the input grid (within + 0.001 pixels) and 2) to set any interpolated point which uses + a missing data point (0 value) to 0. These changes mainly are + for COMBINE but it also affects DISPCOR and REBIN which use the + same rebinning routine. This problem probably occurs very + infrequently but those without this fix should be aware of this + effect. + +NUMBER: 5 +MODULE: onedspec.splot +SYSTEM: V2.5, V2.4, V2.3, V2.2 +DATE: Thu Aug 6 17:14:25 MST 1987 +FROM: valdes + +BUG: In function mode when applying a second spectrum, for example + adding a second spectrum, which doesn't exist there is no error + message and the plot is redrawn as if the operation had been performed. + +STATUS: This has been fixed to report the error and not redraw the plot. + For systems without this fix the only remedy is to be alert and note + whether the operation has changed the original spectrum. + +NUMBER: 6 +MODULE: dataio.reblock +SYSTEM: V2.5 +DATE: Wed Aug 12 13:52:09 MST 1987 +FROM: davis + +BUG: The reblock task was not adding the offset parameter to the physical + tape number before creating the output file name. + +STATUS: The problem was that the reblock task was not querying for the offset + parameter which was by default being set to zero. This bug has been + fixed and the help page updated. + +NUMBER: 7 +MODULE: CL +SYSTEM: V2.5 +DATE: Mon Aug 17 09:01:23 MST 1987 +FROM: valdes + +BUG: Foreign tasks are supposed to participate in I/O redirections just + like regular IRAF tasks. However, appending the output of a foreign + task to a file (i.e. >>file) does not append but instead overwrites + the file without any warning or error message. + +STATUS: [placed on TODO list (DCT)]. + +NUMBER: 8 +MODULE: CL, noao.imred.generic.darksub +SYSTEM: V2.5 +DATE: Thu Aug 20 11:05:33 MST 1987 +FROM: valdes + +BUG: Tasks which write values to their parameter files do not do so when + run in the background. This means that scripts which rely on this + feature will fail, or worse yet, give incorrect results! The + incorrect results occur because the value in the parameter file + is not that put by the task when run in the background script but + that put the last time the script or task ran in the foreground. + This problem arises in the task imred.generic.darksub which uses + the task images.imgets to get a image header parameter for the + exposure time of the dark count image. + THE TASK DARKSUB WILL POSSIBLY GIVE INCORRECT RESULTS IF RUN IN THE + BACKGROUND! + +STATUS: This property of background jobs in the CL has not been dealt with yet. + [The solution is not so simple as merely updating the pfile as if the + task were run in the foreground, as this could cause subtle runtime + context dependent errors in concurrent jobs which attempt to access + the same pfile (DCT)]. Scripts which use images.imgets to get header + parameters and images.sections to get the number of files or images + in a template will work only in the foreground. The DARKSUB task has + been rewritten in V2.6 to avoid this problem; a bugfix is available + for the V2.5 release via the IRAF Hotline, if desired. + +NUMBER: 9 +MODULE: register, geotran +SYSTEM: V2.5 +DATE: Thu Sep 3 10:08:24 MST 1987 +FROM: davis + +BUG: The register and geotran tasks can sometimes produce output images + which have the correct geometric transformation but fluxes which + are the negative of the original image. Two conditions are necessary + to produce this result: 1) the transformation is of a higher order + than a simple translation, rotation, magnification and axis flip and + 2) one of the axes has been flipped. The flux correction is computed + by calculating the Jacobian of the coordinate transformation. When + an axis flip occurs this coordinate surface turns upside down + producing a negative Jacobian. + +STATUS: The appropriate absolute value statements have been added to the code. + A temporary solution to the problem is to multiply the output image + by -1 as the absolute values of the output fluxes are correct. + +NUMBER: 10 +MODULE: longslit.extinction +SYSTEM: V2.5 +DATE: Mon Sep 14 09:49:56 MST 1987 +FROM: valdes + +BUG: Due to an oversight and infrequent use of this task, debugging output + consisting of a list of numbers relating to the extinction function + was not removed and appears when users run this task. + +STATUS: The debugging statement has been removed. As a workaround users + may discard all output (since this task does not produce any normal + output to the terminal) as follows: + + cl> extinction images >& dev$null + + The output is on the standard error stream (STDERR) so the '&' + is required. + +NUMBER: 11 +MODULE: apextract.apnormalize +SYSTEM: V2.5 +DATE: Tue Sep 22 16:51:19 MST 1987 +FROM: valdes + +BUG: For reasons of memory managment the task APNORMALIZE breaks + up its work into groups of apertures. The number of apertures + is a defined constant in the source and is set to 20. The + bug occurs when there are more than this number of apertures. + The task first sets all output pixels to unity and then fills in + the normalized apertures. This makes all points outside the + apertures have a value of 1. The bug arises because it does + this for each set of apertures rather than only once. The + effect is then to output an image with only the last set + of apertures. For example with 28 apertures only the last + eight will have the normalized aperture data. + +STATUS: The reported bug is now fixed by only setting the points + outside the apertures to 1 once. The work around is to do the + the normalization in groups of 20 (there are no problems if + there are 20 or less apertures). The resulting flat field + images may then be multiplied together (since the missing + apertures are set to 1) or applied to the data to be flattened + successively. If this is a serious problem contact us for a + bug fix. + +NUMBER: 12 +MODULE: apextract.apnormalize +SYSTEM: V2.5 +DATE: Tue Sep 22 16:53:05 MST 1987 +FROM: valdes + +BUG: APNORMALIZE does not work when DISPAXIS=1. Since it is rare to + have this orientation the task was never tested with this dispersion + axis. + +STATUS: It has been fixed. The work around is to transpose the flat + field data, normalize, and transpose the normalized flat field. + You must also change or set DISPAXIS whenever you transpose an + image. + +NUMBER: 13 +MODULE: ki_gnode +SYSTEM: V2.5, V2.3 +DATE: Wed Sep 30 16:55:27 MST 1987 +FROM: rooke + +BUG: In the Kernel Interface, code in ki_gnode() checks to see if + a requested node is the same as the local node. However, it + does so by comparing the first n chars of the requested node + against those of the local node (strncmp()). If both nodes + have the same first n chars, but differ beyond that, ki_gnode + thinks it is on the local node. (UCSD, nodes "cass05" and "cass"). + +STATUS: The workaround is to simply use a different node name (alias) until + the bug is fixed. + +NUMBER: 14 +MODULE: sgi2vqms +SYSTEM: V2.5 +DATE: Mon Oct 12 14:01:11 MST 1987 +FROM: sjacoby + +BUG: Line 230 of the source file $iraf/vms/gdev/sgidev/sgi2vqms.f is + missing the character 'x'. As a result, the x coordinate of an + SGI_MOVE instruction is not being output. This character must + have been accidentally deleted by someone browsing through the file. + Any VMS site with a QMS will be affected; all such sites will recompile + the executable because we don't supply it on our distribution tapes. + A second bug in the translator, reported earlier today by Zoltan Levay, + is also being investigated. He reports the Y window limits supplied by + dev$graphcap are not being used in the translator. + +STATUS: The workaround for the first problem is to add the missing character + to line 230 and recompile. The second problem is still under + investigation. The best solution is to obtain the latest version of + this source file from us before setting up the SGI/QMS interface. + +NUMBER: 15 +MODULE: onedspec: dispcor, combine, rebin +SYSTEM: V2.5 +DATE: Fri Oct 16 16:54:28 MST 1987 +FROM: valdes + +BUG: The reported bug was that applying DISPCOR to spectra which ran + from red to blue using SPLINE3 interpolation produced a spectrum + of all zeros. Further investigation showed that anything which + which rebinned spectra with the wavlength sense reversed using + either the SUMS or SPLINE3 interpolation mode had the same + effect. This includes DISPCOR, REBIN, and COMBINE. An additional + bug was that SPLINE3 interpolation was mapped into SUMS mode + so that SPLINE3 interpolation was never possible. + + There were two errors involved: + 1. SPLINE3 interpolation mode was mapped into SUMS mode. + 2. SUMS mode only worked when the rebinning was in the same + wavelength sense as the data. Otherwise an all zero + spectrum was produced. + +STATUS: These bugs have been fixed on V2.6. This code badly needs to be + rewritten. + + 1. The work around is to rebin or dispersion correct in the + same sense as the data and later flip the spectrum if needed. + Note that DISPCOR defaults to wavelength increasing when the + original spectra has wavelength decreasing with pixel. In this + case the user must explicitly reverse the default starting + wavelength and change the sign of the wavelength per pixel. + Automatic mode will fail since it uses the defaults. + 2. Users using SPLINE3 interpolation must be aware that actually + SUMS mode interpolation is used. Some users may be unaware + of this since the data is still correct. + +NUMBER: 16 +MODULE: onedspec.splot +SYSTEM: V2.5 +DATE: Thu Oct 22 19:03:00 MST 1987 +FROM: valdes + +BUG: Deblending in SPLOT is unstable when the data is in FNU and + FLAMBDA units. In fact, a user demonstrated that it crashes + almost every time on VMS with either divide by zero or floating + overflows. It was also found that the 'e' key was not returning + a center. The results of deblending are not consistent and depend + on the prior deblending history; it is recommended in the + documenation that one start by fitting an isolated line to get + a first guess at the width of the lines. + +STATUS: These problems are due to the very small numbers when spectra are + in FLAMBDA (~10E-14) and FNU (~10E-27). In this regime it is very + important to be careful with powers and operations which may + underflow. + + A workaround in V2.5 is to multiply the spectrum either externally or + with the SPLOT arithmetic function to values near unity. + + These bugs were fixed in the development V2.6. The input to + the complex, imported Fortran math routine used for the + deblending is now first scaled to a maximum value of 1. For + the 'e' equivalent width the same scaling is done when + computing the sum of values to the 1.5 power for determining + the centroid of the marked region. I also made the deblending + more consistent by iterating the fit three times; it is no + longer necessary to fit an unblended line first. This can be + done manually by the user as a workaround in V2.5 to achieve + the same result. + + The long term solution requires more careful consideration of + intensity units in all the ONEDSPEC tasks (such as by keeping a + scale factor in the header and leaving the pixel values near + unity) plus a more careful study of deblending routines (the + current one is considered a prototype). + +NUMBER: 17 +MODULE: images.imsurfit +SYSTEM: V2.5 +DATE: Mon Nov 2 13:48:52 MST 1987 +FROM: davis + +BUG: A bug exists in the regions fitting code of the task IMSURFIT. + If the user sets the regions parameter to "sections" and specifies + sections which overlap the program will crash with a segmentation + violation. The modified ranges package used by IMSURFIT was not + handling the overlap condition correctly and sometimes computed + a number of points to be added to the fit that was incorrect. + +STATUS: This bug has been fixed in Version 2.6. Version 2.5 users should be + careful when specifying the regions to be fit that the columns and + rows do not overlap. + +NUMBER: 18 +MODULE: longslit.fluxcalib +SYSTEM: V2.5 & V2.3 +DATE: Thu Nov 5 18:16:27 MST 1987 +FROM: valdes + +BUG: FLUXCALIB behaves incorrectly when the input and output images + are the same; i.e. in place correction. A error message about + a bad file descriptor is given and the task aborts. However, + the image has been correctly calibrated! Multiple images are + not done because the error terminates the task after the first + image is calibrated. + +STATUS: The error occurs when an attempt is made to close the nonexistent + second image though the input image has been corrected in place. + This error is not trapped and terminates the task. For one image + at a time simply ignore the error. For multiple images you + must either do them one at a time or generate new output images. + It is a little surprising that this bug has never been reported + since it has been present since the task was written two years ago. + I apparently never tested this feature myself. People must rarely + flux calibrate 2D images and when they do they are cautious and + create new calibrated images. This bug has been fixed in V2.6. + +NUMBER: 19 +MODULE: astutil.galactic +SYSTEM: V2.5 & V2.3 +DATE: Fri Nov 6 16:15:13 MST 1987 +FROM: valdes + +BUG: The task GALACTIC prints incorrect galactic coordinates on + SUN/IRAF (probably also AOS/IRAF). + +STATUS: The galactic coordinates are computed in double precision. The + bug occurs because it is printed assuming it is single + precision; PARGR instead of PARGD. This does not affect the + answers on VAXs but it does on the SUNs and others with the + same byte order. There is no work around but the code fix is + trivial for those able to edit and recompile the procedure. + Contact us for details. + +NUMBER: 20 +MODULE: dataio$rfits +SYSTEM: V2.5 +DATE: Sun Nov 8 12:25:30 MST 1987 +FROM: davis + +BUG: A serious bug in the way that rfits handles negative declinations + was found by the MIT site when trying to read their CTIO tapes. + Decs of the form -20:35:46 were being transformed to -20:05:06. + The reason for this problem is historical. First it should be + noted that NOAO does not follow the FITS standard in encoding + RAs and DECs on the mountain. These number should technically + be encoded as floating point numbers but for obvious reasons + astronomers are not enthousiastic about seeing dec = -23.6281 + etc. The way IRAF distinguishes between legal and NOAO decs + is to search for the presence of the colon character. In + addition at some time not far back the mountain was producing + things like dec= -20: 3:5 and even -20:-3:-5. which other + iraf programs were not able to interpret or modify. RFITS + tried to clean up these old formats. Apparently NOAO mountain + formats have been fixed and IRAF RFITS did not handle the fix + correctly. + +STATUS: The problem has been fixed in version 2.6. There is no work + around at present. Users should compare the output of rfits + with the make_image parameter turned off to the results of + actually reading in the data. The results in the header listing + which do not alter the data should be correct. If this problem + seriously affects their data reduction then contact the IRAF + group on how to get the fix installed. + +NUMBER: 21 +MODULE: apextract.apsum, apextract.apstrip +SYSTEM: V2.5 +DATE: Mon Nov 9 08:55:17 MST 1987 +FROM: valdes + +BUG: The variance weighted extraction assumes variances of the + form + + V = V0 + V1 * (S + B) + + where S are the counts due to the spectrum and B are the counts of + the background. For very weak spectra with negligible background + (such as when the detector sensitivity is very low) it is possible + that the variance approaches zero or becomes negative; especially + if the zero level variance or readout noise is small or zero such + as in photon counting detectors. Since the weights are the + inverse of the variance this may result in spikes in the extracted + spectrum. + +STATUS: There is no workaround other than to ignore the extracted data + that is nearly nonexistant. The fix is to replace the variance + formula by a suitable positive definite quantity. My solution + is: + + 1. If V0 is 0 (such as with photon counting detectors) + + V = V1 * max (1, S + B)) + + 2. If V0 is not 0 + + V = V0 + V1 * max (0, S + B) + + where max is the maximum function. Thus, if V0=0 then the + minimum variance is V1 and otherwise the minimum variance is + V0. Case 2 makes no assumptions about the data while case 1 + assumes that the spectra is actually in counts and has not been + normalized in such a way as to have significant intensity + values less than 1. If you wish to change the source code and + recompile contact us for details. + +NUMBER: 22 +MODULE: apextract.apsum +SYSTEM: V2.5 +DATE: Mon Nov 9 17:15:18 MST 1987 +FROM: valdes + +BUG: When running APSUM the incorrect error message "apio package not found" + is printed when the dispersion axis has not been set. Continuing with + a list of images causes other problems. + +STATUS: This bug is the result of not having the dispersion axis set. Since + the message is incorrect one must be aware that this message means + you have forgotten to run SETDISP to set the dispersion axis. + The source of this bug is that the task is failing to take appropriate + action when it finds the dispersion axis parameter is missing + and actually triggers another more fatal error. This screws up the + error reporting and causes further errors when processing a list of + images. This has been fixed so that the error is caught and the task + gracefully reports the correct error. + +NUMBER: 23 +MODULE: imdelete +SYSTEM: V2.5 +DATE: Fri Nov 13 08:59:58 MST 1987 +FROM: davis + +BUG: The imdelete task crashes the CL on Lyra in the following situtation: + a set of images out10a.imh, out10b.imh, ... exists on disk + an erroneous image template of the form out10[a-g].imh is + given to the imdelete task and the verify switch is set to yes. + +STATUS: This bug was traced to the VOS routine imio.imaccess which is called + to see if the named image exists before attempting to delete it. + The workaround is to avoid the use of the erroneous image template + when calling tasks such as IMDELETE. Like all tasks which process + a list of images, IMDELETE uses the image template facilities to + specify the list of images to be deleted. Character classes such as + [a-g] are not supported in image templates since the [] are reserved + for image sections. The syntax "out10![a-g]" is a valid way to + specify a character class in an image template. (dct) + +NUMBER: 24 +MODULE: imlintran +SYSTEM: V2.5 +DATE: Wed Nov 25 11:18:33 MST 1987 +FROM: davis + +BUG: A bug was found in the boundary extension = wrap option of the + IMLINTRAN task. The task was computing very large pixels values + for the output image which then caused subsequent tasks such + as imstat to fail. Out of bounds pixel values in the range + 0.0 < x < 1.0, ncols < x < ncols + 1.0, 0.0 < y < 1.0 and + nlines < y < nlines + 1.0 were falling off the ends of the + interpolation array producing erroneous output values. + +STATUS: The problem has been fixed for version 2.6. For the time being + users should avoid the boundary = wrap extension. Note + that the tasks ROTATE, REGISTER and GEOTRAN are also affected + by this bug as they all use the same code. + +NUMBER: 25 +MODULE: rfits +SYSTEM: V2.5 +DATE: Fri Dec 11 09:13:31 MST 1987 +FROM: davis + +BUG: A bug was found in the rfits disk file list handling code. If the + user successfully read a single disk file, for example fitsdat, + and then tried to execute rfits with a file name template which + did not match any disk files the program would try to reread + fitsdat. + +STATUS: The problem arose because the program was not checking correctly + for a zero length file list in the case of disk files. The bug + has been fixed in Version 2.6. + +NUMBER: 26 +MODULE: mtlocal.rcamera +SYSTEM: V2.5 +DATE: Thu Dec 17 15:28:41 MST 1987 +FROM: davis + +BUG: Rcamera was giving bus errors when run on our Sun 4 machine. The + problem was traced the routine bitpak being called with a short + integer argument when it was expecting an integer argument. + +STATUS: The bug has been fixed and the Lyra version has been updated. + +NUMBER: 27 +MODULE: dataio.t2d +SYSTEM: V2.5 +DATE: Thu Dec 17 16:14:00 MST 1987 +FROM: lytle + +BUG: T2D has a bug in the code for interpreting the input file name. + If the user enters an input name of the form `mta[7]' the program + would die with a `segmentation violation' message. + +STATUS: This has ben corrected in V2.6. The workaround is never to use + this form of input filename, the user can just enter `mta' for + the input name and then enter `7' when asked for the list of files. + +NUMBER: 28 +MODULE: all iraf tasks (networking bug) +SYSTEM: V2.5 UNIX/IRAF, V2.5-V2.6 Sun/IRAF and Ultrix/IRAF +DATE: Sat Dec 19 15:59:03 MST 1987 +FROM: tody + +BUG: A bug in the network driver for UNIX/IRAF was causing a host file + descriptor to be opened on every call but never used nor closed. + This could eventually cause the client process to run out of file + descriptors. + +STATUS: The bug is harmless unless the process runs out of file descriptors. + This is unlikely since once a server node is connected to a process + it tends to stay connected for the lifetime of the process, and a + client process is unlikely to connect to very many server nodes. + Nonetheless we found one case where the bug was serious. On our + diskless Sun nodes, images were being read from tape to disk on the + server node and then accessed from a diskless client node. The user + did not have a .irafhosts file, hence every image access would result + in a failed attempt to connect to the remote node, consuming a file + descriptor in each attempt. The workaround is to minimize network + connections, e.g., by using a valid .irafhosts file, or by reading + the images to disk on the client node. + + The bug is fixed in V2.6 UNIX/IRAF. In addition, the network driver + and default host login file dev$hostlogin were modified to make it + unnecessary for the user to have a .irafhosts file. + +NUMBER: 29 +MODULE: all image tasks involving image rename or in-place image operations +SYSTEM: V2.5 +DATE: Sat Dec 19 17:39:27 MST 1987 +FROM: tody + +BUG: The imio.imrename image renaming operator was not working properly + for OIF format images (the default) when renaming an image to a new + directory and the imdir=HDR$ option is in effect (pixel file stored + in header file directory or subdirectory). This would affect not only + obvious image rename operations such as the IMRENAME task, but also + most in-place image operations when run on an image not in the current + directory while imdir=HDR$ is in effect, since such in-place operations + are implemented by creating a temporary output image in the current + directory and then renaming it to replace the old image upon successful + completion of the operation. + +STATUS: The workaround is to avoid in-place operations on images not in the + current directory, and avoid using IMRENAME to move OIF format images + to a new directory. An installable bug fix is available from IRAF + site support if desired (update file imio$iki/oif/oifrename.x). + +NUMBER: 30 +MODULE: imfort.imps3r +SYSTEM: V2.5 +DATE: Sun Dec 20 11:57:39 MST 1987 +FROM: tody + +BUG: This IMFORT routine will appear to work but does not output the data + properly. The line pointer into the input buffer was being incremented + in the K loop (outer loop over Z) rather than the J loop (inner loop + over Y), causing each input line to be replicated to fill each output + band. + +STATUS: Fixed in V2.6. Do not use this routine to output a section for which + J2-J1 > 1 (Y-size of section greater than one line) or it will fail. + The best workaround is to avoid use of the routine entirely. None of + the other routines, e.g, imps3s, imgs3r, etc., contain the bug (all + were checked). + +NUMBER: 31 +MODULE: KI (iraf networking) +SYSTEM: V2.5 +DATE: Mon Dec 21 22:52:02 MST 1987 +FROM: tody + +BUG: If 20 or more nodes are entered in to the network table dev$hosts, + and iraf networking is enabled (the table contains an alias matching + the name of the local node), the network tables are corrupted during + process startup, and no IRAF process can be started, preventing even + logging into the CL! + +STATUS: As far as I know, NOAO is the first site to enounter this bug, since + [1] few sites use the iraf networking facilties presently, and [2] few + sites have more than 20 nodes in the local network. Sites with V2.5 + which wish to use the IRAF networking facilities should not place the + names of more than 19 nodes in the dev$hosts file. The bugs are fixed + in V2.6, and the default size of the network tables are increased to + a maximum of 64 nodes. + +NUMBER: 32 +MODULE: mtlocal.widstape +SYSTEM: V2.5 +DATE: Tue Dec 22 14:47:43 MST 1987 +FROM: sjacoby + +BUG: Task widstape (in the x_onedutil.e executable but mtlocal package) + writes incorrect data values to the output file on non byte swapped + machines such as a Sun. The pixel array is passed to procedure + dtoc3 as type real, where dtoc3 expects a double precision input + argument. + +STATUS: This has been fixed in version 2.6. There is no workaround; + contact us for the bug fix. + +NUMBER: 33 +MODULE: mtlocal.ridsout +SYSTEM: V2.5 +DATE: Tue Dec 29 10:45:59 MST 1987 +FROM: sjacoby + +BUG: These two bugs exist in V2.5 of task ridsout: [1] The values of + airmass, starting lambda and delta lambda are written to stdout + during the execution of ridsout as single precision reals, not + double precision. [2] Negative pixels and the pixel that follows + them are not read correctly, as ridsout requires whitespace + separated fields, and the minus sign causes the fixed field width + to be completely filled. + +STATUS: Both bugs have been repaired in V2.6. The workaround for [1] is + simply to ignore those three printed values when running ridsout. + The discrepancy is noticed only on non byte swapped machines, and + the values are written to the image header correctly. Use slist + or imhead to verify this. No workaround exists for [2]. Negative + pixels should be rare; contact us if you require the fix. + +NUMBER: 34 +MODULE: images.fit1d, generic.background, longslit.background +SYSTEM: V2.5 +DATE: Mon Jan 4 10:26:01 MST 1988 +FROM: valdes + +BUG: When a nonexistent input images is specified (usually the result of + a typo in the input specification) the task hangs up instead of + reporting a warning about failure to find the requested image. +STATUS: This bug is caused by a missing error check on the procedure which + opens the images, which means the task continues as if the + image was successfully opened and leads to reported behavior. The + source code fix is to add an ERRCHK declaration. The work + around is to kill the task and fix the input image specification. + +NUMBER: 35 +MODULE: apextract.apsum +SYSTEM: V2.5 +DATE: Tue Jan 5 11:05:52 MST 1988 +FROM: valdes + +BUG: 1. When extracting apertures which go off the edge using PROFILE + WEIGHTING the part of the extracted spectrum off the edge is garbage + rather than set to zero as intended. + 2. When extracting apertures which go off the edge using PROFILE + WEIGHTING and BACKGROUND SUBTRACTION the task may crash if the + background regions also go entirely off the edge. + +STATUS: 1. This is only an esthetic problem which has now been fixed to set the + extracted spectrum to zero when it is off the image. Just ignore the + meaningless part of the extracted spectrum. + 2. There is no direct work-around for this problem other than to avoid + extracting spectra WITH BACKGROUND SUBTRACTION where the + background regions also go entirely off the edge. One + possiblity is to extract a background region as a separate + aperture and then subtract it later with IMARITH. The code fix + is simple; contact us if you really need this capability. + +NUMBER: 36 +MODULE: all tasks using floating point +SYSTEM: V2.5 Sun/IRAF +DATE: Tue Feb 2 14:59:30 MST 1988 +FROM: tody + +BUG: In V2.5 Sun/IRAF the default configuration of the IEEE hardware + floating point unit is used. A floating divide by zero, floating + overflow, etc., does NOT produce an exception, but instead produces + one of the special numbers NaN or Inf (not a number or infinity), + which do not behave like ordinary floating point numbers, and which + IRAF does not know how to deal with. In particular, if one attempts + to print the value of such a number, an infinite loop results. This + can occur when attempting to write an image to tape with WFITS, when + attempting to update the min and max pixel values in an image, and + in many other places where formatted output occurs. An easy way to + test if your system has this bug is to enter the following command: + + cl> = 1.0 / 0.0 + + If this hangs in a loop, the bug is present in your system and tasks + may hang if they encounter data containing NaN or Inf values. + +STATUS: Fixed in V2.6 Sun/IRAF (by enabling the divide by zero and other + exceptions in the hardware floating point unit). If an image is + somehow generated which contains NaN or Inf pixels, it may be possible + to use the REPLACE task to fix up the bad pixel values. Alternatively, + the data must be reprocessed in such a way that the bad pixels are not + generated, e.g., in a way which does not lead to a divide by zero. + +NUMBER: 37 +MODULE: proto.toonedspec +SYSTEM: V2.5 +DATE: Fri Feb 12 17:03:09 MST 1988 +FROM: valdes + +BUG: When extracting spectra with no summing (i.e. one line or column at + a time) and when the last extracted line or column from one image is + the same and that of the first line or column of the next image + garbage results are obtained. The specific example was extracting + the first line from a set of 2D spectra. + +STATUS: The bug only occurs under the conditions described above. The source + of the bug is that if the line or column is unchange from one call to + the next the task believed that the data it used the previous time + was still valid even though the data pointer had been freed and + and reallocated for the new image. This bug has been fixed as of + this date. The workaround is to flush the process between each image + or extract more than one line. For example if lines 1 and 2 are + extracted from image1 and image2 then the output sequence will be + image1.0001, image1.0002, image2.0001, image2.0002 and the line for + each extraction always differs from the previous extraction. + +NUMBER: 38 +MODULE: identify +SYSTEM: V2.5 +DATE: Thu Feb 18 15:46:47 MST 1988 +FROM: valdes + +BUG: The 't' key fails on the SUNs. + +STATUS: This bug has been present since IDENTIFY was converted to double + precision. This little used key was passing the cursor position + to a procedure as a real value when the procedure was expecting + a double value. This bug is benign on the VAXes but is, presumably, + also present on the MVs. There is no workaround though the code + fix is simple. + +NUMBER: 39 +MODULE: images.imsurfit +SYSTEM: V2.5 +DATE: Mon Feb 29 10:19:04 MST 1988 +FROM: davis + +BUG: If the regions parameter has been set to any of "columns", "circle" + "border" or "sections" and the type type_output parameter is "residual" + "response", imsurfit may produce an erroneous output image. + The the imio input buffer was being altered if the + regions parameter was set to anything other than all or rows, + and was not being flushed when the input image was reread. + The problem would only occur for small images and depends on + the relationship between the size of the fileio buffers and + the image size and has been present since the task was + written. + +STATUS: The bug has been fixed in version 2.6. The workaround is to always + compute the fit if the regions parameter is set to anything + but all or rows and use imarith to compute the residual, or + response images. + +NUMBER: 40 +MODULE: dtoi.hdtoi +SYSTEM: V2.5, Sun/IRAF V2.6 +DATE: Thu Mar 10 14:21:32 MST 1988 +FROM: sjacoby + +BUG: An error exists in the equations used to generate the look up table + used in task hdtoi for the 'k75' and 'k50' transformations. + + Incorrect: + ind_var[i] = density[i] * .50 * log10(1. - 10. ** (-density[i])) + ind_var[i] = density[i] * .75 * log10(1. - 10. ** (-density[i])) + + Correct: + ind_var[i] = density[i] + .50 * log10(1. - 10. ** (-density[i])) + ind_var[i] = density[i] + .75 * log10(1. - 10. ** (-density[i])) + +STATUS: The fix is to edit file hdtoi.x and replace the incorrect equations + (lines 319 and 323). Then type 'mkpkg update'. These transformation + types are accurately calculated in task hdfit; only task hdtoi shows + the error. + +NUMBER: 41 +MODULE: longslit.extinction +SYSTEM: V2.5 & V2.3 +DATE: Thu Mar 24 09:06:53 MST 1988 +FROM: valdes + +BUG: EXTINCTION behaves incorrectly when the input and output images + are the same; i.e. in place correction. A error message about + a bad file descriptor is given and the task aborts. However, + the image has been correctly calibrated! Multiple images are + not done because the error terminates the task after the first + image is calibrated. + +STATUS: The error occurs when an attempt is made to close the nonexistent + second image though the input image has been corrected in place. + This error is not trapped and terminates the task. For one image + at a time simply ignore the error. For multiple images you + must either do them one at a time or generate new output images. + It is a little surprising that this bug has never been reported + since it has been present since the task was written three years + ago. This bug has been fixed in V2.6. See also Bug #18. + +NUMBER: 42 +MODULE: geotran +SYSTEM: V2.5 +DATE: Thu May 5 11:43:33 MST 1988 +FROM: davis + +BUG: A bug was found in the coordinate subsampling code in geotran. If + xsample or ysample were greater than 1 and the output image was + greater than nxblock and nyblock then the program would quit with + an access violation. The problem was that in the code revision + the calling sequence of the subroutine had been changed but the + arguments to the call had not. I also found and fixed another + bug in the coordinate subsampling code that had not so far been + reported. + +STATUS: The bug has been fixed. The workaround is to leave xsample and + ysample = 1 and live with the increase in execution time for + high order distortion corrections. + +NUMBER: 43 +MODULE: CL +SYSTEM: V2.5, V2.6 Sun/IRAF +DATE: Mon May 16 13:58:08 MST 1988 +FROM: tody + +BUG: If one submits a background job from the CL running in a terminal + window under SunView, and then selects "Exit Suntools" in the root + menu with the foreground CL still running, the background CL job is + killed. + +STATUS: The workaround is to logout of the foreground CL before exiting + suntools. The solution, implemented in versions 2.7 and greater, + is to put the background CL in its own process group (an even better + solution, not yet implemented, might be to open a new terminal window + for the background job to run in). + +NUMBER: 44 +MODULE: proto$bscale +SYSTEM: V2.6 +DATE: Fri Jun 10 16:06:20 MST 1988 +FROM: davis + +BUG: The bscale task was going into an infinite loop during the mode + computation, if the computed sigma was less than or equal to zero. + This can occur can occur due to finite machine precision in the + situation where the rms is much less than the mean of the + distribution. + +STATUS: A check for a negative or zero valued sigma has been added in V2.7. + +NUMBER: 45 +MODULE: images$minmax +SYSTEM: V2.5 +DATE: Fri Jun 10 16:56:43 MST 1988 +FROM: davis + +BUG: Minmax was not printing the position of the minimum and maximum + pixel if the input image contained a section specification + and update was set to yes. + +STATUS: This bug has been fixed in version 2.7. The work around is to + turn off the update switch since minmax will not allow the user + to update the image header based on image sections in any case. + +NUMBER: 46 +MODULE: blkavg +SYSTEM: V2.5 +DATE: Wed Jul 13 15:34:53 MST 1988 +FROM: davis + +BUG: Blkavg would not work on 1D images. The header file was being created + correctly but no pixels were written to the pixel file. For 1D images + the number of output image lines was being incorrectly set to 0. + +STATUS: The bug has been fixed. There is no direct workaround but users can + use proto.imstack to create an n by 1 image and run blkavg on that. + + +NUMBER: 47 +MODULE: curfit +SYSTEM: V2.5 +DATE: Thu Jul 14 10:51:30 MST 1988 +FROM: davis + +BUG: The errors of the computed coefficients returned by curfit were + incorrect when points were rejected from the fit by setting the + weights to zero. The problem was in the math package curfit + routine cverrors. The code to compute the variance and the reduced + chi-square was not checking for 0 valued weights. Cverrors saw that + the variance and reduced chi square were different, concluded + that the fit was weighted, not uniform and did not scale the + coefficient errors by the variance. The solution was to add a check + for 0 weights and a new argument npts to the calling sequence for + cverrors. + +STATUS: This bug has been fixed. There is no workaround except to delete + points manually before entering curfit. Affected code in imred$dtoi, + utilities$curfit and xtools$icfit has been updated. + +NUMBER: 48 +MODULE: proto$irmosaic +SYSTEM: V2.6 +DATE: Sat Jul 23 12:10:00 MST 1988 +FROM: davis + +BUG: Irmosaic was not computing the column and row spacing between + adjacent subrasters of the output image if the parameters + nxoverlap and nyoverlap were < -1. The problem showed up in the + alignment stage in the forms of horizontal and vertical + streaks in the output image. + +STATUS: This bug has been fixed. The workaround is to leave nxoverlap and + nyoverlap at their default values. + +NUMBER: 49 +MODULE: local$apphot/polyphot +SYSTEM: V2.5 +DATE: Fri Jul 29 13:18:12 MST 1988 +FROM: davis + +BUG: The polyphot task was going into an infinite loop when supplied + with a polygons file containing comment lines preceeded by the + character # such as those generated by imtool. + +STATUS: This bug has been fixed. The work around is to remove the + comment lines manually before running polyphot. The other apphot + tasks are not affected by this problem. + +NUMBER: 50 +MODULE: utilities.curfit +SYSTEM: V2.5 +DATE: Fri Aug 5 13:51:57 MST 1988 +FROM: sjacoby + +BUG: The curfit task requires input data sorted in x and gives no + indication if this is not the case. Sorted data is required by + the rg_ranges procedure (even in the default case of sample=*) + or else data points will be ommitted from the fit. The only + indication in curfit that all data points are not being used is + that the value of 'total' doesn't equal 'sample' in the plot header. + +STATUS: Repaired in V2.7, such that for list input only, curfit will sort + the input array before fitting. + +NUMBER: 51 +MODULE: system.directory +SYSTEM: V2.5 +DATE: Thu Aug 11 11:45:54 MST 1988 +FROM: sjacoby + +BUG: When directory is called with sort=no, long=no and an extension + matching template like "*.tab", the task fails. On VMS/IRAF, + "no files found" is reported; on SUN/IRAF a segmentation violation + is seen. + +STATUS: The bug has been traced to a single line of code and will be + fixed in IRAF V2.7. A workaround would be to use directory + with "sort=yes", which is the default. + +NUMBER: 52 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.6 +DATE: Tue Aug 16 13:05:26 MST 1988 +FROM: valdes + +BUG: The median option of the combine routines is incorrect when the number + of images is odd. Instead of selecting the (N+1)/2 value, where N is the + number of images, it was selecting the N/2 value. It was also reported + as a bug that for N even it was not selecting the average of the + middle two values. This is not a bug but the intended behavior when + N is even. +STATUS: The bug was fixed as of this date. There is no work around. Though + the image produced is not the true median it will still be a useful + statistic. The help pages have been clarified to define the behavior + when the number of images is even. + +NUMBER: 53 +MODULE: binfil +SYSTEM: V2.5 +DATE: Mon Sep 19 13:53:04 MST 1988 +FROM: davis + +BUG: The short optional header was being incorrectly written to the + output file on the sun machines. The integer parameters ncols, + nrows and datatype were being passsed to short integer fields. + +STATUS: The bug has been fixed in version 2.7. The work around is to + avoid use of the header=yes option if possible. + + +NUMBER: 54 +MODULE: longslit$transform +SYSTEM: V2.5 +DATE: Wed Sep 21 13:47:34 MST 1988 +FROM: davis + +BUG: The longslit package task transform was writing the keyword "W0" + in wavelength units when log10 (wavelength) units were requested. + +STATUS: The bug has been fixed in 2.7. The work around is to be aware of + the problem and use hedit to edit in the correct value. + +NUMBER: 55 +MODULE: galactic +SYSTEM: V2.6 +DATE: Thu Sep 22 16:25:35 MST 1988 +FROM: davis + +BUG: The galactic task was not precessing the ra and dec to 1950 + coordinates before converting to galactic coordinates. Therefore + all computations were only valid for epoch 1950 input. This bug + is only present in v2.6. + + In addition the new code was using the ra and dec of the galactic + pole and the ra and dec of the galactic center to compute the + transformation. The IAU definition specifies the ra and dec of the + galactic pole and the galactic longitude of the north celestial + pole introducing a small error. This bug is only present in v2.6. + +STATUS: Both bugs have been fixed in version 2.7. The only work around is + to be aware of the problem and only use 1950.0 ras and decs. The + error introduced by problem 2 is very small. + +NUMBER: 56 +MODULE: median, fmedian +SYSTEM: V2.5 +DATE: Tue Oct 4 13:50:34 MST 1988 +FROM: davis + +BUG: If an error occurred during the execution of fmedian or median + and the input image name was the same as the output image name + the input image was deleted during the error recovery. The most + common source of error is insufficient disk space for the scratch + pixel file. + +STATUS: The bug in the error handling code has been fixed. The work around + is to avoid using inplace operation if disk space is known to + be limited. + +NUMBER: 57 +MODULE: astutil.rvcorrect +SYSTEM: V2.6- (From Oct87) +DATE: Wed Oct 5 14:25:15 MST 1988 +FROM: valdes + +BUG: The radial velocity component due to the Earth's rotation was in + error by 0.5% (too small). This bug appears in DOPSET from which + parts of RVCORRECT were transcribed. +STATUS: Bug and documentation fixed. + +NUMBER: 58 +MODULE: astutil.rvcorrect +SYSTEM: V2.5 +DATE: Tue Oct 18 09:17:12 MST 1988 +FROM: valdes + +BUG: Some of the radial velocity correction components are grossly in error + on Sun and other IEEE byte ordered systems (Alliant, DG). This is not + a problem on Vaxes. +STATUS: A constant was being used as an argument to a subroutine expecting a + double precision value. By default constants without the D exponent + notation are real numbers and so an argument type mismatch occured. + For Vaxes this is not critical since the most significant part is + correctly interpreted. There is no work around short of checking and + changing all the calls to ast_coords and recompiling. + +NUMBER: 59 +MODULE: ccdred.mkskyflat +SYSTEM: V2.5 +DATE: Thu Oct 20 10:15:34 MST 1988 +FROM: valdes + +BUG: This task produced the error "Cannot open image". +STATUS: The task correctly produced the sky illumination image but failed + when it attempted to multply this by the flat field image, + given in the CCDPROC parameters, to create the sky flat. The + message concerned not being able to open the flat field image. + Instead of the sky flat the resultant output image was a sky + correction image. One could make the sky flat using IMARITH + "imarith flat * skyflat skyflat" where flat and skyflat are + the appropriate images. The bug has now been fixed. + +NUMBER: 60 +MODULE: ccdred.mkillumcor, ccdred.mkillumflat +SYSTEM: V2.5 +DATE: Thu Oct 20 10:27:25 MST 1988 +FROM: valdes + +BUG: If the flat field image which is smoothed to produce a large scale + illumination has negative or zero values (something which should not + be the case for reasonable data) it is possible to obtain an arithmetic + divide by zero exception. Even worse if in some cases where the + mechanics of trapping this error have not been solved (in the latest + Sun systems) infinite loops may result. +STATUS: The arithmetic error, while clear that it is a division by zero, may + not be obvious to the user that the data is suspect. The user must be + aware of this. As a solution the tasks have been modified to count the + number of divisions by zero and print a warning summary at the end. + New task parameters specify what value to use as the result of + division by zero. A work around is to use IMREPLACE to put a + floor in the flat field data. Note that zero division checking + is not done in CCDPROC for efficiency but in these tasks efficiency + is not a problem since they are used at most a few times per + data set. + +NUMBER: 61 +MODULE: onedspec.bswitch +SYSTEM: V2.3-2.5 +DATE: Tue Nov 1 14:34:50 MST 1988 +FROM: valdes + +BUG: The task aborts if it cannot determine the airmass even if it does not + actually need this quantity. +STATUS: The airmass is now required only if the extinction correction is + requested. The work around is to use HEDIT to add a dummy airmass + under the keyword AIRMASS. + +NUMBER: 62 +MODULE: images.geotran +SYSTEM: 2.5 +DATE: Wed Nov 9 08:00:00 MST 1988 +FROM: davis + +BUG: Geotran quits with the error message "GSRESTORE: Invalid x or y order" + if one of the x or y coordinate surfaces is linear (xorder = 2 + yorder = 2) and the other is higher order (xorder > 2 or yorder > 2). + The gsrestore command was not being error checked in the case + where one of the higher order surfaces was null. + +STATUS: The bug has been fixed in 2.7. There is no work around except to + make sure that both higher order surfaces are null or both are non + null. Contact the iraf group for a bug fix. + + +NUMBER: 63 +MODULE: onedspec.dispcor +SYSTEM: V2.7 +DATE: Thu Dec 8 13:32:02 MST 1988 +FROM: valdes + +BUG: The new DISPCOR of V2.7 produces incorrect results (noticable high + frequency component) in very high resolution data (lambda / + delta lambda > 10E6). +STATUS: The bug was the result of a calculation using real arithmetic which + requires double precision for high resolution data. For lower + dispersions there is no problem. For high dispersion one must + either not use flux conservation or use wavelengths with the + large offset subtracted (for example use 76.321 instead of 4876.321 + where 4800 is subtracted from all wavelengths). This bug is fixed + in V2.8. + +NUMBER: 64 +MODULE: apextract.apnormalize +SYSTEM: V2.5-V2.7 +DATE: Thu Dec 15 17:31:22 MST 1988 +FROM: valdes + +BUG: Deleted points during interactive fitting of the normalization spectrum + remain deleted in later apertures. +STATUS: This has been fixed. Generally this would not cause any problems + since only a few points would be missing and the fit is over the + relatively smooth quartz spectrum. + +NUMBER: 65 +MODULE: reblock +SYSTEM: V2.5 +DATE: Sat Jan 28 12:56:27 MST 1989 +FROM: davis + +BUG: The copyn parameter was being ignored for tape to tape copies where + the physical block size was not being altered. + +STATUS: This bug has been fixed in 2.8. + +NUMBER: 66 +MODULE: apphot.polyphot +SYSTEM: V2.6 +DATE: Sat Feb 4 11:15:56 MST 1989 +FROM: davis + +BUG: Polyphot can return an incorrect result if the user inputs a polygonal + aperture which is not convex and if an image line happens to + intersect the polygon exactly on a vertex. + +STATUS: This bug has been fixed in IRAF 2.8. The work around is to use only + convex polygonal apertures. + + +NUMBER: 67 +MODULE: bscale +SYSTEM: V2.6 +DATE: Tue Feb 7 17:55:08 MST 1989 +FROM: davis + +BUG: Bscale would sometimes crash with a memory corruption error when + the image section to be used for computing the image statistics + was specified with the sections parameter instead of using + image section notation. The problem was caused by the task + overflowing the data buffer by attempting to read beyond the + limits of the section. + +STATUS: The bug has been fixed in 2.8. + +NUMBER: 68 +MODULE: apphot.apselect +SYSTEM: V2.6 +DATE: Mon Apr 3 11:44:27 MST 1989 +FROM: davis + +BUG: If a none of fields selected by the user with the fields parameter + actually existed in the apphot database file, the task would + terminate with a segmentation violation. + + The task was not cleaning up dynamically allocated menory in the + case that none of user selected fields were valid. + +STATUS: This bug has been fixed in V2.8 The work around is to retype the + command with the correct field name. + +NUMBER: 69 +MODULE: noao.proto.irafil +SYSTEM: V2.7 +DATE: Fri Apr 28 16:33:34 MST 1989 +FROM: rooke + +BUG: A user reported a segmentation violation running IRAFIL with + a large header area to skip. + +STATUS: Fixed in V2.8. After allocating dynamic storage for the header, + the code was mistakenly reading the header into pixel storage + instead, so if the header was longer than a row of pixels, it + would abort. + +NUMBER: 70 +MODULE: images.imcombine, ccdred.combine +SYSTEM: V2.7 +DATE: Fri May 5 16:47:34 MST 1989 +FROM: valdes + +BUG: 1. When scaling or weighting the sigma image is a factor of the + square root of the number of images too small. This does not occur + when not scaling or weighting. + 2. The sigma image is incorrectly computed by image.imcombine + when the input images are of integer datatype. +STATUS: Fixed in V2.8. + +NUMBER: 71 +MODULE: images.imarith +SYSTEM: V2.7 +DATE: Fri May 5 16:53:20 MST 1989 +FROM: valdes + +BUG: A command of the form + + cl> imarith test[20:30] * 1.2 test[20:30] + + where the output is a section of an existing image does not work as + might be expected and instead clobbers the original image by the + smaller output image. +STATUS: Operations into a subsection of an output image is not allowed by + the task and it was a bug that output image could be clobbered. + This was due to the fact that in place operations (i.e. replacing + an existing image by the result) are allowed. The current fix + is to print a warning and skip the operation if the output image + name contains an image section. + + +NUMBER: 72 +MODULE: images.imsurfit +SYSTEM: V2.5 +DATE: Thu Jun 1 11:41:24 MST 1989 +FROM: davis + +BUG: Imsurfit would go into an infinite loop if regions = "sections" + and the sections file was nonexistent. + +STATUS: The problem was a missing errchk on the open statement. The + bug has been fixed in V2.8. + +NUMBER: 73 +MODULE: specplot +SYSTEM: V2.7 +DATE: Tue Jun 6 08:54:50 MST 1989 +FROM: valdes + +BUG: Task SPECPLOT had wavelengths off by one pixel. +STATUS: This was due to an uninitialized CRPIX1 variable. The wavelength + variables refer to pixel 1 but pixel 0 was being used instead. + This only occurs if the W0 and WPC keywords are used instead of + the FITS keywords. The workaround is to change W0 by subtracting + WPC. Fixed for V2.8. + +NUMBER: 74 +MODULE: ccdred +SYSTEM: V2.7 +DATE: Fri Jun 16 11:03:00 MST 1989 +FROM: valdes + +BUG: If the backup prefix is a nonexistent directory ccdproc hangs + on Suns and possibly on other systems. +STATUS: The workaround is to change the backup prefix or make the directory + with mkdir. A fix has been made to print an error and abort. + The original image will be unchanged and the processed temporary + image is deleted. + +NUMBER: 75 +MODULE: splot +SYSTEM: -V2.7 +DATE: Fri Jun 16 15:29:14 MST 1989 +FROM: valdes + +BUG: If the wavelength per pixel is negative the options 'd' deblend, + 'e' equivalent width, 'm' signal-to-noise, and 'x' fudge extended + over a line give incorrect results. +STATUS: This has been fixed in V2.8. The workaround is to only use positive + wavelength per channel (WPC or CRDELT1). REBIN or SFLIP + can be used to change the dispersion direction. + +NUMBER: 76 +MODULE: dispcor/ecdispcor/msdispcor +SYSTEM: V2.8 +DATE: Mon Jul 10 13:26:08 MST 1989 +FROM: valdes + +BUG: The task DISPCOR does not produce the result one expects at the + endpoints of the input data. + +STATUS: The IRAF convention is that the pixel value refers to the center + of the pixel. When considered as an aperture the pixel extends + between -0.5 and +0.5 of the pixel center. The way the task is + written in V2.8, an interpolation function is fit to the values + at the pixel centers and the function is not defined beyond the + center of the first and last pixels. When using the flux + conservation option (integration of the interpolation function + across the extent of the output pixel) the part of the output + pixel corresponding to the half pixel beyond the center of the + first and last pixel is not used. For the simple case of an + output dispersion such that the size of an input and output + pixel are nearly the same and the endpoints are the same this + gives about a factor of 0.5 for the endpoint pixels. When not + using flux conservation the interpolation function is evaluated + directly. However, it is often the case that the center of the + last output pixel is computed to be just slightly beyond the + center of the last input pixel (due to rounding) and so the + last output pixel is often zero. + + The task has been revised to extrapolate the interpolation function + by a half a pixel on either end of the input data. The workarounds + are to avoid the endpoints when specifying the wavelength scale + during dispcor or by eliminating the endpoints after dispersion + correction using onedspec.sextract. + +NUMBER: 77 +MODULE: dispcor/ecdispcor/msdispcor +SYSTEM: V2.8 (Sun4) +DATE: Mon Jul 10 13:46:09 MST 1989 +FROM: valdes + +BUG: Using a dispersion table with INDEF values for the number of pixels + causes a floating operand error. +STATUS: An attempt is made to convert the magic value for INDEF internally + in such a way that the floating operand exception is encountered. + Note that this is only a problem when the value is read from the + dispersion table file. INDEF is fine as a task parameter. + There is no workaround for the INDEF feature though one can put + the number of pixels in explicitly in the dispersion table. diff --git a/doc/clman.ms b/doc/clman.ms new file mode 100644 index 00000000..62252841 --- /dev/null +++ b/doc/clman.ms @@ -0,0 +1,1287 @@ +.RP +.TL +CL Programmer's Manual +.AU +Elwood Downey +Douglas Tody +George H. Jacoby +.AI +.K2 "" "" "*" +December 1982 +(revised September 1983) +.AB +This document serves as a programmer's manual for the IRAF Command Language +version 1.0. +CL tasks, packages, parameter files, modes, expressions, statements, +abbreviations, environment variables, command logging, error handling and +directives are discussed. The special CL parameters are listed. +A example of a complete CL callable program is given. +.PP +This manual is a programmer's guide, not a user's guide or a technical +specification of the CL. Information about other programming tools +within the IRAF system, such as the SPP language and compiler and the +program interface, is given only to the extent required to introduce +the examples. +.AE + +.NH +Introduction +.PP +The Command Language, or \fBCL\fP, serves as a command and runtime supportive +interface between the user at his computer terminal and the application +programs he is executing. The user types his commands to the CL and it does +whatever task and file manipulations are necessary to carry out the commands. +.PP +The user and the applications task do not communicate directly; they +communicate only through the CL. +Once started, a task requests parameters by name from the CL and the CL responds +with the value of the parameter. +To get that value, the CL may have had to read a parameter +file, query the user, do range checking, extract a value from a command line or +perform other actions. +.PP +All CL/task communications take place via an interprocess communications +link between the CL process and the process containing the applications task. +Standard input, output, error, and plotting channels are multiplexed on this +link and managed by the CL. The CL process and the applications package +process execute concurrently. +.PP +This arrangement relieves each new application program from having +to provide user interface functions that are often rewritten +directly each time, such as command line parsing, command and parameter +abbreviations, and levels of interaction to accommodate both novice and +experienced users. +In addition, the CL provides a common environment for running all tasks +with services such as executing programs with their input and output +redirected to files or to other programs, managing parameters for each command, +handling lists of values in lieu of a simple parameter, logical device +and file name assignments, and help facilities. The CL is a simple programming +language in its own right, with conditional and repetitive command execution, +parameter expressions and a calculator. +.PP +While intended to support scientific reduction and analysis applications at +Kitt Peak and elsewhere, the CL can serve any project that involves running +programs as commands with arguments. Every effort has been made to make the CL +as portable as possible. The link between the CL and the task it +is running is character oriented and allows the task to to be run directly +without any support from the CL if desired. +This link may be simulated by any program that wants to run as a task +under the control of the CL. However, any task written in the SPP +language (which is Fortran based) will automatically include all the i/o +facilities required to interface to the CL. + +.NH +Terminology +.PP +This section defines most of the terminology associated with the CL. +Words in \fBboldface\fP are part of the actual terminology of the CL. +Those in \fIitalics\fP are more descriptive in nature and serve only to +name a representative item. + +.NH 2 +Physical and Logical Tasks, Scripts +.PP +A task runnable under the CL is a file +containing either the executable program itself, or a text file containing +a \fBscript\fP written in the CL language. Either of these is referred to as +a \fBphysical task\fP since they are true files on the host computer. +The executable form consists of one or more \fBlogical tasks\fP but +the script file is always considered exactly one logical task. +The general terms \fBcommand\fP and \fBprogram\fR refer to one of +these logical tasks. In order to know just how to go about running the command, +the CL has a "task" declaration that indicates in which +file the task resides, and whether it is in an executable or script form. +Once declared, the logical task commands are used the same way regardless of +whether they reside in an executable object file or a script. +.PP +In order to manage itself, there are a few commands that the CL does +itself, such as the "task" command mentioned above. These built-in commands +are referred to as CL \fBdirectives\fP, but only as a means of classifying +them as a group. They act and are used very much like regular commands. +In this way, they have the same syntax rules and their diagnostics work in the +same fashion. Since they are built into the CL program itself to achieve +intimate knowledge of its internal data structures or simply to increase +efficiency, the set of directives is not extensible by the user. +.PP +Thus, there are a variety of ways a command may get executed. +It is no accident that there is often no easy way to tell how a command is +implemented. + +.NH 2 +Packages +.PP +Ostensibly, tasks are grouped into packages. This provides a +logical framework to organize a large body of commands in a large system +and also serves to address the problem of redefinitions. +The CL directives and a few utility programs are located in the root +package, called \fBclpackage\fP, and is always present when the CL starts up. +Some of the commands in the root define more packages when run. They +are script tasks that define a package and some tasks in that package. +By convention, the name of the package defined by a script, the logical task +and the script physical task file name are all the same. +.PP +Any package defined to the CL may become the \fBcurrent package\fP. The prompt +issued by the CL includes the first two characters of the current package. +When a command is typed to the CL, it looks in the tasks +of the current package first, then through all tasks in lower packages towards +the root clpackage for the logical task with the given name. Tasks defined +in packages defined farther away from the root are searched last. This +\fBcircular search path\fR provides some measure of control over command +scope. +.PP +Wherever a task name is expected in the CL syntax, the package may be explicitly +specified in the form \fIpackage.task\fP so that only tasks defined +in that specific package will be considered in the search for the given +logical task name. This form allows package names farther away from the root +than the current package to be accessed. It also provides an unambiguous way to +reference a task when the task name appears in more than one loaded package. +If the name of a loaded package itself is given as a command, then it +simply becomes the current package (see the package directive in \(sc12). + +.NH +Parameter Files +.PP +A separate file, the \fBparameter file\fP, may exist for each logical task. +It contains a description of each of the parameters used by the task that +should be known and managed by the CL. (These are not the same as variables +declared in the source program for the task.) The parameter files are the +permanent record of task parameters. When a parameter value is permanently +changed, as with an assignment or when in learn mode, the CL makes a local copy +of the parameter file with the new value. Thus, running tasks imply CL reads +and writes to parameter files as well as execution of the task. +.PP +A logical task need not have a parameter file. If a task makes a request to the +CL for a parameter and the CL knows the task has no parameter file a fake query +for the the parameter will be issued by name (see \(sc4 for more on queries). +All of the range, prompt, learning and type checking advantages of real +parameters will be lost, however. Thus, a parameter reference by a task +that does not have a parameter file at all is not considered an error. This is +different than a reference to a nonexistent parameter by a task that does have a +parameter file, which is an error. + +.NH 2 +Location and Name of Parameter Files +.PP +The parameter file for a logical task may be in two places. The CL first +searches the \fBuparm\fP directory, then the directory containing the physical +task. All physical tasks for a package, including the script task that defines +it, are usually in one directory, often referred to as the \fBpackage +directory\fP. +.PP +Uparm is an environmental entry used by the CL when accessing parameter files. +If it does not exist, the current directory is used. +Uparm may either be another environmental reference to a directory or be in +host-dependent format (see environment, \(sc8). +.PP +The names of parameter files written out, either to uparm or to the current +directory, are formed by concatenating the first two and final characters +of the package name, an underscore, the name of the logical task, and the +extension ".par". +For example, when the parameter file for a task \fItxyz\fP in package +\fIpxyz\fP is written, it is named \fIpxz\(ultxyz.par\fP. +The package prefix is prepended to avoid file name +conflicts if two tasks in different packages happen to have the same name. +Since local copies have the package prefix, the CL looks for them before ones +without the package prefix. + +.NH 2 +Parameter File Format +.PP +The parameter file for a logical task consists of comments, blank lines, and +parameter declarations. These may appear in any desired order. +Comment lines are those that begin with the sharp character, #, +and signal that it and all remaining characters on that line should be +ignored. The maximum line length is 132 characters. +.PP +Parameter declarations within the parameter file take the form +.DS + name, type, mode, value, minimum, maximum, prompt +.DE +where all fields from value on are optional. The comma and the end of the line +itself both serve as a field delimiter and thus a comma is not necessary after +the last field, whatever it is. +.NH 3 +name +.PP +This is the name of the parameter. There is no length limit other than the +overall line length limit consideration. This is the name by which the +parameter will be known to the task and to the CL. It must begin with a +letter or a dollar sign, $, but the remaining characters may be any +combination of letters, numbers, underscore, \(ul, and dollar, $. Casual use +of $ is not recommended, however, as it is used to make environment references +(see \(sc8). +.NH 3 +type +.PP +The type field indicates how the parameter is to be stored. It also implies +some information about what values are acceptable and how they are entered, +as discussed below under value. +.DS +.TS +; +ci ci +l l. +code meaning +.sp +b boolean +i integer +r real +s string +f or f\fIxx\fR file name +struct structure +gcur graphics cursor +imcur image cursor +.TE +.DE +.PP +The codes \fBb\fP, \fBi\fP and \fBr\fP indicate the usual boolean, +integer and real types. They are discussed further in the value section, +below. +.PP +There are several types that manipulate character strings. +The characters themselves may be anything from the ASCII set. +The type \fBs\fP is the simplest and is an ordinary character string. It is +typically used for names, flags and messages. +.PP +The \fBf\fP type is like s except that it is limited to +legal file names on the host operating system, after possible environment +substitution. The f may optionally be followed by any reasonable combination +of the characters \fBe\fP, \fBn\fP, \fBr\fP, or \fBw\fP. +These indicate that checks should be made of the file name before it is +used that it exists, does not exist, that it exists and is readable and that +it exists and is writable, respectively. \fBStruct\fP is also like s but +its value is the entire next line of the parameter file. +.PP +\fBGcur\fP and \fBimcur\fP are +similar to struct but are expected to be of the form "x y char" to be usable +as cursor coordinates. +A gcur or imcur parameter will always read from the hardware +graphics or image display cursor if it is in query mode. +.PP +If the type is preceded by a star, *, the parameter is \fBlist-structured\fP. +When the parameter is referenced, the value will come from +a file, the name of which is the fourth field of the parameter declaration. +All of the basic types may be list-structured. +.NH 3 +mode +.PP +This field indicates what actions are performed when the parameter is +referenced or assigned. +The topic of modes is important to the CL and is covered more thoroughly +elsewhere (\(sc4) Briefly, query mode generally causes the user to be +queried each time the parameter is referenced. +Learn means that all changes to the parameter will be permanent. +Auto mode means that the effective mode of the parameter should be whatever +the mode is of the task that is using the parameter; auto mode defers +mode selection to the task, or CL level. +Hidden means that the existence of the parameter will not be +evident to the user unless its value is not acceptable. +.PP +The mode field may be any reasonable combination of query, learn, +auto and hidden. These may be spelled out and separated with plus signs, +, +or abbreviated to one character and run together. For example, +.DS + ...,auto+learn,... +and + ...,al,... +.DE +and equivalent. +.NH 3 +value +.PP +This field is optional. The value field is the initial or \fBdefault\fP value +of the parameter. It has various characteristics depending on the type of the +parameter. If it is absent, the parameter will be marked as undefined and will +cause an error if used in an expression. A special entry, \fBindef\fP, is +allowed that marks the parameter value as being indefinite, but not undefined. +It may be used with all types. Acceptable constants in the value field are +like those allowed by the CL in expressions (see \(sc5.1). +.PP +For boolean parameters, it should be either the three characters \fByes\fP or +the two characters \fBno\fP. +.PP +Integer and real parameters are as one would expect. Real constants need not +include a decimal point, ., if not required. +.PP +For string and file name parameters, the field +extends from the comma following the mode field to the next comma, or the end +of the line if none. It may be surrounded by single or double quotes, ' or ", +but these are not necessary unless the string is to include a comma. +The length of the storage allocated for the string will be the minimum of +30 characters and the length of the initial value, up to a maximum of 132. +Later changes to the value of the string will be silently truncated to the +amount thus established. +.PP +Structs and the cursor types use the value field to indicate the number of +characters of storage to allocate to hold the value of the parameter. The value +is a string consisting of the entire next line of the parameter file. +If no number is given in the value field, then just enough storage to hold the +next line will be allocated. If the number is larger, this allows +the value to grow longer than the length of the next line. Since dynamic +string storage is not used in the CL, the length of all strings is fixed +and using the value field in this way permits a short initial value but allows +for later growth. +The length of string storage is limited to 132 characters. +It is an error to explicitly specify a storage length shorter than the initial +value. +.PP +The value field for list-structured parameters is the name +of the file containing values for the parameter. This name is subject to the +same restrictions as a parameter of type fr and environmental references are +allowed. +.PP +Thus, the value field entry for a parameter in a parameter file has several +different uses, depending on the type of the parameter. +The term \fBvalue\fP refers to that which is used +when the parameter is used in an expression and \fBvalue field\fP refers +specifically to the fourth field of the parameter specification. +Because of this multiple usage, the CL recognizes this field with several +names, as described under parameter references (\(sc5.2). +.NH 3 +minimum \fRand\fP maximum +.PP +These two fields work together to specify a validity range for the value of +the parameter. They are ignored for all types except integer, real, and file +name parameters and follow the same rules as the value field for these type +parameters. Their application to filenames is to test for a simple lexical +ordering. If they are both set when the parameter is referenced, then a query +will be generated if the value of the parameter is not within range. No range +checking is done if either the minimum or maximum are undefined or if min > +max. If the parameter is list-structured, then the range checking is +applied to the entry read from the file. +.NH 3 +prompt +.PP +This field behaves like a string and extends from just after the sixth +comma in the parameter spec to the end of the line. It may be quoted. +As explained more thoroughly under query mode, its purpose is to provide a +meaningful prompt for the parameter during a query. If no prompt string is +given, then the query will just use the name of the parameter. As with strings, +the length of the prompt implies the amount of static storage to allocate; +later changes to the the prompt will be silently limited to this length. + +.NH +Modes +.PP +The CL supports three modes of operation, query, learn and auto. +.PP +\fBQuery\fP mode is the most interactive and is the standard mode when +the CL is being used interactively. +It causes each parameter referenced by a task, or script, to +produce a query on the terminal consisting of the prompt string for that +parameter, its current value and minimum and maximum values, if set. If there +is no prompt string, then the name of the parameter is used. When the user +sees this query, he may type a simple return to accept the current value or +type a new value. +New values that are entered in this way are checked for validity immediately +with regard to type and range, and the query repeats until a reasonable value +is entered. +.PP +A query will be generated regardless of the effective mode of the +parameter if it does not meet its range requirements. On the other hand, a +query will be prevented if the parameter was set on the command line, again +assuming it is not out of range. Thus, the CL relieves the +application program from some of the burden of verifying its parameters. +.PP +\fBLearn\fP mode retains the values of parameters across task runs +and even across CL sessions. The default values of parameters come from their +entries in the task's parameter file. If learn mode is not in effect, changes +to parameter values by way of command line arguments to the task or queries +do not cause the parameter file to be updated and so the values revert back +to their defaults as soon as the task ends. +Learn mode makes these changes permanent by updating the parameter file for +the task. +.PP +\fBHidden\fP mode applies only to parameters. It prevents queries from being +generated even if the effective mode for the parameter is query, unless its +value is out of range. Hidden mode also prevents +the default value from ever being "learned". The only way to change the default +value of a hidden parameter is by an assignment statement. +Hidden mode is useful for parameters that are rarely if ever changed to hide +their existence from all but experienced users. + +.NH 2 +Determining Modes +.PP +The modes exist independently in a three level hierarchy: the +parameter, the current task, and the CL itself. Whenever a parameter is +referenced, its \fBeffective mode\fP is calculated. To determine +the effective mode, the mode settings of the three levels are used starting +with the parameter level. If the +mode of the parameter is query or learn, that is the effective mode. +If the parameter's mode is \fBauto\fP, then the effective mode is that of the +current task unless it too is in auto mode in which case the effective mode is +that of the CL. If all levels are auto, the effective mode is auto and +neither query nor learn effects will occur. +.PP +Thus, each layer of the hierarchy, starting at the parameter level, defers +to a higher level until it finds either query or learn (or both). +Note that the presence of hidden mode at the parameter does not alter this +process but rather serves to override query mode, should it be found at any +given level. +As a practical example, all the auto-mode parameters in a task can +effectively be put into query mode at once by setting the mode once at the +task level to query. + +.NH 2 +Setting and Changing Modes +.PP +The modes themselves are set in different ways at the parameter and task +level. The mode for a particular parameter is accessed as a field of that +parameter called \fBp\(ulmode\fP. It may be abbreviated. The mode of a task +is in a parameter \fBmode\fP, of type string, that contains any reasonable +combination of the letters \fBq\fP, \fBl\fP, \fBa\fP and \fBh\fP. This +parameter may be declared +and initialized as desired in the parameter file for the task just like any +other parameter. If it does not appear in the parameter file for a task when +it runs, it will be manufactured and supplied with a default setting of 'ql'. +This is the only case of a parameter added by the CL to a parameter list for a +task. One of the parameters to the CL itself is also \fBmode\fP, and this +serves as the mode of the CL, the highest level in the mode hierarchy. +.PP +As a convenience for naming modes, four CL string parameters \fBquery\fP, +\fBlearn\fP, \fBauto\fP and \fBhidden\fP are defined to be the +single-character strings 'q', 'l', 'a' and 'h'. +Examples of setting modes at the CL, task, and parameter +levels: +.TS +center; +l l. +mode \(eq 'ql' # set CL mode to query, learn +package.task.mode \(eq 'a' # set given task mode to auto +package.task.param.p\(ulmode \(eq 'ql' # set given parameter's mode +mode \(eq query + learn # use pre-defined string params +mode +\(eq query # add query +.TE +.PP +The mode of a parameter may also be changed during a query for that +parameter. If the response to the query begins with a percent, %, then +the mode for the parameter may be set using the same format as that used +in the parameter file mode field (see \(sc 3.2). +This is useful during program development for making a parameter hidden once +its default value has been determined. + +.NH 2 +Recommended Mode Settings +.PP +The recommended default modes are auto and learn for the CL itself, query for +each task and auto or hidden for the parameters. Auto mode for all non-hidden +parameters in a task allows them all to be changed at once by changing the +mode of the task. +The user will rarely do more than change a task's mode to auto, +hide a parameter (by use of the %h response to a query, \(sc4.2), +or reset all parameters of a task to their original default by +deleting its parameter file from the uparm directory (see \(sc3.1). + +.NH +Expressions +.PP +The CL allows expressions wherever a simple variable might appear. This applies +only to the language, however, not, for example, in the parameter files. +Expressions are the usual kinds of combinations of constants, variables, +intrinsic functions, operators, parentheses and expressions (recursively). + +.NH 2 +Constants +.PP +Boolean constants are entered as the three characters "yes" or the two +characters "no". There are no true and false constants. +.PP +Integers are an uninterrupted sequence of digits; a trailing `b' denotes an +octal constant. +.PP +Floating point constants are as in most languages but a decimal point is not +necessary if not needed. 5, 5., 5e0, .5e1 and 5.e0 are all equivalent. +Sexagesimal notation may also be used to create a floating point value. +A negative value is indicated by a leading minus sign, -, leading zeros are +not necessary and the seconds field is optional. +1:23:4.56, -12:3:4.5, 1:2:3 and -12:34 are all acceptable. +.PP +Strings are zero or more characters surrounded by single or double +quotes, ' or ". The quotes are not needed in two cases. One is in response to +a query. In that case, everything up to the end of the typed line is taken to +be the string. If the quotes are used, however, they will be discarded. The +other case is when specifying the value of a parameter on the command line +when running a task. If the corresponding parameter is of type string, filename +or is list-structured and the string need not be used in an expression, then +the quotes are optional. +.PP +An additional constant, \fBindef\fP, is known to the CL. This is a +special setting that means indefinite, as opposed to being truly undefined. +The latter causes an abortive error if encounted during the evaluation of an +expression. A parameter that is merely indefinite does not result in an error +or a query and is useful for indicating the value should be ignored, but +propagated through an expression. +.PP +See the discussion of the intrinsic scan function (\(sc 5.3) for two +additional constants, EOF and stdin. + +.NH 2 +Parameter References +.PP +The "variables" in CL expressions are task parameters. To reference a +parameter, the most general form is \fIpackage.task.param.field\fP. +This form may be used anywhere a parameter is legal. +Only the parameter name portion is required. +If the package and task are not specified, the parameters for the current +task, then the current package and finally those of the CL itself are searched. +The parameter is not found if it does not exist in one of these three places. +.PP +If the field is not specified, then the meaningful value +of the parameter is used, as explained under the discussion for the value +field of a parameter (see \(sc3.2). The possible fields are p\(ulname, +p\(ultype, p\(ulmode, p\(ulvalue, p\(ulminimum, p\(ulmaximum and p\(ulprompt. +In addition, the value field may also be given as p\(ullength, p\(uldefault +or p\(ulfilename. These are intended for use with parameters of type struct or +cursor, integer or real, or filename (or list-structured). These aliases are +not strictly enforced but are provided to improve readability and reliability +in CL commands, particularly within script tasks. +Each portion of the parameter reference may be abbreviated separately (see +\(sc7). +.PP +The result of using a logical operator is either the +boolean true or false. These values are represented internally as 1 and 0, +respectively. Although it is bad programming practice to make use of that fact +in further arithmetic operations, it is not prohibited. + +.NH 2 +Intrinsic Functions +.PP +The CL provides a set of standard intrinsic functions that may be used +in expressions. They are much like those found in most math libraries and are +listed here only for reference. As with commands, they may be abbreviated but +unlike commands their arguments must be enclosed in parentheses. +Calling them with illegal arguments or producing underflow or overflow +generates an error. +Their argument(s) may be integer or real and they will try to return the same +type as their argument if no loss of precision would result. +.TS +center; +l c l. +Usage Number of Description +\^ Arguments \^ +\_ \_ \_ +abs(x) 1 absolute value +atan2(y,x) 2 arc tangent, with proper quadrant +cos(x) 1 cosine +exp(x) 1 natural exponentiation +frac(x) 1 fractional part +int(x) 1 integral part +log(x) 1 natural logarithm +log10(x) 1 common logarithm +max(x1,x2...) > 1 maximum +min(x1,x2...) > 1 minimum +mod(x,modulo) 2 first arg modulus the second +round(x) 1 nearest integer, rounded away from zero +scan(l,p...) > 1 free-format read; see below +sin(x) 1 sine +sqrt(x) 1 square root +tan(x) 1 tangent +.TE +.PP +The \fBscan\fP intrinsic function reads from its first argument as a string +and assigns the pieces, suitably type cast, into the remaining arguments. +If the first argument is a list-structured parameter, the next line of the file +is read and scanned, unless query mode is in effect in which case the user is +always prompted for the line. If the first argument is a string-type parameter, +including filename, struct, gcur or imcur, then the string is scanned. This +serves as an in-core read, much like a Fortran decode or a C sscanf function. +Spaces, tabs and commas are recognized delimiters. If the last +target parameter is a string, it will receive the remainder of the string being +scanned. +.PP +Scan returns as its function value the number of successful conversions. +Reading from a list and encountering eof will cause scan to return a count +of zero. There is a pre-defined constant in the CL, \fBEOF\fP, +which is simply zero; it may be used to make the test more explicit. +There is another CL constant, \fBstdin\fP, which may be used as the first +argument to cause scan to read from the standard input. Examples of scan are +.DS +.cs 1 22 +# Read gcur and print radii until end of list. +while (scan (gcur, x, y, remainder) >\(eq 2) + \(eq sqrt (x\(**\(**2 + y\(**\(**2) + +# Read until EOF is detected. +while (scan (file, line) !\(eq EOF) + \(eq line +.DE +.cs 1 + +.NH 2 +Operators +.PP +The following is a list of the arithmetic and logical operators available in +the CL. They are the same as in the SPP language. +.TS +center; +l l l. +Operator(s) Type of Result Function +\_ \_ \_ ++,\ \(mi,\ \(**,\ / numeric the usual, but see below for + with strings +\(**\(** numeric raise to power +% numeric first expression modulus the second; like mod() +<,\ > logical less than, greater than +<\(eq,\ >\(eq logical less than or equal, greater than or equal +\(eq\(eq,\ !\(eq logical equal, not equal +&& logical logical `and' +|| logical logical `or' +! logical logical `not' +.TE +For those familiar with C, note the absence of \(eq. It is not considered +an operator that produces an l-value but may only be used in an assignment +statement. +.PP +The + operator can be used to concatenate strings. If only one of its +operands are strings, the other will be converted first. If one operand is a +string, the other is an integer and the string operand contains an integer on +the same side as the integer operand, then an arithmetic addition will be +performed as well. For example, +.RS +.TS +; +l l l. +'stringa' + 'stringb' \(-> 'stringastringb' +'string1' + 'string2' \(-> 'string1string2' +'string1' + 2 \(-> 'string3' +2 + 'string1' \(-> '2string1' +2 + '9string' \(-> '11string' +'string' + boolean\(ulparam \(-> 'stringyes' (or 'stringno') +.TE +.RE +Points, ., in strings with digits are not recognized as floatings so trying to +add floatings to strings, while not prohibited, probably doesn't do anything +useful. + +.NH +Statements +.PP +Statements fall into the following categories: assignments, commands, +immediate and flow control. These will are discussed separately, below. +.PP +Statements may be delimited by newline or semicolon, ;, and may be grouped +with brackets, { and }. Nesting is supported. +Comments begin with the sharp character, #, which indicates +that all characters from it to the end of the line are to be ignored. +Statements that are too long to fit on a line may be continued by ending +the line with a backslash, \\\, or they are automatically continued if the +last character is a comma. +.PP +When used from a terminal, the CL issues a continuation prompt, >>>, when +the outermost statement has not been completed. This indicates input +is still being accepted and parsed. No work will actually be done until +the CL sees a complete input statement. + +.NH 2 +Assignment Statement +.PP +An \fBassignment\fP is a statement of the form \fIparameter \(eq expression\fP. +The parameter is always permanently changed by an assignment +statement, whether or not learn mode is in effect. +.PP +Two additional forms of assignments are provided that also perform arithmetic, +\fIparam +\(eq exp\fP and \fIparam \(mi\(eq exp\fP. These are equivalent to +\fIparam \(eq param + exp\fP and \fIparam \(eq param \(mi exp\fP. They are more +efficient as well as more convenient. These forms also permanently change the +parameter. +.PP +All forms of the assignment statements will cause an error if the result of +\fIexp\fP is undefined. Thus, the CL will never allow a parameter to be set +to an undefined state. The only way to get an undefined parameter is by not +setting it in a parameter file (see the value discussion in \(sc3.2). +Assignment statements are the only way a hidden parameter may be permanently +changed. + +.NH 2 +Commands +.PP +A \fBcommand\fP is the basic means of running logical tasks. It consists of +the name of the logical task, possibly with arguments, and pipes to more +commands or io redirections. The arguments to the command, if any, may +optionally be surrounded by parentheses. These are recommended in scripts. +Command lines may be continued on the next line automatically if they end +with a comma or a backslash. + +.NH 3 +Command Arguments +.PP +The arguments to a command are given as a comma-separated list and come in two +basic forms, positional and absolute. +The \fBpositional\fP form is any general expression. +The expressions will be evaluated and assigned one-to-one to the corresponding +parameters of the task, as defined by their order in the task's parameter file, +not counting hidden parameters. Only the value of the parameter may be set in +this manner. +A lone comma may be used as a placeholder and skips a parameter without +changing it. Parameters not reached in the matching are also not changed. +.PP +The \fBabsolute\fP form is an assignment, \fIparameter \(eq expression\fP, +where the parameter must be a parameter of the task being run. This is useful +when a parameter value is to be changed but its +position in the argument list is not known or it would be awkward to arrive +at its position by a large number of positional arguments. Since +the parameter is explicitly named, fields other than the default value +may be changed with the absolute form. +.PP +Another form of absolute argument is the \fBswitch\fP. It is +a shorthand way of specifying the truth value of a boolean parameter. A +switch consists of the parameter followed by a plus, +, to set it to yes, or a +minus, \(mi, to set it to no. Thus, these two forms are equivalent ways of +turning off the boolean parameter \fIoption\fP: +.DS + task option\(eqno + task option\(mi +.DE +.PP +While they may be used together, all positional arguments must precede +absolute arguments. Here are examples of using the positional and absolute +forms together: (note the parens in the second example are optional) +.DS + task1 x, task2.param, op+ + task3 (a, b, c, param2\(eqx+y, op3\(mi, param3\(eqtask4.x/zzz) + task4 x, y, z, op1+, op2\(eqyes +.DE +.PP +Parameters changed on the command line will have their new values as long as +the command is executing. If learn mode is not in effect for the parameters, +they will revert back to their original values when the task ends or if the +task aborts for some reason. + +.NH 3 +Pipes and Redirections +.PP +A \fBpipe\fP connects the standard output of one task to the standard input of +another task. A pipe is indicated by separating the tasks +with a vertical bar, |. As many pipes in a series may be used as necessary. +\fBRedirections\fP of the standard input and output of a task from or to files +are also supported. +.PP +The standard input may come from a file by indicating the filename after the +less-than symbol, <, and the standard output from the last task in a pipe +sequence may be sent to a file by giving its name after the greater-than +symbol, >. Two greater-thans, >>, cause the output to be concatenated to the +end of the file. If the output redirection symbol is preceded by an ampersand, +&, then the standard error will also be included, as in &|, &> and &>>. +Output redirections, but not pipes, are considered absolute arguments to the +task so they must follow any positional arguments and must be set off by +commas. For example, task1 reading from file t1input piped to task2 +writing to file t2output is done as +.DS + task1 x,y,z, < t1input | task2 x2, y2\(eqa+b, > t2output +.DE + +.NH 2 +Immediate Statement +.PP +This is the \fBcalculator\fP mode of the CL. It consists of the basic assignment +statement without the left-hand side parameter, as in "\fI\(eq exp\fP". +Instead of computing the expression and assigning it to a parameter, +the result is simply sent to the standard output. This may in turn be +redirected if the calculation is being done from a script. + +.NH 2 +Flow Control +.PP +The CL provides \fBif-then-else\fP and \fBwhile\fP program flow control +constructs. These look like +.DS +.cs 1 22 + \fBif\fR (expr) + statement + \fBelse\fR + statement +and + \fBwhile\fR (expr) + statement +.DE +.cs 1 +This is quite general since the "statement" may be a group of statements in +brackets. Also, since if-then-else is itself a statement, they may be +chained into if-then-else-if- and so on. The else clause is optional. + +.NH 2 +Abbreviations +.PP +If the boolean CL parameter \fBabbreviations\fP is yes, then packages, +commands, intrinsic functions and parameters may be abbreviated. +The scope of the abbreviation is limited by its context. For example, if +a parameter reference is \fItask.param\fP, the only candidates for the param +abbreviation are those parameters belonging to the given task; similarly for +parameter names given in the absolute form of a task's argument list. +Parameter fields, such as p\(ulname and so on, are always considered within +their own class so their briefest forms are always p\(uln, p\(ult, p\(ulmo, +p\(ulv, p\(ull, p\(uld, p\(ulf, p\(ulmi, p\(ulma and p\(ulp (see \(sc5.2). +The intrinsic functions are also in their own class. +.PP +Abbreviations are not allowed in scripts. They are intended +only to streamline interactive work with the CL. + +.NH +Environment +.PP +The \fBset\fP CL directive, as explained elsewhere (\(sc12), provides a simple +string substitution mechanism for filename translations. Most operating systems +allow a logical assignment to a physical device name for use in filenames. +The CL trys to merge this with its own environment table so that definitions +in the host system are available within the CL in addition to new +entries added by the CL. Typical uses for the translations are portable names +for system-dependent directories and io devices, such as tape. +.PP +The CL keeps its environment table in a last-in first-out fashion. New entries +hide but do not overwrite old entries. Substitutions take place in strings +being used as file names in commands and in parameter files. +This includes list-structured parameters and io redirection. Environment +references are indicated by following them with a dollar, $. For example, +if the following environment definition is made: +.DS + set mydir \(eq '/usr/myname/dir/' +.DE +then these uses +.DS + task x, y, z, > mydir$file1 + task2 filename \(eq mydir$file2 +.DE +become +.DS + task x, y, z, > /usr/myname/dir/file1 + task2 filename \(eq /usr/myname/dir/file2 +.DE +Note that the quotes around the value for mydir are necessary since the slashes +are not legal in identifiers. +.PP +The environment facility is strictly a string substitution mechanism. +Directory names and other uses must be complete enough so that a valid +filename is the direct result of the substitution; the environment facility +has no knowledge of file naming requirements on the host system whatsoever. + +.NH +Log File +.PP +If the boolean CL parameter \fBkeeplog\fP is yes, then each command typed +by an interactive CL will be entered into a log. Commands that come to the +CL from tasks or scripts are not kept. The name of the file is in the +filename CL parameter \fBlogfile\fP. This parameter is only used when logging +is started. To change the name of the logging file after logging has +already begun, set keeplog to no, change the value of logfile, then restart +logging by setting keeplog to yes. Each time logging starts, the current time +is entered in the log file as a CL comment. + +.NH +Error Handling +.PP +From the start, the single most important requirement of the CL was that it +properly handle error conditions. As one veteran put it, "the error case is +the normal case, and the case when the program runs perfectly is the abnormal +case".* +.FS +* \fIWriting Interactive Compilers and Interpreters\fP, P.J. Brown, page 55. +.FE +.PP +To most easily explain error recovery in the CL, the discussion diverges for a +moment to explain a bit of its internal structure. +Each new logical task that is run pushes a data structure onto a control stack. +This structure indicates, among other things, where the standard input and +output for the task are connected and process control information. +As each task dies, its control structure gets popped off and the +exposed task resumes as the active one. +.PP +When a task encounters an error, +it issues a diagnostic to its standard error and informs the CL. The CL then +repeatedly pops tasks, killing them as necessary, until it uncovers one +that had its input and output connected to the terminal. Thus, an error +condition forces a return to an interactive task, most likely an instance +of the cl directive. +.PP +As each task is popped, its name and the parameters that +were set on the command line when it was run are given as a kind of "stack +trace" to aid diagnosis. Parameter files of tasks that abort due to their +own errors or because they got killed on the way to restoring an interactive +state are not updated. The environment, package and task definitions, and +all other extensible data structures, are restored to their state at the time +the resumed task was pushed. +.PP +The diagnostics from the CL all begin with "ERROR:". This always +means that the full abortive procedure outlined above has occurred. +If an internal consistency check fails, this becomes "INTERNAL ERROR:". A few +diagnostics begin with "WARNING:". Warnings do not invoke the abortive +procedure but are merely informative messages generated during command +processing. +.PP +Perhaps the least helpful error messages are "syntax error" and "parser +gagged". These are generated by the parser when it has no idea of what it is +trying to crack or when it gets terribly confused. +The only advice, until the improved parser of CL2 is available, is to +carefully inspect the offending statement. If the error occurs during +the interpretation of a script, an approximate line number is also given. + +.NH +CL Initialization +.PP +When the CL starts up, it tries to read two CL script files. The first +is in an IRAF system-wide directory and is called \fBclpackage.cl\fP. +It defines the tasks in the root package clpackage, +makes useful environment entries and does other chores such +as printing news. The other is called \fBlogin.cl\fP and will be run if found +in the current directory from which the CL is started. This serves as a way +to personalize the CL on a per-user basis. Typical uses are to +set modes, options and uparm, define personal tasks and packages and make +environment entries for frequently used directories. +Note that login.cl is run as a genuine script and any changes it makes to the +dictionary after doing a "keep" will be lost. + +.NH +CL Directives +.PP +The following commands are handled directly by the CL. They are always +available in the root package, clpackage. They behave as all other commands +in that they may be abbreviated and may have their input and output redirected +as desired. Arguments in square brackets, [ and ], are optional. +.NH 2 +\fBbye\fR +.PP +Exit the current task and resume the previous one where it left off. If there +is no previous task, then the CL ends. Any task declarations, cached +parameter files and environment definitions not kept (see keep) will be +discarded from core. +The same effect may be achieved by typing EOF (control-z on DEC systems). +If used in a script task, it causes the script to abruptly end as though +the end of the script file had been encountered. +Since most packages are defined in scripts that do the cl directive, bye +often has the effect of exiting from an entire package (see cl). +.NH 2 +\fBcache \fIlt [, lt2, ...]\fR +.PP +Read the parameter file for each given logical task(s) into the dictionary. +They will remain in core until the current task exits (see bye). This is useful +before running a task repetitively to reduce the file i/o required to +bring in and possibly update the task's parameter file each time it runs. +.NH 2 +\fBcl\fR +.PP +Run the cl itself as a task. This is generally useful in script tasks to +stop the script midstream and allow terminal interaction again. The script +might start with a package declaration, make some set and task declarations +then do "cl()". This would cause the cl to run as a subtask to the script task +and allow user interaction, with the new package and tasks. When the cl +sees bye or EOF, the script task resumes, doing whatever cleanup it desires +and exits, taking the new package, tasks and other dictionary changes with it. +Other uses of the cl directive are to run script tasks. Since its input can +be redirected, as with any other task, "cl < file" is a way to run a script +file. Note: just where the cl gets its input when run without arguments is still +being discussed but the above description, as far as it goes, should not +change. +.NH 2 +\fBkeep\fR +.PP +Cause all currently defined tasks and packages and any cached parameter files +to remain in core when the current task ends. Normally, all dictionary space +used by a task is discarded when the task ends. +If any further dictionary changes are made, they will be discarded +as keep only retains what was defined at the instant it is used. +Keep only effects the current task. When the task from which the current task +was called ends, the kept dictionary space will be discarded unless keep +was called in the prior task as well. +.NH 2 +\fBlparam\fP \fIlt [, lt2, ...]\fR +.PP +List all parameters for the given logical task(s), if any. The name, current +value, and prompt string is given for each, one per line. The parameters are +given in the order in which they should be used as positional arguments in +commands. Hidden parameters are listed at the end, surrounded by parentheses. +.NH 2 +\fBpackage\fP \fIpackname\fR +.PP +Create a new package with the given name. The parameter file associated with +the current task, if any, is associated with the package and becomes the +package's parameter file. All later task declarations will go into this +package. A package declaration normally occurs in a script +task, which creates the package and defines are tasks therein. +If the package already exists, an error is indicated. +.PP +As an aside, if the name of an existing package is itself given as a command, +then it is pushed and run as a kind of task; nothing is changed in the +dictionary. Bye or EOF will pop this pseudotask and return the current package +setting to its previous state. This is useful for temporarily changing the +search path for commands when a few commands in a package are needed without +having to worry about tasks with the same name in other packages being found +instead (see \(sc2.2). +.NH 2 +\fBredefine\fP \fI[lt1, lt2, ...] lt \(eq pt\fR +.PP +Exactly like the task directive except that redefinitions are allowed. +A warning message is still issued, however, if a redefinition does occur. +.NH 2 +\fBset\fP \fI[name \(eq value]\fR +.PP +Make a new, or redefines an existing, environment entry. If given +without arguments, all current entries are simply listed, one per line. +Entries are made in the dictionary so are subject to the same rules as +other dictionary objects, that is, entries are discarded when the task +that does the set ends unless it uses keep. +New entries are always made at the top of the list. Since searching also +starts at the top, a second entry with the same name as an existing one will +make the first entry inaccessible. +An attempt is made to merge the environment facilities of the host +operating system with the entries managed by set. Examples are given in +the environment discussion. +.NH 2 +\fBtask\fP \fI[lt1, lt2, ...] lt \(eq pt\fR +.PP +Define the logical task(s) found in the given physical task. +All entries are made in the current package. +Pt is the name of the physical task file. It may be in terms of +environmental directories or, if quoted, may be given in host-dependent form. +If it ends in ".cl", the file is assumed to be a script written in the CL +language. +.PP +The logical tasks, lt1, lt2 and so on are the logical tasks that can be +run from the physical task. At least one must be given. If the logical task +name is prepended with a dollar, $, then no parameter file is to be associated +with that task. If a newly declared logical task redefines an existing one +in the current package, an error message is issued and the entry will not +be made. Other logical tasks that do not conflict will still be entered, +however. It is not an error to reference a physical task in more than one +task command. +.NH 2 +\fBupdate\fP \fIlt [, lt2, ...]\fR +.PP +Cause the in-core parameter file for the given task(s) to be written out. +This is used in conjunction with cache to force an update of a parameter +file before the current task ends. It may also be used to force an update +of a parameter file that would not otherwise be updated, that is, when learn +mode is not effect. +.NH 2 +\fBversion\fR +.PP +Give the current version number of the CL. The current implementation gives +the time at which the program was built. The "version" of the CL for the +near future is always considered to be 1.2. +.NH 2 +\fB?\fP and \fB??\fR +.PP +The "?" command gives the names of all the logical tasks defined in the current +package. The format is an indented, multicolumn block. Entries are read +left-to-right top-to-bottom in the order in which they are searched (opposite +of the order they were declared). +The "??" command is similar but includes all packages. +Packages and tasks that lie above the current package, +and are thus not immediately accessible, are given in parentheses. + +.NH +CL Parameters +.PP +Some of the parameters belonging to the CL logical task itself have special +significance. Many of them have been mentioned elsewhere. These parameters +behave according to all the usual rules but they are used internally by the CL +or by utility tasks to specify options. All the CL parameters may be viewed +with "lparam cl". CL parameters not included in the following list are provided +as handy scratch variables. Other parameters will be added as time goes on. +.sp +.RS +.TS +; +ci ci ci +l l l. +param type usage +.sp +abbreviations boolean enables abbreviations +keeplog boolean enables command logging +logfile filename name of logging file +menus boolean automatically do a "?" when changing packages +mode string sets mode of CL task +.TE +.RE + +.NH +An Example +.PP +This is a complete example of a package, \fBcoord\fP, written for the CL +environment. The package contains two logical tasks, \fBairmass\fP and +\fBprecession\fP. +Airmass accepts \fBelevation\fP and \fBscale\fP and computes airmass. +The result is printed and saved in a parameter \fBairmass\fP. +Precession computes the precession between any two years, \fByear1\fP and +\fByear2\fP. The ra and dec for year1 are read from the standard input and the +precessed coordinates to year2 are written to the standard output. +These two logical tasks are +written in the SPP language and are defined in the single physical +task, \fBcoord.x\fP. +.PP +The following are examples of actual running programs. The name of the +files in each case is given in boldface and is not part of the files. +Numerous other examples can be found in the source directories for the +IRAF system. +.PP +The login.cl file (see \(sc11) defines the logical task \fBcoord\fP +as the script task \fBcoord.cl\fP in its own directory. + +.sp +file \fBlogin.cl\fP: +.sp +.DS L +.cs 1 22 +# When the CL starts up, it looks for a "login.cl" file in the +# current directory. The login file should contain any commands +# or declarations which one wants executed upon startup. A KEEP +# or CL command must be executed after the declarations section +# or the new definitions will go away. + +# The logical directory uparm, if defined, is where the CL will +# save updated parameter files. Other IRAF system routines also +# use this directory to store user-specific database files. + +set uparm \(eq "/usr/jacoby/iraf/tasks/param/" +task $coord \(eq "/usr/jacoby/iraf/tasks/coord/coord.cl" + +keep # keep additions to dictionary when login.cl terminates +.DE +.cs 1 + + +file \fBcoord.cl\fP: + +.DS L +.cs 1 22 +# CL script task to define and run the "coord" coordinate tool +# package. When this script task runs, it defines the package +# "coord", the package directory "codir", and the two logical +# tasks comprising the package, AIRMASS and PRECESS. The task +# CL is called to process commands from the user. When CL +# terminates, COORD will also terminate (since there are no more +# commands in the file), causing the package and its contents to +# become undefined. + +package coord + +set codir \(eq "/usr/jacoby/iraf/tasks/coord/" +task airmass, precess \(eq codir$coord + +cl() +.DE +.cs 1 + +file \fBairmass.par\fP: + +.DS L +.cs 1 22 +# Parameters for logical task AIRMASS. + +elevation,r,a,1.5708,0.,1.5708,elevation angle in radians +scale,r,h,750.,,,scale height +airmass,r,h,1.,,,computed airmass +.DE +.cs 1 + +file \fBprecess.par\fP: + +.DS L +.cs 1 22 +# Parameters for logical task PRECESS. + +year1,r,h,1950,,,year from which coordinates are to be precessed +year2,r,a,1982.9,,,year to which coordinates are to be precessed +.DE +.cs 1 + + +.bp +file \fBcoord.x\fP: + +.DS L +.cs 1 22 +# This file is written in the SPP language, which implements a +# subset of the planned IRAF scientific programming language. + +# Define CL-callable tasks. +task airmass, precess \(eq precess\(ulcoords + + +# AIRMASS -- Airmass calculation utility. Airmass formulation +# from Allen "Astrophysical Quantities" 1973, p. 125, 133. +# +# The logical task airmass has three parameters: +# elevation angular height above horizon +# scale scale height of atmosphere +# airmass calculated air mass + +procedure airmass() + +real elevation, scale, airmass, x # local variables +real clgetr() # functions + +begin + # Get type-real parameters "elevation" and "scale" from CL. + elevation \(eq clgetr ("elevation") + scale \(eq clgetr ("scale") + + # Compute the airmass, given the elevation and scale. + x \(eq scale \(** sin (elevation) + airmass \(eq sqrt (x\(**\(**2 + 2 \(** scale + 1) \(mi x + + # Print result on the standard output, and output the + # computed air mass to the CL parameter "airmass". + + call printf ("airmass: %10.3f\\\\n") + call pargr (airmass) + call clputr ("airmass", airmass) +end +.DE +.cs 1 + + +.DS L +.cs 1 22 +# PRECESS_COORDS -- Precess coordinates from year1 to year2. +# This task is a filter, which reads coordinate pairs from the +# standard input, performs the precession, and outputs the +# precessed coordinates on the standard output. +.DE +.cs 1 + + +.DS L +.cs 1 22 +procedure precess\(ulcoords() + +real default\(ulyear1, year1 # year to precess from +real default\(ulyear2, year2 # year to precess to +double ra1, dec1 # input coordinates +double ra2, dec2 # precessed coordinates +int fscan(), nscan() # formatted input functions +real clgetr() # get real parameter function + +begin + # Get the default "year" parameters from the CL. + default\(ulyear1 \(eq clgetr ("year1") + default\(ulyear2 \(eq clgetr ("year2") + + # Read and precess coordinate pairs from the standard input + # until EOF is detected. Format "ra dec [year1 [year2 ]]". + + while (fscan (STDIN) !\(eq EOF) { + call gargd (ra1) + call gargd (dec1) + call gargr (year1) + call gargr (year2) + + if (nscan() \(eq\(eq 3) # no year2 given + year2 \(eq default\(ulyear2 + else if (nscan() \(eq\(eq 2) # no year1 given + year1 \(eq default\(ulyear1 + else if (nscan() < 2) { + call fprintf (STDERR, "invalid coordinates\\\\n") + next # do next iteration + } + + # Call precession subprogram to precess the coordinates, + # print result on standard output (hms hms yyyy.y). + + call precess (ra1, dec1, ra2, dec2, year1, year2) + call printf ("ra: %12.1h dec: %12.1h %7.1f\\\\n") + call pargd (ra2) + call pargd (dec2) + call pargr (year2) + } +end +.DE +.cs 1 diff --git a/doc/clman_toc.ms b/doc/clman_toc.ms new file mode 100644 index 00000000..134dfb65 --- /dev/null +++ b/doc/clman_toc.ms @@ -0,0 +1,110 @@ + +.RP +.ND +.TL +Contents +.PP +Hi there. +.pn 0 +.bp +.ce +\fBContents\fR +.sp +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBTerminology\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Physical and Logical Tasks, Scripts\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'Packages\l'|5.6i.'\0\02 +.sp +3.\h'|0.4i'\fBParameter Files\fP\l'|5.6i.'\0\03 +.br +\h'|0.4i'3.1.\h'|0.9i'Location and Name of Parameter Files\l'|5.6i.'\0\03 +.br +\h'|0.4i'3.2.\h'|0.9i'Parameter File Format\l'|5.6i.'\0\03 +.br +\h'|0.9i'3.2.1.\h'|1.5i'name\l'|5.6i.'\0\04 +.br +\h'|0.9i'3.2.2.\h'|1.5i'type\l'|5.6i.'\0\04 +.br +\h'|0.9i'3.2.3.\h'|1.5i'mode\l'|5.6i.'\0\04 +.br +\h'|0.9i'3.2.4.\h'|1.5i'value\l'|5.6i.'\0\05 +.br +\h'|0.9i'3.2.5.\h'|1.5i'minimum \fRand\fP maximum\l'|5.6i.'\0\06 +.br +\h'|0.9i'3.2.6.\h'|1.5i'prompt\l'|5.6i.'\0\06 +.sp +4.\h'|0.4i'\fBModes\fP\l'|5.6i.'\0\06 +.br +\h'|0.4i'4.1.\h'|0.9i'Determining Modes\l'|5.6i.'\0\07 +.br +\h'|0.4i'4.2.\h'|0.9i'Setting and Changing Modes\l'|5.6i.'\0\07 +.br +\h'|0.4i'4.3.\h'|0.9i'Recommended Mode Settings\l'|5.6i.'\0\07 +.sp +5.\h'|0.4i'\fBExpressions\fP\l'|5.6i.'\0\08 +.br +\h'|0.4i'5.1.\h'|0.9i'Constants\l'|5.6i.'\0\08 +.br +\h'|0.4i'5.2.\h'|0.9i'Parameter References\l'|5.6i.'\0\08 +.br +\h'|0.4i'5.3.\h'|0.9i'Intrinsic Functions\l'|5.6i.'\0\09 +.br +\h'|0.4i'5.4.\h'|0.9i'Operators\l'|5.6i.'\0\010 +.sp +6.\h'|0.4i'\fBStatements\fP\l'|5.6i.'\0\010 +.br +\h'|0.4i'6.1.\h'|0.9i'Assignment Statement\l'|5.6i.'\0\011 +.br +\h'|0.4i'6.2.\h'|0.9i'Commands\l'|5.6i.'\0\011 +.br +\h'|0.9i'6.2.1.\h'|1.5i'Command Arguments\l'|5.6i.'\0\011 +.br +\h'|0.9i'6.2.2.\h'|1.5i'Pipes and Redirections\l'|5.6i.'\0\012 +.br +\h'|0.4i'6.3.\h'|0.9i'Immediate Statement\l'|5.6i.'\0\012 +.br +\h'|0.4i'6.4.\h'|0.9i'Flow Control\l'|5.6i.'\0\012 +.br +\h'|0.4i'6.5.\h'|0.9i'Abbreviations\l'|5.6i.'\0\013 +.sp +7.\h'|0.4i'\fBEnvironment\fP\l'|5.6i.'\0\013 +.sp +8.\h'|0.4i'\fBLog File\fP\l'|5.6i.'\0\014 +.sp +9.\h'|0.4i'\fBError Handling\fP\l'|5.6i.'\0\014 +.sp +10.\h'|0.4i'\fBCL Initialization\fP\l'|5.6i.'\0\015 +.sp +11.\h'|0.4i'\fBCL Directives\fP\l'|5.6i.'\0\015 +.br +\h'|0.4i'11.1.\h'|0.9i'\fBbye\fR\l'|5.6i.'\0\015 +.br +\h'|0.4i'11.2.\h'|0.9i'\fBcache \fIlt [, lt2, ...]\fR\l'|5.6i.'\0\015 +.br +\h'|0.4i'11.3.\h'|0.9i'\fBcl\fR\l'|5.6i.'\0\015 +.br +\h'|0.4i'11.4.\h'|0.9i'\fBkeep\fR\l'|5.6i.'\0\016 +.br +\h'|0.4i'11.5.\h'|0.9i'\fBlparam\fP \fIlt [, lt2, ...]\fR\l'|5.6i.'\0\016 +.br +\h'|0.4i'11.6.\h'|0.9i'\fBpackage\fP \fIpackname\fR\l'|5.6i.'\0\016 +.br +\h'|0.4i'11.7.\h'|0.9i'\fBredefine\fP \fI[lt1, lt2, ...] lt = pt\fR\l'|5.6i.'\0\016 +.br +\h'|0.4i'11.8.\h'|0.9i'\fBset\fP \fI[name = value]\fR\l'|5.6i.'\0\016 +.br +\h'|0.4i'11.9.\h'|0.9i'\fBtask\fP \fI[lt1, lt2, ...] lt = pt\fR\l'|5.6i.'\0\016 +.br +\h'|0.4i'11.10.\h'|0.9i'\fBupdate\fP \fIlt [, lt2, ...]\fR\l'|5.6i.'\0\017 +.br +\h'|0.4i'11.11.\h'|0.9i'\fBversion\fR\l'|5.6i.'\0\017 +.br +\h'|0.4i'11.12.\h'|0.9i'\fB?\fP and \fB??\fR\l'|5.6i.'\0\017 +.sp +12.\h'|0.4i'\fBCL Parameters\fP\l'|5.6i.'\0\017 +.sp +13.\h'|0.4i'\fBAn Example\fP\l'|5.6i.'\0\017 diff --git a/doc/cluser.ms b/doc/cluser.ms new file mode 100644 index 00000000..264dc21f --- /dev/null +++ b/doc/cluser.ms @@ -0,0 +1,1177 @@ +.RP +.ND +.TL +A User's Guide to the IRAF Command Language +.AU +D. Tody +G. Jacoby +.AI +.K2 "" "" "*" +March 1984 +.AB +This document presents an overview of the IRAF Command language +and how to use it. The discussion is aimed at the first time +user and concentrates on how to execute tasks from the Command +Language. The focus is the Command Language itself, as opposed +to the many packages and tasks comprising the IRAF system, +and on using the command language to run existing programs, +rather than adding new ones of one's own making. +.AE +.bp +.SH +Scope of this Document +.PP +This document is an introduction to the basic features of the IRAF +Command Language (CL), and is not intended to be a complete guide to +using and programming the IRAF system. We concern ourselves here +primarily with the use of the CL to execute commands entered interactively +at the terminal. The first time user rarely needs to do more than enter +commands and run an occasional background job. The IRAF system and +applications packages are described elsewhere; much of the available +documentation is accessible at the terminal via the online \fBhelp\fR facilties. +Programming in the CL or in the IRAF environment is beyond the scope of +this document and is described in the \fICL Programmer's Manual\fR, +the \fIReference Manual for the IRAF Subset Preprocessor Language\fR, +the \fIProgrammer's Crib Sheet\fR, and other documents. +.NH +Introduction +.NH 2 +Function of the Command Language +.PP +The basic function of the command language is to execute external tasks and +manage their parameters. +The CL provides a consistent interface between the user and all applications +programs, giving the user complete control over the parameters, data, and +system resources (graphics devices, etc.) used by IRAF programs. +The CL makes it easy to run individual programs by prompting the user with +the names of the available programs and by prompting for parameters as +necessary when a program is run. +Equally important, the CL provides powerful facilities for connecting +programs together to solve special problems. +.PP +The CL is primarily a \fIcommand\fR language, and only secondarily an +interpreted \fIprogramming\fR language. +To be a good command language, the CL must make +it as easy as possible to enter commands to perform common functions. +To this end the CL provides menus, prompting, minimum match abbreviations, +a concise command syntax for simple commands, parameter defaults, and a +history mechanism for correcting errors and for repeating previous commands +with a minimum of typing. +To be a good programming language the CL must +be reasonably efficient, able to evaluate complex expressions, +compile and run general procedures, and much more. +The present CL is a good command language; as a programming language +it is usable but needs a lot of work. +.PP +.NH 2 +Capabilities of the CL +.PP +Besides fulfilling the basic function of a command language, +the CL is capable of performing the mundane operations of +a desk calculator, evaluating expressions, and some limited +programming functions. These simple features provide a very +powerful means of connecting and interacting with tasks. +This will become more apparent in the later discussion of usage. +.PP +The CL has many features that UNIX users will be familiar with. +For example, the output of any task may be redirected to a file +or to another task. Beware, though, that there are many +differences. The CL and the IRAF system present the user with a +complete environment which is independent of the underlying operating +system. Users running IRAF under VMS, UNIX, AOS, or any other operating +system can type exactly the same commands while in the CL. +.NH +Getting Started +.NH 2 +Setting up the IRAF environment +.PP +A visitor using IRAF at KPNO does not have to do anything special to run IRAF. +Computer support personnel will provide a login on one of the VAX computers +and configure the environment as necessary to run IRAF. Staff members and +long term visitors will already have established themselves on a VAX and will +need to perform a few simple operations before the CL and IRAF can be used +for anything serious. +.PP +An IRAF session begins with entry of the command "\fBcl\fR" to run the CL. +When the CL starts up, it looks for a file called \fBlogin.cl\fR in the +"current" directory. If the CL is run from a directory that does not +contain a login.cl file, it will indeed run and can be used for simple things +like evaluating numerical expressions, but it will not work properly for +all functions. Therefore, decide what directory is to be your IRAF login +directory, and \fIalways run the CL from a properly configured IRAF login +directory\fR. The login directory, once set up, can be used for any number +of sessions. If you wish, you can set up several independent login +directories for working with different types of data. +.RS +.IP [1] +Decide on a login directory and go there. +.IP [2] +Type \fBmkiraf\fR. +.RE +.PP +That is all that is required. In addition, you may wish to edit the +resulting login.cl file and change some of the defaults. +The default login file consists mostly of environment declarations +(\fBset\fR statements) defining directories, devices, and so on. +The use of the environment and the significance of the standard environment +variables are discussed in a later section. +.NH 2 +Starting the CL +.PP +After configuring your IRAF directory, type the command "\fBcl\fP" +to run the command language. After a bit the welcome message +will appear on your terminal, the first or root "menu" of IRAF will be +printed, and the \fBcl>\fP prompt will be issued indicating that the +CL is ready for the first command. +.KS +.TS +center tab(%); +l l l l l. +artdata%digiphot%images%local%softools +astrometry%dtoi%imred%nsurfbrt%system +database%filterphot%language%onedspec%twodspec +dataio%focas%lists%plot%utilities +.TE +.KE +.PP +Everything in the root menu of IRAF is a \fBpackage\fR. +A package is a set of tasks which are logically connected. +For example, the "plot" package contains +an assortment of tasks used to plot things. One can "load" any package +by simply typing its name; loading a package makes the tasks in the package +known to the CL. You must load a package before any of the tasks therein +can be run. +.PP +Once the CL prompt appears, a large number of tasks are available and +ready to be executed. A list of all loaded packages and the tasks in each +package may be obtained by typing the command \fB??\fP. +This will list the tasks organized by package, starting with the "current" +package (note that the system comes up with the \fBclpackage\fR, \fBsystem\fR, +and \fBlanguage\fR packages already loaded). The tasks are listed in the +order in which they are searched when you type a command. +Type \fB?\fP to list only the task names in the current package, +or \fB?\fIpackagename\fR to list the tasks in package "packagename". +.NH 2 +Executing commands from the CL +.PP +At this point you may want to try executing a few simple commands. +The first thing to try is the \fBhelp\fR command. This will give +additional information about the tasks and subpackages in the current package. +In this and all subsequent examples, the text typed by the user is shown +in boldface. +.DS +cl> \fBhelp\fR +.DE +For detailed information about a particular task, type "help" followed +by the name of the task for which help documentation is desired. +For example, +.DS +cl> \fBhelp help\fR +.DE +will print detailed information about the \fBhelp\fR program itself. +.PP +Now let's try running some tasks from the \fBsystem\fR package, which +is already loaded. To list the file "login.cl" on the terminal enter the +following command: +.DS +cl> \fBpage login.cl\fP +.DE +The \fBpage\fR routine will pause at the end of each page of text, +waiting for you to type RETURN before displaying the next page. +To get a directory listing, type: +.DS +cl> \fBdir\fP +.DE +which is actually an abbreviation for "directory". +All package, task, and parameter names may be abbreviated +while working interactively. Any abbreviation may be given which contains +sufficient characters to uniquely identify the name; if the abbreviation +is not unique, an error message is printed. +To list all your files with the ".cl" extension, you can type: +.DS +cl> \fBdir "*.cl"\fP +.DE +Note that the pattern string \fB*.cl\fP \fImust be enclosed in quotes\fR +or you will get a "syntax error" message from the CL. +This is because the CL is attempting to evaluate every command +as a possible aprithmetic expression and the asterisk is a valid +arithmetic operator. +Without the quotes, there is no way of knowing whether an argument to +a task is a string with odd characters or an arithmetic expression. +When in doubt, use quotes around strings and filenames. +Either apostrophes or quotes may be used to delimit strings in the CL. +.PP +Packages are entered the same way tasks are run, +i.e. by merely typing the name of the package or task as a command +(a package is in fact a special kind of task). +Enter the "utilities" package by typing: +.DS +cl> \fButilities\fP +.DE +or just: +.DS +cl> \fBut\fP +.DE +Note also that the prompt has changed from \fBcl>\fP to \fBut>\fP to +let you know you have entered another package, and that +a set of new tasknames is now available to you. +.PP +Upon entry to the \fButilities\fR package you will be presented with a +menu listing the tasks in the new package. One of the utility programs +is the \fBprecess\fR program, used to precess lists of astronomical +coordinates. The simplest way to run \fBprecess\fR is to type only +its name: +.DS +ut> \fBprecess\fP +.DE +and you will be prompted for the name of an input file containing a list +of coordinates to be precessed, and the years over which the +precession is to be computed. If you do not have the coordinates in a +file give the file name as "STDIN" (it must be upper case), and +you can enter the coordinates interactively from the terminal. +Any number of coordinates (input lines from the "file" STDIN) may be entered; +signal the "end of file" by typing the EOF sequence, +\fB\fR on the KPNO systems. +Coordinates are entered in pairs (RA DEC) in either decimal or sexagesimal +notation (i.e., 12.5 or 12:30:04.2). If you have any problems type +\fBhelp precess\fR for additional information, including examples. +.PP +If you have a long list of coordinates to precess, try entering +them into a file. The command +.DS +ut> \fBedit coords.1950\fP +.DE +will call up the default editor (\fBvi\fP on the UNIX systems) to edit the +file "coords.1950". +After creating your coordinate file and exiting the editor in the usual +fashion, you will be back in the CL. Now try executing \fBprecess\fP taking +input from the file: +.DS +ut> \fBprecess coords.1950\fP +.DE +Of course the output will still be placed on the terminal, so +you may wish to redirect the output into a file as well: +.DS +ut> \fBprecess coords.1950, > coords.1984\fP +.DE +Note that \fIarguments must be delimited by commas\fR or you will +get a "syntax error" message from the CL. The following UNIX-like command +will cause a syntax error: +.DS +ut> \fBprecess coords.1950 > coords.1984\fP (illegal syntax) +.DE +.PP +If the coordinate list is very long, you may wish to process +the list as a background job. Probably you will not like to be bothered +by the background task asking for parameters, so be sure to enter +all the necessary parameters on the command line. If you are not +sure what parameters are required or in what order, the fastest way to +find out is to use the "list parameter" task \fBlparam\fR to find out: +.DS +ut> \fBlparam precess\fR +.DE +The \fBlparam\fR task will list the task's parameters in the order in +which they must be given on the command line, showing the current values +of the parameters and the prompt strings as well (more on this later). +To execute the task \fBprecess\fR in the background, type: +.DS +ut> \fBprecess coords.1950, 1950, 1984, > coords.1984 & \fP +.DE +The CL will be available for further interactive use and will +inform you when the background job is complete. +.PP +Now that you are a couple of layers deep into the CL, you may +wonder how to exit. If you type \fBbye\fP, you will exit the current +package and rise one level of loaded packages. If you type \fBbye\fP at the +CL prompt level, you will exit from the CL completely. +.NH +Basic Usage +.NH 2 +CL parameters +.PP +The CL is actually a task and has a set of parameters which +can be used to direct its execution. For example, you may wish +to keep a record of all commands you type. The CL will do this +if you set the boolean parameter \fBkeeplog\fP to yes. (Boolean +parameters can assume only the values yes or no.) Simply type: +.DS +cl> \fBkeeplog = yes\fP +.DE +All subsequent commands will be written to the log file defined by the +string parameter \fBlogfile\fP which defaults to the file name +"uparm$logfile". You may choose to set this file name to "session1", +for example, by: +.DS +cl> \fBlogfile = 'session1'\fP +.DE +For a full list of CL variables type "lparam cl". The CL variables +which affect the behavior of the CL and which you may wish to alter are: +.TS +center box; +cb s s +ci | ci | ci +l | l | l. +CL Parameters +_ +parameter default value function += +abbreviate yes accept abbreviations +keeplog no record commands in a file +logfile "uparm$logfile" log file name +menus yes print menu when package changes +notify yes signal when background job terminates +.TE +.PP +The CL parameters are initialized to their default values in your +\fBlogin.cl\fR file. Any changes made by assignment will be lost when +you log out of the CL (this is not true of the parameters of a normal +task). To permanently change the value of a CL parameter, you should +edit your login.cl file. + +.NH 2 +Environment Variables +.PP +In addition to the CL parameters, which affect only the operation of +the CL, the CL maintains a table of "environment variables" which +affect the operation of all IRAF programs. Environment variables are +created or redefined with the \fBset\fR command; \fBset\fR without +any arguments prints the current list of variables. The environment +list is used to define logical names for directories, to associate +physical devices with logical device names, and to provide control +over the low level functioning of the IRAF file i/o system. +.PP +The default environment list is created at login time, i.e., when the +CL is first run. +One may add new environment variables, or redefine old ones, +at any time during +a session with the \fBset\fR command. Set declarations made during +execution, however, may be lost upon exit from a package. To make +sure environment declarations last for a full session, they should be +made immediately after logging in. To make environment declarations +permanent, they should be placed in your \fBlogin.cl\fR file. +.PP +A selection of the more important environment variables is shown in the +table below. The permissible names of devices are system dependent; +the KPNO devices are "vt100", "vt640" (retrographics enhanced vt100), +"tek4012" or "4012", "versatec", and "imagen". +.TS +center box; +cb s s +ci | ci | ci +l | l | l. +Selected Environment Variables +_ +variable default value usage += +terminal "vt100" default terminal device +printer "imagen" default line printer device +stdgraph "vt640" name of graphics terminal +stdplot "versatec" batch plotter device +stdvdm "uparm$vdm" name of graphics metacode file +stdimage "iism70" image display device +clobber no clobber (overwrite) files +filewait yes wait for busy files to become available +imdir "/tmp2/iraf/" directory where bulk data is stored +.TE +.PP +File \fBclobber\fR refers to the UNIX-like feature of silently +overwriting an existing file when the output file to be created has +the same name. If file clobber is disabled (\fBclobber=no\fR, the default) +neither the CL nor an IRAF program called from the CL will create a new +file if an old file exists with the same name; the program will abort +instead. If \fBfilewait\fR is enabled (\fBfilewait=yes\fR, the default), +a program which cannot access an existing file will wait for it to become +available. This happens when a job needs to write to a file which +is already opened for writing by another job. +.PP +The logical directory \fBimdir\fR is where the IRAF system will store +your image data. IRAF images will appear to be created in your local +user directory, but in fact it is only the header file which goes there. +The pixels are put in a second file on one of the temporary files systems, +which are configured and managed with large datasets in mind. These \fBpixel +storage files\fR are transparent to the user, but if you have a great +deal of data it may be more efficient to set up your own directory on +a temporary files system, and redefine \fBimdir\fR accordingly. +Having a private \fBimdir\fR also makes it convenient to save data on +tape and later restore it to disk; the header files are usually small +enough so that they need not be archived if the data is going to be restored +within a week or two. +.PP +The \fBset\fR statement is used to set environment variables. For example, +to change the name of the graphics terminal from the KPNO default "vt640" +to "tek4012": +.DS +cl> \fBset stdgraph = tek4012\fR +.DE +To change the name of the default printer device from the default "imagen" +to "versatec" (perhaps because it is physically closer to your terminal). +.DS +cl> \fBset printer = versatec\fR +.DE +.PP +The \fBset\fR command is only used to change the \fBsystem wide defaults\fR +for output devices and such. All IRAF programs which write to the line +printer or a graphics device also permit the device to be selected on the +command line. The name of the terminal, and the terminal characteristics +(baud rate, etc.) are most conveniently set with the command \fBstty\fR in +the package \fBsystem\fR. +.NH 2 +File and directory names +.PP +The IRAF system employs a virtual file system so that all file references +will look the same on any computer. The IRAF primitives convert "virtual +file names" into their host operating system equivalents. In general, +either the virtual file name or the equivalent system dependent file name +may be used in a command entered by the user. The IRAF system itself +uses only the virtual form for reasons of transportability. +.PP +The environment list described in the last section plays a fundamental +role in the mapping of virtual file names. The environment list is used +to define logical directories, equating the system dependent name of the +directory to a logical name. An example of a virtual file name is the +default logfile, "uparm$logfile". The "uparm" field, +delimited by the $ character, is the logical directory; the file name +within that directory is "logfile". +.PP +Although file names cannot be abbreviated the way commands can, +pattern matching may be used to refer to many files by typing only a +short string (the pattern). The pattern matching metacharacters are +identical to those used in the UNIX operating system. For example, +to print all files having extensions of '.cl', type: +.DS +cl> \fBlprint '*.cl'\fP +.DE +To page through all files with the "cl" extension in the logical directory +"system": +.DS +cl> \fBpage 'system$*.cl' +.DE +To delete a list of files: +.DS +cl> \fBdelete 'file1,file2,file3' +.DE +.PP +.PP +Note the quotes around the pattern strings; these are required due to the +presence of the asterisk character in the first two examples, and the +comma in the final example. To be more precise, a string need not be +quoted provided [1] it appears as an identifier (a name) in an argument +list not enclosed in parenthesis, and [2] the string contains only instances +of the alphanumeric characters, underscore, period, and dollar sign. +If the string contains any special characters, i.e., an arithmetic or +boolean operator, comma, question mark, etc., it must be quoted. +If in doubt, use quotes (either apostrophes or quotes will do). +.PP +For example, consider the following simple command: +.DS +cl> \fBdelete filex\fR +.DE +The name "filex" given here is actually ambiguous, i.e., it could be either +the name of a file (a string constant) or the name of a string \fIparameter\fR +set to the name of the file to deleted. In this simple and common case, +the CL is will quietly assume that "filex" is the name of a file. +Either of the following forms are equivalent to this command and both are +unambiguous: +.DS +cl> \fBdelete "filex"\fR +.DE +.DS +cl> \fBdelete ("filex")\fR +.DE +The following command is also unambiguous, and specifies that the CL is to +take the name of the file to be deleted from the \fIparameter\fR "filename": +.DS +cl> \fBdelete (filename)\fR +.DE +.PP +Note also that in all the examples, a \fBsingle\fR string type argument, +the file matching template, is used to refer to a list of files. +A template is a string consisting of one or more filenames or patterns +delimited by commas. This convention is employed by all IRAF tasks which +operate on lists of files. Be careful not to confuse a file list template, +which is a string, with the argument list itself. Thus, +.DS +cl> \fBdelete 'file1, file2, prog.*'\fR +.DE +is perfectly acceptable, while +.DS +cl> \fBdelete file, file2, 'prog.*'\fR +.DE +is incorrect. +.PP +Often it is useful to be able to use multiple directories to organize +data. For example, you may have a directory for M87 data, and one for M8. +To print the name of your current directory, or the pathway through the +system to your directory, type +.DS +cl> \fBpath\fP +.DE +The system dependent pathname of the current directory will be printed +(\fBpath\fR is an abbreviation for "system.pathnames"). +To change to a new directory, type: +.DS +cl> \fBchdir \fInewdir\fR +.DE +where \fInewdir\fR is either the name by which the directory is known to the +underlying operating system, or an IRAF logical directory name defined with +a \fBset\fP command. For example to define the logical directory "M87" +on a UNIX based system, execute the following \fBset\fR command (note the +trailing '/'): +.DS +cl> \fBset M87 = "/usr/myname/iraf/M87/" +.DE +and then you may type either of the following commands to change the current +directory to "M87" (note \fIchdir\fR may be abbreviated to \fIch\fR). +.DS +cl> \fBchdir M87\fR +cl> \fBchdir "/usr/myname/iraf/M87" +.DE +.PP +Of course it is not necessary to change to a directory to reference the files +therein. Your login directory, for example, already has the logical name +\fBhome\fR assigned to it. The following command would page the \fBlogin.cl\fR +file in your home directory, regardless of the current directory: +.DS +cl> \fBpage home$login.cl\fR +.DE +.NH 2 +Parameters +.PP +Nearly all tasks have a formally defined set of parameters associated with +them. A task's parameters may be listed with the command +\fBlparam \fItaskname\fR. For example, to list the parameters for the +task \fBdelete\fR, used to delete files: +.DS +cl> \fBlparam delete\fP +.DE +The following list will appear giving the parameter name, its +current value, and the prompt string associated with it. +.DS +.cs 1 18 +.br + files = list of files to be deleted + go_ahead = yes ? + (verify = no) verify operation before deleting each file? +(default_acti = yes) default delete action for verify query + (mode = ql) +.DE +.cs 1 +.PP +Notice that there are two types of parameters, those with and without +parentheses around the \fIparam=value\fR fields. The parameters not +enclosed in parentheses are called \fBpositional parameters\fR, +and will be queried for if not given on the command line. The first +positional parameter will be set by the first "positional" argument on the +command line, the second positional parameter by the second positional argument, +and so on. A \fBpositional argument\fR is an argument which is associated +with a parameter by its position in the command line; nonpositional arguments +refer to parameters by name and must follow the positional arguments. +The parameters enclosed in parentheses are called \fBhidden parameters\fR, +and are the topic of the next section. +.NH 3 +Hidden parameters +.PP +The last three lines in the above example describe additional "hidden" +parameters. The CL does not query for hidden parameters, but automatically +uses the default values. A query will be generated only if there is no +default value, or if the default value is illegal for some reason. +Hidden parameters may be set on the command line, but unlike positional +parameters, the command line value will not be "learned", i.e., become +the new default value. The default value of a hidden parameter may only +be changed by an explicit assigment, and one should exercise caution +in doing so, because it is easy to forget that the parameter has been changed. +.PP +Hidden parameters make it possible to easily change the behavior of a task, +achieving considerable flexibility without requiring many arguments on the +command line, or annoying queries for parameters. Hidden parameters come close +to making it possible to please everybody, since the user can modify the default +behavior of a task to make it do what they want. Hidden parameters can +also be dangerous if they are used improperly (i.e., for data dependent +parameters in scientific programs). +.PP +The \fBdelete\fR task is a good example of a task which it is nice to be +able to personalize. The default behavior of \fBdelete\fR is to simply +delete the named file or files (provided they are not "protected" files). +File deletion is dangerous, particularly since a file name matching +template may be used to delete many files. For example, the command +.DS +cl> \fBdelete '*'\fR +.DE +will delete \fIall\fR of the (unprotected) files in the current directory. +IRAF recognizes a number of special pattern matching metacharacters in +addition to "*", and one could easily get burnt if they were not familiar +with the use of file matching templates. +.PP +To eliminate this possibility you might want to change the default behavior +of \fBdelete\fR to interactively verify each file deletion. This is done +by changing the value of the hidden parameter "verify", which defaults +to \fIno\fR. Hidden parameters of type boolean (yes/no) may be overridden +temporarily on the command line, as follows: +.DS +cl> \fBdelete '*.dat', verify+\fR +.DE +or, equivalently, +.DS +cl> \fBdelete '*.dat', verify=yes +.DE +Either of these commands would cause a prompt to be issued naming +each file matching the template, and asking you if you want to delete +it (this will happen even in batch mode). Setting a hidden parameter +on the command line only overrides the value of that parameter for +that call; the default value is not changed. To permanently change +the default value of a hidden parameter, an explicit assignment is +required: +.DS +cl> \fBdelete.verify = yes\fR +.DE +.PP +This will "permanently" change the value of the "verify" parameter +to yes, causing all subsequent file deletions to be verified, unless +\fBdelete\fR is called with the argument "verify\(mi" or "verify=no" +on the command line. The "permanently" is qualified because it may +be undone by another assignment, or by "unlearning" the \fBdelete\fR +parameters. The \fBunlearn\fR task restores the system default values +of the parameters for a single task or for an entire package. +Thus, +.DS +cl> \fBunlearn delete\fR +.DE +will restore the parameters of the task \fBdelete\fR to their default +values, and +.DS +cl> \fBunlearn system\fR +.DE +will restore the defaults for \fIall of the tasks\fR in the +package "system". If you want to restore the defaults for all the +parameters that ever were, delete the contents of the logical directory +\fBuparm\fR: +.DS +cl> \fBdelete "uparm$*.par"\fR +.DE +.NH 3 +Specifying the parameters to a task +.PP +In many cases, it will be obvious what the arguments to a task +should be, either from the context of what the task does, or +from a parameter listing. If you are unsure how to proceed, +you can simply type the task name, and answer the questions. +Each prompt will include a minimum and maximum acceptable value +if one applies, and the current value of the parameter if +one exists. If you wish to retain the current value, simply +press RETURN. Otherwise, type in a new value. +.PP +Once you are familiar with the operation of a task, you can +enter the parameter values on the command line in the +order in which they appear in the \fBlparam\fR parameter listing. +A command line argument may be any general expression, much like +the arguments to a Fortran subroutine. Parameters may also be +set using the "paramname = value" notation on the command line, +but any positional arguments must be given first. +.PP +For example, the precession task requires a file name (parameter \fIinput\fR), +a starting year (parameter \fIstartyear\fR), and an ending year (parameter +\fIendyear\fR); the latter two parameters specify the interval over +which the coordinate transformation is to occur. +This task can be executed in any of the following ways: +.DS +cl> \fBprecess STDIN,1950,1984\fP +.DE +.DS +cl> \fBprecess stdepoch=1984+i*4\fP +.DE +.DS +cl> \fBprecess\fP +.DE +In the last two cases, the CL will prompt for the missing information. +In the second case, an expression is used to compute the value of the +hidden parameter \fBstdepoch\fR. +Some legal value of the variable 'i' must have been specified previously, +otherwise the CL will ask for that as well. The capability to specify +the values of parameters using expressions is most useful within +\fBwhile\fR loops; this is an advanced topic which will be touched on later. +.NH 2 +Pipes and i/o redirection +.PP +We have already seen how tasks can take their input from either the +terminal or from a file, and send the output to either the terminal +or a file. The capability to change the standard input and output +of a task on the command line is called \fBi/o redirection\fR. The default +standard input and output for a task is the user terminal. +.PP +The \fBpipe\fR syntax is a powerful kind of i/o redirection. +A "pipe" is formed by connecting the output of one task +to the input of another task; an arbitrary number of tasks may be connected +together in this way to form a single pipe command. +UNIX users will already be familiar with the concept and uses of pipes, +but beware that CL pipes differ from UNIX pipes in that the tasks +execute serially rather than concurrently (nothing comes out of the +end of the pipe until all the input has been read in). Note also that +CL queries are not affected by the use of i/o redirection or pipes. +.PP +A simple example of the use of a pipe is redirecting the output of a command +to the line printer. This can be done with i/o redirection as follows. +.DS +cl> \fBhelp help, > tempfile\fR +cl> \fBlprint tempfile\fR +cl> \fBdelete tempfile\fR +.DE +The pipe notation accomplishes the same thing and is far more concise: +.DS +cl> \fBhelp help | lprint\fR +.DE +.PP +For a more sophisticated example of the use of pipes, load the \fBlists\fR +package and try out the following command: +.DS +li> \fB?? | words | match ":",stop+ | sort | table\fR +.DE +This sequence takes the list of menus produced by \fB??\fR, breaks it into +a list of words, filters out the lines that contain the colon character +(the package names), sorts the list, and prints a super menu listing the +tasks in all loaded packages. +.NH 2 +Command Syntax +.PP +The form of a task call is the task name, optionally followed by an +argument list. The argument list may optionally be enclosed in +parenthesis. The argument list consists of a list of expressions +delimited by commas. Simple filename or string arguments appearing +in unparenthesized argument lists need not be quoted (see \(sc3.3). +Any positional arguments must be given first, followed by +"keyword = value" assignments, switches ("param+"), and i/o redirection +assignments ("> file"). The latter three types of arguments may +appear in any order. Commas may be used as placeholders to skip +positional arguments that need not be set, as shown in the following +example: +.DS +cl> \fBtype "coords.1950" | precess ,1950,1984.3\fR +.DE +.PP +The form of a command is not limited to solitary calls to tasks. +For example, several tasks may be called in sequence on a single +command line, using the semicolon character to delimit each call: +.DS +cl> \fBclear; dir\fR +.DE +This command clears the terminal screen, then lists the files in the +current directory. If the command sequence to be executed is too +big to fit on a single line, it can be enclosed in curly brackets: +.DS +.cs 1 18 +cl> \fB{\fR +>>> \fBclear\fR +>>> \fBdirectory\fR +>>> \fBbeep\fR +>>> \fB}\fR +.DE +.cs 1 +An arbitrary number of commands may be entered in this way and executed +as a single unit. The prompt will change to \fB>>>\fR after the first +line to signal that the CL requires more input before it can execute the +command. If an argument list is too large to fit all on one line, +continuation is understood if the last item on a line is a comma, +the "pipe" character ("|"), or an operator (i.e., '+' or '||'). +.DS +.cs 1 18 +cl> \fBgraph "pix[*,5],pix[*,10],pix[*,15]", po+, marker=circle,\fR +>>> \fBxlabel=column, ylabel=intensity, title = "lines 5, 10, and 15"\fR +.DE +.PP +.cs 1 +.NH 2 +Aborting tasks +.PP +Any task may be aborted by typing the interrupt sequence ( on +the KPNO systems). Control will return to the point at which the last +interactive command was entered. When an IRAF program run from the CL +is interrupted, it will usually perform some cleanup functions, deleting +partially written files and so on. If an error (or another interrupt) +should occur during error recovery, the program will issue the following +message: +.DS +PANIC: Error recursion during error recovery +.DE +.PP +A panic abort is usually harmless, but may result in some half-written +dreg files being left behind. +.NH 2 +Background Jobs +.PP +Any command, including multiline commands involving calls to several tasks, +may be executed in the background by appending the character "&" to the +end of the command block. The CL will print out the job number of the +background job and return control to the terminal. Background job numbers +are always small integers in the range 1 to N, where N is the maximum +permissible number of background jobs (typically 3-6). +.DS +cl> \fBcontour 'm92', dev=stdplot &\fR +[1] +cl> +.DE +If the task runs to completion, and if the CL \fBnotify\fR parameter is +set to yes, the message "\fB[1] done\fR" will be printed on your terminal +when the task completes. If the background job writes to the standard +output, and the standard output has not been redirected, the output of +the background job will come out on your terminal mixed in with the output +from whatever else you are doing. +.PP +If sometime during the processing of a background job, the job finds that +it needs to query for a parameter, the message +.DS +[1] stopped waiting for parameter input +.DE +will appear on your terminal. It is not necessary to respond to such a +request immediately; when a convenient point is reached, respond as +follows: +.DS +cl> \fBservice 1\fR +.DE +The prompt string from the background job will be printed, just as if +you were running the job interactively. Respond to the query and the +background job will continue executing. If you do not respond to the +request for service from a background job, it will eventually time +out and abort. +.PP +The \fBkill\fR command may be used to abort a background job. The argument +is the logical job number printed by the CL when the background job +was spawned (or a list of jobs to be killed): +.DS +cl> \fBkill 1\fR +.DE +Sometimes it is desirable to wait for a background job to complete before +resuming interactive work. For example, you might reach a point where +you cannot proceed until the background job has finished writing a file. +The \fBwait\fR command is used to wait for \fIall\fR currently running +background tasks to complete (this is a deficiency which will be corrected +at some point): +.DS +cl> \fBwait; beep\fR +.DE +.PP +There is at present no really nice way to get status on the progress of +background jobs. The command "\fBspy v\fR" will command the host +operating system to print +the processor status (in a system dependent form), including information +on the status of all running processes. +.NH 2 +Sending commands to the host operating system +.PP +Sometimes it is necessary to send a command to the host operating system. +Any command may be sent to the underlying operating system by prefacing +the command with the escape character "!". The rest of the command line +will be passed on unmodified. For example, to read your mail on a UNIX +system, +.DS +\fBcl> !mail\fR +.DE +Upon exiting the mail routine, you will be back in the CL. +.NH +Advanced Usage +.NH 2 +The History mechanism +.PP +The CL \fBhistory mechanism\fR keeps a record of recent commands and provides +a way of reusing those commands to enter new commands with a minimum of +typing. In particular, the last command entered can easily be edited to +correct an error, without having to retype the entire command. +The history mechanism should not be confused with the logfile; the history +mechanism does not permanently record commands, and the logfile cannot +be used to save typing. +.PP +The \fBhistory\fR command is used to display the last few commands entered: +.DS +.cs 1 18 +cl> \fBhistory\fR +101 urand 200,2 | graph po+, marker=circle, szmarker=.03 +102 help graph | lprint +103 history +cl> +.DE +.cs 1 +By default, the last 15 commands entered are printed, each preceeded by +the command number. To print the last N commands, add the argument N to +the \fBhistory\fR command line; this will become the new default (-N will +not change the default). +.PP +Given the history record sequence shown above, any of the following +commands could be used to repeat command 101: +.DS +cl> \fB^101\fR +.DE +.DS +cl> \fB^-3\fR +.DE +.DS +cl> \fB^ur\fR +.DE +.DS +cl> \fB^?mark?\fR +.DE +.PP +The history command \fB^ur\fR finds the last command \fIbeginning\fR with the +string "ur", and executes it. The command \fB?mark?\fR finds the last +command \fIcontaining\fR the string "mark", and executes it (the trailing +? is optional if it is the last character on the line). +A \fB^\fR alone would merely repeat the last command entered. +The recalled command will be echoed for verification. +.PP +Repeating a command in this fashion can be dangerous, of course, if you +make an error and recall the wrong command (watch out for \fB^delete\fR). +To play it safe, append the string \fB:p\fR to the history command: +.DS +cl> \fB^ur:p\fR +urand 200,2 | graph po+, marker=circle, szmarker=.03 +cl> +.DE +This will recall the command and enter it as the most recent command in +the history buffer, but will not execute it. One can then type \fB^\fR +to execute the command. Often it is more useful to recall an old command +and edit it slightly. This is done as follows: +.DS +.cs 1 18 +cl> \fB^ur:p\fR +urand 200,2 | graph po+, marker=circle, szmarker=.03 +cl> \fB^circle^box\fR +urand 200,2 | graph po+, marker=box, szmarker=.03 +.DE +.cs 1 +This sequence would recall command 101, change the string "circle" to +"box", and execute the new command. The same notation may be used to +correct errors in the last command entered. By default, only the first +matched substring is replaced; a trailing \fB^g\fR may be added to replace +all matched substrings. +.PP +Often it is useful to be able to reuse the \fBarguments\fR of a previous +command. The notation \fB^^\fR refers to the first argument in +of the last command entered, \fB^$\fR to the last argument of the last +command, and \fB^*\fR to the whole argument list. Thus, +.DS +cl> \fBdir "file1, file2, *.cl, home$junk", op=l\fR +cl> \fBlprint ^^\fR +.DE +would print a long-form directory listing of the files specified by the +template, then print the same files on the line printer. +.PP +One of the most useful features of the history mechanism is the ability to +repeat a command with additional arguments appended. Almost any +history command may be followed by some extra text which is appended to the +command recalled from the history. For example, +.DS +cl> \fBurand 200,2 | graph po+\fR +cl> \fB^^, title = "200 random numbers"\fR +urand 200,2 | graph po+, title = "200 random numbers" +.DE +In this case the notation \fB^^\fR refers to the \fIentire last command\fR +entered. The notation is unambiguous because the \fB^^\fR appears at +the start of the command line; do not confuse it with the use of \fB^^\fR +to reference the first argument. +.NH 2 +Expressions and intrinsic functions +.PP +We have already seem some simple examples of CL expressions. The CL has a +conventional modern expression syntax which should be familiar to most +users. The following operators are provided: +.DS +.cs 1 18 ++ \(mi * / the conventional arithmetic operators +** exponentiation +// string concatenation +< < = less than, less than or equals +> > = greater than, greater than or equals +!= = = not equal, equal (2 equal signs) +&& || \fBand\fR, \fBor\fR +! \fBnot\fR +.DE +.cs 1 +.PP +Parenthesis may be used to alter the default order of evaluation of an +expression. Quotes are not optional in expressions or anywhere inside +parenthesis; identifiers are assumed to be the names of parameters. +.PP +All of the Fortran intrinsic functions are provided, with the exception +of the hyperbolic and complex functions (the CL has no complex datatype). +The datatypes supported by the CL are \fBboolean\fR, \fBinteger\fR, \fBreal\fR, +\fBstring\fR, and several exotic types discussed in the Programmer's Guide. +Mixed mode expressions involving integers and reals are permitted. +Explicit type conversion is implemented with the intrinsic functions +\fBint\fR, \fBreal\fR, and \fBstr\fR, the latter converting an argument +of any datatype into a string. +.PP +The CL provides a special type of statement for evaluating expressions +and printing the value out on the terminal. The form of the statement +is an expression preceeded by the equals sign: +.DS += \fIexpression\fR +.DE +If you prefer, the more conventional and more general \fBprint\fR statement +can be used with the same results: +.DS +\fBprint (\fIexpression [, expression, ...] \fB)\fR +.DE +For example, try entering the following expressions and see if you +can predict the results: +.DS +cl> \fB= (sin(.5)**2 + cos(.5)**2)\fR +.DE +.DS +cl> \fB= (mod (int(4.9), 2) == 0)\fR +cl> \fB^int^nint\fR +.DE +.DS +cl> \fB= "map" // radix (512, 8)\fR +.DE +.DS +cl> \fB= delete.verify\fR +.DE +.NH 2 +Image Sections +.PP +All IRAF programs which operate upon images may be used to operate on +the entire image (the default) or any \fBsection\fR of the image. +A special notation is used to specify image sections. The section +notation is appended to the file name of the image, much like an +array subscript is appended to an array name in a conventional programming +language. If no section is specified, the entire image will be used. + +.KS +.TS +center; +ci ci +l l. +section refers to + +pix[] whole image +pix[i,j] the pixel value (scalar) at [i,j] +pix[*,*] whole image, two dimensions +pix[*,\(mi*] flip y-axis +pix[*,*,b] band B of three dimensional image +pix[*,*:s] subsample in y by S +pix[*,l] line L of image +pix[c,*] column C of image +pix[i1:i2,j1:j2] subraster of image +pix[i1:i2:sx,j1:j2:sy] subraster with subsampling +.TE +.KE + +.PP +A limited class of coordinate transformations may be specified using image +sections (but transpose is \fInot\fR one of them). +The "match all" (asterisk), flip, subsample, index, and range notations +shown in the table may be combined just about any way that makes sense. +Some examples have already appeared in the text. As a simple example, +the following command will graph line 10 of the image "pix" (the \fBgraph\fR +utility is in the \fBplot\fR package): +.DS +cl> \fBgraph "pix[*,10]"\fR +.DE +To generate a contour plot of an 800 pixel square, two dimensional image +on the graphics terminal, subsampling by a factor of 16 in both dimensions: +.DS +cl> \fBcontour "pix[*:16,*:16]"\fR +.DE +To display the fifth x,z plane of the three dimensional image named "cube" +on frame 1 of the image display device (\fBdisplay\fR is in the +subpackage \fBtv\fR of the package \fBimages\fR): +.DS +cl> \fBdisplay "cube[*,5,*]", 1\fR +.DE +.NH 2 +Statements and inline scripts +.PP +Since this is not a reference manual, we will not attempt to present a +complete definition of the syntax of the command language. +Nonetheless it can be helpful to understand a few of the more useful +types of statements. The last section introduced two statements, +the \fBimmediate\fR statement (\fI=expr\fR) and the \fBprint\fR statement. +The \fBassignment\fR statement should also be familiar, but there is +more to it than first meets the eye. +.PP +The assignment statement is most often used to set the value of a parameter. +Since most parameters are local parameters belonging to some task, the +"dot" notation must be used to name both the task and the parameter. +Thus, in \(sc3.4.1 we used the statement +.DS +cl> \fBdelete.verify = yes\fR +.DE +to set the value of the "verify" parameter belonging to the task "delete". +The task \fBdelete\fR belongs to the \fBsystem\fR package. If there +happened to be another task named \fBdelete\fR in the searchpath, we +would have to specify the package name as well to make the assignment +unambiguous: +.DS +cl> \fBsystem.delete.verify = yes\fR +.DE +In this unfortunate situation of two tasks with the same name in different +packages, we would also have to specify the package name explicitly +just to be able to run the task: +.DS +cl> \fBsys.del \fIfiles\fR +.DE +.PP +Often we do not want to simply assign a value to a parameter, +but rather we want to increment, decrement, or scale a parameter. +These functions can all be performed with assignment statements +in the CL, using the assignment operators \fB+=\fR, \fB\(mi=\fR, \fB*=\fR, +\fB/=\fR and \fB//=\fR. For example, to increment the value of +a parameter, we would use the \fB+=\fR "assignment" statement: +.DS +cl> \fBsum_of_squares += (x ** 2)\fR +.DE +This statement increments the parameter "sum_of_squares" by the value of +the expression \fB(x**2)\fR. +.PP +The CL provides the \fBif\fR, \fBif else\fR, and \fBwhile\fR statements +for controlling the flow of execution in a command. These statements +are quite useful for writing little loops to do things at the command +level. For example, to print the values of the first ten powers +of two: +.DS +.cs 1 18 +cl> \fBi=1; j=2\fR +cl> \fBwhile (i <= 10) {\fR +>>> \fB print (j)\fR +>>> \fB j *= 2\fR +>>> \fB i += 1\fR +>>> \fB}\fR +.DE +.cs 1 +.PP +This example illustrates the use of the builtin CL variables \fBi\fR +and \fBj\fR. A number of variables are provided in the CL for interactive +use; for a full listing type \fBlparam cl\fR. In short, the integer +variables provided are \fBi,j,k\fR, the real variables are \fBx,y,z\fR, +the string variables are \fBs1,s2,s3\fR, and the booleans are +\fBb1,b2,b3\fR. +.PP +Note the parenthesized argument list in the call to \fBprint\fR in the above +loop. If the parameter \fBj\fR were not enclosed in parenthesis, +the CL would interpret it as a \fIstring\fR rather than a parameter, +and erroneously print "j" each time through the loop. To avoid nasty +surprises like this, \fIalways enclose argument lists in parenthesis in +loops and within scripts\fR. As a rule, if arguments lists are not +parenthesized when entering simple commands, but are always parenthesized +in loops and scripts, the CL will probably do what you expect it to. +.PP +A \fBlist structured\fR parameter is also provided for reading lists +(i.e., of file names). Lists are especially useful for setting up batch +jobs. For example, suppose we want to make a series of contour plots +on the standard plotter device. This can be done by interactively +entering a command to produce each plot, but this is tedious, so +we prepare a list of "image sections" to be plotted, one per line +in the text file "sections". The following command could then be used +to generate the plots in the background: +.DS +.cs 1 18 +cl> \fBlist = "sections"\fR +cl> \fBwhile (fscan (list, s1) != EOF)\fR +>>> \fB contour (s1, device = "stdplot") &\fR +.DE +.cs 1 +.PP +If one starts writing commands very much more complicated than these +examples, it is time to learn about \fBscript tasks\fR. A script task +with an arbitary set of local parameters, calling the i/o functions built +into the CL, can be used to write actual programs at the CL level. +That is too complicated for us to go into here, but there are plenty of +examples of CL scripts tasks (files with ".cl" extensions) in the system, +and more detailed information is given in the CL Programmer's Guide. diff --git a/doc/cluser.tex b/doc/cluser.tex new file mode 100644 index 00000000..cfb028f8 --- /dev/null +++ b/doc/cluser.tex @@ -0,0 +1,5354 @@ +%\pagelayout{normal,twoside} +%\textheight 8in \textwidth 6in\topmargin 0.0in +%\documentstyle{article,11pt} + +\documentstyle[11pt,twoside]{article} + +\setlength{\textheight}{8in} +\setlength{\textwidth}{6in} +\setlength{\topmargin}{0in} +\oddsidemargin 0pt +\evensidemargin 0pt +\hyphenation{pre-sents} +\parskip 4pt + +\begin{document} + +\font \smcaps=amcsc10 +\font \bldcn=ambc12 +\font \eighttt=amtt8 + +\newcommand{\filename}[1]{{\tenrm#1}} +\newcommand{\key}[1]{\fbox{\eighttt#1}} +\newcommand{\emphasize}[1]{{\sl#1\/}} +\newcommand{\irafname}[1]{{\bf#1}} +\newcommand{\taskname}[1]{{\sl#1\/}} +\newcommand{\reference}[1]{{\it#1\/}} +\newcommand{\comptype}[1]{{\tt#1}} +\newcommand{\usertype}[1]{{\bldcn#1}} +\newcommand{\upa}{{\tt \char94}} +\newcommand{\lbox}{{\tt \char91}} +\newcommand{\rbox}{{\tt \char93}} +\newcommand{\bsl}{{\tt \char92}} +\newcommand{\pipe}{{\tt |\ }} +\newcommand{\pluseq}{$+\!=$} +\newcommand{\minuseq}{$-\!=$} +\newcommand{\timeseq}{$*\!=$} +\newcommand{\diveq}{$/\!=$} +\newcommand{\concateq}{$//\!=$} +\newcommand{\ppind}{\hspace*{17pt}} + +\begin{titlepage} \vspace*{1.0in} + +\begin{center} \huge +DRAFT\\ \vspace*{0.5in} \large \bf + +A User's Introduction to the IRAF Command Language \\ \medskip +Version 2.3 \\ + +\bigskip + +\smcaps Peter MB Shames\\ +\tenrm Space Telescope Science Institute\\ +\medskip +\smcaps Doug Tody\\ +\tenrm National Optical Astronomy Observatories\\ +\vskip 1cm + +Revised -- \today\\ \vskip 1cm + +\bldcn ABSTRACT\\ \medskip +\end{center} \large + +\begin{quotation} \noindent +This tutorial introduction to the IRAF Command Language +presents an overview of the use and features of the language. +The discussion is aimed toward the first-time +user and describes the execution of tasks from the Command +Language. The focus is the Command Language itself; +the many packages and tasks that compose the IRAF system and the +SDAS packages from STScI are described elsewhere. The emphasis is +on using the Command Language to run existing programs, although +sections are included that describe the addition of new tasks +of one's own making. A quick guide to language features and facilities +and to the suite of reduction and analysis packages currently available +is provided in the Appendices. +\end{quotation} +\end{titlepage} + +\pagestyle{empty} +\newpage +\thispagestyle{empty} + +\begin{center} \vspace*{1in} +\large About the Authors +\end{center} +\vskip 1cm +\rm + +\noindent +Peter Shames is Chief of the Systems Branch at STScI, and along with Jim Rose +and Ethan Schreier, was one of the key persons responsible for the selection +of IRAF as the command language and operating environment for the STScI +Science Data Analysis System (SDAS) in December of 1983. Since that time, +Peter has supervised the VMS/IRAF development effort at STScI, overseeing the +implementation of the VMS/IRAF kernel, the initial port of IRAF to VMS, +and the development of version 2.0 of the IRAF command language. +Peter wrote the original CL User's Guide (version 2.0). + +\vskip 0.5cm +\noindent +Doug Tody is the originator and designer of the IRAF system (including the CL) +and has been Chief Programmer of the IRAF project since the inception of the +project at KPNO (now NOAO) in the fall of 1981. As Chief Programmer, Doug has +written virtually all of the IRAF system software with the exception of the +VMS/IRAF kernel and the original CL 1.0 (which was written by Elwood Downey). +Since 1983 Doug has been head of the IRAF group at NOAO, overseeing the +development of the NOAO science applications software while continuing work +on the IRAF systems software, and coordinating the effort with STScI. + +\newpage +\thispagestyle{empty} + +\begin{center} \vspace*{1in} +\large Acknowledgements +\end{center} +\vskip 1cm +\rm + +\noindent +The authors wish to acknowledge the efforts of the many people who have +contributed so much time, energy, thought and support to the development +of the IRAF system. Foremost among these are the members of the IRAF +development group at NOAO (Lindsey Davis, Suzanne Hammond, George Jacoby, +Dyer Lytle, Steve Rooke, Frank Valdes, and Elwood Downey, with help from +Ed Anderson, Jeannette Barnes, and Richard Wolff) and members of the VMS/IRAF +group at STScI (Tom McGlynn, Jim Rose, Fred Romelfanger, Cliff Stoll, +and Jay Travisano). The sharp editorial eye and sharper pencil of +Chris Biemesderfer have made major contributions to the clarity and style +of this document. + +\vskip 0.3cm +\noindent +The continuing patience and understanding of members of the scientific +staff at both institutions has been essential to the progress that has +so far been achieved. A major software project such as IRAF cannot +be attempted without the cooperation of many individuals, since the +resources required must inevitably place a drain on other activities. +In particular, the support and encouragement of Harvey Butcher, +Garth Illingworth, Buddy Powell, Steve Ridgway and Ethan Schreier has +been invaluable. Mention should also be made of Don Wells, who started +in motion in the latter part of the last decade the process which eventually +led to the creation of the IRAF system. + +\begin{flushright} +Peter Shames \\ +Doug Tody +\end{flushright} + +\clearpage +\pagestyle{myheadings} +\markboth{CL User's Guide (DRAFT)\hspace*{2.1in}} + {\hspace*{2.1in}CL User's Guide (DRAFT)} +\pagenumbering{roman} + +\tableofcontents + +\thispagestyle{empty} +\newpage + +\pagestyle{myheadings} +\markboth{CL User's Guide (DRAFT)\hspace*{2.1in}} + {\hspace*{2.1in}CL User's Guide (DRAFT)} +\pagenumbering{arabic} + +\begin{center} \vspace*{0.5in} \large \bf + +A User's Introduction to the IRAF Command Language \\ \medskip +Version 2.3 \\ + +\bigskip + +\smcaps Peter MB Shames\\ +\tenrm Space Telescope Science Institute\\ +\medskip +\smcaps Douglas Tody\\ +\tenrm National Optical Astronomy Observatories\\ +\vskip 1cm + +\end{center} \rm + +\section*{How to use this book} + +\ppind +This document is an introduction to the IRAF +Command Language (CL), and is designed to be a tutorial +for the first-time user. The examples presented in the text can +(and should) be tried at a terminal. Although this text is +large enough to be a bit daunting at first, it can be tackled +in easy stages, and need not all be read before trying the system. +A basic knowledge of computer systems is assumed. + +The first three chapters form an introductory section +which covers the most basic elements of IRAF. Reading through these, +preferably while seated near a terminal where the examples may be tried +out, is the recommended entry into the IRAF world. The fourth and fifth +chapters deal with the interface between IRAF and the host system, +and with some of the more advanced uses of IRAF for normal data +analysis activities. These chapters will be of use once you are familiar +with the basic environment and the examples here are also designed +to be tried out on a live system. The rest of this document is for the +more adventurous user, who is not happy until he can say \usertype{doit} +and get \irafname{it} done to a turn. Try some of these last examples +when you are ready to customize IRAF for your own particular uses. + +In spite of its size, this document +is not intended to be a complete guide to using and programming +the IRAF system, but is an introduction to many of the functions +of the CL and a quick guide to other sources of more detailed information. +The CL is described as the user's interactive interface to the system, +and simple commands that use the terminal for starting and controlling tasks +and for customizing the environment are presented. +Development of simple functions in the CL are covered briefly here, but +coverage of all the details of programming in the CL or in the +IRAF environment is beyond the scope of this document. +A reasonable amount of documentation is accessible at the terminal via +the online help facilities, which are described here as well. + +More extensive details of the CL may be found in the manual pages for the +\taskname{language} package, in the \reference{CL Programmer's Manual} and +in \reference{The IRAF User's Guide}. +Details of programming in the IRAF system itself are described +in the \reference{Programmer's Crib Sheet for the IRAF Program Interface}, +in the \reference{Reference Manual for the IRAF Subset Preprocessor Language} +and in other documents referred to in the last section of this text, +however, these documents are somewhat dated and most of the documentation +planned for the IRAF programming environment remains to be written. +Documentation in the form of manual pages for the suites of applications +packages being developed at both NOAO and STScI are available both online +and in printed form. + +\section{Introduction} + +\subsection{An Overview of IRAF} + +\ppind +The Image Reduction and Analysis Facility (IRAF) has been designed to +provide a convenient, efficient and yet portable system +for the analysis of images and other classes of data. While the +system has been designed for image data, and for astronomical image data +in particular, it has general facilities that can be applied to many +other classes of data. Some of the functions that are +provided are quite specialized, dealing as they do with the +characteristics of specific instruments, but others are generalized +functions for plotting data, computing statistics, processing lists, and +performing other functions that are common to +data processing tasks in many other fields. + +The runtime IRAF system consists of four basic pieces: + +\begin{itemize} +\item Command Language - which provides the user interface to the system. + +\item Applications Packages - that are the real data analysis algorithms. + +\item Virtual Operating System (VOS) - which is the heart of the portable +system and provides the foundation for all the higher level functions. + +\item Host System Interface (HSI) - the interface between the portable IRAF +system and a particular host system. At the heart of the HSI is the IRAF +\irafname{kernel}, a library of host dependent primitive subroutines that +connects the system independent VOS routines to the host operating system. +Each host system requires a different kernel, hence we speak of the UNIX/IRAF +kernel, VMS/IRAF kernel, and so on. +\end{itemize} + +\noindent +All of these interconnected, yet separable, subsystems +act together to form the IRAF data analysis environment. In +most cases the user need not be further concerned with this structure, +except to understand that the specific part of this structure that +this tutorial addresses is the Command Language or CL. + +IRAF is designed as an open system that can be extended to add +new analysis capabilities, and that can support user customization +of the existing facilities. There are several levels of customization +available, that range from tailoring task parameters to special needs; +through "re-packaging" existing functions into application specific tasks; +and extending to installation of new compiled code tasks in the +environment. There are a variety of facilities provided in IRAF +to assist the user in the creation and installation of such new tasks. +It is not \emphasize{essential} +that all of these functions be performed in the IRAF way, but full +integration of a user task within the IRAF environment can best be +accomplished by using the facilities that are provided. However, +even without the use of the IRAF interfaces, other tasks may be +incorporated into the user's operating environment and +used as if they were part of the distributed system. + +The applications packages and the VOS routines are designed to be +rather stable, and have been coded in the IRAF SPP language for +portability. The kernel layer supports portability across +operating system architectures, and its interface is stable, but +the inner details change as a function of the requirements and +capabilities of the host operating system. The CL is also +rather stable, since it forms the user's interface to the system, +but it is also an area where change is anticipated, as the system evolves +to meet the needs of the users. Because the CL is itself a program +that is supported by the VOS and isolated from the rest of the system +by the VOS, it can be evolved as required without perturbing the other +parts of the system. + +\subsection{Function of the Command Language} + +\ppind +The basic function of the Command Language is to +provide a clean, consistent interface between the user and the various +packages of functions that complete the IRAF environment. +The CL provides an interface between the user and all applications +programs, giving the user complete control over the parameters, data, and +system resources (graphics devices, etc.) used by IRAF programs. +Many features have been incorporated into the CL to provide +on-line support for users, whether they are old hands or new to the system. + +The packages of programs that are provided offer +many of the standard functions for data analysis, and they can +be invoked interactively, one at a time, to perform many common +operations. The execution of these functions is controlled +by various parameters, and users may define their +own values for the parameters as required. IRAF preserves the +last value used, and presents it as the default value upon next +use. Furthermore, there are facilities at several levels to allow +users to assemble existing functions into new tasks that perform +the specific operations on their data sets. This +customization can involve new assemblages of existing functions +or the inclusion of new functions written in the interactive CL +language or in compiled languages. + +The CL will primarily be used as a \emphasize{command} language, +but it is also an interpreted \emphasize{programming} language. +To be a good \emphasize{command} language, the CL must make +it as easy as possible to enter commands that perform common functions. +To this end the CL provides command menus, minimum-match name abbreviations, +parameter prompting and parameter defaults, tutoring on command parameters +and options, and a concise syntax for simple commands. +There is also a history mechanism that supports recall of previous commands +and easy error correction within them. + +A good interactive \emphasize{programming} language must +be reasonably efficient, be able to evaluate complicated expressions, +to compile and run general procedures, and to offer the user an interpreted +environment for investigating his data and exploring the applicable +range of analysis techniques. This version of the CL (Version 2.3) includes +all of the command language features of the earlier versions and makes +major strides in the direction of becoming a powerful interactive +programming language as well, although much remains to be done before the +CL provides a reasonably complete and efficient interpreted programming +environment. + +This may sound complicated at this point, but examples +presented throughout the body of the text will help +clarify the use of the various features. We suggest a first reading of +this introductory section and the next chapter, and then a session at +the terminal, trying out the examples as presented. + +\subsection{Capabilities of the CL} + +\ppind +Besides fulfilling the basic functions of a command language, +the CL is capable of performing as a programmable desk +calculator, evaluating expressions, executing CL script tasks +or external programs, and doing some rather sophisticated +programming functions. These features provide +a means of connecting tasks to build new high level operators. +The user's interaction with newly created tasks appears the same as +interactions with the standard tasks and utility packages, +as will become apparent in the discussions on usage and script tasks. + +The CL has many features familiar to UNIX users in that +I/O redirection, pipes and filters are provided. +The output of any task may be routed to a file (redirection) +or to another task (pipes), and many functions are provided to +perform standard transformations on a variety of data types (filters). +Be aware, however, that there are many differences between the CL +and the UNIX command interpreters. +The CL and the IRAF system present the user with a +complete data analysis environment which is independent of the underlying +operating system. Users running IRAF under UNIX, VMS, AOS, or some +other operating system have the same analysis environment available +to them and can type exactly the same commands while in the CL. + +The CL supports an open environment in which packages of application +specific tasks may be created and run. Some of these packages +have been prepared by the developers to provide a variety of utility +services, others that deal with specific instruments and analytic +techniques are being made available, +and still others can be created by you, to support your +own view of the data analysis process. Beyond this, mechanisms exist +that allow compiled external programs to be inserted in the system in +such a way that they appear (and act) as an intrinsic part of IRAF. +It is this open-ended nature that makes IRAF so powerful in its +support of a variety of analysis activities. + +\newpage +\section{Getting Started} +\subsection{Setting up the IRAF environment} + +\ppind +A visitor wishing to use IRAF does not need to take any special +action to do so. +Computer support personnel will provide an account on one of the analysis +computers and configure the environment as necessary to run IRAF. +Staff members and long term visitors will already have established +themselves with an account and will only need to perform a few simple +operations before the CL and IRAF can be used. \footnote{ {\bf VMS :} The +command {\eighttt IRAF} must be entered to define system symbolic names. +This command can be entered at the terminal or stored in your VMS LOGIN.COM +file; it must be present in the LOGIN.COM file for queued IRAF background +jobs to startup correctly.} +After this has been done, all of the other +commands referenced within this document will be available. + +An interactive IRAF session begins with entry of the command +\usertype{cl} to run the CL. +When the CL starts up, it looks for a file called \filename{LOGIN.CL} in the +user's current directory. If this directory does not contain a +\filename{LOGIN.CL} file, the CL will function for simple things +such as the evaluation of numerical expressions, but will not work +properly for all functions. Therefore, you should always run the CL +from a properly configured IRAF login directory. +This directory needs to be initialized for IRAF before the +CL is invoked; you can use the \usertype{mkiraf} command to setup the +IRAF environment. The login directory, once set up, can be used for any number +of sessions, and if you wish, you can set up several independent login +directories and data directories for working with different types of data. + +\noindent +Summarizing the steps required to set up the IRAF environment: + +\begin{enumerate} +\item Decide on a login directory. +\item Go there. +\item Type \usertype{mkiraf}. +\end{enumerate} + +\noindent +That is all that is required. The \usertype{mkiraf} command performs +several actions, the most important of which are making a +\filename{LOGIN.CL} file which you may wish to edit to change defaults, +and the creation of a \filename{UPARM} subdirectory, which is used +by IRAF to store your customized parameter sets. +The default login file consists mostly of environment declarations +(\usertype{set} statements) that define directories, devices, and so on. +The function of the environment and the significance of the +standard \irafname{environment variables} are discussed in \S 4.2. + +The \usertype{mkiraf} command can be entered at any time to reinitialize +the environment, i.e., create a new \filename{LOGIN.CL} from the system +default and clear the \filename{UPARM} directory. This is recommended +periodically to pick up any recent changes in the system, and may be +required when a major new release of the system is installed. + +\subsection{Starting the CL} + +\ppind +After configuring your IRAF directory, type the command \usertype{cl} +to start the command language. After a bit the welcome message +will appear on your terminal, and the first or root ``menu'' of IRAF will +be displayed. This menu gives the names of the packages available through +the CL. The \comptype{cl>} prompt will be issued indicating that the +CL is ready to accept commands. + +\begin{quotation} +\begin{center} +\comptype{Welcome to the IRAF.}\\ +\smallskip +\end{center} +\begin{verbatim} + dataio images lists noao sdas system + dbms language local plot softools utilities +\end{verbatim} +\comptype{cl>} +\end{quotation} + +Everything shown in the root menu of IRAF is a \irafname{package} name. +A package is a set of \irafname{tasks} that are logically connected. +For example, the \taskname{plot} package contains an assortment of +general plotting tasks. You must \emphasize{load} a package before any of the +tasks therein can be run; you can load any package by simply typing its name. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{plot} +\end{quotation} + +\noindent +would load the plot package and make the tasks in the package known to the CL. +To unload the current package type \taskname{bye}; this frees any system +resources used by the loaded package and restores the CL to state it was in +before the package was loaded. +Note that the system comes up with the \taskname{clpackage, system, language} +and the default \taskname{user} packages already loaded (the \taskname{user} +package allows the user to personalize the system, and is discussed in \S 5.6). + +A comment should be made at this point about case sensitivity in IRAF. +The CL accepts input in both upper +and lower case, and distinguishes between them, i.e. a \usertype{'Y'} is +different from a \usertype{'y'}. All command names are purposely +specified in lower case, which is the default, and all user responses +are expected to be in lower case as well. Upper case or mixed case +names and commands are possible, but should be used with care. + +Once the \comptype{cl>} prompt appears, many tasks will be available and +ready for execution. A list of all loaded packages and the tasks in each +package may be obtained by typing two question marks (\usertype{??}). +This will list the tasks organized by package, starting with the current +package. The packages are listed in the +order in which they are searched when you type a command. Type one question +mark (\usertype{?}) to list only the task names in the current package, +or \usertype{?{\it packagename}} to list the tasks in +package ``packagename''. + +\subsection{Executing commands from the CL} + +\ppind +At this point you may want to try executing a few simple commands. +First try the \usertype{help} command. This will give additional +information about the tasks in the current package. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{help} +\end{quotation} + +For detailed information about a particular package or task, type +\usertype{help} followed by the name of the package or task for which help +documentation is desired. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{help system} +\end{quotation} + +\noindent +will print detailed information about the \taskname{system} package, and + +\begin{quotation}\noindent +\comptype{cl>} \usertype{help page} +\end{quotation} + +\noindent +will print detailed information about the \taskname{page} task which is +in the \taskname{system} package (after each page of text, the \taskname{help} +program will prompt with a list of keystrokes and pause until you type one +of them). + +Now let's try running some tasks from the \taskname{system} package, which +is already loaded. To display the file \filename{LOGIN.CL} on the terminal, +enter the following command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{page login.cl} +\end{quotation} + +The \taskname{page} routine, like \taskname{help}, will pause at the end of +each page of text, waiting for you to type a command keystroke, e.g., +to display the next page of text, quit, return to the start of the file, +go on to the next file if paging a set of files, and so on (typing \key{?} +in response to the \taskname{page} prompt will cause a summary of the +acceptable keystrokes to be printed). To get a directory listing of the +files in the current directory, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{dir} +\end{quotation} + +\noindent +Observe that all package, task, and parameter names may be abbreviated +while working interactively. Any abbreviation may be given which contains +sufficient characters to identify the name unambiguously; if the +abbreviation is not unique, an error message is displayed. In general +the first two or three characters are enough to identify most commands, +but changes to the operating environment, i.e. loading additional packages, +may require entering more characters or specifying the +\emphasize{packagename} +as a prefix to unambiguously identify the required command. + +To list all your files with the \filename{.CL} extension, you can type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{dir $*$.cl} +\end{quotation} + +As you gain familiarity with the CL you may find that you +cannot remember the IRAF command to do something, but do know the +correct command to use in the native operating system. There is an +\emphasize{escape} mechanism built into IRAF, in that any operating system +specific command may be used by prefixing it with a~\usertype{`!'}. +There are some cautions to be observed that are described in detail +(\S 4.1), but this knowledge may remove one possible source of frustration. +Of course, the CL commands \usertype{`?'} or \usertype{`??'} may also be used +to produce a display of the available package names and functions. + +Packages are loaded the same way tasks are run, viz. merely by typing the name +of the package as a command (a package is in fact a special kind of task). +If the desired package is a subpackage of a package, the main package must +be loaded first. For example, suppose we want to run the \taskname{precess} +task. To find out what package \taskname{precess} is in we run \taskname{help} +on the task \taskname{precess} and observe that the package path (printed at +the top of the help screen) is "noao.astutil". This means that the +\taskname{precess} task is in the \taskname{astutil} package which is in the +\taskname{noao} package, which we recognize as a root level package. + +We load first the \taskname{noao} package and then the \taskname{astutil} +package by typing: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{noao} \\ +\comptype{no>} \usertype{astutil} \\ +\comptype{as>} +\end{quotation} + +\noindent +The set of new tasknames now available to you will be displayed automatically. +Note that the prompt will change from \comptype{cl>} to \comptype{no>} +to \comptype{as>} to let you know you have entered another package. + +One of the astronomical utility programs available is the \taskname{precess} +program, which is used to precess lists of astronomical coordinates. +The simplest way to run \taskname{precess} is to type only its name: + +\begin{quotation}\noindent +\comptype{as>} \usertype{precess} +\end{quotation} + +\noindent +The CL will then prompt you for the parameters it requires to run the program; +in this case, the CL needs the name of an input file containing a list +of coordinates to be precessed and the years over which the +precession is to be computed. If you do not have the coordinates in a +file, give the filename as \filename{STDIN} (it must be upper case), and +you can then enter the coordinates interactively from the terminal. +Any number of coordinates (input lines from the special file \filename{STDIN}) +may be entered; signal the ``end of file'' for \filename{STDIN} by typing +the EOF key, e.g., \key{CTRL/Z}. +\footnote {\key{CTRL/Z} is the standard EOF (end of file) +sequence on VMS and most UNIX systems. Similarly, \key{CTRL/C} is the +standard interrupt key on these systems. For simplicity we use the explicit +control codes to refer to these functions in most of the IRAF documentation, +but the reader should be aware that different control sequences may be used +on the local system and be prepared to make the translations. For example, +the key \key{CTRL/D} is often used to signal EOF instead of \key{CTRL/Z}.} +Coordinates are entered in pairs (RA and DEC, delimited by spaces) in either +decimal or sexagesimal notation (e.g., 12.5 or 12:30:04.2). If you have any +problems type \usertype{help precess} for additional information, including +examples. + +If you have a long list of coordinates to precess, try entering +them into a file. The command: + +\begin{quotation}\noindent +\comptype{as>} \usertype{edit coord1950.txt} +\end{quotation} + +\noindent +will call up the default editor (Vi on UNIX systems; EDT or EMACS on VMS +systems) to edit the file \filename{COORD1950.TXT}. +After creating your coordinate file and exiting the editor in the usual +fashion, you will be back in the CL. Now try executing the \taskname{precess} +program, using the file \filename{COORD1950.TXT} as input: + +\begin{quotation}\noindent +\comptype{as>} \usertype{precess coord1950.txt} +\end{quotation} + +\noindent +Of course, the output will still appear on the terminal, and +you may wish to \irafname{redirect} the output into a file as well: + +\begin{quotation}\noindent +\comptype{as>} \usertype{precess coord1950.txt $>$ coord1984.txt} +\end{quotation} + +If the coordinate list is \emphasize{very} long, you may wish to process +the list as a background job. To avoid interruptions from parameter +prompts by the background task (it will inquire at the terminal), be sure to +enter all the necessary parameters on the command line. +To execute the task \taskname{precess} in the background, type: + +\begin{quotation}\noindent +\comptype{as>} \usertype{precess coord1950.txt 1950 1984 $>$ coord1984.txt \& } +\end{quotation} + +\noindent +The final `\usertype{\&}' tells the CL to run the task in the background. +The two parameters 1950 and 1984 will be passed to the task; you will +not be prompted for them. +Once the background task is started, the CL will be available for +further interactive use and you will be +informed when the background job is complete. The use of background +tasks for batch processing is treated in more detail in \S 5.4. + +\subsection{A Comment on Input and Output} + +\ppind +The notion of output \irafname{redirection} has already been introduced, and the +topics of input redirection (accepting input from a file rather than +the terminal) and \irafname{pipes} (connecting the output from one task to the +input of the next) will be dealt with in \S 3.3. The point to be +made at this time is that \emphasize{all} tasks can be thought of as having +three main I/O paths associated with them: + +\begin{quotation}\noindent +\begin{tabular}{l l} +\filename{STDIN} & the input path \\ +\filename{STDOUT} & the output path \\ +\filename{STDERR} & where error messages appear +\end{tabular} +\end{quotation} + +%\begin{quotation}\noindent +%\begin{description} +%\item[\filename{STDIN}] the input path +%\item[\filename{STDOUT}] the output path +%\item[\filename{STDERR}] where error messages appear +%\end{description} +%\end{quotation} + +\noindent +By default, all of these I/O paths are connected to your terminal +(referred to as \filename{TTY}) and you may redirect any one or all +of them using simple command line requests. The output +\emphasize{redirection} introduced in the previous example of +\taskname{precess} is an example of just such an action. Other +examples in \S 3.3 will cover this topic in more detail. + +There are other standard output streams as well that depend on the +specifics of the task. Not surprisingly, graphics tasks +want to talk to a graphics terminal or other suitable device +(\filename{STDGRAPH}) and image tasks need access to an image display +(\filename{STDIMAGE}). There is a stream for the graphics plotter device as well +(\filename{STDPLOT}). Each of these \emphasize{logical} devices is assigned +to a physical device, either by commands in your \filename{LOGIN.CL} file +or by explicit parameters in the function calls. + +\subsection{The Graceful Exit} + +\ppind +Now that you are a couple of layers deep into the CL, you may wonder +how to get back out again. If you type \usertype{bye}, you will exit the current +package and return one level of loaded packages. You cannot, however, type +\usertype{bye} at the root CL level (\comptype{cl>} prompt). +The command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{logout} +\end{quotation} + +\noindent +may be used to exit directly from the CL at any level. +The \usertype{bye} command or the \key{CTRL/Z} sequence that signals +EOF will exit from any task except the CL itself. This is to +prevent an unintended \emphasize{logout} from occuring if a series +of EOF's are entered from the terminal. + +For a less gentle departure from function execution, the interrupt +sequence \key{CTRL/C} may be used at any level. +This will usually terminate any task that appears to +be hung or is operating in error, but will normally put you +back in the CL in interactive mode. + +\newpage +\section{Basic Usage} + +\ppind +The CL can be used as both a command language and a programming language, +but most first-time users (and many experienced ones) will mostly +use the command features of the language. Commands to the CL may be +entered at the terminal, one at a time, or they may be read in from +a script file; in either case the syntax is the same and abbreviation +of command names and variable names is supported. When the CL is +being used for programming the rules are more restrictive, and +full name specification is required, as is a more formal specification +of task parameters. During the early sections of this document +only the command forms will be used for simplicity. +Parameters to a task may be specified on the command line for brevity, +and prompting is automatically enabled for any required parameters that +are not specified or that are given values that are out of range. + +\subsection{Command Syntax} + +\ppind +The form of a command that calls an IRAF task is the +\emphasize{task name}, optionally followed by an +\emphasize{argument list}. The argument +list consists of a list of \emphasize{expressions} delimited by spaces. +Simple filenames or string arguments that appear in the unparenthesized +argument list need not be quoted, but any string that contains an +embedded blank or other special characters should be quoted. +\emphasize{Positional} arguments (typically the first few +arguments \emphasize{required} for a function must be given first and +in order. +All of these may be followed by \emphasize{param = value} keyword assignments, +\emphasize{param$\pm$} switches, and \emphasize{file} I/O redirection +assignments. These last three types of arguments may appear in any order. +In general, the form is as follows : + +\begin{quotation}\noindent +\begin{tabular}{lll} +\comptype{cl>} {\it taskname} [{\it expression} $\ldots$ ] & + [{\it param=value}] & [$<${\it filename}] \\ + & [{\it param}$\pm$] & [$>${\it filename}] \\ + & & [$>>${\it filename}] \\ + & & [$>\&${\it filename}] +\end{tabular} +\end{quotation} + +\noindent +Any or all of these types of parameters may be present +and defaults are provided for most parameters. +In particular, the only parameters that +\emphasize{must} be set are the \irafname{required parameters} +and if these are not specified on the command line, the CL will prompt +for them. Other parameters and switch values are defaulted, but may be +overridden if desired. +The I/O streams typically default to the login terminal, but the +redirection operators may be used to request: input from a file +(\usertype{$<$}); output to a file(\usertype{$>$}); appending to +a file (\usertype{$>>$}); or redirecting the standard output and the +standard error stream to a file (\usertype{$>$\&}). + +The form of a command line need not be limited to a solitary call to a task. +Several tasks may be called in sequence on a single command +line, using the semicolon character `;' to delimit each call: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{clear; dir} +\end{quotation} + +\newpage +\noindent +If the command sequence is too long to fit on a single line, it can be +enclosed in braces: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{\{ } \\ +\comptype{>>>} \usertype{clear} \\ +\comptype{>>>} \usertype{directory} \\ +\comptype{>>>} \usertype{beep} \\ +\comptype{>>>} \usertype{\} } +\end{quotation} + +\noindent +Note that the prompt changes to \comptype{>>>} after the first +line to signal that the CL requires more input before it will execute the +task. (In this particular example, the CL is waiting for a `\}'.) + +Such a construct is called a \irafname{compound statement} and may be +used to aggregate several simple commands into a single new command. +Compound statements may be used directly from the terminal (or within +scripts as we shall see later) and will be treated as a single +entity by the display and editing commands. +An arbitrary number of commands may be entered in a compound statement +and then executed as a single unit. + +Commands may be strung together in another way too, by use of the +pipe notation, which requests that the output of one command +be used as the input to the next. Creation of the temporary files that +support this, and connection of the task logical I/O paths to these +files is handled automatically by IRAF. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{type coord1950.txt \pipe precess 1950 1984} +\end{quotation} + +\noindent +The pipe symbol `{\tt |}' directs the CL to feed the output of +one task (\usertype{type}) to the input of the next (\usertype{precess}). + +\noindent +If an argument list is too long to fit on one line, +continuation is understood if the last item on a line is a backslash +`$\backslash$', the pipe symbol, or an operator (e.g., `$+$' or `{\tt //}'). + +\begin{quotation}\noindent +\comptype{pl>} \usertype{graph "pix[*,5],pix[*,10],pix[*,15]" po$+$ + marker=circle \bsl } \\ +\comptype{>>>} \usertype{xlabel=column ylabel=intensity \bsl } \\ +\comptype{>>>} \usertype{title = "lines 5, 10, and 15"} +\end{quotation} + +Quotes \emphasize{may} be used around +any string of characters, but are generally not required on commands +entered at the terminal. In the previous example quotes are used +around the string value of the \usertype{title} parameter because the +string contains embedded spaces. + +To make precise the rules for quoted strings: +a string need not be +quoted provided [1] it appears as an identifier (a name) in an argument +list \emphasize{not} enclosed in parentheses, AND [2] the string does not +contain any blanks or other characters which are special to the CL, +e.g., the i/o redirection symbols, the pipe symbol, semicolon, the begin +comment character (\usertype{\#}) or curly braces. +If the string contains any special characters it must be quoted. + +Comments may be freely embedded in a command sequence. +Everything following the comment character on a line is ignored by the parser, +so entire comment lines may be entered by starting the line with a comment: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{\# This is a full line comment} \\ +\comptype{cl>} \usertype{type login.cl \hfill \#~Display~the~login~file } +\end{quotation} + +\noindent +or by appending a comment to the end of a line as in the last example. + +\subsection{Task Parameters} + +\ppind +Nearly all tasks have a formally defined set of parameters associated +with them. The parameters for a task may be listed with the command +\usertype{lparam }{\it taskname}. For example, to list the parameters for +the task \taskname{delete}, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{lparam delete} +\end{quotation} + +\noindent +The \usertype{lparam} command produces a display of the parameters of the +named task in the order in +which they must be given on the command line; it shows the current values +of the parameters and the prompt strings as well. + +After one types \usertype{lparam delete}, the following list will appear, +giving the parameter name, its +current value, and the prompt string associated with it: + +\begin{verbatim} + files = list of files to be deleted + go_ahead = yes delete or not ? + (verify = no) verify operation before deleting each file ? + (default_action = yes) default delete action for verify query + (allversions = yes) delete all versions of a file ? + (subfiles = yes) delete any subfiles of a file ? + (mode = ql) +\end{verbatim} + +Notice that there are two types of parameters, those with +parentheses around the \emphasize{param = value} fields and those without. +The parameters not enclosed in parentheses are called +\irafname{positional parameters}; they are required parameters +and will be queried for if not given on the command line. Positional +\emphasize{arguments} are the first arguments on the command line (following +the command itself), and they are associated with parameters by their position +on the command line. The first positional parameter will be set by the first +positional argument on the command line, the second positional parameter by +the second positional argument, and so on. + +The parameters enclosed in +parentheses are called \irafname{hidden parameters}, and are the topic of +the next section. Either type of parameter may be referred to by a +\usertype{param = value} clause, although these parameter references +must \emphasize{follow} the positional arguments. Such name references +\emphasize{must} be used for the hidden parameters, but may be used for all. + +Some of the parameter handling actions in the CL are rather elaborate +and require discussion. As was just noted, the CL will automatically +prompt for any required parameters that have not been provided in some +way by the user. Beyond this, the normal action of the CL is to +remember the parameters that you last used, and when that parameter +name is next encountered, to offer the last value used as the new +default value. This \irafname{learning} of parameters is intended +to reduce user effort and is a means of customizing use of the system. +The learned parameters are saved for you in the \filename{UPARM} +subdirectory, and will be preserved across uses of the system. + +\subsubsection{Hidden Parameters} + +\ppind +The parameters of the \usertype{delete} task that appeared in +parentheses are \taskname{hidden parameters} for the task. +The CL does not query for hidden parameters, but automatically +uses the default values. However, a query will be generated for +even a hidden parameter if there is no +default value or if the default value is illegal for some reason. +Hidden parameters may be set on the command line, but unlike positional +parameters, the value from the command line will not be learned, i.e., it will +not become the new default value. The default value of a hidden parameter may +be changed only by an explicit assignment, or by use of the \taskname{eparam} +task (\S 3.2.3), and you should exercise caution in doing this, +because it is easy to forget that hidden parameters have been changed. + +Hidden parameters are often used to change the behavior of a task, +achieving considerable flexibility without requiring many arguments on the +command line, and without annoying queries for parameters. Hidden parameters +make it possible to support functions like \taskname{graph} that +support different display options, since users can modify +the default behavior of the task to make it behave in the manner they want. +Hidden parameters can also be dangerous if they are used improperly +(e.g., for data dependent parameters in scientific programs). + +The \taskname{delete} task is a good example of a task that is useful to +personalize. The default behavior of \taskname{delete} is simply to delete +the named file or files (provided they are not protected in some way). +File deletion can be hazardous, of course, particularly since a pattern +matching template may be used to delete many files. As many of us are unhappily +aware, inadvertently typing + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete $*$} +\end{quotation} + +\noindent +will bring about the swift deletion of \emphasize{all} of the (unprotected) +files in the current default directory. +As IRAF recognizes a number of special pattern matching metacharacters in +addition to `$*$', one could easily free up a lot of disk space if one were +not familiar with the use of pattern matching templates. + +To reduce the possibility of such devastating side-effects, you might wish to +change the default behavior of \taskname{delete} to verify each file deletion. +This is done by changing the value of the hidden parameter \taskname{verify}, +which defaults to \emphasize{no}. Hidden parameters that are boolean flags +(yes/no) may be overridden temporarily on the command line as follows: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete $*$.dat verify=yes} +\end{quotation} + +\noindent +or, equivalently, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete $*$.dat verify$+$} +\end{quotation} + +\noindent +Either of these commands would cause a prompt to be issued naming +each file matching the template and asking if you want to delete +it (this would happen even if the task were running in batch mode). + +If you set a hidden parameter on the command line, you override the value +of that parameter only for that command; the default value is not changed. +As indicated before, to change the default value of a hidden parameter, +an explicit assignment is required: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete.verify = yes} +\end{quotation} + +\noindent +which will cause all subsequent file deletions to be verified, unless the +\usertype{delete} command is issued with the argument \usertype{verify=no} +or \usertype{verify$-$} on the command line. The change may be undone by +another assignment, or by \emphasize{unlearning} the task parameters. + +\subsubsection{Learning and Unlearning parameters} + +\ppind +The CL facility called \irafname{learn mode} is designed +to simplify the use of the system. +By default, the CL automatically ``learns'' the value of all task +\irafname{parameters} that are prompted for or explicitly set. In practice, +this means that once a required parameter (such as the precession epoch in +the \taskname{precess} example) +has been set, it need not be respecified. The CL will still prompt for +required parameters, but the default value displayed will be the +last value you entered. Simply hitting \key{RETURN} will cause the CL +to reuse the old value; but a new value may be entered and it will +be preserved as the new default. If the required parameters are +specified on the command line, you will not be prompted for them, and the +value you specify will still be learned. + +The parameter-learning mechanism has other ramifications as well. +The most recently used parameter values are automatically preserved +by the CL in \filename{.PAR} files stored in your \filename{UPARM} directory. +These saved parameter +sets are reloaded when you next start the CL, thus providing a +\emphasize{memory} of the options that you used in a previous session. +Any command line arguments +that you specify will override these \emphasize{learned} defaults, but they +will be available if you wish to use them. + +An explicit command may be used to +\emphasize{reset} the values of parameters, +i.e., to restore the defaults. The \usertype{unlearn} command restores the +system default values of all of the parameters for a single task or for an +entire package. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{unlearn delete} +\end{quotation} + +\noindent +will restore the parameters of the task \taskname{delete} to their default +values, and + +\begin{quotation}\noindent +\comptype{cl>} \usertype{unlearn system} +\end{quotation} + +\noindent +will restore the defaults for \emphasize{all} of the tasks in the system +package. If you want to restore the defaults for all the parameters in your +IRAF environment, delete the \filename{.PAR} files from the logical directory +\filename{UPARM} : + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete uparm\$$*$.par} +\end{quotation} + +\subsubsection{Specifying Parameters to a Task} + +\ppind +The simplest and fastest way to invoke a task is to simply type in the name +of the task followed by the necessary arguments on the command line, as we +have been doing in most of the examples thus far. +In many cases, the arguments for a task will be obvious, either from the context +and the prompts issued by the task, or from the \usertype{lparam} display. +If you are unsure about how to proceed, +you can simply type the task name, and answer the questions. +Each prompt may include minimum and maximum acceptable values, +if such apply, and the current value of the parameter if such exists. +For parameters that have only a fixed set of allowable values the list of +valid options will be enumerated. + +Alternatively, the \usertype{eparam} command may be used to invoke the +parameter \emphasize{editor}. The \taskname{eparam} task presents the +parameters of a task in a tabular display on the screen and supports the +use of the cursor keys to navigate the options. It also has commands for +changing entries, or for recalling previous entries for further editing. +The command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{eparam precess} +\end{quotation} + +\noindent +will display the parameters for \taskname{precess} (the \taskname{noao} and +\taskname{astutil} packages must first be loaded). The \key{RETURN} +key will move you down the list or the cursor keys +may be used to move among the parameters, and any entries that you +type will replace the displayed values. You may exit from +\taskname{eparam} at any time with a \key{CTRL/Z} and the parameters +for the task will be updated with your newly edited values. +If you wish to exit the editor \emphasize{without} updating the +parameters, use the interrupt request \key{CTRL/C} instead. +Specifying parameters via \usertype{eparam} has the same effect as +does entering them on the command line, they will be remembered by IRAF +and not prompted for when the function is next invoked. + +\usertype{Eparam} and the history editor \usertype{ehistory} both +use the same simple set of editor commands, and they can mimic several +editors that are common on the currently supported systems. For any +of these editors the default style supports use of the cursor (arrow keys) +on the terminal and the use of the \key{DELETE} key. The sections on +editors (\S 5.2-3) describe this in more detail. + +If you find that you must invariably run \taskname{eparam} before running +a particular task, e.g., because the task has too many parameters to be +specified on the command line, it is possible to get the CL to run +\taskname{eparam} for you automatically whenever the task is run interactively. +This is called \usertype{menu mode}. To set menu mode for a task we +set the string value of the \taskname{mode} parameter of the task; all +tasks have such a parameter. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{precess.mode = ``ml''} +\end{quotation} + +\noindent +will set both menu and learn mode for the task \taskname{precess}. +The default mode for most tasks is \usertype{ql}, i.e., query (the task +will query for all parameters not set on the command line) plus learn +(old parameter values are learned). + +Once you are familiar with the operation of a task, you can +enter the parameter values on the command line in the +order in which they appear in the \usertype{lparam} listing. +Parameters may also be set using the \usertype{param = value} clause on the +command line, but remember that any positional arguments must be given first. +Note that a command line argument may be any general expression, much like +the arguments to a Fortran subroutine. + +\begin{quotation} \noindent +\comptype{cl>} \usertype{precess stdepoch= (1984$+$i$*$4)} +\end{quotation} + +\noindent +Here an expression is used to compute the value of the +hidden parameter \taskname{stdepoch}. Note that the expression must +be enclosed in parentheses in order to cause it to evaluated, since it +will otherwise be treated like a string and just passed into the task +for it to handle. The variable \usertype{i} must previously have +been set to some legal value; otherwise the CL will prompt for it. + +\subsection{Pipes and I/O Redirection} + +\ppind +We have already seen how tasks can take their input from either the +terminal or from a file, and send the output to either the terminal +or a file. By default, both the standard input and standard output for a +task are written to the user terminal; the capability to change them +on the command line is called \emphasize{I/O redirection}. The Appendix of +IRAF commands at the end of this document was created with the +following simple command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{help {\it pkg} $>$ {\it pkg.txt} } +\end{quotation} + +\noindent +where the name of each package was substituted for {\it pkg}. + +The pipe syntax is a powerful kind of I/O redirection. A pipe is formed by +connecting the output of one task to the input of another task; an arbitrary +number of tasks may be connected together in this way to form a single command. +UNIX users will already be familiar with the concept and uses of pipes, +but be aware that CL pipes differ from UNIX pipes in that the CL tasks +execute \emphasize{serially} rather than concurrently (i.e., nothing comes out +of the end of the pipe until \emphasize{all} the input has been processed). +Another difference between IRAF and the usual UNIX implementation +is that IRAF pipes are implemented with temporary files which are +managed by the system. +Note also that queries for parameters are not affected by the use of +I/O redirection or pipes, i.e., required parameters will still be +prompted for when requested by a task. + +A simple example of the use of a pipe is redirecting the output of a command +to the line printer. This can be done with I/O redirection as follows: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{help plot $>$ temp} \\ +\comptype{cl>} \usertype{lprint temp} \\ +\comptype{cl>} \usertype{delete temp} +\end{quotation} + +\noindent +The pipe notation accomplishes the same thing and is more concise: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{help plot \pipe lprint} +\end{quotation} + +\noindent +For a more sophisticated example of the use of pipes, load the +\usertype{lists} package and try out the following command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{?? \pipe words \pipe match : stop$+$ \pipe + sort \pipe table} +\end{quotation} + +\noindent +This sequence of commands takes the list of menus produced by \usertype{??}, +breaks it into a list of words, filters out the lines that contain the colon +character (the package names), sorts the list, and prints a menu listing the +tasks in all loaded packages. + +The following example shows the use of a pipe-filter to sort the output +of a long form directory listing of the system library directory \filename{LIB}, +sorting the list in reverse numeric order by the size of the file, so that +the largest files come out at the top of the list: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{dir lib l$+$ \pipe sort num$+$ rev$+$ col$=$3} +\end{quotation} + +\noindent +We can go a bit further and extend the pipe to print only the ten largest +files and page the output: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{dir lib l$+$ \pipe sort num$+$ rev$+$ col$=$3 \pipe + head nlines$=$10 \pipe page} +\end{quotation} + +Any or all of the input, output or error logical I/O streams may be +redirected with simple command line requests. The next example shows +the use of redirected input and output streams: + +\begin{quotation}\noindent +\comptype{cl>} \usertype { + match \upa\usertype{set} $<$ home\$login.cl $>$ names.env } +\end{quotation} + +\noindent +This command reads from your \filename{LOGIN.CL} file, created by the +initial \usertype{mkiraf} command, matches all the lines that contain +\usertype{set} environment statements (the metacharacter \upa (up-arrow) +causes \usertype{set} to be matched only at the beginning of a line), +and writes these out into the file \filename{NAMES.ENV}. + +The \usertype{$>$} redirection operators will create a new output file. +To append to an existing file we use the \usertype{$>>$} operator instead: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{set \pipe match tty $>>$ names.env} +\end{quotation} + +\noindent +which will scan for all the environment variables having something to do with +the terminal and append them to the file \filename{NAMES.ENV}. + +The operators \usertype{$>$} and \usertype{$>>$} will redirect only the +standard output stream \filename{STDOUT}; error messages will still come +out on the terminal. To redirect both \filename{STDOUT} and \filename{STDERR} +the operators \usertype{$>$\&} and \usertype{$>>$\&} should be used instead. + +The graphics output streams may be redirected (but not piped) much as is +done for the ordinary textual output streams.\footnote{This holds only for +standard IRAF tasks, i.e., tasks which use the IRAF graphics subsystem. +This feature is not currently available for the STScI SDAS tasks since they +do not use the IRAF graphics facilities.} For example, to redirect the +standard graphics output of the \taskname{surface} task (in the \taskname{plot} +package) to produce a graphics metacode file \filename{SURF.MC}: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{ surface dev\$pix $>$G surf.mc} +\end{quotation} + +To redirect the \filename{STDIMAGE} stream, substitute the operator +\usertype{$>$I}, and to redirect the \filename{STDPLOT} stream, use the +operator \usertype{$>$P}. The characters \usertype{GIP} must be uppercase. +The \usertype{$>$} may be doubled to append to an existing file, as for +the standard text streams. As a special case, a graphics stream (or indeed +any stream) may be redirected to the so-called \emphasize{null} file +\filename{DEV\$NULL} to discard the output. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype {prow dev\$pix 100 $>$G dev\$null} +\end{quotation} + +\noindent +will plot row 100 of image \filename{DEV\$PIX}, redirecting the graphics output +into the null file. The null file can be used anywhere a normal file can be +used. + +\newpage +\section{Operating System Interface} + +\ppind +Although IRAF provides a quite complete environment for data analysis +activities, it must be hosted in some particular operating system whenever +it is being used. The isolation from the peculiarities of any +specific operating system command syntax is rather complete, but there +are instances where the syntax of the underlying system must be +used (host filenames) or where the user may desire to use familiar +commands from the host system. IRAF does allow commands to be passed +through to the host operating system, but because IRAF maintains all of +its own environment descriptors, directory structures, and task and +program information, the operating system commands should only be used +to bring information into the IRAF environment, but not to modify it. +In order to change any of the status or control information that +affect IRAF execution, the commands provided by IRAF must be used. + +\subsection{Sending Commands to the Host Operating System} + +\ppind +IRAF allows access to the underlying operating system, and hence to +other programs that operate within the native operating system +environment. There are limitations on some of the system facilities that +can be used without regard to side-effects, but, in general, almost any +program can be called from within IRAF. +External programs can be accessed from within the user's environment and will +operate with a standard interface that is compatible with the +rest of the processing functions that are available. + +Any command may be sent to the host operating system by prefixing +the command with the escape character `\usertype{!}'. The rest of the +command line will be passed on unmodified. For example, to read your mail +on a UNIX or VMS system: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{!mail} +\end{quotation} + +\noindent +Upon exiting the mail routine, you will be back in the CL. Almost any +task that is executable in the normal host environment can be invoked +from within IRAF by means of this escape mechanism. The OS escape +is used to implement some of the standard IRAF commands that request +operating system information, such as \usertype{spy}. +The \usertype{edit} command also uses the escape mechanism, so that +the host supported editors can be used, rather than require that a +completely new editor be learned in order to use IRAF. + +Occasional conflicts will arise if these external tasks re-assign +their terminal input and output streams or perform other unnatural acts. +If strange things happen when trying to use such tasks from within +the CL, consult your \irafname{IRAF Guru}. The other major source of problems +with host system tasks is that they may depend upon system specific +data that have been defined for the OS but are unknown to IRAF. This +is a particular problem under VMS, which does not pass system environment +parameters to sub-tasks, as does UNIX. Variables that affect the +execution of tasks within the environment are controlled by IRAF and +are passed between the executing tasks, as in described next. + +\subsection{Environment Variables} + +\ppind +The CL maintains a table of environment variables which +affect the operation of \emphasize{all} IRAF programs. +The environment variables are used to define logical names for directories, +to associate logical device names with a specific physical device, +and to provide control over the low level functioning of the +IRAF file I/O system. +The default environment is created by IRAF at login time, i.e., when the +CL is first run. Part of this initialization uses a standard system-wide, +site dependent file named \filename{HLIB\$ZZSETENV.DEF}. Additional +initialization of personal environment variables, or redefinition +of standard environment variables, may be done with commands +in your \filename{LOGIN.CL} file. + +One may add new environment variables, or redefine old ones, at any time during +a session with the \usertype{set} command. \usertype{Set} declarations made +during CL execution, however, may be lost upon exit from a package. To secure +environment declarations for a full session, make them \emphasize{immediately} +after logging in. To make environment declarations permanent, place the +relevant \usertype{set} commands in your \filename{LOGIN.CL} file. + +The \usertype{set} command is usually used to change the \emphasize{session} +defaults for output devices and such, but all IRAF programs which write to the +line printer or to a graphics device also permit the device to be selected on +the command line. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{set terminal = vt100} +\end{quotation} + +\noindent +informs IRAF that the user is using a VT100-type terminal for this session. +When typed without any arguments, e.g.: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{set \pipe page} +\end{quotation} + +\noindent +\taskname{set} displays a list of the current values of all of the environment +variables. Note that abbreviations are \emphasize{not} supported for +environment variable names, they must be spelled out in full. +If a shorter name is used the CL will silently create a new environment +variable for you, which may not be what you desired at all. + +Identifying the kind of terminal you are using, the size of the display +window to be used, and setting other terminal options may most conveniently +be done with the \usertype{stty} command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{stty tek4014 baud$=$1200} +\end{quotation} + +\noindent +This command should be used early in the session (if not already present in +the \filename{LOGIN.CL} file) to identify the kind of terminal that you are +using, since the operation of the various editors and of other functions will +be affected by these values. It is only necessary to set baud rate as in +the example if you are working remotely via modem. As was the case with +the \usertype{set} command, typing \usertype{stty} with no arguments will +display the current terminal type and settings. + +The current value of \emphasize{individual} environment variables may be +displayed with the \usertype{show} command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{show printer} +\end{quotation} + +\noindent +A selection of the more important environment variables is shown in the +following table. + +\begin{center} +\begin{tabular}{|l|l|l|} +\hline +\multicolumn{3}{|c|}{\bf Selected Environment Variables}\\ +\hline +{\it variable}& {\it sample value}& {\it usage}\\ +\hline +terminal& ``vt100''& default terminal device\\ +printer& ``printronix''& default line printer device\\ +stdgraph& ``vt640''& name of graphics terminal device\\ +stdplot& ``versatec''& batch plotter device\\ +stdvdm& ``uparm\$vdm''& name of graphics metacode file\\ +stdimage& ``iism75''& image display device\\ +clobber& no& clobber (overwrite) output files\\ +filewait& yes& wait for busy files to become available\\ +\hline +\end{tabular} +\end{center} +\medskip + +\noindent +Clearly, the permissible names of devices are site dependent; for a list of +the devices available at a particular site the user should consult their +\irafname{IRAF Guru} (or look in the \filename{TERMCAP} and \filename{GRAPHCAP} +files in the IRAF logical directory \filename{DEV}). + +Among the set of environment variables that control the operation of +the CL is a subset of variables that define the user environment. These +variables describe the user's home and scratch directories, terminal +type, and editor preference. Because these values describe a user's-eye +view of IRAF, they can be thought of as \emphasize{customization} variables +and can be \usertype{set} in the \filename{LOGIN.CL} file to your +preferred values. + +\begin{center} +\begin{tabular}{|l|l|l|} +\hline +\multicolumn{3}{|c|}{\bf User Environment Variables}\\ +\hline +{\it variable}& {\it sample value}& {\it usage}\\ +\hline +editor& ``vi'' & default editor mode\\ +home& ``/{\it user}/iraf/'' \footnotemark & user home directory\\ +uparm& ``home\$uparm/''& user scratch directory\\ +imdir& \emphasize{system-dependent}&directory where bulk data is stored\\ +imtype& ``imh'' & default image type (header file extension)\\ +userid& {\it user}& user identification name (for output)\\ +\hline +\end{tabular} +\end{center} + +\footnotetext{ {\bf VMS :} an equivalent VMS example might be +``DISK\bsl\$1:[USER.IRAF]''. Note that any dollar sign characters appearing +in host filenames must be escaped in IRAF since the dollar sign is a reserved +character in IRAF filenames.} + +\noindent +The \filename{HOME} directory specification, and possibly an +\filename{IMDIR} declaration should be the \emphasize{only} places in +your \filename{LOGIN.CL} file where any system specific names appear +at all. All of the IRAF name references (except a single root reference) +are processed by the virtual name mapping algorithms. If this same +mechanism is used for all user files as well, then only IRAF +virtual filenames need to be referenced once the root directory +has been properly specified. + +The default \emphasize{uparm} declaration +assumes that a \filename{UPARM} +subdirectory has been set up in your login directory; the \usertype{mkiraf} +command described earlier (\S 2.1) sets this up for you. If a \filename{UPARM} +subdirectory does \emphasize{not} exist, the CL will refuse to update +user parameters and will issue a warning message. + +\subsection{File and Directory Names} + +\ppind +The IRAF system employs \irafname{virtual file} names so that all file +references will look the same on any computer, and IRAF primitives convert +virtual filenames into their host operating system equivalents. In general, +either the IRAF virtual filename or the operating-system-dependent filename +may be used in a command entered by the user, but users should avoid +the use of OS-specific names wherever possible. Internally IRAF itself +uses only virtual filenames for reasons of transportability. + +Note that filename mapping does not operate automatically for virtual file +names that are passed as parameters to foreign (host system) tasks, but a CL +intrinsic function \taskname{osfn} will perform the mapping if called +explicitly on the command line. The host task must be declared as an IRAF +\taskname{foreign task} (\S 5.6) for this to work. There is no provision +for filename mapping when the regular OS escape mechanism (\S 4.1) is used. + +The environment variables described in the preceding section play a fundamental +role in the mapping of virtual filenames. Environment variables define +the logical directories that are used to create host operating system +specific names from logical names. An example of a virtual filename +is the default logfile, \filename{HOME\$LOGFILE.CL}. +The \filename{HOME} field, delimited by the `\$' character, is the logical +directory; the file name within that directory is \filename{LOGFILE.CL}. +Successive translations of `\$'-delimited logical names are performed until the +operating system dependent name has been generated. Names such as +\filename{HOME\$UPARM/} are \emphasize{directory} references; the trailing `/' +indicates that a filename or sub-directory name may be appended to produce +a legal file or directory pathname. + +\subsubsection{File Name Templates and Metacharacters} + +\ppind +Although filenames cannot be abbreviated the way commands can, +pattern matching templates can be constructed that +refer to many files. You need only type a +short string (the pattern) that serves as a \emphasize{template}, and all +files whose names match the template are selected. All of the IRAF +functions that process filenames (and this is most of them) use the +same function to expand filename templates into a list of files. +The pattern matching \irafname{metacharacters} are a super-set of those +used in the UNIX and VMS operating systems. To print all files having +the extension \filename{.CL}, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{lprint $*$.cl} +\end{quotation} + +\noindent +To page through all files in the logical directory \filename{FIO} +with the \filename{.X} extension, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{page fio\$$*$.x} +\end{quotation} + +\noindent +The filenames matched by the file template are passed to the \usertype{page} +task which pages through the set of files. As each file is accessed, the VOS +filename translation facilities are used internally to generate the host +system filename, which is passed to the kernel to physically open the file. + +\begin{center} +\begin{tabular}{|l|l|l|} +\hline +\multicolumn{3}{|c|}{\bf Pattern Matching Metacharacters} \\ +\hline +{\it Meta-char}& {\it Meaning}& {\it Example}\\ +\hline +$*$ & Match zero or more characters & $*$.cl \\ +\lbox...\rbox & Any character in class & \lbox a-z\rbox \\ +\lbox \upa...\rbox & Any character not in class & \lbox \upa A-Z\rbox \\ +? & Match any single character & a?c \\ +\{...\} & Ignore case for the enclosed string & \{Lroff\} \\ +@{\it file} & Read filenames from a list file& @listfile \\ +\hline +\end{tabular} +\end{center} + +\noindent +To delete a named list of files, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete file1,file2,file3} +\end{quotation} + +\noindent +Note that the list of filenames is separated by commas \usertype{','} +\emphasize{with no intervening blanks}. +This causes the individual filenames to be treated as one list-form +parameter rather than to be processed as three separate parameters. +A blank is treated as a delimiter by the parser, and thus may not appear +in a list-form parameter unless the list is enclosed in quotes. + +The following is equivalent to the previous example, except that no warning +will be issued if any of the three files does not exist, since we are asking +the system to find all files that match the template, rather than naming the +files explicitly: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete file\lbox123\rbox} +\end{quotation} + +\noindent +Consider the following simple command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete filex} +\end{quotation} + +\noindent +The name ``filex'' given here is actually ambiguous; it could be either the +name of a file (a string constant) or the name of a string parameter +set to the name of the file to delete. In this simple and common case, +the CL will quietly assume that ``filex'' is the \emphasize{name} of the +file. If the identifier \usertype{filex} is really the \emphasize{name} +of a variable, it will have to be parenthesized to force it to be evaluated. +Either of the following forms are equivalent to this command and both are +unambiguous requests to delete the file named \filename{FILEX}: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete 'filex'}\\ +\medskip +\comptype{cl>} \usertype{delete ('filex')} +\end{quotation} + +\noindent +Note that within parentheses the \emphasize{string} \usertype{'filex'} +must be typed as shown, with quotes, or the CL will attempt to process +it as a variable name, causing a runtime error if there is no such variable +currently defined within the scope of the \taskname{delete} task. + +The following command is also unambiguous, and it specifies that the CL +is to take the name of the file from the \emphasize{parameter} ``filename'': + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete (filename)} +\end{quotation} + +Note that in many of these examples, a \emphasize{single} string +type argument, viz. the file matching template with metacharacters, +is used to refer to a list of files. +This convention is employed by all IRAF tasks which +operate on lists of files. Be careful not to confuse a file list template +with the argument list itself. Thus: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete file,file2,prog.$*$} +\end{quotation} + +\noindent +is perfectly acceptable, and does what the next example does: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete 'file1, file2, prog.$*$'} +\end{quotation} + +\noindent +as long as there are no blanks between elements of the first name list. +If blanks were inadvertently included in the unquoted template string the +CL would interpret the template as several string arguments, probably causing +an error something like ``\comptype{too many positional arguments}''. + +The list file approach is useful when it is difficult to specify a template +for the desired set of files, when the same set of files will be operated +upon several times, when a very large number of files are to be operated +upon, or when a list is already available. The file list may be generated +by the editor, or by a task such as \taskname{files}, e.g.: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{files *.im,run[1-4].* $>$ listfile} +\end{quotation} + +\noindent +The textfile \filename{LISTFILE} may then be referenced in a filename template +as \usertype{@listfile} to operate upon the listed files. A variation on +the listfile approach is \usertype{@STDIN} (must be upper case), which +allows the filenames to be typed in when the task begins running. + +Some tasks use the filename template mechanism to generate the names of a +\emphasize{new} set of \emphasize{output} files. The filename template +expansion code provides two operators for generating new filenames from +old ones. The file template \emphasize{operators}, which are used to +construct new filenames, should not be confused with the pattern matching +\emphasize{metacharacters}, which are used to match a subset of an existing +set of files. + +The first and simplest operator is the string concatenation operator +\comptype{//}. This may be used to concatenate a string suffix to the +\emphasize{root} field of a filename, to concatenate a filename to a string +prefix, to concatenate two filenames, or some combination of the above. +For example, + +\begin{quotation}\noindent +\comptype{cl>} \comptype{files lib\$*.com$//$\_o} +\end{quotation} + +\noindent +will produce a new list of files by appending the string \comptype{"\_o"} to +the root of each filename matched by the template at the left. + +The second and last operator is the string substitution operator +\comptype{\%}. If a sequence of the form \comptype{\%a\%b\%} is inserted +somewhere in a file template, the string \usertype{a} will participate in +the pattern matching operation, but will be replaced by \usertype{b} in the +generated filename. Either \usertype{a} or \usertype{b} may be omitted to +insert or delete fields from a filename. For example, + +\begin{quotation}\noindent +\comptype{cl>} \comptype{files lib\$*\%\%\_o\%.com} +\end{quotation} + +\noindent +is equivalent to the concatenation operation illustrated in the preceding +example. The command + +\begin{quotation}\noindent +\comptype{cl>} \comptype{files lib\$*.\%com\%dat\%} +\end{quotation} + +\noindent +would find all the \filename{.COM} files in the logical directory +\filename{LIB}, generating a new list of files with the extension +\filename{.DAT} substituted for \filename{.COM}. + +All IRAF tasks that use pattern matching or template expansion use the same +syntax and metacharacters as in the examples given here for filename templates. +This includes, for example, the use of templates in the \taskname{help} task +to locate manual pages, and the use of pattern matching in the \taskname{match} +task to search text files for lines that match a pattern. + +\subsubsection{Directories and Path Names} + +\ppind +It is often useful to employ several different directories as an aid to +organizing your data. For instance, you may have one directory for M87 data, +and one for M8 data, or, as was set up for you by the \usertype{mkiraf} command, +a login directory \filename{HOME} and a scratch directory \filename{UPARM}. +New directories may be created with \usertype{mkdir}; use \usertype{chdir} +or \usertype{cd} to change the default directory, and \usertype{back} to +return to the most recent default directory. + +For example, to display the pathway through the system to your current +default directory, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{path} +\end{quotation} + +\noindent +To change to a new default directory, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{chdir }{\it newdir} +\end{quotation} + +\noindent +where {\it newdir} may be an IRAF logical directory name defined +with a \usertype{set} command, an IRAF pathname to the directory, +or a host system directory name (provided any dollar sign characters +therein are escaped). + +The \usertype{mkdir} command can be used to create a new sub-directory +of the current directory: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{mkdir m87} +\end{quotation} + +\noindent +To define a logical directory name (``m87'') for this subdirectory +of your home directory, use the following set command (note the trailing '/'): + +\begin{quotation}\noindent +\comptype{cl>} \usertype{set m87 = 'home\$m87/' }\footnotemark +\end{quotation} + +\footnotetext{ {\bf VMS :} IRAF supports logical names for +files and directories that may contain mixed cases and special +characters. However, to avoid unpleasant surprises, +we recommend that for root directories you use only names valid +for the underlying operating system.} + +\noindent +Once this logical name mapping has been established, you may type either +of the following commands to change the default +directory to the ``m87'' directory (note \usertype{chdir} may be +abbreviated \usertype{cd}): + +\begin{quotation}\noindent +\comptype{cl>} \usertype{chdir m87} \\ +\medskip +\comptype{cl>} \usertype{cd home\$m87}\footnotemark +\end{quotation} + +\footnotetext{ {\bf VMS :} The characters \comptype{\$} and \comptype{[}, +commonly used in VMS device and directory names, will cause a conflict +if VMS file or device names using them are passed to IRAF tasks since these +characters have a special meaning in IRAF filenames and filename templates. +If either of these characters is used in a VMS filename passed to an IRAF +program, the character must be escaped to avoid interpretation as a VOS +metacharacter, e.g., \comptype{page usr\bsl\$0:\bsl[iraf.local]login.cl}.} + +\noindent +If you type \usertype{chdir} or \usertype{cd} without any arguments, the +default directory will be set to your ``home'' directory. + +Once a logical directory has been defined, the IRAF pathname notation may +be used to reference any file or directory in the vicinity of the new logical +directory. For example, the following command would page the file CURSOR.KEY +in the subdirectory SCR of the subdirectory LIB of the IRAF root directory +IRAF, a predefined logical directory: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{page iraf\$lib/scr/cursor.key} +\end{quotation} + +The current directory and the directory one level up from the current +directory may be referenced in pathnames via the synonyms ``\usertype{.}'' +and ``\usertype{..}''. For example, if the current default directory is PKG, +a subdirectory of LIB like SCR in the preceding example, the path to the +CURSOR.KEY file could be entered as follows: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{page ../scr/cursor.key} +\end{quotation} + +It is not necessary to change the default directory to reference +files located in another directory. Your login directory, for example, has +the logical name \filename{HOME\$} assigned to it. +The following command would page through the \filename{LOGIN.CL} +file in your home directory, regardless of the current default directory: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{page home\$login.cl} +\end{quotation} + +\noindent +The logical directory names (\filename{UPARM} and \filename{IMDIR} are examples +of directories that are normally appended to the \filename{HOME} +directory, and you may set up other logical directories as required. +The names of all of the standard IRAF system directories are defined +automatically when the CL starts up, and may be listed with the +\taskname{set} command. + +\subsubsection{Virtual Filename Processing} + +\ppind +Virtual filenames are used throughout IRAF and the CL in preference +to operating system specific names. The obvious reason for this is +to isolate OS specific interfaces to a small set of locations, as +a way of ensuring commonality across operating systems and as an +aid to portability. There is an obvious benefit to the user as well, +in that filename references will look the same within IRAF regardless +of the host environment. Operating system specific names must +eventually be generated, but the details of these operations are +best buried in dedicated interface routines. + +The only place where OS specific names need appear at the user level is +in file system directory names and in references to system physical devices. +Even here, the use of OS specific names should be isolated to only +one or two root directory names. +The other place where OS names must appear is calls to operating +system routines or to external programs that are accessed from within +IRAF via the OS escape mechanism (\S 4.1). The \taskname{pathnames} task +and the \taskname{osfn} intrinsic function are used to translate IRAF virtual +filenames into host system filenames. + +Either of the following commands will print the fully qualified OS name +for the file \filename{HOME\$LOGIN.CL}. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{path home\$login.cl}\\ +\medskip +\comptype{cl>} \usertype{= osfn ('home\$login.cl')}\\ +\end{quotation} + +\noindent +The \taskname{pathnames} task writes the translated filename on its standard +output, while \taskname{osfn} returns the translated filename as the function +value. The \usertype{pathnames} task will also expand filename templates, +and thus can be used to generate the OS names for a list of files: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{path home\$ss433.*\ $>$ ss433files.list} +\end{quotation} + +\noindent +will generate a list of all of the files in directory \filename{HOME} +that match the template, and will write the fully qualified OS names +of these files into \filename{SS433FILES.LIST}. This ASCII file can +be edited as necessary, and used as list-structured input to other +IRAF functions (\S 2.3, \S 6.9, \S 7.3). + +The most common use of the \taskname{pathnames} task is probably to print +the current default directory, which is its function when called with no +arguments on the command line. + +\subsection{Image Data} + +\ppind +An IRAF \emphasize{image} is an N-dimensional data array with an associated +\emphasize{image header} describing the physical and derived attributes of +the image. The content of the header tends to be very data or application +specific. The datatype selected to store the \emphasize{pixels} (data values) +is also application dependent, and a variety of choices are provided. +Images of up to seven dimensions are currently supported, although +in practice most images are either one or two dimensional, and most programs +are written to operate upon one or two dimensional images. Any IRAF program +can be used to operate upon a \emphasize{section} of lesser dimension +(or extent) than the full image, using the \emphasize{image section} notation +discussed in \S 4.4.3, hence the dimensionality of the algorithm implemented +by a program need not prevent use of the program on images of higher dimension. + +\subsubsection{Image Names and Storage Formats} + +\ppind +The notation used to refer to images is similar to that used to refer to +files, except that images are more complex objects than files and hence a +somewhat more complex notation is required. Most of the file, directory, +and pathname notation discussed in \S4.3 carries over to images. +Sets of images are referred to by an \emphasize{image template} notation +which is an extension of the file template notation discussed in \S4.3.1. + +In most, but not all, cases, an IRAF image is stored on disk in two separate +files, one containing the image header and the other containing the pixels. +The basic image name is the filename of the header file. The filename of an +image header file always has an extension specifying the format in which the +image is physically stored on disk. \footnote{In versions of IRAF prior to +V2.3, only one physical image storage format was supported, hence image header +files did not have extensions.} Two storage formats are currently supported, +the old iraf format (OIF) and the SDAS group data format (STF). The old IRAF +format images have the extension \filename{IMH}. The STF images may have any +three character extension ending in \filename{H}, e.g., \filename{HHH} +(the extension \filename{IMH} is reserved for OIF images, of course). +Both types of images may be accessed at any time, with the extension being +used to identify the physical storage format to the IRAF software. + +For example, the IRAF system is distributed with a standard OIF format test +image \filename{PIX} stored in the system directory \filename{DEV}. The full +filename of the header file is \filename{DEV\$PIX.IMH}. To make a copy of +this image in the current directory we could load the \taskname{images} +package and enter the following command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{imcopy dev\$pix pix} +\end{quotation} + +\noindent +or since we don't want to change the image name, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{imcopy dev\$pix .} +\end{quotation} + +\noindent +Note that we did not have to specify the image type extension in the copy +operation. The extension is optional whenever a single image is referenced; +in image templates, the template must match the full filename of each image +as it appears in a directory listing, hence the extension is required in +image templates. + +Sometimes it is necessary to specify the image type extension to force an +image of a certain type to be created. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{imcopy dev\$pix pix.bah} +\end{quotation} + +\noindent +would create an STF format copy of the standard test image in the current +directory. + +When making a copy of an existing image, the new image will have the same +format as the old image unless an extension is specified in the output image +name. When creating a new image from scratch, e.g., when reading a data +tape to disk, the default image type is determined by the value of the CL +environment variable \filename{IMTYPE}, the value of which is the three +character default image type extension. If \filename{IMTYPE} is not defined, +the default value is \usertype{imh}, i.e., an OIF format image will be +created. To change the default to be to create an STF format image, add +a command such as + +\begin{quotation}\noindent +\comptype{cl>} \usertype{set imtype $=$ hhh} +\end{quotation} + +\noindent +to your \filename{LOGIN.CL} file. + +\subsubsection{Image Templates} + +\ppind +Image templates are equivalent to filename templates except that the character +\comptype{`['}, a pattern matching character in filename templates, has a +different meaning in image templates, as we shall see in the next section. +\footnote {If you really want to perform file template style character class +expansion in an image template, use the operator \comptype{![} instead +of \comptype{[}. The conventional escape mechanism, i.e., \comptype{\bsl[}, +is used to include the \comptype{[} in the \emphasize{filename}, as in a +filename template.} + +\noindent +For example, given a directory containing the files + +\begin{verbatim} + irs.log irs.0030.imh irs.0031.imh irs.0032.imh +\end{verbatim} + +\noindent +the template \usertype {irs.$*$.imh} would match the three image files, +whereas \usertype{irs.$*$} would match the \filename{LOG} file as well, +causing \taskname{imheader} to complain about an illegal format image in +its input list. + +\subsubsection{Image Sections} + +\ppind +All IRAF programs which operate upon images may be used to operate on +the entire image (the default) or any section of the image. +A special notation is used to specify \irafname{image sections}. The section +notation is appended to the name of the image, much like an +array subscript is appended to an array name in a conventional programming +language. Note that array or image section \emphasize{index references} +are integer only in pixel coordinates, but that the data may be of any valid +type. + +\begin{quote} +\begin{tabular}{ll} +{\it section}& {\it refers to}\\ +\\ +pix& whole image\\ +pix[]& whole image\\ +pix[i,j]& the pixel value (scalar) at [i,j]\\ +pix[$*$,$*$]& whole image, two dimensions\\ +pix[$*$,-$*$]& flip y-axis\\ +pix[$*$,$*$,b]& band B of three dimensional image\\ +pix[$*$,$*$:s]& subsample in y by S\\ +pix[$*$,l]& line L of image\\ +pix[c,$*$]& column C of image\\ +pix[i1:i2,j1:j2]& subraster of image\\ +pix[i1:i2:sx,j1:j2:sy]& subraster with subsampling +\end{tabular} +\end{quote} + +\noindent +A limited set of coordinate transformations may be specified using image +sections, but please observe that transpose is \emphasize{not} one of them. +The ``match all'' (asterisk), flip, subsample, index, and range notations +shown in the table may be combined in just about any way that makes sense. +As a simple example: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{graph pix[$*$,10]} +\end{quotation} + +\noindent +will graph line 10 of the image \filename{PIX}. +To generate a contour plot of an 800-pixel square image +subsampled by a factor of 16 in both dimensions: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{contour pix[$*$:16,$*$:16]} +\end{quotation} + +\noindent +To display the fifth $x-z$ plane of a three dimensional image named +\usertype{cube} on frame 1 of the image display device: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{display cube[$*$,5,$*$] 1} +\end{quotation} + +\noindent +The image section string is part of the image name and is processed by +the IRAF system software (rather than by each applications program), +hence image sections can be used with all IRAF programs. A section can +be used to write into a portion of an existing output image, as well as to +read from an input image. + +\subsubsection{The OIF Image Format} + +\ppind +The old IRAF image format (OIF) is the original IRAF image format, +unchanged since it was first used in the beginning of the project. +It is called the ``old'' format in anticipation of its eventual replacement +by a new format to be layered upon the planned IRAF database facilities. +The OIF format is the current standard IRAF image format and is the format +used to test the IRAF image processing software at NOAO. + +In the OIF format, each image is stored in a distinct pair of files, the +header file (extension \filename{IMH}) and the pixel file (same root name as +the header file, extension \filename{PIX}). The pixel file need not reside in +the same directory as the header file; by default all pixel files are +created in a user directory on a scratch disk device to permit a different +file quota, file expiration, and backup policy to be employed than is used +for the smaller, more permanent ordinary user files. + +The CL environment variable \filename{IMDIR} determines where OIF pixel files +will be created. \filename{IMDIR} is a required parameter and is normally +defined in the user's \filename{LOGIN.CL} file. The value of \filename{IMDIR} +is only used when the pixel file is created; if the value of \filename{IMDIR} +is later changed, new pixel files will be created in a different directory, +but the system will still be able to find the pixel files of the older images. + +By default, the \taskname{mkiraf} script will create an image storage +directory for the user on a public scratch device and place the host pathname +of the new directory in the user's \filename{LOGIN.CL} file. For example, +on a UNIX system, a typical set environment statement might be: + +\begin{quotation}\noindent +\usertype{set imdir $=$ $/$tmp2$/$iraf$/$user$/$} +\end{quotation} + +\noindent +which will cause the pixel files to be created in the named host directory, +regardless of the directory in which the image header file resides. +As an option, we can request that the pixel file be placed in the +\emphasize{same} directory as the header file: + +\begin{quotation}\noindent +\usertype{set imdir $=$ HDR\$} +\end{quotation} + +\noindent +or in a subdirectory of the header file directory, e.g., subdirectory +\filename{PIXELS}: + +\begin{quotation}\noindent +\usertype{set imdir $=$ HDR\$pixels$/$} +\end{quotation} + +\noindent +Note that the reserved logical directory name \filename{HDR} must be upper +case, and that a trailing slash is required if the subdirectory option is used. +The subdirectory will be created automatically by the system when the first +pixel file is created, if the directory does not already exist. +The \filename{HDR} option should \emphasize{only} be used if the header file +itself is created in a directory on a scratch device; it should always be used +if the image is created on a remote node in the local network. + +\subsubsection{The STF Image Format} + +\ppind +The STF image format is the format used by STScI to store Space Telescope +image data. IRAF provides a dedicated image kernel to read and write this +format so that sites reducing binary ST data do not have to carry out expensive +format conversions to be able to access the data from within IRAF. SDAS +users should note that the SDAS software can \emphasize{only} access STF +format images, hence the STF format must be used if you plan to make extensive +use of SDAS. Reductions involving only IRAF programs should not use the STF +format, since the OIF format is simpler and more efficient, and is the format +used to test the IRAF software. + +In the STF format, an image or a \emphasize{group} of similar images may be +stored in a pair of files, the image header file (extension \usertype{??H}), +and the associated pixel storage file (extension \usertype{??D}). If multiple +images are stored in a group format image, all member images share the same +group header. The group header file is a special VMS format text file which +can be examined by \taskname{page} and \taskname{type}, as well as with +\taskname{imheader}. Each member image in a group format image also has its +own private binary format header, called the group parameter block. The STF +image format supports only single precision real pixels, since that is what +SDAS programs require. + +IRAF programs consider images to be independent entities, with any associations +between images being left up to the user. When a member image of an STF +group format image is accessed from an IRAF program, IRAF constructs the image +header of the member image by concatenating the group header to the group +parameter block for the member image; no distinction is made between the two +classes of header parameters once the image has been opened. + +To refer to a specific member image of a group format image, the group +subscript must be specified in the image name. If there is an image section +as well, it comes after the group subscript. For example, if \filename{WFPC} +is an STF group format image, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{implot wfpc[3]} +\end{quotation} + +\noindent +would call up the interactive image plotting task \taskname{implot} on group +3 of the group format image. If no subscript is specified, the default is +group 1. To plot the same image with the lines flipped end for end, we add +an image section: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{implot wfpc[3][$-*,*$]} +\end{quotation} + +\noindent +To create a new group format image, we must preallocate space for all the +member images, all of which must be the same dimensionality, size, and +datatype. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{imcopy wfpc wfpc2[1$/$10]} +\end{quotation} + +\noindent +would create a new group format image \filename{WFPC2} with the same +dimensionality, size, and group parameter block as the existing STF image +\filename{WFPC}, then copy the pixels from \filename{WFPC} to +\filename{WFPC2[1]}. The new image would inherit the header of the old +image as well. Once a new group format image has been created, the remaining +member images may be written into by specifying the group subscript in the +output image name passed to an IRAF program. The group count +(\usertype{$/$10}) should be omitted, else IRAF will try to create a new +group format image, rather than write into one of the member images of +an existing group. Note that member images cannot be added or deleted +once a group format image has been created. + +\newpage +\section{Advanced Topics in the CL} + +\ppind +In addition to the basic facilities already described, +the CL permits user control over many aspects of the environment. +This includes direct control over the CL itself, control over user tasks +and background processes, the job logfile and the command history mechanism. +These features and others will be of use to the more advanced user +and enable user customization of interactions with the system. + +\subsection{CL Control Parameters} + +\ppind +The CL is itself a task which has a set of parameters that +are used to direct its execution. For example, if you wish to keep +a permanent record of all the commands you enter, the CL will do this +if you set its boolean parameter \taskname{keeplog} to yes. (Boolean +parameters can assume only the values \emphasize{yes} or \emphasize{no}.) +Simply type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{keeplog = yes} +\end{quotation} + +\noindent +and all subsequent commands will be written to the log file. +The name of this file is defined by the +string parameter \taskname{logfile} which defaults to the filename +\filename{HOME\$LOGFILE.CL}. The name of the logfile may be changed +by assigning a new value to the parameter, e.g.: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{logfile = "commands.log"} +\end{quotation} + +The important CL parameters which you may wish to alter or otherwise +access are described in the table below. + +\begin{center} +\begin{tabular}{|l|l|l|} +\hline +\multicolumn{3}{|c|}{\bf CL Parameters}\\ +\hline +{\it parameter} & {\it typical value} & {\it function}\\ +\hline +echo & no & echo CL command input on stderr? \\ +ehinit & (see manpage) & ehistory options string \\ +epinit & (see manpage) & eparam options string \\ +keeplog & no & record all interactive commands in logfile? \\ +logfile & ``home\$logfile.cl'' & name of the logfile \\ +logmode & (see manpage) & logging control \\ +menus & yes & display menu when changing packages? \\ +mode & "ql" & default mode for servicing parameter queries \\ +notify & yes & send done message when bkgrnd task finishes? \\ +szprcache & 3$-$4 & size of the process cache \\ +\hline +\end{tabular} +\end{center} +\medskip + +\noindent +A full list of CL parameters can be obtained with the \emphasize{lparam} +command, or by typing the command \usertype{help language.cl}. The latter +provides a brief description of each CL control parameter including references +to \taskname{language} package manual pages containing more detailed +information. + +Changes that you make to any of the CL task parameters by assignment during +a session will be lost when you log out of the CL. +This is in contrast to the parameters of a normal task, which are learned +by the CL. If you want the CL to ``remember'' values of CL parameters, +you should initialize them to your personal default values in your +\filename{LOGIN.CL} file and they will be reestablished for you each time +you log in. + +\subsection{Setting the Editor Language and Options} + +\ppind +The parameter editor (\usertype{eparam}) command and the history +editor (\usertype{ehistory}) both use the same simple set of edit commands +and a choice of editor languages is available. The command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{set editor = emacs} +\end{quotation} + +\noindent +will set the edit mode for both editors to use the Emacs set of keystrokes. +This also changes the editor that is invoked when +you issue the \usertype{edit} command, so that all of the editor interfaces +that are available will appear to operate in the same way. + +Editor choices, with their associated key bindings, are: + +\begin{itemize} +\item EDT (the default for VMS devotees) +\item Vi (ditto for their UNIX counterparts) +\item Emacs (which runs on either system) +\end{itemize} + +For convenience, all of these editor choices support +use of the cursor keypad keys and the \key{DELETE} key; the +ambitious user may define his own personal set of command key bindings. +The bindings that are available by default in IRAF are shown in an +Appendix (\S A.4). The default editor language that IRAF will start +with is as shown above, chosen for compatibility with the host operating +system. You may, of course, include a \usertype{set} command in +your \filename{LOGIN.CL} file to establish your own preferred editor. + +The edit facilities provided within IRAF are limited in scope, since +they are only intended to facilitate manipulation of user accessible +internal structures, task parameter blocks and history file. IRAF +has not implemented a full scale text editor, so the \usertype{edit} +command invokes the standard system editor which you choose by setting +the \usertype{editor} parameter. +A host system editor must be used for all major text manipulations, +but since it is invoked from within the IRAF environment the continuity +of your session is not lost. + +In addition to selecting the editor language to be used, there are a few user +settable options available to control the operation of the \taskname{eparam} +and \taskname{ehistory} tasks. These options are set by setting the string +values of the CL parameters \taskname{epinit} and \taskname{ehinit}. +For example, setting the \taskname{verify} option for \taskname{ehinit} +will cause the history mechanism to pause waiting for a command to be +edited or inspected, before executing the command. +Read the manual pages for the \taskname{eparam} and \taskname{ehistory} tasks +for a full description of these control options. + +\subsection{The History Mechanism} + +\ppind +The CL history mechanism keeps a record of the commands you enter and +provides a way of reusing commands to invoke new operations with a minimum of +typing. The history mechanism should not be confused with the logfile; +the history mechanism does not make a permanent record of commands, +and the logfile cannot be used to save typing +(except by using the editor on it after the end of the session). +With the history editor, previous commands can easily +be edited to correct errors, without the need to retype the entire command. + +The \usertype{history} command is used to \emphasize{display} command lines. +By default, the last 15 commands entered are printed, each preceded by +the command number. To show the last \emphasize{n} commands, +add the argument \usertype{n} to the \usertype{history} command line: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{history 3} \\ +\comptype{101 urand 200 2 \pipe graph po+ marker=circle szmarker=.03} \\ +\comptype{102 help graph \pipe lprint} \\ +\comptype{103 history} \\ +\comptype{cl>} +\end{quotation} + +\noindent +and note that this number (\emphasize{n}) will become the new default. +If you ask for a negative number of commands (\emphasize{-n}), +the default will not change. + +The \usertype{history} command allows previous command sequences to be +displayed, but a related mechanism must be used to re-execute, or to +edit and execute, commands. You can use the history file \emphasize{editor} +by issuing the command \usertype{ehistory}. Once you are in the history editor, +the cursor (arrow) keys can be used to move about in the history file. You +may select any command and edit it using the simple edit commands described +previously (\S 3.2.3) for the \taskname{eparam} task. Such functions as +deletions and insertions of words or characters, delete to end of line, and +a simple string search and replace capabilities are provided. +The Appendix lists the full range of commands that are supported. +The edited command is executed by hitting +\key{RETURN}. Note that it is a \emphasize{new} command and, as such, it is +appended to the history file. The current contents of the history file +are not changed. + +It is possible to recall \emphasize{individual} commands and edit them; +the special character `\upa' or the \usertype{ehistory} command may be +used for this. Given the history record sequence shown above, +any of the following commands could be used to fetch command 101: + +\begin{quotation}\noindent +\begin{tabbing} +\comptype{cl>} \usertype{\upa 101} \hspace{2cm} \= \#~fetch~command~101 \\ +\medskip +\comptype{cl>} \usertype{ehist -3} \> \#~fetch~third~command~previous \\ +\medskip +\comptype{cl>} \usertype{\upa ur} \> \#~fetch~command~starting~with~``ur'' \\ +\medskip +\comptype{cl>} \usertype{ehist ?mark?} \> \#~fetch~command~containing~``mark'' +\end{tabbing} +\end{quotation} + +The history command \usertype{\upa ur} finds the last command +\emphasize{beginning} with the string ``ur'', while the command +\usertype{ehist ?mark?} finds the last command \emphasize{containing} the +string ``mark'' (the trailing `\usertype{?}' is optional if it is the +last character on the line). A single `\upa' fetches the last command +entered. Successive `\upa' commands +will fetch the next preceding command lines from the history file. + +The selected command is echoed on the screen, with the cursor pointing at it. +At that point, the command can be executed just by typing \key{RETURN}, +or it may be edited. The standard set of editor operations also apply +when you edit a command in single line mode. Note that compound statements +(those enclosed in pairs of braces~``\{~$\ldots$~\}'') are treated as a +\emphasize{single} statement by the editor. Only one command line (which may +be a compound statement) can be edited at a time with the history editor. + +Sometimes you will want to reuse the \emphasize{arguments} of a previous +command. The notation `\upa\upa' refers to the \emphasize{first} argument +of the last command entered, `\upa\$' refers to the \emphasize{last} argument +of the command, `\upa$*$' refers to the whole argument list, `\upa0' refers +to the taskname of the last command, and `\upa$N$' refers to argument +\emphasize{N} of the last command entered. Thus, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{dir lib\$$*$.h,home\$login.cl} \\ +\comptype{cl>} \usertype{lprint \upa\upa} +\end{quotation} + +\noindent +displays a table of the files specified by the template, and then prints +the same files on the line printer. + +One of the most useful features of the history mechanism is the ability to +repeat a command with additional arguments appended. Any recalled command +may be followed by some extra parameters, which are appended to the command. +For example: + +\begin{quotation}\noindent +\comptype{ut>} \usertype{urand 200 2 \pipe graph po$+$} \\ +\comptype{ut>} \usertype{\upa\upa title = '200 random numbers'} \\ +\comptype{urand 200 2 \pipe graph po$+$ title = '200 random numbers'} +\end{quotation} + +\noindent +in this case, the notation `\upa\upa' refers to the last +\emphasize{command} entered. +The notation is unambiguous because the `\upa\upa' appears at the start of +the command line. Do not confuse it with the use of `\upa\upa' to reference +the first argument. + +\subsection{Foreign Tasks} + +\ppind +The foreign task mechanism provides an alternative to the OS escape mechanism +for sending commands to the host operating system. The advantage of the +foreign task mechanism is that it allows foreign commands to be made available +within the IRAF environment just as if they were normal IRAF tasks. +Such commands may be abbreviated, their output may be redirected or piped, +the commands may be run in batch mode, and the argument list is parsed and +evaluated by the CL, hence may contain any valid CL expression. Users should +beware, however, that IRAF virtual filenames appearing in the argument list +of a foreign task are not normally translated to their host equivalents, since +IRAF knows nothing about the argument list of a foreign task +(the \taskname{osfn} intrinsic function may be referenced in the argument +list to explicitly perform the translation, if desired). + +To declare several foreign tasks with the same names in IRAF as in the host +environment, use the following form of the \taskname{task} statement: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{task \$mail \$grep $=$ \$foreign} +\end{quotation} + +\noindent +This declares the new tasks \taskname{mail} and \taskname{grep} in the current +package, whatever that may be. If the current package is subsequently exited, +the task declarations will be discarded. + +To declare a foreign task with a more complex calling sequence, use the +following form of the foreign task declaration: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{task \$who $=$ "\$show users"} +\end{quotation} + +\noindent +This example would be used on a VMS host to map the IRAF foreign task +\taskname{who} to the VMS command \usertype{show users}. If there are +any arguments on the command line when the task is called, they will be +converted to strings and appended to the command prefix given. + +The \filename{LOGIN.CL} file contains a default \filename{USER} package +containing examples of several foreign task statements which may prove +useful on the local host. Users should feel free to modify or extend +the \filename{USER} package, since it is provided with that in mind and +provides a convenient structure for personalizing the CL environment. + +\subsection{Cursor Mode} + +\ppind +Whenever an IRAF program reads the graphics or image display cursor, +the cursor lights up or starts blinking, indicating that the user should +position the cursor and type a key on the terminal to return the cursor +position, keystroke typed, and possibly a character string entered by +the user, to the calling program. The user may also read the cursor +directly, just as a program would. For example, the command + +\begin{quotation}\noindent +\comptype{cl>} \usertype{$=$gcur}\\ +\smallskip +\comptype{345.21 883.13 1 r} +\end{quotation} + +\noindent +would read the graphics cursor, printing a cursor value string such as that +shown noting the world coordinates of the cursor, the world coordinate system +(WCS) of reference, the keystroke typed to terminate the cursor read, and +the string entered by the user if the key typed was \usertype{:} (colon). + +The CL is said to be in \emphasize{cursor mode} whenever the CL is waiting +for the user to type a key to read a cursor. Cursor mode reserves the upper +case keystrokes for itself, providing all sorts of useful functions to the +user via the reserved keystrokes. For example, the graphics display can be +zoomed or panned, a hardcopy of the current screen can be made on a hardcopy +device, or the screen can be saved in or restored from a graphics metafile. +For more information on cursor mode, type \usertype{help cursors} while in +the CL. + +\subsection{Background Jobs} + +\ppind +The CL provides facilities for manipulating and displaying data and +allows interactive development and use of data analysis functions. However, +many fully developed image analysis scenarios are very time consuming +and need not be run interactively. IRAF allows such functions to +be developed interactively and then processed in a batch mode as +a background task, thus freeing the terminal for other interactions +once the background tasks have been started. Several +background tasks can be running at once, and these may be identical +tasks that are just operating on different data sets. + +Any command, including compound commands that may involve calls to several +tasks, may be executed in the background by appending the ampersand character +`\&' to the end of the command block. The CL will create a new control +process for the background job, start it, display the job number of the +background job, and return control to the terminal. +Background job numbers are always small integers in the range 1 to n, +where n is the maximum permissible number of background jobs (typically 3-6). + +\begin{quotation}\noindent +\comptype{pl>} \usertype{contour m92 dev=stdplot \&} \\ +\comptype{[1]} \\ +\comptype{pl>} +\end{quotation} + +\noindent +If a task runs to completion, and if the CL \irafname{notify} parameter +is enabled (the default), the message +``\comptype{[n] done}'' will be printed on your +terminal when the task completes. + +Jobs running in the background may use all of the commands and +perform any of the operations that interactive tasks can, but +extensive user interaction with background jobs is necessarily +somewhat limited (and not too appropriate). +Another difference is that background jobs \emphasize{do not} update +parameter \filename{.PAR} files. This is done to minimize the +confusion that could occur if a background job asynchronously +updated the parameter set for a task that was running interactively, +or vice versa. The implication of this is that parameter values that +are to be output by a task running in the background must be explicitly +written into a file if they are to be available outside that job. +Parameters passed between tasks in the same job are still processed +correctly. + +If the background job writes to the standard +output, and the standard output has not been redirected, the output of +the background job will come out on your terminal mixed in with the output +from whatever else you are doing. Since this is generally not desirable, the +\filename{STDOUT} (and \filename{STDERR}) +for the background job should probably be redirected to a +file and perused at a later time. The following example computes image +statistics and directs these, and any error messages, to the file +\filename{STATS.TXT}: + +\begin{quotation}\noindent +\comptype{im>} \usertype{imstatistics m87 $>$\& stats.txt \&} \\ +\comptype{[2]} \\ +\comptype{im>} +\end{quotation} + +If during the processing of a background job, the job finds it necessary to +query for a parameter, the message + +\begin{quotation}\noindent +\comptype{[1] stopped waiting for parameter input } +\end{quotation} + +\noindent +will appear on your terminal. It is not necessary to respond to such a +request immediately; when a convenient point is reached, respond with: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{service 1} +\end{quotation} + +\noindent +The prompt string from the background job will be printed, just as if +you were running the job interactively. Respond to the query and the +background job will continue executing. If you do not respond to the request +for service from a background job, it will eventually time out and abort. + +More control over the disposition of a batch job is possible by appending +optional arguments to the \usertype{\&} at the end of the command line, +when the job is submitted. The default action if no arguments are appended +is to run the job as a subprocess of the CL, at a priority level one less +than the CL, with output coming to the terminal unless redirected. +To run the job as a subprocess at a specific priority, a numeric string +specifying the \emphasize{host dependent} priority level may be added after +the \usertype{\&}. For example, + +\begin{quotation}\noindent +\comptype{cl>} \usertype{bigjob \&4} +\end{quotation} + +\noindent +will submit the job at host priority level 4. The priority level may also +be specified relative to the CL priority in a machine independent way, +e.g., \usertype{\&-1} will submit the job at a priority level one notch +down from the current CL priority (this is the default). + +On systems which support batch queues (e.g., VMS) jobs may also be submitted +to a batch queue. To submit a job to a batch queue, simply add the name of +the queue after the \usertype{\&}, e.g.: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{bigjob \&fast} +\end{quotation} + +\noindent +will submit the job to the "fast" queue. IRAF supports three logical batch +queues, the \usertype{fast} queue, for short jobs to be run at a high priority, +the \usertype{batch} queue, for medium size jobs, and the \usertype{slow} +queue, for big jobs that may run a long time. The host system name of the +desired queue may also be given. If a big job is submitted to a high priority +queue it will be killed by the system when it exceeds the maximum quota +permitted for that queue; see your system manager for more information on +the batch queues supported by your system. + +Sometimes it is desirable to wait for a background job to complete before +resuming interactive work. For example, you might reach a point where +you cannot proceed until the background job has finished writing a file. +The \usertype{wait} command is used to wait for currently running +background tasks to complete. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{wait 1; beep} +\end{quotation} + +\noindent +will halt the interactive session until background job 1 completes. Issuing +a \usertype{wait} command without a job number will cause the interactive +session to wait for \emphasize{all} background jobs to complete. + +In order to discover the status of all background jobs that you +have running, the command: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{jobs} +\end{quotation} + +\noindent +may be used. The job number will be displayed along with information +about the command that was used to start the job. +The command \usertype{spy v} may also be used. It will request the host +operating system to display the processor status (in an OS-dependent form), +including information on the status of all processes running on the system. + +There are important differences in the behavior of background jobs on different +IRAF host systems. Under UNIX, the background tasks are independent of +activities that may (or may \emphasize{not}) be going on interactively. +UNIX users may terminate their IRAF session and even logoff the UNIX system +altogether, and the background jobs will continue merrily along. +In the VMS implementation of IRAF, background jobs may run either as +sub-processes or as regular VMS batch jobs in one of the system wide batch +queues. The default is to run background jobs as sub-processes, in which +case the jobs will be killed if you log out of VMS (even if you have DETACH +priviledge). Under \emphasize{both} systems, once the interactive CL session +is terminated, communication with still-running background jobs +\emphasize{cannot} be re-established, even by re-entering the CL. + +\subsection{Aborting Tasks} + +\ppind +Any interactive task may be aborted by typing the interrupt sequence +\key{CTRL/C}. +Control will return to the point at which the last interactive command was +entered. When an IRAF program run from the CL is interrupted, it will +usually perform some cleanup functions, deleting partially written files and +so on. If an error (or another interrupt) should occur during error recovery, +IRAF will issue the following message: + +\begin{quotation}\noindent +\comptype{PANIC: Error recursion during error recovery} +\end{quotation} + +\noindent +A panic abort is usually harmless, but may result in some half-written +dregs of files being left behind. A more serious problem occurs when +a subprocess becomes hung (uninterruptable). Repeatedly interrupting the +CL when this occurs will eventually cause the CL to give up and shut down, +necessitating a restart. A quicker solution might be to use the host system +facilities to forcibly kill the subprocess. + +The \usertype{kill} command may be used to abort a background job. The +argument is the logical job number printed by the CL when the background +job was spawned. (It may also be a list of jobs to be killed.) + +\begin{quotation}\noindent +\comptype{cl>} \usertype{kill 1} \\ +\medskip +\comptype{cl>} \usertype{kill 1 3} +\end{quotation} + +In systems that support batch queues as well as sub-processes, +the \usertype{kill} command may be used to control these as well. + +%######################### +\newpage +\thispagestyle{empty} + +\begin{center} \vspace*{1in} +\large NOTE +\end{center} +\vskip 1cm +\rm + +The remainder of this document is from the original draft and has not yet +been brought up to date and may contain minor inaccuracies or omissions. + +\newpage +\section{The CL as a Programming Language} + +All of the examples that have been presented thus far treat the use +of the CL as a \emphasize{command language} for running existing tasks. +The CL can also be used as a high-powered desk calculator, one that +can operate on and display arrays of data as well as scalars; +and that can be fully programmed. +The following sections introduce the programming oriented functions +that are provided in the CL as background for understanding +the creation of new user tasks. + +Extensive use of the CL as a programming language has not been heavily +emphasized, because there are substantial performance penalties +associated with the use of interpreted languages, especially when +dealing with large amounts of data. At the same time, the availability +of an interactive environment that allows easy exploration of +alternative analysis scenarios is very attractive, since it largely +does away with the typical development cycles of edit; compile; link; +test; edit; compile; $\ldots~$. Interactive development provides +immediate, possibly visual, feedback about the effect of the various +analytical tools upon your data. + +Before delving into the details of the language however, a comment is in +order regarding the distinction made in the CL between +\irafname{command mode} and \irafname{program mode}. +\emphasize{Modes} in user interfaces are not in vogue +because of the potential source of confusion, the "How does that command +work now?" problem. IRAF is a little schizoid in this regard because of the +desire for convenient user commands on the one hand: (to minimize +the need for specific command parameter delimiters, +quotes around character strings and special handling of +file names and meta-characters); and the desire for +a familiar language syntax for programming type activities on the other. + +To resolve this dilemma, the CL has two modes: \irafname{command mode} - +which is the default and is used for most terminal interactions; and +\irafname{program mode} - which is: + +\begin{itemize} +\item Entered within the body of a procedure. +\item Entered within parenthesized expressions. +\item Entered on the right-hand side of an equal sign ('='). +\end{itemize} + +\noindent +The syntax of the CL2 programming language was chosen to be as +compatible as possible with SPP, the portable language in which +most of IRAF is written. + +Aspects of the command/program dichotomy have +already crept into the discussions of identifiers, which are treated +as character strings in command mode (\S 4.3.1), but which will be +evaluated as a parameter name if thay are enclosed in parentheses. +In the same vein, when inserted in a parenthesized expression, +an identifier that is handled as a character string +in command mode will be treated as a variable name unless it is quoted. + +In program mode there is a simple disambiguating rule that can be safely +used: always quote character strings and always parenthesize expressions. +While this resolves the ambiguity it is not likely to be too popular +with most users, who typically choose a minimum entropy approach. +In the following sections, where programming issues come under +discussion, programming mode will be assumed as the default. + +\subsection{Expressions in the CL} + +The CL has a conventional modern expression syntax (borrowed heavily +from C and Ratfor) which should feel familiar to most +users. The following operators are provided, presented in order of +precedence: + +\begin{tabular}{ll} +{\it Operator} & {\it Action} \\ + +$**$ & exponentiation \\ +$*, /$ & the usual arithmetic operators \\ +$+, -$ & and the rest of them in precedence order \\ +$//$ & string concatenation \\\ +\&, {\tt ||} & and, or \\ +! & not \\ +$<$, $<=$ & less than, less than or equals \\ +$>$, $>=$ & greater than, greater than or equals \\ +$!=$, $ ==$ & not equal, equal (2 equal signs) + +\end{tabular} + +\noindent +Parentheses may be used to alter the default order of evaluation of an +expression. Quotes are not optional in expressions or anywhere inside +parentheses; identifiers are assumed to be the names of parameters and +strings \emphasize{must} expressly be quoted using either single +or double quotes. + +The data types supported by the CL +are \emphasize{boolean, integer, real, char}, and several exotic types +(\emphasize{imcur, gcur,} and \emphasize{file}) that are touched upon +later in this section. Observe that although the CL has \emphasize{no} +complex datatype, operations on complex data is supported in the rest +of the IRAF system, including the \irafname{SPP} language and +interface libraries. +Arrays of the regular data types of up to seven dimensions are supported. +Explicit type conversion is implemented with the intrinsic functions +\emphasize{int, real}, and \emphasize{str}, +the last converting an argument of any data type into a string. +Mixed-mode expressions involving integers and reals are permitted, +the data type of the result is promoted to the type of the target +of the assignment operator. + +The CL provides a special statement, called the \emphasize{immediate} +statement, for evaluating expressions +and printing the value at the terminal. The form of the statement +is an expression preceded by an equals sign: + +\begin{quotation}\noindent += {\it expression} +\end{quotation} + +\noindent +or, if you prefer, the more conventional and more general \usertype{print} +command can be used with the same results: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{print (}{\it expression} [, {\it expression}, + $\ldots$ ] \usertype{)} +\end{quotation} + +\subsection{CL Statements and Simple Scripts} + +This is not a language reference manual; nonetheless, +you will find it helpful to understand a few of the more useful +types of statements provided in the CL. +We will not attempt to present a +complete definition of the syntax of the command language, +a compendium of basic statement types is listed in the Appendix. +The preceding section introduced two statements, +the \emphasize{immediate} statement and the \emphasize{print} statement. +The \emphasize{assignment} statement should also be familiar from +previous examples. + +Often we do not want simply to assign a value to a parameter, +but rather we want to increment, decrement, or scale one. +These operations can all be performed with assignment statements +in the CL, using the assignment operators \pluseq, \minuseq, \timeseq, +\diveq, and \concateq. For example, to increment the +value of a parameter, we could use the \pluseq~ assignment statement: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{y \pluseq {} (x $**$ 2)} +\end{quotation} + +This statement increments the CL parameter \usertype{y} +by the value of the expression \usertype{(x$**$2)}. The same +operation could also be done with the next statement, but with some +small increase in typing effort. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{y = y $+$ (x $**$ 2)} +\end{quotation} + +\noindent +The advantage of having a shorthand notation becomes obvious +when you contemplate doing arithmetic on a fully specified +parameter name as in the next examples. + +\subsubsection{Assigning Values to Task Parameters} + +The assignment statement may be used to set the value of a parameter +or a variable. +Most parameters are local to some task, and a ``dot'' notation may +be used to unambiguously name both the task and the parameter. +Thus, the statement: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{delete.verify = yes} +\end{quotation} + +\noindent +may be used to set the value of the \taskname{verify} parameter +belonging to the task \taskname{delete}. Since verify is a hidden +parameter, direct assignment is the only way to permanently change +this option setting. + +The task \taskname{delete} belongs to the \taskname{system} package. +Since IRAF permits several packages to be loaded at the same time, +if there happened to be another task named \taskname{delete} in the +search-path, we would have to specify the package name as well to make +the assignment unambiguous: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{system.delete.verify = yes} +\end{quotation} + +\noindent +In the unfortunate situation of two tasks with the same name in different +packages, we would also have to specify the package name explicitly +just to be able to \emphasize{run} the task: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{system.delete {\it files}} +\end{quotation} + +\noindent +In most cases such name collisions will not occur. + +The ability to have +the same task names in more than one package has some very positive +benefits however, in that a new package of tasks that has the +same calling conventions as a standard one may be readily inserted +in the search path. This allows new algorithms to be tested without +impacting the standard system, and also provides the hooks whereby +alternate implementations of existing functions (using an array processor +for instance) can be dynamically linked into the system. + +\subsubsection{Control Statements in a Script Task} + +The CL provides \emphasize{if, if else, while, for, next}, and +\emphasize{break} statements for controlling the flow +of execution in a command sequence. These statements +are quite useful for writing control loops at the command +level. Other control statements (\emphasize{case, switch,} and +\emphasize{default}), which may be familiar from C or RATFOR, +are also provided to ease the programming effort. +By way of example, to print the values of the first ten powers +of two the following statements can be used: + +\begin{quotation}\noindent\comptype{ +cl> i=1; j=2\\ +cl> while (i $<=$ 10) \{\\ +>>> print (j)\\ +>>> j \timeseq {} 2\\ +>>> i \pluseq {} 1\\ +>>> \}} +\end{quotation} + +\noindent +The second of these two statements is a compound statement; +note that the prompt has changed to \comptype{>>>} to indicate this. + +Consider the parenthesized argument list in the \usertype{print} +command in the above loop. +If the parameter (\usertype{j} in this example) were not enclosed in +parentheses, the CL would interpret it as a string rather than a parameter, +and would erroneously print ``\comptype{j}'' each time through the loop. +Remember that the CL will interpret identifiers as a string if found +outside parentheses, but as the name of a valid parameter or variable +inside parentheses. If the CL cannot find the identifier in its +dictionary an error message will be issued. +To avoid nasty surprises like this, one should \emphasize{always} +parenthesize argument lists in loops and within script tasks, and +make a habit of explicitly quoting items that are to be treated as +strings. + +The example uses the built-in CL variables \usertype{i} +and \usertype{j}. A number of variables are provided in the CL for +interactive use; the integer variables provided with the CL +are \usertype{i,j,k}; the real variables are \usertype{x,y,z}; +the string variables are \usertype{s1,s2,s3}; the booleans are +\usertype{b1,b2,b3}; and a list-structure pointer called +\usertype{list} is also provided. +The CL also has the ability to define new variables interactively; +which is discussed in section \S 6.4. + +\subsection{Intrinsic and Builtin Functions} + +The usual Fortran intrinsic functions +(with the exception of the hyperbolic and complex functions) +are provided in the CL, along with some others specific to IRAF. +The other intrinsic and builtin functions are those like +\usertype{set}, \usertype{if}, \usertype{while}, \usertype{case}; +the data declaration and initialization statements; and the +task and I/O control statements that are described throughout +the body of this document, and are listed in Appendix A. The intrinsic +functions \emphasize{must} be used in a statement where the returned +value is explicitly assigned or output in some way. +To compute (and display) the value of \usertype{sin(x)}: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{= sin(x)} +\end{quotation} + +\noindent +must be entered, just typing \usertype{sin(x)} by itself is an error. +The names of intrinsic functions may be used in other contexts, e.g. as +parameter names, but care is needed to avoid confusion. + +\begin{tabular}{lll} +{\it Function} & {\it Action} & {\it Example} \\ + abs & absolute value & z = abs(x) \\ + atan2 & arctangent & r = atan2(y, x) \\ + cos & cosine & x = cos(r**2) \\ + exp & exponentiation & z = exp(3) \\ + frac & fractional part of a number & i = frac(y) \\ + int & convert input to integer & j = int(z*3) \\ + log & natural logarithm of a number & x = log(z) \\ + log10 & base 10 logarithm of a number & y = log10(x) \\ + max & maximum value from input & x = min(1,17.4,43) \\ + min & minimum value from input & y = max(47,11,92.3) \\ + mod & modulus & z = mod(x, {\it base}) \\ + radix & radix to any base & y = radix(x, {\it base}) \\ + real & convert input to real & x = real(i) \\ + sin & sine & y = sin(3*r) \\ + sqrt & square root & z = sqrt(x**2 + y**2) \\ + str & convert input to a string & s1 = str(num) \\ + stridx & index of character in string & i = stridx(s1, 'abc') \\ + substr & select substring from string & s1 = substr(s2, 3, 7) \\ + tan & tangent & x = tan(2*theta) +\end{tabular} + +As examples of the use of these functions, try entering the following +expressions and see if you can predict the results +(the next sections have the clues): + +\begin{quotation}\noindent +\comptype{cl>} \usertype{= (sin(.5)$**$2 + cos(.5)$**$2)} \\ +\smallskip +\comptype{cl>} \usertype{= 2 / 3.} \\ +\smallskip +\comptype{cl>} \usertype{= (mod (int(4.9), 2) $==$ 0)} \\ +\smallskip +\comptype{cl>} \usertype{= 'map' // radix (512, 8)} \\ +\smallskip +\comptype{cl>} \usertype{= delete.verify} +\end{quotation} + +\noindent +You may have been surprised that the result of the last example was +\comptype{no}. This is because \usertype{verify} is a boolean +parameter which can only take on the values \emphasize{yes} and +\emphasize{no}. + +\irafname{CL++} \\ +All of the intrinsic functions in IRAF return a value, the builtin +tasks currently do not. With the completion of changes to the CL +that are now in progress, intrinsics and builtin tasks, and any user defined +functions or tasks may return an optional value. Tasks can thus be +called either in the FORTRAN 'subroutine' style or in the 'function' +style, where a value is expected. If a task returns a value that is +not assigned to a variable it will be silently ignored. + +\subsection{Defining New Variables and Parameters} + +The CL provides a default set of variables that can be used for scratch +computations, and you may declare other variables as needed. +Each task that is invoked, whether it is a CL script task +or an external executable task, may have input or output parameters +associated with it, and these may be defined within the package for the +task or as part of the task itself. Data declarations +for variables contain the item name and type information, +and may also contain an optional initialization clause. Declarations +for function parameters are identical to those for variables, but they +may contain optional fields to specify prompt strings, to define a valid +data range, or to enumerate a list of valid values. + +The simplest data declarations define local or global variables. +The statement: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{int int\_var} +\end{quotation} + +\noindent +defines a simple integer variable. If this command is entered at the root +(\comptype{cl>} prompt) level, it will define a variable that is globally +accessible to any other task that is executed. When the same statement +is incorporated into the body of a script task (after the \usertype{begin} +statement), it will define a local variable visible only to that script task or +to any other task that is called by that script task. Variables declared within +the body of a package definition are globally available to all tasks +within that package, but will be removed from the set of +addressable variables when that package is unloaded. + +User-defined variables may be used just like any standard IRAF +variables: in expressions, passed as parameters to +other tasks, or displayed in a variety of ways. In addition, +these variables may be initialized when they are declared: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{real e = 2.71828183 } +\end{quotation} + +\noindent +establishes a real variable and assigns it an initial value. +This variable may be treated like a constant (as in this case) +or may be re-assigned another value during the course of computations. + +The formal \taskname{parameters} for a task must be defined if the CL +is to provide any of the range checking or input prompting activities. +In the absence of a declaration, or if one is provided that +does not define these optional fields, only the name of the parameter +will be used for prompting and no range checking can be performed. +The simplest case of a \emphasize{parameter} declaration looks just like the +simple variable declaration shown above; but it must +occur within a task body \emphasize{before} the \usertype{begin} statement, +or define a parameter that is named in the calling list for a task. + +The syntax of a data declaration statement is: + +\begin{quotation}\noindent +\begin{tabular}{lll} +\comptype{cl>} {\it type} & [{\it = initializer} [,{\it initializer}] $\ldots$ ] \\ + & \{ \\ + & [{\it initializer} [,{\it initializer}] $\ldots$ ] \\ + & [{\it opt\_field=value} [,{\it opt\_field=value}] $\ldots$ ] \\ + & & \} +\end{tabular} +\end{quotation} + +\noindent +where the valid data types for these declaration statements are shown in +the following table: + +\begin{tabular}{ll} +{\it Data Type} & {\it Explanation} \\ +int & integer (scalar and array) \\ +real & double precision floating point (scalar and array) \\ +char & character strings (scalar and array) \\ +bool & boolean, yes/no (scalar and array) \\ +file & file name \\ +struct & special form of mutli-token string \\ +gcur & graphics cursor struct \\ +imcur & image cursor struct +\end{tabular} + +Most of these data types should be familiar to you, but the IRAF +\irafname{struct} is a special class of data element that is used to +hold multi-token strings, mostly for input. It will be referred to again +in the section on I/O facilities in the CL (\S 6.8). \irafname{Gcur} +and \irafname{imcur} are both structs that return a multi-token result, +namely a string with RA, DEC and a data value. List structured parameters, +which are described in section \S 6.9 are typically declared as +structs. + +The optional fields in a data declaration are used to define the data +ranges for checking, prompt strings, special file type information, +or a list of enumerated items. +Syntactically, the specification of these optional fields is treated +like a special form of initialization; the valid field names are +described in the following table. + +\begin{tabular}{ll} +{\it Field Name} & {\it Explanation} \\ +mode & auto, query, hidden processing modes \\ +min & minimum value for range checking \\ +max & maximum value for range checking \\ +enum & enumerated list of valid responses (mutex with min/max) \\ +prompt & prompt string for undefined values \\ +filetype & r, rw, w, x file type specification +\end{tabular} + +\noindent +All of these fields are optional, the \irafname{mode} defaults to +\irafname{auto}; \irafname{min/max} range checking defaults to NULL; +and \irafname{filetype}, which is valid only for files, defaults to +read only (\irafname{'r'}). The enumerated type (\irafname{enum}), +which names the specific responses that are acceptable, is +mutually exclusive with range checking, which defines a continuum +of values that will be accepted. + +To declare an integer parameter, enable range checking for positive +values and provide a prompt string, use: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{int new\_parm \{ min=0, prompt='Positive integer' \} } +\end{quotation} + +\noindent +and as an example of an +enumerated list of valid input values, consider: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{char color \{enum = 'red \pipe green \pipe blue'\} } +\end{quotation} + +\noindent +which defines a default length character string that is initially undefined +and that has an enumerated list of three valid input values. +If you attempt to use the variable \usertype{color} before a value has +been assigned to it, you will be prompted for a value. +If you try to assign it a value other than one of those that +are enumerated, an error is reported. + +\subsection{Declaring Array and Image Data} + +Variables and task parameters may be defined as arrays of any of the +data types: int, real, char or bool. Arrays may have up to seven dimensions. +Array and image data will be referenced identically in the future, +but for now there +are some differences that are worth noting. Images are treated +as large arrays of data that are stored on disk, +and it is the amount of data to be +processed that determines the choice of storage mechanism. Images +will typically be quite bulky; it is not unusual for a single image +scene to involve five to ten megabytes of data. For this reason, image data +are most efficiently stored in disk files, and operations upon the +data are performed by buffering it into memory as needed. The +\emphasize{main difference} between an array of data and an image is that +the image will be buffered on disk. + +IRAF provides a default \filename{IMDIR} directory that may be used for +bulk image file storage by all users, but it also has facilities that +manage the storing, copying, and accessing of such data sets for users who +wish to store this sort of data in their own directories. +The logical directory \filename{IMDIR} is where the IRAF system will store +your image data \emphasize{by default}. IRAF images will appear to be created +in your local user directory, but in fact it is only the \irafname{image +header file} which goes there. The bulk pixel data are +put in a second file that is part of a temporary files +system, configured and managed with large datasets in mind. Such +\irafname{pixel storage files} are transparent to the user, but if you have a +great deal of data, you may find it more efficient to set up your own directory +on a temporary files system, and to redefine \filename{IMDIR} accordingly. +If one has a personal \filename{IMDIR}, it is also convenient to save data on +tape and later restore it to disk; the header files are usually small +enough so that they need not be archived if the data is going to be restored +within a week or two. + +To declare an integer array of length 100, type: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{int iarray[100] = 100(0)} +\end{quotation} + +\noindent +which also initializes the array \usertype{iarray} to zero. A two dimensional +array with data range checking can be specified by: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{real rarray[50, 50] \{ min=0, max=100 \} } +\end{quotation} + +\noindent +This array could be defined as an image by using the following declaration +to indicate the different \emphasize{storage class} of the data: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{real image rarray[50, 50] \{ min=0, max=100 \} } +\end{quotation} + +\noindent +where the data in this example would be stored on disk. + +The choice of whether data is to be stored +in an array which is stored entirely in memory, +or as an image on disk is up to the user. +The choice should be predicated upon the +amount of data that is to be manipulated, since speed and efficiency +of operation will be better using the image mode for data arrays +much larger than a few hundred items. At present, the +statements that manipulate these two data forms are somewhat different, +as is explained in the following section. + +During the development of IRAF, the handling of images has +been a prime concern, representing as it does the major computational +and I/O load that must be accomodated. Image files currently +may be created on disk, and there are image processing functions that +know how to process this class of data. The IRAF packages +\taskname{images, imred}, and \taskname{plot} currently +handle image data. +The specification of this processing is similar, but +not identical to, the operations performed on array data. +The next section discusses use of image data and arrays within the CL. + +\irafname{CL++} \\ +At the present time the \irafname{IMIO and DBIO} subroutine libraries +are still undergoing design and enhancement. As a result of this effort, +the processing of image type data is not yet in final form. Existing IRAF +packages do support image processing and display +functions and these will appear to be functionally the same after the +development has been completed. The SDAS packages also support image +processing and display functions, but at this point in time the disk +format of these two types of data is vastly different, +and on this interim system, data from these two packages +cannot easily be mixed. This incompatibility is to be rectified when +the completed \irafname{IMIO and DBIO} libraries are available. + +\subsection{Processing of Image Sections} + +All IRAF programs which operate upon images may be used to operate on +the entire image (the default) or any section of the image. +A special notation is used to specify \irafname{image sections}. The section +notation is appended to the name of the image, much like an +array subscript is appended to an array name in a conventional programming +language. Note that array or image section \emphasize{index references} +are integer only, but that the data may be of any valid type. + +\begin{quote} +\begin{tabular}{ll} +{\it section}& {\it refers to}\\ +\\ +pix& whole image\\ +pix[]& whole image\\ +pix[i,j]& the pixel value (scalar) at [i,j]\\ +pix[$*$,$*$]& whole image, two dimensions\\ +pix[$*$,-$*$]& flip y-axis\\ +pix[$*$,$*$,b]& band B of three dimensional image\\ +pix[$*$,$*$:s]& subsample in y by S\\ +pix[$*$,l]& line L of image\\ +pix[c,$*$]& column C of image\\ +pix[i1:i2,j1:j2]& subraster of image\\ +pix[i1:i2:sx,j1:j2:sy]& subraster with subsampling +\end{tabular} +\end{quote} + +\noindent +In the following examples, please note that the references to image +sections are all enclosed in quotes. These are \emphasize{required} +by the present language syntax. As the note at the end of this +section indicates, this rule is to be relaxed in future. + +A limited set of coordinate transformations may be specified using image +sections, but please observe that transpose is \emphasize{not} one of them. +The ``match all'' (asterisk), flip, subsample, index, and range notations +shown in the table may be combined in just about any way that makes sense. +As a simple example: + +\begin{quotation}\noindent +\comptype{pl>} \usertype{graph 'pix[$*$,10]'} +\end{quotation} + +\noindent +will graph line 10 of the image \usertype{pix}. +To generate a contour plot of an 800-pixel square image +subsampled by a factor of 16 in both dimensions: + +\begin{quotation}\noindent +\comptype{pl>} \usertype{contour 'pix[$*$:16,$*$:16]'} +\end{quotation} + +\noindent +To display the fifth $x-z$ plane of a three dimensional image named +\usertype{cube}: + +\begin{quotation}\noindent +\comptype{im>} \usertype{display 'cube[$*$,5,$*$]', 1} +\end{quotation} + +\noindent +on frame 1 of the image display device. + +\irafname{CL++} \\ +The image processing sections of IRAF are undergoing further development, +as was noted in the previous section. Currently only image data +can be processed as shown in the previous examples. Future developments +will remove the need for quoting the section specifications that identify +the image portion to be operated upon. The functional specifications +will not change substantially, nor will the syntax itself be changed +in any important way, but the need to remember to quote image section +references will be removed. Image data will continue to be +stored on disk and passed among tasks by passing the \emphasize{name} +of the file rather than passing the data itself, as a matter of efficiency. + +\subsection{Array Processing in the CL} + +The processing of \emphasize{array} data is handled directly in the CL, +and data arrays may also be passed to script tasks and external tasks. The +entire array will be passed, since the CL cannot yet handle passing of +sub-arrays to other tasks. The operations on arrays are handled via +implicit looping over the array expressions, and only some of the +operations described in the previous section on image data are valid +for array data. References to array data sections need not be quoted +however, and the syntax is otherwise identical to that supported for +images. + +Given the declaration: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{real a[10], b[20], c[10,20], d[10,20,30], e[10,10] +} +\end{quotation} + +\noindent +the following expressions are legal: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{c = 10} \hfill \#~sets~all~elements~of~c~to~10 \\ +\comptype{cl>} \usertype{a = c[*,1]} \hfill \#~copies~row~1~of~c~into~a \\ +\comptype{cl>} \usertype{= b} \hfill \#~prints~all~values~of~b \\ +\comptype{cl>} \usertype{a = b[1:10] } \hfill \#~copies~subrange~of~b~into~a \\ +\comptype{cl>} \usertype{c = d[*,*,1] } +\end{quotation} + +\noindent +and the following expressions are illegal: + + +\begin{quotation}\noindent +\comptype{cl>} \usertype{a = c} \hfill \#~different~dimensionalities \\ +\comptype{cl>} \usertype{a = c[1,*]} \hfill \#~different~limits~on~assign \\ +\comptype{cl>} \usertype{a = b[11:20]} \hfill \#~different~limits +\end{quotation} + +In general, for an expression to be a legal array expression in the +CL, all array references must either be completely specified +(i.e. \usertype{d[1,2,3]}), or they must loop over the same set of indices +(i.e. \usertype{a = b[1:10]}). Indices may be +specified as just the identifier (\usertype{a} or with an +asterisk as the index (\usertype{b[*]}), indicating the entire array; +or as a subrange specified by \emphasize{integer constants} separated +by a colon (\usertype{c[3:5]}). + +\irafname{CL++} \\ +Future developments in the CL will eliminate most of the restrictions +on array operation in the CL and will bring the syntax for operations +on images and arrays into complete alignment. + +\subsection{Input and Output within the CL} + +The CL provides I/O processing for parameters, cursor input and graphics +output, and controls communications to external tasks. The communications +that appear at the terminal in the form of prompts for parameters, +error messages, data range checking queries, and much of the other I/O +is performed in ASCII for portability considerations. The data items that +a user can input in response to a prompt may be: +integer values; floating point numbers, with or without exponent; +yes/no responses for boolean data; or character strings as appropriate. + +Image data and other bulk data forms that are processed by the various +functions are typically \emphasize{not} passed through +the CL itself, instead the names of the files are passed about, and +temporary files are dynamically created as needed to hold intermediate +results of computations. Cursor input from graphics and image devices +are passed directly through the CL however, in order that they may be +re-directed to a file like any other I/O stream. The \irafname{imcur} and +\irafname{gcur} structs are used to handle this type of data. + +As was mentioned in \S 2.4 and in the section on I/O and pipes (\S 3.3) +the CL communicates via its standard input and output, +which are ASCII streams normally connected to the terminal. The +CL functions that manipulate these streams can also be used on +data in a file, just as the CL itself can be driven with commands +from a file. The control files are all ASCII +data streams, with no implied structure, and thus are easy to construct +and to edit, should that be necessary. + +The \irafname{scan} and \irafname{fscan} functions are provided +in the CL to process ASCII input streams; +the only distinction between them is that \usertype{scan} operates +on the terminal input stream (or its re-directed source) and +\usertype{fscan} specifically operates on an file. \usertype{Scan} reads +from the terminal (there is no prompt) and returns the first token it +finds in its input stream; where a token is understood to be any string +of alphanumeric characters delimited by a blank. Quotes are ignored +and no other punctuation has any special meaning. If a \key{CTRL/Z} +is entered EOF is signalled and the following +print statement will not be executed. + +\begin{verbatim} +cl> if (scan (s1) != EOF) +>>> print (s1) +>>> else +>>> return +\end{verbatim} + +The \usertype{print} command takes whatever is passed it as a parameter +and displays it on the terminal, so the previous example does a simple +one-line \emphasize{echo} function of input to output. The argument to +\usertype{scan} in this example is the character variable \usertype{s1}, +but it could as easily be an integer: + +\begin{verbatim} +cl> while (scan (i) != EOF) +>>> print ("Input was a ", i) +\end{verbatim} + +\noindent +This in-line script will continue looping, reading from the input and +echoing to the output, until EOF is signalled. All valid numeric inputs +will be accepted; real input values will be truncated to integers; +character constants (single characters) will be processed as though +\usertype{int} had been called; and any invalid input values will +be silently ignored. \usertype{Print} shows another of its features, +that string constants may be directly inserted into the output stream +and that \emphasize{no format} specifications need be made. + +The I/O functions can be used to process more than one data element +at a time, with no need for explicit formatting. If more data is +presented than there are identifiers in the list, the extra data +is silently ignored; and if there are more data elements in the +parameter list than there is data, +the remaining data elements retain their old values. + +The output or input for these functions can be explicitly redirected, +via the usual mechanisms, or the \irafname{fscan} and \irafname{fprint} +functions can be used instead. The commands: + +\begin{verbatim} +cl> list = 'infile' +cl> while (fscan (list, s1) != EOF) +>>> fprint ('junque', 'The next input line = ', s1) +\end{verbatim} + +\noindent +perform exactly the same function as: + +\begin{verbatim} +cl> list = 'infile' +cl> while (scan (s1, $<$list) != EOF) +>>> print ('The next input line = ', s1, $>>$ 'junque') +\end{verbatim} + +\noindent +where the list structured variable \usertype{list} has been set to the +name of the file to be used for input (\filename{INFILE}) and the +output is being directed to file \filename{JUNQUE}. +These examples are hardly exhaustive, but +will serve as background information for the discussion of list +structured parameters that follows. + +\subsection{List Structured Parameters} + +For certain data analysis tasks, the ability to define a \emphasize{list} +of data files for batch processing can be especially useful. IRAF +supports \irafname{list structured parameters} for specifying a list +of items to be input to a function. Many, but not all, functions +will accept this form of input. List structured parameters are +associated with a file and have their own peculiar, but useful, +semantics. + +Suppose we want to make a series of contour plots on the standard plotter +device of a set of data files. This can be done interactively by +entering a command to produce each plot, but this is tedious. A better +approach would be to prepare a list of image sections (see \S 6.6) to +be plotted, naming one section per line in a text file (which we choose +to call \filename{SECTIONS}). The following command could then be used +to generate the plots in the background: + +\begin{verbatim} +pl> list = 'sections' +pl> while (fscan (list, s1) != EOF) +>>> contour (s1, device = 'stdplot') \& +\end{verbatim} + +In this example, the assignment of \usertype{'sections'} to the +parameter \usertype{list} +has two actions, it associates the name of the file \filename{SECTIONS} +with the list structured parameter, and it causes a \emphasize{logical} +open of the file. The actual file open takes place the +first time that \usertype{fscan} is called. Successive calls to +\usertype{fscan} return successive lines from the file into the +string \usertype{s1}. When the end of file (EOF) is encountered +the \usertype{while} loop terminates. If additional calls are made to +\usertype{fscan} EOF will continue to be returned. A logical +reset to the top of the file can be performed by reassignment +of the same file name +to the parameter \usertype{list}, or another file name can be +associated with this parameter. + +A user can declare other list structured data elements besides the +ones that are provided. The statement: + +\begin{verbatim} +cl> struct *input = uparm\$inlist +\end{verbatim} + +\noindent +declares a list structured variable named input that is bound +to the list named \filename{UPARM\$INLIST}. This file may +contain several records that define image section specifications +or the names of other files to be processed. Once the declaration is +made, lines may be scanned from the file, as in previous examples, +or the records may be fetched by use of a simple assignment operator: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{= input} \hfill \# displays the next record from + file \\ +\comptype{cl>} \usertype{s1 = input} \hfill \# sets s1 to the next record +\end{quotation} + +\noindent +Successive references to the identifier \usertype{input} will result +in successive records being read from the file it is bound to. If +an EOF is detected it is silently ignored, and the last value +read will continue to be returned. List-structured identifiers may be +integer, real, or character as well as struct type data. +The binding to a filename is the same regardless of type, +and the only difference is that data conversion is +performed on the input record to match the type of the identifier. + +If you expect to write commands much more complicated than these +examples, it is time to learn about \irafname{script tasks}. This topic +is covered in \S 7 of this document and more detailed information +is given in the \reference{CL Programmer's Guide}. + +\newpage +\section{Rolling Your Own} + +The true power of the CL and the whole IRAF analysis +environment lies in its ability to tailor analysis functions to the +users' data. This power comes from the ability to define new +functions in the CL, and from the capability to extend the +basic IRAF system by the addition of new analysis packages. +These new routines can be developed incrementally, a line at a time, +and then defined as a new task once the function operates as desired. +User defined functions and analysis packages look just like any of the standard +functions that are provided with the system, and are called in the same way. +All of the same parameter passing, range checking, and prompting operations +of IRAF are available for user defined functions. + +Beyond the ability of the CL to \emphasize{learn} the value of parameters +that you have entered, or the creation of "one-liners", +little user customization has been presented so far. +However, all of the programming and extensibility features of the CL +that have been used in the creation of the standard packages are also +available to the intrepid user, enabling the creation of a personalized +data analysis environment, one's own set of \taskname{doit} functions. +This section introduces the creation of new user script tasks, +user executable tasks, and packages of such tasks. + +Examination of one of the \filename{.CL} script tasks that +defines a standard package will reveal that it +contains several \usertype{set} commands to establish +logical directory names; and then defines the set of +tasks that compose the package. Examine the script task +for the \irafname{system} package of functions: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{page system\$system.cl} +\end{quotation} + +\noindent +to reveal the mysteries of these basic functions. +The task names that appear +in this package description contain a \irafname{logical directory} +portion (as in \usertype{system\$}) and a filename portion +(\usertype{system.cl}). The logical directory name is separated from +the rest of the file name by a dollar sign \usertype{'\$'}, +as was discussed in +the section on virtual file names (\S 4.3). Use of a logical directory +specification in public packages, and even in those for your own private +use, is highly recommended, since it provides an unambiguous +specification of where to find the package and tasks. + +Note that tasks need not be defined as part of a package; individual tasks +can be created and defined at any time, but a package is a convenient +way of grouping related tasks together. Many package have already been +provided in IRAF, and should be browsed by anyone who is searching +for clues about how the CL language can be used for programming. + +\subsection{Creating Script Tasks} + +All of the IRAF commands can be used within a +script task and will operate the same way in that environment as they +do when entered interactively. A script task need be nothing more than +a text file that contains normal CL statements or commands. +Commands may be entered in a script just as they would from a terminal +in \irafname{command mode}, or \irafname{program mode} +may be used, in which case slightly different rules apply (c.f. \S 6.0). +For simple process control scripts command mode is likely +to be satisfactory, but program mode is the obvious choice if more +complicated tasks are undertaken. The main distinction +is that task names must be entered in full and +the standard rules should be followed for variable names and character +string references. Program mode will be used in the following +examples, since it is most likely to be used in any complicated +script tasks that you might wish to develop. + +In order to create a script task one has merely to invoke the editor + +\begin{quotation}\noindent +\comptype{cl>} \usertype{edit {\it taskname}.cl} +\end{quotation} + +\noindent +and enter the CL statements that describe the actions you wish to +have performed. When you have created the new script task +(or modified an existing one), exit the editor in the normal way, +so that the file is written in your current directory. + +A script task for demo purposes might look like: + +\begin{quotation}\noindent +\usertype{ \{ } \\ +\usertype{ print(' Hello, world !! ') } \\ +\usertype{ \} } +\end{quotation} + +\noindent +In order to make this new task available to the CL, you will have to identify +it and indicate where the script task is to be found: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{task \$my\_new\_task = {\it taskname}.cl} +\end{quotation} + +\noindent +Note that the name by which you refer to the new task +need not be the same as the name of the file, although the use of the same +name is conventional. +The `\usertype{\$}' in the \usertype{task} statement is optional and +tells IRAF not to search for a parameter (\filename{.PAR}) file for the task. + +Once the task has been created and declared it may be directly invoked: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{my\_new\_task} +\end{quotation} + +\noindent +will cause the script task file to be parsed and executed by the CL. +You may change the body of a script task +without redefining it with another \usertype{task} statement. + +While tesing new script tasks, such +as this one, you may find it useful to turn on echoing: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{echo = yes} +\end{quotation} + +\noindent +which will cause the CL to echo the commands on the terminal +as they are read from the script. + +Since all of the commands that you have entered at the terminal are +logged a the history file, it is possible to edit all or part +of this command log to create a new script task. You will first have +to output part of the history log to a file and then edit it: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{history 30, $>$ temp } \\ +\comptype{cl>} \usertype{edit temp } +\end{quotation} + +\noindent +which lets you change history (not a bad trick). Once you have edited +the file, the commands needed to turn it into +a CL script task are the same as those described above. + +\subsection{Passing Parameters to Script Tasks} + +Parameters are used to control the operation of tasks by defining input +and output files, indicating execution options, etc. Script tasks that a user +defines may have parameters that operate in exactly the same fashion +as standard tasks. +In fact, the same prompting, learning, and limit checking mechanisms +that operate for standard tasks are available by default for user script tasks, +as well as for external user tasks (about which more in \S 7.5). + +CL parameters and other variables that are defined external to a new +script task may be referenced from within the task with no special action +being taken on your part. Global variables and variables passed +from higher level tasks +are also accessible to a task. However, named parameters for the task, +or variables that are local to the task (and thus protected from +external actions), must be declared within the script task itself. +Parameters are identified by being defined +in the formal parameter list of the procedure or before the \usertype{begin} +statement, while local variables are declared only \emphasize{after} +the \usertype{begin} statement. N.B. the \usertype{begin} and +\usertype{end} statements must appear all by themselves on the line, +and anything that appears \emphasize{after} the \usertype{end} will +be ignored. + +The following simple script task description will serve to illustrate +many of the salient points: + +\begin{verbatim} + +procedure doit (inparm, groups, region, outparm) + +file inparm {prompt = 'Input file name:'} +int groups {prompt = 'Groups to process (0 for all):'} +int region[] {0, mode=hidden} +file outparm {prompt = 'Output file name:'} + +begin + file cal_file = 'calib$wfpc' # Wide Field Camera + int n_group, ngp + + n_group = groups # get the users group request + if (n_group == 0) + n_group = 9999 + + for (ngp=1; ngp <= n_groups; ngp=ngp+1) { + calib (inparm, ngp, cal_file) | # note use of pipe + clean() | + clip (region= region, >> outparm) + } +end +\end{verbatim} + +\noindent +The identifiers {\tt inparm, group, region,} and {\tt outparm} are +parameters of the function and are used to pass data +into and out of the procedure proper. +There is one \emphasize{required} parameter, {\tt inparm}, which is the input +file name that contains the name of +the file to be operated upon. The other parameters are {\tt groups} +the number of data groups to be processed; +a \emphasize{hidden} parameter, {\tt region}, which will not be +prompted for; and the parameter, {\tt outparm}, which is +the name of the file that is to be written by the function. The variable +{\tt cal\_file} is local to the procedure and is only +available within the procedure body (or to any lower level routines to which +variables may be passed as parameters). + +There are some subtleties here that bear mentioning. Hidden parameters, +such as {\tt region}, may be defined for script tasks and must appear +\emphasize{before} the \usertype{begin} statement, but need \emphasize{not} +appear in the formal parameter list. The {\tt groups} parameter will +be prompted for if not specified on the command line, +but is then assigned to a local variable {\tt n\_group}. +This is not required, but is desirable because of a side-effect of the +automatic prompting built into IRAF. Any query mode parameter will be +prompted for automatically, \emphasize{each time it is referenced}. +This can be very useful in a script where a new value is to be input +on each execution of a loop, but can be surprising if one only intends +to enter the value once. The obvious fix is to assign the value to +a local variable (at which time the prompt will occur) and then +operate only on the local variable. + +As with the simple task described before, this procedure must be declared +with a \usertype{task} statement in order that the CL be able to locate it. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{task doit = home\$doit.cl} +\end{quotation} + +\noindent +Remember to specify the logical +directory in the declaration so that the task can unambiguously +be located no matter which directory you use it from. +When you run this new task, you will be expected to enter a value for +the input parameters (and you will be prompted if you don't). + + Remember that once you +have used the \usertype{task} statement to inform the CL how to find your +new function, you need not do so again during that session, since the original +declaration of the task will allow it to be located even if you edit the body +of the task to change its internal operation. +If you need to change the number or type of parameters to a task, +or to change the name of a task, move it to another directory, +or if you wish to redefine the meaning of one of the standard tasks +in the system, you will have to use the \usertype{redefine} command. + +The following commands: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{rename home\$doit.cl funcs\$doit.cl} \\ +\comptype{cl>} \usertype{redef doit=funcs\$doit.cl} +\end{quotation} + +\noindent +rename the file \filename{HOME\$DOIT.CL} to \filename{FUNCS\$DOIT.CL} +and then redefines the \taskname{doit} task to point to the script. +This redefinition causes the CL to reprocess the script task +in order to re-establish pointers to the file and to +redefine the data declarations. + +Once you have tested your new task and have it +debugged, you may wish to enter a \usertype{task} definition for +it into your \filename{LOGIN.CL} file, or to install it in your own +package of private functions. + +\subsection{Using List Structured Parameters in a Script Task} + +It is possible to define a CL script task such that a sequence of files +whose names are defined in an input list +may be processed in one call to the task. This is convenient +when a number of files need to be processed in an identical way. The +following example shows how the task \usertype{doit\_toit} has been +setup to accept a list structured input parameter, and then +to call another task, passing the files from the list one at a time +to the other task. The obvious advantage is that the development +of the task that really does the work, viz. \usertype{doit}, can be done in +isolation from the mechanics of batch processing the list of data files. + +The \usertype{doit\_toit} function is set up for production use and, +as such, it logs all activity in the standard logfile. +It may be run as a background task, like any other IRAF function. + +\begin{verbatim} +# DOIT_TOIT -- A driver task for batch operation of DOIT. + +procedure doit_toit (images, section) + +file *images { prompt = 'List of images to be changed' } +char section { prompt = 'Section of input images to be output' } + +begin + struct imgs # working storage for image file name + bool klog # default size is 32 chars + file logf + + klog = keeplog # get global keeplog flag + logf = logfile # ditto the log file name + + while (fscan (images, imgs) != EOF) { + if (klog) { + # Output a startup message if keeplog is true. + print (' DOIT_TOIT: Process images ', >>logf) + time (>> logfile) + print (' Images : ', imgs, >>logf) + print (' Section : ', section, >>logf) + } + + # Do the actual task by calling the DOIT function, passing + # in the file name with the section concatenated. + + doit (imgs // section, imgs) + + if (klog) { # output the trailing message + time (>>logf) + print (' DOIT_TOIT: Completed. ', >>logf) + } + } +end +\end{verbatim} + +\noindent +The declaration for the variable \usertype{images} needs +some explanation. The asterisk \usertype{'*'} indicates that +\usertype{images} is a \irafname{list structured parameter}, i.e. that +it is to be processed as a pointer to a parameter list, rather than +as the parameter itself. In this instance it will contain the name +of a file that itself contains a list of the names of files to be +processed. + +As with the other script tasks that have been described, this one must +be declared to the CL via a \usertype{task} statement before it can +be executed. Once this has been done the task can be called as follows: + +\begin{quotation}\noindent +\comptype{cl>} \usertype{task doit\_toit = home\$doit\_toit.cl} \\ +\comptype{cl>} \usertype{doit\_toit ( 'images.txt', '[]' )} + \hfill \#~no~sub-sections \\ +\comptype{cl>} \usertype{tail logfile} \hfill \#~check~the~logfile~messages +\end{quotation} + +\noindent +The name of the file containing the list of images \filename{``IMAGES.TXT''} +is passed directly into the task as a quoted string. + +\subsection{Establishing Your Own Function Package} + +Once you have defined several functions that do a useful set of operations, +you may wish to set them up so that they are always available to you. +This can be done by defining them as a package, which is the mechanism +that IRAF uses to organize the other groups of tasks that are made +available as part of the system proper. (Or, more easily, by putting +the \usertype{task} declarations into your \filename{LOGIN.CL} file.) + +\newpage +\begin{verbatim} + +package my_package + +set funcs = "home$func/" # define the logical directory + +task fib = funcs$fibonacci.cl + glib = funcs$wordy.cl + doit = funcs$doit.cl + +clbye() # invoke the cl again for interactive use + +\end{verbatim} + +\noindent +If you now place the declaration for this package task in your +\filename{LOGIN.CL} file, these tasks will be available to you whenever +you login to IRAF. It is a good practice to always use logical directory +names in task declarations and in other file names, since changing the +search path with a \usertype{chdir} may otherwise render tasks not +locatable. + +Packages may, of course, be more complex than the above, since they can +refer to several logical tasks that may be CL script tasks or executable +tasks. User packages may also reference logical tasks that are in other +packages directly, if only one or two such tasks from another package are +needed. Additionally, a package task may declare variables +that are to be treated as global to all of the tasks \emphasize{within} +the package, but are to remain local to the package itself. Other IRAF +commands can be included in a package task as well, such as a load request +for a package of utility routines. As you will recall, the +load operation for a package is implicitly executed whenever a package +is named; thus, a utility package such as \taskname{plot} or \taskname{imred} +can be loaded and made available just by naming it in the package description. + +\subsection{Creating Fortran, SPP and other External Tasks} + +While the IRAF and SDAS applications packages, along with the CL +language, offer substantial facilities for interaction with and +analysis of data, it would not be unusual for users to wish to +make their existing algorithms available +for use in IRAF. Neither the IRAF packages nor the SDAS packages +can provide all of the functions that everyone might desire. IRAF has been +developed as an \emphasize{open system}, and is therefore extendible by the +user so that externally compiled programs are accessible with the CL. +These programs may be coded in any language that +conforms to the standard calling conventions, but Fortran, C, and the +Subset PreProcessor (SPP, the IRAF portable language) have predefined sets of +interface routines that establish access to the IRAF \irafname{kernel} +functions. + +It is suggested that the Fortran programmer use the SDAS/ST +interface routines to access the IRAF environment. These routines +provide access to parameters, perform I/O on image files as well as other data +file formats, provide facilities for header data manipulation, etc. +The routines are described in the \reference{SDAS Applications Programmer's +Guide} (the \reference{Green Book}) and in the \reference{Software +Interface Definition, ST-ECF O-11}, which describes the set of +interfaces that have been agreed upon between the STScI and the +European Coordinating Facility (ECF). + +The SDAS interface routines (and the ST-ECF interfaces) are all +built upon the existing IRAF kernel interfaces as described in the +\reference{IRAF Programmer's Crib Sheet}. These interfaces are rather +more complete than the SDAS/ST ones, providing full access to the facilities +of the IRAF virtual operating system. These routines can be called directly +from SPP, but typically \emphasize{cannot} be called directly from +Fortran programs. + +A selection of software development tools are available to the user who wishes +to integrate personal programs into the IRAF environment. These utilities +are provided as parts of the \taskname{softools} package, and include such +functions as IRAF-specialized compilation and linkage, help file creation, etc. + +A simple SPP language routine is included here as an example that +can be tried from the terminal. It is not a particularly useful +function (it just feeps the terminal bell), but does show the +ease with which an external task can be linked into the environment. + +\begin{verbatim} +#------------------------------------------------------------ +# Simple task to show use of SPP external procs +# Compile and link using SPP command in Softools + +task feep = t_feep +include # include the standard char defs + +# FEEP -- Feep the terminal. + +procedure t_feep() +begin + call putc (STDOUT, BEL) +end +\end{verbatim} + +\noindent +After you have used the editor to create the program source file, +you should load the \irafname{softools} package that contains +the \irafname{xc} compile/link tool. This will compile the +program, link it, and create an executable named \filename{FEEP.E}. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{softool} \\ +\comptype{so>} \usertype{xc feep.x} +\end{quotation} + +Once the \usertype{feep} task has been compiled and linked +it may be made available from within the IRAF environment +in a fashion analogous to that used for CL script tasks. +A \usertype{task} statement that names the executable file and binds it +to a task name must be used to declare the task to the CL. Once this +has been done, the executable task can be invoked just like any other +task. + +\begin{quotation}\noindent +\comptype{cl>} \usertype{task feep = feep.e } \\ +\comptype{cl>} \usertype{feep} \hfill \#~is~used~to~call~it +\end{quotation} + +\noindent +N.B. IRAF tasks written in SPP (and other languages) +may contain more than one logical task, and the CL +\usertype{task} statement must be used to declare each of them. +The logical task names used on the CL \usertype{task} statement +\emphasize{must} correspond with the task names from the {\tt task} +statement used in the body of the SPP file. + +The parameter handling facilities at the user level behave +identically for executable +external tasks and for CL script tasks. If the complete facilities +of parameter range checking, prompt messages, and default values +are desired, a data declaration statement that defines +these values will have to be specified. If a declaration statement +is not provided, the standard prompt processing (naming the +parameter and soliciting input) will be used when parameters are +referenced. + +The details of parameter and file I/O in SPP, and in the Fortran and +C interfaces, are sufficiently different from those presented for the +CL that the entire subject is best deferred to a separate document. +It is important to note however, that the facilities that are available +in the CL and in the IRAF kernel routines that support it are +equally available to all executable modules. The implication of +this is that any program that has been linked into IRAF will have the +same apparent interface as all of the existing programs, and thus +can easily be made to appear as a unified part of the larger system. +This can, of course, be subverted, and programs may maintain their +own identities in so far as that is desirable. However, the advantages +of a unified user interface and of a well defined and completely +implemented set of flexible interface routines cannot be stressed enough. + +\newpage +\section{Relevant Documentation (the Yellow Pages)} + +This document should serve to get the first-time user started (and if it +doesn't, we would like to know about it), but there are many topics +that have been covered quickly or not at all. Other documents and +sources of information about IRAF, SDAS, standard packages, use of +SPP, IRAF internals, etc. exist and this section will provide pointers +into that realm for those who would like more information on these topics. + +\subsection{IRAF Command Language} + +Some of the documents describing the CL are now somewhat out of date +since there have been at least two revisions to IRAF since they were +written. However, these documents are readable and are still +useful, since, by design, most of the changes made to the CL are +compatible with what had gone before. + +\noindent +\reference{CL Programmer's Guide, in preparation} + +This is to be the most complete introduction to programming in the +CL and to the facilities of the CL. As such, it provides details of language +use (especially helpful when developing external and/or script tasks in +Fortran, SPP, and C). Also included are descriptions of the workings of +the CL, the IRAF kernel and inter-process communications as they affect +the use of IRAF for program development. + +\noindent +\reference{Detailed Specifications of the IRAF Command Language, rev Jun82} + +This paper discusses in technical detail the major functions of the CL +and some details about how it works. Since this is a specifications +document, it is not as readable as a user document, but it +does cover many of the same areas as the \reference{CL Programmer's Guide} +in somewhat more detail. + +\subsection{IRAF Applications Packages} + +Much of the richness of the IRAF environment comes from the packages +of applications programs that are being made available within the +environment. The IRAF group at NOAO and the SDAS group at STScI have been +developing analysis programs that are available as packages +within the IRAF environment, and the end-user-oriented documentation of +these systems is described below. + +\noindent +\reference{IRAF Applications Packages, Structure and Requirements, Aug83} + +This document is an attempt to define fully the decomposition of the IRAF +system and applications software into packages. The functions performed by +each package are summarized in the form of requirements. + +Descriptions of specific IRAF applications packages developed at Kitt Peak +are available in a set of user-handbooks : + +\begin{itemize} +\item \reference{APPHOT - Digital Aperture Photometry, Aug83} +\item \reference{GRAPH - Simple Graphics Routine, Mar84} +\item \reference{SURFACE - 3-D Surface Display, Mar84} +\item \reference{CONTOUR - Contour Map Display, Mar84} +\item \reference{HELP - On-Line HELP for IRAF, Mar84} +\item \reference{DATAIO - Data Readers and Writers, Mar84} +\item \reference{LISTS - Basic List Processing Functions (ASCII files), Mar84} +\item \reference{UTILITIES - Miscellaneous Utility Functions, Mar84} +\item \reference{SOFTOOLS - Software Utilities, make, yacc, xc, mklib, Mar84} +\end{itemize} + +\noindent +\reference{Science Data Analysis Software Requirements, Final, Aug82} + +These are the contract requirements of the SDAS system. + +\noindent +\reference{SDAS User's Manual, in preparation} + +A descriptive guide to the use of SDAS. + +\subsection{Standard Program Interfaces} + +There are three sets of interface routines available to the programmer: +those for SPP, those for C, and those for Fortran. The language that +you use depends on the nature of the project being undertaken, your +own level of expertise, and on the +need for creating portable code. SPP is the language of choice for packages +that are to become part of IRAF or for tasks that require access to the +entire virtual system interface. Fortran and the SDAS/ST +interfaces will remain the choice for existing Fortran codes and for many +small scientific applications programs. Users are encouraged to choose +the SDAS/ST interface for their Fortran programs. C has been used +for the innards of the CL itself, and a set of interfaces (the LIBC library) +is provided that emulates the UNIX standard I/O facilities and +gives access to the IRAF kernel facilities. + +\noindent +\reference{A Reference Manual for the IRAF System Interface, rev May84} + +This document is the most complete (and recent) treatment of the +linkages between the portable IRAF kernel, the CL, the external procedures +and the system dependent Z-routine layer. It describes these interfaces +in detail and has the complete specifications of the +Z-routine interfaces. It is of particular use to both the individual who is +trying to port IRAF to another system (it is a \emphasize{must read} for such +persons) and to the system or applications +programmer who wants a more detailed understanding of IRAF. + +\subsubsection{SPP Interfaces} + +\noindent +\reference{Programmer's Crib Sheet for the IRAF Program Interface, rev Sep83} + +This document describes the complete set of interface functions +for the IRAF virtual +operating system as it is available to the SPP programmer. Several +sets of library functions are described for accessing images and various +kinds of data files, terminal capabilities, graphics and image I/O, etc. +Programs written using only these interfaces +will be fully portable, along with the main body of IRAF code. + +\noindent +\reference{Reference Manual for the IRAF SPP, rev Sep83} + +This is the definitive document about the IRAF Subset Preprocessor +language. The language is somewhat like Ratfor (from which +it derives), but it has extensions for dealing with the memory management +and referencing issues that arise when operating on large scale image data. + +\noindent +\reference{The Role of the Preprocessor, rev Dec81} + +This document is an early discussion of the philosophy behind use of +the SPP language. As such, it is valuable +background reading for anyone who wishes to understand fully the +benefits of using a preprocessed language for +implementing a large body of portable +code like IRAF. + +\subsubsection{Fortran Interfaces} + +\noindent +\reference{SDAS Applications Programmer's Guide} + +This is the complete description of the interface set that is now +being used to develop the SDAS program suite at STScI. These interfaces +are expected to be replaced eventually by the set of SDAS/ST +interfaces mentioned in the following document. + +\noindent +\reference{Software Interface Definition, ST-ECF O-11, rev Aug84} + +This describes the set of standard interfaces agreed upon between +the STScI and the ST-ECF. It incorporates most of the features of the +SDAS standard interfaces and is to be used for program development +at STScI and for future MIDAS programs developed at ESO. It is +a rather complete interface for image data, process parameters, +and table data structures, but does leave out many of the other +facilities provided in the complete IRAF SPP interface. + +\newpage +\section{And into the Future} + +This version of IRAF and its CL represents the first external release +of a system that has been under development for more than three years, +and which will continue to evolve for several +more. IRAF was born out of the need for a system that +could survive changes in operating systems and hardware, since such +changes are a normal part of computer system evolution. To +accomodate such changes, and to provide a level of stability +and portability across operating systems, +IRAF is a \emphasize{layered} system: the CL is the user layer; +the kernel is the operating system independent layer; and the +z-routines are the system dependent layer. + +Most of the discussion in this document describes the appearance +and function of the current command language (CL2), the user layer +of IRAF. As has been noted at various points in the text, +the CL is still undergoing +development and is expected to change over time. (The paragraphs +marked \irafname{CL++} in the text hold the clues.) The intent +in these changes is two-fold: + +\begin{itemize} + +\item Provide evolutionary enhancements to the user interface +to improve utility, functionality, usability and coherence. + +\item Bring the programming elements of the CL language +into line with the SPP language which is used for the bulk of the +IRAF portable code. + +\end{itemize} + +\noindent +These requirements are somewhat at odds, as was noted in \S 6, but +further attention is being given these issues to try and resolve +the dilemma. Although not all elements of the CL language can +be mapped easily into the SPP programming language (consider the I/O +control commands), the notion that one +can do development in an interactive environment and then +realize compiled code speeds for execution is an attractive one. +The CL2 implementation has +taken steps in this direction and we expect to see how far this idea +can be taken over the next few years. + +\subsection{Near-Term Software Projects} + +While the evolution of the CL is an important part of IRAF, there +are other elements of the system that are even more important which are +still under development at this time. The most important single area +for development is the database and data catalogue. +Design and prototyping of these important functions, and the +necessary query language, is in progress +right now. These functions are doubly important, since they both represent +a user facility for creating and operating on private catalogues +of data; and also are at the heart of the effort to merge the +SDAS functions cleanly into the IRAF control structure. Only after +the DBIO and IMIO packages have been fully implemented and integrated +into the rest of the system will functions from these two large +applications groups be able to share data and file structures. +A tables system is also envisioned that will offer similar capabilities +to the MIDAS tables, but will be built upon the DBIO routines. + +The areas of graphics and image display will also receive +attention during the next year. The current GIO package +supports a fast kernel and both a GKS and an NCAR emulation. +However, image data are not merged into this structure +and no common meta-file +formats exist that allow image, annotation, and overlay graphics +to be represented in one consistent form. Some efforts have already +been made toward understanding what needs to be done and how (or if) +the requirements can be satisfied within existing standards. +Further efforts will be made, both at NOAO and STScI, and at +other facilities like RAL who have expertise in this area, to develop +an approach that satisfies the requirements. + +Developments in the area of networks, both LAN and wide-area; workstations; +and the related topics of access to distributed data bases and archives +are also receiving attention. We believe that IRAF +has a sufficiently robust and flexible structure that it can operate +successfully within a distributed operating environment. Small scale +efforts are now underway to explore some of the issues related to network +file systems. + +At the same time, a prototype project is underway with a +single platter laser disk, to evaluate the suitability of this media +for large scale, long term archival storage of images and other related +data. As a part of this activity, IRAF is currently +being ported to a SUN workstation and high resolution image display +at the STScI. IRAF and its database package will be important +to this effort, since they will provide some of the basic facilities +for processing the data and managing the catalogues for this archive. + +These are all components of a distributed data system, a long range goal +for the Space Telescope community, and probably of interest to the entire +astronomy and astrophysics community. To the extent that IRAF proves +useful to astronomers, it will play a key role in such a data system. + +\subsection{Where Is the Future?} + +The usual rapid pace of developments in hardware and software systems +will also prompt consideration of changes to the external appearance +and some of the internal implementation details of IRAF. +Developments in graphics and image displays, and in various data +input and storage +devices promise to make revolutionary changes in the way that +people and computers interact. High resolution graphics, touch screens, +mice, WYSIWYG (What You See Is What You Get), DWIM (Do What I Mean), +and the 'cluttered desk' paradigm pioneered by Xerox PARC and emulated +by everyone else, will all appear in one form or another in a variety +of different systems in the next few years. These presentation +techniques and differing interactive views of data, +when well thought out and integrated into a system, +can serve to make computers more accessible to people. +These ideas, however, have been much slower to arrive in the +large-scale systems that have been used for data analysis than in +the super-micro and PC class machines. + +IRAF, in its current version, incorporates only some of these elements, +but many others will be experimented with as it is ported to +different hardware environments. +Because the CL is a separable piece of the system, +it can be changed or replaced, without necessarily making major changes +to the underlying system structure. Efforts now underway to move +IRAF out of the super-mini systems where it has been developed, and +into super-micro workstations will afford the opportunity to +explore some of these user interface issues in a prototyping +mode. Depending on the results of such experiments, +other CL interfaces that take advantage of those +elements that prove successful are likely to evolve. + +These statements should not be +construed to mean that constant change will be the norm. IRAF +was designed to protect the substantial software investment that any +large data analysis system represents, and this it will do, both for +the developers and for the users. The IRAF kernel and the layered +interfaces for applications programs are quite stable, and are not +expected to change, except to incorporate additional functionality. +Furthermore, any changes proposed for +the user interface will be carefully evaluated in terms of their +impact on the existing user community. But, just as we expect that +faster, more efficient FFT or filtering algorithms would receive +a welcome reception we expect that a stable, but slowly evolving system +that continues to serve +users needs will meet with approval. Feedback and commentary from the +users of the system will be vitally important in this development +process, and we encourage that dialogue. + +\newpage +\appendix +\section{Appendices} + +\subsection{CL Commands and the System Package} + +\subsubsection{CL Intrinsic and Builtin Functions} + +\begin{tabular}{rcl} + + access & - & Test to see if a file exists \\ + bye & - & Exit a task or package \\ + cache & - & Cache parameter files, OR \\ + & & Print the current cache list (no arguments)\\ + cd & - & Change directory \\ + chdir & - & Change directory \\ + cl & - & Execute commands from the standard input \\ + clbye & - & Exit a task or package to save file descriptors \\ + defpac & - & Test to see if a package is defined \\ + defpar & - & Test to see if a parameter is defined \\ + deftask & - & Test to see if a task is defined \\ + ehistory & - & Edit commands from the history log file \\ + envget & - & Get the string value of an environment variable \\ + eparam & - & Edit the parameters for a function \\ + error & - & Print error code and message and abort \\ + flprcache & - & Flush the process cache \\ + fprint & - & Format and print a line into a parameter \\ + fscan & - & Scan and format an input list \\ + hidetask & - & Define a new hidden task \\ + history & - & Print the last few commands entered \\ + jobs & - & Show status of background jobs \\ + keep & - & Make recent set, task, etc. declarations permanent \\ + kill & - & Kill a background job or detached task \\ + logout & - & Log out of the CL \\ + lparam & - & List the parameters of a task \\ + mktemp & - & Make a temporary (unique) file name \\ + mkdir & - & Make a new file sub-directory \\ + package & - & Define a new package, OR\\ + & & Print the current package names (no arguments) \\ + print & - & Format and print a line on the standard output \\ + radix & - & Print a number in the given radix \\ + redefine & - & Redefine a task \\ + scan & - & Scan and format the standard input \\ + service & - & Service a query from a background job \\ + set & - & Set an environment variable, OR \\ + & & Print environment (no arguments) \\ + show & - & Show the values of one or more environment variables \\ + sleep & - & Pause execution for specified period \\ + substr & - & Extract a substring from a string \\ + task & - & Define a new task \\ + unlearn & - & Restore the default parameters for a task or package \\ + update & - & Update a task's parameters (flush to disk) \\ + version & - & Print the revision date of the CL \\ + wait & - & Wait for all background jobs to complete +\end{tabular} + +\subsubsection{System Package Functions} + +\begin{tabular}{rcl} + + allocate & - & Allocate a device \\ + beep & - & Beep the terminal \\ + clear & - & Clear the terminal screen \\ + concatenate & - & Concatenate a list of files to the standard output \\ + copy & - & Copy a file, or copy a list of files to a directory \\ + count & - & Count the number of lines, words, and characters in a file \\ + deallocate & - & Deallocate a previously allocated device \\ + delete & - & Delete a file \\ + devstatus & - & Print the status of a device \\ + directory & - & List files in a directory \\ + diskspace & - & Show how much diskspace is available \\ + edit & - & Edit a file \\ + files & - & Expand a file template into a list of files \\ + gripes & - & Post bug reports, complaints, suggestions \\ + head & - & Print the first few lines of a file \\ + help & - & Print online documentation \\ + lprint & - & Print a file on the line printer device \\ + match & - & Print all lines in a file that match a pattern \\ + news & - & Page through the system news file \\ + page & - & Page through a file \\ + pathnames & - & Expand a file template into a list of OS pathnames \\ + protect & - & Protect a file from deletion \\ + rename & - & Rename a file \\ + revisions & - & Print/post a revision notice for a package \\ + rewind & - & Rewind a device \\ + sort & - & Sort a text file \\ + spy & - & Show processor status \\ + stty & - & Show/set terminal characteristics \\ + tail & - & Print the last few lines of a file \\ + tee & - & Tee the standard output into a file \\ + time & - & Print the current time and date \\ + type & - & Type a file on the standard output \\ + unprotect & - & Remove delete protection from a file +\end{tabular} +\clearpage + +\subsection{SDAS Analysis Packages} + +\begin{itemize} + +\item General Data Analysis \\ + +\begin{tabular}{rcl} + areavolum & - & Integrate to find the area/volume under a curve/surface\\ + arrayops & - & Perform arithmetic, logical, and matrix operations on\\ + & & \quad SDAS data arrays\\ + convert & - & Convert data from one type to another (real, integer,\\ + & & \quad logical, byte)\\ + curfit & - & Fit curve to one-dimensional data\\ + dimage & - & General image display package\\ + extract & - & Extract a subset of a data array\\ + fitsrd & - & Read a standard FITS tape and create an SDAS disk data file\\ + fitswr & - & Write a standard FITS tape from an SDAS disk data file\\ + four1d & - & Perform one-dimensional Fourier analysis\\ + four2d & - & Perform two-dimensional Fourier analysis\\ + hstats & - & Compute standard statistics, including histograms\\ + locate & - & Locate features in a spectrum, time series, or image\\ + makemask & - & Make a data mask\\ + plot1d & - & Plot one-dimensional (equally-spaced) data\\ + plot2d & - & Plot two-dimensional (equally-spaced) data as contour\\ + & & \quad map or ruled-surface map\\ + probdist & - & Compute standard probability distributions\\ + register & - & Compute registration parameters for two displaced data\\ + & & \quad arrays (use in conjunction with resample)\\ + repmod & - & Replace/modify/input data in an existing data array\\ + resample & - & Resample data from one grid to another (shift, rescale, rotate)\\ + smooth & - & Smooth data by convolution filtering, median window +\end{tabular} + +\item Spectral Analysis \\ + +\begin{tabular}{rcl} + cntana & - & Continuum analysis (determine reddening, correct for\\ + & & \quad reddening, fit continuum models)\\ + ewlnst & - & Measure equivalent width/line strength\\ + gspect & - & Generate a spectrum for testing\\ + rvdet & - & Measure radial velocities\\ + specph & - & Spectrophotometry +\end{tabular} + +\item Image Analysis \\ + +\begin{tabular}{rcl} + gimage & - & Generate an image for testing\\ +\end{tabular} + +\clearpage +\item Time Series Analysis \\ + +\begin{tabular}{rcl} + glcurv & - & Generate a light curve for testing\\ + hldelc$^*$ & - & Correct HSP times for light delay time\\ + hspcir$^*$ & - & Correct HSP data for instrumental response\\ + hspolar$^*$ & - & Polarimetry package for HSP data\\ + hspphot$^*$ & - & Photometry package for HSP data\\ + hsubbkg$^*$ & - & Subtract background from HSP data +\end{tabular} + +\item Astrometric Analysis \\ + +\begin{tabular}{rcl} + bdresid$^*$ & - & Make histogram of FGS beam deflector residuals\\ + centroid$^*$ & - & Centroid raw FGS encoder data\\ + errsig$^*$ & - & Make histogram of FGS error signals +\end{tabular} + +\end{itemize} + +\vskip 2cm \noindent +$*$ --- these programs may not be available +\clearpage + +\subsection{IRAF Application Packages} + +\begin{itemize} + +\item CRYOMAP Package \\ + +\begin{tabular}{rcl} + + extract & - & Extract Cryomap spectra\\ + findspectra & - & Find Cryomap spectra\\ + iids & - & Convert integrated spectra extractions to IIDS format\\ + maplist & - & List information about the multi-aperture plate\\ + specplot & - & Plot extracted integrated spectra + +\end{tabular} + +\item DATAIO Package \\ + +\begin{tabular}{rcl} + + bintxt & - & Convert a binary file to an IRAF text file\\ + ldumpf & - & List the permanent files on a Cyber DUMPF tape\\ + mtexamine & - & Examine the structure of a magnetic tape\\ + rcamera & - & Convert a Forth/Camera image into an IRAF image\\ + rcardimage & - & Convert a cardimage file into a text file\\ + rdumpf & - & Convert IPPS rasters from a DUMPF tape to IRAF images\\ + reblock & - & Copy a binary file, optionally reblocking\\ + rfits & - & Convert a FITS image into an IRAF image\\ + ridsfile & - & Convert IDSFILES from a DUMPF tape to IRAF images\\ + ridsmtn & - & Convert mountain format IDS/IRS data to IRAF images\\ + ridsout & - & Convert a text file in IDSOUT format to IRAF images\\ + rpds & - & Convert a PDS image into an IRAF image\\ + rrcopy & - & Convert IPPS rasters from an RCOPY tape to IRAF images\\ + txtbin & - & Convert an IRAF text file to a binary file\\ + wcardimage & - & Convert text files to cardimage files\\ + wfits & - & Convert an IRAF image into a FITS image\\ + widsout & - & Convert an IRAF image to IDSOUT text format +\end{tabular} + +\item ECHELLE Package \\ + +\begin{tabular}{rcl} + + background & - & Subtract a scattered light background\\ + extract & - & Extract Echelle orders\\ + findorders & - & Find Echelle orders\\ + iids & - & Convert integrated spectra extractions to IIDS format\\ + orderplot & - & Plot extracted integrated spectra + +\end{tabular} +\clearpage + +\item GENERIC Package \\ + +\begin{tabular}{rcl} + + biassub & - & Subtract a bias image\\ + chimages & - & Change images: trim, flip, transpose, rotate\\ + colbckgrnd & - & Fit and subtract a column by column background\\ + colflat & - & Create a flat field by fitting a function \\ + && to the image columns\\ + darksub & - & Scale and subtract a dark count image\\ + dcbias & - & Subtract a constant bias and trim images\\ + flatten & - & Flatten images using a flat field\\ + linebckgrnd & - & Fit and subtract a line by line background\\ + lineflat & - & Create a flat field by fitting a function \\ + && to the image lines\\ + normalize & - & Normalize images\\ + normflat & - & Create a flat field by normalizing and \\ + && replacing low values + +\end{tabular} + +\item IMAGES Package \\ + +\begin{tabular}{rcl} + + imarith & - & Simple image arithmetic\\ + imaverage & - & Average images together\\ + imcopy & - & Copy an image\\ + imdelete & - & Delete an image\\ + imlinefit & - & Fit a function to each image line\\ + imheader & - & Print an image header\\ + imhistogram & - & Compute image histogram\\ + imstatistics & - & Compute and print image statistics\\ + imtranspose & - & Transpose a two dimensional image\\ + listpixels & - & Convert an image section into a list of pixels\\ + sections & - & Expand an image template on the standard output\\ + shiftlines & - & Shift image lines\\ + tv & - & Image display (see TV-IMAGE Package) + +\end{tabular} + +\item LISTS Package \\ + +\begin{tabular}{rcl} + + average & - & Compute the mean and standard deviation of a list\\ + gcursor & - & Read the graphics cursor\\ + imcursor & - & Read the image display cursor\\ + table & - & Format a list of words into a table\\ + tokens & - & Break a file up into a stream of tokens\\ + unique & - & Delete redundant elements from a list\\ + words & - & Break a file up into a stream of words + +\end{tabular} + +\clearpage +\item LOCAL Package \\ + +\begin{tabular}{rcl} + + binpairs & - & Bin pairs of (x,y) points in log separation\\ + epix & - & Edit pixels in an image\\ + fields & - & Extract specified fields from a list\\ + imreplace & - & Replace pixels in a range by a constant\\ + imscale & - & Scale an image to a specified (windowed) mean\\ + imstack & - & Stack images into an image of higher dimension\\ + imsurfit & - & Fit a surface to an image\\ + imtitle & - & Change the title of an image\\ + notes & - & Record notes\\ + polyfit & - & Fit polynomial to lists of X,Y pairs + +\end{tabular} + +\item MULTISPEC Package \\ + +\begin{tabular}{rcl} + + findpeaks & - & Find the peaks\\ + fitfunction & - & Fit a function to the spectra parameter values\\ + fitgauss5 & - & Fit spectra profiles with five parameter \\ + && Gaussian model\\ + modellist & - & List data and model pixel values\\ + msextract & - & Extract spectra\\ + mslist & - & List entries in a MULTISPEC database\\ + msplot & - & Plot a line of image and model data\\ + msset & - & Set entries in a MULTISPEC database\\ + newextraction & - & Create a new MULTISPEC extraction database\\ + newimage & - & Create a new multi-spectra image + +\end{tabular} + +\item PLOT Package \\ + +\begin{tabular}{rcl} + + contour & - & Make a contour plot of an image\\ + graph & - & Graph one or more image sections or lists\\ + pcol & - & Plot a column of an image\\ + pcols & - & Plot the average of a range of image columns\\ + prow & - & Plot a line (row) of an image\\ + prows & - & Plot the average of a range of image lines\\ + surface & - & Make a surface plot of an image +\end{tabular} + +\clearpage +\item SOFTOOLS Package \\ + +\begin{tabular}{rcl} + + hdbexamine & - & Examine a help database\\ + lroff & - & Lroff (line-roff) text formatter\\ + make & - & Table driven utility for maintaining programs\\ + mkhelpdb & - & Make (compile) a help database\\ + mklib & - & Make or update an object library\\ + mkmanpage & - & Make a manual page\\ + xcompile & - & Compile and/or link an SPP, C or Fortran program\\ + yacc & - & Build an SPP language parser + +\end{tabular} + +\item TV-IMAGE Package \\ + +\begin{tabular}{rcl} + + blink & - & Blink the TV display\\ + display & - & Manipulate the TV display\\ + erase & - & Erase the TV display\\ + frame & - & Define the frames to be manipulated\\ + lumatch & - & Match color look up tables\\ + monochrome& - & Set display into monochrome mode\\ + pseudocolor& - & Set pseudocolor mode on display\\ + rgb & - & Set true RGB mode on display\\ + window & - & Define a display window area\\ + zoom & - & Zoom the display + +\end{tabular} + +\item UTILITIES Package \\ + +\begin{tabular}{rcl} + + airmass & - & Compute the airmass at a given elevation \\ + && above the horizon\\ + ccdtime & - & Compute time required to a observe star \\ + && of given magnitude\\ + detab & - & Replace tabs with tabs and blanks\\ + entab & - & Replace blanks with tabs and blanks\\ + lcase & - & Convert a file to lower case\\ + precess & - & Precess a list of astronomical coordinates\\ + translit & - & Replace or delete specified characters in a file\\ + ucase & - & Convert a file to upper case\\ + urand & - & Uniform random number generator +\end{tabular} + +\end{itemize} +\clearpage + +\subsection{IRAF Editor Functions} + +\begin{tabular}{llll} + +Command & Emacs & EDT$^{\dag}$ & Vi$^{\ddag}$ \\ +\\ +move-up & \key{$\uparrow$} or \key{CTRL/P} & \key{$\uparrow$} + & \key{j} or \key{CTRL/P} \\ +move-down & \key{$\downarrow$} or \key{CTRL/N} & \key{$\downarrow$} + & \key{k} or \key{CTRL/N} \\ +move-right & \key{$\rightarrow$} or \key{CTRL/F} & \key{$\rightarrow$} + & \key{l} or \key{$\rightarrow$} \\ +move-left & \key{$\leftarrow$} or \key{CTRL/B} & \key{$\leftarrow$} + & \key{h} or \key{$\leftarrow$} \\ +\\ +ins-chr/word & {\it text} & {\it text} & i/a-{\it text}\ \key{ESC} \\ +del-left & \key{CTRL/H} or \key{DEL} \hspace{1cm} & \key{DEL} & \key{DEL} \\ +del-char & \key{CTRL/D} & \key{,} & \key{x} \\ +del-word & \key{ESC}\ \key{d} & \key{-} & \key{d}\ \key{w} \\ +del-line & \key{CTRL/K} & \key{PF4} & \key{d} \key{d} \\ +undel-char & \key{ESC}\ \key{CTRL/D} & \key{GOLD}\ \key{,} & \key{u} \\ +undel-word & \key{ESC}\ \key{CTRL/W} & \key{GOLD}\ \key{-} & \key{u} \\ +undel-line & \key{ESC}\ \key{CTRL/K} & \key{GOLD}\ \key{PF4} & \key{u} \\ +\\ +set-fwd & & \key{4} & \\ +set-rev & & \key{5} & \\ +next-word & \key{ESC}\ \key{f} & \key{1} & \key{w} \\ +prev-word & \key{ESC}\ \key{b} & \key{5}\ \key{1} & \key{b} \\ +move-eol & \key{CTRL/E} & \key{2} & \key{\$} \\ +move-bol & \key{CTRL/A} & \key{BS} or \key{CTRL/H} \hspace{1cm} + & \key{.} \\ +next-page & \key{CTRL/V} & \key{7} & \key{CTRL/D} or \key{CTRL/F} \\ +prev-page & \key{ESC}\ \key{V} & \key{5}\ \key{7} + & \key{CTRL/U} or \key{CTRL/B} \\ +move-start & \key{ESC}\ \key{$<$} & \key{GOLD}\ \key{5} & \key{1}\ \key{G} \\ +move-end & \key{ESC}\ \key{$>$} & \key{GOLD}\ \key{4} & \key{G} \\ +\\ +get-help & \key{ESC}\ \key{?} & \key{PF2} & \key{PF2} or \key{ESC}\ \key{?} \\ +repaint & \key{CTRL/L} & \key{CTRL/R} & \key{CTRL/L}\\ +exit-update & \key{CTRL/Z} & \key{CTRL/Z} + & \key{:}\ \key{w}\ \key{q} \\ +exit-no update \hspace{1cm} & \key{CTRL/C} & \key{CTRL/C} + & \key{:}\ \key{q}\ \key{!} \\ + +\end{tabular} + +\hrule width5cm \vskip .15cm \noindent +\dag{} --- EDT employs the notion of ``direction'' (forward and backward +cursor motion). Several command sequences are preceded by \key{5} to indicate +explicitly that they only function after setting ``backward'' mode. All EDT +keystrokes, with the exception of \key{CTRL} keys, use the keypad. + +\medskip \noindent +\ddag{} --- Vi has \emphasize{insert/replace/change modes}, +which are entered by command and terminated by the \key{ESC} key. +Vi-type keystrokes for \usertype{eparam} and \usertype{ehist} are not +yet implemented. + +\twocolumn \columnsep 1cm +\section{Glossary} + +\medskip \noindent \irafname{AAS} --- American Astronomical Society. + +\medskip \noindent \irafname{band} --- A two dimensional array. The Nth band +of a three dimensional array or \irafname{image} is denoted by the subscript +[$*$,$*$,N], where $*$ refers to all the pixels in that dimension. + +\medskip \noindent \irafname{binary file} --- An array or sequence of +data words. Data is transferred between a binary file and a buffer in the +calling program by a simple copy operation, without any form of conversion. + +\medskip \noindent \irafname{binary operator} --- An operator which combines +two operands to produce a single result +(e.g., the addition operator in $x + y$). + +\medskip \noindent \irafname{brace} --- The left and right braces are +the characters `\{' and `\}'. Braces are used in the CL and in the +SPP language to group statements to form a compound statement. + +\medskip \noindent \irafname{bracket} --- The left and right brackets +are the characters `[' and `]'. Brackets are used in the CL and in the +SPP language to delimit array subscripts. + +\medskip \noindent \irafname{byte} --- The smallest unit of storage on +the host machine. The IRAF system assumes that there are an integral +number of bytes in a \irafname{char} and in an address increment +(and therefore that the byte is not larger than either). +On most modern computers, a byte is 8 bits, and a \irafname{char} is 16 bits +(I$*$2). If the address increment is one byte, the machine +is said to be \emphasize{byte addressable}. Other machines are \emphasize{word +addressable}, where one word of memory contains two or more bytes. +In the SPP language, SZB$_{CHAR}$ gives the number of bytes per char, +and SZB$_{ADDR}$ gives the number of bytes per address increment. + +\medskip \noindent \irafname {C} --- A powerful modern language for +both systems and general programming. +C provides data structuring, recursion, automatic storage, a fairly +standard set of control constructs, a rich set of operators, +and considerable conciseness of expression. + +\medskip \noindent \irafname{char} --- The smallest signed integer that can be +directly addressed by programs written in the SPP language. The char +is also the unit of storage in IRAF programs; the sizes of objects are +given in units of chars, and binary files and memory are addressed in +units of chars. Since the SPP language interfaces to the machine via the +local Fortran compiler, the Fortran compiler determines the size of a char. +On most systems, the IRAF data type \emphasize{char} is equivalent to the +(nonstandard) Fortran datatype I$*$2. + +\medskip \noindent \irafname{CL} --- The IRAF Command Language. The CL is an +interpreted language designed to execute external \irafname{tasks}, and +to manage their \irafname{parameters}. +The CL organizes tasks into a hierarchical structure of independent +\irafname{packages}. Tasks may be either \irafname{script tasks}, written in +the CL, or compiled \irafname{programs}, written in the SPP language, and +linked together to form \irafname{processes}. A single process may contain +an arbitrary number of tasks. + +The CL provides \irafname{redirection} of all I/O streams, including graphics +output, and cursor readback. Other facilities include command logging, an +on-line help facility, a ``programmable desk +calculator'' capability, and a \irafname{learn mode}. +New packages and tasks are easily added by the user, +and the CL environment is maintained in the user's own directories, +providing continuity from session to session. + +\medskip \noindent \irafname{column} --- a one-dimensional array. The Nth +column vector of a two dimensional array or image is denoted +by the subscript [N,$*$], +where $*$ refers to all the pixels in that dimension. +The Nth column of the Mth band of a three dimensional array or image +is denoted by [N,$*$,M]. + +\medskip \noindent \irafname{coupling} --- A measure of the strength of +interdependence among modules. +The independence of modules is maximized when coupling is minimized. + +\medskip \noindent \irafname{CTIO} --- Cerro Tollolo Image Observatory, +one of the NOAO facilities located in Chile. + +\medskip \noindent \irafname{data structure} --- An aggregate of two or more +data elements, where the elements are not necessarily of the same type. +Examples include arrays, files, rec\-ords, linked lists, +trees, graphs, and so on. + +\medskip \noindent \irafname{data file} --- a data storage file. Data +files are used to store program generated \irafname{records} or descriptors, +that contain the results +of the analysis performed by a program. Datafile records may be the +final output of a program, or may be used as input to a program. Data +file may contain ASCII or binary data, and may have implicit or explicit +data structures. + +\medskip \noindent \irafname{environment variables} --- Parameters that +affect the operation of \emphasize{all} IRAF programs. +Environment variables define logical names for directories, associate +physical devices with logical device names, and provide control +over the low level functioning of the IRAF file I/O system. + +\medskip \noindent \irafname{ECF} --- European Coordination Facility. The +center that is to coordinate use of Space Telescope data and programs for +the European scientific community. + +\medskip \noindent \irafname{ESO} --- European Southern Observatory, +headquartered at Garching, FDR. + +\medskip \noindent \irafname{field} --- An element of a \irafname{data +structure} or \irafname{record}. Each field has +a name, a datatype, and a value. + +\medskip \noindent \irafname{FITS} --- Flexible Image Transport System. FITS is +a standard tape format used to transport images (pictures) between computers +and institutions. Developed in the late 1970s by Donald Wells (KPNO), +Eric Greisen (NRAO), and Ron Harten (Westerbork), +the FITS standard is now widely used for the +interchange of image data between astronomical centers, and is officially +sanctioned by both the AAS and the IAU. + +\medskip \noindent \irafname{Fortran} --- As the most widely used language +for scientific computing for the past +twenty years, Fortran needs little introduction. Fortran is used in the +IRAF system as a sort of ``super assembler'' language. Programs and procedures +written in the IRAF \irafname{SPP} language are mechanically translated +into a highly +portable subset of Fortran, and the Fortran modules are in turn translated +into object modules by the host Fortran compiler. Existing numerical +and other modules, already coded in the Fortran language, are easily linked +with modules written in the SPP language to produce executable programs. +The IRAF system and applications software does not use any Fortran I/O; +all I/O facilities are provided by the IRAF \irafname{program interface} and +\irafname{virtual operating system}. + +\medskip \noindent \irafname{function} --- A procedure which returns a value. +Functions must be declared before they can be used, and functions must only be +used in expressions. It is illegal to \emphasize{call} a function. + +\medskip \noindent \irafname{HSI} --- The IRAF Host System Interface, +i.e., the interface between the portable IRAF software and the host system. +The HSI include the \irafname{kernel}, the \irafname{bootstrap utilities}, +and any host dependent graphics device interfaces. + +\medskip \noindent \irafname{hidden parameters} --- Parameters that +are not displayed by the CL. +The CL does not query for hidden parameters, but automatically +uses the default values. Hidden parameters may be set on the command line, +but the value from the command line will not be \irafname{learned}. + +\medskip \noindent \irafname{IAU} --- The International Astronomical Union. + +\medskip \noindent \irafname{IKI} --- The Image Kernel Interface. The IKI +gives IRAF the capability of dealing with multiple physical image storage +formats. The high level image i/o software calls the IKI, which in turn +calls one of the format specific image kernels, e.g., the OIF kernel or +the STF kernel. + +\medskip \noindent \irafname{identifier} --- A sequence of characters used to +name a procedure, variable, etc. in a compiled language. In the CL and +SPP languages, an identifier is an upper or lower case letter, followed +by any number of upper or lower case letters, digits, or underscore characters. + +\medskip \noindent \irafname{image} --- An array of arbitrary dimension +and datatype, used for bulk data storage. +An image is an array of \irafname{pixels}. + +\medskip \noindent \irafname{imagefile} --- The form in which images are +stored in the IRAF system. IRAF currently supports images of up to seven +dimensions, in any of eight different data types. +Only \emphasize{line storage} mode is currently available, but support for +VMS mapped image sections is planned. +The imagefile structure is actually implemen\-ted as two separate files, +an \irafname{image head\-er file} and a \irafname{pixel storage file}. + +\medskip \noindent \irafname{image header file} --- a file describing the +contents of an image. It is a small file that is normally placed in the +user's own directory system. + +\medskip \noindent \irafname{interface} --- The visible portion of a +system, program or collection of programs. The only portion of such a +entity that other entities need to have knowledge of or access to. +The connection between hardware or software entities. + +\medskip \noindent \irafname{IRAF} --- The Image Reduction and Analysis +Facility. +IRAF comprises a \irafname{virtual operating system}, a command language +(CL), a general purpose programming language (SPP, which +was developed along with IRAF), a large I/O library, and numerous support +utilities and scientific applications programs. The system is designed to be +transportable to any modern superminicomputer. The +system provides extensive facilities for general image processing, +astronomical data reduction and analysis, scientific programming, +and general software development. + +\medskip \noindent \irafname{IRAF Guru} --- Any individual whose knowledge +of IRAF is greater than yours. Gurus' wisdom embraces all of the essential +mysteries of IRAF, and usually includes the locations of good Chinese +restaurants. + +\medskip \noindent \irafname{kernel} --- A host dependent library of SPP +(or Fortran) callable subroutines implementing the primitive system services +required by the portable IRAF virtual operating system (VOS). Most of the +machine dependence of IRAF is concentrated into the kernel. + +\medskip \noindent \irafname{learn mode} --- A facility designed +to simplify the use of the CL. By default, the CL ``learns'' the value of all +function \irafname{parameters} that are prompted for or explicitly set. + +\medskip \noindent \irafname{line} --- A one-dimensional array. The Nth line +of a two dimensional array or image is denoted +by the subscript [$*$,N], +where $*$ refers to all the pixels in that dimension. +The Nth line of the Mth band of a three dimensional array or image +is denoted by [$*$,N,M]. + +\medskip \noindent \irafname{list structured parameter} --- A text file, each +line of which is a record that contains one or more fields, separated +by blanks or commas, that can be interpre\-ted by the CL. +Not all fields need be present, omitted fields are indicated by insertion +of an extra comma (fields can only be omitted +from right to left). + +\medskip \noindent \irafname{Lroff} --- The text formatter that is part of +the portable IRAF system and used to process \irafname{help} file text. +Lroff is patterned after the UNIX \irafname{Troff} text formatter. + +\medskip \noindent \irafname{macro} --- (1) A \irafname{script task}. +(2) An inline function with zero or more arguments that is +expanded by text substitution during the preprocessing phase +of compilation. + +\medskip \noindent \irafname{metacharacter} --- Characters that have special +meaning to the CL. For example, the asterisk `$*$' is used as a ``wild card'' +place-holder; any alphanumeric character is considered a match. + +\medskip \noindent \irafname{MIDAS} --- Munich Image Data Analysis System. +An analysis package under development by the ESO. + +\medskip \noindent \irafname{NOAO} --- National Optical Astronomy +Observatories. + +\medskip \noindent \irafname{NRAO} --- National Radio Astronomy Observatory. + +\medskip \noindent \irafname{operand} --- A data object that is +operated upon by an operator, \irafname{procedure}, or \irafname{task}. +Operands may be used for either input or output, or both. + +\medskip \noindent \irafname{OIF} --- The old IRAF image format. Refers to the +physical format in which images are stored on disk, as well as to the +\irafname{IKI} kernel used to access images stored externally in the OIF format. + +\medskip \noindent \irafname{OS} --- Operating System. + +\medskip \noindent \irafname{package} --- (1) A collection of modules that +are logically related (e.g., the set of \irafname{system} utilities). +(2) A set of modules that operates on +a specific \emphasize{abstract datatype}. The modules in a package may be +either \irafname{procedures} or \irafname{tasks}. +Examples of abstract datatypes include the CL, the file, +the \irafname{imagefile}, and so on. + +\medskip \noindent \irafname{parameter} --- An externally supplied +argument to a module which directly controls the functioning of the module. + +\medskip \noindent \irafname{pathname} --- An absolute OS-dependent filename +specification. + +\medskip \noindent \irafname{pipe} --- An abstraction that connects the output +of one \irafname{task} to the input of another. The implementation of pipes +is OS-dependent. + +\medskip \noindent \irafname{pixel} --- Picture element. The fundamental unit +of storage in an \irafname{image}. + +\medskip \noindent \irafname{pixel storage file} --- a file that contains image +pixel data. Typically, it is a bulky file and for this reason it is usually +placed in a file system designated for such files. + +\medskip \noindent \irafname{portable} --- A program is said to be portable +from computer A to computer B if it can be moved from A to B without change +to the source code. +A program is said to be \emphasize{transportable} from computer A to computer B +if the effort required to move the program from A to B is much less than the +effort required to write an equivalent program on machine B from scratch. + +\medskip \noindent \irafname{positional parameters} --- Parameters +that are required for the execution of a given \irafname{function}, +and will be queried for by the CL if not given on the command line. Positional +\emphasize{arguments} are the first arguments on the command line (following +the command), and they are associated with parameters by their position +on the command line. The first positional parameter will be set by the first +positional argument on the command line, the second positional parameter by +the second positional argument, and so on. + +\medskip \noindent \irafname{preprocessor} --- A program which transforms the +text of a source file prior to compilation. A preprocessor, unlike a compiler, +does not fully define a language. A preprocessor transforms only those +constructs which it understands; all other text is passed on to the compiler +without change. The SPP language is implemented as a pre-processor. + +\medskip \noindent \irafname{procedure} --- A separately compiled program unit. +The procedure is the primary construct provided by programming languages for +the \emphasize{abstraction of function}. +The external characteristics of a procedure are its name, argument list, +and optional return value. + +\medskip \noindent \irafname{process} --- An executable partition of +memory in the host computer. +The host OS initiates a process by copying or mapping an executable file +into main memory. In a multitasking and multiuser system, a number of processes +will generally be resident simultaneously in main memory, +and the processor will execute each in turn. + +\medskip \noindent \irafname{program} --- A compiled procedure called by the +CL. The procedure must be referenced in a \irafname{task} statement before it +can be accessed by the CL. An arbitrary number of programs may be +linked to form a single \irafname{process}. + +\medskip \noindent \irafname{program interface} --- The interface between an +applications program and everything else. In IRAF, the program interface +defines access to all I/O devices, system services, files, and several +other non-computational facilities that pro\-grams require. + +\medskip \noindent \irafname{record} --- A \irafname{data structure} consisting +of an arbitrary set of fields, used to pass information between program modules +or to permanently record the results of an analysis program in a +\irafname{data file}. + +\medskip \noindent \irafname{redirection} --- The allocation of an input or +output stream to something other than the standard device. For example, +\irafname{tasks} can be made to write output to files instead of terminals +and the output of one task may be redirected to the input of another. + +\medskip \noindent \irafname{script task} --- An interpreted program written +in the CL. A script task, like a compiled program, may have formal parameters +and local variables. A script task may call another task, including another +script task, but may not call itself. +To the caller, script tasks and compiled programs are equivalent. + +\medskip \noindent \irafname{SDAS} --- Science Data Analysis System. A set +of applications routines that are under development at STScI. + +\medskip \noindent \irafname{SPP} --- The IRAF Subset Preprocessor Language. +A general purpose language patterned after Ratfor and C, the SPP provides +advanced capabilities, modern control constructs, enhanced portability, +and support for the IRAF runtime library (CL interface, etc.). + +\medskip \noindent \irafname{STF} --- The STScI SDAS group data image format. +Refers to the physical format in which images are stored on disk, as well as +to the \irafname{IKI} kernel used to access images stored externally in the +STF format. + +\medskip \noindent \irafname{STScI} --- Space Telescope Science Institute. + +\medskip \noindent \irafname{system interface} --- The interface between +the portable IRAF software and the host operating +system. The system interface is a \irafname{virtual operating system}. +The system interface routines, described in \reference{A Reference Manual +for the IRAF System Interface} +are in principle the only parts of a system that need to be changed +when porting the system to a new computer. + +\medskip \noindent \irafname{task} --- A CL callable program unit. +CL tasks may be script tasks, external programs, +or compiled procedures which are built in to the CL. + +\medskip \noindent \irafname{task statement} --- (1) The CL statement that +enters the name of a task in the IRAF task dictionary, +defines the type of task, and in the case of a compiled task, the name of +the process in which it resides. +(2) The statement in the SPP language that defines a list of programs +to be linked together to form a single process. + +\medskip \noindent \irafname{template} --- A string consisting of one or more +names, which may or may not contain patterns +(with \irafname{metacharacters}). + +\medskip \noindent \irafname{text file} --- A file which contains only +text (ASCII character data), and which is maintained +in the form expected by the text processing tools of the host OS. + +\medskip \noindent \irafname{Troff} --- The UNIX text formatter. + +\medskip \noindent \irafname{unary operator} --- An operator which operates on +a single operand, e.g., the minus sign in the expression ``$-x$''. + +\medskip \noindent \irafname{UNIX} --- An operating system developed at Bell +Labs in the early 1970s by Ken Thompson and Dennis Ritchie. Originally +developed for the PDP11, UNIX is now available on a wide range of machines, +ranging from micros to superminis, mainframes, and supercomputers.\\ +UNIX is the software development system for the IRAF project at NOAO. + +\medskip \noindent \irafname{virtual file} --- A file that uses a machine +independent filename within IRAF. The virtual filename is mapped to its +host OS counterpart by the CL. + +\medskip \noindent \irafname{virtual memory} --- A form of addressing that +enables a process to address locations that are not in physical memory. +The amount of physical memory available to a process is known as the +\emphasize{working set} of a process; the virtual address space is organized +into a series of fixed size \emphasize{pages}. Pages which are not +\emphasize{memory resident}, i.e., not in the working set, reside on some form +of backing store, usually a disk file. When a page is referenced which is not +in the working set, a \emphasize{page fault} occurs, causing the page to be +read into the working set. + +\medskip \noindent \irafname{virtual operating system} --- A set of system +calls that define primitive functions comparable +to those provided by an actual operating system. +IRAF provides routines (the so-called +\irafname{program interface}) for file access, process initiation and control, +exception handling, logical names, etc. + +\medskip \noindent \irafname{VMS} --- The native operating system for the +Digital VAX series of supermini computers. + +\medskip \noindent \irafname{VOS} --- The IRAF Virtual Operating System. +The VOS implements all of the basic functionality provided by IRAF, and defines +the environment in which applications programs are written. For example, +the VOS provides facilities for file access, image access, access to graphics +and image display devices, access to the command language to fetch parameters +etc., process control and exception handling facilities, and so on. The VOS +is written in portable SPP using the facilities provided by the IRAF +\irafname{kernel}. + +\medskip \noindent \irafname{Z-routines} --- Machine dependent routines used +to interface to the host operating system. The IRAF Z-routines are maintained +in the package \taskname{OS}. + +\onecolumn + +\end{document} diff --git a/doc/cluser_toc.ms b/doc/cluser_toc.ms new file mode 100644 index 00000000..1b2f226b --- /dev/null +++ b/doc/cluser_toc.ms @@ -0,0 +1,52 @@ +.RP +.ce +\fBContents\fR +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'1.1.\h'|0.9i'Function of the Command Language\l'|5.6i.'\0\01 +.br +\h'|0.4i'1.2.\h'|0.9i'Capabilities of the CL\l'|5.6i.'\0\02 +.sp +2.\h'|0.4i'\fBGetting Started\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Setting up the IRAF environment\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'Starting the CL\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.3.\h'|0.9i'Executing commands from the CL\l'|5.6i.'\0\03 +.sp +3.\h'|0.4i'\fBBasic Usage\fP\l'|5.6i.'\0\05 +.br +\h'|0.4i'3.1.\h'|0.9i'CL parameters\l'|5.6i.'\0\05 +.br +\h'|0.4i'3.2.\h'|0.9i'Environment Variables\l'|5.6i.'\0\05 +.br +\h'|0.4i'3.3.\h'|0.9i'File and directory names\l'|5.6i.'\0\07 +.br +\h'|0.4i'3.4.\h'|0.9i'Parameters\l'|5.6i.'\0\08 +.br +\h'|0.9i'3.4.1.\h'|1.5i'Hidden parameters\l'|5.6i.'\0\09 +.br +\h'|0.9i'3.4.2.\h'|1.5i'Specifying the parameters to a task\l'|5.6i.'\0\10 +.br +\h'|0.4i'3.5.\h'|0.9i'Pipes and i/o redirection\l'|5.6i.'\0\11 +.br +\h'|0.4i'3.6.\h'|0.9i'Command Syntax\l'|5.6i.'\0\11 +.br +\h'|0.4i'3.7.\h'|0.9i'Aborting tasks\l'|5.6i.'\0\12 +.br +\h'|0.4i'3.8.\h'|0.9i'Background Jobs\l'|5.6i.'\0\12 +.br +\h'|0.4i'3.9.\h'|0.9i'Sending commands to the host operating system\l'|5.6i.'\0\13 +.sp +4.\h'|0.4i'\fBAdvanced Usage\fP\l'|5.6i.'\0\13 +.br +\h'|0.4i'4.1.\h'|0.9i'The History mechanism\l'|5.6i.'\0\13 +.br +\h'|0.4i'4.2.\h'|0.9i'Expressions and intrinsic functions\l'|5.6i.'\0\15 +.br +\h'|0.4i'4.3.\h'|0.9i'Image Sections\l'|5.6i.'\0\16 +.br +\h'|0.4i'4.4.\h'|0.9i'Statements and inline scripts\l'|5.6i.'\0\17 diff --git a/doc/crib_title.ms b/doc/crib_title.ms new file mode 100644 index 00000000..55c8b4ee --- /dev/null +++ b/doc/crib_title.ms @@ -0,0 +1,31 @@ +.RP +.TL +Programmer's Crib Sheet +.br +for the +.br +IRAF Program Interface +.AU +Douglas Tody +.AI +.K2 "" "" "*" +September 1983 +.AB +IRAF applications programs, as well as most IRAF system programs, are +written in the IRAF SPP language with calls to the library routines +comprising the IRAF \fIprogram interface\fR. The program interface +includes routines for file i/o, formatted i/o, command language (CL) i/o, +database i/o, image i/o, graphics i/o, magnetic tape i/o, and memory i/o. +Routines are also provided for manipulating virtual file names, for date +and time, process control, exception handling, bitwise boolean operations, +string operations, character comparisons, vector operations (array +processing), sorting, pattern matching, and random number generation. +.PP +Only the machine independent part of the program interface is described +here; the machine dependent OS interface is not intended for use in +applications programs and is therefore not described here. An extensive +collection of mathematical library routines is available but is described +elsewhere. As its name implies, the "crib sheet" does not explain how +to use the program interface routines; little more than the calling +sequence for each routine is given. +.AE diff --git a/doc/decnet_iraf.txt b/doc/decnet_iraf.txt new file mode 100644 index 00000000..78b74aba --- /dev/null +++ b/doc/decnet_iraf.txt @@ -0,0 +1,365 @@ +Notes on networking with DECNET in VMS/IRAF V2.3 - V2.5 +------------------------------------------------------- + +VMS/IRAF networking using DECNET is supported in a limited way in IRAF +releases 2.3 - 2.5. As IRAF networking may change somewhat after V2.5, we +are currently providing these notes only in an informal manner upon request. +Warning: we have not had the opportunity to verify these procedures in all +possible environments, so they may be inaccurate or incomplete. + +IRAF networking is the preferred way to gain access to peripherals on a +remote computer, on systems for which IRAF supports networking internally +(i.e. TCP/IP at present). These peripherals might include printers, +plotters, supported image display devices and large disks. The decnet +network interface does not, at present, permit access to tape drives on +a remote machine. At present, if tape drive access is needed, it will be +necessary to perform a normal IRAF installation on the remote and use the +tape reading facilities on that machine directly (once installed, the +system may be stripped considerably, though). + +If your system uses only DECNET, it may or may not be necessary to use IRAF +networking, depending upon what peripherals it is desired to access on the +remote node. Early testing with a minimal `kernel server' configuration +on the remote is promising and very easy to implement. However, if for some +reason it is not possible to use IRAF networking in this manner, IRAF can be +set up to use DCL command procedures to send printer and plotter output to +the remote node. Contact us to find out if this will work on your system. +Read on if you would like to set up IRAF networking with DECNET. + +The default network protocol on the distributed systems is TCP/IP, because +that is what we use in the local NOAO network. In its present form, the +choice of network protocol is a compile-time option. In IRAF V2.3 one would +edit a file or two, compile with the DEC C compiler, and perform a +relink-sysgen. In IRAF V2.5 the appropriate object file is supplied +automatically (unless you have a source-only distribution or have stripped +all object files from the system), but you would still need to rebuild the +shared library and perform a sysgen. + +There are two ways to use internal IRAF networking: between two fully- +installed IRAF systems, and between one fully-installed system and a +`kernel server' system. The steps below under `Configuring IRAF networking +for DECNET' apply to a fully-installed system, and would have to be taken +for at least one node in an IRAF network. See the section below under +"Server Nodes" if you are using the remote purely for access to peripheral +devices, but not for running IRAF. In node name references in these notes +we will use the convention HOMENODE = fully-installed system, and SERVERNODE = +the server-only node. + + +--------------------------------------------------------------------------- +Configuring IRAF networking for DECNET on a fully-installed system: +This is a summary of the steps you will take: + + o build a decnet version of zfioks.obj and load it into a library + o rebuild the shared library + o relink all the IRAF executables + o edit dev$hosts + o create .irafhosts files in IRAF home directories on home node + o create irafks.com files in VMS login directories on server node + +[1] Get into the directory os$net ([iraf.vms.os.net]). Check to see if there + is a file zfioks_obj.dna (distributed in IRAF V2.5). If there is not, go + to step [2]. If there is, copy it: + + $ copy zfioks_obj.dna zfioks.obj + + ...and proceed to step [3]. + +[2] (There was no zfioks_obj.dna file in [iraf.vms.os.net], so we will + attempt to create one.) + + [a] If you do not have a DEC C compiler, contact us to see about getting + a copy of zfioks.obj built for DECNET; you will not be able to proceed + further until you do. + + [b] You do have a DEC C compiler, so edit zfioks.c and compile it: + + $ edit zfioks.c + change from: + #define DECNET 0 + #define TCP 1 + to: + #define DECNET 1 + #define TCP 0 + + $ cc/nolist zfioks.c + +[3] Load the zfioks object file into the IRAF kernel library: + + $ lib/replace [iraf.vms.hlib]libos.olb zfioks.obj + $ delete zfioks.obj;* + +[4] Make sure the system is configured for IRAF networking. Examine + the file [iraf.vms.hlib]mkpkg.inc, and make sure USE_KNET = yes: + + $set USE_KNET = yes # use the KI (network interface) + +[5] Assuming you are using the shared library, the default, you now + need to regenerate that library. If for some reason you are not + using the shared library, you may proceed to step [6]. To rebuild + the shared library, carry out the steps in section 5.1.3 of the + "VMS/IRAF Installation and Maintenance Guide", July 1987, then + proceed to step [6]. + +[6] Relink the main IRAF system. To do this, carry out the instructions + in section 5.1.4 of the Installation Guide. + +[7] Edit two files in dev$: + + hosts set up node names for your site + hostlogin (optional) set up default public logins if any + +[8] Create .irafhosts files in the IRAF login directories of users who plan + to use networking on HOMENODE. The file's format is a series of lines + of the form: + + alias1 alias2 ... aliasN : loginname password + + If the same login name and password are used on several nodes, an "*" may + be used as the alias. The file should be read protected; also, a `?' may + be used in place of the password (you will be prompted). For example: + + # .irafhosts file + node1 node3 : mylogin mypassword + * : otherlogin ? + +[9] Place a DCL command file called "irafks.com" in the VMS login directories + of all IRAF network users on SERVERNODE (or on both nodes for two-way + network traffic): + + $! IRAFKS.COM -- DCL command file to run the IRAF/DECNET kernel server. + $! Note: the path to the server directory MUST be fully specified + $! below (i.e. substitute your actual disk name for "DISK"). + $! + $! set verify !*debug* + $! netserver$verify = 1 !*debug* + $! + $ set default DISK:[irafserve] + $ @irafuser.com + $ run irafks.exe + $ logout + + where DISK is of course the IRAF disk; the decnet server has no access + to globally defined IRAF symbols or logicals like IRAFDISK until it can + execute irafuser.com. + + +This completes the basic installation; the steps are the same for both +nodes if two-way IRAF network traffic is desired. + + +------------------------------------------------------------------------------ +Server Nodes: +This is a summary of the steps you will take: + + o build non-shared library version of irafks.exe + o install and edit the following files in [irafserve] on server node: + + o irafks.exe + o irafuser.com + o irafks.com + o login.com + o zzsetenv.def + +If a remote node is to be used purely for access to peripherals (you don't +plan to actually run anything in IRAF on the remote node directly), you need +only install a tiny subset of the IRAF system on it. + +[a] (On the existing fully-installed IRAF system, HOMENODE) + Get into the directory [iraf.sys.ki] and link a copy of the IRAF + kernel server executable without the shared library. Note that you + must have first followed the steps above for creating a DECNET version + of this system. + + $ xc -z irafks.o + + You will need the executable file IRAFKS.EXE resulting from this step + shortly, but it may be deleted after being copied to the remote system. + +[b] (On the remote, or `kernel server' system, SERVERNODE) + Ask the system manager to create an IRAF account as was done for the + the main IRAF installation, as in section 2.1 of the 1987 VMS/IRAF + Installation Guide. Although it is not strictly necessary to have an + actual account for IRAF on this machine, it would be helpful should + it ever be necessary for us to debug anything on it. Have its default + directory set to [IRAFSERVE] rather than [iraf.local], and create the + directory [irafserve] (this could be put elsewhere; you would simply + change all references to [irafserve] in these notes). + + Also have the system manager insert the following global symbol definition + into the system-wide login file (e.g. sys$manager:sylogin.com): + + $ irafserve :== @DISK:[irafserve]irafuser.com + + If this is not done, then each user must explicitly execute that `@' + command in their own login.com files. + +[c] (On the remote, or `kernel server' system, SERVERNODE) + Log in as IRAF. You should be in the [irafserve] directory. + Copy the newly-created kernel server executable and some other files + from the fully-installed system onto the kernel server system. + The file irafks.com was discussed in step [9] above; if you do not + have one on HOMENODE, just create it here. + + $ set def [irafserve] + $ copy HOMENODE"account password"::DISK:[iraf.sys.ki]irafks.exe [] + $ copy HOMENODE"account password"::DISK:[iraf.vms.hlib]irafuser.com [] + $ copy HOMENODE"account password"::DISK:[iraf.vms.hlib]zzsetenv.def [] + $ copy HOMENODE"account password"::DISK:[iraf.local]login.com [] + $ copy HOMENODE"account password"::DISK:[iraf.local]irafks.com [] + + with the appropriate substitutions of course. + + Edit irafuser.com to set the logical name definitions IRAFDISK, + IMDIRDISK, and TEMPDISK for the server node. + + $ edit irafuser.com (etc.) + + Make sure the first executable lines in login.com are as below: + + $ edit login.com + + "$ set prot=(s:rwd,o:rwd,g:rwd,w:r)/default" + "$ if (f$mode() .eqs. "NETWORK") then exit" + + Change the DISK specification for the server system in irafks.com to + be the actual disk (or a system-wide logical name for it) -- see + step [9]. + + $ edit irafks.com (etc.) + +[d] Insert irafks.com files into the VMS login directories on the server + node of any IRAF users wanting access to this node. If plotter + access is desired, it is essential that the users' login.com files + explicitly execute the [irafserve]irafuser.com file, and desirable + that they exit if mode = NETWORK (to avoid lots of error messages + in NETSERVER.LOG files). For example (in user's login.com): + + $ set prot=(s:rwd,o:rwd,g:rwd,w:r)/default + $ if (f$mode() .eqs. "NETWORK") then exit + ... + $ irafserve ! define IRAF logicals for plotting + + (The global symbol "irafserve" was defined in the system-wide login + file in step [b] above.) + +This completes the basic network configuration. Although setting up plotting +devices in a network environment can be complicated, here are some guidelines +for installing SGI translators on a kernel server node. + + +-------------------------------------------------------------------------------- +Guidelines for installing SGI translators on kernel server node: +This is a summary of the steps needed: + + o on home node, edit dev$graphcap (and dev$hosts if necessary) + o copy hlib$sgiqueue.com to server and edit it + o copy hlib$sgi2XXXX.exe to server (one for each SGI translator) + +[e] On the home node, edit the graphcap file (dev$graphcap) to insert the + server node prefix into the device name part of the DD string. For + example, if device `vver' lives on SERVERNODE, and the DD string for + that device begins with: + + :DD=vver,tmp$sgk,... + + change it to: + + :DD=SERVERNODE!vver,tmp$sgk,... + + with appropriate substitution for SERVERNODE. If all the plotters to + which you want access are on the same node, you can use the `plot' + alias; just make sure `plot' is an alias for SERVERNODE in dev$hosts + (see `Configuring IRAF networking for DECNET' above). Also make sure + the printer queue names in the DD string are appropriate for SERVERNODE + or "none" if the devices are not spooled. E.g.: + + :DD=plot!vver,tmp$sgk,submit/que=fast/noprint/nolog \ + /para=\050"vver","$F","$(PX) $(PY) VERSAQUEUE","$F.ras"\051 \ + irafhlib\072sgiqueue.com:tc=sgi_versatec: + + +[f] Copy the home node's hlib$sgiqueue.com file to the [irafserve] directory + on SERVERNODE and edit it for the local printer queue names, etc. + Also replace the "irafhlib" in the VMS task definitions, as the translators + on SERVERNODE reside in the same directory as sgiqueue.com, i.e. + [irafserve]. E.g.: + + $ sgi2vver := $DISK:[irafserve]sgi2vver ! versatec interface + +[g] Copy the home node's SGI translators to the [irafserve] directory on + SERVERNODE. + +There are many different ways of interfacing plotters in VMS environments, +so these notes will not work in all cases. Call the IRAF Hotline if you +have any trouble at all [(602) 323-4160]. + + +------------------------------------------------------------------------ +Using the network: + +User summary: each user desiring IRAF network access should have the +following files, as described above: + + on HOMENODE: .irafhosts in IRAF home directory + on SERVERNODE: irafks.com in VMS login directory + on SERVERNODE: "irafserve" command in VMS login.com file + +In some cases, for example where the local node is a MicroVAX with +comparatively slow disk drives and the remote is a big VAX with very +fast disk drives, an image may actually be accessed faster on the remote +over the IRAF network than it can be locally. + +When working on images across the network, it is best to store the pixel +files in the same directory as the image headers, or in a subdirectory. +This is done by "set imdir = HDR$". Or, to cut the size of the directory +in half by placing the pixel files in a subdirectory called "pixels", +"set imdir = HDR$pixels/". To cut down on typing, you might also define +a logical directory for your data area on the remote, "dd" for example. +Thus you could place the following lines in your login.cl file: + + set imdir = HDR$pixels/ + set dd = bigvax!mydisk:\[mydir.iraf.data] + +Suppose you are now in the CL on the HOMENODE, and you want to run IMPLOT +on an image called test001 on the remote node BIGVAX, in directory +[mydir.iraf.data], and then copy it to your current directory on node A: + + pl> implot dd$test001 + pl> imcopy dd$test001 test001 + +The logical directory dd$ may be used in most of the normal fashions (you +won't be able to "chdir" to it). Both IRAF virtual file names may be used +(including all the usual system logical directories) and host file names. +As usual in VMS/IRAF, any "$" and "[" in HOST-system pathnames must be +escaped with "\", and lowercase filenames should only be used in IRAF +virtual filenames. Various file access examples follow: + + Use of environment variable (see above)to cut down on typing: + + cl> set dd = bigvax!mydisk\$1:\[mydir.iraf.data] + cl> dir dd$ + cl> page dd$README + im> imhead dd$*.imh + + Use of IRAF virtual filenames explicitly: (this will only work on + systems where bigvax is a fully-installed system; the IRAF virtual + directories may not be present on a server-only system) + + cl> count bigvax!local$notes + cl> tail bigvax!local$notes nl=100 | page + cl> dir bigvax!hlib$*.com long+ + cl> dir bigvax!sys$gio/R* long+ + cl> page bigvax!sys$gio/README + cl> page bigvax!home$login.cl + cl> dir bigvax!tmp$sgk* long+ + + Use of host-system pathnames: + + cl> dir bigvax!usr\$0:\[mydir.iraf]*.imh + cl> copy bigvax!usr\$0:\[mydir.doc]letter.txt newletter.txt + cl> history 100 > bigvax!usr1:\[mydir]test.his + +Please remember that this is a developing interface, and that it has not +yet been tested as extensively as we would like. We would appreciate being +contacted about any problems you uncover. diff --git a/doc/doc/biblio84.hlp b/doc/doc/biblio84.hlp new file mode 100644 index 00000000..34139777 --- /dev/null +++ b/doc/doc/biblio84.hlp @@ -0,0 +1,344 @@ +.help biblio84 Feb84 "Bibliography of IRAF Documentation" +.ce +\fBBibliography of IRAF Documentation\fR +.ce +February 25, 1984 + + + The IRAF system is still under development and has not yet been released +for use outside KPNO. The amount of top-level, end user documentation +available is therefore minimal at this point. Most of the documentation +currently available is either design documentation or programmer documentation. +We have collected all of the documentation that we thought might be +interesting together in one place, accessible from both the terminal and +from UUCP, so that people would have easy access to the docs. This bibliography +introduces each document. The source directory is "~uucp/IRAF" or +equivalently, "/usr/spool/uucppublic/IRAF". + + Each document entry consists of a list of one or files, one file per line, +followed by a brief description of the document. The file list entries are +taken directly from the output of the directory lister to eliminate the +possibility of an error. Each entry includes the size of the source file in +bytes (100K is roughly 35 pages for a .ms file and 45 pages for a .doc file), +the date when the file was last updated in the bibliography, and the name of +the file. Sometimes a single document consists of several files. + + The ".ms" extension files contain Troff source text using the MS macros and +occasionally Tbl; the KPNO version of the "tmac" MS macro file is included in +the bibliography so that you can reproduce the Troff documents exactly as +they would appear at KPNO. The ".doc" extension files are preformatted 72 +columns by 60 lines with formfeed characters inserted between pages, suitable +for printing on most line printers without further processing. + + + +.ce +\fBGeneral & Miscellaneous\fR + + +-rw-r--r-- 1 tody 13292 Feb 26 12:57 BIBLIO + + A possibly newer version of what you are looking at. + + +-rw-r--r-- 1 iraf 3550 Feb 25 11:39 CvsF77 + + Discusses the relative merits of C versus Fortran for scientific +programming. Attempts to answer the questions (1) why not just use +Fortran like everyone else?, and (2) why not just use C if you are +already using UNIX? + + +-rw-r--r-- 1 iraf 10637 Feb 25 11:57 cover.ms + + A letter introducing the IRAF system, where its all coming from, +what we are trying to achieve, etc. This is the cover letter for +mailed IRAF documentation sets. The bulk of the letter is similar +to the announcement sent out over UNET. + + +-rw-r--r-- 1 iraf 4518 Feb 25 11:51 history.doc + + Summarizes what the IRAF system provides, and outlines the history +of the project (through the fall of 83 when the doc was written). +This is just a short outline; no discussion is given. + + +-rw-r--r-- 1 iraf 51295 Feb 25 12:00 irafplan.ms + + A Feb84 document presenting the detailed IRAF program implementation +plan for 84 and 85. Hard to follow unless you know the system well. + + +-rw-r--r-- 1 iraf 24451 Feb 25 12:34 irafdirs + + A recursive listing of all the directories and file names on our UNIX +based IRAF software development system, for those of you are curious +about how the sources are structured, or who want more information +about what the system currently contains. + + +-rw-rw-rw- 1 iraf 8491 Feb 25 13:14 newsfile + +The "news" from the IRAF software development system. Will be +updated periodically. + + +-rw-rw-r-- 1 iraf 25759 Feb 25 13:13 revsfile + + All revisions to released software, and all releases of new programs +or packages are recorded in the revisions file. This is a snapshot +of the revsfile on our software development system; it will be updated +periodically. When eventually the system is released for use outside +KPNO, the revsfile will be distributed with each successive release +to document all changes and additions to the system. + + +-rw-r--r-- 1 kpno 23131 Feb 26 11:29 tmac + + The KPNO MS-macro file for text processing Troff files. This has nothing +to do with IRAF, but is included so that the ".ms" suffixed documents can be +reproduced exactly by non-KPNO sites. + + +.ce +\fBProgrammer and User documentation\fR + + +.nf +-rw-r--r-- 1 iraf 2959 Feb 25 11:57 clman_toc.ms +-rw-r--r-- 1 iraf 56362 Feb 25 11:57 clman.ms +.fi + + The "CL Programmers Guide", rev Sept83. This is currently the most up +to date documentation available for the CL (command language), though +the CL went through a major revision in the fall of 83, adding many +features which have not yet been documented (these CL mods predate +the use of the revsfile). + + +.nf +-rw-r--r-- 1 iraf 1234 Feb 25 11:58 crib_title.ms +-rw-r--r-- 1 iraf 43315 Feb 25 11:58 crib.doc +.fi + + The "Programmer's Crib Sheet for the IRAF Program Interface". +Summarizes the packages and library procedures comprising the program +interface, i.e., the interface between an IRAF applications program +and the world (file i/o, CL i/o, image i/o, etc.). This is currently +the only comprehensive documentation available for the program +interface; the "Programmer's Reference Manual" and "Programmer's +Guide" have not yet been written. Additional information is however +available in the technical specifications for the various packages +(see "design documentation" below). + + +-rw-r--r-- 1 iraf 32552 Feb 25 11:59 imexpr.ms + + Describes a planned extension to the IRAF Command Language to permit +image or image section operands in general CL expressions +(CL expressions, assignment statements, procedure arguments, etc. +involving whole images or image sections). This topic is related +to the "image calculator" described in the "Packages" document, and +is fundamental to the general image processing capabilities of IRAF. + + +-rw-r--r-- 1 iraf 12285 Feb 25 11:59 imio.ms + + An introduction to the IRAF image i/o package, used to access images +in applications packages. Summarizes the features of the current +interface and planned future enhancements. + + +.nf +-rw-r--r-- 1 iraf 926 Feb 25 12:01 pac_title.ms +-rw-r--r-- 1 iraf 2676 Feb 25 12:01 pac_toc.doc +-rw-r--r-- 1 iraf 78891 Feb 25 12:01 packages.doc +.fi + + This is the top-level design document for the IRAF system, showing +the breakdown of all the top level, user callable software into +"packages", and presenting the requirements for each package. +Emphasizes the scientific requirements for the IRAF system. + + +.nf +-rw-r--r-- 1 iraf 64895 Feb 25 12:04 spp.doc +-rw-r--r-- 1 iraf 637 Feb 25 12:02 spp_title.ms +-rw-r--r-- 1 iraf 3408 Feb 25 12:04 spp_toc.doc +.fi + + The "Reference Manual for the IRAF Subset Preprocessor Language". +The SPP language is a preprocessor language producing essentially +ANSI-66 Fortran as output, which was developed as part of the IRAF +project. The language is reminiscent of Ratfor, but unlike most +preprocessor languages, SPP is a fully defined language. SPP will +eventually be replaced by a full scientific language with enhanced +high level language support, implemented with a true compiler (as +opposed to preprocessor). + + +.nf +-rw-r--r-- 1 iraf 93910 Feb 25 12:05 std.ms +-rw-r--r-- 1 iraf 4099 Feb 25 12:05 std_toc.ms +-rw-r--r-- 1 iraf 21749 Feb 25 12:05 std_gl.ms +.fi + + The "IRAF Standards and Conventions" document. Standards and +standard programming practices for all IRAF system and applications +software and documentation. + + +-rw-r--r-- 1 iraf 15245 Feb 25 12:02 pdr.ms + + This document outlines the steps to be taken in designing and +implementing an IRAF package, i.e., requirements, specifications, +preliminary design review, detailed design, implementation, testing, +and so on. + + + +.ce +\fBHistorical Documents\fR + + +-rw-r--r-- 1 iraf 47655 Feb 18 1983 iraf_ui.ms + + The original IRAF paper, presenting the global design of the system. +Concentrates primarily on the user interface (command language). + + +-rw-r--r-- 1 iraf 34754 Feb 18 1983 iraf_cap.ms + + An early document presenting a simple scientific applications program, +showing how the program would appear and be used at the CL level, +as well as roughly what the source would look like internally. +Pretty dated, but the basic ideas have not changed significantly. + + +-rw-r--r-- 1 iraf 142264 Feb 18 1983 iraf_pp.ms + + The original design document/justification for the IRAF preprocessor +language. Many of the ideas and arguments presented are still valid, +though the language pointed to by this document will differ +significantly in detail when it is finally implemented. Despite its +age, this paper indicates the direction in which the SPP language +will most likely evolve. + + + +.ce +\fBScientific Packages\fR + + +-rw-r--r-- 1 iraf 43049 Feb 25 12:20 Apphot.doc + + Requirements, technical specifications, and algorithms for the Apphot +digital aperture photometry package. Apphot will be capable of +performing background fitting and fractional pixel aperture integration, +interactively or non-interactively, in uncrowded or moderately crowded +fields. Used primarily for digital stellar photometry. + + +.nf +-rw-r--r-- 1 iraf 50203 Feb 25 12:28 MSalgo.ms +-rw-r--r-- 1 iraf 23406 Feb 25 12:30 MSalgo_c.doc +-rw-r--r-- 1 iraf 26531 Feb 25 12:33 MSspecs.doc +-rw-r--r-- 1 iraf 12697 Feb 25 12:30 MSspecs_c.doc +.fi + + Requirements, technical specifications, and algorithms for the +Multispec multispectral extraction package. This package takes +two dimensional multiaperture spectra as input and produces one +dimensional spectra as output, suitable for analysis in Onedspec +or for export on cardimage tapes. This package addresses the +difficult problem of deconvolving blended spectra, and can also +be used to extract the orders on an Echelle spectrogram. This +package is nearing completion and additional (real) documentation +will be available soon. + + +-rw-r--r-- 1 iraf 98564 Feb 25 15:53 Onedspec.doc + + This is a preview of the technical specifications for the one +dimensional spectral analysis package; the preliminary design +of the package is still in progress and the specs document is +incomplete. + + + +.nf +-rw-r--r-- 1 iraf 21328 Feb 25 15:47 FIeqn.ms +-rw-r--r-- 1 iraf 116531 Feb 25 15:47 FIspec.doc +.fi + + Reduction equations and technical specifications for the Filter +Photometry package, used to correct photometric data for extinction, +transform to a standard system, etc. This package will not be built +in the form specified in the FIspec document (the specs did not pass +the preliminary design review), but nonetheless there is valuable +information in these documents, and they will be used as a starting +point when the package is redesigned. + + +.ce +\fBDesign Documentation\fR + + Reader beware: These docs were written primarily as part of the detailed +design process, and only secondarily as technical documentation for the +interfaces. The FIO and IMIO design documentation is particularly obscure, +consisting mostly of semicode; the docs for the other packages are reasonably +readable, though highly technical. + + +-rw-r--r-- 1 iraf 196291 Feb 25 13:10 clspecs.doc + + The original technical specifications of the IRAF command language. +This document is somewhat dated now (it was written in 82), but there +is still a lot of information about the inner workings of the CL +given here that is not written down anywhere else. + + +-rw-r--r-- 1 iraf 61609 Feb 25 12:12 Fio.doc + + Design strategies, structure, semicode etc. for the file i/o +interface. Provides a valuable but highly technical overview of +the capabilities of the device independent, asynchronous, multiple +buffering, etc. IRAF file i/o interface. + + +-rw-r--r-- 1 iraf 41323 Feb 25 12:13 Imio.doc + + Preliminary specifications and detailed design of the image i/o +interface. See also "imio.ms" under "programmer documentation" above; +this latter document is more up to date and less technical. + + +.nf +-rw-r--r-- 1 iraf 14577 Feb 25 12:16 Mtio.doc +-rw-r--r-- 1 iraf 20274 Feb 25 12:16 Zmtio.doc +.fi + + Technical specifications, design strategies, detailed design, etc. +of the magtape i/o interface. The Zmtio document describes the +design of the machine interface, and how the machine dependence of +the interface is minimized. + + +-rw-r--r-- 1 iraf 17366 Feb 25 12:18 TTY.doc + + Terminal control interface. The TTY interface is used to send +control functions to the terminal, inquire about the capabilities +of the terminal, and so on. Uses the UNIX termcap database. + + +-rw-r--r-- 1 iraf 11450 Feb 25 12:18 Vops.doc + + Documentation for the generic preprocessor and the vector operators package. + + +-rw-r--r-- 1 iraf 20326 Feb 25 12:11 dbio.doc + + Technical specifications for the database interface, used for image +headers, output datafiles, general database applications, and so on. +.endhelp diff --git a/doc/doc/bugs.v28 b/doc/doc/bugs.v28 new file mode 100644 index 00000000..b987edb1 --- /dev/null +++ b/doc/doc/bugs.v28 @@ -0,0 +1,889 @@ +# BUGS.V28 -- Known bugs in the frozen IRAF Version 2.8. (start 1 July 1989) +# +# Record Format: +# +# NUMBER: record number, decimal, sequential. +# MODULE: package.task or library.procedure or 'unknown' or ... +# SYSTEM: versions of iraf in which bug was present +# DATE: date bug logged, unix format date string +# FROM: user login name +# BUG: description of the bug +# STATUS: 'fixed in V2.X', 'unresolved', etc. +# +# New records are added to the tail of the bugfile. Left justify field labels, +# indent text to the first tab stop, one blank line between bug entries. +# ---------------------------------------------------------------------------- + +NUMBER: 76 +MODULE: dispcor/ecdispcor/msdispcor +SYSTEM: V2.8 +DATE: Mon Jul 10 13:26:08 MST 1989 +FROM: valdes + +BUG: The task DISPCOR does not produce the result one expects at the + endpoints of the input data. + +STATUS: The IRAF convention is that the pixel value refers to the center + of the pixel. When considered as an aperture the pixel extends + between -0.5 and +0.5 of the pixel center. The way the task is + written in V2.8, an interpolation function is fit to the values + at the pixel centers and the function is not defined beyond the + center of the first and last pixels. When using the flux + conservation option (integration of the interpolation function + across the extent of the output pixel) the part of the output + pixel corresponding to the half pixel beyond the center of the + first and last pixel is not used. For the simple case of an + output dispersion such that the size of an input and output + pixel are nearly the same and the endpoints are the same this + gives about a factor of 0.5 for the endpoint pixels. When not + using flux conservation the interpolation function is evaluated + directly. However, it is often the case that the center of the + last output pixel is computed to be just slightly beyond the + center of the last input pixel (due to rounding) and so the + last output pixel is often zero. + + The task has been revised to extrapolate the interpolation function + by a half a pixel on either end of the input data. The workarounds + are to avoid the endpoints when specifying the wavelength scale + during dispcor or by eliminating the endpoints after dispersion + correction using onedspec.sextract. + +NUMBER: 77 +MODULE: dispcor/ecdispcor/msdispcor +SYSTEM: V2.8 (Sun4) +DATE: Mon Jul 10 13:46:09 MST 1989 +FROM: valdes + +BUG: Using a dispersion table with INDEF values for the number of pixels + causes a floating operand error. + +STATUS: An attempt is made to convert the magic value for INDEF internally + in such a way that the floating operand exception is encountered. + Note that this is only a problem when the value is read from the + dispersion table file. INDEF is fine as a task parameter. + There is no workaround for the INDEF feature though one can put + the number of pixels in explicitly in the dispersion table. + +NUMBER: 78 +MODULE: apextract +SYSTEM: V2.7-V2.8 +DATE: Mon Jul 31 15:54:05 MST 1989 +FROM: valdes + +BUG: The background fitting region is defined over the maximum extent + of the user defined background sample regions. If this region + does not overlap the aperture (for example if the background + is selected to be only on one side of the aperture) then the + background graph in APEDIT does not show the background fit + under the aperture. + +STATUS: The background fitting region has been extended to always overlap + the aperture even if the sample regions are only on one side of + the aperture. There is no work around to get the fit displayed + in APEDIT other than to add sample regions on both sides of the + aperture. + +NUMBER: 79 +MODULE: proto.imedit +SYSTEM: V2.8 +DATE: Thu Aug 3 11:45:57 MST 1989 +FROM: valdes + +BUG: Using :eparam brings up eparam on the task EPIX instead of IMEDIT. + +STATUS: The development name for this task was EPIX and so the command + issued in response to :eparam is "eparam epix" instead of + "eparam imedit". There is no work around but most parameters + can be changed directly with colon commands. + +NUMBER: 80 +MODULE: astutil.rvcorrect +SYSTEM: V2.8 +DATE: Tue Aug 8 16:59:32 MST 1989 +FROM: fitz + +BUG: The RVCORRECT task would die with a floating operand error when + run with an fpa on a Sun-3/OS4, and would produce incorrect results + in the same situations under IRAF V2.7. + +STATUS: This was traced to an optimizer bug and has been fixed in V2.9 by + placing the file astutil$asttools/astcoord.x on the special files list + so it is compiled without optimization. By adding dummy statements + to the code it is also possible to get it working, but this is not + a desired solution. The workaround is to recompile the astcoord.x + file without optimization and relink the astutil package. + +NUMBER: 81 +MODULE: apextract.apsum, apextract.apstrip +SYSTEM: V2.7-V2.8 +DATE: Wed Aug 9 09:53:39 MST 1989 +FROM: valdes + +BUG: The use of a profile image when the number of lines averaged is + greater than one and less than the full image for variance + weighting, cleaning, or extracting the fit as a strip does not + work correctly. + +STATUS: There is no workaround other than to avoid this choice of + parameters. A profile image can be used if the number of lines + averaged is one or the full image. The first case is good if + the profile image has high S/N or has been smoothed. The + latter case is appropriate if the profile does not change with + position along the dispersion. The source code fix is one line + so, if desired and the system has not been stripped of object + libraries, the bug can be fixed and the task recompiled and + linked. + +NUMBER: 82 +MODULE: proto.imedit +SYSTEM: V2.8 +DATE: Thu Aug 17 09:51:14 MST 1989 +FROM: valdes + +BUG: If there are no background points (width = 0) then IMEDIT aborts. + +STATUS: Attempting to fit a background with no background region is a + logical error and should be avoided. The task now prints an + error message and continues. An attempt is now made to trap + any errors in the cursor loop so as to avoid exiting the task + without the chance to save any changes. Note that if an abort + occurs some changes may still exist in the image "epixbuf". + The last changes may be lost due to image I/O buffering (I'm + not sure what happens after an error abort). + +NUMBER: 83 +MODULE: calibrate (onedspec and related imred packages) +SYSTEM: V2.8 +DATE: Thu Aug 24 08:52:44 MST 1989 +FROM: valdes + +BUG: When data to be flux calibrated extends outside the range of the + sensitivity function produced by SENSFUNC and the standard + stars, a warning message is printed and that data outside the + range is improperly calibrated. The usual symptom is that the + calibrated data is in flux units (numbers of order 10e-14) + while the improperly calibrated data is near the original data + units. A plot of this data seems to be all zero on first + inspection because of autoscaling. + +STATUS: The data WITHIN the calibration range is properly calibrated. + One solution is to trim the bad data with SEXTRACT either + before or after calibration. Another solution is to use + TWODSPEC.LONGSLIT.FLUXCALIB which is applicable to 1D spectra. + The source fix is simple if one desires it. + +NUMBER: 84 +MODULE: ccdred.cosmicrays (xtools$gtools/gtascale.x) +SYSTEM: V2.8 (Sun3/OS4/f68881 only) +DATE: Thu Sep 21 14:02:00 MST 1989 +FROM: valdes + +BUG: The task ccdred.cosmicrays aborts with the exception "branch or set on + unordered cond" if a plot is made either interactively or to the + plotfile on Sun3/OS4 using F68881 floating point processor. + +STATUS: The cause is an optimizer bug for the above architecture + in xtools$gtools/gtascale.x. The only workaround if one can't use + another architecture is to not make any plots interactively and set + ccdred.plotfile="". One fix is to recompile the procedure without + optimization and relink ccdred. The fix I used was to make a + minor change to the source which I could see from the optimizer + error would make the problem go away. + +NUMBER: 85 +MODULE: ccdred.cosmicrays +SYSTEM: V2.8 +DATE: Thu Sep 21 14:24:29 MST 1989 +FROM: valdes + +BUG: 1. If no bad pixel output file is specified then the task does not + properly initialize and some random string may be used for this file. + Either a random file will be created or a warning will be issued. + 2. If an incorrect input image is given a warning about transfering + out of an IFERR block is given. + +STATUS: 1. Usually everything will be fine. If a odd file appears just + delete it. If the random file is not writeable a warning is + given which can be ignored. To be absolutely safe specify some + junk bad pixel file which you can delete later. + 2. Don't worry about the IFERR block warning. + +NUMBER: 86 +MODULE: extern.pkg - layered software +SYSTEM: V2.8 +DATE: Tue Sep 26 16:46:35 MST 1989 +FROM: tody + +BUG: Given enough layered package definitions in hlib$extern.pkg, + the string value of the helpdb environment variable would exceed + SZ_LINE chars (160). This would result in failure of the CL to + pass the "set helpdb = ..." statement on to the x_system.e process + while logging into the CL, causing CL startup to fail with a bogus + message such as "Cannot close file (STDERR)". + +STATUS: The bug has been fixed in V2.9. The only workaround for V2.8 is to + minimize the length of the helpdb string, e.g., by including only + needed packages, or consolidating packages so that they appear as + a single package in extern.pkg. + +NUMBER: 87 +MODULE: onedspec +SYSTEM: V2.8 Sun3/80 +DATE: Thu Sep 28 13:39:01 MST 1989 +FROM: valdes + +BUG: Many tasks will abort with a "floating overflow" error when + operating on onedspec format spectra which do not have the + header keyword W0. + +STATUS: This problem only occurs on Sun3/80 and only with onedspec + format (i.e. not multispec or echelle format) which do + not have a wavelength scale (specifically the keyword + W0 is missing). The workaround before the next release + is to add the the parameter W0 with a value of 1 using + HEDIT. A value of 1 is the default anyway and that + means the coordinate of the first pixel is 1; i.e. pixel + coordinates. + +NUMBER: 88 +MODULE: envgetd, impkden +SYSTEM: V2.8 +DATE: Thu Oct 19 17:29:02 MST 1989 +FROM: tody + +BUG: This bug normally shows itself as a failure of the "impkden" + feature, added in V2.8, which allows an environment variable + "impkden" to be defined to specify the image packing density. + Due to a bug in the system procedure envgetd (the variable dval + is declared as int but should be double), the value of impkden + may not be read properly. Normally this is harmless, but in some + cases a segmentation violation may occur if impkden is defined. + +STATUS: The only workaround is to not use impkden, i.e., allow the + system to use the system default packing density. Even if + impkden is defined and the program appears to execute normally, + the value of impkden is probably being ignored. + +NUMBER: 89 +MODULE: imfort - setting image directories +SYSTEM: V2.8, Sun386i/IRAF only +DATE: Thu Oct 19 18:39:12 MST 1989 +FROM: tody + +BUG: Due to an error in the way the imfort library was built for + Sun386i/IRAF, the directory in which pixel files will be placed + cannot be specified, and pixel files will always be placed in + the same directory as the header file (the default). Specifying + the pixel directory, e.g., with IMSDIR, is harmless, but the + request will be ignored. + +STATUS: This bug affects only V2.8 Sun386i/IRAF. The workaround is to + allow imfort to create pixel files in the header file directory, + and then use the IMRENAME task in V2.8 IRAF to move the pixel + file to a new directory. The bug can be fixed by deleting the + imfort library (iraf$bin.i386/libimfort.a) and rebuilding it; + the imfort sources are correct, it is only the library which is + compromised. + +NUMBER: 90 +MODULE: IMFORT +SYSTEM: V2.8 Convex/IRAF +DATE: Tue Oct 24 22:28:18 MST 1989 +FROM: tody + +BUG: IMFORT programs compiled with V2.8 Convex/IRAF (the beta release + system), under version 7.1 of the Convex operating system and + version 5.1.1.0 of the Fortran compiler, will fail immediately on + process startup with a segmentation violation. V2.8 Convex/IRAF + was prepared and tested using version 7.0 of the OS, and version + 5.0 of the Fortran compiler. Something between these two versions + of the host operating system changed the layout of process memory + sufficiently to cause the scheme used to recover the IMFORT program + command line arguments to fail. + +STATUS: The only real workaround is to delay the upgrade to the new Convex + operating system and compiler. Barring that, it is necessary to + contact IRAF site support to obtain and install a patch to fix the + bug. If the file os$zgcmdl.c is replaced with the version from + V2.9 IRAF, compiled, and installed in the library libos.a, then + the bug will go away. + +NUMBER: 91 +MODULE: irred.center +SYSTEM: V2.8 +DATE: Mon Oct 30 08:50:39 MST 1989 +FROM: davis + +BUG: The center.par file in imred$irred was not updated when the two + new parameters "verbose" and "verify" were added to the center task. + This was causing "parameter not found" errors for irred users. + +STATUS: This bug has been fixed in 2.9. There is no workaround except to + use the center task directly from apphot or to copy the + digiphot$apphot/center.par file to imred$irred/center.par. + The datapars.par and centerpars.par files were also updated + for consistency although these files should not have caused any + errors. + +NUMBER: 92 +MODULE: proto.imedit +SYSTEM: V2.8 +DATE: Mon Oct 30 16:48:25 MST 1989 +FROM: valdes + +BUG: When using a previous logfile as cursor input a floating operand + error occurs. + +STATUS: As a shorthand and for readability, the logfile leaves out + cursor coordinates for colon commands. When reading the + logfile as cursor input the cursor reading code supplies the + special INDEF value for the missing coordinates. IMEDIT fails + to check for this value and attempts an operation (adding 0.5) + to these values which causes the exception. (Note when this + task was developed and tested these exceptions were not set so + this error was not seen). The workaround is to edit the + logfile and supply dummy coordinates and coordinate codes to + those commands missing coordinates. For example: + + :aperture circular --> 1 1 1 :aperture circular + +NUMBER: 93 +MODULE: identify, reidentify (onedspec, twodspec, etc.) on CONVEX +SYSTEM: V2.8 +DATE: Tue Oct 31 13:24:32 MST 1989 +FROM: valdes + +BUG: Exiting the dispersion function fitting without any points rejected + by the iterative rejection algorithm causes a bus error on the CONVEX + (both IEEE and NATIVE architectures). + +STATUS: This bug was due to an incorrect assumption about the order of + evalution in complex if statements and that the test is terminated + at the first point the result is known; i.e. at the first false in + a compound "and". The CONVEX is the first FORTRAN compiler + encountered in which this is a problem. The source code fix is + available. The only workaround is to force a point to be + rejected by setting the rejection thresholds low enough or + marking one spurious line to be rejected. + +NUMBER: 94 +MODULE: onedspec.sensfunc +SYSTEM: V2.8 +DATE: Wed Nov 8 09:21:15 MST 1989 +FROM: valdes + +BUG: The combination of specifying an aperture list which does not + include aperture 1 (note a null list always includes aperture 1) + and the ignoreaps flag leads to the error "No degrees of freedom". + +STATUS: What was happening is that when a header record is encountered it + is checked to see if it is in the aperture list. If it is and + the ignore apertures flag is set then the aperture number is + interally set to 1; i.e. when ignoring the aperture numbers all + selected spectra are treated as aperture 1. However, when reading + the following data lines the check was again made to see if the + current aperture number is in the aperture list. The current + aperture number is now 1 but if this aperture is not in the + list then no data will be read. The absence of data leads to + the "No degrees of freedom" message and the subsequent task abort. + This bug has been fixed. The workaround is to avoid the situation + where you want to ignore the aperture numbers (i.e. combine data + from different apertures) but exclude aperture 1. If this rare + situation is required editing the standard star data file to change + the aperture numbers is a workaround. + +NUMBER: 95 +MODULE: apphot.qphot,apphot.phot,apphot.wphot,apphot.polyphot +SYSTEM: V2.8 and earlier +DATE: Thu Nov 16 14:06:54 MST 1989 +FROM: davis + +BUG: A bug has been found in the apphot interactive photometry tasks + wherein magnitudes were occasionally not being updated after + a new sky value was computed. This would occur only if the + sky fitting parameters were changed but the centering and photometry + parameters did not and the cursor was not moved since the previous + measurement. + + The most common situtation where this occurs is when the user + is trying to explore the sky fitting parameter space by + sitting on a single star and altering the skyfitting parameters, + while leaving the cursor position and photometry apertures + unchanged. The problem only exists for this setup star. + All subsequent stars will be measured correctly. Batch + mode operation of all the above tasks was not affected by this bug + +STATUS: This bug has been fixed in IRAF version 2.9. The workaround + is to alter the cursor position slightly between measurements. + +NUMBER: 96 +MODULE: images.imarith +SYSTEM: V2.8 and earlier +DATE: Fri Nov 17 10:45:45 MST 1989 +FROM: davis + +BUG: The images package task imarith was not correctly handling the + image data type ushort. If the first image in a pair was of + pixel type ushort imarith produced a junk image with no + pixel file and did not produce an image. + +STATUS: The bug has been fixed in version 2.9. There is no workaround + but the datatype of ushort images can be changed with the + images task chpixtype. + +NUMBER: 97 +MODULE: dataio.wfits +SYSTEM: V2.8 +DATE: Mon Nov 20 14:16:22 MST 1989 +FROM: davis + +BUG: Wfits was not correctly mapping the pixel datatype ushort to + fits integers. The default bitpix was incorrectly set to 16 + with bscale and bzero of 1.0 and 0.0 respectively. + +STATUS: Wfits has been modified to default to a bitpix of 32 if the + input pixel type is ushort. Although this is not the most + efficient solution in terms of tape space it is the safest in terms + of avoiding type conversions on a subsequent execution of rfits. + The policy of wfits is to try and avoid scaling integer data + in any way. Similarly rfits will create a real image by default + if it sees bscale and bzero values of other than 1.0 and 0.0 + respectively. + + The workaround is to run fits with autoscale=no, bscale=1.0 and + bzero=32768 and bitpix=16. Users concerned with tape space + may also use this workaround to force wfits to bitpix=16 + while still maintaining dynamic range. + +NUMBER: 98 +MODULE: images.geotran,images.register +SYSTEM: V2.8 +DATE: Mon Nov 27 09:04:11 MST 1989 +FROM: davis + +BUG: Geotran and register can occasionally produce out of bounds + pixel errors when the coordinate transform was non-linear + and had a certain functional form. Geotran was incorrectly + computing the distortion of the image boundaries in this case. + +STATUS: There is no work around. Contact the IRAF group for a fix. + +NUMBER: 99 +MODULE: IMFORT/imdir +SYSTEM: V2.8 +DATE: Thu Nov 30 21:31:00 MST 1989 +FROM: tody + +BUG: When the IMFORT interface was originally written, the pixel file + was always created in the same directory as the image header. + With the recent addition of the "image directory" (imdir) feature + to IMFORT, however, it is possible for images in different directories + to share the same directory for pixel file storage. The problem is + that no clobber checking is being performed on the pixel files, + hence if an image of the same name is created in two different + directories, and a common imdir is being used, THE PIXEL FILE OF + THE SECOND IMAGE WILL OVERWRITE THAT OF THE FIRST, resulting in + loss of data, and worse, substitution of an invalid pixel file + in the first image. Note that this bug ONLY occurs if [1] a common + imdir is used with V2.8 IMFORT (not the default), and [2] two or + more images of the same name are created in different directories. + +STATUS: The workaround for V2.8 IRAF is to avoid use of a common global + image storage directory with IMFORT. + +NUMBER: 100 +MODULE: generic.normalize, generic.normflat +SYSTEM: V2.8 +DATE: Fri Dec 1 09:13:11 MST 1989 +FROM: valdes + +BUG: If using the automatic normalization determination, the tasks + may normalize by something other than the mean. This occurs + when the user has modified the parameters for IMSTATISTICS to + other than the default as explained below. + +STATUS: These script tasks were originally written for V2.2 (a long + time ago). They use the task IMSTATISTICS to compute the + mean of an image if the normalization is not explicitly + specified. It uses the third field from the output of + IMSTATISTICS. IMSTATISTICS was modified in V2.8 to allow + the user to select the fields printed with the default being + the same as earlier versions. Thus, if the user changes the + default quantities printed so that the mean is not the third + field the tasks will use the wrong value. The workaround + is to unlearn the parameters, or at least make the third + field be the mean, in IMSTATISTICS. The tasks have been + modified in V2.9 to override the user's defaults for + IMSTATISTICS. + +NUMBER: 101 +MODULE: proto.imexamine +SYSTEM: V2.8 +DATE: Fri Dec 1 13:45:21 MST 1989 +FROM: valdes + +BUG: When no input list is specified the task queries the image display + for the image to be examined. The display frame is determined + from the cursor readback. When using a cursor input file of + x and y with no frame number the default value of frame 0 was + used causing a segmentation error. Thus, a segmentation error + occurs with no input list and when not reading the standard + image display cursor (which always returns a valid frame) and + when the frame number is not part of the cursor input. + +STATUS: The workaround is to either specify an image to be examined + on the command line or to specify the frame number in the + cursor input file for at least the first entry. NOTE THAT + USING ":go" OR "menu mode" WILL IGNORE THE INPUT LIST EVEN IF YOU + SPECIFY ONE. The task has been modified so that the initial + frame used if the cursor input does not specify a frame is 1. + +NUMBER: 102 +MODULE: images.imslice +SYSTEM: V2.8 +DATE: Mon Dec 4 14:03:15 MST 1989 +FROM: davis + +BUG: Imslice was not computing the number of lines in the output image + correctly in the case where the slice dimension was 1. + +STATUS: The bug has been fixed in IRAF V2.9. There is no work-around. + +NUMBER: 103 +MODULE: imtool,install +SYSTEM: V2.8 +DATE: Mon Dec 4 21:06:45 MST 1989 +FROM: tody + +BUG: There is a bug in the V2.8 INSTALL script which can lead to the + loss of the "imtoolrc" file in some circumstances. If this occurs + the symptom will be the inability to set imtool to any frame buffer + configuration other than #1, which is 2 512x512 frames. The bug + occurs when install is run when [1] the imtoolrc file has already + been installed, and [2] the installed version is different than the + source version in iraf (as when upgrading to IRAF V2.8 from an + earlier version, since the imtoolrc file was modified for V2.8). + The first time the install script is run things are still ok, but + the second time the imtoolrc file will disappear (actually it is + merely renamed to .OLD, but it will become inaccessible to IMTOOL). + +STATUS: If this occurs the workaround is easy; copy the backup version of + the file, e.g, /usr/local/lib/imtoolrc.OLD, to /usr/local/lib/imtoolrc + and $iraf/sun/imtoolrc. Since both versions of the file will then + be identical the bug will not recur no matter how many times the + install script is rerun. + +NUMBER: 104 +MODULE: STF images +SYSTEM: V2.8, SPARC (Sun-4) systems only +DATE: Tue Dec 5 10:47:39 MST 1989 +FROM: tody + +BUG: On a Sun-4 running V2.8 IRAF, any attempt to create an STF format + image will result in a [floating overflow] error. Note that only + Sun-4 (SPARC) systems are affected. The bug is due to an unitialized + floating point function value. The function value is not used by + IRAF if not initialized (in this case due to the function taking an + error exit), but will cause an IEEE exception if the unitialized + or garbage value happens to not be a legal floating point number. + +STATUS: The workarounds are obvious: use the OIF image format instead of + STF where possible, or if the STF format must be used, do so on a + non-SPARC system. A user installable bugfix is available from + IRAF site support if necessary. + +NUMBER: 105 +MODULE: CL - background job termination +SYSTEM: V2.8 +DATE: Sat Dec 9 14:53:36 MST 1989 +FROM: tody + +BUG: On certain UNIX/IRAF systems, background jobs submitted from IRAF + may die after the user logs out, if i/o has not been redirected. + The problem occurs when such a job attempts to write to the terminal + after the user has logged out. The host system returns an error + on the write if the output terminal is no longer connected, and the + resultant file write error causes the IRAF job to terminate. This + bug is present on all Sun systems and on the DECstation (Ultrix), + but not with standard BSD/VAX UNIX. Note that on a workstation, + exiting a terminal emulator is equivalent to logging out (the + /dev/tty entry assigned to the terminal emulator is closed), and + any background jobs submitted from the terminal emulator are subject + to termination if this error occurs. + +STATUS: There is a simple workaround, i.e., if you will be logging out before + the background job terminates, redirect the output with ">& " + when the background job is submitted. IRAF versions 2.9 and higher + will ignore this error, discarding the unredirected output. + +NUMBER: 106 +MODULE: CL - i/o redirection and foreign tasks +SYSTEM: V2.8 +DATE: Mon Dec 11 17:35:28 MST 1989 +FROM: tody + +BUG: Append mode i/o redirection is not working properly for foreign + tasks; the output file is clobbered (overwritten), rather than + appended to. In other words, "foo >> output" will overwrite any + existing file "output" if FOO is a foreign task. ONLY foreign + tasks are affected by this bug. + +STATUS: Until this bug is fixed, the only workaround is to redirect the + output to a new file and concatenate the output files later, or + do something like pipe the output to "TYPE STDIN >> output", which + will work because TYPE is an ordinary IRAF task, not a foreign task. + +NUMBER: 107 +MODULE: CCDRED - SETINSTRUMENT +SYSTEM: V2.8 +DATE: Mon Jan 8 16:00:51 MST 1990 +FROM: seaman + +BUG: The file `intruments.men' in the directory `ccddb$ctio/new' + (i.e., noao$ccdred/ccddb/ctio/new/intruments.men) should be + named `instruments.men'. The bug prevents `setinstrument ?' + from working. + +STATUS: Fixed in v2.9. The fix is merely to rename the file. Note + that the site ID in SETINSTRUMENT should be `ctio/new' for + the task to locate any of the files. + +NUMBER: 108 +MODULE: noao.imred.echelle.ecdispcor +SYSTEM: V2.8 +DATE: Mon Jan 15 13:47:23 MST 1990 +FROM: valdes + +BUG: The "sum" option of ECDISPCOR is really an average (the same as the + "average" option. + +STATUS: The workaround is to dispersion correct to onedspec format and + then use onedspec.combine. + +NUMBER: 109 +MODULE: proto.imedit +SYSTEM: V2.8 +DATE: Wed Jan 17 13:13:30 MST 1990 +FROM: valdes + +BUG: Changing the background fitting order with colon commands results + in zero being put into the users parameter file. Regions + outside the specified aperture are occasionally included as + part of the aperture for replacement. + +STATUS: The workaround for the colon command problem is to reset the + parameter values before the next execution of imedit. Note + that if you forget you are queried because a value of zero is + not allowed for these parameters resulting in a request for a + legal value. The second problem is due to a error in + clearing the region mask from the previous aperture. For + background replacement this problem will not be evident and is + most visible when replacing by a constant. The problem goes + away if the buffer parameter is zero but this may not be + desired. + +NUMBER: 110 +MODULE: images$imstatistics +SYSTEM: V2.8 +DATE: Sat Jan 20 15:08:26 MST 1990 +FROM: davis + +BUG: The median was being incorrectly computed in the case where more + than half the image pixels were in the first bin of the integrated + histogram. + + On occasion the output fields would overflow their alloted format + statements results in unreadable output in which the number ran + together. + +STATUS: Both bugs have been fixed in version 2.9. The first problem + can be worked around by changing the binning parameter. + +NUMBER: 111 +MODULE: images.geomap +SYSTEM: V2.8 +DATE: Fri Jan 26 09:08:09 MST 1990 +FROM: davis + +BUG: The path name to the help file was being erroneously redefined + in the interactive portion of the geomap code. As a result + users selecting the double precision computation option were + unable to access the help page. + +STATUS: This bug has been fixed in version 2.9. + +NUMBER: 112 +MODULE: apphot package +SYSTEM: V2.8 +DATE: Wed Feb 7 09:07:14 MST 1990 +FROM: davis + +BUG: The string defining the sky fitting algorithm was not getting + updated correctly when the chosen sky fitting algorithm was + "median" or "gauss", resulting in garbage being written into + the output file header . The correct algorithm however was being + used to compute the sky. + + A floating point error would occur if the user selected the + sky fitting algorithm "constant", left the standard deviation + of the sky at INDEFR, and enabled radial profile plotting in + the phot task. The problem occured when the plotting program + tried to plot the 3 * sigma sky level by adding the sky value + to the standard deviation. + +STATUS: Both bugs have been fixed in version 2.9. The first can be merely + annoying causing garbage to be written to the output filer or + serious causing a memory corruption error. Contact NOAO for a fix. + The workaround for the second is to set the sigma parameter to some + reasonable value. + +NUMBER: 113 +MODULE: proto.imedit +SYSTEM: V2.8 SPARCstation +DATE: Fri Mar 9 15:05:09 MST 1990 +FROM: valdes + +BUG: On SPARCstation 1 cpus the 'a', and 'b' keys sometimes do nothing; + i.e. fail to replace the indicated area by background. + +STATUS: This was due to declaring an integer argument as a real. A later test + comparing the value to zero (an error condition) yields true + even with the integer value is not zero causing a return with + no action taken. This was missed earlier because it is a + sporadic problem and does not appear on 68020 cpus or on a + Sun4. Because it is sporadic I cannot be completely sure of my + machine dependence characterization but all confirmed reports + of this problem are on SPARCstations and I have a confirmed + report from someone with a SPARCstation who has never seen the + problem despite heavy usage. There is no workaround if you see + it. + +NUMBER: 114 +MODULE: dataio.rfits +SYSTEM: V2.8 +DATE: Mon Mar 12 13:27:32 MST 1990 +FROM: davis + +BUG: Rfits was not updating the datamin and datamax parameters correctly + for stf images. The stf kernel intializes the datamin and datamax + parameters explicitly after the first pixel i/o is done by setting + them to zero. This was overwriting the initial values for datamin + and datamax, MAX_REAL and -MAX_REAL respectively set by rfits, + resulting in an incorrect value for datamin of zero for images with + positive data. + + This problem can result in loss of precision or worse when wfits goes + to write out the image again. + +STATUS: The bug has been fixed in IRAF 2.9. This problem is really the result + of a bug in the stf kernel but was easily avoided by making datamin + and datamax local variables instead of pointers to the appropriate + storage location in the header. The header is only updated after + the last image line is written. + + There is no workaround. Users can update the datamin and datamax + values with the images task minmax. + +NUMBER: 115 +MODULE: apphot.daofind +SYSTEM: V2.8 +DATE: Mon Mar 12 13:38:31 MST 1990 +FROM: davis + +BUG: Daofind was failing to compute the convolved image when the output + image format was hhh. This resulted in an output convolved image full + of 0's and no object detections! The hhh format image was failing the + obsolete test [if (IM_PIXFILE(im) == EOS) as the pixel file names + are set at different places in the oif and stf kernel. + +STATUS: This bug has been fixed in IRAF 2.9. The test condition was both + obsolete and dangerous and has been removed. The workaround is to + use .imh format. + +NUMBER: 116 +MODULE: proto.imedit +SYSTEM: V2.8 +DATE: Thu Mar 15 16:58:46 MST 1990 +FROM: valdes + +BUG: Use of a cursor file of x,y pairs and a default key of a, c, d, l, f + or j would infinitely repeat the last cursor position. + +STATUS: The test for end of file for the two keystroke keys listed above was + botched leading to the above behavior. This is probably a rare + usage but acceptable usage. The work around is to end + the cursor file with "1 1 1 q" to cause a quit. Note that a simple + 'q' encounters another bug logged previously dealing with a problem + defining the default coordinates. + +NUMBER: 117 +MODULE: identify, ecidentify +SYSTEM: V2.8 +DATE: Fri Mar 16 10:46:11 MST 1990 +FROM: valdes + +BUG: When INDEF user coordinates are in the feature list, segmentation and + floating overflow errors can occur. In IDENTIFY problems only + arise if points are deleted during fitting. In ECIDENTIFY the + presence of INDEF values will generally cause severe problems. + +STATUS: INDEF values are allowed conceptually and may have a use in these + tasks. However one should not use these values if possible and + it is necessary in ECIDENTIFY in order to avoid the bug above. + INDEF values sometimes creep in accidentally when using a line list. + If a line is marked and there is a line list but the marked position + does not correspond to a line in the list then the default prompt + value is INDEF. If you type carriage return without specifying + a wavelength the line will be entered with the INDEF value. + Without a line list the default prompt is the fitted wavelength. + The bug has been fixed. + +NUMBER: 118 +MODULE: apphot.phot,qphot,wphot,polyphot,center,radprof +SYSTEM: V2.8/386i only +DATE: Wed Mar 21 08:05:06 MST 1990 +FROM: davis + +BUG: Executing any of the apphot tasks which perform a centering + operation results in the message "floating stack fault" + and termination of the task on the 386i. This error occurred only + on the first execution of the task or when the task was submitted + to background. + +STATUS: The problem was traced to an optimizer bug in the 386i fortran + compiler and has been fixed in version 2.9. Contact the IRAF + group for a fix. + + +NUMBER: 119 +MODULE: noao.proto.imexamine +SYSTEM: V2.8 +DATE: Thu Mar 22 12:01:20 MST 1990 +FROM: valdes + +BUG: The 'u' and 'v' vector graphs followed by any other graph can give + memory corruption errors. This appears on VMS (750 and 8600) + but does not appear on Sun systems, though it is just chance that + there is no apparent problem there. + +STATUS: There is no work around short of avoiding the 'u' and 'v' graphs. + The source fix is simple and may be requested if not updating + to V2.9 or V2.10. + +NUMBER: 120 +MODULE: apphot.daofind +SYSTEM: V2.8 +DATE: Fri Mar 30 08:02:12 MST 1990 +FROM: davis + +BUG: In rare circumstances daofind may abort with a "pixel file truncation + error" when trying to read back the convolved images it has just + written. This only occurs on certain sized images and is due to + the interaction of the read, write and boundary extension in image + i/o. For example daofind works fine on a 640 by 1024 image but fails on + one that is 641 by 1025 pixels. + +STATUS: The problem is fixed in 2.9. The solution was to add an imflush + statement to flush the image i/o buffers after the write was + complete and before initiating the read. There is no workaround. + Contact the IRAF group for a fix. diff --git a/doc/doc/crib83.hlp b/doc/doc/crib83.hlp new file mode 100644 index 00000000..d74aef3f --- /dev/null +++ b/doc/doc/crib83.hlp @@ -0,0 +1,1217 @@ +.help crib83 Sep83 "IRAF Program Interface Crib Sheet" +.ih +STANDARD PACKAGES comprising the IRAF Program Interface: + +.nf +file i/o FIO + (character i/o) +formatted i/o FMTIO +cl i/o CLIO +database i/o DBIO +image i/o IMIO +graphics i/o GIO +terminal control TTY +magtape i/o MTIO + +memory management MEMIO +date and time SYS +process control SYS +exception handling SYS +error handling SYS +boolean operators OS + +string utilities FMTIO +vector operators VOPS +image operators IMOPS +.fi + +.sh +FILE I/O (fully implemented) + +.nf + + fd = open (fname, mode, type) # open a file +NI fd = reopen (fd, mode, type) # indep. fd, buffers + close (fd) + + stat = read (fd, buffer, maxch) # binary byte stream i/o + write (fd, buffer, maxch) + flush (fd) + seek (fd, loffset) # move to abs offset + long = note (fd) # note posn for seek + + fseti (fd, param, value) # set FIO options + value = fstat[il] (fd, param) # file status (int, long) + fstats (fd, param, outstr, maxch) # file status (string) + stat = finfo (file, ostruct) # get info on file + + y/n = access (fname, mode, type) # can file be accessed + delete (fname) + rename (old_fname, new_fname) + mktemp (root, fname, maxchars) # make temp file name + + falloc (fname, nchars) # prealloc file space + stat = protect (fname, action) # protect/unprotect + fcopy (from_fname, to_fname) # file copy + fcopyo (from_fd, to_fd) # file copy, open files +.fi + + +.ks +.sh +CHARACTER I/O (fully implemented, except for unget*, unread) + +.nf + stat = getc (fd, char) # get char from file + putc (fd, char) # put char to file + putcc (fd, char) # handles unprintables + + stat = getchar (char) # get char from STDIN + putchar (char) # put char to STDOUT + + stat = getline (fd, linebuf) # get a line of text + putline (fd, linebuf) # output string to fd + +NI ungetc (fd, char) # push back a char +NI ungetline (fd, string) # push back a string +NI unread (fd, buf, nchars) # push back binary data +.fi +.ke + +.ks +.sh +NOTES on file i/o: + + The standard streams STDIN, STDOUT, and STDERR are always open. STDIN +and STDOUT read from and write to the user terminal when working interactively +and i/o has not been redirected. STDERR is for warning or error messages. + + +.nf +Operand types and dimensions: + + int fd # file descriptor + char fname[SZ_FNAME] # file name string + char linebuf[SZ_LINE] # line buffer (for getline) +.fi +.ke + +.ks +.nf +File access modes (no RW access for text files): + + READ_ONLY, WRITE_ONLY, READ_WRITE, APPEND + NEW_FILE # create new file + TEMP_FILE # delete upon task completion +.fi +.ke + +.ks +.nf +File types: + + TEXT_FILE # file of lines of text + BINARY_FILE # buffered binary byte stream +.fi +.ke + + +.ks +.nf +Asynchronous block i/o primitives (binary files only): + +** aread (fd, buffer, maxchars, char_offset) [also areadb ] +** awrite (fd, buffer, nchars, char_offset) [also awriteb] +** nchars = await (fd) [also awaitb ] +.fi +.ke + +Note: "**" identifies routines which are low level, difficult to use in +a machine independent fashion, and which should not be used in applications +code. + +.tp 5 +.sh +VIRTUAL FILE NAMES, DIRECTORY ACCESS (fully implemented) + +.nf + vfn :== [logical_directory_prefix"$"]root_name["."extension] + legal character set [a-zA-Z0-9._+-#], max 20 characters + e.g., "lib$iraf.h" + + + bool = envgetb (env_var) # yes/no --> boolean + int = envgeti (env_var) # convert to integer + nchar = envgets (env_var, os_name, maxch) # get logical name + + zmapfn (vfn, osname, maxch) # vfn --> osfn + fpathname (vfn, osname, maxch) # vfn --> full pathname + fdirname (vfn, osname, maxch) # vfn --> directory name + + nchar = fnldir (vfn, outstr, maxch) # get logical directory + nchar = fnroot (vfn, outstr, maxch) # get root name + nchar = fnextn (vfn, outstr, maxch) # get extension + + +Directory access (use GETLINE to read successive virtual file names) + + fd = diropen (vfn) # open directory +.fi + + +.ks +.sh +FORMATTED I/O + + The SCAN procedures are used to decode lines of input from any of +a number of sources (files, strings, CL parameters). The PRINTF procedures +provide elaborate facilities for encoding lines of output. The "_to_" +primitives provide a very general but low level numeric conversion capability. +.ke + +.ks +.sh +FMTIO INPUT, full language (not yet implemented): + +.nf + nscan = scan ( arg, arg, ...) # scan STDIN + nscan = fscan (fd, arg, arg, ...) # scan file + nscan = sscan (str, arg, arg, ...) # scan string + nscan = clscan (param, arg, arg, ...) # scan cl param +.fi +.ke + + +.ks +.nf +Example: (FSCAN returns nscan or EOF) + + while (fscan (fd, int_variable, real_variable) != EOF) { + if (nscan() == 1) + [ action for deficient scan call ] + ... +.fi +.ke + + +.ks +.nf +FMTIO INPUT, Subset Preprocessor (fully implemented): + + stat = scan () + stat = fscan (fd) + stat = sscan (str) + stat = clscan (param) + + garg[bcsilrdx] (value) # get typed argument + gargstr (outstr, maxch) # get rest of line + gargwrd (outstr, maxch) # get next "word" + gargrad (lval, radix) # non-decimal gargi + gargtok (tok, outstr, maxch) # get next token + scanc (ch) # get single char + reset_scan() # rescan same input +.fi +.ke + + +.ks +.nf +Example: Scan lines from a file + + while (fscan (fd) != EOF) { + call gargi (int_variable) + call gargr (real_variable) + call gargstr (outstr, maxch) + if (nscan() < 3) { + [ action for deficient scan call ] + ... +.fi +.ke + + +.ks +.sh +FMTIO OUTPUT Conversion (spp form fully implemented): + + The full language version of PRINTF (not yet implemented) will permit +a variable number of arguments of any datatype. + +.nf + printf ( format, expr [, expr...]) (STDOUT) + eprintf ( format, expr [, expr...]) (STDERR) + fprintf (fd, format, expr [, expr...]) + sprintf (outstr, maxch, format, expr [, expr...]) + clprintf (param, format, expr [, expr...]) +.fi +.ke + + +A program written in the subset preprocessor language must pass the +arguments explicitly in typed PARG_ calls. + +.ks +.nf + printf (format) # to STDOUT + eprintf (format) # to STDERR + fprintf (fd, format) # to file + sprintf (outstr, maxch, format) # to string + clprintf (param, format) # to cl param + + parg[bcsilrdx], pargstr # pass argument +.fi +.ke + + +.ks +A format specification has the form "%w.dCn", where W is the field width, +D is the number of decimal places or the number of digits of precision, +C is the format code, and N is radix character for format code "r" only. +The W and D fields are optional. The format codes C are as follows: + + +.nf + b boolean (YES or NO) + c single character (c or '\c' or '\0nnn') + d decimal integer + e exponential format (D specifies the precision) + f fixed format (D specifies the number of decimal places) + g general format (D specifies the precision) + h hms format (hh:mm:ss.ss, D = no. decimal places) + m minutes, seconds (or hours, minutes) (mm:ss.ss) + o octal integer + rN convert integer in any radix N + s string (D field specifies max chars to print) + t advance To column given as field W + u unsigned decimal integer + w output the number of spaces given by field W + x hexadecimal integer + z complex format (r,r) (D = precision) + + * deferred: get field from next pargi call + + +Conventions for W (field width) specification: + + W = n right justify in field of N characters, blank fill + -n left justify in field of N characters, blank fill + 0n zero fill at left (only if right justified) + absent, 0 use as much space as needed (D field sets precision) + + +Escape sequences (e.g. "\n" for newline): + + \b backspace + \f formfeed + \n newline (crlf) + \r carriage return + \t tab + \" string delimiter character + \' character constant delimiter character + \\ backslash character + \nnn octal value of character +.fi +.ke + +Any combination of the fields W, D, C, and N may be specified as "*" in +the format string, allowing the field to be passed at run time in a PARG_ call. + +In the absence of a format string (no PRINTF statement), the PARG_ routines +will print their operands using reasonable default formats, adding a space +after each operand. A newline character can be output after the last operand to +terminate the output line. +.ks +.sh +Example (Subset Preprocessor): + +.nf + mean = 4027.123 + sigma = 33.98423 + + call printf ("mean: %0.6g sigma: %6.2f\n") + call pargr (mean) + call pargr (sigma) +.fi +.ke + + +would produce the newline terminated output line + + mean: 4027.12 sigma: 33.98 + +.sh +FMTIO Low Level Formatted I/O Primitives (do not do i/o): + + The following procedures (excluding CTOTOK, which returns an integer +code identifying the type of token) return the number of nonwhite input +characters converted: + +.nf + nchar = ctoi (str, ip, ival) # char to integer + nchar = ctol (str, ip, lval) # char to long + nchar = ctod (str, ip, dval) # char to double + nchar = ctox (str, ip, xval) # char to complex + nchar = cctoc (str, ip, char) # charcon to char + nchar = gctod (str, ip, dval) # convert any number + nchar = gctox (str, ip, xval) # convert any number + nchar = gctol (str, ip, lval, radix) # variable radix + nchar = ctowrd (str, ip, outstr, maxch) # word or string + token = ctotok (str, ip, outstr, maxch) # extract token + +.fi +The following procedures return the number of characters written into the output +string (the DTOC "format" is one of the chars [efghm], i.e., 'f'): +.nf + + nchar = itoc (ival, outstr, maxch) # integer to char + nchar = ltoc (lval, outstr, maxch) # long to char + nchar = ctocc (char, outstr, maxch) # char to charcon + nchar = gltoc (lval, outstr, maxch, radix) + nchar = xtoc (xval, outstr, maxch, decpl, format, width) + nchar = dtoc (dval, outstr, maxch, decpl, format, width) + + +Get/Put a single character from/to a string: + + cval = chfetch (str, ip, cval) # get character + chdeposit (cval, outstr, maxch, op) # put character +.fi + +.ks +.sh +CL I/O (see also "clscan", "clprintf", above) + +Get/put ordinary parameters (the generics are not implemented in the subset +preprocessor; add type suffix as shown below): + +.nf +NI value = clgpar (param) # generic procedure +NI clppar (param, string) # generic procedure + clgstr (param, outstr, maxch) # get string param + clpstr (param, string) # put string param + + generic clgpar --> clget[bcsilrdx] (implemented) + generic clppar --> clput[bcsilrdx] (implemented) + + +Get list structured parameters (return EOF at end of list): + +NI stat = clglpar (param) # generic +NI stat = clglcur (param, x, y, ch) # get cursor param + stat = clglstr (param, outstr, maxch) + + generic clglpar --> clglp[bcsilrdx] (implemented) + + +.fi +Expand file name template (string param in CL). CLPOPNI expands and +sorts a list of input files (contingent on whether or not the standard +input is redirected); CLPOPNS expands and sorts any template; CLPONPU +expands a template without sorting. +.nf + + list = clpopn[isu] (param) # "open" template + clpcls (list) # "close" template + nfiles = clplen (list) # nfiles in list + stat = clgfil (list, outstr, maxch) # get file name(s) + + +To send a general command to the CL (a newline is appended): + +** clcmd (command_string) # send command to CL +.fi +.ke + + +.tp 10 +.sh +DATABASE I/O (not yet implemented) + + Database i/o shall consist of a set of library procedures for accessing +a flat "data dictionary" stored as a single binary random access file. +Any number of independent dictionaries may exist as separate files in the +files system. A dictionary may contain any number of related or unrelated +entries or records, keyed by a character string (the name of the entry). +Each record will have the following attributes: + + +.ks +.nf + Name by which the record is externally known (string). + Aliases (other names pointing to the same physical record). + Datatype: + one of the primitive types + structure + Count of the number of objects of the indicated datatype + in the record. + Offset in the file at which the physical record is stored. +.fi +.ke + + +A structure type record shall consist of a set of fields, each of which shall +have the following attributes: name, datatype (primitive only), count (i.e., +arrays), and relative offset in the structure. A record may consist of an +array of structures, but all structures must have the same format and size. +Note that hierarchically structured records shall not be permitted. + +All access to a database shall be by means of the library procedures. +The details of what is stored in the database, and of how and where +it is stored, will in general not be known to the program which accesses +the database. It shall be possible to add records in any order, +provided a new record does not redefine an old record. + +At a minimum, the following functions shall be provided for operating +upon the database: +.ls 4 +.ls (1) +Create an empty database, open an existing database, close a database. +.le +.ls (2) +Add a new record to the database. +.le +.ls (3) +In the case of an array structured record, add a new element to the end of +the array. +.le +.ls (4) +Read a record, element of an array structured record, or field. +.le +.ls (5) +Write a record, element of an array structured record, or field. +.le +.ls (6) +Delete a record. +.le +.ls (7) +Given a key, return the name of the next entry (alphabetically) in +the dictionary. This is the only way to access a database without +knowing what it contains. +.le +.le + +DBIO will eventually be used to provide a more general and flexible image +header than is currently available. Other uses include program output, +communication amongst the programs within a package, and most common +database applications (i.e., the HELP database). Conversion programs will +be provided for transportation of database files between machines. + +.tp 10 +.sh +IMAGE I/O (implemented, but changes are planned) + + An image structure must be mapped before the image header structure +or the data (pixels) can be accessed. + + +.tp 6 +Language Support (not yet implemented): + + The GETPIX and PUTPIX generic procedures will provide for general +pixel i/o in the full language. These procedures subscript a section +of a mapped image, and return a pointer to the input buffer containing the +pixels, or to the output buffer in which the pixels are to be put. +For example, + +.ks +.nf + bufptr = getpix (a[*,j]) # get line J + bufptr = putpix (b[x1:x2,y1:y2]) # put a subraster +.fi +.ke + + +.tp 6 +Library support (fully implemented): + + An image must be opened with IMMAP before it can be accessed. +The image and buffers must be returned with IMUNMAP when done. The +IMGNL and IMPNL routines are used to perform sequential i/o on images +of any dimension. The GETPIX and PUTPIX routines (or the more specific +procedures named according to the generating function shown below) +are used to get or put specific lines or sections to images. + + +.rj +General routines: + +.nf + im = immap (image_file, mode, len_user_area | old_im) + imunmap (im) + imseti (im, parameter, int_value) # set options + imbln[123] (im, dim_1, ...) # get buffer dims + imdelete (image_file) # delete image + +where + mode = one of the file modes, NEW_IMAGE, or NEW_COPY + + +Sequential i/o (images of any dimension): + + stat = imgnl[silrdx] (im, bufptr, v) # get next line + stat = impnl[silrdx] (im, bufptr, v) # put next line + + +General i/o (for images of a particular dimension): + + generic getpix, putpix --> im[gp][pls][123][silrdx] + +i.e., bufptr = imgl2r (im, linenum) # get line, type real + bufptr = impl2r (im, linenum) # put line, type real + bufptr = imgs2r (im, x1, x2, y1, y2) # get subraster + + +.fi +Here, [gp] implies get or put, [pls] specifies whether a pixel, line, or +section is to be accessed, [123] specifies the dimensionality of the +subscript (but not of the image itself), and [silrdx] specifies the datatype +of the pixels in the program (but not in the image). For example, "imgl2r" +gets a line of REAL pixels, using a subscript for a two dimensional image. + + +Frequently referenced fields of the image header (see for +a full definition of the image header structure): + +.ks +.nf + IM_NDIM(im) # number of dimensions + IM_LEN(im,naxis) # length of axis NAXIS + IM_PIXTYPE(im) # datatype of the pixels +.fi +.ke + +When creating a new image, only the IM_LEN fields of the new header +need be set. IM_NDIM will be computed by counting the number of nonnull +dimensions. IM_PIXTYPE should be set if type REAL pixels (the default) +are not desired. + + +Example: image C = image A + image B + + The following example is for the SPP language, using only low level +calls. The generic functions GETPIX and PUTPIX have not yet been +implemented. + + +.nf +include + +# Add two 2 dimensional, equal sized images, using type +# REAL arithmetic internally. + + +procedure add_images (im_a, im_b, im_c) + +char im_a[ARB], im_b[ARB], im_c[ARB] +pointer a, b, c +int line +pointer immap(), imgl2r(), impl2r() +errchk immap, imgl2r, imunmap + +begin + a = immap (im_a, READ_ONLY, 0) + b = immap (im_b, READ_ONLY, 0) + c = immap (im_c, NEW_COPY, a) + + do line = 1, IM_LEN(a,2) + call aaddr (Memr[imgl2r(a,line)], Memr[imgl2r(b,line)], + Memr[impl2r(c,line)], IM_LEN(a,1)) + + call imunmap (a) + call imunmap (b) + call imunmap (c) +end +.fi + + +The input images IM_A and IM_B are first mapped for READ_ONLY access +mode. The new image IM_C is next mapped as a NEW_COPY of image A +(the header of C is a copy of that of A, except that all fields describing +the pixels are initialized). + +The images are then added line by line, using the vector operator AADDR. +Note that IMPL2R returns a pointer to the output buffer which is filled, +and later flushed (at the next IMPL2R call, or when the image is unmapped). + +.tp 10 +.sh +TERMINAL CONTROL (fully implemented) + + The TTY routines provide a device independent interface to video display +(not graphics) terminals. The following environment variables are defined +to describe the type of terminal in use: + + +.ks +.nf + terminal terminal name (i.e., "vt100", "tek4012") + ttybaud baud rate, default 9600 + ttyncols number of characters per line + ttynlines number of lines per screen +.fi +.ke + + +For example, the sequence "envgeti ("ttyncols")" will conveniently return +the ncols parameter for use in applications programs which format long +output lines. These variables are initialized upon startup to default +values but will need to be changed by the user if an unusual terminal or +baud rate is used. + +The following library procedures are provided for terminal control: + + +.ks +.nf + ttyclear (fd) Output clear,home sequence to file fd. + ttyhome (fd) Home the alpha cursor (upper left). + ttyso (fd, YES/NO) Turn "standout" mode on/off. + ttyup (fd, nlines) Move cursor up nlines. + ttydown (fd, nlines) Move cursor down nlines. + ttyleft (fd, ncols) Move cursor left n columns. +.fi +.ke + + +There is no "ttyright" function; repaint the screen to move right. +A "ttymove" function may be provided in the future for absolute addressing +but is not currently implemented. Standout mode, if available, equates +to reverse video, underline, or a similar enhancement. + +.ks +.sh +GRAPHICS I/O (partially implemented) + + +GIO high level output procedures (subset system) + +.nf + plot (rdata, npix, x1, x2) # (Implemented) + + +GIO low level output procedures + + fd = gopen (stream) # open graphics stream + gclose (fd) # close graphics stream + gflush (fd) # flush graphics output + gscan (fd, file) # take cmds from a file + greset (fd, screen, aspect_ratio) # reset database, clear + gerase (fd, w) # clear window or screen + + gset[irs] (fd, parameter, value) # set GIO parameter + gswind (fd, w, w_struct) # set window + gsmark (fd, mark, array) # define a mark pattern + ginitw (w_struct) # initialize w_struct + + gmov[ar][wpu] (fd, x, y) # move pen + gdrw[ar][wpu] (fd, x, y) # draw line + gpnt[ar][wpu] (fd, x, y) # draw point + gdsh[ar][wpu] (fd, x, y, l) # draw dashed line + gmark[wpu] (fd, mark_type, sx, sy) # draw mark + gmovc[wpu] (fd, x, y) # move cursor + + gplt1[silrdx] (fd, pixels, npix, x) # plot {x=x+i-1,y[i]} + gplt2[silrdx] (fd, pixels, nx, ny, x, y) # plot 2d data + gpltw[silrdx] (fd, wx, wy, npts) # plot {x,y}, window + gpltp[silrdx] (fd, px, py, npts) # plot {x,y}, pixel + gpltu[silrdx] (fd, ux, uy, npts) # plot {x,y}, user + gpltim (fd, image, section, x, y) # plot from imagefile + + gprintf (fd, format, arg [,...]) # plot text string + gptext (fd, str, ang, cent, size) # lower level plot text + + +Access window descriptor structure, transform coords + + stat = ggetw (stream, w, w_struct) # get transformations + g[wpu]to[wpu] (w_struct, x,y, x,y) # coord transformation +.fi +.ke + + +.ks +.nf +Standard graphics devices: + + STDGRAPH # interactive graphics device + STDIMAGE # image display device + STDPLOTTER # batch plot device + +Mark types: + GM_CIRCLE, GM_BOX, GM_PLUS, GM_DIAMOND, GM_HLINE, GM_VLINE, + GM_UPARROW, GM_DOWNARROW, ... +.fi +.ke + +.tp 10 +.sh +MAGTAPE I/O (fully implemented) + + A magtape device is opened with MTOPEN, then accessed like any other +binary file via the FIO interface (sequential access only). Buffering +and record blocking and deblocking is normally handled transparently by +FIO. If a specific tape record size is required when writing, the buffer +size (in chars) should be given when the tape file is opened with MTOPEN. +If the tape is opened for reading, a suitably large buffer will be allocated +to handle the largest permissible tape records. All i/o transfers must be in +units of chars. Use SZB_CHAR (size of a CHAR in bytes) for size conversions. + + +.nf + fd = mtopen (filename, mode, fio_bufsize) + +where + filename = mt[ab][800|1600]'['tape_file_number']', + i.e., "mta1600[2]" == file 2 on drive a + + mode = READ_ONLY, WRITE_ONLY, APPEND (a new file + to tape), NEW_TAPE (write file 1 on tape) + + fio_bufsize = FIO buffer size, chars (default used if 0) +.fi + + +If the filename does not begin with the characters "mt", MTOPEN assumes +the file is a regular (disk resident) binary file and attempts to open +it is as one. If the tape file number subscript is omitted, MTOPEN +opens the tape to the beginning of the file to which the tape is currently +positioned. + +Like any other file, a magtape file is closed with CLOSE. When a file +opened for writing is closed, a new end of tape mark will be written. +It is illegal to seek on a magtape. A magtape may be opened for either +reading or writing, but not for both at the same time. If a read returns +EOF, the next read will return the first record of the next file, or +another EOF if at EOT. + + +.tp 10 +.sh +MEMORY MANAGEMENT (fully implemented) + + Space may be dynamically allocated and freed on either the stack +or the heap. Buffers allocated by MALLOC, CALLOC, or SALLOC are aligned +for all data types. MALLOC and SALLOC allocate a buffer. CALLOC +is like MALLOC except that it also zeros the buffer. BEGMEM tries to +grab physical memory (increase the working set size), FIXMEM returns +physical memory. + + +.nf + nchars = begmem (maxch, oldsize) # increase physical memory + fixmem (oldsize) # restore physical memory + + malloc (ptr, nelem, type) # allocate space on the heap + calloc (ptr, nelem, type) # allocate and zero space + realloc (ptr, nelem, type) # adjust size of buffer + mfree (ptr, type) # free space on the heap + + smark (sp) # save stack pointer + salloc (ptr, nelem, type) # allocate space on stack + sfree (sp) # pop stack to old sp + + addr = zloc (datum) # get absolute address + addr = zlocc (datum) # get address in char units +.fi +.ke + + +.ks +.nf +relevant definitions (global language): + + SZ_type size of type (SHORT, INT, etc.) in CHARS + SZ_VMPAGE size of page of virtual memory (1 if non-v) + SZB_CHAR size of type CHAR in machine bytes + SZB_ADDR size of a machine address increment, bytes +.fi +.ke + + +.tp 10 +.sh +DATE AND TIME (fully implemented) + + CLKTIME and CPUTIME return the difference between the argument and the +current clock or cpu time. If CLKTIME is called with a zero argument, +the local standard time in long integer seconds since 00:00:00 01-Jan-80 +is returned. This may be broken down into the year, day, hour, etc. with +BRKTIME (see ), or converted into a date/time string with CNVTIME +or CNVDATE. The maximum size of the output strings are given by the +parameters SZ_TIME and SZ_DATE in . + +.nf + long = clktime (old_time) # clock time, seconds + long = cputime (old_time) # cpu time used, millisec + + brktime (clktime, ostruct) # get day, hour, etc. + cnvtime (clktime, outstr, maxch) # cvt to long string + cnvdate (clktime, outstr, maxch) # cvt to short string +.fi +.ke + + +.ks +.sh +PROCESS CONTROL (partially implemented) + +.nf +** tid = connect (task, fdin, fdout) # exec and open pipes +** disconnect (tid) # close task + +** code = twait (tid) # wait for completion +** int = tstatus (tid, what) # get task status +** tkill (tid) # kill that task + +** zrestart (code) # error restart +.fi +.ke + + +.tp 10 +.sh +EXCEPTION HANDLING (fully implemented) + + A user handler procedure is posted by a call to XWHEN. If and when the +exception occurs, the handler is called with an integer argument identifying +the exception (the same handler may be posted for multiple exceptions). +The handler procedure should return as its second argument either X_IGNORE +(resume normal execution) or the address of a procedure to be executed, +normally the "old_hander" address returned by XWHEN. + +ONEXIT is used to post a procedure to be executed upon process termination. +The user supplied procedure is called upon abnormal or normal termination +with an integer argument identifying the exit status (OK for a normal +exit, the error code for an error exit). Several procedures may be posted +if desired. An attempt to post a procedure which has already been posted +is ignored. ONERROR is similar, but is called during error restart. + + +.nf + procedure user_handler (exception_code, next_handler) + procedure user_proc (exit_code) + + xwhen (exception, user_handler; old_handler) + onexit (user_proc) + onerror (user_proc) + +.fi +.ke + +.rj +exceptions: + +.nf + X_INT # keyboard interrupt + X_ARITH # arithmetic error + X_ACV # access violation + + +built-in handlers: + + X_IGNORE # ignore exception entirely +.fi + +The user handler may call FATAL to force error restart, or ERROR +to conditionally cause error restart (depends on whether or not an +IFERR type error handler is posted). Error actions should not occur +during execution of an ONEXIT procedure, and ONEXIT procedures should +return promptly. + + +.sh +ERROR HANDLING (fully implemented) + + A recoverable error condition is asserted with ERROR. An irrecoverable +error condition is asserted with FATAL. Error recovery is implemented +using the IFERR and IFNOERR statements in the preprocessor language. +ERRACT may be called in an IFERR statement to cause a warning to be issued, +or to cause a particular error action to be taken. ERRCODE returns either +OK or the integer code of the posted error. + +Language support includes the IFERR and IFNOERR statements and the ERRCHK +declaration. The IFERR statement is grammatically equivalent to the IF +statement. Note that the condition to be tested in an IFERR statement may +be a procedure call or assignment statement, while the IF statement tests +a boolean expression. + + +.nf + errchk proc1, proc2, ... # errchk declaration + + iferr (procedure call or assignment statement) + + + iferr { + + } then + + + +Library procedures (ERROR and FATAL cause a RETURN): + + error (errcode, error_message) + fatal (errcode, error_message) + erract (severity) + val = errcode () +.fi + + +.rj +ERRACT severity codes + +.nf + EA_WARN # issue a warning message + EA_ERROR # assert recoverable error + EA_FATAL # assert fatal error +.fi + + +An arithmetic exception (X_ARITH) will be trapped by an IFERR statement, +provided the posted handler(s) return without causing error restart. +X_INT and X_ACV may only be caught by posting an exception handler with +XWHEN. +.ke + +.ks +.sh +BOOLEAN OPERATORS (fully implemented) + +.nf + int = and (a, b) # (ands, andl) + int = or (a, b) # (ors, orl) + int = not (a) # (nots, notl) + int = xor (a, b) # (xors, xorl) + bool = tbit (a, bit) # test bit (tbits, tbitl) + sbit (a, bit) # set bit (sbits, sbitl) +.fi +.ke + +.ks +.sh +BYTE and CHARACTER conversion (fully implemented) + +.nf + strpak (str, os_str, maxch) # pack OS string + strupk (os_str, str, maxch) # unpack OS string + + chrpak (a, a_off, b, b_off, nchars) # pack chars + chrupk (a, a_off, b, b_off, nchars) # unpack chars + + bytmov (a, a_off, b, b_off, nbytes) # move bytes + bswaps (a, b, nshorts) # byte swap, short + bswapl (a, b, nlongs) # byte swap, longs +.fi +.ke + + +Chars are signed integers, whereas bytes as unsigned integers. The BSWAP +routines are used to swap bytes in short and long integer arrays, as is +sometimes required when transporting data between machines. The MII package +is available for conversions between a machine independent integer format +and the SPP datatypes (documented elsewhere). +.fi +.ke + +.ks +.sp 2 +.rj +CHARACTER COMPARISONS (fully implemented) + +.nf + bool = IS_UPPER (char) # upper case? + bool = IS_LOWER (char) # lower case? + bool = IS_DIGIT (char) # numeral? + bool = IS_PRINT (char) # printable character? + bool = IS_CNTRL (char) # control character? + bool = IS_ASCII (char) # 7 bit ASCII character? + bool = IS_ALPHA (char) # letter (either case)? + bool = IS_ALNUM (char) # alphanumeric character? + bool = IS_WHITE (char) # whitespace character? + char = TO_DIGIT (int) # convert integer to char + int = TO_INTEG (char) # convert digit to integer + char = TO_UPPER (char) # convert to upper case + char = TO_LOWER (char) # convert to lower case +.fi +.ke + + +These definitions are defined in the include file . +These are macro definitions, not procedures (they produce inline code and +need not be declared). TO_UPPER and TO_LOWER must only be applied to +letters of the proper case (use the procedures CHRUPR, CHRLWR otherwise). + +.ks +.sh +STRING UTILITIES (fully implemented) + +.nf + ch = chrupr (ch) # char to upper case + ch = chrlwr (ch) # char to lower case + + strlwr (str) # string to lower case + strupr (str) # string to upper case + index = stridx (char, str) # first index of char in str + index = strldx (char, str) # last index of char in str + strcpy (from, to, maxch) # copy EOS delim string + strcat (str, outstr, maxch) # concatenate str to outstr + int = strlen (str) # length of string (excl EOS) + int = gstrcpy (from, to, maxch) # returns length of outstr + int = gstrcat (str, outstr, maxch) # returns length of outstr + + strtbl (fd,buf,strp,nstr; first_col,last_col,maxch,ncol) +.fi +.ke + + +.ks +.nf +String Comparisons (str__ --> str(eq|ne|le|lt|ge|gt)) + + bool = str__ (s1, s2) # is s1 __ s2? + -1,0,1 = strncmp (s1, s2, n) # counted comparison + nextch = strsearch (str, patstr) # fast substring search + nextch = strmatch (str, patstr) # match strings (^$?#{}) + nextch = gstrmatch (str, patstr, first_ch, last_ch) +.fi +.ke + + +.tp 5 +PATTERN MATCHING (fully implemented) + +.nf + patsize = patmake (patstr, patbuf, maxch) # prepare pattern + nextch = patmatch (str, patbuf) # match pattern + nextch = gpatmatch (str, patbuf, first_ch, last_ch) + + + Metacharacters (note strmatch implements ^$?#{}) + + ^ beginning of line + $ end of line + * zero or more occurrences + ? match any single character + [xy] match char if in the set "xy" + [^xy] match anything but chars in the set "xy" + [x-y] match a range of chars + # short for [ \t]* (whitespace) + { begin matching either upper or lower case + } restore case sensitivity +.fi +.ke + + +.tp 8 +RANDOM NUMBERS + + The URAND procedure (Uniform RANDom number generator) is available +for random number generation. + + real = urand (seed) + +The long integer SEED should be set before the first call, and is controlled +by URAND thereafter. Random numbers are returned in the range [0-1]. + +.tp 8 +.sh +SORTING + + The general quicksort procedure may be used to sort objects of any +type or size. This generality is achieved by having the user program +supply an integer index array (which is what gets sorted), and a comparison +procedure. + +.nf + qsort (index, nelems, compare) +where + int index[nelems], nelems + extern int compare() + + -1,0,1 = compare (index_1, index_2) +.fi + +The external integer function "compare" (of any name) should return -1 if the +object indexed by "index_1" is less than the object indexed by "index_2", +0 if they are equal, and 1 if the first is greater than the second. + +Data vectors of type INT, REAL, etc. may be most conveniently sorted using +the ASRT_ vector operators, described in the next section. + +.tp 10 +.sh +VECTOR OPERATORS (fully implemented, but may change) + + Add a "k" to the three character instruction mnemonic if one of the +vector operands is a constant rather than a vector. Add one or two type +suffix characters to specify the datatype(s) of the operands. + + +.ks +.nf +Examples: + achtir (a, b, npix) (int to real) + amovkr (5.0, b, npix) (fill with 5.0s) + asrtr (a, b, npix) (sort a into b) + aaddi (a, b, c, npix) (c = a + b) +.fi +.ke + + +.tp 5 +.nf + Instruction Operation Data Types + + acht__ b = a (change datatype) UBcsilrdx + aclr_ fill a with zeros UBcsilrdx + amov_ (k) b = a (copy vector) UBcsilrdx + + asrt_ b = sort (a) csilrdx + aabs_ b = abs(a) silrdx + alog_ b = log10(a) silrdx + alln_ b = natural_log(a) silrdx + asqr_ b = sqrt(a) silrdx + aneg_ b = -a silrdx + amap_ b = (a + k1) * k2 silrdx + altr_ b = a, map [a1:a2] -> [b1:b2] silrdx + amap_B b = (a + k1) * k2 silrdx + alutc b = lookup[a], 1 <= a < 128 c + alui_ b = interp (a, x, npix) silrd + + aadd_ (k) c = a + b silrdx + asub_ (k) c = a - b silrdx + amul_ (k) c = a * b silrdx + adiv_ (k) c = a / b silrdx + amin_ (k) c = min(a,b) silrd + amax_ (k) c = max(a,b) silrd + amod_ (k) c = mod(a,b) silrd + apow_ (k) c = a ** int_pwr silrdx + aexp_ (k) c = a ** real_pwr silrdx + awsu_ c = a*k1 + b*k2 silrdx + + anot_ b = !a sil + aand_ (k) c = and(a,b) sil + abor_ (k) c = or(a,b) sil + axor_ (k) c = xor(a,b) sil + + +.tp 4 +Other vector primitives: + + alim_ ngpix = lim_ (a, npix; minval, maxval) silrdx + awin_ nrej = win_ (a, npix, lcut, hcut) silrdx + aavg_ ngpix = avg_ (a, npix; mean, sigma) silrdx + arav_ ngpix = rav_ (a, npix; mean, sigma; ksig) silrdx +.fi + + +Example: Add 1 to each element of the integer vector A. + + call aaddki (a, 1, a, npix) + +NOTE: On a given system, some of the vector operators are likely to +be hand optimized in machine code. Other systems will interface the +vector operators to an array processor. A transportable version of +each operator will always exist. Use the standard vector operators +whenever possible to gain maximum efficiency without compromising the +machine/device independence (transportability) of your program. +.endhelp diff --git a/doc/doc/doc.hd b/doc/doc/doc.hd new file mode 100644 index 00000000..fd54be66 --- /dev/null +++ b/doc/doc/doc.hd @@ -0,0 +1,9 @@ +# Help directory for the DOC package (general system documentation) + +expressions hlp=expressions.hlp + +biblio84 hlp=biblio84.hlp +crib83 hlp=crib83.hlp +pkg84 hlp=pkg84.hlp +pmmatch hlp=pmmatch.hlp +spp83 hlp=spp83.hlp diff --git a/doc/doc/doc.men b/doc/doc/doc.men new file mode 100644 index 00000000..1dafa532 --- /dev/null +++ b/doc/doc/doc.men @@ -0,0 +1,10 @@ + DOC - General IRAF Documentation + + expressions - Standard expression syntax in IRAF tasks + pmmatch - Pixel mask matching + + -- Old Historical Documents -- + biblio84 - Summary of IRAF documentation (circa 1984) + crib83 - Cribsheet for the Program Interface (circa 1983) + pkg84 - Package structure (circa 1984 + spp83 - SPP reference manual (circa 1984) diff --git a/doc/doc/expressions.hlp b/doc/doc/expressions.hlp new file mode 100644 index 00000000..b2ea164a --- /dev/null +++ b/doc/doc/expressions.hlp @@ -0,0 +1,149 @@ +.help expressions Feb07 "IRAF Expressions" + +.sh +Introduction + +Many +.hr #s_see_also IRAF tasks +use expressions. These all go through the same basic expression evaluator. +This provides a standard set of operators and functions with a +common syntax similar to the CL. However, each application can customize + +.ls * +how expressions are input; e.g. from files or with special prefixes +.le +.ls * +how variables (called operands) are specified; e.g. with leading +special characters such as '$' or with single letter capitals +.le +.ls * +where the values are obtained; e.g. from image header keywords or +from data files +.le +.ls * +special, application specific functions; e.g. airmass or arcsep +.le + +This help topic covers the common features of expressions. The +individual task help descriptions may also include this material or +just describe the customization. + +.sh +Expressions + +Expressions consist of operands, numeric and string constants, operators, +and functions. Parentheses are also used to control the evaluation order +as in standard algebraic expressions. String constants are quoted strings +and numeric constants are pure unquoted numbers. Numbers may be given in +sexagesimal notation and are automatically converted to decimal numbers. +The operators are arithmetic, logical, and string. + +.sh +Operands + +The way applications refer to operands is generally unique to that task. +Sometimes they are simply alphanumeric identifiers, sometimes they +have prefixes such '$', sometimes they are limited to specific +identifiers, and sometimes they have additional structure such as +. where is an identifier for an image +and refers to a keyword in the image. Common types of +operands refer to images, table columns, and keywords. + +There is one special common syntax for operands that include characters that +correspond to the operators in expressions. In this case the operand +identifier must be quoted as a string and then referenced using a leading @ +character; e.g. @'mjd-obs'. + +.sh +Operators + +The following operators are recognized in expressions. With the exception +of the operators "?", "?=", and "@", the operator set is equivalent to that +available in the CL. + +.nf + + - * / arithmetic operators + ** exponentiation + // string concatenation + ! - boolean not, unary negation + < <= > >= order comparison (works for strings) + == != && || equals, not equals, and, or + ?= string equals pattern + ? : conditional expression (ternary operator) + @ reference a operand +.fi + +The operators "==", "&&", and "||" may be abbreviated as "=", "&", and "|" +if desired. The ?= operator performs pattern matching upon strings. +The pattern syntax is that described for the task +.hr match \fBmatch\fR. +The @ operator is required to reference keywords with +one of the operator characters. This is most likely to be used as: + +.nf + @"date-obs" +.fi + +A point to be aware of is that in the ?: conditional expression both +possible result values are evaluated though the result of the expression +is only one of them. + +.sh +Functions + +A number of standard intrinsic functions are recognized within +expressions. Many of these may not be useful in the context of the +application but are part of the language. The set of +functions currently supported is shown below. + +.nf + abs atan2 deg log min real sqrt + acos bool double log10 mod short str + asin cos exp long nint sin tan + atan cosh int max rad sinh tanh +.fi + +The trigonometric functions operate in units of radians. +The \fImin\fR and \fImax\fR functions may have any number of arguments up +to a maximum of sixteen or so (configurable). The arguments need not all +be of the same datatype. + +A function call may take either of the following forms: + +.nf + '(' arglist ')' + '(' arglist ')' +.fi + +The first form is the conventional form found in all programming languages. +The second permits the generation of function names by string valued +expressions and might be useful on rare occasions. + +.sh +SEE ALSO + +.hr imexpr \fBimexpr\fR +.hr hedit \fBhedit\fR +.hr hselect \fBhselect\fR +.hr asthedit \fBasthedit\fR +.hr astcalc \fBastcalc\fR +.hr irproc \fBirproc\fR +.hr ircatalog \fBircatalog\fR +.hr ccget \fBccget\fR +.hr mskexpr \fBmskexpr\fR +.hr mskreg \fBmskreg\fR +.hr import \fBimport\fR +.hr export \fBexport\fR +.hr agetcat \fBagetcat\fR +.hr pcalc \fBpcalc\fR +.hr pconvert \fBpconvert\fR +.hr pdump \fBpdump\fR +.hr pselect \fBpselect\fR +.hr tbcalc \fBtbcalc\fR +.hr tbdump \fBtbdump\fR +.hr tbselect \fBtbselect\fR +.hr txcalc \fBtxcalc\fR +.hr txdump \fBtxdump\fR +.hr txselect \fBtxselect\fR + +.endhelp diff --git a/doc/doc/news.v28.hlp b/doc/doc/news.v28.hlp new file mode 100644 index 00000000..8a2eeace --- /dev/null +++ b/doc/doc/news.v28.hlp @@ -0,0 +1,1269 @@ +.help iraf Mar90 "V2.8 Revisions" + +.ce +\fBIRAF Version 2.8 Revisions Summary\fR +.ce +June 30, 1989 +.sp 2 +.NH +Introduction + + This revisions notice coincides with the release of version 2.8 of +IRAF. The V2.8 release is a general release for all supported IRAF hosts. + +The following is a brief description of some of the new features available +in IRAF Version 2.8. This is not intended to be an exhaustive list, but +rather a brief summary of the major changes since the last +major release of IRAF Version 2.5 in July 1987 and subsequent intermediate +releases primarily to support Sun/IRAF: IRAF Version 2.6 (February 1988), +IRAF Version 2.6+ (March 1988), and IRAF Version 2.7 (December 1988). + +More detailed revisions notes are available in the system notes files in +the \fRiraf$doc\fR and \fRiraf$local\fR directories, as well as in the +online revisions notes for the various packages. + +.NH +IRAF System Revisions + + This document highlights the most notable revisions made to the IRAF core +system software for Version 2.8. This is only a revisions summary; +no attempt is made to provide detailed technical documentation for each +revision, nor is there any attempt to exhaustively summarize all revisions. +A complete record of all core system revisions will be found in the +\fISystem Notes\fR for V2.8. Additional information on some of the topics +covered below will be found in the various \fIInstallation Guides\fR +and \fISite Manager's Guides\fR, +and in the \fIIRAF User and Technical Documentation\fR manual sets. + +.NH 2 +Copyright notice + + Subject to AURA and NSF approval, the IRAF software will be copyrighted +sometime during 1989. As a first step in this process, a copyright notice +has been added to all core system source files. The notice reads as follows: +"Copyright(c) 1986 Association of Universities for Research in Astronomy Inc". +We will also be adding a file called COPYRIGHT to the distribution stating +the terms of the copyright and associated licensing agreement for the software. + +The intent of this action is solely to protect the software from unauthorized +commercial exploitation, and the copyright grants, or will grant, the right to +copy, modify, and redistribute the IRAF software provided the original +copyright notice remains intact, the software is made available in source form, +and the rights we grant are passed on with the software. We wish to prevent +others, especially commercial firms, from copyrighting IRAF software in their +own name and possibly taking away the rights we grant with the software. +Granting the right to modify and redistribute IRAF software does not mean +we want to encourage people to do so, we merely want them to have the legal +right to do so if they feel they need to. + +.NH 2 +Major system enhancements + + The information in this section is provided primarily for the benefit of +IRAF site managers and programmers. The reader interested primarily in +science applications may wish to skip ahead. Some systems level familiarity +with the current IRAF system is assumed. +.NH 3 +Layered software enhancements + + A given IRAF installation consists of the core IRAF system, and any number +of \fBlayered software products\fR or \fBexternal packages\fR. The goal +of the layered software enhancements introduced in V2.8 is to make layered +software products self contained and hence independent of the core system +and of other layered software. Examples of layered software products are +the NOAO packages, LOCAL, STSDAS, PROS, and so on. + +The layered software enhancements make it possible to install or deinstall +a layered product by modifying only a single file in the core IRAF system. +The core system may be updated without affecting layered software, and vice +versa. Since layered products are independent and are simple to install, +IRAF can easily be configured with only those packages needed at a particular +site. Software developers benefit from the layered software enhancements +because the facilities provided for development and maintenance of layered +software are equivalent to those provided for development of the core IRAF +system and the NOAO packages. User sites benefit because it is easy to +extend the system with LOCAL packages of their own making. + +Each layered product (usually this refers to a tree of packages) is a system +in itself, similar in structure to the core IRAF system. Hence, there is a +LIB (global system library), one or more BINs (binary file directories), +a Help database, a set of global environment definitions, and all the sources +and runtime files, all contained within the same directory tree. Layered +software products, in their source only form, are portable without change +to any computer which runs IRAF. +.NH 4 +The hlib$extern.pkg file + + This is the file which is modified to install or deinstall layered software +products. To install a layered product, one creates a directory to hold +the software, restores the files to disk, and edits the \fRextern.pkg\fR file +to tell IRAF the name of the root package of the layered product, and where +the root directory is located. If the layered software is distributed in +source only form it will also be necessary to recompile the software, but +this is a completely automated process. +.NH 4 +NOAO and LOCAL packages reorganized + + As part of the project to better support layered software, the NOAO and +LOCAL packages have been reorganized as layered products. These packages +are now structurally equivalent to third party (non-NOAO) packages, +except that the directory trees are rooted in IRAF. Both packages are +now self contained, with their own LIB, BINs, Help database, etc., +and with an entry in \fRextern.pkg\fR, like other layered products. +The NOAO package serves as a working example of how to configure a +layered package. The reorganization of these packages should be +transparent to anyone merely using the system. +.NH 4 +The template LOCAL + + The LOCAL package included with the distributed system has been stripped of +all NOAO site-local tasks and restructured as a layered product, +the \fItemplate local\fR. The template local contains only two sample +tasks and is not intended as an end-user package, but rather as a template +to be copied and modified by sites to construct their own site dependent +LOCAL package. The desire to be able to easily develop and maintain +locally added packages was one of the major motivations for the layered +software enhancements project, and we hope that sites will realize the +significance of this new capability and take advantage of it. +.NH 4 +CL now supports package level BIN directories + + Rather than assuming a global BIN directory for all tasks and packages, +the CL now permits multiple BIN directories, each BIN directory being +associated with the package of definition and all subpackages of that +package (unless they have their own BIN). A new BIN directory is declared +with the optional argument \fRbindir=\fIpath\fR in the \fRpackage\fR +statement, e.g., in a package script task. +.NH 4 +MKPKG support for package environments + + Layered packages now have their own private LIB, including an environment +definitions file (\fRzzsetenv.def\fR), mkpkg global include file +(\fRmkpkg.inc\fR), and, optionally, a mkpkg special file list file for +each supported host system, listing files requiring special compilation +to work around host compiler bugs or whatever. The full mkpkg environment +is formed by reading the IRAF core system environment and mkpkg definitions +and include files, followed by the package definitions and include files. +Reading of the package environment occurs \fIonly\fR if mkpkg is called +with the "\fB-p\fR" flag, or if the variable \fRPKGENV\fR is defined in +the user's environment. + +Another way of expressing this is, when using mkpkg within a layered package, +one must now specify the name of the layered package in order to pick up the +package environment definitions. For example, to update the MTLOCAL package +in NOAO, one would type "\fRmkpkg -p noao update\fR" in the \fRmtlocal\fR +directory. If this is not done compilation errors may result, or the +executable may not be successfully installed in the package BIN directory. +.NH 3 +Multiple architecture support + + A single IRAF system (or layered package) can now simultaneously support any +number of machine architectures using multiple BIN directories sharing a +single machine independent copy of IRAF. Each BIN directory contains all +the object modules, object libraries, and executables for a particular +architecture. An architecture can represent either a type of hardware, +e.g., sparc, mc68020+f68881, mc68020+ffpa, vax, etc., or a software +distinction, e.g., systems compiled with different sets of compiler flags, +or different versions of a system. Multiple architectures are now supported +both for IRAF execution, and for IRAF based software development, e.g., +a single version of IRAF can now be used to develop and run IMFORT programs +on both Sun-3 and Sun-4 nodes. + +The only case where multiple architecture support is used at the present +time is in Sun/IRAF, which is often installed on a heterogeneous network of +workstations, e.g., Sun-3s with various hardware floating point options, +and Sun-4s. A single copy of IRAF will be configured with several BIN +directories, one for each supported architecture, and NFS mounted on all +the network nodes which will be using IRAF. There is no reason that this +feature need be restricted to use with Sun/IRAF, however. +.NH 4 +IRAFBIN and IRAFARCH + + Starting with IRAF V2.8, the old environment variable \fRIRAFBIN\fR has been +obsoleted and replaced by \fRIRAFARCH\fR. On machines which support +multiple architectures, the latter defines the architecture to be used for +both IRAF execution and software development. If only IRAF execution is +needed the variable is optional, with the best architecture being selected +automatically when the CL is started. If one will be doing software +development (including IMFORT) it is best to define the variable in the +host environment before starting IRAF or doing any host level software +development. Typical values of \fRIRAFARCH\fR for a Sun workstation are +"sparc", "i386", "f68881", and "ffpa". +.NH 4 +System libraries moved to the BIN directory + + As part of the revisions required for multiple architecture support for +software development, all object libraries have been moved from the global, +architecture independent LIB to the architecture dependent BIN, with the +LIB entries being replaced by symbolic links (in the case of Sun/IRAF). +This should be transparent to both end users and programmers. +.NH 4 +New bin.generic architecture + + On Sun/IRAF systems, which are distributed configured for multiple +architecture support, the system architecture is set to \fRgeneric\fR +in the distributed system. What this means is that all architecture +dependent files (objects and object libraries) have been removed from +the system directories and archived in the file \fROBJS.arc\fR in the +BIN directory for each architecture. Rebuilding any of the packages in +a system would require restoring the binaries for a particular architecture, +e.g., typing "\fRmkpkg sparc\fR" at the IRAF root would restore the +sparc binaries for the core system on a Sun/IRAF installation. Note that +this \fIonly\fR affects software development for the system in question; +software development for external packages or private user software is +not affected. +.NH 3 +Shared library facility + + IRAF version 2.8 adds support for a general shared library facility for +UNIX based systems. Although currently only used with Sun/IRAF, +this facility is potentially useful for other UNIX based IRAF systems +as well (VMS/IRAF already has its own shared library facility). + +What the shared library facility does is take most of the IRAF system +software (currently the contents of the \fRex\fR, \fRsys\fR, \fRvops\fR, +and \fRos\fR libraries) and link it together into a special sharable +image, the file \fRS.e\fR in each core system BIN directory. This file +is mapped into the virtual memory of each IRAF process at process startup +time. Since the shared image is shared by all IRAF processes, each process +uses less physical memory, and the process pagein time is reduced, speeding +process execution. Likewise, since the subroutines forming the shared image +are no longer linked into each individual process executable, substantial +disk space is saved for the BIN directories. Link time is correspondingly +reduced, speeding software development. + +With the introduction of the shared library facility, the disk space +required for Sun/IRAF is substantially reduced. Due to the increased memory +sharing and reduced process pagein times performance is substantially +improved, especially on systems like the Sun/386i which has a relatively +slow SCSI disk and often limited memory. The disk size of small programs +is reduced by up to a factor of ten in some cases, e.g., an executable +for a small program that was formerly 250 Kb in size might be as small as +25 Kb if the shared library is used and the shared image symbols are omitted +at link time. + +.NH 2 +User interface changes +.NH 3 +Calling IRAF tasks from the host environment + + The IRAF main and zmain were modified to make it easier to call IRAF tasks +as host level tasks, i.e., without having to set up a command file and +run the process with the standard input redirected. In the new scheme, +any extra arguments given on the process command line are passed into +the IRAF main as a command buffer containing the IRAF command or +commands to be run. For example, +.sp +.nf + \fRcl> x_system.e netstatus\fR +.fi +.sp +would run the command \fRnetstatus\fR in process \fRx_system.e\fR. +.sp +.nf + \fRcl> x_system.e count "files=*.x"\fR +.fi +.sp +would run the \fRcount\fR task, counting all ".x" files in the current +directory. +.sp +.nf + \fRcl> x_system.e count "files=*.x 4>_o"\fR +.fi +.sp +would do the same, redirecting the output at the IRAF main level to +the file \fR_o\fR. +.sp +.nf + \fRcl> x_system.e 'directory @pars $nargs=0'\fR +.fi +.sp +would run the \fRdirectory\fR task with the given parameter set, with +\fR$nargs\fR set to 0. If any of the parameters to a task are omitted +the task will query the terminal for them in the usual way, so for example +.sp +.nf + \fRcl> alias count "$iraf/bin/x_system.e count files="\fR +.fi +.sp +would make the IRAF task \fRcount\fR available in UNIX, allowing the +IRAF template specifying the files to be counted to be either given +on the UNIX command line, or prompted for if omitted. Given the +above alias, one could enter a UNIX command such as +.sp +.nf + \fRcl> count 'cl$*.h'\fR +.fi +.sp + +This feature is available in all UNIX based versions of IRAF V2.8, +but did not make it into VMS/IRAF version 2.8. +.NH 3 +Image packing density control (impkden) + + Some users have complained about images taking up more disk space than they +have to, due to the IMIO feature which conditionally blocks image lines to +fill an integral number of disk blocks. This can result in more efficient +image i/o but can also make a significant difference in the amount of disk +space consumed by an image in some cases. + +IMIO can actually support both block-aligned and fully packed images. +The decision is made at image creation time and is based on the \fBimage +packing density\fR if image lines are block aligned. If the packing +density is too low for a block-aligned image, a fully packed image is created +to avoid wasting disk space. The default minimum packing density is 0.6, +i.e., up to 40% wasted space before IMIO switches to full packing (no +wasted space). + +For finer control over the packing density, the user can now specify the +optional environment variable \fRimpkden\fR, the numeric value being the +minimum packing density. For example, +.sp +.nf + \fRcl> set impkden = 1.0\fR +.fi +.sp +would completely disable block-alignment of image lines in IMIO. +.NH 3 +User libraries (IRAFULIB) + + It is now possible for the programmer (SPP or IMFORT) to specify a private +directory to be searched at compile or link time when developing IRAF or IMFORT +programs. This is done by defining the path to the directory in the user +environment as the variable \fRIRAFULIB\fR. When locating a particular file, +this directory will be searched \fIbefore\fR the IRAF system libraries are +searched, hence this feature may be used to substitute custom versions of +files in the IRAF system libraries, e.g., for debugging purposes. +.NH 3 +New logical printer device LPR + + A new logical line printer or plotter device \fRlpr\fR is now supported on +all UNIX/IRAF systems. This treats the UNIX task \fIlpr\fR as a kind of +pseudo-device, leaving it up to UNIX to decide what physical device to dispose +of the output to. This default is system dependent, but on some systems can +be controlled by defining the variable \fRPRINTER\fR in the user environment. +.NH 3 +Machine independent help database + + The IRAF \fRhelp\fR task uses a precompiled binary database to speed help +keyword searching. This file is now machine independent, allowing it to be +generated on one system and included in software distributions without +having to be recompiled. In addition, as part of the layered software +support, \fRhelp\fR now allows each external package to have its own +private help database. The first time \fRhelp\fR is run, all such databases +are read and linked to produce a database containing entries for all +help modules in the core system and all installed external packages. +The help database file is the file \fRhelpdb.mip\fR in the LIB directory +of the core system and each external package. +.NH 3 +Set terminal type will no longer hangup + + On systems, e.g., workstations, which provide virtual terminal windows which +can change in size, IRAF may query the terminal at run time to determine +the screen size. This query is performed, for example, at login time if +the terminal type is set to \fRgterm\fR or \fRsun\fR. Formerly this +could cause the login process to hang indefinitely (i.e., until the user +typed return or interrupt) if the terminal did not respond to the size query, +as would happen when the terminal type was set improperly and the actual +terminal ignored the query. Thanks to the addition of non-blocking raw +terminal i/o in V2.8 IRAF, the terminal screen size query will now time out +with a warning message to reset the terminal type, if the terminal does +not respond to the query within several seconds. +.NH 3 +Installing a new version of IRAF obsoletes old user parameter files + + The problem of old, obsolete user (\fRuparm\fR) parameter files being +used with a newly installed version of IRAF, which could lead to "parameter +not found" error aborts, has been fixed. The CL now checks the date of +the file \fRutime\fR in HLIB, and refuses to use the user pfile if it +is older than either \fRutime\fR or the package pfile provided with the +new system. The contents of old user pfiles are merged into the new system +pfile, as before, preserving learned parameter values even when the user +pfile is obsolete. +.NH 3 +@file list bug fixed + + The problem of the "@file" (at-file-list) syntax not working when the file +in question was not in the current directory has been fixed. + +.NH 2 +Programming interface changes +.NH 3 +IMFORT pixel directory control + + IMFORT has been modified to permit specification of the pixel file +directory by the calling program. The modifications are completely +upwards compatible, i.e., existing programs linked with the new +interface will still create pixel files in the same directory as +the header file, with "HDR$" in the image header. + +The Fortran programmer may set or query the pixel file directory +using the following routines: +.sp +.nf + \fRimsdir (dir) # set pixel directory pathname + imgdir (dir) # get pixel directory pathname\fR +.fi +.sp +where \fIdir\fR is a Fortran character variable. The value should +be either "HDR$" (the default) or a concatenable host directory +pathname (i.e., trailing / required for UNIX). Once set, the +pixel directory will be used for all subsequent image create or +rename operations by the calling process. + +For example, +.sp +.nf + \fRcall imsdir ("/tmp3/pixels/") + call imcrea (image1, axlen, naxis, dtype, ier) + call imcrea (image2, axlen, naxis, dtype, ier)\fR +.fi +.sp +If desired the default pixel directory may be specified in the +host environment as \fRimdir\fR or \fRIMDIR\fR before running the program. +IMFORT will check the host environment for this environment variable +then use "HDR$" as the default if no host definition is found. + +Note that although this is similar to setting the value of \fRimdir\fR +in the IRAF environment, IMFORT programs are not part of the IRAF +environment and are not affected by changes to the IRAF \fRimdir\fR. +Also, since IMFORT is a host level facility and IRAF networking is +not supported, the network prefix (e.g., "node!") is omitted from the +pixelfile pathname, and since IMFORT programs are not necessarily used +in conjunction with IRAF, the "\fR..\fR" (hidden file protection) files +are not used to protect against image deletion. +.NH 3 +Image display interface: IMD + + A new interface IMD has been added to provide a rudimentary facility for +interactive image display device control. This is an interim prototype +interface which will be replaced by the new display interfaces when the +latter become available. + +The IMD interface operates by mapping an image display device frame buffer +onto an IMIO image descriptor. The display frame buffer may then be randomly +edited by normal image i/o operations, e.g., to modify subrasters of the +displayed image, or overlay the image with color graphics. The image pixel +to display frame buffer coordinate transformation is supported, allowing +applications to work in image pixel coordinates if desired. This interim +interface is what is used by the new display oriented tasks \fRimexamine\fR, +\fRimedit\fR, and \fRtvmark\fR. +.NH 3 +Image masks: PLIO, PMIO, MIO + + The following new VOS interfaces have been added in V2.8 to provide a +general boolean or integer image mask facility. +.sp +.nf + PLIO pixel list i/o + PMIO pixel (image) mask i/o + MIO masked image i/o (image i/o through a mask) +.fi +.sp + +PLIO is a general interface for storing and manipulating +multidimensional integer valued rasters containing regions of +constant value (i.e., masks). The masks are stored in a highly +compressed form, the size of the compressed mask being a function +of the information content of the mask. Both pixel array and +range list i/o facilities are provided, as well as a set of general +boolean raster operators, e.g., to extract or insert subrasters, +AND or OR a source with a destination, do the same through a stencil, +draw regions of various kinds (point, line, box, circle, polygon), +and so on. See the \fRPLIO.hlp\fR file in the PLIO source directory +for further information. + +An interactive debug program (\fRplio$zzdebug.x\fR) is provided for +experimenting with masks. Note that PLIO is a stand alone interface +and is not tied in any way to IMIO, even though the data structure +operated upon is similar to an image matrix. + +PMIO is very similar to PLIO except that it is used to associate a +masks with an IMIO maintained reference image. Currently, the PMIO +mask must be the same resolution as the physical reference image. +All coordinates input to PMIO are in the \fIimage section coordinates\fR +of the reference image. Hence, given a physical image and associated +mask, one can operate upon both through a user specified image section +transparently to the applications program. This includes all PLIO +style boolean rasterop operations, as well as mask pixel and range +list i/o. The PMIO interface is layered upon PLIO and IMIO, and the +calling sequences are identical with PLIO except for the package +prefix, and the addition of several new PMIO specific routines. + +MIO is essentially an extension of image i/o for pixel i/o through a +mask. The central routines are the following: +.sp +.nf + \fR mio_setrange (mp, vs, ve, ndim) + n|EOF = mio_[gp]lseg[silrdx] (mp, ptr, mval, v, npix)\fR +.fi +.sp +One defines a rectangular region of the image with mio_setrange, +and then sequentially reads or writes line segments until all pixels +visible through the mask have been accessed. This type of i/o should +be ideal for most image processing applications which need to operate +upon only those pixels visible through a region mask (e.g., a surface +fitting task), upon all pixels except those on a bad pixel mask (e.g., +any analysis program), and so on. + +PLIO (or PMIO) masks may be stored in binary files on disk, the files +having the extension "\fR.pl\fR". The V2.8 version of IMIO has the +capability to treat such masks as if they were images, allowing masks +to be easily displayed, used in image expressions, converted to +image matrices and vice versa, etc. Applications may do either pixel +or \fIrange list i/o\fR to a mask image via IMIO, if MIO is not suitable +for some reason. +.NH 3 +Photon images: QPOE, QPIO, QPEX + + A new set of VOS interfaces supporting photon or \fBevent list data\fR +are now available. The QPOE interface implements the Position Ordered Event +list object, which consists of a general header mechanism plus an +event list, wherein the events are little data structures, e.g., +the attributes required to describe a photon detection (position, +energy, time, etc.). QPOE is designed to efficiently access very large +event lists, e.g., several hundred thousand or several million events in size. +Builtin event attribute filtering and region filtering capabilities are +provided for selecting photons from the event list. These filtering +capabilities may be combined with the sampling capability to produce +filtered, block averaged image matrices from event lists. + +The QPOE interfaces are the following: +.sp +.nf + QPOE header and file access and management facilities + QPIO raw and filtered event i/o + QPEX event attribute filter mechanism + QPF IMIO/IKI kernel for image interface to QPOE files +.fi +.sp +QPOE and QPF add a new image type to the system, with \fR.qp\fR file +extension. Hence, event list data can be used as input to any of the image +processing tasks in standard IRAF, in addition to being analyzed by tasks +which deal with the individual photon events. A QPOE image is contained in +a single file. When a QPOE file is accessed as an image the interface +filters and samples the event list in real time, using a user defined filter, +block averaging factor, region mask, and so on, producing the image matrix +seen by applications at the IMIO level. The QPOE object may be repeatedly +examined with different event filters to view the data in different ways. + +The QPOE interface, in addition to providing an event list capability for +IRAF, serves as a prototype for the "flex-header" portion of the new image +structures project. Many of the capabilities to be provided for image +storage under the new image structures are already present in QPOE. + +Further information is given in the \fRQPOE.hlp\fR file in the QPOE +source directory. +.NH 3 +File manager: FMIO + + A new VOS library FMIO has been installed. FMIO is "File Manager I/O", +and is used to implement a simple binary file manager which maintains the +file data of so-called "lfiles" (lightweight files) inside a single +host binary file. The system overhead for accessing lfiles is much +less than that of host files, and many lfiles can be used to store +a complex data structure without cluttering a host directory or +incurring the inefficiency of accessing host files. FMIO is part of +the DFIO project and will serve as the lowest level interface within +DFIO; it is also used currently in the QPOE interface. Additional +information is given in the README file in the source directory for +the interface. +.NH 3 +IMIO changes + + IMIO is the image i/o interface, the standard IRAF VOS interface for +managing all varieties of image data. +.NH 4 +Mask image support + + IMIO now supports a new type of image, the \fBmask image\fR, stored as a +highly compressed binary (PLIO) file with the extension "\fR.pl\fR". +Image masks are most commonly used to store information describing selected +pixels in an associated data image. An image mask is logically a boolean +or integer image, up to 28 bits deep, containing information only on selected +pixels or regions of pixels. Masks are stored in highly compressed format, +e.g., a simple mask may be stored in only a few hundred bytes of space. +Mask images are readable, writable, and randomly modifiable, like ordinary +raster images. See \(sc2.4.3 for more information. +.NH 4 +Photon image support + + Support has also been added to IMIO for \fBevent list images\fR, stored +as position ordered event list datafiles using the QPOE interfaces. +This new image type has the extension "\fR.qp\fR". QPOE images are +read-only under IMIO. Subject to that restriction, they may be accessed +like any other image by any IRAF image analysis program. Accessing an +event list image as a raster image necessarily involves a runtime sampling +operation, wherein the events in the region of interest are accumulated +into an initially zero image matrix; in the process the event list may +optionally be filtered by event attribute or event position, e.g., +.sp +.nf + \fRcl> display "xray.qp[t=(30:40),pha=10,block=4]"\fR +.fi +.sp +would display the QPOE image \fRxray.qp\fR with a blocking factor of 4, +selecting only those events with \fRt\fR (time) in the range 30 to 40 and +for which \fRpha\fR (energy) has the value 10. The event attributes and +their names are user definable and may vary for different types of data. +See \(sc2.4.4 for more information. +.NH 4 +IMPUTH + + A new procedure \fRimputh\fR has been added to the IMIO header access +library. The new procedure is used to append FITS like HISTORY or COMMENT +cards to the image header. +.NH 4 +IMPARSE + + The calling sequence of the internal IMIO procedure \fRimparse\fR has +changed. Although this procedure is internal to the IMIO interface and is +not supposed to be used within applications, there may be applications which +make use of this procedure. Any such applications must be modified to +reflect the new procedure calling sequence or runtime problems are guaranteed. +.NH 3 +Null string environment variables + + The semantics of the VOS procedures \fRenvgets\fR and \fRenvfind\fR +have changed. This could affect existing programs and any programs which +use these functions should be checked to make certain they will still work +properly. + +These procedures, used to fetch the string values of environment variables, +return the length of the output string as the function value. +Formerly, a value of zero would be returned +both when the named variable existed but had a null string value, and when +the variable was not found. This made it impossible to discriminate between +the case of a variable not being defined, and one which is defined but has +a null value. The routines have been changed to return the value ERR (a +negative integer) if the variable is not defined. Programs which do not +wish to make the distinction between undefined and null-valued should check +for a function value less than or equal to zero. Programs which check for +a function value equal to zero will fail if the named variable is not defined. +.NH 3 +Environment substitution in filenames + + The VOS filename mapping code has been modified to add support a powerful +new environment substitution syntax. Previously the only environment +substitution mechanism available was the logical directory facility, which +could only be used to parameterize the directory field. The new facility may +be used to perform environment substitution anywhere in a filename. This is +used in IRAF version 2.8 to implement multiple architecture support, e.g., +.sp +.nf + \fRcl> set bin = "iraf$bin(arch)/"\fR +.fi +.sp +is how the core system BIN is defined in V2.8 IRAF. +The syntax "\fR(arch)\fR" tells the filename mapping code to substitute +the string value of the environment variable \fRarch\fR, if defined. +If the variable is not defined the null string is substituted. Hence, +if the host system does not implement multiple architecture support and +\fRarch\fR is not defined, BIN is defined as "\fRiraf$bin/\fR", +which is the backwards compatible definition. If \fRarch\fR is defined +as, e.g., "\fR.vax\fR", then BIN is defined as "\fRiraf$bin.vax/\fR". +The new feature allows use of a single environment variable to define +the architecture, not only to form filenames, but for other purposes as +well, e.g., to generate compiler switches or to control library searching +in \fRmkpkg\fR. +.NH 3 +Nonblocking raw terminal i/o + + The VOS file i/o interfaces have been modified to add support for +nonblocking terminal i/o. This facility makes it possible to, in effect, +"poll" the terminal to see if there is any input waiting to be read, to +allow interaction without having a program block if the user has not typed +anything. + +The immediate application of this in version 2.8 was the modification +of the \fRstty\fR (set-terminal) facility to implement a time out for +the terminal size query. Formerly, \fRstty\fR would hang up indefinitely +when the terminal type was set to "gterm" but the actual terminal was +something different, causing the screen size query to be ignored. + +In the more general case, nonblocking terminal i/o makes possible a new +class of user interface, which is not only interactive, but \fBevent driven\fR. +Nonblocking i/o makes it possible for an application to be continually +processing, while checking the terminal occasionally to see if the user +has input any commands. + +At present, nonblocking i/o is always used in conjunction with raw mode +input from a terminal. A new flag \fRF_NDELAY\fR, +defined in \fR\fR, is used to enable or disable nonblocking i/o. +For example, +.sp +.nf + \fRcall fseti (fd, F_RAW, YES)\fR +.fi +.sp +enables conventional blocking, single character raw mode reads, and +.sp +.nf + \fRcall fseti (fd, F_RAW, YES + F_NDELAY)\fR +.fi +.sp +enables nonblocking raw mode input (\fRYES\fR, \fRNO\fR, +and \fRF_NDELAY\fR are bit flags). These modes are mutually exclusive, +e.g., the first call may be issued while nonblocking raw mode is in effect +to make the reads block, and vice versa. A call to \fRfset(fd,F_RAW,NO)\fR +disables both raw mode and nonblocking mode. Once nonblocking raw mode is +in effect one merely reads characters from the terminal in the usual way, +using \fRgetc\fR. EOF is returned if a read is performed when no data +is available for input, otherwise the next character is returned from the +input queue. Further information on nonblocking i/o is given in the system +notes file. +.NH 3 +Function call tables (ZFUNC) + + IRAF has always had the ability to compute the integer valued address of a +procedure, store that address in a table, and later use the address as an +argument to one of the \fRzcall\fR kernel primitives to call the addressed +procedure. This facility has been extended by the addition of a set of +\fRzfunc\fR primitives, used to call integer valued \fIfunctions\fR. +Only integer valued functions are supported (in order to simplify the kernel +support required), but in the systems oriented applications where procedure +call tables are used, this is unlikely to be a serious limitation. + +.NH 2 +Sun/IRAF specific revisions +.NH 3 +IEEE exception handling + + By default the IEEE hardware is now configured, on all Sun systems, +with the invalid, overflow, and divide by zero IEEE exceptions enabled, +and with the default rounding direction and precision modes (nearest, +extended) in effect. This configuration should ensure that all +questionable floating point operations are detected, and that no IEEE +"funny numbers" (NaN, Inf, etc.) get into the data. These values, +since they don't behave like ordinary numbers, can cause programs +to misbehave, e.g., go into an infinite loop. In Sun/IRAF V2.8, +if a computation results in an IEEE funny number being generated, +an exception abort will result. The most common example is divide by zero. + +The IRAF/IEEE interface offers a special debug feature that may be of +interest to programmers developing numerically sensitive software. +If desired, one can change the default rounding direction and +precision (e.g., to test the numerical stability of applications) +by using the debugger to set a nonzero value of the variable +\fRdebug_ieee\fR before running an executable. The procedure for +doing this is documented in the system notes file. +.NH 3 +IMTOOL enhancements + + A number of enhancements and bug fixes have been made for V2.8 to the +SunView based IMTOOL image display server. The most notable changes are +summarized here; refer to the IMTOOL manual page for a more complete +description of the new features. +.NH 4 +Software ZOOM added + + IMTOOL, which has had for some time the ability to pan about on a large +image, now has the ability to zoom as well. Both pan and zoom are controlled +very conveniently by the middle mouse button: place the mouse on an object +and tape the middle button once to pan the object to the center of the +display window; tap it again and the image will be zoomed. Zoom, currently +implemented by writing directly into the hardware frame buffer, is very fast, +almost as fast as a normal unzoomed window refresh. The default set of zoom +factors is 1,2,4,8 after which the sequence wraps around to 1. The zoom +factors are user configurable via the IMTOOL setup panel; very large zoom +factors, e.g., x64, are possible. Dezoom (making a large image smaller) +is not currently supported. +.NH 4 +WCSDIR eliminated + + The host level \fRWCSDIR\fR environment variable, and the text file used +to communicate image coordinate (WCS) information between the display task +and the display server, have been eliminated. All WCS information is now +passed via the datastream used to pass commands and data between the client +and the display server. This eliminates the need for users to have to +remember to define \fRWCSDIR\fR in order to get coordinates in image units, +and some subtle process synchronization problems are eliminated as well. + +In a related change, the frame buffer configuration index is no longer +passed in during a frame erase, hence it is no longer necessary to erase a +frame before displaying an image to ensure that a frame buffer configuration +change is passed to the server. The configuration index is now passed when +the WCS information for a frame is set. +.NH 4 +Graphics colors + + IMTOOL now allocates a range of pixel values for use as graphics overlay +colors. Setting a frame buffer pixel to one of these values causes it to +always be displayed with the assigned color. The graphics color values are +not affected by windowing the display. The most common use of graphics +colors with V2.8 IRAF is for drawing graphics into a displayed frame with +the new \fRtvmark\fR task, available in PROTO. See the IMTOOL manpage +for a table listing the color index assignments. +.NH 4 +New imtoolrc entries + + Several new predefined frame buffer configurations have been added to the +default \fRimtoolrc\fR. These include an 128 pixel square frame buffer +(\fRimt128\fR), a 256 pixel square frame buffer (\fRimt256\fR), +and a full screen display with the same aspect ratio as a 35 mm slide +(\fRimtfs35\fR). +.NH 4 +System crash (FIFO) bug fixed + + Versions of SunOS through at least 4.0.1 have a bug in the FIFO driver code +which can cause the internal kernel FIFO data buffer to be deallocated while +it is still in use. This will result in a bad kernel which will eventually +panic and reboot the system. This is the cause of the IMTOOL crash problem +which some sites may have experienced. IMTOOL has been modified to avoid +the circumstances (repeated 4096 byte transfers) which cause the bug to +surface. So far as we know, the real bug (in SunOS) has not yet been fixed, +but at least on the NOAO systems, the frequency of occurrence of the system +crashes is greatly reduced with the new version of IMTOOL which incorporates +the workaround for the SunOS bug. +.NH 4 +Cursor marking now disabled by default + + When the interactive image cursor read facility was first added to IMTOOL, +the default response to each cursor read was to draw a small white dot at +the position of the cursor. This is convenient when marking a series of +objects to make a list, but with the increasing number of IRAF programs +making user of the interactive image cursor, it has been necessary to change +the default to disable automatic marking of each cursor read. The cursor +mark feature is still available as an option and can be enabled via the +setup panel. +.NH 4 +Ctrl/b may be used for manual blinking + + In addition to the list of blink frames and the timed blink feature IMTOOL +has provided for some time, it is now possible to manually cycle through +the blink frames with the key. Typing while the mouse +is in the image window will cause the display to display the next blink +frame in sequence. +.NH 4 +F4 key will now toggle setup panel + + The F4 function key on the Sun keyboard may now be used to toggle whether +or not the setup panel is displayed. This provides a single keystroke +alternative to calling up the setup panel with the frame menu. + +.NH 2 +VMS/IRAF specific revisions +.NH 3 +NEWUISDISP added to VMS/IRAF + + Nigel Sharp's \fRNEWUISDISP\fR display program, used for image display +under UIS on microvaxes with bitmapped displays, is now available in the +standard VMS/IRAF release, in the directory \fR[IRAF.VMS.UIS]\fR. +.NH 3 +New INSTALL.COM script + + A new \fRINSTALL.COM\fR script (also written by Nigel Sharp) has been +added to VMS/IRAF. This script, run by the system manager to install +selected IRAF executable images, will now automatically check for and +deinstall any old versions of the executables before installing the new ones. +.NH 3 +VMS 4.7/5.0 + + Testing of the standard V2.8 VMS/IRAF release, which was prepared on VMS +4.7, on a VMS 5.0 system has thus far not revealed any problems (NOAO is still +running VMS 4.7 as our standard system). Hence it appears that the standard +V2.8 VMS/IRAF will \fIrun\fR under VMS 5. It is likely, however, that any +attempt to \fIrecompile\fR VMS/IRAF under VMS 5 would cause problems, +since we have not yet tried to rebuild IRAF under VMS 5, and such a major +operating system upgrade will often require changes to the IRAF code. +The system may be relinked under VMS 5 if desired, and this does not appear +to cause any problems, but neither does there appear to be any benefit to +be gained from doing so. + +.NH 2 +Summary of IRAF System Packages Revisions +.sp +.ls 4 o +The tasks RFITS and WFITS in the DATAIO package now support the +reading and writing of arbitrary sized data blocks (IRAF version 2.7 +and later). +.le +.ls 4 o +Several new tasks were added to the IMAGES package. IMCOMBINE (IRAF +version 2.6 and later) provides for the combining of images by a number +of algorithms. The new task CHPIXTYPE (IRAF version 2.7 and later) +changes the pixel types of a list of input images. The task IMSLICE +slices images into images of one less dimension (IRAF version 2.8). +The task IMSTACK has been moved into the IMAGES package (although it +still resides in PROTO as well). + +The IMSTATISTICS task has been rewritten and now allows the user to select +which statistical parameters to compute and print (IRAF version 2.8). +The IMRENAME task has been modified to allow "in place" image renames, +used chiefly for moving the pixel files to a new IMDIR. + +Several other tasks in the IMAGES package were modified (IRAF +version 2.8). IMSHIFT was modified to accept a list of shifts from +a file. REGISTER and GEOTRAN were modified to accept a list of +transforms instead of only a single one. IMHISTOGRAM has undergone +extensive revision including support for "box" type plots, support +for linear or log scaling in the y coordinate, as well as support +for antialiasing of the histogram bins. +.le +.ls 4 o +All the tasks in the IMAGES.TV package were modified (IRAF version 2.8) +so that if a task +is used with an unsupported display device a message is printed +to that effect. +.le +.ls 4 o +The STTY task in the LANGUAGE package has been improved (IRAF version 2.6 +and later) to better +facilitate its "playback" feature. These changes have been documented +in the online help for the task. This feature is little used by +external sites but can be a very useful instructional aid if users +are aware of its capability. +.le +.ls 4 o +A new task PVECTOR was added to the PLOT package that allows one to +plot an arbitrary vector in a two dimensional image (IRAF version 2.6 +and later). + +The task STDPLOT was modified (IRAF version 2.8) +so that it uses the more popular SGI kernel +rather than the NSPP (NCAR) kernel (STDPLOT is now +equivalent to the SGIKERN task). +A new task NSPPKERN was added that uses the NSPP kernel. +.le +.ls 4 o +Two new tasks were added to the SYSTEM package (IRAF version 2.8). +The task DEVICES simply prints the \fRdev$devices.hlp\fR file as edited +by the site manager listing available devices on the local host or +network. The REFERENCES task is used to search the help database +for all tasks or other help modules pertaining to a given topic, +e.g., \fRreferences vector\fR will list all tasks that have the string +"vector" in their one line description. +.NH 2 +Glossary of New Tasks in the IRAF System Packages + \fR +.nf +\fITask\fR \fIPackage\fR \fIDescription\fR + +chpixtype images Change the pixel type of a list of images +devices system Print information on the locally available devices +imcombine images Combine images pixel-by-pixel using various algorithms +imslice images Slice images into images of lower dimension +imstack images Stack images into a single image of higher dimension +nsppkern plot Plot metacode on a NSPP (NCAR) plotter device +pvector plot Plot an arbitrary vector in a 2D image +references system Find all help database references for a given topic +.fi + +In addition, there are new image display oriented tasks \fRimexamine\fR, +\fRimedit\fR, and \fRtvmark\fR in the PROTO package in NOAO (used to +interactively examine and edit images, or draw graphics into image display +frames). These really belong in the core system but have been placed in +\fRnoao.proto\fR since they are prototype tasks. + +.NH +NOAO Package Revisions + + Some of the major revisions to the NOAO packages are listed below. +.NH 2 +Summary of NOAO Packages Revisions +.NH 3 +New NOAO Packages + + Several new packages have been added to the NOAO suite of packages. +.le +.ls 4 o +The APPHOT package is a set of tasks for performing aperture photometry +on uncrowded or moderately crowded stellar fields in either interactive +or batch mode. +This package is now installed in the DIGIPHOT package (IRAF +version 2.7 and later). The APPHOT package was available as an add-on +package to IRAF version 2.5 and later while it was undergoing alpha +testing. Many new features have been added to the package +since it first became available including +the new task QPHOT (quick aperture photometry) and interaction with +the image display cursor for supported image displays +(Sun workstation, IIS model 70). +.le +.ls 4 o +The CCDRED package provides tools for the easy and efficient reduction +of CCD images. +This package has been installed in the IMRED package (IRAF version +2.6 and later). The CCDRED package was also available as an add-on to +IRAF version 2.5. + +A short demonstration of many of the tasks in the CCDRED package is +provided with the DEMO task in the CCDRED.CCDTEST package. +.le +.ls 4 o +The IMRED.ECHELLE package has been replaced with a more +sophisticated collection of tasks for reducing echelle type data (IRAF +version 2.7 and later). The new ECHELLE package recognizes a new +image format in which each extracted echelle order +becomes a line in a two dimensional image rather than having a separate one +dimensional spectrum for each order, although this old output format is still +available as an option. +Several +new tasks exist for computing and applying a wavelength calibration +to the data using the echelle relationship between the orders +(ECIDENTIFY, ECREIDENTIFY, and ECDISPCOR) as well +as for manipulating the new echelle format (ECSELECT, +ECCONTINUUM, and ECBPLOT). +.le +.ls 4 o +The IRRED package has been added to the IMRED package. The IRRED +package collects together in one place those tasks used most frequently +by users reducing IR data such as that taken with the IR imager at KPNO. +The IRMOSAIC and IRALIGN tasks were available +with IRAF version 2.6 and later. +IRMOSAIC takes an ordered list of input images and places them on a grid +in an output image. IRALIGN uses this grid and a coordinate list of +overlapping objects from the individual subrasters to produce an +aligned output image. The tasks IRMATCH1D and IRMATCH2D were available +with IRAF version 2.7 and later. These tasks are similar to IRALIGN +expect that the intensities of adjacent subrasters can be matched as well. +A script called MOSPROC (IRAF version 2.8) has also been +added that prepares a list of images for a quick look mosaic. +.le +.ls 4 o +The MSRED package has been added to the IMRED package. The MSRED +package is a collection of tasks used for reducing multispectral types +of data, e.g. fiber arrays, where the individual spectra are for different +objects. Like the ECHELLE package, it also has its +own multispectral image format (a two dimensional image in which each line +is an extracted spectrum). Several new tasks have been added to the +package for wavelength calibration of multispectral data. +.NH 3 +Modifications to Existing NOAO Packages +.sp +.le +.ls 4 o +The ASTUTIL package was reorganized (IRAF version 2.6 and later - see +IRAF Newsletter No. 3 for details) and several tasks were added and/or +modified. A new task ASTTIMES computes and prints astronomical dates +and times given a local date and time. A new task RVCORRECT computes +and prints radial velocity corrections for an observation. The +tasks PRECESS and GALACTIC were modified slightly using different but +more accurate algorithms. + +The new task SETAIRMASS (IRAF version 2.8) +computes the effective airmass and middle UT of an exposure. +This task was also made available in the TWODSPEC and IMRED +packages. +.le +.ls 4 o +The two tasks in the IMRED.BIAS package, COLBIAS and LINEBIAS, +were modified slightly (IRAF version 2.7 and later) so that +the fitting parameters for the overscan region can be set by the user +as hidden parameters to the tasks. +.le +.ls 4 o +The task COSMICRAYS (from the CCDRED package) was made available in the +IMRED.GENERIC package (IRAF version 2.6 and later). +.le +.ls 4 o +A new task called SYNDICO has been added to the IMRED.VTEL +package (IRAF version 2.6 and later). SYNDICO makes glossy prints on the +NOAO Dicomed printer of the synoptic, full disk, magnetograms and +spectroheliograms taken at the vacuum telescope at Kitt Peak. +.le +.ls 4 o +Modifications were made to the IMRED.DTOI package. These changes +have been documented in IRAF Newsletter No. 4. +.le +.ls 4 o +Three new tasks in the ONEDSPEC package, REFSPECTRA, SEXTRACT, +and SPECPLOT, were +made available in the IMRED.COUDE, IMRED.IIDS, IMRED.IRS, and IMRED.SPECPHOT +packages. +.le +.ls 4 o +Many new tasks and features have been added to the ONEDSPEC package. + +The SENSFUNC task was completely rewritten (IRAF version 2.6 and later) +to allow determination of extinction, display of flux calibrated spectra, +and many new features for displaying and manipulating the data. + +IDENTIFY, REIDENTIFY and DISPCOR were modified (IRAF version 2.6 and later) +so that a dispersion solution from IDENTIFY could be shifted without +changing the original shape of the coordinate function (see IRAF +Newsletter No. 3 for details). + +A new deblending algorithm was added to SPLOT (IRAF version 2.7 and later). +See the online help for SPLOT as well as the article in IRAF Newsletter +No. 4. + +The tasks in the ONEDSPEC.ONEDUTIL package were absorbed into +the ONEDSPEC package (IRAF version 2.7 and later). + +The EXTINCT task disappeared with its +functionality being taken over by a rewritten CALIBRATE (IRAF version 2.7 +and later). + +The COEFS +task was moved to the IMRED.IIDS and IMRED.IRS packages since this is +a very instrument specific task (IRAF version 2.7 and later). + +Three new tasks were added to the package. SEXTRACT (IRAF version 2.6 +and later) extracts subspectra from one dimensional input spectra. +REFSPECTRA (IRAF version 2.7 and later) takes over part of the functionality +of the old DISPCOR task and allows the user to define which arc spectra +are to be used in the calculation of the dispersion solution of object +spectra. SPECPLOT (IRAF version 2.8) is a new plotting task that allows +the compression of many spectra to a page (see IRAF Newsletter No. 6). +.le +.ls 4 o +Several new tasks have been added to the PROTO package. + +Four tasks were added to IRAF version 2.6 and later. BSCALE is a task that +can be used to linearly scale images by the mean, average, or mode of the +image. IRMOSAIC and IRALIGN can be used to combine many frames into one +large image. These three tasks are also available in the IMRED.IRRED package. +MKHISTOGRAM calculates the histogram of the data in a text file. + +Three new tasks were added to IRAF version 2.7 and later. IMSLICE is a +task that slices an image into images of lower dimension. IRMATCH1D +and IRMATCH2D are two tasks that allow combining of many overlapping images +while matching the background intensities in two different ways. + +Three new tasks have been added to IRAF version 2.8 that allow the user +to interact with the image display (for supported display devices, ie +Sun workstation, IIS model 70). IMEXAMINE allows the user to interactively +examine portions of the displayed image. TVMARK allows the user to +mark objects on the image display. IMEDIT allows the user to interactively +edit an image. +.le +.ls 4 o +The APEXTRACT package in the TWODSPEC package has had several rounds +of modifications, as discussed in the IRAF Newsletters, No. 3 and 4. +These changes included improved techniques and additional options +for the extraction of data. + +A new task, APSCATTER, has been added to the package (IRAF version 2.8). +This task determines and subtracts scattered light from two dimensional +aperture or echelle spectra. The task was also made available +from within the ECHELLE package. This task was discussed in +IRAF Newsletter No. 6. +.NH 2 +Modifications and Additions to Calibration Data + + The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory +called ONEDSTDS in \fRnoao$lib\fR. The current contents of this directory +are best summarized by paging through its README file, e.g., +.sp +.nf + \fRcl> page noao$lib/onedstds/README\fR +.fi +.sp + +Two additional line lists (used by IDENTIFY) have been added to this directory +(IRAF version 2.8). +These lists, \fRvacidhenear.dat\fR and \fRvacthorium.dat\fR, +are simply the standard \fR.dat\fR files in air wavelengths +converted to vacuum wavelengths. The equation used for the +conversion as well as the appropriate reference in the literature +are contained in the README file. + +The \fRthorium.dat\fR file has been updated to contain thorium +lines from 3180 Angstroms +to 9540 Angstroms (IRAF version 2.6 and later). Please see the README +file for the source. + +Two new directories have been added containing flux information for +standard stars (IRAF version 2.6 and later): SPECHAYESCAL and SPEC50CAL. +Both of these lists are from Massey et al., 1988, Ap. J., Vol. 328, p. 315. +.NH 2 +Glossary of New Tasks in the NOAO Packages + +.nf +\fITask\fR \fIPackage\fR \fIDescription\fR + +apscatter(1) apextract Fit and subtract scattered light +apselect apphot Extract select fields from apphot output files +asttimes astutil Compute UT, Julian day, epoch, and sidereal time +badpiximage ccdred Create a bad pixel mask image from a bad pixel file +bscale(3) proto Brightness scale images: new = (old-bzero) / bscale +ccdgeometry ccdred Discussion of CCD coordinate/geometry keywords +ccdgroups ccdred Group CCD images into image lists +ccdhedit ccdred CCD image header editor +ccdlist ccdred List CCD processing information +ccdproc ccdred Process CCD images +ccdred ccdred CCD image reduction package +ccdtypes ccdred Description of the CCD image types +center(3) apphot Compute accurate centers for a list of objects +centerpars(3) apphot Edit the centering parameters +combine ccdred Combine CCD images +cosmicrays(4) ccdred Detect and replace cosmic rays +daofind apphot Find stars in an image using the DAO algorithm +darkcombine ccdred Combine and process dark count images +datapars(3) apphot Edit the data dependent parameters +demo ccdtest Run a demonstration of the CCD reduction package +ecbplot echelle Batch plots of echelle spectra +eccontinuum echelle Fit the continuum of echelle spectra +ecdispcor echelle Dispersion correct spectra +ecidentify echelle Identify features in spectrum for dispersion solution +ecreidentify echelle Automatically reidentify features in spectra +ecselect echelle Select and extract apertures from echelle spectra +fitpsf apphot Model the stellar psf with an analytic function +fitsky apphot Compute sky values in a list of regions +fitskypars apphot Edit the sky fitting parameters +flatcombine ccdred Combine and process flat field images +flatfields ccdred Discussion of CCD flat field calibrations +guide ccdred Introductory guide to using the CCDRED package +imedit proto Examine and edit pixels in images +imexamine proto Examine images using image display, graphics, and text +imslice proto Slice images into images of lower dimension +instruments ccdred Instrument specific data files +iralign(3) proto Align the mosaiced image produced by irmosaic +irmatch1d(3) proto Align and intensity match image produced by irmosaic +irmatch2d(3) proto Align and intensity match image produced by irmosaic +irmosaic(3) proto Mosaic an ordered list of images onto a grid +mkfringecor ccdred Make fringe correction images from sky images +mkhistogram proto List or plot the histogram of a data stream +mkillumcor ccdred Make flat field iillumination correction images +mkillumflat ccdred Make iillumination corrected flat fields +mkimage ccdtest Make or modify an image with simple values +mkskycor ccdred Make sky iillumination correction images +mkskyflat ccdred Make sky corrected flat field images +mosproc irred Prepare images for quick look mosaicing +msdispcor msred Dispersion correct spectra +msreidentify msred Reidentify features from/to a multispec image +msselect msred Select and extract apertures from spectra +observe ccdtest Create an artificial CCD observation +phot apphot Measure magnitudes for a list of stars +photpars apphot Edit the photometry parameters +polymark apphot Create polygon lists for polyphot +polypars apphot Edit the polyphot parameters +polyphot apphot Measure magnitudes inside a list of polygonal regions +qphot apphot Measure quick magnitudes for a list of stars +radprof apphot Compute the stellar radial profile of a list of stars +refspectra(5) onedspec Assign wavelength reference spectra to other spectra +rvcorrect astutil Compute radial velocity corrections +setairmass(6) astutil Compute effective airmass for an exposure +setinstrument ccdred Set instrument parameters +sextract(2) onedspec Extract subspectra from dispersion corrected spectra +specplot(5) onedspec Stack and plot multiple spectra +subsection ccdtest Create an artificial subsection CCD observation +subsets ccdred Description of CCD subsets +syndico vtel Make dicomed print of daily grams 18 cm across +tvmark proto Mark objects on the image display +wphot apphot Measure magnitudes for a list of stars with weighting +zerocombine ccdred Combine and process zero level images +.fi +.sp + +Notes: +.le +.ls 4 (1) +Tasks also in echelle and msred packages. +.le +.ls 4 (2) +Tasks also in coude, iids, irs, and specphot packages. +.le +.ls 4 (3) +Tasks also in irred package. +.le +.ls 4 (4) +Tasks also in generic package. +.le +.ls 4 (5) +Tasks also in coude, echelle, iids, irs, msred, and specphot packages. +.le +.ls 4 (6) +Tasks also in imred and twodspec packages. +.endhelp diff --git a/doc/doc/notes.v28 b/doc/doc/notes.v28 new file mode 100644 index 00000000..e5430247 --- /dev/null +++ b/doc/doc/notes.v28 @@ -0,0 +1,3849 @@ +System Notes File for IRAF Version 2.8. +Begun 4 December 1988. +------------------------------------------- + +local/bugs.log +local/notes.v28 +doc/notes.v27 +unix/hlib/buglog.csh +unix/hlib/motd +unix/hlib/zzsetenv.def + 1. Incremented the system version number to V2.8ALPHA. + 2. Moved the `notes.v26' file to doc/notes.v27. + 3. Set up a new system notes file `notes.v28' for V2.8. + 4. Renamed the bugs file to `bugs.log' since it is versionless. + (12/4) + +vms/os/zgcmdl.c + The "len" variable, input by address to lib$get_foreign, was declared + as an int whereas lib$get_foreign wanted a word pointer. The library + routine would set only 16 bits of the int, so if the other word + (allocated dynamically on the stack) happened to have anything in it, + a nonsense string length would be seen in the "line[len] = EOS" + statement, causing a segmentation violation. For some reason this + bug did not show up until we rebuilt the V2.7 VMS/IRAF system, but + it has been there all along. + + I fixed this in V2.8 (IRAFX), as well as in the "frozen" (almost) V2.7 + system. Any IMFORT programs linked since V2.7 was released should be + relinked. I will also regenerate the V2.7 shared library. Although + IMFORT programs do not use the shared library and no IRAF programs + use ZGCMDL, we would like to have the correct version in the shared + library. (12/7) + +dev/edt.ed +dev/emacs.ed + Changed the EDITOR_CMD entries for emacs and edt from "irafemacs" and + "irafedt" to "emacs" and "edt". Note that these are only default + command names, and different naems might have to be substituted + depending upon how the host editors are set up on various systems. + (12/13) + +dev/devices.hlp + +pkg/language/language.hd +pkg/language/language.men + Added a new help keyword "devices". Typing + + cl> help devices + + causes information on the devices available on the local host or + network to be printed. This information is contained in the file + dev$devices.hlp. (12/15) + +unix/hlib/libc/knames.h +vms/hlib/libc/knames.h + Added an entry for ACLRB, which name is used in OSB (aclrb.c), but + which was previously undefined, causing the name to appear in upper + case in libraries (at least on the unix systems). (12/20) + +------------------------- +Log of changes for the Sun/IRAF shared library facility. This was developed +on the 386i initially. This log was written on 28 December and summarizes the +revisions made during the period Tue 20 Dec to Wed 28 Dec 1988. + +[background] + Although SunOS 4.0 supports dynamic linking, mapped files, and shared + libraries, currently only the C compiler can generate position + independent code (PIC). Sun Fortran does not currently support shared + libraries since it cannot yet generate PIC code. In any case, PIC + code executes less efficiently than nonrelocatable code, and the + dynamic linking required by relocatable shared libraries slows down + process startup. + + Our strategy is to implement the equivalent of a shared library by + building a *nonrelocatable* shareable image (executable process), + and mapping it to a fixed address in the address space of client + processes at process startup time. A transfer vector is used to + vector procedure calls to arbitrary offsets in the shared image, + allowing new shared images to be installed without having to relink + client processes (in most cases). The mapped file feature of SunOS + 4.0 is the only thing essential for this scheme to work, and it is + the lack of the mapped file capability which has prevented us from + implementing a shared library up until now. + + Even when (and if) Sun/Fortran eventually adds support for PIC and + shared libraries, the mapped image approach we have followed here + may still be the best choice. Despite the slight loss of execution + efficiency caused by the use of position independent code, use of + PIC is not likely to be a serious drawback. More serious drawbacks + derive from the use of global data, and dynamic linking at runtime. + Dynamic linking, e.g., to set the address of a global variable for + which the location is not known until runtime, requires the + modification of every text page containing code which references the + variable. Aside from the obvious time penalty during process startup + while this linking and page copying is taking place, modification of + a text page defeats shared text, increasing memory and paging + requirements. + + Trying to avoid this problem in a relocatable shared library can be + very difficult, requiring modification to source code if it can be + done at all. The nonrelocatable approach we have followed guarantees + sharing of the entire text of the shared image and does not require + any changes to system or applications source code (provided no + interfaces have been violated). There are other advantages which + derive from the facility being part of the Sun/IRAF HSI, e.g., if + iraf is linked on an NOAO node and later installed with a different + root on a remote node, there is no problem locating the shared library + at runtime. Furthermore, since our approach requires on the part of + the host system only the ability to map files to fixed addresses, + and the ability to specify the base address of the text segment of + an image at link time, it should be applicable to other (non-Sun) + systems which may provide these capabilities but not shared libraries. + +unix/as.i386/zsvjmp.s + After a little experimentation I found that the .SET assembler macro + could be used to set the value of absolute symbols. This allows MEM + to be located at virtual address 0, making shared libraries possible + for the 386i, and improving assembly level debugging as well. + +unix/shlib/README +unix/shlib/S.nm.i386 external names in 386i shared library +unix/shlib/S.nm.mc68020 external names in Sun-3 shared library +unix/shlib/S.ver.i386 386i shared library version number +unix/shlib/S.ver.mc68020 Sun-3 shared library version number +unix/shlib/Slib.c support code +unix/shlib/aout.c utility to decode a.out format process headers +unix/shlib/coff.c utility to decode COFF format process headers +unix/shlib/edsym.c called by XC to edit symbol table of .e file +unix/shlib/mkpkg mkpkg tie-in +unix/shlib/mkpkg.sh called to boostrap edsym.e +unix/shlib/mkshlib.csh script which does it all +unix/shlib/omit.i386 external names to be excluded from 386i shlib +unix/shlib/omit.mc68020 external names to be excluded from Sun-3 shlib + + This directory contains all the code needed to build and maintain the + shared library. The shell script mkshlib.csh, normally called via + the mkpkg, does all the work. This constructs a name list for the + shared library, generates the assembler required for the transfer + vector modules (V.s and S.s), and links the shared image (S.e). + + When building a new shared library, mkshlib checks to see if any + externals have been deleted from or added to the name list of the + old shared library. If any externals have been deleted, the version + number is incremented and any applications linked with the shared + library will have to be relinked. If there were no changes to the + name list or new externals have been added, then the version number + is not incremented, and existing applications are permitted to use + the new shared image without having to be relinked. The shared image + is linked -Bstatic, meaning that any required host library procedures + are bound at link time. + + Only Fortran or Fortran-like externals are permitted, i.e., exported + from the shared image to the client via the transfer vector. This is + necessary to permit clients to be linked -Bdyamic, allowing use of + the host system shared libraries (otherwise name conflicts would + occur at link time). + + The objects produced by the SHLIB code are libshare.a (the shared + library) and S.e (the shareable image), discussed further below. + +bin/S.e + + The shared image. This gets mapped into the address space of any + process linked with the shared library. It is also a runnable process + in its own right; if run directly, it prints out some information + about itself and exits. The full contents (minus the omitted + externals) of the EX, SYS, VOPS, and OS libraries are currently + linked into this image; other libraries may be added in the future, + e.g., some of the MATH libraries. The transfer vector module V.o, + located at a fixed (absolute) offset in the image, is used to vector + procedure calls from the client process into the shared image. + +lib/libshare.a + The shared library. This contains several object modules, including + a single object S.o consisting of a short header plus a name list + containing all the externals exported by the shared image. Each + external (i.e., VOS procedure such as 'clgeti' etc.) appears in S.o + as an absolute symbol, pointing to a fixed location in the transfer + vector in the shared image. Note that externals appear in S.o only + as symbols, hence no actual executable code gets linked into the + client process. To link with the shared library, XC links with + libshare.a instead of libex.a,libsys.a,libvops.a,libos.a. + +unix/os/zmain.c + The zmain is the main procedure for an iraf process. The first thing + the zmain does now is call ZZSTRT, which is described below. Some + code was moved out of the zmain into ZZSTRT, and all references to + global variables in the kernel had to be eliminated, since the zmain + is no longer linked with the kernel procedures (which are off in the + shared image). Other changes included the addition of calls to ZZSETK + to set the values of the kernel variables, and changes to the calling + sequence of IRAFMN to permit the address of SYSRUK and ONENTRY to be + passed in the argument list, rather than being bound at link time. + +unix/os/zzstrt.c + The function of this procedure, which has been a no-op in UNIX/IRAF + up until now, is to perform any runtime initialization of the kernel. + Currently, ZZSTRT maps and initializes the shared image, sets the + desired IEEE exceptions (partially implemented at present), sets the + process working set soft limits, and sets the default values of the + kernel variables via the new ZZSETK procedure. + + Mapping and initializing the shared image is similar to what unix + does during startup of a normal process. The shared image file is + opened, and the header is read to determine the sizes of the text, + data (initialized data), and bss (unitialized data) segments. + IRAF uses an additional shared image header segment containing the + file header and the FIO common (fiocom), which has to be directly + accessed by the client, making it necessary to locate it at a fixed + address in virtual memory. + + The header segment containing the FIO common is then mapped read-write + private, meaning that if any pages are modified the client gets a + private copy of the page. The text segment of the shared image is + mapped read-only shared. The data segment is mapped read-write + private; pages are shared until modified by the client at runtime. + The BSS segment is then mapped onto an arbitrary file offset (zero) + and promptly zeroed, causing all of the pages to belong to the client. + Finally, the addresses of the unix malloc, realloc, and free procedures + are passed into the shared image (dynamic memory allocation must be + in the data space of the client), and the environment pointer in the + shared image is set to point to the environment of the client, so that + the VOS will see the host environment and command line arguments seen + by the client. + + Both ZMAIN and ZZSTRT are linked directly into each client process, + since they are required to map in and initialize the shared image. + (S.e has its own private copies, of course). + +unix/os/zlocpr.c + ZLOCPR had to be modified to deal with the transfer vector. + The problem is that calls to ZLOCPR in the client image and in the + shared image must return the same value, since equality comparisons + of procedure entry points are used to determine, e.g., if a + particular file driver is referenced. ZLOCPR was modified to check + if the referenced procedure is actually a transfer vector entry, + returning the address of the actual procedure in the shared image + if so. Since this is a host level procedure, this is done by + disassembling the JMP instruction in the transfer vector. + +unix/os/zshlib.c + + This object contains everything needed to link a process against the + standard libraries, ignoring the shared library. Dummy shared image + descriptors and procedure entry points are defined so that the code + in ZMAIN and ZZSTRT will link properly. At runtime, the startup code + determines that the shared library is not in use, skipping the map and + initialize operations. + +unix/os/zzsetk.c + + This new kernel procedure is used to initialize the values of all the + global kernel variables formerly initialized via EXTERN references in + the zmain. A procedure (with transfer vector) must be used instead + of a series of global data references in order to be able to link + against the shared library. + +unix/boot/spp/xc.c + 1. XC was modified to link against the shared library by default. + The new switch -z (as in VMS/IRAF) is used to link without using + the shared library. Both the shared library and the shared image + may be in an IRAFULIB directory if desired. + + 2. If linking against the shared library, XC will by default call + EDSYM to edit the symbol table of the new executable, renaming the + symbols pointing to transfer vectors by prefixing a "V", and adding + new symbols to point into the shared image to the actual locations + of the VOS procedures referenced by the transfer vector. This provides + symbols for debugging executables that used the shared image. + + New XC switches: + + -e do not call edsym to do symbol editing + -s strip executable (UNIX linker switch; for XC, defeats + call to edsym). + + edsym switches (accepted by XC): + + -d print symbol table + -k do not delete "uninteresting" symbols + -n do not modify any files + -t omit transfer vector symbols to save some space + -T delete all symbols associated with the shared library + + 3. The -align switch, formerly passed to the 386i linker to page + align the MEM common, was deleted since MEM is now assigned to + location zero with a .SET. + +sys/etc/main.x +sys/etc/xmjbuf.x + + 1. The calling sequence of the iraf main was modified to add sys_runtask + (SYSRUK) and onentry (ONENTY) as arguments, allowing a runtime rather + than link time reference. This was necessary for the shared library + since SYSRUK and ONENTY are client symbols but are called by the iraf + main, which is in the shared image. The new scheme is more flexible + in any case. + 2. The new procedure XMJBUF is used to get an XCHAR pointer to the + zsvjmp/zdojmp context vector used by the iraf main for interrupt and + error recovery. Again, a runtime procedural reference using a pointer + is necessary since the global data area cannot be referenced at link + time. The CL uses both a custom onentry and a custom zdojmp context + vector in order to gain full control over command interpretation. + +unix/hlib/libc/libc.h +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + 1. In libc.h, the ZJUCOM reference was deleted since the XMJBUF + procedure is now used to access the interpreter context vector. + 2. Entries for the new VOS and kernel procedures were added to + [xk]names.h. + +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +mkpkg [at iraf root] + 1. The -z flag (no shared library) was added to the HSI_XF flags in + irafuser.csh, so that HSI executables will not use the shared image. + 2. The mkpkg.inc now includes a switch USE_SHLIB, which if set causes + mkpkg to automatically update the shared library and shared image + during a sysgen. This switch does not actually determine whether the + shared library is *used*, since that is determined by the -z switch + to XC at link time. + 3. For Sun/IRAF, the switch -/Bstatic was added to LFLAGS so that + the iraf executables will be statically linked, rather than using the + SunOS shared library (e.g., libc.a). This was not necessary - there + is no conflict between the iraf and SunOS shared libraries - but was + done to save disk space (see CAVEATS, below). + +unix/mkpkg.sh +unix/shlib/mkpkg.sh + Will build the edsym.e utility and install it in HBIN during a + bootstrap. + +unix/hlib/install + Will make a link for EDSYM in the local/bin directory. + +pkg/cl/main.c + A call to XMJBUF was added to convert to a vectored procedure reference + to the main interpreter context vector. + +sys/gio/cursor/prpsinit.x +sys/gio/cursor/mkpkg +sys/etc/mkpkg +sys/etc/prfindpr.x +sys/etc/propcpr.x +sys/etc/prsignal.x +sys/etc/prfilbuf.x +sys/etc/prgline.x +sys/etc/prupdate.x +sys/etc/prclcpr.x +sys/etc/prstati.x +sys/etc/prredir.x +sys/etc/prgredir.x +sys/etc/prclose.x +sys/etc/proscmd.x [moved from gio/cursor to ETC] +sys/etc/prpsio.x [moved from gio/cursor to ETC] +sys/etc/prc.com [moved from LIB to ETC] +sys/etc/prpsload.x + + Most of the "pr" prefixed files, e.g., PRPSIO, were moved from + gio/cursor to ETC, and the file prc.com (the PR common) was moved + from LIB to ETC, making it a private common. This was necessary + to avoid the global data reference, which would cause the process + control code to fail at runtime due to the client and shared image + having separate copies of the PRC common (another reason to not use + commons!). PRPSIO was modified to use a loadable driver to provide + a runtime technique for linking to the graphics pseudofile i/o + procedures in gio/cursor. In addition to making the shared library + cleaner to implement, this collects all of the process control code + together in one place in the VOS (in ETC - libsys.a), avoids some + circular library references, and makes it possible to use LIBC/stdio + in applications processes without an unresolved linker reference + to PRPSIO (STScI has run into this). + + PRPSINIT is a procedure called by the CL at startup time to load + the gio/cursor graphics pseudofile i/o driver into PRPSIO. + +lib/syserr.h +lib/syserrmsg + A new error SYS_PRPSIOEPA was added, in support of the above + modifications. + +pkg/images/filters/mkpkg +pkg/images/filters/convolve.x +pkg/images/filters/radcnvr.x [used to be called acnvrr.x] + This code contained a routine ACNVRR which redefined a VOPS library + procedure, causing a multiply defined linker error when linking with + the shared library. The offending procedure was renamed CNV_RADCNVR + (radially symmetric convolve, type real). Applications should not + use reserved package prefixes. + +unix/os/zfunc.c + + A set of new kernel primitives ZFUNC1, ZFUNC2, ... ZFUNC9 were added. + These are similar to ZCALL[1-9], but allow calling of functions by + their LOCPR entry point address, as has long been possible with + subroutines and ZCALL. + +CAVEATS - Shared libraries + Several interesting things about SunOS were learned in the process of + implementing the Sun/IRAF shared library. + + 1. Linker Bug. There is a bug in the SunOS linker. The size of the + BSS area is not being computed accurately. For processes with a very + small BSS section, this can lead to a BSS size of zero being computed. + Normally this does not cause a problem, since a small BSS area will + usually fit into the last page of the data area. In some cases, + however, the small BSS area is in an additional page, but since BSS + is zero no BSS area is allocated during process startup, causing a + segmentation violation when the unix code tries to set the value of + the BSS global variable "environ" during process startup. I managed + to avoid this problem by the subtle kludge of adding the following + declaration to the ZZSTRT object (which is linked into every iraf + process): + + int BSS_kludge[256]; + + This provides the process with enough BSS storage (statically allocated + unitialized data space) to avoid having the size of the BSS segment + being set to zero at link time. + + 2. Does using the SunOS shared libraries really save space? + For some reason which I was not able to determine, a small iraf + process linked -Bdyamic (the default, i.e., use the SunOS shared + libraries) always has a text segment of 75-85 Kb, even though the + sum of all the objects therein may be much less. It appears that + the linker may be incorrectly computing the size of the text segment, + causing it to effectively be padded out to a size considerably larger + than what it should be. Linking the process -Bstatic (no SunOS + shared libraries) avoids the bug, yielding a much smaller executable + file, even though more text space is actually required due to the + need to link in modules from the SunOS libraries which would otherwise + be shared. + + 3. Processes with a large BSS segment execute slowly. One thing which + became very clear to me while working on image execution was that + processes with a large BSS segment take a long time to execute. + The reason is that the BSS segment must be zeroed during process + startup. Zeroing a large region of mapped memory involves both the + cpu time required to zero the storage, plus all the mapped file i/o + (paging) required to initialize the mapped swap file pages. This is + not a big deal for processes with a BSS segment in the N*10K region, + but if the BSS is N*100K or N*1000K, then it can take seconds. The + moral is USE DYNAMICALLY RATHER THAN STATICALLY ALLOCATED BUFFERS. + I am going to modify some of the system code as a result of this + lesson, e.g., the CL currently statically allocates about 250K of + combined stack and dictionary buffer space. In applications, BSS + storage is most commonly found as declarations of the form + + char fname[SZ_FNAME] + char line[SZ_LINE] + + and so on. This is of no consequence for small individual programs, + but can add up to a lot of BSS for large packages. The unix "size" + utility may be used to determine the BSS requirements of a process. + +unix/boot/mkpkg/tok.c + An unrelated bug in MKPKG was fixed, which would cause one or the + other of IFOLDER or IFNEWER to fail, when presented with a list of + files to be compared. The bug was that IFOLDER is not equivalent + to !IFNEWER when more than one file must be compared. (12/28) + +unix/as.i386/README +unix/as.i386/aclrb.c +unix/as.i386/aclrc.c +unix/as.i386/bytmov.c +unix/as.i386/aclrs.c +unix/as.i386/aclri.c +unix/as.i386/aclrl.c +unix/as.i386/aclrr.c +unix/as.i386/aclrd.c +unix/as.i386/amovc.c +unix/as.i386/amovs.c +unix/as.i386/amovi.c +unix/as.i386/amovl.c +unix/as.i386/amovr.c +unix/as.i386/amovd.c +unix/hlib/mkpkg.sf.I386 + In an unrelated optimization, the above zero and move procedures + were added to AS. These are written to use calls to the host + BZERO and BCOPY functions to zero or copy blocks of memory, taking + advantage of the special repeat-string-op instructions provided by + the 80386 cpu. (12/28) + +sys/ki/irafks.x + In the open-binary-file code, the fprintf debug message was incorrectly + passing arg1 rather than arg2 as the file access mode. (12/29) + +unix/boot/mkpkg/tok.c + In the $ifeq code, strcmp() would be called with a NULL string pointer + if the referenced environment variable was undefined. (1/2)(1989) + +--------------------- +Moved shared library stuff to tucana (Sun-3) over the period 30Dec-2Jan. +Reworked mkshlib.csh, edsym.c, zzstrt.c etc. for the "a.out" format object +files used on the Sun-3; these are quite different than the Sys V COFF +object format used on the 386i. + +--------------------- +Moved everything back to the 386i, rebuilt the shared library, and relinked +the system. Merged in all recent changes from tucana. (1/3) + +unix/sun/imtoolrc +dev/grahpcap + Changed the X size of frame buffer configuration "imtfs" to 1144; it + has to be a multiple of 4 rather than 2 under SunOS 4.0. (1/6) + +unix/shlib/inode.c + + Added a new utility to print the inodes of the listed files. (1/6) + +unix/os/zzstrt.c + The text segment of the shared image was being mapped private, rather + than shared, causing over 600 Kb of swap space (roughly the size of + the shared image text area) to be reserved unnecessarily for every + process spawned. (1/12) + +unix/hlib/irafuser.csh +unix/shlib/mkshlib.csh +unix/shlib/*.ffpa + + Added support to SHLIB for the ffpa version of iraf, and relinked the + ffpa version with the shared library. (1/13) + +BSS segment test + Changing the CL dictionary and stack areas from BSS to DATA segment + arrays (to avoid runtime initialization of the large BSS area) had + no significant effect on CL startup time, so I left things as they + were. (1/13) + +unix/shlib/mkshlib.csh + 1. Modified to add support for IRAFULIB (custom libraries, for linking + development systems). (1/13) + 2. I got a "too many arguments" abort from the linker while trying to + link the shared library with all the new QPOE, PLIO, FMIO, etc., stuff + on the 386i, so I had to revise the link procedure to prelink each + library and then link everything in a second pass. This is faster + anyhow due to the need to link twice, once to get the name list and + the second time to construct the final image. (1/14) + +unix/boot/mkpkg/tok.c + Character escapes were not being handled properly in getstr(). (1/16) + +unix/shlib/mkpkg + In the mkpkg install sequence, which renames any existing bin$S.e to + bin$S.e.1, and bin$S.e.1 to bin$S.e.2 (to avoid deleting the shared + image while some process has it mapped), added some find -atime +1 + code to delete any old S.e.* files which haven't been accessed for + more than a day. (1/16) + +unix/boot/spp/xpp/xppcode.c + In the case of a redefined string define, the second define was not + replacing the first. (1/23) + + +LAYERED SOFTWARE ENHANCEMENTS (2/22/89) +-------------------------------------------- + +The following sequence of revisions we made to improve the support provided +by IRAF for external or "layered" packages. The idea is that an external +package should be fully self contained with as simple an interface to the +core system as possible, e.g., an entry in a single file. Support for +developing and maintaining such packages should be as good as it is for +core system software. Installing a package should be simple and foolproof; +likewise deinstalling a package, and it should be possible to install an +arbitrary collection of external packages without having them conflict with +each other and without custom modifications to the core system. + +Meeting these goals requires that external packages be *self contained*, +because if installing a package involves modifications to or additions of +numerous files in the core system directories, deinstallation is obviously +going to be difficult, as will updating the core system - all the custom +modifications will be lost. Ideally it should be possible to have a library +containing any number of external packages in some central place, e.g., +on tape or on an archive server somewhere on the net, loading only those +required at any one time onto the local IRAF system. + +The following series of revisions were made on the 386i development system, +tested, and merged back into the master system. The notes summarize what +was modified on the 386i; additional notes will follow as things are tested +on the Sun-3 development system. + +--------------------- +Begin changes to better support layered external software. (1/28) + +unix/os/zgtenv.c +sys/etc/environ.x +sys/etc/envgets.x + ZGTENV, ENVFIND, and ENVGETS were changed to make it possible to + discriminate between undefined environment variables, and variables + that have a null string value. ERR is returned if the variable does + not exist; 0 if exists but has a null value. Since most programs + do a <= 0 test to check for valid environment definitions, this should + be a fairly safe change, although some programs may be affected + (i.e., any program that only does an == 0 test). (1/28) + +sys/libc/cenvget.c +pkg/cl/builtin.c + Minor changes to allow for null valued environment variables. (1/28) + +sys/fio/vfntrans.x + Added a new feature to virtual filename translation, to provide general + environment symbol replacement during translation. This was needed to + support multiple architectures, e.g., different version of the PKG and + LIB directories, but it is a general facility which will be useful + for multiple versions of other types of directories and files as well. + + For example, one might make the following definitions: + + set arch = "" + set bin = iraf$bin(arch)/ + set lib = iraf$lib(arch)/ + + Which become iraf$bin/ and iraf$lib/ by default. If arch is defined + as, for example, ".ffpa", then we have iraf$bin.ffpa/ and likewise + for lib. The default case, where arch is the null string, is what + required the revisions discussed earlier. (1/28) + +----------------- +The following revisions were made all together over a period of a couple +of weeks and summarized on 2/21. + +pkg/system/help/helpdb.x +pkg/system/help/helpdir.x +pkg/system/help/modlist.x +pkg/system/help/modtemp.x +pkg/system/help/prdir.x +pkg/system/help/prfile.x +pkg/system/help/prhlpblk.x +pkg/system/help/prsummary.x +pkg/system/help/t_help.x +pkg/system/help/tlist.x +pkg/system/mkhelpdb.par + 1. The compiled help database files are now stored externally in a + machine independent format. + + 2. HELP now permits multiple compiled help database files. The + parameter / environment variable `helpdb' is now a file template + (e.g., a comma delimited list of files) specifying the helpdb files + to be combined to produce the composite help database to be used + at runtime. HELP takes a little longer to respond the first time + while it is reading and combining all the files, but once the + composite database has been generated in-core all is as it was before. + If any of the helpdb files are modified, or if new files are added, + the incore composite database is automatically regenerated. + + It is still necessary that all package names be unique; this + restriction will be removed in a future implementation but it is + too difficult to fix in the current program. + +dev/help.db - +lib/helpdb.mip + + The old core sytem help database file dev$help.db has been deleted + and replaced by the new machine independent file lib$helpdb.mip, + which now contains only entries for core system help modules. + Each external layered package (noao, local, stsdas, etc.) will + have its own lib/helpdb.mip. + +mkpkg + 1. All references to the noao and local packages have been removed + from the root mkpkg file. Layered packages are maintained + independently of the core system and separate mkpkg sysgens, + etc, are required for each package. + 2. The `stripall' entry has been deleted leaving only `mkpkg strip' + for stripping the system. + +noao/README + Completely new README for the reorganized NOAO package. + +noao/bin + +noao/bin.i386 + + NOAO now has its own BIN directory. For Sun/IRAF, `bin' is a + symbolic link to the bin directory for the architecture for which + the system is currently configured, bin.i386 on my development + system. + +noao/lib/helpdb.mip + compiled help database +noao/lib/mkpkg.inc + global mkpkg definitions for noao +noao/lib/mkpkg.sf.I386 + special file lists for various architectures +noao/lib/mkpkg.sf.SUN3 + " +noao/lib/mkpkg.sf.SUN4 + " +noao/lib/root.hd + root help directory for the noao packages +noao/lib/strip.noao + stripper file for the noao directories + + The above files were added to noao$lib, the global library for the + NOAO packages. All files are maintained in a machine independent + format and may be included in distributions. Files like the mkpkg.* + include machine dependent information but are easily modified or + extended to support new architectures - there is no better way, + one must have things like special file lists for different + architectures (if there isn't one, as in a new port, the application + will still sysgen but there is a real possibility of undetected + compiler bugs). + + The helpdb.mip is machine independent as well, and should be generated + by the developers of an exportable package, and included in the + distribution. The ".mip" extension tells the HSI utilities such as + WTAR that it is a machine independent file and can be included in + "source only" archives. It can be generated under V2.8 with a command + such as + + cl> mkhelpdb helpdir=noao$lib/root.hd helpdb=noao$lib/helpdb.mip + + By default, MKHELPDB will generate the core system help database. + +noao/mkpkg + Added a `mkpkg strip' entry. Other entries will need to be added + in the future to support multiple architecture switching for Sun/IRAF. + +noao/noao.cl + Added the following lines to the noao.cl file: + + set noaobin = "noao$bin(arch)/" + package noao, bin = noaobin$ + + The bin= argument to package is required to tell the CL that noao + has its own bin directory and is discussed below. The `noaobin' + definition permits user redefinition of the noao BIN directory, + as well as specification of the architecture for all packages + via the environment variable `arch', which is defined in terms + of `mach', which defines the machine architecture. + +pkg/cl/bkg.c +pkg/cl/builtin.c +pkg/cl/exec.c +pkg/cl/main.c +pkg/cl/prcache.c +pkg/cl/task.c +pkg/cl/task.h + The CL was modified to generalize the BIN directory scheme. Formerly + executables could be stored either in the package directory or in BIN. + The same is true now except that there can be multiple BIN directories. + By default bin is iraf$bin/. This may be overridden for a package by + specifying the package bin directory with a bin=bindir argument to + the PACKAGE directive (see example above). The new bin will be used + for the referenced package and all subpackages of that package, unless + overridden by another PACKAGE directive. Note that no bin-path + searching is involved; the CL never has more than two directories to + look in for a given executable, since every package has a well defined, + unique BIN directory. + +sys/etc/envgets.x +sys/etc/environ.h +sys/etc/environ.x +sys/etc/envscan.x + 1. ENVFIND will now return ERR if the named variable does not exist, + and a string length of zero if the variable exists but has a null + string value. + 2. ENVSCAN now permits newline to be escaped in the value field, + permitting arbitrarily long value strings. Leading whitespace is + discarded in each continuation line, allowing continuation text to + be left justified at any arbitrary column for readibility. + 3. ENVSCAN recognizes both SET and RESET. + 4. ENVSCAN now supports the "set @filename" syntax for inclusion + of other files containing set environment definitions. All non + set or reset statements are ignored. + 5. The max size value string is increased to 512 chars. + + All of these changes hold also for the HSI version of ENVSCAN + (see the bootlib.envinit.c notes below). + +sys/fio/vfntrans.x + General environment variable replacement is now supported within + virtual filenames via the syntax "(envvar)", which is replaced + by the value of the named environment variable "envvar". This is + different from logical directory replacement which replaces + everything to the left of the $. (Perhaps we should have simply + used the unix symbol replacement syntax in the first place, but + it is too late to change now). For example, + + set mach = f68881 + set arch = .(mach) + set bin = iraf$bin(arch)/ + + This point of this facility is that it allows any field of a filename + to be parameterized with an environment variable. If the named + variable does not exist the null string is used. + +sys/imio/iki/ikiopen.x +sys/libc/cenvget.c + Replaced an "envfind() == 0" by "envfind() <= 0" to reflect the fact + that ENVFIND can now return a negative value. + +unix/boot/bootlib/mkpkg +unix/boot/bootlib/bootlib.h +unix/boot/bootlib/osfn2vfn.c +unix/boot/bootlib/vfn2osfn.c + The UNIX/IRAF HSI has been modified to use VOS filename mapping, + to facilitate use of the zzsetenv.def and extern.pkg logical directory + definitions, as well as all the other semantics of general filename + mapping. Note that this requires use of libsys.a (etc.), but it + was done in such a way that if the library does not exist, bootstrap + filename mapping is used. VOS filename mapping is used only if the + environment variable NOVOS is not defined at HSI bootstrap time; this + variable is defined in the file hlib$irafuser.csh which is assumed + to be referenced at login time by the account of whoever is doing + the bootstrap (normally user iraf). + + A true bootstrap is performed with VOS filename mapping disabled, + and then repeated once a sysgen has been performed to generate the + VOS system libraries. The HSI bootstrap filename mapping facilites + are adequate to compile the VOS but do not support external layered + packages. + +unix/boot/bootlib/envinit.c + This routine is used by the HSI to read the zzsetenv.def file. + This cannot be done with the VOS, even when VOS filename mapping + is in use, because the VOS routine envscan uses FIO (the filename + mapping primitives are much lower level, being layered on the kernel). + I made all the same changes as for ENVSCAN above, so that the + environment variables defined in hlib$extern.pkg will be defined + in the HSI. + +unix/boot/bootlib/osfpathname.c + 1. Modified to avoid the null filename bug that appeared in VMS/IRAF + long ago (VMS/IRAF also uses VOS filename mapping). + 2. Fixed a second bug that would probably only affect UNIX/IRAF. + The filename ".." was not being mapped properly on UNIX/IRAF, whereas + it worked fine on VMS/IRAF. This was because on UNIX/IRAF the call + to vfn2osfn to translate the ".." to the pathname of the previous + directory, whereas on VMS/IRAF all it would do is pass it on, to be + used in the later call to ZFSUBD. + +unix/boot/bootlib/ossysfile.c + Added support for an applications defined system library search path, + e.g., for XC command line -llib library references, or global + include file references. LIB, HLIB, and any other system libraries + are searched first, followed by any package libraries as specified + by the environment variable `pkglibs'. The latter is defined in + extern.pkg and this mechanism is intended as a way of extending the + global library mechanism to support applications libraries. There is + a flaw - a search path opens the possibility of file name collisions, + resulting in the wrong file being used. At least this will be obvious + if it occurs, and the search path is the simplest mechanism in this + case. + + This HSI level library search path mechanism should not be confused + with the IRAFULIB facility used in UNIX/IRAF. Any IRAFULIB directories + are searched *before* the system libraries, allowing custom versions + of system library files for testing or development purposes. In the + case of the `pkglibs' the system libraries are searched first, with the + full search order being the IRAFULIBs, followed by the system libraries + (LIB, HLIB, and also BIN, bin.`mach` etc. for Sun/IRAF), and lastly + the package libraries in the order in which they appear in pkglibs. + There should be minimal execution time penalty from adding pkglibs + searching, since most global file references will be satisfied early + in the search by a system library. + +unix/boot/bootlib/osgetenv.c + Added VOS and NOVOS cases. The VOS case calls ENVFIND to lookup + environment names. This is required to make the environment used + for VOS filename mapping available in the HSI utilities, e.g., + in mkpkg. + +unix/boot/mkpkg/mkpkg +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh + All these files had to be modified to parameterize the list of + libraries to be used to link HSI executables. Formerly libboot + and libos were being referenced explicitly, but now that the HSI + can be linked either VOS or NOVOS, the list can also include + libsys and libvops. The parameter is the unix environment variable + HSI_LIBS defined in hlib$irafuser.csh. + +unix/hlib/clpackage.cl +unix/hlib/clpackage.hd + Removed all references to local, noao, and stsdas. External packages + now have their own root help directories and help database files, so + no entry in the clpackage.hd is required. The external packages are + picked up by clpackage.cl by the following statements: + + # Define the external (user-configurable) packages. + cl < hlib$extern.pkg + + which executes the TASK statements in the extern.pkg to define the + external packages. The environment variables in extern.pkg will + already have been defined by the zzsetenv.def @extern.pkg include, + so they are reset harmlessly when extern.pkg is reinterpreted by + the CL. + +unix/hlib/extern.pkg + +unix/hlib/zzsetenv.def + 1. Removed all references to noao, local, and stsdas from zzsetenv.def, + replacing these by the statement + + set @hlib$extern.pkg + + which includes set (actually reset) statements defining the root + directory of each external package. + + For HELP, deleted the entries for helpdir and helpdb. The helpdir + environment variable is no longer used, and helpdb has been moved + to extern.pkg. + + 2. Added the file hlib$extern.pkg, which is the sole link between the + core system and external packages. To install an external package, + ALL that should be required is to make an entry in this file, after + reading the files onto disk (a mkpkg at the package root will also + be required if the package is distributed in source only form). + To deinstall a package, all one need do is comment out or delete + the related entries in extern.pkg, and backup and delete the external + package directory tree. The core iraf system can be updated without + affecting external packages. + + These things are possible ONLY if we strictly localize package files + to package trees, i.e., do not install library files and executables + from an external package in core system directories, do not rebuild + a central help database file, etc. A further major advantage for + NOAO is that we can easily maintain private LOCAL packages, have + STSDAS on disk for our users, etc., without making modifications to + our export systems which would affect our distribution tapes. + By localizing the changes required to interface an external package + to a single file, we need only replace that one file to make a + distribution tape from one of our master systems. + + For software maintenance purposes, developers should assume that ONLY + the root directory of their package tree is globally defined in the + HSI, and use only references such as "noao$lib/", "-llib", or + "" in their applications (any VOS pathname relative to the + package root is acceptable). Note that a package global library + may be set up by adding the path of the library directory (e.g., + "noao$lib/") to the `pkglibs' entry in the extern.pkg. + + Additional logical directories may be defined in the global package + mkpkg.inc and used in mkpkg files, but these logical directory names + will not be propagated to XC hence cannot be used in include file + references etc. Additional environment variables could in principle + be added to the entry for the package in the extern.pkg, but I would + like to keep the interface as small as possible, localizing all + package information in the package itself as far as possible. + + VMS/IRAF users should note that since XC executes in the context of + MKPKG in VMS/IRAF, mkpkg definitions may be propagated to XC (I + haven't tested this), but to make use of this side effect of how XC + is implemented in VMS/IRAF would be nonportable. + +unix/hlib/gripes.cl +unix/hlib/gripesfile- + Commented out the code which appends gripes to the gripesfile, and + deleted the gripesfile. We will use only electronic mail to enter + gripes from here on. + +unix/hlib/irafuser.csh + 1. Added NOVOS and HSI_LIBS entries to define whether or not VOS file + name mapping is to be used in the HSI, and to list the libraries + to be searched to link HSI executables. If libsys.a does not exist + NOVOS is automatically set, hence bootstrapping UNIX/IRAF on a source + only system will automatically generate the HSI without the VOS. + Redoing the bootstrap once the VOS is compiled will cause the HSI + to be rebuilt with VOS filename mapping, as may be required to compile + any external packages (the core system does not require VOS filename + mapping in the HSI). + + 2. Added a couple of utility command aliases. `mkv' runs mkpkg with + the link flags set in such a way that the resultant executable has + symbols for the transfer vector entries. This is necessary to be + able to see what VOS routines are being called from an application + when debugging (otherwise one sees an offset from vshlib_). Perhaps + I should make this the default on our development system, even though + it almost doubles the size of the symbol table in each executable. + + A second utility definition `mkz' runs mkpkg, linking without the + shared library (like xc -z). These name may change but they should + serve to illustrate how to use the linker options for debugging. + +unix/hlib/libc/knames.h + Made several new entries. + +unix/hlib/login.cl + Added commented out commands to load the `noao' and `tv' packages. + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.I386 +unix/hlib/mkpkg.sf.OS4 +unix/hlib/mkpkg.sf.S34 +unix/hlib/mkpkg.sf.SUN3 + 1. In the mkpkg.inc, changed the FPU definition to MACH, since FPU + is too restrictive a name for what we use this switch for; MACH for + machine architecture comes closer. Possible values of MACH are + f68881, ffpa etc. for Sun-3 hardware options, sparc for the Sun-4, + i386 for the Sun-386, vax for the VAX, and so on. This switch is + used to select default compile and link flags, determine which + special file list to load, etc., allowing the generation of relatively + machine independent mkpkg definition files. + +unix/hlib/strip.iraf + 1. Changed the name from stripper to strip.iraf (strip.noao etc. for + other packages.). Deleted the stripall since I have never been happy + with what that level of stripping anyhow. Still need to review the + action of the strip file to ensure that everything that can be deleted + is being deleted, to add something to strip executables on unix + systems, and so on. + 2. Deleted all entries for the noao and local packages. These packages + now have their own strip files. + +unix/os/zfacss.c + Modified to test for the null filename and return NO in that case. + +unix/os/zgtenv.c + Will now return ERR for a undefined variable, and 0 for a defined + variable with a null string value. + +unix/os/zmain.c +unix/os/zshlib.c [DEBUGGING POINTER] +unix/os/zzstrt.c + Added a new command line switch "-w" to the zmain. Currently this is + only used in Sun/IRAF. Specifying -w causes the shared image text to + be mapped with write permission, allowing breakpoints to be set in + VOS routines. This cannot be done by default because one has to + reserve swap space for the entire shared image text segment in order + to have write (copy on modify) permission. + +unix/shlib/mkpkg + Fixed a bug in the code used to delete old versions of the S.e shared + image files in BIN. + +--------- (end of notes transferred from 386i) ------------ + +sys/mkpkg +sys/fmio/* + +lib/fmlfstat.h + +lib/fmset.h + +lib/syserr.h +lib/syserrmsg + Installed the new VOS library FMIO. FMIO is "File Manager I/O", and + is used to implement a simple binary file manager which maintains the + file data of so-called "lfiles" (lightweight files) inside a single + host binary file. The system overhead for accessing lfiles is much + less than that of host files, and many lfiles can be used to store + a complex data structure without cluttering a host directory or + incurring the inefficiency of accessing host files. FMIO is part of + the DFIO project and will serve as the lowest level interface within + DFIO; it is also used currently in the QPOE interface. Additional + information is given in the README file for the interface. (2/22) + +sys/mkpkg +sys/plio/* + +sys/pmio/* + +lib/plio.h + +lib/plset.h + +lib/pmset.h + +lib/syserr.h +lib/syserrmsg + Installed the following new VOS interfaces: + + PLIO pixel list i/o (system level - libsys) + PMIO pixel (image) mask i/o (used with IMIO - libex) + MIO masked image i/o + + PLIO is a general interface for storing and manipulating + multidimensional integer valued rasters containing regions of + constant value (i.e., masks). The masks are stored in a highly + compressed form, the size of the compressed mask being a function + of the information content of the mask. Both pixel array and + range list i/o facilities are provided, as well as a set of general + boolean raster operators, e.g., to extract or insert subrasters, + AND or OR a source with a destination, do the same through a stencil, + draw regions of various kinds (point, line, box, circle, polygon), + and so on. See the PLIO.hlp file for further information. + + An interactive debug program (plio$zzdebug.x) is provided for + experimenting with masks. Note that PLIO is a stand alone interface + and is not tied in any way to IMIO, even though the data structure + operated upon is similar to an image matrix. + + PMIO is very similar to PLIO except that it is used to associate a + masks with an IMIO maintained reference image. Currently, the PMIO + mask must be the same resolution as the physical reference image. + All coordinates input to PMIO are in the *image section coordinates* + of the reference image. Hence, given a physical image and associated + mask, one can operate upon both through a user specified image section + transparently to the applications program. This includes all PLIO + style boolean rasterop operations, as well as mask pixel and range + list i/o. The PMIO interface is layered upon PLIO and IMIO, and the + calling sequences are identical with PLIO except for the package + prefix, and the addition of several new PMIO specific routines. + + MIO is essentially an extension of image i/o for pixel i/o through a + mask. The central routines are the following: + + mio_setrange (mp, vs, ve, ndim) + n|EOF = mio_[gp]lseg[silrdx] (mp, ptr, mval, v, npix) + + One defines a rectangular region of the image with mio_setrange, + and then sequentially reads or writes line segments until all pixels + visible through the mask have been accessed. This type of i/o should + be ideal for most image processing applications which need to operate + upon only those pixels visible through a region mask (e.g., a surface + fitting task), upon all pixels except those on a bad pixel mask (e.g., + any analysis program), and so on. + + PLIO (or PMIO) masks may be stored in binary files on disk, the files + having the extension ".pl". The V2.8 version of IMIO has the + capability to treat such masks as if they were images, allowing masks + to be easily displayed, used in IMCALC expressions, converted to + image matrices and vice versa, etc. Applications may do either pixel + or *range list i/o* to a mask "image" via IMIO, if MIO is not suitable + for some reason. + + Using the current image structures, applications which use masks should + store the mask in a separate .pl mask file. The mask name may either + be stored in the image header of the associated image(s), or passed + into an application as a string parameter. (2/22) + +sys/symtab + +sys/etc/symtab - + Moved the SYMTAB (general symbol table) package from ETC to the root + VOS directory. (2/22) + +lib/qpset.h + +lib/qpexset.h + +lib/qpioset.h + +sys/qpoe/* + + Installed the QPOE family of interfaces. Although it was my original + intention to wait a bit to install QPOE, it has been built into the + development version of IMIO along with PLIO/PMIO/MIO, and it is now + easier and probably safer to install the whole business rather than + hack it apart. All these interfaces are stable and fairly well + tested, and to date we have had no problems with the standard IMIO + portion of the new interface. Now that the shared library facility + is in place on both Sun/IRAF and VMS/IRAF there is little reason to + worry about the increase in the size of the system libraries (which + is considerable, e.g,. one quarter to one third). + + QPOE is a program interface implementing the Position Ordered Event + list object, which consists of a general header mechanism plus an + event list, wherein the events are little data structures, e.g., + the attributes required to describe a photon detection (position, + energy, time, etc.). The QPOE interfaces are the following: + + QPOE header and file access and management facilities + QPIO raw and filtered event i/o + QPEX event attribute filter mechanism + QPF IMIO/IKI kernel for image interface to QPOE files + + Due to the complexity of the data structures involved, the added + complexity of event attribute and region filtering, and the extreme + performance requirements (an event list may contain millions of + photons which we could like to be able to filter in seconds if + possible), QPOE is quite a complex interface. QPOE is layered + upon FMIO and SYMTAB and the general header part of QPOE is a + prototype of certain parts of DFIO and the new image structures. + + In fact, the QPOE header access functions are very similar to what + is expected to be in the new image structures as the IMIO header + access interface, although the implementation of the IMIO version + will be quite different since it be based on the more general DFIO. + QPOE itself will be relayered upon DFIO when the latter becomes + available, adding machine independence and a much more flexible + and data independent mechanism for storing structured data in the + file header. The QPIO, QPEX, and QPF parts of QPOE are expected + to survive the future QPOE/DFIO upgrade largely intact. + + QPOE and QPF add a new image type to the system, with .qp file + extension. A QPOE image is contained in a single file. When a + QPOE file is accessed as an image the interface filters and + samples the event list in real time, using a user defined filter, + block averaging factor, region mask, and so on, producing the + image matrix seen by applications at the IMIO level. + + Further information is given in the QPOE.hlp file in the sys$qpoe + directory. (2/22) + +sys/imio/* + Installed a new version of IMIO that has been in a development and + testing phase for some months now (it has been stable since about + last November). This version adds support for PLIO mask and QPOE event + list images to the OIF and STF image types previously supported. + A number of new i/o routines have been added for mask i/o, e.g., + routines to test if reqions of an image contain any nonzero mask + pixels, so that an application can decide whether it needs to bother + with the expense of mask i/o. + + Aside from these additions the interface is unchanged from what it + was previously, with one exception - THE CALLING SEQUENCE TO IMPARSE + HAS CHANGED. This routine is supposed to be internal to the interface + so few applications should be affected, but it may have been + inadvertently used in a few applications, and these will have to + be searched for and modified. + + All these new IMIO image types have increased the size of IMIO + considerably. While this is not a serious problem if a shared library + facility is available, not all IRAF implementations have shared + libraries. To make matters worse, we plan to add additional image + types in the future, e.g., FITS, maybe a compressed type, and so on. + Hence, when the IKI interface is revised as part of the new image + structures project, I plan to set things up so that the system manager + at a site can configure IRAF with a subset of the available image + kernels. It will even be possible for a site to add custom kernels + for their own local image types, if desired. (2/22) + +unix/boot/mkpkg/tok.c + Fixed a bug in the (recently added) $if code which processes + file references. This did not show up until VOS filename mapping + was added, since the VOS checks for null filenames. (2/22) + +unix/hlib/mkpkg.inc + Removed the -t flag from the default link flags. This means that + shared image transfer vector symbols are now left in by default, + making the executables larger but improving the situation for + debugging. This switch will only be enabled on tucana, but those + making distribution tapes should be aware that space can be saved + by relinking or more simply, by stripping the executables (either + after the installation at a remote site or before making a + distribution tape). I haven't measured the space penalty, but it + is probably only a couple of Mb for the full system. + + By the way, the transfer vector symbols are the VOS procedure names + with a V prepended, e.g., Vclgeti_ is the transfer vector, clgeti_ + the actual VOS procedure somewhere in the shared image. With the + -t flag, a symbol such as Vclgeti would appear in the applications + program (while debugging) as a jmp to something like vshlib_+0x123. + There is of course no actual procedure Vclgeti_, this is just a + name generated by the shared library link editor. (2/22) + +unix/shlib/mkshlib.csh + Fixed a bug which was causing the "zzzend" symbol to be omitted. + (2/22) + +unix/hlib/extern.pkg + Fixed the root pathnames for local and stsdas - we can now load + stsdas from the master system for the first time!! (to look at the + packages, at least) (2/22) + +unix/hlib/extern.pkg +unix/bootlib/envinit.c +unix/boot/mkpkg/main.c +unix/boot/spp/xc.c +unix/boot/spp/xpp/xppmain.c + The package library search path entry `pkglibs' has been deleted in + extern.pkg and replaced by a better scheme. A new command line switch + "-p pkgname" has been added to the HSI programs mkpkg, xc, and xpp + (which do all logical directory manipulation, file inclusion, file + searching, etc., so far as I can remember). + + Specifying "-p X" the HSI task command line causes: + + o The file "X$lib/zzsetenv.def" to be loaded into the HSI + environment at process startup time, and + + o In the case of mkpkg, the file "X$lib/mkpkg.inc" to be + automatically $include-ed, i.e., interpreted by mkpkg. + + Multiple -p arguments may be specified if desired to load multiple + environments. If no -p arguments are given on the command line the + tasks will check for the environment variable PKGENV and load the + environment for the named package if this variable is defined in the + user's environment (only a single package can be specified via PKGENV). + + The default-PKGENV feature is intended for the convenience of the + programmer who commonly works on a single large external package + such as NOAO, STSDAS, etc.; the -p command line switch can always + be specified if some other package has to be edited. It is also + easy to use CSH aliases, IRAF foreign task definitions, etc., + to avoid having to type the same -p argument frequently. + + These features allow major packages that have their own LIB to have + their own zzsetenv.def and mkpkg environment. The standard IRAF + hlib$zzsetenv.def is still loaded first, of course, and it is this + (via the extern.pkg) which defines the package root directory. + Everything else should be defined in the package zzsetenv.def. (2/23) + +noao/lib/zzsetenv.def + +noao/lib/mkpkg.inc + 1. Added the following definitions the noao mkpkg.inc. These cause + the -p noao flag to be passed to XC for compiling and linking. + + $set XFLAGS = "$(XFLAGS) -p noao" + $set XVFLAGS = "$(XVFLAGS) -p noao" + $set LFLAGS = "$(LFLAGS) -p noao" + + 2. Added a zzsetenv.def file to the noao package library. A few of + the definitions therein are shown below. + + set pkglibs = noao$lib/ + set noaobin = noao$bin(arch)/ + set digiphot = noao$digiphot/ + set imred = noao$imred/ + set noaolib = noao$lib/ + + Defining pkglibs at the package level avoids the possibility of + finding somebody else's file with a system wide package library + search path, which could happen when pkglibs was defined in extern.pkg. + The noaobin and noaolib are the noao package BIN and LIB directories, + given unique names to avoid confusion with the corresponding core + system directories. + + The remaining definitions define the major noao directories. This is + not really necessary, but it allows one to do away with the + + include "../../file.h" + + type references in large packages, using instead + + include "ldir$file.h" or include "ldir$lib/file.h" + + which is independent of the subdirectory path. Both types of files + references still work and are still permitted, but the latter is + cleaner and probably to be preferred now that the logical directories + within a large suite of packages can be defined reliably at the HSI + level. Note that this mechanism is intended only for files which are + globally referenced within a single application; files which are + referenced by two or more applications within a large package should + go into the package (e.g., noao) global library. (2/23) + +noao/mkpkg +noao/*/mkpkg (etc.) + All the noao mkpkg files (48 or so) were modified with a SED script + to replace all occurrences of "bin$" by "noaobin$", e.g., so that + executables will be installed in the NOAO bin. The $include + noao$lib/mkpkg.inc statements added earlier were deleted, since + inclusion of this file is now handled by the -p flag or by defining + PKGENV in the user's environment. This is just as well, since the + $include at the top of each mkpkg file would have been skipped + whenever the user called mkpkg with the name of the mkpkg-module + to be executed on the command line (in which case the statements + at the head of the mkpkg file are not executed). (2/23) + +-------------- +Notes update sent to ST. (2/23) + +noao/noao.cl +noao/lib/zzsetenv.def + 1. Deleted all the set environment definitions (to define noao + package directories) from the noao.cl file, replacing these by + the single statement + + cl < "noao$lib/zzsetenv.def" + + The filename has to be quoted or this won't work. + + 2. To the noao zzsetenv.def, added a KEEP at the end to keep the newly + defined environment definitions when the file is interpreted by the CL. + The keep is ignored when the file is read by the HSI. (2/23) + +sys/fio/vfntrans.x + Replaced all calls to envgets by calls to envfind, to avoid a + brain-damaged feature of envgets (it prompts for the named variable + if it is not defined - I let someone talk me into putting this + feature in years ago). Fetching an environment variable is a + fundamental, low-level operation, and if the variable is not defined + most applications would just like to have the appropriate error + status return. In the present case, the environment fetch was + occurring during filename translation in MKPKG, and the program + was dying with a segmentation violation since I don't want to + fully initialize (and link in) the VOS for use in the HSI, where + all I want from the VOS is low level filename translation. (2/24) + +pkg/cl/builtin.c + Fixed a problem with the new "bin=bindir" feature of the PACKAGE + builtin. This was failing for packages which load dependency + packages in the header of the package script (the CL was getting + confused about just what task was executding the PACKAGE statement). + Hence, noao tasks such as astutil and proto would work, but mtlocal + (which loads dataio), imred/echelle, etc, would fail. (2/24) + +pkg/system/help/helpdb.x +pkg/system/help/helpdir.h + Testing exchange of binary help database files between the Sun-3 and + 386i revealed that there were still some machine dependencies in + the files, namely, char data was being byte swapped improperly. + Some fairly extensive changes were required to fix this, and in the + process I converted the program to save char data on disk in byte + packed from use MII. This has the additional advantage of reducing + the size of the helpdb files by nearly a factor of two. (2/25) + +pkg/language/language.hd +pkg/language/language.men +pkg/system/system.hd +pkg/system/system.men +pkg/system/system.cl +pkg/system/devices.cl + + Moved "help devices" from the language package to system, where it + perhaps more logically belongs. Added a task entry as well: "devices" + merely does a help devices. The actual information, of course, still + resides in dev$devices.hlp and must be updated by the system installer + to be reflect the actual devices in use at a site. (2/26) + +----------------------- +Begin VMS/IRAF HSI upgrade. (2/26) + +dev/devices.hlp + [vms/iraf] +dev/termcap +dev/graphcap +dev/hosts + Added the devices.hlp and updated the other files from UNIX/IRAF. + Will delete the help.db after the portable system is upgraded. (2/26) + +vms/hlib/libc/libc.h +vms/hlib/libc/knames.h +vms/hlib/libc/xnames.h +vms/hlib/libc/kernel.h + Rebuilt from UNIX/IRAF versions. The file kernel.h does not appear to + be used in the VMS/IRAF HSI but it might be useful (it contains some + VOS information), so I will keep it around for now. (2/26) + +vms/os/mkpkg +vms/os/mkpkg.com +vms/os/zfunc.c + + Added the ZFUNC family of procedures (used to call integer functions + by the function entry point address) to the kernel. (2/26) + +vms/boot/mkpkg/main.c +vms/boot/mkpkg/tok.c +vms/boot/mkpkg/mkpkg.h + Updated these machine indepdent files from UNIX/IRAF. (2/26) + +vms/boot/spp/xpp/xppcode.c. (2/26) + Updated from UNIX/IRAF - allow string define to redefine old version. + (2/26) + +vms/os/zgtenv.c + Modified to return ERR for a nonexistent variable, 0 for a variable + with a null string value. (2/26) + +vms/boot/bootlib/envinit.c + New version from UNIX/IRAF with more general syntax, support for + loading package environments. (2/26) + +vms/boot/bootlib/osfpathname.c + Although this routine would work fine for VMS/IRAF, replaced by the + UNIX/IRAF version which should work on both systems. (2/26) + +vms/os/mkpkg +vms/os/mkpkg.com +vms/os/irafpath.c + +vms/boot/bootlib/ossysfile.c + Implemented the same system/applications global file search mechanism + as is used in UNIX/IRAF. Any user defined libraries (defined by the + VMS logical name IRAFULIB) are searched first, followed by the HSI + global directories (currently HLIB, BIN, and LIB), and lastly the + applications global directories, if any (defined by `pkglibs' in the + IRAF (normally HSI) package environment. (2/26) + +vms/boot/bootlib/osgetenv.c + Replaced by the UNIX/IRAF version, which is now capable of accessing + the IRAF HSI (zzsetenv.def) environment, as well as the host + environment. (2/26) + +vms/hlib/clpackage.cl +vms/hlib/clpackage.hd +vms/hlib/clpackage.men +vms/hlib/zzsetenv.def + Merged in changes for use of hlib$extern.pkg to support external + packages. (2/27) + +vms/hlib/stsdas.cl + Deleted. (2/27) + +vms/hlib/mkpkg.sf + Deleted the only `noao' file reference therein. (2/27) + +noao/lib/mkpkg.sf.VMS + + Added a special file list for VMS to the noao library. (2/27) + +vms/hlib/stripall - +vms/hlib/stripper - +vms/hlib/strip.iraf + Deleted the stripall file, and renamed the stripper script to + strip.iraf, deleting the `noao' related entries therein. (2/27) + +vms/os/zfacss.c + Modified to test for the null filename and return NO in that case. + (2/27) + +vms/boot/spp/xpp/xppmain.c + Replaced with the UNIX/IRAF version, which includes support for the + -p flag. (2/27) + +vms/boot/spp/xc.c + Added support for the -p flag and PKGENV environment variable. (2/27) + +vms/boot/bootlib/osfn2vfn.c +vms/boot/bootlib/vfn2osfn.c + Replaced (following diff/merge) with UNIX/IRAF versions. (2/27) + +vms/hlib/zzsetenv.def + Added "set stdimcur = stdimage" to enable the interactive image + cursor in VMS/IRAF. Most NOAO VMS/IRAF users will run IRAF with + a display that has cursor readback, but this default may not be + appropriate for all sites. (2/27) + +------------------ +Completed upgrade of VMS/IRAF HSI. This included all recent revisions plus +a full diff/merge to detect any other files needing updating. All the layered +software enhancements should now be in place. (This was done on tucana and +nothing has been installed on a VMS system yet). (2/27) + +pkg/system/mkhelpdb.par + Converted the MKHELPDB parameters helpdir and helpdb to auto rather + than hidden parameters, since it will now be commonplace to change + the values of these parameters to compile package help databases. + (2/27) + +pkg/system/helpdb.x + 1. A bug in reading a new format helpdb file gave me the opportunity + to develop the ability of HELP to recover from errors reading bad + helpdb files. It should now print a nice error message and proceed + without the offending file (formerly it would go into a loop and + eventually crash with a segmentation violation). + 2. Fixed the bug, which involved reading the index of the help + database (the bug was probably introduced when this file was trashed + and reconstructed a couple of days ago). (2/27) + +------------------ +Begin merge of STScI revisions. (2/27) + +vms/boot/spp/xc.c + Added flag -u to check for undeclared variables. Could not add the + -p flag (alias for -P) since -p is already used for the layered + software enhancements. (2/27) + +sys/imio/iki/ikiopen.x + Removed the restriction that only the first subimage in a cluster + can be accessed in a newimage or newcopy operation; I can't remember + anymore the reason for the restriction, hopefully there wasn't a + good one. (2/27) + +vms/os/exit.c + For the case of a connected subprocess, removed the check for a + non-OK (!=1) exit status before calling ipc_abort. Evidently this + test could fail when exiting a subprocess under the debugger. + It should always be desirable to set EOF on the IPC stream (this + is what ipc_abort does) when a connected subprocess exits. (2/27) + +sys/imio/imaccess.x + This routine was assuming that imparse would return cl_index=1 by + default if no cluster index was indicated in the image specification, + whereas the value actually returned is cl_index=0. Changed the test + cl_index>1 to cl_index>0 accordingly, so that the existence test is + carried out by mapping the image if and only if either a section or + cluster index is specified. (2/28) + +vms/os/zfmkcp.c + It was suggested here that the ZFMKCP routine not propagate the + template file's protections, allowing the default user file protections + to be used instead, as if a new file were being created (but then why + use ZFMKCP?). This isn't really what we want as it makes sense for + a file's attributes to be retained in a copy operation, and such is + required by the specifications and intended use of ZFMKCP. It is + probably not correct to simply copy the file attributes, however. + If the template file belongs to the user probably the file attributes + should be retained; otherwise the attributes should probably be those + of the template file masked by the user's protection mask. This will + have to wait until I have time to look into it a bit further. (2/28) + +sys/imio/imsetbuf.x + To the list of criteria that must be met to enable "fast" i/o (direct + access to the FIO buffer), added the requirement that the pixel array + in the pixel file be properly aligned for pointer type access. This + proved necessary for the STF image format which can have the pixel + segment beginning at an odd-byte file offset. In such a case, wasting + a byte or three to properly align things would greatly speed up image + access, but there is no argument that the interface should verify + alignment at runtime. (2/28) + +sys/imio/db/imgetb.x + Modified to make fetching the value of a nonexistent parameter an + error, rather than just returning false, for consistency with the + other datatypes and to make it easier to disciminate between the + cases. It is still possible for applications to map nonexistence + into false if desired, if not as convenient. + + I checked all core system and NOAO code which uses imgetb to ensure + that it would function correctly given the changed semantics of + this procedure, and did not find any problems (it was only used in + five files). (2/28) + +sys/imio/db/mkpkg +sys/imio/db/imputr.x +sys/imio/db/imputd.x + Rather than decrease the value of the precision used to encode a real + in IMPUTR, I modified the format to use "%0.*g", where * is passed + the value NDIGITS_RP (from ) at runtime. This makes the + encoded precision variable depending upon the precision of the FP + hardware on the host, assuming that the values in are + accurate. The same was done for IMPUTD, except that in this case + it is easy for a double encoded in the full precision to exceed + the 20 char field width of a FITS value, so this routine is set + up to try an encoding of NDIGITS_DP, decreasing the precision + iteratively until the encoded value fits. (2/28) + +sys/imio/db/imputh.x + + Added a new routine IMPUTH, used to write FITS-style HISTORY or + COMMENT cards to the image header. It is not clear whether this + is exactly the capability we will want in the future, but due to + the importance of FITS it is likely that the new image headers + will contain a FITS table as a header parameter, e.g., as a place + to put non-keyword FITS cards (like HISTORY and COMMENT cards) + when a FITS tape is read. In that case IMPUTH would probably + append cards to the FITS-table in the image header. Since the + current headers are already FITS its current function is to append + cards to the header itself. This is different than adding or + updating a named header parameter because these "cards" are + purely informative and do not have unique keyword names. (2/28) + +sys/imio/iki/stf/ + Since there were numerous minor revisions to the STF code, and this + interface is due for a major rewrite (or obsoletion) in the near + future as part of the image structures project, I merely installed + the ST version of STF with a few minor sytlistic changes but no + functional code modifications. (2/28) + +Notes on other st revisions + All STF related revisions - dealt with below. + GDEV, termcap, graphcap revisions - passed on to SJ for review. + Shared library stuff - no action for now, the whole thing needs + to be redone at some point. + Box vectors for imhistogram - will be obsoleted when box vector + feature appears in next version of GIO, but task level feature + is harmless. We will look into including such a revised task + in V2.8 as an interim solution. + CHPIX task is already installed in V2.7. + Support for TY_USHORT in IMCOPY etc. - should be supported, point + passed on to LED. + Excelan network interface - no action for now, will be supported + when network interfaces are reworked to add runtime selection + of the protocol to be used to reach a particular host. + All revisions having to do with installation of files in LIB, DEV, + etc. were ignored, as these files should go into stsdas$lib now + that this is is supported. When selected programs (e.g., IGI) + migrate to the core system the necessary files will be put in + LIB etc. as part of the installation process; HSI file searching + will make this transparent to applications. + (2/28) + +---------------------- +Moved new VMS/IRAF HSI back to draco (main system update to follow). +This was done by deleting the old iraf$vms directory tree, restoring the new +tree from a source only tar tape, and rebooting. Aside from a couple of minor +compile time problems with the new code, the only problems encountered were +[1] initially there was no RTAR, since I had deleted it (!), and [2] I had +to restore hlib$libcalcomp.a before one of the SGI translators would link. +Other than that things appears to work, so far, or at least the hlib$extern.pkg +file is being read. (2/28) + +---------------------- +Updated the machine independent IRAF directories (doc,lib,math,noao,pkg,sys) +from UNIX/IRAF, and started a full sysgen. This was done by deleting all +the old directories and restoring a full tar archive from tucana (a process +which takes HOURS on a VMS/8600, for 8000 files). (2/28) + +Completed sysgen of core and noao systems on 3/2. This was delayed due to +the time required to fix a problem with the new HSI code, which was necessary +before the sysgen could be performed. + +vms/os/irafpath.c + This file searches for files like "libos.a" and "libc/xnames.h" in + standard places like LIB and HLIB. For VMS, I had to modify the + code in irafpath.c (which is internal to the system and not part of + the kernel interface) to deal with / subdirectory references and + file extension mapping. Probably this should be done with bootlib + code but a system dependent routine is required to permit the HSI + to look for the files in peculiar places, e.g., user (IRAFULIB) + directories and architecture dependent directories (e.g., bin.i386 + in Sun/IRAF). Adding irafpath made it possible to have a portable + os_sysfile routine in bootlib. (written 3/2) + +vms/os/zmain.c + Had to be modified to pass references for SYSRUK and ONENTRY to + the iraf main in the argument list. (3/2) + +vms/boot/mkpkg/mkdebug.com + Added a library declaration for the VMS/C library. (3/2) + +vms/hlib/mkpkg.inc + Added defines for MACH and USE_SHLIB. For VMS, MACH="vms" and + USE_SHLIB=no, since the VMS shared library support is not tied + into mkpkg for automatic configuration yet. (3/2) + +----------------- +With these changes I was able to get the VMS/IRAF core system up. There were +a couple of compile time problems in the noao packages which I haven't dealt +with yet and which won't be documented here. (3/2) + +lib/helpdb.mip +noao/lib/helpdb.mip + These help database files propagated successfully to VMS/IRAF via + wtar, and HELP seems happy using them on the VMS system, so the + HELP system now appears to indeed be machine independent. (3/2) + +unix/hlib/install + Modified the installation/update procedure for the "imtoolrc" file. + Formerly this file was left alone if one was already installed, + to avoid clobbering any user modifications. This is too dangerous + as the user is not aware that the file may need to be updated if + they never modified it. On the other hand, if they modified it + they will certainly notice if the file is changed during an update. + The existing file is now copied to imtoolrc.OLD and the new one + installed in its place. (This bug was discovered during a recent + inspection of the 4-meter Sun/IRAF installation). (3/2) + +unix/boot/bootlib/ossysfile.c +vms/boot/bootlib/ossysfile.c + Modified this file to add a commented out #define STANDALONE, which + if uncommented, will cause the file to use its own private copy of + the "irafpath" function, for systems that don't need a custom version + of irafpath. Both Sun/IRAF and VMS/IRAF currently do have their own + private irafpath functions, and do implement the IRAFULIB feature + for software development. The Sun/IRAF version of irafpath() is + more complicated, as it has to determine the names of the directories + to be searched based on the machine architecture (e.g., the HBINs + are bin.sparc, bin.mc68020, bin.i386 etc.). (3/3) + +vms/boot/rmbin/mkdebug.com + Added a LNK$LIBRARY declaration for the VMS/C library. (3/4) + +unix/hlib/libc/knames.h +unix/boot/bootlib/vfn2osfn.c +vms/hlib/libc/knames.h +vms/boot/bootlib/vfn2osfn.c + The stubbed out version of ki_connect() in bootlib turned out to be + a problem, as the real procedure has the necessary side effect of + unpacking the resource name and stripping the node prefix, leaving + the resource name to be passed on to the kernel primitive on the + local node for a local reference. I modified bootlib to stub out + ki_gethosts() instead, to ensure that networking is disabled in the + HSI (when linked with VOS filename mapping), and to prevent linking + in tons of stuff the HSI doesn't need. Examination of the size + of an HSI executable relinked with the new stub indicated that the + desired result was still being achieved. (3/4) + + NOTES - the bootlib routines are being linked through the KI due to + knet being enabled in knames.h. There is no reason for this and the + KI link should be removed. In KFSUBD, the routine calls ZFGCWD for + a local node reference. This is a subtle change to the semantics + of ZFGCWD (the KFSUBD version should be exactly equivalent), and the + call to ZFGCWD should be removed. I will wait until later to do so + as I expect it was put there to "fix" a bug somewhere else. (3/4) + +layered software enhancements test + I set up a dummy library and global include in noao$lib and wrote a + little test package which referenced these, to test package + global include file references and -lXX package library references, + and tested this on both the Sun and VMS systems without any problems. + You have to remember to include the -p package flag though. If this + is forgotten a mkpkg will run but will misbehave. In the case of + the NOAO executables the primary symptom is that the new executable + will be installed as noaobinx_file.e in the package directory, rather + than into noaobin$x_file.e (due to noaobin being undefined). For + applications that reference package global includes or libraries a + compile or link time error will result. (3/4) + +sys/imio/db/idbpstr.x + 1. Improved the rigour of the code which tests if the string value + is numeric. Excessively long numeric sequences are now treated as + string values (to avoid possible arithmetic overflow), and strings + containing multiple tokens are classed as strings even if the first + token is a number. + 2. Replaced a redundant "nint(dval)" by "lval", which has already + been computed at that point. (3/4) + +sys/imio/imrbpx.x +sys/imio/imwbpx.x + Replaced the reference to IM_NDIM by IM_NPHYSDIM. The routines work + on the physical image matrix and the section transformation has been + taken out by the time they are called. The use of IM_NDIM could + lead to a runtime error when referencing a section of lower + dimensionality than the physical image. (3/4) + +unix/os/zgtenv.c +vms/os/zgtenv.c + Increased the max length of a iraf/host/tmp pathname (SZ_VALUE) + from 40 to 80. Added a check to avoid overflow of the value + buffer; pathnames are silently truncated if too long. (3/4) + +sys/imio/iki/stf/stfwfits.x + Added code to check if IM_HDRFILE is the null file; if so, the + routine exits immediately without attempting to update the header + file. This bug would cause rfits make- to fail with the default + image type set to STF. (3/4) + +unix/boot/rmbin/rmbin.c +vms/boot/rmbin/rmbin.c + In interactive mode (rmbin -i) answering no to a file-deletion + query would cause the scan for the directory in which the file was + contained to terminate. (3/4) + +unix/hlib/mkpkg.sf.S34 +noao/lib/mkpkg.sf.SUN3 + Added images/lib/ranges.x and onedspec/dispcor/ranges.x for compilation + with the optimizer turned off (OS-3 only presumably). (3/4) + +sys/imio/db/idbpstr.x + Added a return(OK) after IM_LEN is set for case naxisN. Without this + the routine goes on to set IM_NDIM to the same value. I also added + limit checking on the N in naxisN. (3/4) + +sys/imio/imioff.x + Added code to allow setting the minimum image line packing density + via an environment variable (impkden). Formerly this was wired + into the code via a defined constant. The packing density determines + whether image lines are padded to occupy an integral number of device + blocks or not. If this can be done without wasting too much space, + as determined by the minimum packing density, then image lines will + be aligned, which is more efficient for random i/o accesses. For + sequential i/o accesses it makes little difference and may even be + slower since the image will be larger. (3/4) + +vms/os/zopcpr.c + Added a sys$clref(PROCEF) call to ZCLCPR (immediately after the + sys$waitfr(PROCEF) loop, to clear the event flag once it has been + seen), and to _prinit, to ensure that the flag is clear when the + first process is spawned. Formerly the flag would always be true + after the first connected subprocess exited, causing ZCLCPR to + sit in a tight loop consuming lots of cpu while waiting for the + subprocess to exit. (3/4) + +pkg/system/help/mkhelpdb.hlp + Updated the help page for MKHELPDB. (3/4) + +------------------------------ +Updated irafx@draco. (3/4) + +lib/syserr.h +sys/etc/mkpkg +sys/etc/envgeti.x +sys/etc/envgetr.x +sys/etc/envgetd.x + Added envget[rd] functions to go along with envgeti (I used envgetr + in imioff above). Changed the SYS_ENVI error to SYS_ENVNNUM to be + used for all failures to interpret the values of environment variables + as numbers. (3/5) + +vms/mkpkg.com + Added commands to delete any .mlb files before the bootstrap, to avoid + the bug where a bootstrap run on an already bootstrapped kernel + preserves the old .mlb files, fooling mkpkg into thinking that the + libraries contain more than they do (e.g., iraf networking support + in the kernel). (3/5) + +vms/gdev/sgidev/mkpkg.com + Added an if(f$search...) to conditionally compile the calcomp SGI + translator only if the calcomp library is present in hlib. (3/5) + +------------------------------ +Updated irafx@draco and started sysgen/relinks on both systems. (3/5) +Snapshot of prerelease V2.8 VMS/IRAF sent to ST. (3/6) + +unix/boot/bootlib/tape.c + Modified to open the tape drive newfile=0, i.e., without moving the + tape. This should make it possible to store multiple tar files on + a tape. (3/6) + +sys/qpoe/qpiosync.x + Changed the second if(IO_MINEVL(io)... to if(IO_MAXEVL(io)... (3/8) + +sys/qpoe/qpset.h - +sys/qpoe/qpioset.h - +sys/qpoe/qpexset.h - + Deleted these files, since the real versions are now installed in + LIB. (3/8) + +sys/qpoe/qpiowb.x + The code was scanning all the events in a bucket to compute the min/max + values, but was not updating said values in the min/max event records. + (3/9) + +sys/qpoe/zzdebug.x + Added a new debug task DUMPEVL, used to dump out the QPIO event list + descriptor, including the field values of the min/max event records + for the full list. (3/9) + +sys/pmio/README +sys/plio/README +sys/plio/plsave.x +sys/plio/plsavef.x + 1. In pl_save, the function value being returned was a pointer value, + and not the length of the encoded mask. + 2. In pl_savef, pl_save() was being called as a subroutine with 4 + arguments, whereas it is actually an integer function with 3 arguments. + I modified the calling sequence of pl_save (and pm_save) to add a + fourth, currently unused "flags" argument, and modified pl_savef to + call pl_save properly. (3/10) + +sys/mkpkg +sys/plio/mkpkg +sys/plio/tf/mkpkg + Moved PLIO from libsys to libex. Logically this is where it really + belongs, and the package had to be either moved or modified since + PLIO contains a couple of peripheral routines (pl_saveim and pl_loadim) + which make calls to IMIO, which would lead to a circular reference in + the system libraries. The main motivation for putting PLIO in libsys + in the first place was because the integer vector compress/decompress + routines are generally useful, but perhaps a better approach if these + facilites are required in system code would be to add a set of short + and integer compress and uncompress vector primitives to ETC, giving + the procedures system names but probably making them equivalent to the + PLIO routines. I will probably do this the first time we find we need + such a facility in system code. (3/11) + +sys/fio/fioclean.x + 1. Was not recognizing the F_KEEP flag (keep open after task + termination) in the case of a string or spool file. + 2. In the process of fixing the above, I noticed that F_KEEP was + being ignored during a cleanup following abnormal task termination. + This would seem to render F_KEEP rather useless, so I changed it so + that the file remains open no matter what if F_KEEP is set. (3/11) + +unix/os/zmain.c +sys/etc/main.x + Modified the iraf main and zmain to make it easier to call iraf tasks + as host level tasks, i.e., without having to set up a command file and + run the process with the standard input redirected. In the new scheme, + any extra arguments given on the process command line are passed into + the iraf main as a command buffer containing the iraf command or + commands to be run. For example, + + x_system.e netstatus + + would run the command `netstatus' in process x_system.e. + + x_system.e count "files=*.x" + + would run the `count' task, counting all .x files in the current + directory. + + x_system.e count "files=*.x 4>_o" + + would do the same, redirecting the output at the iraf main level to + the file _o. + + x_system.e 'directory @pars $nargs=0' + + would run the `directory' task with the given parameter set, with + $nargs set to 0. If any of the parameters to a task are omitted + the task will query the terminal (clin) for them in the usual way, + so for example + + alias count "$iraf/bin/x_system.e count files=" + + would make the iraf task `count' available in unix, allowing the + iraf template specifying the files to be counted to be either given + on the unix command line, or prompted for if omitted. Given the + above alias, one could enter a unix command such as + + count 'cl$*.h' + + After some experimentation I even managed to define a cshell alias + to run the prow and stdgraph tasks standalone to plot rows of iraf + images; the alias used was + + alias prow + '$iraf/bin/x_plot.e prow @prow.pars image=\!:1 row=\!:2 "6>_MC"; + $iraf/bin/x_stdgraph.e stdgraph @stdgraph.pars input=_MC; rm _MC' + + after which one types something like the following into the cshell + to plow rows: + + prow 'dev$pix' 101 + + What happens is that if extra stuff is included on the command line + when the task is run, the zmain concatenates it to form the command + file (string buffer) to be interpreted, otherwise commands are read + from CLIN. (3/11) + +sys/imio/iki/stf/stfopen.x + Added the "ksection" argument. (3/16) + +pkg/cl/pfiles.c +pkg/cl/eparam.c + Modified the pfile code to improve the ability of the CL to detect + and recover from truncated pfiles. The pfilewrite code was modified + to always output the "mode" parameter as the last parameter, to mark + the end of the parameter list. If the "mode" parameter is not seen + when a uparm pfile is read by the CL, the package pfile is used + instead, merging the contents of the truncated pfile to recover as + much of the information as possible. (3/17) + +unix/hlib/strip.iraf +noao/lib/strip.noao + To the "-allbut" entries listing extensions of files that should not + be stripped, added .mip (just in case). + +sys/etc/envscan.x +unix/boot/bootlib/envinit.c +vms/boot/bootlib/envinit.c + Generalized to permit commented out continuation lines, e.g., + + set blah = "...\ + # ...\ + ..." (3/17) + +pkg/cl/grammar.l + Modified to ignore leading whitespace and comment lines when + processing continuation lines while accumulating a quoted string. + (3/17) + +local/* + Set up a default "template" local package at iraf$local. The new + package is a full-fledged external package containing several sample + tasks. The intent is that a user site will make a copy of the local + directory tree and customize it, changing the hlib$extern.pkg to point + to the new package. The template package has its own LIB, BIN, package + environment, help database, etc. Instructions for customizing the + package are provided in local$src/README. (3/17) + +unix/boot/bootlib/envinit.c +unix/boot/bootlib/osputenv.c + +unix/boot/mkpkg/main.c +vms/boot/bootlib/envinit.c +vms/boot/bootlib/osputenv.c + +vms/boot/mkpkg/main.c + 1. Modified envinit.c to that host environment variables are allowed + to override the values set in the iraf and package zzsetenv.def files. + This is a little dangerous as unintentional redefs are possible, but + makes it possible to modify logical directory names while testing + software. + 2. Added a new call os_putenv to bootlib. The new routine updates + or sets the value of the named variable in the host environment and + VOS environment, if possible. + 3. If MKPKG is called with "symbol=value" arguments these are now + passed to os_putenv (as well as setting the values in the mkpkg symbol + table), so that logical directories can be reset temporarily on the + command line, e.g., "mkpkg -p local local=$iraf/local/". (3/17) + +pkg/images/imarith/imcthreshold.gx -> imcthresh.gx +pkg/images/imarith/generic/imcthreshold.x -> imcthresh.x +pkg/images/imarith/generic/mkpkg +pkg/images/imarith/mkpkg + Renamed imcthreshold.gx as this source file name was longer than 14 + characters. (only long source file name in the entire system). (3/18) + +--------------- +Begin local system updates. (3/18) + +unix/hlib/irafuser.csh + The NOVOS switch was not being done properly. Changed from an + environment variable to a -DNOVOS on the HSI_CF flags list. (3/18) + +unix/boot/bootlib/envinit.c + Added a #ifdef NOVOS case which stubs out _envinit() and causes an + error message to be printed if loadpkgenv() is called when the HSI + is compiled NOVOS. This happens only if an external package is + compiled with the -p package switch before the HSI has been + rebuilt to use VOS filename mapping. (3/18) + +unix/as.sparc/*.c + +unix/as.i386/*.c + + Copied the Sun-3 versions of the unix-optimized (C) VOPS routines + from as.mc68020 to the Sun-4 and Sun-386i AS directories. (3/18) + +unix/os/zlocpr.c +unix/os/zzstrt.c +unix/shlib/edsym.c +unix/shlib/mkpkg.sh + These files had to be modified to move the SunOS-4 HSI back to OS-3. + The preprocessor directive "#elif" is evidently new in OS-4. Added + #ifdef SUNOS4 directives in a couple of places to disable compilation + of shared library code on OS-3 systems, which cannot support shared + libraries. In shlib/mkpkg.sh, added the $HSI_CF flags argument to + the compile command for edsym. (3/18) + + NOTE - Additional testing revealed that in addition to #elif being + new in OS-4, support for the OS-3 construct "#else #ifdef" has been + dropped in OS-4. The only thing that works is + + #ifdef + #else + # ifdef + # endif + #endif + +unix/hlib/login.cl + Made some changes to bring the default login.cl up to date. + Deleted the stdgraph entry, added stdimcur, node, wcsdir, cmbuflen, + min_lenuserarea entries, with reasonable default values (all commented + out as usual), changed some device names to their typical Sun values. + (3/18) + +unix/boot/mkpkg/sflist.c + Corrected some confusion over gettok returning EOF versus TOK_END. + Evidently this only showed up with the OS-3 Sun/IRAF special file list. + (3/18) + +mkpkg +unix/hlib/mkfloat.csh + The OS-3 system did a NOVOS bootstrap and system library sysgen ok, + but when it came to rebuilding the HSI using the VOS the HSI failed + to link due to the mix of fsoft and f68881 objects. I had to rebuild + the HSI NOVOS and start an fsoft system library sysgen, adding fsoft + entries to the root mkpkg and mkfloat.csh. Interestingly, linking + fsoft and f68881 was not a problem on OS-4 (it shouldn't matter anyhow + since none of the HSI executables use floating point). (3/19) + +unix/hlib/mkfloat.csh +noao/mkpkg + Modified mkfloat.csh to permit it to be used on external packages as + well as on the core system. Added entries to the NOAO package mkpkg + to call mkfloat.csh to switch architectures. When an external package + calls mkfloat the list of directories to be modified is given on the + command line as "-d dir1 dir2 ... dirN". This facility is still rather + adhoc and should be generalized further, or replaced with a better + facility. (3/19) + +unix/hlib/mkpkg.sf.S34 + Added optimized as$ C sources to special files list. (3/19) + +local/* + Finished installing the BSWAP demo task. Set up the root mkpkg to + permit "mkpkg ffpa" etc. for this package. (3/19) + +unix/os/irafpath.c + Rather than simply looking for the named file in BIN, will now check + IRAFBIN if the latter is defined. (3/19) + +unix/hlib/cl.csh + Now defines the environment variable "arch" as well as IRAFBIN, before + running the CL. Should be modified to define both in terms of the + machine type. (3/19) + +noao/lib/mkpkg.sf.SUN3 + Added proto/ir/irmatch2d.x to the special file list, to be compiled + with the -P flag on OS-3 to avoid an infinite iropt phase. (3/19) + +pkg/system/help/help.h +pkg/system/help/t_help.x +pkg/system/help/helpdb.x + The "helpdb" file template string was being truncated to SZ_FNAME. + A fixed size string is still used, but the limit has been increased + to 512 chars which should be enough - this is a factor of 8 increase + and anything longer and it will take forever to load all the files + anyhow. (3/20) + +unix/hlib/mkfloat.csh + Now checks to see that the old objects have been successfully archived + before deleting them and restoring the alternate set. (3/20) + +unix/hlib/cl.csh +unix/hlib/login.cl +unix/hlib/zzsetenv.def + 1. The old IRAFBIN mechanism has been replaced by a similar mechanism + using a new environment variable IRAFARCH. This specifies the + architecture of the IRAF binaries to be used, e.g., ffpa, f68881, + i386, sparc, and so on. The variable "arch", which is what is + actually used within IRAF in pathnames such as bin = iraf$bin(arch)/, + is defined by the cl script as ".$IRAFARCH". As before, IRAFARCH is + optional, and if not defined the script will determine the best + set of binaries to be used with the node on which IRAF is being run. + + So, either + + o omit the IRAFARCH definition + o or define it as f68881, ffpa, sparc, i386, etc.: + + setenv IRAFARCH f68881 + + 2. In the login.cl, commented out the "reset bin = ...". + 3. In the zzsetenv.def, changed the definition of "bin" to + iraf$bin(arch)/. (3/20) + +local/lib/zzsetenv.def + Commented out the "set localbin = local$bin(arch)/" and replaced by + "set localbin = local$bin/" as the default, since by default the + template local package has only one BIN. The commented out version + will remain to give a hint to someone customizing the package about + how to implement multiple architecture support. (2/22) + +--------------------- +Begin update of irafx@draco. (3/22) + +vms/hlib/login.cl +vms/hlib/strip.iraf +vms/boot/bootlib/tape.c +vms/boot/bootlib/envinit.c +vms/boot/bootlib/osputenv.c +vms/boot/mkpkg/sflist.c + Did a diff/merge of the VMS/IRAF HSI and updated any files that had + not been updated since the last IRAFX update. (3/22) + +vms/os/zmain.c + For the moment, implemented the command line feature as the null + string, to get the irafx update completed quickly. (3/22) + +local/* + Replaced the customized local in the irafx VMS/IRAF by the template + local, plus a few files like login.com, irafks.com, etc. All the + custom local stuff is gone from the template local, but is still + present on draco in the old frozen "iraf" system. No doubt some + of the old custom local facilities will live on in the VMS/IRAF + kpnolocal, yet to be set up and installed. (3/22) + +sys/imio/iki/qpf/qpfcopypar.x + This routine was setting the image header parameter "blockfactor" + using the qpoe global default value rather than the qpio value, + which may be different if a blocking factor is specified in the + qpoe image kernel section. (3/22) + +--------------------- +irafx updated completed. +begin 386i update. (3/23) +begin OS-3 ffpa sysgen. (3/23) + +unix/hlib/mach.h + 1. Changed the 'e' to 'd' in the exponent of MAX_DOUBLE. + 2. Deleted all the INDEF defines, since these duplicate definitions + already present in the SPP . (3/23) + +unix/hlib/mkfloat.csh + A junk libpkg.a symbolic link caused the save-file verification to + abort, leaving me at first with no clue as to the reason for the + abort. Modified the script to print a diff of the file lists if + they are different, to give some feedback on the reason for an abort + if the architecture change cannot be completed. (3/24) + +unix/mkpkg.sh + Changed the "rm -f as" to "rm -rf as", so that "as", which is supposed + to be a symbolic link can be deleted and rebuilt even if it gets turned + into a real directory. (3/24) + +unix/reboot + + Added this cshell script command to be used to reboot the HSI. + The purpose of the script is to ensure that hlib/irafuser.csh is + sourced to set up the necessary environment variables before the + bootstrap is attempted. (3/24) + +sys/fmtio/gardwrd.x + Fixed a misstatement in the header comment. (3/27) + +unix/shlib/mkshlib.csh + Added .globl entries to the V.s (transfer vector object) code, to + force the MEM common to location zero in the shared image. This + showed up on the 386i following the recent system rebuild and was + a nasty bug to track down. The SunOS memory allocator data structures + were being corrupted due to a memory overwrite occurring as a result + of different values of MEM in the client process and shared image. + (3/27) + +pkg/images/tv/display/imdgetwcs.x +pkg/images/tv/display/imdrcuro.x + Modified imgdetwcs (an internal, restricted use routine) to return + the image name and title string as well as the WCS info. (3/27) + +pkg/images/tv/display/imdwcs.x + Added a little (internal, interim, restricted use) package for + retrieving the WCS information for a display frame, and performing + coordinate transformations between display frame buffer and image + pixel coordinates and vice versa. This will be used in the initial + versions of tasks like IMMARK which need to operate directly upon + the display frame buffer, but which want to work in image pixel + coordinates. (3/27) + +pkg/images/tv/display/imdmapfr.x + Added a new routine imd_mapframe to the interim display interface. + The new routine maps the given frame of the stdimage display device + onto an image descriptor, displaying the frame if indicated and + performing all other initializations required to do image i/o to + the frame buffer. (3/28) + +pkg/images/tv/doc/display.hlp +pkg/images/tv/display/display.par + Changed the default interpolator order to 0 (replicate) for the + DISPLAY task. (3/28) + +unix/sun/imtool.c + Added some graphics color table entries to IMTOOL. The current + allocation of pixel values or "colors" is as follows: + + 0 = white (sunview background color) + 1-200 = data values, windowed + 201 = cursor color (black-white blinking) + + 202 = black # IMTOOL graphics overlay colors + 203 = white + 204 = red + 205 = green + 206 = blue + 207 = yellow (red+green) + 208 = ? (green+blue) + 209 = ? (red+blue) + (etc.) + + 218-254 = reserved for use by other windows + 255 = black (sunview foreground color) + + A frame buffer pixel with the values 202 and up will have the indicated + color, independent of the color enhancement or window-stretch + adjustment for the frame (the latter only affect the greyscale + pixel values 1-200). Blinking graphics can be achieved by using + the cursor color, 201. (3/28,3/30) + +pkg/cl/debug.c + Added cases for some missing opcodes (CONCAT, PRINT, etc.). (3/29) + +sys/libc/cenvget.c +pkg/cl/builtin.c + The CL was limited in the size of environment variable value string it + could handle by 80 character buffers in the LIBC environment code and + in the "show" command in the CL. Increased the size of these buffers + to 512 as an easy fix. Commands such as + + reset helpdb = (envget("helpdb") // ",myhelpfile") + + will work as expected now. (3/29) + +unix/os/zfiotx.c + 1. When opening a file write-only or new-file, will attempt to set + the file mode bits only if opening a regular file (e.g., rather than + a terminal). + 2. Modified ZCLSTX (ZCLSTY) to ignore the error status of fclose() + when closing a terminal, as an error condition is being returned for + some unknown reason when doing direct terminal i/o on SunOS. + The system error is EPERM, but this makes little sense since the + terminal is already open. As far as I can tell the error, if there + really is one, is harmless and may as well be ignored. (3/30) + +vms/boot/bootlib/osputenv.c + Commented out the calls to putenv() - not supported in the VMS HSI. + (3/31) + +---------------------- +Updated orion. (4/2) +Snapshot tape made for CTIO. (4/3) +Updated irafx@draco and serpens. (4/5) + +noao/lib/mkpkg.inc + The mkpkg.sf.SUN3 special file list was being used as the default + for unknown systems; modified to use no special file list if the + system name is not in the list. (4/5) + +unix/sun/imtoolrc +dev/graphcap + Added three new entries: + + imtfs35 full screen, 35 mm aspect ratio + imt128 128 sq + imt256 256 sq + + and modified the imtgec entry to make the x width a multiple of 4, + as is required under SunOS-4. (4/6) + +sys/imio/iki/qpf/qpf.h +sys/imio/iki/qpf/qpfopen.x +sys/imio/iki/qpf/zfioqp.x +sys/qpoe/README +sys/qpoe/mkpkg +sys/qpoe/qpio.h +sys/qpoe/qpiogetrg.x +sys/qpoe/qpioopen.x +sys/qpoe/qpioparse.x +sys/qpoe/qpiosetrg.x + 1. Modified the way the "rect" keyword is handled by QPIO/QPF. The main + change is that the rect is now read out by QPF and used to set the + logical image size; if a rect is specified which references a + subraster of the full QPOE image matrix, IMIO will see a logical image + the size of the rect (scaled by the current blocking factor). + 2. Added a new QPIO routine qpio_getrange, the complement of + qpio_setrange. This is what is used by QPF to determine the rect. + (4/6) + +sys/pmio/pmnewmask.x + Changed the IM_LEN, used to set the size of the new mask, to IM_SVLEN. + The new mask must be the same size as the physical image matrix of the + reference image, independent of any section transformation in effect + for the reference image. (4/10) + +sys/imio/iki/ikirename.x +sys/imio/iki/oif/oifrename.x +sys/imio/iki/stf/stfrename.x + Modified imrename() to permit "in place" image renames, used with + OIF format images to move the pixel file to a new IMDIR. STF was + modified to recognize and ignore an attempt to rename an image + in place (no need to do more since STF doesn't support IMDIR). (4/10) + +--------------------------------------- +Updated orion (Sun-4), serpens (Sun-3 OS3), draco (VMS). (4/12) +Complete rebuild of carina (BSD VAX) in progress and nearly complete. +IRAF/STSDAS beta release tapes cut. (4/12) + +dev/graphcap +dev/termcap + Added entries for dg4010pc, a PC emulator for the Data General + plus 4010 graphics. Contributed by Skip Schaller. (4/13 ShJ) + +sys/imio/iki/ikiaccess.x + As part of the recent imrename() changes, iki_access was modified + to return the root image name as a pathname. This caused problems + on VMS/IRAF, as the pathname returned may contain $[ characters, + yet is passed on to the VOS routine IMMAPZ to open the image header + when renaming or deleting an image. Modified iki_access to escape + any $[ characters in the returned pathname. (4/13) + +------------------------ +Begin merge of revisions from BSD VAX/IRAF update. + +unix/boot/bootlib/osputenv.c + Added #ifdef vax around the putenv() calls, to allow the same file + to be used for BSD/IRAF. (4/13) + +unix/hlib/cl.csh +unix/hlib/irafuser.csh + Isolated the calls to `mach` to a single set MACH = `mach`, to miminize + modifications for other systems like BSD. Added commented out set + MACH = vax to serve as an example. (4/13) + +unix/hlib/libc/xnames.h + Deleted AMOVC definition, since this is already defined in knames.h. + (4/13) + +unix/mkpkg.sh + Replaced three occurrences of `mach` by $MACH; the latter is defined + in $hlib/irafuser.csh, which is always loaded by "reboot" before the + mkpkg.sh is interpreted. (4/13) + +unix/os/zfiobf.c + Added #ifndef O_RDWR around the #include . (4/13) + +unix/os/zzstrt.c + Added #ifdef sun around the #include , , to allow + compilation of this file on systems like BSD that don't use the + shared library facility. (4/13) + + (end of merge of BSD revisions). + ----------------- + +unix/gdev/zfiogd.x + As an experiment, I tried adding a 10 msec delay in the ZFIOGD + data read/write loops, to see if this reduces the frequency of + the imtool/fifo related system crashes we have been experiencing + with the Suns. (4/14) + +unix/hlib/mkpkg.sf.SUN3 + Don't know how it happened, but the entries for the CL files did + not have the $(MACH) in them, and caused an f68881_used error when + recompiled with the ffpa binaries. (4/14) + +vms/gdev/sgidev/sgi2vccp.for + Changed the length of the 'input_file' character string from + 256 to 128. A length greater than 255 causes an error 'illegal + file name specification' from VMS; all other VMS SGI translators + use a 128 character string for 'input_file'. (ShJ 4/21) + +lib/syserrmsg + Restored the error codes for a block of IMIO messages and deleted + a duplicate block of PLIO messages. This was left from an earlier + attempt to insert the new system messages in sequence. The attempt + was later abandoned, thinking that it will be safer to merely append + the new messages at the end. (4/25) + +pkg/images/doc/imhistogram.hlp +pkg/images/imhistogram.par +pkg/images/iminfo/imhistogram.x + 1. In response to overwhelming user demand, a "logy" switch was + added, making log scaling of the y axis optional. + 2. In list output format, the bin value field is now output in the + same units (z1:z2) as when the plot is drawn (formerly the ordinal + bin number was output instead). The value given is that of the start + of the bin, hence the range of each bin is [ x[i] : x[i+1] ). (4/25) + +bin/x_nsppkern.e + +bin/x_stdplot.e - +dev/graphcap +pkg/plot/doc/nsppkern.hlp + +pkg/plot/nsppkern.par +pkg/plot/plot.cl +pkg/plot/plot.hd +pkg/plot/plot.men +sys/gio/sgikern/x_sgikern.x +sys/gio/nsppkern/gktmfopen.x +sys/gio/nsppkern/mkpkg +sys/gio/nsppkern/t_nsppkern.x +sys/gio/nsppkern/x_nsppkern.x + The following changes were made to change plot.stdplot to point to the + SGI kernel rather than the NSPP (NCAR) kernel, i.e., the SGI kernel is + now the default STDPLOT. + + 1. Changed the name of the gio/nsppkern executable from x_stdplot.e + to x_nsppkern.e. + 2. In the graphcap, changed all occurrences of "stdplot" in the NSPP + section of device entries to "nsppkern". Changed the device names + from "ncar_blah" to "nspp_blah" to be consistent. Added a new logical + device "nsppdefault", the default NSPPKERN output device. For NOAO + this is the dicomed (see plot$nsppkern.par). + 3. Added a manual page for the new task NSPPKERN. + 4. Added the new task NSPPKERN to the PLOT package. STDPLOT still + appears as a task but is now equivalent to SGIKERN. In the par file + for nsppkern, changed the default "device" from "stdplot" to + "nsppdefault". + 5. In gio/sgikern/x_sgikern.x, added a task entry "stdplot=sgikern" + to support the new STDPLOT task as a synonym for sgikern. + 6. In gio/nsppkern, changed all occurrences of "stdplot" to "nsppkern". + This involved renaming several files and editing an error message in + one of the files. (4/26) + +sys/vops/ahgm.gx + 1. Deleted the nbins<2 test. + 2. Modified the logic slightly to prevent aliasing of points in the + out of range interval z1-dz:z1 back into the first bin. + 3. Broke the code into two cases, dz == 1.0 and everything else, + to optimize the case where the histogram is computed without scaling. + (4/28) + +pkg/images/imhistogram.x +pkg/images/doc/imhistogram.hlp + 1. In the case of integer data where the range z1:z2 is small (less + than the default histogram resolution nbins or 1024, whichever is + greater), the histogram resolution is now automatically adjusted to + match the resolution of the data, i.e., nbins is set to z2-z1+1. + This results in a "true" histogram and avoids the zero or high-valued + bins that can occur when the histogram oversamples or slightly + undersamples the data range. (The histogram is also computed more + efficiently since dz == 1.0; see note above). + 2. Added an "autoscale" parameter to enable this feature. + 3. If the data resolution exceeds the histogram resolution for integer + data, and autoscaling is enabled, NBINS, Z1, and Z2 will be adjusted + as necessary to map an integral number of pixel values into each + histogram bin, again to avoid aliasing effects. + 4. Added the standard system banner to the plot title, plus a line + giving the values of Z1, Z2, and NBINS. + 5. Added comments to the BUGS section of the manual page to warn the + user about aliasing and smoothing effects. (4/28-29). + +unix/hlib/mkpkg.inc +unix/os/zlocpr.c +unix/shlib/edsym.c +unix/shlib/mkshlib.csh + Finished setting up the sparc version of shared libraries. This was + just a matter of coming up with the necessary sparc assembler for the + transfer vector, and the ZLOCPR code to disassemble the transfer + vector. This was a little harder for the Sun-4 assembler than on + the other Suns due to a useful feature being missing from the + assembler language (I had to use awk instead), and due to the extra + complexities of hi/lo addressing bits and the delay slot. + + The orion executables are linked with the -T symbol-edit flag, which + omits all symbols associated with the shared library. This saves quite + a bit of space in the symbol table of each executable, but may be + confusing if anyone happens to debug these executables. + + The BIN sizes are + + S.e 1.2 Mb + bin 3.2 Mb (excluding S.e) + noao.bin 3.7 Mb + + for a total of only 8.1 Mb for the full system! (4/29) + +unix/boot/xyacc/files + Changed the definition of the iraf root, which is evidently wired + into this program. (4/30) + +sys/gio/nspp/portlib/*.f +sys/gio/nspp/sysint/mkpkg +sys/gio/nspp/sysint/packum.x +sys/gio/nspp/sysint/nspp.com +sys/gio/nsppkern/gktinit.x +sys/gio/nsppkern/nspp.com +sys/gio/nsppkern/*.f + Modified the NSPP interface to make byteswapping of the output + metacode a graphcap rather than compile time option. Including "BS" + in the graphcap entry for an NSPP logical device causes the output + ncar metacode to be byteswapped. (5/2) + +unix/os/alloc.c + Changed several hlib references to hbin to reflect the new directory + of residence of alloc.e (5/2) + +dev/hosts [tucana, orion] +dev/uhosts [tucana, orion] + Added node "omega", a new IR diskfull Sun-3. (5/3 SRo) + +unix/boot/spp/xc.c + Added a #ifdef SUNOS4, to make linking with the shared libraries the + default only on OS4. (5/5) + +dev/uhosts [all available systems] + Updated to reflect changed internet addresses (downtown noao shuffle). + (5/10 SRo) + +unix/boot/spp/xpp/decl.c +vms/boot/spp/xpp/decl.c + Added a "break;" after the error message "missing right bracket...". + An infinite sequence of error messages would otherwise result. (5/10) + +unix/gdev/zfiogd.x + 1. Modified both ZARDGD and ZAWRGD to timeout after an interval if + a transfer cannot be completed, e.g., because the server has died. + 2. Modified ZAWRGD to tolerate writes that return a status 0 (no + data sent). Formerly this could result in a 0 write status being + returned to the caller, which in the case tested was causing the + kernel server to abort while writing to IMTOOL. (5/14) + +sys/ki/irafks.x + 1. Added a new feature to the kernel server to facilitate debugging. + The detached process command line syntax is now used (as a bit of a + trick) to enable debug mode on the command line, i.e., "-d debugfile" + causes debug messages to be appended at runtime to "debugfile" on the + server. This would be enabled by modifing the dev$hosts entry for + the server to add the debug arguments to the command used to start + the server, assuming that the network interface in use can pass + command line arguments on to the server (this is not required and is + not necessarily the case). Relinking the server with DEBUG=YES is + always possible if this other technique doesn't work. + + 2. Added a couple of calls to flush to the debug code, used to output + messages logging kernel server requests when running the server in + debug mode. (5/16) + +unix/gdev/zfiogd.x + Modified the amount of data sent per transfer when moving a large block + of data through a FIFO from 4096 to 4000 bytes. It appears that use + of a transfer size of 4096 bytes, which is the same size as the FIFO + buffer used in the SunOS kernel, may activate a bug in the SunOS FIFO + code leading to premature deallocation of the FIFO kernel data buffer + under some circumstances. This may cause an i/o error on the FIFO and + always results eventually in a panic reboot of the host system when + the FIFO file is closed, due to an attempt to free an already freed + buffer, which can cause either a kernel bus error or kmem_free panic + depending upon memory dynamics. I don't know if changing the transfer + size to 4000 will avoid this bug but it worked in one test case. + (5/16) + +unix/sun/imtool.c + 1. Changed the fifo i/o transfer size from 4096 to 4000. + 2. Fixed a bug that was preventing large multi buffer fifo i/o + transfers from timing out in the event that the client dies during + a transfer. + 3. Deleted the code which would cause IMTOOL to shut down if + synchronization of the data stream is lost (thereby guaranteeing + that things get initialized). Users would invariably interpret + this as "IMTOOL crashed". Now it should continue running, printing + nasty messages to the console, until either synchronization is + reestablished or the user manually kills and restarts IMTOOL. (5/16) + +unix/sun/fifo.c + + Added this new debug program to the SunView support package. It is + a server process like IMTOOL which emulates the IMTOOL client-server + command datastream, operating upon a fixed size 512 sq. frame buffer + maintained as an array in process memory - the window system is not + used, but the process looks to the client like an IMTOOL server. + All datastream requests received from the client are logged to the + stderr output. This is used to debug datastream and FIFO i/o. + (5/16) + +unix/os/zfiobf.c + Changed the #ifndef O_RDWR to #ifndef O_NDELAY, since the latter is + what is defined in . (5/16) + +------------------ +Rebooted and relinked tucana, and did an incremental update of orion for +further IMTOOL crash testing. (5/16) +Updated pegasus (386i). (5/17) + +unix/hlib/zzsetenv.def + Added defs for fmio,qpoe,plio,pmio to the zzsetenv.def, since we + already have defs for the other system directories. (5/18) + +sys/fio/fioclean.x + Added a call to fcanpb to cancel any pushback, in the status != OK + part of fio_qflush(). It is necessary to cancel any pushback before + messing with the i/o pointers the way fio_qflush() does. (5/18) + +pkg/cl/modes.c + Modified the part of the image cursor read code which text encodes + the cursor value to use a 0.3f instead of 0.6g format to encode the + cursor value, since for the image cursor the range of x,y values is + well defined. This was done because I was seeing occasionally + off-by-one integer cursor values printed out, which I suspect were + due to some kind of integer truncation effect (2.999 -> 2) occuring + during all the encode-decode steps currently involved in a cursor + read. (5/24) + +sys/imio/imdmap.x + Modified to pass a flag in the image descriptor for the mapped display, + telling whether or not the display is a server device. (5/24) + +pkg/images/tv/display/iis.com +pkg/images/tv/display/iis.h +pkg/images/tv/display/iisio.x +pkg/images/tv/display/iisopn.x +pkg/images/tv/display/imdgetwcs.x +pkg/images/tv/display/imdrcuro.x +pkg/images/tv/display/imdsetwcs.x +pkg/images/tv/display/imdwcs.x +pkg/images/tv/display/mkpkg +pkg/images/tv/display/t_dcontrol.x +pkg/images/tv/display/t_display.x +pkg/images/tv/display/zdisplay.h + 1. Modified the display program to support the new datastream WCS + feature added to IMTOOL (see below). If this is used the WCS + information is passed via the datastream rather than via the old + WCS file in the "WCSDIR". The datastream-WCS is enabled if the + device has the LC capability in the graphcap, indicating that it + is a server device. The WCS file is still written to the WCSDIR + if the LC capability is not found. + 2. The IMD code (imd_getwcs) was similarly modified to retrieve the + WCS from the server, rather than trying to read the old WCS file, + if the display device is a server. (5/24) + +unix/sun/imtool.c + 1. The WCS is now passed in and out via the datastream to the client, + rather than via the old WCS file. This should eliminate any problems + with the WCS being "lost" due to concurrent process synchronization + problems. + 2. The set-WCS sequence is now also used to set the frame buffer + configuration, and every display frame load is preceeded by a set-WCS. + This eliminates the bug where turning off frame erase followed by a + reset stdimage could cause the client and server to have different + notions of the frame buffer size, causing skewed images or worse. + The frame number is now incremented by the set-WCS rather than by + frame erase. + 3. IMTOOL now opens the output datastream at startup time and keeps + it open permanently, like the input datastream. This eliminates + possible race conditions that could lead to an open error on the + output datastream, possibly causing IMTOOL termination or an i/o + error in the client. + + 4. The major feature added in this version of IMTOOL is zoom (this + is closely related to pan which was added some time ago). Both zoom + and pan are controlled by the middle mouse button. Moving the mouse + to an image feature and pressing the middle mouse button causes that + feature to be moved (panned) to the center of the display, as before. + Pressing the button *again*, without moving the mouse, now causes + the display to be zoomed about the position of the cursor. Each + time the button is pressed the zoom factor changes, until it wraps + back around to one. The set of zoom factors is controlled by the + setup panel, with the default set being 1,2,4,8. + + Zooming is very fast, even in a full screen window, so it is no + problem to cycle through the zoom factors to magnify a feature and + then return to the unzoomed image to see where the feature is, or + select a new region to be zoomed. The mouse always tracks the + feature as the zoom factor changes, making it easy to determine + where a feature is when returning to the unzoomed image from a full + zoom somehwere in the image. + + Zoom is a server feature, transparent to the client, which sees only + the fixed size frame buffer. Hence a program like TVMARK can be + used to edit the frame buffer (draw color graphics) regardless of the + zoom factor. In most cases it will be best to, for example, use the + smallest character font for graphics, relying upon zoom to magnify + the text for easier reading. + + For performance reasons, zoom and pan is implemented by writing to + the raw frame buffer. For the most part this is transparent to the + user, but since all clipping and locking is bypassed one can create + situations where the screen does not fully represent normal reality. + Redisplaying the screen, or even panning the display window slightly, + will normally fix this. Such problems can be avoided by resizing + the display window so that it does not overlap other windows. + (5/24) + +--------------------- +Updated orion, irafx@draco. (5/27) + +unix/sun/imtool.c + Register wasn't working with zoom; was copying the offset and zoom + factors for a frame but not doing other things, such as zoom the WCS. + (5/29) + +sys/imio/iki/oif/oifgpfn.x + This routine, used to get the pixel file pathname for an image, + was assuming that the header file name was a virtual filename. + This was no problem in the case of simple concatenatable pixel + file name, but in the case of a name such as HDR$pixels/, the + name "pixels/file.pix" was being concatenated to the root pathname + of the header file, producing an illegal filename for VMS, although + it would work for UNIX since the / is acceptable in a UNIX pathname. + Modified to always work with the host pathname equivalent of the + header file root, using zfsubd to fold in any subdirectories found + after the HDR$. (5/30) + +sys/imio/iki/ikiaccess.x + In the modification to "imrename" some weeks ago, this routine was + modified to use the host pathname equivalent of the image name. + This was the reason the above bug (and others fixed earlier) were + discovered. Since presumably these bugs must have been there all + along, since the user could easily enter a host pathname to reference + an image, I have been fixing the second order bugs rather than + modifying imaccess to avoid the host pathname. + + The latest bug is in the generation of this pathname itself. It is + the pathname of the root image path name which is computed, with the + extension stripped. This would fail on VMS if the image name had + extra . delimited fields, e.g., "image.1234.imh", since with the + extension strippped off the pathname would be computed assuming that + the .1234 is the pathname. When later the real extension was added, + and invalid VMS filename would result. (5/30) + +sys/etc/prpsio.x +sys/gio/cursor/gtrctrl.x + The following changes were made to fix the bug of the CL hanging when + appending to STDPLOT, or appending to a redirected graphics stream. + + 1. The CL would hang because output to the pseudofile i/o controller + was being discarded when writing to a redirected graphics stream, + causing the CL to ignore the GETWCS request from the applications + process, which would result in both processes simultaneously waiting + for command input. PRPSIO was interpreting both 1) redirection to a + disk file, e.g, >G, and 2) redirection to a graphics kernel IPC + channel, e.g., when writing to STDPLOT, as redirect cases. + The fix was to simply remove the check for a redirected stream, + leaving it up to the pseudofile i/o controller to decide whether + to ignore the requests. + + 2. Modified the pseudofile i/o controller to properly handle control + requests for a redirected graphics stream. In particular, PUTWCS + and GETWCS are handled even if the stream is redirected to a file. + (5/31) + +sys/imio/db/idbfind.x +sys/imfort/db/idbfind.x + In the third case, fixed length cards and a simple keyword with no + metacharacters, 'recno' was not being incremented for each card, + causing the wrong record number to be returned. (5/31) + +dev/graphcap +dev/cacheg.dat +dev/cachet.dat + Fixed a really subtle bug in the standard Tek (4012) graphcap which + could result in vector data not being drawn when expected. What was + happening is that a vector sequence would be output as GS pt-...-pt, + i.e., the last thing output to the terminal was a graphics vector + point. An image cursor read was then performed with the confusing + result: no graphics vector! What was happening was that the terminal + (gterm in this case, but it could happen with any terminal) was still + in vector-accumulate mode, waiting for the next tek-encoded point of + the vector. This is not normally a problem because most interaction + is via the terminal, and any other type of output to the terminal + would terminate and draw the vector sequence. The fix was to add + the DE (draw-end) sequence to the 4012 graphcap, to output a GS at + the end of each polyline draw sequence. This is harmless but as a + control code, serves to terminate vector-accumulate mode. (5/31) + +sys/imfort/oif.h +sys/imfort/imrnam.x +sys/imfort/imcrex.x +sys/imfort/imfgpfn.x +sys/imfort/imfdir.x + +sys/imfort/mkpkg + IMFORT has been modified to permit specification of the pixel file + directory by the calling program. The modifications are completely + upwards compatible, i.e., existing programs linked with the new + interface will still create pixel files in the same directory as + the header file, with "HDR$" in the image header. + + The Fortran programmer may set or query the pixel file directory + using the following routines: + + imsdir (dir) # set pixel directory pathname + imgdir (dir) # get pixel directory pathname + + where `dir' is a Fortran character variable. The value should + be either "HDR$" (the default) or a concatenatable host directory + pathname (i.e., trailing / required for unix). Once set, the + pixel directory will be used for all subsequent image create or + rename operations by the calling process. + + For example, + + call imsdir ("/tmp3/pixels/") + call imcrea (image1, axlen, naxis, dtype, ier) + call imcrea (image2, axlen, naxis, dtype, ier) + + If desired the default pixel directory may be specified in the + host environment as `imdir' or `IMDIR' before running the program. + IMFORT will check the host environment for this environment variable + then use "HDR$" as the default if no host definition is found. + + Note that although this is similar to setting the value of `imdir' + in the IRAF environment, IMFORT programs are not part of the IRAF + environment and are not affected by changes to the IRAF `imdir'. + Also, since IMFORT is a host level facility and IRAF networking is + not supported, the network prefix (e.g., "node!") is omitted, + and since IMFORT programs are not necessarily used in conjunction + with IRAF, the ".." files are not used to protect against image + deletion. (6/1) + +sys/imfort/clargs.x + Upped the size of the token buffer from SZ_FNAME to SZ_CMDLINE, + to avoid truncating long string tokens. (6/1) + +sys/imfort/db/impstr.x + Modified to allocate the entire card to string values longer than + 21 chars (for string valued cards only). (6/1) + +sys/imfort/doc/TODO + + Added a note to document the new im[gs]dir routines the next time + the IMFORT docs are updated. (6/1) + +sys/imfort/tasks/tasks.cl + Changed the iraf root in this debug file from /iraf to /usr/iraf. + (6/1) + +sys/imfort/tasks/tasks.cl +sys/imfort/tasks/mkim.f + Added a fifth argument "pixdir" to MKIM (in both files), and a + call to IMSDIR if pixdir is given on the mkim command line. + If it is not given on the command line, no query is generated and + the default is used. Ran some tests and everything appears to be + working. (6/1) + +unix/sun/imtool.c +unix/sun/imtool.man + 1. Changed the default cursor marker to "none", i.e., by default a + cursor read will not make a mark on the screen. This is more + appropriate now that we have more programs that read the interactive + image cursor, and the user can still enable marking if they with. + 2. Blinking may now be controlled manually by typing ctrl/b while + the mouse is in the imtool window. This is similar to ctrl/f + (next frame, the "alternate" key on a Sun-3 keyboard) or ctrl/r + (previous frame), except that only the frames in the blink list + will be displayed. + 3. The F4 key may now be used (in addition to the frame menu) to call + up the setup panel. (6/2) + +unix/sun/imtool.c + Looked up a color table and further extended the set of preassigned + IMTOOL graphics colors. The full set is now as follows: + + 0 = sunview background color (normally white) + 1-200 = frame buffer data values, windowed + 201 = cursor color (white) + + 202 = black + 203 = white + 204 = red + 205 = green + 206 = blue + 207 = yellow + 208 = cyan + 209 = magenta + 210 = coral + 211 = maroon + 212 = orange + 213 = khaki + 214 = orchid + 215 = turquoise + 216 = violet + 217 = wheat + + 218-254 = reserved for use by other windows + 255 = black (sunview foreground color) + + Normally we would not publish such magic pixel values, but at present + one must know these numbers to select colors for prototype display + editing tasks such as TVMARK. As before, only the frame buffer pixels + (grelevels 1-200) are windowed, hence the graphics colors will remain + constant regardless of how the image is windowed. (6/3) + +lib/fio.h +lib/fset.h +sys/fio/fseti.x +sys/fio/fstati.x +sys/tty/ttygsize.x +sys/tty/ttyread.x +unix/hlib/libc/fset.h +unix/hlib/libc/kernel.h +unix/hlib/libc/stdio.h +unix/os/zfiobf.c +unix/os/zfiotx.c + The following changes were made with the immediate motivation of + eliminating the problem of STTY, HELP, etc. hanging up indefinitely + when the terminal type is set to gterm but the actual terminal is + something different, causing the screen size query to be ignored. + The solution was to have the screen size query time out after a + reasonable interval (currently 1 second). + + Unfortunately there was no easy way to implement such a timeout, + so I had to do it by extending FIO to support nonblocking reads when + reading from a terminal in raw mode. This is a very powerful + facility, permitting not only things like timeouts when waiting + for input, but also polling of the terminal for user commands from + within compute intensive applications, without having to suspend + execution waiting for a command to be typed, permitting new types + of interactive user interfaces to be developed. My main worry in + supporting this in the VOS is that it may be difficult to implement + on some systems, but since this is not an essential capability and + it can be implemented in both UNIX and VMS as well as most other + modern systems, this is proably not a serious problem. + + 1. Added a new flag F_NDELAY to . This is used in conjunction + with F_RAW to enable nonblocking reads from a terminal in raw mode. + For example, + + call fseti (fd, F_RAW, YES) + + enables conventional blocking, single character raw mode reads, and + + call fseti (fd, F_RAW, YES + F_NDELAY) + + enables nonblocking raw mode input (YES, NO, and F_NDELAY are bit + flags). These modes are mutually exclusive, e.g., the first call may + be issued while nonblocking raw mode is in effect to make the reads + block, and vice versa. A call to fset(fd,F_RAW,NO) disables both + raw mode and F_NDELAY. + + Once nonblocking raw mode is in effect one merely reads characters + from the terminal in the usual way, using GETC or GETCI. EOF is + returned if a read is performed when no data is available for input, + otherwise the next character is returned from the input queue. + Normally one would compute for a while or call ZWMSEC to wait a few + milliseconds, then poll the terminal again with GETC. If nonblocking + i/o is not supported for a given device or host operating system the + GETC call should take an error exit until F_NDELAY is cleared for the + stream. Although the use of EOF looks ambiguous, there should be + no ambiguity for interactive applications since ctrl/d, ctrl/z, ctrl/c, + etc. are returned as data characters when reading from the terminal + in raw mode. + + 2. The UNIX host level terminal (and text file) driver ZFIOTX was + modified to implement nonblocking raw i/o. Upon receipt of the RAWON + sequence to initiate raw mode, the driver will now check for a + following N or B character to determine if nonblocking (N) or blocking + (B) raw i/o is desired. + + 3. TTYREAD, used by ttygsize to read from the terminal in raw mode, + was modified to perform the read in nonblocking raw mode, possibly + timing out after an interval in milliseconds specified by the calling + program. If the timeout interval is given as zero a normal blocking + read (infinite timeout interval) is performed. TTYGSIZE was modified + to call ttyread with a timeout interval of 1 second, and to print a + warning message if the read times out or otherwise fails to return + a valid screen size response for some reason. Note that the screen + size query is only generated if the `qs' parameter is present in the + termcap entry for the device. + (6/3) + +unix/hlib/login.cl +vms/hlib/login.cl + Deleted the "hit return if this hangs" message recently added to + the template login.cl files (along with the notes file entry for + same), since the timeout facility described above is a better + solution to the problem. (6/3) + +vms/os/zfioty.c + Modified the VMS/IRAF terminal driver to support the new nonblocking + raw mode read feature. This was done by using a special QIO request + to query the number of characters of typeahead, performing a blocking + read only if data is present in the typeahead buffer. In the case of + UNIX, a nonblocking read is used, i.e., the read returns immediately if + no data is present in the typeahead buffer. Both techniques accomplish + the same thing fairly easily (a few years ago it would have been + quite a trick to implement this feature on either system). (6/3) + +unix/hlib/cl.csh +unix/hlib/buglog.csh +unix/hlib/irafuser.csh +unix/hlib/mkiraf.csh + Changed all occurrences of $iraf/, $hlib/, etc., to ${iraf}, ${hlib}, + etc., to avoid the double // which has a history of confusing users. + The disadvantage is that file accesses will fail if $iraf, $hlib, etc. + do not end in a /, but that can already happen in some cases anyhow. + (6/4) + +unix/os/zzstrt.c +unix/shlib/mkshlib.csh + The shared library facility was modified to add a word to the shared + image header identifying the machine architecture for which the image + was linked. At process startup time, ZZSTRT checks to see if IRAFBIN + is defined in the process environment, and if it hasn't been defined, + defines IRAFBIN and possibly IRAFARCH to match the architecture of + the shared library with which the process was linked. This is + necessary in cases such as running an iraf process (e.g., irafks.e) + via the network, where no IRAF environment variables will have been + defined, and iraf$bin may point to a different architecture BIN than + that of the process being run. (6/4) + +unix/os/irafpath.c + Modified irafpath (called by the HSI utilities to locate system files) + to use IRAFARCH rather than IRAFBIN to locate the system BIN directory + for the desired architecture. (6/4) + +unix/boot/bootlib/mkpkg +unix/boot/bootlib/ossettime.c +unix/boot/bootlib/ossymlink.c + + 1. Added a new bootlib routine os_symlink, used to test if a file is + a symbolic link, and if so conditionally return the link value. + 2. Fixed a bug in os_settime, which would prevent it from setting + the modify time on files restored to disk with WTAR. It appears + that this feature must never have worked. (6/4) + +unix/boot/rmbin/rmbin.c + Modified RMBIN to check for and ignore symbolic links. Since symbolic + links are now used routinely as part of Sun/IRAF to implement support + for multiple architectures, we don't want rmbin deleting them, or + jumping outside a directory tree to follow links looking for files to + delete. (6/4) + +unix/boot/rtar/rtar.c +unix/boot/wtar/wtar.c + Modifed WTAR/RTAR to treat symbolic links properly, i.e., they are + saved in the archive as links and restored as links, rather than + saving or descending into files possibly outside the directory tree + being archived. (6/4) + +unix/bin + +unix/mkpkg.sh +unix/os/mkpkg.sh +unix/bootlib/mkpkg.sh +unix/hlib/libos.a -> unix/bin/libos.a +unix/hlib/libboot.a -> unix/bin/libboot.a + 1. As part of the support for multiple architectures are compile time, + the HLIB libraries libos.a and libboot.a were moved to bin.mc68020, + and a symbolic link host$bin was added to point to this new BIN. + 2. The file host$mkpkg.sh, called at the beginning of a bootstrap, + was modified to create the link host$bin pointing to the BIN for the + architecture for which the HSI is being compiled. + 3. The os and bootlib mkpkg.sh files now move the libraries into + HBIN rather than HLIB to avoid clobbering the links in HLIB. (6/4) + +unix/shlib/mkpkg +lib/libmain.o -> bin/libmain.o +lib/lib*.a -> bin/lib*.a +bin/OBJS.arc + As part of the support for multiple architectures are compile time, + these architecture dependent files were moved from LIB to BIN for + the core system architecture, being replaced by ../bin symbolic + links in LIB. This makes the files still appear to be in LIB, + allowing the mkpkg "$checkout file lib$" style commands to continue + to function for core system maintenance. The use of ../bin links + means that the LIB links do not have to be modified when the core + system architecture is changed, since the BIN link suffices to + select the correct architecture libraries. + + The OBJS.arc files no longer contain any of the LIB files, since the + latter now permanently reside as files in the BIN. This automatically + provides the ability to link external (non core system) programs or + packages for any supported architecture, since the system (irafpath) + searched the IRAFARCH BIN and HBIN before searching LIB and HLIB. + + To develop software for a given architecture one need only define + IRAFARCH in their UNIX environment, and compiling, linking, and + execution of the resultant executables will proceed as expected. + On Sun-3 systems one must also define FLOAT_OPTION, which should + have the same value as IRAFARCH. + + For example, one could put the following in their .login file: + + alias setarch 'setenv IRAFARCH \!*; setenv FLOAT_OPTION \!*' + setarch f68881 + + Then typing "setarch ffpa" before compiling a program from scratch + will cause an ffpa program to be compiled. This should work for + IMFORT programs compiled with FC as well as IRAF/SPP programs. + + An added benefit of this revision is that the OBJS.arc file is much + smaller, and changing the architecture of the core system, e.g., + with "mkpkg ffpa" is somewhat faster. External packages which are + configured to support multiple architectures should be set up the + same way if their LIB contains any architecture dependent files + (the noao LIB doesn't). (6/4) + +mkpkg +bin.pg + +sys/mkpkg +unix/hlib/mkpkg.inc +unix/shlib/mkshlib.csh + Added a new architecture option "pg". This provides a -pg profiled + version of the system libraries and objects for profiling applications + programs with "gprof" (will only be supported on the tucana development + system). (6/5) + +unix/os/zzstrt.c +unix/os/zxwhen.c + Modified these files to configure the IEEE hardware properly for IRAF + programs, using the new facilities available in recent versions of + SunOS, i.e., ieee_flags() and ieee_handler(). By default the IEEE + hardware is now configured, on all Sun systems, with the invalid, + overflow, and divzero IEEE exceptions enabled, and with the default + rounding direction and precision modes (nearest, extended) in effect. + This configuration should ensure that all questionable floating + point operations are detected, and that no IEEE "funny numbers" + (NaN, Inf, etc.) get into the data. + + If desired, one can change the default rounding direction and + precision (e.g., to test the numerical stability of applications) + by using the debugger to set a nonzero value of the variable + "debug_ieee" before running an executable. The defined bitflags + are as follows (in octal): + + 0001 /* round toward nearest */ + 0002 /* round toward zero */ + 0004 /* round toward negative infinity */ + 0010 /* round toward positive infinity */ + 0020 /* round to extended precision */ + 0040 /* round to ieee double precision */ + 0100 /* round to ieee single precision */ + + For example, + + % adb -w xx.e + debug_ieee?w 0o104 + + would set round toward negative infinity, single precision. + The sun-defined default at process startup is equivalent to 021. + (6/5+sro) + +pkg/images/tv/display/imdrcur.x + Modified to use stg_putline/stg_getline to implement i/o to the + terminal for colon command queries, to ensure proper interaction + with the graphics device when image cursor reads and graphics are + mixed. It might be better, though, to deactivate the workstation + before reading the image cursor so that image cursor colon queries + are consistently handled by the text window. In the future image + cursor colon queries will appear on the "status line" of the display + window, as for a graphics cursor colon command, but in the meantime + the text window is used. (6/5) + +unix/hlib/libc/kernel.h +unix/os/zfiotx.c +unix/os/zfiopr.c +unix/os/zfiomt.c +unix/os/zfioks.c +unix/os/zfiobf.c +unix/os/zoscmd.c +unix/os/zopdpr.c + 1. Delete the _NFILE definition from kernel.h and changed all + references to this definition to use MAXOFILES instead. A fixed + allocation of MAXOFILES=64 kernel file descriptors is now allocated, + rather than trying to set the value appropriate for the host OS, + which is too prone to error. + 2. In several of the device drivers there were arrays such as + pr_ionbytes[fd], etc., which appeared to duplicate storage already + available in the kernel file descriptor array. Changed these to + use the kernel file descriptors instead, e.g., zfd[fd].nbytes, since + once a host file descriptor is assigned to any driver it is reserved + and cannot be used elsewhere. + 3. To every open procedure in the device drivers, which calls a host + routine to open a file descriptor, I added code to check that the + resultant descriptor is less than MAXOFILES, to prevent overflow of + the descriptor array if a given host system should happen to have + more per-process file descriptors than the statically allocated + iraf descriptor array can handle. It would be possible to modify + the kernel to query the host system at startup time and dynamically + allocate the descriptor array, but I don't think such modifications + are worth the effort and risk at the present time. (6/6) + +unix/boot/spp/xc.c + Following the recommendation of the Sun docs, changed the host library + link sequence in XC from "-lF77 -lI77 -lm" to "-lm -lF77 -lI77 -lm". + Although we could not see any difference in testing, this can + reportedly result in use of objects from -lm which are compiled for + the current floating point option, whereas the equivalent modules + in -lF77 are compiled for software floating point. In all the cases + examined of executables linked with the standard library sequence + I could not find any software floating point, but there is indeed + only one -lF77, rather than one for each float option as in the case + of -lm, and it cannot hurt to try this. (6/6) + +unix/os/zzstrt.c +unix/boot/bootlib/vfn2osfn.c + I added a call abrupt_underflow() to ZZSTRT, called during process + startup to configure the IEEE hardware, among other things. The call + to abrupt_underflow causes machines equipped with Weitek floating point + hardware to convert subnormal results or operands (numbers smaller than + can be represented within the machine precision) to underflow abruptly + to zero, rather than signalling the host cpu for recomputation via a + software exception handler to compute the correct IEEE value. This is + contrary to the IEEE standard, but consistent the behavior of most + non-IEEE floating point hardware, and much faster, e.g., if software + recomputation is not disabled, in certain pathological cases a code + which normally takes 10 seconds to execute might instead take 3 hours! + (6/6) + +vms/hlib/gripes.cl + Changed an "iraf@lyra" to "iraf@noao". (6/6) + +unix/os/zxhwen.c + The new IEEE stuff didn't work for the ffpa version of the system - + the FPE_FPA_ERROR exception was not being caught, but was instead + being dealt with by ieee_handler/sigfpe by an abort with core dump. + This exception is routinely generated during process startup to + initialize the hardware; it was causing ffpa executables to abort + with a core dump during process startup. Upon more careful examination + it is evident that ieee_handler only traps some of the FPA exceptions + (the IEEE standard ones), with the rest all causing the default + action of abort with a core dump. This is hardly what IRAF wants - + we want to trap all FPA exceptions - so I went back to the old + version of ZXWHEN, which uses SIGNAL to post an iraf handler to + intercept all FPE exceptions, IEEE standard or otherwise. + + A call to ieee_flags in ZZSTRT is still used to enable the special + IEEE exceptions (divzero etc.) at startup time. I don't think there + will be any problem with this, as it is clear that ieee_flags can be + used to just set flags in the fpu hardware, while signal/sigfpe + perform the complementary action of posting exception handlers. + The call to ieee_flags in ZZSTRT enables the IEEE exceptions and + posts the standard abort exception handler to catch them; a later + call to signal in ZXWHEN replaces the abort handler by the iraf + handler for the IEEE exceptions, and posts the iraf handler for the + remaining SIGFPE exceptions as well, including all those ignored by + ieee_handler. (6/7) + +unix/os/zxwhen.c + Updated the list of hardware exception codes and associated error + messages to include a couple new sparc codes, all the 386i codes + (previously omitted it appears), and a few miscellaneous codes. + (6/7) + +unix/os/alloc.c + This routine had a security loophole that could allow any user to + get read/write access to any file in /dev. The fix, in the deallocate + code, was to do nothing to the file if it is already owned by root. + If the file is not owned by root, then it can be "deallocated" only + if it is owned by the user. Since a file can be "allocated" to a + user only if the file is owned by root and has mode 666, it does not + appear that there are any security loopholes left. (6/7) + +unix/hlib/mkpkg.inc +unix/hlib/mkfloat.csh + Changed the statement + + $set MACH = f68881 (or whatever) + + in hlib$mkpkg.inc, to + + $set MACH = $(IRAFARCH) + + i.e., the mkpkg architecture option now defaults to whatever the + user has set in their environment (or on the mkpkg command line), + rather than tracking the current architecture of the core system, + which is irrelevant for an external package if multiple architecture + support means anything. Commented out the statements in mkfloat.csh + which edit mkpkg.inc to set the default architecture. (6/7) + +noao/mkpkg +noao/bin.pg + + Added a bin.pg (-pg profiled version of the noao binaries) to noao, + to save having to recompile entire packages if anyone should ever + want to profile an noao task. Also added an entry for the i386 + architecture to the mkpkg. (6/7) + +pkg/system/references.cl + +pkg/system/doc/references.hlp + +pkg/system/system.cl +pkg/system/system.men +pkg/system/system.hd + Added a new task REFERENCES to the system package. References is + used to search the help database for all tasks or other help modules + pertaining to a given topic (like the old BSD apropos). By default + the entire help database is searched at runtime, but a quick-reference + file may be prepared and used to speed further searches if desired. + (6/7) + +pkg/system/help/t_hdbexamine.x + Increased the size of the "helpdb" buffer from SZ_FNAME to 256 chars, + to avoid truncation of the helpdb value which is now a list of files + rather than a single file. (6/8) + +----------------- +Updated orion (includes bug fixes below). (6/8-9) + +unix/os/zfiopr.c + The new version of this file is failing with an apparent optimizer + bug on the Sun-4, though it has been in use without problem on the + Sun-3 for several days. Lacking time to investigate further, and + since the revison was minor, I have restored the original version + for now. (6/9) + +pkg/system/system.cl +pkg/system/references.cl + 1. The SYSTEM package now loads the LISTS package. + 2. The REFERENCES task was modified to run the one-liner output + through sort|uniq to get rid of duplicate entries in the "help *." + output (these are due to a bug which it is too risky to fix this + close to a major release). This also has the advantage of producing + a nice sorted output. (6/9) + +----------------- +Updated irafx@draco. (6/9) +Updated 386i. (6/11) + +dev/termcap + Added "vt35", a 35-line vt100 emulator compatible with Apollo's + vtserver in a (746,700) pad. (6/13 SRo) + +dev/termcap +dev/graphcap +dev/devices.hlp + Added entries as suggested by Joe Harrington, MIT Planetary Science + Group. A default printer was added to graphcap, as determined + by the lpr program without specifying a -P argument. Also added + a psdump facility, where the PostScript file is dumped to a file + in /tmp. Added to termcap a default printer and a device 'enscript', + which prints output from the UNIX enscript program on the default + printer. The default printer was added to devices.hlp. (6/15 ShJ) + +dev/termcap +dev/graphcap + Cleaned up XTERM entries, including submissions from Rick McGonegal + and Joe Harrington (chose McGonegal's model, status line in graphics + window, as default). Renamed old xterm entries for kludged X10 ixterm + to "xterm-old". Note for Ultrix installation guide. New entries + should work with all normal, vendor-supplied X11 xterms (except for + brain-damaged X11R2), but not with kludged ixterm. NOTE: Must + re-cache after testing, before cutting tapes! (6/15 SRo + ShJ) + +vms/uis/* + + Added a new directory UIS off iraf$vms, containing the NEWUISDISP + program for displaying images under the VMS UIS window system. (6/16) + +unix/os/zzstrt.c + Modified the startup code to redefine IRAFARCH if it is defined but + does not match the architecture of the executable being run, i.e., + IRAFARCH is defined as f68881, but one runs $iraf/bin.ffpa/x_system.e. + Formerly this would cause the shared library code to attempt to use + the f68881 shared image with the ffpa executable, causing the process + to core dump. It will work properly now, but IRAFARCH is redefined + for the process being run and any of its children. (6/16) + +sys/tty/ttygsize.x +sys/tty/ttyread.x + Made some changes to reduce the probability of the "timeout - terminal + type set wrong?" warning message appearing except when the terminal + type really is set wrong. The warning message could be improperly + issued either if the timeout interval was too short, or if the read + was garbled (more likely), e.g., by the user typing during the read. + ttyread was modified to discriminate between a timeout (status 0) and + a garbled read (status ERR). ttygsize was modified to increase the + timeout interval from 1 to 2 seconds, and to issue the timeout message + only if a timeout actually occurs. Garbled reads are ignored, with + the expectation that a subsequent screen size query will either succeed + or timeout successfully and warn the user about the terminal type if + it is set wrong. (6/17) + +pkg/images/tv/display/t_dcontrol.x +pkg/images/tv/cv/ids/idsopen.x + Modified the TV tasks (cv, cvl, and everything that uses dcontrol) + to check if the display device is a server, and if so, exit with an + error message if an operation is attempted which is not currently + supported for the server devices such as IMTOOL. (6/17) + +dev/termcap +dev/devices.hlp + 1. Added an alias `vmslp' for `vmsprint'. + 2. Changed the name of the logical printer device which directs + output to the unix lpr program (and hence to the default PRINTER + device) from `dp|dpp|default' to just `lpr', since the output is + being directed to lpr. The devices.hlp comments were not accurate, + as lpr is not restricted to Postscript devices, and a default device + will be selected even if PRINTER is not defined in the user environment. + 3. Changed the device entry `udp' to `g-lpr'. Deleted entry `sdp'. + There was no `vdp'. I also noticed that for some reason the #lines + capability was specified as 60 lines for all the U and V entries for + the Apple laserwriters, but 66 for the Sun entries, so I changed all + entries to 66. + 3. Changed device `uenscript' to `g-enscript'. The problem is that + the U prefix cannot be used for a device unless there are also S + and V entries, otherwise a bad termcap will result when the termcap + is moved to another system and all the "=u" prefixes are changed to, + e.g., "=v" in the file header. (6/18) + +dev/termcap + Changed the #lines for the imagend entries from 60 to 64. I don't + know what the real device limit is, we should check on that. (6/18) + +vms/hlib/zzsetenv.def +unix/hlib/zzsetenv.def + Tentatively, changed the default printer to versatec and the default + stdplot to lw5 for draco and tucana. For orion we should probably + use versatec/lw1 or maybe lw1/lw1 if most naive orion users are + expected to be working in the basement. It is probably hopeless to + try to please everyone with these defaults; setting the defaults on + a per account basis in the loginuser.cl is probably the only approach + that can hope to provide the best defaults for each class of user. + Also, changed stdimage to imt512 on tucana; is still set to iism70c + on draco. + + I think the best solution to this problem is to dynamically assign + output devices at login time, based on the location of the workstation, + e.g., people working in one of the basement labs would be assigned + the basement laserwriter, people working in the upstairs iraf lab + would be assigned the imagen near the lab, users in the staff offices + would get the versatec/lw5, etc. A single entry in the login.cl which + would conditionally call a host task to determine the optimim default + output devices would do the job. + + Also, we could do away with the irritating loginuser.cl file by + allowing a user space directly in the login.cl file, and preserving + this by some sort of diff/merge operation when the file is updated + by mkiraf. (6/18) + +unix/sun/imtool.c + 1. Fixed the problem that would cause IMTOOL to scribble outside the + imtool window when painting the imtool window under zoom. This was + occurring because, for speed reasons, imtool writes to the raw frame + buffer when zooming, and if other windows (e.g., the clock) also + write to the frame buffer during the repaint operation, writing will + continue at the wrong position on the screen after the interrupt. + The solution is to lock the screen during the repaint operation. + + 2. When repainting the display window while zooming, the area of the + bottom of the window could be overwritten. This would be most + noticeable at high zoom factors, and was due to the last block of + "zoom" lines being more lines than there was space left for in the + window. Added logic to write a partial block if necessary to avoid + writing beyond the bottom of the window. (6/18) + +pkg/images/tv/display/mkpkg +pkg/images/tv/display/iisopn.x +pkg/images/tv/display/imdgcur.x + +pkg/images/tv/display/imd.com + + The TVMARK program, when used with an IIS, would get a "cannot open + device" error when trying to do an image cursor read. This was + occuring due to an attempt on the part of the CL and TVMARK processes + to simultaneously open the same physical device, due to the way the + interim display interface is implemented. UNIX allows most files or + devices to be mutliply opened, e.g., this is ok for the IMTOOL fifos + and doesn't cause any conflicts, but the IIS device driver does not + permit more than one open at a time. The workaround was to add a new + routine IMD_GCUR, which is a front end to CLGCUR which is functionally + equivalent and has an identical calling sequence. This should be used + instead of CLGCUR in programs which directly map the display. The + function of IMD_GCUR is to close the channel to the physical device, + call CGCUR to read the image cursor, and then reopen the device + channel for additional frame buffer i/o. (6/19) + +sys/fio/close.x + Modified to not attempt to close the physical device if F_CLOSFD is + set on the stream and the physical device is therefore already + closed. This was causing an error at IMUNMAP time in the IMD feature + implemented above. (6/19) + +unix/hlib/utime + +vms/hlib/utime + +unix/hlib/install +pkg/cl/pfiles.c + Modified the CL pfile read mechanism to look at the system update or + install time as well as the package pfile modify time, using whichever + event was more recent, when deciding whether to use the package pfile + or the user (uparm) pfile. If the package pfile is used the user + pfile is scanned, preserving the user defaults for the parameters + which exist in both the old and new pfiles. This fix (using hlib$utime + to mark the system update time) gets around a problem in the pfile + merge code, which would cause out of date user pfiles to be used + instead of the "newer" package pfiles, due to the package pfiles + having been modified in a different version of the system. (6/19) + +pkg/images/tv/display/iispio.x +pkg/images/tv/display/imdrcuro.x + 1. Modified to copy the xferid field out of the IIS header before byte + swapping the header. Formerly the header was being conditionally byte + swapped (e.g., for the IIS) before accessing the xferid field, causing + a read/write bit test to fail. + 2. Modified the non-server (IIS) cursor read code to not do cursor + marking during cursor reads as the default, like IMTOOL. Cursor + marking can be enabled by typing a ctrl/m while reading the image + cursor, after which subsequent ctrl/m's toggle cursor marking. (6/19) + +sys/imio/iki/ikirename.x + Modified iki_rename (imrename) to allow the extension of an image + to be changed in a rename operation, provided the new extension is + a legal extension for the image. This is to allow changing the + extension of STF images in rename operations. (6/19) + +sys/fio/fntgfn.x + 1. Fixed a bug that was preventing use of list files not in the current + directory, e.g., @/path/listfile. The problem was that the code + which parses a template into directory prefix and file matching + pattern fields was being used to attempt to do the same for list + file names; in the case of a list file referenced by pathname, + only the directory prefix was being used as the list file name, + with the filename of the list file being taken to be the pattern. + The fix was to take the whole token folowing the @ to be the list + file name. This prevents use of a pattern to match elements of a + list but that is probably not an important feature anyhow, and + additional syntax would have to be devised to provide this for + list files, due to the difficulty of telling where the list file + name leaves off and the pattern begins. + + 2. Replaced a couple of gstrcpy() calls by calls to nowhite(), to + strip any whitespace from filenames output by fntgfn. (6/20) + +sys/vops/arav.gx + Now checks for a zero or near zero sigma and exits the iterative + rejection loop if this condition occurs, avoiding a case where an + infinite loop could potentially occur. (6/20) + +sys/etc/qsort.x +sys/vops/asrt.gx + Increased LOGPTR from 20 to 32, raising the size of the array that + can be sorted in a worst case scenario from 1e6 to 4e9. (6/20) + +sys/vops/awvg.gx + Replace the statements + + mean = sum / ngpix + temp = sumsq / (ngpix - 1) - sum ** 2 / (ngpix * (ngpix - 1)) + + by the equivalent statements + + mean = sum / ngpix + temp = (sumsq - mean * sum) / (ngpix - 1) + + which should be more numerically stable. (6/20) + +sys/gio/sgikern/sgipm.x + Corrected a logic error that would have prevented points from being + drawn in point polymarkers. (6/20) + +unix/os/zwmsec.c + The code used to calculate the timer interval in seconds and + microseconds, originally written for maximum clarity, could result + in integer overflow for time intervals larger than about 35 minutes. + Modified these expressions to calculate the same thing avoiding + excessively large intermediate terms. (6/20) + +unix/sun/gtermio.c + In an attempt to avoid the "cursor-walk" problem, where successive + transformations between tektronix and window coordinates cause the + cursor to creep to smaller values, I modified the coordinate + transformation code in gtermio.c to employ an integer rounding to + nearest scheme. This is done by adding N/2 before dividing by N, + N being an integer. I want to avoid using floating in computationally + intensive parts of this code, as the terminal server is sometimes + compiled with software floating point since it must be portable to + all machines in a class. (6/20) + +---------------- +Updated serpens. +Updated irafx@draco. (6/20) + +unix/os/zxwhen.c + Added #ifdef SUNOS4 ... #endif around some new exception codes that + turn out to only be defined for OS-4. (6/20) + +vms/hlib/zzsetenv.def + Updated as for Sun/IRAF - V2.8EXPORT, added fmio, qpoe, etc. + definitions, and so on. (6/20) + +unix/hlib/mkfloat.csh + Added code to check if the user has IRAFARCH defined, and if so, warn + the user if their IRAFARCH setting does not match the architecture for + which a directory tree has just been configured. (6/21) + +{math,pkg,sys,unix}*.c +{math,pkg,sys,unix}*.gc +{math,pkg,sys,unix}*.x +{math,pkg,sys,unix}*.gx + Added a copyright notice to all these core system source files. + The notice reads as follows: "Copyright(c) 1986 Association of + Universities for Research in Astronomy Inc". We also plan to add + a file called COPYRIGHT later stating the terms of the copyright + and associated licensing agreement for the software. The intent + is only to protect the software from unauthorized commercial + exploitation, and the copyright grants, or will grant, the right to + copy, modify, and redistribute the software provided the original + copyright notice remains intact, and the rights we grant are passed + on with the software. We wish to prevent others from copyrighting + the software in their own name and possibly taking away the rights + we grant with the software. + + This is not to say that we want to encourage people to modify and + redistribute IRAF software, we merely want them to have the legal + right to do so if they feel they need to. The NOAO packages are not + similarly copyrighted at the present time although that may change + in the future. (6/21) + +vms/*.c +vms/*.x + Inserted the same copyright notices into the VMS/IRAF HSI source files. + Also updated all the {math,pkg,sys} files on VMS/IRAF to propagate + the copyright insertions for those files (which retain the old modify + dates). (6/21) + +------------------ +Updated orion. (6/22) + +dev/hosts + Updated the entries for the U of A sites. (6/23) + +pkg/plot/t_gkixt.x + Had to restore the old version of this program, due to a bug in the + new version which there was inadequate time to fix. In the process, + increased the built-in MAX_FRAMES limit from 500 to 2048. (6/23) + +sys/gio/ncarutil/hafton.f + Fixed an apparent bug in the HAFTON code. A reference off the end + of an array was occuring due to a limit check not being performed + before using an index. This would normally go undetected although + it could cause the program to misbehave; it was finally discovered + because the out of bounds data happened to trigger a reserved operand + fault in the floating point unit. (6/23) + +bin.f68881/libm.a + [OS-3 only] +bin.ffpa/libm.a + [OS-3 only] +unix/boot/spp/xc.c + XC was modified to search the IRAF directories for UNIX system + libraries, before passing the library reference on to the host + system. This allows one to have custom versions of the host libraries + for IRAF, as is sometimes necessary to work around bugs in the host + system. + + The specific case for which this was implemented was to workaround the + "atan2" class of bugs present in OS3: in that version of SunOS, the + host system trig function routines assumed that the IEEE exceptions + had been disabled, and would abort with, e.g., divide by zero + exceptions given perfectly legal inputs if the IEEE exceptions were + enabled. The solution was to take the f68881 and ffpa versions of + the "-lm" library from SunOS-4 and put these in the bin.f68881 and + bin.ffpa directories in IRAF (I had to add a copy of ieee_globals.o + from -lc to -lm to get this to work). XC will now use these versions + of the libraries instead of the host system versions if it finds them + in a system directory. The BIN directories are used so that the + versions of the routines optimized for specific floating point hardware + can be used. In IRAF for SunOS-4 we merely leave out the custom + libraries and the standard host libraries will be used instead. (6/23) + +unix/os/zzstrt.c + Changed the fpmode() flags (used for SunOS-3 only) slightly to reflect + what fpmode returns under OS-4 for our current ieee settings on that + system, make using ieee_flags(). The fpmode() flags are undocumented + so I was really only guessing when I selected the flags to be set + originally; now that we have ieee_flags(), which is documented, + we can determine the desired fpmode flags empiricially. The result + was that 3 out of 4 of the flags we were setting were correct, but + there were a couple others that weren't being set - cannot tell + exactly what they do on OS-3. (6/23) + +vms/hlib/install.com +vms/hlib/install.lst + Replaced the old install.com, which merely runs INSTALL and feeds it + install commands, by a more sophisticated script (written by Nigel + Sharp) which checks to see if an image is already installed and + deinstalls it before installing the new version. (6/23) + +local/.login +local/.rootmenu +local/.sunview +local/.suntools +local/.ttyswrc +local/.defaults + These files, which define the SunOS window environment, were updated + to reflect the latest capabilities of IRAF and SunView. The default + screen layout was optimized for scientific use with an image display + and graphics. The text window is 32 lines, with an image window of + the same height alongside, and a long graphics window below, with no + overlap on any of the windows. The display window is smaller than + 512 in both dimensions and it is assumed that pan will be used to view + the image ("fitframe" is not recommended for normal use). There are + two text windows, exactly overlaid so that an L5 may be used to toggle + between them. The blue window is a cshell window and the red window + runs a CL. The graphics windows associated with each text window are + also overlaid, and are different colors, one blue and the other + burgundy. Also, just to show people how, I set up a fully-featured + rootmenu, and made the windows and background colored. The .login + contains the new `setarch', IRAFARCH, etc., plus a switch/case to + setup the architecture properly on different types of workstations. + (6/23) + +dev/memacs.ed + + Added a new edcap file for Micro-Emacs (a commercial Emacs available + for Unix, VMS, and PCs). Contributed by Bernie Simon at ST. (6/23) + +---------- +Updated pegasus (386i); incremental updates of everything else (serpens, +draco, orion, tucana). (6/23) + +unix/hlib/mkpkg.sf.S34 +unix/boot/mkpkg/sflist.c +vms/boot/mkpkg/sflist.c + 1. Testing of IRAF for SunOS-3 revealed a bug which was traced to a + host Fortran compiler optimizer bugf which was caused by a file on + the special file list not being compiled as directed; this was due + to a typo in the entry for the file in mkpkg.sf.S34 (in the entry + for images/lib/ranges.x, there was a "...:" instead of a "...":). + + 2. In the process of locating the problem with the special file list + entry I also discovered a bug in the special file list code in MKPKG + itself. The bug was the redefinition of the global string buffer + pointer "cp" in the special file list code. This could cause the + special file list to be pruned improperly, discarding all special + file list entries in the case which led me to discover the bug. (6/24) + +------------- +Tapes cut from serpens and draco and sent to ST for testing. (6/24) + +sys/pmio/pmrop.x +sys/pmio/pmsten.x + Corrected a typo: IM_LEN(PM_REFIM(pm,1)) -> IM_LEN(PM_REFIM(pm),1). + (6/24) + +unix/sun/imtool.c + The get-WCS function was modified slightly to prevent it from creating + a new frame buffer when the WCS for a nonexistent frame is queried. + The string "[NOSUCHFRAME]" is returned if the frame does not exist. + This allows use of the WCS query to determine how many frames the + server is currently configured for. (6/26) + +unix/sun/imtool.c + 1. Zooming during a cursor read no longer undoes the blinking round + cursor style used to indicate a cursor read. + 2. Zoom factor input is checked to prevent negative or zero zoom + factors, and enforce the 8 zoom factor limit. (6/27) + +pkg/images/tv/display/imdrcuro.x +pkg/images/tv/display/imdgetwcs.x +pkg/images/tv/display/imdwcs.x + A `status' argument was added to imd_getwcs and iw_open to allow one + to determine whether the WCS for a frame was successfully retrieved. + A valid WCS is always returned; the unitary WCS is returned if the + display WCS could not be retrieved for any reason, in which case + status will be ERR. (6/27) + +vms/os/zxwhen.c + Modified to enable ctrl/c interrupt handling only for processes which + are flagged as type interactive by VMS (requested by ST for use of + iraf processes in the SOGS pipeline, following last minute checkout + of the semi-frozen system.) (6/28) + +unix/sun/imtool.c + 1. Modified the logic used to determine the format for the coord output + box. 'g' format is used for the pixel value only if the zrange is too + large for 'f' format. + 2. The 0.5 pixel coordinate offset is now added only if the image was + loaded into the frame buffer without display task zoom. (6/28) + +vms/uis/* + Installed a new version of the UISDISP display program for VMS/UIS. + This is linked with the new IMFORT and has been tested successfully + on both VMS-4.7 and VMS-5. (6/28) + +pkg/images/display/imdgcur.x +pkg/images/display/iisopn.x + Testing of imexamine revealed a subtle bug in imd_gcur. This routine + closes the display channel then reopens it in order to free the device + for the cursor read. It was not checking first to see if the channel + was still open, hence could do a close on a channel that was either + not open, or open by somebody else. The routine was modified to use + the device open count to avoid the close/reopen if the channel is not + in use. (6/28) + +mkpkg +noao/mkpkg +bin.generic + +IRAF.SUNOS4 + +noao/bin.generic + + Added an entry "generic" to the root mkpkg. Typing "mkpkg generic" + sets the architecture to "generic" (bin.generic), a special case + which never has any binaries. The effect is to remove all architecture + dependent binaries from the core system and make all the real BINs + equal, i.e., complete including the OBJS.arc file. A subsequent + mkpkg f68881, mkpkg ffpa, mkpkg sparc, etc., may be used to configure + the core system (or noao system) for development for a given + architecture. (6/28) + +unix/hlib/login.cl +vms/hlib/login.cl + The template login.cl was modified to delete any old WCS files (as + well as MTIO lok files) at login time, to prevent the system from + thinking that an image loaded in some earlier session is still loaded. + Also, in the commented out section at the end which loads optional + packages, replaced the `tv' by `proto', since proto now loads TV but + contains important display tools of its own. + +unix/sun/imtool.man + Updated the manual page for IMTOOL (zoom, graphics colors, etc.) + +-------------------------- +IRAF V2.8 frozen. Updates of all systems begun. (6/28) diff --git a/doc/doc/pkg84.hlp b/doc/doc/pkg84.hlp new file mode 100644 index 00000000..f4316c42 --- /dev/null +++ b/doc/doc/pkg84.hlp @@ -0,0 +1,282 @@ +.help pkg84 Mar84 "IRAF Packages" +.sh +1. Introduction + + This document summarizes the package structure of the IRAF system as +of March 1984. A list of all the "up" packages is first given, showing +the package structure of IRAF starting from the root package (clpackage). +A listing of the tasks or programs currently available in each package is +then given, including a one-line description of the function of each task. + +.sh +2. Package Organization + + The leftmost column in the table below lists the currently "up" packages +in the root package of IRAF. Some packages contain subpackages, accessible +only by first loading the package in the root. Subpackages are shown indented +one or more levels from the root. Note that despite the tree-like logical +organization of the packages, they are all equally accessible once loaded. + +.nf + dataio FITS, Camera readers etc. + images General image processing + tv Image display load and control + language The CL builtin tasks + lists List processing + local User stuff + plot Plot package + softools Programming tools + system System utilities + utilities General utilities +.fi + +.sh +3. Package Listings + + This section is a collection of the "help package" listings of the tasks +currently available in each installed package. The help listing for a package +may be duplicated in the online system using the help facilities. +As of the release date of this document, there are only a limited number +of manual pages online for the individual tasks. Manual pages are now +available for help, for all of the dataio and utilities +programs, for tv.display, and for the contour, graph, +and surface programs in the plot package. + +NOTE: to get help for one of the modules within a package, the package +must either be loaded, or the package name must be given explicitly. +Thus, + + cl> help contour + +will work only if the plot package is loaded, while + + cl> help plot.contour + +will work at any time. The first form is ambiguous; help will search +the set of loaded packages for all package and tasks for which the +string "contour" is an abbreviation, and print help on all such matches. +If no matches are found, nothing is printed; this can be confusing +and will be fixed at some point. + +.ks +.ce +CLPACKAGE + +.nf + artdata - Artificial data generation package + astrometry - Astrometry package + database - Database manipulation package + dataio - Data format conversion package (RFITS, etc.) [up] + digiphot - Digital stellar photometry package + dtoi - Calibration of nonlinear images + filterphot - Filter photometry package + focas - Faint object classification and analysis package + images - General image processing package [up] + imred - Image reductions package + language - The command language itself [up] + lists - List processing package [up] + local - Local utilities package [up] + nsurfbrt - Galaxy isophotal analysis package + onedspec - One dimensional spectral red & analysis package + plot - Plot package [up] + softools - Software tools package (for programming) [up] + system - System utilities package [up] + twodspec - Two dimensional spectral red & analysis package + utilities - Miscellaneous utilities package [up] +.fi +.ke + + +.ks +.ce +DATAIO + +.nf + mtexamine - Examine the structure of a magnetic tape + rcamera - Convert a Forth/Camera image into an IRAF image + reblock - Copy a binary file, optionally reblocking + wcardimage - Convert text files to cardimage files + pdsread - Convert a PDS image into an IRAF image + rcardimage - Convert a cardimage file into a text file + rfits - Convert a FITS image into an IRAF image +.fi +.ke + + +.ks +.ce +IMAGES + +.nf + imcopy - Copy an image + imdelete - Delete an image + imheader - Print an image header + imhistogram - Compute image histogram +.fi +.ke + + +.ks +.ce +IMAGES.TV + +.nf + tv - Image display load and control package + blink - Blink two frames + display - Load an image or image section into the display + erase - Erase an image frame + frame - Select the frame to be displayed + lumatch - Match the lookup tables of two frames + monochrome - Select monochrome enhancement + pseudocolor - Select pseudocolor enhancement + rgb - Select true color mode (red, green, and blue frames) + window - Adjust the contrast and dc offset of the current frame + zoom - Zoom in on the image (change magnification) +.fi +.ke + + +.ks +.ce +LANGUAGE + +.nf + access - Test if a file exists + bye - Exit a task or package + cache - Cache parameter files, or print the current cache list + chdir - Change the current working directory + cl - Execute commands from the standard input + defpac - Test if a package is defined + defpar - Test if a parameter is defined + deftask - Test if a task is defined + envget - Get the string value of an environment variable + error - Print error code and message and abort + fprint - Format and print a line into a parameter + fscan - Scan a list (formatted input) + history - Print the last few commands entered + keep - Make recent set, task, etc. declarations permanent + kill - Kill a background job + lparam - List the parameters of a task + mktemp - Make a temporary (unique) file name + package - Define a new package, or print the current package names + print - Format and print a line on the standard output + radix - Print a number in the given radix + redefine - Redefine a task + scan - Scan the standard input (formatted input) + service - Service a query from a background job + set - Set an environment variable, or print environment + substr - Extract a substring from a string + task - Define a new task + unlearn - Restore the default parameters for a task or package + update - Update a task's parameters (flush to disk) + version - Print the revision date of the CL + wait - Wait for all background jobs to complete +.fi +.ke + + +.ks +.ce +LISTS + +.nf + average - Compute the mean and standard deviation of a list + gcursor - Read the graphics cursor + imcursor - Read the image display cursor + table - Format a list of words into a table + tokens - Break a file up into a stream of tokens + unique - Delete redundant elements from a list + words - Break a file up into a stream of words +.fi +.ke + + +.ks +.ce +PLOT + +.nf + contour - Make a contour plot of an image + graph - Graph one or more image sections or lists + pcol - Plot a column of an image + pcols - Plot the average of a range of image columns + prow - Plot a line (row) of an image + prows - Plot the average of a range of image lines + surface - Make a surface plot of an image +.fi +.ke + + +.ks +.ce +SOFTOOLS + +.nf + make - Table driven utility for maintaining programs + mklib - Make or update a library + mkmanpage - Make and edit a new manual page + xcompile - Compile and/or link a program + yacc - Build an SPP language parser +.fi +.ke + + +.ks +.ce +SYSTEM + +.nf + allocate - Allocate a device, i.e., magtape drive mta, mtb, ... + beep - Beep the terminal + bugmail - Print/Post bug reports, complaints, suggestions + clear - Clear the terminal screen + concatenate - Concatenate a list of files to the standard output + copy - Copy a file, or copy a list of files to a directory + count - Count the number of lines, words, and characters in a file + deallocate - Deallocate a previously allocated device + delete - Delete a file + devstatus - Print the status of a device (mta, mtb, tty, ...) + directory - List files in a directory + diskspace - Show how much diskspace is available + edit - Edit a file + files - Expand a file template into a list of files + head - Print the first few lines of a file + help - Print online documentation + lprint - Print a file on the line printer device + match - Print all lines in a file that match a pattern + news - Page through the system news file + page - Page through a file + pathnames - Expand a file template into a list of OS pathnames + protect - Protect a file from deletion + rename - Rename a file + revisions - Print/Post a revision notice for a package + rewind - Rewind a device + sort - Sort a text file + spy - Show processor status + stty - Show/Set terminal characteristics + tail - Print the last few lines of a file + tee - Tee the standard output into a file + time - Print the current time and date + type - Type a file on the standard output + unprotect - Remove delete protection from a file +.fi +.ke + + +.ks +.ce +UTILITIES + +.nf + airmass - Compute the airmass at a given elevation above the horizon + ccdtime - Compute time required to observe star of given magnitude + detab - Replace tabs with tabs and blanks + entab - Replace blanks with tabs and blanks + lcase - Convert a file to lower case + precess - Precess a list of astronomical coordinates + translit - Replace or delete specified characters in a file + ucase - Convert a file to upper case + urand - Uniform random number generator +.fi +.ke +.endhelp diff --git a/doc/doc/pmmatch.hlp b/doc/doc/pmmatch.hlp new file mode 100644 index 00000000..0ffdccab --- /dev/null +++ b/doc/doc/pmmatch.hlp @@ -0,0 +1,259 @@ +.help pmmatch Jan08 "Pixel Mask Matching" + +.sh +Introduction + +Pixel masks are associated with images to identify bad pixels, sources, or +regions of interest. In the simplest case the pixel mask "pixels" (masks +are generally stored in a compact encoded format but are logically an +integer image raster) are associated with the image pixels by their raster +coordinates, called \fIlogical coordinates\fR in IRAF. However, because +images and pixel masks are stored and handled as independent entities, +though possibly in the same multi-extension parent file, it is possible +that one or the other may be transformed so a simple matching in logical +coordinates is no longer valid. This topic describes how pixel masks +may still be associated with the images even after such transformations. + +There are many transformations which may be applied to images. Some common +ones are extracting subimages (often using the IRAF image section syntax), +subsampling or decimating (again possibly with an image section), +transposing, block averaging, block summing, and block replication. +These are all simple linear physical transformations. A slightly more +complex linear transformation is image magnification where the axes are +maintained but the pixel sizes may not have an integer relationship with +the original image. These types of linear transformations +where the axes either the same or transposed are called +\fIphysical coordinate\fR transformations. + +At the other extreme are arbitrary transformations with coupled axes such +as rotations, and distortion corrections, and resampling to match another +image or standard sampling. These transformations are typically mappings +in one or more user coordinate systems, called \fIworld coordinates\fR +in IRAF, such as celestial coordinates or spectral coordinates. The +transformations are, therefore, called world coordinate transformations. + +Obviously, one way to deal the pixel masks is to transform both the image +and mask in the same way. Some applications provide both image and +mask outputs for this reason. In other cases the transformation +application may be applied to both. + +This topic decribes another method where a pixel mask is matched to +an image "on-the-fly". In the discussion the pixel mask to be matched +is sometimes refered to as the reference pixel mask and the image being +matched is refered to as the reference image. The matching may be in one +of the logical, physical, or world coordinate systems. Initially only a +few tasks provide this feature but others will be enhanced in the future. +Be sure to check the help pages for a task for how pixel masks are +associated with images. + +A key to this pixel mask matching method using the various coordinate +systems is that tasks which transform the image or mask properly update +the coordinate system information in the header. This is the case for +most IRAF tasks, particularly those which do common, simple physical +transformations, as well as the general resampling or interpolation tasks +such as \fBgeotran\fR and the scripts that use them. In addition, the +IRAF system automatically updates the physical coordinate system when +image sections are used. + +.sh +Specifying the matching with the "pmmatch" variable + +The tasks providing pixel mask matching first set a default matching +coordinate system. Generally this is fixed internally though a task +parameter may be provided in new tasks. The usual default is logical +as this is normally the prior behavior and does not depend on any header +parameters or coordinate propagation. + +The user then overrides the default by setting the environment +variable \fIpmmatch\fR. This may be set in the environment before +starting IRAF, in the IRAF login files, in scripts, or interactively. +The values of this variable may be "logical", "physical", or "world". +An integer value may follow "world" as described later. +A null string, "", may also be used to select the task default. + +Since this is an environment variable, it will apply to all tasks run with +that environment. So a caveat is that in some cases it may be important +to realize the same matching will be used in different tasks and so one +might need to change the value before the task. + +.sh +Logical Coordinate Matching + +The simplest coordinate system is logical. This is where pixels are +matched in raster order. This does not depend on any keywords and is +intuitive, which is why this is usual default. One might think this is +no matching at all, but there is something that happens in this case. + +The pixel mask may be larger or smaller than the image. In the former +the internal matching will trim the pixel mask to the size of the image. +In the latter case the internal mask will be padded with zero. In both +cases the origin is the same and it is the largest columns and lines that +are affect; that is, trimmed or padded on the left and top when thought +of as an picture with origin at the lower left. + +The pixel mask values which overlap the image are left unchanged from +the reference pixel mask. + +.sh +Physical Coordinate Matching + +The physical coordinates are a pixel or raster coordinate system which +remains attached to an image or mask through operations of +subsampling, decimating, blocking, replication, transpose, or magnification. +Normally, an original image and mask will have a physical and logical +coordinate system that is the same. Then as they are transformed they +differ such that pixel value features remain fixed relative to the +physical coordinates. The physical transformation is maintained in the +header by the keywords LTVi and LTMi_j, where i and j are axis numbers. + +For example, a star in an image which had an original pixel coordinate +of (123.4,567.8) will have this physical coordinate in a subraster +containing it or when the image is magnified or reduced by scale +changes. + +When a physical pixel mask matching is selected a reference mask is +matched internally to the same physical pixels as the image. For +simple transformations, such as subrasters the result, is the obvious +one; the mask pixel values remain associated with any features in the +image. + +In the more complicated situation is when the scale is changed +either by block averaging, decimating, or magnifying to arbitrary +scales. The mask pixel values are then the maximum in the reference +pixel mask that overlaps any part of an image pixel. + + +.sh +World Coordinate Matching + +World coordinate matching is the most general. It allows matching pixel +masks to images which have been rotated or resampled beyond just changing +the pixel scale. Often the world coordinate system used with this option +is celestial and the resampling is done to match another image, to remove +distortions, or to transform to a standard celestial orientation and +coordinate system. However, any 2D world coordinate system is allowed. + +If a world coordinate system is not defined the physical coordinate +system is used and, if that is missing, the logical coordinate system +is used. So using world coordinate matching covers all cases. + +In order to do the transformation an internal array of the size of the +image being matched is allocated. To minimize this memory usage the +array packs the mask values into a small number of bits. To advise the +algorithm an integer defining the maximum output mask value may be specified +after the word "world" in the pmmatch variable. The value must be +separated by whitespace. Any input mask value greater than the maximum +is mapped to the maximum value. The default if no maximum is +specified, pmmatch="world", is a boolean mask with values of 0 and 1. + +It is recommended that the maximum value be as small as possible consistent +with the usage. The relationship between the maximum and +memory usage is the number of bits needed to represent the maximum value. +Therefore, the maximum values 1, 3, 7, 15, use 1, 2, 3, 4 bits respectively. + +Note that while the "world" matching is the most general, if the +transformation is only a physical one then use of physical coordinate +matching avoids the requirement of an internal array and potential +large memory usage for large images. + +.sh +Checking the Matching + +The pixel mask matching is performed "on-the-fly" when the reference pixel +mask is opened by the application. One of the benefits of this feature +to avoid having to generate new copies of pixel masks after operations +which transform the original image. + +However, because of the potential for confusion with whether the +coordinate systems have been correctly defined or propagated, it may be +useful to check the matching visually. This can be done using the +\fBdisplay\fR task with the overlay feature. This task supports the +pixel mask matching feature so it is simply a matter of setting the +"pmmatch" variable and specifying the input mask with the +\fIoverlay\fR parameter. + +.sh +Creating a Explict Matched Mask + +It may be desirable to actually create a pixel mask file which matches +a reference image. This may be for applications that don't support +the internal mask matching feature, to export a mask with the image, +for efficiency, or simply because you prefer to use mask files rather +than the internal matching. + +Any task that implements the pixel matching and produces an output pixel +mask may be used. The recommend task is \fBmskexpr\fR. This +is a general task that creates output masks based on expressions. +For creating a mask that matches an image, called the reference image +in this task, from a mask matched to the image, called the reference +mask in this application, the command is something like: + +.nf + cl> mskexpr m matchedmask myimage refmask=mask +.fi + +.sh +Examples + +The examples illustrates the pixel mask matching with a simple image, +the standard IRAF test image, which is +transformed in various ways and the pixel matching is demonstrated by +using the \fBdisplay\fR task to overlay the mask. The creation of an +matching pixel mask file by \fBmskexpr\fR is also shown. + +We begin by creating a pixel mask from an image with a +celestial coordinate system. New images are generated by extracting a +subraster, magnifying the image to a new pixel scale, and rotating the +image by 45 degrees. In each case the mask is shown as an overlay +display. + +1. Create a mask for image wpix and display it as an overlay. + +.nf + cl> imcopy dev$wpix . + cl> imexpr "a > 1000 ? 1 : 0" pm.pl wpix + cl> display wpix 1 overlay=pm +.fi + +2. Overlay the mask with a simple subraster transformation. + +.nf + cl> set pmmatch = physical + cl> display wpix[301:428,101:228] 2 overlay=pm +.fi + +3. Overlay the mask with a subraster and scale change physical transformation. + +.nf + cl> magnify wpix[301:428,101:228] wpixmag 3 3 + + wpixmag + Magnify image wpix[301:428,101:228] to image wpixmag. + Interpolation is linear. + Boundary extension is nearest. + Output coordinates in terms of input coordinates: + x1 = 1., x2 = 128., dx = 0.333333 + y1 = 1., y2 = 128., dy = 0.333333 + cl> set pmmatch = physical + cl> display wpixmag 2 overlay=pm +.fi + +4. Overlay the mask after a 45 degree rotation. Preserve the values 1, 2, +and 3. + +.nf + proto> rotate wpix wpix45 45 bound=const + + Transforming image wpix to image wpix45 + xshift: -106.25 yshift: 256.50 xmag: 1.00 ymag: 1.00 xrot: + 45.00 yrot: 45.00 + proto> set pmmatch="world 3" + proto> display wpix45 2 over=pm + z1=0. z2=456.0118 +.fi + +.sh +TASK SUPPORTING PIXEL MASK MATCHING + +display, imcombine, runmed, fixpix, transform, lscombine, mimstat, mskexpr +.endhelp diff --git a/doc/doc/spp83.hlp b/doc/doc/spp83.hlp new file mode 100644 index 00000000..bbd2feb9 --- /dev/null +++ b/doc/doc/spp83.hlp @@ -0,0 +1,1722 @@ +.help spp83 Jan83 "IRAF Subset Preprocessor Language" +.sh +1. Introduction + + The IRAF subset preprocessor language (SPP) implements a subset of +the proposed IRAF preprocessor language, described in the paper "The Role +of the Preprocessor". The subset does not include pointers, structures, +and dynamic and virtual arrays. Subset preprocessor programs should be +written with eventual conversion to the full preprocessor language +in mind. In general, this conversion will not be difficult, provided +one generates simple and straightforward code. + +One of the best ways to learn to program in a new language is to read the +source listings of existing programs. Many examples of procedures, programs, +and packages written in the SPP language can be found in the IRAF system +source directories. We shall only attempt to summarize the basic features +of the language here. + +.sh +2. Getting Started + + The best way to get started is to build and run a simple program, before +attempting to learn all the details of the language. Here is our version +of the "hello world" program from the C book: + + +.ks +.nf + # Simple program to print "hello, world" on the standard + # output. + + task hello # CL callable task + + + procedure hello() # common procedure + + begin + call printf ("hello, world\n") + end +.fi +.ke + + +On the UNIX system, this program would be placed in a file with the +extension ".x" and compiled with the command XC (X Compiler) as follows. + + xc hello.x + +The XC compiler will translate the program into Fortran, call the Fortran +compiler to generate the object file ("hello.o"), and call the loader +to link the object file with modules from the IRAF system libraries to +produce the executable program "hello". XC may be used to compile +C and Fortran programs as well as X programs, and in general behaves very +much like CC or F77 (note that the "-o" flag is not required; by default +the name of the output module is the base name of the first file name on the +command line). The "-F" flag may be used to inspect the Fortran +generated by the preprocessor; this is sometimes necessary to interpret +error messages from the F77 compiler. + +.sh +3. Fundamentals of the Language + + The SPP language is based on the Ratfor language. The lexical +form, operators, and control flow constructs are identical to those +provided by Ratfor. The major differences are the data types, the form +of a procedure, the addition of inline strings and character constants, the +use of square brackets for arrays, and of course the TASK statement. +The i/o facilities provided are quite different. + +.sh +3.1 Lexical Form + + A subset preprocessor program consists of a sequence of lines of text. +The length of a line is arbitrary, but the SPP is guaranteed to be able to +handle only lines of up to 160 characters in length. The end of each line +is marked by the NEWLINE character. Both upper and lower case characters +are permitted. Case is significant. + +WHITESPACE is defined as one or more tabs or spaces. Newline normally marks +the end of a statement, and is not considered to be whitespace. +Whitespace always delimits tokens, i.e., keywords and operators will not be +recognized as such if they contain embedded whitespace. +.ih 2 4 +3.1.1 Comments + +A comment begins with the character # and ends at the end of the line. +.ih +3.1.2 Continuation + +Statements may span several lines. A line which ends with an operator +(excluding '/') or punctuation character (comma or semicolon) is automatically +understood to be continued on the following line. +.ih +3.1.3 Integer Constants + +A decimal integer constant is a sequence of one or more of the digits 0-9. +An octal constant is a sequence of one or more of the digits 0-7, followed +by the letter 'b' or 'B'. A hexadecimal integer constant is one of the +digits 0-9, followed by zero or more of the digits 0-9, the letters a-f, +or the letters A-F, followed by the letter 'x' or 'X'. The following +notation more concisely summarizes these definitions: + +.nf + decimal constant [0-9]+ + octal constant [0-7]+('b'|'B') + hexadecimal constant [0-9][0-9a-fA-F]*('x'|'X') + identifier [a-zA-Z][a-zA-Z_0-9]* +.fi + +In the notation used above, "+" means 1 or more, "*" means zero or more, +"-" implies a range, and "|" means "or". Brackets ("[]") define a class +of characters. Thus, "[0-9]+" reads "one or more of the characters 0 +through 9". +.ih +3.1.4 Floating Point Constants + +A floating point constant (type REAL or DOUBLE) consists of a decimal +integer, followed by a decimal point, followed by a decimal fraction, +followed by one of (e|E|d|D), followed by a decimal integer, which +may be negative. Either the decimal integer or the decimal fraction +part must be present. The number must contain either the decimal +point or the exponent (or both). Embedded whitespace is not permitted. + +The following are all legal floating point numbers: + +.nf + .01 + 100. + 100.01 + 1E5 + 1E-5 + 1.00D5 + 1.0D0 +.fi + +A floating constant may also be given in sexagesimal format, i.e., +in hours and minutes, or in hours, minutes, and seconds. The number +of colon separated fields must be two or three, and the number of decimal +digits in the second field and in the integer part of the third field is +limited to exactly two. The decimal point is optional. + +.nf + 00:01 = 0.017 + 00:00:01 = 0.00028 + 01:00:00 = 1.0 + 01:00:00.00 = 1.0 +.fi +.ih +3.1.5 Character Constants + +A character constant consists of from 1 to 4 digits delimited at front +and rear by the single quote ("'", as opposed to the double quotes used +to delimit string constants). A character constant is numerically +equivalent to the corresponding decimal integer, and may be used wherever +an integer constant would be used. + +.nf + 'a' integer equivalent of the letter 'a' + '\n' integer equiv. of the newline character + '\007' the octal integer 07B + '\\' the integer equiv. of the character '\' +.fi + +The backslash character ("\") is used to form "escape sequences". +The following escape sequences are defined: + +.nf + \b backspace + \f formfeed + \n newline + \r carriage return + \t tab +.fi +.ih +3.1.6 String Constants + +A string constant is a sequence of characters enclosed in double +quotes. The double quote itself may be included in the string by +escaping it with backslash. All of the escape sequences given above +are recognized. The backslash character itself must be escaped to +be included in the string. A string constant may not span several +lines of text. +.ih +3.1.7 Identifiers + +An identifier is an upper or lower case letter, followed by zero or more +upper or lower case letters, digits, or the underscore character. Identifiers +may be as long as desired, but only the first five characters and the last +character are significant. + +The following identifiers are reserved (though some are not actually used +at present): + +.ls -8 +.nf +auto do include short +begin double int sizeof +bool else long static +break end map struct +call entry next switch +case extern plot task +char false printf true +clgetpar for procedure union +clputpar getpix putpix unmap +common goto real until +complex if repeat virtual +data iferr return vstruct +define imstruct scan while +.fi +.le + +.sh +3.2 Data Types + + The subset preprocessor language supports a fairly wide range of +data types. The actual mapping of an XPP data type into a Fortran +data type depends on what the target compiler has to offer. + +.ks +.nf + XPP Data Types + + bool boolean (Fortran LOGICAL) + char character (8 bit signed) + short short integer + int integer (Fortran INTEGER) + long long integer + real single precision floating (Fortran REAL) + double double precision floating (DOUBLE PRECISION) + complex single precision complex (Fortran COMPLEX) +.fi +.ke + + +The only permissible values for a boolean variable are "true" and "false". +The CHAR data type belongs to the family of integer data types, i.e., a +CHAR variable or array behaves like an integer variable or array. +The value of a CHAR variable may range from -127 to 127. CHAR and SHORT +are signed integer data types (i.e., they may take on negative values). + +In addition to the seven primitive data types, the SPP language provides +the abstract type POINTER. The SPP language makes no distinction between +pointers to different types of objects, unlike more strongly typed languages +such as C (and the full preprocessor). The SPP implementation of the POINTER +data type is a stopgap measure. + +.sh +3.3 Declarations + + The SPP language implements named procedures with formal parameters +and local variables. Global common and dynamic memory allocation may be +used to share data amongst procedures. A procedure may return a value, +but may not return an array or string. Declarations are included for +procedures, variables, arrays, strings, typed procedures, external +procedures, and global common areas. Storage for local and global +variables and arrays may be assumed to be statically allocated. + +.sh +3.3.1 Variable, Array, and Function Declarations + + Although the language does not require that parameters be declared before +local variables and functions, it is a good practice to follow. The syntax +of a type declaration is the same for parameters, variables, and procedures. + + type_spec object [, object [,... ]] + +Here, "type_spec" may be any of the seven primitive data types, a +derived type such as POINTER, or EXTERN. A list of one or more data objects +follows. An object may be a variable, array, or procedure. The declaration +for each type of object (variable, array, or procedure) has a unique syntax, +as follows: + +.ks +.nf + variable identifier + array identifier "[" dimension_list "]" + procedure identifier "()" +.fi +.ke + + +Procedures may be passed to other procedures as formal parameters. +If a procedure is to be passed to a called procedure as a formal parameter, +it must be declared in the calling procedure as an object of type EXTERN. + +.sh +3.3.2 Array Declarations + + Arrays are one-indexed. The storage order is fixed in such a way that +when the elements of the array are accessed in storage order, the leftmost +subscript varies fastest. Arrays of up to three dimensions are permitted. + +The size of each dimension of an array may be specified by any compile +time constant expression, or by an integer parameter or parameters, if the +array is a formal parameter to the procedure. If the array is declared as +a formal parameter, and the size of the highest dimension is unknown, the +size of that dimension should be given as ARB (for arbitrary). + +.nf + real data[ARB] # length of array is unknown + short raster[NPIX*2,128] # 2-dim array +.fi + +The declared dimensionality of an array passed as a formal parameter to +a procedure may be less than or equal to the actual dimensionality of the +array. + +.sh +3.3.3 String Declarations + + A string is an EOS delimited array of type CHAR (EOS stands for End Of +String). Strings may contain only character data (values 0 through 127 +decimal), and must be EOS delimited. A character string may be declared +in either of two ways, depending on whether initialization is desired: + +.nf + char input_file[SZ_FNAME] + string legal_codes "efgdox" +.fi + +The preprocessor automatically adds 1 to the declared array size, to allow +space for the EOS marker. The space used by the EOS marker is not considered +part of the string. Thus, the array "char x[10]" will contain space for +ten characters, plus the EOS marker. + +.sh +3.3.4 Global Common Declarations + + Global common provides a means for sharing data between separately +compiled procedures. The COMMON statement is a declaration, and must +be used only in the declarations section of a procedure. Each procedure +referencing the same common must declare the common in the same way. + + common /common_name/ object [, object [, ... ]] + +To avoid the possibility of two procedures declaring the same common area +differently in separate procedures, the COMMON declaration should be placed +in a INCLUDE file (include files are discussed in a later section). + +.sh +3.3.5 Procedure Declarations + + The form of a PROCEDURE declaration is shown below. The "data_type" +field must be included if the procedure returns a value. The BEGIN +keyword separates the declarations section from the executable body of the +procedure, and is required. The END keyword must follow the last executable +statement. + + +.ks +.nf + [data_type] PROCEDURE proc_name ([p1 [, p2 [,... ]]]) + + (declarations for parameters) + (declarations for local variables and functions) + (initialization) + + BEGIN + (executable statements) + END +.fi +.ke + + +All parameters, variables, and typed procedures must be declared. +The XPP language does not permit implicit typing of parameters, variables, +or procedures (unlike Fortran). + +If a procedure has formal parameters, they should agree in both number and type +in the procedure declaration and when the procedure is called. In particular, +beware of SHORT or CHAR parameters in argument lists. An INT may be passed +as a parameter to a procedure expecting a SHORT integer on some machines, +but this usage is NOT PORTABLE, and is not detected by the compiler. The +compiler does not verify that a procedure is declared and used consistently. + +If a procedure returns a value, the calling program must declare the +procedure in a type declaration, and reference the procedure in an expression. +If a procedure does not return a value, the calling program may reference +the procedure only in a CALL statement. + +.sh +Example 1: The Sinc Function + + This example demonstrates how to declare a typed procedure, which +in this case returns a single real value. Note the inclusion of the +double parenthesis ("()") in the declaration of the function SIN, to +make it clear that a function is being declared, rather than a local +variable. Note also the use of the RETURN statement to return the value +of the function SINC. + + +.ks +.nf + real procedure sinc (x) + + real x + + begin + if (x == 0.0) + return (1.0) + else + return (sin(x) / x) + end +.fi +.ke + +.sh +3.3.6 Multiple Entry Points + + Procedures with multiple entry points are permitted in the subset +preprocessor language because they provide an attractive alternative to +global common when several procedures must have access to the same data. +The multiple entry point mechanism is a primitive form of block structuring. +The advantages of multiple entry points over global common are: +.ls +.ls (1) +Access to the database is restricted to calls to the defined entry points. +A secure database can thus be assured. +.le +.ls (2) +Initialization of data in a procedure with multiple entry points is +permissible at compile time, whereas global common cannot (reliably) be +initialized at compile time. +.le +.le + +Nonetheless, the multiple entry point construct is only useful for +small problems. If the problem grows too large, an enormous procedure +with many entry points results, which is unacceptable. + +The form of a procedure with multiple entry points is shown below. +Either all entry points should be untyped, as in the example, or +all entry points should return values of the same type. Control should +only flow forward. Each entry point should be terminated by a +RETURN statement, or by a GOTO to a common section of code which +all entry points share. The shared section of code should be terminated +by a single RETURN which all entry points share. + + +.ks +.nf +Example 2: Multiple Entry Points + + + procedure push (datum) + + int datum # value to be pushed or popped + int stack[SZ_STACK] # the stack + int sp # the stack pointer + data sp/0/ + + begin + (push datum on the stack, check for overflow) + return + + entry pop (datum) + (pop stack into "datum", check for underflow) + return + end +.fi +.ke + +.sh +3.4 Initialization + + Local variables, arrays, and character strings may be initialized at +compile time with the DATA statement. Data in a global common may NOT be +initialized at compile time. If initialization of data in a global common +is required, it must be done at run time by an initialization procedure. + +The syntax of the DATA statement is defined in the Fortran 77 standard. +Some simple examples follow. + +.ks +.nf + real x, y[2] + char ch[2] + data x/0/, y/1.0,2.0/, ch/'a','b',EOS/ +.fi +.ke + +.sh +3.5 Control Flow Constructs + + The subset preprocessor provides a full set of control flow constructs, +such as are found in most modern languages. Some of these have already +appeared in the examples. + +An SPP control flow construct executes a "statement" either conditionally +or repetitively. The "statement" to be executed may be a simple one line +statement, a COMPOUND STATEMENT enclosed in curly brackets or braces ("{}"), +or the NULL STATEMENT (";" on a line by itself). + + +.nf + conditional constructs: IF, IF ELSE, SWITCH CASE + repetitive constructs: DO, FOR, REPEAT UNTIL, WHILE + branching: BREAK, NEXT, GOTO, RETURN +.fi + + +Two special statements are provided to interrupt the flow of control through +one of the repetitive constructs. BREAK causes an immediate exit from the +loop, by jumping to the statement following the loop. NEXT shifts control +to the next iteration of the loop. If BREAK and NEXT are embedded in a +conditional construct, which is in turn embedded in a repetitive construct, +it is the outer repetitive construct which will define where control is +shifted to. + +.sh +3.5.1 Conditional Execution + + The IF and IF ELSE constructs are shown below. The "expr" part +may be any boolean expression. The "statement" part may be a simple +statement, compound statement enclosed in braces, or the null statement. +The control flow constructs may be nested indefinitely. + + +.ks +.nf + if (expr) IF construct + statement +.fi +.ke + + +.ks +.nf + if (expr) IF ELSE construct + statement + else + statement +.fi +.ke + + +The ELSE IF construct is useful for selecting one statement to be +executed from a group of possible choices. This construct is a more +general form of the SWITCH CASE construct. + + +.ks +.nf + if (expr) ELSE IF construct + statement + else if (expr) + statement + else if (expr) + statement +.fi +.ke + + +The SWITCH CASE construct evaluates an integer expression once, then +branches to the matching case. Each case must be a unique integer constant. +The maximum number of cases is limited only by table space within the +compiler. + +A case may consist of a single integer constant, or a list of integer +constants, delimited by the character ":". The special case DEFAULT, if +included, is selected if the switch value does not match any of the other +cases. If the switch value does not match any case, and there is no +default case, control passes to the statement following the body of the +SWITCH statement. + +Each case of the SWITCH statement may consist of an arbitrary number of +statements, which do not have to be enclosed in braces. The body of the +switch statement, however, must be enclosed in braces as shown. + + +.ks +.nf + switch (int_expr) { SWITCH CASE construct + case int_const_list: + statements + case int_const_list: + statements + default: + statements + } +.fi +.ke + +.ks +.nf +example: + + switch (operator) { + case '+': + c = a + b + case '-': + c = a - b + default: + call error (1, "unknown operator") + } +.fi +.ke + + +The SWITCH construct will execute most efficiently if the cases form +a monotonically increasing sequence without large gaps between the +cases (i.e., case 1, case 2, case 3, etc.). The cases should, of course, +be defined parameters or character constants, rather than explicit numbers. + +.sh +3.5.2 Error Handling + + The SPP language provides support for error actions, error handling +and error recovery. Knowledge of the SPP error handling procedures is +necessary to correctly deal with error actions initiated by the system +library routines. + +A recoverable error condition is asserted by a call to the ERROR statement. +An irrecoverable error condition is asserted with the FATAL statement. +Error recovery is implemented using the IFERR and IFNOERR statements. +If an error handler is not "posted" by a call to IFERR or IFNOERR, +a system defined error handler will be called, returning system resources, +closing files, deleting temporary files, and aborting the program. + + +.ks +.nf + errchk proc1, proc2, ... # errchk declaration + + iferr (procedure call or assignment statement) + + + iferr { + + } then + +.fi +.ke + + +Language support includes the IFERR and IFNOERR statements and the ERRCHK +declaration. The IFERR and IFNOERR statements are grammatically equivalent +to the IF statement. The meaning of the IFERR statement is "if an error +occurs during the processing of the enclosed code,...". IFNOERR is equivalent, +except that the sense of the test is reversed. Note that the condition to +be tested in an IFERR statement may a single or compound procedure call or +assignment statement, while the IF statement tests a boolean expression. + +If a procedure calls a subprocedure which may directly or indirectly take an +error action, then the subprocedure must be named in an ERRCHK declaration +in the calling procedure. If an error occurs during the processing of +a subprocedure and an error handler is posted somewhere back up the chain +of procedure calls, then control must revert immediately back up the chain +of procedures to the procedure which posted the error handler. This will +work only if all intermediate procedures include ERRCHK declarations for +the next lower procedure in the chain. + +Graphically, assume that procedure A calls B, that B in turn calls C, +and so on as shown below: + + +.ks +.nf + A (A posts error handler with IFERR) + B (B must ERRCHK procedure C) + C (C must ERRCHK procedure D) + D (D calls ERROR) +.fi +.ke + + +As indicated by the diagram, procedure D calls ERROR, "taking an error +action". If no handler is posted, the error action will consist of the +system error recovery actions, terminating with the abort of the current +program. But if an error handler is posted, as is done by procedure A +in the example, then control should revert immediately to procedure A. +The error handler in A might try again with slightly different parameters, +perform special cleanup actions and abort, print a more meaningful +error message and take another error action, print a warning message, +or whatever. If the ERRCHK declaration is omitted in procedure B or C, +control will not revert immediately to procedure A, and processing will +erroneously continue in the intermediate procedure, as if an error had +not occurred. + +Several library procedures are provided in the system library for +use in error handlers. The ERRACT procedure may be called in an error +handler to issue the error message posted by the original ERROR call as +a warning message, or to cause a particular error action to be taken. +The error actions are defined in the include file "". +ERRCODE returns either OK or the integer code of the posted error. + +.ks +.nf +Library procedures related to error handling: + + error (errcode, error_message) (language) + fatal (errcode, error_message) (library) + erract (severity) (library) + val = errcode () (library) +.fi +.ke + + +.ks +.nf +.rj +ERRACT severity codes + + EA_WARN # issue a warning message + EA_ERROR # assert recoverable error + EA_FATAL # assert fatal error +.fi +.ke + + +An arithmetic exception (X_ARITH) will be trapped by an IFERR statement, +provided the posted handler(s) return without causing error restart. +X_INT and X_ACV (interrupt and access violation may be caught only by +posting an exception handler with XWHEN. + +.sh +3.5.3 Repetitive Execution + + An assortment of repetitive constructs are provided for convenience. +The simplest constructs are WHILE, which tests at the top of the loop, +and REPEAT UNTIL, which tests at the bottom. The DO construct is +convenient for simple sequential operations on arrays. The most general +repetitive construct is the FOR statement. + + +.ks +.nf + while (expr) WHILE construct + statement +.fi +.ke + + +.ks +.nf + repeat { REPEAT UNTIL + statements + } until (expr) +.fi +.ke + + +.ks +.nf + repeat { infinite REPEAT loop + statements (exit with BREAK, RETURN, etc) + } +.fi +.ke + + +The FOR construct consists of an initialization part, a test part, and +a loop control part. The initialization part consists of a statement +which is executed once before entering the loop. The test part is a +boolean expression, which is tested before each iteration of the loop. +The loop control statement is executed after the last statement in the +body of the FOR, before branching to the test at the beginning of the loop. +When used in a FOR statement, NEXT causes a branch to the loop control +statement. + +The FOR construct is very general, because of the lack of restrictions on +the type of initialization and loop control statements chosen. Any or all +of the three parts of the FOR may be omitted, but the semicolon delimiters +must be present. + + +.ks +.nf + for (init; test; control) FOR construct + statement + +example: + + for (ip=strlen(str); str[ip] != 'z' && ip > 0; ip=ip-1) + ; +.fi +.ke + + +The example demonstrates the flexibility of the FOR construct. The +FOR statement shown searches the string "str" backwards until the +character 'z' is encountered, or until the beginning of the string is +reached. Note the use of the null statement for the body of the FOR, +since everything has already been done in the FOR itself. +The STRLEN procedure is shown in a later example. + + +The DO construct is a special case of the FOR construct. DO is ideal +for simple array operations, and since it is implemented with the Fortran +DO statement, its use should result in particularly efficient code. + +Only INTEGER loop control expressions are permitted in the DO statement. +General expressions are permitted. The loop may run forwards or backwards, +with any step size. The value of the loop control parameter is UNDEFINED +upon exit from the loop. The body of the DO will be executed zero times, +if the initial value of the loop control parameter satisfies the termination +condition. + + +.ks +.nf + do lcp = initial_value, final_value [, step_size] + statement + +example: + + do i = 1, NPIX DO construct + a[i] = abs (a[i]) +.fi +.ke + +.sh +3.6 Expressions + + Every expression is characterized by a data type and a value. +The data type is fixed at compile time, but the value may be either +fixed at compile time, or calculated at run time. An expression +may be a constant, a string constant, an array reference, a call to +a typed procedure, or any combination of the above elements, in +combination with one or more unary or binary operators. + + +.ks +.nf + ( Special Operators ) + + (arglist) procedure call + [arglist] array reference + + + ( Unary Operators ) + + - negation + ! boolean not + + + ( Binary Operators ) + + ** exponentiation + / * arithmetic + + - + + == != <= >= < > boolean comparison + && || boolean and, or +.fi +.ke + + +Parenthesis may be used to force the compiler to evaluate the parts of an +expression in a certain order. In the absence of parenthesis, +the "precedence" of an operator determines the order of evaluation +of an expression. The highest precedence operators are evaluated +first. The precedence of the SPP operators is defined by the +order in which the operators appear in the table above (procedure +call has the highest precedence). + +The "arglist" in a procedure or array reference consists of a list +of general expressions separated by commas. If an expression contains +calls to two or more procedures, the order in which the procedures +are evaluated is undefined. + +.sh +3.6.1 Mixed Mode Expressions + + The binary operators combine two expressions into a single expression. +If the two input expressions are of different data types, the expression +is said to be a "mixed mode" expression. The data type of a mixed mode +expression is defined by the order in which the types of the two input +expressions appear in the table on page 5. The data type which appears +furthest down in this table will be the data type of the combined +expression. For example, an integer plus a real produces a real. Mixed +mode expressions involving booleans are illegal. + +.sh +3.6.2 Type Coercion + + The term "type coercion" refers to the conversion of an object from one +data type to another. Such conversions may involve loss of information, +and hence are not always reversible. Type coercion occurs automatically +in mixed mode expressions, and in assignment statements. Type coercion +is not permitted between booleans and the other data types. + +The data type of an expression may coerced by a call to an intrinsic function. +The names of these intrinsic functions are the same as the names of the data +types. Thus, "int(x)", where X is of type REAL, coerces X to type INT, while +"double(x)" produces a double precision result. + +.sh +3.7 The Assignment Statement + + The assignment statement assigns the value of the general expression on +the right side to the variable or array element given on the left side. +Automatic type coercion will occur during the assignment if necessary +(and legal). Multiple assignments may not be made on the same line. + +.sh +3.8 Some Examples + + We have now finished discussing the fundamentals of the subset +preprocessor language. The following examples demonstrate two complete +procedures written in the SPP language. Additional examples are given in +appendix B, and in the IRAF source directories. + +.sh +Example 3: Length of a String + + This example demonstrates the declaration and use of a function to +compute the length of a character string passed as a formal parameter. +STRLEN simply inspects each character in the string, until the end of +string marker (EOS) is reached. + + +.ks +.nf + int procedure strlen (string) + + char string[ARB] + int ip + + begin + ip = 1 + while (string[ip] != EOS) + ip = ip + 1 + return (ip - 1) + end +.fi +.ke + + +The code fragment shown below shows how the function STRLEN might be +used in another procedure. STRLEN is called to get the index of the +last character in the string, then the string is truncated by +overwriting the last character with EOS. EOS is a predefined +constant, which should be considered part of the language. + + +.ks +.nf + char string[SZ_LINE] + int strlen() + + begin + string_length = strlen (string) + if (string_length >= 1) + string[string_length] = EOS +.fi +.ke + +.sh +Example 4: Min and Max of a REAL Array + + This example shows how to declare a procedure which returns its output +via formal parameters, rather than as the function value. Note the use of +square brackets to declare and reference arrays. If the limiting values of the +data cannot be computed, the special value INDEF is returned, signifying +that the limiting values are indefinite. INDEF is another predefined constant. + + +.tp 6 +.nf + procedure limits (data, npix, minval, maxval) + + real data[npix] # input data array + int npix # length of array + real minval, maxval # output values + int i + + begin + if (npix >= 1) { + minval = data[1] + maxval = data[1] + for (i=2; i <= npix; i=i+1) { + if (data[i] < minval) + minval = data[i] + if (data[i] > maxval) + maxval = data[i] + } + } else { + minval = INDEF + maxval = INDEF + } + end +.fi + + +The generalization of this procedure to handle indefinites in the input +data array is left up to the reader. + +.sh +3.9 Program Structure + + An SPP source file may contain any number of PROCEDURE declarations, +zero or one TASK statements, any number of DEFINE or INCLUDE statements, +and any number of HELP text segments. By convention, global definitions +and include file references should appear at the beginning of the file, +followed by the task statement, if any, and the procedure declarations. + + +.nf + include # character type definitions + include "widgets.h" # package definitions file + + # This file contains the source for the tasks making up the + # Widgets analysis package (describe the contents of the file). + + define MAX_WIDGETS 50 # local definitions + define NPIX 512 + define LONGITUDE 7:32:23.42 + + + task alpha, beta, epsilon=eps + + + # ALPHA -- (describe the alpha task) + + procedure alpha() + ... +.fi + +.sh +3.9.1 Include Files + + Include files are referenced at the beginning of a file to include +global definitions that must be shared amongst separately compiled +files, and within procedures to reference common block definitions. +The INCLUDE statement is effectively replaced by the contents of the +named file. Includes may be nested at least 5 deep. + +The name of the file to be included must be delimited by either angle +brackets () or quotation marks ("file"). The first form is used +to reference the IRAF system include files. The second, more general, +form may be used to include any file. + +.sh +3.9.2 Macro Definitions + + Macro definitions are invaluable for "information hiding", and can do +much to enhance the modifiability of a program. The effective use of macros +also tends to improve the readability of a program. By convention, the +names of macros are always upper case, to make it clear that a macro is +being used, and to avoid redefinitions of ordinary variables and procedures. + +There are two kinds of macros -- those with arguments, and those without. +Macros without arguments are the most common, and are used primarily to +turn explicit constants into symbolic parameters. Examples are shown +above. + +Macros may also be used to reference the field of a structure, or to +define inline code fragments (similar to Fortran statement functions). +In the SPP, the arguments of a macro are referenced as "$1", "$2", in +the following manner: + + +.ks +.nf + define I_TYPE $1[1] + define I_NPIX $1[2] + define I_COEFF $1[10] + + + if (I_TYPE(coeff) == LINEAR) + ... +.fi +.ke + + +In this example, the array "coeff" is actually a simple structure, +containing the fields "i_type", "i_npix", ..., and "i_coeff". +It greatly enhances the readability of the program to refer to the +fields of this structure by name, rather than offset ("coeff[2]"), +and furthermore makes it trivial to modify the structure. + +Macros with arguments may also be used to define inline functions. +For example, here are a couple of definitions of character classes +from the system include file "ctype.h": + + +.ks +.nf + define IS_UPPER ($1>='A'&&$1<='Z') + define IS_LOWER ($1>='a'&&$1<='z') + define IS_DIGIT ($1>='0'&&$1<='9') + +usage: + if (IS_DIGIT(string[i])) { + ... +.fi +.ke + + +Note that these definitions work for ASCII, but not for EBCDIC (IBM). +By using macros, we have concentrated this machine dependent knowledge +of the character set into a single file. + +NOTE: In the current implementation of the SPP, macro definitions may +not include string constants. All other types of constants, constant +expressions, array and procedure references, are allowed. The domain +of definition of a macro extends from the line following the macro, to +the end of the file (except for include files). Macros are recursive. +Redefinitions of macros are silently permitted. + +.sh +3.9.3 The TASK Statement, and Tasks + + The TASK statement is used to make an IRAF task. A file +need not contain a task statement, and may not contain more than a +single task statement. Files without task statements are separately +compiled to produce object modules, which may subsequently be linked +together to make a task, or which may be installed in a library. + +A single physical task (ptask) may contain one or more LOGICAL TASKS (ltasks). +These tasks need not be related. Several ltasks may be grouped together +into a single ptask merely to save disk storage, or to minimize the +overhead of task execution. Ltasks should communicate with one another +only via disk files, even if they reside in the same ptask. + + task ltask1, ltask2, ltask3=proc3 + +The task statement defines a set of ltasks, and associates each with +a compiled procedure. If only the name of the ltask is given in the task +statement, the associated procedure is assumed to have the same name. +A file may contain any number of ordinary procedures which are not +associated (directly) with an ltask. The source for the procedure associated +with a given ltask need not reside in the same file as the task statement. + +An ltask associated procedure MUST not have any arguments. An ltask +procedure gets its parameters from the CL via the CL interface. Most commonly +used are the CLGETx procedures. The CLPUTx procedures may be used to +change the values of parameters. + + +.ks +.nf + task alpha, beta, epsilon=eps + + + procedure alpha() + + int npix, clgeti() + real lcut, clgetr() + char file[SZ_FNAME] + + begin + npix = clgeti ("npix") + lcut = clgetr ("lower_cutoff") + call clgstr ("input_file", file, SZ_FNAME) + ... +.fi +.ke + + +An IRAF task may be run by the CL or called from the command interpreter +provided by the host operating system, without change. Parameter requests +and i/o to the standard input and output will function properly in both +cases. When running without the CL, of course, the interface is much more +primitive. + +To run an IRAF task directly, without the CL (especially useful for +debugging purposes), begin by simply running the task. The task will +sense that it is being run without the CL, and issue a prompt: + + +.ks +.nf + > ? + alpha beta epsilon + > alpha + npix: (response) + lower_cutoff: (response) + input_file: (response) + (ltask "alpha" continues) + > bye +.fi +.ke + + +Every IRAF task has two special commands built in. The command "?" will +list the names of the ltasks recognized by the interpreter. The command +"bye" is used to exit the interpreter. + +.sh +3.9.4 Help Text + + Documentation may be embedded in an XPP source file either by commenting +out the lines of text, or by enclosing the lines of text within ".help" +and ".endhelp" directives. If there are only a few lines of text, it is +probably most convenient to comment them out. Large blocks of text should +be enclosed by the help directives, making the text easier to edit, and +accessible to the online documentation and text processing tools. + + +.ks +.nf + # (everything from the '#' to end of line is a comment) + + .help [keyword [qualifier [package_description_string]]] + (help text) + .endhelp +.fi +.ke + + +The preprocessor ignores comments, and everything between ".help" +and ".endhelp" directives. The directives must occur at the beginning +of a line to be recognized. In both cases, the preprocessor ignores +the remainder of the line. The arguments to ".help" are used by the +HELP, MANPAGE, and LISTING utilities, but are ignored by XPP. + +Help text may be typed in as it is to appear on the terminal or printer, +or it may contain text processing directives. A filter (LISTING) is +available to strip help text out when making listings, or to replace help +text containing directives with nicely formatted text. See the LROFF +documentation for a description of the IRAF text processing directives. + +Manual pages for ltasks may be stored either directly in the source file +as help text segments, or in separate files. If separate source and help +files are used, both files should reside in the same directory and should +have the same root name, and the help text file should have the extension +".hlp". + +.sh +4. Anachronisms + + Certain constructs in the subset preprocessor language are not likely +to survive in their present form in the full preprocessor. These include: + +.ks +.nf + the STRING declaration + the DATA statement + the COMMON statement + the POINTER data type +.fi +.ke + +The STRING declaration will disappear at the same time as the DATA +statement. Both will be replaced by initializations of the form + +.nf + real x = 0.0, y[] = {1.,2.,4.} + char opcodes[SZ_OPCODES] = {'f','g','e','d'} +.fi + +COMMON declarations, in their present form, are cumbersome and dangerous +to use. The global data capability provided by COMMON will be present in +the full preprocessor in a more structured form. + +The POINTER data type will be replaced by a strongly typed (and therefore +much more reliable) implementation of pointers, patterned after C. + +.sh +5. Notes on Topics Not Discussed + + This present version of the SPP reference manual omits a discussion +of the basic i/o facilities, some of which require language support. +Dynamic memory management and pointers will be covered in a later revision +of the manual. Data structuring is possible in the SPP, using macros, +and is discussed in the design documentation for VSIO. + +Programs written in the subset preprocessor language should adhere to +the (currently informal) coding standard being developed for IRAF. The +coding standard has not yet been documented. Try to style procedures after +those shown in the examples, and in the IRAF system source directories. + +.bp +.sh +APPENDIX A: Predefined Constants + + The subset preprocessor language includes a number of predefined +symbolic constants. Included are various machine dependent constants +describing the hardware and data types. Other symbolic constants are +used for basic file i/o. All predefined constants are of type integer. + + +.nf +language and machine definitions: + + ARB arbitrary (array dimension) + BOF,BOFL beginning of file + EOF,EOFL end of file + EOS end of string + EPSILON smallest real x s.t. 1+x > 1 + EPSILOND double precision epsilon + ERR error status return + INDEF indefinite of type REAL + INDEF[SILRDX] indefinites for all types + MAX_DIGITS number of digits of precision (double) + MAX_EXPONENT largest positive exponent + MAX_INT largest positive integer + MAX_LONG largest positive long integer + MAX_REAL largest real or double + MAX_SHORT largest short integer + MIN_REAL smallest representable real number + NBYTES_CHAR number of machine bytes per character + NO opposite of YES + NULL invalid pointer + OK status return, opposite of ERR + SZ_BOOL nchars per bool + SZ_CHAR nchars per char + SZ_COMPLEX nchars per complex + SZ_DOUBLE nchars per double + SZ_FNAME size of a file name string, chars + SZ_INT nchars per int + SZ_LINE size of a file line buffer, chars + SZ_LONG nchars per long + SZ_REAL nchars per real + SZ_SHORT nchars per short + TY_BOOL code for type bool + TY_CHAR code for type char + TY_COMPLEX code for type complex + TY_DOUBLE code for type double + TY_INT code for type int + TY_LONG code for type long + TY_REAL code for type real + TY_SHORT code for type short + YES opposite of NO + + +file i/o definitions: + + APPEND file access mode + BINARY_FILE file type + NEW_FILE file access mode + READ_ONLY file access mode + READ_WRITE file access mode + STDERR standard error output + STDGRAPH standard graphics output + STDIMAGE standard image display output + STDIN standard input + STDOUT standard output + STDPLOTTER standard plotter output + TEXT_FILE file type + WRITE_ONLY file access mode +.fi + +.sh +APPENDIX B: Detailed Examples + +Example 5: Matrix Inversion + + An SPP translation of Bevington's routine to invert a matrix by +gaussian elimination with partial pivoting is shown below. The help +text is shown with text formatter commands inserted. The restriction +of this procedure to matrices of a fixed size is unfortunate, but +we have kept it that way to conform to Bevington's original code. +.nf + + +.help matinv 2 "math library" +.nf ____________________________________________________________________ +NAME + matinv -- invert a symmetric matrix and calculate its determinant. + +SOURCE + Bevington, pages 302-303. + +USAGE + call matinv (array, order, determinant) + +PARAMETERS + + array (real) Input matrix of fixed size 10 by 10 (smaller + matrices may be placed in this matrix). Replaced by the + inverse upon output. + + order The number of rows and columns in the actual matrix. + + determinant + (real) Determinant of input matrix. + + +DESCRIPTION + The input matrix, which must be dimensioned [10,10] in the calling + program, is inverted, and its determinant is calculated. The + inverse overwrites the input matrix. The algorithm used is + gaussian elimination with partial pivoting. +.endhelp _______________________________________________________________ + +define MAX_ORDER 10 # maximum size of matrix + + +procedure matinv (array, order, determinant) + +double array[MAX_ORDER,MAX_ORDER] +int order +real determinant + +int ik[MAX_ORDER], jk[MAX_ORDER] +int i, j, k, l +double maxval, temp + +begin + determinant = 1. + + do k = 1, order { + + # Find largest element array[i,j] in rest of matrix. + + maxval = 0. + repeat { + do i = k, order + do j = k, order + if (abs(maxval) <= abs(array[i,j])) { + maxval = array[i,j] + ik[k] = i + jk[k] = j + } + + if (maxval == 0) { # abnormal return + determinant = 0.0 + return + } + + # Interchange rows and columns to put maxval in + # array[k,k]. + + i = ik[k] + if (i >= k) { + if (i != k) + do j = 1, order { + temp = array[k,j] + array[k,j] = array[i,j] + array[i,j] = -temp + } + j = jk[k] + if (j >= k) + break + } + } + + if (j != k) + do i = 1, order { + temp = array[i,k] + array[i,k] = array[i,j] + array[i,j] = -temp + } + + # Accumulate elements of inverse matrix. + + do i = 1, order + if (i != k) + array[i,k] = -array[i,k] / maxval + + do i = 1, order + do j = 1, order + if (i != k && j != k) + array[i,j] = array[i,j] + array[i,k] * array[k,j] + + do j = 1, order + if (j != k) + array[k,j] = array[k,j] / maxval + + array[k,k] = 1.0 / maxval + determinant = determinant * maxval + } + + # Restore ordering of matrix. + + do l = 1, order { + k = order - l + 1 + j = ik[k] + if (j > k) + do i = 1, order { + temp = array[i,k] + array[i,k] = -array[i,j] + array[i,j] = temp + } + + i = jk[k] + if (i > k) + do j = 1, order { + temp = array[k,j] + array[k,j] = -array[i,j] + array[i,j] = temp + } + } +end +.fi + +.sh +Example 6: Pattern Matching + + The next example was selected for inclusion here because it demonstrates +most of the control flow constructs, as well as the use of defined +parameters. The STRMATCH procedure searches a string for the specified +pattern. The pattern may contain several meta-characters, or characters +which are not matched but rather which tell STRMATCH what constitutes +a match. For example: + +.nf + if (strmatch (line_buffer, "^{naxis}#=") > 0) + ... +.fi + +In this case, STRMATCH would search for the string "naxis =", returning +the index of the first character matched or zero. The meta-characters are +defined in the INCLUDE file "pattern.h", as follows: +.nf + + +# Pattern Matching Metacharacters (STRMATCH, PATMATCH) + +define CH_BOL '^' # beginning of line symbol +define CH_NOT '^' # not, in character classes +define CH_EOL '$' # end of line symbol +define CH_ANY '?' # match any single character +define CH_CLOSURE '*' # zero or more occurrences +define CH_CCL '[' # begin character class +define CH_CCLEND ']' # end character class +define CH_RANGE '-' # as in [a-z] +define CH_ESCAPE '\\' # escape character +define CH_WHITESPACE '#' # match optional whitespace +define CH_IGNORECASE '{' # begin ignoring case +define CH_MATCHCASE '}' # begin checking case + + +The source for the STRMATCH procedure, in file "strmatch.x", follows. +Though this is not a good example of modular code (the control flow is +too complex), it does serve to illustrate the use of many of the control +flow constructs. + + +include +include + +.help strmatch, gstrmatch +.nf __________________________________________________________________ +STRMATCH -- Find the first occurrence of the string A in the string B. +If not found, return zero, else return the index of the first +character following the matched substring. + +GSTRMATCH -- More general version of strmatch. The indices of the +first and last characters matched are returned as arguments. The +function value is the same as for STRMATCH. + +STRMATCH recognizes the meta-characters BOL, EOL, ANY, WHITESPACE, +IGNORECASE, and MATCHCASE (BOL and EOL are special only as the first +and last chars in the pattern). The null pattern matches any string. +Metacharacters can be escaped. +.endhelp _____________________________________________________________ + + +# STRMATCH -- Search a string for a pattern. + +int procedure strmatch (str, pat) + +char pat[ARB], str[ARB] +int first_char, last_char +int gstrmatch() + +begin + return (gstrmatch (str, pat, first_char, last_char)) +end + + +# GSTRMATCH -- Generalized strmatch which returns the indices of the +# match substring. + +int procedure gstrmatch (str, pat, first_char, last_char) + +char pat[ARB], str[ARB] +int first_char, last_char +bool ignore_case, bolflag +char ch, pch # string, pattern characters +int i, ip, initial_pp, pp + +begin + ignore_case = false + bolflag = false + ip = 1 + initial_pp = 1 + + if (pat[1] == CH_BOL) { # match at beginning of line? + bolflag = true + initial_pp = 2 + } + + # Try to match pattern starting at each character offset in + # string. + + for (first_char=ip; str[ip] != EOS; ip=ip+1) { + i = ip + # Compare pattern to string str[ip]. + for (pp=initial_pp; pat[pp] != EOS; pp=pp+1) { + switch (pat[pp]) { + case CH_WHITESPACE: + while (IS_WHITE (str[i])) + i = i + 1 + case CH_ANY: + if (str[i] != '\n') + i = i + 1 + case CH_IGNORECASE: + ignore_case = true + case CH_MATCHCASE: + ignore_case = false + + default: + pch = pat[pp] + if (pch == CH_ESCAPE && pat[pp+1] != EOS) { + pp = pp + 1 + pch = pat[pp] + } else if (pch == CH_EOL || pch == '\n') + if (pat[pp+1] == EOS && str[i] == '\n') { + first_char = ip + last_char = i + return (last_char + 1) + } + + ch = str[i] + i = i + 1 + + # Compare ordinary characters. The comparison is + # trivial unless case insensitivity is required. + + if (ignore_case) { + if (IS_UPPER (ch)) { + if (IS_UPPER (pch)) { + if (pch != ch) + break + } else if (pch != TO_LOWER (ch)) + break + } else if (IS_LOWER (ch)) { + if (IS_LOWER (pch)) { + if (pch != ch) + break + } else if (pch != TO_UPPER (ch)) + break + } else { + if (pch != ch) + break + } + } else { + if (pch != ch) + break + } + } + } + + # If the above loop was exited before the end of the pattern + # was reached, the pattern did not match. + + if (pat[pp] == EOS) { + first_char = ip + last_char = i-1 + return (i) + + } else if (bolflag || str[i] == EOS) + break + } + + return (0) # no match +end +.fi + +.sh +Example 7: Error Handling + + The following simple procedure reads a list of file names from +the CL, and attempts to delete each file. The DELETE library procedure +will take an error action if it cannot delete a file; this is not +what is desired, so we post an error handler and reissue the error +message from DELETE as a warning message. + + +.nf +include + +# DELETE_FILES -- Delete a list of files. + +procedure delete_files() + +char filename[SZ_FNAME] # name of file to be deleted +int list, clpopns(), clgfil() + +begin + # Fetch template and open it as a list of files. + list = clpopns ("template") + + # Read successive file names from the list, and delete each + # file. + while (clgfil (list, filename, SZ_FNAME) != EOF) + iferr (call delete (filename)) + call erract (EA_WARN) + + call clpcls (list) +end +.fi + + +The Fortran output for the DELETE_FILES procedure is shown below. +Note the implementation of the "template" string, the mapping of long +identifiers into 6 character Fortran identifiers, and the implementation +of the while statement using GOTO. + + +.ks +.nf + subroutine delets() + integer*2 filene(33 +1) + integer list, clpops, clgfil + integer*2 st0001(9) + logical xerpop + data st0001 /116,101,109,112,108, 97,116,101, 0/ + save + list = clpops (st0001) +110 if (.not.(clgfil (list, filene, 33 ) .ne. (-2))) goto 111 + call xerpsh + call delete (filene) + if (.not.xerpop()) goto 120 + call erract (3 ) +120 continue + goto 110 +111 continue + call clpcls (list) +100 return + end +c delets delete_files +c filene filename +c clpops clpopns +.fi +.ke +.endhelp diff --git a/doc/doc/v28revs.ms b/doc/doc/v28revs.ms new file mode 100644 index 00000000..8158844c --- /dev/null +++ b/doc/doc/v28revs.ms @@ -0,0 +1,1247 @@ +.PP +.ce +.ps +2 +\fBIRAF Version 2.8 Revisions Summary\fP +.ps +.ce +June 30, 1989 +.sp 2 +.NH +Introduction +.PP +This revisions notice coincides with the release of version 2.8 of +IRAF. The V2.8 release is a general release for all supported IRAF hosts. +.PP +The following is a brief description of some of the new features available +in IRAF Version 2.8. This is not intended to be an exhaustive list, but +rather a brief summary of the major changes since the last +major release of IRAF Version 2.5 in July 1987 and subsequent intermediate +releases primarily to support Sun/IRAF: IRAF Version 2.6 (February 1988), +IRAF Version 2.6+ (March 1988), and IRAF Version 2.7 (December 1988). +.PP +More detailed revisions notes are available in the system notes files in +the \f(CWiraf$doc\fP and \f(CWiraf$local\fP directories, as well as in the +online revisions notes for the various packages. + +.NH +IRAF System Revisions +.PP +This document highlights the most notable revisions made to the IRAF core +system software for Version 2.8. This is only a revisions summary; +no attempt is made to provide detailed technical documentation for each +revision, nor is there any attempt to exhaustively summarize all revisions. +A complete record of all core system revisions will be found in the +\fISystem Notes\fP for V2.8. Additional information on some of the topics +covered below will be found in the various \fIInstallation Guides\fP +and \fISite Manager's Guides\fP, +and in the \fIIRAF User and Technical Documentation\fP manual sets. + +.NH 2 +Copyright notice +.PP +Subject to AURA and NSF approval, the IRAF software will be copyrighted +sometime during 1989. As a first step in this process, a copyright notice +has been added to all core system source files. The notice reads as follows: +"Copyright(c) 1986 Association of Universities for Research in Astronomy Inc". +We will also be adding a file called COPYRIGHT to the distribution stating +the terms of the copyright and associated licensing agreement for the software. +.PP +The intent of this action is solely to protect the software from unauthorized +commercial exploitation, and the copyright grants, or will grant, the right to +copy, modify, and redistribute the IRAF software provided the original +copyright notice remains intact, the software is made available in source form, +and the rights we grant are passed on with the software. We wish to prevent +others, especially commercial firms, from copyrighting IRAF software in their +own name and possibly taking away the rights we grant with the software. +Granting the right to modify and redistribute IRAF software does not mean +we want to encourage people to do so, we merely want them to have the legal +right to do so if they feel they need to. + +.NH 2 +Major system enhancements +.PP +The information in this section is provided primarily for the benefit of +IRAF site managers and programmers. The reader interested primarily in +science applications may wish to skip ahead. Some systems level familiarity +with the current IRAF system is assumed. +.NH 3 +Layered software enhancements +.PP +A given IRAF installation consists of the core IRAF system, and any number +of \fBlayered software products\fP or \fBexternal packages\fP. The goal +of the layered software enhancements introduced in V2.8 is to make layered +software products self contained and hence independent of the core system +and of other layered software. Examples of layered software products are +the NOAO packages, LOCAL, STSDAS, PROS, and so on. +.PP +The layered software enhancements make it possible to install or deinstall +a layered product by modifying only a single file in the core IRAF system. +The core system may be updated without affecting layered software, and vice +versa. Since layered products are independent and are simple to install, +IRAF can easily be configured with only those packages needed at a particular +site. Software developers benefit from the layered software enhancements +because the facilities provided for development and maintenance of layered +software are equivalent to those provided for development of the core IRAF +system and the NOAO packages. User sites benefit because it is easy to +extend the system with LOCAL packages of their own making. +.PP +Each layered product (usually this refers to a tree of packages) is a system +in itself, similar in structure to the core IRAF system. Hence, there is a +LIB (global system library), one or more BINs (binary file directories), +a Help database, a set of global environment definitions, and all the sources +and runtime files, all contained within the same directory tree. Layered +software products, in their source only form, are portable without change +to any computer which runs IRAF. +.NH 4 +The hlib$extern.pkg file +.PP +This is the file which is modified to install or deinstall layered software +products. To install a layered product, one creates a directory to hold +the software, restores the files to disk, and edits the \f(CWextern.pkg\fP file +to tell IRAF the name of the root package of the layered product, and where +the root directory is located. If the layered software is distributed in +source only form it will also be necessary to recompile the software, but +this is a completely automated process. +.NH 4 +NOAO and LOCAL packages reorganized +.PP +As part of the project to better support layered software, the NOAO and +LOCAL packages have been reorganized as layered products. These packages +are now structurally equivalent to third party (non-NOAO) packages, +except that the directory trees are rooted in IRAF. Both packages are +now self contained, with their own LIB, BINs, Help database, etc., +and with an entry in \f(CWextern.pkg\fP, like other layered products. +The NOAO package serves as a working example of how to configure a +layered package. The reorganization of these packages should be +transparent to anyone merely using the system. +.NH 4 +The template LOCAL +.PP +The LOCAL package included with the distributed system has been stripped of +all NOAO site-local tasks and restructured as a layered product, +the \fItemplate local\fP. The template local contains only two sample +tasks and is not intended as an end-user package, but rather as a template +to be copied and modified by sites to construct their own site dependent +LOCAL package. The desire to be able to easily develop and maintain +locally added packages was one of the major motivations for the layered +software enhancements project, and we hope that sites will realize the +significance of this new capability and take advantage of it. +.NH 4 +CL now supports package level BIN directories +.PP +Rather than assuming a global BIN directory for all tasks and packages, +the CL now permits multiple BIN directories, each BIN directory being +associated with the package of definition and all subpackages of that +package (unless they have their own BIN). A new BIN directory is declared +with the optional argument \f(CWbindir=\fIpath\fR in the \f(CWpackage\fP +statement, e.g., in a package script task. +.NH 4 +MKPKG support for package environments +.PP +Layered packages now have their own private LIB, including an environment +definitions file (\f(CWzzsetenv.def\fP), mkpkg global include file +(\f(CWmkpkg.inc\fP), and, optionally, a mkpkg special file list file for +each supported host system, listing files requiring special compilation +to work around host compiler bugs or whatever. The full mkpkg environment +is formed by reading the IRAF core system environment and mkpkg definitions +and include files, followed by the package definitions and include files. +Reading of the package environment occurs \fIonly\fP if mkpkg is called +with the "\fB-p\fR" flag, or if the variable \f(CWPKGENV\fP is defined in +the user's environment. +.PP +Another way of expressing this is, when using mkpkg within a layered package, +one must now specify the name of the layered package in order to pick up the +package environment definitions. For example, to update the MTLOCAL package +in NOAO, one would type "\f(CWmkpkg -p noao update\fP" in the \f(CWmtlocal\fP +directory. If this is not done compilation errors may result, or the +exectable may not be successfully installed in the package BIN directory. +.NH 3 +Multiple architecture support +.PP +A single IRAF system (or layered package) can now simultaneously support any +number of machine architectures using multiple BIN directories sharing a +single machine independent copy of IRAF. Each BIN directory contains all +the object modules, object libraries, and executables for a particular +architecture. An architecture can represent either a type of hardware, +e.g., sparc, mc68020+f68881, mc68020+ffpa, vax, etc., or a software +distinction, e.g., systems compiled with different sets of compiler flags, +or different versions of a system. Multiple architectures are now supported +both for IRAF execution, and for IRAF based software development, e.g., +a single version of IRAF can now be used to develop and run IMFORT programs +on both Sun-3 and Sun-4 nodes. +.PP +The only case where multiple architecture support is used at the present +time is in Sun/IRAF, which is often installed on a heterogeneous network of +workstations, e.g., Sun-3s with various hardware floating point options, +and Sun-4s. A single copy of IRAF will be configured with several BIN +directories, one for each supported architecture, and NFS mounted on all +the network nodes which will be using IRAF. There is no reason that this +feature need be restricted to use with Sun/IRAF, however. +.NH 4 +IRAFBIN and IRAFARCH +.PP +Starting with IRAF V2.8, the old environment variable \f(CWIRAFBIN\fP has been +obsoleted and replaced by \f(CWIRAFARCH\fP. On machines which support +multiple architectures, the latter defines the architecture to be used for +both IRAF execution and software development. If only IRAF execution is +needed the variable is optional, with the best architecture being selected +automatically when the CL is started. If one will be doing software +development (including IMFORT) it is best to define the variable in the +host environment before starting IRAF or doing any host level software +development. Typical values of \f(CWIRAFARCH\fP for a Sun workstation are +"sparc", "i386", "f68881", and "ffpa". +.NH 4 +System libraries moved to the BIN directory +.PP +As part of the revisions required for multiple architecture support for +software development, all object libraries have been moved from the global, +architecture independent LIB to the architecture dependent BIN, with the +LIB entries being replaced by symbolic links (in the case of Sun/IRAF). +This should be transparent to both end users and programmers. +.NH 4 +New bin.generic architecture +.PP +On Sun/IRAF systems, which are distributed configured for multiple +architecture support, the system architecture is set to \f(CWgeneric\fP +in the distributed system. What this means is that all architecture +dependent files (objects and object libraries) have been removed from +the system directories and archived in the file \f(CWOBJS.arc\fP in the +BIN directory for each architecture. Rebuilding any of the packages in +a system would require restoring the binaries for a particular architecture, +e.g., typing "\f(CWmkpkg sparc\fP" at the IRAF root would restore the +sparc binaries for the core system on a Sun/IRAF installation. Note that +this \fIonly\fP affects software development for the system in question; +software development for external packages or private user software is +not affected. +.NH 3 +Shared library facility +.PP +IRAF version 2.8 adds support for a general shared library facility for +UNIX based systems. Although currently only used with Sun/IRAF, +this facility is potentially useful for other UNIX based IRAF systems +as well (VMS/IRAF already has its own shared library facility). +.PP +What the shared library facility does is take most of the IRAF system +software (currently the contents of the \f(CWex\fP, \f(CWsys\fP, \f(CWvops\fP, +and \f(CWos\fP libraries) and link it together into a special sharable +image, the file \f(CWS.e\fP in each core system BIN directory. This file +is mapped into the virtual memory of each IRAF process at process startup +time. Since the shared image is shared by all IRAF processes, each process +uses less physical memory, and the process pagein time is reduced, speeding +process execution. Likewise, since the subroutines forming the shared image +are no longer linked into each individual process executable, substantial +disk space is saved for the BIN directories. Link time is correspondingly +reduced, speeding software development. +.PP +With the introduction of the shared library facility, the disk space +required for Sun/IRAF is substantially reduced. Due to the increased memory +sharing and reduced process pagein times performance is substantially +improved, especially on systems like the Sun/386i which has a relatively +slow SCSI disk and often limited memory. The disk size of small programs +is reduced by up to a factor of ten in some cases, e.g., an executable +for a small program that was formerly 250 Kb in size might be as small as +25 Kb if the shared library is used and the shared image symbols are omitted +at link time. + +.NH 2 +User interface changes +.NH 3 +Calling IRAF tasks from the host environment +.PP +The IRAF main and zmain were modified to make it easier to call IRAF tasks +as host level tasks, i.e., without having to set up a command file and +run the process with the standard input redirected. In the new scheme, +any extra arguments given on the process command line are passed into +the IRAF main as a command buffer containing the IRAF command or +commands to be run. For example, +.DS +\f(CWcl> x_system.e netstatus\fP +.DE +would run the command \f(CWnetstatus\fP in process \f(CWx_system.e\fP. +.DS +\f(CWcl> x_system.e count "files=*.x"\fP +.DE +would run the \f(CWcount\fP task, counting all ".x" files in the current +directory. +.DS +\f(CWcl> x_system.e count "files=*.x 4>_o"\fP +.DE +would do the same, redirecting the output at the IRAF main level to +the file \f(CW_o\fP. +.DS +\f(CWcl> x_system.e 'directory @pars $nargs=0'\fP +.DE +would run the \f(CWdirectory\fP task with the given parameter set, with +\f(CW$nargs\fP set to 0. If any of the parameters to a task are omitted +the task will query the terminal for them in the usual way, so for example +.DS +\f(CWcl> alias count "$iraf/bin/x_system.e count files="\fP +.DE +would make the IRAF task \f(CWcount\fP available in UNIX, allowing the +IRAF template specifying the files to be counted to be either given +on the UNIX command line, or prompted for if omitted. Given the +above alias, one could enter a UNIX command such as +.DS +\f(CWcl> count 'cl$*.h'\fP +.DE +.LP +This feature is available in all UNIX based versions of IRAF V2.8, +but did not make it into VMS/IRAF version 2.8. +.NH 3 +Image packing density control (impkden) +.PP +Some users have complained about images taking up more disk space than they +have to, due to the IMIO feature which conditionally blocks image lines to +fill an integral number of disk blocks. This can result in more efficient +image i/o but can also make a significant difference in the amount of disk +space consumed by an image in some cases. +.PP +IMIO can actually support both block-aligned and fully packed images. +The decision is made at image creation time and is based on the \fBimage +packing density\fP if image lines are block aligned. If the packing +density is too low for a block-aligned image, a fully packed image is created +to avoid wasting disk space. The default minimum packing density is 0.6, +i.e., up to 40% wasted space before IMIO switches to full packing (no +wasted space). +.PP +For finer control over the packing density, the user can now specify the +optional environment variable \f(CWimpkden\fP, the numeric value being the +mininum packing density. For example, +.DS +\f(CWcl> set impkden = 1.0\fP +.DE +would completely disable block-alignment of image lines in IMIO. +.NH 3 +User libraries (IRAFULIB) +.PP +It is now possible for the programmer (SPP or IMFORT) to specify a private +directory to be searched at compile or link time when developing IRAF or IMFORT +programs. This is done by defining the path to the directory in the user +environment as the variable \f(CWIRAFULIB\fP. When locating a particular file, +this directory will be searched \fIbefore\fP the IRAF system libraries are +searched, hence this feature may be used to substitute custom versions of +files in the IRAF system libraries, e.g., for debugging purposes. +.NH 3 +New logical printer device LPR +.PP +A new logical line printer or plotter device \f(CWlpr\fP is now supported on +all UNIX/IRAF systems. This treats the UNIX task \fIlpr\fP as a kind of +pseudo-device, leaving it up to UNIX to decide what physical device to dispose +of the output to. This default is system dependent, but on some systems can +be controlled by defining the variable \f(CWPRINTER\fP in the user environment. +.NH 3 +Machine independent help database +.PP +The IRAF \f(CWhelp\fP task uses a precompiled binary database to speed help +keyword searching. This file is now machine independent, allowing it to be +generated on one system and included in software distributions without +having to be recompiled. In addition, as part of the layered software +support, \f(CWhelp\fP now allows each external package to have its own +private help database. The first time \f(CWhelp\fP is run, all such databases +are read and linked to produce a database containing entries for all +help modules in the core system and all installed external packages. +The help database file is the file \f(CWhelpdb.mip\fP in the LIB directory +of the core system and each external package. +.NH 3 +Set terminal type will no longer hangup +.PP +On systems, e.g., workstations, which provide virtual terminal windows which +can change in size, IRAF may query the terminal at run time to determine +the screen size. This query is performed, for example, at login time if +the terminal type is set to \f(CWgterm\fP or \f(CWsun\fP. Formerly this +could cause the login process to hang indefinitely (i.e., until the user +typed return or interrupt) if the terminal did not respond to the size query, +as would happen when the terminal type was set improperly and the actual +terminal ignored the query. Thanks to the addition of non-blocking raw +terminal i/o in V2.8 IRAF, the terminal screen size query will now time out +with a warning message to reset the terminal type, if the terminal does +not respond to the query within several seconds. +.NH 3 +Installing a new version of IRAF obsoletes old user parameter files +.PP +The problem of old, obsolete user (\f(CWuparm\fP) parameter files being +used with a newly installed version of IRAF, which could lead to "parameter +not found" error aborts, has been fixed. The CL now checks the date of +the file \f(CWutime\fP in HLIB, and refuses to use the user pfile if it +is older than either \f(CWutime\fP or the package pfile provided with the +new system. The contents of old user pfiles are merged into the new system +pfile, as before, preserving learned parameter values even when the user +pfile is obsolete. +.NH 3 +@file list bug fixed +.PP +The problem of the "@file" (at-file-list) syntax not working when the file +in question was not in the current directory has been fixed. + +.NH 2 +Programming interface changes +.NH 3 +IMFORT pixel directory control +.PP +IMFORT has been modified to permit specification of the pixel file +directory by the calling program. The modifications are completely +upwards compatible, i.e., existing programs linked with the new +interface will still create pixel files in the same directory as +the header file, with "HDR$" in the image header. +.PP +The Fortran programmer may set or query the pixel file directory +using the following routines: +.DS +\f(CWimsdir (dir) # set pixel directory pathname +imgdir (dir) # get pixel directory pathname\fP +.DE +where \fIdir\fP is a Fortran character variable. The value should +be either "HDR$" (the default) or a concatenatable host directory +pathname (i.e., trailing / required for unix). Once set, the +pixel directory will be used for all subsequent image create or +rename operations by the calling process. +.LP +For example, +.DS +\f(CWcall imsdir ("/tmp3/pixels/") +call imcrea (image1, axlen, naxis, dtype, ier) +call imcrea (image2, axlen, naxis, dtype, ier)\fP +.DE +If desired the default pixel directory may be specified in the +host environment as \f(CWimdir\fP or \f(CWIMDIR\fP before running the program. +IMFORT will check the host environment for this environment variable +then use "HDR$" as the default if no host definition is found. +.PP +Note that although this is similar to setting the value of \f(CWimdir\fP +in the IRAF environment, IMFORT programs are not part of the IRAF +environment and are not affected by changes to the IRAF \f(CWimdir\fP. +Also, since IMFORT is a host level facility and IRAF networking is +not supported, the network prefix (e.g., "node!") is omitted from the +pixelfile pathname, and since IMFORT programs are not necessarily used +in conjunction with IRAF, the "\f(CW..\fP" (hidden file protection) files +are not used to protect against image deletion. +.NH 3 +Image display interface: IMD +.PP +A new interface IMD has been added to provide a rudimentary facility for +interactive image display device control. This is an interim prototype +interface which will be replaced by the new display interfaces when the +latter become available. +.PP +The IMD interface operates by mapping an image display device frame buffer +onto an IMIO image descriptor. The display frame buffer may then be randomly +edited by normal image i/o operations, e.g., to modify subrasters of the +displayed image, or overlay the image with color graphics. The image pixel +to display frame buffer coordinate transformation is supported, allowing +applications to work in image pixel coordinates if desired. This interim +interface is what is used by the new display oriented tasks \f(CWimexamine\fP, +\f(CWimedit\fP, and \f(CWtvmark\fP. +.NH 3 +Image masks: PLIO, PMIO, MIO +.PP +The following new VOS interfaces have been added in V2.8 to provide a +general boolean or integer image mask facility. +.DS +PLIO pixel list i/o +PMIO pixel (image) mask i/o +MIO masked image i/o (image i/o through a mask) +.DE +.PP +PLIO is a general interface for storing and manipulating +multidimensional integer valued rasters containing regions of +constant value (i.e., masks). The masks are stored in a highly +compressed form, the size of the compressed mask being a function +of the information content of the mask. Both pixel array and +range list i/o facilities are provided, as well as a set of general +boolean raster operators, e.g., to extract or insert subrasters, +AND or OR a source with a destination, do the same through a stencil, +draw regions of various kinds (point, line, box, circle, polygon), +and so on. See the \f(CWPLIO.hlp\fP file in the PLIO source directory +for further information. +.PP +An interactive debug program (\f(CWplio$zzdebug.x\fP) is provided for +experimenting with masks. Note that PLIO is a stand alone interface +and is not tied in any way to IMIO, even though the data structure +operated upon is similar to an image matrix. +.PP +PMIO is very similar to PLIO except that it is used to associate a +masks with an IMIO maintained reference image. Currently, the PMIO +mask must be the same resolution as the physical reference image. +All coordinates input to PMIO are in the \fIimage section coordinates\fP +of the reference image. Hence, given a physical image and associated +mask, one can operate upon both through a user specified image section +transparently to the applications program. This includes all PLIO +style boolean rasterop operations, as well as mask pixel and range +list i/o. The PMIO interface is layered upon PLIO and IMIO, and the +calling sequences are identical with PLIO except for the package +prefix, and the addition of several new PMIO specific routines. +.PP +MIO is essentially an extension of image i/o for pixel i/o through a +mask. The central routines are the following: +.DS +\f(CW mio_setrange (mp, vs, ve, ndim) +n|EOF = mio_[gp]lseg[silrdx] (mp, ptr, mval, v, npix)\fP +.DE +One defines a rectangular region of the image with mio_setrange, +and then sequentially reads or writes line segments until all pixels +visible through the mask have been accessed. This type of i/o should +be ideal for most image processing applications which need to operate +upon only those pixels visible through a region mask (e.g., a surface +fitting task), upon all pixels except those on a bad pixel mask (e.g., +any analysis program), and so on. +.PP +PLIO (or PMIO) masks may be stored in binary files on disk, the files +having the extension "\f(CW.pl\fP". The V2.8 version of IMIO has the +capability to treat such masks as if they were images, allowing masks +to be easily displayed, used in image expressions, converted to +image matrices and vice versa, etc. Applications may do either pixel +or \fIrange list i/o\fP to a mask image via IMIO, if MIO is not suitable +for some reason. +.NH 3 +Photon images: QPOE, QPIO, QPEX +.PP +A new set of VOS interfaces supporting photon or \fBevent list data\fP +are now available. The QPOE interface implements the Position Ordered Event +list object, which consists of a general header mechanism plus an +event list, wherein the events are little data structures, e.g., +the attributes required to describe a photon detection (position, +energy, time, etc.). QPOE is designed to efficiently access very large +event lists, e.g., several hundred thousand or several million events in size. +Builtin event attribute filtering and region filtering capabilities are +provided for selecting photons from the event list. These filtering +capabilities may be combined with the sampling capability to produce +filtered, block averaged image matrices from event lists. +.LP +The QPOE interfaces are the following: +.DS +QPOE header and file access and management facilities +QPIO raw and filtered event i/o +QPEX event attribute filter mechanism +QPF IMIO/IKI kernel for image interface to QPOE files +.DE +QPOE and QPF add a new image type to the system, with \f(CW.qp\fP file +extension. Hence, event list data can be used as input to any of the image +processing tasks in standard IRAF, in addition to being analyzed by tasks +which deal with the individual photon events. A QPOE image is contained in +a single file. When a QPOE file is accessed as an image the interface +filters and samples the event list in real time, using a user defined filter, +block averaging factor, region mask, and so on, producing the image matrix +seen by applications at the IMIO level. The QPOE object may be repeatedly +examined with different event filters to view the data in different ways. +.PP +The QPOE interface, in addition to providing an event list capability for +IRAF, serves as a prototype for the "flex-header" portion of the new image +structures project. Many of the capabilities to be provided for image +storage under the new image structures are already present in QPOE. +.PP +Further information is given in the \f(CWQPOE.hlp\fP file in the QPOE +source directory. +.NH 3 +File manager: FMIO +.PP +A new VOS library FMIO has been installed. FMIO is "File Manager I/O", +and is used to implement a simple binary file manager which maintains the +file data of so-called "lfiles" (lightweight files) inside a single +host binary file. The system overhead for accessing lfiles is much +less than that of host files, and many lfiles can be used to store +a complex data structure without cluttering a host directory or +incurring the inefficiency of accessing host files. FMIO is part of +the DFIO project and will serve as the lowest level interface within +DFIO; it is also used currently in the QPOE interface. Additional +information is given in the README file in the source directory for +the interface. +.NH 3 +IMIO changes +.PP +IMIO is the image i/o interface, the standard IRAF VOS interface for managing +all varieties of image data. +.NH 4 +Mask image support +.PP +IMIO now supports a new type of image, the \fBmask image\fP, stored as a +highly compressed binary (PLIO) file with the extension "\f(CW.pl\fP". +Image masks are most commonly used to store information describing selected +pixels in an associated data image. An image mask is logically a boolean +or integer image, up to 28 bits deep, containing information only on selected +pixels or regions of pixels. Masks are stored in highly compressed format, +e.g., a simple mask may be stored in only a few hundred bytes of space. +Mask images are readable, writable, and randomly modifiable, like ordinary +raster images. See \(sc2.4.3 for more information. +.NH 4 +Photon image support +.PP +Support has also been added to IMIO for \fBevent list images\fP, stored +as position ordered event list datafiles using the QPOE interfaces. +This new image type has the extension "\f(CW.qp\fP". QPOE images are +read-only under IMIO. Subject to that restriction, they may be accessed +like any other image by any IRAF image analysis program. Accessing an +event list image as a raster image necessarily involves a runtime sampling +operation, wherein the events in the region of interest are accumulated +into an initially zero image matrix; in the process the event list may +optionally be filtered by event attribute or event position, e.g., +.DS +\f(CWcl> display "xray.qp[t=(30:40),pha=10,block=4]"\fP +.DE +would display the QPOE image \f(CWxray.qp\fP with a blocking factor of 4, +selecting only those events with \f(CWt\fP (time) in the range 30 to 40 and +for which \f(CWpha\fP (energy) has the value 10. The event attributes and +their names are user definable and may vary for different types of data. +See \(sc2.4.4 for more information. +.NH 4 +IMPUTH +.PP +A new procedure \f(CWimputh\fP has been added to the IMIO header access +library. The new procedure is used to append FITS like HISTORY or COMMENT +cards to the image header. +.NH 4 +IMPARSE +.PP +The calling sequence of the internal IMIO procedure \f(CWimparse\fP has +changed. Although this procedure is internal to the IMIO interface and is +not supposed to be used within applications, there may be applications which +make use of this procedure. Any such applications must be modified to +reflect the new procedure calling sequence or runtime problems are guaranteed. +.NH 3 +Null string environment variables +.PP +The semantics of the VOS procedures \f(CWenvgets\fP and \f(CWenvfind\fP +have changed. This could affect existing programs and any programs which +use these functions should be checked to make certain they will still work +properly. +.PP +These procedures, used to fetch the string values of environment variables, +return the length of the output string as the function value. +Formerly, a value of zero would be returned +both when the named variable existed but had a null string value, and when +the variable was not found. This made it impossible to discriminate between +the case of a variable not being defined, and one which is defined but has +a null value. The routines have been changed to return the value ERR (a +negative integer) if the variable is not defined. Programs which do not +wish to make the distinction between undefined and null-valued should check +for a function value less than or equal to zero. Programs which check for +a function value equal to zero will fail if the named variable is not defined. +.NH 3 +Environment substitution in filenames +.PP +The VOS filename mapping code has been modified to add support a powerful new +environment substitution syntax. Previously the only environment substitution +mechanism available was the logical directory facility, which could only be +used to parameterize the directory field. The new facility may be used to +perform environment substitution anywhere in a filename. This is used in +IRAF version 2.8 to implement multiple architecture support, e.g., +.DS +\f(CWcl> set bin = "iraf$bin(arch)/"\fP +.DE +is how the core system BIN is defined in V2.8 IRAF. +The syntax "\f(CW(arch)\fP" tells the filename mapping code to substitute +the string value of the environment variable \f(CWarch\fP, if defined. +If the variable is not defined the null string is substituted. Hence, +if the host system does not implement multiple architecture support and +\f(CWarch\fP is not defined, BIN is defined as "\f(CWiraf$bin/\fP", +which is the backwards compatible definition. If \f(CWarch\fP is defined +as, e.g., "\f(CW.vax\fP", then BIN is defined as "\f(CWiraf$bin.vax/\fP". +The new feature allows use of a single environment variable to define +the architecture, not only to form filenames, but for other purposes as +well, e.g., to generate compiler switches or to control library searching +in \f(CWmkpkg\fP. +.NH 3 +Nonblocking raw terminal i/o +.PP +The VOS file i/o interfaces have been modified to add support for nonblocking +terminal i/o. This facility makes it possible to, in effect, "poll" the +terminal to see if there is any input waiting to be read, to allow interaction +without having a program block if the user has not typed anything. +.PP +The immediate application of this in version 2.8 was the modification +of the \f(CWstty\fP (set-terminal) facility to implement a time out for +the terminal size query. Formerly, \f(CWstty\fP would hang up indefinitely +when the terminal type was set to "gterm" but the actual terminal was +something different, causing the screen size query to be ignored. +.PP +In the more general case, nonblocking terminal i/o makes possible a new +class of user interface, which is not only interactive, but \fBevent driven\fP. +Nonblocking i/o makes it possible for an application to be continually +processing, while checking the terminal occasionally to see if the user +has input any commands. +.PP +At present, nonblocking i/o is always used in conjunction with raw mode +input from a terminal. A new flag \f(CWF_NDELAY\fP, +defined in \f(CW\fP, is used to enable or disable nonblocking i/o. +For example, +.DS +\f(CWcall fseti (fd, F_RAW, YES)\fP +.DE +enables conventional blocking, single character raw mode reads, and +.DS +\f(CWcall fseti (fd, F_RAW, YES + F_NDELAY)\fP +.DE +enables nonblocking raw mode input (\f(CWYES\fP, \f(CWNO\fP, +and \f(CWF_NDELAY\fP are bit flags). These modes are mutually exclusive, +e.g., the first call may be issued while nonblocking raw mode is in effect +to make the reads block, and vice versa. A call to \f(CWfset(fd,F_RAW,NO)\fP +disables both raw mode and nonblocking mode. Once nonblocking raw mode is +in effect one merely reads characters from the terminal in the usual way, +using \f(CWgetc\fP. EOF is returned if a read is performed when no data +is available for input, otherwise the next character is returned from the +input queue. Further information on nonblocking i/o is given in the system +notes file. +.NH 3 +Function call tables (ZFUNC) +.PP +IRAF has always had the ability to compute the integer valued address of a +procedure, store that address in a table, and later use the address as an +argument to one of the \f(CWzcall\fP kernel primitives to call the addressed +procedure. This facility has been extended by the addition of a set of +\f(CWzfunc\fP primitives, used to call integer valued \fIfunctions\fP. +Only integer valued functions are supported (in order to simplify the kernel +support required), but in the systems oriented applications where procedure +call tables are used, this is unlikely to be a serious limitation. + +.NH 2 +Sun/IRAF specific revisions +.NH 3 +IEEE exception handling +.PP +By default the IEEE hardware is now configured, on all Sun systems, +with the invalid, overflow, and divide by zero IEEE exceptions enabled, +and with the default rounding direction and precision modes (nearest, +extended) in effect. This configuration should ensure that all +questionable floating point operations are detected, and that no IEEE +"funny numbers" (NaN, Inf, etc.) get into the data. These values, +since they don't behave like ordinary numbers, can cause programs +to misbehave, e.g., go into an infinite loop. In Sun/IRAF V2.8, +if a computation results in an IEEE funny number being generated, +an exception abort will result. The most common example is divide by zero. +.PP +The IRAF/IEEE interface offers a special debug feature that may be of +interest to programmers developing numerically sensitive software. +If desired, one can change the default rounding direction and +precision (e.g., to test the numerical stability of applications) +by using the debugger to set a nonzero value of the variable +\f(CWdebug_ieee\fP before running an executable. The procedure for +doing this is documented in the system notes file. +.NH 3 +IMTOOL enhancements +.PP +A number of enhancements and bug fixes have been made for V2.8 to the SunView +based IMTOOL image display server. The most notable changes are summarized +here; refer to the IMTOOL manual page for a more complete description of the +new features. +.NH 4 +Software ZOOM added +.PP +IMTOOL, which has had for some time the ability to pan about on a large +image, now has the ability to zoom as well. Both pan and zoom are controlled +very conveniently by the middle mouse button: place the mouse on an object +and tape the middle button once to pan the object to the center of the +display window; tap it again and the image will be zoomed. Zoom, currently +implemented by writing directly into the hardware frame buffer, is very fast, +almost as fast as a normal unzoomed window refresh. The default set of zoom +factors is 1,2,4,8 after which the sequence wraps around to 1. The zoom +factors are user configurable via the IMTOOL setup panel; very large zoom +factors, e.g., x64, are possible. Dezoom (making a large image smaller) +is not currently supported. +.NH 4 +WCSDIR eliminated +.PP +The host level \f(CWWCSDIR\fP environment variable, and the text file used +to communicate image coordinate (WCS) information between the display task +and the display server, have been eliminated. All WCS information is now +passed via the datastream used to pass commands and data between the client +and the display server. This eliminates the need for users to have to +remember to define \f(CWWCSDIR\fP in order to get coordinates in image units, +and some subtle process synchronization problems are eliminated as well. +.PP +In a related change, the frame buffer configuration index is no longer +passed in during a frame erase, hence it is no longer necessary to erase a +frame before displaying an image to ensure that a frame buffer configuration +change is passed to the server. The configuration index is now passed when +the WCS information for a frame is set. +.NH 4 +Graphics colors +.PP +IMTOOL now allocates a range of pixel values for use as graphics overlay +colors. Setting a frame buffer pixel to one of these values causes it to +always be displayed with the assigned color. The graphics color values are +not affected by windowing the display. The most common use of graphics +colors with V2.8 IRAF is for drawing graphics into a displayed frame with +the new \f(CWtvmark\fP task, available in PROTO. See the IMTOOL manpage +for a table listing the color index assignments. +.NH 4 +New imtoolrc entries +.PP +Several new predefined frame buffer configurations have been added to the +default \f(CWimtoolrc\fP. These include an 128 pixel square frame buffer +(\f(CWimt128\fP), a 256 pixel square frame buffer (\f(CWimt256\fP), +and a full screen display with the same aspect ratio as a 35 mm slide +(\f(CWimtfs35\fP). +.NH 4 +System crash (FIFO) bug fixed +.PP +Versions of SunOS through at least 4.0.1 have a bug in the FIFO driver code +which can cause the internal kernel FIFO data buffer to be deallocated while +it is still in use. This will result in a bad kernel which will eventually +panic and reboot the system. This is the cause of the IMTOOL crash problem +which some sites may have experienced. IMTOOL has been modified to avoid +the circumstances (repeated 4096 byte transfers) which cause the bug to +surface. So far as we know, the real bug (in SunOS) has not yet been fixed, +but at least on the NOAO systems, the frequency of occurrence of the system +crashes is greatly reduced with the new version of IMTOOL which incorporates +the workaround for the SunOS bug. +.NH 4 +Cursor marking now disabled by default +.PP +When the interactive image cursor read facility was first added to IMTOOL, +the default response to each cursor read was to draw a small white dot at +the position of the cursor. This is convenient when marking a series of +objects to make a list, but with the increasing number of IRAF programs +making user of the interactive image cursor, it has been necessary to change +the default to disable automatic marking of each cursor read. The cursor +mark feature is still available as an option and can be enabled via the +setup panel. +.NH 4 +Ctrl/b may be used for manual blinking +.PP +In addition to the list of blink frames and the timed blink feature IMTOOL +has provided for some time, it is now possible to manually cycle through +the blink frames with the key. Typing while the mouse +is in the image window will cause the display to display the next blink +frame in sequence. +.NH 4 +F4 key will now toggle setup panel +.PP +The F4 function key on the Sun keyboard may now be used to toggle whether +or not the setup panel is displayed. This provides a single keystroke +alternative to calling up the setup panel with the frame menu. + +.NH 2 +VMS/IRAF specific revisions +.NH 3 +NEWUISDISP added to VMS/IRAF +.PP +Nigel Sharp's \f(CWNEWUISDISP\fP display program, used for image display +under UIS on microvaxes with bitmapped displays, is now available in the +standard VMS/IRAF release, in the directory \f(CW[IRAF.VMS.UIS]\fP. +.NH 3 +New INSTALL.COM script +.PP +A new \f(CWINSTALL.COM\fP script (also written by Nigel Sharp) has been +added to VMS/IRAF. This script, run by the system manager to install +selected IRAF executable images, will now automatically check for and +deinstall any old versions of the executables before installing the new ones. +.NH 3 +VMS 4.7/5.0 +.PP +Testing of the standard V2.8 VMS/IRAF release, which was prepared on VMS 4.7, +on a VMS 5.0 system has thus far not revealed any problems (NOAO is still +running VMS 4.7 as our standard system). Hence it appears that the standard +V2.8 VMS/IRAF will \fIrun\fP under VMS 5. It is likely, however, that any +attempt to \fIrecompile\fP VMS/IRAF under VMS 5 would cause problems, +since we have not yet tried to rebuild IRAF under VMS 5, and such a major +operating system upgrade will often require changes to the IRAF code. +The system may be relinked under VMS 5 if desired, and this does not appear +to cause any problems, but neither does there appear to be any benefit to +be gained from doing so. + +.NH 2 +Summary of IRAF System Packages Revisions +.sp +.IP \(bu +The tasks RFITS and WFITS in the DATAIO package now support the +reading and writing of arbitrary sized data blocks (IRAF version 2.7 +and later). +.IP \(bu +Several new tasks were added to the IMAGES package. IMCOMBINE (IRAF +version 2.6 and later) provides for the combining of images by a number +of algorithms. The new task CHPIXTYPE (IRAF version 2.7 and later) +changes the pixel types of a list of input images. The task IMSLICE +slices images into images of one less dimension (IRAF version 2.8). +The task IMSTACK has been moved into the IMAGES package (although it +still resides in PROTO as well). +.RS +.LP +The IMSTATISTICS task has been rewritten and now allows the user to select +which statistical parameters to compute and print (IRAF version 2.8). +The IMRENAME task has been modified to allow "in place" image renames, +used chiefly for moving the pixel files to a new IMDIR. +.LP +Several other tasks in the IMAGES package were modified (IRAF +version 2.8). IMSHIFT was modified to accept a list of shifts from +a file. REGISTER and GEOTRAN were modified to accept a list of +transforms instead of only a single one. IMHISTOGRAM has undergone +extensive revision including support for "box" type plots, support +for linear or log scaling in the y coordinate, as well as support +for antialiasing of the histogram bins. +.RE +.IP \(bu +All the tasks in the IMAGES.TV package were modified (IRAF version 2.8) +so that if a task +is used with an unsupported display device a message is printed +to that effect. +.IP \(bu +The STTY task in the LANGUAGE package has been improved (IRAF version 2.6 +and later) to better +facilitate its "playback" feature. These changes have been documented +in the online help for the task. This feature is little used by +external sites but can be a very useful instructional aid if users +are aware of its capability. +.IP \(bu +A new task PVECTOR was added to the PLOT package that allows one to +plot an arbitrary vector in a two dimensional image (IRAF version 2.6 +and later). +.RS +.LP +The task STDPLOT was modified (IRAF version 2.8) +so that it uses the more popular SGI kernel +rather than the NSPP (NCAR) kernel (STDPLOT is now +equivalent to the SGIKERN task). +A new task NSPPKERN was added that uses the NSPP kernel. +.RE +.IP \(bu +Two new tasks were added to the SYSTEM package (IRAF version 2.8). +The task DEVICES simply prints the \f(CWdev$devices.hlp\fP file as edited +by the site manager listing available devices on the local host or +network. The REFERENCES task is used to search the help database +for all tasks or other help modules pertaining to a given topic, +e.g., \f(CWreferences vector\fR will list all tasks that have the string +"vector" in their one line description. +.NH 2 +Glossary of New Tasks in the IRAF System Packages +\fR +.TS +center; +c c c c c +l c l c lw(4i). +Task Package Description +_ + +chpixtype - images - Change the pixel type of a list of images +devices - system - Print information on the locally available devices +imcombine - images - Combine images pixel-by-pixel using various algorithms +imslice - images - Slice images into images of lower dimension +imstack - images - Stack images into a single image of higher dimension +nsppkern - plot - Plot metacode on a NSPP (NCAR) plotter device +pvector - plot - Plot an arbitrary vector in a 2D image +references - system - Find all help database references for a given topic +.TE +.PP +In addition, there are new image display oriented tasks \f(CWimexamine\fP, +\f(CWimedit\fP, and \f(CWtvmark\fP in the PROTO package in NOAO (used to +interactively examine and edit images, or draw graphics into image display +frames). These really belong in the core system but have been placed in +\f(CWnoao.proto\fP since they are prototype tasks. + +.NH +NOAO Package Revisions +.PP +Some of the major revisions to the NOAO packages are listed below. +.NH 2 +Summary of NOAO Packages Revisions +.NH 3 +New NOAO Packages +.PP +Several new packages have been added to the NOAO suite of packages. +.IP \(bu +The APPHOT package is a set of tasks for performing aperture photometry +on uncrowded or moderately crowded stellar fields in either interactive +or batch mode. +This package is now installed in the DIGIPHOT package (IRAF +version 2.7 and later). The APPHOT package was available as an add-on +package to IRAF version 2.5 and later while it was undergoing alpha +testing. Many new features have been added to the package +since it first became available including +the new task QPHOT (quick aperture photometry) and interaction with +the image display cursor for supported image displays +(Sun workstation, IIS model 70). +.IP \(bu +The CCDRED package provides tools for the easy and efficient reduction +of CCD images. +This package has been installed in the IMRED package (IRAF version +2.6 and later). The CCDRED package was also available as an add-on to +IRAF version 2.5. +.RS +.LP +A short demonstration of many of the tasks in the CCDRED package is +provided with the DEMO task in the CCDRED.CCDTEST package. +.RE +.IP \(bu +The IMRED.ECHELLE package has been replaced with a more +sophisticated collection of tasks for reducing echelle type data (IRAF +version 2.7 and later). The new ECHELLE package recognizes a new +image format in which each extracted echelle order +becomes a line in a two dimensional image rather than having a separate one +dimensional spectrum for each order, although this old output format is still +available as an option. +Several +new tasks exist for computing and applying a wavelength calibration +to the data using the echelle relationship between the orders +(ECIDENTIFY, ECREIDENTIFY, and ECDISPCOR) as well +as for manipulating the new echelle format (ECSELECT, +ECCONTINUUM, and ECBPLOT). +.IP \(bu +The IRRED package has been added to the IMRED package. The IRRED +package collects together in one place those tasks used most frequently +by users reducing IR data such as that taken with the IR imager at KPNO. +The IRMOSAIC and IRALIGN tasks were available +with IRAF version 2.6 and later. +IRMOSAIC takes an ordered list of input images and places them on a grid +in an output image. IRALIGN uses this grid and a coordinate list of +overlapping objects from the individual subrasters to produce an +aligned output image. The tasks IRMATCH1D and IRMATCH2D were available +with IRAF version 2.7 and later. These tasks are similar to IRALIGN +expect that the intensities of adjacent subrasters can be matched as well. +A script called MOSPROC (IRAF version 2.8) has also been +added that prepares a list of images for a quick look mosaic. +.IP \(bu +The MSRED package has been added to the IMRED package. The MSRED +package is a collection of tasks used for reducing multispectral types +of data, e.g. fiber arrays, where the individual spectra are for different +objects. Like the ECHELLE package, it also has its +own multispectral image format (a two dimensional image in which each line +is an extracted spectrum). Several new tasks have been added to the +package for wavelength calibration of multispectral data. +.NH 3 +Modifications to Existing NOAO Packages +.sp +.IP \(bu +The ASTUTIL package was reorganized (IRAF version 2.6 and later - see +IRAF Newsletter No. 3 for details) and several tasks were added and/or +modified. A new task ASTTIMES computes and prints astronomical dates +and times given a local date and time. A new task RVCORRECT computes +and prints radial velocity corrections for an observation. The +tasks PRECESS and GALACTIC were modified slightly using different but +more accurate algorithms. +.RS +.LP +The new task SETAIRMASS (IRAF version 2.8) +computes the effective airmass and middle UT of an exposure. +This task was also made available in the TWODSPEC and IMRED +packages. +.RE +.IP \(bu +The two tasks in the IMRED.BIAS package, COLBIAS and LINEBIAS, +were modified slightly (IRAF version 2.7 and later) so that +the fitting parameters for the overscan region can be set by the user +as hidden parameters to the tasks. +.IP \(bu +The task COSMICRAYS (from the CCDRED package) was made available in the +IMRED.GENERIC package (IRAF version 2.6 and later). +.IP \(bu +A new task called SYNDICO has been added to the IMRED.VTEL +package (IRAF version 2.6 and later). SYNDICO makes glossy prints on the +NOAO Dicomed printer of the synoptic, full disk, magnetograms and +spectroheliograms taken at the vacuum telescope at Kitt Peak. +.IP \(bu +Modifications were made to the IMRED.DTOI package. These changes +have been documented in IRAF Newsletter No. 4. +.IP \(bu +Three new tasks in the ONEDSPEC package, REFSPECTRA, SEXTRACT, +and SPECPLOT, were +made available in the IMRED.COUDE, IMRED.IIDS, IMRED.IRS, and IMRED.SPECPHOT +packages. +.IP \(bu +Many new tasks and features have been added to the ONEDSPEC package. +.RS +.LP +The SENSFUNC task was completely rewritten (IRAF version 2.6 and later) +to allow determination of extinction, display of flux calibrated spectra, +and many new features for displaying and manipulating the data. +.LP +IDENTIFY, REIDENTIFY and DISPCOR were modified (IRAF version 2.6 and later) +so that a dispersion solution from IDENTIFY could be shifted without +changing the original shape of the coordinate function (see IRAF +Newsletter No. 3 for details). +.LP +A new deblending algorithm was added to SPLOT (IRAF version 2.7 and later). +See the online help for SPLOT as well as the article in IRAF Newsletter +No. 4. +.LP +The tasks in the ONEDSPEC.ONEDUTIL package were absorbed into +the ONEDSPEC package (IRAF version 2.7 and later). +.LP +The EXTINCT task disappeared with its +functionality being taken over by a rewritten CALIBRATE (IRAF version 2.7 +and later). +.LP +The COEFS +task was moved to the IMRED.IIDS and IMRED.IRS packages since this is +a very instrument specific task (IRAF version 2.7 and later). +.LP +Three new tasks were added to the package. SEXTRACT (IRAF version 2.6 +and later) extracts subspectra from one dimensional input spectra. +REFSPECTRA (IRAF version 2.7 and later) takes over part of the functionality +of the old DISPCOR task and allows the user to define which arc spectra +are to be used in the calculation of the dispersion solution of object +spectra. SPECPLOT (IRAF version 2.8) is a new plotting task that allows +the compression of many spectra to a page (see IRAF Newsletter No. 6). +.RE +.IP \(bu +Several new tasks have been added to the PROTO package. +.RS +.LP +Four tasks were added to IRAF version 2.6 and later. BSCALE is a task that +can be used to linearly scale images by the mean, average, or mode of the +image. IRMOSAIC and IRALIGN can be used to combine many frames into one +large image. These three tasks are also available in the IMRED.IRRED package. +MKHISTOGRAM calculates the histogram of the data in a text file. +.LP +Three new tasks were added to IRAF version 2.7 and later. IMSLICE is a +task that slices an image into images of lower dimension. IRMATCH1D +and IRMATCH2D are two tasks that allow combining of many overlapping images +while matching the background intensities in two different ways. +.LP +Three new tasks have been added to IRAF version 2.8 that allow the user +to interact with the image display (for supported display devices, ie +Sun workstation, IIS model 70). IMEXAMINE allows the user to interactively +examine portions of the displayed image. TVMARK allows the user to +mark objects on the image display. IMEDIT allows the user to interactively +edit an image. +.RE +.IP \(bu +The APEXTRACT package in the TWODSPEC package has ungone several rounds +of modifications, as discussed in the IRAF Newsletters, No. 3 and 4. +These changes included improved techniques and additional options +for the extraction of data. +.RS +.LP +A new task, APSCATTER, has been added to the package (IRAF version 2.8). +This task determines and subtracts scattered light from two dimensional +aperture or echelle spectra. The task was also made available +from within the ECHELLE package. This task was discussed in +IRAF Newsletter No. 6. +.RE +.NH 2 +Modifications and Additions to Calibration Data +.PP +The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory +called ONEDSTDS in \f(CWnoao$lib\fP. The current contents of this directory +are best summarized by paging through its README file, e.g., +.DS +\f(CWcl> page noao$lib/onedstds/README\fP +.DE +.PP +Two additional line lists (used by IDENTIFY) have been added to this directory +(IRAF version 2.8). +These lists, \f(CWvacidhenear.dat\fP and \f(CWvacthorium.dat\fP, +are simply the standard \f(CW.dat\fP files in air wavelengths +converted to vacuum wavelengths. The equation used for the +conversion as well as the appropriate reference in the literature +are contained in the README file. +.PP +The \f(CWthorium.dat\fP file has been updated to contain thorium +lines from 3180 Angstroms +to 9540 Angstroms (IRAF version 2.6 and later). Please see the README +file for the source. +.PP +Two new directories have been added containing flux information for +standard stars (IRAF version 2.6 and later): SPECHAYESCAL and SPEC50CAL. +Both of these lists are from Massey et al., 1988, Ap. J., Vol. 328, p. 315. +.NH 2 +Glossary of New Tasks in the NOAO Packages +\fR +.TS +center; +c c c c c c +l c l c lw(3.5i) n. +Task Package Description Note +_ + +apscatter - apextract - Fit and subtract scattered light 1 +apselect - apphot - Extract select fields from apphot output files +asttimes - astutil - Compute UT, Julian day, epoch, and sidereal time + +badpiximage - ccdred - Create a bad pixel mask image from a bad pixel file +bscale - proto - Brightness scale images: new = (old-bzero) / bscale 3 + +ccdgeometry - ccdred - Discussion of CCD coordinate/geometry keywords +ccdgroups - ccdred - Group CCD images into image lists +ccdhedit - ccdred - CCD image header editor +ccdlist - ccdred - List CCD processing information +ccdproc - ccdred - Process CCD images +ccdred - ccdred - CCD image reduction package +ccdtypes - ccdred - Description of the CCD image types +center - apphot - Compute accurate centers for a list of objects 3 +centerpars - apphot - Edit the centering parameters 3 +combine - ccdred - Combine CCD images +cosmicrays - ccdred - Detect and replace cosmic rays 4 + +daofind - apphot - Find stars in an image using the DAO algorithm +darkcombine - ccdred - Combine and process dark count images +datapars - apphot - Edit the data dependent parameters 3 +demo - ccdtest - Run a demonstration of the CCD reduction package + +ecbplot - echelle - Batch plots of echelle spectra +eccontinuum - echelle - Fit the continuum of echelle spectra +ecdispcor - echelle - Dispersion correct spectra +ecidentify - echelle - Identify features in spectrum for dispersion solution +ecreidentify - echelle - Automatically reidentify features in spectra +ecselect - echelle - Select and extract apertures from echelle spectra + +fitpsf - apphot - Model the stellar psf with an analytic function +fitsky - apphot - Compute sky values in a list of annular or circular regions +fitskypars - apphot - Edit the sky fitting parameters +flatcombine - ccdred - Combine and process flat field images +flatfields - ccdred - Discussion of CCD flat field calibrations + +guide - ccdred - Introductory guide to using the CCDRED package + +imedit - proto - Examine and edit pixels in images +imexamine - proto - Examine images using image display, graphics, and text +imslice - proto - Slice images into images of lower dimension +instruments - ccdred - Instrument specific data files +iralign - proto - Align the mosaiced image produced by irmosaic 3 +irmatch1d - proto - Align and intensity match image produced by irmosaic (1D) 3 +irmatch2d - proto - Align and intensity match image produced by irmosaic (2D) 3 +irmosaic - proto - Mosaic an ordered list of images onto a grid 3 + +mkfringecor - ccdred - Make fringe correction images from sky images +mkhistogram - proto - List or plot the histogram of a data stream +mkillumcor - ccdred - Make flat field illumination correction images +mkillumflat - ccdred - Make illumination corrected flat fields +mkimage - ccdtest - Make or modify an image with simple values +mkskycor - ccdred - Make sky illumination correction images +mkskyflat - ccdred - Make sky corrected flat field images +mosproc - irred - Prepare images for quick look mosaicing +msdispcor - msred - Dispersion correct spectra +msreidentify - msred - Reidentify features from one multispec image to another +msselect - msred - Select and extract apertures from spectra + +observe - ccdtest - Create an artificial CCD observation + +phot - apphot - Measure magnitudes for a list of stars +photpars - apphot - Edit the photometry parameters +polymark - apphot - Create polygon lists for polyphot +polypars - apphot - Edit the polyphot parameters +polyphot - apphot - Measure magnitudes inside a list of polygonal regions + +qphot - apphot - Measure quick magnitudes for a list of stars + +radprof - apphot - Compute the stellar radial profile of a list of stars +refspectra - onedspec - Assign wavelength reference spectra to other spectra 5 +rvcorrect - astutil - Compute radial velocity corrections + +setairmass - astutil - Compute effective airmass and middle UT for an exposure 6 +setinstrument - ccdred - Set instrument parameters +sextract - onedspec - Extract subspectra from dispersion corrected spectra 2 +specplot - onedspec - Stack and plot multiple spectra 5 +subsection - ccdtest - Create an artificial subsection CCD observation +subsets - ccdred - Description of CCD subsets +syndico - vtel - Make dicomed print of daily grams 18 cm across + +tvmark - proto - Mark objects on the image display + +wphot - apphot - Measure magnitudes for a list of stars with weighting + +zerocombine - ccdred - Combine and process zero level images +.TE +.sp +.LP +Notes: +.IP (1) +Tasks also in echelle and msred packages. +.IP (2) +Tasks also in coude, iids, irs, and specphot packages. +.IP (3) +Tasks also in irred package. +.IP (4) +Tasks also in generic package. +.IP (5) +Tasks also in coude, echelle, iids, irs, msred, and specphot packages. +.IP (6) +Tasks also in imred and twodspec packages. diff --git a/doc/dsuxiraf.ms b/doc/dsuxiraf.ms new file mode 100644 index 00000000..3ab235a9 --- /dev/null +++ b/doc/dsuxiraf.ms @@ -0,0 +1,653 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +Decstation Ultrix/IRAF Installation Guide +.AU +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +June 1989 +.br +Revised September 1992 + +.AB +This document describes how to install or update IRAF on a Decstation +running DEC Ultrix. Both standalone and networked, multiple architecture +configurations are described. Only those issues which one must understand +to install Ultrix/IRAF are discussed here; a companion document, +\fIUNIX/IRAF Site Manager's Guide\fR, deals with other issues such as +interfacing new devices, configuring the IRAF networking system, adding +layered software, and so on. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling Ultrix/IRAF\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Install the files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Installing from a network distribution\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing from tape\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Configuring the BIN directories\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.3.\h'|0.9i'Merge local revisions back into the new system\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.4.\h'|0.9i'Run the INSTALL Script\l'|5.6i.'\0\07 +.sp +3.\h'|0.4i'\fBSystem Checkout\fP\l'|5.6i.'\0\08 +.sp +\fBAppendix A.\0A Complete Example\fP\l'|5.6i.'\0\09 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Before installing Ultrix/IRAF, one must 1) obtain an appropriate Ultrix/IRAF +distribution, e.g., from the IRAF network archive on \f(CWiraf.noao.edu\fR +(or by ordering a tape distribution from NOAO), 2) select the server or node +on which the system is to be installed and arrange for sufficient disk space +to hold the system, and 3) set aside sufficient time to do the +installation. If these directions are followed carefully and mistakes are +avoided the basic installation should only take a half hour or so. +Additional time may be required to customize the system, to configure the +local tape drives and other devices, set up IRAF networking, and so on. +.PP +This Installation Guide is intended primarily for sites installing IRAF on a +Decstation running Ultrix 4.2 or later. Other popular UNIX systems for +which IRAF is available, e.g. IRIX and SunOS, have their own system specific +IRAF installation guides. There is also a separate installation guide for +the DEC VAXstation running Ultrix. The IRAF distribution for the VAXstation +is known as VXUX. The Decstation Ultrix/IRAF distribution described here is +DSUX. + +.NH +Installing Ultrix/IRAF +.PP +Although the details of how Ultrix/IRAF is installed or updated depend upon +the type of distribution and the desired local system configuration, the +basic procedure is always the same. First one obtains the distribution +files, then one follows the procedure outlined below to install the system. +Most of these steps should be performed while logged in as IRAF; superuser +permission is required in the final stages of the installation, to run the +\fIinstall\fP script. +.PP +System managers familiar with the installation of typical UNIX programs +should beware that IRAF, being a large system in its own right and not a +UNIX program, does not always follow to the usual conventions. It is wise +to read and adhere to the installation instructions to avoid problems. +.XS +\fR# Prepare the root IRAF directory.\fP +if new installation + create iraf account +else if updating an old installation + save locally modified files; delete old system + +\fR# Install the files.\fP +login as iraf +unpack the core system distribution +configure the BIN directories + +\fR# Merge local revisions into new system.\fP +if updating an old installation + merge locally modified files back into new system + +run the iraf install script to complete the installation +checkout the new system +.XE +.PP +If problems should arise during the installation help is available via the +IRAF HOTLINE (602-323-4160), or by sending email to \f(CWiraf@noao.edu\fP. + +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation then you will be replacing +IRAF by the new version, and IRAF should already have an account and root +directory on the desired host system. You should save any locally modified +files and delete the old system, e.g., login as IRAF and enter something +like the following. +.XS +% cd $iraf\(dg +% tar -cf /scr0/oiraf.tar local dev unix/hlib +% /bin/rm -rf * +.XE +.FS +\(dg\0\(CW$iraf\fP symbolizes the UNIX pathname of the root IRAF directory. +If no "iraf" environment variable is defined just supply the actual pathname. +.FE +.PP +There are many possible variations on this, e.g., you could use \fImv\fR to +move the above directories to someplace outside the main IRAF directory +tree. Although it is probably simplest and safest to save entire +directories as in the example, in practice only a few files are likely to +have been modified. These are the following. +.XS +dev/graphcap +dev/hosts +dev/tapecap +dev/termcap +hlib/extern.pkg +hlib/login.cl +hlib/zzsetenv.def +local/.login +.XE +.PP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. It is important to delete the old system first to +avoid creating junk files or directories when the new system is installed +(due to file or directory name changes or deletions). Once the new system +has been restored to disk, do \fInot\fR merely restore the files saved above, +as you will need to carefully merge local changes into the versions of the +files supplied with the new IRAF release (more on this later). +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set +up a new account for the user `\f(CWiraf\fP'. This is necessary for IRAF +system management, which should always be done from the IRAF account. The +IRAF account has special login files which set up a custom UNIX environment +for IRAF system management. Having an IRAF account provides a convenient +place (the IRAF system manager's login directory) to keep scratch files +created during system configuration. +.PP +The location of the IRAF root directory is arbitrary. Our practice here is +to locate the software in a system file storage area separate from the +Ultrix system files (to simplify Ultrix upgrades), and then use a symbolic +link such as /iraf or /usr/iraf to point to the actual root directory. This +makes life simpler if IRAF is NFS mounted on several machines and it is +later necessary to move the IRAF files. Try to keep the path to the +physical IRAF root directory short to avoid filename truncation problems +when IRAF is run. +.PP +The login directory for the iraf account should be $iraf/local (e.g., +/iraf/iraf/local), rather than the IRAF root directory $iraf as one might +expect. This is done to provide a work area for local files separate from +the main IRAF directory tree, to simplify updates and make it easier to keep +track of what has been locally added and what is standard IRAF. In any +case, make sure that when the IRAF account is set up the login directory is +set correctly, or the IRAF environment will not be set up properly, and +later problems are sure to result. +.PP +A typical IRAF installation consists of the main IRAF release, a number of +BIN directories (the IRAF binaries), and additional directories for layered +software such as STSDAS, PROS, and so on. If sufficient disk space is +available to keep everything in one area the following directory structure +is recommended. +.XS +/iraf/iraf \fR# iraf root directory ($iraf)\fP +/iraf/iraf/local \fR# iraf login directory (~iraf)\fP +/iraf/irafbin \fR# iraf BIN directories\fP +/iraf/irafbin/bin.ddec \fR# DEC Fortran binaries - iraf core system\fP +/iraf/irafbin/noao.bin.ddec \fR# DEC Fortran binaries - iraf NOAO package\fP +/iraf/irafbin/bin.dmip \fR# MIPS Fortran binaries - iraf core system\fP +/iraf/irafbin/noao.bin.dmip \fR# MIPS Fortran binaries - iraf NOAO package\fP +/iraf/stsdas \fR# layered package\fP +/iraf/xray \fR# layered package\fP + \fI(etc.)\fP +.XE +.PP +For the purpose of this example we assume that the IRAF files are stored in +/iraf; as we say this might be a link and the actual directory is +arbitrary. Given this directory the IRAF root $iraf would be "/iraf/iraf/" +and the login directory for the IRAF account would be /iraf/iraf/local. The +ddec (DEC Fortran) binaries for the core IRAF system would be in +/iraf/irafbin/bin.ddec, with a link $iraf/bin.ddec pointing to this directory +(more on this later). +.PP +Given the above directory structure the \f(CWpasswd\fR file entry for the +IRAF account would be something like the following. +.XS +iraf:abcdef:312:12:IRAF system login:/iraf/iraf/local:/bin/csh +.XE +.PP +Do not worry about configuring the environment files for the new account as +these will be created when the iraf system is later restored to disk. + +.NH 2 +Install the files +.PP +If you are installing from tape skip forward to \(sc2.2.2. If you are +installing from a network distribution (i.e., from disk) continue with the +next section. +.NH 3 +Installing from a network distribution +.PP +Ultrix/IRAF is available over the network via anonymous ftp from the node +\f(CWiraf.noao.edu\fR, in the subdirectory \f(CWiraf/v\fInnn\fP/DSUX\fR, +where "\f(CWv\fInnn\fR" is the IRAF version number, e.g., subdirectory +\f(CWiraf/v210/DSUX\fR for V2.10 Ultrix/IRAF. +.PP +If IRAF is being installed from a network distribution all the architecture +independent IRAF files for both the core IRAF system and the NOAO packages +will be in the distribution file \f(CWas.dsux.gen\fR. This "file" is stored +in the network archive as a directory wherein the large distribution file +has been split into a number of smaller pieces, e.g., +.XS +% ls as.dsux.gen +CHECKSUMS as.dsux.gen.Z.12 as.dsux.gen.Z.26 +FILES.Z as.dsux.gen.Z.13 as.dsux.gen.Z.27 +as.dsux.gen.Z.00 as.dsux.gen.Z.14 as.dsux.gen.Z.28 +as.dsux.gen.Z.01 as.dsux.gen.Z.15 as.dsux.gen.Z.29 +as.dsux.gen.Z.02 as.dsux.gen.Z.16 as.dsux.gen.Z.30 +as.dsux.gen.Z.03 as.dsux.gen.Z.17 as.dsux.gen.Z.31 + \fI(etc.)\fP +.XE +.LP +Assume that the directory \f(CWas.dsux.gen\fR as shown above has been +recreated somewhere on the machine on which IRAF is to be installed. +We can restore the main IRAF source tree as follows. +.XS +% whoami +iraf +% cd $iraf +% cat /\fIpath\fP/as.dsux.gen/as.* | uncompress | tar -xpf - +.XE +After the above finishes the root IRAF directory should appears as follows +(this is for V2.10). +.XS +HS.DSUX.GEN bin.ddec dev local noao tags +IS.PORT.GEN bin.dmip doc math pkg unix +bin bin.generic lib mkpkg sys +.XE +The files \f(CWbin.ddec\fR and \f(CWbin.dmip\fR are links to the IRAF BIN +directories (for binary executables), which probably do not exist yet. +Configuring the BIN directories is discussed in section \(sc2.2.3. +.NH 3 +Installing from tape +.PP +If you have not already done so, log into the IRAF account so that the files +when restored will belong to IRAF. Mount the distribution tape, which may +be a cartridge tape, a 6250 bpi 9 track tape, a DAT tape, an Exabyte, or +whatever. +.PP +IRAF distribution tapes consist of multiple files separated by tape marks, +with a TOC (table of contents) file as the first file on the tape. To find +out what is on the tape, rewind it and read out the TOC file as follows (the +actual device name will likely be different than that shown in the examples). +.XS +% mt -f /dev/nrmt0h rew; cat /dev/nrmt0h +.XE +This should cause a TOC file to be listed similar to the following, except +for the file names which will vary depending upon what type of distribution +you have (the actual file sizes may differ from what is shown). The example +below is for a distribution of Ultrix/IRAF for the Decstation, including all +available binaries. +.XS +0 Table of Contents + +1 AS.DSUX.GEN 50.0Mb IRAF, NOAO packages and Ultrix/OS sources +2 IB.DSUX.DEC 38.0Mb DEC Fortran binaries for IRAF system +3 NB.DSUX.DEC 32.8Mb DEC Fortran binaries for NOAO packages +4 IB.DSUX.MIP 34.3Mb MIPS Fortran binaries for IRAF system +5 NB.DSUX.MIP 32.3Mb MIPS Fortran binaries for NOAO packages +.XE +.PP +Here, the first column is the file number on the tape, the TOC file being +file zero (the first distribution file is number one), the second column is +the name of the tape file, the third column is the file size in megabytes +(this tells you how much space will be needed to unpack the file on disk), +and the last column is a description of the file contents. +.PP +There are three types of tape files in the example shown: the \f(CWAS\fR +file, which is all the IRAF sources (the core IRAF system, NOAO packages, +and the Ultrix host system interface), the \f(CWIB\fR files, or IRAF core +system binaries, one for each architecture, and the \f(CWNB\fR files, or +NOAO package binaries. The NOAO package sources are included in the +\f(CWAS\fR file since most people requesting IRAF are expected to want the +astronomical reduction software, although IRAF can be configured without +this if desired. All of the file objects are UNIX \fItar\fR format files, +with the exception of the TOC file which is a simple text file. The +distribution files may be compressed if this was necessary to fit all the +files on a tape. +.PP +In the above example, the \f(CWDSUX\fR in the file names indicates that +these files are for a Decstation running DEC Ultrix. A SunOS version 4 +distribution is indicated by a \f(CWSOS4\fR in the file names, an IBM AIX +distribution by a \f(CWAIX3\fP, and so on. In principle a given +distribution tape may contain any combination of these files. +.PP +The V2.10 Ultrix/IRAF distribution for the Decstation supports two +architectures, \fBddec\fR and \fBdmip\fR. The ddec binaries were generated +with the DEC Fortran compiler and the dmip binaries were generated with the +MIPS Fortran compiler. Either set of binaries can be used to \fIrun\fR IRAF +on the Decstation, regardless of which Fortran compiler is installed on a +system, in fact regardless of whether a Fortran compiler is installed at +all. The correct set of binaries must be installed however, in order to +compile and link IRAF programs, e.g. layered packages or IMFORT programs. +If you wish to compile programs with the DEC compiler you should install +the ddec binaries; if you wish to compile with the MIPS compiler you should +install the dmip binaries. Both sets of binaries can be simultaneously +installed if desired. Refer to the README file in the DSUX distribution for +additional information on the V2.10 Ultrix/IRAF architectures. +.PP +The following commands would suffice to restore the main IRAF system to +disk, given the distribution tape described by the TOC file in our example +above. Once again, the tape device file and possibly the block size will +likely have to be changed to whatever is needed for the actual tape device +used. +.XS +% whoami +iraf +% cd $iraf +% mt -f /dev/nrmt0h rew; mt -f /dev/nrmt0h fsf 1 +% tar -xpf /dev/nrmt0h +.XE +.PP +After the above tar file read operation, the tape is left positioned to +\fIjust before the EOF of the file just read\fR, since \fItar\fP stops +reading the file data before reading the physical EOF. Hence, an +\fImt\0fsf\fR will be required to position to the next file on the tape. +Any combination of \fIfsf\fP (forward skip file) or \fIbsf\fR (backward skip +file) operations may be used to position to a file on a 9 track tape. On +some tape drives, it is safest to plan things so that only forward file +skips are used, using a rewind and forward skip if it is necessary to +position to an earlier file on the tape. +.PP +Once the main system, containing only sources, is installed it is possible to +create one or more empty BIN directories for the executables, then compile +and link the full system. More commonly one will merely read the precompiled +executables off the distribution tape, as we discuss in the next section. +.NH 3 +Configuring the BIN directories +.PP +In IRAF all the files specific to any particular hardware or software +architecture, e.g., for the DEC Fortran or MIPS Fortran compiler in the +case of the Decstation, are contained in a single directory called the BIN, +or "binary", directory. To run IRAF you must install not only the +\f(CWAS\fR (all-sources) directory tree, but the BIN directory for each +architecture. The IRAF core system and the NOAO packages have separate BIN +directories. +.PP +The BIN directories for the IRAF core system or a layered package (such as +NOAO) are located, logically or physically, in the root directory of the +IRAF core system or layered package. Every layered package has its own set +of BIN directories. In the distributed V2.10 system you will find the +following BIN files (directories or symbolic links) at the IRAF root. +.XS +link bin -> bin.generic +directory bin.generic +link bin.ddec -> ../irafbin/bin.ddec +link noao/bin.ddec -> ../../irafbin/noao.bin.ddec +link bin.dmip -> ../irafbin/bin.dmip +link noao/bin.dmip -> ../../irafbin/noao.bin.dmip +.XE +.PP +If the IRAF directory structure is set up as described in \(sc2.1.2, with +$iraf located at iraf/iraf and the BIN directories stored in iraf/irafbin, +then these links will not have to be modified. If a different directory +structure is used you will have to modify the links accordingly. +.PP +The \fIbin\fR link and the \fIbin.generic\fR directory are required for the +correct operation of the IRAF system software (\fImkpkg\fR) and are +maintained automatically by the IRAF software management utilities. +\fIUnder no circumstances should "bin" or "bin.generic" be modified or +deleted\fR. It is a very common error to manually delete the bin link and +manually set it to bin.ddec or some other architecture. The bin.ddec link +can be modified as desired but bin and bin.generic should be left alone. +.PP +Assume that the bin.ddec directory has been created somewhere (e.g. in the +iraf/irafbin directory) and that the \f(CWib.dsux.dec\fR distribution files +for the core IRAF system VAX binaries have been downloaded from the +network archive. We can restore the ddec binaries with the following +commands. +.XS +% cd $iraf/bin.ddec +% cat /\fIpath\fP/ib.dsux.dec/ib.* | uncompress | tar -xpf - +.XE +Similarly, to restore the NOAO package ddec binaries: +.XS +% cd $iraf/noao/bin.ddec +% cat /\fIpath\fP/nb.dsux.dec/nb.* | uncompress | tar -xpf - +.XE +This process is repeated for each architecture. For example, a central +Ultrix/IRAF distribution installed on a server machine might well require +both the ddec and dmip architectures, or four BIN directories in all. +.PP +The procedure for restoring a BIN directory from a tape distribution is +similar to that described in \(sc2.2.2 for the core system. For example, +.XS +% cd $iraf/bin.ddec +% mt -f /dev/nrmt0h rew; mt -f /dev/nrmt0h fsf 2 +% tar -xpf /dev/nrmt0h +.XE +would restore the core system bin.ddec directory from a TK50 tape +containing an uncompressed \f(CWib.dsux.dec\fR as file 2 on the tape. + +.NH 2 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure to not replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF.\(dg +.FS +\(dgThe UNIX utility \fIdiff\fP is useful for comparing files to see +what has changed. +.FE +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each +site to maintain their own custom LOCAL package external to the core IRAF +system. The core system LOCAL is now only a \fItemplate-local\fR to be +copied and used as the starting point for a custom LOCAL layered package. +The layered software enhancements, and the procedure for building a custom +LOCAL, are discussed further in the \fIUNIX/IRAF Site Manager's Guide\fR. + +.NH 2 +Run the INSTALL Script +.PP +Once all of the IRAF files have been restored to disk the Ultrix/IRAF +installation script must be run to complete the system installation. The +install script modifies the system as necessary to reflect the new root +directory and new default image storage and local bin directories, checks +the mode and ownership of a number of files, installs a small set of IRAF +commands in UNIX, and so on. +.LP +To make a trial run of the install script, enter the following commands: +.XS +% setenv iraf /\fIpath\fP/iraf/ +% cd $iraf/unix/hlib +% source irafuser.csh +% ./install -n +.XE +and answer the questions (don't forget the trailing `/' in the "setenv +iraf"). The "-n" argument tells install to go through the motions without +actually doing anything, so that one can see what will be done before +committing to it. +.PP +Installing IRAF requires a few changes to be made to system directories +outside the IRAF directory tree. Two fifo device entries are made in /dev. +A symbolic link "iraf.h" is created in /usr/include. A number of links (cl, +mkiraf, etc.) are made in /usr/local/bin or some similar directory which +most users can be expected to have in their search path. The tape +allocation task alloc.e is made suid root (there are no known security +loopholes, although we cannot make any guarantees). A symbolic link +imtoolrc is created in /usr/local/lib. +.PP +Following one or more trial "no execute" ("-n") runs to see what the install +script will do, the install script should be run without the "-n" to +complete the installation. This must be done by the superuser as superuser +permission is required to carry out the necessary additions to UNIX. +.PP +It is necessary to run the install script separately on each node from which +IRAF will be used. If a single version of IRAF is installed on a server and +NFS mounted on one or more clients, the install script must be run first on +the server and then on \fIeach\fR client (when installing on a client there +will be warnings about insufficient permission to make changes to files on +the NFS mounted partitions, which can be ignored). To install IRAF on a +diskless client it may be necessary to run the install script \fIon the +server\fR to do the install for the client, since the client's /usr/include +and /dev directories may only be writable by root on the server. On some +systems /usr is mounted read-only, and must be unmounted and remounted +read-write before doing the installation to allow an entry to be made in +/usr/include. Once the installation is complete the default mount access +mode may be restored. +.LP +The exchange with the install script will be along the lines of the +following. +.XS +% ./install -n +new iraf root directory (/iraf/iraf): +default root image storage directory (/d0/iraf): +local unix commands directory (/usr/local/bin): +install iraf for machine type dsux +old iraf root = /usr/iraf, old imdir = /d0/iraf +installing iraf at /iraf/iraf, imdir=/d0/iraf, lbindir=/usr/local/bin +proceed with installation? (yes): +.XE +.LP +The "iraf root directory" is the value of $iraf (minus the trailing `/'in +this case). The "root image storage directory" is the default place to put +image data for users; the program may prompt with /tmp if it cannot find any +likely looking data storage areas on your system, but /tmp is not a good +place to put image data as the contents are deleted whenever the system +reboots. The value entered should be the path to a public iraf subdirectory +of a designated data or scratch disk on your system. Lastly, the "local +unix command directory" is where the UNIX callable IRAF startup commands +will be defined. This should be a UNIX directory which is in the default +path of anyone who might want to use IRAF; /usr/local/bin is the most common +value. +.PP +After answering with "yes" or hitting return in response to the "proceed with +installation" query, the script will issue a series of messages as it checks +the system and performs the installation, possibly answering additional +questions in the process. + +.NH +System Checkout +.PP +The basic IRAF system should be usable once the files have been restored to +disk, the binaries have been configured or generated, and the install script +has been run. To verify that the basic system comes up and runs +successfully, login as iraf and startup the CL (IRAF command language) from +the iraf account. You should be able to login as IRAF and type "cl" to +start IRAF, using the login files which come with the distributed system. +.XS +% login iraf +% cl +.XE +.LP +To more thoroughly test the installation it is a good idea to test IRAF from +a user account. To do this you login to a user account and run the +\fImkiraf\fR task to set up the IRAF login files. This will create or +initialize the user's \f(CWuparm\fP (user parameter) directory, and create a +new \f(CWlogin.cl\fP file. It may also be desirable to edit the +user's \f(CW.login\fP file to modify the way the environment variable +\f(CWIRAFARCH\fP is defined. This variable, required for software +development but optional for merely using IRAF, must be set to the name of +the desired machine architecture, in this case \fIvax\fR. +.XS +% mkiraf +Initialize uparm? (y|n): y +Terminal types: xterm,gterm,vt640,vt100,etc." +Enter terminal type: xterm +A new LOGIN.CL file has been created in the current directory. +You may wish to review and edit this file to change the defaults. +.XE +The \fIcl\fR command should now start up the CL, which will clear the screen +and print out a startup message. The standard test procedure included in +Volume 1A of the \fIIRAF User Handbook\fP should be run to verify the +installation. + +.bp +.SH +Appendix A. A Complete Example +.PP +Assume we are installing IRAF for the first time on a Decstation. The +IRAF directories will be located at /u3/iraf using a symbolic link /iraf to +point to this location. We will configure only ddec binaries, locating +the BIN directories in the directory /iraf/irafbin. The local user commands +will be placed in /usr/local/bin. We will be installing from a network +distribution with the distribution files located in /scr0. +.PP +The first step is for the superuser to create an account for the fictitious +user `\f(CWiraf\fP', with home directory /iraf/iraf/local and shell +/bin/csh. The /u3/iraf directory is created owned by IRAF, and pointed to +by the link /iraf. We then login as IRAF (a warning message will be printed +since there is no login directory) and proceed as follows. +.XS +% whoami +iraf +% +% setenv iraf /iraf/iraf/ \fR# set root directory\fP +% mkdir /iraf/iraf +% +% cd $iraf \fR# unpack main IRAF distribution\fP +% cat /scr0/as.dsux.gen/as.* | uncompress | tar -xpf - +% +% cd /iraf \fR# create BIN directories\fP +% mkdir irafbin +% mkdir irafbin/bin.ddec +% mkdir irafbin/noao.bin.ddec +% +% cd $iraf/bin.ddec \fR# unpack core bin.ddec\fP +% cat /scr0/ib.dsux.dec/ib.* | uncompress | tar -xpf - +% +% cd $iraf/noao/bin.ddec \fR# unpack NOAO bin.ddec\fP +% cat /scr0/nb.dsux.dec/nb.* | uncompress | tar -xpf - +% +% cd $iraf/unix/hlib \fR# run the INSTALL script\fP +% source irafuser.csh +% ./install -n +% su +# ./install +# exit +% +% cd +% source .login \fR# read new .login\fP +% rehash \fR# pick up new iraf commands\fP +% cl \fR# verify that the CL runs\fP +.XE +.LP +This will fully install IRAF on a server or a standalone system. If this +version of IRAF will be accessed via NFS by client nodes then the IRAF +install script must be run on each client node as well. Installing IRAF +does not allow one to access local tape drives, printers, and so on. +Refer to the \fIUNIX/IRAF Site Manager's Guide\fR for information on how +to configure IRAF for the local site. diff --git a/doc/em4010.ms b/doc/em4010.ms new file mode 100644 index 00000000..33d66ba8 --- /dev/null +++ b/doc/em4010.ms @@ -0,0 +1,279 @@ +.TL +IRAF Graphics with the Diversified Computer Systems EM4010 Terminal Emulator +.AU +Steve Rooke +April 1987 + +.NH +Introduction +.PP +The popular vtxxx and Tektronix 4010 terminal emulator, \fBem4010\fP, +a product of Diversified Computer Systems, Inc., may be used as a graphics +terminal within IRAF. In its current form, the emulator has certain features +that make its use within IRAF a bit awkward, though it is fully functional. +The user must first make sure the emulator's Setup Mode features are set +properly, then must inform the IRAF graphics system that it is talking to +an \fBem4010\fP terminal. + +.PP +Since it is intended for a class of desktop personal computer that does +not have separate hardware graphics and text memories, the \fBem4010\fP +\fIemulates\fP individual graphics and text planes. +In general you will want to enter IRAF from the emulator's \fBvt220\fP +(7-bit) mode, although the \fBvt102\fP and \fBvt100\fP modes probably work +equally well. +IRAF needs to know what kind of terminal you are using, requiring that +\fBem4010\fP entries exist in both the \fLdev$termcap\fP and \fLdev$graphcap\fP +files, and that you notify the system about the terminal with the \fLstty\fP +task. +Once inside IRAF, the system will take care of switching the emulator between +text and graphics modes. + +.NH +The Termcap and Graphcap Entries +.PP +IRAF stores information about text terminals in the file \fItermcap\fP in +the \fIdev\fP directory, and information about graphics terminals +in the file \fIgraphcap\fP. +You can determine whether your system currently supports the \fBem4010\fP +by searching those files for `em4010': +.nf +.sp 1 +.in 5 +\fLcl> match em4010 dev$termcap +cl> match em4010 dev$graphcap\fP +.in 0 +.sp 1 +.fi +If there is no match, the IRAF system manager will need to install the +entries, which may be obtained from the IRAF group at NOAO or edited in +from the Appendix. +The \fItermcap\fP and \fIgraphcap\fP entries should be placed with the +other terminal entries and the device cache rebuilt, for the best performance. +See \fLcl> help mktty\fP and the comments at the beginning of each file +for information on caching device entries. +If it is not possible to rebuild the cache (e.g. if the system's source +files have been stripped) performance will be better if the entries are +inserted near the beginning of the file. +Note the comments in \fLhelp mktty\fP about modifying entries that +have already been cached. + +.NH +EM4010 Setup Mode Settings +.PP +In order to use the \fBem4010\fP for graphics within IRAF, +you must first establish the correct Tektronix mode settings. +To enter \fISetup Mode\fP from vt220 mode (vt100, vt102, etc.), +first press \fBALT F1\fP, then select the Tektronix mode page +with \fBSHIFT F3\fP. If you are already in the emulator's graphics +mode, simply press \fBALT F1\fP. +Remember to save the new settings; look for the function key +menu entry for \fIsave\fP at the bottom of the screen. +Also note that \fBALT H\fP may be used from either vtxxx or 4010 +mode to obtain on-line help about using the emulator. + +.NH 2 +Graphics Board Settings +.PP +Make sure you have the graphics board setting corresponding to +the actual hardware in your terminal. For the most efficient and +accurate graphics, you will need to know this setting when you set +your terminal type (see `Identifying the Terminal to IRAF' below). + +.NH 2 +Options +.PP +The option settings should be as follows: +.sp 1 +.TS +center, box; +c s +c|c +l|a. +Tektronix Setup Settings for IRAF +_ +Option Value +_ +GIN Mode Input Terminator ^M (CR) +Transparent Mode Entry ^X +Exit String ^E +Clear VT Screen on Exit No +Auto Switch Enable +Text Mode Replace +.TE +The `^' above means enter the named letter as a control character. +Note that, although you enter the \fIGraphics Input (GIN)\fP terminator +as `control-M', the carriage return, it is echoed as a back arrow (\fB\(<-\fP). +You may wish to experiment with the Text Mode setting. In \fIOverstrike\fP +mode some plots may look better or more familiar, but it may become hard to +read the status line. +.NH +Identifying the Terminal to IRAF +.PP +Once you have the emulator set up properly, you need to inform IRAF that it +is talking to the \fBem4010\fP. The best way to do this is with the command: +.sp 1 +.nf +.in 5 +\fLcl> stty em4010\fP +.in 0 +.fi +.sp 1 +If the \fBem4010\fP is your normal, default terminal, place the +`\fLstty em4010\fP' +command into your login.cl or loginuser.cl file. +.PP +The standard termcap and graphcap entries for device \fBem4010\fP will +suffice in most cases. However, if you have a graphics board other than +the Hercules, in particular the IBM high or medium resolution boards, or +the AT&T 6300 monochrome graphics board, you should set the device as +follows, to be sure you always get the right size text characters +while in graphics mode: +.sp 1 +.TS +center, box; +c s +c|c +l|a. +EM4010 Device Names for IRAF +_ +Graphics Board IRAF Device Name +_ +Hercules monochrome graphics board em4010he +IBM high resolution board em4010ih +IBM medium resolution board em4010im +IBM enhanced graphics board em4010ieh +Tecmar Master graphics board, non-interlaced em4010tn +Tecmar Master graphics board, interlaced em4010ti +AT&T 6300 monochrome graphics board em4010att +.TE +For example, for the AT&T board, use: +.sp 1 +.nf +.in 5 +\fLcl> stty em4010att\fP +.in 0 +.fi +.sp 1 +(or just `\fLstty em4010att\fP' in your login.cl file). + +.NH +Caveats: Undesirable Features or Emulator Bugs +.PP +The current version of the \fBem4010\fP emulator has several features +which can be viewed as bugs or design deficiencies. None of these features +is serious enough to limit use of the \fBem4010\fP, though they may +make certain functions somewhat awkward. + +.NH 2 +Losing the Graphics Buffer +.PP +When in IRAF's \fIcursor mode\fP, the emulator stays in graphics mode for most +functions, including those utilizing the single status line at the bottom +of the screen. +However, those functions that require temporarily flipping +to text mode with the paging system, such as \fIcursor mode\fP's +`\fB?\fP', \fB:.help\fP, etc., cause the graphics buffer to be lost. +If you exit the pager with a carriage return rather than +\fBq\fP, the graphics screen will be refreshed automatically by IRAF. + +.PP +Certain IRAF graphics tasks may try to write text output while you are +still in graphics mode, without using the pager employed +by the likes of \fB:.help\fP. +On some terminals this works fine, with the text output scrolling up +over the graphics, or appearing in a separate window. +However, in the \fBem4010\fP, since the text output is written into +the emulated text `plane', there is an automatic `exit-graphics', causing the +graphics buffer to be erased. +The effect of this is that the graphics screen will be cleared \fIand\fP +you will not have had time to see the text output, though you should still be in +\fIGIN\fP mode (you still have the crosshair). +To redraw the screen at this point, type \fBR\fP. + +.PP +To first view the text output manually, +press \fBALT V\fP; you will now see the full contents of the text buffer. +To go back to graphics, press \fBALT G\fP followed by an \fBR\fP +and \fIfive carriage returns\fP to redraw the screen. +This is because the emulator has forgotten that you were in \fIGIN\fP mode, +while IRAF still expects it to be in that state, not knowing +anything about your temporary manual switch to vtxxx mode. + +.NH 2 +Overstrike vs. Replacement Text +.PP +An apparent emulator bug is that while in Tektronix text mode \fIoverstrike\fP, +the feature that allows us to erase an existing status line before +writing to it afresh is disabled. This means that you can \fBeither\fP have +all text written to the graphics plane overlaid on the plot as with +the \fIvt640\fP and most Tektronix terminals, and never erase the +status line, \fBor\fP erase the status line normally but have text +\fIreplace\fP whatever it writes over. +Here, replacing means there will be a blank border around each character, +so for example in a contour plot the text characters labelling the +contour levels will wipe out any contour lines immediately underneath them. +The latter will still be preferable to most users, because the single +status lines are used frequently by IRAF applications. + +.NH 2 +Unimplemented Tektronix Features +.PP +The emulator does not implement broken lines (dashed, dotted, etc.) at all. +Nor does it emulate different sizes of hardware text, though one can always +set text quality to `high' in \fIcursor mode\fP, and let the +IRAF graphics system generate characters in software +(see \fLhelp cursors\fP). + +.NH +Future Developments +.PP +We are working with the people at Diversified Computer Systems to +try to get them to modify the emulator, particularly to prevent the +graphics buffer from being erased upon exit from graphics mode, and to +cause the emulator to remember when graphics was exited from \fIGIN\fP mode. +We will also try to get them to implement broken lines. + +.bp +.SH +Appendix -- EM4010 Termcap and Graphcap Entries +.sp 1 +.SH +dev$termcap +.LP +.sp 1 +.ft L +.nf +# Diversified Computer Systems vt220/tek4010 emulator (em4010) series +em4010|em4010he|em4010ih|em4010im|em4010ieh|em4010tn|em4010ti|em4010att:\\ + :gd:li#24:co#80:cl=50\\E[H\\E[2J^X:is=^]^X\\E[1;24r\\E[24;1H:tc=vt220: +.sp 1 +.fi +.SH +dev$graphcap +.LP +.sp 1 +.ft L +.nf +# Diversified Computer Systems vt220/tek4010 emulator (em4010) series +em4010he|em4010 emulator for Hercules monochrome graphics board:\\ + :xr#720:yr#348:xs#.19:ys#.15:ar#.77:li#38:ch#.026:tc=em4010: +em4010ih|em4010 emulator for IBM high-res board:\\ + :xr#640:yr#200:li#33:ch#.030:tc=em4010: +em4010im|em4010 emulator for IBM medium-res board:\\ + :xr#320:yr#200:li#33:co#64:ch#.030:cw#.016:tc=em4010: +em4010ieh|em4010 emulator for IBM enhanced graphics board:\\ + :xr#640:yr#350:li#38:ch#.026:tc=em4010: +em4010tn|em4010 emulator for Tecmar Master graphics board, non-interlaced:\\ + :xr#720:yr#352:li#38:ch#.026:tc=em4010: +em4010ti|em4010 emulator for Tecmar Master graphics board, interlaced:\\ + :xr#720:yr#704:li#38:ch#.026:tc=em4010: +em4010att|em4010 emulator for AT&T 6300 monochrome graphics board:\\ + :xr#640:yr#400:li#42:ch#.024:tc=em4010: +em4010|Tek 4010 emulator for IBM PC-compatibles (default Hercules):\\ + :xr#720:yr#348:xs#.19:ys#.15:ar#.77:li#38:ch#.026:lt#1:nc#1:th#1:\\ + :Y1#40:Y2#739:RC=^]\\E"4g:CW=^E\\E[24;0H\\E[K:\\ + :GD=^X\\E[24;1h\\E[24;1f\\E[0K:tc=vt640: +.sp 1 +.ft P +.nf diff --git a/doc/imexpr.ms b/doc/imexpr.ms new file mode 100644 index 00000000..77214778 --- /dev/null +++ b/doc/imexpr.ms @@ -0,0 +1,739 @@ +.ce +\fBImage Expressions in the IRAF Command Language\fR +.ce +Technical Specifications +.ce +Doug Tody +.ce +November 1983 +.sp 2 + +.NH +Requirements +.PP +We wish to be able to directly manipulate images in expressions at the CL +level as easily as we currently manipulate scalars. This feature is +essential if the scientist is to be able to solve general image reduction +and analysis problems with minimal time spent developing special +purpose software. Furthermore, we expect to rely heavily on image expressions +in IRAF for batch reductions of large astronomical datasets, and therefore the +implementation of image expressions must be efficient. + +.RS +.IP (1) +It shall be possible to evaluate general expressions wherein the operands +are constants, scalar variables, images or image sections of any dimension +or datatype, or functions of any of the above. +.IP (2) +It shall be possible to freely use image expressions and statements within +the standard conditional and looping constructs of the CL without any +special restrictions. +.IP (3) +It shall be possible to pass a general expression evaluating to an operand +of type image to any procedure which expects an image as an input argument. +.IP (4) +It shall be possible to pass images or \fIsubsections\fR of images to +procedures as input operands, output operands, or input/output operands. +.IP (5) +It shall be possible for both CL script tasks and external compiled programs +to be used routinely with image expression arguments. +.IP (6) +It shall be easy for the user to extend the system, adding special purpose +scripts or programs beyond those provided by the system. Any such tools +added by the user shall be retained from session to session indefinitely. +It shall not be possible for such user extensions to affect the operation +of the basic system. +.RE + +.PP +We \fImust\fR be able to process complex expressions involving very large +images without compromising the transportability of the IRAF system. +In particular, such operations shall be possible on reasonably equipped +supermicro computers (2-4 Mb main memory) which do not have good virtual +memory facilities (few do), or which have no virtual memory facilities at all. + +.NH +Specifications +.PP +The proposed implementation of image expressions described here meets all +of the above requirements without sacrificing modularity or requiring +major modifications to the current CL. The design can handle large images +very efficiently; i/o and memory requirements are minimized and hooks are +included for eventually adding a bit-mapped array processor. For small +images, i.e., two dimensional images less than 64 pixels square, there is +significant overhead but the interactive response should still be good. +New features not found in any currently available image processing system +(so far as I am aware) include general image sections and conditional +expressions. +.NH 2 +Images +.PP +An image is an IRAF imagefile. Images are described in detail elsewhere. +In brief, images of from one to seven dimensions are (currently) supported. +The permissible imagefile datatypes are short, unsigned short, int, long, +real, double, and complex. There is effectively no limit on the size of +an image, nor is there a fixed limit on the size of the images in image +expressions, even on modest non-virtual memory machines. +.PP +Each image has a header describing the physical and derived attributes of +the image, i.e., the dimensions and datatype, mininum and maximum pixel +values, title, history, histogram, coordinate systems, and so on. +An image may also have a bad pixel list. +In general, bad pixel lists are automatically merged in image expressions +and the resultant list passed on to the output image, but otherwise no +distinction is made between good and bad pixels in image expressions. +.NH 2 +Image Operand Syntax +.PP +Any operand in a CL expression which is subscripted has the datatype +\fBimage\fR. An image type operand or \fBimage section\fR has the form +.DS + \fIimage_name\fR "[" \fIsubscript_list\fR "]" +.DE +where \fIimage_name\fR may be any string or integer valued expression, and +where \fIsubscript_list\fR is a (possibly null) list of subscript expressions +(described in \(sc2.5), or a string valued expression which reduces to a +string containing only section metacharacters or numeric constants. +The subscripting operator "[" is a true operator with a precedence +(binding force) greater than that of any of the +conventional operators, and which is right associative. +.PP +Parentheses may be used to change the default order of evaluation of an +expression containing a subscript, if desired. For example, consider +the following two expressions: +.DS + imname // imnumber [] + (imname // imnumber)[] +.DE +Due to the strong precedence of the [], the first expression is actually +equivalent to "imname // (imnumber[])", which is probably not what was +intended. +.PP +Lastly, since the image name string is a filename string, it is subject +to the usual restrictions on optional quoting of filename strings. +Consider the following two expressions: +.DS + m92[] \(mi biasframe[] + "m92"[] \(mi (biasframe)[] +.DE +The first expression is ambiguous, since it is not evident whether +or not the identifiers "m92" and "biasframe" are string constants (filenames) +or parameter names. The expression is resolved by applying the usual +disambiguating rules, i.e., if a string is expected and there are no +enclosing parentheses, the identifer is assumed to be a string constant. +The second expression is unambiguous. +.PP +If the filename string is not a legal identifier, for example if it is an OS +dependent pathname or if it contains special characters (as in "PK157+23"), +the quotes are required. If the ultimate in brevity is desired numeric +filenames may be used, as in the expression "5[] + 9[]". The actual disk +files would be named "I5" and "I9" in this example. Numeric filenames need +never be quoted. +.NH 2 +Parameters of Type Image +.PP +CL script tasks and compiled programs may have parameters of type \fBimage\fR. +In many respects image type parameters are similar to filename or string +type parameters, i.e., they may be list structured, queries are generated +in the usual fashion, and so on. The essential thing to keep in mind when +using image type parameters is that they have the datatype image, not +string, and therefore may not be subscripted. An image type parameter may +be used anywhere an image type operand expression would be used, and in +fact they are the same type of object. +.PP +Image parameters are set either by using an image type expression in +the argument list to a procedure, or by explicit assignment. In an +assignment, the value of the image parameter on the left side is set +only if the right-hand side has the datatype string. Otherwise, the +image parameter defines the image section to be stored into. Thus, +.DS + output_image = a[*,\(mi*] +.DE +is an image copy operation (it moves pixels), whereas +.DS + output_image = str (a[*,\(mi*]) +.DE +merely sets the value of the parameter "output_image" to the indicated +image section specification. +.NH 2 +The Attributes of an Image +.PP +The physical attributes of an image are accessible within the CL by means +of special intrinsic functions. The special image attribute intrinsic +functions are the following: + +.RS +\fBndim\fR (\fIimage_section\fR) +.RS +Returns the number of dimensions in the referenced image. +.RE +.sp +\fBlen\fR (\fIimage_section\fR, \fIaxis\fR) +.RS +Returns the length of the indicated dimension of the named section. +The x-axis is dimension number one, the y-axis is dimension number two, +and so on. If the axis argument is omitted, the total number of pixels +is returned. +.RE +.sp +\fBpixtype\fR (\fIimage_section\fR) +.RS +Returns a string identifying the datatype of the pixels in the image +(i.e., "ushort", "short", "real", etc.). +.RE +.RE + +.PP +The remaining physical image attributes, and all of the special user +defined attributes, are accessible only via the DBIO/CL interface. +.NH 2 +Image Sections +.PP +Image sections are used to specify the region of the image to be operated +upon. If the entire image is to be operated upon, then the null section +("[]") must still be given to tell the CL that the operand is of type image. +A limited class of coordinate transformations may be specified using image +sections (but transpose is \fInot\fR one of them). Though the use of an +explicit image section appears to require knowledge of the actual dimensions +of the image, in fact the actual image may be of a higher dimension than +indicated, with the higher dimensions being set to one. The basic types of +image sections are noted below for two dimensional images. + +.KS +.TS +center; +ci ci +l l. +section refers to + +pix[] whole image +pix[i,j] the pixel value (scalar) at [i,j] +pix[*,*] whole image, two dimensions +pix[*,\(mi*] flip y-axis +pix[*,*,b] band B of three dimensional image +pix[*,*:s] subsample in y by S +pix[*,l] line L of image +pix[c,*] column C of image +pix[i1:i2,j1:j2] subraster of image +pix[i1:i2:sx,j1:j2:sy] subraster with subsampling +pix[*n,*] shift N pixels in x +.TE +.KE + +The "match all" (asterisk), flip, subsample, index, range, and shift notations +may be combined just about any way that makes sense. Some examples +are given later. +.PP +The subscript list part of an image section specification may be either an +expression list, as in the examples above, or a string valued constant, +parameter, or expression. If the same section specification is used several +times within a procedure it may be desirable to parameterize it, so that the +procedure may be easily used to process other sections. For example, many +modern CCD detectors produce an image with a bias strip along one side of +the image which must be removed from the data at some point in the reductions. +The coordinates of the bias strip and of the data area should be parameterized +so that the same scripts can easily be used to process data from slightly +different detectors: + +.DS +bias_strip = "325:350,1:512" +data_area = "1:324,1:512" + +# Display only the data pixels. +display rawpix[data_area] +.DE +.NH 2 +Statements +.PP +In general, image expressions may be used wherever an ordinary arithmetic +expression would be used. No image expression produces a boolean result +and therefore image expressions may not be used where boolean expressions +are expected (i.e., in \fBif\fR, \fBwhile\fR, etc. conditions). +Image expressions may be freely used within conditional and looping control +constructs, within the argument lists of subprocedures, and within the +subprocedures themselves. +.PP +Much of the power of image expressions derives from their use within +assignment statements wherein the left hand side (lhs) is an image or image +section. The CL implements five kinds of assignment statements, as +illustrated in the table below. +.PP +A lhs of type image may specify either a full image (as in the examples), +or a section of an existing image. If a full image section is specified, +a new image will be created, overwriting any existing image. The datatype +of the new image will be that of the expression on the right hand side. +The rhs may be a scalar, a vector of length matching one of the dimensions +of the lhs, or a section with the same dimensions as the lhs. +If a subsection is specified, the named image must exist and the indicated +section will be edited as specified. + +.KS +.TS +center; +ci ci +l l. +statement meaning + +a[] = expr simple assignment +a[] += expr add image expression to image A +a[] \(mi= expr subtract image expression from image A +a[] *= expr multiply image expression into image A +a[] /= expr divide image expression into image A +.TE +.KE + +.PP +When we say that a new image overwrites any existing image of the same +name, what we actually mean is that it does so only if file \fBclobber\fR +is enabled. File clobber protection is a standard feature of the IRAF system; +if clobber is disabled (default), an abort will occur when a program attempts +to overwrite an existing file (in which case the file or image must be +explicitly deleted and the operation repeated). There is another standard +feature allowing the user to explicitly "protect" files. +.PP +The four "exotic" assignment operators are used to edit existing images. +The same image may, if desired, appear on both sides of an assignment +statement. The "+=" assignment is especially useful for constructing +mosaics. +.NH 2 +Operators +.PP +An expression containing image type operands is grammatically like any +other CL expression (or SPP expression), and therefore the same set of +operators may be used for both types of expressions. The precedence and +associativity of these operators are the same in all cases. + +.TS +center; +ci ci +l l. +operator meaning + ++ addition +\(mi subtraction or unary negation +* multiply +/ divide +** exponentiation +// concatenation + +\(eq\(eq equal +!\(eq not equal +< less than +<\(eq less than or equal +> greater than +>\(eq greater than or equal +! boolean negation + +? conditional expression +.TE + +.PP +When used with image type operands, as in any expression, the concatenation +operator produces a string result. Normally the image section will be +concatenated as a string without actually accessing an image. If this is +not what is desired, i.e., we want to concatenate the scalar value of a single +pixel, parentheses should be used to force evaluation of the image reference +before concatenation. +.PP +The boolean operators have a different meaning when used with one or more +operands of type image then when used in in normal expressions. +In normal expressions, the result of a boolean expression is a scalar +of type boolean. If an image type operand is present in a boolean expression, +the expression is of type image, and the output image will be a short integer +image wherein the pixels take on the values zero (false) or one (true). +Boolean images are useful for forming masks. +.PP +The final operator shown, the conditional operator, is used to specify +pointwise image operations wherein the action taken for a given output pixel +may depend on the values of each of the input pixels. +In scalar expressions, conditional expressions are useful but not really +essential, but in image expressions the only alternatives are to build special +purpose compiled procedures (time consuming), or to subscript individual pixels +at the CL level (very inefficient). +.PP +To illustrate the use of the conditional +expression, consider the following statement which divides image A into image +B, placing the result back into image B. The operation is equivalent to a +simple division unless the value of an A pixel is less than 0.01, in which case +the corresponding output pixel is set to zero. +.sp +.DS + b[] \(eq (a[] < .01) ? 0 : b[] / a[] +.DE +.NH 2 +Intrinsic Functions +.PP +All of the standard CL/SPP arithmetic intrinsic functions are permitted +in image expressions. Some additional intrinsic functions, useful only in +image expressions, are also available. The standard set of intrinsic +functions used in image expressions is shown in the table below. + +.KS +.TS +center; +l l l l l l. +abs min mod nint long floor +atan2 sin aimag sqrt real max +cos ceil double complex tan short +int log log10 exp conjug +.TE +.KE + +.PP +Nearly all of these intrinsic functions, when called with an image type +argument or arguments, will return an image result. The exceptions are +\fBmin\fR and \fBmax\fR, which return the minimum and maximum values of +an image or image section, respectively. The functions \fBfloor\fR and +\fBceil\fR are used to perform max and min \fIvector\fR operations. +.PP +Additional special image intrinsic functions are required and will be +added once a well thought out list has been prepared. Examples of such +operators might be vector sum, sum of squares, mean, median, and boxcar +smooth. Major operations such as image transpose, convolution, filtering, +etc. will be implemented with external procedures, rather than as intrinsic +functions. The intrinsic functions are evaluated with "inline" vector +instructions and this necessarily limits the range of functions that can +be provided. +.NH 2 +Referencing Out of Bounds +.PP +By default, it is illegal to reference out of bounds on an image, except +when using a shift type image section specification. If more explicit +out of bounds references are desired than one must set the \fBnboundarypix\fR +parameter to a nonzero value, and the \fBboundarytype\fR parameter to the +type of boundary extension desired. For the convenience of +interactive users these parameters are defined globally, but they should +be redefined as local parameters in the parameter file for a task which +must reference out of bounds. +.PP +There is no one best way to satisfy out of bounds pixel references (unless +it is to abort). The following options are currently available: + +.KS +.TS +center; +ci ci +l l. +boundarytype action + +nearest use value of nearest boundary pixel +reflect reflect coords back into image +project project outward from boundary +wraparound wrap around to opposite side of image +indefinite set pixel value to INDEF +apodize sample a cosine (for fourier analysis) +.TE +.KE +.NH 2 +Procedures +.PP +Only a limited number of predefined intrinsic functions are available +due to the way expressions containing intrinsic functions are evaluated. +The system can accomodate any number of procedures, however, and many are +available in the \fBimages\fR, \fBimred\fR, \fBartdata\fR, and other packages +in the IRAF system. The user can easily add packages and procedures of +their own. Refer to the \fICL Programmer's Guide\fR for information on +adding new packages and procedures. +.NH 2 +Cursor Readback +.PP +Whenever an image is displayed or a vector is plotted, graphics descriptor +information is saved by the system defining the source image and coordinate +systems used to generate the graphics. When working interactively, the +graphics or image cursor may be read merely by referencing one of the global +cursor parameters \fBgcur\fR and \fBimcur\fR in an expression. Each reference +will cause a cursor read. If a cursor is to be referenced within a procedure, +a local parameter of \fIdatatype\fR gcur or imcur should be defined, +to make it easier to use the procedure noninteractively with a list of cursor +coordinates. + +.NH 2 +Examples +.PP +A few examples should help to illustrate the use of images and image +sections in expressions in the CL. Images of any datatype may be used in +expressions, with type coercion following the usual rules. Explicit +type coercion may be indicated using intrinsic functions (\fBint\fR, +\fBreal\fR, etc). Operations involving images of different dimensions are +permissible, but in general the images in an expression must be the same +size. If the actual images are not the same size then sections must +be used to indicate the regions to be used. +.PP +For example, to compute the average of the two images A and B and display +the result, we could enter the commands +.DS +.cs 1 22 +avg[] = (a[] + b[]) / 2 +display avg[] +.DE +.cs 1 +Although not shown that way, if A and B were filenames, not parameters, +they would have to be quoted, since they occur within parentheses. +The null subscript in the call to \fBdisplay\fR is optional since the +entire image is being passed as an argument. +The above operation could be expressed more concisely in the form +.DS +.cs 1 22 +display (a[] + b[]) / 2 +.DE +.cs 1 +which would compute and display the same average image, without explicitly +creating an intermediate image. +.PP +To plot column COL of image PIX on a logarithmic scale, after first +subtracting a bias value, we can either explicitly take the logarithm with +an intrinsic function or let the plotting code compute the logarithm. +The latter is the best choice because \fBplot\fR will then be able to a +better job of labeling the axes. It remains only to subtract the bias value: +.DS +.cs 1 22 +plot pix[col,*] \(mi bias, logy+, + title = "Log of column " // col // " of image " // pix +.DE +.cs 1 +Now suppose we have a million point spectrum which we wish to plot. +The most straightforward way to plot such a large array on a graphics +terminal is to subsample every 1024 pixels: +.DS +.cs 1 22 +plot spectrum[*:1024] +.DE +.cs 1 +To display the fifth xz plane of the image cube "cube", with +contour lines 10 graylevels wide spaced every 100 graylevels: +.DS +.cs 1 22 +plane[] = cube[*,5,*] +display ((mod (plane[] / 10, 10) == 0) ? 0 : plane[]) +.DE +.cs 1 +Image sections may also be used to modify a section of an existing image. +Thus, +.DS +.cs 1 22 +pix[col,*] += 5.3 +.DE +.cs 1 +would add the constant 5.3 to each pixel in column COL of image PIX. Similar +statements may be used to copy subrasters, form mosaics, etc. +.PP +Shifting is useful for image registration and to some extent for filtering. +Linear combinations of the same image shifted a pixel or so differently +in each reference may be used to perform simple filtering operations +(i.e., gradient or laplacian), though generally it is more convenient to +use the standard \fBimages\fR procedures for filtering. To display the +difference of two images A and B with B shifted to align it with A: +.DS +.cs 1 22 +display a[] \(mi b[*3,*\(mi1], 1 +.DE +.cs 1 +.PP +Most expressions involving images will operate on entire images or image +sections. Occasionally, however, it is necessary to be able to operate on +individual pixels. This is done in the obvious way, i.e., by subscripting +individual pixels: +.sp +.DS +.cs 1 22 +sum = 0 +for (j = j1; j <= j2; j += 1) + for (i = i1; i <= i2; i += 1) + sum += pix[i,j] + +# Print "sum over pix[i1:i2,j1:j2] = value". +print ("sum over ", pix, "[", str(i1), ":", str(i2), ",", + str(j1), ":", str(j2), "] = ", sum) + +# Subtract mean value from subraster. +pix[i1:i2,j1:j2] \(mi= sum / (i2\(mii1+1 * j2\(mij1+1) +.DE +.cs 1 +.sp +Doing this sort of thing at the CL level is quite inefficient compared to +the equivalent compiled program, but interactive response is not hard to +achieve provided the number of pixels operated on in this fashion is small. +.PP +As a final example, suppose we have four 800-square images +which we wish to combine together to form a mosaic. To keep things simple +we assume that no rotations are required and that the frames do not overlap. +We further assume that the procedure \fImkimage\fR is available for making +constant (default zero valued) images of arbitrary dimension and size. +One way of forming the mosaic is shown below. +.sp +.DS +.cs 1 22 +mkimage mosaic, real, 800, 800 +for (j=1; j < 1600; j += 800) + for (i=1; i < 1600; i += 800) + mosaic[i:i+800\(mi1,j:j+800\(mi1] = quadrant +.DE +.cs 1 +.sp +We assume here that the parameter "quadrant" is either a query mode +or list structured parameter, so that it may take on a different value +in each reference. Alternatively a naming convention could be used to +form the names of the quadrant images. + +.NH +Implementation Strategies +.PP +The implementation proposed here requires minimal modifications to the +CL and makes full use of the facilities provided by the IRAF program interface, +in particular the IMIO and VOPS interfaces. A separate process running +concurrently with the CL is used to execute a series of very high level +"assembler language" instructions passed it by the CL, which parses the +original expression, resolves all parameter references, and reduces all +scalar expressions to a single constant. +.PP +The design is very efficient for operations on large images because the +expression is evaluated an image line at a time, requiring one pass through +the entire image expression for each line in the output image. This scheme +minimizes memory requirements while also minimizing i/o, since no intermediate +images need be written to disk. The alternative strategy (whole image +operations) is simpler and more efficient for small images, but for large +images either requires an enormous amount of physical memory or leads to +excessive and needless i/o (page faulting). +.PP +At the lowest level all processing will be done with calls to the VOPS +vector operators. This leads to increased efficiency, since the VOPS +vector "instructions" may easily be optimized in assembler or microcode if +necessary. +Furthermore, the VOPS interface makes it straightforward to interface to +the new bit-mapped (shared memory) array processors. The use of a shared +memory AP, as opposed to a conventional AP, is desirable because such AP's +can process short vectors (image lines) with very little overhead, since +no additional i/o is required. We merely allocate our line buffers in +a Fortran common block in the shared memory region. The AP is then a true +coprocessor which can be used to execute logical vector instructions. +.PP +The use of a separate process is justified because the image calculator +process will probably be larger in size and comparable in complexity to the +CL itself (when one considers the complexity of the IMIO, DBIO, VOPS, and FIO +interfaces), and because the current CL does not use any of these facilities +and is already a very large and complex program. We also nearly double the +maximum number of open files by using two processes instead of one. +By defining a simple interface between the image calculator and CL we will +find it much easier to modify and enhance both in the future. +Finally, the CL as it now stands is quite useful for non-image processing +applications (i.e., software development, database applications, graphics, +etc.), and the addition of extensive code to support special purpose +applications can only decrease the generality of the CL. +.NH 2 +Scope of CL Modifications Required +.PP +All that we need add to the grammar of the CL to support image expressions +is the ability to parse image section subscripts. To the CL an image section +subscript will be a fancy kind of string concatenation. An identifier +followed by an image section is converted into a string-type operand with +the abstract datatype "image". The section string is pushed on the operand +stack as a datume of datatype image, much as a filename string is currently +pushed onto the operand stack. All processing of the actual image section +string is left to IMIO (in the image calculator process). The current +implementation of IMIO already has the capability to process image sections +in the manner described in this document. IMIO also does all buffering, type +conversion, and handling of out of bounds pixel references. +.PP +The image subscript notation tells the CL that an operand is of type +"image" without need for an explicit declaration, as is required for normal +CL scalar or list structured variables. Another way of expressing this +is that an image is an external data object, like a file, and is not a +parameter and therefore need not be declared. +.PP +The first function of the CL in processing a statement involving image +type operands is to parse expressions and statements into an +internal virtual machine "assembly language" form. The current CL already +does this, and little need be added to support image type operands. +The resultant code is then executed (interpreted) in the usual fashion by +the CL, satisfying all parameter references and evaluating all scalar +expressions. If an image section is encountered which is merely assigned +into an image parameter as a string or which is passed to a subprocedure, +it is not an image expression and no call to the image calculator is +necessary. +.PP +If the code contains expressions containing image operands, each such +expression is first processed to satisfy all parameter references and +reduce all scalar expressions to constants, +then it is passed to the image calculator process as a sequence of +ASCII "assembler" instructions containing only image section string +constants, numeric constants, and calls to intrinsic functions. +.PP +A separate call to the image calculator is required to evaluate each +image expression or image assignment (the image calculator process will +normally sit in the process cache, i.e. hibernate, between calls and will +not have to be reexecuted). The image calculator process carries out +the actual expression evaluation, evaluating the entire expression once +for each line in the output image. +.PP +The result of an image type expression is a new imagefile, unless the +result is a scalar in which case the scalar is returned to the CL and left +on the CL runtime operand stack as the value of the expression. +If the expression is not explicitly assigned into a named image or +image section by the user, the CL generates a temporary image name which +receives the new image. Image expressions used as arguments to procedures +are evaluated before the procedure is called, passing only the name of the +resultant temporary image to the subprocedure. The temporary images are +deleted after normal or abnormal termination of the subprocedure. +.NH 2 +The Image Calculator +.PP +The main function of the image calculator is to evaluate a (reverse polish) +expression and write an output image. This is the case whether or not +the original expression was part of an assignment statement; to the image +calculator, expressions in argument lists are assignments into temporary +imagefiles. Since the expression is evaluated for all images simultaneously, +the maximum complexity of an expression is limited by the maximum number +of open files permitted a process by the OS. The image header file need +be open only at immap and imunmap time, so only one file descriptor is +required for each image. Most systems permit from 16 to 25 open files; +on some systems the number is configurable. +.PP +To minimize \fBimmap\fR and \fBimunmap\fR calls when repeatedly operating +on the same image or set of images, it is desirable to maintain a cache +of mapped images in the image calculator process. If this is done +then a CL loop which accesses an image in storage order a pixel at a time +will require "only" four context switches and some code execution per +pixel access. No i/o will be required since the pixels will, in general, +already be buffered within the image calculator process. Similar gains +will result for scripts which repeatedly access lines or subrasters in the +same image in successive calls. +.PP +The \fBonexit\fR call in the program interface will be used to unmap all +cached images when the CL commands the image calculator process to exit. +The CL automatically flushes its process cache (containing the image +calculator process) whenever a background job is spawned or an OS escape +is issued, so competing processes should not hang up unnecessarily waiting +for access to an image which is opened for writing by another process (but +they will still do so if necessary). +.PP +All operators and intrinsic functions recognized by the image calculator +will be implemented with VOPS primitives. One is required for each +data type dealt with internally. There will be five internal datatypes, +though seven datatypes are permitted on disk. The internal datatypes +will be short, long, real, double, and complex. The same functionality +could be acheived with fewer internal types, but it is desirable to +minimize the expense of type conversion. If necessary a stripped +version of the process could be provided implementing only datatypes +long and real, using an environment variable to specify whether the stripped +or the general process is to be run. +.PP +The CL need have no knowledge of the set of acceptable imcalc intrinsic +functions, except to know which ones return scalar values. The parser will +recognize a call to an intrinsic function in an image expression and +generate a call to the named function in the assembler code, but will +otherwise know nothing about the class of intrinsic functions accepted by +the image calculator. New intrinsic functions may thus be added to the +image calculator without requiring any modifications to the CL. +.PP +The evaluation of expressions in the image calculator is straightforward +because IMIO does most of the work. Since IMIO handles image sections +and resolves out of bounds pixel references, the calculator is presented +with the simple problem of reading in N vectors M times and performing +the same set of operations each time. The line-sequential mode IMIO +i/o calls will be used to read and write image lines, so that we need +not be concerned about dimensionality. Some logic is required to deal +with the cases of a scalar times an image or a vector times an image. +Conditional expressions are evaluated by reducing the three parts to +vectors using the VOPS primitives, then calling another VOPS primitive +to select elements from the true and false vectors to generate the +output vector. diff --git a/doc/iraf.ms b/doc/iraf.ms new file mode 100644 index 00000000..26f28220 --- /dev/null +++ b/doc/iraf.ms @@ -0,0 +1,1779 @@ +.pl 8.5i +.nr PS 11 +.nr VS 12 +.nr PD 1v +.nr PO 0.875i +.nr LL 9.215i +.nr HM 0.5i +.nr FM 0.5i +.de CH +.. +.LP +.TL +The IRAF Data Reduction and Analysis System +.AU +Doug Tody +.AI +National Optical Astronomy Observatories +P.O. Box 26732, Tucson, Arizona, 85726 +.AB +.ti 0.75i +The Image Reduction and Analysis Facility (IRAF) is a general purpose +software system for the reduction and analysis of scientific data. +The IRAF system provides a good selection of programs for general image +processing and graphics applications, plus a large selection of programs +for the reduction and analysis of optical astronomy data. The system also +provides a complete modern scientific programming environment, making it +straightforward for institutions using IRAF to add their own software to +the system. Every effort has been made to make the system as portable +and device independent as possible, so that the system may be used on a +wide variety of host computers and operating systems with a wide variety +of graphics and image display devices. +.AE +.LP + +.ce +\fB1. Introduction\fR +.PP +The IRAF project began in earnest in the fall of 1981 at Kitt Peak National +Observatory (NOAO did not yet exist at that time). The preliminary design of +the system was completed early in 1982, and the first versions of the command +language (CL) and the applications programming environment were completed +during 1982. The NOAO IRAF programming group was formed in 1983. The first +internal release of the system occurred at NOAO in 1984, and a beta release +of the system to a few outside sites occurred in 1985. +.PP +The Space Telescope Science Institute (STScI) selected IRAF to host their +Science Data Analysis System (SDAS) in December of 1983, and carried out the +initial port of IRAF to VMS, as well as some CL extensions, during 1984 and +1985. In June of 1985, UNIX/IRAF became the primary reduction and analysis +facility at NOAO/Tucson. By October the VMS version of the system was fully +functional at NOAO on the newly installed VAX 8600, which soon became our +primary data processing system. By late 1985 the system had been ported to +such disparate systems as +a Sun workstation running UNIX and to a Data General MV/10000 running AOS/VS +(the latter port was still in progress when this paper was written and was +being undertaken by Steward Observatory, Univ. of Arizona). In February of +1986 a limited public release of the system occurred, with UNIX and VMS +versions of the system being distributed to about 40 astronomical sites. +The system is expected to be made generally available sometime in 1987. +.PP +This paper describes the system as it existed in March of 1986, shortly after +the first public release. The focus of the paper is primarily on the IRAF +system software as seen by the user and by the software developer, although +the NOAO science applications software is briefly introduced. The distinction +is made because the IRAF system software is expected to be used by numerous +institutions to host the science software developed independently by each +institution. The NOAO and STScI science software packages are the first +examples of this; similar undertakings are already in progress, and more are +expected in the future as the system becomes more mature and more widely used. +These science software systems are major projects in their own right and are +best described elsewhere. +.PP +The purpose of this document is to present an overview of the IRAF system +from the system designer's point of view. After a brief discussion of the +global system architecture, we take a tour through the system, starting at +the user level and working down through the programming environments and +the virtual operating system, and ending with the host system interface. +The emphasis is on the system design, on the functionality provided by the +various subsystems, and on the reasoning which went into the design. +The reader is assumed to be familiar with the technology and problems +associated with large software systems and large software development projects. + +.sp +.ce +\fB2. System Architecture\fR +.SH +2.1 Major System Components +.PP +The major components of the IRAF system are outlined in Figure 1. +The \fBcommand language\fR, or CL, is the user's interface to IRAF. +The CL is used to run the \fBapplications programs\fR, which are grouped +into two classes, the system utilities and the scientific applications programs. +Both the CL and all standard IRAF applications programs depend upon the +facilities of the IRAF \fBvirtual operating system\fR (VOS) for their +functioning. The VOS in turn depends upon the \fBkernel\fR, the runtime +component of the host system interface (HSI), for all communications with +the host system. All software above the host system interface is completely +portable to any IRAF host, i.e., to any system which implements the HSI. +The system is ported by implementing the HSI for the new host; note that +the effort required to port the system is independent of the amount of code +above the HSI, and once the system is in place no additional effort is +required to port new applications software. + +.KS +.TS +center; +l l. +Command Language (CL) user interface, command interpreter +Applications Programs system utilities, scientific applications programs +Virtual Operating System (VOS) the system libraries, all i/o interfaces +Host System Interface (HSI) bootstrap utilities, \fBkernel\fR primitives +.TE +.ce +Figure 1. Major System Components +.KE +.PP +From the point of view of the system structure, the CL is itself an +applications program in that it uses only the facilities provided by the +IRAF VOS. In principle an applications program can do anything the CL +can do, and multiple command languages can coexist within the same system. +In practice only the CL is allowed to interact directly with the user +and spawn subprocesses, in order to provide a uniform user interface, +and to minimize the kernel facilities required to run an applications +program. All standard IRAF applications programs can be run directly at +the host system level as well as from the CL, making it possible to run +the science software on a batch oriented system which is incapable of +supporting the CL. +.SH +2.2 Process Structure +.PP +In normal interactive use IRAF is a multiprocess system. The standard +process structure is depicted in Figure 2. The CL process handles all +communications to the user terminal, which is usually a graphics terminal +of some sort. All applications programs run as concurrent subprocesses of +the CL process. A single applications process will usually contain many +executable programs or compiled \fBtasks\fR; the CL maintains a +\fBprocess cache\fR of connected but idle (hibernating) subprocesses to +minimize the process spawn overhead. +If graphics i/o to a device other than the graphics terminal is necessary, +a graphics kernel process is connected to the CL as a subprocess. +.PP +The process cache always contains the process "x_system.e", which contains all +the tasks in the \fBsystem\fR package. The system subprocess is locked in the +cache by default. The remaining process cache slots (typically 2 or 3 slots) +are dynamically assigned as tasks are run by the user. Up to 3 graphics kernels +may be simultaneously connected. The entire process structure is duplicated +when a background job is submitted by the user from an interactive CL. + +.KS +.PS +box "CL"; line <->; box dashed "GIO" "subkernel" +line <-> down at 1st box.s +box width 1.2i "applications" "process" +.PE +.ce +Figure 2. IRAF Process Structure +.KE +.PP +The multiprocess architecture has significant \fBflexibility advantages\fR +over the alternative single process and chained process architectures. +The system is highly modular and easily extended, allowing new versions of +the CL or a new graphics kernel to be tested or installed even while the +system is in use, without having to relink all the applications modules. +New applications modules can be debugged outside the normal CL environment +using host system facilities, and then installed in the system while the +system is in use without any affect on the rest of the system. There is no +limit to the number of applications packages which the system can support, +nor is there any limit to the number of graphics devices which the system +can be interfaced to. Support for a new graphics device can be added to a +running system without any affect on the existing applications programs. +.PP +The multiprocess architecture also has significant \fBefficiency advantages\fR +over less modular architectures. Since most of the system software resides in +independent processes, the amount of code which has to be linked into an +applications program is minimized, reducing the link time as well as the +disk and memory requirements for an executable. Since all users on a multiuser +system use the same CL executable, graphics kernels, and other system +executables, significant savings in physical memory are possible by employing +shared memory access to the executables. The ability of IRAF to link many +tasks into a single executable promotes code sharing, reducing disk and memory +requirements and greatly improving interactive response by minimizing process +connects. Paradoxically, the use of multiple concurrent processes can actually +improve performance by permitting pipelined execution, e.g., the applications +process can be busy generating graphics metacode while the CL or graphics +kernel is waiting for i/o to a graphics device. +.PP +The \fBchief disadvantage\fR of the IRAF process structure is the difficulty of +error recovery in response to a user interrupt or program abort. An interrupt +may occur while all processes in the group are busily computing and passing +messages and data back and forth via interprocess communication (IPC), making it +necessary to terminate the current task and clear and synchronize the entire +IPC data path. That this problem is tractable at all is due to the +master/slave nature of the IPC protocol. At any one time there will be only +one master process in the system. When an interrupt occurs it is only the +master process which is (logically) interrupted. If the task currently +executing in the master process does not intercept the interrupt and either +ignore it or take some special action, control will pass to the VOS error +recovery code in the master process, which will oversee the synchronization +and cleanup of the i/o system before returning control to the CL. + +.sp +.ce +\fB3. The Command Language (CL)\fR +.SH +3.1 Basic Concepts +.PP +The IRAF Command Language (CL) is the user's interface to the IRAF system. +The CL organizes the many system and applications \fBtasks\fR (programs) +into a logical hierarchy of \fBpackages\fR. A package is a collection of +logically related tasks, and is represented to the user using a type of +\fBmenu\fR. Each task has its own local set of \fBparameters\fR. To keep +the calling sequence concise, each task has only a few required or +\fBquery mode\fR parameters. For maximum flexibility, tasks may provide +any number of optional \fBhidden mode\fR parameters as well, each with +a reasonable default value chosen by the programmer but modifiable by the +user, either permanently or via a command line override. +.PP +A package is implemented as a special kind of task, and packages often contain +"tasks" which are really subpackages, hence the logical organization of +packages is a tree. A package must be \fBloaded\fR by typing its name +before any of the tasks therein can be executed or referenced in any other +way by the CL. Loaded packages are organized as a linear list, with the +list order being the order in which the packages were loaded. References to +tasks in loaded packages are resolved by a circular search of this list, +starting with the \fBcurrent package\fR, which may be any package in the +set of loaded packages. If a task with the same name appears in more than +one package, the package name may optionally be specified to resolve the +ambiguity. Note that is is not necessary to traverse the package tree to +execute a task in a loaded package. +.SH +3.2 Command Language Features +.PP +The most notable features of the IRAF command language are summarized in +Figure 3. The CL is designed to serve both as a \fBcommand language\fR and +as an interpreted \fBprogramming language\fR. The emphasis in this initial +version of the CL has been on providing good command entry facilities. +Extensive CL level programming facilities are also provided in the current CL, +but full development of this aspect of the CL is a major project which must +wait until development of the baseline IRAF system is completed. + +.KS +.TS +center; +l l. +\(bu provides a uniform environment on all host systems +\(bu package structure for organization and extensibility +\(bu menus and extensive online help facilities +\(bu concise command syntax similar to UNIX cshell +\(bu i/o redirection and pipes; aggregate commands +\(bu minimum match abbreviations for task and parameter names +\(bu both local and global parameters, hidden parameters +\(bu direct access to host system; foreign task interface +\(bu parameter set editor; command history editor (edt, emacs, vi) +\(bu background job submission (including queuing) +\(bu logfile facility for recording all task invocations +\(bu graphics and image display cursor mode facilities +\(bu virtual filename facility; unix style pathnames to files +\(bu programmable: procedures, C style expressions and control constructs +.TE +.sp +.ce +Figure 3. Selected Features of the IRAF Command Language +.KE +.PP +The basic IRAF command syntax is the same as that used in the UNIX cshell. +Similar \fBi/o redirection\fR and \fBpipe\fR facilities are provided, +extended in the CL to provide support for the standard graphics streams. +\fBBackground job\fR submission facilities are provided, including support +for batch queues, control of job priority, and servicing of parameter queries +from background jobs after the job has been submitted. A cshell like +\fBhistory mechanism\fR is provided, extended in the CL to record multiline +command blocks rather than single command lines, and including a builtin +screen editor facility for editing old commands. Minimum match abbreviations +are permitted for task and parameter names, allowing readable (long) names +to be used without sacrificing conciseness. +.PP +Extensive online \fBhelp\fR facilities are provided, including the package +menu facility already mentioned, a utility for listing the parameters of +a task, as well as online manual pages for all tasks. An interactive +\fBcursor mode\fR facility provides a builtin graphics or image display +control capability operable whenever a cursor is read by an applications +program, without need to exit the applications program. Cursor mode is +discussed further in \(sc6.6. +.PP +While the CL provides a fully defined, complete environment independent of +the host system, an \fBescape mechanism\fR is provided for interactively sending +commands to the host system. In addition, host system tasks, including user +written Fortran or other programs, may be declared as IRAF \fBforeign tasks\fR +and accessed directly from the CL much like true IRAF tasks, permitting the +use of the CL i/o redirection, background job submission, etc. facilities for +these tasks. A host system \fBeditor\fR interface is provided so that the +user may access their favorite editor from within the IRAF environment. +New IRAF programs and packages may be developed and tested from within the +IRAF environment, or programs (CL procedures) may be written in a C like +dialect of the command language itself. +.PP +It is beyond the scope of this paper to attempt to discuss the user level +features of the CL in any detail. The reader is referred to any of the +following references for additional information. +\fIA User's Introduction to the IRAF Command Language\fR explains the basic +use of the language, and the \fIThe IRAF User Handbook\fR contains many +examples as well as manual pages for the CL language features. The document +\fIDetailed Specifications for the IRAF Command Language\fR presents the +author's original design for the CL, and although now rather dated contains +information about the conceptual design and inner workings of the CL not +found in any of the more recent user oriented manuals. +.SH +3.3 Principles of Operation +.PP +With very few exceptions, all user interaction in IRAF is via the CL. +This ensures a consistent user interface for all applications programs, +simplifies applications code, and provides maximum flexibility, since +the CL (and hence the user) controls all aspects of the environment in +which a program is run. Applications programs do not know if they are +being used interactively or not, or even if they are being called from +the CL. Indeed, any IRAF program may be run at the host system level +as well as from the CL, although the user interface is much more primitive +when the program is called at the host level. +.PP +The CL executes concurrently with the applications process, responding to +parameter requests from the applications process, managing the standard i/o +streams, processing graphics output and managing cursor input, and so on. +In effect the CL and the applications task are one large program, except +that binding occurs at process connect time rather than at link time. +This makes it possible for programs to have a highly interactive, sophisticated +user interface, without linking enormous amounts of code into each executable. +A further advantage is that since a single process is used for all user +interaction, the \fIcontext\fR in which a task executes is preserved from +one task to the next, without need to resort to inefficient and awkward +techniques using disk files. +.PP +The CL recognizes a number of different types of tasks, most of which have +already been mentioned. The \fBbuiltin tasks\fR are primitive functions which +are built into the CL itself. \fBScript tasks\fR are interpreted CL procedures. +\fBCompiled tasks\fR are IRAF programs written in some compiled language and +executing in a connected subprocess residing in the process cache. Lastly, +\fBforeign tasks\fR are compiled host programs or host command scripts, +which the CL executes by sending commands to the host system. +A special case of a builtin task is the \fBcl task\fR, the function of which +is to interpret and execute commands from a command stream, e.g., the user +terminal. +.PP +All of these types of tasks are equivalent once the task begins executing, +i.e., while a task is executing the function of the CL is to interpret and +execute commands from the \fItask\fR, until the task informs the CL that it +has completed. If a command is received which causes another task to be run, +the CL pushes a new task context on its control stack and executes the new +task, popping the old context and resuming execution of the old task when +the called task terminates. Logout occurs when the original "cl" task exits. +The key point here is that the CL functions the same whether it is taking +commands from the user, from a script, or from a compiled applications program. +This is known as the principle of \fBtask equivalence\fR, and is fundamental +to the design of the CL. +.SH +3.4 Extensibility +.PP +New tasks or entire packages may be added to the CL at any time by entering +simple declarations, hence the CL environment is easily extended by the user. +The mechanism used to do this is the same as that used for the packages and +tasks provided with the standard system, hence the user has full access to +all the facilities used for the standard IRAF tasks, including the help +mechanism. No changes have to be made to the standard system to add locally +defined packages and tasks. Conversely, a new version of the standard system +can be installed without affecting any local packages (provided there have +been no interface changes). + +.sp +.ce +\fB4. Applications Software\fR +.SH +4.1 System Packages +.PP +The IRAF applications packages are divided into two broad classes, the system +packages and the scientific reduction and analysis packages. In this section +we introduce the system packages, which are listed in Figure 4. When +describing the applications packages, we list all packages which have been +implemented or which we plan to implement, since the purpose of this paper +is as much to present the design of IRAF as to report its current state. +The status of each package is indicated in the table below, where \fIdone\fR +means that the package has reached its planned baseline functionality +(of course, all packages continue to evolve after they reach this state), +\fIincomplete\fR means that the package is in use but has not yet reached +baseline functionality, \fIin progress\fR means the package is actively being +worked on but is not yet in use, and \fIfuture\fR means that work has not yet +begun on the package. It should be pointed out that each of these packages +typically contains several dozen tasks, and many contain subpackages as well. +It is beyond the scope of this paper to delve into the contents of these +packages in any detail. + +.KS +.TS +center; +ci ci +n c. +package status (March 86) + +dataio -\& Data input and output (FITS, cardimage, etc.) done +dbms -\& Database management utilities future +images -\& General image processing, image display incomplete +language -\& The command language itself done +lists -\& List processing incomplete +plot -\& General graphics utilities done +softools -\& Software tools, programming and system maintenance done +system -\& System utilities (file operations, etc.) done +utilities -\& Miscellaneous utilities done +.TE +.ce +Figure 4. System Packages +.KE +.PP +The system packages include both those packages containing the usual operating +system utilities, e.g., for listing directories or printing files, as well as +those packages which are required by any scientific data processing system, +e.g., for general image processing and graphics. The conventional operating +system utilities are found in the \fBsystem\fR package. The \fBlanguage\fR +package contains those tasks which are built into the CL itself. +The \fBsoftools\fR package contains the software development and system +maintenance tools, including the HSI bootstrap utilities, i.e., the compiler, +librarian, the \fImkpkg\fR utility (similar to the UNIX \fImake\fR), +the UNIX \fItar\fR format reader/writer programs, and so on. +The \fBdbms\fR package is the user interface to a planned IRAF relational +database facility. The \fBlists\fR package contains an assortment of tasks +for operating upon text files containing tabular data, e.g., for performing +a linear transformation on one or more of the columns of a list. +.PP +The \fBdataio\fR package contains a number of tasks for reading and writing +data in various formats, including FITS, cardimage, and a number of other +more NOAO specific formats. These programs are typically used to read or +write magtape files, but all such programs can be used to operate upon a +disk file as well, a useful alternative for sites which have access to +an electronic network. The \fBplot\fR package contains a number of vector +graphics utilities, including CL callable versions of all the NCAR graphics +utilities (using the IRAF/GIO GKS emulator). The \fBimages\fR package, +which is actually a tree of related packages, contains the general image +processing tasks plus the image display and display control tasks. +.SH +4.2 Optical Astronomy Packages +.PP +The NOAO packages for the reduction and analysis of optical astronomy data +are summarized in Figures 5 and 6. There are two categories of optical +astronomy packages. The packages listed in Figure 5 are intended to be of +general use for any optical astronomy data, not just for data taken at an NOAO +observatory with an NOAO instrument. Since these are intended to be general +purpose, instrument independent packages, naturally they are not always the +most convenient packages to use for reducing data from a specific instrument. +The \fBimred\fR packages, summarized in Figure 6, fulfill the need for easy to +use or "canned" reduction procedures for specific instruments. In many cases +the tasks in the \fBimred\fR packages are CL scripts which fetch instrument +specific parameters from the image headers and call tasks in the more general, +instrument independent packages. The list of \fBimred\fR packages is +continually growing as new instruments are supported. + +.KS +.TS +center; +ci ci +n c. +package status (March 86) + +artdata -\& Artificial data generation package in progress +astrometry -\& Astrometry package future +digiphot -\& Digital photometry package in progress +focas -\& Faint object detection and classification package future +imred -\& NOAO Instrument reduction packages done +local -\& Local user added tasks (not configuration controlled) - +onedspec -\& One dimensional spectral reduction and analysis package done +twodspec -\& Two dimensional spectral reduction and analysis packages done +surfphot -\& Galaxy surface brightness analysis package future +.TE +.ce +Figure 5. General Optical Astronomy Reduction and Analysis Packages +.KE +.PP +The \fBartdata\fR package consists of tasks for generating various types of +test data, e.g., pure test images, artificial starfields, artificial spectra, +and so on. The \fBastrometry\fR package is used to obtain astrometric +coordinates for objects in stellar fields. +The \fBdigiphot\fR package contains +a collection of tasks for automatically generating starlists, for performing +aperture photometry on an image (fractional pixel, multiple concentric +apertures, polygonal apertures), and for performing photometry using point +spread function fitting techniques. The \fBfocas\fR package performs faint +object detection and classification (e.g., to discriminate between faint +stars and galaxies), and will be largely a port of the existing UNIX +package of the same name to IRAF. The \fBonedspec\fR package provides a +standard set of tools for the dispersion correction, flux calibration, and +analysis of one dimensional spectra. The \fBtwodspec\fR package performs +the same operations for two dimensional spectra of various types, and currently +consists of the subpackages \fBlongslit\fR, \fBmultispec\fR, and +\fBapextract\fR. The \fBsurfphot\fR package fits ellipses to the isophotes +of galaxies. + +.KS +.TS +center; +ci ci +n c. +package status (March 86) + +imred.bias -\& General bias subtraction tools done +imred.coude -\& Coude spectrometer reductions done +imred.cryomap -\& Cryogenic camera / multi-aperture plate reductions done +imred.dtoi -\& Density to intensity calibration in progress +imred.echelle -\& Echelle spectra reductions done +imred.generic -\& Generic image reductions tools done +imred.iids -\& KPNO IIDS spectral reductions done +imred.irs -\& KPNO IRS spectral reductions done +imred.vtel -\& NSO (solar) vacuum telescope image reductions done +.TE +.ce +Figure 6. Current NOAO Instrument Reduction Packages +.KE +.PP +The \fBimred\fR packages perform general CCD image reductions, as well as the +reductions for other more specialized instruments. The \fBcryomap\fR, +\fBiids\fR, \fBirs\fR, and \fBvtel\fR packages deal with specific NOAO +instruments and are probably only of interest to people who observe at an NOAO +observatory. The remaining packages should be useful for anyone with CCD, +Echelle, or photographic (density) data. +.SH +4.3 Third Party Software +.PP +In addition to the applications packages already mentioned, all of which are +being developed by the IRAF group at NOAO, we anticipate that a fair amount of +third party software will eventually be available for use within IRAF as well. +The STScI SDAS software is the first example of this. +Third party software appears within IRAF as a new branch on the package tree. +There is no limit on the size of such an addition, and in the case of SDAS +we find a suite of packages comparable to the IRAF system itself in size. +As of this writing, a number of other groups are either actively developing +additional third party software or are contemplating doing so, +but it would be inappropriate to be more specific until these packages +are announced by the institutions developing them. +.PP +Third party software may unfortunately not meet IRAF standards, +hence the software may not be usable on all IRAF hosts, nor usable with all +the graphics and image display devices supported by IRAF. +Applications software which is built according to IRAF standards is +automatically portable to all IRAF hosts without modification (although +some debugging is typically required on a new host), hence sites considering +adding their own software to IRAF are encouraged to model their software +after the existing NOAO IRAF applications. + +.sp +.ce +\fB5. Programming Environments\fR +.SH +5.1 Overview +.PP +It is unrealistic to expect any finite collection of applications packages +to provide everything that a particular user or institution needs. +To be most useful a system must not only provide a good selection of ready +to use applications software, it must make it easy for users to add their own +software, or to modify the software provided. Furthermore, implementation and +development of even the standard IRAF applications packages is a major project +requiring many years of effort, hence the system must minimize the effort +required for software development by professional programmers as well as by +users. The solution to these problems is a \fBprogramming environment\fR, +or more precisely, a set of programming environments, each tailored to a +particular type of software and to the level of expertise expected from the +programmer. +.PP +The term programming environment refers to the languages, i/o libraries, +software tools, and so on comprising the environment in which software +development takes place. A good programming environment will provide all +the facilities commonly required by applications programs, ideally in +a form which is high level and easy to use without sacrificing flexibility +and efficiency. The facilities provided by the environment should be +layered to provide both high and low level facilities and to maximize code +sharing and minimize program size. The programming environment should +provide machine and device independence (code portability) as an inherent +feature of the environment, without requiring an heroic sacrifice or +transcendent wisdom on the part of the programmer to produce portable code. +.PP +IRAF currently provides three quite different programming environments. +The highest level environment is the CL, where the programming language is +the command language itself, and the environment is defined by the CL callable +packages and tasks. This is a very attractive programming environment for +the scientist/user because of its high level, interactive nature, but much +work remains to be done before this environment reaches its full potential. +At the opposite extreme is the host Fortran interface, which allows Fortran +programs written at the host level, outside of IRAF, to access IRAF images +and to be called from the CL. This is of interest because it allows +existing Fortran programs to be productively used within IRAF with minimal +modifications, and because it makes it possible for users to write image +operators immediately without having to learn how to use a more complex +(and capable) environment. +.PP +The third programming environment is that defined by the IRAF VOS. This is the +most powerful and best developed environment currently available, and is used +to implement nearly all of the existing IRAF systems and applications software. +Full access to the VOS facilities and full portability are available only for +programs written in the IRAF SPP (subset preprocessor) language, the language +used to implement the VOS itself. A C language interface is is also available, +but only a small subset of the VOS facilities are available in this interface, +and there are serious portability problems associated with the use of this +interface in applications programs (it is currently used only in highly +controlled systems applications, i.e., the CL). While IRAF does not currently +provide a Fortran interface to the VOS facilities, Fortran subroutines may +be freely called from SPP programs, allowing major portions of an applications +program to be coded in Fortran if desired. There are, however, serious +portability problems associated with the direct use of Fortran for applications +programs. +.PP +Only the SPP language adequately addresses the problem of providing full +functionality without compromising portability. This is because the SPP +language is an integral part of a carefully conceived, complete \fIprogramming +environment\fR, whereas C and Fortran are merely general purpose third +generation programming \fIlanguages\fR. Because it is specially designed +for large scientific programming applications, the SPP language and associated +programming environment will never see widespread usage like C and Fortran, +but for the same reasons it is ideally suited to our applications. +.SH +5.2 SPP Language Interface +.PP +The IRAF SPP (subset preprocessor) language is a general purpose programming +language modeled after C but implemented as a Fortran preprocessor. +Programming in SPP is conceptually very similar to programming in C; +the SPP language provides much the same basic facilities and syntax as C, +including pointers, structures, automatic storage allocation, \fBdefine\fR and +\fBinclude\fR, C style character data type, and Ratfor style versions of all +the usual control constructs. +The same problem will generally be solved the same +way in both languages. Since the SPP language resembles C but is translated +into Fortran, SPP combines the software engineering advantages of C with the +scientific programming advantages of Fortran. In addition, since SPP is an +integral part of the IRAF system, SPP provides language level support for +the VOS and for the IRAF programming environment in general. +.PP +The significance of the SPP language cannot be understood by studying only +the language itself as one would study C or Fortran. Rather, one must study +the programming environment and the role played by the SPP language in that +environment. The major components of the IRAF programming environment are the +SPP language, the VOS (\(sc6.1), the software tools, e.g., the \fBxc\fR +compiler, \fBmkpkg\fR, etc. (\(sc7.2), the applications libraries, e.g., +\fBxtools\fR, and the various math libraries, e.g., \fBcurfit\fR, \fBsurfit\fR, +\fBiminterp\fR, etc (\(sc5.6). +Considered as a whole, these components define a very rich +programming environment. Few systems provide a programming environment of +comparable capability, let alone in a machine and device independent format. +.PP +The chief problem facing a programmer trying to write their first applications +program in IRAF is learning the programming environment and "how things are +done" in IRAF. Learning the SPP language itself is generally a simple problem +dispensed with in hours or days, depending upon the individual. While most +people can be productively generating new programs within a few days, +weeks or months may be required to develop a deep understanding of and +fluency with the full environment. This is typical of any large software +system capable of supporting sophisticated applications programs, +and demonstrates that porting applications programs and applications +programmers between different programming environments is a myth. +In a sense, there are no (nontrivial) portable applications \fIprograms\fR, +only transportable programming \fIenvironments\fR. +.PP +Since a program is only as portable as the environment it is written for, +there are few portability advantages to programming large applications in a +standardized language (a case can however be made for purely numerical +routines). In fact the opposite is often the case, since few if any compilers +have ever been written which rigorously implement a language standard and +nothing more nor less. In the case of a language like Fortran, +it is not uncommon for half of the features offered by a particular +manufacturer's compiler to be nonstandard extensions to the formal language +standard, or even more dangerous, relaxations of subtle restrictions imposed +by the standard. It is difficult for a programmer to resist using such +extensions even when they know what the nonstandard extensions are, and usually +a programmer will be more concerned with getting the program functioning +as soon as possible than with making it portable. + +.KS +.PS +box wid 0.9 "SPP" "module"; arrow; ellipse width 1.1i "preprocessor" +arrow; box wid 0.9 "Host Fortran" "module" +line <- down at 1st ellipse.s +box "translation" "tables" +.PE +.ce +Figure 7. Preprocessor Dataflow +.KE +.PP +.PP +The SPP language solves this problem by providing all the features the +programmer needs directly in the language, so that the programmer +does not have to do without. If a new feature is needed and can be justified, +it can easily be added to the language since IRAF defines the SPP language +standard. Since the SPP translator is part of IRAF rather than part of the +host system, there is only one translator and the problem of writing code +which will be accepted by a variety of host compilers is greatly minimized. +The intermediate Fortran generated by the translator uses only the most +common features of Fortran, hence is intrinsically highly portable. +The intermediate Fortran is prettyprinted (indented to show the structure, +etc., so that a human can read it) and may optionally be saved and used for +symbolic debugging with the host system debugger. +.PP +Since a mechanical translator is used to generate the host Fortran when an +SPP program is compiled, nonstandard host Fortran extensions can be used +without compromising the portability of applications programs, by simply +modifying the host dependent tables used to drive the translation. +Since the SPP compiler is part of the IRAF environment rather than the +host environment, it understands IRAF virtual filenames, an essential +capability for referencing global include files. The \fBdefine-include\fR +facility itself is vital for parameterizing the characteristics of the +host machine and VOS configuration, as well as for structuring applications +software. Since the SPP language places an interface between IRAF +applications programs and the host Fortran compiler, our considerable and +ever growing investment in applications software is protected from future +changes in the Fortran standard. +.PP +As the name subset preprocessor implies, the SPP language implements a +subset of a planned future language. Most of the limitations of the +current SPP language are due to the use of preprocessor technology +to carry out the translation. A much more powerful approach is to use +a full syntax directed compiler with an associated code generator which +generates host Fortran statements rather than assembler instructions. +This will greatly improve compile time error checking, increase the +portability of both the applications software and the compiler, +and will make it possible to include certain advanced features in the +language for generalized image and vector processing. +This is an exciting area for future research, as compiler technology +makes possible the solution of a large class of image processing problems +which cannot readily be addressed any other way. +.PP +In summary, the IRAF SPP language interface provides a rich scientific +programming environment without compromising program portability. +Programmers using this environment can concentrate on the problem to be +solved without concern for the portability of the resultant software, +and are free to use all of the facilities provided by the language and the +environment. All of the facilities one needs for a particular application +are likely to either be already available somewhere in the environment, or +easily constructed using lower level facilities available in the environment, +and are guaranteed to be available in the same form on all IRAF host machines. +The proof of the concept of this interface is found in the current IRAF +system, where thousands of files in hundreds of directories are routinely +moved between quite different IRAF hosts, then compiled and run without +any changes whatsoever. +.SH +5.3 Host Fortran Interface +.PP +The host Fortran program interface (IMFORT) is in most respects the opposite +of the SPP/VOS programming environment. The IMFORT interface is a small +Fortran callable library which may be linked with host Fortran (or C) programs +to get the foreign task command line from the CL and perform some operation +upon an IRAF image or images. The host Fortran program may be declared as a +foreign task in the CL and accessed much as if it were a conventional IRAF +task, using the CL to parse, evaluate, and concatenate the command line to +be passed to the foreign task as a string. As a foreign task, the host +program may also be run outside the CL, using the host system command +interpreter, if desired. +.PP +The purpose of the IMFORT interface is to allow the existing Fortran programs +in use at a site when IRAF arrives to be modified for use within the IRAF +environment with minimal effort. The interface is also useful for the +scientist who needs to write a small program and does not want to take the +time to learn how to use the SPP/VOS environment. The IMFORT interface +consists of only a dozen or so routines hence almost no effort is required +to learn how to use the interface. Of course, the IMFORT interface does +not provide access to the extensive facilities of the SPP/VOS programming +environment, hence is not suitable for the development of large programs. +Programs written using the IMFORT interface are generally not portable +to other hosts, but this may not be a serious consideration to scientists +writing programs for their own personal use. +.SH +5.4 IRAF Fortran Interface +.PP +As noted earlier, IRAF does not currently have a Fortran applications +programming interface, other than the host Fortran program interface. +An IRAF Fortran programming environment would provide a subset of the +functionality provided by the SPP environment as a higher level library +of Fortran callable procedures. This differs from the host Fortran interface +in that the resultant programs would be fully integrated into IRAF, with +potential access to all SPP environment facilities, whereas the host Fortran +interface provides only limited imagefile access and the ability to fetch +the CL command line as a string, plus unrestricted access to host system +facilities. +.PP +We are considering adding such an interface for the scientist/programmer who +needs more than the IMFORT interface but is unwilling or unable to invest +the time required to learn to use the SPP environment. Unfortunately, +the lack of structures, pointers, dynamic memory allocation, +\fBdefine-include\fR, filename translation, etc. in ANSI standard Fortran +makes it prohibitively difficult to define a Fortran interface with capabilities +comparable to the SPP programming environment. Also, the resultant Fortran +programs would inevitably use the nonstandard features of the host Fortran +compiler and hence would not be portable. If such an interface were made +available and then used extensively, it seems likely that it would gradually +grow until it approximated the SPP environment in complexity, without the +advantage of the more elegant interface made possible by the SPP language. +.PP +If an embedded Fortran programming environment is ever added to IRAF it +therefore makes sense only if the environment is expressly designed with the +scientist/programmer in mind. The interface should provide all the necessary +facilities for small scientific programs but nothing more, and it should be +possible to become familiar with the use of the interface in a day or less. +Simplicity of use should be emphasized rather than efficiency. All large +applications projects and all "user qualified" software should continue to +be implemented in the SPP language and environment. +.SH +5.5 C Language Interface +.PP +The IRAF C language interface (library LIBC) consists of a fairly complete +UNIX STDIO emulation plus a C binding for a systems programming +subset of the IRAF VOS, comparable in capability to a V7 UNIX kernel. +All of the standard Berkeley UNIX STDIO facilities are provided, e.g., +the definitions in the include files \fI\fR and \fI\fR, +and functions such as \fIfopen\fR, \fIfread\fR, \fIfwrite\fR, \fIgetc\fR, +\fIputc\fR, \fIprintf\fR, \fIscanf\fR, \fImalloc\fR, and so on. +The STDIO procedures are implemented as an interface to the IRAF VOS, +hence calls to the VOS i/o procedures may be intermixed with calls to the +STDIO procedures, and the STDIO emulation is thus part of the portable system. +No UNIX sources are used hence a UNIX license is not required to use the +interface. Existing UNIX/C programs may be ported to the C language +environment with minor modifications (some modifications are always required), +assuming that the i/o requirements of the programs are modest. +.PP +The C language interface is currently used only to support the CL, which is +written in C primarily for historical reasons (the original CL was developed +concurrently with the VOS). The C language interface could in principle be +expanded to include more VOS facilities, but the sheer size of the VOS and +of the rest of the programming environment makes this impractical. +In any event, the SPP language is more suited to scientific programming, +avoids the portability problems of calling Fortran library procedures from C, +and will always be better integrated into the IRAF programming environment. +The use of the C language interface is not recommended except possibly for +porting existing large systems programs written in C to IRAF. +.SH +5.6 Applications Libraries +.PP +The standard applications libraries currently available in IRAF are summarized +in Figure 8. All libraries may be called from SPP programs. Only the purely +numerical Fortran libraries may be called from Fortran programs. +The sources for all libraries used in IRAF are included with the distributed +system and are in the public domain. In some cases the sources for the standard +numerical libraries have had to be modified slightly to eliminate calls to +the Fortran STOP, WRITE, etc. statements, sometimes used in error handlers. +Some major public domain math packages have yet to be installed in IRAF, e.g., +for nonlinear least squares and for evaluating special functions, for the +simple reason that we haven't needed them yet in our applications. + +.KS +.TS +center; +ci ci +l l. +library description + +bev Bevington routines (generally, these should be avoided) +curfit 1-D curve fitting package (SPP) +deboor DeBoor spline package +gks IRAF GKS emulator (subset of Fortran binding) +gsurfit Surface fitting on an irregular grid (SPP) +iminterp Image interpolation package, equispaced points (SPP) +llsq Lawson's and Hanson's linear least squares package +ncar NCAR graphics utilities, GKS version (uses GKS emulator) +nspp Old NCAR system plot package +surfit Surface fitting on a regular grid (SPP) +xtools General tools library for SPP applications programs +.TE +.ce +Figure 8. Applications Libraries (March 86) +.KE +.PP +The most heavily used numerical libraries in IRAF are those which were +written especially for IRAF (marked SPP in the figure). Our experience has +been that most of the generally available interpolation, curve and +surface fitting packages are overly general and inefficient for +use on bulk image data where the data points tend to be on an even grid, +or where the same X vector may be used to fit many Y vectors. +The SPP based math packages are nicely packaged, using dynamic memory +allocation to internally allocate a descriptor and all working storage, +and to hide the details of which of the possible algorithms supported by a +package is actually being used. +The supported interpolators include nearest neighbor, linear, +cubic spline, and third and fifth order divided differences. +The supported curve types include linear spline, cubic spline, +and the Chebyshev and Legendre orthogonal polynomials. +As far as possible the packages are vectorized +internally using the VOPS operators, to take advantage of the vector +processing hardware anticipated on future machines. + +.sp +.ce +\fB6. The Virtual Operating System (VOS)\fR +.SH +6.1 Major Components of the VOS +.PP +The primary functions of the VOS are to provide all the basic functionality +required by applications programs, and to isolate applications programs from +the host system. The VOS defines a complete programming environment suitable +both for general programming and for scientific programming in particular. +In addition to the standard facilities one expects from a conventional +operating system, e.g., file i/o, dynamic memory allocation, process control, +exception handling, network communications, etc., the VOS provides many +special facilities for scientific programming, e.g., a CL interface, +image i/o (access to bulk data arrays on disk), and a graphics subsystem +supporting both vector graphics and image display devices. The major +subsystems comprising the IRAF VOS are outlined in Figure 9. + +.KS +.TS +center; +l l. +CLIO command language i/o (get/put parameters to the CL) +DBIO database i/o (not yet implemented) +ETC exception handling, process control, symbol tables, etc. +FIO file i/o +FMTIO formatted i/o (encode/decode, print/scan) +GIO graphics i/o (both vector graphics and image display access) +IMIO image i/o (access to bulk data arrays on disk) +KI kernel interface (network communications) +LIBC UNIX stdio emulation, C binding for the VOS, used by the CL +MEMIO memory management, dynamic memory allocation +MTIO magtape i/o +OSB bit and byte primitives +TTY terminal control (\fItermcap\fR, \fIgraphcap\fR access) +VOPS vector operators (array processing) +.TE +.ce +Figure 9. Major Subsystems Comprising the IRAF VOS +.KE +.PP +Although the VOS packages are normally presented as independent packages, +there is naturally some vertical structure to the packages. The highest level +packages are GIO and IMIO, which depend upon many of the lower level i/o +packages. The most fundamental packages are FIO and MEMIO, which are used +by everything which does i/o. At the bottom are the KI (the kernel interface) +and the kernel itself, which is part of the host system interface (\(sc7.3). +All of the VOS code is portable with the exception of certain GIO graphics +device kernels, hence the VOS is functionally equivalent on all IRAF hosts. +.PP +Most of the capabilities provided by the VOS are already present in existing +commercial operating systems or in commercial or public domain libraries +available for such systems. It is certainly possible to assemble a functional +reduction and analysis system by starting with the facilities provided by a +particular host OS, obtaining a few libraries, and building the rest of the +software locally. This is the approach most organizations have followed, and +it certainly would have been a lot easier (and less controversial) for us to +do the same rather than construct an entire virtual operating system as we did. +.PP +The chief problem with the off-the-shelf approach is of course that the +resulting programming environment is unlikely to be very portable and would very +likely be incomplete, forcing applications software to bypass the environment +and use host facilities to get the job done. Furthermore, it is hard to +produce a consistent, efficient, well engineered \fIsystem\fR by patching +together independently developed subsystems, even if the individual subsystems +are very good considered all by themselves (and often they are not, nor are they +often in the public domain). These problems typically scale as some large power +of the size of the system being developed. The off-the-shelf approach shows +results sooner, but in the long run it costs far more, particularly if the +planned system is large and has to be maintained in numerous configurations +on numerous host machines. +.PP +The approach we have adopted results in a better system which is easier to +port initially to a new machine (because the host interface is small, well +isolated, and well defined), and which is much easier to support once the +initial port has been carried out. The VOS subsystems are often quite large +and are expensive to develop, but they do exactly what we want, fit into the +system just right, and once they have been developed they become a permanent +fixture in the environment requiring little or no maintenance, freeing our +limited resources for interesting new projects. +.SH +6.2 The File I/O (FIO) Subsystem +.PP +At the heart of the VOS i/o subsystem is \fBFIO\fR, the file i/o interface. +FIO makes a distinction between two broad classes of file types, text +files and binary files. The type of a file must be specified at open +time, but once a file has been opened file i/o is device independent. +FIO supports a wide range of \fBstandard devices\fR, e.g., disk resident +text and binary files, terminals, magtapes, line printers, IPC (interprocess +communications channels), static files (can be preallocated and mapped into +virtual memory), network communications channels, the pseudofiles +(see below), and text and binary memory-buffer files. Device drivers for +\fBspecial devices\fR may be dynamically loaded at run time by applications +programs, hence the FIO interface (and all programs which use FIO) may be +used to access any physical or abstract device. For example, an applications +program may interface an image display device as a binary file and then +use IMIO to access the display. +.PP +\fBText files\fR are stored on disk in the host system text file format, +e.g., in a format acceptable to host system text file utilities such as +an editor or file lister. Reading or writing a text file implies an +automatic conversion between the IRAF internal format and the host system +format. The internal format is a stream of ASCII characters with linefeed +characters delimiting each line of text (as in UNIX). The text file +abstraction is required in a portable system to be able to use the host +utilities on text files generated by the portable system, and vice versa. +.PP +\fBBinary files\fR are unstructured byte stream arrays; data is written to and +read from a binary file without any form of conversion. There are two +subclasses of binary files, the \fBstreaming\fR binary files, and the +\fBrandom access\fR binary files. The streaming files can only be read and +written sequentially; examples are IPC and magtape. Random access binary +devices are assumed to have a fixed device block size which may differ for +each device. A binary device is characterized by device dependent block size, +optimum transfer size, and maximum transfer size parameters read dynamically +from the device driver when a file is opened on the device. By default FIO +configures its internal buffers automatically based on the device parameters, +but the buffer size for a file may be overridden by the user program if +desired. +.PP +FIO supports a special builtin type of file called the \fBpseudofile\fR, +a binary streaming file. The pseudofile streams are opened automatically +by the system when a task is run. The pseudofile streams of interest to +applications programs are STDIN, STDOUT, and STDERR (the standard input, +output, and error output streams), and STDGRAPH, STDIMAGE, and STDPLOT +(the standard vector graphics, image display, and plotter streams). +These streams are normally connected to the terminal, to a graphics device, +or to a file by the CL when a task is run. The user may redirect any of +these streams on the command line. Pseudofile i/o is multiplexed via IPC +to the CL process whence it is directed to the physical device, graphics +subkernel, or file connected at task initiation time. Graphics frames +output to STDGRAPH are spooled in a buffer in the CL process so that the user +may later interact with the graphics output in \fIcursor mode\fR (\(sc6.6). +.PP +The top level FIO procedures are stream oriented. The FIO \fBuser interface\fR +is a simple open-close, getc-putc, getline-putline, read-write-seek, etc. +interface which is quite easy to use. +Character data may be accessed a character at a time or a line at a time; +terminal i/o is normally a line at a time but a \fBraw mode\fR is provided +as an option (this is used for keystroke driven programs such +as screen editors). Binary data may be read and written in chunks of any +size at any position in a file. On random access devices a seek call is +required to position within the file. FIO handles record blocking and +deblocking, read ahead and write behind, etc., transparently to the +applications program. An asynchronous, unbuffered, block oriented, direct +to user memory interface is also provided for applications with unusual +performance requirements (for binary files only). +.SH +6.3 FMTIO, MEMIO, TTY, VOPS, ETC +.PP +The \fBformatted i/o\fR interface (FMTIO) is concerned with formatting output +text and decoding input text. The primary high level stream oriented procedures +\fIscan\fR, \fIfscan\fR, \fIprintf\fR, \fIfprintf\fR, \fIsprintf\fR, etc., +are modeled after the UNIX facilities for which they are named. +A set of low level string oriented procedures provide a variety of numeric +encode/decode functions, a set of general string operator functions, +some lexical analysis functions, and a general algebraic expression evaluation +function. The FMTIO numeric conversion routines fully support indefinite +valued numbers (INDEF). +.PP +The \fBmemory i/o\fR interface (MEMIO) provides a dynamic memory allocation +facility which is heavily used throughout the IRAF system. Both \fBheap\fR +and \fBstack\fR facilities are provided. The high level heap +management procedures \fImalloc, calloc, realloc\fR, and \fImfree\fR are modeled +after the comparable UNIX procedures, although there are some minor differences. +An additional procedure \fIvmalloc\fR is provided to allocate buffers aligned +on virtual memory page boundaries. A pair of procedures \fIbegmem\fR and +\fIfixmem\fR are provided to dynamically adjust the working set size at +runtime, or to simply query the amount of available physical memory if the +working set cannot be adjusted. This is used to dynamically tune large-memory +algorithms to avoid thrashing. The stack procedures are used mainly to +simulate automatic storage allocation, with the advantage that the amount +of space to be allocated is a runtime rather than compile time variable. +MEMIO relies heavily upon the pointer facility provided by the SPP language. +.PP +The terminal capabilities database interface (TTY) provides a basic +screen management capability for terminals. The TTY interface uses the +Berkeley UNIX \fBtermcap\fR terminal database, which supports dozens of +terminals and which is easily extended by the user. The database capabilities +of the TTY interface are also used for the line printer interface and for +the IRAF \fBgraphcap\fR database, used to store device dependent information +describing the various graphics terminals, image displays, and plotters +supported by IRAF. +.PP +The \fBvector operators\fR interface (VOPS) is a large library of subroutines, +each of which performs some simple operation on one or more one dimensional +arrays. Operators provided include the arithmetic operators, sqrt, power, +abs, min, max, reciprocal, the trig functions, a full matrix of type conversion +operators, fill array, clear array, memory to memory copy, a set of boolean +operators, sort, statistical functions (median, average, etc.), rejection mean, +weighted sum, lookup table operations, vector interpolation, inner product, +vector sum, sum of squares, various linear transformations, convolution, +fourier transform operators, and so on. The VOPS operators are written in +a generic dialect of the SPP language and are expanded into a full set of +type specific operators by the \fBgeneric preprocessor\fR before compilation +and insertion into the VOPS library. A full range of datatypes is supported +for each operator, including type complex where appropriate. +.PP +Using the conditional compilation facilities provided by \fImkpkg\fR, selected +VOPS operators may be hand optimized in assembler or host specific Fortran +(e.g., using Fortran vector extensions on vector machines) without +compromising the portability of the system. +Similarly, selected VOPS operators might be +implemented in an array processor on a host which has one; ideally the array +processor should be tightly coupled to the cpu for this to be worthwhile +(a shared memory interface using MEMIO support is possible). The VOPS +operators are used heavily throughout IRAF with the expectation that +\fBvector machines\fR will become increasingly common in the future. +.PP +The ETC package is the catch-all for those VOS facilities too small +to warrant full fledged package status. Major ETC subpackages include the +\fBprocess control\fR facilities, used to spawn and control connected +subprocesses and detached processes, the \fBexception handling\fR facilities, +used to trap interrupts, post signal handlers, etc., and the \fBenvironment\fR +(logical name) facility. ETC also contains the \fBdate and time\fR facilities, +the \fBdevice allocation\fR facilities, a general purpose \fBsymbol table\fR +facility, and a number of other subpackages and miscellaneous system procedures. +IRAF relies upon the environment facilities to map virtual filenames to host +filenames and to assign logical names to physical devices. The VOS +automatically propagates the environment and current default directory to +connected subprocesses. +.SH +6.4 The Command Language I/O (CLIO) Subsystem +.PP +The CL is almost completely invisible to the applications program. The CLIO +interface consists of little more than a set of get/put procedures for CL +parameter i/o. Parameters may be accessed either by name or by the offset +of the parameter in the command line. A task may query the number of +positional parameters on the command line, or whether a particular pseudofile +stream has been redirected on the command line. +.PP +The CLIO interface is very simple at the applications level; all of the +complexity and power of the interface is hidden behind the CLIO interface +in the CL itself. +Parameter requests may be satisfied either directly by the applications +process, i.e., when it is run outside the CL, or by the CL at task invocation +time or while the task is executing. The CL (i.e., the user) determines how +a parameter request is satisfied transparently to the applications program. +Some parameter requests result in interactive queries, +others are satisfied immediately without a query. If a task repeatedly +requests the same CL parameter, a different value may be returned for each +request, allowing tasks to be used interactively. By assigning a text file +containing a list of values to such a parameter, the user may run such tasks +in batch mode. The graphics and image display cursors are implemented as +CL parameters, and cursor input may be either interactive (causing cursor +mode to be entered) or batch (input is taken from a text file assigned to the +cursor type parameter by the user). +.SH +6.5 The Image I/O (IMIO) Subsystem +.PP +The IMIO interface is used to access bulk data arrays or \fIimages\fR +(rasters, pictures) normally stored in random access binary files on disk. +An \fBimage\fR consists of an N-dimensional array of \fBpixels\fR and an +associated \fBimage header\fR describing the physical and derived attributes +of the image. Arbitrary user or applications defined attributes may be +stored in the image header. The present interface supports images with +from zero to seven axes. There are no builtin limits on the size of an +image since all data buffers are dynamically allocated. The datatype of +the pixels in an image may be any SPP datatype, i.e., \fIshort\fR (signed +16 bit integer), \fIlong\fR, \fIreal, double\fR, or \fIcomplex\fR, or the +special disk only datatype \fIushort\fR (unsigned 16 bit integer). +.PP +IMIO is primarily a conventional binary file i/o type of interface. While it is +possible to map all or portions of an image into \fBvirtual memory\fR if the +host system supports such a facility and if a number of runtime conditions +are met, all current IRAF applications use only the conventional binary file +i/o access method. +This is necessary for full portability (a true virtual memory machine is not +required to run IRAF) and furthermore is the most flexible and +efficient type of access for the majority of our image processing applications. +While there are some difficult image analysis applications which benefit +significantly from the use of virtual memory, most applications access the +entire image sequentially and can easily be programmed using binary file i/o. +Sequential whole image operators are most efficiently implemented using binary +FIO; the heavy page faulting resulting from sequential image access via a +virtual memory interface places a greater load on the system. +More importantly, the price of using virtual memory is the loss of +\fIdata independence\fR, which greatly limits the flexibility of the interface. +.PP +While IMIO imposes certain restrictions upon the logical representation of +an image as seen by an applications program, there are few restrictions on +the physical storage format, and indeed IMIO is capable of supporting multiple +disk data formats, including site dependent formats if desired. The primary +restriction on the physical storage format is that images are assumed to be +stored in a noninterleaved \fBline storage mode\fR, i.e., like a Fortran array, +although the image lines may be aligned on device block boundaries if desired. +While no other storage modes are supported by the current interface, we hope +to add support for band interleaved, binary nested block (BNB), etc. storage +modes in the future. An efficient implementation of the BNB storage format +which preserves data independence will probably require language support. +.PP +The IMIO \fBuser interface\fR consists primarily of a set of procedures to +get/put image lines and subrasters. The high level IMIO routines are written +in generic SPP and a version of each i/o procedure is available for each +SPP datatype, allowing programs to be written to deal with any single datatype +or with multiple datatypes. The IMIO interface will automatically coerce the +datatype of the pixels when i/o occurs, if the type requested by the +applications program does not match that on disk. +.PP +Much of the flexibility and efficiency inherent in the IMIO interface derives +from the fact that pixel data is buffered internally in IMIO, returning a +\fIpointer\fR to the buffered line or subraster to the user, rather than +copying the data to and from the user buffer. This makes it possible for +IMIO to return a pointer directly into the FIO buffer if all the right +conditions are met, avoiding a memory to memory copy for the most efficient +possible i/o. Leaving the buffer management to IMIO also makes the interface +easier to use. +.PP +IMIO provides a number of optional features which make certain common +types of image applications easier to code. The number of input line buffers +may be set by the user to some value greater than one, allowing the use +of a \fBscrolling region\fR for filtering applications. A program may +optionally reference beyond the boundary of an image, with IMIO using the +specified \fBboundary extension\fR technique (nearest neighbor, constant value, +reflect, wrap around, etc.) to generate values for the out of bounds pixels. +This is useful for convolution or subraster extraction applications to avoid +having to deal with the boundary region as a special case. +.PP +Perhaps the most novel, most popular, and most useful feature of IMIO is the +built in \fBimage section\fR capability. Whenever the user enters the name of +an image they may optionally append an image section to specify the subset +of pixels in the image to be operated upon. For example, if image \fLpix\fR is +a 512 square, 2-dimensional image, then \fLpix[*,-*]\fR is the same image +flipped in Y, \fLpix[*,55]\fR is a one dimensional image consisting of line 55 +of the image, \fLpix[19:10,50:69:2]\fR is a 10 by 10 subraster obtained by +flipping in X and subsampling by 2 in Y, and so on. +If \fLcube\fR is a three dimensional image, \fLcube[*,*,5]\fR is band 5 of +the image cube (a two dimensional subimage), \fLcube[*,5,*]\fR is the XZ plane +at Y=5, and so on. The image section is processed by IMIO when the image is +opened, transparently to the applications program, which sees what appears +to be a smaller image, or an image of lesser dimensionality than the original. +The image section facility is automatically available for \fIany\fR program +that uses IMIO, and is only possible by virtue of the data independence +provided by the interface. +.SH +6.6 The Graphics I/O (GIO) Subsystem +.PP +For many scientific applications programs, fast interactive graphics is the key +to a good user interface. High quality graphics hardcopy is likewise essential +for presenting the final results of data analysis programs. These requirements +are the same both for vector graphics applications and for image processing +applications, and ideally the same interface should serve both types of +applications. Not everyone has ready access to an image display, so it should +be possible to run software intended for use with an image display device on +a graphics terminal. Likewise, it should be possible to overlay vector +graphics on an image display, even if the graphics program was intended for +use on a graphics terminal. While an interactive cursor driven graphics +interface is desirable for interactive reductions, one should not be forced +to use a program interactively, hence the graphics system should allow any +cursor driven graphics program to be used noninteractively as well. +Lastly, since a great variety of graphics and image display devices are in +use and more are being developed every day, the graphics system must make it +as easy as possible to interface to new devices and to support multiple +devices. +.PP +These were the primary performance requirements which the IRAF graphics i/o +subsystem (GIO) was designed to meet. GIO provides a uniform, device +independent interface for graphics terminals, graphics workstations, raster +and pen plotters, laser printers, and image display and image hardcopy devices. +GIO is one of the largest subsystems in IRAF, and is unlike most of the IRAF +interfaces in that it is not completely self contained, but rather is designed +to make use of existing non-IRAF graphics packages such as GKS, CORE, NCAR, +and so on. Nonetheless, GIO does provide all of the software necessary to +meet its primary requirement of providing fast interactive graphics for IRAF +applications normally run on a graphics terminal. GIO can be interfaced to +virtually any graphics terminal without modifying or writing any software, +and without relinking any executables. +.DS +.PS 8 +AP: box wid 0.9i "applications" "program" +NCAR: ellipse "NCAR" at AP.e + (1.0i,0.5i) + arrow right +GK1: ellipse "GKS" "emulator" + +GIO: box "GIO" at AP.e + (3.6i,0) + spline -> right .2i from AP.e + (0,0.1i) then to NCAR.w - (.2,0)\ + then to NCAR.w + spline -> right .2i from GK1.e then to GIO.w + (-.2,0.1i) \ + then to GIO.w + (0,0.1i) + line -> right at AP.e to GIO.w "(graphics output)" above + +GK2: ellipse "GKS" "emulator" at AP.e + (1.6i,-0.5i) + spline -> right .2i from AP.e - (0,0.1i) then to GK2.w - (.2,0) \ + then to GK2.w + spline -> right .2i at GK2.e then to GIO.w - (.2,0.1i) \ + then to GIO.w - (0,0.1i) + + line -> right 0.8i at GIO.e "GKI" "metacode" +CM: box dashed "cursor" "mode" + line <-> +GK: box "graphics" "kernel" + line <-> + box "graphics" "device" + +CLIO: box "CLIO" at GIO.n + (0,1.0i) + spline <- right .2i at CLIO.e - (0,0.1i) then to CM.n + (0,.2)\ + then to CM.n + line <- right at CLIO.e + (0,0.1i); ellipse dashed "cursor" "listfile" + spline <- up .4i at AP.n to AP.n + (.5,.6) then to CLIO.w - (.2i,0)\ + then to CLIO.w + "(cursor input)" at CLIO.w - (2.0,0) + + "(applications process)" at GIO - (2,1.1) + "|" at GIO + (0.8,-1.1) + "(CL)" at CM + (0,-1.1) + "|" at CM + (0.65,-1.1) + "(CL or subkernel)" at GK + (0.5,-1.1) +.PE +.sp +.ce +Figure 10. GIO Dataflow +.DE +.PP +The major components of the GIO subsystem and the flow of data between them +(graphics output and cursor input) are shown in Figure 10. A different, +somewhat simplified view emphasizing the process structure is given in Figure 2. +The first thing to note is that normally only a portion of the graphics system +is linked into an applications program. This reduces the size of applications +programs, makes it possible to add support for new graphics devices without +relinking the system, increases concurrency on single user systems, reduces +physical memory requirements on multiuser systems (since multiple users can +share the memory used by the graphics kernel process), reduces startup time +(since the same kernel process can be used by many tasks), and reduces the +need to worry about memory utilization in the graphics kernels, since the +kernel has an entire process to itself. +.PP +Applications programs normally contain only the device independent, output +oriented part of the graphics system. This includes any high level graphics +packages such as the NCAR utilities and the GKS emulator, the GIO axis drawing +and labelling code, and that part of GIO which transforms vectors input in +world coordinates into clipped NDC (normalized device) coordinates. +The graphics output of an applications program consists of GKI metacode, +a device and machine independent stream of 16 bit signed integer graphics +instruction opcodes and data. +.PP +The GKI opcodes, as well as the lowest level GIO interface procedures available +to the programmer, resemble the graphics primitives of the GKS standard, i.e., +polyline, polymarker, polytext, fill area, cell array, and so on. +The GIO \fBprogrammer interface\fR includes several layers of higher level +calls based on these primitives, providing everything likely to be needed by +applications software, e.g., autoscaling routines, coordinate transformations, +multiple world coordinate systems including optional log scaling in either axis, +both relative and absolute drawing commands (these build up polylines +internally), mark drawing routines, vector plotting routines, +the standard axis drawing and labelling routines, and so on. +.PP +The primary component of the GIO \fBuser interface\fR is the \fBcursor mode\fR +facility. The graphics system makes a clear distinction between graphics +output and cursor input. Often the task which reads the graphics cursor +is different than that used to generate the graphics output. When a graphics +frame is output, the world coordinate systems (WCS) associated with the frame +and all or part of the frame itself (a stream of GKI metacode instructions +beginning with a screen clear) is saved in a cursor mode \fIframe buffer\fR +in the CL process. +.PP +Sometime later the cursor position may be read by the task which generated +the frame, by a different task, or by the user by typing a command into the CL. +This causes cursor mode to be entered; cursor mode is terminated when the +user types a lower case or nonalphanumeric key on the terminal. +The cursor position is returned encoded as a string consisting of the fields +X, Y, WCS number, key typed, and an optional character string entered by the +user. While in cursor mode the user may zoom and pan the buffered frame, +repaint the screen, print the cursor position in world coordinates, draw axes +around the current window into the buffered frame, annotate the frame, +save the frame in a metacode file or reload the frame from such a file, +take a "snapshot" of the frame on a plotter device, and so on. Cursor mode +reserves the upper case keystrokes for itself, leaving the lower case +keystrokes and most of the nonalphanumeric characters for the applications +program. +.PP +The GKI metacode output by an applications program is normally transmitted +via IPC or the network interface to the CL process and then on to a graphics +kernel, which may be linked directly into the CL process or which may reside +in a subkernel, i.e., in a CL subprocess connected upon demand by the +pseudofile i/o system. GKI metacode may also be spooled in +a file by specifying the graphics output device \fBvdm\fR (virtual device +metafile), by redirection of the graphics stream on the command line, +or by running the applications process outside the CL with the graphics +stream redirected into a file. A variety of utilities are provided for +operations upon metacode files, e.g., for decoding the GKI instructions in +a metacode file (useful for debugging), for extracting frames from a metacode +file, for printing a directory of the frames in a metacode file, for generating +a new metacode file wherein each frame contains a mosaic of N of the frames +in the input metacode file, and so on. Spooled metacode may be used as input +to any graphics kernel to make plots on any device supported by that kernel. +.PP +All of the pieces of the graphics subsystem thus far discussed have been +device independent. The device dependent part of the graphics system is +the GIO \fBgraphics kernel\fR. The function of a graphics kernel is to +convert a stream of GKI metacode instructions into device instructions to +control the device or to perform i/o to the device. Since all WCS to NDC +coordinate transformations and clipping are handled by the device (and kernel) +independent GIO software, the graphics kernel sees only integer NDC +coordinates in the range 0 to 32767. The graphics kernel is an independent +module in the system, and GIO may support any number of distinct graphics +kernels. A GIO kernel may be a direct interface to a particular device, +or an interface to an external graphics library which may support any number +of physical or logical devices. +.PP +The IRAF system includes one graphics kernel which is completely portable and +hence available on any system. The STDGRAPH (standard vector graphics) kernel +is used for interactive graphics on the user's graphics terminal. To provide +the fastest possible response for interactive applications, the STDGRAPH kernel +is linked directly into the CL process. The STDGRAPH kernel is capable of i/o +to virtually any graphics terminal which has a serial interface. +A \fBgraphcap\fR entry for the device must be provided to tell the STDGRAPH +kernel the characteristics of the device, e.g., how to encode a pen motion +command, the resolution of the device, how to plot text, the number of +hardware text fonts available, and so on. Tektronix compatible terminals are +the most common, but the graphcap facility is general enough to describe most +other terminals as well (in fact, the more smarts the terminal has the better). +A graphcap entry is a runtime table typically consisting of less than a dozen +lines of text; new entries can easily be added by the user. +.PP +A GIO kernel is implemented as a \fIlibrary\fR, consisting of a pair of +open-kernel and close-kernel subroutines, plus one subroutine for each GKI +instruction. The GKI interface (graphics kernel interface) may be used to +call the kernel subroutines either directly, i.e., if the kernel is linked +into the same process as the program using GIO, or indirectly via a GKI +metacode data stream transmitted via pseudofile i/o if the kernel resides +in a different process. All GIO kernels are also installed in the system +linked into compiled IRAF tasks callable either as \fBsubkernels\fR by the +pseudofile i/o system, or by the user as a conventional CL task. When called +as a subkernel the GIO kernel reads metacode from a pseudofile stream; +when called as a CL task the kernel reads metacode from a file. +.PP +The IRAF system currently (March 86) provides kernels for the old NCAR system +plot package, for the Calcomp graphics library, and for the SUN-3 +implementation of the proposed CGI standard. Eventually, GIO kernels should be +available for GKS, CORE, and possibly other standard graphics libraries as well. +If a kernel is not already available for the host system and graphics devices +used at a particular site, it should not be difficult to generate a new +kernel by modifying one of the existing ones. Often it should only be +necessary to relink one of the GIO kernels supplied with the system with the +local GKS, Calcomp, etc. library to get a functional kernel. As a last resort, +a new GIO kernel can be built to talk directly to a specific physical device. +.PP +The current GIO subsystem supports vector graphics and batch plotter devices +quite well, but has not yet been used extensively for \fBimaging devices\fR +because there is no standard graphics interface for these devices. +A standard set of Fortran callable subroutines for interfacing to imaging +devices is currently being defined by an international consortium of +astronomical centers. Our intention is to build a GIO kernel which uses this +device independent image interface as soon as the interface definition is +complete. Implementations of the interface subroutines for the half a +dozen or so types of image displays used at NOAO are also planned. Once the +image display interface subroutines are defined and a GIO kernel which uses +them is in place, users will be able to interface new image devices to IRAF +by implementing the standard subroutines, relinking a few executables, +and adding a graphcap entry for each new device. +.PP +For more detailed information on the design of the GIO subsystem, including +specifications for the interface subroutines, for the graphcap facility, +and so on, the reader is referred to the document \fIGraphics I/O Design\fR +(March 85), which is available from the author. +.SH +6.7 The Database I/O (DBIO) Subsystem +.PP +The DBIO subsystem is the only subsystem in the original VOS design remaining +to be implemented. DBIO will be used for image header storage, for intermodule +communication in large packages, and for the storage of large catalogs such as +those produced by analysis programs as well as existing astronomical catalogs. +DBIO will be essentially a record manager type interface. The related CL +package DBMS will provide a relational database interface to catalogs and +other data maintained under DBIO. The planned database subsystem is a major +facility comparable in size and complexity to the existing graphics subsystem. +The reader is referred to the document +\fIDesign of the IRAF Database Subsystem\fR (draft, October 85) for additional +information on DBIO and DBMS, including a discussion of some of the potential +applications of database technology to astronomy. +.SH +6.8 Networking Facilities +.PP +The portable IRAF system includes support for network access to any physical +resource resident on a remote node, including disk binary and text files, +magtape devices, terminals, image displays, printer/plotters, and even +subprocesses and batch queues. Since this facility is provided by the portable +IRAF system the network nodes do not have to run the same operating system. +It is permissible for the nodes to be architecturally incompatible computers, +provided the higher level IRAF systems or applications software maintains data +externally in a machine independent format. +.PP +The broad scope of the IRAF networking facilities is made possible by the +fact that all access to host system resources in IRAF has to go through the +IRAF kernel, a part of the host system interface (\(sc7.3). The IRAF +networking capability is provided by a VOS package called the +\fBkernel interface\fR (KI). The KI is a sysgen option in IRAF and is not +required to run the system on a single node. The relation of the KI to the +rest of the VOS and to the IRAF kernel is illustrated in Figure 11. +.DS +.PS + down + box "VOS" + line <-> +KI1: box "KI" + line <-> + box "local" "kernel" + +KI2: box dashed "kernel" "server" at KI1.e + (2,0) + line <-> down + box dashed "remote" "kernel" + + line <-> from KI1.e to KI2.w "network" "channel" + line -> right from KI2.e + " (etc)" ljust +.PE +.sp +.ce +Figure 11. The Kernel Interface +.DE +.PP +In an IRAF system configured without networking, the VOS code directly calls the +procedures forming the IRAF kernel for the local node. In a system configured +with networking, the VOS code calls instead KI procedures which are functionally +equivalent to the regular kernel procedures. If the kernel resource resides on +the local node the KI procedure merely calls the corresponding kernel procedure +on the local node, hence the KI adds a fixed overhead of one procedure call +when it is present in a system but not used to access remote nodes. +If the kernel resource resides on a remote node, the KI encodes the procedure +call in a machine independent format and passes it to a \fBkernel server\fR +on the remote node via a data stream network interface, returning any output +arguments to the local VOS via the same interface. +.PP +A remote resource is referenced by prefixing the resource name with the node +name and an exclamation character, i.e., \fInode!resource\fR. For example, +the command "\fLpage lyra!dev$graphcap\fR" might be entered to page the +\fLgraphcap\fR file on node \fLlyra\fR. Logical node names may be defined to +avoid introducing site dependent information into resource +names in portable code. When the first reference to a resource on a remote +node is received the KI "connects" the remote node, i.e., it spawns a kernel +server process on the remote node. The kernel server remains connected until +the client process on the local node terminates, or until an i/o error occurs +on the KI channel. In the current implementation of the KI, each client process +on the local node requires a dedicated kernel server process on the remote node. +A future implementation of the KI may permit a single server process to serve +an entire process tree on the local node. +.PP +The beauty of the kernel interface is that since it intercepts all kernel +requests it automatically provides such exotic network services as the ability +to interactively access a remote graphics device, or to spawn and interactively +run a subprocess on the remote node, without requiring any changes to the VOS +or to applications software. Furthermore, implementation of the KI required +no changes to the IRAF kernel (which is unaware that the KI exists), and the +KI software itself is portable, as is the kernel server task. The only machine +dependent software required is a FIO binary file driver capable of "opening" +a "file" (spawning a kernel server process) on a remote node, and providing +bidirectional binary communications with the remote server. +.PP +The network interface is currently in regular use at NOAO for remote image +display, plotter, and file access between VAX nodes running both UNIX and VMS, +using a TCP/IP network interface and Ethernet hardware. For example, a user +on node A might make a line plot of an image resident on node B, enter cursor +mode, and use the "snapshot" facility to dump the plot to a laser printer +on node C. We have not yet made use of the remote process and batch queue +capabilities. A DECNET interface also exists and will soon be tested in a +MicroVax to mainframe configuration. + +.sp +.ce +\fB7. The Host System Interface (HSI) +.SH +7.1 Major Components of the Host System Interface +.PP +The host system interface (HSI) is the interface between the portable +IRAF system and a particular host operating system. While the HSI contains +all of the machine dependent or potentially machine dependent code in IRAF, +much of the code in the HSI is actually fairly portable. To port IRAF to +a new operating system one must implement the HSI. Once the HSI has been +implemented for a new OS, the entire VOS and all of the IRAF system packages +and NOAO science packages will in principle compile and run without modification +(in reality, some testing and bug fixes are always required). Note that once +IRAF has been \fIported\fR to a new host OS, i.e., once the HSI has been +implemented for a particular host OS, one must still configure the site and +device dependent tables for a particular host to \fIinstall\fR IRAF on that +host. +.PP +The HSI currently consists of the following components. The IRAF \fBkernel\fR +is a subroutine library containing all the host dependent primitive functions +required by the VOS, and is usually the most machine dependent part of the HSI, +and the major item to be implemented in a port. The \fBbootstrap utilities\fR +are a set of utility programs required to compile and maintain the main IRAF +system; these are written in C and are mostly portable (they use the kernel +facilities when possible). The \fBhlib\fR library is a directory containing +a number of host and site dependent compile and run time tables used to +parameterize the characteristics of the host system. The \fBas\fR directory +contains the source for any library modules which have been written in +assembler for one reason or another; while IRAF currently requires only one +assembler module, any library module may be hand optimized in assembler if +desired, without compromising the portability of the system. Lastly, the +\fBgdev\fR directories contain the host dependent i/o interfaces for any +binary graphics devices supported by otherwise machine independent GIO kernels. +Often it is possible to write a portable (but device dependent) GIO kernel if +the i/o functions are factored out into a separate interface. +.SH +7.2 The Bootstrap Utilities Package +.PP +The bootstrap utilities are required to compile and maintain the rest of the +IRAF system. Since the bootstrap utilities must run before IRAF does, they +are implemented as \fIforeign tasks\fR callable either from the host system +or from the CL. Since the bootstrap utilities are required to compile and +maintain the VOS as well as the rest of the portable system, they do not +use the VOS facilities. Rather, they use a special \fIbootlib\fR library +which requires some direct access to host facilities but which mostly uses +the kernel facilities. + +.DS +.TS +center; +l l. +generic The generic preprocessor +mkpkg The "make package" library and package maintenance tool +rmbin Removes binary files in a directory tree +rmfiles Removes classes of files in a directory tree +rtar Reads TAR format tape or disk files +spp The XC compiler for the SPP language +wtar Writes TAR format tape or disk files +xyacc YACC compiler-compiler for SPP (requires UNIX license) +.TE +.sp +.ce +Figure 12. The Bootstrap Utilities +.DE +.PP +The bootstrap utilities are summarized in figure 12. The major utilities +are the \fImkpkg\fR program and the \fIxc\fR compiler; both of these are +required to compile and maintain the portable IRAF system. The \fIrmbin\fR +and \fIrmfiles\fR utilities are used to strip all binaries from the system +prior to a full sysgen, or to strip all sources from a runtime system to +save disk space. The \fItar\fR format reader/writer programs are used to +transport directory trees between IRAF systems running on different host +operating systems. For example, one might use \fIwtar\fR to make a source only +archive of a package in a disk file on a UNIX node, push the file through +the network to a VMS node, unpack the archive with \fIrtar\fR, and compile +and link the new package with \fImkpkg\fR, all without any knowledge of +the contents of the package and without editing any files (we do this all +the time). The \fIxyacc\fR utility is used to make SPP parsers. This utility +is not needed other than on our software development machine, since the output +of the utility is an SPP module which can be compiled and used on any IRAF host. +.SH +7.3 The IRAF Kernel +.PP +The IRAF kernel (also known as the OS package) is a library of fifty or so +files containing a number of Fortran callable subroutines. The kernel +procedures may be written in any language provided they are Fortran callable; +all current IRAF kernels are written in C. As far as possible, IRAF is designed +to implement all complex functions in the VOS, making the kernel as simple +as possible and therefore easier to implement for a new host. +The kernel is a well defined, well isolated interface which can be implemented +according to specifications without any knowledge of the rest of the system. +The current 4.2BSD UNIX/IRAF kernel contains 5900 lines of C code (something +like three percent of the full system), half of which is probably in the +various FIO device drivers. The IRAF kernel is discussed in detail in the +document \fIA Reference Manual for the IRAF System Interface\fR (May 84). + +.sp +.ce +\fBConclusions\fR +.PP +The IRAF system provides a large and steadily growing capability for the +reduction and analysis of astronomical data, as well as a general purpose +image processing and graphics capability useful for image data of any type. +The system itself is nonproprietary and no proprietary external libraries +are required to run IRAF. IRAF is a machine and device independent system, +hence is easily ported to many current machines as well as to future machines. +IRAF provides a complete modern programming environment suitable for general +software development and for scientific software development in particular. +.PP +IRAF has been designed from the beginning with the capabilities +of the next generation of computers in mind, hence the system is designed +to make use of the vector hardware, networking facilities, bit-mapped graphics +displays, large memories, and personal workstations expected to become +increasingly available during the next decade. The system has been designed +and implemented to a consistently high standard, and the combination of a +modern design and many advanced capabilities, plus a high degree of efficiency, +portability and device independence insure that the system will continue to +grow in capability and use in the years to come. + +.sp +.ce +\fBAcknowledgments\fR +.PP +The author wishes to acknowledge the efforts of the many people who have +contributed so much time, energy, thought and support to the development +of the IRAF system. Foremost among these are the members of the IRAF +development group at NOAO (Lindsey Davis, Suzanne Hammond, George Jacoby, +Dyer Lytle, Steve Rooke, Frank Valdes, and Elwood Downey, with help from +Ed Anderson, Jeannette Barnes, and Richard Wolff) and members of the VMS/IRAF +group at STScI (Peter Shames, Tom McGlynn, Jim Rose, Fred Rommelfanger, +Cliff Stoll, and Jay Travisano). +.PP +The continuing patience and understanding of members of the scientific +staff at both institutions has been essential to the progress that has +so far been achieved. A major software project such as IRAF cannot +be attempted without the cooperation of many individuals, since the +resources required must inevitably place a drain on other activites. +In particular, the support and encouragement of Buddy Powell, Harvey Butcher, +and Garth Illingworth was of critical importance during the first years +of the project. In recent years the support of John Jefferies, Steve Ridgway, +and Ethan Schreier has been invaluable. Mention should also be made of +Don Wells, who in 1978 started in motion the process which eventually led +to the creation of the IRAF system. + +.sp +.ce +\fBReferences\fR +.PP +The references listed here pertain only to the IRAF system software. +Unless otherwise noted, all papers are by the author. +These are mostly design documents; comprehensive user documentation for the +programming environment is not yet available. Considerable additional +documentation is available for the IRAF system packages and for the NOAO +and STScI science packages. Contact the responsible institution directly +for information on the science software. +.sp +.pg +.ta .3i +.in .3i +.ftR +.sp.3 +.ti0 +1. Shames, P.M.B, and Tody, D., +.ul +A User's Introduction to the IRAF Command Language Version 2.0, +revised February 1986. The current user's guide to the CL. +.sp.3 +.ti0 +2. +.ul +Detailed Specifications for the IRAF Command Language, +January 1983. The original CL design paper. No longer accurate or +comprehensive, but still contains useful information about the inner +workings of the CL. +.sp.3 +.ti0 +3. +.ul +IRAF Standards and Conventions, +August 1983. Coding standards, program design principles, portability +considerations for programming in the SPP environment. +.sp.3 +.ti0 +4. +.ul +A Reference Manual for the IRAF Subset Preprocessor Language, +January 1983. The most up to date documentation currently available for +the SPP language proper. +.sp.3 +.ti0 +5. +.ul +The Role of the Preprocessor, +December 1981. The original design document for the SPP language. +Primarily of historical interest. Documents the reasoning which led to +the decision to use a preprocessor language in IRAF. +.sp.3 +.ti0 +6. +.ul +Programmer's Crib Sheet for the IRAF Program Interface, +September 1983. Summarizes the contents of the various i/o subsystems +comprising the VOS. Somewhat out of date, but still useful. +.sp.3 +.ti0 +7. +.ul +Graphics I/O Design, +March 1985. Specifications for the graphics i/o subsystem. +Reasonably up to date. +.sp.3 +.ti0 +8. +.ul +Design of the IRAF Database Subsystem, +draft, October 1985. Presents the conceptual design of the planned database +subsystem. +.sp.3 +.ti0 +9. +.ul +A Reference Manual for the IRAF System Interface, +May 1984. An essential document describing the IRAF kernel, including the +principles of operation and specifications for the kernel routines. +.sp.3 +.ti0 +10. +.ul +UNIX/IRAF Installation and Maintenance Guide, +March 1986. +.sp.3 +.ti0 +11. +.ul +VMS/IRAF Installation and Maintenance Guide, +March 1986. +.sp.3 +.ti0 +12. +.ul +A Set of Benchmarks for Measuring IRAF System Performance, +March 1986. Contains comparative benchmarks for IRAF running on VAX/UNIX, +VAX/VMS (750,780,8600), the SUN-3, and additional machines in the future. diff --git a/doc/iraf92.tex b/doc/iraf92.tex new file mode 100644 index 00000000..46558215 --- /dev/null +++ b/doc/iraf92.tex @@ -0,0 +1,625 @@ +\documentstyle[11pt,paspconf,epsf]{article} +\parskip=4pt + +\begin{document} + +\title{IRAF in the Nineties} + +\author{Doug Tody\altaffilmark{1}} +\affil{National Optical Astronomy Observatories, Tucson, AZ 85726} + +\altaffiltext{1}{NOAO is operated by AURA, Inc.\ under contract to the +National Science Foundation.} + +\begin{abstract} +The IRAF system (Image Reduction and Analysis Facility) has been under +development since 1981 and in use since 1984. Currently, in 1992, IRAF is a +mature system with hundreds of applications which is in wide use within the +astronomical community. After a brief look at the current state of IRAF, +this paper focuses on how the IRAF system is expected to develop during the +coming decade. Certain key new technologies or trends which any new data +analysis system will need to deal with to be viable in the nineties and +beyond are discussed. An overview of the planned enhancements to the IRAF +system software is presented, including work in the areas of image data +structures, database facilities, networking and distributed applications, +display interfaces, and user interfaces. +\end{abstract} + +\keywords {IRAF, image processing, data analysis, graphics, visualization, +software environments} + +\section {Introduction} + +The IRAF data reduction and analysis system has been around since 1981. +Today IRAF is a mature system with hundreds of applications which is supported +on all major platforms. Many institutions, projects, and individuals around +the U.S. and the world have developed software for IRAF. Some of these +packages are comparable in size to the IRAF core system itself. + +At the present time there are half a dozen large groups developing software +for IRAF, plus many individuals or small groups. Coordination of the work +being done by the large groups is the responsibility of the IRAF TWG +(Technical Working Group), an interagency group which oversees IRAF software +development. Scientific review of IRAF development is provided by an IRAF +User's Committee, which oversees IRAF as a whole and which reports to NOAO, +by additional User's Committees reporting on the various projects developing +large layered packages for IRAF, and by the staff and management of the +institutions funding IRAF development. IRAF is used primarily by the ground +based astronomy (NSF) and NASA space astrophysics communities. + +A list of the IRAF layered packages currently installed at NOAO/Tucson is +shown in Figure 1, to illustrate the variety of packages available. This +list is not all-inclusive, i.e., there are additional layered packages +available for IRAF other than those shown here, which were the ones which +happened to be installed at NOAO when this figure was prepared. The +standard IRAF distribution itself, consisting of the core IRAF and NOAO +package trees, contains about 50 additional packages, or several hundred +tasks, totaling approximately 1.3 million source lines. The core IRAF +system includes the IRAF system software (host system interface, run time +and programming environments, command language and other user interfaces, +and core applications) and is required to compile and run any layered +software. + +\small +\begin{tabbing} +\hspace{0.3in}\=\hspace{1.5in}\=\kill +\> adccdrom \> tools for accessing ADC CD-ROM\\ +\> ccaccq \> IRAF CCD data acquisition\\ +\> color \> prototype RGB rendering tasks\\ +\> ctio \> CTIO local tasks\\ +\> demos \> IRAF demos\\ +\> ftools \> FITS tools package\\ +\> grasp \> GONG data processing (helioseismology)\\ +\> ice \> IRAF CCD data acquisition\\ +\> iue \> tools for importing IUE spectral data into IRAF\\ +\> mem0 \> maximum entropy image restoration\\ +\> nlocal \> NOAO/Tucson local tasks\\ +\> nso \> Solar astronomy\\ +\> spptools \> SPP programming utilities\\ +\> steward \> Steward observatory local tasks\\ +\> stsdas \> STScI (HST) data processing\\ +\> tables \> STScI table tools package\\ +\> vol \> volume rendering\\ +\> xray \> SAO x-ray data analysis package\\ +\\ +\normalsize +\> {Figure 1.} IRAF layered packages installed at NOAO (Dec. 1992)\\ +\end{tabbing} +\normalsize +\vskip -12pt + +As of late 1992 the current release of IRAF, which is still in distribution, +is version 2.10. As of December 1992 there were a total of 1068 logged +distributions of the previous version of IRAF, V2.9, of which 196 +distributions were tape distributions mailed to the user at cost, and 872 +distributions were downloaded via anonymous ftp from the IRAF network +archive on iraf.noao.edu. An unknown number of additional distributions +were downloaded via DECNET network transfer (we don't know how many, as we +log only ftp file transfers). These statistics count only distributions +leaving NOAO; since the system is freely available, we have no way of +recording redistribution of the system at remote sites or within large +institutions. IRAF site support traffic totals over 5000 email messages or +phone calls per year, counting both incoming and outgoing messages. Based +on the number of distributions and the site support traffic we estimate +there are currently several thousand active users of IRAF. + +The remainder of this paper focuses on where IRAF is headed over the +remainder of this decade. We look first at some key new technologies that +we feel IRAF (or any modern astronomical data analysis system) must use +effectively to be competitive by the end of the decade. Some pitfalls that +we feel system developers would be wise to consider are also discussed. +Finally, we summarize the work planned for the next few years to enhance the +IRAF system software to meet these new challenges. + +\section {Key new technologies for the next decade} + +IRAF is a long term project. Most of the software or hardware technologies +upon which IRAF is based typically have a lifetime of only 5 or 10 years - +considerably less than the expected lifetime of the IRAF software. To +remain up to date it is necessary to make use of new technology, but one +must do so carefully to avoid tying the software irrevocably to a technology +which will one day become obsolete. It is not easy to change a large system +once a direction has been chosen, so one must take the long term view, +always planning 5 to 10 years in the future, trying to visualize what future +computer systems will be like and what we want our software to look like on +those systems. + +\subsection {Key new technologies} + +The following are some key new technologies and technological issues or +trends which we feel any modern data analysis system should be concerned +with. + +\vspace {-5pt} +\subsubsection {User interfaces} + +As computer systems become more powerful, software systems are becoming +larger and more complex. People do a lot more with computers now than they +did a few years ago. Functionality and efficiency, while still important, +are no longer the overriding concerns they once were. The issues of +managing complexity, and ease of use, are increasingly important concerns. +The challenge of user interface design is to make complex systems +comprehensible, intuitive, and easier to learn and use. Sophisticated user +interfaces will make our software more pleasant to use, and allow more +complex and sophisticated applications to be written. The days are past +when the user interface can be taken for granted when designing new +software. + +\subsubsection {High level languages} + +Our common everyday computers are becoming so powerful that most of the +compute cycles now go to waste. At the level of compiled code, our computer +languages and software systems are becoming increasingly complex, to the +point where it may take an expert with years of training to deal with them. +It may be that the time is rapidly passing when casual users will do very +much programming with general purpose compiled languages like Fortran, C, +C++, and so on. The trend is towards higher level interpreted languages +which are tailored for a particular type of application. Whether these +languages are syntax driven, visual, or whatever does not really matter; in +general the optimum type of language depends upon how the language will be +used, and languages should be customized for a particular application. In +the future, users will still develop custom applications, but they will +increasingly do so using sophisticated, high level, application specific +custom languages which are embedded in feature-rich data processing +environments. + +\subsubsection {Networking and distributed objects and data} + +Our computers are getting powerful enough that for many applications, +further gains in compute power won't make a whole lot of difference. A +powerful computer and sophisticated software aren't worth much unless one +has data or other raw information of some type to process, analyze, or +query. Fortunately a new way has been found to expand the capability of a +computer system: the growth of global networks is opening up a whole new +dimension on what we can do with computers. It is already the case that one +can do wondrous things with even the simplest hand held computer - so long +as it is connected to the global networks. The networks give us access to +an inconceivable amount of data or information of various types. Not only +do the networks provide access to vast amounts of raw information, they make +it possible to export arbitrary {\it services} via the network. Rather than +export data or software, one can now export services which remote clients +can access at runtime to do any number of interesting things. We are only +just starting to learn how to make use of the global networks, but it is +already clear that the networks will change forever how we do computing, and +how we use computers. + +\subsubsection {Object oriented software structure and methodology} + +Every few years something new comes along (e.g., AI, CASE, HyperCard, etc.) +which proponents claim will revolutionize how we do computing. Most of +these ``silver bullets'', useful though they may be in some applications, +are oversold and after a time something else gets all the press. The latest +such hot item is object oriented programming (OOP). The journals are full +of talk about object oriented languages, databases, programming tools, and +so on. This time it is not just another overhyped product though. The +object oriented approach to software development and software design is +probably the most important development in software engineering since +structured programming in the 80's. In fact it is a natural outgrowth of +the best software practices of the 80's. + +What is important about object orientation is not a particular language, +commercial product, or other tool, but the concepts and methodology +underlying the object oriented approach to software development and systems +design. In particular, the object oriented approach places a special +emphasis on the {\it conceptual modeling} of the objects (classes) +comprising a software system. This emphasis on conceptual modeling, and the +encapsulation or information hiding that is a natural part of the object +oriented approach, are fundamentally important in dealing with the +complexity of large modern software systems. Other elements of the object +oriented approach such as subclassing and inheritance are probably +fundamental to a true object oriented software structure, but this is a +fairly specific software structure, and not necessarily the best one for all +applications. Like any technology, OOP will be better for some things than +for others, and we are still learning the limitations of this new technology +and where it can be used most effectively. + +\subsubsection {Database technology} + +There is nothing very new about database technology. To date though, +astronomy has done little with database technology, beyond its obvious use +for indexing data archives. We think that there is much that could be done +by combining, e.g., database technology with a graphical user interface to +perform sophisticated queries of the catalogs produced by astronomical +analysis programs such as are produced by image classification, source +detection, and stellar or galaxy photometry programs. Furthermore our data +sets are becoming larger and increasingly more complex, as is the way we +access data, especially when we take network access to remote databases into +account. Database technology will eventually have to be brought into play +to effectively manage this increased complexity. Conventional relational +database technology will continue to be important for large data archives +and for some types of catalogs produced by analysis programs, but object +oriented database techniques will be better suited to the complex data +objects dealt with by our online analysis systems. + +\subsection {Concerns} + +In the process of employing all this new technology there are a number of +things to watch out for. + +\subsubsection {The coming OS wars} + +UNIX is king right now, but will this be the case ten years from now? Ten +years ago the dominant system in astronomy was the VAX running VMS. Today +it is the UNIX workstation. UNIX is a very good system and it (or more +properly its descendents) might still be the dominant system ten years from +now, but this is by no means certain. There is a very real possibility that +the dominant system for astronomers ten years from now could be the PC. Not +the PC we have now, but the PC we will have then, when a PC is more powerful +than the workstation of today, cheaper, portable, fully connected to the +networks, and capable of running ``shrink wrapped'' personal applications in +addition to specialized astronomical software. The engineering workstations +and servers of today will still be around, and they will be more powerful +than ever, but an increasing share of scientific computing is likely to be +done on mass market PC systems. + +If the PC does so well then we cannot be certain that UNIX will still be the +predominant operating system ten years from now. We might instead be using +an operating system which was designed for the mass market, such as +Windows/NT, or conceivably even some future version of MacOS (most likely a +mixture of all these). UNIX may be more powerful, more elegant, more +technically superior, and less proprietary, but those criteria will not +necessarily prove as compelling to the mass markets as they have to the +academic and engineering markets. Even within the UNIX community there is +still considerable variation in what we call UNIX, and despite efforts like +POSIX there is no real evidence that this situation will ever change. On +the contrary, UNIX systems are becoming increasingly complex and small +differences are correspondingly magnified. + +\subsubsection {Window systems} + +In the past the main concern when porting software to a new platform was the +operating system. Operating system differences are still a concern, but not +as big a concern as in times past. A possibly more significant problem, and +one which is perhaps being overlooked by many folks now writing software, is +the window system, or in the case of X, the window system toolkit. Modern +window systems are comparable in complexity to operating systems but the +technology is much newer, and is still evolving rapidly. It is likely that +any window system specific software written today will have to be thrown out +and rewritten a few years from now. Most window system specific software +today would have to be largely rewritten to ``port'' the application to a +different window system on a different platform. Despite these problems, +most window system applications written today are monolithic applications +with the application specific functions and user interface code tightly +interwoven. Window systems may prove to be the ``assembly language'' of the +90's. + +\subsubsection {Computer languages} + +In the past ten years the major players in the general computer languages +arena have changed, but the game has not. We have seen Fortran 77, K\&R C, +ANSI C, Fortran 90, and lately C++, with others such as Ada, Pascal, and +Objective C on the sidelines. Computer languages are constantly evolving. +Even given language standards, implementations of a language by vendors on +different hardware vary considerably. This is unlikely to ever change. + +The evolution of computer languages is not a problem so long as one is +content to write disposable software. If the projected lifetime of a body +of software is ten years or longer, and the body of software is large enough +that rewriting it may not be practical, the evolution of languages is a +serious problem which may eventually cause the software to become obsolete, +along with the technology it has been tied to. Even in the short run, the +variation in language implementations on different platforms can be a +serious support headache if the body of code is sufficiently large. + +\section {Major IRAF system software enhancements} + +In this section we describe the work being done to enhance the IRAF system +software. This is a long term effort extending over a period of years. +Some of the work discussed has already been completed, but much of it is +either in progress or still to be done. + +The work presented here attempts to exploit the new technologies discussed +in the last section, while avoiding the pitfalls that can come from tying +software too closely to a particular technology. Existing technology is +only useful up to a point; much of the work discussed in this section is an +outgrowth of the work already done on the IRAF system, and reflects problems +some of which appear to be unique (at some level) to astronomical data +analysis. + +The reader is assumed to already have some familiarity with the current IRAF +system software. The software described here is very extensive and it is +impossible in a short review article like this to go into very much detail, +or explain all the terminology used. + +\subsection {Image Structures} + +The term ``image structures'' refers to the representation of the primary +data type in IRAF, the {\it image}. In IRAF an image is not a simple +picture, but an arbitrarily complex data object. An image consists of an +N-dimensional logical data raster (sampled data array) plus various bits of +associated information, some of which may be quite complex objects in their +own right. The logical data raster need not be physically stored as a +sampled data array, for example in the case of event data the data is stored +as an event list and sampled only when the image is accessed. The +information often associated with a data raster includes history +information, any attributes computed by analysis of the image data, world +coordinate systems, pixel or region masks, uncertainty or "noise" +information, and so on. + +A common example of an image is a raw data image, i.e., an astronomical +observation. Examples of raw data images are a 1D spectrum, a 2D CCD data +frame, or a 3D Fabry-Perot or radio spectral image cube. Images of +dimension higher than 3 are rare in astronomy. Typical astronomical data +sets can be quite large, e.g. several gigabytes, perhaps consisting of +thousands of small spectra, or several hundred large 2D images. Individual +images of 32 megabytes or larger are occasionally seen. + +\small +\begin{tabbing} +\hspace{0.3in}\=\hspace{0.3in}\=\hspace{0.3in}\=\hspace{2in}\=\kill +\>{\bf high level image class}\\ + \>\>{\tt IMIO} \>\>image i/o\\ +\\ +\>{\bf image header access}\\ + \>\>{\tt IMIO} \>\>header access\\ + \>\>\>{\tt DFIO} \>datafile manager (*)\\ + \>\>\>{\tt FMIO} \>file manager\\ +\\ +\>{\bf image kernels} (internal to IMIO)\\ + \>\>{\tt IKI} \>\>image kernel interface\\ + \>\>\>{\tt OIF} \>old (original) image format\\ + \>\>\>{\tt STF} \>HST image format\\ + \>\>\>{\tt PLF} \>pixel list image format\\ + \>\>\>{\tt QPF} \>QPOE (event list) image format\\ + \>\>\>{\tt FTF} \>FITS image format\\ + \>\>\>new format \>new DFIO based image format (*)\\ + \>\>\>others \>HDS(?), ``PC'' image formats (*)\\ +\\ +\>{\bf auxiliary classes}\\ + \>\>{\tt MWCS} \>\>world coordinate systems\\ + \>\>{\tt PMIO, PLIO, MIO} \>\>pixel masks or lists\\ + \>\>{\tt QPOE} \>\>event list data files\\ + \>\>{\tt NFIO} \>\>noise function package (*)\\ +\\ +\> \normalsize {Figure 2.} New Image Structures\\ +\end{tabbing} +\normalsize +\vskip -12pt + +When IRAF was first released some years ago the only image format consisted +of a pair of files per image, one for the header and one for the pixel +matrix, with the header file consisting of a fixed binary structure plus a +variable number of FITS cards (not a terribly flexible or efficient +structure). Over time several alternative image formats have been added, as +well as support for some of the auxiliary data objects associated with +images. It has become increasingly difficult to store all this information +in the simple data structures provided by the older IRAF image formats. The +purpose of the new image structures project is to provide a general, well +integrated hierarchy of image object classes for flexibly and efficiently +representing a wide variety of image data. + +The major components of the new image structures are summarized in Figure +2. The new image structures project is further along than most of the other +new software discussed in this paper; everything listed has been implemented +except for the items marked with an asterisk. This is a {\it big} project; +some of the subsystems listed here, e.g., MWCS, QPOE etc., are major +projects in their own right, and in total the new image structures code +will likely exceed 100K lines, not counting the lower level IRAF classes +or other library code. + +A key feature of the implementation of the image interface in IRAF is the +{\it image kernel}. An image kernel is the only part of IRAF that knows +anything about how an image is stored externally, i.e., the physical image +format. The image kernel implements a mapping between the physical image +format and the logical view of an image implemented in the runtime image +descriptor used to access an active image object. The image kernel can +provide a standard interface to a wide variety of image types, including odd +things like photon event lists, image masks, or image display server frame +buffers, in addition to various standard image raster disk file formats. In +principle IRAF can be integrated with any external image processing system +by implementing an IKI image kernel for the image format defined by the +external system. The best example of this is FITS. The FITS image kernel +also allows archival data, e.g. on CD-ROM or on a remote network server, to +be directly accessed by IRAF programs. + +The main work remaining to be done to finish the new image structures +project is to implement a new standard IRAF online image format based on the +general datafile manager (DFIO, discussed in the next section). This will +replace the existing OIF image format. The new format will make it possible +to simply and efficiently group complex objects such as world coordinate +systems, pixel masks, and compressed pixel uncertainty arrays with pixel +arrays to form the objects we call images. + +\subsection {Database facilities} + +Managing complex data structures such as the image structures in a flexible +and efficient manner, while providing features such as data independence, +machine independence, a data recovery capability, transparent storage of +arbitrarily large data elements, capabilities for storing complex objects +(not just simple tables), indexing for efficient lookup, and a good +integration with the higher level IRAF software, is a complex and demanding +problem. The low level interface planned to provide this capability for +IRAF is DFIO, the data file manager. DFIO is layered upon FMIO, the file +manager, which is in turn layered upon IRAF binary file i/o (FIO). DFIO is +a medium level interface designed for embedded applications, e.g. it will +be used internally within IMIO to store image data. For the most part IRAF +applications will not use DFIO directly, rather they will deal with data at +a higher level, e.g. via the image class. + +One of the types of data DFIO will be capable of storing is the table, as in +a relational database. Hence, in addition to its use as an embedded +interface within IRAF system software to store complex data objects, DFIO +will provide a traditional relational database capability for applications +such as catalog access. Since IRAF already provides a builtin networking +capability, DFIO will automatically be usable in client-server applications +to provide a distributed database facility. To be able to access external, +non-IRAF databases, a database server architecture will be used (similar to +the use of image kernels by IMIO). + +\subsection {Networking and distributed applications} + +Networking is an integral part of IRAF and IRAF has always been able to +support distributed applications. In IRAF all access to external resources +is via the IRAF kernel. The IRAF kernel has a builtin remote procedure call +facility allowing kernel procedures to execute either locally or remotely. +(This includes {\it all} kernel procedures that access a named external +resource, be it a file, directory, tape drive, image display, process, or +whatever). In a local reference the procedure is executed directly; when +the resource being accessed resides on a remote node a custom RPC protocol +layered upon the IRAF networking driver is used to remotely execute the +kernel procedure. The only system dependent part of all this is the +networking driver, which can use any standard message or stream oriented +transport layer, e.g. TCP/IP, DECNET, and so on. Since the IRAF kernel +provides a standard host interface, the routing or leaf nodes in a +distributed IRAF process tree can execute on host machines running any +operating system to which IRAF has been ported. It is even possible to +transparently route RPC calls between different networks, e.g. the Internet +and SPAN. + +There are still some significant enhancements planned for the IRAF +networking system but these are for the most part comparatively minor +evolutionary enhancements. One of the most interesting enhancements being +considered is some sort of interface to non-IRAF servers, e.g. ftp or WAIS +servers. This would not provide the full capability of the IRAF kernel, but +might work for simple directory and file access, and would allow any IRAF +application to transparently access arbitrary servers on the network whether +or not they provide an IRAF kernel server. + +\subsection {User Interfaces} + +In general, the IRAF system circa 1992 is very strong in terms of the +functionality provided, but is weak in the area of user interfaces. This +directly reflects the priorities for IRAF development in the late 1980's, +which emphasized getting numbers out of the data. This meant new +applications, and due to the common environment, enhanced system support for +these applications (e.g. the new image structures). In the early 1990's, +with a wealth of software now in the system and more people than ever using +IRAF, the emphasis has shifted towards ease of use and improved user +interaction and data display. + +Enhancements to the IRAF user interfaces are planned in many areas. Two of +the most exciting are a general GUI (graphics user interface) capability, +available to any IRAF application and capable of making full use of the +advanced capabilities of modern window systems, and less obviously, something +called minilanguage support. + +Modern window systems are remarkably complex software systems, and the field +is still evolving rapidly, with many quite different window systems and +window system toolkits being developed or in use. Using window user +interfaces effectively in scientific applications is challenging, as if one +is not careful and the wrong approach is taken, programmers may spend all +their time struggling with complex window system software and not get any +science software written. Due to the complexity of the field, learning a +particular toolkit or user interface builder is time consuming and a +considerable investment in time is required to make use of any particular +tool. A wrong decision could result in a great deal of wasted time, +particularly for a large project where many people may be developing +software. + +%\small +%\begin{verbatim} +% IRAF application <---- (file defining user interface) +% | | +% GIO | +% | | +% Interpreter <====== IPC =======> Interpreter +% | +% Object Manager +% | +% Window System Toolkit +% +% (Client Application) (Widget Server) +%\end{verbatim} +%\normalsize +% +%\hspace{0.3in}{Figure 3.} Widget Server Architecture +%\vspace{12pt} + +\begin{figure} +\epsfxsize=5.0in \epsfbox{iraf92f3.eps} +\hspace{0.3in}{Figure 3.} Widget Server Architecture +\end{figure} + +After considerable time spent studying window systems and graphics user +interfaces we think we have found a solution to this problem. It is called +the {\it widget server}. In the widget server architecture the application +and the user interface are in two separate processes. The application is a +type of minilanguage with a simple parsed command line interface. The user +interface resides in the widget server process. When an application starts +up it downloads a text file to the widget server containing the user +interface to be executed. This defines all the widgets forming the user +interface as well as the code to be executed (interpreted) while the user +interface executes. During execution, the user interface (widget server) +and client application exchange commands and data via interprocess +communication. + +This architecture has many advantages, e.g., a complete separation of the +user interface and functional code, and a high level interpreted interface +to the window system for the programmer, making it easy to develop GUIs (and +easy for the user to customize the user interface). Since only the widget +server knows about a particular window system or toolkit, the widget server +also provides window system and toolkit independence, allowing a new window +system or toolkit to be supported merely by implementing a new version of the +widget server. The widget set provided by the widget server will include +the standard toolkit text, button, scollbar, list, geometry, etc. widgets, +plus some custom widgets (such as graphics and image display widgets) +tailored to IRAF applications. + +As powerful as the graphics user interface can be, it is not the only way to +do a user interface, nor is it necessarily the best type of user interface +for all interactive applications. A quite different type of applications +user interface which is at least as powerful, and also well suited to +complex applications, is the context-based minilanguage. A minilanguage is +a single program (IRAF task) with a syntax driven, command line user +interface. The program maintains an internal state and successive input +statements modify this state. The syntax, command or function set, and +internal data structures are customized for each application. The +individual functions are usually simple, but arbitrarily complex operations +can be performed by stringing together sequences of commands or +expressions. By designing an appropriate syntax very powerful +applications-specific languages can be devised. + +A good language will be extensible, allowing users to define new procedures, +link to external compiled routines, or interface external IRAF or host tasks +so that they appear as functions in the minilanguage. It will even be +possible to combine a graphics user interface with a minilanguage. For +example, the combination of the widget server with a minilanguage will +provide both a fully featured GUI capability and a powerful interpreted +computing engine, both programmable by the user without need to resort to +low level compiled languages. When all this is layered upon the IRAF +environment, providing well integrated access to powerful facilities such as +the IRAF image structures and a wealth of existing external tasks, the +result will be high level applications of unprecedented power, flexibility, +and sophistication. + +\vspace{12pt} +\acknowledgments + +Without the contributions of many people over the years, the IRAF system we +have now would not exist. The author particularly wishes to thank Frank +Valdes and Lindsey Davis of the NOAO IRAF group, who wrote much of the IRAF +software. STScI and SAO have made major contributions to the system over +the years and the IRAF project would not be the same without their +involvement. A grant from the NASA astrophysics data program has made all +the difference as IRAF use continued to grow while the NOAO budget continued +to shrink. Finally, we wish to thank the NOAO directors and scientific +staff for their continuing support and enthusiastic use of IRAF, and for +their help in making IRAF a better system. + +\begin{references} +\reference Tody, D., 1986, ``The IRAF Data Reduction and Analysis System'', +in {\it Instrumentation in Astronomy VI}, David L. Crawford, Editor. + +\reference +Hanisch, R. J. 1991, +``STSDAS: The Space Telescope Science Data Analysis System'', +in {\it Data Analysis in Astronomy IV} (Di Ges\`{u}, V., +Scarsi, L., Buccheri, R., Crane, P., Maccarrone, M.C., and Zimmermann, H.U., +eds., Plenum Press, New York), 97. + +\reference +Worrall, D.M., Conroy, M., DePonte, J., Harnden, F.R., Mandel, E., +Murray, S.S, Trinchieri, G. , VanHilst, M. , Wilkes, B.J., 1992, +``PROS: Data Analysis for ROSAT'' +in {\it Data Analysis in Astronomy IV}, eds.~V. Di Gesu {\it et al.}, +Plenum Press, 145. + +\reference Olson, E. C. and Christian, C. A., 1992, +``The EUVE Guest Observer Analysis Software.'' +in {\it Astronomical Data Analysis Software and Systems I}. + +\reference See also the many technical papers describing the IRAF software, +available in {\tt iraf.noao.edu:iraf/docs}. + +\end{references} +\end{document} diff --git a/doc/iraf92f3.eps b/doc/iraf92f3.eps new file mode 100644 index 00000000..d9ebc0e2 --- /dev/null +++ b/doc/iraf92f3.eps @@ -0,0 +1,519 @@ +%!PS-Adobe-1.0 +%%BoundingBox: 0 0 683 239 +%%Creator: lepus:tody (Doug Tody,NOAO/IRAF,749-0726) +%%Title: stdin (xv wbit.pbm) +%%CreationDate: Sun Jan 24 17:17:33 1993 +%%EndComments +%%Pages: 1 +%%EndProlog +%%Page: 1 1 + +/bitgen + { + /nextpos 0 def + currentfile bufspace readhexstring pop % get a chunk of input + % interpret each byte of the input + { + flag { % if the previous byte was FF + /len exch def % this byte is a count + result + nextpos + FFstring 0 len getinterval % grap a chunk of FF's + putinterval % and stuff them into the result + /nextpos nextpos len add def + /flag false def + }{ % otherwise + dup 255 eq { % if this byte is FF + /flag true def % just set the flag + pop % and toss the FF + }{ % otherwise + % move this byte to the result + result nextpos + 3 -1 roll % roll the current byte back to the top + put + /nextpos nextpos 1 add def + } ifelse + } ifelse + } forall + % trim unused space from end of result + result 0 nextpos getinterval + } def + + +/bitdump % stk: width, height, iscale + % dump a bit image with lower left corner at current origin, + % scaling by iscale (iscale=1 means 1/300 inch per pixel) + { + % read arguments + /iscale exch def + /height exch def + /width exch def + + % scale appropriately + width iscale mul height iscale mul scale + + % data structures: + + % allocate space for one line of input + /bufspace 36 string def + + % string of FF's + /FFstring 256 string def + % for all i FFstring[i]=255 + 0 1 255 { FFstring exch 255 put } for + + % 'escape' flag + /flag false def + + % space for a chunk of generated bits + /result 1000 string def + + % read and dump the image + width height 1 [width 0 0 height neg 0 height] + { bitgen } + image + } def +%72 300 div dup scale +0.25 dup scale +90 rotate 0 -2847 translate +%777 226 translate +332 949 3 bitdump +ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0 +ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff05f803ff22f0ff05 +c0007fff21f0ff0580003fff21f0ff04fe0ffc1fff21f0ff04fc3fff010fff21f0ff04fc +ff02c7ff21f0ff04fdff02e7ff21f0ff29f0ff29f0ff0603ff22f0ff05fc00ff22f0ff05 +f0003fff21f0ff05e0001fff21f0ff05c1ff010fff21f0ff05c7ff018fff21f0ff05cfff +01e7ff21f0ff05cfff01e7ff21f0ff05dfff01e7ff04e000000000000000000000000000 +00000000000000000003ff05f0ff05dfff01e7ff04e00000000000000000000000000000 +000000000000000003ff05f0ff05dfff01e7ff04e0000000000000000000000000000000 +0000000000000003ff05f0ff05dfff01e7ff04e000000000000000000000000000000000 +00000000000003ff05f0ff05cfff01e7ff04e00000000000000000000000000000000000 +000000000003ff05f0ff05cfff01c7ff04e0ff08c7ff05c7ff0783ff05f0ff05c7ff018f +ff04e0ff08c7ff05c7ff0783ff05f0ff05e3fe07ff04e0ff08c7ff05c7ff0783ff05f0ff +05f3fc07ff04e0ff08c7ff05c7ff0783ff05f0ff0ce0ff08c7ff05c7ff0783ff05f0ff0c +e0ff08c7ff05c7ff0783ff05f0ff0ce0ff08c7ff05c7ff0783ff05f0ff05dfff01efff04 +e0ff08c7ff05c7ff0783ff05f0ff05dfff01efff04e0ff08c7ff05c7ff0783ff05f0ff05 +c00007ff04e0ff08c7ff05c7ff0783ff05f0ff05c00007ff04e0ff08c7ff05c7ff0783ff +05f0ff05c00007ff04e0ff08c7ff05c7ff0783ff05f0ff05dfff06e0ff08c7ff05c7ff07 +83ff05f0ff0ce0ff08c7ff05c7ff0783ff05f0ff0ce0ff08c7ff05c7ff0783ff05f0ff0c +e0ff08c7ff05c7ff0783ff05f0ff05dff7ff05e0ff08c7ff05c7ff0783ff05f0ff05dff3 +ff05e0ff08c7ff05c7ff0783ff05f0ff05c003c7ff04e0ff08c7ff05c7ff0783ff05f0ff +05c003c7ff04e0ff08c7ff05c7ff0783ff05f0ff05c003c7ff04e0ff08c7ff05c7ff0783 +ff05f0ff05dfff06e0ff08c7ff05c7ff0783ff05f0ff0ce0ff08c7ff0203ff02c7ff0783 +ff05f0ff0ce0ff08c7ff01fc00ff02c7ff0783ff05f0ff05f81fff05e0ff08c7ff01f800 +3fff01c7ff0783ff05f0ff05e007ff05e0ff08c7ff01e0001fff01c7ff0783ff05f0ff05 +c187ff05e0ff08c7ff01c1ff010fff01c7ff0783ff05f0ff05c7b3ff05e0ff08c7ff01c7 +ff018fff01c7ff02f7ff0483ff05f0ff05c7b3ff05e0ff08c7ff01cfff01e7ff01c7ff02 +f3ff0483ff05f0ff05cfbbff05e0ff08c7ff01cfff01e7ff01c7ff02f0ff0483ff05f0ff +05cfb3ff05e0ff08c7ff01dfff01e7ff01c7ff02f01fff0383ff05f0ff05cf83ff05e0ff +08c7ff01dfff01e7ff01c7ff02f60fff0383ff05f0ff05c787ff05e0ff03f7ff01f9ff02 +c7ff01dfff01e7ff01c7ff02f781ff0383ff05f0ff05f38fff05e0ff03f7ff01f9ff02c7 +ff01dfff01e7ff01c7ff03907fff0283ff05f0ff0ce0ff03f3ff01f1ff02c7ff01cfefe7 +ff01c7ff039e1fff0283ff05f0ff0ce0ff03f00001ff02c7ff01cfcfc7ff01c7ff039f81 +ff0283ff05f0ff05dff7ff05e0ff03f00001ff02c7ff01c00f87ff01c7ff039f01ff0283 +ff05f0ff05dff7ff05e0ff03f00001ff02c7ff01c00e07ff01c7ff039807ff0283ff05f0 +ff05c003ff05e0ff03f7ff01f9ff02c7ff01e00e07ff01c7ff03801fff0283ff05f0ff05 +c003ff05e0ff03f7ff01f9ff02c7ff02cfff02c7ff02f400ff0383ff05f0ff05c003ff05 +e0ff08c7ff02efff02c7ff02f003ff0383ff05f0ff05dff7ff05e0ff03f7fdff03c7ff05 +c7ff02f01fff0383ff05f0ff05dff3ff05e0ff03f7fdff03c7ff05c7ff02f0ff0483ff05 +f0ff06f3ff05e0ff03f000ff03c7ff05c7ff02f1ff0483ff05f0ff05dff3ff05e0ff03f0 +00ff03c7ff01dfff01e7ff01c7ff02f7ff0483ff05f0ff05c003ff05e0ff03f000ff03c7 +ff01dfff01e7ff01c7ff02f7ff0483ff05f0ff05c003ff05e0ff03f7fdff03c7ff01cfff +01c7ff01c7ff0783ff05f0ff05c007ff05e0ff03f7fcff03c7ff01c00007ff01c7ff0783 +ff05f0ff05dfff06e0ff04fcff03c7ff01c00007ff01c7ff01fdff01fdff0383ff05f0ff +05dfff06e0ff03f7fcff03c7ff01c00007ff01c7ff01fdff01fdff0383ff05f0ff0ce0ff +03f000ff03c7ff01dfff01e7ff01c7ff01fc0000ff0383ff05f0ff06fbff05e0ff03f000 +ff03c7ff01dfff01e7ff01c7ff01fc0000ff0383ff05f0ff06fbff05e0ff03f001ff03c7 +ff05c7ff01fc0000ff0383ff05f0ff05c001ff05e0ff03f7ff04c7ff05c7ff01fdf3f9ff +0383ff05f0ff05c0007fff04e0ff03f7ff04c7ff0203ff02c7ff01fdf7fcff0383ff05f0 +ff05c0003fff04e0ff08c7ff01fc00ff02c7ff02f7fcff0383ff05f0ff05cffbff05e0ff +04feff03c7ff01f8003fff01c7ff02f3f8ff0383ff05f0ff05cffbff05e0ff04feff03c7 +ff01e0001fff01c7ff02f1f0ff0383ff05f0ff05e7ff06e0ff03f0007fff02c7ff01c1ff +010fff01c7ff02f801ff0383ff05f0ff0ce0ff03f0001fff02c7ff01c7ff018fff01c7ff +02fc01ff0383ff05f0ff0ce0ff03f0000fff02c7ff01cfff01e7ff01c7ff02fe07ff0383 +ff05f0ff0ce0ff03f3feff03c7ff01cfff01e7ff01c7ff0783ff05f0ff0ce0ff03f3feff +03c7ff01dfff01e7ff01c7ff0783ff05f0ff0ce0ff03f9ff04c7ff01dfff01e7ff01c7ff +01fdff01fdff0383ff05f0ff0ce0ff08c7ff01dfff01e7ff01c7ff01fdff01fdff0383ff +05f0ff0ce0ff03fe07ff03c7ff01cfff01e7ff01c7ff01fc0000ff0383ff05f0ff0ce0ff +03f801ff03c7ff01cfff01c7ff01c7ff01fc0000ff0383ff05f0ff0ce0ff03f061ff03c7 +ff01c3ff018fff01c7ff01fc0000ff0383ff05f0ff05dfff06e0ff03f1ecff03c7ff01e1 +fe0fff01c7ff01fdf3f9ff0383ff05f0ff05cfff06e0ff03f1ecff03c7ff01f0001fff01 +c7ff01fdf7fcff0383ff05f0ff05c3ff06e0ff03f3eeff03c7ff01f8007fff01c7ff02f7 +fcff0383ff05f0ff05c07fff05e0ff03f3ecff03c7ff01fe00ff02c7ff02f3f8ff0383ff +05f0ff05d83fff05e0ff03f3e0ff03c7ff0203ff02c7ff02f1f0ff0383ff05f0ff05de07 +ff05e0ff03f1e1ff03c7ff05c7ff02f801ff0383ff05f0ff05fe41ff05e0ff03fce3ff03 +c7ff05c7ff02fc01ff0383ff05f0ff05fe787fff04e0ff08c7ff05c7ff02fe07ff0383ff +05f0ff05fe7e07ff04e0ff08c7ff05c7ff0783ff05f0ff05fe7c07ff04e0ff08c7ff05c7 +ff0783ff05f0ff05fe601fff04e0ff08c7ff05c7ff0783ff05f0ff05fe007fff04e0ff03 +f7fdff03c7ff05c7ff02f7ff01fbff0283ff05f0ff05d003ff05e0ff03f7fdff03c7ff05 +c7ff02f7ff01fbff0283ff05f0ff05c00fff05e0ff03f000ff03c7ff05c7ff02f00001ff +0283ff05f0ff05c07fff05e0ff03f000ff03c7ff05c7ff02f00001ff0283ff05f0ff05c3 +ff06e0ff03f000ff03c7ff05c7ff02f00001ff0283ff05f0ff05c7ff06e0ff03f7f8ff03 +c7ff05c7ff02f7ff0483ff05f0ff05dfff06e0ff04f8ff03c7ff05c7ff0783ff05f0ff05 +dfff06e0ff04f8ff03c7ff05c7ff0783ff05f0ff0ce0ff04f9ff03c7ff05c7ff02f7fdff +0383ff05f0ff04f7ff01f7ff05e0ff02fdff01fdff03c7ff05c7ff02f7fcff0383ff05f0 +ff04f7ff01f7ff05e0ff02fdff01fdff03c7ff05c7ff02f000f1ff0283ff05f0ff04f000 +03ff05e0ff02fc0000ff03c7ff05c7ff02f000f1ff0283ff05f0ff04f00003ff05e0ff02 +fc0000ff03c7ff05c7ff02f000f1ff0283ff05f0ff04f00003ff05e0ff02fc0000ff03c7 +ff05c7ff02f7ff0483ff05f0ff04f7cfe7ff05e0ff02fdf3f9ff03c7ff05c7ff0783ff05 +f0ff04f7dff3ff05e0ff02fdf7fcff03c7ff05c7ff0783ff05f0ff05dff3ff05e0ff03f7 +fcff03c7ff05c7ff02fe07ff0383ff05f0ff05cfe3ff05e0ff03f3f8ff03c7ff05c7ff02 +f801ff0383ff05f0ff05c7c3ff05e0ff03f1f0ff03c7ff05c7ff02f071ff0383ff05f0ff +05e007ff05e0ff03f801ff03c7ff05c7ff02f1f8ff0383ff05f0ff05f007ff05e0ff03fc +01ff03c7ff05c7ff02f1fcff0383ff05f0ff05f81fff05e0ff03fe07ff03c7ff05c7ff02 +f3feff0383ff05f0ff0ce0ff08c0000000000007ff02f3feff0383ff05f0ff0ce0ff08c0 +000000000007ff02f3f0ff0383ff05f0ff04f7ff01f7ff05e0ff03f7fdff03c000000000 +0007ff02f1f1ff0383ff05f0ff04f7ff01f7ff05e0ff03f7fdff03c7ff08fcf3ff0383ff +05f0ff04f00003ff05e0ff03f000ff03c7ff0d83ff05f0ff04f00003ff05e0ff03f000ff +03c7ff0d83ff05f0ff04f00003ff05e0ff03f000ff03c7ff0d83ff05f0ff04f7cfe7ff05 +e0ff03f7f8ff03c7ff08f8ff0483ff05f0ff04f7dff3ff05e0ff04f8ff03c7ff08f871ff +0383ff05f0ff05dff3ff05e0ff04f8ff03c7ff08f030ff0383ff05f0ff05cfe3ff05e0ff +04f9ff03c7ff08f190ff0383ff05f0ff05c7c3ff05e0ff08c7ff08f3deff0383ff05f0ff +05e007ff05e0ff03fe07ff03c7ff08f1ceff0383ff05f0ff05f007ff05e0ff03f801ff03 +c7ff08fce4ff0383ff05f0ff05f81fff05e0ff03f061ff03c7ff08f000ff0383ff05f0ff +0ce0ff03f1ecff03c7ff08f001ff0383ff05f0ff0ce0ff03f1ecff03c7ff08f003ff0383 +ff05f0ff0ce0ff03f3eeff03c7ff08f1ff0483ff05f0ff05dfff01efff04e0ff03f3ecff +03c7ff0d83ff05f0ff05dfff01efff04e0ff03f3e0ff03c7ff0d83ff05f0ff05c00007ff +04e0ff03f1e1ff03c7ff09feff0383ff05f0ff05c00007ff04e0ff03fce3ff03c7ff09fe +ff0383ff05f0ff05c00007ff04e0ff08c7ff08f0007fff0283ff05f0ff05dfff06e0ff08 +c7ff08f0001fff0283ff05f0ff0ce0ff08c7ff08f0000fff0283ff05f0ff0ce0ff04feff +03c7ff08f3feff0383ff05f0ff0ce0ff04feff03c7ff08f3feff0383ff05f0ff05dff7ff +05e0ff03f0007fff02c7ff08f9ff0483ff05f0ff05dff3ff05e0ff03f0001fff02c7ff0d +83ff05f0ff05c003c7ff04e0ff03f0000fff02c7ff08f7fdff0383ff05f0ff05c003c7ff +04e0ff03f3feff03c7ff08f7fcff0383ff05f0ff05c003c7ff04e0ff03f3feff03c7ff08 +f000f1ff0283ff05f0ff05dfff06e0ff03f9ff04c7ff08f000f1ff0283ff05f0ff0ce0ff +08c7ff08f000f1ff0283ff05f0ff0ce0ff03fe07ff03c7ff08f7ff0483ff05f0ff05f81f +ff05e0ff03f801ff03c7ff0d83ff05f0ff05e007ff05e0ff03f061ff03c7ff0d83ff05f0 +ff05c1c7ff05e0ff03f1ecff03c7ff090fff0383ff05f0ff05c7e3ff05e0ff03f1ecff03 +c7ff08fc03ff0383ff05f0ff05c7f3ff05e0ff03f3eeff03c7ff08f801ff0383ff05f0ff +05cffbff05e0ff03f3ecff03c7ff08f0f1ff0383ff05f0ff05cffbff05e0ff03f3e0ff03 +c7ff08f3feff0383ff05f0ff05cfc3ff05e0ff03f1e1ff03c7ff08f7feff0383ff05f0ff +05c7c7ff05e0ff03fce3ff03c7ff08f7feff0383ff05f0ff05f3cfff05e0ff08c7ff08f7 +fcff0383ff05f0ff0ce0ff08c7ff08f1f1ff0383ff05f0ff0ce0ff08c7ff08f801ff0383 +ff05f0ff0ce0ff03f7fdff03c7ff08fc03ff0383ff05f0ff05e3ff06e0ff03f7fdff03c7 +ff08fe07ff0383ff05f0ff05e1c7ff05e0ff03f000ff03c7ff0d83ff05f0ff05c0c3ff05 +e0ff03f000ff03c7ff0d83ff05f0ff05c643ff05e0ff03f000ff03c7ff08f7fdff0383ff +05f0ff05cf7bff05e0ff03f7f8ff03c7ff08f7fdff0383ff05f0ff05c73bff05e0ff04f8 +ff03c7ff08f000ff0383ff05f0ff05f393ff05e0ff04f8ff03c7ff08f000ff0383ff05f0 +ff05c003ff05e0ff04f9ff03c7ff08f000ff0383ff05f0ff05c007ff05e0ff08c7ff08f7 +fdff0383ff05f0ff05c00fff05e0ff08c7ff08f7fcff0383ff05f0ff05c7ff06e0ff08c7 +ff09fcff0383ff05f0ff0ce0ff08c7ff08f7fcff0383ff05f0ff06fbff05e0ff08c7ff08 +f000ff0383ff05f0ff06fbff05e0ff08c7ff08f000ff0383ff05f0ff05c001ff05e0ff08 +c7ff08f001ff0383ff05f0ff05c0007fff04e0ff08c7ff08f7ff0483ff05f0ff05c0003f +ff04e0ff08c7ff08f7ff0483ff05f0ff05cffbff05e0ff08c7ff0d83ff05f0ff05cffbff +05e0ff08c7ff0d83ff05f0ff05e7ff06e0ff08c7ff0d83ff05f0ff0ce0ff08c7ff0d83ff +05f0ff0ce0ff08c7ff0d83ff05f0ff05dff7ff05e0ff08c7ff0d83ff05f0ff05dff3ff05 +e0ff08c7ff0d83ff05f0ff05c003c7ff04e0ff08c7ff0d83ff05f0ff05c003c7ff04e0ff +08c7ff0d83ff05f0ff05c003c7ff04e0ff08c7ff0d83ff05f0ff05dfff06e0ff08c7ff0d +83ff05f0ff0ce0ff08c7ff0d83ff05f0ff0ce0ff08c7ff0d83ff05f0ff05fc3fff05e0ff +08c7ff0d83ff05f0ff05f00fff05e0ff08c7ff0d83ff05f0ff05e007ff05e0ff08c7ff0d +83ff05f0ff05c3c7ff05e0ff08c7ff0d83ff05f0ff05cffbff05e0ff08c7ff0d83ff05f0 +ff05dffbff05e0ff08c7ff0d83ff05f0ff05dffbff05e0ff08c7ff0d83ff05f0ff05dff3 +ff05e0ff08c7ff0d83ff05f0ff05c7c7ff05e0ff08c7ff0d83ff05f0ff05e007ff05e0ff +08c7ff0d83ff05f0ff05f00fff05e0ff08c7ff0d83ff05f0ff05f81fff05e0ff08c7ff0d +83ff05f0ff0ce0ff08c7ff0d83ff05f0ff0ce0ff08c7ff0d83ff05f0ff05dff7ff05e0ff +08c7ff0d83ff05f0ff05dff7ff05e0ff08c7ff0d83ff05f0ff05c003ff05e0ff08c7ff0d +83ff05f0ff05c003ff05e00000000000000000000000000000000000000000000003ff05 +f0ff05c003ff05e00000000000000000000000000000000000000000000003ff05f0ff05 +dff7ff05e00000000000000000000000000000000000000000000003ff05f0ff05dff3ff +05e00000000000000000000000000000000000000000000003ff05f0ff06f3ff05e00000 +000000000000000000000000000000000000000003ff05f0ff05dff3ff0acfff0b9fff0b +f0ff05c003ff0a87ff0b0fff0bf0ff05c003ff0a03ff0afe07ff0bf0ff05c007ff0a03ff +0afe07ff0bf0ff05dfff0afe01ff0afc03ff0bf0ff05dfff0afe01ff0afc03ff0bf0ff10 +fc00ff0af801ff0bf0ff10fc00ff0af000ff0bf0ff04fdff02e7ff08f8007fff09f000ff +0bf0ff04fcff02e7ff08f0003fff09e0007fff0af0ff04fc7fff018fff08f0003fff09e0 +007fff0af0ff04fe0ffc1fff08e0001fff09c0003fff0af0ff0580003fff08e0001fff09 +80001fff0af0ff0580007fff08c0000fff0980001fff0af0ff05f803ff09800007ff0900 +000fff0af0ff10800007ff0900000fff0af0ff10000003ff08fe000007ff0af0ff100000 +03ff09fe0fff0bf0ff0ffe000001ff09fe0fff0bf0ff0ffc000000ff09fe0fff0bf0ff0f +fc000000ff09fe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe +03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0a +fe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff +0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff +10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03 +ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe +0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0b +f0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10 +fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff +0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0f +ff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0 +ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe +03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0a +fe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff +0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff +10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03 +ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe +0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0b +f0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10 +fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff +0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0f +ff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0 +ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe +03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0a +fe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff +0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff10fe03ff0afe0fff0bf0ff +10fe03ff0afe0fff0bf0ff10fe03ff0af800ff0bf0ff10fe03ff0a000007ff0af0ff10fe +03ff09f00000007fff09f0ff10fe03ff09c00000001fff09f0ff10fe03ff09800000000f +ff09f0ff10fe03ff090001ee0007ff09f0ff10fe03ff08fc007fff01f001ff09f0ff10fe +03ff08f800e039ce00ff09f0ff10fe03ff08e003e03fff01803fff08f0ff10fe03ff08c0 +07810f7bc01fff08f0ff10fe03ff080067818f7bd007ff08f0ff10fe03ff0800ef879fff +01f807ff08f0ff10fe03ff07fe038c8719ce7203ff08f0ff10fe03ff07fc07e70f9fff02 +01ff08f0ff10fe03ff07fc0ee01c2f7bde81ff08f0ff10fe03ff07f81ef03c0f7bdec0ff +08f0ff10fe03ff07f03ff87dff03e07fff07f0ff10fe03ff07e0339ce739ce73803fff07 +f0ff10fe03ff07e07fff05f03fff07f0ff10fe03ff07c0def7bdef7bdef01fff07f0ff10 +fe03ff0780dcf7a5ef7bdef00fff07f0ff10fe03ff0781fc0007ff03fc0fff07f0ff10fe +03ff070270000739ce739c07ff07f0ff10fe03ff0707fde7efff02fe7f07ff07f0ff10fe +03ff0703dce7a5ef7bde7707ff07f0ff10fe03ff0703dee7a5ef60007707ff07f0ff10fe +03ff06fe07ff01efe7ff01c0007f03ff07f0ff10fe03ff06fe0e7380873980001c83ff07 +f0ff10fe03ff06fe0fff01f007ff019ffe7f83ff07f0ff10fe03ff06fe0bdef41def3bde +7783ff07f0ff10fe03ff06fe0bdef7bdef3bdef783ff07f0ff10fe03ff06fc0fff04bfff +0281ff07f0ff10fe03ff06fc0e739807398e739cc1ff07f0ff10fe03ff06fc1fff01f007 +ff019ffe7fc1ff07f0ff10fe03ff06fc1bdee185ef0bde7781ff07f0ff10fe03ff06fc1b +dee7a5ef40007781ff07f0ff10fe03ff06f91fff01e7b7ff02fe7fc1ff07f0ff10fe03ff +06f80e738ca739ce721cc1ff07f0ff10fe03ff06f83fff01e787ff04c1ff07f0ff10fe03 +ff06f83bdef38def7bdef781ff07f0ff10fe03ff06f83bdef39def7bdef781ff07f0ff10 +fe03ff06f83fff048e3fff01c1ff07f0ff10fe03ff06f80e739ce7398c139cc1ff07f0ff +10fe03ff06f83fff01f81fff01b85fff01c1ff07f0ff10fe03ff06f83bdef005ef39def7 +81ff07f0ff10fe03ff06f83bdee185ef31def781ff07f0ff10fe03ff06f83fff01e7e7ff +01811fff01c1ff07f0ff10fe03ff06f80e7384e73982139cc1ff07f0ff10fe03ff06f83f +ff01eff7ff04c1ff07f0ff10fe03ff06f83bdee785ef7bdef781ff07f0ff10fe03ff06f8 +3bdef38def605ef781ff07f0ff10fe03ff06f83fff01fbff02c01fff01c1ff07f0ff10fe +03ff06f80e739ce73986139cc1ff07f0ff10fe03ff06f83fff049e9fff01c1ff07f0ff10 +fe03ff06f83bdef7bdef1adef781ff07f0ff10fe03ff06f83bdee7a5ef3a9ef781ff07f0 +ff10fe03ff06f83fff01efe7ff019e1fff01c1ff07f0ff10fe03ff06f80e73800719ce33 +9cc1ff07f0ff10fe03ff06f83fff01e0071fee7fff01c1ff07f0ff10fe03ff06f83bdee7 +bdef7bdef781ff07f0ff10fe03ff06f83bdef7bdef7bdef781ff07f0ff10fe03ff06f83f +ff01eff7ff01bf9fff01c1ff07f0ff10fe03ff06f80e738ce3398e139cc1ff07f0ff10fe +03ff06f83fff01e0007f801fff01c1ff07f0ff10fe03ff06f83bdee0002f001ef781ff07 +f0ff10fe03ff06f83bdee7b50f3b1ef781ff07f0ff10fe03ff06f83fff02f79fff019fff +01c1ff07f0ff10fe03ff06f80e738ce719ce139cc1ff07f0ff10fe03ff06f83fff01eff7 +9fff03c1ff07f0ff10fe03ff06f83bdee0050f7bdef781ff07f0ff10fe03ff06f83bdee0 +05ef7bdef781ff07f0ff10fe03ff06f83fff01efff05c1ff07f0ff10fe03ff06f80e739c +e739ce739cc1ff07f0ff10fe03ff06f83fff07c1ff07f0ff10fe03ff06f83bdef7bdef7b +def781ff07f0ff10fe03ff06f83bdef01def7bdef781ff07f0ff10fe03ff06f83fff01f0 +07ff01bffe7fc1ff07f0ff10fe03ff06f80e7380c7398e721cc1ff07f0ff10fe03ff06f8 +3fff01e7e7ff0180007fc1ff07f0ff10fe03ff06f83bdee7b5ef00007781ff07f0ff10fe +03ff06f83bdee7b5ef00007781ff07f0ff10fe03ff06f83fff01e787ff01bffe7fc1ff07 +f0ff10fe03ff06f80e739087398e721cc1ff07f0ff10fe03ff06f83fff01fbff05c1ff07 +f0ff10fe03ff06f83bdef7bdef3b9ef781ff07f0ff10fe03ff06f83bdef7bdef001ef781 +ff07f0ff10fe03ff06f83fff01f1ff02801fff01c1ff07f0ff10fe03ff06f80e73808739 +8e139cc1ff07f0ff10fe03ff06f83fff01e007ff01bf9fff01c1ff07f0ff10fe03ff06f8 +3bdee635ef7b9ef781ff07f0ff10fe03ff06f83bdee735ef3b9ef781ff07f0ff10fe03ff +06f83fff01f327ff01801fff01c1ff07f0ff10fe03ff06f80e7380073980339cc1ff07f0 +ff10fe03ff06f83fff01e00fff01bfff02c1ff07f0ff10fe03ff06f83bdee7bdef3bdef7 +81ff07f0ff10fe03ff06f83bdef7bdef7bdef781ff07f0ff10fe03ff06f83fff07c1ff07 +f0ff10fe03ff06f80e739ce739ce539cc1ff07f0ff10fe03ff06f83fff01e003ff01800f +ff01c1ff07f0ff10fe03ff06f83bdee000ef0002f781ff07f0ff10fe03ff06f83bdee7b5 +ef1bdef781ff07f0ff10fe03ff06f83fff01e7f7ff019fdfff01c1ff07f0ff10fe03ff06 +f80e7394e739ce739cc1ff07f0ff10fe03ff06f83fff07c1ff07f0ff10fe03ff06f83bde +e7a5ef605ef781ff07f0ff10fe03ff06f83bdee7a5ef401ef781ff07f0ff10fe03ff06f8 +3fff01e0071f861fff01c1ff07f0ff10fe03ff06f80e738007198e139cc1ff07f0ff10fe +03ff06f83fff01efff029edfff01c1ff07f0ff10fe03ff06f83bdef7bdef3a9ef781ff07 +f0ff10fe03ff06f83bdef7bdef1a1ef781ff07f0ff10fe03ff06f83fff01fc3fff01ce3f +ff01c1ff07f0ff10fe03ff06f80e73900739ce739cc1ff07f0ff10fe03ff06f83fff01e0 +07ff04c1ff07f0ff10fe03ff06f83bdee7a5ef7bdef781ff07f0ff10fe03ff06f83bdee7 +b5ef3b9ef781ff07f0ff10fe03ff06f83fff01eff7ff01bf9fff01c1ff07f0ff10fe03ff +06f80e7384e73980139cc1ff07f0ff10fe03ff06f83fff01e387ff01801fff01c1ff07f0 +ff10fe03ff06f83bdef00def3b1ef781ff07f0ff10fe03ff06f83bdef43def7b9ef781ff +07f0ff10fe03ff06f83fff059fff01c1ff07f0ff10fe03ff06f80e739ce739ce739cc1ff +07f0ff10fe03ff06f83fff04bfdfff01c1ff07f0ff10fe03ff06f83bdee7a5ef1bcef781 +ff07f0ff10fe03ff06f83bdee005ef0000f781ff07f0ff10fe03ff06f83fff01e007ff01 +80007fc1ff07f0ff10fe03ff06f80e738ce7398e521cc1ff07f0ff10fe03ff06f83fff01 +efe7ff01bfde7fc1ff07f0ff04ef7bdef7bdef7bdef7bdef7bde03bdef7bdef7bde83bde +f7a5ef7bd87781ef7bdef7bdff02f0ff04ef7bdef7bdef7bdef7bdef7bde03bdef7bdef7 +bde83bdee7a5ef7bd8f781ef7bdef7bdff02f0ff10fe03ff06f83fff01e007ff01c7ff02 +c1ff07f0ff04b9ce739ce739ce739ce739ce7200e739ce739ce7380e7380073982339cc1 +39ce739ce73fff01f0ff10fe03ff06f83fff01efff02801fff01c1ff07f0ff04ef7bdef7 +bdef7bdef7bdef7bde03bdef7bdef7bde83bdee7bdef19def781ef7bdef7bdff02f0ff10 +fe03ff06f83bdef7bdef18def781ff07f0ff10fe03ff06f83fff04cc9fff01c1ff07f0ff +10fe03ff06f80e739ce73980139cc1ff07f0ff10fe03ff06f83fff04803fff01c1ff07f0 +ff10fe03ff06f83bdef7bdef1bdef781ff07f0ff10fe03ff06f83bdef7bdef7bdef781ff +07f0ff10fe03ff06f83fff07c1ff07f0ff10fe03ff06f80e738ce719c0739cc1ff07f0ff +10fe03ff06f83fff01efff019fc01fff01c1ff07f0ff10fe03ff06f83bdee0000f031ef7 +81ff07f0ff10fe03ff06f83bdee0000f1b9ef781ff07f0ff10fe03ff06f83fff01e0001f +9fdfff01c1ff07f0ff10fe03ff06f80e738cc7198e539cc1ff07f0ff10fe03ff06f83fff +01efdf9f9e1fff01c1ff07f0ff10fe03ff06f83bdef79d8f4a1ef781ff07f0ff10fe03ff +06f83bdef79d8f6bdef781ff07f0ff10fe03ff06f83fff028f9fff03c1ff07f0ff10fe03 +ff06f80e739c0719ce739cc1ff07f0ff10fe03ff06f83fff02fe1fe07fff01c1ff07f0ff +10fe03ff06f83bdef7bdef401ef781ff07f0ff10fe03ff06f83bdef7bdef021ef781ff07 +f0ff10fe03ff06f83fff01efe7ff019e9fff01c1ff07f0ff10fe03ff06f80e738ce7398e +539cc1ff07f0ff10fe03ff06f81fff01e0071fbe9fff01c1ff07f0ff10fe03ff06fc1bde +e0050f1a1ef781ff07f0ff10fe03ff06fc1bdee7bdef4a1ef781ff07f0ff10fe03ff06fc +1fff04ee7fff01c1ff07f0ff10fe03ff06fc0e739ce739ce739cc1ff07f0ff0d7fff019f +fe03ff06fc0fff01efff01bfff0381ff07f0ff0d7fff019ffe03ff06fe0bdee7bdaf7bde +f783ff07f0ff0d3fff011ffe03ff06fe0bdee0000f7bdef783ff07f0ff0d00001ffe03ff +06fe0fff01e0001fff0383ff07f0ff0d00001ffe03ff06fe0e738ce739ce739c83ff07f0 +ff0d00001ffe03ff06fe07ff0703ff07f0ff0d7fff019ffe03ff0703def7bdef7bdef707 +ff07f0ff0d7fff019ffe03ff0703def01def7bdef707ff07f0ff10fe03ff0707ff01f007 +ff0407ff07f0ff10fe03ff070273808739ce739c07ff07f0ff0d7fff019ffe03ff0781ff +01e7a7ff03fc0fff07f0ff0d7fff019ffe03ff0780dee7b5ef7bdef00fff07f0ff0d3fff +011ffe03ff07c0dee7a5ef7bdef01fff07f0ff0d00001ffe03ff07e07fe787ff03f03fff +07f0ff0d00001ffe03ff07e033908739ce73803fff07f0ff0d00001ffe03ff07f03ffb9f +ff03e07fff07f0ff0d7f7f9ffe03ff07f81ef7bdef7bdec0ff08f0ff0d7f7f9ffe03ff07 +fc0ef7bdef7bde81ff08f0ff0e3f9ffe03ff07fc07ff0501ff08f0ff0e3f9ffe03ff07fe +039ce739ce7203ff08f0ff0e1f1ffe03ff0800ff04f807ff08f0ff0e843ffe03ff080077 +bdef7bd007ff08f0ff0e803ffe03ff08c017bdef7bc01fff08f0ff0ec07ffe03ff08e00f +ff03803fff08f0ff10fe03ff08f800e739ce00ff09f0ff10fe03ff08fc007fff01f001ff +09f0ff10fe03ff090001ee0007ff09f0ff0dfc0fff01fe03ff09800000000fff09f0ff0d +f003ff01fe03ff09c00000001fff09f0ff0dc000ff01fe03ff09f00000007fff09f0ff0d +80007ffe03ff0a000007ff0af0ff0d07fc3ffe03ff0af800ff0bf0ff0d1ffe3ffe03ff17 +f0ff0d3fff019ffe03ff17f0ff0d3fff019ffe03ff17f0ff0d7fff019ffe03ff17f0ff0d +7fff019ffe03ff17f0ff0d7fff019ffe03ff17f0ff0d7fff019ffe03ff17f0ff0d3fff01 +9ffe03ff17f0ff0d3fff011ffe03ff17f0ff0d1ffe3ffe03ff17f0ff0d8ff81ffe03ff17 +f0ff0dcff01ffe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03 +ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff +17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17 +f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0 +ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff +10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10 +fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe +03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03 +ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff +17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17 +f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0 +ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff +10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10 +fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe +03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03 +ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff +17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17 +f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0 +ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff +10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10 +fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe +03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03 +ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff +17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17 +f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0 +ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff +10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10 +fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe03ff17f0ff10fe +03ff17f0ff0ffc000000ff16f0ff0ffc000000ff16f0ff0ffe000001ff16f0ff10000003 +ff16f0ff10000003ff16f0ff10800007ff16f0ff10800007ff16f0ff10c0000fff16f0ff +10e0001fff16f0ff10e0001fff16f0ff10f0003fff16f0ff10f0003fff16f0ff10f8007f +ff16f0ff10fc00ff17f0ff10fc00ff17f0ff10fe01ff17f0ff10fe01ff17f0ff1103ff17 +f0ff1103ff17f0ff1187ff17f0ff0be00000000000000000000000000000000000000000 +00000000003fff03f0ff0be0000000000000000000000000000000000000000000000000 +003fff03f0ff0be0000000000000000000000000000000000000000000000000003fff03 +f0ff0be0000000000000000000000000000000000000000000000000003fff03f0ff0be0 +000000000000000000000000000000000000000000000000003fff03f0ff0be0ff18f83f +ff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0 +ff18f83fff03f0ff0be0ff18f83fff03f0ff05f803ff04e0ff18f83fff03f0ff05c0007f +ff03e0ff18f83fff03f0ff0580003fff03e0ff04f00fff12f83fff03f0ff04fe0ffc1fff +03e0ff04f00fff12f83fff03f0ff04fc3fff010fff03e0ff04fc3fff12f83fff03f0ff04 +fcff02c7ff03e0ff04fc7fff12f83fff03f0ff04fdff02e7ff03e0ff04fc7fff01fe7fff +07f3ff07f83fff03f0ff0be0ff04fc7fff01fe7fff07f3ff07f83fff03f0ff0be0ff04fc +7fff01fc7fff07e3ff07f83fff03f0ff07e7ff03e0ff04fc7e20f01f07f03807f81f0780 +fc1fc0ff04f83fff03f0ff07c7ff03e0ff04fc78007c7c63c00001e00c63e3f18f007fff +03f83fff03f0ff0787ff03e0ff04fc7e3c7c7cf1f038e1f81cf1e3f3c7c0ff04f83fff03 +f0ff06fc07ff03e0ff04fc7e3c7c78f1f1f8f0f8f8f1e3e3c7c7ff04f83fff03f0ff06f0 +07ff03e0ff04fc7e3c7c7801f1f8f8f8f801e3e007c7ff04f83fff03f0ff068007ff03e0 +ff04fc7e3c7c79ff01f1f8f8f8f9ff01e3e7ff01c7ff04f83fff03f0ff05fc01e7ff03e0 +ff04fc7e3c7c79ff01f1f8f8f8f9ff01e3e7ff01c7ff04f83fff03f0ff05f003ff04e0ff +04fc7e3c7c78ff01f1f8f8f8f8ff01e3e3ff01c7ff04f83fff03f0ff05c01ff7ff03e0ff +04fc7e3c7c78fdf1f8f9f8f8fde3e3f7c7ff04f83fff03f0ff05e03fe7ff03e0ff04fc7e +3c7c6c39f1f8f1f8fc39e370e7c7ff04f83fff03f0ff05fc1fc7ff03e0ff04fc3e3c7c0c +03f1f863f8fc03e0700fc7ff04f83fff03f0ff068307ff03e0ff04f008181c1e07c0f807 +e07e07e0f81f03ff04f83fff03f0ff06e007ff03e0ff0bf8ff0cf83fff03f0ff06c007ff +03e0ff0bf8ff0cf83fff03f0ff0600e7ff03e0ff0bf8ff0cf83fff03f0ff05f801e7ff03 +e0ff0bf8ff0cf83fff03f0ff05c00fff04e0ff0bf0ff0cf83fff03f0ff05c07fff04e0ff +0be03fff0bf83fff03f0ff05e03fff04e0ff18f83fff03f0ff05fe07ff04e0ff18f83fff +03f0ff06c027ff03e0ff18f83fff03f0ff06f007ff03e0ff18f83fff03f0ff06fe07ff03 +e0ff18f83fff03f0ff07c7ff03e0ff18f83fff03f0ff07e7ff03e0ff18f83fff03f0ff07 +e7ff03e0ff18f83fff03f0ff0be000000000000000000000000000000000000000000000 +0000003fff03f0ff05dff7ff04e000000000000000000000000000000000000000000000 +0000003fff03f0ff05dff3ff04e000000000000000000000000000000000000000000000 +0000003fff03f0ff05c003c7ff03e0ff18f83fff03f0ff05c003c7ff03e0ff18f83fff03 +f0ff05c003c7ff03e0ff18f83fff03f0ff05dfff05e0ff18f83fff03f0ff0be0ff18f83f +ff03f0ff0be0ff18f83fff03f0ff05f83fff04e0ff18f83fff03f0ff05e00fff04e0ff18 +f83fff03f0ff05c007ff04e0ff18f83fff03f0ff05c3c3ff04e0fe07ff013ffe3fff0507 +ff0181ff0af83fff03f0ff05cffbff04e0f801f83ffe3fff0503ff0181ff0af83fff03f0 +ff05cffbff04e0f0f8fe3ffe3fff05c1ff0107ff0af83fff03f0ff05cffbff04e0e1fc3e +3fff07c1ff0107ff0af83fff03f0ff05c7f3efff03e0e3fe3e3fff05cfff01c1ff0147ff +0af83fff03f0ff05c0000fff03e0c7fe3e3fff05cfff01c0fe47ff0af83fff03f0ff05c0 +0007ff03e0c7ff011e3fff058fff01c8fe47ff0af83fff03f0ff05c00007ff03e087ff01 +1e20ff013f83fc1e03ff01c87e47f81f883f81fe07fc1fc0f83fff03f0ff05cfff05e087 +ff011e007c3e31f18f8fff01c87cc7f18e001f18fce0f18f00783fff03f0ff05cfff05e0 +87ff011e387e3e78f18f8fff01cc7cc7f18f8f1f18f8f0f3c7c0f83fff03f0ff0be087ff +011e3c3e3c78e3cf8fff01cc38c7f38f8f1f38f8f3e3c7c7f83fff03f0ff0be087ff011e +3e3e3c00e7ff018fff01cc39c7fe0f8f1fe0f8f3e007c7f83fff03f0ff04fc7fff05e087 +ff011e3e3e3cff01e7ff018fff01ce13c7fc0f8f1fc0f8f3e7ff01c7f83fff03f0ff04f8 +470fff04e0c7ff013e3e3e3cff01e7ff018fff01ce13c7f98f8f1f98fc63e7ff01c7f83f +ff03f0ff04f90207ff04e0c3fe3e3e3e3c7fe3ff018fff01cf07c7f38f8f1f38fe07e3ff +01c7f83fff03f0ff04f18003ff04e0e3fe3e3e7e3c7ee3f78fff01cf07c7e38f8f1e38fc +7fe3f7c7f83fff03f0ff04f388fbff04e0f1fc7e3c7e3e1cf0e78dff01cf87c7e10b8f1e +10b8ff01f0e7c7f83fff03f0ff04f38dfbff04e0f070fe18fe3e01f00f81ff01c78783e0 +038f1e003807f00fc7f83fff03f0ff04f38dfbff04e0f801fe01fe3f03f81f83ff0103ce +01f0420607043801f81f03f83fff03f0ff04f38cf3ff04e0ff04fe3fff0dfc00ff03f83f +ff03f0ff04f98c03ff04e0ff04fe3fff0df1fcff03f83fff03f0ff04f89e07ff04e0ff04 +fe3fff0df3f8ff03f83fff03f0ff04fc1fe7ff04e0ff04e23fff0df0f0ff03f83fff03f0 +ff04fc3fe7ff04e0ff04e07fff0df803ff03f83fff03f0ff0be0ff04f0ff0efc0fff03f8 +3fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff05f81fff04e0ff18f83fff +03f0ff05e007ff04e0ff18f83fff03f0ff05c187ff04e0ff18f83fff03f0ff05c7b3ff04 +e0ff18f83fff03f0ff05c7b3ff04e0ff18f83fff03f0ff05cfbbff04e000000000000000 +0000000000000000000000000000000000003fff03f0ff05cfb3ff04e000000000000000 +0000000000000000000000000000000000003fff03f0ff05cf83ff04e000000000000000 +0000000000000000000000000000000000003fff03f0ff05c787ff04e0ff18f83fff03f0 +ff05f38fff04e0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff06 +fbff04e0ff18f83fff03f0ff06fbff04e0ff18f83fff03f0ff05c001ff04e0ff18f83fff +03f0ff05c0007fff03e0ff18f83fff03f0ff05c0003fff03e0ff18f83fff03f0ff05cffb +ff04e0ff18f83fff03f0ff05cffbff04e0ff06e0001fff03f3e7ff01c7ff08f83fff03f0 +ff05e7ff05e0ff06e0001fff038307ff01c7ff08f83fff03f0ff0be0ff06e78f9fff03e3 +c7ff01c7ff08f83fff03f0ff0be0ff06e78f9fff03e3c7ff0af83fff03f0ff0be0ff06ef +8fdfff03e3c7ff02cfff07f83fff03f0ff0be0ff06ef8fdfff03e3c7ff02cfff07f83fff +03f0ff0be0ff078fff04e3c7ff028fff07f83fff03f0ff0be0ff078ffe1ffc3fe3c60786 +03ff07f83fff03f0ff0be0ff078ff8c7f18fe3c71f078fff07f83fff03f0ff0be0ff078f +f1e3e3c7e3c67fc78fff07f83fff03f0ff0be0ff078ff3e1e7c3e3c4ff01c78fff07f83f +ff03f0ff05f0ff05e0ff078fe3f1c7e3e3c1ff01c78fff07f83fff03f0ff05c0fc3fff03 +e0ff078fe3f1c7e3e3c1ff01c78fff07f83fff03f0ff05c3f80fff03e0ff078fe3f1c7e3 +e3c0ff01c78fff07f83fff03f0ff05c7f00fff03e0ff078fe3f1c7e3e3c07fc78fff07f8 +3fff03f0ff05cfe0c7ff03e0ff078ff1f3e3e7e3c63fc78fff07f83fff03f0ff05dfe1e7 +ff03e0ff078ff1e3e3c7e3c61fc78dff07f83fff03f0ff05dfc3e7ff03e0ff0787f8c7f1 +8fe3c70fc781ff07f83fff03f0ff05cf87e7ff03e0ff06fe01fc0ff81f8103030383ff07 +f83fff03f0ff05cf07e7ff03e0ff18f83fff03f0ff05c60fc7ff03e0ff18f83fff03f0ff +05c01f87ff03e0ff18f83fff03f0ff05e03e07ff03e0ff18f83fff03f0ff05f87e7fff03 +e0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff +03f0ff0be0ff18f83fff03f0ff05f81fff04e0ff18f83fff03f0ff05e007ff04e0ff18f8 +3fff03f0ff05c187ff04e0ff18f83fff03f0ff05c7b3ff04e0ff18f83fff03f0ff05c7b3 +ff04e0ff18f83fff03f0ff05cfbbff04e000000000000000000000000000000000000000 +0000000000003fff03f0ff05cfb3ff04e000000000000000000000000000000000000000 +0000000000003fff03f0ff05cf83ff04e000000000000000000000000000000000000000 +0000000000003fff03f0ff05c787ff04e0ff18f83fff03f0ff05f38fff04e0ff18f83fff +03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff05dff7 +ff04e0ff18f83fff03f0ff05dff7ff04e0ff18f83fff03f0ff05c003ff04e0ff18f83fff +03f0ff05c003ff04e0ff18f83fff03f0ff05c003ff04e0ff18f83fff03f0ff05dfe3ff04 +e0ff18f83fff03f0ff06e3ff04e0ff18f83fff03f0ff06e3ff04e0ff18f83fff03f0ff06 +e7ff04e0ff18f83fff03f0ff0be0ff18f83fff03f0ff06fbff04e0ff18f83fff03f0ff06 +f3ff04e0ff18f83fff03f0ff06c3ff04e0ff18f83fff03f0ff05fe03ff04e0ff18f83fff +03f0ff05f803ff04e0ff18f83fff03f0ff05e00bff04e0ff18f83fff03f0ff05c0ff05e0 +ff07c0180f00ff01c030007fff08f83fff03f0ff05c1ff05e0ff07c03c0f00ff01c03000 +3fff08f83fff03f0ff05f07bff04e0ff07f07e3fc3ff01f0fc3e1fff08f83fff03f0ff05 +fe0bff04e0ff07f83c7fc7ff01f1fc7f0fff08f83fff03f0ff06c3ff04e0ff07fc38ff01 +c7ff01f1fc7f0fff08f83fff03f0ff06f3ff04e0ff07fe19ff01c7ff01f1fc7f8fff08f8 +3fff03f0ff06fbff04e0ff07fe19ff01c7ff01f1fc7f0fff08f83fff03f0ff0be0ff0803 +ff01c7ff01f1fc7f1fff08f83fff03f0ff0be0ff0887ff01c7ff01f1fc7c1fff08f83fff +03f0ff05f81fff04e0ff0887ff01c7ff01f1fc003fff08f83fff03f0ff05e007ff04e0ff +0883ff01c7ff01f1fc3e1fff08f83fff03f0ff05c187ff04e0ff0801ff01c7ff01f1fc7f +0fff08f83fff03f0ff05c7b3ff04e0ff0821ff01c7ff01f1fc7f87ff08f83fff03f0ff05 +c7b3ff04e0ff07fe30ff01c7ff01f1fc7f87ff08f83fff03f0ff05cfbbff04e0ff07fc70 +7fc7fef1fc7fc7ff08f83fff03f0ff05cfb3ff04e0ff07f8f83fc7fcf1fc7f87ff08f83f +ff03f0ff05cf83ff04e0ff07f9f83fc7f8f1fc7f0fff08f83fff03f0ff05c787ff04e0ff +07f1fc1fc3f1f0fc3e0fff08f83fff03f0ff05f38fff04e0ff07c0f80f0001c030001fff +08f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0ff0be0ff18f83fff03f0 +ff05dff7ff04e0ff18f83fff03f0ff05dff7ff04e0ff18f83fff03f0ff05c003ff04e0ff +18f83fff03f0ff05c003ff04e0ff18f83fff03f0ff05c003ff04e0ff18f83fff03f0ff05 +dfe3ff04e0ff18f83fff03f0ff06e3ff04e0ff18f83fff03f0ff06e3ff04e0ff18f83fff +03f0ff06e7ff04e0ff18f83fff03f0ff0be0ff18f83fff03f0ff04fdff02e7ff03e0ff18 +f83fff03f0ff04fcff02e7ff03e0ff18f83fff03f0ff04fc7fff018fff03e0ff18f83fff +03f0ff04fe0ffc1fff03e0ff18f83fff03f0ff0580003fff03e0ff18f83fff03f0ff0580 +007fff03e0ff18f83fff03f0ff05f803ff04e0ff18f83fff03f0ff0be0ff18f83fff03f0 +ff0be0ff18f83fff03f0ff0be00000000000000000000000000000000000000000000000 +00003fff03f0ff0be0000000000000000000000000000000000000000000000000003fff +03f0ff0be0000000000000000000000000000000000000000000000000003fff03f0ff0b +e0000000000000000000000000000000000000000000000000003fff03f0ff0be0000000 +000000000000000000000000000000000000000000003fff03f0ff29f0ff29f0ff29f0ff +29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff +29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0ff29f0f0123456789abcdef012345678 + +showpage +%%Trailer diff --git a/doc/irixiraf.ms b/doc/irixiraf.ms new file mode 100644 index 00000000..50523945 --- /dev/null +++ b/doc/irixiraf.ms @@ -0,0 +1,632 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +IRIX/IRAF Installation Guide +.AU +Steve Rooke +Mike Fitzpatrick +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +June 1989 +.br +Revised July 1992 + +.AB +This document describes how to install IRAF on an IRIX workstation or +server, or update an existing installation. Both standalone and networked, +multiple architecture configurations are described. Only those issues which +one must understand to install IRIX/IRAF are discussed here; a companion +document, \fIUNIX/IRAF Site Manager's Guide\fR, deals with other issues +such as interfacing new devices, configuring the IRAF networking system, +adding layered software, and so on. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling IRIX/IRAF\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Install the files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Installing from a network distribution\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing from tape\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Configuring the BIN directories\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.3.\h'|0.9i'Merge local revisions back into the new system\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.4.\h'|0.9i'Run the INSTALL Script\l'|5.6i.'\0\06 +.sp +3.\h'|0.4i'\fBSystem Checkout\fP\l'|5.6i.'\0\08 +.sp +\fBAppendix A.\0A Complete Example\fP\l'|5.6i.'\0\09 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Before installing IRIX/IRAF, one must 1) obtain an appropriate IRIX/IRAF +distribution, e.g., from the IRAF network archive on \f(CWiraf.noao.edu\fR +(or by ordering a tape distribution from NOAO), 2) select the server or node +on which the system is to be installed and arrange for sufficient disk space +to hold the system, and 3) set aside sufficient time to do the +installation. If these directions are followed carefully and mistakes are +avoided the basic installation should only take a half hour or so. +Additional time may be required to customize the system, to configure the +local tape drives and other devices, set up IRAF networking, and so on. +.PP +This Installation Guide is intended primarily for sites installing IRAF on +an SGI workstation running IRIX 4.0.x or later. Other popular UNIX systems +for which IRAF is available, e.g. Ultrix and SunOS, have their own system +specific IRAF installation guides. + +.NH +Installing IRIX/IRAF +.PP +Although the details of how IRIX/IRAF is installed or updated depend upon the +type of distribution and the desired local system configuration, the basic +procedure is always the same. First one obtains the distribution files, +then one follows the procedure outlined below to install the system. Most +of these steps should be performed while logged in as IRAF; superuser +permission is required in the final stages of the installation, to run the +\fIinstall\fP script. +.PP +System managers familiar with the installation of typical UNIX programs +should beware that IRAF, being a large system in its own right and not a +UNIX program, does not always follow to the usual conventions. It is wise +to read and adhere to the installation instructions to avoid problems. +.XS +\fR# Prepare the root IRAF directory.\fP +if new installation + create iraf account +else if updating an old installation + save locally modified files; delete old system + +\fR# Install the files.\fP +login as iraf +unpack the core system distribution +configure the BIN directories + +\fR# Merge local revisions into new system.\fP +if updating an old installation + merge locally modified files back into new system + +run the iraf install script to complete the installation +checkout the new system +.XE +.PP +If problems should arise during the installation help is available via the +IRAF HOTLINE (602-323-4160), or by sending email to \f(CWiraf@noao.edu\fP. + +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation then you will be replacing +IRAF by the new version, and IRAF should already have an account and root +directory on the desired host system. You should save any locally modified +files and delete the old system, e.g., login as IRAF and enter something +like the following. +.XS +% cd $iraf\(dg +% tar -cf /scr0/oiraf.tar local dev unix/hlib +% /bin/rm -rf * +.XE +.FS +\(dg\0\(CW$iraf\fP symbolizes the UNIX pathname of the root IRAF directory. +If no "iraf" environment variable is defined just supply the actual pathname. +.FE +.PP +There are many possible variations on this, e.g., you could use \fImv\fR to +move the above directories to someplace outside the main IRAF directory +tree. Although it is probably simplest and safest to save entire +directories as in the example, in practice only a few files are likely to +have been modified. These are the following. +.XS +dev/graphcap +dev/hosts +dev/tapecap +dev/termcap +hlib/extern.pkg +hlib/login.cl +hlib/zzsetenv.def +local/.login +.XE +.PP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. It is important to delete the old system first to +avoid creating junk files or directories when the new system is installed +(due to file or directory name changes or deletions). Once the new system +has been restored to disk, do \fInot\fR merely restore the files saved above, +as you will need to carefully merge local changes into the versions of the +files supplied with the new IRAF release (more on this later). +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set +up a new account for the user `\f(CWiraf\fP'. This is necessary for IRAF +system management, which should always be done from the IRAF account. The +IRAF account has special login files which set up a custom UNIX environment +for IRAF system management. Having an IRAF account provides a convenient +place (the IRAF system manager's login directory) to keep scratch files +created during system configuration. +.PP +The location of the IRAF root directory is arbitrary. Our practice here is +to locate the software in a system file storage area separate from the IRIX +files (to simplify OS upgrades), and then use a symbolic link such as +/iraf or /usr/iraf to point to the actual root directory. This makes life +simpler if IRAF is NFS mounted on several machines and it is later necessary +to move the IRAF files. Try to keep the path to the physical IRAF root +directory short to avoid filename truncation problems when IRAF is run. +.PP +The login directory for the iraf account should be $iraf/local (e.g., +/iraf/iraf/local), rather than the IRAF root directory $iraf as one might +expect. This is done to provide a work area for local files separate from +the main IRAF directory tree, to simplify updates and make it easier to keep +track of what has been locally added and what is standard IRAF. In any +case, make sure that when the IRAF account is set up the login directory is +set correctly, or the IRAF environment will not be set up properly, and +later problems are sure to result. +.PP +A typical IRAF installation consists of the main IRAF release, a number of +BIN directories (the IRAF binaries), and additional directories for layered +software such as STSDAS, PROS, and so on. If sufficient disk space is +available to keep everything in one area the following directory structure +is recommended. +.XS +/iraf/iraf \fR# iraf root directory ($iraf)\fP +/iraf/iraf/local \fR# iraf login directory (~iraf)\fP +/iraf/irafbin \fR# iraf BIN directories\fP +/iraf/irafbin/bin.irix \fR# IRIX binaries - iraf core system\fP +/iraf/irafbin/noao.bin.irix \fR# IRIX binaries - iraf NOAO package\fP +/iraf/stsdas \fR# layered package\fP +/iraf/xray \fR# layered package\fP + \fI(etc.)\fP +.XE +.PP +For the purpose of this example we assume that the IRAF files are stored in +/iraf; as we say this might be a link and the actual directory is +arbitrary. Given this directory the IRAF root $iraf would be "/iraf/iraf/" +and the login directory for the IRAF account would be /iraf/iraf/local. The +binaries for the core IRAF system would be in /iraf/irafbin/bin.irix, +with a link $iraf/bin.irix pointing to this directory (more on this +later). +.PP +Given the above directory structure the \f(CWpasswd\fR file entry for the +IRAF account would be something like the following. +.XS +iraf:2drP8tNQ:312:12:IRAF system login:/iraf/iraf/local:/bin/csh +.XE +.PP +Do not worry about configuring the environment files for the new account as +these will be created when the iraf system is later restored to disk. + +.NH 2 +Install the files +.PP +If you are installing from tape skip forward to \(sc2.2.2. If you are +installing from a network distribution (i.e., from disk) continue with the +next section. +.NH 3 +Installing from a network distribution +.PP +IRIX/IRAF is available over the network via anonymous ftp from the node +\f(CWiraf.noao.edu\fR, in the subdirectory \f(CWiraf/v\fInnn\fP/IRIX\fR, +where "\f(CWv\fInnn\fR" is the IRAF version number, e.g., subdirectory +\f(CWiraf/v210/IRIX\fR for V2.10 IRIX/IRAF. +.PP +If IRAF is being installed from a network distribution all the architecture +independent IRAF files for both the core IRAF system and the NOAO packages +will be in the distribution file \f(CWas.irix.gen\fR. This "file" is stored +in the network archive as a directory wherein the large distribution file +has been split into a number of smaller pieces, e.g., +.XS +% ls as.irix.gen +CHECKSUMS as.irix.gen.Z.12 as.irix.gen.Z.26 +FILES.Z as.irix.gen.Z.13 as.irix.gen.Z.27 +as.irix.gen.Z.00 as.irix.gen.Z.14 as.irix.gen.Z.28 +as.irix.gen.Z.01 as.irix.gen.Z.15 as.irix.gen.Z.29 +as.irix.gen.Z.02 as.irix.gen.Z.16 as.irix.gen.Z.30 +as.irix.gen.Z.03 as.irix.gen.Z.17 as.irix.gen.Z.31 + \fI(etc.)\fP +.XE +.LP +Assume that the directory \f(CWas.irix.gen\fR as shown above has been +recreated somewhere on the machine on which IRAF is to be installed. +We can restore the main IRAF source tree as follows. +.XS +% whoami +iraf +% cd $iraf +% cat /\fIpath\fP/as.irix.gen/as.* | uncompress | tar -xpf - +.XE +After the above finishes the root IRAF directory should appear as follows +(this is for V2.10). +.XS +HS.IRIX.GEN bin.generic lib noao +IS.PORT.GEN bin.irix local pkg +README dev math sys +bin doc mkpkg unix +.XE +The files \f(CWbin.irix\fR (and others for multiple architectures) are links +to the IRAF BIN +directories (for binary executables), which probably do not exist yet. +Configuring the BIN directories is discussed in section \(sc2.2.3. +.NH 3 +Installing from tape +.PP +If you have not already done so, log into the IRAF account so that the files +when restored will belong to IRAF. Mount the distribution tape, which may +be a cartridge tape, a 6250 bpi 9 track tape, a DAT tape, an Exabyte, or +whatever. +.PP +IRAF distribution tapes consist of multiple files separated by tape marks, +with a TOC (table of contents) file as the first file on the tape. To find +out what is on the tape, rewind it and read out the TOC file as follows (the +actual device name will likely be different than that shown in the examples). +.XS +% mt -f /dev/nrtape rew; cat /dev/nrtape +.XE +This should cause a TOC file to be listed similar to the following, except +for the file names which will vary depending upon what type of distribution +you have (also the file sizes are now somewhat larger than what is shown). +The example below is for a distribution of IRIX/IRAF with the binaries. +.XS +0 Table of Contents + +1 AS.IRIX.GEN nn.n Mb IRAF, NOAO packages and IRIX/OS sources +2 IB.IRIX.MIP nn.n Mb IRIX binaries for IRAF system +3 NB.IRIX.MIP nn.n Mb IRIX binaries for NOAO packages +.XE +.PP +Here, the first column is the file number on the tape, the TOC file being +file zero (the first distribution file is number one), the second column is +the name of the tape file, the third column is the file size in megabytes +(this tells you how much space will be needed to unpack the file on disk), +and the last column is a description of the file contents. +.PP +There are three types of tape files in the example shown: the \f(CWAS\fR +file, which is all the IRAF sources (the core IRAF system, NOAO packages, +and the IRIX host system interface), the \f(CWIB\fR files, or IRAF core +system binaries, one for each architecture, and the \f(CWNB\fR files, or +NOAO package binaries. The NOAO package sources are included in the +\f(CWAS\fR file since most people requesting IRAF are expected to want the +astronomical reduction software, although IRAF can be configured without +this if desired. All of the file objects are UNIX \fItar\fR format files, +with the exception of the TOC file which is a simple text file. The +distribution files may be compressed if this was necessary to fit all the +files on a tape. +.PP +In the above example, the \f(CWIRIX\fR in the file names indicates that +these files are for SGI IRIX. A SunOS version 4 distribution is +indicated by a \f(CWSOS4\fR in the file names, and a DECstation Ultrix +distribution is indicated by a \f(CWDSUX\fP, and so on. In principle a +given distribution tape may contain any combination of these files. +.PP +The following commands would suffice to restore the main IRAF system to +disk, given the distribution tape described by the TOC file in our example +above. Once again, the tape device file and block size shown in the example +will very likely have to be changed to whatever is needed for the tape +device being used (the example is for a cartridge drive). +.XS +% whoami +iraf +% cd $iraf +% mt -f /dev/nrtape rew; mt -f /dev/nrtape fsf 1 +% tar -o -xpbf 126 /dev/nrtape +.XE +.PP +After the above tar file read operation, the tape is left positioned to +\fIjust before the EOF of the file just read\fR, since \fItar\fP stops +reading the file data before reading the physical EOF. Hence, an +\fImt\0fsf\fR will be required to position to the next file on the tape. +Any combination of \fIfsf\fP (forward skip file) or \fIbsf\fR (backward skip +file) operations may be used to position to a file on a 9 track tape. On a +cartridge tape, it is best to plan things so that only forward file skips +are used, using a rewind and forward skip if it is necessary to position to +an earlier file on the tape. +.PP +Once the main system, containing only sources, is installed it is possible to +create one or more empty BIN directories for the executables, then compile +and link the full system. More commonly one will merely read the precompiled +executables off the distribution tape, as we discuss in the next section. +.NH 3 +Configuring the BIN directories +.PP +In IRAF all the files specific to any particular architecture, e.g., IRIX +or SunOS are contained in +a single directory called the BIN, or "binary", directory. To run IRAF +you must install not only the \f(CWAS\fR (all-sources) directory tree, but +the BIN directories (the IRAF core system and the NOAO packages have separate +BIN directories). +.PP +The BIN directories for the IRAF core system or a layered package (such as +NOAO) are located, logically or physically, in the root directory of the +IRAF core system or layered package. Every layered package has its own set +of BIN directories. In the distributed V2.10 system you will find the +following BIN files (directories or symbolic links) at the IRAF root. +.XS +link bin -> bin.generic +directory bin.generic +link bin.irix -> ../irafbin/bin.irix +link noao/bin.irix -> ../../irafbin/noao.bin.irix +.XE +.PP +If the IRAF directory structure is set up as described in \(sc2.1.2, with +$iraf located at iraf/iraf and the BIN directories stored in iraf/irafbin, +then these links will not have to be modified. If a different directory +structure is used you will have to modify the links accordingly. +.PP +The \fIbin\fR link and the \fIbin.generic\fR directory are required for the +correct operation of the IRAF system software (\fImkpkg\fR) and are +maintained automatically by the IRAF software management utilities. +\fIUnder no circumstances should "bin" or "bin.generic" be modified or +deleted\fR. It is a very common error to manually delete the bin link and +manually set it to bin.irix or some other architecture. The bin.irix link +can be modified as desired but bin and bin.generic should be left alone. +.PP +Assume that the bin.irix directory has been created somewhere (e.g. in the +iraf/irafbin directory) and that the \f(CWib.irix.mip\fR distribution files +for the core IRAF system IRIX binaries have been downloaded from the +network archive. We can restore the IRIX binaries with the following +commands. +.XS +% cd $iraf/bin.irix +% cat /\fIpath\fP/ib.irix.mip/ib.* | uncompress | tar -xpf - +.XE +Similarly, to restore the NOAO package IRIX binaries: +.XS +% cd $iraf/noao/bin.irix +% cat /\fIpath\fP/nb.irix.mip/nb.* | uncompress | tar -xpf - +.XE +Note that when restoring the NOAO package binaries that the bin is yet +another link to the \f(CWirafbin\fR directory, and specifically to a +\f(CWnoao.bin.irix\fR directory the installer has created within +\f(CWirafbin\fR. +.PP +The procedure for restoring a BIN directory from a tape distribution is +similar to that described in \(sc2.2.2 for the core system. For example, +.XS +% cd $iraf/bin.irix +% mt -f /dev/nrtape rew; mt -f /dev/nrtape fsf 2 +% tar -o -xpbf 126 /dev/nrtape +.XE +would restore the core system bin.irix directory from a cartridge tape +containing an uncompressed \f(CWib.irix.mip\fR as file 2 on the tape. + +.NH 2 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure to not replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF.\(dg +.FS +\(dgThe UNIX utility \fIdiff\fP is useful for comparing files to see +what has changed. +.FE +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each +site to maintain their own custom LOCAL package external to the core IRAF +system. The core system LOCAL is now only a \fItemplate-local\fR to be +copied and used as the starting point for a custom LOCAL layered package. +The layered software enhancements, and the procedure for building a custom +LOCAL, are discussed further in the \fIUNIX/IRAF Site Manager's Guide\fR. + +.NH 2 +Run the INSTALL Script +.PP +Once all of the IRAF files have been restored to disk the IRIX/IRAF +installation script must be run to complete the system installation. The +install script modifies the system as necessary to reflect the new root +directory and new default image storage and local bin directories, checks +the mode and ownership of a number of files, installs a small set of IRAF +commands in UNIX, and so on. +.LP +To make a trial run of the install script, enter the following commands: +.XS +% setenv iraf /\fIpath\fP/iraf/ +% cd $iraf/unix/hlib +% source irafuser.csh +% ./install -n +.XE +and answer the questions (don't forget the trailing `/' in the "setenv +iraf"). The "-n" argument tells install to go through the motions without +actually doing anything, so that one can see what will be done before +committing to it. +.PP +Installing IRAF requires a few changes to be made to system directories +outside the IRAF directory tree. Two fifo device entries are made in /dev. +A symbolic link "iraf.h" is created in /usr/include. A number of links (cl, +mkiraf, etc.) are made in /usr/local/bin or some similar directory which +most users can be expected to have in their search path. The tape +allocation task alloc.e is made suid root (there are no known security +loopholes, although we cannot make any guarantees). A symbolic link +imtoolrc is created in /usr/local/lib. +.PP +Following one or more trial "no execute" ("-n") runs to see what the install +script will do, the install script should be run without the "-n" to +complete the installation. This must be done by the superuser as superuser +permission is required to carry out the necessary additions to UNIX. +.PP +It is necessary to run the install script separately on each node from which +IRAF will be used. If a single version of IRAF is installed on a server and +NFS mounted on one or more clients, the install script must be run first on +the server and then on \fIeach\fR client (when installing on a client there +will be warnings about insufficient permission to make changes to files on +the NFS mounted partitions, which can be ignored). To install IRAF on a +diskless client it may be necessary to run the install script \fIon the +server\fR to do the install for the client, since the client's /usr/include +and /dev directories may only be writable by root on the server. On some +systems /usr is mounted read-only, and must be unmounted and remounted +read-write before doing the installation to allow an entry to be made in +/usr/include. Once the installation is complete the default mount access +mode may be restored. +.LP +The exchange with the install script will be along the lines of the +following. +.XS +% ./install -n +new iraf root directory (/iraf/iraf): +default root image storage directory (/d0/iraf): +local unix commands directory (/usr/local/bin): +install iraf for machine type irix +old iraf root = /usr/iraf, old imdir = /d0/iraf +installing iraf at /iraf/iraf, imdir=/d0/iraf, lbindir=/usr/local/bin +proceed with installation? (yes): +.XE +.LP +The "iraf root directory" is the value of $iraf (minus the trailing `/'in +this case). The "root image storage directory" is the default place to put +image data for users; the program may prompt with /tmp if it cannot find any +likely looking data storage areas on your system, but /tmp is not a good +place to put image data as the contents are deleted whenever the system +reboots. The value entered should be the path to a public iraf subdirectory +of a designated data or scratch disk on your system. Lastly, the "local +unix command directory" is where the UNIX callable IRAF startup commands +will be defined. This should be a UNIX directory which is in the default +path of anyone who might want to use IRAF; /usr/local/bin is the most common +value. +.PP +After answering with "yes" or hitting return in response to the "proceed with +installation" query, the script will issue a series of messages as it checks +the system and performs the installation, possibly answering additional +questions in the process. + +.NH +System Checkout +.PP +The basic IRAF system should be usable once the files have been restored to +disk, the binaries have been configured or generated, and the install script +has been run. To verify that the basic system comes up and runs +successfully, login as iraf and startup the CL (IRAF command language) from +the iraf account. You should be able to login as IRAF and type "cl" to +start IRAF, using the login files which come with the distributed system. +.XS +% login iraf +% cl +.XE +.LP +To more thoroughly test the installation it is a good idea to test IRAF from +a user account. To do this you login to a user account and run the +\fImkiraf\fR task to set up the IRAF login files. This will create or +initialize the user's \f(CWuparm\fP (user parameter) directory, and create a +new \f(CWlogin.cl\fP file. It may also be desirable to edit the +user's \f(CW.login\fP file to modify the way the environment variable +\f(CWIRAFARCH\fP is defined. This variable, required for software +development but optional for merely using IRAF, must be set to the name of +the desired machine architecture, in this case \fIirix\fR. +.XS +% mkiraf +Initialize uparm? (y|n): y +Terminal types: xterm,gterm,vt640,vt100,etc." +Enter terminal type: xterm +A new LOGIN.CL file has been created in the current directory. +You may wish to review and edit this file to change the defaults. +.XE +The \fIcl\fR command should now start up the CL, which will clear the screen +and print out a startup message. The standard test procedure included in +Volume 1A of the \fIIRAF User Handbook\fP should be run to verify the +installation. + +.bp +.SH +Appendix A. A Complete Example +.PP +Assume we are installing IRAF for the first time on an Indigo. The IRAF +directories will be located at /u3/iraf using a symbolic link /iraf to point +to this location. The BIN directories will be located in the directory +/iraf/irafbin. The local user commands will be placed in /usr/local/bin. +We will be installing from a network distribution with the distribution +files located in /scr0. +.PP +The first step is for the superuser to create an account for the fictitious +user `\f(CWiraf\fP', with home directory /iraf/iraf/local and shell +/bin/csh. The /u3/iraf directory is created owned by IRAF, and pointed to +by the link /iraf. We then login as IRAF (a warning message will be printed +since there is no login directory) and proceed as follows. +.XS +% whoami +iraf +% +% setenv iraf /iraf/iraf/ \fR# set root directory\fP +% mkdir /iraf/iraf +% +% cd $iraf \fR# unpack main IRAF distribution\fP +% cat /scr0/as.irix.gen/as.* | uncompress | tar -xpf - +% +% cd /iraf \fR# create BIN directories\fP +% mkdir irafbin +% mkdir irafbin/bin.irix +% mkdir irafbin/noao.bin.irix +% +% cd $iraf/bin.irix \fR# unpack core bin.irix\fP +% cat /scr0/ib.irix.mip/ib.* | uncompress | tar -xpf - +% +% cd $iraf/noao/bin.irix \fR# unpack NOAO bin.irix\fP +% cat /scr0/nb.irix.mip/nb.* | uncompress | tar -xpf - +% +% cd $iraf/unix/hlib \fR# run the INSTALL script\fP +% source irafuser.csh +% ./install -n +% su +# ./install +# exit +% +% cd +% source .login \fR# read new .login\fP +% rehash \fR# pick up new iraf commands\fP +% cl \fR# verify that the CL runs\fP +.XE +.LP +This will fully install IRAF on a server or a standalone system. If this +version of IRAF will be accessed via NFS by client nodes then the IRAF +install script must be run on each client node as well. Installing IRAF +does not allow one to access local tape drives, printers, and so on. +Refer to the \fIUNIX/IRAF Site Manager's Guide\fR for information on how +to configure IRAF for the local site. diff --git a/doc/mancl.hlp b/doc/mancl.hlp new file mode 100644 index 00000000..31f8111e --- /dev/null +++ b/doc/mancl.hlp @@ -0,0 +1,20 @@ +.help module date package +.ih +NAME +module -- description +.ih +USAGE +module args +.ih +PARAMETERS +.ih +DESCRIPTION +.ih +EXAMPLES +.ih +TIME REQUIREMENTS +.ih +BUGS +.ih +SEE ALSO +.endhelp diff --git a/doc/manx.hlp b/doc/manx.hlp new file mode 100644 index 00000000..ae719961 --- /dev/null +++ b/doc/manx.hlp @@ -0,0 +1,19 @@ +.help module date package +.ih +NAME +module -- description +.ih +SYNOPSIS +.nf +.fi +.ih +DESCRIPTION +.ih +RETURN VALUE +.ih +NOTES +.ih +BUGS +.ih +SEE ALSO +.endhelp diff --git a/doc/news.old.hlp b/doc/news.old.hlp new file mode 100644 index 00000000..c2c0cf80 --- /dev/null +++ b/doc/news.old.hlp @@ -0,0 +1,199 @@ +.help news Jul86 "Ancient News" +.nf +30 July 86 IMIO Modifications +------------------------------------------------------------------------------- + + The new IMIO interface, used by all IRAF tasks to access bulk image data +on disk, is now capable of operating upon both the old IRAF format (OIF) +images as well as STScI SDAS/GEIS format images. The default image type is +the OIF format. Any existing OIF format images are readable by the new system +without change. Although IRAF can read either OIF or STF format images, +SDAS can read only STF format images, so serious SDAS users should configure +IRAF to work with STF format images as the default. All other users should +continue to use the OIF format images as image access is more efficient, +and the IRAF software has been extensively tested only for OIF format images. +Users of the OIF format should note that they can read a VMS BACKUP tape +(or UNIX TAR tape) containing STF format images directly to disk and immediately +access the images, without changing the default configuration of IRAF. + + The image type is specified by a filename extension; extensions for the +OIF format images are new in this release of the system. The recognized +extensions are shown below. + + image type header file extensions + + OIF .imh + STF .??h (? stands for any character) + +In most cases when operating upon an image with an IRAF task the extension +can be omitted. The most important exception occurs in image templates. +THE PATTERN GIVEN IN AN IMAGE TEMPLATE MUST FULLY MATCH THE IMAGE HEADER +FILE NAMES AS THEY APPEAR IN A DIRECTORY LISTING, i.e., the header filename +extension must be matched by the image template. The image type extension +must also be specified to access an image which is not of the default image +type (OIF or STF), or when changing the type of an image. For example, + + cl> imcopy dev$pix.imh pix.hhh + +will make an STF format copy in the current directory of the OIF format image +"dev$pix". + +The default image type is controlled by the new environment variable IMTYPE. +The string value of IMTYPE is the desired image header file extension, e.g., +"imh" (omit the dot) for an OIF format image. If IMTYPE is not defined the +default image type is "imh". For STF format images there are many possible +image header extensions, and IMTYPE specifies the default type IMIO should +look for when the extension is not explicitly given, or the default extension +to use when a completely new image is to be created. When making a new copy +of some existing image, IMIO will make a new image of the same type as the +existing input image unless an extension is given to force some other type +of image to be created. + + environment variable description + + IMTYPE the default image type (extension) + IMDIR pixel storage directory for OIF images + +The IMDIR environment variable defines the directory in which the pixel file +is to be placed when creating a new OIF format image. In V2.2 and older +versions of IRAF, IMDIR could only be a logical or machine dependent directory +pathname. The new system also recognizes the special "builtin" logical +directory name "HDR$" (must be upper case). If the value of IMDIR is "HDR$", +IMIO will create the pixel file in the SAME directory as the header file, +rather than in some other directory. It is also possible to place the pixel +file in some subdirectory of the header directory, e.g., "HDR$pixels/" will +cause the pixel files to go into the subdirectory "pixels". + + set imdir = "/tmp/user/" # pixel files -> specified directory + set imdir = "HDR$" # pixel files -> header file directory + set imdir = "HDR$pixels/" # pixel files -> subdirectory of HDR$ + +The root filename of OIF pixel files is now the same as that of the header +file, rather than a computer generated name. The filename extension of an +OIF pixel file is ".pix". + +The STF format images support group format, a format very similar to that +used for group format FITS tapes. IRAF users accessing an STF group format +image can specify the `group' (subimage) to be accessed by appending a +subscript to the image name, e.g., + + cl> imstat pix.aah[3] # access group 3 +or + cl> imstat pix.aah[3][*,100] # line 100 of group 3 + +A new group format image can be created in a similar fashion, specifying the +number of groups to preallocate space for, e.g., + + cl> imcopy dev$pix testimage[1/10] + +would create a new group format image "testimage" with space for 10 groups +(subimages), and initialize group 1. The remaining groups would then be +initialized by specifying only the group subscript "[N]". Note that all +groups must be the same size, new groups cannot be allocated, old groups +cannot be deleted, the set of possible group parameters is fixed at creation +time, and all groups share the same FITS header. + + +15 June 86 System Tasks +------------------------------------------------------------------------------- + + The DIRECTORY, HELP, and PAGE system tasks have all undergone important +revisions. The directory task has been completely rewritten and now handles +directory pathnames, etc., correctly, and in addition it has a more concise +syntax. The HELP and PAGE tasks have been modified to replace the old "more" +boolean query mechanism (used to pause between pages of output) with a nicer +keystroke driven mechanism which offers more options and is faster. Read the +manual pages for additional details. The old parameter files should be +unlearned. + + +28 April 86 Package Reorganization +------------------------------------------------------------------------------- + + The basic package structure of IRAF has been modified to make a distinction +between the system packages and the NOAO optical astronomy packages. The basic +directory structure of the system was also changed to reflect the new package +organization, and the printed documentation will be changed as well when time +permits. These changes were necessary to better isolate science software such +as the NOAO and STScI/SDAS packages from the system software, for a more logical +package structure, and to make it easier to install and maintain the science +packages. + +The new root menu of IRAF is as follows: + + dataio images lists noao sdas system + dbms language local plot softools utilities + +The NOAO menu is as follows: + + artdata astutil focas mtlocal proto twodspec + astrometry digiphot imred onedspec surfphot + +Three new packages were added and three old packages were extensively revised. +The NOAO mountain tape readers were moved from the DATAIO package into the new +MTLOCAL package. The astronomically oriented utility tasks were moved from +the UTILITIES package to the new ASTUTIL package. The old LOCAL package was +renamed PROTO, and a new LOCAL package was added in the directory +"iraf$local/tasks". + +The concept of the new PROTO package is appropriate for what the old LOCAL +package was used for, i.e., prototype, temporary, or contributed tasks which +are part of the NOAO package and which are exported with the system, but which +are expected to eventually disappear or be replaced by planned system +facilities. The new LOCAL package is a place to put tasks of strictly local +interest, or tasks which are not portable, e.g., foreign tasks and the Peritek +package. The LOCAL package should be particularly useful for outside sites +as it gives them a place to put locally added tasks which will not be affected +by future updates of the system. Also, the framework (mkpkg, local.cl, etc.) +is all set up, making it easier for outside sites to add their own software +without having to figure out how to set up an IRAF package. + + +20 Feb 85 Recovery from Interrupts +------------------------------------------------------------------------------- + + Tests today (unfortunately only shortly before the first IRAF release) +have shown that VMS/IRAF has higher failure rate than expected for recovery +from a ctrl/c interrupt of a running subprocess, especially if the process +is actively doing i/o. It is probably much safer to interrupt a compute +bound process than a process which is doing heavy i/o, e.g., reading a tape +or doing many file opens, or probably large numbers of any type of system +calls. The failure rate for i/o intensive processes was as high as 1 failure +to recover in 4 interrupts in some of the cases tested. Testing of UNIX/IRAF +turned up some of the same problems, but the failure rate was considerably +lower, probably because the kernel and i/o system are so much simpler. + +Interrupting a process at the wrong time can cause many problems, e.g., +[1] subprocess memory can be corrupted, resulting in unpredictable behavior +and possibly deadlock when the CL later tries to talk to the process, +[2] a VMS forced exit of the process can occur, e.g., when trying to deliver +an AST to an invalid address, [3] corruption of the CL/subprocess communications +protocol can occur, resulting in deadlock or the loss of sync (the output of +a task will come out when the next command is entered), and various other +problems as well. + +Tests on the old version of VMS/IRAF, which dates back to last fall, show +that the problem has existed all along. The fact that we did not fully +appreciate the problem until now indicates that the problem is not a serious +hindrance provided one is conservative about the use of interrupts. It also +appears that this will not be an easy problem to solve, hence it is likely +to be with us for a while. Probably nothing at all will be done about it +for some months since other projects are likely to have a higher priority +if this problem is understood and can be worked around. + +In summary, try to minimize the use of interrupts, and in particular, avoid +interrupting processes which are doing heavy i/o. When in doubt, type +"flpr" after interrupting a process to force it to be restarted. If a +subprocess becomes hung it may be necessary to restart the CL itself. + + +20 Feb 85 Process connect failure during ":.snap" in cursor mode +---------------------------------------------------------------------------- + + We are still occasionally having problems when trying to spawn a graphics +subkernel in response to a ":.snap" command in cursor mode. This happens +infrequently (which is why it is so hard to find the bug), and will usually +go away after exiting and reentering cursor mode and trying again. It might +also help to do a ":.gflush" while in cursor mode. +.fi +.endhelp diff --git a/doc/news.v29.hlp b/doc/news.v29.hlp new file mode 100644 index 00000000..65d69f83 --- /dev/null +++ b/doc/news.v29.hlp @@ -0,0 +1,867 @@ +.help iraf Mar90 "V2.9 Revisions Summary" + +.ce +\fBIRAF Version 2.9 Revisions Summary\fR +.ce +April 10, 1990 +.sp 2 +.NH +Introduction + + This document summarizes the changes in IRAF version 2.9. +This was primarily +a development release intended to support applications software development, +hence the major changes were in the programming environment, although there +are important new features of interest to general users too. Since IRAF V2.9 +is primarily a development release, it is not being released on all platforms, +and it is expected that many sites will not need to upgrade until IRAF V2.10 +is available. Sites interested in obtaining IRAF V2.9 should contact the +IRAF project to determine if the release is available for a particular host +system. At the present time, the release is being made available for all +Sun systems, for VAX/VMS, and for the DECstation running Ultrix. + +What follows is a brief description of some of the new features available +in IRAF Version 2.9. This is not intended to be an exhaustive list, but +rather a brief summary of the major changes since the last +release of IRAF, Version 2.8, released in July 1989. +More detailed revisions notes are available in the system notes file, +\fIiraf$local/notes.v29\fR, as well as in the online revisions notes for +the various packages. + +Users looking for information on a particular new package should note that +if the package is not mentioned in these release notes and therefore is not +included in IRAF V2.9, that does not necessarily mean that it is not +available. Most major reduction and analysis packages are now made available +for testing as user installable layered packages before they are included in +the standard distribution. For information on the available add-on packages, +contact the IRAF group, or check the latest \fIIRAF Newsletter\fR. + + +This revisions summary is organized as follows: +.sp +.nf + 1. \fBIntroduction\fR + + 2. \fBIRAF System Revisions\fR + + 3. \fBIRAF Package Revisions\fR + 3.1. Changes to the System Packages + 3.2. Glossary of New Tasks in the IRAF System Packages + 3.3. Changes to the NOAO Packages + 3.4. Modifications and Additions to Calibration Data + 3.5. Glossary of New Tasks in the NOAO Packages + + 4. \fBProgramming Environment Revisions\fR + 4.1. Changes to the Programming Utilities + 4.2. Programming Interface Changes +.fi + +.NH +IRAF System Revisions +.NH 2 +IEEE to native floating point conversions + + Support has been added to the programming interfaces (section 4.2.3) for +converting between the IEEE floating point and native floating point data +formats, including both single and double precision. The FITS programs +in DATAIO (section 3.1.1) make use of this, allowing floating point data to +be exchanged in FITS format without having to convert to type integer. +.NH 2 +World coordinate system support + + A major new VOS interface MWCS has been added to support general world +coordinate systems (WCS) and transformations thereon (section 4.2.1). +This includes support for linear, piecewise linear or sampled WCS, +and general nonlinear WCS such as the tangent plane or gnomonic projection. + +If a FITS image is read into the system which has WCS information in the +header, the WCS will be retained in the IRAF image header and can be used +in coordinate transformations. The IMAGES tasks which move pixels around +have been modified to edit the WCS to reflect the transformation (section +3.1.2). The image i/o system will automatically propagate the WCS of an +image to a new copy of the image, and will edit the WCS as necessary if an +image section is copied (this applies to all IRAF tasks which operate upon +images). The task RIMCURSOR in the LISTS package has been rewritten to add +support for coordinate transformations (section 3.1.3), and can be used, +e.g., to read out the RA and DEC of objects on the image display using the +image cursor, if the image has the necessary WCS information in the image +header. + +Full integration of the new world coordinate facilities into all the IRAF +applications, e.g., the graphics tasks and the spectral reduction packages, +will take a year or longer due to the amount of software involved. In V2.9 +the IRAF spectral packages have not yet been converted to use MWCS, and if +MWCS is enabled it could alter the normal behavior of these packages. +\fIIRAF V2.9 is therefore shipped with MWCS disabled\fR. What "disabled" +means is that WCS information in the image headers is not edited to +reflect operations involving image sections, or geometric transformations +of images. Tasks such as RIMCURSOR which use an already existing WCS will +still work whether or not header editing is disabled. If the spectral tasks +will not be used and it is desired that world coordinates be propagated +correctly in image transformations, MWCS header editing can be enabled in +either of the following ways. + +The MWCS transformations are disabled by defining the variable "\fInomwcs\fR" +in the IRAF environment. To globally enable MWCS by default for everyone +using the system, edit the file "\fIhlib$zzsetenv.def\fR" and comment out the +following line as shown (you want to add the leading \fI#\fR, which will +be missing in the distributed version): +.sp +.nf + #set nomwcs = yes +.fi +.sp +To enable MWCS header editing temporarily, for the current IRAF run: +.sp +.nf + cl> reset nomwcs = no +.fi +.sp +Detailed information on the coordinate systems defined by MWCS can be +obtained in the online system with the command +.sp +.nf + cl> phelp mwcs$MWCS.hlp fi+ +.fi +.sp +Additional information is also given in the help page for RIMCURSOR. +.NH 2 +IMFORT changes + + The IMFORT interface (host level Fortran or C interface to the IRAF image +format) has undergone the following bug fixes and enhancements: +.in +4 +.ls 4 o +A couple of bugs associated with the IMDIR (image pixel-file directory) +feature introduced in IRAF V2.8 have been fixed. +.le +.ls 4 o +Image clobber checking has been added. By default, if you create a new +image and another image with the same name already exists, the image create +will now return an error code leaving the existing image unchanged. +To override clobber checking in IMFORT programs, restoring the previous +behavior of the interface, define "\fIclobber\fR" in your host environment. +.le +.ls 4 o +IMFORT will now perform a limited filename translation service using the +IRAF VOS filename translation code. This should allow most IRAF filenames +to be used as input to host level IMFORT programs. Full VOS filename mapping +is not provided, but filenames containing upper case characters and +multiple "." delimited fields should be translated as in IRAF programs. +.le +.ls 4 o +On systems with multiple architecture support (e.g., Sun, Convex) the FC +task, used to compile and link IMFORT programs from within the IRAF +environment, is now a script rather than a simple foreign task front end +to XC. The purpose of the script is to see that all the necessary IRAF +and host level command line switches and environment definitions +(\fIIRAFARCH\fR, \fIFLOAT_OPTION\fR, etc.) are used. +Previously, users had to make these environment definitions manually, +and if they forgot the IMFORT program could fail to link or execute. +.le +.ls 4 o +On most UNIX/IRAF systems, the host library \fI-lU77\fR is now searched +automatically by FC when an IMFORT program is linked. This library is +not used by any of the IRAF code, but is required to link some Fortran +programs that might want to use IMFORT. +.in -4 + +Users are encouraged to use FC to link their IMFORT programs. It is possible +to manually link against the IRAF libraries if you know what you are doing, +but the location of the libraries and the required host level command line +switches vary for different systems and for different architectures of a +single system, and it is easy to make mistakes. +.NH 2 +MKIRAF now copies login.cl to login.cl.OLD + + On UNIX/IRAF systems, the MKIRAF command will now copy any existing +\fIlogin.cl\fR file to \fIlogin.cl.OLD\fR, so that, for example, you +can more easily merge any custom changes back in after running MKIRAF. +On VMS/IRAF systems a new file version is created, as before. +.NH 2 +Local additions to termcap/graphcap + + The termcap and graphcap device capability files have been reorganized with +a section at the top for local additions. It is recommended that any locally +added entries be made in this area, to simplify future system updates. +The local additions can then be simply transferred to the new version of +the file when a new version of IRAF is installed (any entries which are +modified versions of standard entries should always be checked to see if +anything has changed in the distributed version). +.NH 2 +BIN directories now smaller + + On systems with multiple architecture support, the architecture save file +\fIOBJS.arc\fR stored in the BIN directory for each architecture is now +maintained as a compressed file. In a typical case this reduces the size +of the file by about a factor of two, saving 1-2 Mb of disk space in each +BIN directory. +.NH 2 +Various system buffers increased in size + + The layered software support in IRAF V2.8 (\fIextern.pkg\fR and all that) +had a problem with very long \fIhelpdb\fR environment strings, limiting the +number of external packages which could be defined. To fix this problem, +various buffers were increased in size all over the system. The +maximum length of an environment variable such as \fIhelpdb\fR is now 960 +characters (12 80 character lines of text). String parameters to tasks can +also be larger, and the system is more resistant to problems when size limits +are exceedd. Foreign task commands, OS escapes, etc., can all be larger now. +The current limit on such strings is about 1024 characters, and is defined +at sysgen time by the new system parameter \fISZ_COMMAND\fR in +\fIhlib$iraf.h\fR. +.NH 2 +Shared library versions + + The Sun/IRAF shared library mechanism was modified to add support for shared +library versions. The result is that when you install IRAF V2.9, which has a +different shared library than V2.8, any local programs or other layered +software linked under V2.8 will continue to run, because both the old V2.8 +shared library and the new V2.9 shared library are included in V2.9 (with +different version numbers). Although old programs will continue to run with +V2.9, it is recommended that they be relinked eventually to take advantage +of the many features and bug fixes provided by V2.9. In the case of very +large packages, e.g., STSDAS 1.0, it may be wise to wait until the latest +release can be obtained and installed before relinking, as the old version +will not have been tested under IRAF V2.9 (which of course, didn't exist +back then). +.NH 2 +File pager enhancements + + The system file pager, used in the PAGE task, the new PHELP task, +and other places, has undergone the following enhancements. +.le +.ls 4 o +The N and P keys, used to move to the next or previous file when paging a list +of files, now have a dual meaning: when paging a \fIsingle\fR file containing +multiple formfeed delimited pages, the keys will move to the next or previous +\fIpage\fR in the file. This feature is used in the new PHELP task to page +a large file containing, e.g., all the HELP pages for a package. +.le +.ls 4 o +A limited upscrolling capability is now supported, e.g., if you hit the 'k' +key while in the pager, the screen will be scrolled up one line in the file +being paged. This feature may not be supported for some terminals, in which +case the entire screen is redrawn at the new file location. +.NH 2 +STF image kernel enhancements + + Extensive work has been done on the STF image kernel in this release (the +STF kernel allows IRAF to access the Space Telescope image format directly). +The changes included the following. +.le +.ls 4 o +Header file caching. STF images often have quite large FITS headers which +can be time consuming to read. A header file caching scheme is now used to +optimize the kernel in cases where the same imagefile is repeatedly accessed, +e.g., when successively reading each element of a large group format image. +By default up to 3 header files will be cached; this default should be +fine for most applications. If necessary the number of cache slots can be +changed by defining the integer variable "\fIstfcache\fR" in the IRAF +environment (the builtin maximum is 5 cached headers per process). +.le +.ls 4 o +\fIThe semantics of the kernel regarding header updates have changed\fR. +STF images differ from other IRAF images in that they may consist of a +group of images all in the same file, with each individual image having +its own header (the group header), plus a single global FITS header shared +by all images in the group. This is no problem in a read operation, +but in a write or update operation there can be problems since parameters +cannot be added to or deleted from the individual group headers. +The new semantics regarding STF image header updates are as follows: +1) when updating the header of a multigroup image (not recommended) only +the group header is updated, and attempts to add new parameters are +ignored; 2) when updating the header of an image containing a single group, +both the group header and the FITS header are updated. +.sp +As a result of these changes, the behavior of a single group STF image is +now identical to that of a regular IRAF image. It is recommended that +multigroup STF images be treated as read only if possible, creating only +single group images during interactive processing (except when running a +program that is explicitly designed to create multigroup images). +.le +.ls 4 o +The kernel was modified to work with the new MWCS (world coordinate system) +interface. The image section transformation is now performed by MWCS rather +than by the STF kernel. +.le +.ls 4 o +A number of minor changes were made to the way the group parameter block (GPB) +cards are maintained in the IRAF image descriptor. The comments on GPB +definition cards are now preserved. Restrictions on the grouping of GPB +cards in the header have been removed. +.le +.ls 4 o +A number of bugs were fixed and restrictions removed, e.g., the size of a +header is no longer limited to 32767 characters (404 lines). + +The IRAF core system and NOAO science applications were extensively tested +with both single and multigroup STF images using the new kernel, and we now +feel that it is safe to use the STF image format with these tasks, +although the regular format is preferred if there is no special reason to +use the STF format (the regular format is more efficient). +.NH 2 +QPOE (event list image format) enhancements + + The QPOE image kernel, used for event list data (photon counting detectors, +e.g., X-ray satellites such as ROSAT) underwent the following changes. +.le +.ls 4 o +MWCS (world coordinate system) support has been added (section 4.2.2). This +provides a consistent coordinate system despite, e.g., the blocking factor, +rect, or image section used to construct an image matrix from an event list. +.le +.ls 4 o +When opening a QPOE file as an IRAF image, the runtime filter expression +used to create the image matrix is now saved in the parameter \fIQPFILT\fIn\fR +in the image header (multiple cards are used for long expressions). +.le +.ls 4 o +Region masks of arbitrary complexity and size can now be used to mask the +event list when reading time-ordered or unordered (unindexed) event lists. +This is done using the new PLRIO package (section 4.2.5) which provides the +capability to efficiently random access large image masks of arbitrary +complexity. +.le +.ls 4 o +Unmatched brackets, braces, or parentheses are now reported as an error by +the filter expression parser (this can occur even with a valid expression, +e.g., due to truncation of the expression string). A reference to an +undefined keyword, e.g., due to a spelling error, is now detected and reported +as an error. Any errors occurring during expression parsing will now result +in termination of the calling task, unless caught in an error handler. +.le +.ls 4 o +A number of bugs were fixed. +.NH 2 +Changes affecting image display in VMS/IRAF + + A new version of Nigel Sharp's UISDISPLAY program, for image display on +VMS systems running UIS, has been installed in "\fIiraf$vms/uis\fR". +An executable for an early version of the SAOIMAGE display program for the +X window system, written by Mike VanHilst (SAO), and ported to VMS by Jay +Travisano (STScI) has been placed in the directory "\fIiraf$vms/x11\fR". +An executable for a VMS version of XTERM (the X window terminal emulator, +ported to VMS by Stephan Jansen), is also in this directory. We wanted our +VMS users to have access to these programs, although more development work +and testing is needed before we can offer good support for X window based +image display and graphics on VMS. A more comprehensive package providing +enhanced capabilities should be available as an add-on later this year. + +.NH +IRAF Package Revisions + + The most notable changes to the tasks in the IRAF packages are summarized +below. Further information may be obtained by reading the help page for each +task, or by paging the revisions file for a particular package. +For example, to page the revisions for the DATAIO package: +.sp +.nf + cl> phelp dataio.revisions op=sys +.fi +.sp +.NH 2 +Changes to the System Packages +.NH 3 +Modifications to tasks in the DATAIO package +.le +.ls 4 o +The RFITS and WFITS tasks have been modified to add support for the IEEE +floating point format. The "bitpix" parameter in WFITS can be set to -32 +or -64 to specify real or double precision IEEE floating numbers on output. +RFITS recognizes these same values in the bitpix keyword in the FITS header +on input and converts the data accordingly. Note that this option must be +selected by the user as the defaults for writing a FITS tape have not changed. +The user is cautioned that support for the IEEE floating formats is a new +feature of FITS and may not be supported by all FITS readers. +.le +.ls 4 o +RFITS was modified so that the "iraf_file" parameter can be a list of +output images or a image root name. +.NH 3 +Modifications to tasks in the IMAGES package +.le +.ls 4 o +MWCS (world coordinate system) support was added to those tasks in the +IMAGES package which change the geometry of an image, i.e., +IMSHIFT, SHIFTLINES, MAGNIFY, IMTRANSPOSE, IMCOPY, BLKREP, BLKAVG, ROTATE, +IMLINTRAN, REGISTER, and GEOTRAN (REGISTER and GEOTRAN only support simple +linear transformations). If one of these tasks is used to linearly transform +an image, the world coordinate system (WCS) in the image header will be +updated to reflect the transformation. Note that MWCS is disabled by default +in IRAF V2.9, and must be explicitly enabled to allow these tasks to edit +the image header to update the WCS (see section 2.2). +.le +.ls 4 o +The IMSTATISTICS task was modified. The "verbose" parameter was renamed +"format" with the default being set to "yes" (fixed format with column labels). +Otherwise the fields are printed in free format with 2 blanks separating +the fields. The name of the median field has been changed to "midpt". +.le +.ls 4 o +The IMHISTOGRAM task has a new parameter called "hist_type" that gives +the user the option of plotting the integral, first derivative, or +second derivative of the histogram instead of the normal histogram. +.NH 3 +Modifications to tasks in the LISTS package +.le +.ls 4 o +The RIMCURSOR task in the LISTS package was completely rewritten to add +MWCS support, so that coordinates may be output in any user specified +coordinate system defined by the WCS information in the image header of +the reference image. For example, if an image with a TAN projection WCS +is loaded into the image display, RIMCURSOR may be used to print the right +ascension and declination at the location defined by the image cursor. +Refer to the help page for details. +.NH 3 +Modifications to tasks in the PLOT package +.le +.ls 4 o +A new graphics kernel task IMDKERN (written by Zolt Levay at STScI) has been +added to the PLOT package. The new graphics kernel allows the graphics +output of any task to be plotted as a graphics overlay on the image display. +As with the other graphics kernels, this may be done by calling the IMDKERN +task directly, but is more often done by specifying the image display +(e.g., device "\fIimd\fR") as the output device when running a graphics task. +Refer to the help page for details. +.le +.ls 4 o +The CONTOUR task was modified so that it could be used with IMDKERN to +overlay contour plots on the image display. +If the parameters \fIfill=yes\fR and \fIperimeter=no\fR are set +the contour plot is scaled to fill the entire device viewport and all +axis and plot labeling is disabled. If the image being displayed also +fills the entire device viewport (display frame) then the contour plot +will be drawn to the same scale as the displayed image. +Refer to the help page for details. +.le +.ls 4 o +Several tasks in the PLOT package were modified to allow use with image +specifications containing brackets, e.g., group format images, QPOE +filter expressions, and image sections. The tasks modified were PROW, +PROWS, PCOL, PCOLS, SURFACE, and CONTOUR. +.le +.ls 4 o +An option was added to the PVECTOR task to output the vector (cut through +the image at an arbitrary angle and center) as a text file or image, +rather than plotting the vector. +.NH 3 +Modifications to tasks in the SYSTEM package +.le +.ls 4 o +A new task PHELP (paged help) was added to the SYSTEM package. +PHELP is a script task front end to HELP which collects the output of HELP +in a scratch file and pages it with the system pager, allowing one to +randomly skip around to read the help text. Note that paging of all the +help pages in a package is supported, e.g., +.sp +.nf + cl> phelp images.* +.fi +.sp +would page all the help files for the IMAGES package. +.le +.ls 4 o +The NEWS task was completely rewritten, and is now used to page the +revisions summary for the current and previous releases. In other words, +one can now type NEWS to find out what is new in the current release. +.le +.ls 4 o +The GRIPES task was modified to send mail to +\fIiraf@noao.edu\fR or \fI5355::iraf\fR. +The IRAF site administrator may want to check this script for compatibility +with the local mail system. +.NH 2 +Glossary of New Tasks in the IRAF System Packages + +.KS +.nf +\fITask\fR \fIPackage\fR \fIDescription\fR + +imdkern plot Image display device (IMD) graphics kernel +news system Summarize what is new in the current release +phelp system Paged HELP: collects and pages the output of HELP +rimcursor lists Read image cursor position in world coordinates +.fi +.KE + +.NH 2 +Changes to the NOAO Packages +.NH 3 +New NOAO Packages + + A new package ARTDATA, used to generate artificial data, has been added +to the NOAO packages. ARTDATA includes tasks for the generation of star +fields, optionally containing galaxies, and one and two dimensional spectra +as well as simple test pattern images. +The tasks GALLIST and STARLIST provide many options for producing lists +of galaxies or stars that can then be used by the task MKOBJECTS to produce +output images. The tasks MK1DSPEC and MK2DSPEC provide tools for making +artificial spectral data. The task MKNOISE allows the user to add readout +noise, poisson noise and/or cosmic ray events to new or already +existing images. The task MKPATTERN allows the user to make images +from a choice of patterns. +.NH 3 +Modifications to Existing NOAO Packages +.NH 4 +The ASTUTIL package +.le +.ls 4 o +The task SETAIRMASS in the ASTUTIL package was modified so that it now +processes the coordinates to the epoch of the observation. +.NH 4 +The DIGIPHOT.APPHOT package +.le +.ls 4 o +A new task APTEST was added to the DIGIPHOT.APPHOT package that +tests the execution of the package. Output files are generated that +the user can review. +.le +.ls 4 o +Two new parameters were added to DATAPARS, "datamin" and "datamax". +Pixels outside this range are rejected from the sky fitting algorithms +and from the non-linear least square fits in FITPSF and RADPROF. +.le +.ls 4 o +An "update" parameter was added to all of the APPHOT tasks. If the +"verify" parameter is set to "yes" and the task is run in non-interactive +mode \fIupdate=yes\fR will update the critical parameters in their +respective parameter sets. +.le +.ls 4 o +Four new parameters, "airmass", "xairmass", "filter", and "ifilter", +were added to the DATAPARS task. These parameters provide the user the +option of having the filter and airmass quantities from the image +headers to be carried over into the APPHOT database files for later +transmission to calibration programs. +.le +.ls 4 o +A new algorithm "mean" was added to the sky fitting options. +.le +.ls 4 o +A setup menu mode was added to all the APPHOT tasks. When the user types +"i" in interactive mode a setup menu is presented rather than a fixed +set of predefined commands. +.NH 4 +The IMRED.IRRED package +.le +.ls 4 o +The APSELECT +task (from the APPHOT package) has been made visible. +.le +.ls 4 o +The image i/o +for IRMOSAIC, IRALIGN, IRMATCH1D, and IRMATCH2D has been optimized +so things should run much faster. There is now an option to trim +each section before insertion into the output image. The actions of +these tasks can now optionally be output to the terminal. +.NH 4 +The IMRED.MSRED package +.le +.ls 4 o +A task called MSBPLOT was added to the IMRED.MSRED package. +This task allows the user to plot a range of lines in multispec images in batch +mode. +.NH 4 +The ONEDSPEC package +.le +.ls 4 o +Several modifications were made to the ONEDSPEC package. These changes +affect all of the IMRED packages that include these tasks as well. +.le +.ls 4 o +The equivalent width measurement using the "e" keystroke in SPLOT +is now computed using the ratio of the spectrum to the continuum. The +previous approximation is included in the logfile for comparison. +.le +.ls 4 o +The DISPERSION task will now add CD\fIi\fR_\fIj\fR (CD matrix) keywords to +the image header as an alternative way of expressing the dispersion function. +If the keywords W0 and WPC or CRVALn and CDELTn +are not in the image header the tasks reading this information for +setting the wavelength (IDENTIFY, SENSFUNC, SPLOT, and SPECPLOT) will +look for the CD\fIi\fR_\fIj\fR keywords. This change should have no affect +on the NOAO applications but provides compatibility with STSDAS applications +using the new MWCS interface provided with IRAF version 2.9. +.le +.ls 4 o +The call to the CALIBRATE task in the script task BATCHRED was modified so that +the "extinct" parameter is always set to "yes". Since CALIBRATE checks to +be sure the data has not been previously extinction corrected this simple +change provides more flexibility. +.NH 4 +The PROTO package +.le +.ls 4 o +Two new tasks, IMALIGN and IMCENTROID, were added to the package. IMCENTROID +computes a set of relative shifts required to register a set of images. +The task IMALIGN both computes the shifts and aligns the images. +.le +.ls 4 o +The JOIN task (previously a simple script) has been replaced by a compiled +version which removes many of the restrictions of the previous version. +.le +.ls 4 o +The IR tasks have been modified as mentioned above under the IMRED.IRRED +section (section 3.3.2.3). +.le +.ls 4 o +The TVMARK task was modified to permit deletion (the "u" key) +as well as addition of +objects to the coordinate file. Another cursor keystroke, the "f" key, +was added allowing the user to draw a filled rectangle. +.NH 4 +The TWODSPEC.LONGSLIT package +.le +.ls 4 o +Tasks in the TWODSPEC.LONGSLIT package that are used for setting +wavelength information (EXTINCTION, FLUXCALIB, and TRANSFORM) +were modified for the CD\fIi_j\fR keywords as outlined above for ONEDSPEC. +.NH 2 +Modifications and Additions to Calibration Data + + The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory +called ONEDSTDS in \fInoao$lib\fR. The current contents of this directory +are best summarized by paging through its README file, e.g., +.sp +.nf + cl> page noao$lib/onedstds/README +.fi +.sp + +A new directory \fIspec50redcal\fR in "\fInoao$lib/onedstds\fR" +has been added containing flux information for standard stars. +The data in this list are from Massey and Gronwall, Ap. J., July 20, 1990. +.NH 2 +Glossary of New Tasks in the NOAO Packages + +.tp 5 +.nf +\fITask\fR \fIPackage\fR \fIDescription\fR + +aptest apphot Run basic tests on the apphot package tasks +gallist artdata Make an artificial galaxies list +imalign proto Register and shift a list of images +imcentroid proto Compute relative shifts for a list of images +mk1dspec artdata Make/add artificial 1D spectra +mk2dspec artdata Make/add artificial 2D spectra +mknoise artdata Make/add noise and cosmic rays to 1D/2D images +mkobjects artdata Make/add artificial stars and galaxies to 2D images +mkpattern artdata Make/add patterns to images +msbplot msred Batch plots of multispec spectra using SPLOT +starlist artdata Make an artificial star list +.fi + +.NH +Programming Environment Revisions +.NH 2 +Changes to the Programming Utilities +.NH 3 +MKPKG changes + + The MKPKG utility can now substitute the contents of a file back into the +input stream, as a special case of the macro replacement syntax. +For example, the sequence +.sp +.nf + abc$(@file)def +.fi +.sp +would be translated as +.sp +.nf + abc10def +.fi +.sp +if the file "\fIfile\fR" contained the string "10". The replacement is +performed by inserting the contents of the file back into the input stream, +replacing sequences of newlines, spaces, or tabs by a single space, and +omitting any trailing whitespace. + +The "-p " argument to MKPKG, XC, and so on loads the environment of the +named package \fIpkg\fR, to define the package environment variables, load +the mkpkg special file list, define the directories to be searched for global +include files and libraries, and so on. Multiple "-p" arguments may be given +to load multiple package environments. What is new is that if \fIpkglibs\fR +is defined in the environment of a package to list the package library +directories to be searched (the usual case), and multiple package environments +are loaded, successive redefinitions of \fIpkglibs\fR will \fIadd\fR to +the list of directories to be searched, rather than redefining the old list +as each new package environment is loaded. For example, if two package +environments are loaded, and each defines its own library, both libraries +will be searched. +.NH 3 +Generic preprocessor + + A minor change was made to the generic preprocessor which affects +how strings such as "FOO_PIXEL" are translated. +In the usual case, the preprocessor +replaces all occurrences of "PIXEL" by "int", "real", or whatever the actual +datatype is. The translation is now context sensitive. Rather than +translating "FOO_PIXEL" as "FOO_int" (e.g., "MII_PIXEL" -> "MII_int"), the +type name will now be output in upper case if the rest of the name in which +it occurs is upper case. Hence, a string such as "MII_PIXEL" will now be +translated as "MII_INT". This allows the use of generic constructs to +symbolize SPP macros. +.NH 3 +SPP changes + + The language constant ARB, formerly defined as 32767, is now treated +differently depending upon how it is used. In a declaration of an array +argument, ARB is replaced in the output Fortran by a "*", e.g., +"\fIint data[ARB]\fR" becomes "\fIINTEGER DATA(*)\fR". In an executable +statement, ARB is replaced by a very large ("arbitrarily" large) integer +value, e.g., to define a DO-loop which is to loop an arbitrary number of +times. If ARB is mistakenly used to dimension an array which is a local +variable rather than an argument, the SPP translator will now detect and +report the error. +.NH 3 +Interactive development and the process cache + + Whenever a CL task is run and the process containing the task is already +idling in the CL process cache, the CL will now check to see if the modify +date on the process executable has changed, and restart the process if the +executable has been modified. For example, when doing software development +from within the CL and a process is alternately relinked and tested, the +CL will now automatically detect that the process has been relinked and will +run the new process, without any need to manually flush the process cache. +.NH 2 +Programming Interface Changes +.NH 3 +New MWCS interface (world coordinate system support) + + A major new VOS interface MWCS, providing general facilities for +linear and nonlinear world coordinate systems, has been added to +the programming environment and is used in IRAF V2.9 in IMIO, IMAGES, and +other parts of the system. MWCS is intended for use in scientific +applications as well as in system code such as IMIO, hence is of potential +interest to anyone developing software within the IRAF environment. +The source directory is "\fImwcs\fR" and the interface is documented in the +file "\fImwcs$MWCS.hlp\fR". Users should be aware that, although the new +interface addresses the general WCS problem and has been carefully designed, +a second version of the interface is planned and the current interface is +not yet a "frozen" interface. +.NH 3 +QPOE interface changes + + The QPOE (event list image) interface has been extended to add routines to +store MWCS objects in the QPOE header. By default, there is one MWCS per +QPOE file, stored encoded in a machine independent binary format in a +variable length array \fIqpwcs\fR of type \fIopaque\fR. The new routines +are as follows: + +.nf + mw = qp_loadwcs (qp) + qp_savewcs (qp, mw) + mw = qpio_loadwcs (io) +.fi + +The routines \fIqp_savewcs\fR and \fIqp_loadwcs\fR merely save a MWCS in the +QPOE header, or load a previously saved one. The QPIO (event i/o) routine +\fIqpio_loadwcs\fR is like \fIqp_loadwcs\fR, except that it will also modify +the Lterm of the MWCS to reflect any blocking factor or "rect" specified in +the filtering expression when the event list was opened. The new routine is +called automatically by QPF and IMIO whenever a QPOE event list is opened +under image i/o, making the physical coordinate system of the image matrix +the same as physical event coordinates. + +The calling sequences of the \fIqp_add\fR and \fIqp_astr\fR routines, used +to conditionally add or update header parameters, have been changed (so far +as we could determine very few programs exist yet which use these routines, +so we decided to risk an interface change). The change made was to add a +\fIcomment\fR argument. This change was motivated by the observation that +people would not use the routines but would instead use lower level routines, +in order to be able to set the comment field if the parameter has to be added +to the header. +.NH 3 +IEEE support routines added + + Routines for IEEE floating to native floating conversions have been added to +the MII and OSB interfaces. The new MII routines are as follows: + +.nf + nelem = miiread[rd] (fd, spp, maxelem) + miiwrite[rd] (fd, spp, nelem) + miipak[rd] (spp, mii, nelems, spp_datatype) + miiupk[rd] (mii, spp, nelems, spp_datatype) +.fi + +The \fImiiread\fR and \fRmiiwrite\fR routines are like their FIO +counterparts, except that they are used only with data of the indicated +type, and perform the IEEE to native floating conversion (or vice versa) +as part of the i/o operation. The \fImiipak\fR and \fImiiupk\fR routines +pack (native->IEEE) and unpack (IEEE->native) arrays of the indicated +type. + +The lowest level conversion routines are the OSB routines, which are what +the MII routines use to perform the lowest level translation. + +.nf + ieepak[rd] (datum) + ieeupk[rd] (datum) + ieevpak[rd] (native, ieee, nelem) + ieevupk[rd] (ieee, native, nelem) + iee[sg]nan[rd] (NaN) +.fi + +The \fIieepak\fR and \fIieeupk\fR routines transform a single scalar value +in place, while the \fIieevpak\fR and \fIieevupk\fR routines transform +vectors (note that the package prefix is "iee", not "ieee"). In-place +vector conversions are permitted. Since IRAF does not support the IEEE +not-a-number formats, \fINaN\fR, \fIInf\fR etc. values are converted to a +legal native floating value on input. The native floating value to which +\fINaN\fRs are mapped (default zero) may be globally set with \fIieesnan\fR. + +On some systems, e.g., the VAX, the low level conversion routines may be +written in assembler or machine dependent C. If so, the source file actually +used by the system will be found in the "\fIhost$as\fR" directory. +.NH 3 +New routine GETLLINE added to FIO + + A new routine \fIgetlline\fR (get long line) has been added to FIO. This +is similar to \fIgetline\fR, except that it will reconstruct arbitrarily +long newline delimited lines of text, whereas \fIgetline\fR returns at most +SZ_LINE characters. +.sp +.nf + nchars = getlline (fd, outstr, maxch) +.fi +.sp +The new routine should not be confused with the old routine \fIgetlongline\fR, +a higher level routine which performs a similar function, but which also +ignores comment lines and help blocks, and maintains a line counter. +.NH 3 +Modifications to PLIO/PMIO + + A new routine \fIp[lm]_sectnotconst\fR has been added to PLIO and PMIO +(the pixel list and image mask interfaces). As the name suggests, the +routine tests whether a given rectangular section of the mask is all at +the same value, and if so returns the mask value as an output argument. +.sp +.nf + bool = pl_sectnotconst (pl_src, v1, v2, ndim, mval) +.fi +.sp +A new subpackage PLRIO has been added. This is used to efficiently random +access any 2D plane of an existing pixel list or image mask. + +.nf + plr = plr_open (pl, plane, buflimit) + plr_setrect (plr, x1,y1, x2,y2) + mval = plr_getpix (plr, x, y) + plr_getlut (plr, bufp, xsize,ysize, xblock,yblock) + plr_close (plr) +.fi + +The mask is opened for random access on a special descriptor which incorporates +a scaled, active 2D lookup table. Most subsequent \fIplr_getpix\fR calls +will return the given mask value directly from the table with +very little overhead; only if the referenced pixel occurs in a region +too complex to be described by a single table entry is the value +computed by direct evaluation of the mask. A special 2D binary +recursive algorithm (using \fIpl_sectnotconst\fR above) with log2(N) +performance is used to calculate the scaled lookup table. These +algorithms provide efficient table generation and random mask pixel +access even for very large masks. +.endhelp diff --git a/doc/newsfile b/doc/newsfile new file mode 100644 index 00000000..51a19e99 --- /dev/null +++ b/doc/newsfile @@ -0,0 +1,8008 @@ + +IRAF (Mar02) V2.12EXPORT Release Notes IRAF (Mar02) + + + IRAF V2.12EXPORT Release Notes + January 25, 2002 + Updated: March 25, 2002 + + +These release notes provide a summary of the major changes in V2.12. +This is a major release of IRAF and will be available for all supported +platforms. More detailed technical documentation of all system changes +will be found in the 'notes.v211' and 'notes.v212' files in the +iraf$doc and iraf$local directories. Detailed revisions notes for each +application package are in the package directories in a file called +Revisions, e.g. apphot$Revisions. + + 1. Highlights of This Release + 2. IRAF System Revisions Summary + 3. Core IRAF Revisions Summary + 3.1 New Tasks + 3.2 Existing tasks with new parameters/defaults + 3.3 Existing tasks with new capabilities + 4. NOAO Package Revisions Summary + 4.1 New NOAO Packages + 4.2 New NOAO Package Tasks + 4.3 Existing tasks with new parameters/defaults + 4.4 Existing tasks with new capabilities + 5. General Package Changes + 6. General Task Changes + 7. Parameter File Changes + 8. Details of Major System Changes + 8.1 FITS Kernel Changes + 8.2 Large Image Support + 8.3 Virtual Memory Cache + 8.4 New Developer libraries + 9. System Changes Which May Affect You + 9.1 Shared Library Version Incremented + 9.2 External Package Recompilation + 9.3 Parameter File Changes + 9.4 Installation Script Changes + 9.5 Help System Changes + 9.6 Image Display Changes + 9.7 PLIO Changes + 9.8 New Environment Variables Changes + + + + +1. Highlights of This Release + + o Pixel Mask Support Added to FITS Kernel + The FITS kernel was modified to add support for storing images in + extensions as compressed pixel masks using the binary table extension. + These masks may be accessed like any other image and allow for tasks + to more easily store bad-pixel masks, regions masks, or error arrays + in the same image file as the science data. + + o New Pixel Mask Tasks + Several new tasks have been added to the system PROTO package for + manipulating pixel masks: + + o MIMSTATISTICS allows image statistics to be computed while + rejecting pixels specified by an input mask. + o MSKEXPR task is a general-purpose mask expression evaluator + similar to IMEXPR for images, but has builtin boolean region + functions which can be used to set values inside or outside + of certain geometric shapes. + o MSKREGIONS creates an output mask based on an input text de- + scription. Region descriptions can be composed of geometric + shapes and logical operation on mask regions. + + o OBJMASKS in the NPROTO package is a new task for detecting objects + in an image and creating an output catalog or pixel mask of + found objects. + + o Shared Memory Limitations Eased + The IMAGES and DAOPHOT packages executables are now linked statically + to remove per-process memory limitations imposed by the IRAF shared + library on Sun and Dec Alpha systems. Previously tasks such as + DAOFIND and IMCOMBINE were limited to 268Mb on Sun systems, these + tasks can now use up to the machine memory limits. + + o Image I/O Buffer Sizes Increased + Support for large image I/O was improved by changes to the internal + buffer sizes. These buffers may automatically adjust to optimal + values for the image being accessed, however new environment variables + may be set to further tune the buffers at the user level. Where + needed applications tasks were modified to take advantage of these + buffer size changes to force the imio buffer to be the size of the + input image. + + o Simplified Installation Script + The install script was rewritten to clarify the output and provide + some basic checking of the IRAF system setup prior to installation, + and to do some of the most common post-install configuration. The + script will print an explanation of any errors it finds and suggest + corrective action, the hope is this will lead the user past some of + the most common installation errors. + + In addition, the SYSINFO diagnostic script which does more extensive + checking of the system is also now part of the distribution. This + script can be used to verify the system once the install is complete, + or to generate a report of the system configuration if needed by + site support. An UNINSTALL script to remove iraf command links and + files created by the INSTALL script is also available to remove IRAF + from a machine. All scripts are now installed in the hlib$ directory. + + o New HELP GUI and Output Options + The HELP task was enhanced to have a new GUI option for XGterm + users. This is essentially the XHELP task which has been available + in the GUIAPPS external package for some time, however the task is + fully backwards compatible and the text-mode output is still the + default. As part of this work, help pages may also now be formatted + as either HTML or Postscript for web presentation or pretty-printing + to a hardcopy device. The LROFF task was similarly modified to + provide direct conversion of lroff text sources. + + o DISPLAY Task Changes + As part of the recent X11IRAF enhancements, the DISPLAY task and + others such as IMEXAMINE which interact with the display server were + modified to take advantage of the new features in XImtool V1.3. + These include support for 16 frame buffers (increased from 4 in + previous versions), and enhanced WCS readout capabilities. The + changes are fully backwards compatible for use with older XImtool + versions or display servers such as SAOimage, SAOtng, or DS9 which + have not yet been updated. + + X11IRAF V1.3 is being released simultaneously (but still separately) + with IRAF V2.12. While V2.12 is fully compatible with older versions + of X11IRAF, however users will need to upgrade both systems to take + full advantage of all the new features. Users should consult the + X11IRAF Release Notes for details on what has changed there. + + o New Packages + Several new packages are available in this release (see the NOAO + package change notes below for details): + + - A new ASTCAT package for extracting astrometric and photometric + calibration data from remote or local catalogs was added to NOAO. + + - A new CRUTIL package for doing cosmic ray detection and removal + package was installed in the IMRED package. + + - A new QUADRED reduction package for QUAD format data was installed + in the IMRED package. This is a generalized replacement for the + ARED.QUAD and XCCDRED external packages for processing CTIO and + ESO FORS1 multi-amplifier data. + + - A new OBSUTIL package was installed in NOAO. This is a collection + of tasks from various external packages which are useful to plan or + carry out observations. + + o New Developer Libraries. + Several new libraries are available for SPP developers: + + - PSIO is a new Postscript text generation library installed in + sys$psio. + + - CATQUERY is a remote astrometric/photometric catalog access lib + installed in the XTOOLS utility library. + + - SKYWCS is a sky coordinate transformation library installed in + the XTOOLS utility library. + + + + +2. IRAF System Revisions Summary + + o The IRAF shared library version number was incremented for SunOS + and Solaris systems. See below for details on how this change + will affect external packages and locally-compiled software. + + o The maximum number of nodes in a local iraf network was increased + from 320 to 512. + + o The max number of open files in FIO, FIO_MAXFD, was increased from + 256 to 4096. This is the "hard limit" on the maximum number of + open files in an IRAF process. + + o The maximum number of host level open files, MAXOFILES, was increased + from 64 to 256. This is the maximum number of files that can be + simultaneously open at the host level. It determines the maximum + number of files that can be simultaneously open by an IRAF process + in the usual case. + + o The number of keywords in a group header block for STF images (i.e. + the MAX_PCOUNT) was increased from 50 to 99 in the STF image kernel. + + o Added support for the bitwise boolean operators: '&' (and), '|' (or), + '^' (xor), and '~' (not/complement), to vectory expression evaluator + fmtio$evvexpr.gy. The IMEXPR task was modified to allow these new + bitwise operations. + + o Added new vector operators to VOPS library: alan, alank (logical AND) + and alor, alork (logical OR). These take any integer data as input + (short, int, long) and return a logical (expressed as int) result. + + o The 'imextn' environment variable will now accept upper-case extensions + to specify image types. + + o Host Command Execution: The way command line arguments are parsed + was modified to make it easier to set the value of a string parameter + to the null string. Whitespace is still skipped in @par files + as before, however null strings are valid parameter values and will + no longer cause a parameter prompt. + + o The MKPKG special file list link support was enhanced to allow replacing + LFLAGS (the link flags variable) as well as the entire link line. + This makes is possible to write special-file list entries for packages + which need e.g. to be compiled nonshared on certain platforms without + creating a platform specific mkpkg file for the package itself. + + o The HSI zawset.c routine which controls a process working set size was + modified to automatically detect the physical size of system memory + (with a maximum return value of 2Gb). The hard upper limit on memory + utilization defined by the unix kernel can be limited either by the + value return by the IRAF kernel (up to 90% of physical memory), or by + the value set in the user environment variable MAXWORKSET (given in + units of Mb). + + o New stdimage display devices were added to support the display of Gemini + GMOS CCD data. These devices are named 'imt45' thru 'imt49' and + correspond to the following frame buffer sizes: + + imt45 2080 x 4644 # imt45|imtgmosccd + imt46 6400 x 4644 # imt46|imtgmos + imt47 3200 x 2322 # imt47|imtgmos2 + imt48 1600 x 1161 # imt48|imtgmos4 + imt49 800 x 581 # imt49|imtgmos8 + + + +3. CORE IRAF REVISIONS SUMMARY + + + +3.1 New Tasks + imcoords.ccget - extract objects from a test file catalog + imcoords.ccstd - transform to and from standard astrometric coordinates +proto.mimstatistics - do image statistics through a mask + proto.rskysub - sky subtract images using running mean or median + proto.mskexpr - general mask expression evaluator + proto.mskregions - create a mask from a list of region specifications + + + +3.2 Existing Tasks with New Parameters or New Parameter Defaults + immatch.imcentroid - new parameter maxshift + immatch.imalign - new parameter maxshift + immatch.geomap - new parameter maxiter, default reject = 3.0 not INDEF + imcoords.ccmap - new parameter maxiter, default reject = 3.0 not INDEF + imcoords.imcctran - new parameter longpole + imutil.hedit - new parameter addonly +imutil.imstatistics - new parameters nclip, lsigma, usigma, cache + + + +3.3 Existing Tasks with New Capabilities + immatch.imcentroid - optionally rejects objects whose centers wander too much + immatch.imalign - optionally rejects objects whose centers wander too much + immatch.geomap - iterative rejection capability added + imcoords.ccmap - iterative rejection capability added + imcoords.imcctran - support for non-zenithal projections added + imutil.hedit - support for add keyword only if new option +imutil.imstatistics - support for iterative rejection and memory caching added + imutil.imexpr - support for bitwise operators or, and, xor, and not added + + + + +4. NOAO PACKAGE REVISIONS SUMMARY + + + +4.1 New NOAO Packages + astcat - Astronomical catalog and surveys access package + crutil - Cosmic ray detection and removal package + obsutil - Observing utilities package + + + +4.2 New NOAO Package Tasks + apphot.pcalc - Do arithmetic operations on a list of apphot databases + apphot.pconvert - Convert a text database to a tables database + apphot.pdump - Print selected fields from a list of apphot databases + apphot.pexamine - Interactively examine and edit an apphot database + apphot.prenumber - Renumber stars in an apphot database + apphot.pselect - Select records from an apphot database + apphot.psort - Sort an apphot database + + astcat.aclist - List the supported astrometric catalogs + astcat.agetcat - Extract astrometry files from astrometric catalogs + astcat.afiltcat - Filter astrometry files derived from astrometric catalogs + astcat.adumpcat - Catalog access debugging task + astcat.aslist - List the supported image surveys + astcat.agetim - Extract FITS images from image surveys + astcat.ahedit - Initialize the image wcs and set standard keywords + astcat.aimfind - Select images containing catalog objects + astcat.adumpim - Image survey access debugging task + astcat.aregpars - Default region parameter set + astcat.acatpars - Default astrometry file format parameter set + astcat.afiltpars - Default astrometry file filtering parameters + astcat.aimpars - Default image data parameters + astcat.awcspars - Default image wcs parameters + + crutil.cosmicrays - Remove cosmic rays using flux ratio algorithm + crutil.craverage - Detect CRs against average and avoid objects + crutil.crcombine - Combine multiple exposures to eliminate cosmic rays + crutil.credit - Interactively edit cosmic rays using an image display + crutil.crfix - Fix cosmic rays in images using cosmic ray masks + crutil.crgrow - Grow cosmic rays in cosmic ray masks + crutil.crmedian - Detect and replace cosmic rays with median filter + crutil.crnebula - Detect and replace cosmic rays in nebular data + +obsutil.psfmeasure - Measure PSF sizes from stellar images + obsutil.specfocus - Determine spectral focus and alignment variations + obsutil.starfocus - Determine direct focus variations from stellar images + obsutil.ccdtime - CCD photometry exposure time calculator + obsutil.pairmass - Plot airmass vs time for a given coordinate + obsutil.sptime - Spectroscopic exposure time calculator + obsutil.specpars - Spectrograph instrument parameters for sptime + obsutil.bitcount - Accumulate the bit statistics for a list of images + obsutil.findgain - Estimate the gain and readnoise of a CCD + obsutil.shutcor - Shutter correction from images of varying exposure times + + nproto.objmasks - detect and catalog objects in image + + + +4.3 Existing Packages and Tasks with New Parameters or New Parameter Defaults + apphot - new package parameters wcsin, wcsout, and cache + apphot.center - new parameters wcsin, wcsout, cache + apphot.daofind - new parameters wcsout, cache + apphot.fitpsf - new parameters wcsin, wcsout, cache + apphot.fitsky - new parameters wcsin, wcsout, cache + apphot.phot - new parameters wcsin, wcsout, cache + apphot.polymark - new parameters wcsin, wcsout, cache + apphot.polyphot - new parameters wcsin, wcsout, cache + apphot.qphot - new parameters wcsin, wcsout, cache + apphot.radprof - new parameters wcsin, wcsout, cache + apphot.wphot - new parameters wcsin, wcsout, cache + apphot.txdump - replaced by pdump, available as a hidden task + +astutil.setairmass - new parameters ra, dec, equinox, st, ut, scale + + daophot - new package parameters wcsin, wcsout, wcspsf, and cache + daophot.addstar - new parameters wcsin, wcsout, wcspsf, and cache + daophot.allstar - new parameters wcsin, wcsout, and wcspsf + daophot.daoedit - new parameters cache + daophot.daofind - new parameters wcsout, and cache + daophot.group - new parameters wcsin, wcsout, wcspsf, and cache + daophot.nstar - new parameters wcsin, wcsout, wcspsf, and cache + daophot.peak - new parameters wcsin, wcsout, wcspsf, and cache + daophot.phot - new parameters wcsin, wcsout, and cache + daophot.psf - new parameters wcsin, wcsout, and cache + daophot.substar - new parameters wcsin, wcsout, and cache + + + +4.4 Existing Tasks with New Capabilities + apphot.center - coordinate system support, optional image cacheing + apphot.daofind - coordinate system support, optional image cacheing + apphot.fitpsf - coordinate system support, optional image cacheing + apphot.fitsky - coordinate system support, optional image cacheing + apphot.phot - coordinate system support, optional image cacheing + apphot.polymark - coordinate system support, optional image cacheing + apphot.polyphot - coordinate system support, optional image cacheing + apphot.qphot - coordinate system support, optional image cacheing + apphot.radprof - coordinate system support, optional image cacheing + apphot.wphot - coordinate system support, optional image cacheing + +astutil.setairmass - ra, dec, equinox, st, ut, scale are no longer hardwired + astutil.rvcorrect - more flexibility in setting ut + + daophot.addstar - coordinate system support, optional image cacheing + daophot.allstar - coordinate system support + daophot.daoedit - optional image cacheing + daophot.daofind - coordinate system support, optional image cacheing + daophot.group - coordinate system support, optional image cacheing + daophot.nstar - coordinate system support, optional image cacheing + daophot.peak - coordinate system support, optional image cacheing + daophot.phot - coordinate system support, optional image cacheing + daophot.psf - coordinate system support, optional image cacheing + daophot.substar - coordinate system support, optional image cacheing + + + + +5. General Package Changes + +NOAO + + ONEDSPEC + More than 999 apertures are now allowed. + + APPHOT + Coordinate Support: + All the apphot tasks have been modified to accept input coordinates + in the logical, tv, physical, or world systems, and to write output + coordinates in the logical, tv, or physical coordinate systems. One + consequence of this is that the apphot tasks will now work correctly + on image sections in interactive mode. Another is that users can now + work directly on image sections while preserving the coordinate + system of the parent image. + + Image Cacheing Support: + All the apphot tasks which accept image pixel input have been mod- + ified to optional cache the entire input image in memory. Cacheing + may significantly improve the performance of tasks where many random + access operations are performed. + + File and image name directory information removed from output files + All the apphot tasks have been modified to strip directory infor- + mation from the image and coordinate file names written to the output + files, to the terminal, and to the plot headers. The colon commands + will still read and write full image and coordinate file path names. + + New PTOOLS Tasks Added + The ptools package tasks pcalc, pconvert, pdump, prenumber, pselect + and psort were added to the apphot package. The functionality of the + old txdump task as been replaced by the pdump. TXDUMP is still avail- + able as a hidden task. + + ASTCAT + The astcat package is a set of tasks for extracting astrometric and + photometric calibration data from remote or local catalogs, filtering + the data, extracting FITS images from remote or local surveys, and adding + standard keywords to the extracted images. There is also a task for + selecting images which contain catalog objects and locating the catalog + objects in the image. + + IMRED.CRUTIL + Cosmic ray detection and removal package. This package includes new + tasks and links to tasks from other package. It replaces the CRUTIL + external package. + + IMRED.QUADRED + Reduction package for QUAD format data. This replaces the ARED.QUAD + and XCCDRED external packages for processing CTIO and ESO FORS1 multi- + amplifier data. + + DAOPHOT + Coordinate Support + All the daophot tasks have been modified to accept input coordinates + in the logical, tv, physical, or world systems, and to write the output + coordinates in the logical, tv, or physical coordinate systems. One + consequence of this is that the daophot tasks will now work correctly + on image sections in interactive mode. Another is that users can now + work directly on image sections while preserving the coordinate + system of the parent image. + + Image Cacheing Support + All the daophot tasks which accept image pixel input have been modified + to optionally cache the entire input image in memory. Cacheing signif- + icantly improves the performance of the tasks when many random access + operations are performed. The cacheing already performed by the + ALLSTAR task is unchanged. + + File and image name directory information removed from output files + All the daophot tasks have been modified to strip directory information + from the image and coordinate file names written to the output files, + to the terminal, and to the plot headers. The colon commands will still + read and write full image and coordinate file path names. + + OBSUTIL + New observing utilities package. This collects tasks from the NMISC, + SPECTIME, PROTO, and NLOCAL external package which are useful to + plan or carry out observations. The new tasks are: + + PSFMEASURE STARFOCUS SPECFOCUS CCDTIME + PAIRMASS SPTIME BITCOUNT FINDGAIN + SHUTCOR + + OBSOLETE + o Added tasks OIMCOMBINE and OIMSTATISTICS which are the previous + versions from V2.113b system + o Deleted the ODISPLAY task + + + + +6. General Task Changes + +NOAO + ONEDSPEC.SPLOT + Rather than refusing to evaluate errors when there is negative data, + negative data is treated as zero. + + ASTUTIL.SETAIRMASS + Modified to have greater flexibility in selecting the keyword defining + the universal time. New parameters define the keywords for RA, dec, + equinox, siderial time, universal time, and astrospheric scale height. + + ASTUTIL.RVCORRECT + Modified to have greater flexibility in selecting the keyword defining + the universal time. + + IMRED.ECHELLE.ECIDENTIFY + Help page describes how to externally evaluate the dispersion fcns. + + IMRED.CCREDRED.COSMISRAYS + Task was removed (see CRUTIL) + + NPROTO.FINDGAIN + Task was removed (see OBSUTIL) + + NPROTO.OBJMASKS + This is a new task for detecting objects in an image and creating + an output catalog or pixel mask of found objects. + + TWODSPEC.LONGSLIT.FITCOORDS + - Help page describes the contents of the database and how to ext- + ernally evaluate the fits. + - The RMS is shown in the graph title and in the :show output. + + TWODSPEC.APEXTRACT.APEDIT + When there is just one aperture the background regions are shown + on the graph without needing to enter the 'b' background mode. + + +IMAGES + + TV.DISPLAY + - The mask overlay feature when the displayed image is a reduction of + mask (e.g. a block average) now uses the maximum of all mask pixels + within the display pixel. + - The task will now allow up to 16 frame buffers to be used for the + display if allowed by the server. (Currently requires XIMtool V1.3). + + TV.IMEXAMINE + - A new key 't' allows output of a region centered on the cursor as an + image for further analysis by other programs. + - The task will now allow up to 16 frame buffers to be used for the + display if allowed by the server. (Currently requires XIMtool V1.3). + - Cursor readback will now properly detect the correct image when more + than one image is displayed per frame, e.g. in a mosaic. (Currently + requires XIMtool V1.3). + + IMMATCH.IMCOMBINE + - New parameters "headers", "bpmasks", "rejmasks", "nrejmasks", and + "expmasks" provide additional types of output. The old parameters + "rejmask" and "plfile" were removed. The new "nrejmasks" parameter + corresponds to the old "plfile" and the new "rejmasks" parameter + corresponds to the old "rejmask". + - There is a new "combine" type "sum" for summing instead of averaging + the final set of offset, scaled, and weighted pixels. + - There is a new parameter "outlimits" to allow output of a subregion + of the full output. This is useful for raster surveys with large + numbers of images. + - Additional keywords may appear in the output headers. + - Scaling is now done relative to the first image rather than an average + over the images. This is done so that flux related keywords such as + exposure time and airmass remain representative. + - A median calculation was made faster. + - The previous version is available in the OBSOLETE package. + + IMMATCH.IMCENTROID + IMMATCH.IMALIGN + A new parameter maxshift has been added to the imcentroid and imalign + tasks. Maxshift defines the maximum permitted difference between the + predicted and computed shifts. It is used to reject objects whose + positions have wandered too far from the predicted positions. + + IMMATCH.GEOMAP + IMCOORDS.CCMAP + An iterative rejection capability has been added to the geomap and + ccmap tasks. The new parameter maxiter in combination with the existing + parameter reject define the rejection parameter. The default value of + the reject parameter has been changed from INDEF to 3.0. + + The colon command ":order " has been added to the geomap and ccmap + tasks. The new command enables the user to change all the order parameters + simultaneously when experimenting with different fitting functions. + + IMCOORDS.STARFIND + The starfind task background estimation algorithm has been modified so + that it no longer depends on the value and density of the central pixel. + + IMCOORDS.IMCCTRAN + Support for non-zenithal projections has been added to the imcctran task. + The previous technique of rotating the cd matrix does not work properly + for these functions. The new parameter longpole was added to imcctran. + Longpole enables the user to select either the cd matrix or longpole / + latpole method for transforming zenithal projections. + + IMCOORDS.CCGET + The new task ccget was added to the imcoords package. Ccget extracts + objects in a user specified region from a a simple text file catalog. + + IMCOORDS.CCSTD + The task ccstd was added to the imcoords package. Ccstd transforms pixel + and celestial coordinates to standard coordinates and vice versa. + + IMUTIL.HEDIT + The new parameter addonly was added to hedit task. The addonly switch + is used to add a parameter to the image header only if it does not + already exist. The addonly switch has a precedence intermediate between + the add and delete switches. + + IMUTIL.IMSTATISTICS + An interative rejection capability has been added to the imstatistics + task. The new parameters nclip, lsigma, and usigma define the rejection + parameters. A memory cacheing option was also added to imstatistics in + order to optionally speed up performance if iterative rejection is en- + abled or the midpt/mode is computed. + + IMUTIL.IMEXPR + Support for the bitwise operators or (|), and (&), exclusive or (^), and + not (~) has been added to the imexpr task. The logical operators or (||) + and and (&&) have ben made truly logical i.e. they return 0's or 1's, + rather than results of a bitwise or and and. + + +PROTO + MIMSTATISTICS + The new task mimstatistics has been added to the proto package. + Mimstatistics does image statistics through a mask. + + RSKYSUB + The new task rskysub was added to the proto package. Rskysub does a + running mean or median sky subtraction on an ordered list of images + using optional background scaling and object masking. + + MSKEXPR + The new task mskexpr has been added to the proto package. Mskexpr + creates a new mask from a user supplied expression, an optional + reference image, and an optional reference mask. + + MSKREGIONS + The new task mskregions has been added to the proto package. Mskregions + creates a new mask or modifies an existing mask using a list of region + definitions or region expressions. + + +XTOOLS + SKYWCS + A new library skywcs has been added to the xtools package. The skywcs + library is a set of routines for managing image and catalog celestial + coordinate systems and for transforming from one celestial coordinate + system to another. Skywcs is layered on the Starlink Positional + Astronomy library slalib which is installed in the iraf math package. + + CATQUERY + A new library catquery was added to the xtools package. The catquery + library is a set of routines for doing local and remote catalog and + image survey access. + +SYSTEM + HELP + Task was modified to call the XHELP code to run the GUI version of + the task if requested. Task output is the same if the device + remains the default 'terminal' value, however resetting the 'device' + parameter to one of 'gui', 'html', or 'ps' will either spawn the GUI + task under xgterm or print the converted help page to the stdout. + + LROFF + The task was enhanced with a new 'format' parameter that allows the + text to be formatted as one of: plain-text, HTML, or Postscript. + + + + +7. Parameter File Changes + +In the tables below each parameter change is identified with one of the +following codes followed by task name and the description of the change. + * n = new parameter + * c = changed/modified parameter + * d = deleted parameter + + +CL + n cl Added the new CL parameter "release". This + is a string valued parameter with values such + as "2.11.3a", "2.12", "3.0" etc. This differs + from "version" which is a descriptive string + such as "NOAO/IRAF V2.11.3 EXPORT". There can + be multiple releases of one version of the + software, and "release" specifies exactly what + build the software is. The release strings are + composed in such a way that they can be used + in expressions, e.g. (release >= 2.11.3) would + be true for IRAF V2.11.3 and all subsequent + releases. + +DATAIO + c dataio.export Made the 'format' parameter automatic mode + c dataio.import Made the 'format' parameter automatic mode + +IMAGES + n imcoords.imcctran Added a new parameter longpole to the imcctran + task. If longpole=yes then coordinate transfor- + mations with zenithal projections will be rot- + ated using longpole rather than the CD matrix. + + c immatch.wregister Fixed boundary option typo, "refect" to "reflect". + c immatch.sregister Fixed boundary option typo, "refect" to "reflect". + + n immatch.imcentroid Added a new parameter maxshift to the imcentroid + immatch.imalign and imalign tasks. Maxshift is the maximum perm- + itted difference between the computed and predicted + shifts. Maxshift can be used to reject objects whose + centers have wandered too far from the expected + center. By default maxshift is undefined. + + n immatch.geomap Added a new parameter maxiter to the geomap and + immatch.ccmap ccmap tasks. Maxiter defines the maximum number of + rejection iterations and has a default value of 0 + for no rejection. + + c immatch.geomap Changed the default value of the ccmap and geomap + c immatch.ccmap parameter reject from INDEF to 3.0. + + c immatch.imcombine Numerous changes, see details above + + c imgeom.imlintran Changed the nrows argument names to nlines + + + n imutil.hedit Added a new addonly parameter to the hedit task. If + addonly is set a new field will only be added to + the image header if it does not already exist. + + n tv.imexamine Added new parameters 'output', 'ncoutput', and + 'nloutput' used by the new 't' keystroke when + outputting an image section centered on the cursor. + +SYSTEM + n help New parameters required for GUI options, output + formats for HTML/PS, printer, etc. + n lroff Added new 'format' parameter for HTML/PS output + +UTILITIES + + c utilities.surfit Added support for the half cross-terms option to + the surfit task. This involved changing the type + of the xterms parameter from boolen (yes/no) to + string (none,half,full). + +NOAO + + ASTUTIL + n astutil.setairmass new parameters ra, dec, equinox, st, ut, scale + + DIGIPHOT + n apphot new package parameters wcsin, wcsout, and cache + n apphot.center new parameters wcsin, wcsout, cache + n apphot.daofind new parameters wcsout, cache + n apphot.fitpsf new parameters wcsin, wcsout, cache + n apphot.fitsky new parameters wcsin, wcsout, cache + n apphot.phot new parameters wcsin, wcsout, cache + n apphot.polymark new parameters wcsin, wcsout, cache + n apphot.polyphot new parameters wcsin, wcsout, cache + n apphot.qphot new parameters wcsin, wcsout, cache + n apphot.radprof new parameters wcsin, wcsout, cache + n apphot.wphot new parameters wcsin, wcsout, cache + + n daophot new package params wcsin, wcsout, wcspsf, and cache + n daophot.addstar new parameters wcsin, wcsout, wcspsf, and cache + n daophot.allstar new parameters wcsin, wcsout, and wcspsf + n daophot.daoedit new parameters cache + n daophot.daofind new parameters wcsout, and cache + n daophot.group new parameters wcsin, wcsout, wcspsf, and cache + n daophot.nstar new parameters wcsin, wcsout, wcspsf, and cache + n daophot.peak new parameters wcsin, wcsout, wcspsf, and cache + n daophot.phot new parameters wcsin, wcsout, and cache + n daophot.psf new parameters wcsin, wcsout, and cache + n daophot.substar new parameters wcsin, wcsout, and cache + + + ONEDSPEC + n standard new parameter mag, magband, and teff. These + n splot params can be use to specify calibration files + n lcalib as blackbody curves scale to a specified magnitude + + TWODSPEC + c apextract.apall1 Reduced the 'polysep' parameter. + c apextract.apdebug Reduced the 'polysep' parameter. + c apextract.apfit1 Reduced the 'polysep' parameter. + c apextract.apnoise1 Reduced the 'polysep' parameter. + c apextract.apnorm1 Reduced the 'polysep' parameter. + c apextract.apparams Reduced the 'polysep' parameter. + + + + + +8. Details of Major System Changes + + + +8.1 FITS kernel changes + The FITS kernel was modified to add support for storing images in + extensions as compressed pixel masks. The mask is stored as a binary + table using the "ZIMAGE" (compressed image) convention proposed by White, + Greenfield, Pence, and Tody in 1999: + + http://heasarc.gsfc.nasa.gov + /docs/software/fitsio/compression/compress_image.html + + In the current implementation only the "PLIO_1" compression + algorithm is implemented. Mask extensions may be read or written directly + by the kernel. When writing a new extension it will be appended to the + MEF file. To append an image to a MEF file as a mask, include "type=mask" + in the image kernel section when the output image is opened. + + Masks are interfaced to the system as images and may be read and + written like any other image via IMIO. They have a normal image header + and can be manipulated with any program that deals with images. The pixel + type is INT. + + It is also possible to access a mask image as a PLIO mask. An + IMSTATI query for IM_PLDES parameter will return the PLIO mask descriptor. + While a mask extension is opened under IMIO it is represented as a PLIO + mask and may be accessed in this form like any other mask. + + The mask image is stored in the FITS binary table (BINTABLE) + extension when the image is closed, and is loaded from the extension when + the image is opened. The compression representation used to store the + mask in the binary table is the same as is used within PLIO. The new + (V2.12) encoding is used, allowing very large masks to be stored. + Currently masks up to 3D are supported. Data on each 2D mask plane + will be compressed in both X and Y as with PLIO. The depth of the mask + is preserved. + + Although a mask is stored as a binary table the format of the + table is not completely general. In the current implementation there + can be only one column in the table (COMPRESSED_DATA). This is an + integer-valued variable length array column containing, for each line of + the N-dimensional image, the PLIO compressed version of that image line. + The actual compressed data is stored in the heap area of the table. + Multiple image lines may point to the same compressed line list, e.g., + to store the empty line or to compression in Y. + + + + +8.2 Large Image Support + + The following changes were made to enable IMIO to use larger +buffer sizes to optimize i/o for large images: + + The default file buffer size set by IMIO is unchanged: it is still + about 512 MB, the value set for V2.11.2. However, a new parameter + IM_BUFFRAC was added. Both IM_BUFSIZE and IM_BUFFRAC are used to help + determine the FIO buffer size set when an image is opened. The logic + for this is implemented in imsetbuf.x. + + Backwards compatibility. If you do nothing about IMIO/FIO buffers + in your program, the system may transparently use a larger buffer for + larger images. If you set BUFSIZE in your program, the system will + by default use the value you give, or possibly a larger value, if the + image you are accessing is very large. If you set BUFSIZE and you want + to guarantee that the value you set is used (even for very large images) + then you should also set BUFFRAC=0 to ensure that only BUFSIZE is used. + + How it works. BUFFRAC specifies the default FIO buffer size used to + access an image, expressed as a percentage of the size of the image. + For example, the builtin default value of BUFFRAC=10 will try to make a + FIO buffer 10% of the size of the image. The actual value used will be + given by BUFFRAC, but will be at least BUFSIZE, and no more than a builtin + default maximum value, currently 32 MB. Given the builtin defaults, + the buffer size will range from 0.5 to 32 MB depending upon the size of + the image being accessed. As noted above, BUFSIZE and BUFFRAC can be + set to force the buffer size to a specific value if desired. + + Environment variables for both parameters are provided. The names + are "IMIO_BUFSIZE" (specified as bytes) and "IMIO_BUFFRAC" (specified + as a decimal fraction). If defined, these override (at image open time) + the builtin default values for both parameters. An IMSET call by the + application will override all such defaults. + + The FIO buffer allocated will not be larger than the size of the + image. The FIO buffer will also not exceed the maximum size set by + the file driver being accessed. For example, for PLIO images the file + buffer will not exceed about 2KB, even for a very large mask. This is + because the "pixel file" for a PLIO image is dev$null, the driver for + which specifies a maximum i/o buffer size of 2K (the real file to load + or save the mask will use a different descriptor). + + The intent here is to provide an adaptive mechanism for setting the + FIO buffer size used to access an image, which automatically adapts to + the size of the image being accessed. If you access a lot of small + images you will get smaller buffers - everything will be as before. + If you access very large images, you may get large buffers up to the + builtin maximum value of (currently) 32 MB. + + Using large buffers could cause a machine to run out of memory. + However, it is likely that if someone is working on 300 MB images + that they are using a machine which has a memory at least that large + - probably larger. If there are problems, the environment variable + overrides can be used to tune IMIO. + + The reason for large file buffers is to limit the number of disk + data transfers, and hence the number of disk seeks. Using buffers larger + than a certain amount (32 MB is generous) is probably counterproductive. + If the i/o system provides 20 MB/sec i/o transfers, 32 MB will take + 1.6 seconds. This should be more than a large enough granularity to + provide efficient i/o, hence is a reasonable limit (at this point paging + effects are likely to dominate). + + + +8.3 Virtual Memory Cache + + The VMcache client interface and daemon provide a method by +which data-intensive IRAF tasks (or non-IRAF tasks for that matter) can +manage how files/images are maintained in virtual memory to avoid +excessive system paging. In essence it's a way to "lock" a specific +image in memory to improve performance. As of this release no tasks in +the system have been modified to make use of the VMcache daemon, +however installing it in the system at this point provides a framework +for future applications and systems development. + + The following notes summarize the changes made for this feature +and describe it's function in more detail. A more complete description +of the interface, environment variables which control it, etc can be +found in the main systems revisions file iraf$local/notes.v211. + + The source for the developmental version of the VMcache library + and the VMcache daemon (vmcached) have been installed in the + unix$boot tree and the HSI binary file driver was modified to add VMcache + client support. This adds two new capabilities to the driver: 1) + built-in support for direct i/o (on systems that support it), and 2) + a client interface to the VMcache daemon to permit the daemon to + optimally manage binary file i/o if a VMcache daemon is present. + + The vmcached code is complete but only enough debug/testing was done to + support development of the VMcache client interface for IRAF (the vmcached + code is debugged but the new version of the vmcache library code has + not been tested). Since the daemon can be utilized outside the normal + IRAF release we do not have to fully develop it for the release. + + It should be stressed that VMcache is only useful or warranted for + systems that are very data intensive. The standard host operating + system file access heuristics are best for "normal" processing where + either the system is not really busy, or the datafiles are not + excessively large. On systems with very large physical memories + where massive amounts of data are being processed, VMcache can make + a significant difference in overall system performance. + + VMcache is too complex to document here. Without going into the + details, its function is to manage a cache of files in system + virtual memory. Files can be explicitly cached or uncached, or they + can be "accessed", and VMcache will decide whether or not to cache + the file in virtual memory. This is what the VMcache client + interface does: every time it accesses (opens or extends) a file + larger then the VM threshold it sends an "access" directive to the + VMcache daemon. The daemon sends back a response of 0 (file not + cached; use direct i/o to access the file), or 1 (file cached in VM; + use normal VM-buffered i/o to access the file). Even if a file is + not cached the daemon keeps track of all accesses. Files which are + frequently accessed will have a higher prority and are more likely + to be cached in memory. + + The VMcache daemon is a separate system-level program outside of + IRAF. This is necessary to provide a central system-wide cache + controller. It also provides flexibility, allowing multiple + versions of the daemon to exist, e.g., to allow experimentation with + different types of caching algorithms. It also allows easy + customization of the daemon independently of the IRAF applications + using the VMcache client interface. + + + + +8.4 New Developer Libraries + + o Several new libraries are now available for developers: + + PSIO New Postscript text generation library installed in the + sys$psio. The PSIO interface is used to format a block of + text as Postscript output on a page of a given size (Letter, + Legal, A4 or B5). See the psio$README file for details. + + CATQUERY Remote astrometric/photometric catalog access lib installed + in the XTOOLS utility library. + The catquery package provides a set of routines for local + and remote catalog and image survey server access. The sup- + ported catalogs and image surveys are described in records + stored in a catalog and image survey configuration file + respectively. The catalog and image survey records specify + the network address, the query format, and the output format + for each supported catalog or image display server. See + "help catalogs" and "help surveys" for details. + + SKYWCS Sky coordinate transformation library installed in the XTOOLS + utility library. + The skywcs package contains a simple set of routines for + managing sky coordinate information and for transforming from + one sky coordinate system to another. The sky coordinate + system is defined either by a system name, e.g. "J2000", + "galactic", etc., or by an image system name, e.g. "dev$ypix" + or "dev$ypix world". + + + + +9. System Changes Which May Affect You + + * SHARED LIBRARY VERSION INCREMENTED (Sun/IRAF only) + The IRAF shared library for SunOS and Solaris platforms has been + incremented with this release due to the nature of various system + changes. Existing IRAF binaries (e.g. locally written software + or external packages) will continue to run using the old shared + image, however they will need to be recompiled against V2.12 in order + to pick up the numerous system bug fixes and features in this release. + In particular, pixel masks produced by V2.12 IRAF tasks may be + incompatible with external packages which have not been recompiled. + + * EXTERNAL PACKAGE RECOMPILATION + The V2.12 release contains changes to the FIO and PLIO/PMIO interface + header files used by numerous applications. Relinking of an external + package may fail to pick up these changes and not recompile a source + file which uses one of these header files if the mkpkg file doesn't + correctly list all of the dependencies (nearly all packages have one + or more mkpkg files which have this problem). In the worst cases + this could lead to a runtime error due to the incompatibilities. + + For this reason we recommend that all packages and local tasks be + recompiled (completely from source* (rather than simply relinked + against the new version) to assure that all changes and new features + will be included. Recompilation also guarantees that packages can + take advantage of some of the larger buffer sizes and optimizations + in this release. Site support can supply a list of missing mkpkg + dependencies for most external packages being developed outside NOAO + that wish to fix these files for a future release. + + * PARAMETER FILE CHANGES + As with all major releases, we recommend that you do a MKIRAF and + delete all your old parameter files after the IRAF upgrade. You may + choose not to do this if you are in the midst of a project and have + setups that may be difficult to reproduce. + + The automatic parameter file update/merge mechanism, which is used + if you do not initialize your parameters with MKIRAF, is based on + file date comparisons. If you run IRAF V2.11 after V2.12 has been + installed, the file dates on your uparm parameter files will be + more recent than the V2.12 installation date. If you then try to + run V2.12, the automatic parameter file merge/update will fail due + to the file dates. The system only updates personal parameter + files which are older than the update date of the system. A + MKIRAF avoids the problem if you delete your parameter files, + causing them to be updated from the system default versions. + + * INSTALLATION SCRIPT CHANGES + As the first step of an ongoing effort to simplify the installation + and system configuration, the IRAF install script was rewritten to + do some error-checking of the iraf setup, present a simplified and + easier to read output, and do some common post-install configuration + of the system. Additionally, the SYSINFO diagnostic script for + finding system errors and reporting on the configuration, and a new + UNINSTALL script for removing IRAF files/links from the system have + also been installed. The old install script is still available as + a fallback in case problems with the new script are found. + + * HELP SYSTEM CHANGES + The HELP task was modified with several new parameters controlling + the display and formatting of the help pages. Help may now be + presented as formatted text (as before), HTML, or fully formatted + Postscript. Additionally, users running under an XGterm window can + use the task in a new GUI mode. The help GUI allows users to browse + the help system and easily search for tasks/topics using a familiar + web-like interface. The GUI mode is not the default, but can be + enabled easily using the 'device' parameter. + + * IMAGE DISPLAY CHANGES + Tasks which display images or interact with the image display were + modified to take advantage of new features added to XImtool V1.3 + (e.g. the multiple WCS and pixel-value readouts and 16 display frame + buffers). These changes were done in a backwards compatible way so + interaction with display servers such as SAOimage, SAOtng, DS9, or + older XImtool versions should be unaffected. If problems are dis- + covered a CL environment variable 'disable_wcs_maps' can be defined + to force all of the old behaviors. These changes do not add any new + functionality to the tasks themselves, only the underlying display + protocols. + + * PLIO Changes + The LEN and BLEN fields of the encoded line list (LL) descriptor + would limit the length of a pixel area (and hence the size of a + pixel mask) to the max size of a signed short, 32768. This was due + to the use of a simple array of type short to encode the line list + (which simplifies handling considerably). Nonetheless the limit to + 32K was unacceptable. The fix adopted was to increase the LL header + from 3 to 7 words. Two 16 bit words are now used to encode each of + LEN and BLEN. A "version" word was added to allow the old, new, and + future encodings to be distinguished. A "hdrlen" word was added to + parameterize the length of the LL header, rather than fix it at + compile time as in the initial version. With this change, the + maximum length of an image line under PLIO is increased from 32768 + to 1073741824 (32768*32768). All the higher level PLIO code is + integer, so should already support larger masks. + + This was done in such a way that old line lists can still be read, + although PLIO will always write out new format line lists (pixel + mask files and images, QPOE, and MWCS all store encoded line lists + in external storage, so backwards compatibility is important; also + existing complied programs will continue to generate the old + format). The cost is 8 bytes per encoded line list. For most masks + this should only increase the size of the mask by a few percent at + most. + + * NEW ENVIRONMENT VARIABLES + The following new environment variables may be defined to tune the + size of the system file i/o buffers used by the image i/o system. + The system will automatically adjust to use larger buffers when + accessing larger images, these variables may be set to further + optimize the buffers + + IMIO_BUFSIZE Size of the FIO buffer size in bytes. + + IMIO_BUFFRAC FIO buffer size expressed as a percentage of + the image size. Actual value will be at least + BUFSIZE and no more than BUFMAX. + + IMIO_BUFMAX Max size of FIO buffer which will override the + 32Mb default. + + + Other miscellaneous environment variables: + + disable_wcs_maps If defined or set to 'yes', this variable will + force any tasks which interact with the image + display to use the old protocols. + + pspage Variable which is used by the PSIO interface to + set the default page size. Acceptable values + include "letter" (the default) for US Letter, + "legal" for US Legal, and "a4" and "b5" for the + most common European sizes. Pspage can be used + by the new HELP and LROFF tasks to automatically + set the desired Postscript page size. + + IRAF (Aug97) V2.11 Revisions Summary IRAF (Aug97) + + + + IRAF V2.11 Revisions Summary + August 27, 1997 + +Introduction + + Modifications and additions to IRAF V2.11EXPORT, compiled since the last +documented release of IRAF, V2.10.3, are summarized below. V2.11EXPORT is +a major release of IRAF and will be available for all supported +platforms. These release notes provide a summary of the major changes in +V2.11. More detailed technical documentation of all system changes will +be found in the "notes.v210" and "notes.v211" files in the iraf$doc and +iraf$local directories. + + 1. Things to be aware of or watch out for + 1.1. Parameter file changes + 1.2. Networking change + 1.3. Image format change + 1.4. FITS kernel + 1.5. RFITS/wfits changes + 1.6. Merged SunOS and Solaris IRAF systems + 1.7. Tape access + 1.8. Default magnitude zero changed + + 2. IMAGES package changes + + 3. Major system changes + 3.1. New FITS image kernel (FXF) + 3.2. Changes to the IRAF native image format (OIF) + 3.3. IMFORT changes + 3.4. Environment variables + 3.5. New intrinsic functions + 3.6. System default modifications + 3.7. Libraries added + 3.8. Graphics changes + 3.9. FITS-related core-level task changes + 3.10. General changes + + 4. New tasks, or old tasks moved to new packages + + 5. Task and package deletions + + 6. Modifications to old tasks + + 7. Parameter file changes + + +The IRAF V2.11 release notes can also be found online on the Internet at +the URL http://iraf.noao.edu/v211revs.html. + + +1. Things to be aware of or watch out for + + +1.1 Parameter file changes + +Since this is a major release we recommend that you do a mkiraf and +delete all your old parameter files. You may choose not to do this if +you are in the midst of a project and have setups that may be difficult +to reproduce. Old IMAGES package parameter files will no longer be +recognized, however, because of the package reorganization mentioned +below. Generally, old parameter files are merged automatically with +any new parameter files if there have been any changes, but if you do +have problems you will need to unlearn the task before you can proceed. +A list of the parameter file changes appears below and you may wish to +check this list to see how this will affect your setups. + +The automatic parameter file update/merge mechanism, which is used if +you do not initialize your parameters with mkiraf, is based on file date +comparisons. If you run IRAF V2.10 after V2.11 has been installed, the +file dates on your uparm parameter files will be more recent than the +V2.11 installation date. If you then try to run V2.11, the automatic +parameter file merge/update will fail due to the file dates. The system +only updates personal parameter files which are older than the update +date of the system. A mkiraf avoids the problem if you delete your +parameter files, causing them to be updated from the system default +versions. + + +1.2 Networking change + +The "set node = foo" syntax, used to enable remote image display under +IRAF networking, has changed. The new syntax requires that an +exclamation be appended to the node name as in the example below (this +dates back to V2.10.4 so many users will already be familiar with the +feature). + + cl> set node = "orion!" + + +1.3 Image format change + +The internal IRAF image format (.imh images) has changed. V2.11EXPORT +can read the old image format but the new image format is not readable +by V2.10.4 or earlier versions. This means that you can not easily go +from the new IRAF system (V2.11) to an old one (V2.10.4 or earlier) +unless you first convert the V2.11 IRAF images to FITS files. All your +old V2.10.4 or earlier images are readable by V2.11EXPORT. The benefit +is that the new image format is machine independent, slightly more +storage efficient, and supports long file pathnames. If it is +necessary to be able to read images written by V2.11 with older +software, V2.11 can be made to write the old IRAF image format by +setting the oifversion environment variable, e.g., "set oifversion = 1" +(the default is version 2). See below for details. + + +1.4 FITS kernel + +A FITS image kernel is available in V2.11, allowing runtime read and +write access to FITS files on disk. There are many related changes to +IRAF image i/o and FITS support. More information on the new image +kernel, and on the expanded FITS support available in V2.11, is given +below. + + +1.5 RFITS/WFITS changes + +rfits and wfits have been modified to support multi-extension FITS +files. The extension numbering convention used is the same as in the +FITS image kernel. As a result, users who read simple FITS files on +disk with a command such as "rfits diskfilename 1 foo" will find that +this no longer works - instead use "rfits diskfilename 0 foo". See +below for details. + + +1.6 Merged SunOS and Solaris IRAF systems + +A single installation of Sun/IRAF will now simultaneously support both +SunOS and Solaris (previously separate IRAF distributions were required +for each). + + +1.7 Tape access + +The "tapecap" mechanism has changed. The system now looks for the +filename "tapecap." followed by the default "tapecap". : +should be the hostname (as used by IRAF networking) of the server +hosting the tape drives described by the tapecap file. For example if +host "gemini" serves up some tape drives it's tapecap file is named +"tapecap.gemini". If a server-specific tapecap file is not found the +default "tapecap" (on the possibly remote server node) is used. This +feature allows a single IRAF installation to be shared by multiple +servers. + + +1.8 Default magnitude zero changed + +The default APPHOT magnitude zero point has been changed from 26.0 to +25.0 to bring it into agreement with the DAOPHOT package default value +and thereby avoid confusion for users who switch back and forth between +packages. The affected APPHOT tasks are phot, photpars, polypars, +polyphot, qphot, radprof, and wphot. The APPHOTX package in the addon +DIGIPHOTX package will retain the old zero point values until IRAF 2.11 +is released after which they will be updated. + +The default value of the magzero parameter in imexamine was changed +from 30.0 to 25.0 for consistency with the DIGIPHOT package. + + +2. IMAGES package changes + +The IMAGES package has been reorganized by function into the 7 +subpackages listed below. + + imcoords - Image coordinates package + imfilter - Image filtering package + imfit - Image fitting package + imgeom - Image geometric transformation package + immatch - Image matching and combining package + imutil - Image utilities package + tv - Image display utilities package + +The new IMAGES package contains a total of 82 tasks, including 26 new +tasks from the IMMATCH and VOL external addon packages, 6 existing +PROTO package tasks, and 1 existing NOAO.PROTO package task. The +undocumented IMAGES package IMDEBUG and its 6 tasks have been deleted +from the IMAGES package. User should use the tasks in the ARTDATA +package instead. + +This reorganization of the IMAGES package should be mostly transparent +to the user and not affect any existing scripts, unless you were using +any of the 6 deleted tasks. By default, the IMAGES subpackages are +automatically loaded when you log in to the CL. Old parameter files +will not be recognized since the package names have changed. + + +3. Major system changes + + +3.1 New FITS image kernel (FXF) + +V2.11 introduces a new image kernel providing runtime access to FITS +multi-extension image datafiles. What this means is that IRAF tasks +can now read and write FITS images directly at runtime. The native IRAF +image format (used by images with the .imh extension), remains the +default as it is the most efficient and well-tested format. IMH, FITS, +and the other types of images supported by IRAF can be used +interchangeably in most IRAF tasks. Although we have extensively tested +the new FITS image kernel, it is still evolving, is complex, and still +has some bugs. Users should use it with caution. Please let us know of +any problems. + +Besides support for classical FITS images, the new FITS kernel also +supports multi-extension FITS files: several FITS files packed into one +large file with a PHU (Primary Header Unit) that contains global header +information shared by the other files. Multi-extension FITS files are +0-indexed, with the PHU being 0 and the first image extension (or other +data extension) at index 1. If there is no PHU then the first FITS +image is 0 and there is no global header. + +For further details about the FITS kernel please see the new FITS Kernel +User's Guide by Nelson Zarate. + + +3.2 Changes to the IRAF native image format (OIF) + + o It was necessary to change the IRAF image format to increase the + maximum path length for header and pixel files. This made it necessary + to change the disk image format, since the old format only allowed 80 + characters for the pixel file pathname. The path lengths can now be up + to 255 characters. + + Support for two versions of the image and pixel file headers was added. + V2.11 will read both the old image format (V1) and the new image format + (V2). But the new image format is not readable by older versions of IRAF. + + o Native format IRAF images (OIF type or extension ".imh") are now machine + independent, for example, a PC and a Sun can now access the same images. + + o Support was added for byte swapping pixels. With the machine independent + image header, this allows .imh images to be read on any node (integer) + or any IEEE-compatible node (floating). + + o Some pointers: "strings foo.imh" (or other tools like the "less" file + viewer) can be used at the Unix level to look at the text contained in + the new V2 OIF image headers. + + +3.3 IMFORT changes + + o IMFORT was brought up to date to read and write the new V2 ".imh" images. + The old V1 format is still supported but new images are written using + the new machine independent V2 format by default. + + o Image headers can now be any size (the old IMFORT had a fixed, relatively + low, limit on the image header size). + + o The "min_lenuserarea" variable is now supported by IMFORT (since IMFORT + is host level the variable must be defined in the host environment). + The builtin default header buffer is 64000 chars, which is about 800 + card images. + + +3.4 Environment variables + +Several new environment variable have been added to the system. + + o The new environment variable imextn determines the image kernels + (image file formats) recognized by IRAF and defines the mapping of + imagefile extensions to these image formats. A file that does not have + an extension listed in imextn may not be recognized as an image by all + IRAF tasks. The default value of imextn is as follows: + + imextn = "oif:imh fxf:fits,fit plf:pl qpf:qp stf:hhh,??h" + + IRAF tasks will not recognize a file as an image unless it has an + extension (except rfits which will read FITS files on disk that + have no extensions). The rename task can be used to add + extensions to image files if needed. "imextn" can be redefined (use + reset imextn = "new-value") to modify the mapping of extensions to + image types. + + The meaning of the fields of the default "imextn" are as follows. Each + substring corresponds to a single kernel. The "xxx:" is the internal + name of the image kernel, i.e. "oif", "fxf", "plf", etc. A comma + delimited list of the extensions, or extension patterns, associated with + that image format follows the colon. For example, for the FITS image + kernel, the internal kernel name is "fxf" and the system default file + extensions are ".fits" and ".fit". + + - oif:imh - The original (native) IRAF image format. + + - fxf:fits,fit - The FITS image extension format, which supports + classical FITS images as well as multi-extension FITS files. + + - plf:pl - The pixel list format used for compressed pixel masks. + + - qpf:qp - The QPOE image format for event list data (typically + X-ray or other high energy data). + + - stf:hhh,??h - The Space Telescope runtime GEIS image format. + + Users can define extensions for the fxf and stf kernels. For example, + if you have FITS files on disk that have a .ft extension then you can + reset imextn so that IRAF will recognize these image extensions: + + cl> reset imextn="fxf:ft" + + The new .ft extension for the FITS kernel images will now override the + default values - the other kernels remain unchanged. ".fits" will no + longer be recognized as a FITS file unless you include it in the list + of extensions for the "fxf" kernel. + + The first extension given for a kernel defines the default file + extension for new images of that type (rather than e.g. the value of + imtype, or a builtin default). + + The value of "imextn" is only read once when a process starts up. Hence + it is advisable to do a "flpr" (flush process cache) after changing + this variable, to force all processes to re-read it. + + o The environment variable imtype defines the default image type for + new images created by IRAF. If a file extension is given explicitly + when creating a new image then this file extension, in combination with + the "imextn" mappings, determines the type of the new image. Otherwise + the type is determined by the value of "imtype". Typical values are + "imh" for native IRAF images, or "fits" for FITS images. The internal + kernel name documented above for "imextn" can be used instead of a file + extension to ensure that the desired image format is used regardless of + what extensions are assigned to that type by imextn. + + The default value of imtype is "oif,noinherit" which means that the + IRAF native format is the default for all new images, regardless of the + type of the input image (i.e. do not "inherit" the input image type). + "inherit" was the default in V2.10 and earlier versions of IRAF. + + For example, if you wish to use FITS as the default for new images you + can set imtype=fits as follows: + + cl> reset imtype="fits" + cl> flpr % needed before the next task execution + + Assuming "imextn" defines ".fits" as a valid file extension for FITS + imagefiles (kernel "fxf"), all new images produced by IRAF will be FITS + files with the extension .fits unless some other extension is given + explicitly when creating a new image. + + cl> reset imtype = "imh,inherit" + + This example sets the default type for new images to ".imh" for native + format images, but enables image type inheritance. By default new + images will be of the same type as the input image. For example if a + FITS image is being read another FITS image will be output, or if a + pixel mask is being read a pixel mask will be created. + + You can override the default output image type specified by imtype by + giving an image extension (as defined by imextn) explicitly in the image + name, e.g. "pix.imh", "pix.fits", "pix.pl" and so on. + + o A new environment variable called imclobber has been added. + The default value is set to no. If imclobber is set to yes, images + can and will be overwritten, without warning, when you create new + images. + + o The original IRAF image format (OIF) kernel now supports an environment + variable oifversion which, if defined, specifies the file + version for new OIF images (for example, oifversion=2 produces the + new format, or version 2 images). By default the variable is undefined, + the builtin OIF default will be in effect, and new-format images will + be generated. This variable is provided only for backwards + compatibility, e.g., when using V2.11 IRAF with old software which + cannot easily be updated. + + +3.5 New intrinsic functions + +Two new intrinsic functions were added to the CL, imaccess and defvar. +imaccess tests whether an image exists, e.g., (imaccess("dev$pix")) or +(imaccess(foo.fits[3])). defvar tests whether an environment variable +exists, e.g. (defvar("imextn")). + + +3.6 System default modifications + + o The default size of the user area (min_lenuserarea) was increased + to 64000 (about 800 80 character cards). There was some ambiguity about + units for min_lenuserarea; it should be consistently characters now. + + o The maximum number of open IRAF logical files was increased from 128 to + 256. This is good news for imcombine users. + + o Various buffer limits were increased: + + - The IRAF line length was increased from 161 to 1023 characters. + One often ran into this lower limit when entering a long list of + input image names, for example. + + - CL commands can now be 2047 characters long (the old limit was + 1024) - this is particularly useful for scripts. + + - IRAF file names can now be up to 255 characters long. + + - Expanded file names (pathnames) can be up to 511 characters long. + + +3.7 Libraries added + +The Starlink positional astronomy library SLALIB was added to the math +package. + + +3.8 Graphics changes + + o SGI Translator change: Modified the header ID string produced by + sgi2uapl to be "%!PS", this is required by certain models of printers. + + o Installed graphcap support for the STSDAS PostScript graphics kernel. + + o The SGI graphics kernel was upgraded with a better roman font, and a + new greek font was added. To use the new high-quality greek fonts use + the "\fG" escape sequence when you use the "T" keystroke to mark text + in a plot, e.g., \fGa Hydra would produce " Hydra". The greek font + may also be used in label parameters for tasks like GRAPH, for example + + cl> graph dev$pix xlabel="Wavelength\\fG(A)" + + would produce an Angstrom symbol in parenthesis. The double backslash + is necessary to pass the escape string thru the CL. A file containing + the mappings for the greek fonts and other special characters can be + found at http://iraf.noao.edu/greek.ps. + + +3.9 FITS-related core-level task changes + + +3.9.1 IMHEADER + +The behavior of imheader has changed a bit - typed with no arguments it +will list all the images in the current directory, as in the following +example: + + cl> imhead + pix4.imh[512,512][short]: m51 B 600s + boc.fits: FXF: must specify which FITS extension (boc.fits) + fits.fits[512,512][short]: m51 B 600s + pix.fits[512,512][short]: m51 B 600s + pix3.fits[512,512][short]: m51 B 600s + pix5.fits: FXF: must specify which FITS extension (pix5.fits) + zero.fits: FXF: must specify which FITS extension (zero.fits) + mask.pl[512,512][int]: m51 B 600s + foo.qp[1024,811][int]: + +The multi-extensions FITS files show up in the list with the message +"FXF: must specify which FITS extension", since these files contain +multiple images and the task does not know which image to open to get +header information. + +At present imheader does not use "imextn" to determine what is and is +not an image. The parameter "imlist" defines the valid imagefile +extensions. If imextn is modified "imlist" may need to be modified as +well. + + +3.9.2 RENAME + +The rename task was modified to allow a destination directory to be +specified without changing the filename. A new "field" parameter option +"all" was added and made the default so the entire filename is changed +(or moved in the case of a destination directory). When field is set +to "extn" filenames without an extension will not have the new extension +appended so a filename isn't generated which can get overwritten. + + +3.9.3 rfits/wfits + +Some changes were also implemented in rfits and wfits to add support +for multi-extension FITS files. + + o The default action of wfits when writing to tape is unchanged for + single image files. + + wfits now has a new parameter called "fextn" and it is set to + "fits". This parameter only affects FITS files written by wfits + to disk - the extension .fits will automatically be added to the + filenames, so that the files will be automatically recognized by + the FITS image kernel. + + wfits also has two additional parameters called "extensions" and + "global_hdr" that deal with writing multi-extension FITS files. + + o The default action of rfits from tape to disk remains unchanged. + + If rfits is used to read FITS files on disk then users need to + be aware of a change to the behavior of the "file-list" parameter. + File-list is now used to define the list of files on the tape as + well as the list of extensions in a multi-extension FITS image. + To read single FITS images on disk use "" as the value for + "file-list". Some users have been using "1" for this value but now + that value will try to read the first extension which doesn't + exist - use "0" if you wish to put something there. + + rfits will unpack multi-extension FITS files upon a read. If you + wish to retain the multi-extension FITS format then use T2D and + RENAME. + +The help pages have been updated to reflect these changes. + +wfits now writes ushort (16 bit unsigned short) images to FITS images +with bitpix=16, bscale=1.0, and bzero=32768.0 by default. rfits will +read these images back as type ushort. + + +3.10 General changes + + o The GSURFIT package has been updated to include support for the "half" + cross terms option useful in computing plate solutions. Tasks that can + make use of this feature have been updated although their default + behaviors have not changed. + + o The code which computes the CD matrix from CDELT/CROTA was modified. + The old code computed the diagonal (scale) terms correctly but the + rotation terms were evidently incorrect. The old code was based on + the 1988 Hanisch and Wells WCS paper and the new code is based on a + more recent paper by Mark Calabretta et al, which supercedes the + 1988 representation. The affect of this change should be limited + as it only affects rotated images for which CDELT is given but no + CD matrix is defined. (V2.10.4p2) + + o Several new celestial coordinate projection functions have been added. + Users with IPAC data that use the CAR projection function should now be + able to read the image coordinates directly with LISTPIXELS, etc. + + +4. New tasks, or old tasks moved to new packages + + Task Name Package Function + + CCXYMATCH IMCOORDS Four new tasks for computing and evaluating + CCMAP simple astrometric plate solutions and storing + CCSETWC them in the image headers in fits-compatible + CCTRAN format. + + CCFIND IMCOORDS CCFIND locate objects in an image given a + celestial coordinate list and the image wcs. + + IMCCTRAN IMCOORDS Two new tasks for transforming celestial + SKYCTRAN coordinate lists and image celestial + coordinate systems from one celestial + coordinate system to another. + + STARFIND IMCOORDS STARFIND automatically detects stellar objects + in a list of images. + + WCSCTRAN IMCOORDS A new task for transforming between IRAF image + coordinate systems. + + WCSEDIT IMCOORDS Two unaltered former PROTO package tasks for + WCSRESET editing IRAF image coordinate systems. + + FRMEDIAN IMFILTER Four new tasks for doing circular/elliptical/ + FRMODE ring image median filtering. + RMEDIAN + RMODE + + IM3DTRAN IMGEOM The former addon VOL package task IM3DTRAN for + doing 3D image transposes. + + GEOXYTRAN IMMATCH A new task for transforming coordinate lists + using the results of the GEOMAP task. + + IMCENTROID IMMATCH Four new tasks for computing matched pixel + SKYXYMATCH lists. IMCENTROID is a modified version of the + WCSXYMATCH PROTO package task of the same name. + XYXYMATCH + + SKYMAP IMMATCH Two new tasks for computing geometric + WCSMAP transforms using the image coordinate system + information. + + IMALIGN IMMATCH Three new tasks for doing automated image + SREGISTER registration. IMALIGN is a modified version + WREGISTER of the PROTO package task of the same name. + + WCSCOPY IMMATCH A new task for copying the coordinate system + of a reference image to a set of input images. + + PSFMATCH IMMATCH A new task for matching the PSFs of a set of + input images to the PSF of a reference image + using Fourier techniques. + + LINMATCH IMMATCH A new task for matching the linear intensity a + scale of a set of input images to the + intensity scale of a reference image. + + IMFUNCTION IMUTIL The former PROTO package task for applying a + single argument function to an image. + + IMJOIN IMUTIL The former addon VOL package task for joining + same-dimensioned images along a specified + dimension. + + IMREPLACE IMUTIL The former PROTO package task IMREPLACE for + replacing bad pixels based on their value. + + IMTILE IMUTIL A modified version of the NOAO.PROTO IRMOSAIC + task for tiling same sized 2D images into a + single mosaiced image. + + EXPORT DATAIO Two new tasks from the external IMCNV package + IMPORT for exporting IRAF images to binary formats + and for importing binary files into IRAF + images. + + TEXT2MASK PROTO This new task appears in conjunction with a + new pixel mask based version of FIXPIX. + + IMEXTENSIONS PROTO This task selects and lists image extensions + in files. Image extensions currently occur + in multi-extension FITS files and multi-group + Geiss (STF format) files. + + CCDMASK CCDRED This new task creates a pixel mask from a + CCD image. + + AIDPAR ONEDSPEC New parameter set for automatic line + identification for the tasks AUTOIDENTIFY, + IDENTIFY and REIDENTIFY. + + AUTOIDENTIFY ONEDSPEC A new task to automatically identify lines + and fit the dispersion function. + + SKYTWEAK ONEDSPEC Sky spectra are shifted and scaled to best + subtract sky features from data spectra. + + TELLURIC ONEDSPEC Telluric calibration spectra are shifted and + scaled to best divide out telluric features + from data spectra. + + ASTCALC ASTUTIL An astronomical calculator. + + ASTRADIUS ASTUTIL Finds images within a circle on the sky. + + +5. Task and package deletions + +CUBE, DUMP, GSUBRAS, MAXMIN, MKIMAGE, MKTEST: These tasks have been +superseded by the equivalent tasks in the IMAGES or ARTDATA packages. +The functionality of these tasks still exists in the +iraf$pkg/images/lib/zzdebug.x file. + +REGISTER: This task has been renamed to GREGISTER. + +IMALIGN, IMCENTROID, IMFUNCTION, IMREPLACE, WCSEDIT, WCSRESET: Moved to +the IMAGES package. + + +6. Modifications to old tasks + +Grouped by package, a list of modifications to old tasks in IRAF are +summarized below. We have included modifications since the V2.10.3 +release. + +IMFILTER: + FMEDIAN, FMODE, MEDIAN, MODE + Minimum and maximum good data value parameters zloreject and zhireject + and a verbose option parameter were added. + MEDIAN, MODE + The 64 x 64 maximum kernel size limit was removed from these tasks. + +IMMATCH: + GEOMAP + Renamed the output parameter to database for the sake of consistency + with other new images tasks. + + Changed the default value of the reject parameter from 0.0 to INDEF. + + Added the transforms parameter. Transforms permits the user to specify + the names of the output database records explicitly. + + Added the parameter results. Results permits the user to save a summary + of the results including a description of the transform geometry, and a + listing of the input coordinates, the fitted coordinates, and the fit + residuals. + + Added the fitgeometry parameter. Fitgeometry permits the user to + constrain the linear part of the fit to: 1) x and y shifts only, 2) x + and y shifts and rotation only, 3) x and y shifts and x and y scale + changes only, 4) x and y shifts, rotation, and a scale change only, 5) + x and y shifts, rotation, x and y scale changes only, and 5) x and + shifts, rotation, skew, and x and y scale changes. + GREGISTER + Renamed the register task gregister to emphasize that it is paired with + the geomap task and to avoid confusion with the new registration tasks. + GEOTRAN, GREGISTER + Renamed the transform parameter to transforms. + + Added the verbose parameter. + GEOTRAN + Added the ability to write to a section of an existing image. + IMCOMBINE + The limit of the number of images that may be combined has been + removed. If the number of images exceeds the maximum number of + open images permitted then the images are stacked in a single + temporary image and then combined with the project option. + Note that this will double the amount of diskspace + temporarily. There is also a limitation in this case that the + bad pixel mask from the first image in the list will be applied + to all the images. + + Integer offsets may be determined from the image world + coordinate system. + + A combination of ushort and short images now defaults to + integer. + + Added support for type ushort images. + + Added a new options for computing offsets using the image wcs. + + Removed the limit on the maximum number of images that can be combined. + IMALIGN, IMCENTROID + Renamed the images parameter to input, changed the reference parameter + mode from hidden to automatic, and reversed the order of the reference + and coords parameters. + +IMUTILS: + IMEXPR + Modified the task so that it will accept an image name that looks like + a number in the first few characters, but which is really an image + name. For example, "123.imh" or "../foo.imh". The previous version + of imexpr was treating any string which looked like a number in the + first few characters as a numeric constant. (V2.10.4p2) + IMREPLACE + The lower value is now rounded up for integer images so that a + range like 5.1-9.9 affects pixels 6-9 instead of 5-9. + IMSUM + Now allows "ushort" data types. + +TV: + DISPLAY + The bad pixel mask, overlay mask, sample mask, and overlay + colors parameters and functionality have been added. The + "nsample_lines" parameter is now an "nsample" parameter. + + Bugs in the coordinate system sent to the image display for + cursor readback were fixed. + IMEDIT + If xorder or yorder are zero then a median background is + computed for the 'a' and 'b' keys. + IMEXAMINE + ('a' and 'r'): The fit to the radial profile points now + includes both a Gaussian and a Moffat profile. The Moffat + profile exponent parameter, beta, may be fixed or left free to + be fit. + + ('a' and 'r'): New estimates fo the FWHM were added to the 'a' + and 'r' keys. These include the Moffat profile fit noted + above, a direct measurement of the FWHM from the radially + binned profile, and a Gaussian or Moffat fit to the radial + enclosed flux profile. The output from these keys was modified + to include the new information. + + ('a' and 'r'): The direct FWHM may be used to iteratively + adjust the fitting radius to lessen the dependence on the + initial fitting radius value. + + ('k'): Added a kimexam parameter set. + + The default value of rimexam.magzero parameter was changed from + 30.0 to 25.0 for consistency with the digiphot package. + +PROTO: + FIELDS + The default value for the lines parameter was changed to an open + upper limit. + + Changed the default value of the lines parameter from "1-999" to + "1-" so that the upper bound would be open ended. + FIXPIX + This task replaces the old task (now obsolete.ofixpix) and + works with the more general pixel mask facilities. It also + provides greater flexibility in chosing the interpolation + direction. + +ICFIT used in various tasks: + ICFIT + The :xyshow output was modified to 1) not include colon labels, + 2) print (X, Y, Y fit, Weight) instead of (X, Y fit, Y), and 3) + the printed values are those actually used in the fit when using + composite points (naverage not 1). + +ARTDATA: + MK1DSPEC + Lorentzian and Voigt profiles were added and the parameters and + input line list format were changed. The widths are now FWHM + instead of gaussian sigmas. + MKOBJECTS, MKNOISE + The default value of "ranbuf" was changed to zero. + GALLIST + The default value for the minimum elliptical galaxy axial ratio + was changed to 0.3 to cover the range E0-E7 uniformly. + MKPATTERN + Now allows ndim=0 to make an dataless header. + Now allows ushort pixel type. + +ASTUTIL: + SETJD + The checking of the epoch keyword value was improved. + Previously if there was a problem with the keyword value + (missing or malformed) the task would use the epoch of the + observation. Now it is an error if an epoch keyword is + specified but the epoch value can't be determined. Also a + leading 'B' or 'J' is allowed and a warning will be given if + the epoch value is unlikely. + ASTHEDIT + There are new astronomical functions and input/output functions. + The command syntax may now use "=" as a delimiter as well as + the whitespace. + + A new parameter "update" allows protecting images and accessing + read-only images for the purpose of calculating and printing + quantities. + + The special variable name "$I" has the value of the image name, + $D the current date, and $T the current time. + + The case of no image name creates and deletes a temporary image + so the task can be used purely as a calculator (but see + astcalc). + +CCDRED: + CCDPROC + The bad pixel fixing was modified to allow use of pixel masks, + images, or the text file description. Bad pixel masks are the + desired description and use of text files is only supported for + backward compatibility. Note that support for the trimmed or + untrimmed conversion from text files has been eliminated. + + Line-by-line overscan/prescan subtraction is now provided with + three simple algorithms. + COMBINE + The limit of the number of images that may be combined has been + removed. If the number of images exceeds the maximum number of + open images permitted then the images are stacked in a single + temporary image and then combined with the project option. + Note that this will double the amount of diskspace + temporarily. There is also a limitation in this case that the + bad pixel mask from the first image in the list will be applied + to all the images. + + Integer offsets may be determined from the image world + coordinate system. + + Fixed a bug where a variable was improperly used for two different + purposes causing the algorithm to fail. This also affected IMCOMBINE + and SCOMBINE. See bug 316 for details. (V2.10.4p2) + COSMICRAYS + The output bad pixel data accidentally included some extra fields + making it incorrect to use the file directly with BADPIXIMAGE. + The extra diagnostic fields were removed. For details, see bug 311 + in the buglog. (V2.10.4p2) + +ECHELLE: + ECIDENTIFY + The dispersion units are now determined from a user parameter, + the coordinate list, or the database entry. + +IMRED Spectral Packages: + DOARGUS, DOFIBERS, DOHYDRA + A sky alignment option was added. + + The aperture identification can new be taken from image header + keywords. + + The initial arc line identifications is done with the automatic + line identification algorithm. + DOSLIT, DO3FIBER + The initial arc line identifications is done with the automatic + line identification algorithm. + +ONEDSPEC: + Support for the Sloan Sky Survey was added by allowing multifiber + reductions with up to 500 fibers with non-linear dispersions. (V2.10.4p2) + + BPLOT + Fixed a general problem in BPLOT and SLIST that caused a segmentation + violation error. See buglog 312 for details. (V2.10.4p2) + FITPROFS + Modified to include lorentzian and voigt profiles. The + parameters and positions file format have changed in this + version. A new parameter controls the number of Monte-Carlo + samples used in the error estimates. + IDENTIFY + The dispersion units are now determined from a user parameter, + the coordinate list, or the database entry. + A new key, 'e', has been added to add features from a line list + without doing any fits. This is like the 'l' but without the + automatic fitting before and after adding new features. + + A new key, 'b', has been added to apply an automatic line + identification algorithm. + + The 'x' key has been changed to use the automatic line + identification algorithm. The allows finding much larger + shifts. + + The match parameter may now be specified either in user + coordinates or in pixels. The default is now 3 pixels. + + The default threshold value has been changed to 0. + REIDENTIFY + A new parameter, "search", was added to specify a search radius + for the automatic line identification algorithm. + + The "nlost" parameter now also applies when not tracing; i.e. it + will issue a warning and not record a solution if the specified + number of features is lost when reidentifying against a specific + reference spectrum as is done with multispec data. + + The task will now work with only a warning if the reference + image is absent; i.e. it is possible to reidentify given only + the database. + + The addfeatures function will now add features before a fit if + there are no reference database features. Previously features + could only be added after an initial fit using the reference + features and, so, required the reference database to contain + features for reidentification. This new feature is useful if + one wants to uses a dispersion function from one type of + calibration but wants to add features for a different kind of + calibration. + SAPERTURES + This task has been modified to allow use of image header + keywords as done in the APEXTRACT package. + SARITH + Previously both w1 and w2 had to be specified to select a range + to be used. Now if only one is specified the second endpoint + defaults to the first or last pixel. + + The noise band in multispec data is only copied from the primary + spectrum and not modified. This is a kludge until the noise is + handled properly. + + Fixed a problem in SARITH and SCOPY where a segmentation error + occurred when a wavelength range was specified in the reverse sense + of the data and without rebinning. See buglog 323 for details. + (V2.10.4p2) + SBANDS + Fixed a problem in SBANDS that caused a segmentation violation when + the number of input bandpasses was greater than 10. See buglog 298 + for details. (V2.10.4p2) + SCOPY + Previously both w1 and w2 had to be specified to select a range + to copy. Now if only one is specified the second endpoint + defaults to the first or last pixel. + SPECPLOT + The scale and offset parameters may now be a value, a filename, + or and image header keyword. + + The 'f' key was added to toggle between world and logical pixel + coordinates. + SPLOT + The profile fitting and deblending was expanded to include + lorentzian and voigt profiles. A new parameter controls the + number of Monte-Carlo samples used in the error estimates. + RSPECTEXT + The task now automatically senses the presence of a header. + +APEXTRACT: + APALL, APSUM, APNOISE, APNORMALIZE, APSCATTER, APTRACE, + APRECENTER, APRESIZE, APMASK, APFIND, APFLATTEN + The "apertures" parameter can be used to select apertures for + resizing, recentering, tracing, and extraction. This parameter + name was previously used for selecting apertures in the + recentering algorithm. The new parameter name for this is now + "aprecenter". + APALL, APSUM + The "nsubaps" parameter now allows onedspec and echelle output + formats. The echelle format is appropriate for treating each + subaperture as a full echelle extraction. + APALL + The aperture ID table information may now be contained in the + image header under the keywords SLFIBnnn. + APSUM + The dispersion axis parameter was moved to purely a package + parameter. + + As a final step when computing a weighted/cleaned spectrum the + total fluxes from the weighted spectrum and the simple + unweighted spectrum (excluding any deviant and saturated + pixels) are computed and a "bias" factor of the ratio of the + two fluxes is multiplied into the weighted spectrum and the + sigma estimate. This makes the total fluxes the same. In this + version the bias factor is recorded in the logfile if one is + kept. Also a check is made for unusual bias factors. If the + two fluxes disagree by more than a factor of two a warning is + given on the standard output and the logfile with the individual + total fluxes as well as the bias factor. If the bias factor is + negative a warning is also given and no bias factor is applied. + In the previous version a negative (inverted) spectrum would + result. + +RV: + RVIDLINES, RVREIDLINES + These tasks now work in the units of the input spectra. + FXCOR + The input spectra are converted to Angstroms for the + crosscorrelation and analysis. Thus the velocities will + be correctly computed regardless of the units of the + input spectra. + +DAOPHOT: + DAOFIND + A major bug in the DAOFIND task centering code that affects the + computed x and y positions was fixed. Users should refer to bug + log entry number 332 for details. (V2.10.4p2) + + A new roundness statistic was added to the DAOFIND output to + bring the task into conformance with standalone DAOPHOT II. The new + statistic is sensitive to and tries to eliminate detected objects + which are significantly elongated in directions other than 0, 90, + 180, and 270 degrees. The original roundness statistic is stored in + the ground column, the new one in the sround column. The same + default roundness limits apply to both statistics. (V2.10.4p2) + + DAOPARS + Added a new parameter "mergerad" to the DAOPARS parameter set. + Mergerad permits the user to control the merging process. If + mergerad is INDEF (the default setting) the default merging radius + is used. If mergerad is 0 object merging is turned off altogether. + Otherwise the user can set the merging radius to a specific value. + Mergerad is used by the nstar and allstar tasks, but their default + behavior is unchanged. (V2.10.4p2) + + Changed the name of the "critovlap" parameter to "critsnratio" to + avoid confusion with the the meaning of the parameter especially + with regard the mergerad parameter. The behavior of the parameter is + unchanged. (V2.10.4p2) + + +7. Parameter file changes + +The parameter file changes below are for modifications between V2.10.4 +and V2.11. For a list of parameter file changes between V2.10.3 and +V2.10.4 see the file iraf/v210/params.v2104.Z in the IRAF FTP archives. + +In the tables below each parameter change is identified with one of the +following codes followed by task_name.parameter_name and the +description of the change. + + n = new parameter + c = changed/modified parameter + d = deleted parameter + +TV: + n display.nsample: replaces nsample_lines + d display.nsample_lines: replaced by nsample + n display.bpmask: specify a bad pixel mask + n display.bpdisplay: specify display mode for bad pixel mask + n display.bpcolors: specify overlay colors for bad pixel mask + n display.overlay: specify an overlay mask + n display.ocolors: specify overlay colors for overlay mask + n display.zmask: specify a sample mask for the zscale calculation + c imedit.xorder: now allows a value of zero for median background + c imedit.yorder: now allows a value of zero for median background + n rimexam.fittype: specify a profile type to fit - default is now moffat + n rimexam.iterations: specify number of iterations to adjust fitting radius + n rimexam.beta: specify beta value for moffat fitting + c rimexam.buffer: default value changed from 1 to 5 + c rimexam.width: default value changed from 2 to 5 + c rimexam.magzero: default value changed from 30 to 25 + n wcslab.overplot: specify overplotting + +DATAIO: + n wfits.fextn: extension to append to output disk FITS filename - default is + fits + n wfits.extensions: write all images to a single FITS file ? - default is no + n wfits.global_hdr: prepend a global header to the FITS extensions - default + is yes + +IMAGES: + n fmedian.zloreject: good data minimum + n fmedian.zhireject: good data maximum + n fmedian.verbose: verbose option + n fmode.zloreject: good data minimum + n fmode.zhireject: good data maximum + n fmode.verbose: verbose option + n median.zloreject: good data minimum + n median.zhireject: good data maximum + n median.verbose: verbose option + n mode.zloreject: good data minimum + n mode.zhireject: good data maximum + n mode.verbose: verbose option + n geomap.transforms: list of record names + n geomap.results: results summary file + n geomap.fitgeometry: fitting geometry + d geomap.output: renamed to database + c geomap.reject: changed from 0.0 to INDEF + n [g]register.verbose: verbose option + d [g]register.transform: renamed to transfo + n geotran.verbose: verbose option + d geotran.transform: renamed to transforms + c imcombine.offsets: now allows specifying "wcs" to compute offsets from WCS + d imalign.images: renamed to input + c imalign.reference: went from hidden to auto + c imalign.coords: reversed places with reference + d imcentroid.images: renamed to input + c imcentroid.reference: went from hidden to auto + c imcentroid.coords: reversed places with reference + n imheader.imlist: default image names + +PLOT: + n graph.ltypes: specify the line types + n graph.colors: specify the colors + +PROTO: + n fixpix.masks: new version specifies bad pixel masks + n fixpix.linterp: specify mask values for line interpolation + n fixpix.cinterp: specify mask values for column interpolation + n fixpix.pixels: list pixels that are modified + d fixpix.badpixels: new version does not use bad pixel region description + c fields.lines: default value changed from "1-9999" to "1-" + +ARTDATA: + n mk1dspec.profile: define the profile type + n mk1dspec.gfwhm: replaces sigma for gaussian profile width + n mk1dspec.lfwhm: width for lorentzian profile + c artdata.randbuf: default value changed from 1000 to 0. + c mkpattern.ndim: allows a value of 0 for a dataless header. + c mkpattern.pixtype: allows ushort. + c gallist.ar: default value changed to 0.3. + d mk1dspec.sigma: replaced by gfwhm + +ASTUTIL: + n rvcorrect.keywpars: added to define keywords used + n asthedit.prompt: used for new calculator option + n asthedit.update: update the header + n asthedit.oldstyle: to allow backward compatibility + +APEXTRACT, IMRED spectral packages: + n apnoise.apertures: select apertures to be used + n apfit.apertures: select apertures to be used + n apedit.apertures: select apertures to be used + n apfind.apertures: select apertures to be used + n apnormalize.apertures: select apertures to be used + n apscatter.apertures: select apertures to be used + n apsum.apertures: select apertures to be used + n aptrace.apertures: select apertures to be used + n apresize.apertures: select apertures to be used + n apmask.apertures: select apertures to be used + n apflatten.apertures: select apertures to be used + n aprecenter.apertures: select apertures to be used + n aprecenter.aprecenter: was what was previously the apertures parameter + n apall.apertures: select apertures to be used + n apall.aprecenter: was what was previously the apertures parameter + +ARGUS, HYDRA, SPECRED: + n doargus.crval: for automatic line identifications + n doargus.crdelt: for automatic line identifications + n doargus.skyalign: night sky alignment option + n dohydra.crval: for automatic line identifications + n dohydra.crdelt: for automatic line identifications + n dohydra.skyalign: night sky alignment option + n dofibers.crval: for automatic line identifications + n dofibers.crdelt: for automatic line identifications + n dofibers.skyalign: night sky alignment option + n do3fiber.crval: for automatic line identifications + n do3fiber.crdelt: for automatic line identifications + +ARGUS, HYDRA, KPNOCOUDE, KPNOSLIT, SPECRED: + c params.match: default value changed to -3 (3 pixels instead of Angstroms) + c sparams.match: default value changed to to -3 (3 pixels instead of Angs) + +ONEDSPEC, IMRED spectral packages: + d fitprofs.sigma: replaced by gfwhm + d fitprofs.function: replaced by profile + d fitprofs.fitsigmas: replaced by fitgfwhm + d rspectext.header: removed since the task now senses the header information + +ONEDSPEC, LONGSLIT, IMRED spectral packages: + n identify.units: specify the desired units for the dispersion function + n identify.crval: for automatic line identifications + n identify.crdelt: for automatic line identifications + n identify.aidpars: parameter set for automatic line identifications + c identify.match: default value changed to -3 (3 pixels instead of Angstroms) + c identify.threshold: default value changed from 10 to 0. + c reidentify.match: default value changed to -3 (3 pixels instead of Angs) + c reidentify.threshold: default value changed from 10 to 0. + n reidentify.crval: for automatic line identifications + n reidentify.crdelt: for automatic line identifications + n reidentify.aidpars: parameter set for automatic line identifications + n reidentify.search: specify a search radius for the automatic line + identification algorithm + n ecidentify.units: specify the desired units for the dispersion function + n fitprofs.profile: define the profile type + n fitprofs.gfwhm: replaces sigma for gaussian profile width + n fitprofs.lfwhm: width for lorentzian profile + n fitprofs.fitgfwhm: replaces fitsigmas + n fitprofs.fitlfwhm: select whether to fit lorentzian profile widths + n fitprofs.nerrsample: allows control of the error calculation accuracy + n splot.nerrsample: allows control of the error calculation accuracy + +CCDRED: + c ccdproc.fixfile: this now specifies a bad pixel mask + c combine.offsets: now allows specifying "wcs" to compute from WCS + +RV: + n rvcorrect.par: Added the KEYWPARS pset declaration + +DAOPHOT: + c daopars.critsnratio: critical S/N ratio for group membership - changed + the name only from critovlap (V2.10.4p2) + n daopars.mergerad: critical object merging radius in scale units + (V2.10.4p2) + IRAF (Jul92) V2.10 Revisions Summary IRAF (Jul92) + + + IRAF Version 2.10 Revisions Summary + July 1992 + + + + +1. Introduction + + This document summarizes the changes made to IRAF in version 2.10. +V2.10 is a major release of IRAF, meaning that there were significant +changes to both the system and applications software, and the release +will eventually be made available on all supported platforms. + +By IRAF version 2.10 we refer only to the core IRAF system and NOAO +packages. Numerous external or "layered" packages are also available +for IRAF, for example the NSO package (solar astronomy), the ICE +package (data acquisition), the STSDAS package from STScI (HST data +reduction and analysis), the TABLES package from STScI (tabular data), +the XRAY package from SAO (X-ray data analysis), and so on. These +packages are layered upon the IRAF core system, and once installed, are +indistinguishable from the rest of IRAF. Layered packages are +developed and maintained separately from the core IRAF release and +follow independent release schedules, hence we will not discuss them +further here. Contact the IRAF project or any of the outside groups +supporting IRAF layered packages for additional information on what is +available. + +This document is intended only as an overview of what is new in version +2.10 IRAF. More detailed documentation will be found in the systems and +applications notes files (files sysnotes.v210.Z and pkgnotes.v210.Z in +the network archive), in the online help pages, and in any reference +papers or user's manuals distributed with the software. The IRAF +Newsletter is a good source of information for new IRAF software. + +This revisions summary is organized as follows: + + 1. Introduction + + 2. IRAF System Revisions + + 3. IRAF and NOAO Package Revisions + 3.1. Changes to the System Packages + 3.2. Changes to the NOAO Packages + + 4. Programming Environment Revisions + 4.1. Compatibility Issues + 4.2. Portability Issues + 4.3. Software Tools + 4.4. Programming Interface Changes + + 5. Getting Copies of this Revisions Summary + +The reader is assumed to already be familiar with the basic concepts and +operation of the IRAF system. In particular, familiarity with V2.9 +IRAF is assumed. + + + +2. IRAF System Revisions + + +2.1 Starting up V2.10 IRAF + + Before attempting to start V2.10 IRAF each user should run the +mkiraf command in their IRAF login directory. This will create a new +login.cl file and uparm (user parameter) directory. mkiraf should be +allowed to delete any existing parameter files, as there have been many +changes to task parameter sets in the new version of IRAF. + + +2.1.1 LOGIN.CL changes + + The login.cl file is read by the CL during startup to perform some +runtime initialization and to customize IRAF for each user. A standard +login.cl file is created and initialized by the mkiraf command when the +user's IRAF login directory is configured. For V2.10 IRAF the login.cl +file has undergone the following changes. + + o The IRAF version number is now checked automatically whenever + you login, and a warning message will be printed if your + login.cl file is out of date. If you see this message it means + that important changes have been made to the login.cl file and + you need to rerun mkiraf to update this file. + + o Most of core IRAF system packages are now loaded automatically + at login time by the login.cl file. If you use a personal + loginuser.cl file and you previously loaded any core system + packages in this file, you should edit the file and remove + those entries. + + o A "quiet" login option is now provided. If a file named + .hushiraf exists in the login directory when you start up the + CL, printing of the usual login messages will be disabled (the + only output seen will be the "cl>" prompt). + + o On UNIX/IRAF systems the login script now looks at the host + system environment variable TERM and checks for the common + terminal types "sun" and "xterm", configuring the IRAF stty + accordingly if either terminal type is seen (note that the + default number of lines set for an xterm terminal window may + need to be modified). The logic used to do this is not + foolproof however, and is provided only as an example + illustrating how to make use of the host system terminal + definitions. You may need to customize this portion of the + script, or override it in your loginuser.cl file. + + o The CL hidden parameter showtype is now set to "yes" by default. + This will cause a character to be printed after the name of + each package or named pset in CL package menus to allow these + objects to be easily distinguished from ordinary tasks. + Packages are marked with a trailing period (".") and psets with + an ampersand ("@"). This feature can be disabled with a + "showtype=no" statement. + + o The V2.10 login script contains a call to a new internal + (non-user) IRAF task mtclean. Be sure to leave this alone, it + is required for the correct operation of the new magtape i/o + system. + + The USER package defined in the template login.cl has been + extensively revised, adding many new tasks. These are mainly used + to make common UNIX commands available from within the IRAF + environment. Type "?user" in the CL to see what is available, e.g.: + + cl> ?user + adb cp fc lpq mv rlogin spell top + bc csh find ls nbugs rsh sps touch + buglog date finger mail nm rtar strings vi + cal df ftp make od ruptime su w + cat diff generic man ps rusers sync wc + cls du grep mkpkg pwd rwho telnet wtar + comm emacs less mon rcp sh tip xc + + + Note that since the USER package is defined in the user's login + file it is easily customized to add new tasks. Refer to the + existing package for examples illustrating how to do this. + + +2.1.2 Compatibility Issues + + Version 2.10 IRAF requires the new login.cl file; if the CL does not +start up correctly, it may be because the user has not done a mkiraf, +or because they have some construct in their loginuser.cl file which is +incompatible with V2.10 IRAF. The V2.10 login file is usable with V2.9 +IRAF, however this is not recommended. + +There have been many task parameter changes between V2.9 and V2.10. If +"parameter not found" messages are seen, most likely the user has an old +uparm directory, or has been switching back and forth between IRAF +versions. An unlearn or mkiraf should fix the problem. + +The V2.10 IRAF networking system is not fully compatible with earlier +versions of IRAF. This can cause problems when, e.g., a newly installed +V2.10 system is used to communicate with an older version of IRAF on +another system. The best solution is to update to V2.10 on all +systems, but if this is not convenient it is possible to configure the +networking system to avoid the problems. See the discussion of the new +networking system given below. + +Accessing a remote magtape device via IRAF networking will not work +between V2.10 and older versions of IRAF (the remote procedure calls +have changed). To remotely access magtape devices you will need to +install V2.10 IRAF on both the client and server nodes. + +In most respects installing V2.10 IRAF will be very similar to +installing earlier versions of IRAF. The main difference is the +tapecap file required to use the new magtape system. The old +dev$devices file is no longer used. See the discussion of the new +magtape system given below for more details. + +Due to name changes in certain low level system routines (made to avoid +name clashes when linking with host level libraries) the V2.10 +libraries are incompatible with older versions of IRAF. Any IRAF +programs or external packages relinked under V2.10 will have to be +fully recompiled or the linker will complain about unresolved +externals. Note that so long as the old program is not relinked there +should be no problem, even if the program uses the IRAF shared image, +since the V2.9 shared image is included in V2.10 (this applies to +Sun/IRAF systems only). + +Starting with V2.10, many IRAF applications now fully support +generalized world coordinates (WCS). While in principle this should +not pose any compatibility problems, the image headers do contain more +information in V2.10 than previously, and there can be problems if, for +example, an input image contains an illegal WCS. Previous versions of +IRAF would ignore this but in V2.10 such an image could result in an +error or warning message. If WCS related problems are encountered it +is probably best to contact the IRAF group for help. + + + +2.2 CL Enhancements + + +2.2.1 Formatted scans and prints, scan from a pipe + + New in the V2.10 CL (command language) are formatted scan and print +routines, and the ability to scan from a pipe or other form of +redirected input. These new facilities will prove most useful in CL +scripts. + +The old unformatted scan and print routines are the following. These +are still available and are the simplest routines to use where they are +adequate. + + scan (arglist) # scan standard input + fscan (list, arglist) # scan a list + print (expr, exprlist) # print to standard output + fprint (param, exprlist) # print to a string buffer + + +For example, + + list = "filename" + while (fscan (list, x, y) != EOF) + print ("x=", x, "y=", y) + + +In the above, arglist is a comma delimited list of output arguments +(parameter or parameter field names) and exprlist is a comma delimited +list of expressions to be printed. list is the name of a +list-structured parameter to be scanned, and param is the name of a +parameter, the value field of which is to receive the output string. +The unformatted scan routines will automatically convert output data +values to match the types of the output arguments. + +The new formatted routines are as follows. These take an extra format +argument which tells how to parse the input string in the case of the +scanf routines, or how to format the output in the case of the printf +routines. + + scanf (format, arglist) # formatted scan from stdin + fscanf (list, format, arglist) # formatted scan from a list + printf (format, exprlist) # formatted print to standard output + + +Currently there is no fprintf routine. For the printf routine the +format argument is similar to that for the SPP/VOS printf (which is +similar to the C printf). The format argument for the scanf routines +is the same as the VOS LIBC scanf, which is patterned after the C scanf +(in fact the UNIX manual page for scanf can be used as a guide to the +CL scanf with only minor deviations). + +The following examples illustrate the new routines. + + cl> printf ("%d foo %7.3f\n", 5, 12.123) | scanf ("%d foo %g", i, x) + cl> printf ("new values are i=%d, x=%g\n", i, x) + new values are i=5, x=12.123 + +or, + + while (fscanf (list, " %*d size=%d name=%s", i, s1) != EOF) + printf ("size=%05o, name=`%s'\n", i, s1) + + +Note in the first example the use of scanf to scan from a pipe. There +are actually two different versions of scan and scanf in V2.10 IRAF, an +intrinsic function version and a procedure version. When called as an +intrinsic function, a scan routine returns as its function value the +number of operands successfully scanned, or EOF. When called as a +procedure, the function value of a scan routine is discarded. + +Here is another example illustrating scan from a pipe, in this case +using an unformatted scan since the hselect output is in a simple +tabular format (hselect prints selected fields of the image header). + + cl> hselect dev$pix naxis,naxis1,naxis2 yes | scan (i, j, k) + cl> printf ("naxis=%d, axlen=[%d,%d]\n", i, j, k) + naxis=2, axlen=[512,512] + + +When using the formatted scan routines, care must be taken to ensure +that the data types implied by the format argument match the actual data +types of the output parameters. The scanf routines are implemented +using an internal call to the C (LIBC) scanf, with the output parameter +value fields referenced directly via a pointer. If the data type is +incorrect the output value may be meaningless. + + +2.2.2 Unlearning package parameters + + The unlearn task now works for package parameters as well as task +parameters. In a command such as "unlearn pkgname" the package +parameters for the named package will be unlearned, as well as the +parameters for all the tasks in the package. This works whether or not +the package is loaded. + + +2.2.3 Loading packages at login time + + A bug has been fixed which affected packages with package +parameters loaded at login time. It is now permissible to load any +package at login time regardless of whether it has package parameters +(V2.9 users will recognize this bug as one which prevented loading +CCDRED in the login script). + + +2.2.4 Environment variables + + The environment variables imtype, cmbuflen, and min_lenuserarea are +now defined at login time. Previously, explicit values for these +variables were not defined, and the system would use the builtin +internal defaults. Explicit definitions were added so that the user +can query the current value, e.g. + + cl> show cmbuflen + 128000 + +A show or set with no arguments will print the full environment list. +New values for these and other common environment variables may be set +in the user login.cl file. + + + +2.3 System Management Related Changes + + +2.3.1 Install script + + The UNIX/IRAF install script underwent minor changes to make it more +robust. Problems are still possible if the IRAF root pathname is set to +different values in the various system dependent files modified by the +script. The system as shipped from NOAO has the same initial root +pathname set in all such files, but problems can occur if the files are +manually edited during or after installation. To avoid problems always +use the install script to make system changes such as installing at a +different root directory. + + +2.3.2 Caching of termcap entries + + User caching of termcap or graphcap entries with the old mkttydata +task is no longer recommended. The most common entries (e.g. sun, +xterm, vt100) are already cached. Modern workstations are so fast that +there is no longer much point in caching termcap entries; it is +sufficient to merely place local additions near the top of the file. +Most programs that repeatedly access the terminal cache the entries +internally during execution. Custom caching of termcap or graphcap +device entries requires that the system be relinked, and the risk +inherent in relinking the system (hence giving up the prebuilt, +pretested binaries) is not worth the small performance gain achieved. + + +2.3.3 Sorting of UNIX directories + + The UNIX-based versions of IRAF now sort UNIX directories whenever a +directory is accessed to expand a file or image template. This will +fix the problem sometimes seen in earlier versions of IRAF, in which an +image template could appear to be expanded in a seemingly random +fashion. + + +2.3.4 UMASK support + + The UNIX-based versions of IRAF now support the host level umask +file creation mask correctly. If files or directories created by V2.10 +IRAF do not have the desired permissions, it is because you do not have +umask set correctly at the UNIX level (most people set umask to 022). + + + +2.4 Networking Enhancements + + +2.4.1 New networking driver + + The UNIX/IRAF networking driver has been completely rewritten for +version 2.10 IRAF, with the goals of eliminating redundant password +prompts, improving efficiency, and enhancing system security. For the +most part the changes will be transparent to the user. Once the IRAF +system manager has configured the dev$hosts file for the local site the +networking system should function automatically; in the default +configuration a password prompt should be seen only when connecting to +a server for which rhosts ("trusted" hosts) permission is not granted. + +The following information is provided mainly for IRAF system managers. +In normal use the user does not need to understand how the networking +system functions. + + +2.4.1.1 How it works + + The IRAF networking system is an RPC (remote procedure call) +mechanism for the IRAF kernel; all kernel procedures may execute either +locally or remotely, and the client and server nodes do not even need +to run the same operating system. IRAF applications may be +distributed, and may access resources which reside anywhere on the +network. IRAF networking is layered upon standard low level networking +protocols such as TCP/IP and DECNET. + +The IRAF networking system defines one or more connection protocols +which are used by a client to connect to the IRAF kernel server on a +remote machine. The old networking driver supported only one +connection protocol, the rexec protocol, which requires a login name +and password. The new driver adds support for an rsh based protocol. +This is the default connection protocol for V2.10 IRAF; automatic +fallback to the rexec protocol is provided in the event that the rsh +connect fails. The rsh connection protocol bootstraps off the +suid-root rsh command found in most BSD derived UNIX systems (most +System V systems provide the equivalent command remsh). + +The connection protocol is used to start the in.irafksd IRAF networking +daemon on the remote server node. This daemon executes with the same +uid and permissions as the account which initiated the connection, and +there is one such daemon per user per server node. Once the daemon has +been started via the rsh or rexec connection protocol, new client +connections are made very quickly, by merely forking the daemon to +create the IRAF kernel server process, and setting up a direct socket +connection between the IRAF client process and the server. The daemon +process runs indefinitely, shutting down if idle for longer than a +certain interval (the current default is one hour). When connecting to +the daemon a client must supply an authentication key to gain access to +the daemon. If authentication fails the daemon shuts down and it is +necessary to reestablish the connection. + + +2.4.1.2 The .irafhosts file + + The new networking driver retains the old irafhosts file, used to +store information telling how to connect to various IRAF hosts (the +irafhosts file is the file .irafhosts in the user's login directory). +The networking system will automatically create this file for the user +if the file is not found; if an old-style file is found, it will be +edited by the system to make it compatible with the new networking +system. While it is no longer necessary for the irafhosts file to +contain password information to avoid password prompts, the file is +used to store the user authentication key, hence the file should be +read protected. The networking system will automatically read protect +the file if it is not already protected. + +To avoid authentication failures when clients on different nodes +attempt to connect to the same server, the same authentication code +should be used on all server nodes. Unfortunately there is no way that +the networking system can do this automatically (without going to some +much more complicated authentication scheme, such as a key server), so +users who make heavy use of the networking system should install a copy +of their irafhosts file in their login directory on all server nodes. +If this is not done the networking system will still work, but will be +less efficient than it could be, when simultaneously accessing the same +server from IRAF sessions running on multiple client nodes. + +The truly paranoid may not be happy with even the unique user +authentication code used in the current networking system. If this is +the case the port parameter (see below) may be set to zero to force rsh +to be used for every connection (in effect the in.irafksd daemon has to +be restarted for every connection). This imposes an overhead of as +much as several seconds on every server connect. Alternatively, KSAUTH +can be defined in the user environment at login time, setting the value +string to some random integer value selected at login time. If defined +in the user environment, KSAUTH will override the value of auth given in +the irafhosts file. This approach would at least allow efficient +connects for a single login process tree. + +The irafhosts file consists of two sections. The first section defines +several networking parameters: port, auth, hiport, and timeout. The +second section is a list of server nodes, with login and password +information describing how to connect to each node. + + port = default + auth = 1234567890 + hiport = default + timeout = default + + ursa : ? + * : + + +The example above illustrates a typical irafhosts file. Typically a +unique authentication code is allocated automatically by the system +when the file is first created, and the other parameters retain their +default values as shown (i.e., the string "default"). In the example +the host list consists of an entry for the node "ursa", and an entry +for everything else. The format of a host entry is "host-name : +login-name password". If login-name is the reserved string "" +the user name on the client node is used for login authentication on +the remote node. Setting the password to "" as well causes the +rsh connect protocol to be used; anything else causes the rexec +protocol to be used. If the rexec protocol is used the password field +may be set to the actual password or to the string "?", in which case +the system will prompt for the password whenever a connection attempt +is made. The "*" entry should always be the last entry in the list, +since it matches all nodes. The default host list contains only the +"*" entry. + +Additional information on the irafhosts file is provided in the +comments in the file dev$irafhosts, and in the system notes file. + + +2.4.1.3 Compatibility + + By default the new networking system will try to use the rsh +protocol to connect to the server node. If the server is running an +older version of IRAF the connection attempt will hang and eventually +time out. If this occurs the networking system will fall back on the +rexec protocol and issue a password prompt, but by then the user will +probably have interrupted the connect. The best way to avoid this +problem is to update the server node to V2.10, but if this is not +possible, an explicit entry for the node can be made in the irafhosts +file, setting the password field so that the rexec protocol will be +used. + +An older, e.g. V2.9 client connecting to a V2.10 server should not be a +problem. In this case the V2.10 server will see an attempt to connect +with the rexec protocol, which should be processed as in the past. + +Aside from the problem of making a connection the pre-V2.10 and V2.10 +networking systems are compatible, except for the magtape i/o calls. +Since the magtape driver calling sequences were changed in V2.10, remote +magtape access between V2.10 and older systems is not supported. + + +2.4.2 The hosts file + + The file dev$hosts is used to interface new host machines to the +IRAF networking system. This file defines, for each host, the primary +host name, any aliases, and the command to be executed remotely to start +up the IRAF kernel server on a remote node. + +The format and role of the hosts file is unchanged in V2.10. Two +changes were made which affect the use of this file. + +o A user can now have a private copy of the hosts file. To enable + this feature, the variable irafhnt (IRAF host name table) should be + defined in the user's IRAF or host level environment, with the + string value giving the file pathname of the user's private host + name table file. + +o The maximum number of entries in the host name table has been + increased from 64 to 128. In the current implementation these + entries are statically buffered, so it is necessary to keep the + maximum number of entries to a reasonable value. + + The hosts file must be configured to enable IRAF networking. IRAF + networking is disabled if there is no entry for the local host in + this file. The netstatus command may be used to examine the state + of the host name table after it has been loaded by the networking + system. + + There is another file dev$uhosts which often confuses people. This + file is not used by UNIX/IRAF and can be ignored; it is there for + VMS/IRAF and other IRAF implementations which do not provide the + equivalent of the UNIX system routine gethostbyname. On host + machines which implement name server facilities IRAF will use the + name server, allowing any machine on the internet to be accessed + via IRAF networking, so long as there is an entry in the system + wide or user IRAF hosts file. + + + +2.5 Magtape System Enhancements + + The magtape subsystem underwent a major revision in V2.10. The VOS +level MTIO interface was extensively revised, and the host-level IRAF +magtape driver ZFIOMT is completely new. A new device configuration +facility called tapecap was introduced. Together with the new +"programmable" magtape driver, this makes it possible to interface +almost any removable media mass storage device to the magtape +subsystem. The DATAIO applications, in particular the FITS programs, +underwent minor, but important revisions. + +A full specification of the new magtape subsystem, particularly the +tapecap facility, is beyond the scope of this document. Our intention +here is merely to introduce the new facilities. A reference paper is +planned, time permitting, which will fully document the new magtape +system and tapecap. + + +2.5.1 Basic usage + + In most respects basic usage of the magtape system is unchanged from +previous releases. Many new capabilities have been added, but these are +upwards compatible with earlier releases. + + +2.5.1.1 Logical device names + + Magtape devices are still referred to in IRAF applications much as +they have been in the past. Whether or not the logical device names +are the same before and after the V2.10 upgrade depends upon how the +IRAF system manager configures the tapecap file. The new magtape +system is much more flexible than previously regarding device names, +but to avoid user confusion it is recommended that the old names be +supported as aliases regardless of whatever the full device name may be. + +As in earlier versions of IRAF, a simple magtape reference might be + + cl> mtexamine mta + +where "mta" is the device name. To examine only file 3 on the tape one +might enter + + cl> mtex mta[3] + +If the device is on the remote node "ursa" the command would be + + cl> mtex ursa!mta[3] + +If the device is a 9 track tape supporting multiple densities we might +specify the density explicitly, e.g. + + cl> mtex mta1600[3] + +Device names can be more complex. For example, + + cl> mtex mtwd + +might refer to a WangDAT drive, and + + cl> mtex mtwdc + +to the same drive, but with data compression enabled. + +Devices can have multiple names, possibly with slightly different +behavior or characteristics. Device names such as "mta" are usually +only host specific aliases for the lower level, host independent device +names. The names "mta" and "mtb" might be aliases for the actual device +names "mthp0" and "mtxt1". This can be useful in networked systems +where IRAF and the tapecap file reside on a server node, but the user +is running IRAF on their workstation with a local tape drive attached. +In this case there may be no entry for the local drive in the installed +tapecap file, but the user can still access the local drive using the +lower level, host independent device entry (it is also possible to have +a private tapecap file as we shall see later). + +To see what logical devices are known to the magtape system you can +enter the following command (the task gdevices was intended for +graphics devices but can be pressed into service to list a tapecap file +as well). Just because a device is listed does not mean that the +physical device actually exists on a particular host system. + + cl> gdev devices='^mt' graphcap=dev$tapecap + +In IRAF V2.10 it is possible to include tapecap parameters in the device +specification to do clever things, as in the following example. + + cl> mtex "mta[:so=lepus:se:nb]" + +This is discussed further below in the section describing the tapecap +facility. + + +2.5.1.2 Device allocation + + Device allocation operates much the same in V2.10 as in earlier +versions of IRAF. The main change is that it is no longer necessary to +allocate a device in order to be able to access it. It is strongly +recommended however that you always allocate a device before accessing +it in IRAF. If the device is not allocated anyone can access the +drive, e.g., changing the tape position, and this can cause data to be +lost or improperly read back. The only reason to access the drive +without allocating it is if there is some problem with device +allocation on your system. + +A device is allocated with the allocate command, e.g. + + cl> alloc mta + +A device is deallocated with deallocate. If the tape has already been +unmounted use the rewind=no option to avoid accessing the drive. By +default the tape will be rewound when it is deallocated. Deallocating +and reallocating a drive initializes the magtape system, i.e., all +cached knowledge of the status of the drive is discarded. + + +2.5.1.3 Device status + + The device status can be examined at any time that the magtape +device is idle (not being actively accessed by an IRAF task) using the +devstatus task. + + cl> devs mtc + # Magtape unit mtc status Thu 12:54:02 04-Jun-92 user v14 + file = 4 + record = 1 + nfiles = 0 + tapeused = 405 + pflags = 0 + + +Of particular interest are the tapeused and nfiles fields. nfiles +refers to the total number of files on the tape (if a file is appended +to the tape it will be file nfiles+1). If nfiles is given as zero that +means that the magtape system does not yet know how many files are on +the tape (it has not seen the end of tape). + +tapeused reports the amount of tape used in units of kilobytes. This +is intended to refer to the amount of tape used up to and including the +end of tape (EOT). However, the magtape system only knows about data +that it has seen, i.e. physically read or written, so whether or not +tapeused is accurate depends upon how you have accessed the tape. + +For example, if you started out with a fresh tape and appended a number +of files the number should be accurate. If you just completed a full +scan of the tape with mtexamine the number should be accurate, since +all the data was read. If you just put on a new tape and did a scan of +the FITS headers with "rfits make-", the number may or may not be +accurate, depending upon the device and how file skipping forward was +done. In most cases only the header area of each file will have been +read and tapeused will not reflect the full contents of the tape. If +however, "rfits make-" is done immediately after writing to a new tape, +the number will be accurate, since all the data was written before the +tape was rescanned to print the FITS headers. + +Be advised that by default an explicit rewind will clear the nfiles and +tapeused fields, since by default rewind initializes the magtape +system. See the discussion of rewind below. + +In summary tapeused can be useful for monitoring how much space is left +on a tape, but you have to know what you are doing. When writing to a +new tape the number will be accurate so long as you avoid doing an +explicit rewind. A simple procedure which will always work when +mounting a non-empty tape and appending files to it, is to do an +mtexamine of the tape and then append the new files. This can be time +consuming for large tapes but does provide a safe and +device-independent method for getting the maximum amount of data on a +tape. + + +2.5.1.4 File positioning + + File positioning when accessing magtape files in IRAF is +straightforward in the sense that you can simply specify the file +number to read an existing file, or "append" (as in wfits new-) to +append a file to an existing tape. Most tasks accept range lists to +access existing files, e.g. + + cl> mtexamine mta file="3,5,9-11" + +It is even possible to position a tape to a specific record within a +file. Opening a tape with file zero (as in "mta[0]") disables file +positioning, allowing the tape to be positioned with host level +utilities to workaround media problems. + +There can be problems with this simple scheme however, with modern tape +devices such as DAT and Exabyte which have capacities in the gigabyte +range and which may be used to store thousands of files. It is beyond +the scope of a revisions summary to go into this in detail here, but a +simple example will help illustrate the problem. + +Assume we have a tape mounted on device "mtwd" containing 900 files. We +want to append image "pix" as a FITS file. The obvious thing to do is +enter the following command. + + cl> wfits pix mtwd new- + +This will certainly work. The only problem is that if the tape is +freshly mounted the magtape system will not know how many files there +are on the tape, and it will have to skip forward one file at a time to +count the files and determine where EOT is. In the worst case of a +tape containing several thousand files this could literally take hours. + +If we know apriori the number of files on the tape, e.g., 900 in our +example, the following command would be much faster (something like +10-40 seconds on most DAT drives, assuming a decent host level driver). + + cl> wfits pix mtwd[901] + +Of course, if there were actually 930 files on the tape, the last 30 +files would be overwritten. + +There is a useful trick which works in some cases if we don't care +exactly how many files are on the tape (whether this works depends upon +the specific device and the host driver). Assume that we know there +are several hundred files on the tape, but less than 1000. We enter +the following command to append a file to the tape. + + cl> wfits pix mtwd[1000] + +If this works, after the operation the magtape system will think there +are 1000 files on the tape. A subsequent "wfits new-" would be very +fast regardless of the tape position, since so long as the magtape +system knows where the end of tape is relative to the current position, +it can get there very fast. + +If the trick doesn't work for your particular device or driver you will +probably get a positioning error when attempting to position to a +nonexistent file beyond the EOT. + +More automated techniques for rapid positioning with very high capacity +tapes are still a matter for study. One promising technique would be to +formalize the above approach by supporting EOT-relative positioning. A +tape catalog based approach is also possible. The best approach may +simply be to not write so many small files on large tapes, by grouping +images or other data system files into a single large tape file (as +with UNIX tar). None of these approaches are implemented in V2.10. + + +2.5.1.5 Rewind + + In IRAF a magtape device is rewound with the rewind command, as in +the following example. + + cl> rewind mta + +By default this will not only rewind the tape but also initialize the +magtape system, in the sense that all cached information regarding the +named device is erased (e.g., nfiles and tapeused in the cached device +status). This is necessary when changing tapes without deallocating the +drive; always do an explicit rewind (or deallocate) of the device before +removing a tape or mounting a new one. Having rewind initialize things +is also useful if error recovery should fail following an interrupt or +program abort. + +In some cases it may be useful to be able to do a rewind without +erasing the cached device status. This is done by specifying the init- +option on the command line. + + +2.5.2 New magtape driver + + The IRAF magtape driver is new for V2.10. The chief feature of the +new driver is that it is programmable, via the tapecap device entry, +making it possible to interface new devices or host drivers without +having to make any binary code changes to IRAF. All one has to do is +add a device entry in the tapecap file. + + +2.5.2.1 Software structure + + The IRAF magtape system has enough layers that it may be confusing +exactly what the magtape driver is and what role it plays. A brief +review of the software structure may help clarify things. + +Starting at the top we have applications, such as the DATAIO and MTLOCAL +tasks, which can access magtape files. These use the IRAF/VOS +interfaces FIO (file i/o) and MTIO (magtape i/o) to do i/o to tape +devices. For the most part i/o is done with FIO and is device +independent, but a call to the magtape system is required to open a +magtape device. The tapecap file is read by the GTY interface, which +is called by MTIO. MTIO passes the tapecap device entry as a string to +ZFIOMT, the IRAF magtape device driver, when a tape file is opened. +All magtape positioning and i/o is done by ZFIOMT driver under the +control of the MTIO interface. Device allocation is done prior to +accessing the device by the CL and is handled by the allocation +routines in the ETC interface, with kernel support (this is largely +independent of the magtape system). + +All of the code listed above is part of the portable IRAF system (i.e., +is OS independent and shared by all host versions of IRAF) until we get +to the ZFIOMT driver. This is in the IRAF kernel and is host system +dependent. At present the only version of ZFIOMT is the UNIX version; +other versions, e.g., for VMS will follow as IRAF is updated to V2.10 +on these systems. The UNIX version of ZFIOMT uses only generic UNIX +ioctls and should compile on most UNIX systems without change. All of +the system and device dependence has been concentrated in the tapecap +file. The ioctls used to communicate with a UNIX tape device are +fairly standard, but the semantics are often poorly defined and are +certainly not standardized. + +Beneath the IRAF driver are the host level magtape device drivers. A +given host system may have more than one of these, typically one for +each class of magtape device. Some systems, notably Sun with their ST +(SCSI tape) driver, try to control more than one type of device with a +single host driver. The host driver may come with the OS or may be +supplied by a third party vendor. + +Beneath the host driver is the actual tape device. Often these days +this is a SCSI tape device such as a DAT or Exabyte. These devices are +intelligent peripherals; control of the physical tape hardware resides +in the tape unit. There is a small computer in each tape drive which +communicates with the host computer via the SCSI interface, passing +commands and data back and forth. The drive will buffer 256K to 512K +of data passed in bursts over the SCSI bus, and then copied to or from +the physical media at a much slower rate. These drives emulate +variable size records by blocking and deblocking within the drive unit, +and writing fixed size blocks to the media. Features such as error +correction and data compression are also handled within the drive. + +Although we usually speak of tape devices, the "magtape" device does not +have to be a tape device at all. The IRAF magtape system can also make +use of, e.g., a floppy disk, or anything that looks like a raw disk +partition. The problem with the latter devices is that they usually +don't support files and file positioning, hence can only be used to +store one "file". + + +2.5.2.2 Driver features + + A detailed description of the magtape driver is beyond the scope of +this document. Briefly, the driver supports two main classes of +devices, variable record size devices and fixed block devices. All +file positioning is handled by the driver, and while the driver has the +device open it is responsible for keeping track of the device position +(the saved device position is passed in at open time and saved by the +high level code at close time). A couple of dozen tapecap parameters +are defined which describe the characteristics of each device, such as +whether it supports variable records, the maximum record size, whether +it can backspace, and so on. A socket or file based status logging +feature is provided which allows detailed monitoring of the tape status +during execution (see below). + +In the simplest case the new magtape system, coupled with the UNIX +version of the magtape driver, will emulate simple UNIX commands such +as tar and mt insofar as the requests made to the host system and +magtape device are concerned. That is, if one writes a series of files +the only system requests made for each file will be open, write, and +close. When reading a series of files in sequence the only requests +made will be open, read, and close. Providing no file positioning is +attempted it is possible to get by with no file positioning requests +other than rewind. The driver provides extensive facilities for file +positioning, using tapecap parameters to work around any shortcomings +of the host system or device, but in case of trouble it is possible to +operate with only open, close, read, and write requests, which should +work for any device (unless it is truly broken). + + +2.5.3 Tapecap + + The tapecap file, or magtape device capabilities file, defines the +magtape devices known to the system and how to access these devices. +While large portions of this file depend only upon the host operating +system and device type and hence are fairly site independent, it will +typically be necessary to customize the tapecap file to configure the +IRAF magtape system for a site. In normal use the tapecap file is +invisible to the user, but users with special problems may wish to +learn more about tapecap to gain more control over the behavior of the +magtape system. + + +2.5.3.1 Using tapecap + + The standard tapecap file is the file dev$tapecap. A system +environment variable tapecap is defined which by default points to this +file. + +Users can customize or manipulate tapecap entries in either of two ways. +The user can have their own private copy of the tapecap file (much as is +currently done with the termcap and graphcap files), by resetting the +value of the tapecap environment variable to point to their local copy +of the file. For example, + + cl> reset tapecap = home$tapecap + +This may be necessary to customize a device entry, or add support for a +local device not supported by the system wide tapecap file. + +It is also possible to modify a tapecap device entry "on the fly", by +overriding the values of specific tapecap parameters on the command line +when the device is accessed. For example, + + cl> mtex "mta[:so=/dev/tty]" + +would override the default value of the tapecap parameter "so" for +device mta (in this case enabling status output logging and directing +this output to the user terminal). + +Specifying tapecap parameters on the command line is useful for +experimentation but rapidly becomes tiresome if many commands are +entered. In this case it becomes simpler to redefine tapecap to include +the desired tapecap parameter overrides. + + cl> reset tapecap = ":so=/dev/tty" + +As we see, the tapecap environment variable can be used to either +specify the tapecap file name, or globally override specific tapecap +parameters (all device entries are affected). The full form of the +value string for tapecap is + + cl> reset tapecap = [tapecap-file] [`:' capabilities-list] + +Any number of colon-delimited tapecap capabilities or parameters may be +given. + +It is beyond the scope of this document to detail all the tapecap +parameters here. A reference paper for the magtape system is planned. +For the present, there is a summary of the tapecap parameters in the +ZFIOMT driver source file, os$zfiomt.c. For examples of actual usage +refer to the tapecap file in the distributed system. + + +2.5.3.2 Configuring tapecap + + The tapecap file uses the standard "termcap" file format, +originally developed for BSD UNIX and adopted long ago for IRAF. Any +UNIX system will probably have a manual page defining the termcap file +format, if not this can be obtained from the IRAF group. + +The distributed tapecap file is divided into three sections: the host +machine specific device aliases (names like "mta" etc.), the site +logical devices, and the generic device entries. To customize the +tapecap file for a site you modify the first and second sections. To +configure the tapecap file for a particular host machine you uncomment +the entries for that host in the first section of the file. Sites +which don't have a large network of hosts may prefer to combine the +first two sections to simplify things. Site specific changes should +never be made to the bottom, or generic, part of the tapecap file, as +you will want to update this portion of the file when new versions of +IRAF are released. + +Don't be intimidated by the apparent complexity of some of the tapecap +device entries. In most cases the generic device entry will already +exist for the device you need to interface, and all you need to do is +add a site entry which references the generic entry. In some cases the +generic entry itself may be sufficient (for example, in the distributed +SunOS version of tapecap, logical device "mtxb0" would provide access +to Exabyte unit 0 interfaced with the Sun ST driver, "mtxb1" would be +the same but unit 1, "mthp0" the HP 9 track tape on unit 0, and so on). + +For example to interface Exabyte unit 2, using the Sun ST driver, as +local device "mta", the following entry would suffice. + + mta| :tc=mtst2-exb: + +If the generic device entry provided doesn't quite work and minor +modifications are needed, these should be made to the local entry and +not the standard generic entry. This is easily done with termcap +parameter redefinitions. For example, in SunOS 4.1.2 (but not earlier +versions of SunOS) there is a bug in the Sun ST driver which +necessitates rewinding the tape after a tape scan is made to position +to EOT (!). The capabilities ":se:nb" can be added to the tapecap +entry for the device to workaround this bug, as in the following +example. + + mta| :se:nb:tc=mtst2-exb: + +The parameters mean that the device spaces past EOT in a read (se) and +cannot backspace (nb). Neither of these things is actually true, but +the effect is that the tape is rewound and spaced forward to get back +to the desired file, working around the host level driver bug. Access +will be less efficient than it should be, but the interface will work +properly and the user does not have to be concerned with the problem. + +As a final example, suppose we need to write a new tapecap entry from +scratch because there is no generic entry for the device in the +distributed tapecap file. To simplify things we assume that no special +tapecap parameters are needed, i.e., that the standard UNIX defaults +builtin to the driver will work for the device. We are upgrading from +an old version of IRAF so we already have an old dev$devices file to +work with. For the purposes of our example we use an old HP 88780 1/2 +tape drive entry, but pretend that the device is something which is not +already supported. + +The old devices file entry was as follows. + + mta nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 + mta.6250 nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 + +The minimal tapecap entry required to duplicate this is the following. + + mta|mta6250|HP 88780 1/2 inch tape drive:\ + :al=nrst4 nrst12 nrst20 nrst28 rst4 rst12 rst20 rst28:\ + :dv=nrst20:lk=st4:tc=9tk-6250: + +Here, the "al" parameter lists the device files to be allocated, the +"dv" parameter is the device file to be used for i/o at the desired +density (6250bpi in this case), and "lk" is the root file name to be +used for the ".lok", or device status file. The "tc=" picks up the +standard parameters for a 9 track 1/2 inch tape drive operating at 6250 +bpi. Two device aliases are defined, "mta" and "mta6250". + + +2.5.3.3 Supported devices + + The IRAF magtape system itself should support almost any magtape +device if properly configured. What devices are actually supported at +a site depends upon the tapecap file, and in particular upon the host +system (different host systems have different tapecap files). + + Device Driver + + QIC-11 cartridge tape Sun st + QIC-24 cartridge tape Sun st + QIC-150 cartridge tape Sun st + Pertec compatible 1/2 inch drives Xylogics + HP 88780 1/2 inch drive Sun st + WangDAT 1300, 2000 ApUNIX + HP DAT ApUNIX + Exabyte 8200, 8500 ApUNIX, Sun st, Ciprico + DC2000 cartridge tape A/UX tc + FDHD floppy disk A/UX fd + +As an example, the tapecap file distributed in the V2.10.0 release of +Sun/IRAF supported the devices listed in the table above. New devices +are constantly being added. As V2.10 IRAF propagates to the various +platforms on which IRAF is supported, similar tapecap files will be +configured for those systems. + + +2.5.4 Status output + + The new magtape driver has a facility known as status output +logging which can be used to monitor interactively lengthy tape jobs +while i/o is in progress. The status output facility can also be +useful for debugging magtape problems. + +In its simplest form, the status output may be directed to a file, +e.g., an actual text file, or a terminal device. Status output is +enabled by setting the "so" option in tapecap. For example, + + cl> mtex "mta[:so=/tmp/mta.out]" + +would enable status output logging and direct the output text to the +file /tmp/mta.out. Likewise, + + cl> mtex "mta[:so=/dev/ttyp7]" + +would enable status output and direct the output to a pseudoterminal, +e.g., an xterm window. When this form of status output logging is used +one sees the raw, driver level status messages, as in the following +example. + + cl> mtex "mta[:so=/dev/tty]" + open device tc2n\n + devtype = Apple Tape 40SC + tapetype = DC2000 + tapesize = 38500 + density = na + blksize = 8192 + acmode = read + file = -1 + record = -1 + nfiles = 0 + tapeused = 0 + device tc2n opened on descriptor 4\n + rewinding... + done\n + position to file 1\n + file = 1 + record = 1 + reading...\n + recsize = 65536 + record = 9 + tapeused = 64 + (etc.) + + +The UNIX version of the new magtape driver also has an option to direct +status output to a TCP/IP socket, which can be anywhere on the network. +For this option to be useful one must have a program which will listen +on the designated socket, accept the connection when the magtape driver +tries to open a connection, and then read and process the status +messages (which are still text, exactly as in the example above). + +Status output to a socket is enabled by giving a host name instead of a +file name in the "so" directive: + + cl> mtex "mta[3:so=lepus]" + +to examine file 3, directing status messages to a socket on node +"lepus". + +An X11 client application called xtapemon has been developed to listen +on a socket, read messages from the tape driver, and provide a real-time +display of the status of the tape device. While not included in the +V2.10 IRAF distribution, this utility will be available later in 1992 +as part of the X11 support package currently under development. + + +2.5.5 Error recovery + + Considerable effort went into "bullet proofing" the new magtape +system to make it recover gracefully from ctrl/c interrupts or other +program aborts. In practice it can be very difficult to reliably catch +and recover from interrupts in a multiprocess, distributed system such +as IRAF. No doubt there are still conditions under which an interrupt +will leave the magtape system in a bad state, but in most circumstances +the system should now be able to successfully recover gracefully from +an interrupt. + +If it is necessary to interrupt a tape operation, it is important to +understand that the host system will not deliver the interrupt signal +to the IRAF process until any pending i/o operation or other driver +request completes. For example, in a read operation the interrupt will +not be acted upon until the read operation completes, or in a tape +positioning operation such as a rewind or file skip forward, the +interrupt will not be acted upon until the tape gets to the requested +position. For a device such as a disk you rarely notice the delay to +complete a driver request, but for a magtape device these operations +will take anywhere from a few seconds to a few tens of seconds to +complete. Type ctrl/c once, and wait until the operation completes and +the system responds. + +If a magtape operation is interrupted, the IRAF error recovery code will +mark the tape position as undefined (devstatus will report a file +number of -1). This will automatically cause a rewind and space forward +the next time the tape is accessed. The rewind is necessary to return +the tape to a known position. + + +2.5.6 Device optimization + + In addition to making it possible to characterize the behavior of a +magtape device to permit the device to be accessed reliably, the +tapecap facility is used to optimize i/o to the device. The parameter +"fb" may be specified for a device to define the "optimum" FITS +blocking factor for the device. Unless the user explicitly specifies +the blocking factor, this is the value that the V2.10 wfits task will +use when writing FITS files to a tape. Note that for cartridge devices +a FITS blocking factor of 22 is used for some devices; at first this +may seem non-standard FITS, but it is perfectly legal, since for a +fixed block size device the FITS blocking factor serves only to +determine how the program buffers the data (for a fixed block device +you get exactly the same tape regardless of the logical blocking +factor). For non-FITS device access the magtape system defines an +optimum record size which is used to do things like buffer data for +cartridge tape devices to allow streaming. + +Some devices, i.e., some DAT and Exabyte devices, are slow to switch +between read and skip mode, and for files smaller than a certain size, +when skipping forward to the next file, it will be faster to read the +remainder of the file than to close the file and do a file skip +forward. The "fe" parameter is provided for such devices, to define +the "file equivalent" in kilobytes of file data, which can be read in +the time that it takes to complete a short file positioning operation +and resume reading. Use of this device parameter in a tape scanning +application such as rfits can make a factor of 5-10 difference in the +time required to execute a tape scan of a tape containing many small +files. + +On most cartridge tape devices backspacing, if permitted at all, is very +slow. On such devices it may be best to set the "nf" parameter to tell +the driver to rewind and space forward when backspacing to a file. + + +2.5.7 MTIO interface changes + + A number of new routines were added to the MTIO (magtape i/o) +programming interface. These are documented in the summary of +programming environment revisions given below. Existing magtape +applications may benefit from being modified to make use of these new +routines. + + + +2.6 Graphics and Imaging Subsystem Enhancements + + +2.6.1 New graphics applications + + New tasks for histogram plotting, radial profile plotting, and +producing lists of the available graphics devices have been added to +the PLOT package. All of the tasks in this package were revised to add +support for world coordinates. A related task for drawing world +coordinate grid overlays on images or plots was added to the IMAGES.TV +package. See the appropriate sections of IRAF and NOAO package +revisions below for further information on these changes. + + +2.6.2 Graphics system changes + + +2.6.2.1 Encapsulated postscript SGI kernel + + A new encapsulated postscript SGI kernel has been added. Graphics +output may be directed to any of the logical graphics devices eps, epsl, +epshalf, etc. to render a plot in encapsulated postscript, e.g., for +inclusion as a figure in a document. For example, + + cl> prow dev$pix 101 dev=eps; gflush + +will leave a ".eps" file containing the plot in the current directory. +The command "gdev dev=eps" will produce a list of the available EPS +logical graphics devices. + + +2.6.2.2 Graphics output to the default printer + + Graphics output (SGI postscript) can now be directed to the UNIX +default printer device by directing output to any of the logical +devices "lpr", "lp", or "lw". + + cl> prow dev$pix 101 dev=lpr + + +Output will be sent to the default device for the UNIX lpr command (set +by defining "PRINTER" in your UNIX environment). This makes it +possible to make immediate use the distributed IRAF graphcap without +having to add entries for specific local devices (although you may +still wish to do so). + + +2.6.2.3 Tick spacing algorithm improved + + The algorithm used to draw the minor ticks on IRAF plots was +replaced by an improved algorithm contributed by the STScI STSDAS group +(Jonathan Eisenhamer in particular). This was derived from similar +code in Mongo. + + +2.6.2.4 Graphics metacode buffer + + The default maximum size of the graphics metacode buffer in the CL, +used to buffer graphics output for cursor mode interaction, was +increased from 64K to 128K graphics metacode words (256Kb). The +cmbuflen environment variable may be used to change this value. + + +2.6.2.5 IMTOOL changes + + The imtool display server (SunView) was enhanced to add additional +builtin color tables, support for user color tables, and setup panel +control over the screen capture facilities. A version supporting +encapsulated postscript output is in testing. This will be the final +version of the SunView based version of imtool (the new display servers +are all X window system based). + + +2.6.2.6 IMTOOLRC changes + + The imtoolrc file, used by display servers such as imtool and +saoimage to define the available image frame buffer configurations, has +been relocated to the DEV directory to make it easier for local site +managers to customize. The IRAF install script now uses a link to +point to this file, rather than copying it to /usr/local/lib. The +maximum number of frame buffer configurations was increased from 64 to +128. + + +2.6.2.7 X11 support + + The released version of V2.10 does not contain any changes insofar +as X11 support is concerned. Since our X11 support code is host level +stuff, with minimal ties to IRAF per se, it is being developed +independently of the V2.10 release and will be distributed and +installed as a separate product. + + + +2.7 Image Structures + + +2.7.1 Image I/O (IMIO) + + The image i/o interface (IMIO) is that part of the IRAF system +responsible for imagefile access and management. The changes to IMIO +for V2.10 included the following. + + +2.7.1.1 Null images + + Null images are now supported for image output, much like the null +files long supported by the file i/o system. For example, + + cl> imcopy pix dev$null + +would copy the image "pix" to the null image. This exercises the +software but produces no actual output image. Unlike null files, null +images do not work for input since images have some minimal required +structure, whereas files can be zero length. + + +2.7.1.2 Preallocating pixel file storage + + In the UNIX versions of IRAF, when a new image is created storage +is not physically allocated for the output image until the data is +written. This is because most UNIX systems do not provide any means to +preallocate file system storage. The UNIX/IRAF file creation primitive +zfaloc, used by IMIO to create pixel files, now provides an option +which can be used to force storage to be physically allocated at file +creation time. This feature is enabled by defining the environment +variable ZFALOC in the UNIX environment. For example, + + % setenv ZFALOC + +can be entered before starting IRAF to cause space for all pixel files +to be preallocated as images are created. If it is not desired to +preallocate all image storage (there is a significant runtime overhead +associated with preallocating large images) then a value string can be +given to specify which types of images to preallocate storage for. For +example, + + % setenv ZFALOC /scr5 + +would preallocate only those pixel files stored on the /scr5 disk, and + + % setenv ZFALOC "/scr5,zero" + +would preallocate only images on /scr5, or images containing the +substring "zero" in the image name. In general, the string value of +ZFALOC may be the null string, which matches all images, or a list of +simple pattern substrings identifying the images to be matched. + +In most cases the default behavior of the system, which is to not +physically allocate storage until the data is written, is preferable +since it is more efficient. The preallocation option is provided for +users who, for example might have an application which spends a lot of +time computing an image, and they want to ensure that the disk space +will be available to finish writing out the image. + + +2.7.1.3 Image templates now sorted + + As mentioned earlier in the System Management section, UNIX/IRAF now +sorts UNIX directories. One result of this is that the sections of +image templates which are expanded via pattern matching against a +directory will now be sorted, or at least logically ordered (the final +output list will not necessarily be fully sorted if string substitution +is being performed - this is the reason the output list itself is not +sorted). + + +2.7.1.4 The dev$pix test image + + Minor changes were made to clean up the image header of the +standard test image dev$pix. A second test image dev$wpix has been +added. This is the same image, but with a different header containing a +test world coordinate system (actually the image is just a second image +header pointing to the dev$pix pixel file, now shared by both images). + + +2.7.2 Image kernels (IKI) + + The IMIO image kernels are the data format specific part of the +IRAF image i/o subsystem. Each kernel supports a different image +format. Existing disk image formats range from the conventional image +raster formats (OIF and STF) to the photon image format (QPF and QPOE) +and the pixel mask image format (PLF and PMIO/PLIO). There also exist +special image kernels which allow IMIO to be used to access non-disk +storage devices such as image display frame buffers. + + +2.7.2.1 New PLF image kernel + + A new image kernel, the PLF image kernel, has been added which +allows IRAF PMIO/PLIO pixel masks to be stored as images. This kernel +first appeared as a patch to version 2.9 IRAF but was actually +developed within V2.10. + +Pixel mask images may be created, deleted, read, written, etc. like +other IRAF images, but the image is stored in a special compressed +format designed specially for image masks. An image mask is an +N-dimensional raster-like object wherein typically there are regions of +constant value but arbitrary shape. Masks are used by applications +involving image decomposition. The image is decomposed into regions of +different types, the type of region being very dependent upon the type +of image analysis being performed. A special type of mask image is the +bad pixel mask, used to flag the bad pixels in an image. Other +applications use masks for data quality, to identify the region or +regions to be used for analysis, and so on. + +A PMIO image mask is a special case of a PLIO pixel list. Masks can +exist and be accessed independently of the image i/o system, but the +PLF image kernel allows a mask to be stored and accessed as an IRAF +image. Any IRAF application which operates upon images can operated +upon a mask image. For example, the imcalc (image calculator) program +in the SAO XRAY package can be used to combine images and masks, or +compute new masks by evaluating an algebraic expression over an image. + +Mask images have the reserved image extension ".pl". Some of the +features of mask images are illustrated by the following example. + + cl> imcopy dev$pix pix.pl + dev$pix -> pix.pl + cl> imstat dev$pix,pix.pl + # IMAGE NPIX MEAN STDDEV MIN MAX + dev$pix 262144 108.3 131.3 -1. 19936. + pix.pl 262144 108.3 131.3 6. 19936. + +This is a sort of worst case test of the mask encoding algorithm, since +our test image is not a mask but a noisy image (and hence not very +compressible). Note that masks must be positive valued, hence the MIN +value is different for the two images. Storing dev$pix as a mask does +not result in any significant compression, but for a real mask very +high compression factors are possible. The compression algorithm used +in PLIO is simple and fast, combining 2D run length encoding and a +differencing technique in a data structure allowing random access of +multidimensional masks (masks are not limited to one or two dimensions). + +For further information on pixel lists and pixel masks, see the document +plio$PLIO.hlp in the online system. This is also available as +plio.txt.Z in the IRAF network archive. + + +2.7.2.2 OIF image kernel changes + + The OIF image kernel is the kernel for the old IRAF image format - +this is still the default IRAF image format. Revisions to the OIF +kernel for V2.10 included the following items. + +o A valid image header is now written even if an application which + writes to a new image is aborted. Previously, the pixel file would + be written but the image header would be zero length until the + image was closed. If an image creation task aborts the image will + likely be incomplete in some way, e.g., part of the pixels may not + have been written to, or the header may be missing application + specific keywords. By valid image header we mean that the header + will be valid to IMIO, allowing the image to be accessed to try to + recover the data, or to delete the image. + +o The image header file of a new image is now written to and closed + at image create time, then reopened at image close time to update + the header. This frees one file descriptor, an important + consideration for applications which for some reason need to write + to dozens of output images simultaneously. + +o The OIF image kernel uses file protection to prevent inadvertent + deletion of the image header file. In UNIX/IRAF systems file + delete protection is simulated by creating a ".." prefixed hard + link to the file. This could cause problems with images if the + user deleted the image header file outside of IRAF, leaving the + ".." prefixed link to the file behind. A subsequent image create + operation with the same image name would fail due to the existence + of the hidden ".." prefixed file. It is unlikely that such a file + (with a ".." prefix and a ".imh" extension) could ever be anything + but an old IRAF image header file, so the system will now silently + replace such files when creating a new image. + + A couple of related system changes were made which, while not + implemented in the OIF kernel, do involve the OIF or ".imh" image + format. The default template login.cl now defines the environment + variable imtype and sets it to "imh". The environment variable + min_lenuserarea is also defined now at login time, with a default + value of 20000, allowing image headers with up to about 250 header + parameters. + + +2.7.2.3 STF image kernel changes + + The STF image kernel is the kernel for the online HST (Hubble Space +Telescope) image format. This format allows multiple images to be +grouped together in a single "group format" image. There is a common +image header stored in a FITS-like format, as well as a small fixed +format binary header associated with each image in the group. + +o A check was added for a group index out of range. This yields a + more meaningful error message about no such group, rather than + having IMIO complain about a reference out of bounds on the pixel + file. + +o Support was added for non-group STF images (GROUPS=F in the header). + At first glance a non-group group format image might seem a little + silly, but it turns out that a non-group STF image with a zero + length group parameter block is very close to "FITS on disk", since + the header is FITS-like and the image matrix is simple. It is + still not true FITS since the header and pixels are stored in + separate files and the pixels are not encoded in a machine + independent form, but on UNIX hosts which are IEEE standard and not + byte swapped, it comes close enough to be useful for communicating + with external applications in some cases. + + A true FITS image kernel is planned for IRAF. This will probably + appear in one of the V2.10 patches, sometime during 1992. + + +2.7.2.4 QPF image kernel changes + + The QPF image kernel is the interface between the QPOE (position +ordered event file) interface and IMIO, allowing QPOE event files to be +accessed as images by general IRAF applications. Photon "images" are +unique in that the image raster is generated at runtime as the image is +accessed, optionally passing the photon list through event attribute +and spatial filters, and sampling the photons to produce a raster +image. For example, + + cl> imcopy "snr[time=@snr.tf,bl=4]" snr.imh + +would filter the event list stored in the file "snr.qp" by the time +filter stored in file "snr.tf", sample the image space blocking by a +factor of 4, and store the resultant image raster in the OIF image file +"snr.imh". + + cl> display "snr[time=@snr.tf,bl=4]" 1 + +would display the same image raster without creating an intermediate +disk image. + +The changes to the QPF interface for V2.10 included the following. + +o A bug was fixed which would prevent very long filter expressions + from being correctly recorded in the IMIO image header. The + current version of IMIO stores applications header parameters in + FITS format, hence multiple FITS cards are required to store long + filter expressions. The bug would cause only one such card to be + output. + +o A new facility was added which allows general expressions to be + computed for the input event list and stored as keywords in the + output image header. The header of the input QPOE file can contain + one or more parameters named defattr1, defattr2, and so on. If + present, the string value of each such parameter should be a + statement such as + + exptime = integral time:d + + which will cause a keyword named "exptime" to be added to the + output image header, the scalar value of the keyword being the + value of the expression on the right. Currently, only the integral + function is provided. This computes the included area of a range + list field of the event attribute expression, such as a time + filter. In the example, "time" is the name of the event attribute + to be integrated, and the ":d" means use a range list of type + double for the computation. The data types currently supported are + integer, real and double. + + Other minor changes to QPF included improvements to the error + recovery, and other changes to support very large filters. + + +2.7.3 World coordinate system support (MWCS) + + MWCS is the IRAF world coordinate system package, one of the major +new system interfaces developed for the new image structures project. +A full description of the MWCS interface is given in the file +mwcs$MWCS.hlp in the online system, and in the file mwcs.txt.Z in the +IRAF network archive. + + +2.7.3.1 Applications support + + MWCS was first released in V2.9 IRAF and at the time the interface +was new and few applications were yet using it. In V2.10 IRAF most +(but not all) applications which deal with coordinates now use MWCS. +These include all of the system plotting tasks, and the spectral +reduction packages. Details of the MWCS support added to the system +and science applications in V2.10 are given in the IRAF and NOAO +package revisions section of this revisions summary. + + +2.7.3.2 New function drivers + + Function drivers for the arc, sin, and gls nonlinear sky +projections were added, as well as a special function driver for the +multispec image format. The latter allows general programs which don't +know anything about spectra to access and display spectra in world +coordinates, e.g., for plotting. + + +2.7.3.3 WCS attributes + + The maximum number of "attributes" per WCS was increased from 64 to +256, mainly to support the multispec function driver, which makes heavy +use of attributes. A limit on the size of a single attribute value +string was removed, allowing arbitrarily large attribute values to be +stored. + + +2.7.3.4 Axis mapping + + Axis mapping is now fully implemented. Axis mapping is used when, +for example, you extract a 2 dimensional section from a 3 dimensional +image and write the result to a new image. Axis mapping allows the 2 +dimensions of the new image to be mapped backed into the original 3 +dimensional WCS, making it possible to get the full physical +coordinates (which are 3 dimensional) for any point in the extracted +image. A new header keyword WAXMAPnn was added to store the axis map +in image headers. + + +2.7.3.5 MWCS save format + + The newer IRAF image formats such as QPOE are capable of storing +arbitrarily complex objects such as a MWCS in an image header keyword. +In the case of a stored MWCS object, the MWCS interface is responsible +for encoding the object in its external storage format, and restoring +it to a MWCS descriptor when the MWCS is accessed. The code which does +this was revised to add a new version number for the stored V2.10 MWCS, +to make it possible to differentiate between the MWCS save formats used +in V2.9 and V2.10 and allow recovery of MWCS objects from data files +written under V2.9. + + +2.7.3.6 Bug fixes + + Since MWCS is a new interface and V2.10 saw its first real use in +applications, a number of interface bugs were discovered and fixed. +Most of the bugs turned out to be in the part of MWCS which converts +between the internal MWCS WCS representation, and the FITS WCS +representation, used for those image formats that still use FITS-like +headers. Bug fixes included a problem with the treatment of CROTA2, a +problem with the FITS CD matrix, an axis mapping problem that caused +"dimension mismatch" errors, and a problem with support for the +old-style CDELT/CROTA which could result in a singular matrix during +WCS inversion when compiling a transformation. + + +2.7.4 Event files (QPOE) + + The QPOE interface is the interface responsible for creating and +accessing event files, the main data format produced by event counting +detectors. We summarize here the main enhancements to QPOE made during +the preparation of V2.10. Some of these features appeared earlier in +the patches made to V2.9 IRAF but these revisions have never been +formally documented so we summarize both the old and new revisions +here. See also the discussion of the QPF image kernel given earlier. + + +2.7.4.1 Blocking factors + + The builtin default blocking factor, when sampling the event list +to make an image raster, is one. This may be changed on a per-datafile +basis by defining the parameter defblock in the QPOE file header. + + +2.7.4.2 Parameter defaults + + Since parameters such as the blocking factor can be set at a number +of levels, a parameter defaulting scheme was defined to determine the +precedence of parameter overrides. The lowest level of precedence is +the builtin default. Next is any datafile specific value such as +defblock. A value such as blockfactor set in the QPDEFS file will +override the datafile default value if any. Specifying the parameter +value in a runtime filter expression or qpseti call is the highest +order of precedence and will override any other setting. + +Another way to think of this is the more recently the parameter was +set, the higher the precedence. The oldest value is the default +builtin to the code. Next is the datafile value, usually set when the +datafile was created. Next is the QPDEFS macro file, usually set by +the user or for a site. Last (highest precedence) is the value set by +the user when the data is accessed. + + +2.7.4.3 Referencing the current datafile in macros + + A special symbol $DFN is now recognized during macro expansion and +if present is replaced by the filename of the current QPOE file. This +allows macros to be written which automatically perform some operation +involving the datafile to which they applied, e.g., computing an +attribute list from aspect or data quality information stored in the +datafile header. + + +2.7.4.4 Bitmask expressions + + Bitmask expressions may now be negated, e.g., "%3B" is the mask 03 +octal, "!%3B" or "!(%3B)" is the complement of 03 octal. + + +2.7.4.5 Large time filters + + A number of changes and bug fixes were made to QPOE for V2.10 to +support large time filters. These are lists of "good time" intervals +used to filter the event list. These large time filters may contain +several hundred double precision time intervals spanning the exposure +period. Often a large time filter is combined with a complex spatial +filter (PLIO mask) to filter an event list consisting of from several +hundred thousand to several million events. QPOE can handle this +efficiently regardless of whether the data is temporarily or spatially +sorted and regardless of the complexity of the temporal or spatial +filters. + +A number of minor bugs were fixed caused by the large filter expressions +overflowing various buffers. The default sizes of the program and data +buffers used to compile filter expressions were increased to allow all +but very large filters to be compiled without having to change the +defaults. If the buffers overflow more space can be allocated by +setting the progbuflen and databuflen parameters in QPDEFS (these +buffers are not dynamically resized at runtime for efficiency reasons). +During testing with large time filters it was discovered that a routine +used to test floating point equality was being used inefficiently, and +compilation of large time filters was taking a surprisingly long time. +A change was made which reduced the time to compile large filters by a +factor of 10 to 15. + + +2.7.4.6 Default filters + + QPOE now fully supports default event attribute and spatial +filtering of data at runtime. The idea is that the full data set (all +events) is stored in the QPOE file, along with default event attribute +and spatial filters. When the data is accessed these filters are, by +default, automatically applied. Any user specified event attribute or +spatial filters are "added" to the builtin default filters to produce +the combined filter used when the event list is accessed. The point of +all this is to make it easy for the user to modify or replace the +default filters and "reprocess" the raw event list. In effect the raw +and processed event list are available in the same file. + +The default filter and mask, if any, are stored in the datafile header +parameters deffilt and defmask. If the datafile contains multiple +event lists a default filter or mask may be associated with each list +by adding a period and the name of the event list parameter, e.g., +"deffilt.foo" would be the default filter for the event list "foo". + +By default, if a default filter or mask exists for an event list it is +automatically applied when the event list is accessed. Use of the +default filter or mask can be disabled in QPDEFS with either of the +following statements: + + set nodeffilt + set nodefmask + +The default filter and mask can also be disabled in a filter expression +by adding a "!" before the expression, as in the following example. + + display "snr[!time=@times.lst,pha=(3,8:11)]" + +There are actually several variants on the "=" assignment operator used +in filter expressions such as that above. The operator "=" is +equivalent to "+=", meaning the expression term on the right adds to +any existing filter specified for the event attribute on the left. The +operator ":=" on the other hand, means replace any existing filter by +the new filter expression. + + +2.7.4.7 Alternate coordinate systems + + The event structure used to represent each event in an event list +may contain multiple coordinate systems if desired, for example, +detector and sky coordinates. One coordinate system should be defined +as the default when the event list is created, and if the event list is +to be indexed it must be sorted using the coordinate system specified +as the default. Any coordinate system may be used when the data is +accessed however; this can result in quite different views of the same +data set. For example, + + cl> display snr.qp 1 + +would display the QPOE file "snr.qp" in display frame 1, using all +defaults for the event list, blocking factor, filter, mask, and so on. +The default event coordinate system would probably be sky coordinates. +To display the same event list in detector coordinates, one could enter +the following command. + + cl> display "snr.qp[key=(dx,dy)]" 1 + +This assumes that the event structure fields "dx" and "dy" are defined +somewhere, either in the datafile header or in QPDEFS (otherwise the +actual field datatype-offset codes must be given). + +Currently if the QPOE datafile has a WCS associated with it this WCS can +only refer to one coordinate system, normally the default event +coordinate system. Additional WCS can be stored in the QPOE file, +either in the stored MWCS object or as separate MWCS objects, but at +present there is no mechanism for selecting which will be used (if the +parameter qpwcs exists in the QPOE file header, this is assumed to be a +stored MWCS object and this is the WCS which will be used). + + + +2.8 System Specific Changes + + +2.8.1 Sun/IRAF + + Since V2.10 has only just been completed and at this stage has only +been released on Sun platforms, there are few system specific revisions +to report. For SunOS there were several system specific revisions +worth noting here. + +o The HSI binaries for the sparc architecture are now statically + linked. This makes them considerably larger, but avoids problems + with SunOS complaining about shared library version mismatches + (note that we refer here to to Sun shared libraries - this is not a + problem with the IRAF shared library facility since we control the + version numbers). + +o The HSI binaries for the Motorola architectures (f68881 and ffpa) + are not statically linked since they cannot be without running into + linker problems warning about f68881_used etc. To avoid or at least + minimize warnings about SunOS shared library versions the system was + linked on 4.1.1 instead of 4.1.2. SunOS 4.0.3 versions of the + Motorola HSI binaries are also available upon request. + +o The system as distributed was linked with the name server library, + -lresolv. This means that if the local host is configured to use + the name server, IRAF will be able to access almost any host on the + Internet without an entry in the /etc/hosts file on the local host. + + Additional system specific changes will be reported in the + documentation distributed with each release, as V2.10 is moved to + the various platforms for which IRAF is supported. + + + +3. IRAF and NOAO package revisions + + The revisions for the various packages in the IRAF core system and +in the NOAO packages are summarized below. There have been many changes +with this release. Users are encouraged to refer to the help pages, +user's guides provided with some packages, revisions notes, and more +recent issues of IRAF Newsletters for more details. Comprehensive +notes on systems and applications modifications are in the files +pkgnotes.v210.Z and sysnotes.v210.Z in the directory iraf/v210 in the +network archive. This summary can be read online by typing news. +Revisions notes for the various packages can also be accessed online as +in the following example. + + cl> phelp dataio.revisions opt=sys + + +One of the system changes that affects many tasks in the IMAGES, PLOT, +and LISTS packages as well as most tasks in the spectroscopic packages +in NOAO is the full implementation of the world coordinate system +(WCS), introduced in V2.9 but not fully integrated into the IRAF and +NOAO tasks at that time. There are currently three classes of +coordinate systems: the logical system is in pixel units of the current +image section; the physical system is in pixel units of the parent +image (for a WCS associated with a raster image); the world system can +be any system defined by the application, e.g. RA and DEC or +wavelength. In general, this should be transparent to the user since +most defaults have been chosen carefully so that tasks perform the same +as in V2.9. The NOAO spectroscopic tasks also use the WCS extensively, +but again, this should be transparent to the user, although it can +cause some problems with backward compatibility. Users will notice the +biggest difference in the image headers with additional keywords added +by the interface. Two tasks in the PROTO package may help the +interested user understand more about the WCS - see wcsedit and +wcsreset. Technical notes on the WCS are available in a paper in the +iraf$sys/mwcs directory. Type the following to read more about the +MWCS interface. + + cl> phelp mwcs$MWCS.hlp fi+ + + + +3.1 Changes to the IRAF system packages + + +3.1.1 DATAIO package modifications + +o The output defaults for wfits have been modified. If the pixel + type on disk is real or double precision the output will be IEEE + format (FITS bitpix = -32 or -64, respectively). If the pixel type + on disk is short integer then the output will be integer format + (bitpix = 16) as before. These defaults can of course be changed + by modifying the parameters for wfits. + +o The wfits "blocking_factor" parameter can accept values up to and + including 10 for variable blocked devices, i.e. 1/2" tape drives, + Exabytes, and DATs. If the "blocking_factor" parameter is set to + "0", as in the default, the value is read from the "fb" parameter + in the tapecap file (usually 10 for variable blocked devices). For + fixed blocked devices such as cartridge tape drives the default + value for the "fb" parameter in the tapecap file is 22 (used to + determine a buffer size) and the block size of the device is given + by the "bs" parameter. + +o All tasks were modified to accept tapecap parameters as part of the + magtape file name syntax. Tapecap parameters can now be appended + to the magtape file name to add to or override values in the + tapecap file. For example, "mta6250[:se]" is a valid magtape file + name (the "" are important when tapecap parameters are specified at + execution time). See the file os$zfiomt.c for more details about + the tapecap parameters. + +o The rfits task has been modified to permit a short last record, + i.e. a last record that has not been padded out to 2880 bytes. No + warning messages are issued. + +o rfits was modified to map ASCII control characters in the header to + blanks. + +o The sequence number appended to disk file names by rfits and wfits + was modified to 4 digits, i.e. 0001 - 9999. + + +3.1.2 IMAGES package modifications + +o WCS (world coordinate system) support was added to all tasks in the + IMAGES package that could introduce a coordinate transformation. + Some tasks had already been modified for the V2.9 release. These + tasks (blkavg, blkrep, geotran, imcopy, imlintran, imshift, + imslice, imstack, imtranspose, magnify, register, rotate, and + shiftlines), upon execution, will update the image header to + reflect any transformation. + +o The listpixels task was modified to list the pixel coordinates in + either logical, physical, or world coordinates. A format parameter + was added to the task for formatting the output pixel coordinates + taking precedence over the WCS in the image header, if used. + +o A new imcombine task was added to the package. This new task + supports image masks and offsets, and has an assortment of new + combining algorithms. See the help pages for complete details on + this powerful new task. + +o The imhistogram task has a new "binwidth" parameter for setting + histogram resolution in intensity units. + +o The default values for the parameters "xscale" and "yscale" in the + register and geotran tasks were changed from INDEF to 1.0, to + preserve the scale of the reference image. + + +3.1.3 IMAGES.TV package reorganization and modifications + +o The TV package has been reorganized. The IIS dependent tasks have + been moved into a subpackage, TV.IIS. The imedit, imexamine, and + tvmark tasks that were previously in PROTO have been moved to TV. + +o A new task wcslab developed at STScI by Jonathan Eisenhamer was + added to the package. wcslab overlays a labeled world coordinate + grid on an image using WCS information stored in the header of the + image or in parameters of the task. + +o imexamine was modified to use WCS information in axis labels and + coordinate readback, if selected by the user. Two new parameters, + "xformat" and "yformat", were added to specify the format of the + WCS if it is not present in the header of the image. + +o A new option was added to imexamine to allow for fitting 1D + gaussians to lines or columns. + +o tvmark had two cursor key changes. The "d" keystroke command that + marked an object with a dot was changed to "."; the "u" keystroke + command that deleted a point was changed to "d". + + +3.1.4 LISTS package modifications + +o Two new parameters were added to the rimcursor task, "wxformat" and + "wyformat". These parameters allow the user to specify the + coordinate formats for the output of the task and override any + values stored in the WCS in the image header. + + +3.1.5 OBSOLETE package added + +o An new package called OBSOLETE was added. Tasks will be moved to + this package as they are replaced by newer tasks in the system. + OBSOLETE tasks will then be removed at the time of the next release. + +o mkhistogram, imtitle, radplt, and the old imcombine task have been + moved to the OBSOLETE package. Users should become familiar with + phistogram, hedit, pradprof, and the new imcombine and use them + instead since mkhistogram, imtitle, radplt, and oimcombine will be + retired with the next release. + + +3.1.6 PLOT package modifications + +o A new task called phistogram was added to the PLOT package. This + task takes input from an image or from a list and allows full + control over the plotting parameters. This task replaces the + obsolete.mkhistogram task. + +o A new task pradprof was added to the PLOT package. This task plots + or lists the radial profile of a stellar object. This task + replaces the obsolete.radplt task. + +o A new task called gdevices was added to the package. gdevices + prints available information known about a particular class of + device. The default parameters are set up to print a list of the + available stdimage devices in the standard graphcap file. + +o WCS support was added to the tasks graph, pcol(s), and prow(s). A + new parameter called "wcs" was added to define the coordinate + system to be used on the axis, either logical, physical or world. + Two additional parameters, "xformat" and "yformat", were also added + to allow the user to set the format for axis labels overriding any + values in the image header. The "xlabel" parameter values were + extended to include the special word "wcslabel" to select the WCS + label for the x axis from the image header. + +o WCS support was added to the task implot. A new parameter called + "wcs" was added to define the coordinate system for plotting, + either logical, physical, or world. Two new ":" commands were also + added: ":w" allows the user to set a new WCS type interactively; + ":f" allows the user to change the axis format, for instance, ":f + %H" would change the axis to read h:m:s, if the world coordinate RA + had been defined in the image header. The "space" key now prints + out the coordinate and pixel value information. + +o graph has a another new parameter "overplot" that allows the user + to overplot multiple plots with different axes. + +o The default parameters for "floor" and "ceiling" in contour and + surface were changed to INDEF. + + +3.1.7 PROTO package reorganization and modifications + + This package has been reorganized. The PROTO package now resides +in the core system. Tasks in the old PROTO package that were general +image processing tools were kept in this new PROTO package. Tasks that +were more data reduction specific were moved to the new NPROTO package +in the NOAO package. The current PROTO package now contains the tasks +binfil, bscale, epix, fields, fixpix, hfix, imalign, imcentroid, +incntr, imfunction, imreplace, imscale, interp, irafil, joinlines, +suntoiraf, wcsedit, and wcsreset. + +o The new task hfix was added to the package. This task allows the + user to extract the image headers into a text file, view or modify + this file with a specified command, and then update the image + header with the modified file. + +o A new task called suntoiraf was added to this package. This is a + host dependent task that will most likely be useful only on Sun's. + This task converts a Sun raster file into an IRAF image. + +o Two new tasks dealing with the WCS were added to this package, + wcsreset and wcsedit. wcsreset resets the coordinate systems in + the image header to the logical coordinate system. wcsedit allows + the user to modify the existing WCS or to create a new WCS and then + update the image header. + +o A new version of bscale was added to the package. The task now + takes a list of input images and output images. + +o A new version of imfunction was added to the package. The task + supports many more functions, for example log10, alog10, ln, aln, + sqrt, square, cbrt, cube, abs, neg, cos, sin, tan, acos, asin, + atan, hcos, hsin, htan, and reciprocal. + +o imreplace was modified to support the "ushort" pixel type. + +o The task join has been renamed joinlines. + + +3.1.8 Additions to XTOOLS and MATH + + Programmers may be interested in the following new additions to the +XTOOLS and MATH libraries. + +o The interactive non-linear least squares fitting package INLFIT, + developed by Pedro Gigoux at CTIO, was added to XTOOLS. + +o The 1D image interpolation routines in the MATH library were + modified to support sinc interpolation. + + +3.1.9 Glossary of new tasks in the IRAF core system + +Task Package Description + +gdevices plot List imaging or other graphics devices +hfix proto Fix image headers +imcombine images Combine images pixel-by-pixel +phistogram plot Plot or print the histogram of an image or list +pradprof plot Plot or list the radial profile of an object +suntoiraf proto Convert Sun rasters into IRAF images +wcsedit proto Edit the image coordinate system +wcslab tv Overlay an image with a world coordinate grid +wcsreset proto Reset the image coordinate system + + +3.2 Changes to the NOAO Packages + + An updated version of the observatory task has been installed at the +NOAO level. The task sets observatory parameters from a database of +observatories or from the parameters in the task itself. Many packages +and tasks within the NOAO packages that need information about where +the data was observed use information supplied by the observatory task. + + +3.2.1 ARTDATA package modifications + + A new version of the ARTDATA package was released with IRAF version +2.9.1. A summary of those changes plus modifications since that update +are listed below. A more comprehensive list of the changes included in +V2.9.1 are discussed in IRAF Newsletter Number 10. + +o A new task mkechelle has been added that creates artificial 2D + echelle images. + +o A new task mkexamples has been added. The task is intended to + generate a variety of artificial images to be used in testing or + demonstrations. + +o A new task mkheader adds or modifies image headers using a header + keyword data file. + +o The mk1dspec task was modified to create multispec and echelle + format images, line by line. + +o A parameter "header" was added to mkobjects, mknoise, mk1dspec, and + mk2dspec so that a header data file could be added to the output + image. Other header parameters are also added to the image header + such as gain, rdnoise, and exptime. + +o A "comments" parameter was added to various tasks to + include/exclude comments in the header of the output image that + describe the data parameters. + + +3.2.2 ASTUTIL package modifications + +o A new task gratings has been added to the package. This task + computes grating parameters; five of the seven parameters must be + specified at one time. + +o A new task setjd has been added to the package. setjd computes the + geocentric, heliocentric, and integer local Julian dates from + information given in the headers of the input list of images. This + information is then listed or added to the image headers. + +o A few changes were made to setairmass. The default value for + "update" was changed to "yes"; an update field was added to the + "show" messages; a warning is printed if both "show" and "update" + are set to "no" indicating that nothing was done. + + +3.2.3 DIGIPHOT package modifications + + A new version of the DIGIPHOT package was installed. Some changes +were made to the existing APPHOT package used for aperture photometry, +and those are mentioned below. But three new packages have also been +installed, DAOPHOT, PHOTCAL, and PTOOLS. + +DAOPHOT has been available for the past two years as an add-on package +known as TESTPHOT. It is now part of the distributed system. The IRAF +version of DAOPHOT, used to do photometry in crowded fields, has been a +collaborative effort with Peter Stetson and Dennis Crabtree of the +DAO. For the convenience of the many TESTPHOT users, changes to the +package since the last release of TESTPHOT are summarized below. + +PHOTCAL is the photometric calibration package for computing the +transformations of the instrumental magnitudes output from APPHOT and +DAOPHOT to the standard photometric system. This package has been a +collaborative effort with Pedro Gigoux at CTIO. + +PTOOLS is a package containing an assortment of tools for manipulating +the data files produced from APPHOT and DAOPHOT. If users are using +STSDAS TABLES format data files then they must first install the TABLES +layered package. This package can be obtained from either STScI or +NOAO (see iraf/contrib in the IRAF network archive). + + +3.2.4 DIGIPHOT.APPHOT package modifications + +o The apselect task was replaced with the functionally equivalent + txdump task. txdump allows the user to select fields of data from + the output data files produced from APPHOT tasks and either simply + list the extracted data or save it in another file. + +o A new task called pexamine has been added to the package. pexamine + is a general purpose tool for interactively examining and editing + the data files produced from tasks in either APPHOT or DAOPHOT. + This task is intended to complement the batch oriented task txdump. + +o All of the APPHOT tasks will now query to verify the "datamin" and + "datamax" values, if these values are used by the tasks. + +o The time of the observation, i.e. UT, can now be carried over into + the output data files, if a keyword in the image header contains + this information. + +o If there is bad data within the photometry aperture a value of + INDEF will be stored in the data file for that magnitude. + + +3.2.5 DIGIPHOT.DAOPHOT (TESTPHOT) package modifications + + This is a new package but for the convenience of the many users of +the TESTPHOT add-on package, the changes to TESTPHOT between its last +release and its installation into the DIGIPHOT package as DAOPHOT are +summarized below. + +o The append, convert, dump, renumber, select, and sort tasks were + renamed to pappend, pconvert, pdump, prenumber, pselect, and psort. + +o The "text" parameter was moved from daopars to the DAOPHOT package + parameters. + +o All the DAOPHOT routines were modified so that "psfrad", "fitrad", + and "matchrad" are defined in terms of scale. + +o The tasks allstar, group, nstar, peak, psf, and substar were all + modified to include "datamin" and "datamax" in their verify + routines. + +o Support was added for a time of observation parameter to all the + appropriate DAOPHOT tasks. If present, this time will be carried + over into the output data files. + +o All the DAOPHOT tasks except psf have been modified to accept lists + of input and output files. + +o The new pexamine task was added to this package. pexamine is a + general purpose tool for interactively examining and editing the + data files produced from tasks in either APPHOT or DAOPHOT. This + task is intended to complement the batch oriented task txdump. + +o Several changes were made to psf: the default PSF image header will + now hold up to 66 stars (but it is still dependent on the + environment variable min_lenuserarea); a check was added so that + the same star can not be added to the PSF twice; potential PSF + stars are now rejected if their sky or magnitude values are INDEF; + a check was added so that stars with INDEF valued positions are + treated as stars that were not found. + +o group was modified so that the groups are output in y order instead + of in order of the size of the group. + +o Both group and peak were modified so that stars with INDEF centers + are not written to the output file. + + +3.2.6 IMRED package modifications + + The spectroscopic packages within the IMRED package have undergone +quite a bit of work and reorganization. The spectroscopic packages are +now ARGUS, CTIOSLIT, ECHELLE, HYDRA, IIDS, IRS, KPNOCOUDE, KPNOSLIT, +and SPECRED. These packages are a collection of tasks from APEXTRACT +and ONEDSPEC that are appropriate for the specific applications. All +these packages use the new versions of the APEXTRACT and ONEDSPEC +packages; the changes for APEXTRACT and ONEDSPEC are summarized below. +Earlier versions of all these packages were released as the NEWIMRED +add-on package. The NEWIMRED package is now defunct and the +distributed system contains the latest versions of these packages. + +The spectroscopic packages now contain "DO" tasks that are scripts that +streamline the reduction process for the user. The "DO" tasks have been +modified for each particular application. + +The ARGUS package is for the reduction of data taken with the CTIO argus +instrument. Its corresponding script task is doargus. + +The CTIOSLIT package is similar to the ARGUS package except that is a +collection of spectroscopic tasks used for general CTIO slit +reductions. The doslit task allows for streamlined reductions. + +The ECHELLE package has the addition of the doecslit task for simplied +echelle reductions. The dofoe task has been added for the reduction of +Fiber Optic Echelle (FOE) spectra. + +The HYDRA package is used for the reduction of multifiber data taken at +KPNO. The dohydra task has been customized for streamlining nessie and +hydra reductions. + +The KPNOCOUDE package has been customized for the KPNO Coude. The +doslit task allows the user to go through the reduction process with as +few keystrokes as possible. The do3fiber task is specialized for the 3 +fiber (two arc and one object) instrument. + +The KPNOSLIT package can be used for general slit reductions at KPNO. +The doslit task in this package is similar to that in the other +packages. + +The SPECRED package is the old MSRED package, used for general +multispectral reductions. This is a generic package that can be used +for slit and multifiber/ aperture data. General doslit and dofibers +tasks are available. + +Several of the spectroscopic packages has a special task called msresp1d +for creating 1d aperture response corrections from flat and throughput +data. This task is specialized for multiaperture or multifiber data. + +All of the "DO" tasks have reference manuals that are available in the +network archive in the iraf/docs directory. + + +3.2.7 IMRED.CCDRED package modifications + +o A new task ccdinstrument was added to the package. The purpose of + this task is to help users create new CCD instrument translation + files to use with the package. + +o The combine task (as well as darkcombine, flatcombine, and + zerocombine) is the same task as the new imcombine task in IMAGES. + A few parameters were added for compatibility with the CCDRED tasks. + +o A new parameter was added to ccdproc called "minreplace". Pixel + values in flat fields below the value for "minreplace" are replaced + by the same value (after overscan, zero, and dark corrections). + This avoids dividing by zero problems. + +o The default computation and output "pixeltype" in the package + parameter for CCDRED are both real. Note that both can now be + specified separately. + +o The default parameters for darkcombine and flatcombine have been + changed. + + +3.2.8 NOBSOLETE package added + + This new package has been defined but currently no tasks reside in +it. This package will be used as a repository for tasks that have been +replaced by newer tasks in the NOAO packages. The NOBSOLETE tasks will +then be removed at the time of the next release. + + +3.2.9 NPROTO package modifications + + The old PROTO package was divided into two separate packages, one +called PROTO that now resides in the IRAF core system and the other +called NPROTO that resides in the NOAO package. The current NPROTO +tasks are binpairs, findgain, findthresh, iralign, irmatch1d, +irmatch2d, irmosaic, linpol, and slitpic. The imedit, imexamine, and +tvmark tasks were moved to the IMAGES.TV package. The ndprep task was +moved to ONEDSPEC. All other tasks were moved to the PROTO package at +the core level. + +o Two new tasks called findgain and findthresh were added to this + package. findgain determines the gain and read noise of a CCD from + a pair of dome flats and from a pair of bias/zero frames using the + Janesick method. findthresh estimates the background noise level + of the CCD using a sky frame and the gain and readnoise of the CCD. + +o A new task called linpol has been added to the PROTO package. This + task calculates the pixel-by-pixel fractional linear polarization + and polarization angle for three or four images. The polarizer + must be set at even multiples of a 45 degree position angle. + +o The task ndprep used for CTIO 2DFRUTTI reductions was moved to the + ONEDSPEC package. + +o The task toonedspec was removed since its function can now be + performed by the onedspec.scopy task. + + +3.2.10 ONEDSPEC package reductions + + There have been significant changes to the ONEDSPEC package. A +more detailed revisions summary is available in the IRAF network +archive as file onedv210.ps.Z in the subdirectory iraf/docs. + +The new package supports a variety of spectral image formats. The older +formats can still be read. In particular the one dimensional +"onedspec" and the two dimensional "multispec" format will still be +acceptable as input. Note that the image naming syntax for the +"onedspec" format using record number extensions is a separate issue +and is still provided but only in the IMRED.IIDS and IMRED.IRS +packages. Any new spectra created are either a one dimensional format +using relatively simple keywords and a two or three dimensional format +which treats each line of the image as a separate spectrum and uses a +more complex world coordinate system and keywords. For the sake of +discussion the two formats are still called "onedspec" and "multispec" +though they are not equivalent to the earlier formats. + +In addition, the one dimensional spectral tasks may also operate on two +dimensional images. This is done by using the "dispaxis" keyword in the +image header or a package dispaxis parameter if the keyword is missing +to define the dispersion axis. In addition there is a summing +parameter in the package to allow summing a number of lines or +columns. If the spectra are wavelength calibrated long slit spectra, +the product of the longslit.transform task, the wavelength information +will also be properly handled. Thus, one may use splot or specplot for +plotting such data without having to extract them to another format. +If one wants to extract one dimensional spectra by summing columns or +lines, as opposed to using the more complex APEXTRACT package, then one +can simply use scopy (this effectively replaces proto.toonedspec) + +Another major change to the package is that spectra no longer need to +be interpolated to a uniform sampling in wavelength. The dispersion +functions determined by identify/reidentify can now be carried along +with the spectra in the image headers and recognized throughout the +package and the IRAF core system. Thus the WCS has been fully +implemented in the ONEDSPEC tasks and although much is to be gained by +this it can cause problems with earlier IRAF systems as well as making +it difficult to import data into non-IRAF software. But it is now +possible to use imcopy with an image section on a spectrum, for +instance, and have the wavelength information retained correctly. + +A sinc interpolator is now available for those tasks doing geometric +corrections or interpolations. This option can be selected by setting +the "interp" parameter in the ONEDSPEC package parameters. + +Other changes are summarized: + +o The new task deredden corrects input spectra for interstellar + extinction, or reddening. + +o The new task dopcor corrects input spectra by removing a specified + doppler velocity. The opposite sign can be used to add a doppler + shift to a spectrum. + +o The new task fitprofs fits 1D gaussian profiles to spectral lines or + features in an image line or column. This is done noninteractively + and driven by an input list of feature positions. + +o The task ndprep was moved to this package from the PROTO package. + ndprep is used for CTIO 2DFRUTTI reductions. + +o The new task sapertures adds or modifies beam numbers and aperture + titles for selected apertures based on an aperture identification + file. + +o The new task sarith does spectral arithmetic and includes unary + operators. The arithmetic can be performed on separate input + spectra or on apertures within a multispec format image. + +o The task scombine has been added to the package. This new task is + similar to the new imcombine task in the IMAGES package but is + specialized for spectral data. + +o The new task scopy copies subsets of apertures and does format + conversions between the different spectrum formats. + +o The new task sfit fits spectra and outputs the fits in various ways. + This includes a new feature to replace deviant points by the fit. + Apertures in multispec and echelle format are fit independently. + +o The tasks addsets, batchred, bswitch, coincor, flatdiv, flatfit, + subsets and sums were moved to the IIDS and IRS packages. + +o The task combine was removed with the all new scombine suggested in + its place. + +o The tasks rebin, sflip and shedit were removed from the package. + Rebinning of spectra can now be done with scopy or dispcor. scopy + and imcopy can now be used in place of sflip. And hedit is an + alternative for shedit. + +o bplot and slist have been modified to support the multispec format. + +o The task continuum now does independent fits for multispec and + echelle format spectra. + +o There is now only one dispcor task doing the work of the three + previous tasks dispcor, msdispcor and ecdispcor. Several of the + parameters for this task have been changed. The old "recformat" + and "records" parameters for supporting the old onedspec format + have been removed except in the IIDS/IRS packages. A "linearize" + parameter has been added for setting the interpolation to yes or no + on output. The "interpolation" parameter was removed since this + information is now read from the package parameter "interp". The + "ignoreaps" parameter has been changed to "samedisp". + +o identify and reidentify now treat multispec format spectra and two + dimensional images as a unit allowing easy movement between + different image lines or columns. The database is only updated upon + exiting the image. The "j", "k", and "o" keys have been added to + the interactive sessions to allow for scrolling through the + different lines in a two dimensional image. The database format + now uses aperture numbers rather than image sections for multispec + format spectra. + +o The task specplot has new parameters "apertures" and "bands" to + select spectra for plotting in the multispec format. + +o splot now allows deblending of any number of components and allows + simultaneous fitting of a linear background. Several cursor keys + have been redefined and colon commands have been added to fully + support the new multispec format and to add even more flexibility + to the task than before! Please see the help pages for details. + +o The reidentify task is essentially a new task. The important + changes are an interactive review option, the ability to add + features from a line list, using the same reference spectrum for + all other spectra in a 2D reference image rather than "tracing" + (using the results of the last reidentification as the initial + guess for the next one) across the image, and matching image + lines/columns/apertures from a 2D reference image to other 2D + images rather than "tracing" again. + + +3.2.11 RV package added + + This is a new package installed with IRAF version 2.10. A version +of this package, RV0, has been available as an add-on for the past year +or so. The package contains one main task fxcor that performs a Fourier +cross-correlation on the input list of spectra. The package supports +the multispec format. + + +3.2.12 TWODSPEC package modifications + + The old MULTISPEC package that has resided in the TWODSPEC package +for years has been disabled. The code is still there for browsing, +however, and the package can be resurrected easily if needed. + +The observatory task was moved to the NOAO package itself. The +setairmass task was moved to LONGSLIT. And the setdisp task is no +longer needed; task or package parameters are used in its place. + +Changes to the APEXTRACT and LONGSLIT packages are summarized below. + + +3.2.13 TWODSPEC.APEXTRACT package modifications + + A new version, version 3, of the IRAF APEXTRACT package has been +completed. A detailed revisions summary is available in the IRAF +network archive (file apexv210.ps.Z in iraf/docs). + +There were three goals for the new package: new and improved cleaning +and variance weighting (optimal extraction) algorithms, the addition of +recommended or desirable new tasks and algorithms (particularly to +support large numbers of spectra from fiber and aperture mask +instruments), and special support for the new image reduction scripts in +the various IMRED packages. + +The multispec format, the default image format for all spectroscopic +packages except IIDS and IRS, is either 2D or 3D (the 3D format is new +with this release). The 3D format is produced when the parameter +"extras" is set to yes in the extraction tasks. The basic 2D format, +which applies to the first plane of the 3D format, has each 1D aperture +spectra extracted in a line. Thus, the first coordinate is the pixel +coordinate along the spectra. The second coordinate refers to the +separate apertures. The third coordinate contains extra information +associated with the spectrum in the first plane. The extra planes are: + + 1: Primary spectra which are variance and/or cosmic ray cleaned + 2: Spectra which are not weighted or cleaned + 3: Sky spectra when using background subtraction + 4: Estimated sigma of the extracted spectra + +If background subtraction is not done then 4 moves down to plane 3. +Thus: + + output.ms[*,*,1] = all primary spectra + output.ms[*,5,1] = 5th aperture spectrum which is cleaned + output.ms[*,5,2] = raw/uncleaned 5th aperture spectrum + output.ms[*,5,3] = sky for 5th spectrum + output.ms[*,5,4] = sigma of 5th spectrum + + +The following summarizes the major new features and changes. + +o New techniques for cleaning and variance weighting extracted + spectra have been implemented. + +o Special features for automatically numbering and identifying large + numbers of apertures have been added. + +o There is no longer a limit to the number of apertures that can be + extracted. + +o The new task apall integrates all the parameters used for one + dimensional extraction of spectra. + +o The new task apfit provides various types of fitting for two + dimensional multiobject spectra. + +o The new task apflatten creates flat fields from fiber and slitlet + spectra. + +o The new task apmask creates mask images from aperture definitions + using the new pixel list image format. No tasks have yet been + written, however, to use this new mask image format. + +o The new tasks and algorithms, aprecenter and apresize, will + automatically recenter and resize aperture definitions. + +o The task apio is defunct. Its functionality has been replaced by + the APEXTRACT package parameters. + +o The task apstrip has been removed. + +o Minor changes have been made to the old "AP" tasks to accommodate + these new changes in the package; in some cases new parameters have + been added to the task and in other cases new cursor options have + been implemented. See the help pages for details. + + +3.2.14 TWODSPEC.LONGSLIT package modifications + +o The "dispaxis" parameter was added to the package parameters. This + value is used unless DISPAXIS is in the image header. + + +3.2.15 Glossary of new tasks in the NOAO packages + +Task Package Description + +addstar daophot Add artificial stars to an image +allstar daophot Group and fit psf to multiple stars +apall apextract Extract 1D spectra +apfit apextract Fit 2D spectra +apflatten apextract Remove shapes from flat fields +apmask apextract Create an IRAF pixel mask from apertures +aprecenter apextract Recenter apertures +apresize apextract Resize apertures +ccdinstrument ccdred Review instrument translation files +centerpars daophot Edit the centering algorithm parameters +chkconfig photcal Check the configuration file +continpars rv Edit continuum subtraction parameters +daofind daophot Find stars using the DAO algorithm +daopars daophot Edit the daophot algorithms parameter set +datapars daophot Edit the data dependent parameters +deredden onedspec Apply interstellar extinction correction +do3fiber kpnocoude Process KPNO coude three fiber spectra +doargus argus Process ARGUS spectra +doecslit echelle Process Echelle slit spectra +dofibers specred Process fiber spectra +dofoe echelle Process Fiber Optic Echelle (FOE) spectra +dohydra hydra Process HYDRA spectra +dopcor onedspec Apply doppler corrections +doslit ctioslit Process CTIO slit spectra +doslit kpnocoude Process KPNO coude slit spectra +doslit kpnoslit Process slit spectra +doslit specred Process slit spectra +evalfit photcal Compute standard indices +filtpars rv Edit the filter function parameters +findgain nproto Estimate the gain and readnoise of a CCD +findthresh nproto Estimate a CCD's sky noise +fitparams photcal Compute transformation equations +fitprofs onedspec Fit gaussian profiles +fitskypars daophot Edit the sky fitting parameters +fxcor rv Radial velocities via cross correlation +gratings astutil Compute and print grating parameters +group daophot Group stars +grpselect daophot Select groups from a daophot database +invertfit photcal Compute the standard indices by inversion +istable ptools Is a file a table or text database file? +linpol nproto Polarization and Stoke's parameters +keywpars rv Translate image header keywords +mkcatalog photcal Type in a standard star catalog +mkconfig photcal Prepare a configuration file +mkechelle artdata Make artificial 1D and 2D echelle spectra +mkexamples artdata Make artificial data examples +mkheader artdata Append/replace header parameters +mkimsets photcal Prepare an image set file for mkNobsfile +mk(n)obsfile photcal Make a starfield observations file +mkphotcors photcal Check photometric corrections files +msresp1d argus Create 1D response spectra +msresp1d hydra Create 1D response spectra +msresp1d kpnocoude Create fiber response spectra +msresp1d specred Create 1D response spectra +nstar daophot Fit the psf to groups of stars +obsfile photcal Make a starfield observations file +pappend daophot Concatenate daophot databases +pappend ptools Concatenate apphot/daophot databases +pconvert daophot Convert text database to tables database +pconvert ptools Convert text database to tables database +pdump daophot Print fields from daophot databases +pdump ptools Print columns of daophot/apphot databases +peak daophot Fit the psf to single stars +pexamine apphot Examine or edit an apphot output file +pexamine daophot Examine and edit a daophot database +pexamine ptools Examine and edit an apphot/daophot database +phot daophot Compute sky values and initial magnitudes +photpars daophot Edit the photometry parameters +prenumber daophot Renumber stars in a daophot database +prenumber ptools Renumber a list of apphot/daophot databases +pselect daophot Select records from daophot database +pselect ptools Select records from apphot/daophot databases +psf daophot Fit the point spread function +psort daophot Sort a daophot database +psort ptools Sort a list of apphot/daophot databases +sapertures onedspec Set or change aperture header information +sarith onedspec Spectrum arithmetic +scombine onedspec Combine spectra +scopy onedspec Select and copy apertures +seepsf daophot Compute an image of the PSF +setjd astutil Compute and set Julian dates in images +sfit onedspec Fit spectra +substar daophot Subtract the fitted stars +tbappend ptools Concatenate apphot/daophot tables databases +tbdump ptools Print columns of tables databases +tbrenumber ptools Renumber apphot/daophot tables databases +tbselect ptools Select records from apphot/daophot databases +tbsort ptools Sort apphot/daophot tables databases +txappend ptools Concatenate apphot/daophot text databases +txdump apphot Dump selected fields of apphot output file +txdump ptools Print columns of text databases +txrenumber ptools Renumber apphot/daophot text databases +txselect ptools Select records from text databases +txsort ptools Sort apphot/daophot text databases + + + +4. Programming Environment Revisions + + + +4.1 Compatibility Issues + + V2.10 IRAF requires that any local IRAF programs external to the +V2.10 system (such as layered packages or locally written tasks) be +fully recompiled if they are relinked against V2.10. The problem +arises only if the programs are relinked; external programs will +continue to run after V2.10 is installed, but linker errors will be +seen if the programs are relinked without being fully recompiled. This +is because the internal names of some important system routines were +changed in V2.10 to avoid name clashes with host system routines. For +example, the SPP procedure "rename" is now translated to "xfrnam" when +the SPP code it appears in is compiled. + +As always, actual interface changes affecting existing source code were +very few. The macro "E" in was renamed to "BASE_E" to minimize +the chance of an accidental name collision. The calling sequence for +the onentry procedure (ETC) was changed, but since this is a little used +system procedure very few tasks should be affected. A number of new +procedures were added to MTIO and the syntax of a magtape device has +changed; old applications should be modified to use the MTIO procedures +to operate upon magtape device names. + +These and other revisions affecting the programming environment are +discussed in more detail below. + + + +4.2 Portability Issues + + The V2.10 UNIX/IRAF kernel now includes "#ifdef SYSV" support for +System V UNIX, making it easier to port IRAF to SysV based systems. +The UNIX/IRAF HSI (host system interface) is still not as portable to +UNIX variants as it could be, but at this point it is easier for us to +make the minor revisions required for a new port than to further refine +the HSI. The disadvantage is that it is harder than it should be for +people in the community to do their own IRAF ports, due to the level of +IRAF expertise required to tune the code. Someday we plan to generate +a generic-UNIX HSI. Note that these comments pertain only to the few +thousand lines of code in the HSI - the bulk of the IRAF code is 100% +portable (identical on all IRAF systems) as it has always been. + +The recent port of IRAF to A/UX (the Apple Macintosh UNIX) is +interesting from a portability standpoint because we used the +publically available Fortran to C translator f2c plus the GNU C +compiler gcc to compile all the SPP and Fortran code in IRAF. This was +remarkably successful and means that the IRAF code is now portable to +any system with a C compiler. In the process of performing these +compilations a few dozen minor bugs were found by the static compile +time checking performed by f2c and gcc. The IRAF C code was run +through gcc with ANSI mode enabled, and hence should now be ANSI-C +compatible. The GNU debugger gdb proved to be an effective tool for +debugging of IRAF code compiled with gcc. + + + +4.3 Software Tools + + +4.3.1 LOGIPC feature + + A new facility has been added to UNIX/IRAF (all systems) for +debugging interprocess communication (IPC). This feature will also be +useful for debugging tasks standalone, particularly in cases where a +bug seen when running a task from the CL is difficult to reproduce when +the task is run standalone. The new facility allows one to carry out a +normal IRAF session while transparently logging all interprocess +communications. Each process can then be rerun individually using the +logged IPC to exactly duplicate the functioning of the process to, +e.g., examine the program operation in detail under a debugger. + +The facility is this: if LOGIPC is defined in the host environment when +an iraf process is started, the process will create two files pid.in +and pid.out, where pid is the process id. Everything read from the IPC +input file is copied to the .in file, and everything written to the IPC +output (i.e., sent back to the CL) is copied to the .out file. This is +done only for connected subprocesses. It will work for any connected +subprocess, e.g., normal cached processes and graphics subkernels in +both foreground and background CLs, but not the i/o of the CL itself +since the CL is not driven by IPC. + +The IPC streams saved are an exact binary copy of whatever was sent via +IPC, including the binary IPC packet headers, and binary graphics data, +and so on. All the IPC communications used to start up the process, +run zero or more tasks, and close the process down will be logged. +Most IPC traffic is textual in nature so it will usually be possible to +examine the IPC files with a file pager, although the results may be +less than satisfactory if binary data such as a graphics metacode +stream is logged. It is not necessary to examine the IPC files to use +them for process execution or debugging. + +A particularly interesting use of this feature is to allow a process to +be run under the CL in the normal fashion, then rerun under a host level +debugger using the saved IPC input to duplicate the input and actions +of the process when run under the CL. For example, + + % setenv LOGIPC + % cl + cl> dir + cl> logout + % unsetenv LOGIPC + +will run the CL, saving the IPC of all subprocesses, e.g. x_system.e. +We can then run the system process manually, using the saved IPC input: + + % $iraf/bin/x_system.e -c < pid.in + +To run the process under adb or dbx, using the saved input: + + % adb $iraf/bin/x_system.e + :r <pid.in -c + +or + + % dbx $iraf/bin/x_system.e + dbx> r -c < pid.in + +Note that the redirection has to be given first for adb, and last for +dbx. This also works for gdb using the run command. Some +implementations of adb are picky about syntax and will not allow a +space between the "<" and the process id in the :r command. + +Running a task in this way is not identical to running the task +standalone, e.g. using a dparam file for parameter input, because the +full runtime context of the process as run under the CL is reproduced +by LOGIPC but not when the task is run standalone. The differences are +subtle but can be important when trying to reproduce a bug seen when +the process is run under the CL. It is often the case that a bug seen +when a task is run from the CL will disappear when the task is run +standalone, but in most cases LOGIPC will duplicate the bug. + + +4.3.2 XC changes + + The xc program (IRAF compiler-linker) underwent the following +changes for V2.10, in addition to the usual host-system specific +changes required to support new host compiler versions. + +Multiple "-p pkgname" arguments are now supported. These are used when +compiling a module which uses multiple package environments, e.g., + + cl> xc -p noao -p tables foo.x + +Each package environment may define package environment variables, +directories to be searched for include files and libraries, and so on. +Package environments are used by the IRAF layered packages. + +Host libraries named on the command line using the -l switch (e.g., +"-lresolv") are now searched after the IRAF system libraries, rather +than before as in previous versions of xc. If the host library is +referenced by absolute pathname it is still searched before the IRAF +libraries, since the command line order determines the search order. + + +4.3.3 SPPLINT code checker + + A static code checker utility spplint has been developed for +checking SPP programs. This uses the SPP translation utilities in IRAF +to convert SPP to Fortran, f2c to generate C code, and lint to check +the C code. The code is checked in various ways at all phases of +translation. Some of the most useful checking are performed by f2c, +which checks the number and type of arguments in all calls to IRAF VOS +library procedures. In other words, spplint will determine if an IRAF +library procedure is called incorrectly, as well as perform a variety +of other checks. + +The spplint utility is not included in the main IRAF release, but is +available separately. Contact the IRAF project for information on the +availability of this and other optional code development utilities. + + +4.3.4 Multiple architecture support + + Multiple architecture support is a way of using multiple sets of +compiled program binaries within a single copy of IRAF. Multiple sets +of binaries are used to support different machine architectures (e.g. +sparc and Motorola), different compiler options (floating point +options, vectorization options, profiling options), different +compilers, and so on. + +The command for checking the architecture of the IRAF core system or a +layered package has been changed from showfloat to arch to reflect the +fact that multiple architecture support is no longer used merely to +select the floating point option. + + cl> mkpkg arch + sparc + +The default architecture of the distributed system is "generic", meaning +no specific architecture has been set (the source tree is generic, not +configured for any particular architecture). + +It is suggested that developers of layered software for IRAF adopt this +same convention in their root mkpkg files. + + +4.3.5 Package environments + + All the HSI software utilities now permit multiple "-p pkgname" +package environment references. The host PKGENV environment variable +now also permits multiple package environments to be referenced, e.g. + + % setenv PKGENV "noao tables xray" + +The package names should be whitespace delimited (PKGENV is used to +avoid having to give the "-p" flags on the mkpkg or xc command line). +To successfully load a package enironment, the package root directory +must be defined in hlib$extern.pkg or in the user's host environment. +A host environment definition will override the value given in +extern.pkg. + + +4.3.6 Finding module sources + + IRAF V2.10 includes a "tags" file in the IRAF root directory to aid +software development. This file contains an index to all procedures in +the IRAF VOS and HSI and can be used with host editors such as vi to +rapidly find and display the source for IRAF system procedures. Note +that the names of the kernel procedures are given in upper case, e.g., +"ZOPNBF", whereas the names of the VOS procedures are given in lower +case. To use the tags file with vi, start the editor at the IRAF root +directory and while in the editor, type a command such as ":ta foo" to +view the source for procedure foo. + + + +4.4 Programming Interface Changes + + +4.4.1 IEEE floating support + + Modifications were made to the IEEE floating conversion routines in +the OSB package to support NaN mapping. This is a low level package +used by, e.g., the MII package in ETC. The interface as it currently +stands is summarized below. + + ieepak[rd] (datum) # pack scalar value + ieeupk[rd] (datum) # unpack scalar value + ieevpak[rd] (native, ieee, nelem) # pack vector + ieevupk[rd] (ieee, native, nelem) # unpack vector + iee[sg]nan[rd] (NaN) # set/get NaN value + ieemap[rd] (mapin, mapout) # enable/disable NaN mapping + ieestat[rd] (nin, nout) # get count of NaN values + ieezstat[rd] () # zero NaN counters + + +The new or modified routines are ieesnan, ieegnan, ieemap, ieestat, and +ieezstat. By NaN (not-a-number) we refer collectively to all IEEE +non-arithmetic values, not just IEEE NaN. The routines ieesnan and +ieegnan set or get the native floating value used to replace NaNs or +overflows occurring when converting IEEE to the native floating format +(any floating value will do, e.g., zero or INDEF). If NaN mapping is +enabled, the ieestat routines may be used to determine the number of +input or output NaN conversions occurring since the last call to +ieezstat. Both real and double versions of all routines are provided. + +The NaN mapping enable switch and statistics counters are undefined at +process startup; programs which use the IEEE conversion package should +call ieemap to enable or disable NaN mapping, and ieezstat to +initialize the statistics counters. + + +4.4.2 MATH libraries + + The following changes were made to the MATH libraries in the IRAF +core system. Refer to the online help pages of the affected routines +for detailed information. + +o The one-dimensional image interpolation library iminterp was + modified to add support for sinc interpolation. + +o A new library nlfit was added for non-linear function fitting. An + interactive graphics front end to this was also added in XTOOLS. + +o The name of the symbol E in was changed to BASE_E to + minimize the chance of name clashes. + + +4.4.3 CLIO interface + + The CLIO (command language i/o) interface underwent the following +changes for version 2.10 IRAF. + +o A README file was added to the source directory containing an up to + date interface summary. + +o The routines clgpset and clppset (get/put string valued parameter) + were renamed clgpseta and clppseta. The old procedures were + retained for compatibility but are now obsolete and may at some + point in the future disappear or be reused for some other function. + +o Two new routines cllpset and clepset were added for listing and + editing psets (parameter sets). + + The calling sequences for the new pset routines are as follows. + + cllpset (pp, fd, format) # list pset + clepset (pp) # edit pset + + These new routines are still considered experimental and should be + avoided or used with caution (they could change). + + Internal to the CLIO code, the CLIO parameter caching package + underwent minor changes to add a new clc_compress routine and + improve pset handling, as part of the minilanguage support effort. + + +4.4.4 ETC interface + + The ETC interface contains miscellaneous system interface routines. +The ETC interface underwent the following changes for V2.10 IRAF. + + +4.4.4.1 Calling sequence for onentry changed + + The calling sequence for the onentry routine was changed. The new +calling sequence is as follows. + + action = onentry (prtype, bkgfile, cmd) + +The onentry procedure is an optional procedure which is called when an +IRAF process starts up. Normally the onentry procedure is a no-op, +passing control to the IRAF main in-task interpreter. Custom IRAF +applications, e.g., the CL, have a special onentry procedure which +replaces the default in-task interpreter. + +The change made to the onentry calling sequence was the addition of the +additional argument cmd. This argument receives the command line used +to invoke the IRAF process at the host level. The application can +parse this command line to extract arguments, allowing the IRAF process +to operate as a host program (it is already possible to call any IRAF +task from the host level, but use of an onentry procedure allows the +in-task interpreter to be bypassed and gives the application control +over parsing the command line). + +See etc$onentry.x for additional information on how to use this +procedure. + + +4.4.4.2 New onerror and onexit procedures + + Two new procedures onerror_remove and onexit_remove were added. +These have the following calling sequences. + + onerror_remove (proc) # remove posted onerror procedure + onexit_remove (proc) # remove posted onexit procedure + +The new routines are used to remove onerror or onexit procedures posted +by a task during task execution. Such user procedures are called if +the task aborts (onerror procedures) or during normal task exit (onexit +procedures). Formerly there was no way to "unpost" the procedures +other than by the normal cleanup occurring during task termination. + + +4.4.4.3 New gqsort routine + + A new quick-sort routine gqsort (generalized quick sort) was added. +This has the following calling sequence. + + gqsort (x, nelem, compare, client_data) + +gqsort is identical to the old qsort routine except for the addition of +the fourth argument client_data. This is an integer value which is +passed on to the compare procedure during sorting to compare two data +values. The compare routine is called as follows. + + result = compare (client_data, x1, x2) + +The new routine eliminates the need to use a common area to pass +information to the compare routine, as was often necessary with qsort. + + +4.4.5 FIO interface + + The FIO interface (file i/o) underwent minor changes to fix some +bugs affecting pushed back data. The F_UNREAD file status parameter +will now correctly report pushed back data as well as any buffered +input file data. The F_CANCEL file set option will now cancel any +pushed back data. + + +4.4.5.1 Nonblocking terminal i/o + + A new nonblocking form of raw mode terminal input has been added. +This permits polling the terminal for input without blocking +(suspending process execution) if no input is available. In a +character read, EOF is returned if no input is available otherwise the +character value is returned. An example illustrating the use of +nonblocking terminal i/o follows. + + include + + task foo + + procedure foo() + + int fd, ch + int getci() + + begin + fd = STDIN + call fseti (fd, F_IOMODE, IO_RAW+IO_NDELAY) + + repeat { + if (getci(fd,ch) == EOF) + call printf ("no pending input\r\n") + else { + call printf ("ch = %03o\r\n") + call pargi (ch) + } + call sleep (1) + } until (ch == '\004' || ch == 'q') + + call fseti (fd, F_IOMODE, IO_NORMAL) + end + + +This sample program sets the terminal i/o mode to nonblocking raw mode +and polls the terminal once per second, printing the character value in +octal if a character is typed on the terminal, exiting when ctrl/d or +'q' is typed. Note that in raw mode characters such as ctrl/d or +ctrl/c are passed through as data and do not get mapped to EOF, +generate an interrupt, and so on. Raw mode i/o such as this will work +both when running a task under the CL and standalone, and in +combination with IRAF networking (e.g. to access a remote device). + +Nonblocking terminal input is used in applications which run +continuously but which we wish to be able to control interactively. + + +4.4.6 FMTIO interface + + The FMTIO interface (formatted i/o) is used to format output text +or decode input text. The V2.10 release adds two new printf output +formats, %H and %M. These are used to print numbers in +hours-minutes-seconds or minutes-seconds format and are equivalent to +the older output formats %h and %m except that the number is first +divided by 15. This converts degrees to hours allowing values given in +units of degrees to be printed as hours with just a change of the output +format. In other words, given a number N in units of degrees, %H would +print the number in hours-minutes-seconds, i.e., "hh:mm:ss.ss", whereas +%h would print the same number as degrees-minutes-seconds, +"dd:mm:ss.ss". The %m formats are similar except that only two of the +three fields are printed. + + +4.4.7 GTY interface + + The GTY interface is a generalized version of that portion of the +older TTY interface dealing with termcap format files. The TTY code +which accesses termcap format files has been extracted to form the new +GTY interface, allowing arbitrary termcap format files to be accessed +by filename, unlike TTY which returns TTY descriptors given the termcap +or graphcap device name. GTY was contributed by Skip Schaller of +Steward Observatory. + + gty = gtyopen (termcap_file, device, ufields) + gtyclose (gty) + cp = gtycaps (gty) + pval = gtyget[bir] (gty, cap) + nchars = gtygets (gty, cap, outstr, maxch) + + +The gtyopen call returns the GTY descriptor for the named device from +the file termcap_file. The ufields string may be either NULL or a list +of colon-delimited device capabilities, which will override the +corresponding capabilities in the device entry given in the termcap +file. If termcap_file is the null string ufields is taken to be the +device entry for the named device. The gtycaps routine may be used to +get the entire device entry as a string, whereas the gtyget and gtygets +routines are used to get the values of individual capabilities or +parameters. + + +4.4.8 MTIO interface + + MTIO is the magtape i/o interface. The magtape i/o subsystem was +extensively revised for V2.10 IRAF, as documented earlier in this +revisions summary. The VOS level MTIO interface itself was not changed +other than to add a few new routines. The tapecap facility is new in +V2.10. The revisions to the host level magtape driver ZFIOMT required +that the calling sequences of some of the interface routines be changed. + + +4.4.8.1 MTIO applications programming interface + + The current MTIO applications programming interface is summarized +below. Most of these routines are new: the old routines are mtfile, +mtopen, mtrewind and mtposition. + + yes|no = mtfile (fname) + yes|no = mtneedfileno (mtname) + gty = mtcap (mtname) + mtfname (mtname, file, outstr, maxch) + + mtparse (mtname, device, fileno, recno, attrl, maxch) + mtencode (mtname, maxch, device, fileno, recno, attrl) + + fd = mtopen (mtname, acmode, bufsize) + mtrewind (mtname, initcache) + mtposition (mtname, file, record) + + +The mtfile routine is used to test whether the given filename is a +magtape file or something else, i.e., a disk file. mtneedfileno tests +whether a file number has been specified in mtname (e.g., to determine +whether or not to query for a file number parameter). mtfname takes +mtname and a file number and constructs a new magtape device name in +the output string. mtparse parses a magtape device name into its +component parts, and mtencode does the reverse. mtcap returns the GTY +descriptor of the tapecap entry for the device. gtyclose should be +used to free this descriptor when it is no longer needed. + +Some older magtape applications programs parse the magtape device name +directly, looking for characters like `['. These old programs are +making assumptions about the form of a magtape device name which are +probably no longer true. Such old applications should be rewritten to +use the new MTIO procedures for all magtape device name operations. + + +4.4.8.2 MTIO system procedures + + The MTIO interface also includes a number of procedures intended +for use in systems code. These are summarized in the table below. + + mtallocate (mtname) + mtdeallocate (mtname, rewind_tape) + mtstatus (out, mtname) + mtclean (level, stale, out) + + +The only new routine here is mtclean. This is called by the mtclean +task in the V2.10 SYSTEM package and is used to scan the magtape status +file storage area to delete old magtape position status files. Prior +to V2.10 these files were stored in the user's UPARM directory, but in +V2.10 the files are stored in /tmp so that multiple IRAF sessions will +share the same tape position information. A special task is needed to +delete old position files in order to protect against, e.g., one user +deleting another user's device position file while the device is +actively in use. + + +4.4.8.3 Magtape driver procedures + + All access to the physical magtape device is via the host level +IRAF magtape device driver ZFIOMT. The driver procedures had to be +revised for V2.10 to add support for the tapecap facility and to +accommodate changes in the way the device position is maintained. The +new driver procedures are summarized below. + + zzopmt (device, acmode, devcap, devpos, newfile, chan) + zzrdmt (chan, buf, maxbytes, offset) + zzwrmt (chan, buf, nbytes, offset) + zzwtmt (chan, devpos, status) + zzstmt (chan, param, value) + zzclmt (chan, devpos, status) + zzrwmt (device, devcap, status) + + +The corresponding KI (kernel interface) routines were also modified to +reflect the new calling sequences. A result of this is that IRAF +networking for magtape devices is incompatible between V2.10 and +earlier versions of IRAF. + +The host level device driver procedures are not normally called directly +in applications code (applications use mtopen). Refer to the comments +in the source file os$zfiomt.c for additional details. + + +4.4.9 MWCS interface + + The MWCS interface provides world coordinate system support for the +IRAF system and applications. The main changes in the MWCS interface +for V2.10 were bug fixes and semantic changes, e.g. various +restrictions having to do with WCS attributes were removed, new +function drivers were added, and so on. These changes are documented +elsewhere in this revisions summary. + +The only interface change affecting MWCS was the addition of the new +MWCS procedure mw_show. + + mw_show (mw, fd, what) + + +This is used to dump a MWCS descriptor to the given output file, and is +useful for examining MWCS descriptors while debugging applications. + + + +5. Getting Copies of this Revisions Summary + + Additional copies of this revisions summary are available via +anonymous ftp from node iraf.noao.edu in the directory iraf/v210, or via +email from iraf@noao.edu. + IRAF (Mar90) V2.9 Revisions Summary IRAF (Mar90) + + + IRAF Version 2.9 Revisions Summary + April 10, 1990 + + + + +1. Introduction + + This document summarizes the changes in IRAF version 2.9. This was +primarily a development release intended to support applications +software development, hence the major changes were in the programming +environment, although there are important new features of interest to +general users too. Since IRAF V2.9 is primarily a development release, +it is not being released on all platforms, and it is expected that many +sites will not need to upgrade until IRAF V2.10 is available. Sites +interested in obtaining IRAF V2.9 should contact the IRAF project to +determine if the release is available for a particular host system. At +the present time, the release is being made available for all Sun +systems, for VAX/VMS, and for the DECstation running Ultrix. + +What follows is a brief description of some of the new features +available in IRAF Version 2.9. This is not intended to be an +exhaustive list, but rather a brief summary of the major changes since +the last release of IRAF, Version 2.8, released in July 1989. More +detailed revisions notes are available in the system notes file, +iraf$local/notes.v29, as well as in the online revisions notes for the +various packages. + +Users looking for information on a particular new package should note +that if the package is not mentioned in these release notes and +therefore is not included in IRAF V2.9, that does not necessarily mean +that it is not available. Most major reduction and analysis packages +are now made available for testing as user installable layered packages +before they are included in the standard distribution. For information +on the available add-on packages, contact the IRAF group, or check the +latest IRAF Newsletter. + + +This revisions summary is organized as follows: + + 1. Introduction + + 2. IRAF System Revisions + + 3. IRAF Package Revisions + 3.1. Changes to the System Packages + 3.2. Glossary of New Tasks in the IRAF System Packages + 3.3. Changes to the NOAO Packages + 3.4. Modifications and Additions to Calibration Data + 3.5. Glossary of New Tasks in the NOAO Packages + + 4. Programming Environment Revisions + 4.1. Changes to the Programming Utilities + 4.2. Programming Interface Changes + + + +2. IRAF System Revisions + + +2.1 IEEE to native floating point conversions + + Support has been added to the programming interfaces (section +4.2.3) for converting between the IEEE floating point and native +floating point data formats, including both single and double +precision. The FITS programs in DATAIO (section 3.1.1) make use of +this, allowing floating point data to be exchanged in FITS format +without having to convert to type integer. + + +2.2 World coordinate system support + + A major new VOS interface MWCS has been added to support general +world coordinate systems (WCS) and transformations thereon (section +4.2.1). This includes support for linear, piecewise linear or sampled +WCS, and general nonlinear WCS such as the tangent plane or gnomonic +projection. + +If a FITS image is read into the system which has WCS information in the +header, the WCS will be retained in the IRAF image header and can be +used in coordinate transformations. The IMAGES tasks which move pixels +around have been modified to edit the WCS to reflect the transformation +(section 3.1.2). The image i/o system will automatically propagate the +WCS of an image to a new copy of the image, and will edit the WCS as +necessary if an image section is copied (this applies to all IRAF tasks +which operate upon images). The task RIMCURSOR in the LISTS package +has been rewritten to add support for coordinate transformations +(section 3.1.3), and can be used, e.g., to read out the RA and DEC of +objects on the image display using the image cursor, if the image has +the necessary WCS information in the image header. + +Full integration of the new world coordinate facilities into all the +IRAF applications, e.g., the graphics tasks and the spectral reduction +packages, will take a year or longer due to the amount of software +involved. In V2.9 the IRAF spectral packages have not yet been +converted to use MWCS, and if MWCS is enabled it could alter the normal +behavior of these packages. IRAF V2.9 is therefore shipped with MWCS +disabled. What "disabled" means is that WCS information in the image +headers is not edited to reflect operations involving image sections, +or geometric transformations of images. Tasks such as RIMCURSOR which +use an already existing WCS will still work whether or not header +editing is disabled. If the spectral tasks will not be used and it is +desired that world coordinates be propagated correctly in image +transformations, MWCS header editing can be enabled in either of the +following ways. + +The MWCS transformations are disabled by defining the variable "nomwcs" +in the IRAF environment. To globally enable MWCS by default for +everyone using the system, edit the file "hlib$zzsetenv.def" and +comment out the following line as shown (you want to add the leading #, +which will be missing in the distributed version): + + #set nomwcs = yes + +To enable MWCS header editing temporarily, for the current IRAF run: + + cl> reset nomwcs = no + +Detailed information on the coordinate systems defined by MWCS can be +obtained in the online system with the command + + cl> phelp mwcs$MWCS.hlp fi+ + +Additional information is also given in the help page for RIMCURSOR. + + +2.3 IMFORT changes + + The IMFORT interface (host level Fortran or C interface to the IRAF +image format) has undergone the following bug fixes and enhancements: + +o A couple of bugs associated with the IMDIR (image pixel-file + directory) feature introduced in IRAF V2.8 have been fixed. + +o Image clobber checking has been added. By default, if you create a + new image and another image with the same name already exists, the + image create will now return an error code leaving the existing + image unchanged. To override clobber checking in IMFORT programs, + restoring the previous behavior of the interface, define "clobber" + in your host environment. + +o IMFORT will now perform a limited filename translation service + using the IRAF VOS filename translation code. This should allow + most IRAF filenames to be used as input to host level IMFORT + programs. Full VOS filename mapping is not provided, but filenames + containing upper case characters and multiple "." delimited fields + should be translated as in IRAF programs. + +o On systems with multiple architecture support (e.g., Sun, Convex) + the FC task, used to compile and link IMFORT programs from within + the IRAF environment, is now a script rather than a simple foreign + task front end to XC. The purpose of the script is to see that all + the necessary IRAF and host level command line switches and + environment definitions (IRAFARCH, FLOAT_OPTION, etc.) are used. + Previously, users had to make these environment definitions + manually, and if they forgot the IMFORT program could fail to link + or execute. + +o On most UNIX/IRAF systems, the host library -lU77 is now searched + automatically by FC when an IMFORT program is linked. This library + is not used by any of the IRAF code, but is required to link some + Fortran programs that might want to use IMFORT. + +Users are encouraged to use FC to link their IMFORT programs. It is +possible to manually link against the IRAF libraries if you know what +you are doing, but the location of the libraries and the required host +level command line switches vary for different systems and for +different architectures of a single system, and it is easy to make +mistakes. + + +2.4 MKIRAF now copies login.cl to login.cl.OLD + + On UNIX/IRAF systems, the MKIRAF command will now copy any existing +login.cl file to login.cl.OLD, so that, for example, you can more +easily merge any custom changes back in after running MKIRAF. On +VMS/IRAF systems a new file version is created, as before. + + +2.5 Local additions to termcap/graphcap + + The termcap and graphcap device capability files have been +reorganized with a section at the top for local additions. It is +recommended that any locally added entries be made in this area, to +simplify future system updates. The local additions can then be simply +transferred to the new version of the file when a new version of IRAF +is installed (any entries which are modified versions of standard +entries should always be checked to see if anything has changed in the +distributed version). + + +2.6 BIN directories now smaller + + On systems with multiple architecture support, the architecture +save file OBJS.arc stored in the BIN directory for each architecture is +now maintained as a compressed file. In a typical case this reduces +the size of the file by about a factor of two, saving 1-2 Mb of disk +space in each BIN directory. + + +2.7 Various system buffers increased in size + + The layered software support in IRAF V2.8 (extern.pkg and all that) +had a problem with very long helpdb environment strings, limiting the +number of external packages which could be defined. To fix this +problem, various buffers were increased in size all over the system. +The maximum length of an environment variable such as helpdb is now 960 +characters (12 80 character lines of text). String parameters to tasks +can also be larger, and the system is more resistant to problems when +size limits are exceeded. Foreign task commands, OS escapes, etc., can +all be larger now. The current limit on such strings is about 1024 +characters, and is defined at sysgen time by the new system parameter +SZ_COMMAND in hlib$iraf.h. + + +2.8 Shared library versions + + The Sun/IRAF shared library mechanism was modified to add support +for shared library versions. The result is that when you install IRAF +V2.9, which has a different shared library than V2.8, any local +programs or other layered software linked under V2.8 will continue to +run, because both the old V2.8 shared library and the new V2.9 shared +library are included in V2.9 (with different version numbers). +Although old programs will continue to run with V2.9, it is recommended +that they be relinked eventually to take advantage of the many features +and bug fixes provided by V2.9. In the case of very large packages, +e.g., STSDAS 1.0, it may be wise to wait until the latest release can +be obtained and installed before relinking, as the old version will not +have been tested under IRAF V2.9 (which of course, didn't exist back +then). + + +2.9 File pager enhancements + + The system file pager, used in the PAGE task, the new PHELP task, +and other places, has undergone the following enhancements. + +o The N and P keys, used to move to the next or previous file when + paging a list of files, now have a dual meaning: when paging a + single file containing multiple formfeed delimited pages, the keys + will move to the next or previous page in the file. This feature + is used in the new PHELP task to page a large file containing, + e.g., all the HELP pages for a package. + +o A limited upscrolling capability is now supported, e.g., if you hit + the 'k' key while in the pager, the screen will be scrolled up one + line in the file being paged. This feature may not be supported + for some terminals, in which case the entire screen is redrawn at + the new file location. + + +2.10 STF image kernel enhancements + + Extensive work has been done on the STF image kernel in this +release (the STF kernel allows IRAF to access the Space Telescope image +format directly). The changes included the following. + +o Header file caching. STF images often have quite large FITS + headers which can be time consuming to read. A header file caching + scheme is now used to optimize the kernel in cases where the same + imagefile is repeatedly accessed, e.g., when successively reading + each element of a large group format image. By default up to 3 + header files will be cached; this default should be fine for most + applications. If necessary the number of cache slots can be + changed by defining the integer variable "stfcache" in the IRAF + environment (the builtin maximum is 5 cached headers per process). + +o The semantics of the kernel regarding header updates have changed. + STF images differ from other IRAF images in that they may consist + of a group of images all in the same file, with each individual + image having its own header (the group header), plus a single + global FITS header shared by all images in the group. This is no + problem in a read operation, but in a write or update operation + there can be problems since parameters cannot be added to or + deleted from the individual group headers. The new semantics + regarding STF image header updates are as follows: 1) when updating + the header of a multigroup image (not recommended) only the group + header is updated, and attempts to add new parameters are ignored; + 2) when updating the header of an image containing a single group, + both the group header and the FITS header are updated. + + As a result of these changes, the behavior of a single group STF + image is now identical to that of a regular IRAF image. It is + recommended that multigroup STF images be treated as read only if + possible, creating only single group images during interactive + processing (except when running a program that is explicitly + designed to create multigroup images). + +o The kernel was modified to work with the new MWCS (world coordinate + system) interface. The image section transformation is now + performed by MWCS rather than by the STF kernel. + +o A number of minor changes were made to the way the group parameter + block (GPB) cards are maintained in the IRAF image descriptor. The + comments on GPB definition cards are now preserved. Restrictions + on the grouping of GPB cards in the header have been removed. + +o A number of bugs were fixed and restrictions removed, e.g., the + size of a header is no longer limited to 32767 characters (404 + lines). + + The IRAF core system and NOAO science applications were extensively + tested with both single and multigroup STF images using the new + kernel, and we now feel that it is safe to use the STF image format + with these tasks, although the regular format is preferred if there + is no special reason to use the STF format (the regular format is + more efficient). + + +2.11 QPOE (event list image format) enhancements + + The QPOE image kernel, used for event list data (photon counting +detectors, e.g., X-ray satellites such as ROSAT) underwent the +following changes. + +o MWCS (world coordinate system) support has been added (section + 4.2.2). This provides a consistent coordinate system despite, + e.g., the blocking factor, rect, or image section used to construct + an image matrix from an event list. + +o When opening a QPOE file as an IRAF image, the runtime filter + expression used to create the image matrix is now saved in the + parameter QPFILTn in the image header (multiple cards are used for + long expressions). + +o Region masks of arbitrary complexity and size can now be used to + mask the event list when reading time-ordered or unordered + (unindexed) event lists. This is done using the new PLRIO package + (section 4.2.5) which provides the capability to efficiently random + access large image masks of arbitrary complexity. + +o Unmatched brackets, braces, or parentheses are now reported as an + error by the filter expression parser (this can occur even with a + valid expression, e.g., due to truncation of the expression + string). A reference to an undefined keyword, e.g., due to a + spelling error, is now detected and reported as an error. Any + errors occurring during expression parsing will now result in + termination of the calling task, unless caught in an error handler. + +o A number of bugs were fixed. + + +2.12 Changes affecting image display in VMS/IRAF + + A new version of Nigel Sharp's UISDISPLAY program, for image +display on VMS systems running UIS, has been installed in +"iraf$vms/uis". An executable for an early version of the SAOIMAGE +display program for the X window system, written by Mike VanHilst +(SAO), and ported to VMS by Jay Travisano (STScI) has been placed in +the directory "iraf$vms/x11". An executable for a VMS version of XTERM +(the X window terminal emulator, ported to VMS by Stephan Jansen), is +also in this directory. We wanted our VMS users to have access to +these programs, although more development work and testing is needed +before we can offer good support for X window based image display and +graphics on VMS. A more comprehensive package providing enhanced +capabilities should be available as an add-on later this year. + + + +3. IRAF Package Revisions + + The most notable changes to the tasks in the IRAF packages are +summarized below. Further information may be obtained by reading the +help page for each task, or by paging the revisions file for a +particular package. For example, to page the revisions for the DATAIO +package: + + cl> phelp dataio.revisions op=sys + + + +3.1 Changes to the System Packages + + +3.1.1 Modifications to tasks in the DATAIO package + +o The RFITS and WFITS tasks have been modified to add support for the + IEEE floating point format. The "bitpix" parameter in WFITS can be + set to -32 or -64 to specify real or double precision IEEE floating + numbers on output. RFITS recognizes these same values in the + bitpix keyword in the FITS header on input and converts the data + accordingly. Note that this option must be selected by the user as + the defaults for writing a FITS tape have not changed. The user is + cautioned that support for the IEEE floating formats is a new + feature of FITS and may not be supported by all FITS readers. + +o RFITS was modified so that the "iraf_file" parameter can be a list + of output images or a image root name. + + +3.1.2 Modifications to tasks in the IMAGES package + +o MWCS (world coordinate system) support was added to those tasks in + the IMAGES package which change the geometry of an image, i.e., + IMSHIFT, SHIFTLINES, MAGNIFY, IMTRANSPOSE, IMCOPY, BLKREP, BLKAVG, + ROTATE, IMLINTRAN, REGISTER, and GEOTRAN (REGISTER and GEOTRAN only + support simple linear transformations). If one of these tasks is + used to linearly transform an image, the world coordinate system + (WCS) in the image header will be updated to reflect the + transformation. Note that MWCS is disabled by default in IRAF + V2.9, and must be explicitly enabled to allow these tasks to edit + the image header to update the WCS (see section 2.2). + +o The IMSTATISTICS task was modified. The "verbose" parameter was + renamed "format" with the default being set to "yes" (fixed format + with column labels). Otherwise the fields are printed in free + format with 2 blanks separating the fields. The name of the median + field has been changed to "midpt". + +o The IMHISTOGRAM task has a new parameter called "hist_type" that + gives the user the option of plotting the integral, first + derivative, or second derivative of the histogram instead of the + normal histogram. + + +3.1.3 Modifications to tasks in the LISTS package + +o The RIMCURSOR task in the LISTS package was completely rewritten to + add MWCS support, so that coordinates may be output in any user + specified coordinate system defined by the WCS information in the + image header of the reference image. For example, if an image with + a TAN projection WCS is loaded into the image display, RIMCURSOR + may be used to print the right ascension and declination at the + location defined by the image cursor. Refer to the help page for + details. + + +3.1.4 Modifications to tasks in the PLOT package + +o A new graphics kernel task IMDKERN (written by Zolt Levay at STScI) + has been added to the PLOT package. The new graphics kernel allows + the graphics output of any task to be plotted as a graphics overlay + on the image display. As with the other graphics kernels, this may + be done by calling the IMDKERN task directly, but is more often + done by specifying the image display (e.g., device "imd") as the + output device when running a graphics task. Refer to the help page + for details. + +o The CONTOUR task was modified so that it could be used with IMDKERN + to overlay contour plots on the image display. If the parameters + fill=yes and perimeter=no are set the contour plot is scaled to + fill the entire device viewport and all axis and plot labeling is + disabled. If the image being displayed also fills the entire + device viewport (display frame) then the contour plot will be drawn + to the same scale as the displayed image. Refer to the help page + for details. + +o Several tasks in the PLOT package were modified to allow use with + image specifications containing brackets, e.g., group format + images, QPOE filter expressions, and image sections. The tasks + modified were PROW, PROWS, PCOL, PCOLS, SURFACE, and CONTOUR. + +o An option was added to the PVECTOR task to output the vector (cut + through the image at an arbitrary angle and center) as a text file + or image, rather than plotting the vector. + + +3.1.5 Modifications to tasks in the SYSTEM package + +o A new task PHELP (paged help) was added to the SYSTEM package. + PHELP is a script task front end to HELP which collects the output + of HELP in a scratch file and pages it with the system pager, + allowing one to randomly skip around to read the help text. Note + that paging of all the help pages in a package is supported, e.g., + + cl> phelp images.* + + would page all the help files for the IMAGES package. + +o The NEWS task was completely rewritten, and is now used to page the + revisions summary for the current and previous releases. In other + words, one can now type NEWS to find out what is new in the current + release. + +o The GRIPES task was modified to send mail to iraf@noao.edu or + 5355::iraf. The IRAF site administrator may want to check this + script for compatibility with the local mail system. + + +3.2 Glossary of New Tasks in the IRAF System Packages + +Task Package Description + +imdkern plot Image display device (IMD) graphics kernel +news system Summarize what is new in the current release +phelp system Paged HELP: collects and pages the output of HELP +rimcursor lists Read image cursor position in world coordinates + + + +3.3 Changes to the NOAO Packages + + +3.3.1 New NOAO Packages + + A new package ARTDATA, used to generate artificial data, has been +added to the NOAO packages. ARTDATA includes tasks for the generation +of star fields, optionally containing galaxies, and one and two +dimensional spectra as well as simple test pattern images. The tasks +GALLIST and STARLIST provide many options for producing lists of +galaxies or stars that can then be used by the task MKOBJECTS to produce +output images. The tasks MK1DSPEC and MK2DSPEC provide tools for making +artificial spectral data. The task MKNOISE allows the user to add +readout noise, poisson noise and/or cosmic ray events to new or already +existing images. The task MKPATTERN allows the user to make images +from a choice of patterns. + + +3.3.2 Modifications to Existing NOAO Packages + + +3.3.2.1 The ASTUTIL package + +o The task SETAIRMASS in the ASTUTIL package was modified so that it + now precesses the coordinates to the epoch of the observation. + + +3.3.2.2 The DIGIPHOT.APPHOT package + +o A new task APTEST was added to the DIGIPHOT.APPHOT package that + tests the execution of the package. Output files are generated that + the user can review. + +o Two new parameters were added to DATAPARS, "datamin" and "datamax". + Pixels outside this range are rejected from the sky fitting + algorithms and from the non-linear least square fits in FITPSF and + RADPROF. + +o An "update" parameter was added to all of the APPHOT tasks. If the + "verify" parameter is set to "yes" and the task is run in + noninteractive mode update=yes will update the critical parameters + in their respective parameter sets. + +o Four new parameters, "airmass", "xairmass", "filter", and "ifilter", + were added to the DATAPARS task. These parameters provide the user + the option of having the filter and airmass quantities from the + image headers to be carried over into the APPHOT database files for + later transmission to calibration programs. + +o A new algorithm "mean" was added to the sky fitting options. + +o A setup menu mode was added to all the APPHOT tasks. When the user + types "i" in interactive mode a setup menu is presented rather than + a fixed set of predefined commands. + + +3.3.2.3 The IMRED.IRRED package + +o The APSELECT task (from the APPHOT package) has been made visible. + +o The image i/o for IRMOSAIC, IRALIGN, IRMATCH1D, and IRMATCH2D has + been optimized so things should run much faster. There is now an + option to trim each section before insertion into the output + image. The actions of these tasks can now optionally be output to + the terminal. + + +3.3.2.4 The IMRED.MSRED package + +o A task called MSBPLOT was added to the IMRED.MSRED package. This + task allows the user to plot a range of lines in multispec images + in batch mode. + + +3.3.2.5 The ONEDSPEC package + +o Several modifications were made to the ONEDSPEC package. These + changes affect all of the IMRED packages that include these tasks + as well. + +o The equivalent width measurement using the "e" keystroke in SPLOT + is now computed using the ratio of the spectrum to the continuum. + The previous approximation is included in the logfile for + comparison. + +o The DISPERSION task will now add CDi_j (CD matrix) keywords to the + image header as an alternative way of expressing the dispersion + function. If the keywords W0 and WPC or CRVALn and CDELTn are not + in the image header the tasks reading this information for setting + the wavelength (IDENTIFY, SENSFUNC, SPLOT, and SPECPLOT) will look + for the CDi_j keywords. This change should have no affect on the + NOAO applications but provides compatibility with STSDAS + applications using the new MWCS interface provided with IRAF + version 2.9. + +o The call to the CALIBRATE task in the script task BATCHRED was + modified so that the "extinct" parameter is always set to "yes". + Since CALIBRATE checks to be sure the data has not been previously + extinction corrected this simple change provides more flexibility. + + +3.3.2.6 The PROTO package + +o Two new tasks, IMALIGN and IMCENTROID, were added to the package. + IMCENTROID computes a set of relative shifts required to register a + set of images. The task IMALIGN both computes the shifts and + aligns the images. + +o The JOIN task (previously a simple script) has been replaced by a + compiled version which removes many of the restrictions of the + previous version. + +o The IR tasks have been modified as mentioned above under the + IMRED.IRRED section (section 3.3.2.3). + +o The TVMARK task was modified to permit deletion (the "u" key) as + well as addition of objects to the coordinate file. Another cursor + keystroke, the "f" key, was added allowing the user to draw a + filled rectangle. + + +3.3.2.7 The TWODSPEC.LONGSLIT package + +o Tasks in the TWODSPEC.LONGSLIT package that are used for setting + wavelength information (EXTINCTION, FLUXCALIB, and TRANSFORM) were + modified for the CDi_j keywords as outlined above for ONEDSPEC. + + +3.4 Modifications and Additions to Calibration Data + + The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory called +ONEDSTDS in noao$lib. The current contents of this directory are best +summarized by paging through its README file, e.g., + + cl> page noao$lib/onedstds/README + + +A new directory spec50redcal in "noao$lib/onedstds" has been added +containing flux information for standard stars. The data in this list +are from Massey and Gronwall, Ap. J., July 20, 1990. + + +3.5 Glossary of New Tasks in the NOAO Packages + +Task Package Description + +aptest apphot Run basic tests on the apphot package tasks +gallist artdata Make an artificial galaxies list +imalign proto Register and shift a list of images +imcentroid proto Compute relative shifts for a list of images +mk1dspec artdata Make/add artificial 1D spectra +mk2dspec artdata Make/add artificial 2D spectra +mknoise artdata Make/add noise and cosmic rays to 1D/2D images +mkobjects artdata Make/add artificial stars and galaxies to 2D images +mkpattern artdata Make/add patterns to images +msbplot msred Batch plots of multispec spectra using SPLOT +starlist artdata Make an artificial star list + + + +4. Programming Environment Revisions + + +4.1 Changes to the Programming Utilities + + +4.1.1 MKPKG changes + + The MKPKG utility can now substitute the contents of a file back +into the input stream, as a special case of the macro replacement +syntax. For example, the sequence + + abc$(@file)def + +would be translated as + + abc10def + +if the file "file" contained the string "10". The replacement is +performed by inserting the contents of the file back into the input +stream, replacing sequences of newlines, spaces, or tabs by a single +space, and omitting any trailing whitespace. + +The "-p " argument to MKPKG, XC, and so on loads the environment +of the named package pkg, to define the package environment variables, +load the mkpkg special file list, define the directories to be searched +for global include files and libraries, and so on. Multiple "-p" +arguments may be given to load multiple package environments. What is +new is that if pkglibs is defined in the environment of a package to +list the package library directories to be searched (the usual case), +and multiple package environments are loaded, successive redefinitions +of pkglibs will add to the list of directories to be searched, rather +than redefining the old list as each new package environment is +loaded. For example, if two package environments are loaded, and each +defines its own library, both libraries will be searched. + + +4.1.2 Generic preprocessor + + A minor change was made to the generic preprocessor which affects +how strings such as "FOO_PIXEL" are translated. In the usual case, the +preprocessor replaces all occurrences of "PIXEL" by "int", "real", or +whatever the actual datatype is. The translation is now context +sensitive. Rather than translating "FOO_PIXEL" as "FOO_int" (e.g., +"MII_PIXEL" -> "MII_int"), the type name will now be output in upper +case if the rest of the name in which it occurs is upper case. Hence, +a string such as "MII_PIXEL" will now be translated as "MII_INT". This +allows the use of generic constructs to symbolize SPP macros. + + +4.1.3 SPP changes + + The language constant ARB, formerly defined as 32767, is now treated +differently depending upon how it is used. In a declaration of an array +argument, ARB is replaced in the output Fortran by a "*", e.g., "int +data[ARB]" becomes "INTEGER DATA(*)". In an executable statement, ARB +is replaced by a very large ("arbitrarily" large) integer value, e.g., +to define a DO-loop which is to loop an arbitrary number of times. If +ARB is mistakenly used to dimension an array which is a local variable +rather than an argument, the SPP translator will now detect and report +the error. + + +4.1.4 Interactive development and the process cache + + Whenever a CL task is run and the process containing the task is +already idling in the CL process cache, the CL will now check to see if +the modify date on the process executable has changed, and restart the +process if the executable has been modified. For example, when doing +software development from within the CL and a process is alternately +relinked and tested, the CL will now automatically detect that the +process has been relinked and will run the new process, without any +need to manually flush the process cache. + + +4.2 Programming Interface Changes + + +4.2.1 New MWCS interface (world coordinate system support) + + A major new VOS interface MWCS, providing general facilities for +linear and nonlinear world coordinate systems, has been added to the +programming environment and is used in IRAF V2.9 in IMIO, IMAGES, and +other parts of the system. MWCS is intended for use in scientific +applications as well as in system code such as IMIO, hence is of +potential interest to anyone developing software within the IRAF +environment. The source directory is "mwcs" and the interface is +documented in the file "mwcs$MWCS.hlp". Users should be aware that, +although the new interface addresses the general WCS problem and has +been carefully designed, a second version of the interface is planned +and the current interface is not yet a "frozen" interface. + + +4.2.2 QPOE interface changes + + The QPOE (event list image) interface has been extended to add +routines to store MWCS objects in the QPOE header. By default, there +is one MWCS per QPOE file, stored encoded in a machine independent +binary format in a variable length array qpwcs of type opaque. The new +routines are as follows: + + mw = qp_loadwcs (qp) + qp_savewcs (qp, mw) + mw = qpio_loadwcs (io) + +The routines qp_savewcs and qp_loadwcs merely save a MWCS in the QPOE +header, or load a previously saved one. The QPIO (event i/o) routine +qpio_loadwcs is like qp_loadwcs, except that it will also modify the +Lterm of the MWCS to reflect any blocking factor or "rect" specified in +the filtering expression when the event list was opened. The new +routine is called automatically by QPF and IMIO whenever a QPOE event +list is opened under image i/o, making the physical coordinate system +of the image matrix the same as physical event coordinates. + +The calling sequences of the qp_add and qp_astr routines, used to +conditionally add or update header parameters, have been changed (so far +as we could determine very few programs exist yet which use these +routines, so we decided to risk an interface change). The change made +was to add a comment argument. This change was motivated by the +observation that people would not use the routines but would instead +use lower level routines, in order to be able to set the comment field +if the parameter has to be added to the header. + + +4.2.3 IEEE support routines added + + Routines for IEEE floating to native floating conversions have been +added to the MII and OSB interfaces. The new MII routines are as +follows: + + nelem = miiread[rd] (fd, spp, maxelem) + miiwrite[rd] (fd, spp, nelem) + miipak[rd] (spp, mii, nelems, spp_datatype) + miiupk[rd] (mii, spp, nelems, spp_datatype) + +The miiread and miiwrite routines are like their FIO counterparts, +except that they are used only with data of the indicated type, and +perform the IEEE to native floating conversion (or vice versa) as part +of the i/o operation. The miipak and miiupk routines pack +(native->IEEE) and unpack (IEEE->native) arrays of the indicated type. + +The lowest level conversion routines are the OSB routines, which are +what the MII routines use to perform the lowest level translation. + + ieepak[rd] (datum) + ieeupk[rd] (datum) + ieevpak[rd] (native, ieee, nelem) + ieevupk[rd] (ieee, native, nelem) + iee[sg]nan[rd] (NaN) + +The ieepak and ieeupk routines transform a single scalar value in +place, while the ieevpak and ieevupk routines transform vectors (note +that the package prefix is "iee", not "ieee"). In-place vector +conversions are permitted. Since IRAF does not support the IEEE +not-a-number formats, NaN, Inf etc. values are converted to a legal +native floating value on input. The native floating value to which +NaNs are mapped (default zero) may be globally set with ieesnan. + +On some systems, e.g., the VAX, the low level conversion routines may be +written in assembler or machine dependent C. If so, the source file +actually used by the system will be found in the "host$as" directory. + + +4.2.4 New routine GETLLINE added to FIO + + A new routine getlline (get long line) has been added to FIO. This +is similar to getline, except that it will reconstruct arbitrarily long +newline delimited lines of text, whereas getline returns at most +SZ_LINE characters. + + nchars = getlline (fd, outstr, maxch) + +The new routine should not be confused with the old routine getlongline, +a higher level routine which performs a similar function, but which +also ignores comment lines and help blocks, and maintains a line +counter. + + +4.2.5 Modifications to PLIO/PMIO + + A new routine p[lm]_sectnotconst has been added to PLIO and PMIO +(the pixel list and image mask interfaces). As the name suggests, the +routine tests whether a given rectangular section of the mask is all at +the same value, and if so returns the mask value as an output argument. + + bool = pl_sectnotconst (pl_src, v1, v2, ndim, mval) + +A new subpackage PLRIO has been added. This is used to efficiently +random access any 2D plane of an existing pixel list or image mask. + + plr = plr_open (pl, plane, buflimit) + plr_setrect (plr, x1,y1, x2,y2) + mval = plr_getpix (plr, x, y) + plr_getlut (plr, bufp, xsize,ysize, xblock,yblock) + plr_close (plr) + +The mask is opened for random access on a special descriptor which +incorporates a scaled, active 2D lookup table. Most subsequent +plr_getpix calls will return the given mask value directly from the +table with very little overhead; only if the referenced pixel occurs in +a region too complex to be described by a single table entry is the +value computed by direct evaluation of the mask. A special 2D binary +recursive algorithm (using pl_sectnotconst above) with log2(N) +performance is used to calculate the scaled lookup table. These +algorithms provide efficient table generation and random mask pixel +access even for very large masks. + IRAF (Mar90) V2.8 Revisions IRAF (Mar90) + + + IRAF Version 2.8 Revisions Summary + June 30, 1989 + + + + +1. Introduction + + This revisions notice coincides with the release of version 2.8 of +IRAF. The V2.8 release is a general release for all supported IRAF +hosts. + +The following is a brief description of some of the new features +available in IRAF Version 2.8. This is not intended to be an +exhaustive list, but rather a brief summary of the major changes since +the last major release of IRAF Version 2.5 in July 1987 and subsequent +intermediate releases primarily to support Sun/IRAF: IRAF Version 2.6 +(February 1988), IRAF Version 2.6+ (March 1988), and IRAF Version 2.7 +(December 1988). + +More detailed revisions notes are available in the system notes files in +the iraf$doc and iraf$local directories, as well as in the online +revisions notes for the various packages. + + + +2. IRAF System Revisions + + This document highlights the most notable revisions made to the +IRAF core system software for Version 2.8. This is only a revisions +summary; no attempt is made to provide detailed technical documentation +for each revision, nor is there any attempt to exhaustively summarize +all revisions. A complete record of all core system revisions will be +found in the System Notes for V2.8. Additional information on some of +the topics covered below will be found in the various Installation +Guides and Site Manager's Guides, and in the IRAF User and Technical +Documentation manual sets. + + + +2.1 Copyright notice + + Subject to AURA and NSF approval, the IRAF software will be +copyrighted sometime during 1989. As a first step in this process, a +copyright notice has been added to all core system source files. The +notice reads as follows: "Copyright(c) 1986 Association of Universities +for Research in Astronomy Inc". We will also be adding a file called +COPYRIGHT to the distribution stating the terms of the copyright and +associated licensing agreement for the software. + +The intent of this action is solely to protect the software from +unauthorized commercial exploitation, and the copyright grants, or will +grant, the right to copy, modify, and redistribute the IRAF software +provided the original copyright notice remains intact, the software is +made available in source form, and the rights we grant are passed on +with the software. We wish to prevent others, especially commercial +firms, from copyrighting IRAF software in their own name and possibly +taking away the rights we grant with the software. Granting the right +to modify and redistribute IRAF software does not mean we want to +encourage people to do so, we merely want them to have the legal right +to do so if they feel they need to. + + + +2.2 Major system enhancements + + The information in this section is provided primarily for the +benefit of IRAF site managers and programmers. The reader interested +primarily in science applications may wish to skip ahead. Some systems +level familiarity with the current IRAF system is assumed. + + +2.2.1 Layered software enhancements + + A given IRAF installation consists of the core IRAF system, and any +number of layered software products or external packages. The goal of +the layered software enhancements introduced in V2.8 is to make layered +software products self contained and hence independent of the core +system and of other layered software. Examples of layered software +products are the NOAO packages, LOCAL, STSDAS, PROS, and so on. + +The layered software enhancements make it possible to install or +deinstall a layered product by modifying only a single file in the core +IRAF system. The core system may be updated without affecting layered +software, and vice versa. Since layered products are independent and +are simple to install, IRAF can easily be configured with only those +packages needed at a particular site. Software developers benefit from +the layered software enhancements because the facilities provided for +development and maintenance of layered software are equivalent to those +provided for development of the core IRAF system and the NOAO +packages. User sites benefit because it is easy to extend the system +with LOCAL packages of their own making. + +Each layered product (usually this refers to a tree of packages) is a +system in itself, similar in structure to the core IRAF system. Hence, +there is a LIB (global system library), one or more BINs (binary file +directories), a Help database, a set of global environment definitions, +and all the sources and runtime files, all contained within the same +directory tree. Layered software products, in their source only form, +are portable without change to any computer which runs IRAF. + + +2.2.1.1 The hlib$extern.pkg file + + This is the file which is modified to install or deinstall layered +software products. To install a layered product, one creates a +directory to hold the software, restores the files to disk, and edits +the extern.pkg file to tell IRAF the name of the root package of the +layered product, and where the root directory is located. If the +layered software is distributed in source only form it will also be +necessary to recompile the software, but this is a completely automated +process. + + +2.2.1.2 NOAO and LOCAL packages reorganized + + As part of the project to better support layered software, the NOAO +and LOCAL packages have been reorganized as layered products. These +packages are now structurally equivalent to third party (non-NOAO) +packages, except that the directory trees are rooted in IRAF. Both +packages are now self contained, with their own LIB, BINs, Help +database, etc., and with an entry in extern.pkg, like other layered +products. The NOAO package serves as a working example of how to +configure a layered package. The reorganization of these packages +should be transparent to anyone merely using the system. + + +2.2.1.3 The template LOCAL + + The LOCAL package included with the distributed system has been +stripped of all NOAO site-local tasks and restructured as a layered +product, the template local. The template local contains only two +sample tasks and is not intended as an end-user package, but rather as +a template to be copied and modified by sites to construct their own +site dependent LOCAL package. The desire to be able to easily develop +and maintain locally added packages was one of the major motivations +for the layered software enhancements project, and we hope that sites +will realize the significance of this new capability and take advantage +of it. + + +2.2.1.4 CL now supports package level BIN directories + + Rather than assuming a global BIN directory for all tasks and +packages, the CL now permits multiple BIN directories, each BIN +directory being associated with the package of definition and all +subpackages of that package (unless they have their own BIN). A new +BIN directory is declared with the optional argument bindir=path in the +package statement, e.g., in a package script task. + + +2.2.1.5 MKPKG support for package environments + + Layered packages now have their own private LIB, including an +environment definitions file (zzsetenv.def), mkpkg global include file +(mkpkg.inc), and, optionally, a mkpkg special file list file for each +supported host system, listing files requiring special compilation to +work around host compiler bugs or whatever. The full mkpkg environment +is formed by reading the IRAF core system environment and mkpkg +definitions and include files, followed by the package definitions and +include files. Reading of the package environment occurs only if mkpkg +is called with the "-p" flag, or if the variable PKGENV is defined in +the user's environment. + +Another way of expressing this is, when using mkpkg within a layered +package, one must now specify the name of the layered package in order +to pick up the package environment definitions. For example, to update +the MTLOCAL package in NOAO, one would type "mkpkg -p noao update" in +the mtlocal directory. If this is not done compilation errors may +result, or the exectable may not be successfully installed in the +package BIN directory. + + +2.2.2 Multiple architecture support + + A single IRAF system (or layered package) can now simultaneously +support any number of machine architectures using multiple BIN +directories sharing a single machine independent copy of IRAF. Each +BIN directory contains all the object modules, object libraries, and +executables for a particular architecture. An architecture can +represent either a type of hardware, e.g., sparc, mc68020+f68881, +mc68020+ffpa, vax, etc., or a software distinction, e.g., systems +compiled with different sets of compiler flags, or different versions +of a system. Multiple architectures are now supported both for IRAF +execution, and for IRAF based software development, e.g., a single +version of IRAF can now be used to develop and run IMFORT programs on +both Sun-3 and Sun-4 nodes. + +The only case where multiple architecture support is used at the present +time is in Sun/IRAF, which is often installed on a heterogeneous +network of workstations, e.g., Sun-3s with various hardware floating +point options, and Sun-4s. A single copy of IRAF will be configured +with several BIN directories, one for each supported architecture, and +NFS mounted on all the network nodes which will be using IRAF. There +is no reason that this feature need be restricted to use with Sun/IRAF, +however. + + +2.2.2.1 IRAFBIN and IRAFARCH + + Starting with IRAF V2.8, the old environment variable IRAFBIN has +been obsoleted and replaced by IRAFARCH. On machines which support +multiple architectures, the latter defines the architecture to be used +for both IRAF execution and software development. If only IRAF +execution is needed the variable is optional, with the best +architecture being selected automatically when the CL is started. If +one will be doing software development (including IMFORT) it is best to +define the variable in the host environment before starting IRAF or +doing any host level software development. Typical values of IRAFARCH +for a Sun workstation are "sparc", "i386", "f68881", and "ffpa". + + +2.2.2.2 System libraries moved to the BIN directory + + As part of the revisions required for multiple architecture support +for software development, all object libraries have been moved from the +global, architecture independent LIB to the architecture dependent BIN, +with the LIB entries being replaced by symbolic links (in the case of +Sun/IRAF). This should be transparent to both end users and +programmers. + + +2.2.2.3 New bin.generic architecture + + On Sun/IRAF systems, which are distributed configured for multiple +architecture support, the system architecture is set to generic in the +distributed system. What this means is that all architecture dependent +files (objects and object libraries) have been removed from the system +directories and archived in the file OBJS.arc in the BIN directory for +each architecture. Rebuilding any of the packages in a system would +require restoring the binaries for a particular architecture, e.g., +typing "mkpkg sparc" at the IRAF root would restore the sparc binaries +for the core system on a Sun/IRAF installation. Note that this only +affects software development for the system in question; software +development for external packages or private user software is not +affected. + + +2.2.3 Shared library facility + + IRAF version 2.8 adds support for a general shared library facility +for UNIX based systems. Although currently only used with Sun/IRAF, +this facility is potentially useful for other UNIX based IRAF systems +as well (VMS/IRAF already has its own shared library facility). + +What the shared library facility does is take most of the IRAF system +software (currently the contents of the ex, sys, vops, and os +libraries) and link it together into a special sharable image, the file +S.e in each core system BIN directory. This file is mapped into the +virtual memory of each IRAF process at process startup time. Since the +shared image is shared by all IRAF processes, each process uses less +physical memory, and the process pagein time is reduced, speeding +process execution. Likewise, since the subroutines forming the shared +image are no longer linked into each individual process executable, +substantial disk space is saved for the BIN directories. Link time is +correspondingly reduced, speeding software development. + +With the introduction of the shared library facility, the disk space +required for Sun/IRAF is substantially reduced. Due to the increased +memory sharing and reduced process pagein times performance is +substantially improved, especially on systems like the Sun/386i which +has a relatively slow SCSI disk and often limited memory. The disk +size of small programs is reduced by up to a factor of ten in some +cases, e.g., an executable for a small program that was formerly 250 Kb +in size might be as small as 25 Kb if the shared library is used and +the shared image symbols are omitted at link time. + + + +2.3 User interface changes + + +2.3.1 Calling IRAF tasks from the host environment + + The IRAF main and zmain were modified to make it easier to call +IRAF tasks as host level tasks, i.e., without having to set up a +command file and run the process with the standard input redirected. +In the new scheme, any extra arguments given on the process command +line are passed into the IRAF main as a command buffer containing the +IRAF command or commands to be run. For example, + + cl> x_system.e netstatus + +would run the command netstatus in process x_system.e. + + cl> x_system.e count "files=*.x" + +would run the count task, counting all ".x" files in the current +directory. + + cl> x_system.e count "files=*.x 4>_o" + +would do the same, redirecting the output at the IRAF main level to the +file _o. + + cl> x_system.e 'directory @pars $nargs=0' + +would run the directory task with the given parameter set, with $nargs +set to 0. If any of the parameters to a task are omitted the task will +query the terminal for them in the usual way, so for example + + cl> alias count "$iraf/bin/x_system.e count files=" + +would make the IRAF task count available in UNIX, allowing the IRAF +template specifying the files to be counted to be either given on the +UNIX command line, or prompted for if omitted. Given the above alias, +one could enter a UNIX command such as + + cl> count 'cl$*.h' + + +This feature is available in all UNIX based versions of IRAF V2.8, but +did not make it into VMS/IRAF version 2.8. + + +2.3.2 Image packing density control (impkden) + + Some users have complained about images taking up more disk space +than they have to, due to the IMIO feature which conditionally blocks +image lines to fill an integral number of disk blocks. This can result +in more efficient image i/o but can also make a significant difference +in the amount of disk space consumed by an image in some cases. + +IMIO can actually support both block-aligned and fully packed images. +The decision is made at image creation time and is based on the image +packing density if image lines are block aligned. If the packing +density is too low for a block-aligned image, a fully packed image is +created to avoid wasting disk space. The default minimum packing +density is 0.6, i.e., up to 40% wasted space before IMIO switches to +full packing (no wasted space). + +For finer control over the packing density, the user can now specify the +optional environment variable impkden, the numeric value being the +mininum packing density. For example, + + cl> set impkden = 1.0 + +would completely disable block-alignment of image lines in IMIO. + + +2.3.3 User libraries (IRAFULIB) + + It is now possible for the programmer (SPP or IMFORT) to specify a +private directory to be searched at compile or link time when +developing IRAF or IMFORT programs. This is done by defining the path +to the directory in the user environment as the variable IRAFULIB. +When locating a particular file, this directory will be searched before +the IRAF system libraries are searched, hence this feature may be used +to substitute custom versions of files in the IRAF system libraries, +e.g., for debugging purposes. + + +2.3.4 New logical printer device LPR + + A new logical line printer or plotter device lpr is now supported on +all UNIX/IRAF systems. This treats the UNIX task lpr as a kind of +pseudo-device, leaving it up to UNIX to decide what physical device to +dispose of the output to. This default is system dependent, but on +some systems can be controlled by defining the variable PRINTER in the +user environment. + + +2.3.5 Machine independent help database + + The IRAF help task uses a precompiled binary database to speed help +keyword searching. This file is now machine independent, allowing it +to be generated on one system and included in software distributions +without having to be recompiled. In addition, as part of the layered +software support, help now allows each external package to have its own +private help database. The first time help is run, all such databases +are read and linked to produce a database containing entries for all +help modules in the core system and all installed external packages. +The help database file is the file helpdb.mip in the LIB directory of +the core system and each external package. + + +2.3.6 Set terminal type will no longer hangup + + On systems, e.g., workstations, which provide virtual terminal +windows which can change in size, IRAF may query the terminal at run +time to determine the screen size. This query is performed, for +example, at login time if the terminal type is set to gterm or sun. +Formerly this could cause the login process to hang indefinitely (i.e., +until the user typed return or interrupt) if the terminal did not +respond to the size query, as would happen when the terminal type was +set improperly and the actual terminal ignored the query. Thanks to +the addition of non-blocking raw terminal i/o in V2.8 IRAF, the +terminal screen size query will now time out with a warning message to +reset the terminal type, if the terminal does not respond to the query +within several seconds. + + +2.3.7 Installing a new version of IRAF obsoletes old user parameter files + + The problem of old, obsolete user (uparm) parameter files being +used with a newly installed version of IRAF, which could lead to +"parameter not found" error aborts, has been fixed. The CL now checks +the date of the file utime in HLIB, and refuses to use the user pfile +if it is older than either utime or the package pfile provided with the +new system. The contents of old user pfiles are merged into the new +system pfile, as before, preserving learned parameter values even when +the user pfile is obsolete. + + +2.3.8 @file list bug fixed + + The problem of the "@file" (at-file-list) syntax not working when +the file in question was not in the current directory has been fixed. + + + +2.4 Programming interface changes + + +2.4.1 IMFORT pixel directory control + + IMFORT has been modified to permit specification of the pixel file +directory by the calling program. The modifications are completely +upwards compatible, i.e., existing programs linked with the new +interface will still create pixel files in the same directory as the +header file, with "HDR$" in the image header. + +The Fortran programmer may set or query the pixel file directory using +the following routines: + + imsdir (dir) # set pixel directory pathname + imgdir (dir) # get pixel directory pathname + +where dir is a Fortran character variable. The value should be either +"HDR$" (the default) or a concatenatable host directory pathname (i.e., +trailing / required for unix). Once set, the pixel directory will be +used for all subsequent image create or rename operations by the +calling process. + +For example, + + call imsdir ("/tmp3/pixels/") + call imcrea (image1, axlen, naxis, dtype, ier) + call imcrea (image2, axlen, naxis, dtype, ier) + +If desired the default pixel directory may be specified in the host +environment as imdir or IMDIR before running the program. IMFORT will +check the host environment for this environment variable then use +"HDR$" as the default if no host definition is found. + +Note that although this is similar to setting the value of imdir in the +IRAF environment, IMFORT programs are not part of the IRAF environment +and are not affected by changes to the IRAF imdir. Also, since IMFORT +is a host level facility and IRAF networking is not supported, the +network prefix (e.g., "node!") is omitted from the pixelfile pathname, +and since IMFORT programs are not necessarily used in conjunction with +IRAF, the ".." (hidden file protection) files are not used to protect +against image deletion. + + +2.4.2 Image display interface: IMD + + A new interface IMD has been added to provide a rudimentary +facility for interactive image display device control. This is an +interim prototype interface which will be replaced by the new display +interfaces when the latter become available. + +The IMD interface operates by mapping an image display device frame +buffer onto an IMIO image descriptor. The display frame buffer may +then be randomly edited by normal image i/o operations, e.g., to modify +subrasters of the displayed image, or overlay the image with color +graphics. The image pixel to display frame buffer coordinate +transformation is supported, allowing applications to work in image +pixel coordinates if desired. This interim interface is what is used +by the new display oriented tasks imexamine, imedit, and tvmark. + + +2.4.3 Image masks: PLIO, PMIO, MIO + + The following new VOS interfaces have been added in V2.8 to provide +a general boolean or integer image mask facility. + + PLIO pixel list i/o + PMIO pixel (image) mask i/o + MIO masked image i/o (image i/o through a mask) + + +PLIO is a general interface for storing and manipulating +multidimensional integer valued rasters containing regions of constant +value (i.e., masks). The masks are stored in a highly compressed form, +the size of the compressed mask being a function of the information +content of the mask. Both pixel array and range list i/o facilities +are provided, as well as a set of general boolean raster operators, +e.g., to extract or insert subrasters, AND or OR a source with a +destination, do the same through a stencil, draw regions of various +kinds (point, line, box, circle, polygon), and so on. See the PLIO.hlp +file in the PLIO source directory for further information. + +An interactive debug program (plio$zzdebug.x) is provided for +experimenting with masks. Note that PLIO is a stand alone interface +and is not tied in any way to IMIO, even though the data structure +operated upon is similar to an image matrix. + +PMIO is very similar to PLIO except that it is used to associate a +masks with an IMIO maintained reference image. Currently, the PMIO +mask must be the same resolution as the physical reference image. All +coordinates input to PMIO are in the image section coordinates of the +reference image. Hence, given a physical image and associated mask, +one can operate upon both through a user specified image section +transparently to the applications program. This includes all PLIO +style boolean rasterop operations, as well as mask pixel and range list +i/o. The PMIO interface is layered upon PLIO and IMIO, and the calling +sequences are identical with PLIO except for the package prefix, and +the addition of several new PMIO specific routines. + +MIO is essentially an extension of image i/o for pixel i/o through a +mask. The central routines are the following: + + mio_setrange (mp, vs, ve, ndim) + n|EOF = mio_[gp]lseg[silrdx] (mp, ptr, mval, v, npix) + +One defines a rectangular region of the image with mio_setrange, and +then sequentially reads or writes line segments until all pixels +visible through the mask have been accessed. This type of i/o should +be ideal for most image processing applications which need to operate +upon only those pixels visible through a region mask (e.g., a surface +fitting task), upon all pixels except those on a bad pixel mask (e.g., +any analysis program), and so on. + +PLIO (or PMIO) masks may be stored in binary files on disk, the files +having the extension ".pl". The V2.8 version of IMIO has the +capability to treat such masks as if they were images, allowing masks +to be easily displayed, used in image expressions, converted to image +matrices and vice versa, etc. Applications may do either pixel or +range list i/o to a mask image via IMIO, if MIO is not suitable for +some reason. + + +2.4.4 Photon images: QPOE, QPIO, QPEX + + A new set of VOS interfaces supporting photon or event list data +are now available. The QPOE interface implements the Position Ordered +Event list object, which consists of a general header mechanism plus an +event list, wherein the events are little data structures, e.g., the +attributes required to describe a photon detection (position, energy, +time, etc.). QPOE is designed to efficiently access very large event +lists, e.g., several hundred thousand or several million events in size. +Builtin event attribute filtering and region filtering capabilities are +provided for selecting photons from the event list. These filtering +capabilities may be combined with the sampling capability to produce +filtered, block averaged image matrices from event lists. + +The QPOE interfaces are the following: + + QPOE header and file access and management facilities + QPIO raw and filtered event i/o + QPEX event attribute filter mechanism + QPF IMIO/IKI kernel for image interface to QPOE files + +QPOE and QPF add a new image type to the system, with .qp file +extension. Hence, event list data can be used as input to any of the +image processing tasks in standard IRAF, in addition to being analyzed +by tasks which deal with the individual photon events. A QPOE image is +contained in a single file. When a QPOE file is accessed as an image +the interface filters and samples the event list in real time, using a +user defined filter, block averaging factor, region mask, and so on, +producing the image matrix seen by applications at the IMIO level. The +QPOE object may be repeatedly examined with different event filters to +view the data in different ways. + +The QPOE interface, in addition to providing an event list capability +for IRAF, serves as a prototype for the "flex-header" portion of the +new image structures project. Many of the capabilities to be provided +for image storage under the new image structures are already present in +QPOE. + +Further information is given in the QPOE.hlp file in the QPOE source +directory. + + +2.4.5 File manager: FMIO + + A new VOS library FMIO has been installed. FMIO is "File Manager +I/O", and is used to implement a simple binary file manager which +maintains the file data of so-called "lfiles" (lightweight files) +inside a single host binary file. The system overhead for accessing +lfiles is much less than that of host files, and many lfiles can be +used to store a complex data structure without cluttering a host +directory or incurring the inefficiency of accessing host files. FMIO +is part of the DFIO project and will serve as the lowest level +interface within DFIO; it is also used currently in the QPOE +interface. Additional information is given in the README file in the +source directory for the interface. + + +2.4.6 IMIO changes + + IMIO is the image i/o interface, the standard IRAF VOS interface +for managing all varieties of image data. + + +2.4.6.1 Mask image support + + IMIO now supports a new type of image, the mask image, stored as a +highly compressed binary (PLIO) file with the extension ".pl". Image +masks are most commonly used to store information describing selected +pixels in an associated data image. An image mask is logically a +boolean or integer image, up to 28 bits deep, containing information +only on selected pixels or regions of pixels. Masks are stored in +highly compressed format, e.g., a simple mask may be stored in only a +few hundred bytes of space. Mask images are readable, writable, and +randomly modifiable, like ordinary raster images. See \(sc2.4.3 for +more information. + + +2.4.6.2 Photon image support + + Support has also been added to IMIO for event list images, stored +as position ordered event list datafiles using the QPOE interfaces. +This new image type has the extension ".qp". QPOE images are read-only +under IMIO. Subject to that restriction, they may be accessed like any +other image by any IRAF image analysis program. Accessing an event +list image as a raster image necessarily involves a runtime sampling +operation, wherein the events in the region of interest are accumulated +into an initially zero image matrix; in the process the event list may +optionally be filtered by event attribute or event position, e.g., + + cl> display "xray.qp[t=(30:40),pha=10,block=4]" + +would display the QPOE image xray.qp with a blocking factor of 4, +selecting only those events with t (time) in the range 30 to 40 and for +which pha (energy) has the value 10. The event attributes and their +names are user definable and may vary for different types of data. See +\(sc2.4.4 for more information. + + +2.4.6.3 IMPUTH + + A new procedure imputh has been added to the IMIO header access +library. The new procedure is used to append FITS like HISTORY or +COMMENT cards to the image header. + + +2.4.6.4 IMPARSE + + The calling sequence of the internal IMIO procedure imparse has +changed. Although this procedure is internal to the IMIO interface and +is not supposed to be used within applications, there may be +applications which make use of this procedure. Any such applications +must be modified to reflect the new procedure calling sequence or +runtime problems are guaranteed. + + +2.4.7 Null string environment variables + + The semantics of the VOS procedures envgets and envfind have +changed. This could affect existing programs and any programs which +use these functions should be checked to make certain they will still +work properly. + +These procedures, used to fetch the string values of environment +variables, return the length of the output string as the function value. +Formerly, a value of zero would be returned both when the named +variable existed but had a null string value, and when the variable was +not found. This made it impossible to discriminate between the case of +a variable not being defined, and one which is defined but has a null +value. The routines have been changed to return the value ERR (a +negative integer) if the variable is not defined. Programs which do not +wish to make the distinction between undefined and null-valued should +check for a function value less than or equal to zero. Programs which +check for a function value equal to zero will fail if the named +variable is not defined. + + +2.4.8 Environment substitution in filenames + + The VOS filename mapping code has been modified to add support a +powerful new environment substitution syntax. Previously the only +environment substitution mechanism available was the logical directory +facility, which could only be used to parameterize the directory +field. The new facility may be used to perform environment +substitution anywhere in a filename. This is used in IRAF version 2.8 +to implement multiple architecture support, e.g., + + cl> set bin = "iraf$bin(arch)/" + +is how the core system BIN is defined in V2.8 IRAF. The syntax +"(arch)" tells the filename mapping code to substitute the string value +of the environment variable arch, if defined. If the variable is not +defined the null string is substituted. Hence, if the host system does +not implement multiple architecture support and arch is not defined, +BIN is defined as "iraf$bin/", which is the backwards compatible +definition. If arch is defined as, e.g., ".vax", then BIN is defined +as "iraf$bin.vax/". The new feature allows use of a single environment +variable to define the architecture, not only to form filenames, but +for other purposes as well, e.g., to generate compiler switches or to +control library searching in mkpkg. + + +2.4.9 Nonblocking raw terminal i/o + + The VOS file i/o interfaces have been modified to add support for +nonblocking terminal i/o. This facility makes it possible to, in +effect, "poll" the terminal to see if there is any input waiting to be +read, to allow interaction without having a program block if the user +has not typed anything. + +The immediate application of this in version 2.8 was the modification +of the stty (set-terminal) facility to implement a time out for the +terminal size query. Formerly, stty would hang up indefinitely when +the terminal type was set to "gterm" but the actual terminal was +something different, causing the screen size query to be ignored. + +In the more general case, nonblocking terminal i/o makes possible a new +class of user interface, which is not only interactive, but event +driven. Nonblocking i/o makes it possible for an application to be +continually processing, while checking the terminal occasionally to see +if the user has input any commands. + +At present, nonblocking i/o is always used in conjunction with raw mode +input from a terminal. A new flag F_NDELAY, defined in , is +used to enable or disable nonblocking i/o. For example, + + call fseti (fd, F_RAW, YES) + +enables conventional blocking, single character raw mode reads, and + + call fseti (fd, F_RAW, YES + F_NDELAY) + +enables nonblocking raw mode input (YES, NO, and F_NDELAY are bit +flags). These modes are mutually exclusive, e.g., the first call may +be issued while nonblocking raw mode is in effect to make the reads +block, and vice versa. A call to fset(fd,F_RAW,NO) disables both raw +mode and nonblocking mode. Once nonblocking raw mode is in effect one +merely reads characters from the terminal in the usual way, using +getc. EOF is returned if a read is performed when no data is available +for input, otherwise the next character is returned from the input +queue. Further information on nonblocking i/o is given in the system +notes file. + + +2.4.10 Function call tables (ZFUNC) + + IRAF has always had the ability to compute the integer valued +address of a procedure, store that address in a table, and later use +the address as an argument to one of the zcall kernel primitives to +call the addressed procedure. This facility has been extended by the +addition of a set of zfunc primitives, used to call integer valued +functions. Only integer valued functions are supported (in order to +simplify the kernel support required), but in the systems oriented +applications where procedure call tables are used, this is unlikely to +be a serious limitation. + + + +2.5 Sun/IRAF specific revisions + + +2.5.1 IEEE exception handling + + By default the IEEE hardware is now configured, on all Sun systems, +with the invalid, overflow, and divide by zero IEEE exceptions enabled, +and with the default rounding direction and precision modes (nearest, +extended) in effect. This configuration should ensure that all +questionable floating point operations are detected, and that no IEEE +"funny numbers" (NaN, Inf, etc.) get into the data. These values, +since they don't behave like ordinary numbers, can cause programs to +misbehave, e.g., go into an infinite loop. In Sun/IRAF V2.8, if a +computation results in an IEEE funny number being generated, an +exception abort will result. The most common example is divide by zero. + +The IRAF/IEEE interface offers a special debug feature that may be of +interest to programmers developing numerically sensitive software. If +desired, one can change the default rounding direction and precision +(e.g., to test the numerical stability of applications) by using the +debugger to set a nonzero value of the variable debug_ieee before +running an executable. The procedure for doing this is documented in +the system notes file. + + +2.5.2 IMTOOL enhancements + + A number of enhancements and bug fixes have been made for V2.8 to +the SunView based IMTOOL image display server. The most notable +changes are summarized here; refer to the IMTOOL manual page for a more +complete description of the new features. + + +2.5.2.1 Software ZOOM added + + IMTOOL, which has had for some time the ability to pan about on a +large image, now has the ability to zoom as well. Both pan and zoom +are controlled very conveniently by the middle mouse button: place the +mouse on an object and tape the middle button once to pan the object to +the center of the display window; tap it again and the image will be +zoomed. Zoom, currently implemented by writing directly into the +hardware frame buffer, is very fast, almost as fast as a normal +unzoomed window refresh. The default set of zoom factors is 1,2,4,8 +after which the sequence wraps around to 1. The zoom factors are user +configurable via the IMTOOL setup panel; very large zoom factors, e.g., +x64, are possible. Dezoom (making a large image smaller) is not +currently supported. + + +2.5.2.2 WCSDIR eliminated + + The host level WCSDIR environment variable, and the text file used +to communicate image coordinate (WCS) information between the display +task and the display server, have been eliminated. All WCS information +is now passed via the datastream used to pass commands and data between +the client and the display server. This eliminates the need for users +to have to remember to define WCSDIR in order to get coordinates in +image units, and some subtle process synchronization problems are +eliminated as well. + +In a related change, the frame buffer configuration index is no longer +passed in during a frame erase, hence it is no longer necessary to +erase a frame before displaying an image to ensure that a frame buffer +configuration change is passed to the server. The configuration index +is now passed when the WCS information for a frame is set. + + +2.5.2.3 Graphics colors + + IMTOOL now allocates a range of pixel values for use as graphics +overlay colors. Setting a frame buffer pixel to one of these values +causes it to always be displayed with the assigned color. The graphics +color values are not affected by windowing the display. The most +common use of graphics colors with V2.8 IRAF is for drawing graphics +into a displayed frame with the new tvmark task, available in PROTO. +See the IMTOOL manpage for a table listing the color index assignments. + + +2.5.2.4 New imtoolrc entries + + Several new predefined frame buffer configurations have been added +to the default imtoolrc. These include an 128 pixel square frame +buffer (imt128), a 256 pixel square frame buffer (imt256), and a full +screen display with the same aspect ratio as a 35 mm slide (imtfs35). + + +2.5.2.5 System crash (FIFO) bug fixed + + Versions of SunOS through at least 4.0.1 have a bug in the FIFO +driver code which can cause the internal kernel FIFO data buffer to be +deallocated while it is still in use. This will result in a bad kernel +which will eventually panic and reboot the system. This is the cause +of the IMTOOL crash problem which some sites may have experienced. +IMTOOL has been modified to avoid the circumstances (repeated 4096 byte +transfers) which cause the bug to surface. So far as we know, the real +bug (in SunOS) has not yet been fixed, but at least on the NOAO +systems, the frequency of occurrence of the system crashes is greatly +reduced with the new version of IMTOOL which incorporates the +workaround for the SunOS bug. + + +2.5.2.6 Cursor marking now disabled by default + + When the interactive image cursor read facility was first added to +IMTOOL, the default response to each cursor read was to draw a small +white dot at the position of the cursor. This is convenient when +marking a series of objects to make a list, but with the increasing +number of IRAF programs making user of the interactive image cursor, it +has been necessary to change the default to disable automatic marking +of each cursor read. The cursor mark feature is still available as an +option and can be enabled via the setup panel. + + +2.5.2.7 Ctrl/b may be used for manual blinking + + In addition to the list of blink frames and the timed blink feature +IMTOOL has provided for some time, it is now possible to manually cycle +through the blink frames with the key. Typing while +the mouse is in the image window will cause the display to display the +next blink frame in sequence. + + +2.5.2.8 F4 key will now toggle setup panel + + The F4 function key on the Sun keyboard may now be used to toggle +whether or not the setup panel is displayed. This provides a single +keystroke alternative to calling up the setup panel with the frame menu. + + + +2.6 VMS/IRAF specific revisions + + +2.6.1 NEWUISDISP added to VMS/IRAF + + Nigel Sharp's NEWUISDISP display program, used for image display +under UIS on microvaxes with bitmapped displays, is now available in the +standard VMS/IRAF release, in the directory [IRAF.VMS.UIS]. + + +2.6.2 New INSTALL.COM script + + A new INSTALL.COM script (also written by Nigel Sharp) has been +added to VMS/IRAF. This script, run by the system manager to install +selected IRAF executable images, will now automatically check for and +deinstall any old versions of the executables before installing the new +ones. + + +2.6.3 VMS 4.7/5.0 + + Testing of the standard V2.8 VMS/IRAF release, which was prepared +on VMS 4.7, on a VMS 5.0 system has thus far not revealed any problems +(NOAO is still running VMS 4.7 as our standard system). Hence it +appears that the standard V2.8 VMS/IRAF will run under VMS 5. It is +likely, however, that any attempt to recompile VMS/IRAF under VMS 5 +would cause problems, since we have not yet tried to rebuild IRAF under +VMS 5, and such a major operating system upgrade will often require +changes to the IRAF code. The system may be relinked under VMS 5 if +desired, and this does not appear to cause any problems, but neither +does there appear to be any benefit to be gained from doing so. + + + +2.7 Summary of IRAF System Packages Revisions + + +o The tasks RFITS and WFITS in the DATAIO package now support the + reading and writing of arbitrary sized data blocks (IRAF version 2.7 + and later). + +o Several new tasks were added to the IMAGES package. IMCOMBINE (IRAF + version 2.6 and later) provides for the combining of images by a + number of algorithms. The new task CHPIXTYPE (IRAF version 2.7 and + later) changes the pixel types of a list of input images. The task + IMSLICE slices images into images of one less dimension (IRAF + version 2.8). The task IMSTACK has been moved into the IMAGES + package (although it still resides in PROTO as well). + + The IMSTATISTICS task has been rewritten and now allows the user to + select which statistical parameters to compute and print (IRAF + version 2.8). The IMRENAME task has been modified to allow "in + place" image renames, used chiefly for moving the pixel files to a + new IMDIR. + + Several other tasks in the IMAGES package were modified (IRAF + version 2.8). IMSHIFT was modified to accept a list of shifts from + a file. REGISTER and GEOTRAN were modified to accept a list of + transforms instead of only a single one. IMHISTOGRAM has undergone + extensive revision including support for "box" type plots, support + for linear or log scaling in the y coordinate, as well as support + for antialiasing of the histogram bins. + +o All the tasks in the IMAGES.TV package were modified (IRAF version + 2.8) so that if a task is used with an unsupported display device a + message is printed to that effect. + +o The STTY task in the LANGUAGE package has been improved (IRAF + version 2.6 and later) to better facilitate its "playback" feature. + These changes have been documented in the online help for the + task. This feature is little used by external sites but can be a + very useful instructional aid if users are aware of its capability. + +o A new task PVECTOR was added to the PLOT package that allows one to + plot an arbitrary vector in a two dimensional image (IRAF version + 2.6 and later). + + The task STDPLOT was modified (IRAF version 2.8) so that it uses + the more popular SGI kernel rather than the NSPP (NCAR) kernel + (STDPLOT is now equivalent to the SGIKERN task). A new task + NSPPKERN was added that uses the NSPP kernel. + +o Two new tasks were added to the SYSTEM package (IRAF version 2.8). + The task DEVICES simply prints the dev$devices.hlp file as edited + by the site manager listing available devices on the local host or + network. The REFERENCES task is used to search the help database + for all tasks or other help modules pertaining to a given topic, + e.g., references vector will list all tasks that have the string + "vector" in their one line description. + + +2.8 Glossary of New Tasks in the IRAF System Packages + +Task Package Description + +chpixtype images Change the pixel type of a list of images +devices system Print information on the locally available devices +imcombine images Combine images pixel-by-pixel using various algorithms +imslice images Slice images into images of lower dimension +imstack images Stack images into a single image of higher dimension +nsppkern plot Plot metacode on a NSPP (NCAR) plotter device +pvector plot Plot an arbitrary vector in a 2D image +references system Find all help database references for a given topic + +In addition, there are new image display oriented tasks imexamine, +imedit, and tvmark in the PROTO package in NOAO (used to interactively +examine and edit images, or draw graphics into image display frames). +These really belong in the core system but have been placed in +noao.proto since they are prototype tasks. + + + +3. NOAO Package Revisions + + Some of the major revisions to the NOAO packages are listed below. + + +3.1 Summary of NOAO Packages Revisions + + +3.1.1 New NOAO Packages + + Several new packages have been added to the NOAO suite of packages. + +o The APPHOT package is a set of tasks for performing aperture + photometry on uncrowded or moderately crowded stellar fields in + either interactive or batch mode. This package is now installed in + the DIGIPHOT package (IRAF version 2.7 and later). The APPHOT + package was available as an add-on package to IRAF version 2.5 and + later while it was undergoing alpha testing. Many new features + have been added to the package since it first became available + including the new task QPHOT (quick aperture photometry) and + interaction with the image display cursor for supported image + displays (Sun workstation, IIS model 70). + +o The CCDRED package provides tools for the easy and efficient + reduction of CCD images. This package has been installed in the + IMRED package (IRAF version 2.6 and later). The CCDRED package was + also available as an add-on to IRAF version 2.5. + + A short demonstration of many of the tasks in the CCDRED package is + provided with the DEMO task in the CCDRED.CCDTEST package. + +o The IMRED.ECHELLE package has been replaced with a more + sophisticated collection of tasks for reducing echelle type data + (IRAF version 2.7 and later). The new ECHELLE package recognizes a + new image format in which each extracted echelle order becomes a + line in a two dimensional image rather than having a separate one + dimensional spectrum for each order, although this old output + format is still available as an option. Several new tasks exist + for computing and applying a wavelength calibration to the data + using the echelle relationship between the orders (ECIDENTIFY, + ECREIDENTIFY, and ECDISPCOR) as well as for manipulating the new + echelle format (ECSELECT, ECCONTINUUM, and ECBPLOT). + +o The IRRED package has been added to the IMRED package. The IRRED + package collects together in one place those tasks used most + frequently by users reducing IR data such as that taken with the IR + imager at KPNO. The IRMOSAIC and IRALIGN tasks were available with + IRAF version 2.6 and later. IRMOSAIC takes an ordered list of + input images and places them on a grid in an output image. IRALIGN + uses this grid and a coordinate list of overlapping objects from + the individual subrasters to produce an aligned output image. The + tasks IRMATCH1D and IRMATCH2D were available with IRAF version 2.7 + and later. These tasks are similar to IRALIGN expect that the + intensities of adjacent subrasters can be matched as well. A + script called MOSPROC (IRAF version 2.8) has also been added that + prepares a list of images for a quick look mosaic. + +o The MSRED package has been added to the IMRED package. The MSRED + package is a collection of tasks used for reducing multispectral + types of data, e.g. fiber arrays, where the individual spectra are + for different objects. Like the ECHELLE package, it also has its + own multispectral image format (a two dimensional image in which + each line is an extracted spectrum). Several new tasks have been + added to the package for wavelength calibration of multispectral + data. + + +3.1.2 Modifications to Existing NOAO Packages + + +o The ASTUTIL package was reorganized (IRAF version 2.6 and later - + see IRAF Newsletter No. 3 for details) and several tasks were added + and/or modified. A new task ASTTIMES computes and prints + astronomical dates and times given a local date and time. A new + task RVCORRECT computes and prints radial velocity corrections for + an observation. The tasks PRECESS and GALACTIC were modified + slightly using different but more accurate algorithms. + + The new task SETAIRMASS (IRAF version 2.8) computes the effective + airmass and middle UT of an exposure. This task was also made + available in the TWODSPEC and IMRED packages. + +o The two tasks in the IMRED.BIAS package, COLBIAS and LINEBIAS, were + modified slightly (IRAF version 2.7 and later) so that the fitting + parameters for the overscan region can be set by the user as hidden + parameters to the tasks. + +o The task COSMICRAYS (from the CCDRED package) was made available in + the IMRED.GENERIC package (IRAF version 2.6 and later). + +o A new task called SYNDICO has been added to the IMRED.VTEL package + (IRAF version 2.6 and later). SYNDICO makes glossy prints on the + NOAO Dicomed printer of the synoptic, full disk, magnetograms and + spectroheliograms taken at the vacuum telescope at Kitt Peak. + +o Modifications were made to the IMRED.DTOI package. These changes + have been documented in IRAF Newsletter No. 4. + +o Three new tasks in the ONEDSPEC package, REFSPECTRA, SEXTRACT, and + SPECPLOT, were made available in the IMRED.COUDE, IMRED.IIDS, + IMRED.IRS, and IMRED.SPECPHOT packages. + +o Many new tasks and features have been added to the ONEDSPEC package. + + The SENSFUNC task was completely rewritten (IRAF version 2.6 and + later) to allow determination of extinction, display of flux + calibrated spectra, and many new features for displaying and + manipulating the data. + + IDENTIFY, REIDENTIFY and DISPCOR were modified (IRAF version 2.6 + and later) so that a dispersion solution from IDENTIFY could be + shifted without changing the original shape of the coordinate + function (see IRAF Newsletter No. 3 for details). + + A new deblending algorithm was added to SPLOT (IRAF version 2.7 and + later). See the online help for SPLOT as well as the article in + IRAF Newsletter No. 4. + + The tasks in the ONEDSPEC.ONEDUTIL package were absorbed into the + ONEDSPEC package (IRAF version 2.7 and later). + + The EXTINCT task disappeared with its functionality being taken + over by a rewritten CALIBRATE (IRAF version 2.7 and later). + + The COEFS task was moved to the IMRED.IIDS and IMRED.IRS packages + since this is a very instrument specific task (IRAF version 2.7 and + later). + + Three new tasks were added to the package. SEXTRACT (IRAF version + 2.6 and later) extracts subspectra from one dimensional input + spectra. REFSPECTRA (IRAF version 2.7 and later) takes over part + of the functionality of the old DISPCOR task and allows the user to + define which arc spectra are to be used in the calculation of the + dispersion solution of object spectra. SPECPLOT (IRAF version 2.8) + is a new plotting task that allows the compression of many spectra + to a page (see IRAF Newsletter No. 6). + +o Several new tasks have been added to the PROTO package. + + Four tasks were added to IRAF version 2.6 and later. BSCALE is a + task that can be used to linearly scale images by the mean, + average, or mode of the image. IRMOSAIC and IRALIGN can be used to + combine many frames into one large image. These three tasks are + also available in the IMRED.IRRED package. MKHISTOGRAM calculates + the histogram of the data in a text file. + + Three new tasks were added to IRAF version 2.7 and later. IMSLICE + is a task that slices an image into images of lower dimension. + IRMATCH1D and IRMATCH2D are two tasks that allow combining of many + overlapping images while matching the background intensities in two + different ways. + + Three new tasks have been added to IRAF version 2.8 that allow the + user to interact with the image display (for supported display + devices, ie Sun workstation, IIS model 70). IMEXAMINE allows the + user to interactively examine portions of the displayed image. + TVMARK allows the user to mark objects on the image display. + IMEDIT allows the user to interactively edit an image. + +o The APEXTRACT package in the TWODSPEC package has ungone several + rounds of modifications, as discussed in the IRAF Newsletters, No. + 3 and 4. These changes included improved techniques and additional + options for the extraction of data. + + A new task, APSCATTER, has been added to the package (IRAF version + 2.8). This task determines and subtracts scattered light from two + dimensional aperture or echelle spectra. The task was also made + available from within the ECHELLE package. This task was discussed + in IRAF Newsletter No. 6. + + +3.2 Modifications and Additions to Calibration Data + + The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory called +ONEDSTDS in noao$lib. The current contents of this directory are best +summarized by paging through its README file, e.g., + + cl> page noao$lib/onedstds/README + + +Two additional line lists (used by IDENTIFY) have been added to this +directory (IRAF version 2.8). These lists, vacidhenear.dat and +vacthorium.dat, are simply the standard .dat files in air wavelengths +converted to vacuum wavelengths. The equation used for the conversion +as well as the appropriate reference in the literature are contained in +the README file. + +The thorium.dat file has been updated to contain thorium lines from +3180 Angstroms to 9540 Angstroms (IRAF version 2.6 and later). Please +see the README file for the source. + +Two new directories have been added containing flux information for +standard stars (IRAF version 2.6 and later): SPECHAYESCAL and SPEC50CAL. +Both of these lists are from Massey et al., 1988, Ap. J., Vol. 328, p. +315. + + +3.3 Glossary of New Tasks in the NOAO Packages + +Task Package Description + +apscatter(1) apextract Fit and subtract scattered light +apselect apphot Extract select fields from apphot output files +asttimes astutil Compute UT, Julian day, epoch, and sidereal time +badpiximage ccdred Create a bad pixel mask image from a bad pixel file +bscale(3) proto Brightness scale images: new = (old-bzero) / bscale +ccdgeometry ccdred Discussion of CCD coordinate/geometry keywords +ccdgroups ccdred Group CCD images into image lists +ccdhedit ccdred CCD image header editor +ccdlist ccdred List CCD processing information +ccdproc ccdred Process CCD images +ccdred ccdred CCD image reduction package +ccdtypes ccdred Description of the CCD image types +center(3) apphot Compute accurate centers for a list of objects +centerpars(3) apphot Edit the centering parameters +combine ccdred Combine CCD images +cosmicrays(4) ccdred Detect and replace cosmic rays +daofind apphot Find stars in an image using the DAO algorithm +darkcombine ccdred Combine and process dark count images +datapars(3) apphot Edit the data dependent parameters +demo ccdtest Run a demonstration of the CCD reduction package +ecbplot echelle Batch plots of echelle spectra +eccontinuum echelle Fit the continuum of echelle spectra +ecdispcor echelle Dispersion correct spectra +ecidentify echelle Identify features in spectrum for dispersion solution +ecreidentify echelle Automatically reidentify features in spectra +ecselect echelle Select and extract apertures from echelle spectra +fitpsf apphot Model the stellar psf with an analytic function +fitsky apphot Compute sky values in a list of regions +fitskypars apphot Edit the sky fitting parameters +flatcombine ccdred Combine and process flat field images +flatfields ccdred Discussion of CCD flat field calibrations +guide ccdred Introductory guide to using the CCDRED package +imedit proto Examine and edit pixels in images +imexamine proto Examine images using image display, graphics, and text +imslice proto Slice images into images of lower dimension +instruments ccdred Instrument specific data files +iralign(3) proto Align the mosaiced image produced by irmosaic +irmatch1d(3) proto Align and intensity match image produced by irmosaic +irmatch2d(3) proto Align and intensity match image produced by irmosaic +irmosaic(3) proto Mosaic an ordered list of images onto a grid +mkfringecor ccdred Make fringe correction images from sky images +mkhistogram proto List or plot the histogram of a data stream +mkillumcor ccdred Make flat field illumination correction images +mkillumflat ccdred Make illumination corrected flat fields +mkimage ccdtest Make or modify an image with simple values +mkskycor ccdred Make sky illumination correction images +mkskyflat ccdred Make sky corrected flat field images +mosproc irred Prepare images for quick look mosaicing +msdispcor msred Dispersion correct spectra +msreidentify msred Reidentify features from/to a multispec image +msselect msred Select and extract apertures from spectra +observe ccdtest Create an artificial CCD observation +phot apphot Measure magnitudes for a list of stars +photpars apphot Edit the photometry parameters +polymark apphot Create polygon lists for polyphot +polypars apphot Edit the polyphot parameters +polyphot apphot Measure magnitudes inside a list of polygonal regions +qphot apphot Measure quick magnitudes for a list of stars +radprof apphot Compute the stellar radial profile of a list of stars +refspectra(5) onedspec Assign wavelength reference spectra to other spectra +rvcorrect astutil Compute radial velocity corrections +setairmass(6) astutil Compute effective airmass for an exposure +setinstrument ccdred Set instrument parameters +sextract(2) onedspec Extract subspectra from dispersion corrected spectra +specplot(5) onedspec Stack and plot multiple spectra +subsection ccdtest Create an artificial subsection CCD observation +subsets ccdred Description of CCD subsets +syndico vtel Make dicomed print of daily grams 18 cm across +tvmark proto Mark objects on the image display +wphot apphot Measure magnitudes for a list of stars with weighting +zerocombine ccdred Combine and process zero level images + + +Notes: + +(1) Tasks also in echelle and msred packages. + +(2) Tasks also in coude, iids, irs, and specphot packages. + +(3) Tasks also in irred package. + +(4) Tasks also in generic package. + +(5) Tasks also in coude, echelle, iids, irs, msred, and specphot + packages. + +(6) Tasks also in imred and twodspec packages. + NEWS (Jul86) Ancient News NEWS (Jul86) + +30 July 86 IMIO Modifications +------------------------------------------------------------------------------- + + The new IMIO interface, used by all IRAF tasks to access bulk image data +on disk, is now capabable of operating upon both the old IRAF format (OIF) +images as well as STScI SDAS/GEIS format images. The default image type is +the OIF format. Any existing OIF format images are readable by the new system +without change. Although IRAF can read either OIF or STF format images, +SDAS can read only STF format images, so serious SDAS users should configure +IRAF to work with STF format images as the default. All other users should +continue to use the OIF format images as image access is more efficient, +and the IRAF software has been extensively tested only for OIF format images. +Users of the OIF format should note that they can read a VMS BACKUP tape +(or UNIX TAR tape) containing STF format images directly to disk and immediately +access the images, without changing the default configuration of IRAF. + + The image type is specified by a filename extension; extensions for the +OIF format images are new in this release of the system. The recognized +extensions are shown below. + + image type header file extensions + + OIF .imh + STF .??h (? stands for any character) + +In most cases when operating upon an image with an IRAF task the extension +can be omitted. The most important exception occurs in image templates. +THE PATTERN GIVEN IN AN IMAGE TEMPLATE MUST FULLY MATCH THE IMAGE HEADER +FILE NAMES AS THEY APPEAR IN A DIRECTORY LISTING, i.e., the header filename +extension must be matched by the image template. The image type extension +must also be specified to access an image which is not of the default image +type (OIF or STF), or when changing the type of an image. For example, + + cl> imcopy dev$pix.imh pix.hhh + +will make an STF format copy in the current directory of the OIF format image +"dev$pix". + +The default image type is controlled by the new environment variable IMTYPE. +The string value of IMTYPE is the desired image header file extension, e.g., +"imh" (omit the dot) for an OIF format image. If IMTYPE is not defined the +default image type is "imh". For STF format images there are many possible +image header extensions, and IMTYPE specifies the default type IMIO should +look for when the extension is not explicitly given, or the default extension +to use when a completely new image is to be created. When making a new copy +of some existing image, IMIO will make a new image of the same type as the +existing input image unless an extension is given to force some other type +of image to be created. + + environment variable description + + IMTYPE the default image type (extension) + IMDIR pixel storage directory for OIF images + +The IMDIR environment variable defines the directory in which the pixel file +is to be placed when creating a new OIF format image. In V2.2 and older +versions of IRAF, IMDIR could only be a logical or machine dependent directory +pathname. The new system also recognizes the special "builtin" logical +directory name "HDR$" (must be upper case). If the value of IMDIR is "HDR$", +IMIO will create the pixel file in the SAME directory as the header file, +rather than in some other directory. It is also possible to place the pixel +file in some subdirectory of the header directory, e.g., "HDR$pixels/" will +cause the pixel files to go into the subdirectory "pixels". + + set imdir = "/tmp/user/" # pixel files -> specified directory + set imdir = "HDR$" # pixel files -> header file directory + set imdir = "HDR$pixels/" # pixel files -> subdirectory of HDR$ + +The root filename of OIF pixel files is now the same as that of the header +file, rather than a computer generated name. The filename extension of an +OIF pixel file is ".pix". + +The STF format images support group format, a format very similar to that +used for group format FITS tapes. IRAF users accessing an STF group format +image can specify the `group' (subimage) to be accessed by appending a +subscript to the image name, e.g., + + cl> imstat pix.aah[3] # access group 3 +or + cl> imstat pix.aah[3][*,100] # line 100 of group 3 + +A new group format image can be created in a similar fashion, specifing the +number of groups to preallocate space for, e.g., + + cl> imcopy dev$pix testimage[1/10] + +would create a new group format image "testimage" with space for 10 groups +(subimages), and initialize group 1. The remaining groups would then be +initialized by specifying only the group subscript "[N]". Note that all +groups must be the same size, new groups cannot be allocated, old groups +cannot be deleted, the set of possible group parameters is fixed at creation +time, and all groups share the same FITS header. + + +15 June 86 System Tasks +------------------------------------------------------------------------------- + + The DIRECTORY, HELP, and PAGE system tasks have all undergone important +revisions. The directory task has been completely rewritten and now handles +directory pathnames, etc., correctly, and in addition it has a more concise +syntax. The HELP and PAGE tasks have been modified to replace the old "more" +boolean query mechanism (used to pause between pages of output) with a nicer +keystroke driven mechanism which offers more options and is faster. Read the +manual pages for additional details. The old parameter files should be +unlearned. + + +28 April 86 Package Reorganization +------------------------------------------------------------------------------- + + The basic package structure of IRAF has been modified to make a distinction +between the system packages and the NOAO optical astronomy packages. The basic +directory structure of the system was also changed to reflect the new package +organization, and the printed documentation will be changed as well when time +permits. These changes were necessary to better isolate science software such +as the NOAO and STScI/SDAS packages from the system software, for a more logical +package structure, and to make it easier to install and maintain the science +packages. + +The new root menu of IRAF is as follows: + + dataio images lists noao sdas system + dbms language local plot softools utilities + +The NOAO menu is as follows: + + artdata astutil focas mtlocal proto twodspec + astrometry digiphot imred onedspec surfphot + +Three new packages were added and three old packages were extensively revised. +The NOAO mountain tape readers were moved from the DATAIO package into the new +MTLOCAL package. The astronomically oriented utility tasks were moved from +the UTILITIES package to the new ASTUTIL package. The old LOCAL package was +renamed PROTO, and a new LOCAL package was added in the directory +"iraf$local/tasks". + +The concept of the new PROTO package is appropriate for what the old LOCAL +package was used for, i.e., prototype, temporary, or contributed tasks which +are part of the NOAO package and which are exported with the system, but which +are expected to eventually disappear or be replaced by planned system +facilities. The new LOCAL package is a place to put tasks of strictly local +interest, or tasks which are not portable, e.g., foreign tasks and the Peritek +package. The LOCAL package should be particularly useful for outside sites +as it gives them a place to put locally added tasks which will not be affected +by future updates of the system. Also, the framework (mkpkg, local.cl, etc.) +is all set up, making it easier for outside sites to add their own software +without having to figure out how to set up an IRAF package. + + +20 Feb 85 Recovery from Interrupts +------------------------------------------------------------------------------- + + Tests today (unfortunately only shortly before the first IRAF release) +have shown that VMS/IRAF has higher failure rate than expected for recovery +from a ctrl/c interrupt of a running subprocess, especially if the process +is actively doing i/o. It is probably much safer to interrupt a compute +bound process than a process which is doing heavy i/o, e.g., reading a tape +or doing many file opens, or probably large numbers of any type of system +calls. The failure rate for i/o intensive processes was as high as 1 failure +to recover in 4 interrupts in some of the cases tested. Testing of UNIX/IRAF +turned up some of the same problems, but the failure rate was considerably +lower, probably because the kernel and i/o system are so much simpler. + +Interrupting a process at the wrong time can cause many problems, e.g., +[1] subprocess memory can be corrupted, resulting in unpredictable behaviour +and possibly deadlock when the CL later tries to talk the the process, +[2] a VMS forced exit of the process can occur, e.g., when trying to deliver +an AST to an invalid address, [3] corruption of the CL/subprocess communications +protocol can occur, resulting in deadlock or the loss of sync (the output of +a task will come out when the next command is entered), and various other +problems as well. + +Tests on the old version of VMS/IRAF, which dates back to last fall, show +that the problem has existed all along. The fact that we did not fully +appreciate the problem until now indicates that the problem is not a serious +hindrance provided one is conservative about the use of interrupts. It also +appears that this will not be an easy problem to solve, hence it is likely +to be with us for a while. Probably nothing at all will be done about it +for some months since other projects are likely to have a higher priority +if this problem is understood and can be worked around. + +In summary, try to minimize the use of interrupts, and in particular, avoid +interrupting processes which are doing heavy i/o. When in doubt, type +"flpr" after interrupting a process to force it to be restarted. If a +subprocess becomes hung it may be necessary to restart the CL itself. + + +20 Feb 85 Process connect failure during ":.snap" in cursor mode +---------------------------------------------------------------------------- + + We are still ocasionally having problems when trying to spawn a graphics +subkernel in response to a ":.snap" command in cursor mode. This happens +infrequently (which is why it is so hard to find the bug), and will usually +go away after exiting and reentering cursor mode and trying again. It might +also help to do a ":.gflush" while in cursor mode. diff --git a/doc/notes.solaris b/doc/notes.solaris new file mode 100644 index 00000000..46a5fed2 --- /dev/null +++ b/doc/notes.solaris @@ -0,0 +1,514 @@ +Begin IRAF port to Solaris 2.3 +Wed May 25 15:38:55 MST 1994 +---------------------------------------- + +bin.ssun + +bin.ssun/IB.SSOL.SUN + +bin.sf2c + +bin.sf2c/IB.SSOL.F2C + +noao/bin.ssun + +noao/bin.ssun/IB.SSOL.SUN + +noao/bin.sf2c + +noao/bin.sf2c/IB.SSOL.F2C + + Set up the Solaris platform (SSOL = Sun Solaris) and the two planned + Solaris architectures, SUN (Sun unbundled compilers) and F2C (F2C + and FSF compilers). (5/25) + +unix/hlib/irafuser.csh + 1. Replaced the `mach` reference by something that will work on both + SunOS and Solaris, using uname. + 2. Modified to define either SUNOS or SOLARIS in HSI_CF, so that + kernel code can support both systems. (5/25) + +unix/os/getproc.c + Added a Solaris version of uid_executing(). This reads /proc and + scans the process files to see if any belong to the given uid. (5/25) + +unix/hlib/irafuser.csh +unix/os/mkpkg.sh + 1. alloc.e would no longer link without linking against the library + -ldl. Note that -ldl can only be linked dynamic (no -Bstatic). + 2. Added a new definition HSI_LFLAGS to irafuser.csh and modified the + mkpkg.sh in OS to use this to define the link flags for alloc.e. + This will probably have to be done for other HSI executables as well. + (5/25) + +unix/os/prwait.c + Solaris defines the exit_status argument to wait() differently and + the code had to be modified to allow for this. (5/27) + +unix/os/zfioks.c + The select facility on Solaris uses fd_set, FD_SET, etc. and it + was necessary to add #ifdef SOLARIS code to reflect this. (5/27) + + +Fri Jun 24 14:23:32 MST 1994 +---------------------------------------- +Resume port (elsewhere for the past month) + +unix/hlib/libc/kernel.h + Added a definition PFV; PFI is now a pointer to function returning + int, and PFV is a pointer to a function returning void. Also added + a new definition SIGFUNC, which is whatever type signal() refers to + on the local system. (6/24) + +unix/os/zfioks.c + 1. Changed a number of PFI instances to SIGFUNC. + 2. Changed the second two arguments to ks_onsig to type int*. These + are not used and the actual type is different on Solaris than other + systems. Probably the args should just be omitted but it may be + more portable to define a couple of dummy args. + 3. The second argument to bind() is type (struct sockaddr *) in + Solaris, was (caddr_t) on other systems. (6/24) + +unix/os/zfiotx.c + 1. Deleted the import_fset, which apparently isn't used and which + contains a #define which conflicts with a Solaris one. + 2. Changed a bunch of PFI instances to SIGFUNC. Added some + (SIGFUNC) declarations to the signal handler arguments to signal(). + 3. Replaced the two dummy arguments (same as item 2 above) in three + instances of event handlers with dummy args declared (int *). (6/24) + +unix/os/zopdir.c + Modified to use Solaris version of opendir/readdir. (6/24) + +unix/os/zoscmd.c + Modified to use SIGFUNC instead of PFI, and to declare generic + dummy arguments for an event handler. (6/24) + +unix/os/zshlib.c + Fixed a syntax error on the last line, an extra ';' following a + stubbed out function declaration. (6/24) + +unix/os/zwmsec.c + 1. Modified to use signal instead of sigvec; the latter is BSD specifc. + 2. sigpause() takes a signal number instead of a signal mask. Omitted + sigblock, which is no longer needed since we aren't using a mask, and + which doesn't exist on Solaris. + Possibly this routine should be completely rewritten on Solaris, + there may be better facilities for small timed delays. (6/24) + +unix/os/zxwhen.c + 1. For Solaris we must include and . + 2. fcancel macro modified to use the constant BUFSIZ. + 3. The table of hardware exceptions was modified to omit all + codes other than those for SIGFPE; the other codes (at least on + Solaris) alias with the FPE codes, and aren't used anywhere in + zxwhen anyway. Added Solaris SIGFPE codes. + 4. Modified calling sequence of exception handler ex_handler to + the form Solaris requires. Added a statement to get the hardware + exception code out of the siginfo argument. + 5. Replaced a number of PFI's by SIGFUNC's. (6/25) + +unix/os/zfiomt.c + Modified signal handling code to use type SIGFUNC. (6/25) + +unix/os/zzstrt.c + Made a few changes to get this code to compile, although the shared + library support isn't expected to work at this point. (6/25) + +unix/hlib/irafuser.csh +unix/os/zzstrt.c + Added a new define SHLIB, used to conditionally compile zzstrt for + shared library support. (6/25) + +unix/boot/bootlib/bootlib.h + This file had a #ifdef UNIX in it, but this define is not defined + anywhere. Modified to #ifdef VMS but assume unix otherwise. (6/25) + +unix/hlib/irafuser.csh + Modified to define RANLIB as "echo ranlib" for Solaris. (6/25) + +unix/hlib/kernel.h + Solaris doesn't have bcopy/bzero, so added a couple of #defines to + kernel.h to map these functions onto the equivalent Solaris versions + memmove/memset. (6/25) + +unix/os/zoscmd.c +unix/os/zopdpr.c +unix/os/zfiopr.c + Replaced all calls to getdtablesize() by corresponding calls to + getrlimit(). (6/25) + +unix/os/zfgcwd.c + Replaced getwd() by getcwd(). (6/24) + +unix/boot/mkpkg/scanlib.c + It was necessary to add an (int) cast to (int)fread(...) > 0 + to avoid a warning message from the compiler, because fread has an + odd type on Solaris. (6/25) + +unix/hlib/irafuser.csh + Added -lsocket -lnsl (the Solaris socket emulation library) to the + list of HSI host libraries used to link the HSI utilities. (6/25) + +unix/boot/spp/xc.c + Made some minor changes to xc for Solaris - not clear yet what all + will be needed. Most of it looks like it will work. Added a #ifdef + conditional for the Solaris F77 libraries, taking the SunSoft + compiler as the builtin default. Modified signal handling to use + SIGFUNC to be more portable. (6/25) + +unix/boot/rmfiles/rmfiles.c + Added an "extern char *vfn2osfn()" declaration. (6/25) + +unix/boot/spp/rpp/ratlibc/initst.c + Added a #ifdef conditional to access the stdio streams on Solaris. + (6/25) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2uhpgl.c +unix/gdev/sgidev/sgi2ueps.c + 1. These files contained a number of cases where the file descriptor + "out" was declared int where (FILE *) was intended. + 2. Replaced an instance of gethostname() in sgi2uapl.c by a call + to sysinfo(). (6/25) + + +Sat Jun 25 23:26:24 MST 1994 +---------------------------------------- +Completed first bootstrap. Try initial sysgen of core system. + +unix/boot/spp/xc.c + Modified xc to automatically do a "-t" when linking. This disables + linker warnings about different size commons. (6/26) + +unix/os/irafpath.c + Added a case for Solaris/sparc. (6/26) + +mpkg +as.ssol + +bin.ssol + +unix/setarch.sh +unix/hlib/irafuser.csh + For Solaris/sparc the HSI AS and BIN are as.ssol and bin.ssol. + Hopefully it will be possible to use a single set of directories + for both the ssun and sf2c binary architectures. (6/26) + +unix/hlib/install + Added some code to set the platform architecture automatically for + either SunOS or Solaris. On a Solaris system the suntools stuff is + skipped. (6/26) + +unix/boot/bootlib/envinit.c + Fixed a bug/typo in this code: "printf (stderr, ...)". (6/26) + +unix/boot/bootlib/vfn2osfn.c + Several more cases of a null statement ";" at the end of this file. + This happens in dummy function constructs like "foo(){};". (6/26) + +unix/hlib/mkpkg.inc + Added cases for IRAFARCH=ssun and sf2c. (6/26) + +unix/hlib/mkpkg.sf.SSUN + +unix/hlib/mkpkg.sf.SF2C + + Added starter special file lists for the two Solaris architectures. + (6/26) + +unix/as.ssol/zsvjmp.s + This assembler source appears to assemble ok, but I had to remove the + leading underscore from _zsvjmp_ as the SunSoft Fortran compiler + doesn't use leading underscores. (6/26) + + +Sun Jun 26 20:18:48 MST 1994 +---------------------------------------- +Completed first core system sysgen: system starts up and runs, but a number +of bugs are evident. + +unix/hlib/irafuser.csh + HSI_XF now includes flags such as -/DSYSV -/DSOLARIS etc., so that + mkpkg can be used to update HSI libraries such as OS. This is only + a temporary solution, ideally XC should accept HSI_CF. (6/27) + +sys/fio/fdirname.x + There was an actual bug in this file that showed up during testing + of the new port. zfxdir (kfxdir) was being used incorrectly to + test for the existence of host directory pathnames. (6/27) + +unix/os/zopdir.c + The above testing also revealed a bug in this file. This was + preventing commands such as "dir /" from working, due to a bug in + the code which strips trailing slashes from directory names. (6/27) + +unix/os/zfiotx.c + 1. Raw mode terminal i/o was not working properly on Solaris; output + data was being lost when raw mode was entered, even though the ioctl + used would (presumably) wait for the output to drain before changing + the terminal mode. It is not clear what the connection might be, + but this was fixed by deleting the iflag=0, i.e., not resetting the + iflags, when entering raw mode. Evidently clearing one of the + default input flags was the source of this problem, even though + ICANON was disabled. Since ICANON is disabled we shouldn't need + to change the iflags anyway, so it should be safe to omit this. + In fact, it is probably safer to preserve all default terminal flags + by default and change only those affecting raw i/o, but at present + I will leave it fully setting the oflags and lflags, since this + is working. + 2. Solaris also provides the POSIX termios interface which is the + recommended interface. This appears to be a simple front end to + the termio ioctl interface. I decided to avoid this for the moment + since the SYSV termio interface appears to be widely available. + (6/27) + + +Sun Jul 3 23:08:27 MST 1994 +---------------------------------------- +Resume work on Solaris port. + +unix/as.ssol/enbint.s + +unix/os/zzstrt.c +unix/os/zxwhen.c + After a bit more research got IEEE floating point exception handling + working under Solaris. The new routine enbint.s is used to enable the + exceptions. sigaction turned out to block SIGFPE when the handler + was called and it proved necessary to add the SA_NODEFER flag to + prevent this. (7/03) + +unix/os/zfioks.c +unix/os/zfiond.c + Fixed a couple bugs that were keeping networking from working. + "RSH" was not being defined correctly in zfioks, and it was necessary + to add FD_ZERO calls to zero the select fd arrays before calling + FD_SET. (7/04) + +sys/imfort/tasks/ +unix/hlib/fc.csh + Tested FC on the imfort tasks. This worked without incident following + minor changes to the fc.csh script. The only thing unusual is that + an IEEE retrospective is printed when the task exits, indicating + that the IEEE divzero,overflow,invalid exceptions were enabled. + This is annoying but is not exactly a bug (ieee_retrospective is always + called by Fortran programs, it just doesn't usually generate any + output), so for the moment I don't see the need to change anything + at present. (7/04) + +Build of ssun binaries for TABLES proceeded without incident. (7/04) + +unix/boot/bootlib/ossymlink.c + This file used #ifdef BSDUNIX incorrectly, preventing the #ifdef-ed + code from compiling on UNIX systems for which BSDUNIX was not set. + Changed the statement to #ifndef VMS. (7/05) + +unix/shlib/zzzend.c + Deleted ";" at the end (empty declaration). (7/10) + +unix/shlib/medit.c + Added a #define for bcopy, which doesn't exist in Solaris. (7/10) + +unix/shlib/mkpkg + Modified to avoid use of ranlib on Solaris platforms. (7/10) + +unix/boot/spp/mkxc.sh + Modified to do the compile and link in separate steps. (7/14) + +unix/gdev/sgidev/sgi2uapl.c + Modified to put "%!PS" in the Postscript file header. (7/19) + +dev/tapecap + Added Solaris support. (7/20) + +unix/boot/spp/xc.c + Added -lintl to the list of builtin host libraries. (7/23) + +unix/os/zfiotx.c + Rather than leaving iflags unmodified when raw mode is entered, + now clears several input processing flags, in particular CR is not + mapped to NL. (7/23) + +unix/hlib/zzsetenv.def + Changed the default printer device to "lw". (7/25) + +unix/shlib/Slib.c +unix/shlib/edsym.c +unix/shlib/elf.c + +unix/shlib/medit.c +unix/shlib/mkpkg +unix/shlib/mkpkg.sh +unix/shlib/mkshlib.csh.ssol + +unix/shlib/zzzend.c +unix/os/zzstrt.c + There were many changes here, especially to mkshlib.csh, edsym.c, + Slib,c, and zzend.c, to support IRAF shared libraries under Solaris. + Most of the changes were made earlier but I did not keep detailed + notes during development. The changes are not fully backwards + compatible, so it will be necessary to configure separate shlib + directories for SunOS and Solaris. (7/25) + +unix/hlib/mkpkg.inc + A wfits problem was traced to a bug in the Fortran optimizer using + SunSoft Fortran 2.0.1. Compiling -O2 avoids the problem. (7/29) + +unix/hlib/install + The install script was modified earlier to just exit when it came + to the gterm/imtool config stuff. Modified this to continue on + with this, but to do only the X11 related configuration. This + consists of making the /dev/imt fifos, installing the imtoolrc, + and checking that termcap and graphcap are sufficiently up to date + to contain xgterm and imtool entries. (7/30) + +unix/hlib/libc/kernel.h +unix/os/zfiotx.c +unix/os/zzstrt.c + Replaced the terminal driver by a version which maintains a unique + descriptor for every hardware terminal device, regardless of the + file descriptor used to access the terminal. (8/02) + +dev/graphcap + The xgterm graphcap entry now recognizes either CR or LF as the + trailer code for a cursor read. (8/02) + +unix/boot/mkpkg/mkpkg + Changed "cc" to "$(CC)". (8/17) + +unix/boot/spp/xc.c + XC now supports multiple packages in PKGENV. (8/18) + +----------------------------------------------------- +Solaris 2.10.3 release +*** apus upgraded to Solaris 2.4, SunSoft V3.0 compilers *** + +unix/os/zfiotx.c + Installed the tty_reset bugfix. (9/17) + +unix/os/getproc.c + This routine was omitting the "/proc" from pathnames of process + files in the /proc directory, causing uid_executing to always + return zero. (10/05) + +----------------------------------------------------- +Merged in V2.10.4 revisions from tucana. (4/22 1995) + +unix/hlib/mkpkg.sf.SSUN + Added explicit $xc build commands to the special file list entries for + C files. The default compile flags from mkpkg.inc would cause a + warning when applied to C files, as CC doesn't understand -O2. (4/26) + +unix/shlib/mkshlib.ssol-sc2 +unix/shlib/mkshlib.ssol-sc3 + + Renamed mkshlib.csh.ssol to mkshlib.ssol-sc2. This is the version for + the version 2x SunSoft compilers. Started a variant mkshlib.ssol-sc3 + for the version 3x compilers. In this made various minor changes: + 1) File header size increased from 0x74 to 0x78. + 2) Compiler libraries and objects are now in /opt/SUNWspro/SC*/lib + instead of /opt/SUNWspro/SC*. + 3) There is a new library -lsunmath which follows -lF77. (4/26) + +unix/boot/spp/xc.c + Modified to add the -lsunmath library if used with the Version 3 or + greater SunSoft compilers. XC attempt to automatically distinguish + Version 2 and Version 3 and do the right thing. (4/26) + +unix/hlib/mkpkg.inc + Removed the -O2 switch from the standard compile flags in mkpkg.inc. + This was put in for an older version of the compilers and probably + isn't needed any longer. This also avoids the problem of passing -O2 + to the C compiler when compiling C code. (4/26) + +----------------------------------------------------- +Completed a full bootstrap and sysgen of V2.10.4 Solaris/IRAF using +Solaris 2.4 and the SunSoft V3 compilers. (4/26) + +unix/hlib/zzsetenv.def + Updated "version" to 2.10.4EXPORT. (5/18) + +unix/hlib/spy.cl + Rewrote spy.cl to work on both BSD and SYSV systems (SunOS and + Solaris in the case of Solaris/IRAF). (5/19) + +unix/os/zgtime.c + Modified for Solaris systems to use CLK_TCK (which does a runtime call + to sysconf) to get the clock frequency, instead of the compile time + kernel constant CLKFREQ. On our development system CLK_TCK is 100, + rather than 60 which is the value compiled into the kernel. (5/19) + +unix/os/gmttolst.c + In the internal routine get_timezone added a call to "tzset()" + before accessing the external variable timezone. This is necessary + to set the value of timezone in the first call after process + startup. (5/19) + +unix/os/zoscmd.c + This fix was made to resolve a problem where EMACS or VI would + hang up when run from the CL and ctrl/g or ctrl/c was typed. + Evidently this was due to the code in zoscmd.c which pretends to + ignore interrupts while the child is executing, but in reality was + catching interrupts and setting a flag then continuing to wait for + the child process to terminate. Evidently on SysV systems, or at + least on Solaris, the interrupt handler was causing the process + to read from the terminal, and wait() was not being reentered + folowing an interrupt causing both the parent and the child to read + from the terminal at the same time. The fix was to modify zoscmd.c + so that on SYSV systems the parent does not post any interrupt + handler. (5/19) + +unix/os/zzstrt.c +unix/shlib/mkpkg +bin.ssun/S10_5.4.e + + It appears that the system library libsocket.a in Solaris is + incompatible between Solaris 2.3 and 2.4. Networking is broken if + an IRAF executable linked under Solaris 2.3 is run on 2.4 and vice + versa. Our workaround, at least for the moment, is to have different + versions of the IRAF shared image for different versions of solaris. + During startup an IRAF process will query the OS release number, + e.g. 5.3 (Solaris 2.3) or 5.4 (Solaris 2.4) and map the corresponding + shared image. A mkpkg in unix/shlib updates the version of the + shared image corresponding to the OS release on which IRAF is + currently running. The new shared image file names are S10_5.3.e + for Solaris 2.3 and S10_5.4.e for Solaris 2.4. If the release + dependent version is not found the system will automatically fall + back to S10.e. (5/22) + +----------------------------------------------------- +Did another sysgen-relink and rebuilt the distribution files. (5/22) + +unix/boot/spp/xc.c + Modified to compile only C and assembler files in the catch-all + compile phase. Prevents compile attempts where the file list + contains only object files. This was a problem under Solaris 2.5. + (10/19) + +unix/shlib/mkshlib.ssol-sc3 + Modified to suport the SC4.0 compilers under Solaris 2.5. There was + a bug in the script if both SC3.0.1 and SC4.0 compilers were present + in the same system. The link line was slightly different for the + new compiler. (10/19) + +unix/shlib/mkshlib.ssol-sc3 - +unix/shlib/mkshlib.ssol-sc34 + + 1. Changed the name of this file to sc34 since it supports both the SC3 + and SC4 compilers. Updated the comments accordingly. + 2. I tried changing the page alignment for the shared image from + 0x2000 (8K) to 0x4000 (16K). The intent was to support Sparc clones + with 16K pages. It worked (at least on a Sun sparc), but would + produce a bogus version match please relink error message on startup + for old executables, due to relocation of the transfer vector. I had + to set things back to 0x2000 as we can't afford to break old + executables for a patch. (3/25 1996) + +unix/os/zmain.c + Added a #ifdef SYSV conditional to allow for different calling + sequences for setpgrp() on SYSV and BSD systems. (4/24) + +unix/os/zfinfo.c + Commented out the setpwent/getpwent, they are not needed on Solaris + and appear to cause an associated Solaris bug to crop up. (8/16) + +------------------------------------------- +V2.10.4 patch 2 released. (5/22 1996) + + +TODO + o Tue Nov 21 12:50:24 MST 1995 + XC assumes /opt/SUNWspro in isv3(). + + o Thu Feb 1 11:54:17 MST 1996 + Skip reports networking failure - AA05224 + + o Mon Mar 11 12:24:55 MST 1996 + Modify zawset.c to use actual physical memory as determined by sysconf. + + o Mon Mar 11 12:25:10 MST 1996 + Change SHLIB address from 0a000000 to 03c000000 to allow 1 Gb process + data segment. This requires that all applications be relinked so + cannot be done until V2.11. diff --git a/doc/notes.v210 b/doc/notes.v210 new file mode 100644 index 00000000..41eec3c8 --- /dev/null +++ b/doc/notes.v210 @@ -0,0 +1,9642 @@ +System Notes File for IRAF Version 2.10. +Begun 15 May 1990. +------------------------------------------- + +pkg/cl/cl.par +doc/notes.v29 + +local/notes.v210 + +doc/bugs.v28 + +local/bugs.log +unix/hlib/buglog.csh +unix/hlib/motd +unix/hlib/zzsetenv.def + Switched IRAFX development systems to version 2.10. (5/15) + +unix/hlib/install + Added xyacc to the list of HSI tasks to be installed as command in + the unix local/bin. (5/16) + +dev/graphcap + Updated entries for devices uapl[123457] and vapl[123457] to include + newly measured values of xs, ys and ar. (5/21 ShJ) + +mkpkg +bin.dsux + +noao/mkpkg +noao/bin.dsux + +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.MIPS +noao/lib/mkpkg.sf.DSUX + +local/.login +unix/hlib/cl.csh +unix/hlib/install +unix/hlib/irafuser.csh [DSUX ONLY] +unix/hlib/mkpkg.inc +unix/mkpkg.sh +unix/setarch.sh + +unix/os/irafpath.c +unix/os/zgcmdl.c + 1. Modified DECstation/IRAF to change the architecture name from "mips" + to "dsux". Anyone having IRAFARCH defined in their environment as + "mips" will have to change it to "dsux" to run IRAF. + 2. A couple of the files in OS were modified to change #ifdef mips + constructs to also check for #ifdef ultrix. If both mips and ultrix + are defined it is a DECstation, otherwise at present we will assume + the OS is umips. (5/27) + +mkpkg +noao/mkpkg + Modified so that the same mkpkg file can be used for DSUX and MIPS + systems without change. (5/27) + +local/COPYRIGHT - +local/COPYRIGHTS + + Replaced the COPYRIGHT file by the more carefully prepared COPYRIGHTS + file from the network archive. (5/27) + +doc/ports/notes.mips - +doc/ports/notes.dsux + + Renamed the notes file for the DECstation port. (5/28) + +sys/mwcs/README + + Added a README file to MWCS, containing an interface summary. (6/5) + +sys/mwcs/iwewcs.x + The code which computes CRPIX when reconstructing the Wterm from a + FITS header was optimized with a "if (have_ltv)" but this was + incorrect, since the computation uses both the LTV and LTM portions + of the Lterm (hence it is necessary to test have_ltm as well). + The result was that, given an Lterm consisting of only a scale term + and no shift, the code could fail to restore the correct Wterm + reference pixel coordinate. (6/7) + +dev/termcap [tucana, orion, gemini] + Added Rob's 3 two-column landscape mode printer entries. (6/12/90 SRo) + +* + Removed world write permission from all iraf files. Only a few were + affected, but there were a few files and directories that happened + to have world write perm, and none should (too easy for users to + delete or modify files, accidentally or otherwise). (6/18) + +pkg/softools/mkttydata.hlp + Deleted the explicit instructions for performing a sysgen-relink, + which are no longer applicable to all versions of IRAF, and added + comments to the affect that use of MKTTYDATA to cache termcap or + graphcap entries is inadvisable for most sites. (6/19) + +sys/qpoe/QPOE.hlp + Revised and updated the section on QPEX; the documentation for this + section was out of date. (6/20) + +lib/syserrmsg + Changed the error message for SYS_QPUKNPAR from "attempt to delete a + nonexistent parameter" to "unknown parameter". This message is used + for all unknown parameter references, not just parameter deletions. + (6/22) + +sys/qpoe/qpgpsym.x +sys/qpoe/qpgmsym.x +sys/qpoe/qpaccessf.x +sys/qpoe/README + 1. The QPOE macro facility supports two kinds of macros, global macros + defined in an external QPDEFS type file which affect all QPOE file + references, and datafile-local macros defined as "macro" type + parameters in the individual QPOE file headers. There was a problem + with the latter feature (datafile-local macros) due to QPOE header + parameter references employing full macro expansion. A routine + such as qp_write would perform macro expansion on the parameter name, + and if the referenced parameter was the macro parameter itself, one + would get the parameter pointed to by the macro alias rather than + the macro parameter, making it impossible to access macro parameters + once defined. The solution adopted was to disable expansion of + datafile-local macros in low level header parameter accesses. + Datafile-local macros are still used in expressions, hence can be + used to define things like event struct fields names. Also, global + macros are still used in header parameter accesses, hence header + parameters may still be aliased using global defines. + + 2. The routine qp_expandtext was reclassed as an interface routine + instead of an internal routine. If aliasing of header parameters + using datafile-local macro parameters is desired, this routine may + be called to conditionally translate the parameter name before + accessing the parameter, allowing the name to be aliased. (6/24) + +unix/boot/rtar/rtar.c +unix/boot/rtar/rtar.hlp + Added two new switches to RTAR. + + -m Do not restore the file modify times. + -u Do not attempt to reset the user and group ids. + (6/25) + +sys/qpoe/qpclose.x + A qp_open to create a new qpoe file followed immediately by a qp_close + would create a file with no qpoe file header descriptor, causing an + error when the file was subsequently opened with qp_open. qp_close + was checking for the case of an open/close with no header writes and + was forcing a qp_bind in this case, but the QP_MODIFIED flag was zero + so the file header was not being updated. Added a QP_MODIFIED(qp)=YES + to force the file header to be updated, if qp_close is called on a + new qpoe file before any header modifications have been made. (6/26) + +sys/gio/imdkern/imdopen.x +sys/gio/imdkern/imdopenws.x + The imd_openws routine in the new IMD kernel was given a calling + sequence of imd_openws(devname,n,frame,color,mode) when the kernel + was first written. However, this routine is one of the externally + callable driver routines and the calling sequence is fixed as defined + by the GKI interface (the calling sequence must be the same for all + GIO kernels). The IMD kernel will work fine when run standalone, + but could die on a segmentation violation when called as a GIO + subkernel, since the subkernel interface is GKI. By chance this + escaped all our testing, as the argument list mismatch can easily + go undetected, depending upon the chance contents of the registers + or stack locations associated with the missing input arguments. (7/1) + +unix/hlib/mkiraf.csh + Modified the unix/iraf mkiraf script to prevent the user from running + mkiraf in an iraf system directory (any iraf directory other than + iraf/local). (7/5) + +unix/hlib/mkpkg.inc +unix/shlib/edsym.c + 1. In the tucana/irafx mkpkg.inc, deleted the -T from the default + link flags to allow editing of shared image symbols. + + 2. When shared image versions were added a while back I forgot + to add version support to EDSYM, the symbol table editor. The + program has been modified to examine the text segment of the + file being edited to determine the shared library version number, + and use this to access the correct shared image (e.g., S5.e is + the version 5 shared image). With these changes, executables + linked in the default way will again have the correct symbols + for the shared image (allowing use of adb or dbx to examine + locations in the shared image, without having to relink -z). (7/5) + +unix/boot/spp/xc.c + Modified XC to automatically disable the call to EDSYM (the symbol + table editor) when linking a host program (xc -h). (7/6) + +sys/imfort/mkpkg +sys/imfort/imfparse.x +sys/imfort/imfmkpfn.x +sys/imfort/imftrans.x + + 1. Due to the use of vfn_translate in imfparse.x, the directory prefix + field, if any, of the image name was being discarded. This would + prevent use of IMFORT to access images other than in the current + directory. The use of vfn_translate was inadvisable in any case, + as it performs more VFN translation than is desired, and IMFORT is + supposed to allow unrestricted use of host filenames. The fix was + to replace the call to vfn_translate by a call to a new internal + imfort routine imf_trans. This will still do a very limited amount + of escape sequence encoding on the image filename, allowing mixed + case and multiple "." delimited fields to be input and translated + as for IRAF vfns, e.g., on VMS. Since such filenames are not legal + in VMS (mixed case is legal but is not very useful in VMS) this + level of translation should be fairly safe. + + This was introduced into V2.9 on 11/28/89 (when the IMFORT pixel-file- + clobber bug was fixed). It is surprising that the problem was not + reported earlier. Most people must access only images in the current + directory. (7/6) + + 2. The call to vfn_encode in imf_parse was not quite right either. + vfn_encode only returns the next field of a pathname, and when + imf_parse was called with a path and a non-image 3 char extension, + part of the path would be lost. The solution was to replace the + call to vfn_encode by a call to the new imf_trans routine, which + avoids just this problem. (7/9) + +dev/hosts [tucana, orion, gemini] + Changed cmd field for draco, to use known object "241", which + currently points at usr$0:[rooke]irafks.com, but will shortly + point to usr$3:[irafext.kpnolocal.src.dni]irafks.com. (7/12 SRo) + +dev/graphcap [tucana, orion, gemini] + Added iism70d field for draco-hosted iis, aliased to iism70c & iism70l + for backward compatibility. Changed DD in default iism70 entry to + point to draco, using iia0, as we currently have no UNIX-hosted iis. + (7/12 SRo) + +unix/os/zmain.c +unix/os/zzsetk.c +unix/os/zfiopr.c + Added a new facility to UNIX/IRAF for debugging interprocess + communication (IPC). This feature will also be useful for debugging + tasks standalone, particularly in cases where a bug seen when the + task is run from the CL is difficult to reproduce when the task + is run standalone. + + The facility is this: if LOGIPC is defined in the host environment + when an iraf process is started, the process will create two files + PID.in and PID.out, where PID is the process id. Everything read + from the IPC input file is copied to the .in file, and everything + written to the IPC output (e.g., sent back to the CL) is copied to + the .out file. This is done only for connected subprocesses. + It will work for any connected subprocess, e.g., normal cached + processes and graphics subkernels in both foreground and background + CLs, but not the i/o of the CL itself since it is not driven by IPC. + + The IPC streams saved are an exact binary copy of whatever was sent + via IPC, including the binary IPC packet headers, binary graphics + data, etc. However, most IPC traffic is textual in nature, so it + will usually be possible to read the IPC files with a file pager, + or even "cat" them to the screen (not avisable if graphics data is + involved). + + A particularly interesting use of this feature is to allow a process + to be run under the CL in the normal fashion, then rerun under the + debugger using the saved IPC input to duplicate the input and actions + of the process when run under the CL. For example: + + % setenv LOGIPC + % cl + cl> dir + cl> logout + % unsetenv LOGIPC + + Will run the CL, saving the IPC of all subprocesses (x_system.e). + We can then run the system process manually, using the saved IPC + input: + + % $iraf/bin/x_system.e -c < PID.in + + To run the process under ADB or DBX, using the saved input: + + % adb $iraf/bin/x_system.e + :r r -c < PID.in + + Note that the redirection has to be given first for ADB, and last + for DBX. [In recent versions of SunOS there must be no space after + the "<" in the :r command to adb.] + + Running a task in this way is not identical to running the task + standalone, e.g. using a DPARAM file for parameter input, because + the exact runtime context of the process as run under the CL is + reproduced. The differences are subtle but can be important when + trying to reproduce a bug seen when the process is run under the + CL. For example, the functioning of the task is slightly differenct + when the -c flag is used, the environment is passed in via IPC rather + than being read from hlib$zzsetenv.def, and so on. Except for + possible kernel level differences associated with spawning the + process by forking a shell rather than the CL, the process should + execute identically as it did under the CL. (7/17) + +sys/vops/amov.gx + This routine could fail, corrupting the data array, in some + cases when the input and output arrays overlap. The same + problem exists in standard V2.9 iraf except that in most iraf + implementations, a host optimized version of AMOV is used, + hence the bug has not been seen. (7/19) + +sys/imfort/tasks/pcube.f + This file contained a subroutine containing the following sequence of + statements (irrelevant statements ommitted): + + subroutine pcuber (pix, nx,ny,nz, i1,i2, j1,j2, k1,k2) + real pix(nx,ny,nz) + integer nx, ny, nz + + On the MIPS, this produced a warning about nx/ny/nz already having + been declared. Probably when the compiler processes the REAL + statement it assumes the parameters are type integer. This seems + reasonable, so I moved the INTEGER card up before the REAL and the + warning went away. (7/19) + +sys/imfort/tasks/mkim.f + This task creates a test image where the pixel value is computed based + on the position of the pixel in the image. The relation being used + was (j*ncols+i), which is the pixel number starting at [1,1], except + that the value is offset by a line, which is ok but not what one would + expect. I changed it to ((j-1)*ncols+i). (7/19) + +vms/hlib/sigqueue.com + Added qualifiers /passall/nofeed to the ln03 print command. (7/20 ShJ) + +pkg/utilities/doc/polyfit.hlp + Added the missing "statistical" heading under the weighting section + in the polyfit task help page. (7/23/90 LED) + +sys/plio/pllpr.x +sys/plio/pllnext.x +sys/plio/pll2r.gx +sys/plio/pll2p.gx +sys/plio/plcmpress.x + These files each contained statements of the form + + (foo * I_SHIFT) + goo + + where foo is type short and I_SHIFT is an integer constant. The VMS + Fortran compiler, due to a misfeature or otherwise, evaluates a short + times an integer literal using short integer arithmetic, causing + integer overflow in the short integer intermediate expression. The + solution adopted was to replace the "foo" in expressions such as the + above by "int(foo)". (7/24) + +vms/os/zmain.c + The vms/iraf process main was modified to add support for calling + iraf tasks on the host system command line, a feature which was added + to unix/iraf some time ago. As with unix/iraf, any extra command + line arguments are passed on to the iraf main as the iraf command to + be executed. The vms/iraf version has the additional feature that + the process stdin and stdout/stderr may be redirected on the command + line, using the usual syntax file >>file. This is NOT THE + SAME as redirecting the i/o of the iraf task, with 4>file etc. + arguments to the task. Both or either form of redirection may be + used, but the process main arguments must preceed the command to be + passed to the iraf main. (7/24) + +noao/lib/strip.noao + Added ONEDSPEC to the list of packages to be stripped; don't know + why this was missing. (7/25) + +pkg/utilities/t_curfit.x,curfit.gx + Moved the ic_close(rd) calls out of the input file/image loop + and into the main routine. The pointer to icfit was being freed + after the first file of data was fit and not reallocated before the + next fit was initiated resulting in a segmentation violation. + (LED 7/30/90) + +dev/hosts [tucana only] + Added adonis (engineering hp9000/370) to network for hpux testing. + (7/30/90 SRo) + +math/gsurfit/gsder.gx,gsderd.x + Corrected a typo in the gsder.gx routine which was causing a + pointer to be passed to the salloc routine instead of a size. + If the pointer addresses became very large this caused + an out of memory allocation error. This error has been in existence + as long as the package but only showed up on the MIPS. + (8/1/90 LED) + +sys/imio/iki/oif/oifmkpfn.x + Modified to check for the null image, and return "dev$null" as + the pixel file name in this case. (8/4) + +unix/boot/spp/xc.c + 1. All internal system executables called by XC (currently xpp.e, + rpp.e, and edsym.e) are now located using the iraf routine + os_sysfile, rather than searching through the host system + directories /usr/bin, /usr/local/bin, and so on. This ensures + that XC will always find these executables, regardless of where + the iraf host level commands xpp, rpp, etc. are installed (XC does + not even care if these are installed as user commands, anymore). + + 2. The technique used to locate host commands such as f77 and cc + was changed to the following sequence: [1] first the directories + defined by the user's $PATH are searched (using execvp), [2] the + internally defined directory SYSBINDIR is searched (this defaults + to /usr/lang on a Sun), [3] the internally defined directory + LOCALBINDIR is searched (defaults to /usr/local/bin). + + 3. When linking on a Sun/IRAF system, -lI77 is searched only if + the old (pre-V1.3) compilers are being used, as I77 has been + deleted with the V1.3 compiler. + + The result of the above change for Sun/IRAF is that the revised XC + will work with either the new V1.3[.1] compiler, or any of the old + compilers. If both compilers are installed, either may be + selected using $PATH. If the system contains only the new + compiler at /usr/lang and the user has not included this directory + in their path, XC will still find the compiler. (8/4) + + NOTE - Although IRAF can now make use of the new V1.3 compilers, + these are NOT fully supported yet. These appear to be largely new + compilers. A new set of system default compiler switches will + have to be developed, and the full iraf system recompiled from + scratch and tested before the new compilers are fully supported. + In particular, note that there is no guarantee that sources + compiled with the new compiler will link correctly with iraf + objects produced by the old compiler, or that old iraf objects + will link properly with the system libraries included with the + new compiler. The default iraf mkpkg compiler switches may not + be correct for the new compilers. Compiler bugs are likely. + +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c + Modified the code which outputs runtime initialization statements + to output these statements after any DATA initialization statements + (they were coming out before the DATA statements). Runtime + initialization is used to zero the function value of real and double + functions upon procedure entry. (8/7) + +sys/qpoe/README +sys/qpoe/mkpkg +sys/qpoe/qpio.h +sys/qpoe/qpmacro.x +sys/qpoe/qpoe.h +sys/qpoe/qpopen.x + 1. The builtin interface default blocking factor for QPOE was changed + from 8 to 1. + + 2. The default blocking factor may now be specified individually for + each datafile, by defining the optional parameter "defblock" in the + QPOE header. If a datafile default is given this overrides the + builtin interface default; any global SET value overrides both, + and setting the block factor in the runtime filter expression or + in a runtime call to an interface seti routine will override both + the datafile and global defaults. + + 3. In a related change made while implementing the above feature, + qp_open was modified so that interface parameters set in global + SET statements (as in QPDEFS) will override datafile parameters + inherited from an existing datafile in a NEW_COPY operation. + In other words, if the user explicitly specifies a parameter such + as "pagesize" or "bucketlen" in their QPDEFS, this will override + the default value inherited from an old datafile when a new copy + is made. As before, any runtime qp_seti calls made once the new + datafile has been opened will override these defaults. This was + necessary to be consistent with the rule that the most recently + specified value for a parameter takes precedence. (8/8) + +pkg/system/directory.x + A couple of obscure bugs were fixed which affected unsorted + directory listings. (8/8) + +pkg/images/imarith/imasub.gx + Fixed a bug in the special path for subtracting an image from + the constant zero; i.e. negation via subtraction. (8/15) + +pkg/images/imutil/hedit.x + Modified hedit to use the maximum of the default task min_lenuserarea + value (28800) and the "min_lenuserarea" environment variable if + defined. The previous version always used the default value. (8/15 LED) + +dev/graphcap [tucana, orion] + Known object irafks.e is failing due to some problem with its I/O + channels at startup time; this happened apparently without any change + to VMS or IRAF software. IIS access via dni from tucana or orion + still works if the user has an irafks.com in their login directory. + Changed draco!iis to dnidraco!iis, so that the private irafks.com + is used. Will have to fix known object irafks.e later. (8/17/90 SRo) + +pkg/dataio/t2d/t_t2d.x + Increased OBUF_PAD, which controls the size of a data record read, + from 20000 to 32767 chars. This value limits the maximum size of + an input data record in the tape record, and it is a read error if + the actual record is larger. (Also increased SZ_OBUF to the next + larger power of two and increased the max ranges, not that the latter + is likely to matter). (8/22) + +dev/uhosts + Updated this file to reflect changes in the NOAO internet. This file + is a modified version of tucana's /etc/hosts file. (ShJ 8/29) + +dev/graphcap + Added entries for all colors of imd devices; color indices 202 through + 217 are now available. Also added a device "imddicomed" suitable for + drawing black, variable width lines destined for dicomed output via + the imdkernel. The imd entry was modified so xs=ys=#0.263, indicating + a physically square device. (8/30 ShJ) + +unix/hlib/config.h + Changed MT_SZBDEFIBUF (the default maximum input buffer size for + magtape i/o) from 32768 to 65535. This more nearly reflects the + maximum record size of most modern devices, and the change was needed + to permit the full range of blocking factors for tapes. (9/3) + +unix/os/zfiomt.c +unix/os/zfiomt.c.BSD + + Installed the temporary "hacked magtape driver" for SunOS, which + includes Exabyte support. This will be replaced shortly in V2.10 + but is what is being shipped in V2.9.1. This driver supports the + following combinations of devices and host drivers (given the + current chaotic situation with tape drivers on Suns it is unlikely + that any combinations not tested will work): + + 1/2" reel tape 4.0.3 all except ST (SCSI tape) driver + 1/2" reel tape 4.1 untested, but should work + + Exabyte 4.0.3 Sun ST driver, Ciprico RT driver + sparcstation under 4.0.3 not tested + Exabyte 4.1 Sun ST driver, except sparcstation + + 1/4" cartridge tape and 1/2" reel tape on the Sun SCSI driver (at + least under 4.0.3) is not currently supported. The Exabyte on the + sparcstation version of the ST driver is not currently supported + due to serious bugs in the sparcstation version of the ST driver, + which is different than any other version of the ST driver. + + The driver automatically determines whether the current system is + running 4.0.3 or 4.1 and adjusts it behavior accordingly. The + behavior of the ST driver differs from 4.0.3 to 4.1, and worse, + the driver ioctls changed, which prevents magtape code compiled + under 4.0.3 from even running on 4.1. zfiomt works around this + by using the hardwired values of the iocts for the two SunOS + versions. (9/3) + +unix/os/tape.c + + This file (not part of the runtime iraf system) is a host level + magtape test program, which should compile and run on most unix + systems. It is kind of like the unix "mt" program, except that it + runs as a command interpreter, allowing one to open a drive and + issue a series of commands to exercise the drive. All the + standard driver ioctls are provided, plus commands for reading and + writing data records, and various interpreter control commands. + The program is useful for exercising drivers (and drives) to + determine exactly what they do when the various driver ioctls are + issued. + + The following commands are provided: + + open [device [r|w]] rewind fsf [n] + close read [nrec [bufsz]] fsr [n] + log [file] write [nrec [bufsz]] bsf [n] + run weof bsr [n] + verbose status quit + + The "write" command writes records of the given size (default 1024) + containing a comment such as "file M, block N" at the beginning of + each record. The "read" command prints out the first 80 printable + chars or so of each record read, omitting unprintable chars. These + commands can be used to prepare test tapes and determine to what + record the tape is positioned after a given ioctl or command is + issued. (The program is also useful as a crude mtexamine type + program). (9/3) + +unix/boot/spp/xc.c [Sun/IRAF only] + The SunOS version of the XC compiler, which makes a stab at trying + to support the version 1.3 Sun Fortran and other compilers, was + modified as follows: + + o When a compile is performed with the new compilers in the + path, the compiler runtime BIN directory /usr/lang/SC0.0 + (or whatever - the path is generated at runtime to reflect + whereever the user installed the compiler) is passed as + in -L/usr/lang/SC0.0 to the CC command used to link. This + is necessary because the version of CC used to link may be + the old C compiler, which will not automatically search + the compiler BIN directory /usr/lang. + + The actual library search path specified depends upon + whether FLOAT_OPTION is defined in the user environment. + For example, if FLOAT_OPTION is defined in the user + environment as "ffpa", the search path command line options + will be -L/usr/lang/SC0.0/ffpa -L/usr/lang/SC0.0 (where + the user specified path (/usr/lang) and BIN version (SC0.0) + are determined automatically at runtime). Referencing the + right version of each library is necessary in order to get + the library version optimized for the local floating point + hardware on Sun-3s. + + o The host libraries searched to link with the 1.3 compilers + were changed to -lF77 -lm. It appears that -lU77 was + eliminated in 1.3, as well as the -lI77 noted earlier. + + Using, e.g., f77 to perform the link would avoid the need to have + XC know the details of the host libraries but is probably not a + workable solution since iraf programs are not Fortran programs + ("host" programs linked with xc -h are not necessarily Fortran + programs either). f77 would set up the startup files etc. + required by f77 programs, whereas an iraf program is to the host + system a C program which uses some of the f77 libraries. If f77 + could be used to link a C program then it might provide an + alternative to having XC know what host libraries to link against, + but I doubt if this would work. + + It should be noted that while we are attempting to support the new + compilers, full support cannot be expected until the IRAF project + begins using these compilers routinely. (9/3) + + Addendum - Note on 1.3 compilers. Testing the new XC with the 1.3 + compilers on a Sun-3, I find that FLOAT_OPTION no longer works as + it used to. If FLOAT_OPTION is defined in the environment and one + does, e.g., a cc to compile a file, a message is printed warning that + FLOAT_OPTION is being ignored and the the default (fsoft) is being + used. It is necessary to explicitly compile with -f68881 or whatever + to get the desired architecture. This is not a problem for mkpkg or + fc, since these utilities automatically generate the -float arguments, + but if one calls xc directly the argument must be given. (9/4) + +dev/graphcap [orion, tucana] + Changed dni networking to draco back to normal (known object) mode + after fixing vms irafks.e startup problem (kpnolocal version). + (9/4/90 SRo) + +dev/hosts [orion only] + Added columba to hosts file (gemini & tucana were okay). (9/7/90 SRo) + +-------------------- +All tucana architectures and irafx@draco were updated to the latest snapshot +of V2.10. orion, pegasus, columba, cephus, and iraf@draco were updated to +V2.9.1 and the V2.9 distribution files rebuilt in the network archive. +(3-9 Sept.) + +sys/imio/db/idbfind.x + Commented out a couple of lines of code in the code which scans + an unblocked header. The erroneous code was harmless given a + normal header containing nonempty cards, but could result in header + cards being skipped if blank header lines were encountered. (9/11) + +doc/ports/notes.mips + + Archived the notes for the the MIPS port. (9/17) + +unix/os/tape.c + Installed a newer version which is more conservative about the use + of the status (NOP) ioctl. (9/17) + +math/curfit/cvrestore.gx,cvrestorer.x,cvrestored.x +math/gsurfit/gsrestore.gx,gsrestorer.x,gsrestored.x +math/surfit/isreplace.x + Changed all the int() calls to nint() calls in the above math + package restore routines. This is a totally safe way for the + math routines to do the required floating point to integer + conversions and removes any potential precision problems for + tasks which read the math package structures back from a text + file. This change was made in response to problems encountered + with reading text databases on the HP. (LED 9/18) + +unix/hlib/zzsetenv.def + Removed the default imdir=tmp$ entry. Having this in zzsetenv.def + prevents use of a host level environment definition to set the per-user + default, and isn't necessary as IMIO will default to imdir=HDR$ if + imdir is not defined. (10/2) + +dataio/doc/wfits.hlp + Added some comments to the wfits help page concerning the unwisdom + of writing to EOT on a blank tape. Updated the section describing + the tape blocking factors and added an example showing how + wfits can be used to write exabyte tapes with large blocking + factors. (LED 10/3) + +----------- +f68881,ffpa,sparc binaries updated on tucana. (10/16) + +unix/boot/spp/xpp/xppcode.c + Fixed a typo on line 888, changing "op >= &sbuf" to "op >= &obuf". + (10/19) + +pkg/images/imhistogram.par +pkg/images/iminfo/imhistogram.x +pkg/images/doc/imhistogram.hlp + Added a new parameter binwidth to the imhistogram task so that the + user can define the imhistogram resolution in terms of intensity + units or number of bins. (LED 10/26) + +pkg/images/tv/doc/display.hlp + Modified the description of zrange to note that the minimum and + maximum pixel values, if not already known, are estimated rather + than computed by examination of the full image. (11/5) + +sys/INDEX + + I added a MKTAGS procedure index listing to the SYS directory, + to make it easier for people to locate VOS routines without having + to know about MKTAGS (since few do, it seems). This file contains + a list of all the procedures defined in all the .x source files in + the sys$ directories, giving the calling sequence and source file + and line number for each. (11/8) + +dev/graphcap +unix/sun/imtoolrc + Added a new entry for the GONG Cache Monitor. (11/9/90 ShJ) + +sys/qpoe/qpexdebug.x + Modified to print the lookup table zero to NDIGITS_DP precision, + in the case of a double precision lookup table. (11/9) + +sys/qpoe/zzdebug.x + 1. Modified the `hlist' task to survive the case of a symbol + returned by qp_gnfn not being found by qp_gpsym; this can happen + when the symbol name is a macro. + 2. Modified the default debug event list struct to agree with that + of PROS/Einstein datafiles, for convenience sake when debugging with + this data (the zzdebug code is crude and uses a wired-in compile + time event struct). (11/10) + +dev/hosts +dev/devices +dev/devices.hlp + 1. Added node ursa. + 2. The 1/2" drives now have a default density of 6250 instead of 1600. + 3. devices.hlp file updated to reflect the above changes. + (ShJ 11/12) (CB 11/12) + +pkg/images/images.hd +pkg/images/rotate.cl +pkg/images/imlintran.cl +pkg/images/register.cl +pkg/images/register.par + Added src="script file name" entries to the IMAGES help database + for the tasks ROTATE, IMLINTRAN, and REGISTER. Changed the CL + script for REGISTER to a procedure script to remove the ugly + local variable declarations. Added a few comments to the scripts. + (LED 11/12) + +sys/qpoe/README +sys/qpoe/mkpkg +sys/qpoe/qpexgetat.x + +sys/qpoe/qpexattrl.gx + + Added the following new routines to QPEX: + + nc = qpex_getattribute (ex, attribute, outstr, maxch) + nr = qpex_attrl[ird] (ex, attribute, xs, xe, xlen) + + The qpex_getattribute routine is like qpex_getfilter, except that it + returns only that portion of the current compiled filter which + pertains to the named attribute. The filter expression for the + attribute is returned as a text string. The family of routines + qpex_attrl[ird] are similar, except that they return the filter for + the named attribute as a binary range list. In both cases, the + actual filter is stored internally in the QPEX descriptor as a + compiled program, hence the attribute or expression is only a + representation of the actual filter. Unless there is a bug they + should amount to the same thing, but one should be aware that the + internal form of the compiled filter is not a simple range list. + (11/12) + +sys/qpoe/zzdebug.x + Added a new debug task TFILTER, used to verify time filtering. Also + tests qpex_attrld, qpex_getattribute, and the use of QPEX and QPIO + independently, using qpex_seti to set the event attribute filter and + rewind the event list. Time filtering is tested by filtering the + event list once using the normal optimized time filtering code, + saving the x/y of each event which passes the filter in a memory + array. The event list is then rewound, the filter removed, + qpex_attrld called to get the time filter as a binary range list, + and the raw event list is manually filtered and the x/y of each + event which passes the filter saved in memory. The filter results + are then compared to see if they agree. (11/12) + + [I wasted half a day getting TFILTER working, due to a very uncommon + problem. Changing the name of the task in the task statement in the + QPOE zzdebug.x would cause QPEX parsing (totally unrelated) to fail + in some cases and work in others. I traced this to particular file, + but when it was recompiled the bug went away. The newly compiled + object, though, was identical to that on orion (V2.9.1). Short of + recalling files from a backup tape, it was impossible to look into + this further.] + +sys/qpoe/qpexeval.x + In testing the time filtering code with the new debug task I found + the following bugs. + + 1. The code which evaluates the filter expression for a single event + was not initializing the value of the expression to false before + evaluation. In most cases this step is redundant (which is probably + why I didn't put it in the original code) but it turns out that + there is a case in the lookup table code used to evaluate long range + lists where the old expression value is pushed before evaluating a + subexpression, and an undefined value could be pushed causing events + near a range boundary to occasionally be passed when they shouldn't. + + 2. The first thing the lookup table code does is map the data value + to a bin of the lookup table. This involves an INT operation, and + values a fraction of a data value left of the first bin of the table + would have a fractional negative value which INT would convert to + a zero, causing values just left of the first bin to erroneously be + mapped into the first bin. (11/14) + +unix/os/tape.c + Was opening the tape drive with mode 1 when open-write was specified; + changed this to open with mode 2, read-write. (11/15) + +sys/qpoe/qpexcode.gx + Nested range list evaluation lookup tables occur where a bin of the + table at level N maps to so many closely spaced ranges that another + lookup table at level N+1 is needed to evaluate the range list for a + value that maps into the bin. Using the new TFILTER debug task to + test nested floating time filter lookup tables, I found that a + couple of internal variables were not being saved on the stack when + the routine recursed to generate code for the new table. (This is + the first time this feature was ever tested, as it has not been + needed until now). (11/15) + +sys/qpoe/qpex.h + Increased the size of the program and data buffers used for + expression evaluation by QPEX. These can overflow at runtime + causing a program abort and the memory is dynamically allocated so + we may as well be more generous. There is still a builtin default + upper limit, but if someone does come up with a filter which is + large enough to overflow either buffer the size can be increased in + QPDEFS before compiling the filter. (11/15) + +pkg/system/doc/help.hlp + Added REFERENCES and PHELP to the "SEE ALSO" section. (11/16) + +unix/os/mkpkg.sh + Modified the bootstrap code to avoid compiling sources such as + getproc.c and tape.c into LIBOS, since these are not part of the + library. The new version compiles all z*.c files plus an explicit + list of other files which are part of the kernel, such as + irafpath.c, prwait.c, and so on. (11/19) + +pkg/images/doc/gauss.hlp + Added a detailed mathematical description of the form of the + Gaussian kernel used in the GAUSS task to the help page. (28/11/90) + +pkg/images/filters/t_convolve.x + CONVOLVE was not decoding the legal 1D kernel "1.0 2.0 1.0" correctly + although the alternate form "1.0 2.0 1.0;" worked. Leading blanks in + string kernels as in for example " 1.0 2.0 1.0" also generated + an error. Fixed these bugs and added some additional error checking + code. (11/28/90 Davis) + +dev/hosts [draco, iraf and irafx] + Changed path to irafks.e to use "bin.dsux" for cephus. Other + DECstation installations left as "bin.mips. Node equuleus uses + mips as IRAF architecture; couldn't check virgo (passwd changed?). + (11/28/90 CB) + +unix/boot/spp/xc.c + While testing the magtape driver code on Ursa (Sun 470, SunOS 4.1) + I had occasion to compile a file and found that XC failed with the + message "f77 not found". The following two changes were made. + + 1. There was an actual bug in the code for "run". This would build + the path of the executable, e.g., "/usr/lang/f77", but not use it, + calling execv with only the task name, e.g. "f77". Hence the routine + would only work if the executable was found in the user's path. + + 2. Evidently the V1.3 compiler cannot even execute unless the + directory containing the f77 driver (normally /usr/lang) is in the + user's path. Since we want XC to function properly whether or not + the user has /usr/lang in their path, I modified XC to use PUTENV to + add /usr/lang to PATH in the environment for the XC process, if f77 + is found in this directory. (If f77 is in some nonstandard location + then the user will already have the directory in their path). + (12/1) + +dev/hosts [tucana only] + Added madrona (George Jacoby) to network. + (12/4/90 FV) + +sys/qpoe/qpgettok.x + Edited the description of TOK_IDENTIFIER in the file header. The list + of legal identifier characters ommitted certain characters. (12/4) + +pkg/dataio/fits/t_rfits.x + Modified the rfits task so that it will supply a temporary root output + file name if old_irafname="yes" or quit with a clear error message if + old_irafname="no", in the case where the user sets the output file + to the null string "". (12/6/90 LED) + +dev/hosts + Modified the dev/hosts file on draco (iraf and irafx) so that + the kernel server was started on orion-gw rather than orion. + (12/6/90 jvb) + +pkg/system/cmdstr.x + Would ignore any parameter the name of which began with "mode". + Fixed to ignore only the mode parameter (I guess this is right; + actually it is not obvious if the mode parameter really has to + be skipped, although it should be safe to do so). (12/11) + +doc/ports/notes.dsux + Fixed a typo; a Dec 1990 date should have been Dec 1989. (12/13) + +sys/imio/impmap.x + The "flags" value was being passed to im_pmopen, rather than "mode", + causing im_pmopen to get an access mode of zero. This was harmless + when opening masks read only but prevented opening new masks. (12/14) + +sys/imio/immap.x + The case of a NEW_COPY .pl image (mask image) was broken out as a + special case. A mask image is created with mode NEW_IMAGE, set to + the logical size of the image being copied, and im_make_newcopy is + called to copy the header and other inheritable image attributes. + + This is not a normal create-mask operation because the new mask is + actually an image stored as a mask which is a new copy of another + image; this is not the same as a new mask which is created for use + with some reference image. The main difference is that a mask is + always associated with the physical image matrix, and inherits any + runtime section defined for the reference image, whereas an image + which is a new copy of another image is sized according to any + section defined for the old image. In other words, a new-copy .pl + mask-image created from a section of an existing image will be the + size of the section being copied, rather than the size of the full + image. Normal mask operations do not work that way, which is why + im_pmmap cannot be called directly in this case to make a NEW_COPY + mask. (12/15) + +sys/imio/impmmap.x +sys/imio/impmopen.x + The flag PL_BOOL (create boolean mask) was being set in IM_PLFLAGS + by im_pmopen, but that was incorrect as this routine doesn't have + access to the image descriptor. Moved the flag setting code to + im_pmmap. (12/15) + +sys/imio/impmhdr.x + +sys/imio/impmmap.x +sys/imio/imunmap.x + The IMIO image mask support was modified to save the image header in + the PLIO save file, and restore the header when the mask is later + mapped onto an image descriptor. The image title string and header + cards are stored in the mask "title" string as an arbitrarily long + string consisting of a number of lines of text. In effect, this + gives PLIO mask images (.pl images) the same header functionality + as, e.g., OIF format images. Mask images can now be dynamically + created, edited, etc., and have full headers, so they can be + considered full fledged images except for the one restriction that + the pixel type is always integer (with 28 bit unsigned integer + pixels). The semantics of accessing or copying sections, world + coordinates, etc., are the same as for any other image format. + Randomly accessing an image should be efficient despite the + compression, since the mask lines are compressed and indexed + individually. + + One possibly useful feature of image masks is that they represent + the first machine independent image format for iraf. Character + data is stored as byte packed ascii strings, and the save format + for mask image data is an MII short integer sequence. + + Mask images provide a general image compression capability for + integer images. If you try to store a floating image in a mask it + will work, but the data will be converted to integer (with + incredible compression if the data converts to zeros!). Since the + compression algorithm was designed for masks there will be little + compression for noisy 16 bit images. 32 bit integer images, or any + smooth (low noise) integer image will compress to some degree. + Compression factors for actual image masks, of course, will be very + large, with factors of 100-1000 being common. (12/17) + +sys/imio/iki/iki.h +sys/imio/iki/ikiinit.x +sys/imio/iki/mkpkg +sys/imio/iki/plf/README + +sys/imio/iki/plf/mkpkg + +sys/imio/iki/plf/plf.h + +sys/imio/iki/plf/plfcopy.x + +sys/imio/iki/plf/plfdelete.x + +sys/imio/iki/plf/plfrename.x + +sys/imio/iki/plf/plfaccess.x + +sys/imio/iki/plf/plfnull.x + + Added limited support to the IKI interface for PLIO image masks. + A new mini-kernel PLF was added; this consists of about half of + an IKI kernel (the access/copy/delete/rename primitives), with + the open/close, header access, and i/o functions being performed + directly in the IMIO code and in the IMPM code in IMIO. With + this change operations such as imaccess, imdelete, imrename, etc. + will work for .pl image masks as for the other image formats. + + In principle everything related to image masks should be isolated to + an IKI kernel, but the mask i/o stuff does not fit the current image + kernel model very well, and it was simpler to solve the problem as a + special case in the IMIO code. This will be cleaned up later as + part of the new image structures project when the IKI interface is + redesigned. (12/17) + +pkg/images/imfit/imsurfit.x +pkg/images/imfit/t_imsurfit.x +pkg/images/lib/pixlist.h +pkg/images/lib/pixlist.x + Changed the package prefix of the "pixlist" package, used internally + within IMSURFIT, from "pl" to "prl" (pixel range list) to avoid a + name conflict with the system interface PLIO. (12/18) + +sys/imio/immap.x + Modified so that the .pl extension does not have to be given + explicitly for the code therein to recognize a mask image. (12/18) + +sys/plio/plloadf.x + Modified to make specification of the .pl extension optional when + opening an existing save file. (12/18) + +sys/imio/immap.x +sys/imio/imunmap.x +sys/imio/iki/ikiinit.x +sys/imio/iki/plf/mkpkg +sys/imio/iki/plf/plfclose.x +sys/imio/iki/plf/plfupdhdr.x +sys/imio/iki/plf/plfopen.x + The special case nature of the code to map pixel mask images in + IMMAP led to further complications, to the point where it became + worthwhile to scrap this and move the open procedure into the + IKI PLF kernel where it belongs. Added open, update header, and + close procedures to the PLF image kernel and deleted the special + case code in immap.x and imunmap.x The main thing still missing + from this kernel is the i/o, which is still handled directly in + IMIO (pixel masks do not fit the virtual file model very well). + (12/20) + +sys/imio/imopsf.x + The code in this file which copies the descriptor of the reference + image was doing too much. Replaced by some code that copies only + selected fields. The concept of what a reference image means in + this case is still muddy, however, so I doubt if this stuff is right + yet. (12/20) + +sys/imio/imioff.x + The impkden computation could result in a divide by zero if the + logical block size was 1 char. Alignment does nothing in such a + case anyhow, so I put an IF around this code to skip it if the + logical block size is given as 1 char. This is the case in some + of the new image kernels which do not do anything so simple as + store pixels on a blocked device. (12/20) + +sys/qpoe/qpoe.h +sys/qpoe/qpgettok.x +sys/qpoe/qpioopen.x +sys/qpoe/qpioparse.x +sys/qpoe/qpexeval.x +sys/qpoe/qpexmodfil.x + QPOE has a parameter "deffilt" which can be used to define a default + event attribute filter for event i/o. Previously, either the default + filter was used or a user specified filter was used, i.e., if the + user specified a filter it would *replace* the default filter. This + was changed so that the user specifed filter would add to or modify + the default filter, on an attribute by attribute basis. In effect + the data is run through the default filter, then the result is run + through the user filter. + + The expected use of the default filter, which is stored in the + datafile with the data, is to exclude "bad" data from normal analysis. + Since all the data is nonetheless present, the default filter can + be overridden to get at the normally excluded data. This can be done + by editing the value of the deffilt parameter, deleting the parameter, + or by overriding elements of the filter in the user specified filter + at run time. + + For example, + + cl> countpoe "foo.qp[time:=@times]" + + would replace the time term of the default filter with the time list + from the file "times", preserving any other terms of the default + filter, whereas + + cl> countpoe "foo.qp[time+=@times]" + or + cl> countpoe "foo.qp[time=@times]" + + would modify the filter for the time attribute, passing only those + events which pass both the default time filter and the time filter + given in the file "times". The new assignment operator ":=" must + be used to override any existing filter term; if the usual "=" is + used, the default filter term, if any, remains in effect. + + The default filter is a string of the form "attr=expr[,attr=expr...]". + This is parsed at qpio_open time just as the user specified filter + is, hence the default filter may reference macros, include files, + etc. Operators such as qpex_getattribute and qpex_attrl will return + the final filter or range list as used to filter the data, produced + by combining the default and user filters. (12/27) + +sys/qpoe/zzdebug.x + Added a new debug task SETFILT, used to set the value of the "deffilt" + parameter in a QPOE datafile. (12/27) + +sys/qpoe/QPDEFS + 1. Added a comment at the top to make it more clear that this file + is only intended as an example of a QPDEFS file, and to give some + pointers regarding how to use the global macro facility. + 2. Changed the event structure definitions to match those now used + in qpoe$zzdebug.x. (12/28) + +sys/qpoe/qpexpand.x + This routine copies the input string to the output string, expanding + any macros or include file references in the process. The problem + was that qp_gettok returns a string token with the quotes removed, + and qp_expand was merely copying tokens out, resulting in the quotes + being stripped from string tokens. qp_expand was modified to + restore the quotes to string tokens written to the output stream. + I checked various other places where text is pushed back, and all + other instances preserved the quotes. (12/29) + +sys/qpoe/qpgettok.x + Added support for the builtin symbol or macro "$DFN". When + encountered in the input stream being processed by qp_gettok(), this + results in the datafile name being returned as a string token. This + can be used, for example, in macros used to call external tasks, + e.g., [time=`mytask($DFN,arg,...)`]. (12/29) + +sys/qpoe/qpiogetev.x + When rereading an event list opened and read earlier, and a PLRIO + descriptor was created, any existing PLRIO descriptor would not be + closed first. Added a plr_close call to deal with this case. (12/29) + +sys/qpoe/zzdebug.x + Added a new debug task TESTPOE, used to make simple artificial or test + qpoe files for testing purposes. This was used to check out a bug + report that events with x=y=1 would pass a filter containing a mask + which excluded this corner of the image, however I was unable to + duplicate the problem. (12/30) + +sys/qpoe/qpioparse.x + This routine was missing a call to qp_closetext(), causing it to leave + an open file descriptor behind. This would cause a task which did + many qpio_open() calls to eventually run out of file descriptors. + [FDEBUG is very useful to diagnose problems like this). (12/30) + +sys/qpoe/qpioopen.x +sys/qpoe/qpioclose.x + While working on other things I noticed that qpio_open() was not + setting the IO_EXCLOSE flag when calling qpex_open to open an + expression evaluator. This did not matter much as qpio_close was + not checking the flag to see if it needed to close the QPEX, but in + the rare circumstance that a new QPEX was set with qpio_seti() an + open descriptor would have been left behind. Also a QPEX passed in + with qpio_seti() woudl be closed by qpio_close() when it shouldn't. + Modified qpio_open() to set the flag and qpio_close to check it. + (12/30) + +lib/qpset.h +lib/qpioset.h +sys/qpoe/qpoe.h +sys/qpoe/qpio.h +sys/qpoe/qpseti.x +sys/qpoe/qpstati.x +sys/qpoe/qpioseti.x +sys/qpoe/qpiostati.x +sys/qpoe/qpmacro.x +sys/qpoe/qpioopen.x + Since the default filter (and probably mask eventually) are now much + more dangerous or noticeable than previously, I added switches in all + the usual places to disable the use of these defaults. Specifically, + in we have + + QPOE_NODEFFILT + QPOE_NODEFMASK + + (default off, i.e., use default filter or mask. In we + have the same thing, just at the level of a specific QPIO descriptor: + + QPIO_NODEFFILT + QPIO_NODEFMASK + + And for global control by the user we have the new global set options + + set nodeffilt + set nodefmask + + which do what they say (omit or comment out these definitions to + enable use of the default filter and mask). (12/31) + +sys/qpoe/qpioparse.x + As an alternative to the "attr := expr" syntax, which can only + override any earlier filter terms for the referenced attribute (such + as terms of the default filter) I added some new syntax which can + disable the entire default filter and mask for a particular filter + expression. This is done by adding a "!" after the leading "[", and + before the new filter, e.g.: + + display "foo[!time=@times.lst,pha=(3,8:11)]" + + would temporarily disable both the default filter and mask. This + does not affect the use of ! within expressions since an expression + cannot be the first term of a filter. (12/31) + +sys/qpoe/qpioopen.x + A QPOE file is supposed to be able to contain more than one event + list, so the default filter/mask facility was modified to permit + a different default filter or mask to be specified for each event + list. For example, to define a default filter for event list "foo", + one would insert the parameter "deffilt.foo" into the datafile. + When looking for the default filter or mask, qpio_open() will look + first for the "def[filt|mask]." parameter, then "def[filt|mask]". + (1/1/91) + +sys/qpoe/qpiolmask.x +sys/qpoe/qpioopen.x +sys/qpoe/qpiosetfil.x + The default mask mechanism was modified to provide the same + semantics as the default filter. If a default mask is defined and + nodefmask is not set, the default mask is used as a spatial filter + for event i/o. If a default mask is defined, nodefmask is not set, + and a user mask is also specified, the user mask is edited using the + default mask as a stencil (the new mask is the user mask, with only + those pixels set which were also set in the default mask). Setting + nodefmask, QPOE_NODEFMASK, QPIO_NODEFMASK, or using ! or mask:= in a + filter expression disables the default mask. If the mask is set + with an explicit qpio_seti() call the default mask is ignored. (1/1) + +sys/plio/plsten.x + This routine was evidently not working at all, due to an internal + interface change that was never propagated to this routine. The + call to pl_linestencil was missing the maxpixval argument for both + the source and destination line lists. (1/1) + +sys/qpoe/qpexcode.gx + The QPEX parser syntax for bitmask expressions was generalized + somewhat to permit expression negation and parens, e.g., "%1", + "!%1", "!(%1)", "!(!%1)", etc. are now handled properly. Range + lists are still not supported for bitmask expressions, as it is + not clear that such a feature would be useful (one can just enter + a different bitmask instead). (1/1) + +sys/qpoe/README + Updated this file to reflect all recent changes to the QPOE + interfaces. (1/2) + +pkg/dataio/doc/rcardimage.hlp +pkg/dataio/cardimage/t_rcardimage.x + Modified the rcardimage help page to include an example of how + to reformat an odd-blocked cardimage tape with reblock. + Modified the rcardimage task to print a clearer error message + when it encounters an odd-blocked rcardimage tape. (1/3 LED) + +pkg/system/help/help.par +pkg/system/help/t_help.x +pkg/system/help/tlist.x +pkg/system/help/help.h + The HELP task was modified to add a new parameter "curpack", default + value "AskCL". With this default the help task will issue a clcmdw + to ask the CL the name of the current package; this is necessary to + preserve the current semantics of HELP (in the case of task redefs, + help for the task in the current package is returned). The reason + for the new parameter is to allow the current package to be + specified explicitly to avoid the clcmdw query, e.g., when calling + the task at the host level. (1/4) + +dev/hosts + Added noctua to iraf hosts table. (1/8/91 SRo) + +pkg/dataio/fits/fits_rimage.x +pkg/dataio/fits/fits_wimage.x + The scaling routines in rfits and wfits were modified to minimize + the precision lost when converting from real pixels to fits integers + and vice versa. (1/17/91 LED) + +dev/hosts + Added aquarius to iraf hosts table on tucana and Draco/iraf. + (1/17/91 jvb) + +unix/hlib/extern.pkg [orion, tucana] + Added steward package at iraftest level after numerous discussions. + (1/22/91 SRo) + +dev/devices [ursa] + Added argo and libra exabytes, since these machines are hosted by + ursa now. Just tacked onto the end (mt[fgh]); perhaps we should + establish noao conventions for which letters represent 9track, + cartridge, exabyte, dat. (1/28/91 SRo) + +pkg/images/gradient.par +pkg/images/laplace.par +pkg/images/gauss.par +pkg/images/convolve.par +pkg/images/doc/gradient.hlp +pkg/images/doc/laplace.hlp +pkg/images/doc/gauss.hlp +pkg/images/doc/convolve.hlp +pkg/images/filter/t_gradient.x +pkg/images/filter/t_laplace.x +pkg/images/filter/t_gauss.x +pkg/images/filter/t_convolve.x +pkg/images/filter/convolve.x +pkg/images/filter/xyconvolve.x +pkg/images/filter/radcnv.x + Modified the convolution operators (laplace, gauss, and convolve) to + make use of symmetries in the convolution kernel to compute the + convolution much faster. Laplace now makes use of radial + symmetry in the y direction as well as the x direction + resulting in a modest decrease in execution time. Gauss now + computes 2 indepedent 1D convolutions in x and y if the user + specified kernel is separable in x and y instead of the full 2D + kernel. (1/29/91 LED) + +dev/hosts + Added Doug Rabin's mozart to irafx host table. (1/30/91 SRo) + +-------------------------- +Tucana system upgraded from SunOS 4.0.3 to 4.1.1. (2/4) +Began revisions of Sun/IRAF to support SunOS 4.1. (2/5) + +./* + The iraf root was relocated to /u3/iraf on tucana, retaining link + at /usr/iraf. All of the iraf runtime files (sources and bins) are + now consolidated on /u3. (2/6) + +unix/* + Did a bootstrap of the system (mc68020 version) under 4.1.1 without + incident. (2/6) + +local/.login +local/.exrc + Made a number of changes for 4.1.1. Added OPENWINHOME and MANPATH + definitions. Added /usr/lang (default location of new Fortran + compiler) to the default PATH. FLOAT_OPTION is no longer defined + as it is not used by the new compilers and causes a warning message + to be issued. The default IRAFARCH for Sun-3 systems is now f68881 + if the f68881 binaries are installed. EXINIT is no longer defined, + added a .exrc file instead to allow for vi macros such as the very + useful "@". Deleted the susp/eof control in STTY, it seems time to + abandon the DEC defaults and go with the UNIX standard ctrl/z and + ctrl/d instead. (2/6) + +unix/boot/spp/xc.c + The SunOS version of XC was modified to look for the IRAFARCH + environment variable and add a -f68881, -ffpa, etc. switch to the + f77 or cc command line. Specifying any switch beginning with -/f on + the XC command line overrides the use of IRAFARCH. With this change + the architecture used for both compilation and linking is controlled + entirely by IRAFARCH, and FLOAT_OPTION is no longer used. So long + as IRAFARCH is specified and all modules of a program are compiled + with the same setting, mixing of modules or libraries compiled for + different architectures is ruled out. (2/6) + +unix/shlib/edsym.c + Looking at the edsym code I note that lseek(fd,o,L_SET) is now + considered obsolete and one is supposed to use lseek(fd,o,SEEK_SET) + instead, including to define SEEK_SET. L_SET is still + defined for backwards compatibility so I think I will leave things + as they are for now. (No changes.) (2/6) + +unix/shlib/mkshlib.csh + 1. Modified to support the new Sun V1.3 Fortran compiler. The iraf + shared image is linked explicitly with LD and it is necessary to + specify exactly the directories, objects, and libraries to be + linked. These are much different for the new compiler than for the + old one. For example, for f68881 one links with + /usr/lang/SC0.0/crt0.o, /usr/lang/SC0.0/f68881/_crt1.o, the libm.a + in SC0.0/f68881 (linking with the SC0.0 version of libm.a causes + Mlog10[ds] to be unresolved), and the libF77.a in SC0.0. In + principle the directory /usr/lang can be relocated so this is + defined as a variable at the top of the file. + + 2. The following error message was being reported (by edsym) when + linking shared with XC under SunOS 4.1: + + cannot read shared image version number from .e + + In the code which generates the S.s file (the shared library) I + moved ushlib from data space to text space. Evidently under 4.1.1 + the system is more clever and can have initialized data at addresses + for which corresponding file offsets do not exist in the executable + file. This results in a seek to an offset beyond the end of the .e + file, leading to the error message shown above. Since ushlib is not + modified at runtime we can just as easily have it in text space, + which avoids the problem. A simple workaround for this problem is + to link -e (no edsym symbol table editing). (2/6) + +unix/hlib/mkpkg.inc + Added -libmil (use inline templates) and -dalign (double align type + double data) to the list of default mkpkg compile switches for the + new compiler. By default the compiler will use optimization level -O3 + and on a Sun-4, will compile -cg87. This latter option is necessary + for code compiled for a Sun-4 to run on both older and newer Suns, + which have different floating point units. There is another option + -cg89 which tells the compile to take advantage of certain features + of the newer floating point units (e.g. hardware sqrt) but we can't + use that for binaries that must run on all sparc systems. (2/6) + +unix/hlib/mkpkg.sf.SUN3 +unix/hlib/mkpkg.sf.SUN4 + Commented out all the bug entries, we should start over with this + new compiler. (2/6) + +--------------------- +Started full f68881 sysgen/recompile. (2/6) + +unix/hlib/mkpkg.sf.SUN3 + The files vops$ak/{abnekx.x,abnex.x} and vops$lz/aveqx.x, all of + which contain equality comparisons of complex numbers, produced the + following message from the V1.3 compiler: + + warning: unexpected parent of complex expression subtree + + Compiling the files without optimization avoids the problem. The + floating point or complex equalities used in these routines are + questionable, but there does not appear to be anything wrong with + the code. (2/7) + +unix/boot/spp/xpp/decl.c + The d_runtime() routine returns in a char argument any runtime + initialization text needed for a procedure. The routine would do + nothing if no initialization was required, which was incorrect, as + any old text in the string buffer argument would then be reused. + Modified to write an EOS into the output string in this case. + This bug was introduced as a result of a recent change in V2.10 + iraf. (2/7) + +pkg/cl/compile.c + The CL failed to come up after the sysgen. This was eventually + traced to the compile() function. This contains a register flag + "status" which was used without being initialized. The routine + would operate correctly provided the (random) value of the variable + was anything other than ERR. This is highly likely which is why + the bug has gone undetected for so long. (2/7) + +unix/sun/Makefile + Changed the suggested values of FLOAT from fswitch/fsingle for + Sun-3/other to -f68881/"". (2/7) + +----------------------------------- +Sysgen of f68881 binaries for core system completed. +Sparc bootstrap completed; sparc sysgen begun. +Sysgen of f68881 binaries for noao packages begun. (2/7) + +unix/hlib/mkpkg/host.c + In the sparc sysgen I got an error message complaining that a $purge + directive had failed. It turns out that the unix/iraf version of + h_purge in host.c is a no-op and does not even return an exit status, + which is incorrect as the status of the routine is checked by the + portable mkpkg code. I modified it to always return an exit status + of OK. Checking the rest of the routines in the file, there was + one other routine which inconsistently returned status values and I + fixed that as well. (2/8) + +unix/hlib/mkpkg.inc + Deleted the "-dalign" switch from all X*FLAGS entries. It turns out + that the CL does not begin to double align double data, and cannot + be easily modified to do so, so this cannot be used, at least with + the CL C code (SPP pretty much double aligns all double data so there + is no problem there). This option only affects Sun-4s, i.e., the + already compiled f68881 code is not affected by this switch. (2/8) + +----------------------------------- +ffpa sysgen begun. (2/8) + +unix/boot/spp/xc.c + The ffpa sysgen went fine except that all the links failed with a + ffpa_used unresolved external message. This was occurring due to + the -Bstatic and the reference was occuring in one of the C libraries. + It was necessary to add a -f switch to the CC command + used for the link to avoid the problem. XC explicitly links all the + right Fortran libraries for a given architecture, but it is still + necessary to pass the -fxxx flag for the benefit of the C libraries. + (2/8) + +bin.ffpa/S.e +bin.f68881/S.e +bin.sparc/S.e +unix/boot/spp/xc.c + Since shared image version support has been around for a year or so + and V2.10 no longer uses the older shared images I deleted S.e and + S4.e in the recent sysgens, leaving only the current (actually V2.9) + shared image S5.e. It turns out however, that XC needs to have a + file entry S.e in the directory containing the real shared image in + order to permit runtime searching to find the file (runtime searching + is necessary to provide architecture support, IRAFULIB support, etc.). + XC could search for S.e except that it is difficult to determine + the shared image version number. The simple solution was to add a + file entry S.e in each of the core system BIN directories. This is + not an actual shared image, rather a zero length directory entry used + to flag the directory containing the real shared image or images. + If this marker file is not present the system will still run, but + link time EDSYM symbol editing will be disabled. (2/10) + +unix/shlib/mkshlib.csh +unix/os/zmain.c +unix/os/zzstrt.c +unix/os/zshlib.c + It turned out that zmain/zzstrt were using the ushlib vector to pass + the sh_debug flag, used to map the shared image text writable so + that debug breakpoints can be set (as in :r -w in adb). This was a + bit of a trick and doesn't work any more since I moved ushlib to the + text segment, so I made sh_debug an explicit variable in data space. + It is defined in the shared library (libshare.a) or in zshlib.o if + linking unshared. (2/10) + +unix/hlib/install + I added a rm -f preceeding each ln -s, since ln will not clobber + any existing link. This could occur in certain cases when link + /usr/include/iraf.h already existed but had the wrong value. (2/10) + +unix/as.sparc/oscmd.s + +unix/hlib/mkpkg.sf.SUN4 + After the sparc sysgen with the new compiler all OS escapes would + fail with the error "cannot open `A'". This was traced to a host + compiler error for file oscmd.x. The null string "" was being passed + to a subroutine; in Fortran this is a short array of length 1 + initialized to zero, but the compiler was initializing the value to + random garbage, in this case A (in tests I ran other values were + generated). Other identical cases of "" being passed to subroutines + in the same file were compiled correctly. Compiling without + optimization did not help, so I had to edit the assembler and place + the file on the special file list. (2/10) + +--------------------------------- +SunOS 4.1.1 / Sun Fortran 1.3.1 upgrades completed (except for full +testing and further bug fixing). (2/10) + +iraf/dev/devices [Ursa only] + Added mti to the devices file for libra's 9track tape drive. It + was interesting that there was no entry in the devices file when + libra was served by orion - but then the host names were the same + for both orion and libra's mtas. + +sys/qpoe/qpioparse.x + The event list filter syntax supports runtime specification of the + event coordinate system to be used with the notation key=(xoff,yoff) + where xoff,yoff are event field specifiers, e.g., (s0,s2). Fixed + two problems with the code in this routine which parses the KEY + keyword: 1) whitespace etc. was not being skipped properly, causing + the key= expression to be rejected, and 2) the offset values were + being used directly, which is incorrect, since at the user level + event struct offsets are specified in bytes, whereas in the QPIO + descriptor short integer offsets are used for efficiency reasons. + With these problems fixed the key=(x,y) feature checks out, i.e., + QPIO itself handles the key properly and it was only the parsing + routine which had problems. (2/10) + +dev/devices [tucana] + deleted mt device aliases no longer used in OS 4.1.1 (2/12 ShJ) + +sys/qpoe/qprenamef.x + This routine renames a header parameter by creating a new one and + setting the deleted bit in the old one. There was a subtle bug + which could cause the old parameter to fail to be deleted. The + routine was indeed setting the delete bit in the symstruct of the + old parameter, but it was doing so *after* adding the new parameter + to the SYMTAB symbol table. This was not correct because the + symstruct of the first parameter was being referenced by an absolute + pointer the value of which was computed before the new parameter + was added. In SYMTAB adding a new parameter can cause the symbol + table to be reallocated, invalidated any such pointer. (2/13) + +sys/qpoe/qpgnfn.x + 1. The pattern string input by the user was being used almost directly, + after only * -> ?* mapping. Any match was accepted. This is + incorrect because we want to accept matches which only match the + *entire* field name. It is necessary to constrain the match to + begin at the beginning of the string being checked, and verify that + the entire string is matched. + 2. Sorting was not working correctly. The package was using zero + indexed string buffer offsets internally, and calling STRSRT with + this index array. This is incorrect because STRSRT expects a one + indexed index array. The result was that the list would be sorted + ignoring the first character of each string. (2/13) + +sys/qpoe/zzdebug.x + Added a "sort" parameter to the HLIST task. (2/13) + +sys/imio/db/imgnfn.x +sys/imfort/db/imgnfn.x +pkg/images/doc/hedit.hlp + Since the QPOE gnfn code was derived from IMIO I figured the IMIO + code might have the same bug and indeed it did (the pattern matching + bug, not the sort bug). Fixing this should fix the problem of HSELECT + matching field names using a prefix-match rather than full match. + The IMIO version was mapping * to ?* and was constraining the match + to the beginning of the name, but was not checking for a full + length match. This was not completely trivial as the name being + matched is embedded in a FITS card, hence space or "=" terminates + the name, rather than EOS. (2/13) + +sys/ki/ki.h +sys/ki/kighost.x + Added support for an optional environment variable "irafhostnametable". + If defined, this specifies the host pathname of the hosts file to be + used for iraf networking. The default is dev$hosts. (2/13) + + [Changed variable name to "irafhnt". The original name was too long, + this could conceivably cause problems on some systems. (5/13)] + +unix/hlib/mkpkg.sf.SUN4 + Evidently with the latest OS, the sparc register set is no longer + saved with the version of SETJMP found on a Sun-4. This would cause + a process executed on a Sun-4 to die in the iraf main during error + recovery, upon return from the ZSVJMP call. Compiling without + optimization so that the compiler does not cache values in registers + seems to avoid the problem. I added etc$main.x to the special file + list to be compiled without optimization, although this is probably + going to be sufficiently common problem that we might want to + consider some more machine independent way of always compiling + without optimization routines that use ZSVJMP. (2/14) + +pkg/images/doc/hedit.hlp +pkg/images/doc/hselect.hlp +pkg/images/doc/imheader.hlp +pkg/images/doc/imgets.hlp + Added a reference to the imgets and imheader tasks in the SEE ALSO + sections of the HEDIT and HSELECT tasks. Added a reference to the + HSELECT and HEDIT tasks in the SEE ALSO sections of the IMHEADER + and IMGETS tasks. (2/22/91 LED) + +pkg/images/imfit/imsurfit.x + Fixed a bug in the deviant pixel rejection code in the IMSURFIT + task. If the parameter upper > 0 and lower = 0.0 or vice versa + the rejection limits were not being computed correctly. In the + former case all point with negative residuals were rejected + instead of none and in the latter case all points with positive + residuals were rejected instead of none. (2/25/91 LED) + +sys/fio/getlline.x +sys/fio/glongline.x + Added some comments to the file headers noting that the size of + the output buffer must be at least SZ_LINE characters larger than + the length of the longest line to be read. (3/01) + +sys/mwcs/iwewcs.x + The value of the (obsolete) FITS keyword CROTA2, which is input in + decimal degrees, was being used without first converting to radians. + There is no problem when the CD matrix notation is used instead. (3/12) + +pkg/images/tv/display/sigl2.x + The routine si_blkavgs, which is used to block average an image + (when scaling a large image to fit into a small display window) + would accumulate the sum of several short integer image lines in + a short integer buffer. This could lead to integer overflow in + the case of images with large pixel values. The routine was + modified to accumulate into a buffer of type long. (Note that + the problem affected only block averaging in Y, X was being + handled correctly by the vector operator ABAV.). (3/20) + +dev/hosts + Updated grus from 68881 to sparc. (3/21/91 SRo) + +dev/hosts + Added herbie, Stuart Jeffries' new workstation to table. (4/2/91 SRo) + +sys/fio/fstati.x +sys/fio/fmkpbbuf.x + 1. A fstati on F_UNREAD returns the number of unread characters in the + file buffer. This was ignoring any pushback; the fstati routine was + modified to count pushed back data as well as any data remaining to + be read in the current buffer area. Zero will be returned only if + the file buffer is empty and there is no pushed back data. + 2. fmkppbuf (make pushback buffer) will now automatically create the + normal file i/o buffer if any pushback occurs. Probably this is not + necessary but we may as well make sure that pushback before any file + i/o occurs is not different than after i/o has occurred and a buffer + has been created. (4/2) + +sys/imio/iki/oif/mkpkg +sys/imio/iki/oif/oifgpfn.x + Added an "include " to oifgpfn.x. This is needed for the + zfsubd call in the routine. (4/3) + +sys/ki/kfsubd.x + Was not returning the length of the output string correctly in + the case of a file on the local node, but with the node name + prefix included. (4/3) + +dev$hosts + Added khaki, lapis, taupe, scarlet, and elsol to dev$hosts on + tucana, orion, gemini, and ursa. (4/5 jb) + +pkg/images/geometry/geofit.x +pkg/images/geometry/geogmap.x +pkg/images/doc/geomap.hlp + Cross-term fitting will now work in the case where xxorder=2 + and xyorder=2 (x fit) and in the case where yxorder=2 and + yyorder=2 (y fit). (4/9/91) + +dev$hosts + Added aliases to dev$hosts on tucana, orion, gemini, and ursa + for machines on mountain (machine.kpno.noao.edu). (4/10 jb) + +hlib$extern.pkg + Swapped RV0 for RV since this will be the new package. No tucana + users are working w/ RV at present anyway. (4/16 MJF) + +pkg/images/geometry/t_blkavg.x +pkg/images/geometry/blkavg.gx +pkg/images/geometry/blkavg.x + The blkavg task was partially modified to support complex image data. + The full modifications cannot be made because of an error in abavx.x + and the missing routine absux.x. (4/18/91 LED) + +pkg/images/imarith/t_imcombine.x + Changed the order in which images are unmapped to unmap the output + images last. Closing the input images frees file descriptors + which are needed for the temporary file used when updating + STF images. Previously IMCOMBINE would fail for STF images which + used the full number of file descriptors, had a sigma output + image, and a logfile. (4/22/91, Valdes) + +math/curfit/cv_b1eval.gx +math/curfit/cv_beval.gx +math/curfit/cv_feval.gx +math/curfit/cvaccum.gx +math/curfit/cvacpts.gx +math/curfit/cvchomat.gx +math/curfit/cvfree.gx +math/curfit/cvinit.gx + Did some cleaning up in the .gx files to make the code easier to + read. (4/23/91, LED) + +sys/ki/ki.h + Increased the maximum number of nodes from 64 to 128. This is only a + stopgap measure; eventually the code should be rewritten to eliminate + the fixed size static host name table. (4/29) + +dev/devices.hlp +dev/graphcap +dev/termcap + Added "lw6" and removed "imagen" from these files on tucana, gemini, + ursa, orion and irafx@draco. (4/30 ShJ) + +pkg/images/doc/imarith.hlp + Fixed some formating problems in the IMARITH help page. (5/2/91 LED) + +math/curfit/cvpower.gx + Changed the amovk$t (INDEFR,,,) call to amovk$t (INDEF,,,) to avoid + the double precision version of the routine being called with + INDEFR. This problem was caught with f2c on the Mac. (5/6/91 LED). + +math/gsurfit/gs_f1deval.gx + Changed the amulk$t (,,,2.,,,) call to amulk$t (,,,2$f,,,) to remove + a type dependency mismatch in the routine. This problem was caught + with f2c on the Mac. (5/6/91 LED). + +math/curfit/cverrors.gx +math/curfit/cvpower.gx +math/curfit/cvrefit.gx +math/curfit/cvrestore.gx + Finished cleaning up the .gx files in the curfit directory. (5/6/91 LED) + +unix/hlib/login.cl + The line + + if (access ("home$loginuser.cl") cl < "home$loginuser.cl" + + causes the following statement to be ignored if the IF is true. + This is a CL bug, but for now the workaround is to add a null + statement ; to the line following the IF. (5/6) + +unix/sun/imtoolrc + Added a new config imt31|imtret for the Reticon CCD (1240x400_ + at the request of CTIO. (5/8) + +lib/math/curfit.h +lib/math/gsurfit.h +lib/math/iminterp.h +lib/math/interp.h +lib/math/surfit.h + Added dictionary string definitions for the interpolator types and + weights. Use of these strings insures that strdic/clgwrd will + return the correct type code. Currently one has to assume the code + definitions will not change or put a lookup table with a data + statement containing the macro definitions. The code would also + have to be modified to add new types. The dates were restored to + their original values to avoid recompilation. (5/9, Valdes) + + [I updated the dates on the above files and performed sysgen updates + over the weekend. It is dangerous to modify files without modifing + the file date, as this can break various automatic system maintenance + procedures. (5/11DCT)] + +unix/hlib/login.cl + The noao and proto packages are now loaded by default in the standard + login.cl. This indirectly includes images, tv, and plot. (5/11) + +pkg/images/imarith/t_imarith.x + There was a missing statement to set an error flag if the operand + image dimensions do not agree. (5/14/91, Valdes/Schaller) + +pkg/images/minmax.par +pkg/images/imutil/t_minmax.x +pkg/images/imutil/minmax.x +pkg/images/doc/minmax.hlp + Modified the minmax task to compute the minimum and maximum + pixel values with the correct precision if the input images are + of type double precision or complex. Note that does not get + around the fact that the minimum and maximum pixel values are + stored in the image header as type real. (5/16/91 Davis) + +pkg/images/listpixels.par +pkg/images/iminfo/listpixels.x +pkg/images/doc/listpixels.hlp + Modified the listpixels task to print the image pixel coordinates + in logical, physical or world coordinates. The default is logical + as before. (5/17/91 Davis) + +unix/boot/spp/xc.c +unix/boot/mkpkg/main.c +unix/boot/mkpkg/mkpkg.h + These tasks have supported multiple -p pkg arguments for some time, + but would only pass one such argument on to subprocesses. XC was + modified to pass multiple -p pkg arguments on to XPP and MKPKG was + modified to load the mkpkg.inc file for multiple enviroments + (formerly it would load multiple environments, but would only read + one mkpkg.inc in addition to the global core system one). The PKGENV + environment variable was generalized; this can be now be a + whitespace delimited list of packages, not just a single package + name. It was not necessary to modify MKPKG to pass -p pkg stuff + on to XC, since this is done explicitly in the package mkpkg.inc + files (by redefining XFLAGS and LFLAGS). (5/21) + +sys/vops/asqr.gx + Changed to test for <0 rather than <=0, since taking the square root + of zero is a legal operation. (6/3) + +pkg/dataio/fits/fits_read.x +pkg/dataio/fits/fits_write.x + Modified the fits reader and writer to deal correctly with + image sections in the IRAFNAME header parameter. (11/6 LED) + +pkg/images/iminfo/imhistogram.x + The imhistogram task has been modified to print out the value + at the middle of the histogram bin instead of the value of the + left most edge if the output type is list. (11/6 LED) + +pkg/dataio/doc/wfits.hlp +pkg/dataio/fits/wfits.h +pkg/dataio/fits/t_wfits.x +pkg/dataio/fits/fits_write.x +pkg/dataio/fits/fits_wheader.x + The wfits task has been modified to write IEEE format FITS files, + fits bitpix = -32 and -64, instead of scaled integers if the input + image pixel type is real or double respectively and if the wfits + parameter bitpix is left at the default. If the user overrides the + default and elects to scale the data, a warning message with an + estimate of the maximum precision loss is provided. (11/6 LED) + +dev/termcap + Fixed typo so that "stty wyse" works, not just "stty wyse75". + (6/12/91 SRo) + +dev/devices [gemini only] + Updated the devices file on gemini for Tom Duvall's two Exabytes + on his workstation. They are called rst0 and rst1 so this + causes duplicate entries in the devices file for different + mt[devices]. (6/13/91 jb) + +sys/etc/mkpkg +sys/etc/qsort.x +sys/etc/xqsort.x + + Added a new routine XQSORT, a variant on the old QSORT routine. + This is identical to qsort except for an extra argument which is + private to the compare routine and merely passed on to the compare + routine by xqsort. The intent of this is to avoid the need for + initialization routines and commons to pass context information + on to the compare routine. The datatype of the "private data" + argument is int but a pointer can be passed as well, as in C where + an integer cast is used to pass pointer data in an integer. Since + a pointer can be passed, if necessary any arbitrarily complex + descriptor can be passed on to the compare routine. (6/15) + + !NOTE -- the name of this procedure had to be changed to "gqsort". + !See note below. (6/27) + +lib/clio.h +lib/clset.h +sys/clio/README +sys/clio/mkpkg +sys/clio/clcache.x +sys/clio/clstati.x +sys/clio/clepset.x + +sys/clio/clgpseta.x + +sys/clio/clppseta.x + +sys/clio/clgpset.x +sys/clio/clppset.x + 1. Added a full CLIO interface definition to the README file. + + 2. The pset routines cl[gp]pset, used to get/put the values of + string valued parameters, where named to cl[gp]pseta as the old + names were too misleading (what does it mean to get/put a pset). + The old routines are retained for compatibility but are now + considered obsolete. + + 3. The CLGFIL routines are also now considered obsolete. clgstr + and fntgfn etc. should be used instead. It doesn't make any sense + to have a system routine that arbitrarily combines two such + different facilities as get-string and the file name template + package (if this is justified then any number of other equally + logical combinations are possible too). + + 4. Added a new routine CLEPSET to the pset package. This is called + to "edit" a pset. So far as the application is concerned all this + means is that the pset values can be changed by the operation. In + the specific case of the current combination of CLIO and the CL, + EPARAM is called to edit the pset and the edited values are updated + in the parameter cache in the local process. This routine is still + considered experimental. (6/22) + +pkg/cl/task.h +pkg/cl/exec.c +pkg/cl/opcodes.c + Minor changes to the CL were required to support the CLEPSET + routine. clepset uses dparam to efficiently obtain the edited pset + and update the local parameter cache. A way was needed to redirect + the output of a task like dparam back to CLIO in a subprocess. A + hidden special file ("IPC$IPCIO-OUT" currently, but this could + change at any time) was defined such that if a task is run with the + output redirected as in "dparam > IPC$IPCIO-OUT" the stdout of the + task is sent to t_out, the CLIN of the subprocess which issued the + command. When the task terminates the message "# IPC$IPCIO-FINISHED\n" + is sent to mark the end of the output from the task. + + These changes are considered internal to CLIO. The method used to + implement this feature is a minimum-modification approach which + only solves a part of a more general problem, hence this facility + should not be used outside of CLIO. (6/22) + +sys/clio/README +sys/clio/clcache.x +sys/clio/clio.com +sys/clio/clepset.x +sys/etc/main.x + 1. Added a new routine clc_compress() to the CLIO parameter cache + code, with a call to this routine in clepset(). The caching + mechanism handles parameter updates by simply redefining the + parameter and its value in the symbol table; if there are many + parameter updates significant wasted space can result. clc_compress + rebuilds the cache symbol table, saving only the most recent entry + for each parameter. + + 2. Modified clc_init() to permit it to be called repeatedly to + reinitialize the parameter cache. Modified main.x to use clc_init + instead of clc_mark/clc_free to reinitialize the cache before + running a task. This was done to eliminate the external marker, + which would be invalidated after rebuilding the cache symbol table + in an operation such as clc_compress. (6/23) + +sys/gio/imdkern/idk.x + The arguments "frame" and "color" to the idk_open procedure were + being modified by the procedure, causing the external values to be + preserved across open/close workstation calls. This was causing + the automatic frame number detection logic to fail when displaying + to multiple frames without restarting the kernel. (6/23) + +sys/clio/README +sys/clio/mkpkg +sys/clio/clcache.x +sys/clio/cllpset.x + + Added a new routine clc_list(fd,pset,format) to the parameter + cache package, and a corresponding routine cllpset(pp,format) to + the pset package. These are used to list the contents of a pset, + or of the full parameter cache, to an output file using a caller + specified format. (6/23) + +sys/fio/fseti.x + Added a call to fcanpb() in the F_CANCEL code to cancel any pushed + back input. (6/24) + +dev/hosts + Added radix (Richard Green) to host table. (6/27/91 SRo) + +sys/etc/mkpkg +sys/etc/qsort.x +sys/etc/xqsort.x - +sys/etc/gqsort.x + + It was necessary to change the name of the recently added procedure + "xqsort" to "gqsort" to avoid a library name conflict. The old + qsort procedure is defined in hlib$iraf.h as "xqsort". The best + thing to do would have been to change this definition to something + more obscure, but this would have required recompiling all existing + applications that use qsort, and worse, since there would be a new + procedure xqsort with a different calling sequence, existing + applications using the new shared image would get the new xqsort + and would have died with a segvio when the program was executed. + It is easier to pick a new name then force recompilation of the + existing applications. (6/27) + +dev/termcap +dev/graphcap + Added new entry for pericomdg submitted by Skip Schaller. Modified + existing termcap entry for vi501 as suggested by Alan Koski. (7/5 ShJ) + +dev$hosts + Added aliases to dev$hosts on tucana, orion, gemini, ursa, + and draco for downtown node "morrison". (CB, 7/5/91) + +ursa!hlib$extern.pkg + Set ccdacq as a top level package to point to /u2/rooke/ice/ccdaqcq. + (7/5/91 SRo) + +sys/pmio/miogl.x + The activation code in this routine was not initializing the "ve" + vector. The error was harmless in the typical case where the + i/o range is the full image, but could lead to an error when + mio_setrange was used to specify a subregion, becasuse the "ve" + vector was only used in the latter case. (7/6) + +sys/pmio/zzdebug.x + Added a "region" parameter to the MIO zzdebug task, to allow testing + of mio_setrange. (7/6) + +sys/imio/db/imgnfn.x +sys/imio/db/idbkwlu.x +sys/imio/db/imgftype.x +sys/imio/db/idbpstr.x +sys/imio/db/idbgstr.x + 1. The image keyword list (gnfn) stuff, which was modified earlier + to require full keyword matches for header keywords, would still + permit partial matches for the standard builtin keywords (there + was a second call to patmatch, used to check the stadard keywords, + which was missed earlier). + 2. Tightened up the keyword matching performed on the naxisN keywords. + Formerly there would have been a conflict if a user keyword happened + to have a name such as "naxisNfoo". + 3. In imgftype, there was some code in the procedure to check for + "i_" and naxisN which was apparently redundant (idb_kwlookup already + does this) so I deleted the code. (7/8) + +pkg/system/help/helpdb.x +pkg/system/help/helpdir.x + 1. Added a new routine hd_debug to helpdir.x. This dumps the + descriptor of a compiled help directory to a file and is used for + debugging purposes (it is not used in the runtime system). + + 2. The routine hdb_make_rhd, used to make the root help directory + (directory of packages), contained a line HD_NMODULES(hd) = + HDB_NENTRIES(db) which was incorrect; this could add extra, + unitialized modules to the help directory just assembled, possibly + leading to a segementation violation when later the unitialized + entries were referenced. This was causing segmentation violations + when many external packages were loaded (the bug would only come + into effect with root help directories, and each external package + has one). The bug has always been there, it is just more likely to + cause a problem when there are many packages. (7/10) + +sys/qpoe/qpexmodfil.x + A filter expresion such as "foo = expr" is supposed to be the same + as "foo += expr", adding to any existing filter term, instead of + replacing the existing filter as with "foo := expr". This code had + it the other way around, i.e., = was the same as := (replace). (7/15) + +unix/hlib/login.cl + Modified the template login.cl as follows: + 1. Added code to check the environment variable TERM, if it exists, + for the special cases "sun" and "xterm". This won't work in many + cases but should make it easier for people to customize things if + they want, without requiring a loginuser.cl. + 2. If the file ".hushiraf" is seen during login the message of the + day is not printed and cl.menus is set to no. This makes it + possible to get a simple cl prompt without all the other verbiage + being printed, which experienced users don't necessarily want + to see during every login. + 3. Deleted some old stuff that has been commented out for quite a + while without causing problems. (7/15) + +pkg/system/doc/mkdir.hlp + Fixed a typo. (7/18) + +dev/hosts + Added enzo to the hosts table (Frank Hill's new machine). Did this on + tucana and gemini. (7/19 jb) + +pkg/images/imarith/imc* - +pkg/images/imarith/ic* + +pkg/images/imarith/t_imcombine.x +pkg/images/imarith/mkpkg +pkg/images/imarith/generic/mkpkg +pkg/images/imcombine.par +pkg/images/doc/imcombine.hlp + Replaced old version of IMCOMBINE with new version supporting masks, + offsets, and new algorithms. (7/19 fv) + +lib/math/iminterp.h +math/iminterp/arbpix.x +math/iminterp/arider.x +math/iminterp/arieval.x +math/iminterp/asider.x +math/iminterp/asieval.x +math/iminterp/asifit.x +math/iminterp/asiffree.x +math/iminterp/asigrl.x +math/iminterp/asiinit.x +math/iminterp/asirestore.x +math/iminterp/asisave.x +math/iminterp/asivector.x +math/iminterp/ii_1dinteg.x +math/iminterp/ii_eval.x +math/iminterp/ii_pc1deval.x +math/iminterp/im1interpdef.h +math/iminterp/doc/arbpix.hlp +math/iminterp/doc/arider.hlp +math/iminterp/doc/arieval.hlp +math/iminterp/doc/asider.hlp +math/iminterp/doc/asieval.hlp +math/iminterp/doc/asifit.hlp +math/iminterp/doc/asigrl.hlp +math/iminterp/doc/asiinit.hlp +math/iminterp/doc/asivector.hlp + The 1D image interpolation routines were replaced with new versions + modified by Frank Valdes to support sinc interpolation. (7/26/91 Davis) + +sys/qpoe/qprlmerge.gx + +sys/qpoe/qpexattrl.gx +sys/qpoe/qpexgetat.x +sys/qpoe/README +sys/qpoe/mkpkg +sys/qpoe/gen/mkpkg +sys/qpoe/zzdebug.x + The qpex_attrl routine would fail for attribute expressions + containing multiple eterms (filter subexpressions). Instead of + AND-ing the successive filter terms, it was combining them (OR-ing + them) to produce a single expression, and parsing the result + to return the output range list. + + 1. Modified qpex_getattribute to return expressions containing + multiple eterms with a semicolon rather than a comma delimiting + each eterm, so that the eterms can be distinguished. + 2. Added a new routine qp_rlmerge, used to merge (AND) two range + lists of any datatype. + 3. Modified qpex_attrl to parse each eterm separately and merge + the resultant range list into the output range list. + 4. Added a new debug task mergei and used this to test the new + merge range list routine. (7/27) + +sys/imio/iki/stf/stfrgpb.x + Added a check for a group index out of range. (7/28) + +sys/pmio/miopl.gx +sys/pmio/miogl.gx +sys/pmio/miostati.x +sys/pmio/mioseti.x +sys/pmio/miosrange.x +sys/pmio/mio.h + MIO_SETRANGE still wasn't working correctly so I had a more careful + look at the mio_[gp]l routines. + + 1. The fix made earlier to initialize the "ve" vector was incorrect, + as any data that wants to be saved between calls has to be saved in + the i/o descriptor and "ve" is a local variable. Moved the "ve" + initialization to immediately before the call to imggsc, where the + variable is used. + + 2. Made extensive changes to the way the "V" vector is handled. + This is passed back by the routines in each call to give the + coordinates of the first pixel of the referenced line segment. + Modified the routine to pass back a vector matching the image + dimension rather than of length IM_MAXDIM, to lessen the chance + of overrunning the client's buffer. Fixed a bug that was preventing + the routine from returning correct vector coordinates when doing + i/o on a subregion (mio_setrange) of the image. Fixed a bug that + would cause the data pointer to be offset when accessing subregions. + + 3. By default the coordinates of the V vector returned by the + mio_[gp]l routines will be relative to any subregion specified + with a prior call to mio_setrange. This is convenient when using + mio_setrange to randomly access subregions of the image. If this + is not what is desired it is now possible to follow the mio_setrange + call with a call to "mio_seti(mio,P_REGCOORDS,NO)" to cause the + V vector to be returned in image rather than region relative + coordinates. This is more convenient for applications that use + mio_setrange only to optimize i/o and want this to be transparent + to the rest of the code. (7/28) + +pkg/images/geometry/t_imshift.x + The shifts file pointer was not being correctly initialized to NULL + in the case where no shifts file was declared. When the task + was invoked repeatedly from a script, this could result in an array + being referenced, for which space not been previously allocated. + (LED 7/29/91) + +unix/hlib/extern.pkg URSA ONLY + Changed ccdacq from /u2/rooke/ice/ccdacq/ to + /ursa/iraf/extern/ice/ccdacq. We now have "production" and development + versions on ursa. (7/31/91 SRo) + +dev/hosts + Added mira, Mike Merrill's machine - this had been added to gemini + but not to tucana. (8/3/91 jb) + +mkpkg +noao/mkpkg + Added a new entry point "arch" as an alias for "showfloat". The + command "mkpkg arch" will print the current architecture. (8/06) + +pkg/xtools/inlfit/ + +pkg/xtools/doc/inlfit.hlp + +pkg/xtools/mkpkg + The interactive non-linear least squares fitting package inlfit + developed by Pedro Gigoux and used by the photcal package has + been added to xtools. (8/7/91 LED) + +dev/hosts [tucana, gemini, ursa] + Changed lapis to /usr/iraf/iraf. Other mountain systems should be + changed as Jim Davis gets around to them. (8/8/91 SRo) + +sys/libc/qsort.c + Added the copyright notice from the BSD source. Berkeley finally + made this source publically available without a unix source license, + provided the copyright notice is retained. (8/11) + +sys/imio/iki/stf/stfaddpar.x + Added a case for TY_BOOL (LOGICAL*4), and changed the abbreviated + type names "INT*4" etc. to their full Fortran equivalents. (Bug + fix contributed by B.Simon). (8/11) + +sys/mwcs/mwgsys.x + +sys/mwcs/mkpkg + Added source for the routine mw_gsystem. This was in the interface + specification but was missing from the interface. (8/11) + +unix/sun/imtoolrc +unix/sun/imtool.c + Added several new entries to the imtoolrc file. Increased the + maximum number of frame buffer configuration entries from 64 to 128, + and added a comment to the file suggesting that users add their + custom additions starting with config #64. (8/11) + +pkg/plot/phistogram.par +pkg/plot/phistogram.x +pkg/plot/phminmax.x +pkg/plot/doc/phistogram.hlp + Added a new task phistogram to the plot package. Phistogram takes + input from either an image or a list and permits full control over + the plotting parameters. The histogram computation is done in + and identical manner to the imhistogram task. (8/14/91 LED) + +pkg/plot/pradprof.par +pkg/plot/t_pradprof.x +pkg/plot/doc/pradprof.hlp + Added a new task pradprof to the plot package. (8/16/91 LED) + +unix/gdev/sgidev/mkpkg.sh +unix/gdev/sgidev/sgi2ueps.c + Installed new SGI to EPS (encapsulated postscript) graphics driver. + (8/16) + +dev/graphcap + 1. Installed a minor bug fix affecting the vhpl (VMS) entry. + 2. Added entries for the EPS driver. Device "eps" is the default + portrait mode output, "epsl" provides landscape mode. (8/16) + +dev/hosts [tucana, gemini, ursa] + Changed khaki to /usr/iraf/iraf. (8/16 jb) + +pkg/cl/exec.c + There was a bug in the oneof() function in how the "alldone" flag + is set to cause termination of a background process. The flag + would be set when attempting to pop (at task termination) a task + that has the T_BATCH flag set. The problem is that this test + would result in the continued execution of the task *after* execution + of the background command completed. In the normal case of a + background command submitted interactively on the command line this + would be harmless as the task would be "cl", which would see EOF + on the stdin and exit. In more complex cases, e.g., an executable + task or a script reading from a file, this could result in an + attempt to read from a stream that existed in the foreground CL + but which was never opened in the background CL. + + The particular case in which this showed up was in the OBSERVE task + in CCDACQ, when submitting the command "display 1 &" to + the CL from the subprocess, using clcmd. The display task would + run normally, being left behind in the process cache as the first + non-system process. The task descriptor for the observe task in + the background cl would be set up to read from a connected subprocess, + and after execution of the display command would resume waiting for + commands from the subprocess. Meanwhile, the subprocess actually + in the cache would be display rather than observe, and display would + have already terminated, resulting in deadlock with both the CL + (observe) and the display task executable waiting for a command. + Due to the deadlock the background job would never terminate and + after this sequence had repeated several times background job + submission would fail in the foreground cl with "no more background + job slots". (8/18) + +pkg/plot/phistogram.par +pkg/plot/phistogram.x +pkg/plot/phminmax.x +pkg/plot/doc/phistogram.hlp + The new phistogram task has been restored to the plot package after + the disk crash. (8/26/91 LED) + +pkg/plot/pradprof.par +pkg/plot/t_pradprof.x +pkg/plot/doc/pradprof.hlp + The new pradprof task has been restored to the plot package after + the disk crash. (8/26/91 LED) + +dev/graphcap + Added the six new ICE imtool frame buffer entries. (8/27/91 SRo) + +sys/qpoe/qpexmodfil.x + There was a simple bug in the buffer reallocation code which would + cause filter expansion to fail for expressions longer than 1024 + characters. A "sz_expr = INC_SZEXPRBUF" should have been + "sz_expr = sz_expr + INC_SZEXPRBUF". (9/04) + +unix/shlib/mkshlib.csh [not modified] + After a sysgen all sparc executables would fail to run due to an + access violation. This was due to a problem with the shared image; + the data and text segments were overlapping by 8 bytes, evidently + due to a linker bug in SunOS 4.1.1. I worked around the problem by + manually relinking the shared image including a dummy object "foo.o" + in the link to make the text segment slightly larger. Since the + text size of the shared image will change as soon as any code is + changed, it doesn't seem worthwhile to devise a more permanent + workaround. It looks like the linker fails to align the data segment + properly if etext is close to a page boundary. (9/07) + +unix/hlib/math.h + Changed the name of the define "E" to "BASE_E", to decrease the + chance of accidental name aliases. (9/17) + +pkg/images/doc/magnify.hlp + Fixed a bug in the magnify task help page. + (9/18/91 LED) + +pkg/images/filters/t_gauss.x + The code which computes the gaussian kernel in the gauss task + was producing a divide by zero error if ratio=0.0 and bilinear=yes + (2.10 version only). (9/18/91 LED) + +sys/gio/gadraw.x + It was possible for integer overflow to occur for case linear in the + assignments mx=x,my=y. Added 0:MAXNDC pre-clipping for case linear. + (9/20) + +pkg/system/help/helpdb.x + There were still problems with the code in helpdb which reorders + the package index help directory to depth-first order. A bug + which would cause commands such as "help lists.*" to print each + module twice was traced to this code. The help directory + reordering code was rewritten (inverting the two main loops) to + ensure that the reordered help directory does not have any holes + in it, and that the number of modules is correct. (9/21) + +dev$hosts + Changed aliases in dev$hosts on tucana, orion, gemini, ursa, + and draco for downtown node "morrison" to "vegemite". (CB, 9/21/91) + +----------------------------------------------------------------------- +Merge changes (including many minor bug fixes) from A/UX IRAF port. +This includes support for GCC and ANSI C, and limited SYSV support. (9/21) + +unix/hlib/install + 1. Added a #!/bin/csh at the top of the script. + 2. Added a "set path" so that explicit paths to executables can be + avoided. Changed "/etc/chown" to "chown" (this utility is in + different places on different systems). + 3. I had trouble on A/UX with the $hbin/sgi2* $hlib/sgi2* stuff in + MODEFILES. The second did not expand to anything and the string + "$hlib/sgi2*" was left in MODEFILES with the * unexpanded, causing + problems later when appended to a directory prefix. Since there are + not supposed to be any executables in hlib anyhow I deleted the + second reference. + 4. In the code which checks the MODEFILES, I added a test to see if + $file exists as named, before looking for it in each of the + directories. Otherwise the $hbin/sgi2* entries, which are already + fully resolved pathnames, expand to pathnames referencing + nonexistent directories when a BINDIRS prefix is prepended. + This could cause the install script to bomb on A/UX. + 5. Changed all occurrences of constructs like `ls ...` to `$LS ...` + with LS defined as /bin/ls at the top of the file. The problem is + that a subshell is spawned to evaluate the command in the back + ticks, and if "ls" is defined as an alias in a .cshrc file, as is + typically necessary on SYSV systems (to get -C) the alias will be + used, causing the output to be different than expected by the script. + (9/21) + +unix/hlib/irafuser.csh + Generalized somewhat - added some commented out GCC definitions, + and new definitions for CC, F77, HSI_F77LIBS, and RANLIB. These + are used in the mkpkg.sh files (used to bootstrap the HSI). (9/22) + +unix/hlib/mkfloat.csh + Added a definition TARXFLGS, with BSD and SYSV versions. (9/22) + +unix/boot/bootlib/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/rpp/ratlibc/mkpkg.sh +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/os/mkpkg.sh +unix/shlib/mkpkg.sh + Changed all occurrences of "cc" to "$CC" and all occurrences of "f77" + to "$F77". Changed all occurrences of "ranlib" to $RANLIB. (9/22) + +unix/setarch.sh + The A/UX version of "test" does not have the -h flag to test for + symbolic links, so the existing script did not work. Still trying + to find a portable way to do this, I changed the script to use the + construct: if [ "`ls -d as`" = "as" ]; then ... (9/22) + +unix/os/alloc.c + 1. The file header comment section contained the sequence "for the + /dev/* entries...". The "/*" would cause a warning from gcc that + there might be a comment buried in another comment, which can cause + a comment to terminate prematurely. In this case it was harmless + and indeed there was no error, but I changed the text to eliminate + the warning. + 2. Moved the #include to before the #include , + as the A/UX version of the latter requires the former, and SunOS + doesn't care. (9/22) + +unix/os/prwait.c + In pr_getipc(), deleted unused variables error_code, error_status, + waitpid. (9/22) + +unix/os/zalloc.c + 1. In ZDVALL, deleted unused variable x_status. + 2. Deleted unused variable i in loggedin(). (9/22) + +unix/os/zfioks.c +unix/hlib/irafuser.csh + 1. Deleted the old, commented out code for rcmd(), as variables + defined for this were being reported as unused. Added a comment + explaining that rcmd and friendly-host authentication cannot be + used without making the process suid root. + 2. Added #ifdef SYSV support for SYSV termio. Terminal driver ioctls + are used in this routine to set raw mode for the password prompts. + 3. GCC was complaining that the setjmp/longjmp used in zardks, + zawrks could cause certain register variables to become undefined + (op and nbytes in zardks, ofd in zawrks), so I changed the storage + class from register to auto for these variables. + 4. GCC would still warn that longjmp could clobber the values of + several local variables in zardks. Evidently this is a feature of + ANSI C. The values of automatic variables not declared "volatile" + are not guaranteed to be preserved in a longjmp. Added a -DANSI to + irafuser.csh and some #ifdef ANSI code to zfioks.c to provide the + necessary (but not non-ANSI backwards compatible) definitions. (9/22) + +unix/os/zfiolp.c + I had to change the declaration + + static PKCHAR xnullstr[1] = XEOS; + to + static PKCHAR xnullstr[1] = { XEOS }; + + (PKCHAR=short and XEOS=0) or GCC would complain about an invalid + initializer. Must be a feature of the ANSI C syntax. (9/22) + +unix/os/zfiotx.c +unix/hlib/libc/kernel.h + 1. Modified to add #ifdef SYSV support for SysV terminal i/o. + 2. GCC complained about some functions which were used (default + storage class extern) and later declared static; added static + declarations for these functions to the file header to eliminate + these (harmless) warning messages. + 3. Another longjmp warning, this time in zgettx. Variable "op" might + not be saved over a longjmp. In this case I was able to avoid the + problem merely by moving the op initialization statement to after + the setjmp. (9/22) + +unix/os/zfxdir.c + Deleted unused local variable "ch". (9/22) + +unix/os/zgcmdl.c + Deleted unused local variable "ev". (9/22) + +unix/os/zgtime.c + Had to #ifndef SYSV the #include as this file does + not exist on SysV systems. (9/22) + +unix/os/zmain.c + Deleted unused local variables "junk" and "wsetsize". (9/22) + +unix/os/zwmsec.c + Added "static" to explicitly specify the storage class in the first + declarations of "napmsx", which is declared static in the source + given later in the file. (9/22) + +unix/os/zxwhen.c + 1. GCC did not realize that the call to kernel_panic in zxwhen was + an exit, and would warn that the value of variable "vex", used later + in the procedure, could be unitialized. Added a statement to init + this to null to avoid the warning message. + 2. In zxgmes, the char pointer to the returned error message was + not being initialized if no error had occurred. Modified to return + the null string in this case. (9/22) + +unix/os/zzstrt.c + Added #ifdef SUNOS4 conditionals around certain declarations which + are used only the #ifdef SUNOS4 code which follows, to avoid unused + variable warnings on non-Sun systems. (9/22) + +unix/boot/bootlib/envinit.c + Deleted the unused variable "osfn" in loadpkgenv. (9/22) + +unix/boot/bootlib/bootlib.h + Deleted the commented out #define NOVOS definition, which causes + a /* in comment warning and doesn't need to be in this file anyhow. + (9/22) + +unix/boot/bootlib/osfcopy.c + 1. Deleted the unused variable "binary_file". + 2. Added a return at the end of the function, to guarantee that + a function value was returned. (9/22) + +unix/boot/bootlib/ostime.c + Modified with #ifdef SYSV for SysV. This whole business needs to + be redone sometime to provide rigorously correct time primitives + for iraf. (9/22) + +unix/boot/bootlib/vfn2osfn.c + Local variable "first_time" defined but never used. (9/22) + +unix/boot/generic/generic.c + 1. In copy_comment(), added an entry time initializer for the + local variable "flag". + 2. GCC complained about the variable "ch" in evaluate_expr() possibly + being used before being initialized. This looked harmless in this + case, but I added a global initializer to eliminate the warning + message. (9/22) + +unix/boot/mkpkg/host.c + 1. Deleted a couple of unused "exit_status" variables. Changed some + "return(exit_status=N)" constructs to separate assignment and return + statements in cases where the function does not return a value. + 2. Deleted unused variable "ip" in search_mkpkgfile(). + 3. Added a #ifdef SYSV to the code which calls RANLIB, since this is + not used on SYSV (COFF) systems. (9/22) + +unix/boot/mkpkg/mkpkg +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/scanlib.c + 1. Added a #include "mkpkg.h" to scanlib.c. This file includes extern.h + which references a structure defined in mkpkg.h. + 2. Deleted unused local variable "key" in h_scanlibrary(). + 3. Replaced the MAX_SYMBOLS definition in scanlib.c by MAX_LIBFILES, + as there is also a MAX_SYMBOLS in mkpkg.h which means something + quite different. (9/22) + +unix/boot/mkpkg/sflist.c + In sf_scanlist, the GCC static analysis indicated that variable "tail" + could possibly be used without being initialized. Added code to + initialize tail=head before scanning the list. (9/22) + +unix/boot/mkpkg/tok.c + 1. In do_if(), in the event of a syntax error the local variable "bval" + could be used without being initialized. Once again probably harmless + but it makes GCC complain. + 2. Unused variable "ch" in do_call(). + 3. Module do_include() was not returning an exit status in all + cases. (9/22) + +unix/boot/rmfiles.c + 1. Unused variable "i" in main(). + 2. Another warning from GCC static analysis suggesting that local + variable "fp" might be being used before being initialized (definitely + not in this case, but I added an initializer to avoid the message). + (9/22) + +unix/boot/wtar/wtar.c + Unused variable "op" in putheader(). (9/22) + +unix/boot/spp/xc.c + 1. Unused variable "cmdbuf" in main(). + 2. Variable "append" in sys() could be used before being + initialized. (9/22) + +unix/boot/spp/xpp/xppcode.c + 1. Unused variable "irafdefs" in do_include(). + 2. parse_task_statement() did not return a function value in all cases. + 3. accum() did not return a function value in all cases. + 4. Unused variable "digit" in charcon(). Function did not return + a value in all cases. + 5. Variable "value" not initialized in all cases (when an error + occurs, but it causes a warning message). (9/22) + +unix/boot/spp/xpp/decl.c + 1. Local variable "sp" was not being initialized in all cases (i.e., + when an error occurred). + 2. Added a new procedure d_declfunc which is called to output function + declarations. Currently this doesn't do anything special, but it + provides a single point of modification should it be necessary to do + any special processing of function declarations in the future (for + example intrinsic functions). (9/22) + +unix/boot/spp/rpp/ratlibc/getlin.c + The local variable "c" was not being initialized in all cases. (9/22) + +unix/gdev/sgidev/sgidispatch.c + Deleted unused local variables "maxch" and "status". (9/22) + +unix/os/gmttolst.c + Added #ifdef SYSV support. SYSV uses a global variable "timezone" + (a questionable construct - see below) while BSD uses a time_info + structure returned in a function call. (9/23) + +unix/os/zzstrt.c + This problem was indirect and hence difficult to track down. The + time-task feature of iraf, e.g., "$imstat dev$pix", when run for the + first time in a new process, would return a clock time such as + "-416:+0" instead of "0:13" or whatever. Thereafter it would be ok, + until the process was restarted. This turned out to be due to the + clock time returned by the first call to ZGTIME being wrong. The + eventual solution was to add a call to TZSET to zzstrt to initialize + the SysV time stuff before any time calculations take place. What I + suspect was happening is that in gmt_to_lst I was accessing + "timezone", which is a global data variable in SysV, but the value + was being changed sometime later in an indirect call to TZSET. + Using a global variable for something like this that is evidently + not constant is a very questionable feature of SVID (unless this + was a bug in A/UX). (9/23) + +unix/os/mkpkg.sh + Changed the "rm alloc.o" to "rm -f alloc.o", as the .o file is + not being left behind on this system, using GCC. (9/23) + +unix/os/zfiopl.c + In zclspl, another case of an array aggregate initializer "= val;" + having to be changed to "= { val };" when initializing an array of + length 1. (9/23) + +unix/os/zoscmd.c + 1. Modified so that if SYSV is defined, "fork" is used instead of + the BSD-ism "vfork". + 2. On Sun systems is included (disables the global optimizer + on sparc systems due to nonstandard register usage). (9/23) + +unix/boot/spp/rpp/ratlibr/defs + Replaced by the version rpprat/defs (they should be the same, although + in this case the differences did not affect the ratlib code). (9/24) + +unix/boot/spp/rpp/ratlibr/Makefile +unix/boot/spp/rpp/rpprat/Makefile + These makefiles now use a .r.f rule using /usr/local/bin/ratfor to + generate the .f files, rather than using f77 -F, which requires + replacing the host version of ratfor. (9/24) + +unix/boot/spp/rpp/ratlibf/*.f +unix/boot/spp/rpp/rppfor/*.f + Regenerated all the preprocessor Fortran sources. The new files are + lower case. Although upper case source is standard Fortran, all + modern compilers I am aware of accept lower case source (SPP outputs + lower case after all), and a case sensitive compiler may generate + upper case externals for upper case procedure names, causing a case + mismatch when linking with the C support library. (9/24) + +unix/boot/spp/rpp/ratlibc/r4tocstr.c + Installed a minor bug fix which allows the routine to accept as + input character arrays consisting of either one char per integer, or + a char plus 3 blanks per integer. The old F66 convention of + assigning one Hollerith character to a binary integer can generate + either type of integer value. (9/24) + +sys/imfort/imemsg.x + This file contained four Fortran escapes (error message strings) + which ran over the 72 character line limit of Fortran. (9/24) + +sys/gio/nspp/portlib/gridal.f + The equivalence on line 4 was incorrect (or at least ill-advised) + due to a dimension error. The code "mfmtx(1),ifmt(1))" should + have been "mfmtx(1),ifmt(1,1))". (9/24) + +sys/gio/nspp/portlib/z8zpbd.f +sys/gio/nspp/portlib/z8zpii.f + The z8zpbd.f file was using DATA statements to initialize variables + in common (works on most systems but is technically illegal). I + moved all the remaining DATA statements out of z8zpbd.f into run + time initialization statements in z8zpbd.f (9/24) + +unix/boot/spp/xc.c + The routine printargs() was attempting to print one more argument + than it should, due to a <= that should have been a < in a FOR loop. + (9/24) + +pkg/system/help/lroff/textout.x + Modified to eliminate the ENTRY point. (9/24) + +sys/fmtio/ctotok.x + Local variable numch never used (this is old code so I don't know + why no other compiler has found this). (9/24) + +sys/fmtio/evexpr.y +sys/fmtio/evexpr.x + The second argument (a debug flag) to yyparse (xev_parse) is a + boolean, but xev_parse was being called elsewhere with an integer + argument. Changed to a boolean since the Y*cc code contains many + if (yydebug) constructs. (9/24) + +sys/etc/main.x + FREDIR is a subroutine but was being called as a function in one + place in this file. (9/24) + +sys/tty/ttyputl.x + This file contained a statement call putci (fd, "_") which was + incorrect, since the argument "_" is type char but is supposed to + be integer. (9/24) + +sys/gio/gopen.x + 1. The pointer array graphcap_file was not being used. + 2. Local string variable graphcap never used. (9/24) + +sys/pmio/pmplls.x + The second call to pl_plls was missing the ll_depth argument. (9/24) + +sys/qpoe/qpppar.x + The second call to qp_sizeof was missing an argument. (9/24) + +sys/imfort/bfio.x + There was an extra "status" argument to one of the calls to + zsttbf. (9/24) + +sys/gio/ncarutil/conran.f + Local variable LNGTHS not used. (9/24) + +pkg/plot/crtpict/t_crtpict.x + A call to gargwrd was missing the maxch argument. (9/24) + +pkg/plot/t_graph.x + Variable window declared but not used. (9/24) + +pkg/plot/t_velvect.x + Variable nset declared but not used. (9/24) + +sys/fmio/fmlfundel.x + The two calls to fmio_bind and fmio_errck were both lacking the + fm argument. (9/24) + +sys/ki/kireceive.x + A call to strcpy was missing an argument. (9/24) + +sys/imio/imopsf.x + The call to pl_ssize had an extra unused argument. (9/24) + +sys/etc/pagefiles.x + ttyctrl, which is an integer function, was being called as a + subroutine. (9/24) + +sys/imio/iki/oif/oifclose.x +sys/imio/iki/oif/oifdelete.x + The integer function protect() was being called as a subroutine. + (9/24) + +sys/plio/plglr.gx + The routine pl_rangerop was being called incorrectly. (9/24) + +sys/plio/plprop.gx + The VOPS routine argt (replace if greater than) was being + called incorrectly in three places. (9/24) + +sys/plio/plascii.x + The subroutine pl_glpi() was being called as a function. (9/24) + +sys/plio/pldebug.x + The integer function pl_l2ri() was being called as a subroutine. + (9/24) + +sys/pmio/pmglp.gx + The routine pl_pixrop was being called incorrectly. (9/24) + +sys/qpoe/qpioopen.x + A call to syserr was being made where syserrs was intended. (9/24) + +sys/gio/cursor/grccmd.x + External pr_psio() declared but never used. (9/24) + +sys/gio/stdgraph/stgclws.x + External std_onerror() declared but never used. (9/24) + +sys/libc/qsort.c + The static function qst() was being used before being declared, + resulting in an extern/static declaration inconsistency. (9/24) + +sys/ki/irafks.x + The "task irafks = onentry" was incorrect since ONENTRY is an integer + function. This was harmless since the purpose of the task statement + was merely to get an iraf main, but I set up a dummy t_irafks task + to avoid the type clash. (9/24) + +pkg/cl/bkg.c + Static function bkg_close() used before being declared static. + Added a static function declaration to the file header. (9/24) + +pkg/cl/debug.c + Same as above, function dd_f(). (9/24) + +pkg/cl/edcap.c + Same as above, function map_escapes(). (9/24) + +pkg/cl/pfiles.c + Same as above, function mapname(). (9/24) + +pkg/cl/cl.x + Same problem as in irafks, above. ONENTRY is a function and should + not be referenced as a subroutine in the task statement. Added a + dummy t_cl procedure to avoid the type clash. (9/24) + +------------------- +End of revisions merge from A/UX GCC/ANSI-C/F2C work. + +dev/graphcap +dev/devices.hlp + Output can now be directed to the default UNIX `lpr' device using + any of the aliases "lpr", "lp", or "lw". The actual device is + defined by the value of PRINTER if defined in the user's environment, + else is the "lp" device in /etc/printcap. (9/23) + + (lw is no longer an alias for the NOAO/Tucson device lw1) + +pkg/images/iminfo/t_imstat.x +pkg/images/doc/imstat.hlp + Corrected a bug in the mode computation in imstatistics. The parabolic + interpolation correction for computing the histogram peak was being + applied in the wrong direction. Note that for dev$pix the wrong answer + is actually closer to the expected answer than the correct answer + due to binning effects. (LED 9/24) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + Added the following name redefinitions. On systems where Fortran and + C share the same name space these can cause name collisions. (9/28) + + define fatal xfatal + define fchdir xfchdr + define fscan xfscan + define getopt xgtopt + define getpid xgtpid + define getuid xgtuid + define rename xfrnam + define reset xreset + define scan xxscan + +------------------------------------------- +Started a full bootstrap and recompile for the sparc architecture. (9/28) + +sys/fmtio/tokdata.inc + Deleted the DATA statement for numch, which is no longer used by + ctotok.x, the routine which includes this file. (9/29) + +lib/plset.h + Added PL$T_LEN defines for type long, required for the generic + expansion of plglr.gx in PLIO. (9/29) + +unix/boot/mkpkg/host.c + Added a return(OK) to h_purge(), which is a no-op on unix systems. + (9/29) + +pkg/images/imarith/mkpkg +pkg/images/imarith/imsum.gx +pkg/images/imarith/generic/mkpkg +pkg/images/imarith/generic/imsum.h - + Images failed to link, with all the imsum externals reported as + undefined externals. + 1. Edited imsum.gx and changed `include "imsum.h"' to `include + "../imsum.h"'. + 2. Deleted generic/imsum.h and the code in imarith/mkpkg which + generates it. There should not be multiple copies of global header + files. + 3. Rebuilt the generic/mkpkg using mkmlist, to ensure that the + library list is correct (all the imsum entries were missing). (9/29) + +noao/artdata/mkheader.x + 1. Fixed a "local variable ua never used" warning, caused by some code + being commented out. + 2. I was also surprised to see the construct `fd = immap (fname, ...)' + in this file. FD means file descriptor whereas immap returns an + image descriptor. FNAME means file name but an image name is not a + file name. FD is declared pointer in this file but is used later in + the same routine to hold a file descriptor, which is an integer. + This code is illegally accessing the user area of the image header. + (9/29) + +noao/twodspec/longslit/illumination.x + This file failed to compile, with the following errors: + local variable "clgeti" never used + attempt to use undefined variable "im" + attempt to use untyped function "clgetr" + 1. Changed the call to clgetr to a call to clgeti, since the + parameter being fetched is integer. Added a declaration for im. + 2. In the process of doing this I noticed that in the call + iferr (axis = imgeti (im, "dispaxis")) { + the variable IM was being used before being initialized (or declared). + I changed the "im" to "in" but couldn't be certain this was correct + since there are two input image pointers (I think; I couldn't be + certain they were both input since there are no #[IOU] markers in the + comments). (9/29) + +noao/twodspec/longslit/response.x +noao/twodspec/longslit/fluxcalib.x + Similar construct. Changed calls to clgetr to clgeti in both + routines. (9/29) + +unix/hlib/extern.pkg + All the digiphot packages failed to link, due to the cross link + against the V2.9 versions of the TABLES libraries (due to the + recent name changes in iraf.h all code has to be recompiled for + V2.10). I temporarily created a local copy of TABLES in + /u3/extra/tables and compiled this with V2.10. (9/29) + +bin.sparc/S5.e +bin.sparc/S6.e + + Installed the V2.9.3 version of S5.e (the V2.9 shared image) from ursa. + S6.e is the V2.10 shared image. (9/29) + +unix/boot/xyacc/mkpkg.sh + Added a rm -f *.o to delete the xyacc objects after a bootstrap. (9/29) + +--------------------------------------------- +Begin f68881 bootstrap and full sysgen-recompile. (9/29) + +sys/ki/koscmd.x + The output spool file on the local node was being opened with zopntx, + but written to with kputtx with an invalid channel descriptor, causing + the output to be lost when attempting to redirect the output. The + fix was to change the call to kputtx to a call to zputtx. (9/30) + +dev/imtoolrc + +unix/hlib/install + Copied imtoolrc into dev so that the frame buffer entries in graphcap + and imtoolrc can be more easily maintained together, and so that + the user does not have to modify a source directory (unix/sun) in + order to change a runtime configuration file (imtoolrc). Modified + the install script to make /usr/local/lib/imtoolrc a link to the + file in DEV, instead of a copy of the file. (9/30) + +noao$rv/ + +noao$mkpkg +noao$noao.hd +noao$noao.cl +noao$noao.men +noao$lib/strip.noao +noao$lib/zzsetenv.def +noao$lib/scr/fxcor.key + +noao$lib/scr/specmode.key + +noao$lib/scr/fftmode.key + + Installed the RV0 package as the NOAO.RV package and recompiled for + the f68881. A sparc executable was built separately and installed in + noao$bin.sparc. The noao helpdb was also recompiled to include the + new rv help pages. (9/30 MJF) + +hlib$extern.pkg + Removed the RV0 package definition from the V2.10 iraf. (9/30 MJF) + +hlib$extern.pkg + Removed the testphot package definition from the V2.10 iraf. (9/30 LED) + +bin.f68881/S5.e + Replaced by the V2.9.3 version. (9/30) + +unix/os/zfioks.c +unix/os/zfiotx.c + Fixed minor typos in the #ifdef SYSV code. (10/02) + +unix/boot/mkpkg.pkg.c + Deleted declarations for a couple of unused variables. (10/02) + +unix/os/zawset.c + Added SYSV support. (10/02) + +unix/os/zfiopr.c + Added SYSV support (vfork is defined as fork). On Sun systems + is conditionally included. (10/02) + +unix/os/zgtenv.c + Replaced a comment within a comment construct (example from ) + by a version which substitutes @ for *, to avoid GCC warning messages + about a possible problem with nested comments. (10/02) + +unix/os/zopdpr.c + Added SYSV support for vfork/fork as above, plus nice() is used + for SYSV instead of the BSD {get|set}priority. (10/02) + +unix/boot/spp/rpp/rpprat/gtok.r +unix/boot/spp/rpp/rppfor/gtok.f + Commented out the declaration for the unused variable "digits". (10/02) + +math/gsurfit/mkpkg + Contained a statement $ifeq (USE_GENERIC, YES) which was incorrect, + as a lower case "yes" is required since $ifeq uses a simple string + comparison. I noticed this because a bug had been fixed in a .gx + file, but was still present in the real/double files, which had not + been modified since 1987. (10/02) + +math/nlfit/nlfitdefr.h +math/nlfit/nlfitdefd.h +math/nlfit/nlzero.gx + Corrected several bugs in the way the aclr$t routines were being + called in the nlzero(rd) routine. (10/3/91 LED) + +pkg/plot/phistogram.x + Corrected some type mismatch problem in calls to gset. (10/3/91 LED) + +sys/gio/ncarutil/pwrity.f + Unused variable LEN on line 335. (10/02) + +sys/gio/ncarutil/pwrzi.f +sys/gio/ncarutil/pwrzs.f +sys/gio/ncarutil/pwrzt.f + Variables HIGH,WIDE,WHITE, and LNGTH not used (same problem in + all three files). (10/02) + +sys/ki/koscmd.x + In the call to zopntx to open the local spool file (when redirecting + the output), the unpacked version of the filename was being used + instead of the packed version required by the kernel routine. (10/05) + +pkg/plot/crtpict/calchgms.x + Changed the declarations for the variables min_val and max_val in + the procedure crt_user_hgram from int to short. (10/5/91 LED) + +dev$hosts + Added felis to dev$hosts for Shopbell. On tucana only since irafks.e + on felis seems quirky. (10/5/91 MJF) + +pkg/dataio/fits/fits_rpixels.x + 1. The rfits task has been modified to accept a short last record, i.e. + a last record that has not been padded out to 2880 bytes, without + generating any warning messages. Short last records were only a + problem for IRAF 2.9 when the blocking code was rewritten. + (10/8/91 LED) + +unix/boot/generic/generic.c + The -k (clobber) option would fail to clobber an existing file if + account executing generic did not own the file. (10/09) + +pkg/images/iminfo/t_imstat.x + Corrected a bug in the kurtosis computation, wherein a 4.0 was + being subtracted from the sum instead of a 3.0 (10/11/91 LED) + +unix/boot/spp/xc.c + Minor typo in run() code. (10/11) + +pkg/dataio/fits/fits_cards.x + Changed the name of the IRAF-B/P keyword to IRAF-BPX to conform to the + new FITS standard. (10/15/91 LED) + +unix/sun/README +unix/sun/gterm.c +unix/sun/halley.lut +unix/sun/heat.lut +unix/sun/imtool.c +unix/sun/imtool.icon +unix/sun/screendump.c + I have been holding off on installing this for a couple of weeks + in the hopes of finishing the planned work, but rather than delay + longer I have installed this version, to be updated later. The + main changes or new features are as follows. + + 1. Screendump parameters (R_DISPOSE etc.) are now in the setup panel. + 2. A number of new builtin lookup table options (e.g. HEAT) have + been added. + 3. User defined lookup tables are now supported. + 4. Updating of the global screen colortable is now a setup panel + option. This allows it to be turned off, which makes imtool + better behaved under openwindows. + + Features not yet in are EPS support, more flexibility in the use + of FIFOs, and maybe socket support. (10/20) + +unix/os/zfiomt.c +unix/os/zalloc.c +unix/os/alloc.c +sys/mkpkg +sys/mtio/* +sys/gty/* +sys/libc/(some) +sys/ki/(some) +pkg/cl/builtin.c +dev/tapecap + Installed the new magtape i/o subsystem. I will document this more + fully later. Usage is much as before. The key file controlling the + configuration is dev$tapecap. A description of the tapecap + parameters is given in os$zfiomt.c. Testing and configuration of + the tapecap file is only rudimentary at this point. I have + successfully tested thus far with the DC2000 cartridge tape and + floppy disk on lepus, the DAT drive on coma, and the 1/2inch 6250 + bpi tape on tucana. There is some confusion (dev$devices out of + date) regarding the device entries for the 1/4inch cartridge drive + on tucana so I did not complete the tapecap entry for this drive. + The driver is new and MTIO has been extensively revised. The new + GTY interface provides a general termcap style database facility + which is used for tapecap. (10/20) + +dev/termcap + Added a new entry for "xirafhelp". (11/10) + +dev/hosts + Added sonoma to the hosts file on tucana and ursa. (11/13 jb) + +pkg/plot/t_graph.x +plt/plot/doc/graph.hlp + 1. Local variables overplot,append in t_graph were declared int + but were used everywhere as bool. + 2. Missing .le in help page entry for overplot. (11/20) + +lib/fio.h + Added a comment for LEN_RAWCMD. (11/20) + +lib/fset.h +sys/fio/fseti.x +sys/fio/fstati.x +unix/hlib/libc/fset.h + Added a new fset option F_IOMODE. The value field is a bit flag + consisting of either IO_NORMAL (normal line by line i/o with echo) + or some combination of, currently, IO_RAW and IO_NDELAY. F_RAW is + also still defined and if used in a fseti call will set F_IOMODE + to IO_RAW with IO_NDELAY disabled. On a fstati query, F_RAW checks + if IO_RAW mode is set, and F_IOMODE returns the i/o mode as a bit + flag integer word. (11/20) + + [Note - the fset integer codes were modified. This will require + [that all layered software which uses fset/fstat be recompiled.] + +sys/etc/prpsio.x + Testing revealed that while both raw mode and NDELAY (nonblocking + i/o) worked from a stand alone process, and raw mode worked from + a subprocess, NDELAY would not work from a subprocess. This was + due to the prpsio code, which must check for the i/o mode control + strings and make a local fseti call if these are seen. The prpsio + code would set raw mode but was ignoring NDELAY, hence setting + IO_RAW+IO_NDELAY in a subprocess would result in only raw mode + being set in the pseudofile i/o control process (the CL). (11/20) + +sys/tty/ttyread.x + Modified to set F_IOMODE rather than F_RAW. Since this routine + uses NDELAY it it worth updating to use the new bit flags. Most + of the old VOS code still uses F_RAW=(YES|NO), which is fine so + long as only raw mode is being set. (11/20) + +pkg/cl/mkpkg + Added to the header file dependency list for + history.c. (11/20) + +sys/tty/mkpkg + Entry in library dependency list for ttygsize.x was incorrect; + rebuilt list with mkmlist. (11/21) + +dev/graphcap +dev/imtoolrc + Added imt13-16, imttall128 (128x1056), imttall256 (256x1056), + imtwide128 (1056x128), and imtwide256 (1056x256) for use in + spectroscopy at request of KPNO. Also added aliases for the new + KPNO 1992 chip names to the six entries between imt32 and imt37. + (11/22/91 SRo) + +unix/sun/imtoolrc + Installed the above mentioned imtoolrc in the imtool source + directory. (11/22) + +sys/fio/fstati.x + Fixed a bug which could cause fstati(fd,F_UNREAD) to return an + incorrect unread character count for pushed back data. (11/27) + +mwcs.h +mwswtype.x + Removed the compile time SZ_ATVAL restriction on the length of + a WCS attribute value. The size of an attribute value string is + now determined dynamically at run time and the buffers sized + accordingly. (11/27) + +mwsaveim.x + Deleted the call to mw_ssystem, which would force mw_saveim to + save the default world system. mw_saveim will now save the current + world system instead; the application should call mw_ssystem first + if it wishes to save a particular system. This applies only to + the use of mw_saveim with the current FITS-header images. In future + image formats mw_saveim will save the entire MWCS and it will not + be necessary to specify which WCS to save. (11/27) + +wfinit.x +wfmspec.x + +wfsin.x + +wfgls.x + +wfarc.x + +iwewcs.x +mkpkg + Installed four new MWCS function drivers: + + sin sin projection + arc arc projection + gls global sinusoidal projection + multispec multispec image format (ONEDSPEC etc.) + (11/27) + +pkg/dataio/mtexamine/mkpkg + The mkpkg was missing an entry for fseti.h (among other things). + Rebuilt library module list with mkmlist. (11/27) + +sys/mtio/mtio.h + Was getting truncation of tapecap entry string during tape testing + on orion. This was traced to a buffer size being set too small in + zopnmt.x (SZ_DEVCAP). Increased to 512 chars. (11/27) + +unix/os/zfiomt.c + Fixed a bug in the new V2.10 zfiomt.c which affected appending to + a tape after a rewind. (12/01) + +unix/os/zfiomt.c + 1. RE now causes a read error to be ignored not only when positioning + to EOT, but on a file read if recno=1 (a read a the beginning of a + file is used by high level programs like mtexamine to detect EOT). + 2. The tapeused counter was not being updated properly (the size of + a filemark was not being counted) when EOF was seen on a read. (12/02) + +dev/tapecap + Installed a new, better organized and more complete version of the + tapecap file. This now includes support for the HP 88780 and Exabyte + drives under SunOS. (12/02) + +unix/os/zfiomt.c + 1. When passed a tapecap device entry containing multiple entries for + the same capability, the driver was allowing later entries to + override the first entry, whereas the termcap convention is that + the first entry given overrides any later (tc=) entries. + 2. Added support for negated entries, as in ":nb@:". (12/02) + +pkg/dataio/cardimage/mkpkg + The mkpkg was missing several file dependencies including + fset.h. (LED 12/03) + +pkg/dataio/fits/mkpkg + The mkpkg was missing several some file dependencies. + (LED 12/03) + +pkg/dataio/imtext/mkpkg + The mkpkg was missing several some file dependencies. + (LED 12/03) + +vms/gdev/zfiovi.c + Installed a bug fix (actually workaround for an apparent VMS problem) + reported by STScI. The lock enqueue code can receive the status + SS$_VALNOTVALID even though the value block is apparently valid. + The workaround is to issue a warning but otherwise ignore the + condition. Hopefully this is correct. (12/03) + +dev/tapecap + Replaced with new version with expanded support for QIC cartridge + drives. Unfortunately not yet fully tested due to system problems + with the QIC-11/24 drive I was using for testing. (12/05) + +sys/mwcs/wfsin.x + The forward transform now checks for a negative value before taking + a square root. (12/06) + +unix/os/zfiomt.c + Installed a new version of the new magtape driver which adds + support for status output to a TCP/IP socket. I also have a new + program XTAPEMON (not currently installed in IRAF) which listens + on a socket and accepts connections from the the new driver (or + any similar client) displaying tape status messages in a window + on any X server while the drive is being accessed. + + Status output may be directed to either a file or a socket, using + the syntax ":so=foo:". If foo is an absolute pathname beginning + with / then output is to a file (this field is interpreted by the + unix driver so we are talking about unix pathnames). Otherwise, the + field is assumed to refer to a socket of the form ":so=[host][,port]", + e.g., ":so=lepus:", ":so=lepus,5138", ":so=,2345:", and so on. + If no host is specified localhost is assumed. If no port is + specified the default port is used. + + In practice, the minimal specification is ":so:". This will cause + the drive to atempt to open a socket connection to the default port + on the local host. If no server is registered the connection will + fail harmlessly. If xtapemon is running on the local host it will + accept the connection. Currently, xtapemon supports multiple + concurrent servers (using consecutive port numbers) but the driver + does not, unless the port number is given explicitly. Multiple + clients are allowed to access the same server, e.g., multiple + processes in the same process tree. + + Note that status output, if enabled, is output in an ascii text + stream to either a socket or a file (including things like + /dev/ttyX, /dev/tty, /dev/console etc. as well as disk files). + Hence the xtapemon utility, while useful for workstations running X, + is not required in any way to use the new magtape system or even to + view status output. In the simplest case, "devstatus" may be used + to print the drive status. (12/15) + +unix/os/zopdir.c + The zopdir routines were modified to read the UNIX directory into a + buffer and sort it, before returning filenames to the caller (some + VOS routine). UNIX directories are not stored in sort order on + disk, and previously, IRAF routines which read directories to + produce file lists but which did not sort the list for some reason, + could produce what appeared to be randomly ordered lists (for + example, in image templates). + + A practical result of this revision is that dir sort- will produce + a listing which is sorted across the columns rather than along the + columns. This may be preferable when listing very large directories. + (12/15) + +sys/etc/main.x +sys/etc/onentry.x # INTERFACE CHANGE +pkg/cl/cl.x +sys/ki/irafks.x + The calling sequence for ONENTRY was modified to add a third + argument "command". This is used to pass any optional arguments + given on the host command line when the process is executed at + the host level. Since the purpose of the ONENTRY procedure is to + provide an alternative to the normal iraf process level command + interpreter, the procedure should get full access to the command line. + (12/26) + +dev/irafhosts + +unix/os/zfioks.c +sys/ki/irafks.x + Totally new networking driver. This version supports both RSH and + REXEC connection protocols. The default RSH protocol avoids + password prompts. In addition, a feature is provided to spawn a + daemon process in.irafksd which makes it much faster to fork a new + kernel server, once the first RSH connection to a server node has + been made. The new kernel server is largely backwards compatible + (although due to magtape i/o changes V2.10 networking cannot be used + with older systems anyhow). The new driver still uses a .irafhosts + file, but it need not contain passwords, and the file is automatically + created and read protected. Details to follow. (12/26) + + Here is some more information on the new networking system (12/31). + + The new driver support three different connection protocols. The + default protocol uses rsh|remsh to spawn a networking daemon which + is used thereafter to start iraf kernel server processes on that + node (more on the this later). This is the most efficient protocol, + and does not require any passwords. A rsh only protocol is also + supported which requires a rsh connection every time a connection is + made. This is slightly more secure than the rsh/daemon protocol but + considerably less efficient. Finally, the old rexec protocol is + still supported. This is what is used if a password is given for a + node in the .irafhosts file. It is also now possible to use iraf + networking even if no rsh or rexec service is available, by manually + starting the iraf networking daemon on a server node. + + The rsh/daemon protocol works as follows. The client calls the + zfioks driver to open a connection. zfioks reads the irafhosts file + and determines that the rsh/daemon protocol should be used for the + named host. zfioks attempts to connect to the daemon process on the + remote host. If the connection is made the client passes its port + number and an authorization code to the daemon, the daemon forks to + create a new irafks kernel server, which then connects to the client + via the client supplied port number, and the connection is made. If + the client cannot connect to the daemon, the client forks and execs + the rsh task which is used to start up the daemon process on the + remote host. The client can then connect to the daemon in the usual + way. + + When the daemon is first started with rsh, the client passes a + unique long integer authorization code. All subsequent connections + to the daemon must supply the same code or the connection will be + refused. The authorization code is given in the irafhosts file. + Since this networking scheme avoids any suid root processes, the + daemon process runs with the uid of the user whose client issued + the original rsh request to start the daemon. Each user has their + own daemon process on each server node. The daemon is started + automatically when the first connection is made. After a certain + period of inactivity (default 1 hour) the daemon process will exit. + + Once a daemon has been started with rsh (this takes several seconds) + a network connection can be made very quickly, as all that is + required is a connect to a remote socket, a fork of the daemon + process, and a connect back to the client supplied socket. The + irafks server and the client zfioks driver will then be directly + connected via a socket. The daemon process is just the usual + irafks.e running as a daemon, which is why it only needs to fork to + spawn a new irafks server. Only one daemon process is required per + user per server node, but there can be any number of irafks + servers. Any number of client hosts can connect to a single server + host via a single daemon process, provided the user has set up a + .irafhosts with the same authorization code on each client node (if + this is not done the connection will still be made, but will require + an expensive rsh connect on each call). + + The new driver still uses the .irafhosts file, although most of the + motivation for including passwords in the file is gone. The + .irafhosts file is required and will be created automatically by the + system if not present. If an old style .irafhosts file is present + it will be replaced by the new version of the file. The system + automatically read protects the file. The .irafhosts file contains + three regions: some header comments, some keyword=value networking + parameters, and the user supplied host list. + + The irafhosts keywords are as follows. + + port The TCP port number used by the daemon process. + Normally set to "default", which tells the driver + to assign a port for each user based on HIPORT + and the user uid code. If PORT is set to "none" + use of the daemon is disabled and rsh will be used + for every connect (this is provided in case someone + doesn't feel the authorization code scheme is + secure enough). + + auth The user authorization code. Set to "default" in + dev$irafhosts, but replaced by a unique authorization + code when the user uses networking for the first time + and the .irafhosts file is created. + + hiport Used to dynamically assign unique port numbers + (see "port" above). hiport defines the top of the + reserved port region used for the irafks daemon. + Normally set to "default" (47000). + + timeout The idle time in seconds after which the daemon + will exit. Normally set to "default". The builtin + default timeout is 1 hour. + + The format of a host-list entry is as follows. + + host-name ":" login-name password + + The default host-list entry is the following. + + * : + + This enables the rsh/daemon protocol for all server nodes. + The login-name field may be set to "none" to disable networking + for a node, or to the actual user login name to cause the + connection to a node to be made with different login name than + that of the user on the local host. Setting the password field + to an explicit password causes the rexec connect protocol to + be used for that node. Setting the password to "?" causes the + driver to prompt for the password, after which the rexec protocol + is used to make the connection. + + In actual practice, all of this is automatic and the user never + needs to look at or modify the .irafhosts file, unless they want + to customize things. Once the .irafhosts file has been created + by the system it should be copied to the user's login directory + on other nodes in the local network. If this is not done iraf + networking will still work, but will be less efficient if iraf + clients running on different hosts try to connect to the same + server (they will have different authorization codes and the + driver will have to fall back on the rsh connect protocol for + every connection). + + The system template irafhosts file is dev$irafhosts. The iraf + system manager can set the default network parameters in this file + if they don't like the builtin defaults. Note that the hostlogin + file is no longer used. It was confusing for the files to have + different names so dev$hostlogin was replaced by dev$irafhosts. + + COMPATIBILITY. By default the system will try to use one of the + rsh protocols, hence the server as well as the client must be + running v2.10 iraf. To connect to a pre-v2.10 server from a v2.10 + client the rexec protocol must be enabled by setting the password + field in the irafhosts file. A v2.9 client should be able to + transparently connect to a v2.10 server. In all cases where v2.9 + and v2.10 clients and servers are being mixed, remote magtape + access cannot be used since the protocols have changed in v2.10. + +sys/ki/kzopmt.x + The devcap string was not being passed at the correct offset. + (12/29) + +sys/ki/irafks.x + Fixed a couple of problem in the zfiomt server code which were + preventing magtape i/o from working over the network. The server + was missing an entry for the new zzstmt routine. (12/29) + +unix/os/zfioks.c + Fixed a bug that was causing remote device allocation/deallocation + to fail, when accessing a device over the network. SIGCLD was + being received by the server when the alloc.e terminated and was + executing a longjmp to a stack frame that no longer existed (the + zfioks driver, with all its forks, has several parallel execution + paths all in the same code). + + With this fix remote magtape access seems to be working again using + the new magtape and networking drivers. (12/30) + +unix/os/zfiomt.c + For a read (zzrdmt), the recsize output to the status output was + changed from the requested read size to the actual read size, i.e., + the actual size of the record read. (1/02/92) + +unix/hlib/iraf.h +sys/mtio/mtio.h + Moved the definition of EOT from mtio.h to iraf.h, so that applications + can use it (required for mtparse/mtname). (1/02) + +sys/etc/xalloc.x + Changed mt_allocate/mt_deallocate to mtallocate/mtdeallocate, to be + consistent with the other extern MTIO routines. (1/02) + +sys/mtio/README +sys/mtio/mkpkg +sys/mtio/mtalloc.x +sys/mtio/mtcap.x +sys/mtio/mtdealloc.x +sys/mtio/mtglock.x +sys/mtio/mtgtyopen.x + +sys/mtio/mtio.h +sys/mtio/mtname.x + +sys/mtio/mtneedf.x + +sys/mtio/mtopen.x +sys/mtio/mtparse.x +sys/mtio/mtpos.x +sys/mtio/mtrdlock.x +sys/mtio/mtrewind.x +sys/mtio/mtstatus.x + 1. An interface summary was added to the README file. + 2. Revised MTIO to add a number of new externally callable user + routines. The following is excerpted from the README file. + + yes|no = mtfile (fname) # Is fname a magtape device? + yes|no = mtneedfileno (mtname) # No file number given? + gty = mtcap (mtname) + mtfname (mtname, fileno, outstr, maxch) + + mtparse (mtname, device, fileno, recno, attrl, maxch) + mtencode (mtname, maxch, device, fileno, recno, attrl) + + fd = mtopen (mtname, acmode, bufsize) + mtrewind (mtname, initcache) + mtposition (mtname, file, record) + + Use CLOSE to close a file descriptor opened with mtopen. + Use GTYCLOSE to close a termcap descriptor opened with mtcap. + MTNAME is the full magtape device specification, i.e, "mt[...]". + + The new routines are MTCAP, MTNEEDFILE, MTFNAME, MTPARSE, and + MTENCODE. MTCAP opens the GTY descriptor for the device specified + in mtname. MTNEEDFILE tells whether a file number is specified in + the given mtname. MTFNAME constructs a magtape file name, given an + existing mtname and a file number. + + The MTPARSE and MTENCODE routines are lower level and are provided in + case a mtname needs to be edited or constructed which the simpler + routines given above cannot deal with. MTPARSE parses an mtname + into the device name, file and record numbers (set to ERR if not + given) and tapecap attribute list, if any. MTNAME does the reverse, + building a mtname from these pieces. (1/02) + +dev/tapecap +unix/os/zfiomt.c + Added a new capability "fb" to tapecap. This specifies the default + FITS block factor for each type of device. (1/02) + +unix/os/zfioks.c + 1. Tested the password prompting option (password = ?). Fixed a + bug in the SysV version of the password prompting code. + 2. Tested the in.irafksd idle-timeout feature, seems to work. + 3. Added a timeout feature to the handshaking that goes on between + client and server during a connect. The connect will now fail and + shutdown automatically if there is no response for 45 seconds during + a connect (e.g., because the guy on the other end is not what we + expect it to be). (1/02) + +sys/qpoe/qpiosetrg.x + Changed the dimension of the VS, VE input array arguments from "ndim" + to "ARB". (1/07) + +sys/etc/xgdevlist.x + Added a call to ki_xnode to propagate the network node prefix, if any, + to the output resource string. (1/07) + +sys/ki/irafks.x + The devpos struct (position information) was not being passed back + properly when closing a magtape device opened for network access. + (1/07) + +sys/mtio/mtparse.x + When called with sz_attrl=0, could write to attrl[0] (write off the + beginning of the array). Zero is of course not a legal index, but + the routine should be able to accept it as a size, indicating that + the attrl string is not desired. In cases like this the application + must still allow space for 1 char of output, e.g., the EOS. (1/08) + +sys/mtio/mtrewind.x +sys/mtio/mtposition.x + These routines were constructing the magtape device name in order to + position to a specific file, but were discarding the attrl field, + preventing use of tapecap attributes on the command line in a rewind. + Changed to use mtfname to construct the device name. (1/08) + +sys/ki/irafks.x + Modified the debug output logging code to print more of the ARG + array in the command packet. Modified the zfiomt interface debug + logging code to include devcap in the diagnostic output. (1/08) + +sys/ki/kzrwmt.x +sys/ki/kzopmt.x +sys/ki/kopdpr.x +sys/ki/kgfdir.x + These routines were not computing the value of p_sbuflen correctly. + This can affect optional string arguments passed in the networking + packet header. (1/08) + +unix/hlib/irafuser.csh + Changed the definition of mkz to link "-z -/Bstatic". Omitting the + -Bstatic has caused too much trouble on SunOS, when linking on one + version of SunOS and executing on a different version. (1/08) + +unix/hlib/login.cl + Added a definition for the convenience alias "cls" (unix clear;ls) + to the template login.cl. (1/08) + +sys/mtio/mtopen.x +sys/mtio/mtcache.x +sys/mtio/mtrdlock.x + Modified to pass the mtname parameter though to mtallocate, which + can be called by mtrdlock.x in some circumstances. (1/08) + +unix/os/zfiomt.c + 1. Repeated calls to mtexamine on the same tape would result in the + tapeused value incrementing slightly in each iteration. This was + due to the space for the last (EOT) filemark being counted in each + read of the tape. The problem would only show up on some drives; + this was because the file mark size is only set to a nonzero value + for some devices in tapecap. + 2. Modified the driver to record the checksum of the status output + device, and check to see if the device has changed when the driver + is opened repeatedly. It will now automatically (witout flpr) + detect any changes and close and reopen the status device. + 3. Status output to a file is now enabled if there is a / anywhere + in the filename, not just as the first character. Hence, :so=./file + would write to a file in the current directory. (1/08) + +sys/mtio/mtgtyopen.x + Modified to permit inclusion of device capabilities in the tapecap + definition. The syntax of a tapecap environment definition is now + , e.g., "home$tapecap:so". Either + field can be omitted. For example, set tapecap = ":so=host" would + cause MTIO to use the default tapecap (dev$tapecap) but enable + status output to the named host for all magtape operations. + + Device capabilities can now be specified in the tapecap device + entries, in the tapecap environment variable, or on the command line + (as in "mta[:so=host]"). The precedence is the command line, which + overrides everything, the tapecap environment variable, which + overrides the tapecap file entries, and the tapecap file entry + (followed lastly by the builtin defaults where applicable). (1/09) + +unix/os/zfioks.c + 1. Modified the rsh based connect code to add a fallback to rexec + (with a password prompt) if the rsh fails for any reason. If the + connect succeeds, the daemon process will still be started as with + rsh, hence all further connects will suceed by direct connection to + the daemon. In practice, what this means is that if an attempt is + made to connect to a node to which rsh cannot connect (e.g., because + there is no entry in hosts.equiv on the server node), the system + will print "access denied", prompt for the user password, and then + connect normally. Subsequent connects will succeed immediately, + without any further password prompts, until the daemon process times + out and shuts down. + + 2. If the integer variable "KSAUTH" is defined in the user + environment, the value of "auth" in the user .irafhosts file is + ignored and the environment value is used instead. This makes it + possible to dynamically assign authorization codes in the user + environment at login time, if someone doesn't like having their + kernel server authorization code in the .irafhosts file. (1/10) + +dev/termcap +dev/graphcap + Modified and tested these entries for lw9 and lw10 on tucana, + ursa, and gemini. (1/20 - jb) + +unix/hlib/zzsetenv.def +unix/hlib/clpackage.men +unix/hlib/clpackage.hd +unix/hlib/clpackage.cl + Added entries for the new core system PROTO and OBSOLETE packages. + (1/23) + +sys/mwcs/mwcs.h + Increased MAX_WATTR from 64 to 256, and resized the main MWCS + descriptor accordingly. (1/30) + +pkg/proto/* + +pkg/obsolete/* + +unix/hlib/clpackage.cl +unix/hlib/clpackage.hd +unix/hlib/clpackage.men +unix/hlib/zzsetenv.def + Added the new core IRAF system packages PROTO and OBSOLETE (the old + NOAO package PROTO is renamed NPROTO for noao-proto). PROTO is for + prototype or adhoc (interim, not fully general) tasks. OBSOLETE is + for obsoleted tasks that are one step away from disappearing. (Jan 92) + +pkg/images/tv/* + The TV package was extensively revised, adding the new tasks IMEDIT, + IMEXAMINE, TVMARK, and WCSLAB and moving all the IIS control tasks + (which don't work with display servers such as imtool or saoimage) + to a new subpackage IIS. The new tasks are from the old NOAO PROTO + package, except for WCSLAB, which is contributed software from STScI + written by Jonathan Eisenhamer. (Jan 92) + +unix/hlib/login.cl + 1. All the major core system packages are now loaded automatically + at login time (dataio, images, lists, plot, proto, tv, utilities). + The NOAO package is present but is commented out. + 2. The USER package was redone, adding many common unix tasks + as foreign task aliases. + 3. The CL parameter showtype is now initialized to yes, causing + packages and psets to be marked in package lists. (2/08) + +pkg/images/tv/mkpkg +unix/hlib/mkpkg.inc + Added a USE_IIS conditional. This can be set to "no" in mkpkg.inc + on systems where the IIS package will not be used, to avoid trying + to build the package. (2/10) + +pkg/cl/cl.par + Updated the value of the version parameter to V2.10BETA (should have + done this a few months ago). (2/10) + +unix/hlib/login.cl +pkg/cl/cl.par +pkg/images/images/cl + Set up a mechanism to automatically detect and warn about out of + date login.cl files. A new parameter "logver", for login.cl file + version, was added to cl.par, with the default value being the null + string. The real value is set by an assignment in the login.cl. + When the IMAGES package is loaded, images.cl compares the value of + cl.logver with cl.version and complains (harmlessly) if there is a + mismatch, suggesting that `mkiraf' be used. It is a bit of a kludge + to use images.cl for this, but it is a simple technique and should + work fine, since it is unlikely that anyone using IRAF will not be + loading the IMAGES package at some point (clpackage.cl and system.cl + cannot be used as they are read too early in the load cycle, and + obviously login.cl cannot be used). If there is any question about + the comparative dates of IRAF and the user's login.cl this can be + determined by executing "lpar cl" after the CL starts up. (2/10) + + It is very important with V2.10 that the new login.cl be used. + Magtape i/o depends upon this as does the new package loading scheme. + +imio/iki/oif/oifopix.x +imio/iki/oif/oifupdhdr.x +imio/iki/oif/oifopen.x + A couple of changes were made to improve error recovery for OIF + format images, in the event that a task aborts before an image + creation operation completes. Previously this could leave a pixel + file behind with no associated header file. + + 1. The header of a new image is now updated at open time and at + pixel file create time, as well as when the image is closed. A + legal image results even if the operation is aborted before the + pixel file is created, or before writing the pixel file completes. + 2. The header file is now closed after the immap for new images + and read-write images, as has always been the case for read-only + images. The header is reopened as necessary when updated. In the + case of a new image, it is necessary to close the header or the + header file will be deleted by FIO if the task aborts before the + file is completed and closed. Closing the header of a new image + also frees a file descriptor, and important consideration for + applications that open many images. (2/11) + +unix/os/zfprot.c + The protection code will now silently clobber any existing ..foo + file entry when protecting file foo. There is a slight risk in + this, but it should be miniscule as .. prefixed files are very + rarely encountered (other than for IRAF image header file protection). + Also, the clobber can only occur when a file is protected, a rare + operation in itself except for OIF format images. (2/11) + +sys/gty/gtyopen.x + Modified to allow a device entry input as a character string to be + opened on a GTY descriptor. The routine already permitted a caplist + to be input which would override selected fields of the named device + entry, so the change was to allow the termcap file and device entry + name to be omitted. This routine is a useful corollary to GTYCAPS; + gtycaps takes an open GTY descriptor and returns the device + capability list (caplist) as a string, and gtyopen can now be used + to take the caplist and open another descriptor on it. This makes + it possible to store device entries in any form, not just in termcap + file form. (2/12) + +sys/mtio/mtcap.x + Fixed a bug in this routine. MTCAP takes a magtape device + specification as input and returns as output the GTY tapecap + descriptor corresponding to the named magtape device. The problem + was that it was calling mt_gtyopen and returning the gty descriptor + returned by this routine directly to the client. The client + subsequently calls gtyclose to free the descriptor, but mt_gtyopen + is used within MTIO to cache the most recently referenced tapecap + device entry. When the client closes the descriptor the cache is + left pointing to a nonexistent descriptor. The routine was modified + to call GTYCAPS to get the caplist of the cached descriptor, then + open a new descriptor on this with GTYOPEN. (2/12) + +sys/imio/iki/oif/oifrename.x + This routine calls immapz (what a kludge) to open the image header + and read/edit the pixel file name. A minor modification was required + to preserve the header file name in the descriptor to allow the + subsequent header update to succeed, now that the header file is + closed and reopened for updating. (2/13) + + +pkg/dataio/wfits.par +pkg/dataio/doc/wfits.hlp +pkg/dataio/fits/wfits.h +pkg/dataio/fits/t_wfits.x +pkg/dataio/fits/fits_write.x +pkg/dataio/fits/fits_wheader.x +pkg/dataio/fits/fits_wimage.x +pkg/dataio/fits/fits_wpixels.x + Modified wfits to fetch the default fits blocking factor for a device + from the dev$tapecap file. The user can still overrride this value + (which is usually set to 10) for variable blocked devices, but is no + longer required to know or set the block size for fixed block devices + like cartridge tapes. (2/13 LED) + +unix/as.sparc/ieee.gx + +unix/as.sparc/ieeer.x + +unix/as.sparc/ieeed.x + +unix/hlib/mkpkg.sf.SUN4 +unix/as.mc68020/ieee.gx + +unix/as.mc68020/ieeer.x + +unix/as.mc68020/ieeed.x + +unix/hlib/mkpkg.sf.SUN3 + Installed a custom Sun version of the IEEE-floating to native-floating + conversion routines. The code is actually fairly portable SPP code, + but includes Sun Fortran escapes used for NaN mapping. The routines + iee[sg]nan[rd], used to set|get the reserved (native) magic value + used to replace or match NaNs, are now functional (formerly they + were stubbed out for SunOS). On Sun-3s and Sun-4s, which are IEEE + and unswapped, the only function of the IEEE conversion routines + is to map NaNs to and from the reserved (ieesnan[rd]) value. + + ieemap[rd] (YES|NO) # enable/disable NaN mapping + + A new routine IEEMAP[RD] (YES|NO) is used to explicitly enable or + disable NaN mapping. Note that NaN mapping occurs on both input + and output, for both the scalar and vector conversion routines. + NaN mapping is automatically enabled if IEESNAN[RD] is called. + "call ieemap[rd](NO)" should be called before using the conversion + routines, if NaN mapping is not desired. (2/14) + +pkg/dataio/fits/fits_rheader.x + Modified rfits to replace control characters decimal 0 (00X) to + 31 (1FX) and decimal 127 (7FX) in fits card images with the blank + character. The new fits standard now explicitly defines these + as illegal in fits headers. (LED 14/2/92) + +unix/gdev/sgidev/sgi2uapl.c +unix/sun/screencopy.c + The call to the Postscript "setmatrix" operator was replaced by a + functionally equivalent series of calls to the operators + "initmatrix", "scale", and "translate", in an attempt to make + the Postscript output of these routines more device independent. + (2/14) + +unix/as.sparc/ieee.gx +unix/as.sparc/ieeed.x +unix/as.sparc/ieeer.x +unix/as.sparc/ieee.gx +unix/as.sparc/ieeed.x +unix/as.sparc/ieeer.x + The SunOS IEEE conversion package was modified to add support for + counting any NaN values encountered during input and output + conversions (the portable vops$ieee.gx still remains to be updated). + + The new routines are as follows. + + ieestat[rd] (nin, nout) + ieezstat[rd] () + + IEEZSTAT zeros the counters (since there is no "open" procedure in + this package this must be done explicitly). IEESTAT returns the + number of NaNs encountered in the IEEE input (nin) and the number of + NaN values output (nout). (2/14) + + +unix/as.sparc/ieee.gx +unix/as.sparc/ieeed.x +unix/as.sparc/ieeer.x +unix/as.sparc/ieee.gx +unix/as.sparc/ieeed.x +unix/as.sparc/ieeer.x + I made one change to the IEEE interface - the calling sequence for + IEEMAP[RD] is now + + ieemap[rd] (mapin, mapout) + + i.e., mapping can be enabled independently for input and output. + + The semantics of the IEESNAN routine were also changed slightly. + IEESNAN now has the side effect of enabling mapping for both input + and output (it did this before) and zeroing the statistics counters + (this is new). Hence, setting the native pseudo-NaN value will + initialize the NaN mapping code. (2/15) + +sys/osb/ieee.gx + Installed a new version of the "portable" IEEE conversions package. + This is identical to the version developed for SunOS, with the code + which initializes the IEEE NaN constant commented out (since the way + this is done is system dependent). The new version of the portable + ieee.gx includes the new IEEMAP and IEESTAT/IEEZSTAT routines, and + if input mapping is enabled is capable of detecting and converting + input NaN values to the local pseudo-NaN value. It will also + attempt to convert pseudo-NaN to IEEE-NaN upon output (if mapout is + enabled), but since the IEEE-NaN constant is not initialized the + output NaN value will be something else, usually zero. An + as$ieee.gx version of the file is required to set the true IEEE-NaN + value. In principle this can be done portably using an integer + equivalenced to a floating variable, but the current version does + not bother with that (for output; a similar technique is used to + recognize NaN values in the input). (2/15) + +pkg/images/tv/display/t_display.x + Added a call to IMGIMAGE to strip any image section from the image + name stored in the WCS passed to the display server. Since the WCS + output by display refers to the full image matrix ignoring any + section, defining the image as a section was incorrect. The WCS + still does not deal correctly with dimensional reduction when + displaying images greater than 2 dimensions. + + This was tested with both image raster and QPOE data using RIMCURSOR + to generate coordinates and seems to work correctly. In particular, + the correct physical coordinates are generated for QPOE data + regardless of the QPOE block factor or image section. (2/16) + +sys/qpoe/qpioparse.x + Fixed a bug that was preventing the key=(x,y) (alternate coordinate + system) feature of QPIO from working properly. The code was setting + the IO_EVXOFF field twice but was not setting IO_EVYOFF; hence, given + a key such as key=(dx,dy), XOFF was being set to DY and YOFF would + retain its old value, probably Y. A reasonable looking image would + result but it was the wrong image (we were seeing key=(dy,y)). (2/16) + +sys/imio/iki/qpf/qpf.h +sys/imio/iki/qpf/qpfwfilter.x + Fixed a bug in the code which writes the QPIO filter to the QPF image + header, which would cause it to omit all but the last card when + writing filters longer than will fits on a single QPFILTxx header + card. (2/16) + +sys/imio/imparse.x + The routine was modified to make it a little more forgiving regarding + variations on the standard image section syntax, and to improve error + detection of invalid section specifications. (2/16) + +pkg/dataio/fits/fits_rimage.x +pkg/dataio/fits/fits_wimage.x + Modified rfits so that the ieee +/-NaNs, and +/-Infs are correctly + mapped to a user specified native floating point number. Underflow + values are automatically converted to 0.0. A warning message is + printed on the terminal if any bad pixels were replaced. A warning + message is also printed if valid floating point pixel values > + MAX_REAL or < -MAX_REAL were detected which can happen for both fits + bitpix -32 and -64 images. Imreplace can be used to replace these + explicitly. (LED 2/17/92) + +pkg/dataio/fits/fits_wheader.x + Modified the short_header=yes option in wfits so that the image + pixel type, fits bitpix, and the scaling parameters are printed on + the standard output, along with the image name, size, and number of + records written. (LED 2/17/92) + +pkg/dataio/fits/fits_params.x + Modified wfits so that string parameters that are 1) written + explictly by wfits, and 2) <= 20 characters long including quotes, + will have the / in column 33 instead of 2 spaces past the end of the + string. The affected keywords are OBJECT, ORIGIN, DATE, IRAFNAME, + IRAF-BPX, and IRAFTYPE. (LED 2/17/92) + +pkg/dataioo/fits/rfits.com +pkg/dataio/fits/t_rfits.x +pkg/dataio/fits/fits_read.x + Implemented a scan mode in rfits so that devices which have a slow + single-file file skip function (e.g. dat drives) can be used more + efficiently with the rfits make_image=no option. (LED 2/18/92) + + +dataio$fits/t_rfits.x +dataio$fits/t_wfits.x + Changed the maximum sequence number that can be appended to an output + root image of fits file name from 999 to 9999. This is actually + a format limitation %04d than a numerical limitation. (LED 2/18/92) + +sys/qpoe/qpiogetfil.x + Modified to remove an unneeded trailing comma which was being returned + in some circumstances in the reconstructed filter expression output + by the routine. (2/18) + +sys/qpoe/zzdebug.x + The zzdebug would not link any more due to a routine being referred + to by a name which had since changed (qp_rlmerge). (2/18) + +sys/imio/iki/qpf/mkpkg +sys/imio/iki/qpf/qpfwattr.x + + Added a new routine qpf_wattr to QPF. This is called when an + image descriptor is set up for a QPOE image. The routine checks + for the existence of a series of QPOE header paramters "defattr1", + "defattr2", etc. If present, these are string value parameters, + the string value specifying the name of a parameter to be added + to the output image header, and how to compute the value of the + parameter. For example, defattr1 might have the value + + exptime = integral time:d + + meaning add a parameter "exptime" to the output image header, giving + as the value of the parameter the integral of the range-list of + attribute "time", type double, of the event attribute expression + used to filter the event list used to create the output image. (In + other words, compute EXPTIME, the total exposure time for the + filtered image). Currently, the syntax of the DEFATTRn parameter is + very limited and must be similar to that shown in the example, but + the parameter and attribute names can be anything, and the datatype + can be int, real, or double. Since the parameter is string valued + it will be easy to generalize in the future should we need to do + so. (2/18) + +sys/imio/iki/qpf/qpfcopypar.x + Improved the error recovery. (2/18) + +pkg/cl/gram.c + Constants such as 0:00:60 or even 0:00:59.999999999 could trigger + an "illegal constant" error abort in CL scripts, due to round off + errors in the CL code. Technically there is no reason one cannot + have a number such as 0:00:60 (or 0:00:any-positive-number for + that matter), since the result is well defined, so I relaxed the + overly stringent error checking in the gram.c code. (2/19) + +sys/gio/cursor/grcwcs.x + The code which computes the scale terms for an axis could die on + a divide by zero error when presented with an axis that has no + range. It will now detect the condition and set the scale term to + 1.0; the value is arbitrary, since there is no range on the axis + and deviations from the mean will always be zero. (2/19) + +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfwfits.x + The STF image kernel was modified slightly to support images with + GROUPS=F. When the FITS image header is read, if GCOUNT=F the + parameters GCOUNT, PCOUNT, and PSIZE are initialized as for an image + with a single group and no GPB. The header update code was modified + to omit these parameters when updating an image for which GROUPS=F, + since the parameters should not be present in the FITS image header + if the image unless GROUPS=T. (2/19) + +sys/imio/iki/oif/oifrename.x + An image rename operation such as pix.0001.imh -> pix.imh would + succeed for the header file but would fail to rename the pixel + file. This would often pass unnoticed using a hidden imdir, but + is very evident when using imdir=HDR$. The problem was due to the + use of fnroot in oifrename, in a test to see if the root image + name is the same for the rename operation. This would fails as + fnroot cannot descriminate between image extensions and file + extensions. I replaced the calls to fnroot by calls to zfnbrk, + to get the root offset and hence strip off any logical directory + prefix, which was the point of the original call to fnroot. (2/19) + +unix/os/zfiomt.c + It turns out there was still one case where the new magtape driver + did not emulate the simple unix model of open, write,write,write, + close, open, write,write,write, close, open, etc. The exception was + minor, but caused a problem with the TIB SI driver for the HP drive + on a Sun (the only one of these we have seen so far is at STScI). + The result was a double EOT between each file on the tape, when + appending files with WFITS. + + What was happening is that when the driver was opened to append a + file to the tape, it opened the drive read-only to position the + tape, then closed it and reopened write-only for writing. This is + done to avoid clobbering the tape if an abort occurs during the + file positioning operation. What was happening was that when already + positioned to EOT, the drive would be opened read-only, no positioning + would occur since the tape was already at EOT, the drive would be + closed, and reopened for writing. Hence there was an unnecessary + open-read/close before writing each tape. This should be harmless - + it does not move the tape or talk to the hardware - but it was + triggering a bug in the host driver. + + Evidently (this is my theory at least), this host driver is pretty + clever and delays writing the double file mark marking end of tape. + So long as you just append files it never write the EOT, until the + tape is rewound. A rewind or backspace should trigger writing of + the EOT. What I think was happening was that the open-read would + trigger writing of the delayed-EOT. The host driver would write + two tapemarks and backspace over the second one. Only problem is, + it had already written one (one is always written after every file + even with delayed EOT), so you end up with a double file mark, or + EOT, between every file on the tape. This is a blatant bug in the + host driver. We were able to duplicate this using only using UNIX + TAR by writing a small C program which did close(open(/dev/xxx,0)); + and was called before using tar to append each file. + + As a workaround I have revised the iraf driver to avoid opening the + tape read-only for positioning unless some positioning is actually + necessary. If all one does is append files, the positioning open + is avoided and the simple unix semantics are exactly duplicated, + i.e., all the driver does is open for writing, write the file, and + close. (2/19) + +pkg/dataio/fits/fits_write.x + Replace a call to imgimage with one to imgcluster since the + original purpose of the imgimage call was to extract the root + image name. (have not yet rebuilt dataio) (2/20/92 LED) + +------------------------ +Beta system cut and installed on URSA (2/20). + +unix/os/zfiomt.c + Fixed a bug having to do with error recovery in the event that the + device cannot be opened (as when attempting to rewind or deallocate + a device that is offline). (2/22) + +unix/hlib/login.cl + Modified the template login.cl to allow V2.10 login.cl files to be + used with V2.9 IRAF (available as "irafo" on our systems). It + was necessary to add conditional references for LOGVER and PROTO. + Also, the NOAO package is now loaded by default. (2/22) + +pkg/plot/crtpict.par + Changed the default output device from "dicomed" to "film_recorder". + The latter is a generic device alias set in graphcap to point to + whatever the desired local device may be. (2/22) + +local/login.cl + Updated to V2.10. Edited so that it is fairly generic and has a + chance to work when the system is installed on a different host. + (2/22) + +dev/tapecap + 1. Added local entries for node ursa. + 2. Added a SCSI 5 entry for the Sun HP drive. (2/22) + +dev/graphcap + Additions for Solitaire film recorder. Set the default generic + "film_recorder" entry to point to the solitaire. The Solitaire + is currently interfaced via a custom graphics kernel (modified + version of the SGI kernel) which resides outside the standard + IRAF system, in the NLOCAL package. (2/22) + +pkg/system/rewind.par + Changed the default for the "initcache" parameter from yes to no. + initcache causes rewind to "forget" how many files there are on the + tape, forcing a rescan the next time one seeks to EOT. It is + arguable whether it is safer to init the tape status cache on a + rewind or now, but it sure can be a lot faster on devices with + many files to retain this information. (2/22) + +------------------------- +Beta distribution files regenerated to pick up these changes. (2/22) + +unix/bin.mc68020/gterm.e.403 +unix/bin.mc68020/imtool.e.403 + Added SunOS 4.0.3 versions of the GTERM and IMTOOL executables, + for the convenience of those who have not updated to 4.1.x (as is + the case with argo, locally). (2/23) + +unix/as.sparc/ieee.gx +unix/as.mc68020/ieee.gx +sys/osb/ieee.gx + Fixed a typo in the generic code for ieevupk - an "amovr" should have + been a "amov$t". This would cause type double vector unpack operations + to fail for large numbers. (2/25) + +unix/os/zfiomt.c + Added a new capability "fe" to tapecap. This stands for "file + equivalent" and is the amount of tape in Kb which, in a file read, + is equivalent to a file-skip-forward 1 file operation. This + capability can be used by applications which scan large tapes + containing many files to decide whether to read the rest of the + file, or close the file immediately and open to the next file (which + implies a FSF). On devices (like some DAT drives) where a FSF + operation can be slower than a file read, it is faster to read + small files than to FSF to the next file. If the fe parameter is + missing the value is assumed to be zero, meaning that FSF is faster + than reading the file. Note that "fe" is not used by the driver, + it is an optional parameter provided for use by tape applications + as a device-dependent optimization. (2/27) + +pkg/dataio/fits/fits_read.x + Changed the interpreation of the fe parameter as read from + dev$tapecap from MB to KB. (2/27 LED) + +dev$hosts + Added spud and pantera to hosts file on tucana, orion, gemini and + ursa (MJF 2/28) + +sys/etc/erract.x + Replaced an explicit reference to the common "zjucom" by the symbol + JUMPCOM defined in config.h. (This was a historical oddity, harmless, + but would cause a problem if the name of the common was ever changed + in config.h). (2/29) + +sys/etc/onexit.x +sys/etc/onerror.x + A procedure was added to both of these small packages, for removing + previously posted onerror or onexit procedures. + + onerror_remove (procname) + onexit_remove (procname) + + Previously there was no way to deactivate such procedures, other than + during error recovery or task termination. (2/29) + +sys/mtio/mtupdlock.x + This procedure calls FATAL if an error occurs while updating a lock + file. This was causing problems with magtape error recovery, + because mt_sync, which causes the lock files to be updated, is + posted by MTIO as an ONERROR procedure. If an error occurred and + the lock file could not be updated, FATAL would abort the task, + error recovery would call mt_sync, which would try again to update + the lock file, leading to error recursion or errors during error + recovery, and various nasty scenarios. With this change magtape + error recovery appears to be working correctly again. I tried + several mtexamine runs, aborting each with a ctrl/c (but omitting + the flpr) and the system recovered perfectly each time. (2/29) + +sys/mtio/mtdealloc.x + Added calls to mtdeallocate to sync the MTIO cache (update the lock + files with the current tape position) and then clear the cache, + clearing the entry for the deallocated device as well as forcing all + devices to reload their lock files. This was the source of the + problem where allocating and deallocating device A and then allocating + device B would cause devstatus B to fail. Following this fix various + tests with two devices allocated and accessed together or alternately + were performed without seeing any problems. (2/29) + +pkg/system/rewind.par + Changed the default for the initcache parameter back to yes. It is + essential that the cache be initialized when a tape is removed and a + new tape mounted, and it more likely that the user will rewind the + tape (in software) than that they will deallocate/reallocate. (3/01) + + rewind init[+|-] appears to be working correctly now, probably as a + result of one of the bug fixes made during the period 2/29-3/01. + +unix/os/zfiomt.c + The tapeused counter is now cleared when opening a tape and the tape + position is undefined. This condition forces a rewind and clears + all cached data. (3/01) + +sys/ki/kzopmt.x +sys/mtio/mtcache.x +sys/mtio/zclsmt.x +sys/mtio/zopnmt.x + A number of changes were made to these routines during two days of + beating on the system with ctrl/c interrupts to improve error + recovery. With these improvements the magtape i/o system again + appears to be solid with respect to error recovery. A tape task can + be interrupted either during positioning or during a read and the + system should recover completely, without need to do a flpr (I + didn't do any flprs during all this testing). Interrupting a write + is ok too, but will leave a partial file on the tape. Any kind of + interrupt will cause the tape position to be marked undefined, + forcing a rewind the next time the tape is accessed, and clearing + all cached information (clearing cached tape information when an + interrupt occurs during a read is not necessary in all + circumstances, but simplifies things and is probably safer). + + 1. The kzopmt routine (KI) had a serious bug in that it did not + allocate a KI channel descriptor until after the device open. This + is ok for most devices, but not for tapes since the device open + implies a tape positioning operation which may take a very long + time, and hence is suspectible to interrupts. FIO and MTIO error + recovery has to be able to close a tape device which is "partially + open", or open read-only for positioning, prior to the i/o operation. + The close operation would fail as the kzclmt routine would be + expecting a KI channel descriptor but would not get one, causing + a bogus file descriptor to be closed. This would cause the tape + close to fail and could in some cases result in a segmentation + violation or process panic shutdown. + + 2. zopnmt was modified to update the cached file position after + the driver open. This was necessary to mark the cached entry + for updating, to allow an undefined position to be written in the + event that an interrupt occurred during i/o. + + 3. zclsmt required minor changes for both the interrupt-while- + positioning and interrupt-during-i/o cases. In the IWP case mt_sync + is now called with a status of ERR to cause an undefined position + to be written. In the IDIO case MT_FILNO = -1 in the internal + MTIO descriptor is used to flag error recovery, but due to the + calling sequence of the driver open having changed with the new + driver, MT_FILNO was being overwritten with a valid tape position + during the device close. This would cause a valid position to be + written to the .lok file when a tape operation was interrupted + while i/o was in progress. + + 4. The file position cache code underwent several subtle modifications. + Probably these were not necessary but they bullet-proof the code a + little bit. + + The result of all these changes is that, following an interrupt of + a tape operation, 1) devstatus should always show file=-1, record=-1, + and 2) the next tape operation should cause an automatic rewind + followed by a space forward to the indicated file. It should not be + necessary to flush the process cache. Any other behavior, even if + harmless, is considered incorrect. (3/01) + +sys/etc/xalloc.x +sys/mtio/mtalloc.x +sys/mtio/mtstatus.x + Modified the "devstatus" command to print the tape status file + (.lok file) even if the device is not allocated, provided the file + exists. This is desirable since taping is now permitted even on + unallocated devices, and it is useful to be able to see the tape + status file to see what file the tape is positioned to, how much + tape has been used, etc. If the device has not been allocated + devstatus will still issue a warning message to that effect, as it + has always done, followed by the contents of the .lok file (tape + status file), if such exists. Since existence of the tape status + file no longer necessarily implies that the tape has been allocated, + the header message in the file was changed from "Magtape device X + allocated to ..." to "Magtape device X status ...". (3/01) + +sys/mwcs/mwshow.x + + Added a new routine MW_SHOW to MWCS. This is used to print a + representation of a MWCS to an output file (usually, for debugging + purposes when writing an application). + + call mw_show (mw, out, what) + + The routine does not yet print all that it could about the MWCS. + The argument "what" is not yet used. This routine was described + in the original interface but had never been implemented. (2/25-3/01) + +sys/mwcs/mwcs.h +sys/mwcs/mwsv.h + +sys/mwcs/wfinit.x +sys/mwcs/mwload.x +sys/mwcs/mkpkg + In IRAF v2.10 we increased the max number of WCS attributes, which + affected the size of the MWCS descriptor. This caused the WCS stored + in old QPOE files to be unreadable, since it turns out that while + the MWCS interface (mw_save) encodes a MWCS descriptor in a machine + independent form for external storage, this form is essentially just + a copy of the internal MWCS binary descriptor. When the internal + descriptor changed the old saved descriptors could not be read. + Since QPOE is a runtime binary format there is no requirement that + the files be readable from one version of iraf to the next, but it + is desirable to minimize such incompatibilities, or at least detect + them and issue an appropriate error message. + + Really fixing this problem in a general way is not easy given the + complexity of the MWCS descriptor. What I did was define a separate + MWSV save file descriptor in mwsv.h, deleting the old SV_ entries + from mwcs.h. The old save structure had some extra space in it for + just this sort of emergency, which is zeroed out in the old MWCS + savefile descriptors. Fields giving the MWSV version number, number + of WCS, and WCSLEN (WCS substructure length) were added to the save + descriptor. Since these fields are zero in the old descriptors the + "version number" of these old descriptors is zero. The mw_load code + was modified to use a builtin MWSV version zero value for WCSLEN, + and calculate NWCS, allowing it to read these old descriptors. New + descriptors are written using the actual values for NWCS and WCSLEN + and a version number of 1. Hence, the new mw_[save|load] code can + both read old descriptors and write and read the new descriptor with + its larger max number of WCS attributes. + + I also discovered and fixed a minor problem in the save code. The + SV header (integer) was being read and written directly without use + of the MII routines, hence the MWCS save/load code was not fully + machine independent. The appropriate MII routines were added to + pack and unpack (byte swap) the save header. This won't affect + existing saved MWCS written on big-endian machines like Sun, since + the MII routines merely copy the data on such machines. (2/25-3/01) + +sys/mwcs/mwsctran.x + Fixed a typo in the error checking code. There was a "mw_system" + reference which should have been "mw_ssystem". (3/04) + +plot/pltwcs.x +plot/t_graph.x + Modifications were made to produce a label appropriate for the + wcs type selected rather than always use the world system label + in the image; i.e. if plotting in logical wcs the label is + "Logical pixel" rather than something like "Wavelength (Angstroms)". + The change affects pcol(s), prow(s), and graph. (3/04 FV) + +dev$hosts + Added solarium and taco to the hosts file on tucana and orion. Nigel + added these to ursa and gemini. He also notes that lyra, carina and + aquila can be deleted. (3/4/92 MJF) + +unix/bin.mc68020.403 + +unix/bin.mc68020/gterm.e.403 - +unix/bin.mc68020/imtool.e.403 - + Added a complete bin.mc68020 directory compiled and linked for + SunOS 4.0.3. Deleted the 4.0.3 versions of gterm.e and imtool.e + from the SunOS 4.1.1 version of bin.mc68020. + + In case this problem occurs again here are the symptoms: + + ld.so: warning: /usr/lib/libc.so.0.12 has older revision than expected + ld.so: call to undefined procedure _tolower from 0x20266 + + This occurs when executing any HSI executable on a 4.0.3 system. + If this occurs the solution will be to install bin.mc68020.403 as + bin.mc68020, i.e., + + % mv bin.mc68020 bin.mc68020.411; mv bin.mc68020.403 bin.mc68020 + + Currently there are no plans to ship V2.10 with the 4.0.3 binaries + installed by default. Linking the HSI -Bstatic also avoids this + problem but the executables are quite a bit larger and there may + still be subtle problems which are dependent upon SunOS versions, + e.g., with alloc.e. (3/05) + +sys/imio/iki/qpf/qpfwattr.x + Modified to deal with the case where there is no filter expression + and the QPEX descriptor is NULL. (3/05) + +pkg/images/iminfo/listpixels.x + Modified the listpixels task to use the MWCS axis "format" + attributes if they are present in the image header, and added + support for dimensionally reduced images whose coordinate + transformations are dependent on the reduced axis. (3/6/92 LED) + +pkg/lists/rimcursor.par +pkg/lists/rimcursor.x +pkg/lists/doc/rimcursor.hlp + Added two new parameters wxformat and wyformat to the rimcursor task. + These formats if defined take precedence over the formats stored in + the WCS in the image header, and the internal default format for + all values of the wcs parameter. (Davis 9/3/92) + +sys/mio/mtupdlock.x + This, routine, which updates the magtape device status file (aka + lockfile) was a bit too zealous about error checking and could fail + to update the status file and cause a fatal exit of the task in + circumstances where this was not really necessary, for example when + the old status file did not exist or could not be read. This could + result in the message "fatal error while closing magtape file". I + modified the routine to recover if the old file could not be read + and to take an error exit only if the new status file could not be + written. The error message was changed to "Fatal error writing + magtape device lockfile". (3/10) + +sys/imio/iki/stf/stfaddpar.x + The stf_addpar routine is used for a new image or a new copy of a + non-STF image to add parameters to the GPB. As each parameter is + added a parameter is also added to the open image descriptor (image + header). The imaddX calls for the image header would initialize + the value of any existing header parameters, causing any existing + WCS to be lost (since the standard GPB parameters are for the WCS). + The fix was to omit the imaddX call if the named parameter already + exists in the image header. (3/10) + +sys/imio/iki/stf/stfaddpar.x + The value of STF_PSIZE was being computed incorrectly. There was + an implicit assumption that the CTYPEn field was the same size as + SZ_DOUBLE, evidently made in the original code to simplify the + expression. Rewrote to use an explicit 8 bytes for the CTYPEn field, + and also reordered and commented the expression for clarity. (3/10) + +pkg/images/iminfo/t_imstat.x + Precision was being lost unnecessarily in the computation of the + standard deviation, skew, and kurtosis because two of the + intermediate variables in the computation were real instead of + double precision. (3/10/92, Davis) + +dev$hosts + Added 'elric' to hosts file on tucana, orion, and ursa. Previously + added to gemini by Nigel. (3/11 MJF) + +pkg/images/imutil/t_imslice.x +pkg/images/doc/imslice.hlp + Added wcs support to the imslice task. (3/12 LED) + +unix/os/zfiomt.c + Discovered and fixed another error recovery problem. During testing + using WFITS to write a number of very small images, the program was + spending most of the time doing the file close on the magtape device + (which writes a tape mark and takes a finite time for such a device). + An interrupt would therefore usually occur during the close, resulting + in a half-completed file close; error recovery closes open files, and + the driver was bombing as part of the descriptor had already been + deallocated. The fix was to modify ZZCLMT to check for a partially + deallocated descriptor before proceeding to close the file. (3/14) + +unix/os/zfiomt.c + When appending files to a tape, the space for the file mark was not + being counted, causing an incorrect tapeused value when writing to + DAT or Exabyte. (3/14) + +unix/os/zfiomt.c + Added two new tapecap device parameters "ro" and "rr". If "ro" + (rewind-on-open) is set the tape is rewound on every open to get to + a known position, after which the driver will space forward to the + desired file. If "rr" (rewind-after-close-readonly) is set the tape + is rewound when closed following a readonly operation. These + options are rather drastic, but are provided to deal with drives that + leave the tape in an unknown position after a file operation. (3/15) + + I also looked into the problem of fast techniques for finding the EOT + of large tapes containing hundreds of files. This is important as + seeking to the end of tape file by file where are hundreds of files + can be very time consuming. + + At least in the case of a DAT with the ApUNIX driver there is no + system and driver independent way to do this because the driver does + not report an error if one attempts a fsf N where N is greater than + the number of files on the tape. However, such an operation *does* + leave the drive positioned to EOT, hence operations with large N can + be used to position to EOT or append to a tape. This is perhaps + most easily explained with some examples. Assume we have a tape mta + with 100 files on it. + + wfits dev$pix mta[999] appends a file + mtex mta[999] positions to EOT + mtex mta[998] after the above, reads last file + + After one of the above operations the driver will report that + there are 999 or 998 files on the tape. A mtex of the full tape + would automatically correct this figure. + + Of course if the user knows that there are 100 files on the tape + they could just write to mta[101] or read mta[100], and the driver + would immediately position to the indicated file using a multifile + space operation (if enabled in tapecap). + + Further studies will be needed to determine if there is any way + to exploit this sort of drive behavior in the driver to make things + transparent to the user. + +sys/fmtio/dtoc.x +sys/fmtio/fprfmt.x +sys/fmtio/parg.x +sys/libc/printf.c + Added two new format specifiers %H and %M to FMTIO. These are + identical to %h and %m except that the value to be output is divided + by 15.0 (to convert degrees to hours) before being printed. (3/15) + +pkg/lists/doc/rimcursor.hlp + Added an explanation of the %H format and example of its use to + the rimcursor help page. (3/16 LED) + +sys/fmtio/lexdata.inc +sys/fmtio/doc/lexnum.hlp + The action for the character B in the DHR production was incorrect; + changed from d_d (reduce decimal) to HEX (go to the HEX production). + (3/16) + +sys/fmtio/dtoc3.x + The DTOC3 code had a very nasty problem which showed up on a specific + machine (lepus, mc68882 fp). There is some code in this routine which + goes as follows: + + do i = 1, no_digits { + v = v * 10.0d0 + j = v + v = v - j + (etc.) + + where V is double and J is integer. In the case where this failed + the number being printed was 6 and upon entry to the above loop V + was 0.6 (normalized to 0-1). The int operation J=V was setting J to + 5, but the V=V-J was returning 1.0. In the next loop V was 1 and + V * 10 was 10, causing digit conversion to fail, since the value + being digitized must be a single digit. + + In mathematical terms the code was correct but evidently it was + failing due to some sort of roundoff problem. I added some code + to try to detect this condition and correct it. The statement + J=V was also replaced by J=INT(V+EPSILOND) to round up numbers + which are integral to within the machine epsilon (e.g., 5.99999999 + with 16 or so 9s becomes 6). (3/22) + + This sounds similar to a problem which has been reported before, + it may fix the older problem. + +sys/etc/oscmd.x +unix/as.sparc/oscmd.s + I encountered some sort of bizarre (i.e. very subtle) problem with + a minilanguage which would send an OS escape to the CL to be + executed, while there were already parameter set statements buffered + in the CLOUT. The CL (actually prpsio code) would get both in the + same read and it was causing some problem which I did not have time + to investigate. Added a call to flush(CLOUT) to avoid the problem, + is safer anyway. (3/22) + + [need to add as.mc68020 version or remove from special file list] + +pkg/images/tv/wlutil.x + Wcslab was not working correctly if an image larger than the frame + buffer was displayed with fill=no. (3/25/92 LED) + +dataio$fits/t_rfits.x: Davis, Mar 25, 1992 + Rfits was using the value of the iraf_file parameter instead of the + name of the first output image, if the value was an @file, e.g + "@outlist" and the number of output files was 1. + +dev$hosts + Added Rob Hubbard's machine 'deneb' to hosts file. Added to gemini + and ursa by Ed Anderson (3/31/92 MJF) + +qpiogetfil.x +qpexpand.x +qpexgetfil.x +qpexgetat.x + These routines return the string length of the output string as the + function value. If the output string overflows maxch characters are + returned, however the function value in this case could be maxch-1, + causing the calling routine to fail to detect string overflow. The + code was modified to return maxch if string overflow occurs. (3/31) + +qpmacro.x + Modified to permit QPDEFS statements such as "set nodeffilt", i.e., + a SET statement with no value assignment. (3/31) + +qpex.h + Doubled the default size of the program, data, and expression buffers. + (3/31) + +qpexparse.gx + Timing tests on filter expressions containing many floating range + list terms (e.g. large time filters) revealed that this routine was + very inefficient in its used of fp_equal[rd]. I optimized a couple + of inner loops slightly and was able to speed up expression + compilation by a factor of 10-15. (3/31) + +qpexdebug.x + Modified to allow for output of the full expression string when + used with very long range lists. (3/31) + +-------------------------- +TUCANA upgraded from a 3/160 to a Sparcstation 2. +SunOS 4.1.2, Sun Fortran 1.4, Sun C compiler. (4/03) + +unix/mkpkg + + Added a mkpkg file providing a "mkpkg summary" facility for compressing + reboot output. (4/04) + +unix/shlib/mkshlib.csh + Added support for Sun Fortran 1.4, for sparc only so far. (4/04) + +unix/hlib/mkpkg.sf.SUN4 + Commented out the special file list entry for oscmd.x, I doubt if + it is needed any more. (4/04) + +-------------------------- +Completed a full sparc bootstrap and sysgen-compile for SunOS 4.1.2, +Sun Fortran 1.4, and the unbundled C compiler. (4/04) + +unix/hlib/irafuser.csh +unix/bin.sparc + Set up the HSI to link the HSI executables -Bstatic. I don't like + doing this as the resulting bin is 3.6 Mb, but the libc.a shared + library versions are too much of a headache. HSI executables + linked shared under SunOS 4.1.2 will generate a shared library + warning message when run under 4.1.1, and this is just a micro + version difference. The mc68020 executables (and local nodes) are + still at 4.1.1 so there is no problem there. (4/05) + +unix/boot/mkpkg/host.c + The code used to check two iraf directory pathnames for equality + could fail for pathnames such as /u3/iraf/iraf, containing more than + one "iraf/". This caused the special file list to be ignored in + the recent upgrades and full sysgen. (4/06) + + [all affected files recompiled] + +unix/hlib/install + Modified the install script to choose /usr/local/bin over /local/bin + if both are found. (4/06) + +noao/mkpkg +noao/nobsolete/mkpkg + + Added a stubbed-out mkpkg to nobsolete. Uncommented the commented-out + entries for nobsolete in noao/mkpkg. Restore the original package + build order, which builds all the main packages first followed by + imred. (4/06) + +sys/etc/prpsio.x + The code which intercepts raw mode control sequences would erroneously + match any terminal output string of the same length as a raw mode + control sequence and which begins with ESC (a full equality test was + not being performed). (4/06) + +unix/os/zfiomt.c + Due to a data structure change, tapecap parameter negation as in + "mta[:xx@]" to negate parameter xx wasn't working. (4/07) + +pkg/images/iminfo/listpixels.x + Added a formats parameter for formatting the output pixel + coordinates to the listpixels task. These formats take precedence + over the formats stored in the WCS in the image header and the + previous default format. (4/7/92, Davis) + +unix/os/zfaloc.c +unix/os/zfiobf.c +unix/os/zoscmd.c + Modified these routines to use the user's UMASK to compute the file + mode for a new file. zfiotx.c already does this, although it isn't + entirely correct (one can add more permissions with umask but one + always gets at least 0644 for new text files). The other routines + make full use of umask now. (4/07) + +unix/os/zfaloc.c + Since I was already working on zfaloc I also added a feature to + permit full preallocation of files on unix systems. The default + behavior of zfaloc, for efficiency reasons, is to physically + preallocate only the last block of the file, leaving the remainder + of the file blocks to be allocated when data is written to the file. + Now, if "ZFALOC" is defined in the user's host environment, full + preallocation of the file is enabled. If the variable is defined + but has no string value all zfaloc files are fully preallocated, + otherwise, the string value is a comma delimited list of substrings, + and a file will be fully preallocated only if one of those substrings + matches a substring of the file name in the zfaloc call. This allows + files in certain directories or of certain types to be fully + preallocated while others are allocated in the normal fashion, so + that the behavior of the routine can be customized for a given + type of application. (4/07) + +dev/hosts + Corrected the Loden entry on Gemini for Rich Reed. We should + verify all these paths in the master system. (4/07 RLS) + +dev/pix.imh +dev/pix.pix + Replaced dev$pix by a version that has the header tweaked up a bit. + (4/08) + +dev/termcap + Added entries to allow two-up page printing on all printers. Change + also made to gemini and ursa termcap files. (4/8 MJF) + +pkg/plot/t_pcol.x +pkg/plot/t_implot.x +pkg/plot/t_graph.x +pkg/plot/t_pcols.x +pkg/plot/t_prows.x +pkg/plot/pltwcs.x +pkg/plot/graph.par +pkg/plot/prow.par +pkg/plot/prows.par +pkg/plot/pcol.par +pkg/plot/pcols.par +pkg/plot/doc/graph.hlp +pkg/plot/doc/implot.hlp +pkg/plot/doc/prow.hlp +pkg/plot/doc/prows.hlp +pkg/plot/doc/pcol.hlp +pkg/plot/doc/pcols.hlp + 1. Modified GRAPH, IMPLOT, PROW(S), and PCOL(S) to define and set a + coordinate format in plots. This allows graphs to be made in + DD:MM:SS and related formats. + 2. Modified GRAPH, IMPLOT, PROW(S), and PCOL(S) to use any WCS + attribute coordinate format found in the images. + 3. Added xformat and yformat parameters to GRAPH, PROW(S), and + PCOL(S) to define coordinate plot formats. This allows having a + format when a format attribute in not found in the images, to + override a format attribute, and to allow setting the format in + simple text input. For example, GRAPH can plot formated RA and DEC + from a list of input RA and DEC coordinates. + 4. Added a ":f format" to IMPLOT to allow specifying/overriding the + WCS attribute format. + 5. Added as a key in IMPLOT to print coordinate and pixel + value information: + line=256, column=142, coordinate=13:27:55.6, value=222. + (4/9 Valdes) + +pkg/cl/exec.c + The symptom of this bug was that if a package which has package + parameters was loaded at login time and the package parameters were + later edited, the edited values would not be used. + + This was traced to a problem with the pfile pointer in the package + descriptor pointing to a discarded copy of the package pset. The + PACKAGE command, executed in the package script task when the package + was loaded, would quite correctly set up the package descriptor + pointing to the runtime copy of the package pset for the package + script task. When EOF of the login.cl was reached the package + script task would terminate and the runtime pset would be copied + back to the main package pset and the runtime pset freed - but the + package descriptor was left pointing to the old, no longer used pset. + + The fix was to modify oneof() (that's "on-eof"), called when a task + terminates, to check if the task is a package script task and if + so fix the package descriptor to point to the main pset. (4/09) + +pkg/cl/builtin.c +pkg/cl/pfiles.c + "unlearn pkgname" will now unlearn the package parameters of package + pkgname, as well as the parameters of each task in the package (but + it does not descend into subpackages). (4/09) + +sys/libc/cprintf.c + +sys/libc/scanf.c +sys/libc/mkpkg + Added an interface of the VOS printf routines to LIBC. These are + the routines c_printf, c_fprintf, c_parg[bcsilrd], and c_pargstr. + LIBC already has unix stdio-like print routines, but the VOS + routines avoid the varargs stuff, and do automatic type conversion. + (4/11) + +pkg/cl/gram.c +pkg/cl/debug.c +pkg/cl/y.output +pkg/cl/ytab.c +pkg/cl/ytab.h +pkg/cl/grammar.y +pkg/cl/opcodes.c +pkg/cl/compile.c +pkg/cl/opcodes.h +pkg/cl/scan.c +pkg/cl/builtin.c +pkg/cl/mkpkg + Added the long-awaited ability to scan from a pipe (or whatever the + stdin is connected to). Also added the new formatted scan and print + routines scanf, fscanf, and printf. These are like the unix/stdio + versions but use FMTIO, supporting such FMTIO features as %h and + %*.*. For example, + + cl> printf ("%d foo %g\n") | scanf ("%d foo %g", i, x) + + or + while (fscanf (list, "%d %s", i, s1) != EOF) + printf ("i=%d, s1=`%s'\n", i, s1) + + Don't forget the [f]scan routines, which may still be more convenient + for simple unformatted scans. + + The new printf routine uses the VOS PARG routines to pass argument + operands, hence provides automatic type conversion on output. If an + incorrect number of arguments are passed an incomplete format error + will result. The scanf routine is an interface to the LIBC scanf + routine (actually, u_doscan). The CL scanf/fscanf routines call the + LIBC scanf which parses the format string and writes the output + values whose addresses are passed in a manually crafted varargs + argument list. Since scanf writes directly into the value fields of + the output parameter descriptors, no automatic type conversion is + possible and there is no checking for string overflow when writing + to a string valued parameter. Care should be taken to make sure the + scanf format matches the datatypes of the output parameters. (4/11) + +pkg/cl/debug.c + Fixed a minor problem with the uncompiled output, where non-string + values output for pushconst would contain a trailing '. (4/11) + +unix/os/zfiobf.c +unix/os/zfiotx.c +unix/hlib/libc/kernel.h + Tested the recently added umask support and made a few changes. The + umask semantics for text files are now identical to those for binary + files etc. (4/11) + +unix/hlib/zzsetenv.def + Added an entry for the gty system source directory. (4/17) + +pkg/plot/doc/gdevices.hlp + +pkg/plot/gdevices.par + +pkg/plot/gdevices.x + +pkg/plot/mkpkg +pkg/plot/plot.cl +pkg/plot/plot.hd +pkg/plot/plot.men +pkg/plot/x_plot.x + Added a new task GDEVICES to PLOT. This task will scan the active + graphcap database and print a table of the available devices in the + given class of devices (by default the stdimage devices), giving for + each device a list of the device aliases, the device resolution in + X and Y, and a short descriptive string if one was given in the + graphcap entry for the device. See the help file for examples. (4/18) + +sys/mwcs/imwcs.h +sys/mwcs/iwctype.x +sys/mwcs/iwsaxmap.x +sys/mwcs/mwloadim.x +sys/mwcs/mwsaveim.x + Various changes were made to fix the MWCS "dimension mismatch" + problem. This would happen during an image open (iw_saxmap) when + the dimension of the WCS was different than that of the image and + an image section was in use. The error was being detected in + mw_saxmap and was correct, i.e., the routine was being called + incorrectly by iw_saxmap, part of the image header interface code. + + Evidently axis mapping was not fully implemented; it worked for + runtime read-only maps of an image, but failed when making a new + image which was a reduced-dimension section of another image + (e.g., imcopy dev$pix[*,10] pix1 would do it). The new image would + retain the original WCSDIM which would not match the physical image + dimension when the new image was later opened with a section and + a new axis map created. + + The fix was to preserve the axis map in an mw_saveim/mw_loadim + operation, and in iw_setaxmap, merge the new axis map for the + reduced-dimension image into the axis map associated with the stored + MWCS. A new image header parameter WAXMAPnn was added to store the + axis map. iwsaxmap.x now reads the old axis map of dimension + MI_NDIM, and merges it with the axis map for the new image of + dimension IM_NPHYSDIM. (4/19) + +sys/mwcs/mwloadim.x +sys/mwcs/mwopen.x + The axis map, even if unused, is initialized to the unitary + transformation when a new MWCS is created. (4/19) + +sys/mwcs/iwctype.x +sys/mwcs/mwsaveim.x + The FITS CD matrix as used in MWCS was transposed relative to what + the draft FITS standard requires. Modified the iwctype.x code (input) + and mwsaveim.x (output) to swap the I,J axes in the CDi_j keyword, + in effect transposing the matrix as seen by MWCS. (4/19) + +sys/mwcs/iwewcs.x + Deleted the comma in "axis 1: axtype=ra, axis 2: axtype=dec" (in the + "ra,"). The attribute list syntax does not permit a comma in this + context and it is included in the axtype string value. (4/19) + +sys/mwcs/iwewcs.x + Modified the code which sets up the CD matrix in the case when no + CD matrix is given in the image header (in which case CDELT/CROTA2 + is normally used instead) to use a double DO-loop to initialize the + CD matrix to the unitary matrix. The old code had two bugs: 1) the + full WCSDIM dimensioned CD matrix was not being initialized when + CDELT/CROTA2 were used instead of the CDi_j notation, and 2) mk_idmd + was being used to initialize IW_CD to the unitary matrix of dimension + ndim, but this was no good as IW_CD has a fixed dimension of MAX_DIM. + It is necessary to use an explicit DO-loop instead. (4/19) + +sys/mwcs/iwpstr.x + Added a statement "Memc[bigstr+nchars] = EOS" after the blank fill + loop - the string was not explicitly EOS terminated. (4/19) + +sys/mwcs/mwgwtermr.x + Changed the aclrr in the code used to initialize the CD matrix, to a + call to mw_mkidmr, which makes the identity matrix. Formerly a zero + matrix was being returned instead of the identity matrix. (4/19) + +sys/mwcs/mwmkidmr.x + +sys/mwcs/mkpkg + Added a new routine mw_mkidmr, used to create an identity matrix of + type real. (4/19) + +pkg/images/imutil/imdelete.x + A portion of the image title string is now included in the "delete + image..." message when the verify option is enabled. (4/20) + +sys/gio/cursor/gtr.h + Increased the default max graphics frame buffer from 64K to 128K. + (4/20) + +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Added a commented out entry for "imtype" to the template login.cl. + Added values for imtype, cmbuflen, and min_lenuserarea to zzsetenv.def. + The values for imtype and cmbuflen are the same as the builtin + defaults. The value for min_lenuserarea is temporarily set to 20K, + until the real problem of image header truncation can be in the IMIO + code. (4/20) + +pkg/proto/proto.cl +pkg/proto/proto.men +pkg/proto/proto.hd +pkg/proto/x_proto.x +pkg/proto/mkpkg +pkg/proto/wcsreset.par +pkg/proto/t_wcsreset.x +pkg/proto/doc/wcsreset.hlp + A new task wcsreset has been added to the proto package. + (4/21 LED) + +sys/gio/glabax/glbfind.x + GLABAX now uses a different, hopefully better algorithm for determining + the spacing of the minor ticks (formerly the tick spacing algorithm + used was the same as used for the major ticks). As before, NMINOR + is used as only a starting point for the automatic algorithm. It + is now possible however to disable the automatic algorithm by giving + a negative NMINOR, in which case exactly abs(nminor) ticks will be + drawn. (4/21) + +sys/fio/vfntrans.x + The code in the vfn_translate routine which recognizes subdirectories + was not sufficiently discriminating about "." and "..", and would + treat . prefixed files as subdirectories during translation. (4/21) + +sys/fio/fntgfn.x + Modified the file template code to check for a leading "." in the + pattern string and automatically enable listing of the hidden files + in a directory in this case. (4/21) + +pkg/proto/proto.cl +pkg/proto/proto.men +pkg/proto/proto.hd +pkg/proto/x_proto.x +pkg/proto/mkpkg +pkg/proto/wcsedit.par +pkg/proto/t_wcsedit.x +pkg/proto/doc/wcsedit.hlp +lib/scr/wcsedit.key + A new task wcsedit has been added to the proto package. + (4/22 LED) + +unix/os/zfiotx.c + In a normal raw mode read the terminal driver has interrupts + enabled, but catches any interrupt occuring during a read and maps + it into 003. This approach doesn't work for nonblocking raw mode + reads because since reads don't block, the driver spends only a + miniscule amount of time in the ZGETTX read code. This would cause + interrupts to abort a task doing nonblocking raw mode reads. The + fix was to have the driver put the terminal into true raw mode, with + signals disabled, when nonblocking raw mode is in effect. This + applies to suspend as well as interrupt. (4/22) + +sys/imfort/db/imputd.x +sys/imfort/db/mkpkg + The double precision value could be truncated in some cases when + copying the formatted string into the 20 char value field. Modified + (like imio/db/imputd.x) to use a loop, decreasing the formatted + precision until the value fits. (4/22) + +-------------------------- +"Final" V2.10.0 beta generated. After this only minor bug fix type changes +will be made. + +pkg/images/register.par +pkg/images/geotran.par +pkg/images/doc/register.hlp +pkg/images/doc/geotran.hlp + Changed the default values of the parameters xscale and yscale in + the register and geotran tasks from INDEF to 1.0 (4/23 Davis) + +pkg/images/geometry/t_imtrans.x + Modified the imtranspose task to pick up the axis map and copy + it to the wcs of the output image. (4/23 Davis) + +pkg/images/geometry/t_blkavg.x +pkg/images/geometry/t_blkrep.x + Modified the blkrep and blkavg tasks to set axbits explicitly in + the calls to mw_shift and mw_scale. Axbits set to 0, meaning + all axes, was producing a "singular matrix" error from mwcs. + (4/23 Davis) + +unix/os/zgtenv.c + A link of an IMFORT program using V2.10 IRAF, compiled on a 4.1.1 + system, would fail with an + + ld: Undefined symbol + _tolower + + on a 4.0.3 system. This is actually the second time I have run + into this problem. It is caused by SunOS changing tolower from + a macro to a library routine in 4.1. The problem was avoided by + changing the iraf code to define a macro to_lower which is used + instead. (4/23) + +dev/imtoolrc +dev/graphcap + Added new imt entries for Nigel's Solitaire formats. These are + named imt17|imtssy and imt18|imtssn for resolutions of 1008x648 and + 1024x680 respectively. Also added to gemini, ursa and orion. (4/23 MJF) + +pkg/images/geometry/t_imslice.x + Modified the imslice task to read the old and write a new axis map. + (4/23 LED) + +pkg/images/geometry/t_imstack.x + Modified the imstack task to read the old and write a new axis map. + (4/23 LED) + +pkg/cl/grammar.y + When scan from a pipe was used in a procedure script the scan would + not write into a parameter belonging to the procedure calling scan. + This was happening because except for the call by reference arguments, + scan is implemented as a CL task. The usual parameter search order + would apply, i.e., task (scan), package, cl, hence the parameters for + the task calling scan would not be seen. This could be gotten around + by referencing the parameters as task.pname, but this should not be + necessary. It was necessary to change the cl compiler to convert + names such as "param" to "task.param" when compiling scan statements + (scan as a task). This is only done if no task or package name is + given and the current task's pset includes the named parameter. (4/26) + +dev/hosts + Corrected the loden entry and updated the khaki entry (it's now + a sparc) for Rich Reed on tucana, gemini, and ursa. I had fixed + the loden entry previously (4/7). It must have been clobbered + somehow in the last three weeks. (4/27 RLS) + +dev/termcap +dev/graphcap + Added contributed entries for the HP LaserJet III series printers. + These entries are known to work but given the variety of PostScript + cartridges available may need some adjusting. Included in 2.10 + because the HP sgi translators are now distributed. (4/27 MJF) + +pkg/dataio/fits/fits_read.x + Modified rfits to use the tapecap fe parameter if present and + greater than 0 to skip to EOF. (4/27 LED) + +sys/mtio/mtio.h +sys/mtio/mtcache.x +sys/mtio/mtcache.com + The symptoms of the bug fixed here were as follows: when testing the + fixed block cartridge drive, mtexamine and rfits make+ would work fine, + but rfits make- would fail with a read error. The failure would only + occur the second time the task was run, on the tenth file, and only + when diagnostic output was enabled. The read error was occurring + because, for some reason, the read request being issued by IRAF was + not a multiple of the device block size for this fixed block device. + + It took about 5 hours to track this one down as it took a while to + find a repeatable test case (I used LOGIPC), and the actual bug was + far removed from the read error seen during testing. What was + happening was that the 1) the read error was due to a read request + not a multiple of the device block size, 2) the bad read request + was due to a device open with no tapecap information (the driver + actually works in this case, using all the builtin defaults which + are correct for most variable block UNIX devices), 3) the lack of + tapecap information was due to an invalid string pointer passed to + the zopnmt routine at open time, 4) the bad pointer was due to the + real GTY pointer being clobbered by a bug in the mtcache code. The + entire MTIO descriptor was being cached, including the runtime fields + as well as the positional fields. When a cached entry was recalled + the GTY pointer stored in the descriptor would be overwritten. Since + the cache is updated in the first open following task invocation the + cached values for the runtime fields would normally be valid and no + error would be seen. (4/29) + +pkg/proto/doc/suntoiraf.hlp + Replaced the suntoiraf help pages with an updated one. (4/30 LED) + +unix/boot/spp/xc.c + If a library specified as -lname does not resolve to an iraf library + (i.e. it is a host library) the library will now be searched after the + iraf libraries are linked, rather than at the location of the -lname + in the link line. This allows searching of special host libraries + after the iraf externals have been generated and before the standard + Sun libraries libc, libm, etc. are searched. If the old behavior + is desired it can be achieved by using a reference of the form + libname.a in place of the -lname. (4/30) + +unix/shlib/mkshlib.csh + Modified to link against -lresolv, if such exists, when building the + iraf shared image. This allows the statically linked iraf executables + to use the name server. By default only SunOS executables which are + dynamically linked use the name server. The -lresolv code will fall + back on the /etc/hosts file if the name server does not respond, so + this should be safe. (4/30) + +dev/hosts + Added kingfisher (aliased as 'kingfishe') to hosts file on tucana, + orion, gemini and ursa. (4/30 MJF) + +unix/hlib/mkiraf.csh + Updated the terminal type prompt slightly. (4/30) + +unix/hlib/irafuser.csh + Disabled the -Bstatic option for linking the HSI executables. This + causes f68881_used undefined error messages from the linker on a + Sun-3 (but it is ok on a sparc). (4/30) + +dev/wpix.imh + + Added a second version of the test image dev$pix called dev$wpix. + This is dev$pix with a WCS in the image header. To save space, both + image headers point to the same pixel file. (4/30) + +unix/hlib/motd +unix/hlib/login.cl +unix/hlib/zzsetenv.def +pkg/cl/cl.par + Changed IRAF version to V2.10EXPORT. (4/30) + +-------------------------- +Built initial V2.10EXPORT distribution files and began testing of same. +V2.10EXPORT was installed from the network archive on ursa, orion, and +several mountain nodes to check with problems having to do with how the +distribution was built. (4/30) + +local/.login + 1. Commented out the "setenv TERM sun". This was getting pretty + annoying as I usually use an xterm. Better to let the login inherit + the terminal type. + 2. Added a set prompt statement for a "iraf@hostname% " type prompt. + 3. Made the "setenv iraf" a bit smarter. iraf is still set to a + constant value, but the file now checks to see if $iraf exists and + if not sets $iraf to `(cd ..;cwd)`/. The constant value is still + desirable to allow use of symbolic directory links. + (5/02) + +unix/os/zzstrt.c + Modified this routine to map the data and bss sections of the iraf + shared image with execute permission. There are cases where the Sun + compilers can generate executable code in the data segment. Old Sun + hardware does not implement hardware checking for execute + permission, but some of the new hardware does. This was causing a + routine (iraf networking using the name server library, which is + linked -pic) to fail on a new Sun multiprocessor system which would + execute fine on older hardware. (5/02) + +unix/bin.sparc/gterm.e +unix/bin.sparc/imtool.e + Rebuilt these executables under SunOS 4.1.1. The versions built under + 4.1.2 would cause shared library version older than expected warning + messages when run on a 4.1.1 system. (5/02) + + (It is not necessary to do this for the bin.mc68020 versions since + our Sun-3s are still all running 4.1.1). + +unix/hlib/install + 1. Smartened up the code used to guess the iraf root directory. It now + looks for /iraf/iraf before /iraf in the "pretty name" section (needed + to support symbolic links). When all done, it checks to see if the + directory actually exists and if not sets the value to (cd ../..;cwd) + instead, assuming install is being run from $iraf/unix/hlib. This + latter feature also has the effect of ignoring an incorrect value of + $iraf set before running the install script. + 2. Added a "set hlib = " to the "Set the BINDIRS" section. An old + value of hlib set when install was run would otherwise be inherited + ignoring the new value of $iraf set in the script. (5/02) + +sys/imfort/imflsh.x + The integer function bfflsh was being called as a subroutine with the + wrong number of arguments. (5/02) + +-------------------------- +Performed a sysgen to pick up the zzstrt.c change above, and rebuilt the +distribution files. (5/02) + +unix/hlib/install + Added a $iraf relative definition of $host, since this is used in the + MODEFILES definition but is not defined in the script, hence would be + inherited from outside, possibly with the wrong value. (5/03) + +unix/os/zfioks.c + Fixed a minor bug in the new zfioks code. If client authorization + fails (as when one has different authorization codes in .irafhosts + files on different nodes) the driver is supposed to shutdown the + old in.irafksd daemon and start another one via rsh for the new + authorization code. This was failing as a status value was not being + cleared before doing the rsh. The rsh would succeed but then the + client would see a bad status and give up (unnecessarily), falling + back on a password prompt and rexec call to make the connection. + It was actually working due to the redundancy in the driver, but + due to the bug one would get the unnecessary password prompt for the + rexec. (5/04) + +dev/tapecap + Fixed a typo (wrong device entry) in the mtst1.qic-24 entry. (5/05) + +unix/os/zfmkdr.c + This routine was missed a while back when the UMASK support was + redone. (5/06) + +dev/tapecap + The entries for the QIC drives were modified to fix a problem where, + e.g., every other file on a tape would be read in an operation such + as rfits. Currently the :se capability is only enabled for the QIC + drive on ursa, since this appears to be needed only for the ST + driver bug seen on this system. The fb#2000 capability (which avoids + file skip operations which cause problems on the QIC drives due to + (I think) buffered data being lost) is more generic and harmless so + I moved that to the generic device entry. (5/07) + +sys/imio/iki/ikiopen.x +sys/imio/iki/ikiinit.x +sys/imio/iki/ikildd.x +sys/imio/iki/iki.h + IKI was modified to add a flag word for each driver which can be + used to note IKI level characteristics of the different image kernels. + This was used to flag that the QPF driver cannot write to or create + QPOE images. In a new copy operation, iki_open will not automatically + preserve the image type if the read-only flag is set for the input + image type. Hence, in a new copy of a QPOE image, the type of the + new image will be controlled by the imtype environment variable rather + than trying to make a .qp image. For other images types a new-copy + operation will preserve the image type as before. Explicitly giving + the image extension for a new image always forces that type of image + to attempt to be created, whether it can be created by the image + kernel or not. (5/07) + +sys/imio/iki/stf/stfhextn.x + This bug was unrelated to the above change but was found during + testing (in fact it has been there for years). In v2.10, "imtype" + is set by default, with value "imh". In an imcopy operation such as + + imcopy foo.hhh foo2 + + the output image preserves the image type of the input image, + i.e., an STF image is created. What was happening was that an STF + image was being created named "foo2.imh", since imtype was set to + "imh" and this is a legal STF image extension. I hacked stfhextn.x + to ignore imtype if set to "imh". (5/07) + +pkg/dataio/fits/fits_wheader.x +pkg/dataio/fits/mkpkg + Modified the wfits file format message to include a "blkfac=xxx" + field. The xxx is the blocking factor for variable blocked devices, + and the string "fixed" for fixed block devices. (5/07) + +-------------------------- +Rebuilt distribution files. (5/07) + +dev/hosts + Added 'dynamo' to orion, gemini, and ursa. Primary name is + 'dynamo.kpno.noao.edu' since this is all it responds to, but made an + alias named 'dynamo'. Not added to Tucana while release being worked + on, I'll do it later. (5/8/92 MJF) + +dev/termcap + Made an entry for the machine in Pat Osmer's office, lw8, on gemini, + ursa, and orion. Added to Tucana by JB. (5/8/92 MJF) + +unix/os/zfiomt.c + 1. Changed the builtin defaults for the maximum and optimum record + sizes to 64512. This is a more conservative value, smaller than the + original defaults (maxrec was previously 65535), hence less likely + to cause a read error. The builtin defaults are overridden in most + tapecap entries but will be used in user-written tapecap entries + which do not set maxrec/optrec explicitly and are likely to rely + heavily on the builtin defaults. The value 64512 is the largest + multiple of 1024 less than 65536, and is the minphys value in SunOS. + On some devices a read request larger than this value cannot be + serviced and will result in an i/o error. + + 2. The maxrec value set in tapecap was not being used for file + positioning where the driver searches for EOT by skipping a file + and reading a record to check for EOT (a read after a fsf which + returns zero signals EOT). On some devices the large read request + could cause the read operation to return an error. + + 3. If a nonzero maxrec value is set, the driver now guarantees that + optrec will not be greater than maxrec (this was not necessary since + MTIO does this anyway, but it seems advisable to apply the constraint). + (5/28) + +pkg/images/tv/wcslab.par +pkg/images/tv/wcslab/doc/wcslab.hlp + Changed the default value of the fill parameter from no to yes. + (LED 5/29) + +pkg/xtools/doc/inlfit.hlp + The xtools inlfit help was not hooked up due to a bug in the inlfit + help page. (LED 5/29) + +pkg/images/doc/imstat.hlp + Fixed a bug in the definition of variance in the imstatistics + task help page. (LED 5/29) + +sys/mtio/mtio.h + Changed the magtape lock file directory from uparm$ to tmp$. Storing + the lok (magtape position) files in uparm causes problems if the + user starts up two concurrent CLs with different uparms, and then + tries to command the same device from both CLs. Since they would have + different uparms they would have different copies of the lok file for + the device, and MTIO could get confused about the tape position. + Years ago, in the early days of MTIO the lok files were moved to + uparm to avoid multi-user problems (see below), but the multi-user + problem is tractable and less of a problem than the concurrent-CL + problem dealt with here. (5/29) + +pkg/system/x_system.x +pkg/system/mkpkg +pkg/system/system.cl +pkg/system/mtclean.x + +pkg/system/mtclean.par + +sys/mtio/mkpkg +sys/mtio/README +sys/mtio/mtclean.x + + Added a new (hidden) system task called MTCLEAN. This is called at + CL startup time to delete old magtape lok files. Previously the + login.cl file would delete these files using "delete + uparm$mt*.lok". This approach is no longer discriminating enough + however, when the lok files are stored in tmp$ which is a public + directory. The MTCLEAN task is like "delete uparm$mt*.lok" except + that it leaves a lok file alone if it belongs to a different user + who currently has the drive allocated. If the lok file is for a + device which is not currently allocated it is unconditionally + deleted. If the lok file belongs to the current user it is deleted + only if it is "stale", i.e., older than a certain interval + (currently one hour, and a parameter default). + + It is harmless to delete lok files in the sense that MTIO will + automatically recover (by rewinding the tape) if the lok file is + lost, so it is safest to err on the side of occasionally deleting a + lok file which is current. However, this will only happen if the + user has not allocated the drive and someone starts up a CL, or if + someone using an allocated drive starts up a second CL and the lok + file is older than the "stale" threshold. (5/29) + +unix/hlib/motd +unix/hlib/login.cl +pkg/cl/cl.par + Changed the login.cl version string to force a mkiraf to pick up + the "mtclean" addition. This was done by adding a "revision 1" + to the logver string. (5/29) + +pkg/obsolete/doc/imtitle.hlp +pkg/obsolete/doc/mkhistogram.hlp +pkg/obsolete/doc/radplt.hlp +pkg/obsolete/doc/oimcombine.hlp + Added a "USE INSTEAD" section to the help pages for the obsolete + tasks. (5/29 LED) + +pkg/system/doc/rewind.hlp + Added some comments on the "initcache" parameter to the help page + for the REWIND task. (5/29) + +dev/tapecap + Added support for the HP DAT drive under the ApUNIX driver. (6/03) + +unix/hlib/clpackage.men + At Bob Hanisch's request changed "obsoleted tasks" to "obsolete + tasks" so that stickers for obsoleted grammar won't cringe when + reading this menu. (6/19) + +unix/hlib/login.cl + Several minor changes were made to the template login.cl over the + past couple of weeks. + + 1. The "stty xterm" statement in if(envget("TERM")=="xterm") was + changed to "stty xterm nl=44". Since xterm does not have a screen + size sense query (like gterm) we can't set the screen size correctly, + but it is better to set a small wrong value than a large wrong value + like the termcap default of 65. + 2. Added an if(deftask("mtclean")) to prevent mtclean from being + called if it isn't defined, i.e., when running irafo=v2.9. + 3. Moved the cl nb). (7/17) + +pkg/plot/t_implot.x + Changed an incorrect real array index to an int. (FV 7/21) + +unix/shlib/mkshlib.csh + Modified to not link the shared image with -lresolve on a 386i. (7/21) + +pkg/images/filters/t_gauss.x + An incorrect convolution kernel was being computed in the case + theta=90.0, 0. < ratio < 1.0, and bilinear=yes, because the sigma + argument were not being correctly entered into the routine which + computes the gaussian function in that case. (7/23 LED) + +pkg/math/nlfit/nlfit.gx +pkg/math/nlfit/nliter.gx + Due to precision problems the nlfit code can go into an infinite + loop if convergence is slow and the tolerance is set low. + Added some checks to trap this condition (7/24 LED). + +dev/hosts + Added benhur (Ron Probst's Sun) to the hosts files on tucana, orion, + gemini, and ursa - this is not a new machine but it must have slipped + through the crack during the v2.10 upgrade. (7/24 jvb) + +-------------------------------- +IRAF V2.10.1 (patch-1) released. Tucana system version number incremented to +V2.10.2 (7/24) + +lib/finfo.h + 1. This file contained a series of defines FI_[RW]OWNER etc. giving + the bit *number* (1, 2, 3, etc.) for the file permissions bitflags. + Bitflags are preferable and more conventional so I added a parallel + set of statements FF_[RW]OWNER, FF_[RW]GROUP, etc., defining the + bitflags. + + 2. Two new file permissions flags FF_RDLOCK and FF_WRLOCK were added. + These are normally zero (as before) but can be set by the zfinfo + kernel routine to indicate that a temporary read or write lock is in + place on the file. (7/24) + +sys/fio/fwtacc.x + The routine had a number of problems. It was rewritten to use the + new FF_{RD|WR}LOCK flags returned by zfinfo to determine whether a + temporary lock is preventing access to a file. The "wait for + access" will occur only if "filewait" is enabled in the environment + and a temporary lock is in place on the file. This should fix the + bogus "waiting for access to file" messages we have been seeing + occasionally. (7/24) + +sys/gty/gtyopen.x +sys/tty/ttyopen.x + The code which scans along looking for the `:' character when + expanding ":tc=device:" fields could run off the end of the string + if the : character was missing. Added checks for beginning of + string and EOS. (7/28) + +pkg/images/imfit/t_imsurfit.x + Fixed a bug in the section reading code. Imsurfit is supposed to switch + the order of the section delimiters in x and y if x2 < x1 or y2 < 1. + Unfortunately the y test in the code was if (y2 < x1) instead of + if (y2 < y1). Whether or not the code actually works correctly + depends on the value of x1 relative to x2. This bug was not present + in 2.9.1 but is present in subsequent releases. (7/30 LED) + +mkpkg +noao/mkpkg + Added a means to set the spoolfile name to the "mkpkg summary" + function of the package root mkpkg file. One can now generate the + summary with a command such as + + mkpkg summary spool=filename + + to cause the sumary to be generated from file "filename". (8/03) + +sys/osb/ieee.gx +sys/osb/ieeer.x +sys/osb/ieeed.x +unix/as.sparc/ieee.gx +unix/as.sparc/ieeer.x +unix/as.sparc/ieeed.x +unix/as.mc68020/ieee.gx +unix/as.mc68020/ieeer.x +unix/as.mc68020/ieeed.x +unix/as.i386/ieee.gx +unix/as.i386/ieeer.x +unix/as.i386/ieeed.x + 1. There was a (normally) harmless bug here in that the real and + double versions of the ieenan common had the same name, i.e. were + shared. There are now separate ieenanr, ieenand commons. + + 2. The code which detects a NaN uses the technique of equivalencing + an integer array of length 1 (real) or 2 (double) to the floating + value so that a bitmask can be used to check for the NaN exponent + (here NaN actually means any non-finite IEEE value). On most systems + the exponent for a double will be in the first integer of the 2 + element array, but on a 386i (Intel) the second longword is used. + The code was modified to parameterize this offset and flag it as + machine dependent. (8/15) + +unix/hlib/mkpkg.sf.I386 + 1. Added entries for the i386 versions of ieeer.x, ieeed.x. + 2. Set up mwcs$wftan.x to be compiled with no optimization. The + optimized version of this routine returns a garbage value for the + declination (it calculates it correctly but the code which outputs + the value to the w[] output array is incorrect). (8/16) + +pkg/cl/pfiles.c + When pfileload is called to load the parmeters for a pset task the + parameter file name assigned to the pset can come from the pset + parameter of a running task which uses the pset. Hence, pfileload + scans the task descriptors on the task to see if any reference the + pset. The "newtask" pointer, set during task startup, was being + used to start the scan of the control stack containing the task + descriptors. This could fail in some circumstances as newtask is an + invalid pointer except when a new task is being initialized. (8/17) + + This problem was an interesting case study in debugging techniques. + I at first tried to use dbx on this problem; this is normally + desirable with CL problems due to the lengthy procedures common in C + code. This was on the Sun 386i where the problem was seen. I had a + lot of trouble getting dbx on the 386i to use the source files, even + though the files were compiled -g. Eventually it became clear that + dbx will not permit source code debugging on the 386 if the iraf + shared image is used (there is no such problem on the other Suns). + Source code debugging would work if the process was linked -z. Of + course, then the problem went way. The 386i is very slow so by the + time I determined that I was wasting my time I had wasted 2 hours. + Looking at the problem with adb, I found the problem within 20 + minutes. + +pkg/images/filters/mkpkg +pkg/images/filters/t_fmedian.x +pkg/images/filters/fmedian.x +pkg/images/filters/fmd_buf.x +pkg/images/filters/fmd_maxmin.x + The fmedian task could crash with a segmentation violation if image + pixel to integer mapping was turned off (hmin = zmin and hmax = zmax) + and the input image contained data outside the range defined by zmin + and zmax. Added calls to amink and amaxk for integer images and a + call to amapr for floating point data to protect against out of bounds + data. (8/18/92, Davis) + +sys/imio/iki/qpf/qpfwattr.x + Modified to return INDEF as the value of the integral over an + attribute range list, if no range list is defined or either or both + ends of the range are open. (8/18) + +sys/mwcs/mwsaveim.x + The expression "if (ndim == 1 || (ndim == 2 && ...))" was incorrect + as the ndim==2 case contained references to CD matrix elements that + might not contain valid floating point values in the case of a 1 dim + wcs. (8/18) + +pkg/images/imutil/imcopy.x + Added a call to flush after the verbose status output so the the + output will appear immediately on the terminal. (8/19 LED) + +unix/os/zxwhen.c + Added some #ifdef i386 code to reenable the floating point exceptions + following such an exception. On the other Sun systems this is + automatic, but on the 386i it has to be done explicitly. (8/20) + + Note 8/21 - the above fix works fine under the debugger, but there + are still problems trapping repeated floating exceptions when a + 386i process executes normally. There are no such problems on any + of the other Suns (the interface is the same) so this tends to + indicate a problem with the 386i. + +dev/termcap +dev/graphcap + Added entries for Kermit terminal emulator supplied by Pat Seitzer. + The termcap entry is for MS Kermit 3.0 in VT320 mode; graphcap for + Kermit3.10 and CGA or VGA display. (8/20 ShJ) + +unix/os/zfiomt.c + 1. The "ue" option (update-eot, or force search for EOT) was not + working correctly - it had never been used until recently. + 2. The "ow" option (overwrite EOF) was tested and optimized. (8/20) + +sys/fmtio/dtcscl.x + This routine scales a double floating value to determine its mantissa + and exponent when printing the number. For numbers smaller than .1 + this is done as follows: + + while (v < 0.1d0) { + v = v * 10.0d0 + e = e - 1 + + The problem with this seemingly simple piece of code is that if V is + an IEEE subnormal value and IEEE underflow-to-zero is enabled, any + arithmetic operation on V will return a zero. Hence, even though + V is nonzero to start with, V * 10 returns zero. If V underflows to + zero the code segment above will enter an infinite loop. To fix + this a test for v==0 was added to the loop to check for underflow. + + On machines which have good hardware support for IEEE floating + computations involving subnormals the best thing to do is to NOT + underflow to zero, but rather to retain the subnormal values. This + increases the precision of floating point computations in small + number arithmetic. On some systems however, underflow (or inexact) + requires a trap and recomputation in a trap handler to produce the + correct IEEE result, and this can be very inefficient. + + As an example, In the case of Sun/IRAF we currently have underflow + to zero enabled due to the expense of recomputation for the ffpa and + some early sparc systems. Suns with these processors will silently + underflow to zero. Some other Sun systems do not employ + recomputation of subnormals and these systems ignore the request to + underflow to zero, returning a valid IEEE subnormal instead. This + includes the 386i and some sparc based systems (different sparc + systems have different floating point units). Hence, the behavior + of systems even within the Sun product line will vary in the way + subnormals are treated. + + (A subnormal is a number smaller than about 1.175e-38 for real and + 2.225e-308 for double). (8/21) + +sys/gio/fpnormd.x +sys/gio/fpnormr.x + These routines (called by fp_equal[rd]) scale floating point numbers + in a way similar to dtcscl.x, above. In principle they could be + subject to the same problem with underflow to zero and infinite loops, + so I added a check for underflow to these routines as well. (8/21) + +unix/os/zfioks.c + 1. Fixed a byte swap bug in the server side code that was preventing + it from constructing the network address properly to call back the + client. This affected only the "little-endian" machines, such as + the decstation and 386i. + 2. Changed the default value of MAXCONN from 0 to 1, since that is + probably what it should be anyway (I think I got the 0 out of someone + else's code). (8/21) + +unix/os/tape.c + Will now increment the file number at close time after writing a + file to tape. (8/21) + +dev/hosts + Added kale (Bruce Bohannan's d/t Sun) to the hosts files on gemini, + ursa, orion, and tucana. (9/3 jb) + +unix/os/tape.c + 1. Increased the maximum i/o buffer size to 262144 and changed the + default read request size to 64512. + 2. Added a "seek" command, for testing i/o to devices that respond + to a seek request. "seek" to report the current offset, seek nnn[bkm]" + to seek to the given block, kilobyte offset, or megabyte offset. + The block size is whatever was used in the last read request, or + 64512 at program entry. (9/07) + +sys/osb/zzeps2.f + Added an alternate version of the machine epsilon computation program + which may avoid problems seen on some systems with excess precision + due to the epsilon value being accumulated in a register. (9/10) + +sys/imio/imaccess.x + Was failing to strip off the ksection before calling iki_access. + Modified to treat a ksection similarly to an image section, i.e., + immap is called to test for the existence of the object specified + by the full notation, if a section or ksection is given. (9/11) + +doc/unixsmg.ms + Installed a new version of the UNIX/IRAF Site Manager's Guide, newly + updated for V2.10. (9/13) + +doc/irixiraf.ms + +doc/dsuxiraf.ms + +doc/vxuxiraf.ms + + Installed new SGI IRIX, Decstation Ultrix, and VAX Ultrix + Installation Guides. (9/14) + +dev/hosts + Updated the lapis entry on gemini, ursa, orion, and tucana. (9/14 RLS) + +unix/as.vax/ieeer.s +unix/as.vax/ieeed.s + Updated to the V2.10 versions. (9/21) + +unix/as.rs6000 + + Added the rs/6000 version of this directory. (9/21) + +unix/os/zgtime.c + The expression that converts the cpu time from clock ticks to msec + could result in integer overflow for very large numbers. Restructured + the code to avoid this problem, while preserving the maximum precision + for small numbers. (9/22) + +unix/hlib/libc/knames.h + Added a #define for zzstmt. This should be there, but though missing + did not cause a problem as no C code currently uses ZZSTMT. (9/22) + +mkpkg + Merged in changes for DSUX, AIX3. (9/23) + +lib/plio.h + The definitions for I_DATA and I_OPCODEMASK were modified to coerce + the macro argument to int, to avoid a short/int type clash when the + macro is called with a short integer argument. (9/23) + +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.DSUX - +noao/lib/mkpkg.sf.DDEC + +noao/lib/mkpkg.sf.DMIP + +noao/lib/mkpkg.sf.AIX3 + + Merged in mkpkg support for DSUX and AIX3. (9/23) + +pkg/images/tv/display/iisofm.x + Added the int in "y[i] = max (int(y[i])," to fix a short/int type + clash. (9/23) + +pkg/images/tv/iis/ids/idsinit.x +pkg/images/tv/iis/iism70/iissplit.x +pkg/plot/t_gkidir.x + More fixes for short/int type clashes. (9/23) + +sys/gio/gki/gkiclose.x + In "call zcall2 (epa, Mems[gki+GKI_CLOSEWS_D-1], n)", the gki pointer + was missing. (9/23) + +sys/gio/ncarutil/autograph/agdash.f +sys/gio/ncarutil/autograph/agdflt.f +sys/gio/ncarutil/autograph/aglbls.f +sys/gio/ncarutil/autograph/agsetp.f + Several declarations of the form CHARACTER*504 in these files were + changed to CHARACTER*500. The Fortran compiler on AIX does not allow + character variables longer than 500. IRAF does not use any of the + NCAR autograph code anyway. (9/23) + +sys/imio/imsetr.x + In the two statements + + IM_PLFLAGS(im) = or (IM_PLFLAGS(im), PL_RLIO) + IM_PLFLAGS(im) = and (IM_PLFLAGS(im), not(PL_RLIO)) + + the second "(im)" was missing. (9/23) + +sys/mwcs/mwtransd.x + Changed the expression "* -ltv_1[i]" to "* (-ltv_1[i])". The AIX + compiler did not like this expression. (9/23) + +sys/plio/pllrop.x +sys/plio/pllsten.x +sys/plio/plp2l.gx +sys/plio/plr2l.gx + Same thing, placed parens around the -dv in "M_DH + -dv". (9/23) + +sys/plio/plp2l.gx +sys/plio/plr2l.gx + Had to add an int to "and (int(pv), I_DATAMAX)" to avoid a short/int + type clash. (9/23) + +sys/plio/plrrop.gx + Added an "int" to fix three cases of short/int type clash. (9/23) + +sys/qpoe/qpiomkidx.x + Added an int to fix a short/int type clash. (9/23) + +sys/vops/fftx.f + This routine contained a declaration "x(2), y(2)" where the arrays + X,Y are of arbitrary length. Later on in the code the third and + fourth elements of each array were referenced and this caused a + compiler message about an incorrect constant array subscript. + Changed the declaration to "x(*), y(*)". (9/23) + +unix/gdev/iism75/zrdm75.x + Added an int to fix a short/int type clash. (9/23) + +unix/hlib/libc/kernel.h +unix/os/zgtime.c + Changed the #define name "HZ" to "CLKFREQ" to reduce the probability + of a name clash, as happened on the RS/6000. (9/23) + +math/bevington/legfit.f + This file, unmodified since 1985, had the character ^? at the end of + line 77, which is a comment line. Evidently most compilers ignore + comment lines, but the VMS-5 Fortran compiler didn't like this one. + (9/24) + +sys/osb/strupk.c + This routine was calling the C strlen(), which was an inadvertent + interface violation (VOS code bypassing the kernel and using host + facilities. This caused a link failure on VMS/IRAF, after the + str routines in the VMS/IRAF kernel were renamed to avoid name + collisions with host library routines (hence strlen was no longer + in libos.a). The routine was rewritten to use a for loop instead + of strlen. (9/24) + +dev/hosts + Added a stis1 entry on gemini,ursa & tucana for Rich Reed. (10/1 RLS) + +pkg/images/imarith/t_imcombine.x +pkg/images/imarith/icaclip.gx +pkg/images/imarith/iccclip.gx +pkg/images/imarith/icgrow.gx +pkg/images/imarith/iclog.x +pkg/images/imarith/icombine.com +pkg/images/imarith/icombine.gx +pkg/images/imarith/icombine.h +pkg/images/imarith/icpclip.gx +pkg/images/imarith/icscale.x +pkg/images/imarith/icsclip.gx +pkg/images/imarith/icsetout.x +pkg/images/imcombine.par +pkg/images/doc/combine.hlp + The weighting was changed from using the square root of the exposure + time or image statistics to using the values directly. This + corresponds to variance weighting. Other options for specifying the + scaling and weighting factors were added; namely from a file or from + a different image header keyword. The \fInkeep\fR parameter was + added to allow controlling the maximum number of pixels to be + rejected by the clipping algorithms. The \fIsnoise\fR parameter was + added to include a sensitivity or scale noise component to the noise + model. Errors will now delete the output image. (9/30/92, Valdes) + +unix/hlib/extern.pkg + On Gemini, added definitions for the ccdacq package as mounted + from Ursa. (10/5 RLS) + +dev/hosts + Modified a number of these hosts files on different CCS Suns and + IRAF development systems to establish and check IRAF networking + to/from felis. (10/5 jb) + +unix/os/zfioks.c + A new connect protocol has been added to iraf networking called + rexec-callback. This is a variation on the rexec protocol. Rexec + is used to start up the remote kernel server as before, but instead + of communicating via the rexec stdio stream to the remote process, + the server calls the client back on a private socket set up by the + client. This ensures a direct socket connection, which is not + always guaranteed when using the rexec stdio streams. For example + when using rexec to start up a kernel server on a VMS host running + Multinet, the stdio streams are routed through a VMS mailbox on the + VMS side. This fails due to lost data resulting from the mailbox + being too small, and would be inefficient even if it worked. + + The rexec-callback connect protocol is enabled in the .irafhosts file + entry for a node (since this is where protocol selection currently + occurs for rexec vs. rsh). To enable the rexec-callback protocol, + one adds the string "rexec-callback" after the password field for a + node, e.g., + + robur : rexec-callback + + A number of related changes were made to the VMS/IRAF networking + driver, which is new for V2.10. These are documented in the VMS/IRAF + upgrade notes file. (10/06) + + [NOTE - the way the rexec-connect protocol is enabled was changed; + see the entry for zfioks below. 10/11] + +sys/mtio/mtlocknam.x + The magtape lock file name is now constructed as "node!tmp$mtxx.lok" + rather than "tmp$mtxx_node.lok", causing the lock file to be + maintained on the same node as the drive itself. (10/07) + +sys/ki/kienvreset.x + This routine is called to propagate runtime changes of environment + variables to remote iraf kernel servers. It was passing all + variables, but was modified to filter out redefinitions of the + host-specific variables "iraf", "host", and "tmp". This is necessary + as these variables may have different values on different hosts. + It is also needed to be consistent with kiopenks.x. (10/07) + +unix/boot/bootlib/tape.c +unix/boot/rtar/rtar.hlp +unix/boot/wtar/wtar.hlp + Replaced RTAR and WTAR by new versions updated for V2.10 magtape + i/o. The old versions read the dev$devices file to map iraf device + names like "mta" to the corresponding host device names. In V2.10 + the tapecap file replaces the devices file, and the tapecap file + format is too complex to be worth parsing in a HSI utility, so in + V2.10 host magtape device names such as "/dev/nrmt8", "MSA0" etc. + must be used with RTAR and WTAR. The VMS/IRAF versions of these + utilities now restore file dates properly, provided the VMS logical + name IRAFGMTOFF is defined correctly (see the VMS notes file for the + details). (10/10) + +sys/ki/ki.h +sys/ki/kiconnect.x + The dev$hosts file now supports two types of host entries, "connect" + entries and "route" entries. A connect entry is what we have always + had, e.g. + + ursa u : ursa!/iraf/iraf/bin.sparc/irafks.e + + A route entry is an entry such as that for node "draco" below: + + robur : robur!irafks + draco : @robur!draco + + another use is for logical node names, e.g., + + lpnode : @ursa + + A route entry is denoted by the character `@' as the first character + in the server command field. In a reference to a network object + such as "node!foo", if node is defined as "@bar", the string "node" + is replaced by "bar", i.e., by whatever follows the @, after which + the network object name is rescanned. For example, given the + definitions for node robur and draco above, "draco!foo" and + "robur!draco!foo" are equivalent references. IRAF networking will + automatically map the former reference to the latter internally. + + This facility provides a simple static routing capability for IRAF + networking, allowing connects to specific nodes to be routed through + another node. This can be used, for example, to use a certain node + as a gateway between different types of networks, such as tcp/ip and + decnet. (10/11) + +unix/os/zfioks.c + A number of features were added to the unix/iraf network driver. + + o The connect protocol may now be specified in the hosts + file entry for a node. For example, + + robur : -rcb robur!irafks + + causes the rexec-callback connect protocol to be used to + connect to node robur. The possible protocols are -rsh + (rsh), -rex (rexec) and -rcb (rexec-callback), with the + default being -rsh. (The "irafks" in the above example + is a VMS symbol defined in the VMS/IRAF irafuser.com file, + used to start the kernel server on a VMS node). + + o A new argument "-log " is now supported on the irafks + command line. Since the irafks command line is taken from + the dev$hosts file in a normal client connect, the hosts + file can be edited to turn on zfioks level debug logging. + For example, + + tucana t : -log ks.out tucana!/usr/iraf/bin.sparc/... + + Any file can be specified, for example /dev/tty. If the + -log argument is given before the node!cmd as in the example + above, logging is enabled on the local node. If the -log + argument follows the node!cmd, it is processed by the kernel + server on the remote node and enables logging on that node. + + This is related to irafks level logging. irafks level + logging is a feature that irafks has supported for some + time. It is enabled by including "-d " on the irafks + command line. + + o The networking daemon for the in.irafksd daemon may now be + started manually (normally it is started via a rsh command + from a client during a rsh connect). For example, + + irafks.e in.irafksd [timeout] + + would start the daemon on the specified port. Clients would + have to specify the given auth code to connect to the port. + The daemon executes with the UID of the calling process. + Care should be taken to avoid security problems, e.g., this + should be used only with "safe" accounts. Currently, + commands such as sps, ps, etc. will show the full command + line including the auth code so there is little security. + + When the daemon is started in this way the irafks.e will + exit immediately, leaving the daemon running as a forked + process. The daemon runs forever until killed, unless a + timeout is specified. + + o Arguments such as "rexec-callback" are no longer supported + in the .irafhoss file. Instead, this scheme has been + generalized to permit any network parameter to be overridden + for a particular node in the user's .iraf hosts file. + The parameters that can be set are "port", "auth", "hiport", + "timeout", and "protocol". These are all numeric parameters + except "protocol" which should be specified as "rsh", "rex", + or "rcb". For example, + + corvus : none none port=20000 auth=12345 + + would cause connects to node corvus to be directed to + socket 20000 using the auth code 12345. The login name + and password are not used when connecting to a running + daemon, so they are given as "none" in the example. + + These changes should be backwards compatible with the V2.10.1 + version of IRAF networking. + + In case it isn't obvious, the above changes combined with the + enhancements to VMS/IRAF networking support (tcp/ip servers, runtime + selection of either tcp/ip or decnet transport) allow connections to + be made transparently to any VMS node running decnet, using a node + running both tcp/ip and decnet (e.g. a VMS node running Multinet) as + a gateway between SPAN and the Internet. For example, "type + draco!login.com", where draco is a decnet node, given the hosts file + configuration showed in the examples, would result in 1) "draco" + being replaced by "robur!draco" causing the reference to be routed + to node robur via rexec-connect, 2) robur passes the request to node + draco via decnet. This requires a .irafhosts file on the gateway + node (robur) since there is no way to respond to a password prompt + from a kernel server running as a network process on a remote node. + (10/11) + +unix/os/zmain.c + Problems were encountered passing irafks commands such as -log or + -rcmd to the irafks task when called as a standalone host process. + This was because the IRAF zmain for unix/iraf was intercepting all + `-' prefixed command arguments. The zmain was changed to filter out + only those arguments it uses, e.g., -c, -C, -d , and -w. For + completeness a new flag -h (host process) was added. This is the + same as calling the process with no arguments, i.e., it is the + default. Unknown flags will no longer cause a usage message to be + printed, instead they are just passed on to the iraf task. (10/11) + +pkg/cl/builtin.c + The internal name clscan(), used to implement the CL scan() function, + was changed to clscans() to avoid a name clash with the FMTIO routine + clscan. This only happens on systems where Fortran and C externals + share the same name space, and shared libraries are used. (10/12) + +pkg/system/references.cl + Changed a couple of "uniq"s to "unique", which is the full name of + the LISTS task used in the script. (10/12) + +pkg/cl/grammar.y + The CL grammar was changed to give a higher precedence to the + exponentiation operator than to unary minus. The former precedence + was inconsistent with the Fortran expression syntax that the CL + is supposed to emulate. (10/12) + +sys/ki/kbzstt.x + This routine was calling zsttks (the status routine for the networking + driver) with a fixed channel code of zero. This worked up until now + as most iraf network drivers ignore the channel code in zsttks, but + this is not the case with the new VMS/IRAF driver. (10/13) + +dev/graphcap + Added entries for em4010vg (em4010 for VGA) and vwsregis (regis + emulator for VWS 3.3 and later). (10/14) + +sys/gio/fpequalr.x +sys/gio/fpequald.x + These routines could fail when comparing small numbers to zero. + For example, fp_equalr (1.0e-10, 0.0) would return false even though + the numbers are equivalent to within the machine epsilon. This is + incorrect given the definition of fp_equal, even though the numbers + are in fact not equal. The routine would fail because zero is a + special case: it cannot be normalized with fp_norm. It was necessary + to add code to handle the special case of either input operand being + exactly zero. (10/18) + +unix/os/zfiomt.c + 1. Two new device capability switches were added. ":ce" means + ignore the status of the close() system call when closing a device + opened read-only. ":eo", used only in the VMS version of the + driver, disables writing of the double tape mark at EOT when a tape + opened for writing is closed. + + 2. The ":nf" parameter was modified to allow an integer value to be + given. Without a parameter, ":nf" means rewind and space forward + to backspace files on a tape, e.g., because this is faster than BSF. + An entry such as ":nf#5" means do a BSF if the file is 5 files or + less back, but if more files must be skipped do a rewind and space + forward. This parameter is intended mainly to help optimize file + seeks on slow devices like cartridge tapes. + + 3. The ":fc" parameter (device does a FSF on CLRO [close read-only]) + was put in when the driver was written to accomodate some SysV systems + but had never been tested. As it turns out, AIX is such a system and + it was necessary to make minor changes. In particular, the OS does + not always do a FSF - it only does this when the file is partly read. + If EOF has been reached on the file (hence the tape is positioned to + the first record of the next file) then the FSF is skipped. + + 4. I added a couple of zmtdbg calls during multifile skips to cause + the file number to be updated more frequently, when using the status + output feature. (10/18) + +pkg/proto/t_imcntr.x + Modified the imcntr task to use image templates and to check for + constant data. (10/27/92 LED) + +dev/termcap +dev/graphcap + Added "lwg", an HP IIIp LaserJet on Canopus, to these files on Ursa + and Gemini at Frank Bull's request. (10/27/92 MJF) + +dev/termcap +dev/graphcap + Added entries for xgterm. (10/27) + +sys/libc/cenvget.c + Changed envgets() to use ENVFIND rather than ENVGETS, so that the + routine will detect the environment variable not found condition + and return NULL in that case. (10/27) + +sys/gio/gks/gschup.x + Changed the character up vector to be calculated as the nearest integer + instead of just being truncated to an integer. (ShJ 10/29/92) + +dev/hosts + Added BigX to the hosts files on tucana, BigX, ursa, gemini, and + orion to establish IRAF networking for our new server. (11/12 jb) + +dev/hosts + Added claret to the hosts files on tucana. (11/13 RLS) + +sys/symtab/stalloc.x +sys/symtab/stsqueeze.x +sys/symtab/stpstr.x +sys/symtab/symtab.h + The symtab package could fail with an "out of memory" error during + symbol table or string buffer reallocation in applications which + call stsqueeze to free unused storage (as when doing an stsave to + save to a file). This was caused by the buffer increment being + increased by a factor of two during overflow, combined with stsqueeze + returning the unused space. Two changes were made, either of which + will avoid the problem: 1) stsqueeze now reinitializes the buffer + increment when the buffer length is reset, and 2) the buffer increment + is now allowed to grow larger than a fixed value (32K) defined in + symtab.h. (11/16) + +sys/qpoe/qpmacro.x + 1. The code which scans a file and decodes macros was using a large, but + fixed size, string buffer to store the macro value. This was + overflowing when extremely large time filters were stored in QPDEFS + as macros. The routine was rewritten to use a dynamically reallocated + buffer. + 2. The variables nodeffilt and nodefmask, which are false by default, + could only be set true since the "set nodeffilt" type statement does + not have a value and there is no unset. For the moment, this was + fixed as a special case by initializing the values of these parameters + to the default before scanning the QPOE macro file. (11/17) + +sys/qpoe/zzdebug.x + In the expand debug routine, used to test macro expansion, increased + the size of the output buffer to 128k to accomodate extremely large + macros. (11/17) + +sys/qpoe/qpioparse.x + A bug which would cause "filter=..." terms in expressions to be + discarded was fixed. (11/17) + +sys/qpoe/README + Added optbufsize to the list of QPDEFS parameters. (11/17) + +sys/mwcs/imwcs.h + Increased the size of the string buffer used in the FITS read code + from 20480 chars to 102400 chars. This fixed size buffer is not + (easily) reallocatable because the card descriptors use pointers to + point to the FITS card data in the buffer. The buffer is only + allocated while a header is being read so the size isn't really an + issue. (11/17) + +sys/mwcs/mwsctran.x + The internal variable pdim, the dimensionality of the linear portion + of the transform, used to size the vector and matrix buffers for the + linear algebra, was not being computed correctly. This could cause + problems when the dimension of a WCS in the transform was less than + the dimension of the full MWCS system. The problem was a typo in the + statement + + pdim = min (WCS_NDIM(w1), WCS_NDIM(w1)) + + the second w1 was changed to w2. (11/17) + +unix/os/zfioks.c + Fixed a typo affecting stderr debug out to /dev/console. (11/18) + +------------------------ +Patch 2.10.2 built; tucana irafx version incremented to v2.10.3. (11/18) + +pkg/cl/scan.c + Removed several calls to "makelower". These were forcing parameter + name operands to lower case. (11/20) + +sys/imio/iki/qpf/qpfwfilter.x + The QPF interface uses a sequence of QPFILTxx cards to record in the + image header the QPOE filter used to generate an image. To avoid + overfilling the header, excessively long filter strings are truncated. + The truncation limit was increased from 1024 chars to 4096, increasing + the number of output cards from a maximum of 16 to 64. In addition, + if truncation occurs the string "..." is now written to the end of the + last card to indicate that the filter string has been truncated. (11/20) + +sys/mwcs/wfmspec.x + Installed a new version of the multispec function driver. (11/20) + +mkpkg + Added an entry for the f2c architecture. (11/21) + +dev/devices - +dev/hostlogin - + Deleted these obsolete files, no longer used. (11/21) + +unix/os/zopdpr.c + Added #ifdef SYSV support. (11/21) + +unix/boot/mkpkg/sflist.c + A call to strcpy had an extra argument. (11/21) + +unix/boot/spp/rpp/rpprat/gtok.r +unix/boot/spp/rpp/rppfor/gtok.f + Due to some commented out code, the external variable index was not + used and was causing a warning message. (11/21) + +sys/mwcs/iwrfits.x + Added a call to idb_close, to return the descriptor allocated by + idb_open. (11/23) + +unix/hlib/login.cl + Added lprm to the unix foreign task definitions. (11/24) + +dev/hosts + Fixed the pathname to irafks.e for cephus (11/27 MJF) + +dev/hosts + Updated pathname to irafks.e for pegasus on tucana, ursa, gemini, + and bigx. (11/30 jb) + +iraf/doc/aixiraf.ms + + Installed the IBM AIX/IRAF installation guide. (11/30) + +pkg/plot/crtpict/calchgms.x + Fixed an argument type mismatch (int->short) in a call to amaps on + line 158. This was causing a floating divide by zero in the + case of a user supplied lookup table when calculating the transformed + histogram. (12/05 ShJ) + +pkg/cl/unop.c + On some systems (sparc) CL expressions such as -(big-floating) would + abort with a floating operand error. This was the result of integer + overflow occuring when the floating value was assigned to an int. + The CL was checking for this case, but would fail for negative + values. (12/10) + +unix/boot/wtar/wtar.hlp + Updated a couple of paragraphs to document the recent changes to + the utility. (12/23) + +dev/termcap +dev/graphcap + Added entries for Kermit terminal emulator supplied by Pat Seitzer. + The termcap entry is for MS Kermit 3.0 in VT320 mode; graphcap for + Kermit3.12 and CGA or VGA display. (1/7 MJF) + +unix/boot/bootlib/tape.c + Replaced a call to ACLRB by functionally equivalent C code. The ACLRB + works under normal circumstances, but fails in a NOVOS bootstrap. + (1/08 1992) + +sys/imio/db/imgnfn.x +pkg/images/doc/hedit.hlp + The header keyword template package had a builtin limit of 128 on the + maximum number of keywords matching a pattern (e.g. *). This builtin + limit was increased to 1024. (1/11) + +dev/hosts + Added Dick Joyce's machine "charfman" to the file on Gemini + (i.e., where Dick's IRAF comes from - networking was totally + down). (1/13 RLS) + +./math/iminterp/arbpix.x +./math/interp/arbpix.x +./noao/astutil/t_setairmass.x +./noao/digiphot/photcal/evaluate/phprint.x +./noao/mtlocal/cyber/cykeywords.x +./noao/mtlocal/cyber/t_ridsfile.x +./noao/onedspec/ecidentify/ecline.x +./noao/onedspec/irsiids/t_bswitch.x +./noao/onedspec/irsiids/t_flatdiv.x +./noao/onedspec/irsiids/t_flatfit.x +./noao/onedspec/irsiids/t_sums.x +./noao/twodspec/apextract/peaks.x +./noao/twodspec/multispec/fitclean.x +./noao/twodspec/multispec/fitsmooth.x +./noao/twodspec/multispec/intgauss5.x +./noao/twodspec/multispec/peaks.x +./noao/twodspec/multispec/solve.x +./noao/twodspec/multispec/t_fitfunc.x +./pkg/bench/xctest/lintran.x +./pkg/images/lib/sigl2.x +./pkg/images/tv/display/sigl2.x +./pkg/images/tv/iis/src/sigl2.x +./pkg/lists/lintran.x +./pkg/plot/crtpict/sigl2.x +./pkg/proto/t_imscale.x +./sys/clio/clgeti.x +./sys/clio/clgetl.x +./sys/clio/clgetr.x +./sys/clio/clgets.x +./sys/clio/clglpi.x +./sys/clio/clglpl.x +./sys/clio/clglpr.x +./sys/clio/clglps.x +./sys/clio/clputi.x +./sys/gio/calcomp/t_calcomp.x + These files were modified to replace equals-INDEF type constructs by + IS_INDEF type constructs. (1/15). + +unix/mkpkg + Modified the "mkpkg summary" feature to work for either cc or gcc. + (1/15) + +unix/os/zfiotx.c + Modified to use the TCSETAW ioctl instead of TCSETAF in some cases + (SysV systems only). (1/15) + +pkg/dataio/reblock/t_reblock.x +pkg/dataio/doc/reblock.hlp + Added support for multiple disk file input and output to the reblock + task. (1/20/93 LED) + +dev/hosts + Added Daryl Willmarth's machine "jannu" on Tucana. + (1/20 FV) + +dev/hosts + At Ed Anderson's request, added nodes anasazi and prometheus to + dev$hosts on tucana, ursa and gemini. The lacerta pathname was + updated in these files as well. (1/21/93 ShJ) + +dev/termcap +dev/graphcap + Cleaned up the VMS specific entries for lw6-10 so all are available + now from VMS/IRAF. Graphcap needed a vapl6 entry; termcap needed + entries for vapple[6,8-10]. (1/20/93 ShJ) + +dev/devices.hlp + Updated the first section of this file to have accurate locations for + the various printers and to include the device names for generating + PostScript output files. (1/21/93 ShJ) + +pkg/images/filters/fmedian.x + The fmedian task was printing a lot of garbage debugging information + under iraf 2.10.2. Removed the eprintf statements. (1/25/93 LED) + +pkg/system/phelp.cl + Changed the default value for the parameter "all" to "yes". This + causes phelp to print help for all modules matching the given + template, rather than just the first one. (1/26) + +pkg/system/doc/help.hlp + Added a description of the "all" parameter. (1/26) + +sys/etc/xerstmt.x + The code which modifies the `error (ddd, "message")' command sent to + the CL when a task aborts was modified to eliminate characters such + as newline or double quote which could cause the syntax of the + generated command to be invalid. (There are 31 cases of "call error" + statements in the core distribution which contain unwanted newline + characters in the message string). (1/27) + +pkg/images/tv/wcslab/wcslab.x + Fixed a bug in the axis mapping code in wcslab which was causing the + task to fail in some circumstances if the input image was a section + of a higher dimensioned parent image. (1/28/93, Davis) + +vms/gdev/sgidev/sgi2veps.for + +vms/gdev/sgidev/mkpkg.com +vms/hlib/sgiqueue.com +dev/graphcap + Added an SGI translator for Encapsulated PostScript to VMS/IRAF. + As with the Unix version of the translator, the device names are + eps, epsl and epsh. The output file is named sgixxxxx.eps and + is left in the users home$ directory. (2/1/93 ShJ) + +unix/hlib/install + Added a number of statements such as "rm -f $TEMP >& /dev/null" to + ensure that any existing temp files are deleted before trying to + create new ones (file creation can fail due to permissions problems). + (2/01) + +vms/gdev/sgidev/sgi2vapl.for + Modified to close the output file before sending it to the printer + queue with sndjbcw. Without this, the file wouldn't be closed until + the program finished, possibily resulting in an intermittent error: + %RMS-E-FLK, file currently locked by another user. This was more + likely to be seen on a [relatively] fast machine such as Robur, when + the queue processing could turn on before the translator completed. + In this case, the output file would still be open [and locked] by the + executing sgi2vapl program. (2/2/93 ShJ) + +dev/hosts + Modified this file on all hosts for Fred Gillett's new Sun called + turkey. (2/2/93 jb) + +dev/hosts + Added the GONG machines soi and mdi to hosts files on tucana, orion + and ursa. Added on gemini by Nigel. (2/2/93 MJF) + +pkg/images/tv/wcslab/wcslab.h +pkg/images/tv/wcslab/wcs_desc.h +pkg/images/tv/wcslab/wcslab.x +pkg/images/tv/wcslab/wlwcslab.x + Removed a dependency on the file gio.h from the wcslab task. + (2/11/93 LED) + +pkg/images/imutil/t_imslice.x + Removed an error check in imslice, that was preventing the task from + being used to reduce the dimensionality of images where + IM_LEN(im,slice_dimension) = 1. + (2/16/93 LED) + +dev/imtoolrc +dev/graphcap + Added a new frame buffer, imt37, at Skip Schaller's request for + the Loral 1200x800 CCDs. (2/17/93 MJF) Modified imt37 and imt26 + (cryocam) to suit KPNO nomenclature. (2/18/93 RLS) + +pkg/images/tv/imexamine/ierimexam.x +pkg/images/tv/doc/imexamine.hlp + The simple gaussian fitting was inadequate and gave biased answers. + Replaced this algorithm with NLFIT version. It is still just a two + parameter fit with the center and sky being determined and then fixed + as before. (3/2/93, Valdes) + +dev/hosts + Merged all differences on ursa, gemini, orion, and bigx back into + tucana's hosts file. (3/5/93 jb) + +pkg/images/tv/imexamine/iestatistics.x + The statistics computation was done in real precision, using aavgr, + which gives an incorrect standard deviation, presumable because of + precision truncation, when the mean is large and the actual data + noise is small. The routine was changed to use the double + precision version, aavgd, which gives the correct results. + (3/10/93, Valdes) + +noao/mkpkg + Added support for HPUX. (3/14) + +pkg/cl/main.c + Modified memneed(), used to allocate space at the end of the + dictionary, to quad align the allocated storage. (3/14) + +pkg/cl/pfiles.c + Modified this code to remove an assumption about the amount of + space allocated by memneed. (3/14) + +sys/imfort/tasks/mkpkg - +sys/imfort/tasks/README + Deleted the mkpkg, which is system dependent. (3/14) + +unix/os/alloc.c + Modified alloc to allow the drive in it unallocated state to be + owned by any system uid (any uid < 10), rather than insisting that + the drive be owned by root. If the drive is owned by any system + uid and has world rw permission it can be allocated under this + new scheme. This avoids requiring that the system manager set + the device ownership to root on systems where the device is owned + by bin or some other system uid. (3/15) + +mkpkg + Added irix and hpux support. (3/15) + +dev/hosts + Added otter to hosts file on tucana, ursa, gemini, orion, and + bigx. (3/24 jb) + +dev/graphcap +dev/termcap + Added entries for lw15|lwcloset to tucana, ursa, gemini, orion, and + bigX. (3/26 ShJ) + +sys/libc/cread.c + The case of EOF on a text file was not being handled correctly. (3/31) + +sys/fio/ffilsz.x + The file size was not being computed correctly in the case of a file + opened for writing and positioned to EOF, with some unwritten data + in the file buffer. (4/05) + +pkg/cl/exec.c + The LT_STDINB, LT_STDOUTB flags were not being propagated into the + task descriptor correctly (they were being treated as additional + cases of mutually exclusive task types). (4/07) + +pkg/images/doc/gauss.hlp + Fixed two sign error in the equations in the documentation for + the gauss task. (4/13 LED) + +unix/hlib/libc/stdio.h + Added a declaration for gets(). (4/16) + +pkg/images/imarith/imcombine.gx + There was no error checking when writing to the output image. If + an error occurred (the example being when an imaccessible imdir was + set) obscure messages would result. Errchks were added. + (4/16/93, Valdes) + +pkg/images/doc/rotate.hlp + Fixed a bug in the rotate task help page which implied that automatic + image size computation would occur if ncols or nlines were set to 0 + instead of ncols and nlines. (4/17/93, LED) + +sys/imio/iki/stf/stfrgpb.x + This code was directly referencing fields of the GPB in calls to + imaddX routines to build the image header. Since fields in STF + group parameter blocks are often not aligned, this could fail for + type double on machines that require that double values be double + aligned. The code was modified to copy the values out to + temporary variables (which the compiler will automatically align), + passing the aligned temporary values in the imaddX calls. (5/04) + +dev/graphcap + Merged in latest xgterm entries (these are not compatible with + early prerelease versions). (5/05) + +./lib/gescape.h +./lib/gim.h + +./lib/gio.h +./lib/gki.h +./lib/gset.h +./lib/scr/cursor.key +./lib/scr/xgterm.gui + +./pkg/language/doc/cursors.hlp +./pkg/plot/t_implot.x +./sys/etc/prpsio.x +./sys/gio/cursor/giotr.x +./sys/gio/cursor/grcaxes.x +./sys/gio/cursor/grccmd.x +./sys/gio/cursor/grcredraw.x +./sys/gio/cursor/grcwcs.x +./sys/gio/cursor/gtrctrl.x +./sys/gio/cursor/gtrdelete.x +./sys/gio/cursor/gtropenws.x +./sys/gio/cursor/gtrrcur.x +./sys/gio/cursor/gtrwsclip.x + +./sys/gio/cursor/gtrwstran.x +./sys/gio/cursor/mkpkg +./sys/gio/cursor/rcursor.x +./sys/gio/gactivate.x +./sys/gio/ggcur.x +./sys/gio/gim/mkpkg + +./sys/gio/gim/README + +./sys/gio/gim/gimrasini.x + +./sys/gio/gim/gimcrras.x + +./sys/gio/gim/gimderas.x + +./sys/gio/gim/gimwpix.x + +./sys/gio/gim/gimrpix.x + +./sys/gio/gim/gimqras.x + +./sys/gio/gim/gimsetmap.x + +./sys/gio/gim/gimrcmap.x + +./sys/gio/gim/gimwcmap.x + +./sys/gio/gim/gimimap.x + +./sys/gio/gim/gimcpras.x + +./sys/gio/gim/gimgetmap.x + +./sys/gio/gim/gimenmap.x + +./sys/gio/gim/gimref.x + +./sys/gio/gim/gimsetras.x + +./sys/gio/gim/gimrefpix.x + +./sys/gio/gki/gkifaset.x +./sys/gio/gki/gkigcur.x +./sys/gio/gki/gkiprint.x +./sys/gio/gki/gkircval.x +./sys/gio/gki/gkiwesc.x + +./sys/gio/gki/mkpkg +./sys/gio/gmprintf.x + +./sys/gio/gmsg.x + +./sys/gio/gopen.x +./sys/gio/gplcache.x +./sys/gio/greset.x +./sys/gio/gsetr.x +./sys/gio/gstatr.x +./sys/gio/gsview.x +./sys/gio/gswind.x +./sys/gio/mkpkg +./sys/gio/sgikern/sgifa.x +./sys/gio/stdgraph/mkpkg +./sys/gio/stdgraph/stdgraph.com +./sys/gio/stdgraph/stdgraph.h +./sys/gio/stdgraph/stgescape.x +./sys/gio/stdgraph/stgfaset.x +./sys/gio/stdgraph/stggcur.x +./sys/gio/stdgraph/stggim.x + +./sys/gio/stdgraph/stginit.x +./sys/gio/stdgraph/stgopen.x +./sys/gio/stdgraph/stgopenws.x +./sys/gio/stdgraph/stgrcur.x +./sys/gio/stdgraph/stgreset.x +./sys/gio/stdgraph/stgscur.x +./sys/gio/stdgraph/stgwtty.x +./sys/tty/tty.h +./sys/tty/ttyopen.x + Merged in a number of changes made to add IRAF-side support for the + prototype widget server. These will be documented in detail later. + The changes should be backwards compatible; any compatibility + problems should be reported. (5/05) + +pkg/images/geometry/t_imshift.x + Added support for type ushort images to the imshift task in the + case that the pixel shifts are integral not fractional. + (5/8/93 Davis) + +pkg/images/imarith/icmedian.gx + The median calculation is now done so that the original input data + is not lost. This slightly greater inefficiency is required so that + an output sigma image may be computed if desired. (5/10/93, Valdes) + +images/doc/imshift.hlp + Fixed a typo in the name of the "interp_type" param. (5/13/92 MJF) + +dev/tapecap + Added support (mto*) for the new Exabyte 8500 drive on Argo. + Added lo/hi/comp aliases for the ST driver entries. (5/17) + +dev/hosts + Added aldebaran to all hosts files - needed temporarily until this + machine becomes argo. (5/19 jb) + +pkg/images/tv/display/t_display.x + The code for the fill+ option did not handle the case of a non-square + display frame buffer correctly. (5/19) + +pkg/plot/phistogram.x + Fixed a bug in the way the phistogram task was reading in data + redirected from the standard input. (5/20 LED) + +/dev/hosts + Added lemming to all hosts files. (5/25 jb) + +images/imarith/icgdata.gx + There was an indexing error in setting up the ID array when using + the grow option. This caused the CRREJECT/CCDCLIP algorithm to + fail with a floating divide by zero error when there were non-zero + shifts. (5/26/93, Valdes) + +sys/ki/kixnode.x + This routine used a fixed length intermediate buffer which could + result in truncation of a resource name. Modified to base the buffer + size on the size of the resource string being edited. (5/29) + +doc/iraf92.tex +doc/iraf92f3.eps + Installed ADASS-93 IRAF paper sources. (6/02) + +doc/ports/aux_port.doc + Installed AUX/IRAF port notes. (6/02) + +lib/gescape.h +lib/gim.h +sys/gio/cursor/giotr.x +sys/gio/cursor/gtropenws.x +sys/gio/cursor/rcursor.x +sys/gio/gim/README +sys/gio/gim/gimlcmap.x +sys/gio/gim/gimwcmap.x +sys/gio/gim/mkpkg +sys/gio/sgikern/sgifa.x +sys/gio/stdgraph/mkpkg +sys/gio/stdgraph/stggcur.x +sys/gio/stdgraph/stggim.x +sys/gio/stdgraph/stgopenws.x +sys/gio/stdgraph/stgrcur.x +sys/gio/stdgraph/stgscur.x + Various files updated as part of display interfaces enhancements; + notes to be added later. (6/02) + +dev/hosts + Added odysseus to tucana/orion. Nigel added it to ursa/gemini. + (6/15MF) + +sys/vops/arav.gx + Changed the termination condition to cause loop termination if an + interation results in fewer pixels being rejected. This shouldn't + happen, but is possible due to arithmetic errors when the algorithm + is near convergence. (6/19) + +sys/imio/iki/oif/oifopix.x + Improved the error handling for the case where there is no pixel + storage file. (6/21) + +gio/ncarutil/conbd.f +gio/ncarutil/conrec.f + Dimension of array IR in subroutine STLINE was increased from 20k + to 80k. This array, in common block CONRE2, holds the starting + location of all contours at a given level. Larger data arrays, and + users wanting to contour each pixel rather than subsampling or block + averaging, have necessitated the gradual increase of this array + over the years from its original value of 500 to 80000. (ShJ 6/21) + +pkg/plot/phistogram.x + Fixed a bug in the way phistogram was binning real data read in from + a list or image that was causing to create one less bin than required + to hold the data. (26/6/93, Davis) + +dev/hosts + Added sandalwood to all hosts files, ie tucana, bigx, ursa, gemini, + and orion. (jb 7/1/93) + +doc/vmsiraf.ms + +doc/vmsiraf.ms.v29 + + Installed the new, extensively revised VMS/IRAF manual. (7/01) + +unix/hlib/buglog.csh + Modified to also append a new buglog entry to the bugs.log file in + the network archive (~ftp/iraf/v210/bugs.log). (7/02) + +pkg/utilities/t_surfit.x + +pkg/utilities/surfit.par + +pkg/utilities/doc/surfit.hlp + +pkg/utilities/x_utilities.x +pkg/utilities/mkpkg +pkg/utilities/utilities.cl +pkg/utilities/utilities.men +pkg/utilities/utilities.hd + A task for fitting a 2D function or "surface" to an irregularly + sampled set of x, y, and z points has been added to the utilities + package. (fv 7/6) + +pkg/images/geometry/geomap.par +pkg/images/geometry/t_geomap.x +pkg/images/geometry/geogmap.x +pkg/images/geometry/geofit.x + Fixed a bug in the error handling code in geomap which was producing + a segmentation violation on exit if the user's coordinate list + had fewer than 3 data points. Also improved the error messages + presented to the user in both interactive and non-interactive mode. + (7/7/93, LED) + +unix/os/zfmkcp.c + This routine makes a zero-length copy of a file, preserving the file + mode bits so that the application need not know about the host + system's view of file types, permissions, etc. The routine was + modified to preserve the file mode bits EXCEPT that the new file has + read and write permission enabled for the owner (it is likely that + an IRAF application creating a new, zero length copy of a file or + file template will want to write to the file). (7/07) + +dev/hosts + Added pandora. (7/10/93 jb) + +sys/mwcs/mwsave.x + Added a missing call to sfree. (7/13) + +pkg/system/doc/help.hlp + Deleted a comment about using device=text with the help task and + added another example showing how to use help | type dev=text to + get a text file copy of a help page. (7/23) + +pkg/images/filters/t_median.x +pnkg/images/filters/t_mode.x + Removed an extraneous invalid argument from the call to eprintf + inside an iferr block. (7/28/93) + +------------------- +V2.10.3 BETA, first release. (7/29) + +mkpkg +unix/hlib/strip.iraf + Minor updates to strip a few things that were being missed. mkpkg + strip at the iraf root now prints some helpful messages. (8/01) + +unix/hlib/login.cl + Added dbx and gdb to the default user package. (8/01) + +pkg/images/imarith/t_imcombine.x + The algorithm for making sure there are enough file descriptors + failed to account for the need to reopen the output image header + for an update. Thus when the number of input images + output + images + logfile was exactly 60 the task would fail. The update + occurs when the output image is unmapped so the solution was to + close the input images first except for the first image whose + pointer is used in the new copy of the output image. (8/4/93 fv) + +pkg/images/imfit/fit1d.x + When the input and output images are the same there was an typo error + such that the output was opened separately but then never unmapped + resulting in the end of the image not being updated. Fixing the + typo means that only one I/O pointer is used in READ_WRITE mode + as intended. (8/6/93 fv) + +sys/mkpkg +sys/memdbg/ + +lib/libmemdbg.a + +unix/hlib/mkpkg.sf.SUN4 + +unix/as.sparc/zrtadr.s + + Added a new system library -lmemdbg. This is a debug version of MEMIO, + used to log calls to the MEMIO routines and check programs for + memory leaks (unfreed buffers). See the README file in the memdbg + directory for details on usage. (8/08) + +pkg/softools/memchk.par + +pkg/softools/memchk.x + +pkg/softools/mkpkg +pkg/softools/softools.cl +pkg/softools/softools.men +pkg/softools/x_softools.x + Added a new task MEMCHK to the softools package. This is used in + conjunction with the memdbg facility. (8/08) + +pkg/system/sort.x + This very old program had some pretty small buffer sizes and hence + was slow sorting large files. The buffer sizes were increased by + about a factor of 10. (8/08) + +sys/clio/clclose.x +sys/clio/mkpkg +sys/etc/main.x + Made a minor modification to the IRAF main to close the stdio + streams during process shutdown. This makes memdbg output a little + less confusing, although the system still allocates a number of + buffers that exist for the lifetime of the process and are never + freed. (8/08) + +sys/fio/stropen.x + Added a call to strclose to free the file pushback buffer if any. + This is only necessary when pushback is used on a string buffer + opened as a file, as in parsers. (8/08) + +sys/fio/vfnmap.x + Added a missing sfree. (8/08) + +sys/vops/aselk.gx +sys/vops/lz/mkpkg +sys/vops/mkpkg +sys/vops/vops.calls +sys/vops/vops.men +sys/vops/vops.syn + Added a missing VOPS routine aselk, the vector/scalar version of the + existing asel routine. (8/08) + +lib/evvexpr.h + +sys/fmtio/evvexpr.x + +sys/fmtio/evvexpr.y + +sys/fmtio/evvexpr.gy + +sys/fmtio/evvexpr.com + +sys/fmtio/mkpkg + Installed a new FMTIO routine evvexpr, a vector version of the old + evexpr with many other enhancements (expanded datatypes, intrinsic + functions, etc.). Refer to the imexpr help page and the comments + at the top of evvepxr.gy for details. (8/08) + +pkg/images/images.hd +pkg/images/images.men +pkg/images/images.cl +pkg/images/x_images.x +pkg/images/imarith/mkpkg +pkg/images/imarith/imexpr.x + +pkg/images/imarith/imexpr.gx + +pkg/images/imarith/gettok.x + +pkg/images/imarith/gettok.h + +pkg/images/doc/imexpr.hlp + + Installed a new task IMEXPR, used to evaluate general image + expressions. Refer to the help page for details. (8/08) + +unix/boot/mkpkg/host.c + The routine h_direq in this file is supposed to be smart enough + to be able to match up directories even when symbolic links are + used. It was being fooled by a case where the name of the iraf + root directory is not a simple "iraf" - for example on tucana the + root directory is currently called "iraf/iraf.develop". When + h_direq fails it can cause mkpkg special file list entries to + be ignored. (8/11) + +sys/fmtio/evvexpr.gy + Swapped the precedence of the unary minus and exponentiation operators + (the latter should have higher precedence). (8/12) + +sys/fmtio/evvexpr.gy + 1. The input arguments to the intrinsic functions INT and NINT were + being coerced to floating before performing the operation (harmless + but unnecessary, and inefficient). + 2. The code for the intrinsic functions "short" and "long" was missing + and was added. (9/04) + +unix/hlib/mkpkg.sf.SUN3 +unix/hlib/mkpkg.sf.SUN4 + Added the compiler switch "-Ns2048" for fmtio$evvexpr.x. This routine + (which is computer generated from evvexpr.gy and which is enormous) + was overflowing the Fortran compiler symbol table. Interestingly, + I got the same error message and had to add exactly the same switch, + using the Sun Fortran compiler on the Sun and F2C on A/UX! (9/04) + +dev/termcap +dev/graphcap + Added HP LaserJet 4M 600dpi printer 'lw16' to graphcap/termcap file + on tucana, orion, gemini, ursa, and bigx. (9/17/93 MJF) + +dev/hosts + Modified herbie entry on all hosts. Herbie now feeds off of + gemini. (jb 9/23/93) + +sys/mwcs/mwgctran.gx + Fixed a typo that was preventing LTV from being output correctly. + (9/24) + +pkg/images/imarith/icscale.x +pkg/images/doc/imcombine.hlp + The help indicated that user input scale or zero level factors + by an @file or keyword are multiplicative and additive while the + task was using then as divisive and subtractive. This was + corrected to agree with the intend of the documentation. + Also the factors are no longer normalized. (9/24/93, Valdes) + +pkg/images/imarith/icsetout.x + The case in which absolute offsets are specified but the offsets are + all the same did not work correctly. (9/24/93, Valdes) + +sys/gio/gmsg.x +sys/gio/gmprintf.x + 1. gmsg (and indirectly gmsg[bcsilrdx]) was modified to format a + message as required to the set the value of an OBM parameter object. + Previously it was working, but it would send any message to any + UI object and this would have required that applications format + messages specially for UI parameters. + 2. Reviewing gmprintf.x it appeared that the routine was never + finished and won't work - I added a comment to that effect. The + gmsg routines should prove more useful anyway. (9/26) + +sys/gio/stdgraph/stgopenws.x + When reactivating a device in certain circumstances a flag was not + being set to tell the kernel that the device was activated. A symptom + of this was that in a cursor read, colon commands would not be echoed + or the 'C' key would appear to do nothing (the characters were + actually being output but since the dialog box was never activated + they were not being printed). (10/01) + +dev/graphcap + The xgterm entry was modified to add a new field to the cursor + return struct. (10/7) + +sys/gio/stdgraph/stgopen.x +sys/gio/stdgraph/stgopenws.x +sys/gio/stdgraph/stgclose.x +sys/gio/stdgraph/stgreset.x +sys/gio/stdgraph/stgrcur.x +sys/gio/stdgraph/stgrtty.x +sys/gio/stdgraph/stdgraph.com +sys/gio/stdgraph/stdgraph.h + The stdgraph kernel was modified to allow a message to be returned + as part of a cursor read. The cursor value struct for devices such + as xgterm contains a field "nchars" defining the number of chars, + default zero, following the fixed size cursor value struct. If this + data is present it is read as part of the cursor read, and played + in a dynamically reallocatable message buffer in the stdgraph + kernel. The next stg_readtty call (as used in CL cursor reads or + when reading from STDIN when graphics is activated) returns data from + this message buffer rather than reading from the terminal. A new + routine stg_msglen was added to allow the kernel to be queried to + see how much message data is buffered. The message buffer is + emptied in each cursor read or after the first stg_readtty call. + (10/7) + +sys/gio/cursor/rcursor.x + In a colon cursor read, the rcursor code (=gcur, clgcur) now calls + stg_msglen and echoes the ":" only if there is no buffered message + data. (10/7) + +sys/gio/gmsg.x + The messaging routine gmsg now automatically disables and renables + F_FLUSHNL if this is set on STDOUT, as this interferes with the + operation of gmsg. (10/7) + +pkg/images/imarith/icsetout.x + Added MWCS calls to update the axis mapping when using the project + option in IMCOMBINE. (10/8, Valdes) + +dev/hosts + Added node sol to tucana at Ed Anderson's request. (10/8 ShJ) + +pkg/dataio/imtext/t_rtextimage.x +pkg/dataio/imtext/t_wtextimage.x +pkg/dataio/imtext/rt_cvtpix.x +pkg/dataio/rtextimage.par +pkg/dataio/wtextimage.par +pkg/dataio/doc/rtextimage.hlp +pkg/dataio/doc/wtextimage.hlp + A parameter was added to select whether to read or write the pixel + values. This is complementary to rfits/wfits and allows use of + these tasks to store and restore image headers. (10/22 FV) + +dev/hosts + Updated argo entry now that it has been updated to a sparc - on + all servers. (10/27 jb) + +pkg/images/icgrow.gx +pkg/images/icpclip.gx +pkg/images/icsclip.gx +pkg/images/icaclip.gx +pkg/images/iccclip.gx +pkg/images/t_imcombine.x +pkg/images/doc/imcombine.hlp + If there were fewer initial pixels than specified by nkeep then the + task would attempt to add garbage data to achieve nkeep pixels. This + could occur when using offsets, bad pixel masks, or thresholds. The + code was changed to check against the initial number of pixels rather + than the number of images. Also a negative nkeep is no longer + converted to a positive value based on the number of images. Instead + it specifies the maximum number of pixels to reject from the initial + set of pixels. (11/8, Valdes) + +sys/fio/stropen.x + There was an off by one problem with marking the end of the string + buffer, making it possible to run off the end of the buffer by one + char before overflow would occur. (11/10) + +pkg/images/tv/display/t_display.x + Changed the format of the z1=,z2= message to produce something that + can be cut and pasted into another CL display command to use the + same scaling. (11/12) + +pkg/images/imarith/t_imarith.x +pkg/images/doc/imarith.hlp + If no calculation type is specified then it will be at least real + for a division. Since the output pixel type defaults to the + calculation type if not specified this will also result in a + real output if dividing two integer images. (11/12/93, Valdes) + +sys/ki/irafks.x + 1. Modified the code which handles ZFSTT optbufsize,maxbufsize requests + for the binary file drivers to also query the maxbufsize for ZFIOKS + and return the minimum of this value and the device value. This + prevents the size of a binary file data transfer from exceeding the + max size network transfer. + 2. The irafks.exe executable was updated in our VMS/IRAF system. + (11/17) + +sys/ki/kbzstt.x + While looking at this code I noticed that the internal variable + kb_maxbufsize could be used before being initalized. Although I am + not aware of this having caused any problems, I modified the code to + properly initialize the variable. (11/17) + +sys/vops/arav.gx + The change made on 6/19 (to avoid an infinite loop condition that + could arise due to roundoff errors) introduced a bug that would cause + the routine to return after one iteration, without rejecting any + data. (11/18) + +sys/fmtio/gargs.x + Was not properly checking for indefinite or overflow in the double + to short conversion. (11/22) + +sys/gio/gmsg.x + The gmsg routines now do an automatic gflush before sending the + message. The gflush and a flush of STDOUT are always done regardless + of whether the output device supports messaging, to ensure that the + flush semantics are not device dependent. (11/24) + +pkg/proto/t_bscale.x + Added a call to flush after the status printout so that the output will + appear after each image is processed. (11/29 LED) + +dev/hosts + Modified deneb entry at Ed Anderson's request. (12/1 ShJ) + +sys/imio/iki/stf/stfcopyf.x + Added errchk declarations for getline and putline. (12/10) + +doc/ports/notes.aix + + It appears that we never installed the notes file from the AIX/IRAF + port so I went ahead and did this. (12/13) + +sys/imio/iki/stf/stfcopyf.x + Increased the size of the internal arrays to MAX_PCOUNT+NKW, and + added a constraint on a loop index to ensure that images with large + GPBs would not exceed this limit. (12/20) + +dev/hosts + Modified herbie entry at Lisa Wells' request. (12/22 ShJ) + +pkg/images/geometry/t_geomap.x +pkg/images/geometry/geofit.x +pkg/images/geometry/geograph.x + Fixed a bug in the geomap code which caused the linear portion of + the transformation to be computed incorrectly if the x and y fits + had a different functional form. (12/29/93 LED) + +unix/hlib/buglog.csh + The buglog will now log the bug to adass.iraf.bugs in addition to + all the usual places. (01/06 1994) + +noao/lib/zzsetenv.def + Added a definition of "noao$bin(arch)/" to 'pkglibs' so that the + smw and asttools libraries would be picked up by other packages + using '-p noao' when the package is configured generically. + (1/10/94 MJF) + +math/gsurfit/gssub.gx +math/gsurfit/gssubd.x + The gsurfit double precision routine gssubd was incorrectly calling + the real precision routine gsgeti instead of the double precision + routine dgsgeti due to an error in the gssub.gx file. This bug + results in the wrong value of the parameter GSNSAVE being returned + to the calling routine gssubd in the double precision case. + (1/17/94 Davis) + +unix/hlib/buglog.csh + Changed the default version to V2.10. (1/21) + +sys/gio/stdgraph/stgwtty.x + Due to a too-nonspecific test for the termination of a graphics + message, a newline occuring at just the right position in a text + message could cause termination of a message. This was causing + large messages to be prematurely terminated (actually this could + occur in any message but it was more likely to be seen in a large + message). (1/24) + +dev/termcap + Added an entry for xgterm called "oldgterm". This is for using + xgterm with old versions of IRAF. It makes the text window look + like an xterm but the graphics is gterm. (1/27) + +sys/memdbg/README + Fixed a couple of typos. (1/28) + +pkg/plot/t_implot.x +pkg/plot/implot.par +pkg/plot/doc/implot.hlp + The step for the j/k keys may now be set by a task parameter. (2/02 fv) + +sys/gio/gmsg.x + 1. The dtoc and xtoc functions were being called incorrectly in the + gmsg[rdx] routines. + 2. Corrected a minor typo in a procedure header. (2/04) + +pkg/dataio/doc/bintxt.hlp +pkg/dataio/doc/mtexamine.hlp +pkg/dataio/doc/rcardimage.hlp +pkg/dataio/doc/reblock.hlp +pkg/dataio/doc/rfits.hlp +pkg/dataio/doc/rtextimage.hlp +pkg/dataio/doc/txtbin.hlp +pkg/dataio/doc/wcardimage.hlp +pkg/dataio/doc/wfits.hlp +pkg/dataio/doc/wtextimage.hlp + Added a "SEE ALSO" section to most of the help pages, and fixed a + number of other minor formatting errors. (2/13) + +pkg/cl/login.cl + Updated this file. (2/14) + +pkg/cl/lexicon.c + When skipping leading whitespace before a token, will now recognize + an escaped newline and skip the newline as well. (2/14) + +sys/memdbg/README + Added a couple more minor comments. (2/18) + +unix/as.sparc/zrtadr.s + MEMDBG was not returning valid values for the RETADR (return + address) field. This was traced to a problem with as$zrtadr.s. + Evidently the real zrtadr.s was lost back when MEMDBG was written, + probably due to an accidental cc -S after the package had already + been debugged. The version in as.sparc was the assembler for the + dummy version (zrtadr.c) in sys/memdbg. I had to rewrite the real + assembler version of this routine from scratch (ouch). (2/18) + +dev/graphcap +gio/stdgraph/stggim.x + The refresh pixels function was broken due to the graphcap entry for + this function being aliased to that for read pixels (RP). This + would cause an "incomplete or reentrant format" error when trying to + do a gim_refreshpix from an IRAF imaging application. (2/24) + +gio/gim/gimrefpix.x + Edited the procedure header description to reflect a change in the + definition of the GtRefreshPixels routine in the gterm widget. (2/25) + +dev/graphcap +sys/gio/stdgraph/stggim.x + The name for the ME capability (refresh mapping) used in the xgterm + graphcap entry was a redefinition of the marker-end capability used + for drawing polymarkers. Changed the name to MN. We need a more + rigorous way to register device capability names to avoid this sort + of problem. I usually search the graphcap file, but in this case + the named was used in the stdgraph kernel but was not actually defined + for any existing device. (3/03) + +sys/imio/imwrpx.x + This code assumed that IM_PIXTYPE was int, the same as the type of + the pixel masks. Modified to convert the pixel values if necessary + when writing to the output mask. (Note that this is not necessary + when *reading* a mask, as IM_PIXTYPE will always be int in that + case). (3/07) + +sys/plio/plp2l.gx +sys/plio/plp2r.gx + Modified this code to apply a max(0,value) to the input pixel values, + i.e. to clip at zero. Masks permit only nonnegative pixel values. + Negative input values could cause the data to be improperly encoded. + (3/07) + +pkg/math/gsurfit/gs_eval.gx + The sfree statement was commented out in the routines gs_evpoly + and dgs_evpoly. This results in over-utilization of memory and + occasionally in out of memory errors for tasks which make many + successive calls to gsvector or dgsvector if the surface type + is polynomial. (3/08/94 LED) + +dev/graphcap +dev/termcap + Added entries for lw14 as requested by Ed Anderson. (3/28/94 ShJ) + +pkg/images/tv/imexamine/ierimexam.x + Changed the gaussian fitting code to use a fraction of the fitting + radius as the initial value for the full-width half-maximum in cases + where the moment analysis failed, thus avoiding an occasional + floating overflow error. (4/15/94 LED) + +dev/graphcap + Updated the VMS solitaire entries for the new location of the + qsoli.com file, usr3\072[irafext.nlocal.lib]qsoli.com. (ShJ 4/19/94) + +unix/os/mkpkg +unix/os/zfiond.c + +unix/hlib/libc/kernel.h +unix/hlib/libc/knames.h +sys/fio/mkpkg +sys/fio/ndopen.x +sys/fio/zzdebug.x + Installed a new FIO driver, the ND or network device driver. This + driver can potentially support any connection oriented, streaming + type network or IPC communications domain. The initial set of + supported communications domains are Internet sockets, UNIX domain + sockets, and FIFO pipes. The type of connection is specified by + the "filename" argument to the driver at open time. Both client + and server connections are supported. + + A client or a server opens a network device connection as follows: + + fd = ndopen (filename, mode) + + The mode is NEW_FILE for a server, anything else for a client. + The file descriptor is bidirectional. The "filename" string syntax + is determined by the ND driver and is transparent to IRAF system + and applications code. For the UNIX/IRAF ND driver, here are some + examples: + + inet:5177 # Internet socket, server + inet:5177:foo.bar.edu # Internet socket, client + unix:/tmp/.IMT%d # UNIX domain socket + fifo:/dev/imt1i:/dev/imt1o # FIFO (named pipe) + + Refer to the comments in fio$ndopen.x and os$zfiond.c for further + information. The file fio$zzdebug.x contains sample client and + server tasks. (5/01) + +sys/fio/zzdebug.x + Added two tasks "client" and "server" for testing the ND driver. + These also demonstrate how to do bidirectional i/o on a streaming + file descriptor. + (5/01) + +dev/graphcap +unix/gdev/zfiogd.x + Modified the display server interface to use the ND driver. These + changes allow use of socket connections to talk to the display + server, but are backwards compatible and will work with older + display server that only support fifos. + + 1. The "/dev/imt1" was deleted from the imtool graphcap entries and + replaced by the null string. This causes the GD (not ND) driver + to use a default network address for the connection: the default + is 1) personal (per-user) unix domain socket at /tmp/.IMT, + 2) standard imtool fifo pair at /dev/imt1[io], 3) fail. + + 2. The GD driver was modified to use the ND driver instead of + the BF driver for generic device "imtool". The user may define + IMTDEV in their host environment to override the ND "pathname" + given in the graphcap entry for the device. + + The new image display server ximtool also supports all three ND + protocols (tcp/ip sockets, UNIX domain sockets, fifos) and will + simultaneously listen for connections on all three. Multiple + connections are supported, e.g. the user can be running imexamine + on one frame while client applications load images into 1 or more + other frames. Problems can still result if multiple clients try + to simultaneously access the same frame buffer, or if different + clients have different notions of the frame buffer configuration. + (5/01) + +unix/hlib/mkpkg.sf.SUN3 + Set the compile flags for evvexpr.x to "$xc -c -/Ns2048 -/Nx2048" + for the Sun-3 (larger compiler tables). (5/07) + +sys/gio/cursor/gtrctrl.x + Modified to set the SKIPOPEN flag on openws only for interactive + (inline) graphics kernels. A F_CANCEL on the graphics spool + buffer in the prpsio code was cancelling the openws for a subkernel + and preventing it from being passed to the kernel. The SKIPOPEN + is used to keep the giotr code from sending the openws again + when the grahics data is processed. A better solution might be + to just omit the gki_write in gtrctrl but the current approch + appears to work. This fixes several bugs seen recently with + graphics subkernels (SGI, IMD, etc.) where e.g. a gflush was + necessary to make a plot appear, or to keep separate plots from + being overplotted. (5/07) + +sys/fio/putline.x + Putline would flush the output buffer after the last character + written if the number of characters written exactly filled the + buffer. This was harmless in most cases, but would prevent using + putline to write the last character in a stropen file. This + behavior was not quite correct, as FIO normally flushes the buffer + only when one tries to write to the next character after the end of + the buffer. + + This bug was causing the STF image kernel to fail to read STF + images, due to the use of stropen in the kernel. The bug was seen + only recently due to a recent fix to stropen which caused the top of + the buffer to be changed by one character. The routine was changed + to flush only when writing beyond the end of the current buffer. + (5/07) + +sys/fmtio/evvexpr.gy + The code for the || operator was incorrect, it was computing the + and instead. (5/07) + +pkg/images/imarith/imexpr.x + This code is supposed to generate an integer image for a boolean + operand when automatic determination of the output image type is + enabled, but this was incompletely implemented. Modified to + generate a TY_SHORT image if the operant type is boolean and + automatic determination of the output image type is enabled. (5/07) + +sys/fmtio/evvexpr.gy + Changed MAX_ARGS from 16 to 17 in the arglist structure to double + align the storage for the operand structs. (5/08) + +sys/mwcs/wfmspec.x + Modified wf_msp_init to fix a problem in the computation of the + inverse transformation which could occur when the first physical + pixel in an image was greatly different from the first logical + pixel. (5/08) + +--------------------------------- +Another 2.10.3 beta released and installed on all the downtown tucana +sysems. (5/08/94) + +pkg/utilities/curfit.gx + Removed the explicit x axis limits to allow the GTOOLS default + buffer to be applied so that the end points don't fall on + the vertical axes. (5/10/94 FV) + +lib/evvexpr.h +sys/fmtio/evvexpr.gy + Added padding to the operand struct to cause arrays of operand + structures to be double aligned. (5/10) + +sys/gio/cursor/giotr.x + This file was evidently not updated when the change to gtrctrl.x + was made on 5/07, but both were modified to fix the gflush or + overlaid plots problem. (5/10) + +sys/fmtio/mkpkg + Restructured the mkpkg so that the code which calls the generic + preprocessor is called both when mkpkg is run in the source + directory, and during a sysgen update. (5/10) + +sys/vops/mkpkg + Minor cosmetic edit. (5/10) + +pkg/images/geometry/t_geotran.x + In cases where the geomap database was undefined and the geometric + transformation was linear, geotran was unnecessarily overiding the + size of the output image specified by the user, if this size was + bigger than the default output size (the size of the output image + which would include all the input image pixels if no user shifts + were applied). (5/10/94, Davis) + +pkg/images/imarith/icaclip.gx +pkg/images/imarith/iccclip.gx +pkg/images/imarith/icpclip.gx +pkg/images/imarith/icsclip.gx + The reordering step when a central median is used during rejection + but the final combining is average was incorrect if the number + of rejected low pixels was greater than the number of pixels + not rejected. See bug #244. (5/25/94, Valdes) + +dev/hosts + Modified irafks.e path to deneb on all the servers, added dynamo. + (6/3/94 MJF) + +pkg/images/imarith/icaclip.gx +pkg/images/imarith/iccclip.gx +pkg/images/imarith/icpclip.gx +pkg/images/imarith/icsclip.gx + The restoration of deleted pixels to satisfy the nkeep parameter + was being done inside the iteration loop causing the possiblity + of a non-terminating loop; i.e. pixels are rejected, they are + restored, and the number left then does not statisfy the termination + condition. The restoration step was moved following the iterative + rejection. (6/6/94, Valdes) + +pkg/images/geometry/xregister/rgxicorr.x + The path names to the xregister task interactive help files was + incorrect. (6/13/94, Davis) + +math/nlfit/nlfit.gx +math/nlfit/nlfitr.x +math/nlfit/nlfitd.x + Fixed a divide by zero error in the nlscatter routine which occurs + if the fit has no degrees of freedom and the weighting type is + WTS_SCATTER. (6/13/94 Davis) + +math/nlfit/nlchomat.gx +math/nlfit/nlchomatr.x +math/nlfit/nlchomatd.x + Changed the singular matrix test to avoid problems with matrices + whose diagonal elements have values in the same dynamic ranges as + the machines epsilon. (6/15/94 Davis) + +pkg/utilities$t_polyfit.x +pkg/utilities$pfregres.f + Added a trap for rmul values < 0.0 and > 1.0 to the polyfit routine + to avoid floating operand errors caused by trying to take the square + route of a negative number. (6/20/94 LED) + +pkg/images/geometry/geofit.x + A routine expecting two char arrays was being passed two real arrays + instead resulting in a segmentation violation if calctype=real + and reject > 0. (6/21/94, Davis) + +pkg/plot/t_surface.x + The surface task no longer calls error when the input array is + unsuitable for plotting (constant valued, entirely below floor or + above ceiling). The surf_limits procedure was modified to call + eprintf and then return an error value to the calling program, which + terminates the task quietly. This less drastic error exit will + allow [e.g., IRAF test] scripts to continue after calling SURFACE + with an invalid input image. (ShJ 6/23/94) + +unix/os/zfiond.c + Fixed a typo, fd2 was being used where fd1 was intended, in an + fcntl call after an open for a client fifo. (6/24) + +unix/os/zshlib.c + Fixed a syntax error on the last line, an extra ';' following a + stubbed out function declaration. (6/24) + +pkg/images/tv/imexaine/ierimexam.x + The Gaussian fitting can return a negative sigma**2 which would + cause an FPE when the square root is taken. This will only occur + when there is no reasonable signal. The results of the gaussian + fitting are now set to INDEF if this unphysical result occurs. + (7/7, Valdes) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2ueps.c + Merged in changes from Solaris port having to do with the declaration + of a file descriptor as (FILE *) rather than int, added some #idefs + to sgi2uapl.c needed by Solaris. Also modified the header ID string + produced by sgi2uapl to be "%!PS", this is required by certain HP + LaserJet 4M printers. (7/8/94 MJF) + +pkg/utilities$t_polyfit.x + Revoved the dependent variable normalization which was not doing + anything to improve the numerical statbility of the routine and which + was causing problems in the computation of the reduced chi-squared + and standard deviation statistics. + (7/11/94 LED) + +sys/fio/zfiott.x + Modified the ttyio logging code to flush the output after each + log message. (7/23) + +pkg/images/tv/wcslab/wcslab.x + Fixed an initialization bug in wcslab that was causing the axis labels + of the plot to be drawn incorrectly the first time wcslab was run. + This was only a bug under 2.10.3 + (26/7/94 Davis) + +pkg/images/geometry/xregister/rgxregions.x + The routine strncmp was being called (with a missing number of + characters argument) instead of strcmp. This was causing a bus error + under solaris but not under sun os whenever the user set the regions + parameter to "grid ...". (7/27/94 LED) + +unix/hlib/libc/kernel.h + Replaced this file with the version from the Solaris port, which + replaces the overused PFI definition by definitions of PFI, PFV, + and SIGFUNC. (7/30) + +pkg/images/geometry/xregister/rgxcorr.x + A procedure was being incorrectly declared as an integer function. + (8/02 LED) + +unix/os/zfiotx.c +unix/os/zzstrt.c + The terminal driver (zfioty i.e. zfiotx) has long had a weakness + in that it had no protection against confusion over the terminal + state if the terminal was accessed by two or more different file + descriptors. This was the chief cause of the cursor hang problem + seen with xgterm occasionally. The ehist/eparam code in the CL + was using two different file descriptors to set the terminal modes, + and when the second when in and out of raw mode it would leave the + first descriptor thinking the terminal was in raw mode while it was + not, causing the cursor to be read in "cooked" mode. This would + cause the \r (CR) delimiter in a cursor read to be mapped to \n + hence making it impossible to read the cursor. + + The terminal driver was rewritten to maintain an internal array + of descriptors of open terminal devices. When a file descriptor + is used to access a terminal device the driver maps the file + descriptor to its internal terminal device descriptor, which is + used to uniquely maintain state information for the device. This + ensures that the device is handled consistently regardless of what + file descriptor is used to set the device mode. + + The zzstrt code had to be modified to call ZOPNTY on each of the + three stdio streams, to initialize the terminal device descriptor + for the user terminal. The driver looks for a special filename + ("unix-stdin" etc.) and uses the already open stream (stdin, stdout, + or stderr) if one of the standard streams is specified. (8/02) + +dev/graphcap + Changed the xgterm graphcap entry to recognize either \r or \n as + the trailer code for a cursor read. This is a safeguard to permit + terminating a cursor read should the tty port somehow get raw mode + cleared, e.g. by some third party process. (8/02) + +pkg/images/tv/imexamine/ierimexam.x + World coordinates printed in the 'r' profile graph are now formated. + (8/02, Valdes) + +unix/hlib/login.cl + Modified to eliminate the stty xterm case. This causes problem when + TERM is set to xterm in the host environment, but the terminal is + an xgterm. Now, if the user sets the terminal type to xgterm in + their mkiraf, this is the value which will be used. (8/10) + +unix/hlib/mkiraf.csh + Added "xgterm" to the list of suggested terminal types. (8/10) + +------------------------------- +2.10.3 beta-3 release cut (Solaris). (8/10) + +pkg/images/iminfo/imheader.x + Changed the way this task tests whether a valid pixel file exists. + This fixes the bug where [NO PIXEL FILE] is printed when the pixel + file field in the header is something other than a filename. (8/15) + +------------------------------- +2.10.3 beta-3 release updated (Solaris). (8/17) + +doc/ports/notes.solaris + + Installed notes file from Solaris/IRAF port. (8/17) + +unix/boot/spp/xc.c + Modified XC to support PKGENV values listing multiple packages. + Formerly XC supported multiple package environments (-p pkgenv) + on the command line, but permitted only a single package to be + given in PKGENV. MKPKG has long supported both options. (8/18) + +unix/os/zfiotx.c + The terminal driver had a bug affecting nonblocking raw mode + (IO_RAW+IO_NDELAY). IO_NDELAY was implementing using fcntl O_NDELAY + on the file descriptor, which sets asynchronous mode on the + device with which the file descriptor is associated, i.e., the + tty port for a terminal device. This will fail if some other + process, e.g. the unix wall/rwall task, opens and writes to the tty + device, clearing asynchronous mode and causing the next read of + the tty by the IRAF process to block. It was necessary to modify + ZGETTX to handle a nonblocking raw mode read as a special case. + Select() is used to poll the device to see if there is any data to + be read, and the read is performed only if there is data to be + read. (8/18) + +------------------------------- +2.10.3 beta-3 release updated (Solaris). (8/18) + +local/login.cl + Modified as per login.cl revision of 8/10. (8/22) + +sys/fmtio/dtoc3.x + Fixed a bug that would prevent numbers from being rounded correctly + in special cases. The bug affected only fixed format where the + number being printed was smaller than the number of decimal places. + For example, 0.09 printed with %.1f would be printed as 0.0 as + rounding was not being done properly. (9/10) + +sys/etc/prchdir.x +sys/etc/prenvset.x +sys/etc/prupdate.x + Modified prupdate to add an argument "flushout", used to force flushing + of the command output to the specified subprocess. Modified prchdir + and prenvset to use the new calling sequence for prupdate. prchdir + calls prupdate with flushout=YES, prenvset uses flushout=NO. This + should fix a problem where chdir requests could be buffered and later + flushed after one of the referenced directories had been deleted, + causing the chdir sequence to fail. (9/14) + +sys/mwcs/mwrotate.x + When rotating about a nonzero center this code was failing to + shift back to the original center after the rotate. (9/16) + +sys/mwcs/mwtransd.x + The matrix multiplication in mw_axtran was not being done properly. + The code would work in the most common cases but would fail when + rotation (non-diagonal matrix) was combined was an axis flip. (9/16) + +unix/os/zfiotx.c + tty_reset was being called incorrectly in zclstx(). (9/17) + +sys/clio/clgcur.x + Removed the limitation imposed by this routine on the maximum + length of the string which can be returned. (9/20) + +pkg/images/tv/tvmark/mkmark.x + Replaced a seek to EOF call with a flush call in the the tvmark task + "add object" procedure. On SunOS systems the seek to EOF was apparently + forcing the flush while on Solaris systems it was not, resulting in the + added objects never being written to the coordinate file. + (10/3 LED) + +dev/hosts + added entry for hohokam at Ed Anderson's request. (ShJ 10/5/94) + +sys/vops/awvg.gx + Modified to always use double precision for the loop variables + sum, sumsq, etc., even if the data is single precision. (10/06) + +sys/mwcs/wfmspec.x + Code was added to perform a direct search if the default, faster + inversion algorithm fails. (10/07) + +pkg/dataio/doc/rfits.hlp + Removed a confusing reference to difficulties reading images with + very long lines from the bugs section of the help page. + (10/10/94 LED) + +pkg/images/imfit/fit1d.x + A Memc in the ratio output option was incorrectly used instead of Memr + when the bug fix of 11/16/93 was made. (10/14/94, Valdes) + +dev/termcap + Added a two-up termcap entry for lw16 called "lw16p2" (10/20/94 MJF) + +pkg/images/iminfo/imheader.x + Restructured the code which tests for the pixel file to avoid a + potential reentrant printf. (10/24) + +sys/fmtio/ctod.x + Fixed a typo in the comment specifying the lexical form of a + sexagesimal number. (10/24) + +pkg/images/imarith/imexpr.gx + The @file form of the expression parameter was failing due to the + newline at the end of the expression as read from the text file. + Modified to convert all newlines to spaces when the file is read + in. This should work as when invoked this way the included file + can only contain a single expression, and no expression syntax + requires a newline to be entered. (10/25) + +dev/termcap +dev/graphcap + Added a new HP LJ 4 600dpi laserwriter to all servers (10/26/94 MJF) + +sys/gio/gim/gimlcmap.x + Fixed a case of an intrinsic function called with mixed type + arguments. (10/28) + +sys/gio/glabax/glabax.x + Modified to use the graphcap capability "fa" instead of "FS" to + test whether the output device has a fill area capability. (11/04) + +unix/boot/mkpkg/mkpkg + Changed a "cc" to a "$(CC)". (11/04) + +pkg/images/tv/imexamine/iecolon.x +pkg/images/tv/doc/imexamine.imh +lib/src/imexamine.key + 1. The "label" parameter was incorrectly attributed to the surface + plot instead of the contour plot. + 2. The "axes" parameter for the surface plot was missing in the code + though noted in the help. + 3. Updated the help and key file to show the label parameter belongs + to the e plot and to show the axes parameter. + (11/08) + +pkg/images/xregister.par +pkg/images/doc/xregister.hlp +pkg/images/geometry/xregister/t_xregister.x +pkg/images/geometry/xregister/rgxcorr.x +pkg/images/geometry/xregister/rgxicorr.x +pkg/images/geometry/xregister/rgxcolon.x +pkg/images/geometry/xregister/rgxdbio.x + The xregister task was modified to to write the output shifts file + in either text database format (the current default) or in simple text + format. The change was made so that the output of xregister could + both be edited more easily by the user and be used directly with the + imshifts task. (11/11 LED) + +pkg/images/geometry/xregister/rgxbckgrd.x + In several places the construct array[1++nx-wborder] was being used + instead of array[1+nx-wborder]. The Sun compilers did not catch this, + but the IBM/RISC6000 compilers did. (11/16/94, LED) + +dev/hosts + At eanderson's request, added entry for dyevushka and deleted helios. + (11/17/94 ShJ) + +dev/hosts + At eanderson's request, added entry for mimbres and changed equuleus. + (11/18/94 MJF) + +pkg/images/geometry/t_imshift.x +pkg/images/geometry/t_magnify.x +pkg/images/geometry/geotran.x +pkg/images/geometry/xregister/xrgximshift.x + The buffering margins set for the bicubic spline interpolants were + increased to improve the flux conservation properties of the interpolant + in cases where the data is undersampled. (12/6/94, Davis) + +unix/boot/spp/xpp/xppcode.c + Increased MAX_STRINGS from 100 to 256. (12/14) + +pkg/cl/param.c +pkg/cl/modes.c +pkg/cl/operand.c + Made minor changes to improve handling of INDEF. + 1) When scanning into a string parameter the string "INDEF" is no + longer converted to an indefinite operand, it is left as string data + (the INDEF test was being performed unconditionally for all operand + types, which was incorrect). + 2) Fixed bugs in a couple of places were indefinite was being + confused with undefined, or where indefinite was being treated as + an invalid operand. (12/23) + +------------ +The following changes are being merged back in following the DEC Alpha/OSF +port. (12/30) + +unix/hlib/libc/spp.h + Set XLONG to int (32 bits) instead of long. This should work for + both 32 and 64 bit platforms. (12/30) + +unix/os/zdojmp.c + This code assumed that jmpbuf was an int array and that a pointer + could be stored in the first integer element. This fails on 64 + bit machines where pointers are 64 bits and ints are 32. Modified + to coerce the jmpbuf array to long so that both 32 and 64 bit + machines will be supported. (12/30) + +unix/boot/wtar/wtar.c + Fixed a bug in WTAR involving coercion of a pointer to an integer + (line 536, bp = ...). (12/30) + +sys/gio/gks/gcas.x + Changed the procedure name from "gca" to "gcas". There is already + another procedure in the same library called "gca". "gcas" is + supposed to be the type short version. (12/30) + +sys/gio/ncarutil/autograph/agrstr.f + Commented out statements number 901, 902: "no path to this statement". + These statements are never called as the code that calls them is also + commented out. (12/29) + +sys/gio/ncarutil/autograph/agsave.f + Same thing, statement 901. (12/29) + +sys/gio/ncarutil/conlib/consld.f + Commented out statement functions SCRTCH and IARVL. These are never + called and result in a warning message. (12/29) + +sys/gio/ncarutil/conrec.f + Commented out three lines around line 1226. These lines were no + longer used because other code had been commented out, and were + resulting in a "Variable XX is used before it value has been + defined" warnings. (12/29) + +sys/gio/nspp/sysint/encd.f + Commented out several lines that were no longer used and were causing + a "no path to this statement" warning. (12/29) + +math/deboor/setdat2.f +math/deboor/setdat3.f + This library contains three files setdat.f, setdat2.f, setdat3.f + all of which contain a procedure "setdat", causing library conflicts. + These routines are not really part of the library anyway and are + only used to generate data for examples in DeBoor's book, but to + avoid the library conflicts I changed the names of the second and + third procedures to setdt2, setdt3. (12/29) + +pkg/cl/bkg.c +pkg/cl/builtin.c +pkg/cl/compile.c +pkg/cl/config.h +pkg/cl/debug.c +pkg/cl/decl.c +pkg/cl/errs.c +pkg/cl/exec.c +pkg/cl/gram.c +pkg/cl/main.c +pkg/cl/mem.h +pkg/cl/modes.c +pkg/cl/opcodes.c +pkg/cl/opcodes.h +pkg/cl/operand.c +pkg/cl/param.c +pkg/cl/prcache.c +pkg/cl/scan.c +pkg/cl/stack.c +pkg/cl/task.c + The CL has long defined the dictionary and stack as arrays of + unsigned integer. This causes problems on a 64 bit machine like + the Alpha where integer and pointer are not the same size. + To avoid this problem a new type "memel" was defined in a typedef + in config.h. The CL code was modified as necessary to declare + all dictionary and stack storage and references using this new + type. (12/29) + +pkg/cl/scan.c + The varargs code in this routine failed to compile on the Alpha, + which defines va_list as a structure rather than a variable. + This caused a (va_list) cast to fail. After studying this for + a while I couldn't find any way to safely and portably use varargs + to fake an argument list as an array. The solution adopted was + to just make a normal call to sscanf, putting the variable number + of arguments on the argument list in the normal fashion as v[0], + v[1], v[2], and so on. The current implementation imposes a + limit of at most 32 arguments for a CL scan operation. (12/29-30) + +mkpkg +noao/mkpkg + Added an entry for the "alpha" architecture. (12/29) + +unix/hlib/mkfloat.csh + 1. Modified to look for .E files as well as .e files. + 2. The script was failing because tar -tf would output file names + with a trailing space after the filename (surely a bug in OSF1 tar). + Had to add a filter to trim the whitespace. + 3. Modified the script to treat the "generic" architecture specially, + avoiding any attempt to restore any binaries etc. (12/29) + +sys/libc/zzdebug.c -> zztest.c + Renamed zzdebug.c zztest.c to avoid a name conflict with the zzdebug.x + in the same directory. (12/29) + +unix/hlib/libc/stdio.h + In struct _iobuf, changed the type declarations from long and int + to XLONG and XINT. (12/29) + +dev/hosts + Added an entry for "lyra" to the hosts table. (12/29) + +unix/os/zopdir.c + 1. Modified to use (conditionally) the newer versions of + opendir/readdir. + 2. Testing revealed a bug in this file. This was preventing commands + such as "dir /" from working on Solaris, due to a bug in the code + which strips trailing slashes from directory names. + 3. zopdir would pass back a pointer coerced to an int as the "file + descriptor" but this would fail on 64 bit systems where pointers + don't fit in 32 bits. Modified the routine to allocate a kernel + file descriptor for the directory and pass back a normal fd instead. + + Items 1 and 2 above were actually made in the Solaris port. (12/30) + +pkg/dataio/fits/t_wfits.x + Wfits was using the name of the @file instead of the first file as the + root output fits file name if the number of output files was 1. + (1/18/94 LED) + +unix/os/alloc.c + Fixed a bug in alloc.e which could allow some files in /dev/ to be + allocated even though the file permissions didn't permit this. (1/18) + +tags + Edited this old tags file to change absolute pathnames such as + "/usr/iraf/sys/..." to "sys/...". (1/19) + +dev/hosts + Added lyra to this file on ursa. (01/20 jb) + +unix/os/zfiond.c + Added a check for the status returned by getstr() to avoid attempting + undefined operations on a null return value. (1/27) + +sys/fio/zzdebug.x + Added a task "daytime" to the FIO zzdebug. This demonstrates use + of the zfiond driver to connect to the TCP/IP "daytime" service to + print out the date and time. (1/27) + +hlib/extern.pkg + Added the ccdacq package from ursa to permit help to be accessed + via the irafhelp web page per Jeannette's request. (2/1 RLS) + +iraf/dev/hosts + Added katmai to the hosts files on tucana, ursa, gemini, bigx and + orion. (2/7/95 jb) + +pkg/math/curfit/doc/curfit.spc + Fixed a bug in the specification of the Legendre polynomials. + (2/15 LED) + +pkg/images/tv/imexamine/iejimexam.x + Fixed a pointer addressing error found by Zarate. (2/16 FV) + +pkg/plot/t_implot.x +pkg/plot/pltwcs.x + When trying to plot a column of a 1D image the physical axis was + being set to zero and then used inapproprriately as a pointer offset + causing an error on the Dec Alpha port. The axis now defaults to + 1 and also the task now beeps when attempting a column plot rather + than plotting a point point line. (2/16 FV) + +sys/imio/iki/stf/stfopix.x + The pointer o_im (old image header) was being used in an expression + even for new (non new-copy) images. Whether or not the pointer was + actually referenced would depend on the Fortran compiler and how + it evaluated the expression. (2/18 1995) + +sys/gio/cursor/grcread.x + A call to grc_message was missing the "stream" argument. (2/23) + +pkg/system/help/helpdb.x + The final call to error() was missing the errcode argument. (2/23) + +sys/gio/gki/gkiexe.x + The code for GETCELLARRAY was incorrectly using zcall7 instead of + zcall6. (2/23) + +sys/gio/stdgraph/stgreset.x + Not all polyline and fillarea attributes were being reset when a + open or close workstation (stg_reset) occurred. Added initializations + for PLTYPE, FASTYLE, PLWIDTH. (2/25) + +unix/hlib/extern.pkg + Installed IMCNV for use on tucana. (3/2 MJF) + +pkg/images/geometry/xregister/rgxtools.x + Changed some incorrect amovr and amovi calls to the correct amovkr + and amovki calls. (3/15 LED) + +pkg/dataio/fits/fits_cards.x + Added some wfits code to filter any "END " keywords out of the + image header userarea. (3/17 LED) + +pkg/images/tv/doc/display.hlp + Clarified the explanation of the 'zrange' parameter to indicate that + if min/max values are defined they will be used, otherwise the image + is subsampled using nsample_lines to approximate the min/max when + determining the mapping. (3/22 MJF) + +pkg/plot/t_gkixt.x +pkg/plot/doc/gkiextract.hlp + Increased the size of the index array from 2048 to 8192 to accomodate + very large metacode files. Added a note to the help page mentioning + the limit. (3/22 MJF) + +pkg/images/geometry/xregister/t_xregister.x + Added a test on the status code returned from the fitting routine to + prevent the xregister task from writing an output image when the user + quits the task in in interactive mode. (3/31/95, Davis) + +dev/hosts + Added 'vanilla' to the mountain sites on all servers. (4/5/95 MJF) + +sys/imio/iki/stf/stfrfits.x + Added an errchk for open. (4/03 1995) + +sys/fio/open.x + Added errchks for fgetfd, filopn, seek. (4/03) + +pkg/images/tv/mkpkg +pkg/images/tv/wcslab/mkpkg + The general purpose routines in WCSLAB were moved into libds.a. (4/10) + +pkg/images/tv/doc/imexamine.hlp + Fixed a typo in the equation for ellipticity. (4/10) + +pkg/images/tv/imedit/t_imedit.x +pkg/images/doc/imedit.hlp + The 'j', 'k', 'n', and 'u' keys were added to those recorded in the + logfile. (4/11, FV) + +sys/gio/imdkern/t_imdkern.x + The IMD kernel was modified to add a new debug option that will + work even when the kernel is run as a generic subkernel of the CL. + For example if we do a "set idkdebug = /tmp/idk.out" then the + kernel will log GKI input to the file ikd.out. In debug mode output + is flushed after every output line, hence one can do a "tail -f" on + the file to monitor the kernel during execution, to see what the + CL is sending it. Currently this feature is only available in the + IMD kernel but it would be easy to add it to other graphics kernels + if needed. (4/13) + +sys/etc/prpsio.x + The pseudofile i/o controller was modified to fix what has been + referred to as the "imdkern bug", where the IMD kernel would not + flush its output to the image display as it used to prior to 2.10.3. + + What happened was that the addition of GUI support in 2.10.3 + included support for bidirectional GIO, where the application sends + a request to the graphics server and reads back the response. The + pseudofile i/o system buffers messages in the graphics streams in + the CL and in order to support bidirectional transfers it is + necessary to cancel the i/o buffer for the graphics stream to + prepare for a possible response. No bug was found in this code, but + what was happening was that when a control message was sent to + PSIOCTRL a request such as close-workstation would write the GKI + request to the graphics stream; this stream is just a file buffer in + the CL and any data written there is not passed to the graphics + subkernel until the subkernel reads from its input stream. In most + circumstances subsequent graphics output would cause the buffered + control request to be passed on to the subkernel and this is what + was happening in versions of IRAF prior to 2.10.3. The addition of + the cancel-stream statements in 2.10.3 would cause these buffered + control requests to be discarded. In the case of imdkern the kernel + would never see the close-workstation request, and the output would + not be flushed until an event occurred such as shutting down the + kernel with gflush. + + The fix was to modify the PSIOCTRL handling in prpsio.x to push an + XMIT request on the psio control stack, to cause the buffered + control requests to be passed on to the subkernel in the next + iteration of the pseudofile i/o controller. (4/13) + +kifndnode.x +kignode.x +kilnode.x +kimapname.x + +kishownet.x +mkpkg + KI was modified to change the way logical node names are handled. + A logical node name is an environment variable which maps to a + node name from the dev$hosts table. Logical node names are used + to create symbolic links to physical node names, providing physical + node name independence, or to otherwise alias node names without + having to modify the hosts table. + + The initial implementation of this feature was dangerous as logical + node names and other environment variables share the same name + space and inadvertent name collisions could occur. The fix was to + require a special syntax to define a logical node name: an environment + variable is treated as a logical node name only if the node delimiter + character "!" is appended to the value string. For example, "set + alpha = foo.bar.edu!" would define logical node alpha to be the same + as foo.bar.edu. (4/13) + +unix/hlib/motd + Version number incremented to V2.10.4BETA. (4/13) + +sys/fmtio/evvexpr.gy + This routine was modified as follows to fix bugs seen in IMEXPR. + 1. There was a bug affecting binary scalar/vector boolean operations + where the vector operand was the second operand: the type conversion + would fail if the vector operand was of type boolean. The routine + xvv_boolop was modified to treat any input boolean operands as + integer (they are stored in expressions operands as integers anyway), + this avoids the special case and is a bit more general. The test + case used was the expression "(J <= 5 && I <= 10) ? 0 : a". + 2. xvv_quest was modified to permit int as well as bool for the + input conditional. A bug was fixed where the routine would fail + if the input conditional was a scalar but the data operands were + vectors; the code was assuming a vector conditional in this case. + For example, "(J <= 5) ? 0 : a" would fail, as (J <= 5) is a scalar + (J is a constant when evaluating the expression for a line). (4/14) + +sys/gio/gascale.x +sys/gio/grscale.x + These routines can modify or set a WCS but they were not setting + the WF_MODIFIED flag, a recent addition with the GUI support. This + fixes a problem first seen with IMPLOT where cursor reads would in + some cases print NDC coordinates instead of pixel coordinates. (4/15) + +sys/osb/miinelem.x + The miinelem routine was incorrectly rounding up to the next full + mii_type when computing the number of mii_type items that can fit in + a char array of a given length. (Bug reported by Phil Hodge May94). + (4/17) + +pkg/images/doc/fit1d.hlp + Added a description of the interactive parameter to the fit1d help + page (4/17 LED). + +sys/mwcs/mkpkg +sys/mwcs/mwsave.x +sys/mwcs/mwload.x + 1. The mw_save/mw_load routines are supposed to encode a MWCS in a + machine independent form and later restore it, but due to a bug the + encoded MWCS was not fully machine independent. mw_save uses pl_p2li + to compress the integer part of the MWCS descriptor, but mw_save + was using miipak32 to encode this for external storage. This is + incorrect since pl_p2li produces a type short rather than integer + array. The bug was harmless on big-endian machines like a Sun or + on any machine when the saved MWCS was read back on the same machine, + but would cause the saved MWCS to fail to load when tranferred to a + machine with a different architecture. The fixed code now uses + mii{pak,upk}16 to transform the data. mw_load can still read old + saved MWCS provided they were written on a machine of the same + architecture. + 2. mw_load now initializes the axis map to a 1 to 1 mapping as in + a call to mw_open to create a new MWCS (formerly the axis map + storage was zeroed following a mw_load). The axis map is not saved + and restored over a mw_save/mw_load sequence. (4/18) + +sys/mwcs/zzdebug.x + Added two new debug tasks "save" and "load". SAVE creates a dummy + MWCS, calls mw_save to encode it , and then saves it to a file + "mwcs.sav" in the current directory. LOAD calls mw_load to load + the named MWCS save file. Both routines call mw_show to display + the MWCS so that one can easily verify that it has been saved and + restored correctly. (4/18) + +sys/mwcs/iwewcs.x + The routine iw_enterwcs could set the RA axis incorrectly for a ra/dec + projection where the ra/dec axes were not axes 1/2 or 2/1 and the + CDELT keywords were used rather than the CD matrix. (4/18) + +sys/mwcs/imwcs.h +sys/mwcs/iwctype.x +sys/mwcs/iwpstr.x +sys/mwcs/mwcs.h +sys/mwcs/mwsaveim.x + The maximum number of WCS attributes was increased from 256 to 512. + The WAT and WSV keyword handling code was modified to permit more + than 999 keywords to be output; the format changes to omit the + underscore if the index value exceeds 999. These changes should be + backwards compatible while allowing more complex WCS to be stored. + (4/19) + +pkg/system/rename.x +pkg/system/rename.par +pkg/system/doc/rename.hlp + Modified the task to allow a destination directory to be specified + without changing the filename. A new "field" parameter option "all" + was added and made the default so the entire filename is changed (or + moved in the case of a destination directory). When field is set to + "extn" filenames without an extension will not have the new + extension appended so a filename isn't generated which can get + overwritten. (3/14/95 MJF 4/19 DCT) + +pkg/cl/builtin.c + Appending the output of a foreign task now works correctly; previously + it would overwrite any existing output file. For example, "ls >> foo" + will append the output of ls to file foo. The bug addressed here + affected only explicit redirection of the output of a foreign task. + Previous version of the CL would correctly redirect the output of a + foreign task so long as the task was called indirectly, e.g. from + within a CL script. (4/19) + +sys/etc/oscmd.x + Added clobber checking for the output redirection files if any. + (4/19) + +unix/shlib/mkshlib.csh + We had another one of those nasty occurrences where the iraf shared + library is rebuilt and suddenly nothing runs anymore (this happened + after the trivial modifications to oscmd.x above). The problem was + traced to the setting of the "environ" pointer in low shared image + memory by vlibinit when the shared image is mapped by zzstrt. The + environ variable is part of the Sun startup code and is one of the + first objects linked into the shared library image. The problem was + that the data for this variable was located in the end of the last + page of text, but since the text was mapped readonly a segvio would + occur when attempting to write to this variable. The fix, at least + for the moment, was to add a ".align 4096" to the end of V.s to + force the data segment to be aligned to a page boundary. (4/20) + +sys/imio/iki/stf/stfdelete.x + stfdelete now checks to see if the pixel file exists before trying + to delete it. It is not considered an error if there is no pixel + file. (4/20) + +pkg/cl/config.h + Doubled the size of the stack and dictionary. (4/21) + +unix/hlib/zzsetenv.def + The default printer and stdplot devices were changed to "lp", which + on unix systems is the default line printer device. If the user + has PRINTER set in their host environment IRAF printer output will + be directed to the user specified device. The default printer + device may still be overridden from within IRAF by setting an + environment variable or via a parameter override. (4/28) + +unix/hlib/libc/kernel.h +unix/os/zawset.c + A number of changes were made to ZAWSET (called by BEGMEM) to improve + memory utilization for IRAF tasks that request and use very large + amounts of memory. These changes should be backwards compatible and + the usages of ZAWSET and BEGMEM were not changed. + + 1. Modified to make it easier to determine whether the setrlimit + code is used on different platforms. + 2. Removed the setrlimit that was being performed at process + initialization time to set the soft limit on a processes memory. + It is questionable whether this should be limited by default on + modern systems which are mostly personal workstations, and it + is better to use the "limit" command in the CSH (or equivalent) + to do this outside of IRAF, under user control. + 3. In kernel.h, increased the default WSS to 8 Mb and the builtin + max WSS to 256 Mb. These values are used only on platforms where + ZAWSET can't determine the value from the UNIX kernel, e.g. using + getrlimit. Assuming MAXWORKSET is not defined (see below) the + max WSS value compiled into the IRAF kernel, e.g. 256 Mb, will + however serve as an upper limit on the amount of memory reported + as available to an IRAF task. + 4. Added support for an environment variable "MAXWORKSET". This + value if defined sets an upper limit on the working set reported + to a task via ZAWSET (or BEGMEM). This can be used to override + the builtin upper limit. If the platform supports getrlimit and + a memoryuse limit is defined which is less than MAXWORKSET, the + getrlimit value will be used instead: this the current limit, + as opposed to the maximum limit. The units of MAXWORKSET are Mb, + e.g. "setenv MAXWORKSET 32" sets the maximum working set to 32 Mb. + Since MAXWORKSET is used by the host-level kernel code it must be + set in the host environment, not in IRAF. + + A quick survey of SunOS, Solaris, and OSF/1 shows that the system + default getrlimit returns the amount of available physical memory + (57 Mb) on OSF/1, but an "unlimited" value (2 Gb) on the Sun systems. + The OSF/1 value is what zawset ideally wants to return, i.e. the + maximum amount of physical memory available to the process before + paging occurs. This can be difficult to determine on many unix + platforms and currently the builtin kernel limit of 256 Mb will be + what is returned on platforms like SunOS/Solaris that don't report + the physical memory value. With further research we may be able to + find a way to do reliably return the correct value on platforms + like Sun, however this can be a very system dependent feature to + implement. In the meantime the MAXWORKSET environment variable, + or "limit" in the cshell (etc.) can be used to fine tune ZAWSET on + platforms that can't determine the max physical memory. (5/02) + +unix/hlib/zzsetenv.def + Changed "gterm" to "xgterm" for the default values of stdgraph + and terminal. (5/03) + +sys/gio/fpequald.x +sys/gio/fpequalr.x + The comparison could fail if either operand was zero and the other + was a very small nonzero number. (5/10) + +------------------------------ +V2.10.4 distribution (beta test for the NOAO servers) prepared. (5/10/95) + +unix/hlib/login.cl + Added a note about the trailing "!" needed for "set node =" in + V2.10.4. (5/11) + +sys/etc/xerpop.x +unix/hlib/libc/libc.h + Changed the C construct {XERPSH();stmt;}if(XERPOP()) to + {XERPSH();stmt;}if(XERPOPI()), and added a new routine XERPOPI to + xerpop.x. The original construct was incorrect as it was treating + the result of the boolean function xerpop() as an integer. (5/12) + +------------------------------ +V2.10.4 distribution upgrade prepared. (5/14) + +pkg/cl/scan.c + Fixed a nasty bug in the scan code affecting scans into a string + parameter; the string buffer was being improperly referenced. This + bug has been in place since the scan code was modified on 12/29/94 + but evidently was never seen as IRAF is not exercised enough on + tucana. Showed up right away when V2.10.4 moved to the user nodes. + (5/15) + +unix/os/zawset.c + On Solaris it turns out that setrlimit, when used to set the soft + memory limit, sets a hard limit on memory allocation for the process, + causing malloc requests to fail if the set limit is exceeded. This + is not really the point of begmem/zawset, so the code was modified + to only call setrlimit if one attempts to increase the current "soft" + memory limit. Requests for less working set than the soft limit + do not result in a call to setrlimit, and the routine merely indicates + that the requested space is available. (5/15) + +unix/hlib/zzsetenv.def + Updated "version" to 2.10.4EXPORT. (5/19) + +unix/hlib/spy.cl + Rewrote spy.cl to work on both BSD and SYSV systems (SunOS and + Solaris in the case of Solaris/IRAF). (5/19) + +------------------------------ +V2.10.4 distribution upgrade prepared. (5/21) + +dev/hosts + Added Tod Lauer's machine seurat to hosts file on all servers (5/25 MJF) + +sys/imio/db/imgnfn.x + This code supported, for keyword selection, only naxis[1-3]. Added + support for axes up to 7. (5/26) + +sys/fmtio/evvexpr.gy + 1. Modified the conditional expression code (xvv_quest) to consider + the dimension of the condition operand as well as that of the two + data operands when computing the dimension of the expression result. + For example, if the condition is a vector but the two data operands + are scalars, the expression result should be a vector (formerly it + was a scalar). The datatype of the expression is still determined + solely by the datatypes of the two data operands. + 2. The condition operand for a conditional expression may now be any + integer type, i.e. short or long as well as int, in addition to bool. + If int is permitted it doesn't make much sense to exclude short and + long. + 3. The logical not code (e.g. "!a") was modified to permit integer + class operands (short, int, long) as well as boolean. (5/27) + +------------------------------ +V2.10.4 distribution upgrade prepared. (5/29) + +dev/hosts + Corrected path name to irafks.e for pyxis on all servers (5/31 MJF) + +dev/hosts + Added lonestar and tribble to all downtown servers (6/6 MJF) + +------------------------------ +IRAF V2.10.4 system copied to iraf.export and V2.11 development begun. (6/12) + +unix/hlib/motd +unix/hlib/zzsetenv.def + Develop system version number incremented to V2.11. (6/12) + +pkg/images/geometry/t_geotran.x +pkg/images/geometry/geotran.x +pkg/images/geometry/geotimtran.x + Fixed a bug in the buffering of the x and y coordinate surface + interpolants which can cause a memory corruption error if, the + nxsample or nysample parameters are > 1, and the nxblock or nyblock + parameters are less than the x and y dimensions of the input image. + Took the opportunity to clean up the code. (6/13/95, LED) + + +pkg/math/curfit/cvpower.gx +pkg/math/curfit/cvpowerr.x +pkg/math/curfit/cvpowerd.x +pkg/math/curfit/doc/curfit.hd +pkg/math/curfit/doc/curfit.men +pkg/math/curfit/doc/cvepower.hlp + Added the new routine cvepower to the curfit math library. Cvepower + computes the errors in the power series coefficients equivalent + to the fitted Legendre and Chebyshev coefficients. Cvepower is + available in both real and double precision versions. (6/13/95, LED) + + +pkg/images/fmedian.hlp +pkg/images/fmode.hlp +pkg/images/median.hlp +pkg/images/mode.hlp +pkg/images/fmedian.par +pkg/images/fmode.par +pkg/images/median.par +pkg/images/mode.par +pkg/images/filters/fmedian.h +pkg/images/filters/fmode.h +pkg/images/filters/median.h +pkg/images/filters/mode.h +pkg/images/filters/t_fmedian.x +pkg/images/filters/t_fmode.x +pkg/images/filters/t_median.x +pkg/images/filters/t_mode.x +pkg/images/filters/fmedian.x +pkg/images/filters/fmode.x +pkg/images/filters/median.x +pkg/images/filters/mode.x +pkg/images/filters/fmd_buf.x +pkg/images/filters/fmd_hist.x +pkg/images/filters/fmd_maxmin.x +pkg/images/filters/med_buf.x +pkg/images/filters/med_sort.x + Added minimum and maximum good data parameters to the fmedian, fmode, + median, and mode filtering tasks. Removed the 64X64 kernel size limit + in the median and mode tasks. Replaced the common blocks with + structures and .h files. (6/20/95, LED) + +pkg/images/frmedian.hlp +pkg/images/frmode.hlp +pkg/images/rmedian.hlp +pkg/images/rmode.hlp +pkg/images/frmedian.par +pkg/images/frmode.par +pkg/images/rmedian.par +pkg/images/rmode.par +pkg/images/filters/frmedian.h +pkg/images/filters/frmode.h +pkg/images/filters/rmedian.h +pkg/images/filters/rmode.h +pkg/images/filters/t_frmedian.x +pkg/images/filters/t_frmode.x +pkg/images/filters/t_rmedian.x +pkg/images/filters/t_rmode.x +pkg/images/filters/frmedian.x +pkg/images/filters/frmode.x +pkg/images/filters/rmedian.x +pkg/images/filters/rmode.x +pkg/images/filters/med_utils.x + Added new ring median and modal filtering tasks frmedian, rmedian, + frmode, and rmode to the images package. (6/20/95, LED) + +doc/ports/notes.osf1 + + Added notes file from DEC Alpha OSF/1 port. (6/21) + +sys/fio/fioclean.x +sys/fio/stropen.x + Two new internal routines str{set,get}mode were added to stropen.x. + These are used to set or query the file access mode as stored for + the string file, which represents these in a file-dependent way. + fio_cleanup was modified to force the access mode of a string file + to READ_ONLY before closing it during file cleanup, to prevent the + writing of the trailing EOS when closing a string file opened for + writing. The latter could cause a segmentation violation if the + string buffer was no longer in a mapped region of memory, as is + possible if the string file is still open (i.e. not closed normally) + following task termination when fio_cleanup is called. This problem + was found when testing the OSF/1 version of IRAF. (6/21, merged from + OSF1 revision of 6/06) + +dev/termcap + Added "lp" as an alias for "lpr". (6/26) + +dev/hosts + Added solstice to the downtown servers (tucana,ursa,gemini,orion,bigx) + at Ed Anderson's request (6/26 RLS) + +unix/hlib/mkpkg + Changed "mkshlib.csh" references to "./mkshlib.csh" to make the + script more robust in cases where the user has the path screwed + up. (7/03) + +dev/tapecap + Added support for device mtc|mtcc for BIGX, an HPDAT drive using the + ST driver. Also generic device st-hpdat, the HPDAT on ST. (7/18) + +dev/hosts + Added aten, volans, & musca to all servers, deleted vegemite (7/18 MJF) + +dev/hosts + Added soleil to all downtown server at Ed Anderson's request. (7/27 MJF) + +sys/fmtio/strdic.x + Was not ignoring leading whitespace on the string to be tested, when + computing the length "len" of the string. (7/31) + +pkg/proto/t_wcsreset.x + Added an error check to the mw_openim command so wcsreset can erase + the world coordinate systems of images with wcss that it cannot + read correctly. (1/8/95, Davis) + +pkg/xtools/inlfit/incopy.gx +pkg/xtools/inlfit/incopyr.x +pkg/xtools/inlfit/incopyd.x + Changed 4 MEMP (Memi) references to Mem$t references. (02/8/95, Davis) + +dev/tapecap + Modified gemini entry to change WangDat to an HP drive. (8/10) + +sys/fio/zzdebug.x + Replaced the t_ndopen debug task by a more recent version. (8/28) + +lib/gio.h +sys/gio/gplcache.x +sys/gio/gctran.x + The WCS transformation caching mechanism used in gctran was not + reliable and could fail in some cases where the WCS was changed more + frequently than gctran was called. To make caching of WCS related + information more robust a new field GP_WCSORD was added to the GIO + descriptor. This is set to a unique integer ordinal when a WCS is + fixed. If the ordinal changes any routines that cache WCS information + should invalidate their cache (unless they cache it on the basis of + WCSORD). WCSORD will differ for WCS stored in different graphics + descriptors, so testing WCSORD also does an implicit test that the + GP has changed. (8/28) + +sys/mwcs/iwewcs.x + Modified so that if an image contains a partial Lterm consisiting + of an LTV but no LTM, the missing LTM will default to the identity + matrix instead of the zero matrix (the latter causes a segvio if you + try to invert it). An image with a zero LTM is illegal but MWCS + should not die with a segvio in this case. (8/29) + +sys/imio/immaky.x +sys/imio/mkpkg + When copying an image section IMIO will call MWCS to update the Lterm + of the output image. This requires that it load any existing WCS + so that it can be modified and written out to the output image. IMIO + was modified to put the mw_open in an iferr block, printing a warning + message if the WCS cannot be loaded, rather than aborting the immap. + Aborting means that all IRAF imaging tasks fails to access the image + if it contains a WCS of a type not supported by IMIO. (8/29) + +sys/mwcs/iwgbfits.x + The code which reads in multiline FITS strings (WATi_j etc.) would + always read 68 characters per card. This was changed to read at + most 68 characters, terminating if newline, EOS, or a single closing + quote is seen in the input data. This allows the string on a line to + be less than 68 characters. It also avoids a bug seen with non-blocked + headers where the cards may contain less than 80 characters. (8/29) + +sys/mwcs/iwpstr.x + The final card of a multi-card string is no longer blank filled, i.e. + the closing quote will appear at the end of the string instead of in + column 80. (8/30) + +sys/mwcs/mwsaveim.x + The code which puts spaces between a sequence of attribute=value + keywords in a WCS attribute list was improved to avoid an unnecessary + space at the end of the list (spaces are now only used between the + members of the list). (8/30) + +sys/imio/db/impstr.x + When writing a string valued parameter the code checks for a trailing + quote and tries to add one if it is missing. The closing quote is + omitted if it would overwrite a data character - it isn't required + when reading cards unless the string ends before column 80. (8/30) + +sys/mwcs/mwsave.x + The DBUF offset in the save header was not being aligned to double. + (8/30) + +------------------------------------- +V2.10.4 patch 1 generated. (8/30) + +doc/rev2.hlp + Renamed this file to rev2.txt, it is not a help file. (9/03) + +unix/boot/bootlib/osfiletype.c + Added ".gz" to the list of "source" file types. Also added ".fit" + as an alias for ".fits". (9/03) + +mkpkg +noao/mkpkg + Added entries for linux and linuz architectures. (9/06) + +unix/hlib/strip.iraf +noao/lib/strip.noao + Replaced by updated versions, some files moved around and others + have been added. (9/06) + +local/.cshrc + Added "." and moved /usr/lang up in the hierarchy. (9/21) + +hlib/extern.pkg + Added the helpdb for the finder package on gemini and ursa. The + package is still loaded through the nlocal package. (10/12 RLS) + +sys/mwcs/imwcs.h + CROTA was being stored internally as an integer, causing small + truncation errors of non-integral rotational angles. (10/18) + +dev/graphcap +dev/imtoolrc + Added a new 8192x8192 frame buffer (imt7|imt8192). Redefined the + old imt7 (imt4x1) as imt19. (11/01) + +pkg/images/tv/imexamine/ierimexam.x +pkg/images/tv/imexamine/stfmeasure.x + +pkg/images/tv/imexamine/starfocus.h + +pkg/images/tv/imexamine/mkpkg +pkg/images/tv/doc/imexamine.hlp +lib/src/imexamine.key + New FWHM estimates based on the enclosed flux and a direct + measurement were added to the 'a' and 'r' keys. The weights for + the Gaussian fit were modified to reduce the influence of pixels + outside the half-maximum radius. The ? help and help page were + revised to described the new output and algorithms. (11/09) + +dev/hosts + Added 'inti' to all downtown servers. (11/20 MJF) + +pkg/images/median.par +pkg/images/rmedian.par +pkg/images/mode.par +pkg/images/rmode.par +pkg/images/fmedian.par +pkg/images/frmedian.par +pkg/images/fmode.par +pkg/images/frmode.par +pkg/images/doc/median.hlp +pkg/images/doc/rmedian.hlp +pkg/images/doc/mode.hlp +pkg/images/doc/rmode.hlp +pkg/images/doc/fmedian.hlp +pkg/images/doc/frmedian.hlp +pkg/images/doc/fmode.hlp +pkg/images/doc/frmode.hlp +pkg/images/filters/t_median.x +pkg/images/filters/t_rmedian.x +pkg/images/filters/t_mode.x +pkg/images/filters/t_rmode.x +pkg/images/filters/t_fmedian.x +pkg/images/filters/t_frmedian.x +pkg/images/filters/t_fmode.x +pkg/images/filters/t_frmode.x + Added a verbose parameter to the median, rmedian, mode, rmode, fmedian, + frmedian, fmode, and frmode tasks. (11/27/95, Davis) + +dev/hosts + Corrected path to irafks.e for cephus on all servers (11/30 MJF) + +unix/boot/spp/xpp/xppcode.c + Modified XPP to make keyword recognition case sensitive. Keywords + such as "int", "char", "procedure", etc. must be lower case to be + recognized. This permits macros to use the upper case versions of + these keywords. (12/05) + +pkg/cl/debug.c + Added INDXINCR and PUSHINDEX to the debug code. (12/14) + +pkg/cl/builtin.c +pkg/cl/compile.c +pkg/cl/debug.c +pkg/cl/exec.c +pkg/cl/grammar.y +pkg/cl/main.c +pkg/cl/opcodes.c +pkg/cl/opcodes.h +pkg/cl/prcache.c + 1. Fixed minor bugs in the CL array code which showed up on the 64bit + DEC Alpha. The array code had builtin assumptions about the size of + structures stored in CL memory, but on 64 bit systems the CL stack + and dictionary have a 64 bit memel size, rather than 32 bit. + + 2. Added a new builtin "d_trace" which permits instruction and + process tracing during execution. Typing d_trace without any + arguments toggles this feature. An optional argument 0 or 1 may be + used to disable or enable instruction tracing. A source line trace + feature might have been nicer, but instruction tracing should still + be of use for tracking down bugs in scripts, or otherwise revealing + what is going on when the CL executes a task. (12/16) + +sys/fmio/zzdebug.x + Added a parameter to the create datafile task to allow specification + of FM_MAXPTPAGES (max page table pages), for testing large datafiles. + (12/18) + +dev/hosts + Added new solaris machine oso to all servers. (1/29/96 MJF) + +pkg/images/imarith/imexpr.gx + Modified imexpr so that it will accept an image name that looks like + a number in the first few characters, but which is really an image + name. For example, "123.imh" or "../foo.imh". The previous version + of imexpr was treating any string which looked like a number in the + first few characters as a numeric constant. (2/8/96 LED 2/14 DCT). + +dev/hosts + Eliminated all references to /gemini and /ursa since all machines + have been updated such that /iraf is the correct path. Merged all + changes from other servers to tucana so all hosts files are now + identical, new machines added include ozzie, verdi, corondito and + pearl.kpno. Backups of previous files will be maintained. (2/14 MJF) + +pkg/images/geometry/t_geotran.x +pkg/images/geometry/geograph.x +pkg/images/doc/geomap.hlp + Corrected the definition of skew in the routines which, compute the + geometric interpretation of the 6-coefficient fit, compute the + coefficients from the geometric parameters, and in the relevant help + pages. (2/19/96, LED) + +sys/fio/zzdebug.x + Spiffed up the "daytime" debug/test task to permit entry of a host + name, so that one can use this to find out what time it is at some + site halfway around the world. (2/23) + +pkg/images/tv/imexamine/iejimexam.x +pkg/images/tv/jimexam.par +pkg/images/tv/doc/imexamine.hlp + There were several errors in this which only showed up when using a + world WCS. The parameter prompt and help now indicate the initial + sigma value is in pixels even when fitting in world coordinates. + (2/27/96, FV) + +pkg/images/tv/imexamine/iemw.x + The inverse WCS function was incorrect and is fixed. (2/27/96, FV) + +pkg/dataio/doc/rfits.hlp + Added a note about support for unsigned short integers to the + rfits help page. (2/27/96, LED) + +pkg/xtools/icfit/icvshow.gx +pkg/xtools/icfit/icshow.x +pkg/xtools/icfit/icerrors.gx + All output except the tabular part of :xyshow now begins with + the comment character. (2/29, Valdes) + +pkg/utilities/curfit.gx + Removed repeated output and added a comment character to the table + header line. (2/29, Valdes) + +dev/hosts + Changed GONG machines soi/mdi to use bin.ssun after solaris upgrades. + (3/8/96 MJF) + +sys/fmio/fmio.h +sys/fmio/fmlfopen.x +sys/fmio/fmlfbwr.x +sys/fmio/fmlfbrd.x +sys/fmio/fmioextnd.x +sys/fmio/fmclose.x + 1. Changed the lfile pagemap (LF_PAGEMAP) from type short to int. + This is entirely an internal array, created at lfile open time from + the global pagemap, and never written out, so there should be no + problem changing the datatype of the array. A type short lfile + pagemap limits the maximum datafile size by limiting the max file + offset to 32K datafile pages. This is not a problem for the global + page table as the global table stores the lfile number in each PTE, + with the offset of the PTE entry giving the associated file offset + (page number). + 2. Increased the default lfile pagemap size and increment on + overflow. (3/11) + +lib/qpset.h +sys/qpoe/qpoe.h +sys/qpoe/qpstati.x +sys/qpoe/qpseti.x +sys/qpoe/qpopen.x +sys/qpoe/qpmacro.x +sys/qpoe/qpbind.x + Added a new parameter "maxptpages" (QPOE_MAXPTPAGES) to QPOE. This + is a datafile control parameter similar to "maxlfiles" or "pagesize". + The pagesize and matptpages together determine the maximum datafile + size. In the past we have had to increase the pagesize to accomodate + very large datafiles, but beyond a certain point it is better to + increase the maximum page table size (maxptpages). Since QPOE files + can be very large it is necessary to allow control of this parameter + from within QPOE. (3/11) + +dev/hosts + Added Doug Geisler's machine kukita to all servers. (3/11/96 MJF) + +sys/fmtio/dtoc.x + Added some rounding to avoid printing numbers such as 12:29:60.0 + when formatting sexagesimal (HMS or MS) numbers. (3/12) + +sys/mwcs/iwewcs.x + Modified the code which computes the CD matrix from CDELT/CROTA. + The old code computed the diagonal (scale) terms correctly but the + rotation terms were evidently incorrect. The old code was based on + the 1988 Hanisch and Wells WCS paper and the new code is based on a + more recent paper by Mark Calabretta et. al. which supercedes the + 1988 representation. The affect of this change should be limited + as it only affects rotated images for which CDELT is given but no + CD matrix is defined. (3/13) + +pkg/images/tv/src/iecolon.x +pkg/images/tv/src/starfocus.h +pkg/images/tv/src/stfmeasure.x +pkg/images/tv/src/ierimexam.x +pkg/images/tv/rimexam.par +pkg/images/doc/imexamine.hlp +lib/scr/imexamine.key + The radial profile fitting and width measurements now have an option to + use a Gaussian or Moffat profile model. The model is selected by a + new "fittype" parameter. A new "beta" parameter may be specified as + INDEF to be determined from the fit or have a fixed value. The Moffat + profile model does better in producing consistent FWHM values so + this is the default. (3/16, Valdes) + +math/gsurfit/gsrestore.gx +math/gsurfit/gsrestorer.x +math/gsurfit/gsrestored.x + Changed the type declaration of the xmin, xmax, ymin, ymax variables + from real to PIXEL to avoid machine precision problems. (3/21 Davis) + +pkg/cl/builtin.c + Modified the clprintf code to support INDEF operands. (3/23) + +pkg/images/tv/imedit/epsearch.x +pkg/images/tv/imedit/epgcur.x + 1. The search algorithm produced incorrect results if part of the + aperture was off the edge (negative image coordinates). + 2. The rounding was incorrect when part of the aperture was off the + edge (negative image coordinates). + 3. A floating operand error occurs when a key is given without + coordinates. + (3/26, Valdes) + +pkg/plot/t_implot.x + When the vector being plotted was constant the 'l' and 'c' keys + selecting lines/columns from the right plot axis did not work. The + code was fixed for this case. (3/27, Valdes) + +pkg/images/geometry/xregister/rgxfit.x + Changed several Memr[] references to Memi[] in the rg_fit routine. + This type conversion bug was causing a floating point error + in the xregister task on the Dec Alpha machines if the coords file + was defined, and could potentially cause problems on other machines. + (Davis, April 3, 1996) + +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + Removed the type long variables gmtl, lstl and modified all calls to + localtime() so that the argument is of type time_t. This is standard + for all modern systems. Some older systems still require that the + argument be type long, but as this is nonstandard it should be + ifdef-ed in the source for these older systems. (4/04 1996) + +unix/hlib/libc/libc.h + The macros Memcptr and Memiptr included a "+ 1" which shouldn't have + been there. The one indexing correction was already being done in + the Memc/Memi macros and Memcptr/Memiptr take a zero indexed C pointer + as input. This was causing a bug in LIBC version of realloc, which + is not used anywhere in the IRAF system code. (4/05) + +pkg/images/tv/imexamine/ierimexam.x +pkg/images/tv/imexamine/stfmeasure.x + Fixed incorrect datatype declaration "real np" -> "int np" in various + related places. (4/9/96, Valdes) + +unix/os/zmain.c + Added a #ifdef SYSV conditional to change the calling sequence for + setpgrp() for SYSV and BSD systems. (4/24) + +sys/imio/iki/plf/plfopen.x + Fixed an imerr() call which had the wrong argument type. (5/06) + +sys/libc/realloc.c + Modified to work when called with a null pointer. (5/06) + +sys/gio/stdgraph/stgdrawch.x + The text drawing routines were not controlling the polyline width + when drawing characters in software mode using polylines. There is + no line width attribute for graphics text and we probably don't want + one, so the code was modified to force the line width to 1 when + drawing software characters. (5/10) + +unix/boot/bootlib/osgetenv.c + The envinit code calls _os_getenv to fetch the value of "pkglibs". + This code assumes that _os_getenv returns the string argument, but + nothing was being returned if the named environment variable was not + found. Changed it to return a NULL-terminated empty string in this + case. (5/10) + +sys/etc/mkpkg +sys/etc/onentry.x +sys/etc/main.x +unix/os/zmain.c + 1. The IRAF main (irafmn) was changed to an integer function and + modified to return an exit status. If a task aborts and the main + exits without running any more tasks (as when executing a task at + the host level where only a single task is run) then the error status + of the task is returned. In normal use as a connected process this + condition never occurs and the main always returns XOK as the status. + + 2. Several calls to sys_panic in various etc$ routines were modified + to ensure that a zero error code is not returned. sys_panic returns + the error code as the exit status of the process. + + 3. The process main (zmain.c) was modified to call IRAF_MAIN as an + integer function and to return its exit status. + 4. The call to exit() in zmain.c was changed to _exit(). (5/11) + +pkg/plot/t_graph.x +pkg/plot/graph.par +pkg/plot/doc/graph.hlp + Added parameters "ltypes" and "colors" to specify a list of line types + and colors when doing multiple data sets. (5/13, Valdes) + +---------------------------------------- +V2.10.4 patch 2 release. (5/22 1996) + +unix/boot/bootlib/envinit.c + Fixed a typo in some code that went "printf (stderr, ...)" (should be + fprintf), also changed following fflush to flush stderr. (5/27) + +unix/boot/bootlib/vfn2osfn.c + Deleted some unneeded semicolons from some stub routines, e.g. in + "KI_SEND(){};" the ; should not be there. (5/27) + +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/rpp/mkpkg.sh +unix/boot/xpp/mkpkg.sh +unix/boot/xyacc/mkpkg.sh + Replaced HSI_CF by HSI_LF in the link line (5/28) + +unix/hlib/irafuser.csh + Added a dummy definition of HSI_LF (not used in SunOS/IRAF but is + needed on other platforms). (5/28) + +unix/boot/rmfiles/mkpkg.sh + Added a (char *) declaration for vfn2osfn(). (5/28) + +pkg/cl/grammar.h +pkg/cl/globals.c + Added global definitions for parse_state, proc_script, and parse_pfile + to globals.c and modified grammar.h to define these as extern (found + with the IRIX 5.3 port). (6/03) + +pkg/obsolete/ - + The old (V2.9) IMCOMBINE task was removed. (6/14 FV) + +pkg/obsolete/t_fixpix.x + +pkg/obsolete/fixcol.gx + +pkg/obsolete/t_fixline.gx + +pkg/obsolete/ofixpix.par + +pkg/obsolete/doc/ofixpix.hlp + +pkg/obsolete/mkpkg +pkg/obsolete/x_obsolete.x +pkg/obsolete/obsolete.cl +pkg/obsolete/obsolete.hd +pkg/obsolete/obsolete.men + Moved the V2.10.4 version of PROTO.FIXPIX to OBSOLETE and renamed + it to OFIXPIX. (6/14 FV) + +pkg/proto/generic/ + +pkg/proto/imfunc.x -> generic/ +pkg/proto/imrep.x -> generic/ + Added a generic directory for generic files. The generic procedures + imfunc.x and imrep.x are now in this directory. (6/14 FV) + +pkg/proto/t_fixpix.x +pkg/proto/fpfixpix.gx +pkg/proto/fixpix.par +pkg/proto/text2mask.par + +pkg/proto/t_text2mask.x + +pkg/proto/t_mask2text.x + +pkg/proto/doc/fixpix.hlp +pkg/proto/doc/text2mask.hlp + +pkg/proto/mkpkg +pkg/proto/x_proto.x +pkg/proto/proto.cl +pkg/proto/proto.hd +pkg/proto/proto.men + Replaced the old version of FIXPIX by a new version that works with + mask images. Two new tasks were also added, TEXT2MASK and + MASK2TEXT, that convert from the old text file description to mask + images and back. The MASK2TEXT task is hidden to discourage + continued use of the text file description. (6/14 FV) + +unix/boot/spp/xc.c + Fixed a couple bugs in the PKGENV processing code. (7/05) + +doc/ports/notes.irix + + Installed the notes file from the IRIX 5.3 port. (7/07) + +unix/os/irafpath.c + Added entries for Solaris, Linux, FreeBSD. (7/17) + +unix/os/zfaloc.c +unix/os/zfiobf.c + Changed type of lseek() to off_f. (7/17) + +unix/boot/spp/xpp/xppcode.c + Changed warn() to a static function. (7/17) + +mkpkg +noao/mkpkg + Added an entry for the "freebsd" architecture. (7/17) + +pkg/images/filters/median.x + The routine mde_yefilter was being called with too many arguments. + (7/18 LED) + +pkg/xtools/inlfit/ingresults.gx + Changed several INDEFR references to INDEF references so that INDEF + as the correct data type (real or double) in the output .x files. + (7/18 LED) + +sys/gio/fpequald.x +sys/gio/fpequalr.x + Backed off the tolerance slightly, from 10*EPSILON to 32*EPSILON. + (7/25) + +sys/imfort/bfio.x + In zfaloc, the first arg to strpak was changed from fname (a Fortran + character variable which was incorrect) to sppname. (7/17(26)) + +pkg/images/imarith/icsort.gx + There was an error in the ic_2sort routine when there are exactly + three images that one of the explicit cases did not properly keep + the image identifications. See buglog 344. (8/1 FV) + +dev/hosts + Revised the list of Kitt Peak hosts. (8/7 RLS) + +pkg/proto/fields.par +pkg/proto/doc/fields.hlp + Changed the default lines in FIELDS to an open upper limit. (8/22 FV) + +pkg/images/tv/imexamine/stfmeasure.x + Fixed bug in evaluation of enclosed flux profile in which the scaled + radius was used for the gaussian subtraction stage instead of pixels. + This does not currently affect IMEXAM because the scale is fixed + at 1. (8/29, FV) + +unix/os/zfnbrk.c + Modified this routine to ignore file or directory characters other + than those it considers to be file or directory name delimiters. + On platforms that permit it, the effect is to permit characters (such + as + and -) in filenames other than simple identifier characters. + There is no expectation at this point however that all IRAF code will + permit this. (9/03) + +dev/hosts + Updated the hosts file on all Tucson servers for rainbow, Jim + Deveny's new Sun. (9/10/96 jb) + +pkg/system/phelp.cl + Modified to copy the "template" argument into a local variable since + it is referenced twice in the script. (10/10) + +sys/fio/fioclean.x + The file descriptor was being accessed after the file had been + closed. (10/11) + +unix/os/zfiond.c + Added a ":" field to the ND network driver. The only protocol + flags currently supported are "text" and "binary". If "text" is + specified then the datastream is assumed to consist of byte packed + ascii text, and the driver will automatically convert to and from + SPP chars during i/o. (10/29) + +sys/fio/zzdebug.x + Added a new debug task "http". Given a hostname and a HTTPD-root + relative file path the task will connect to the HTTP server on the + given host and fetch the file at the given path. The output + consists of the HTTP/1.0 protocol header followed by a blank line + and the contents of the requested file. (10/29) + +pkg/images/tv/wcslab/t_wcslab.x +pkg/images/tv/doc/wcslab.hlp + Added an "overplot" option to append to a plot but with a different + viewport. (11/06/96 Valdes) + +pkg/images/imarith/t_imcombine.x +pkg/images/imarith/icombine.gx + Changed the error checking to catch additional errors relating to too + many files. (11/12/96, Valdes) + +dev/hosts + Added driftwood to all downtown servers. (11/18/96 MJF) + +dev/hosts + Updated block of KPNO hosts on solaris tree on Gemini. + This was up to date on development system. (11/19/96 RLS) + +sys/fmtio/sscan.x +sys/fmtio/fscan.x +sys/fmtio/clscan.x +sys/fmtio/scan.com + Modified scan.com to dimension scanbuf locally as SZ_SCANBUF instead of + SZ_COMMAND, in the process increasing the size from 1024 to 4096. + Modified sscan to check for overflow of the scan buffer. (11/19) + +sys/ki/ki.h + Increased maximum network hosts in the in-core host table from 128 to + 256. (11/21) + +pkg/images/tv/imedit/epgsfit.x +pkg/images/tv/imedit/epcolon.x +pkg/images/tv/doc/imedit.hlp +pkg/images/tv/imedit/imedit.par + Added a median background if the xorder or yorder is zero. + (11/22/96 Valdes) + +dev/hosts + Cleaned up the hosts table: Deleted + adonis aldebaran auriga + columba crater irafdemo + libra noctua octans + omega serpens suntest + verdi vela + Fixed path names for mytoy and scorpius (11/21/96 MJF) + +pkg/images/imarith/icsetout.x +pkg/images/doc/imcombine.hlp + A new option for computing offsets from the image WCS has been added. + (11/30/96 Valdes) + +pkg/images/tv/display/sigm2.x + + Added a version of the spatial interpolation routines that allows masks + to interpolate the input across bad pixels. (12/5/96, Valdes) + +pkg/images/tv/display/t_display.x + 1. Fixed numerous problems with the coordinate system. + 2. Fixed a bug in how ztrans=log was done. + (12/5/96, Valdes) + +pkg/images/tv/display/iishdr.x +pkg/images/tv/display/iisers.x + Replaces SPP int -> short assignments by calls to achtiu because of + overflow problems with some VMS fortran compilers. + (12/6/96, Valdes as reported by Zarate) + +pkg/images/tv/display/imdmapfr.x +pkg/images/tv/display/imdputwcs.x + + Added two routines to hide knowledge of the channel structure and + other details from the calling routines. (12/11/96, Valdes) + +dev/hosts + Changed hohokam to ssun, updated all servers w/ master copy from + tucana to remove hosts and fix /gemini path names. (1/7/97 MJF) + +dev/hosts + Changed the following SWN machines to bin.ssun: + aquarius aten bokchoy + carina (new) hedgehog herbie + inti mdi potosi + soi soleil + Updated all servers. (1/15/97 MJF) + +pkg/xtools/dttext.x + Added the routine dtgetd to the text database package. (1/16/97 LED) + +dev/hosts + Changed norma to a solaris box. (1/24/97 MJF) + +unix/boot/bootlib/osfiletype.c + Added several entries for files considered to be "source" files. + These include .pl, .gif, .jpeg, and .tiff (.fits is already present). + There are cases where it may make sense to include these files in + the machine indendent source tree, e.g. for small test data files + or for online help. (1/11) 1997 + +dev/hosts + Added George's linux box aloe to all servers. (2/13/97 MJF) + +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c + The recent change of warn() to static in xppcode.c caused a problem + as warn is also used in decl.c. Changed warn() back to an external + function but changed the name to xpp_warn to avoid whatever the + platform-specific problem was that resulted in the original fix + (probably warn was an internal function in some platform system + library). (3/03) + +sys/mwcs/wfmspec.x + On line 327, changed din=log10(in[1]) to din=log10(din). (3/04) + +-------------------------------- +Did a diff/merge of recent tucana HSI changes into the Solaris/IRAF HSI. +Replaced the "unix" directory on tucana SunOS/IRAF by the version from +Solaris/IRAF. This HSI is supposed to work for both SunOS and Solaris +(SunOS compatibility was preserved but never tested during the Solaris/IRAF +port). Did a bootstrap and sysgen under both SunOS and Solaris. + +Mounted tucana iraf.develop as iraf.develop on Data. tucana iraf (irafx) +is now solaris/iraf as well as sunos/iraf, they are the same thing. One +benefit of this is that irafx is now available on solaris systems in the +building (although we do have to update the ssun binaries periodically or +it does no one any good). A complication is that since we have to update +the ssun binaries, it is now more likely that the architecture may be set +to something other than sparc. (3/19 1997) + +local/.cshrc +local/.login + Modified to work for both SunOS and Solaris. (3/19) + +unix/as.sparc/enbint.s + This file from Solaris/IRAF isn't used by SunOS/IRAF, but it is + probably better to provide it in the library than to add conditionals + to the build files in OS. (3/19) + +unix/boot/bootlib/osfiletype.c +unix/boot/bootlib/vfn2osfn.c +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c +unix/hlib/libc/kernel.h +unix/os/irafpath.c +unix/os/zfaloc.c +unix/os/zfiobf.c +unix/os/zfiomt.c +unix/os/zfiond.c +unix/os/zlocpr.c +unix/os/zzstrt.c + Assorted minor changes to make these files work for both SunOS + and Solaris. (3/19) + +unix/shlib/medit.c +unix/shlib/mkpkg +unix/shlib/mkpkg.sh +unix/shlib/mkshlib.sos4 +unix/shlib/mkshlib.ssol +unix/shlib/mkshlib.ssol-sc34 + Various file modifications and file name changes to make shlib + build for both SunOS and Solaris. (3/19) + +pkg/math/curfit/cvacpts.gx +pkg/math/curfit/cvacptsr.x +pkg/math/curfit/cvacptsd.x +pkg/math/curfit/doc/cvpower.hlp +pkg/math/curfit/cvpower.gx +pkg/math/curfit/cvpowerr.x +pkg/math/curfit/cvpowerd.x + The weights computed by the WTS_CHISQ option in the routines + cvacpts[rd] were not being forced to be positive as intended. (3/20) + + There was an inconsistency in the way the ncoeff argument to the + cvpower[rd] routines was being used internally. Ncoeff was intended + to be an output argument but was being used as an input argument by + one of the routines called by cvpower. (3/20) + +sys/mtio/mtgtyopen.x + MTIO was modified to add support for server-specific tapecap files. + When opening the tapecap file MTIO will now look for "tapecap." + followed by the default "tapecap". should be the hostname + (as used by IRAF networking) of the server hosting the tape drives + described by the tapecap file. For example if host "gemini" serves + up some tape drives it's tapecap file is named "tapecap.gemini". + If a server-specific tapecap file is not found the default "tapecap" + (on the possibly remote server node) is used. This feature allows + a single IRAF installation to be shared by multiple servers. (3/21) + +dev/README +dev/tapecap.sunos + +dev/tapecap.solaris + + Since the Sun/IRAF DEV is now shared by both SunOS and Solaris it + now contains the template tapecap files for both systems. The README + in DEV contains some pointers on configuring tapecap and other device + files. (3/21) + +pkg/images/tv/display.par +pkg/images/tv/display/t_display.x +pkg/images/tv/display/zscale.x +pkg/images/tv/display/sigm2.x + +pkg/images/tv/display/maskcolor.x + +pkg/images/tv/display/dspmmap.x + +pkg/images/tv/display/display.h +pkg/images/tv/display/gwindow.h +pkg/images/tv/display/mkpkg +pkg/images/tv/doc/display.hlp + 1. Improved the structure of DISPLAY. + 2. Fixed coordinate system errors. + 3. Added parameters to display bad pixel masks and overlay masks. + 4. The z scaling sampling may use a pixel mask or image section. + 5. The z scaling excludes bad pixels. + (3/20, Valdes) + +-------------------------------- +The following series of revisions were made to increase the size of various +system buffers. This included a full system reboot and recompile. (3/24) + +lib/fio.h +sys/fio/vfnmap.x +sys/fio/vfntrans.x + Various buffer sizes affecting filename mapping were increased. + SZ_VFNFN (max length of the root field of a VFN) went from 32 -> 127. + SZ_OSDIR (max length of the osdir field of a VFN) from 79 -> 255. + SZ_FFNAME, an internal filename buffer, went from 127 -> 255. + In an unrelated change SZ_SPOOLBUF, the intial size of a spool + buffer, was increased from 1024 to 4096. (3/23) + +unix/hlib/config.h + 1. MAX_ROOTLEN was increased from 32 to 128. This is supposed to be the + limit the host system places on the root portion of a filename (that + is, only the root name, not the pathname). Anything in the range + 128-256 is typical for unix systems today. + 2. The maximum number of open VOS files was increased from 128 -> 256. + (3/23) + +sys/fio/fntgfn.x + SZ_PATTERN, SZ_TEMPLATE, SZ_LDIR, SZ_PATSTR were all increased, + although so far as I know there has never been a case of pattern + buffers overflowing. The new limit for a pattern string is about + 1024. (3/23) + +unix/hlib/iraf.h + SZ_FNAME went from 63 -> 255. + SZ_PATHNAME went from 127 -> 511. + SZ_LINE went from 161 -> 1023. + SZ_COMMAND went from 1024 -> 2047. (3/23) + +unix/hlib/iraf.h +unix/hlib/mach.h + MAX_EXPONENTD went from 38 (same as real) to 308, the value for + IEEE double. MAX_DOUBLE increased from 0.99d37 to 0.99d307. + INDEFD was changed from 1.6d38 to 1.6d308 for IEEE systems. (3/23) + +unix/hlib/libc/libc.h +unix/hlib/libc/spp.h + FIO_MAXFD, INDEFD, SZ_LINE, SZ_FNAME, SZ_PATHNAME, SZ_COMMAND were + updated to agree with the SPP values. (3/23) + +sys/imio/iki/stf/stfrdhdr.x + Unrelated STF bug fix. stfrdhdr.x was modified to handle the case + where datamin/datamax were not defined in the GPB, but were defined + in the main image header. (3/24) + +unix/boot/spp/xpp/xppmain.c + Removed a redundant SZ_PATHNAME. (3/24) + +unix/shlib/mkpkg +unix/shlib/mkshlib.sos4 + Changed the address of the shared library from 0xa000000 to 0x10000000. + This increases the maximum available per-process dynamic memory from + 167 MB to 268 MB (much more is possible if the process is statically + linked). (3/24) + +unix/os/zzstrt.c + Changed some address-related ints to unsigned just to be safe. (3/24) + +sys/etc/pagefiles.x + Increased SZ_LONGLINE from 1024 to 4096. At 1024 it was the same as + the new SZ_LINE, causing a loop test to fail. (3/25) + +pkg/images/tv/rimexam.par +pkg/images/tv/doc/rimexam.par + Changed the zero point of the magnitude scale from 30.0 to 25.0 + for the sake of consistency with other photometry tasks. (3/31, LED) + +pkg/images/tv/imexamine/ierimexam.x + The log output for 'a' or 'r' has one line per measurement as in + previous versions. The standard output, however, uses two lines to + print nicely on 80 column windows. (3/31, FV) + +pkg/dataio/mkpkg +pkg/dataio/dataio.cl +pkg/dataio/dataio.hd +pkg/dataio/dataio.men +pkg/dataio/x_dataio.x +pkg/dataio/import/ + +pkg/dataio/import.par + +pkg/dataio/export/ + +pkg/dataio/export.par + +pkg/dataio/doc/import.hlp + +pkg/dataio/doc/export.hlp + + Installed the IMPORT/EXPORT task for general use. The images database + used by the IMPORT task is currently defined to be stored in + dataio$import/images.dat. (3/31/97 MJF) + +pkg/proto/proto.cl +pkg/proto/proto.men +pkg/proto/proto.hd +pkg/proto/x_proto.x +pkg/proto/mkpkg + The tasks imalign, imcentroid, imfunction, imreplace, wcsedit, and + wcsreset have been deleted from the proto package and moved to the + reorganized images package. (3/31/97 LED) + +lib/imhdr.h +lib/imio.h + The sizes of the pixel file, header file, title and imhistory strings + were increased. Defines were added for the image header file and + pixel file "magic' strings. A couple fields were added relating to + byte swapping. IM_SWAPPED, in the image header, tells whether the + pixels in the disk image are byte swapped. (3/31) + +sys/imio/iki/oif/imhv1.h +sys/imio/iki/oif/imhv2.h +sys/imio/iki/oif/mkpkg +sys/imio/iki/oif/oif.h +sys/imio/iki/oif/oifmkpfn.x +sys/imio/iki/oif/oifopen.x +sys/imio/iki/oif/oifopix.x +sys/imio/iki/oif/oifrdhdr.x + +sys/imio/iki/oif/oifupdhdr.x +sys/imio/iki/oif/oifwrhdr.x + +sys/imio/iki/oif/oifwphdr.x - + It was necessary to change the OIF kernel to increase the maximum + path length for header and pixel files. This made it necessary to + change the disk image format, since the old format only allowed 80 + characters for the pixel file pathname. In the process reading and + writing the disk header was separated out from the in-memory + header. Support for two versions of the image and pixel file + headers were added. The "magic" string in the image or pixel file + header identifies the version. Old (version 1) image headers have + "imhdr" at the head of the file, with the string in SPP chars. The + new (version 2) headers have "imhv2" as the magic string. V2 headers + are byte packed and machine independent. The path limit is 255. + (3/31) + +sys/imio/immaky.x +sys/imio/imrdpx.x +sys/imio/imwrpx.x + 1. Support was added for byte swapping pixels. With the machine + independent V2 image header, this allows .imh images to be read on + any node (integer) or any IEEE-compatible node (floating). The + pixels are written in the native swap order of the creating host, + but the order is recorded in the IM_SWAPPED field of the image header, + and IMIO uses this to determine whether or not the pixels need to + be byte swapped during i/o. + 2. Minor changes to trim junk data after EOS delimited strings. + Since the V2 headers are byte packed the string data in these headers + can be viewed with Unix tools such as "less" and "strings". (3/31) + + Some pointers: "strings foo.imh" (or other tools like less) can be + used at the Unix level to look at V2 image headers. New images are + always written with host-native binary format pixels, so there is no + byte swapping involved for images read and written on the same + host. Images can any other (IEEE) host can be read or written but + there may be some slight overhead for byteswapping. If the image is + rewritten however using imcopy, the bytes will be swapped to the + native ordering of the new host. + +pkg/images/imutil/src/imheader.x + The only change so far was to eliminate some histogram dependence, + since this unused feature was removed from the standard IMIO in-memory + image header. (3/31) + +dev/pix.imh +dev/pix.pix +dev/wpix.imh + Regenerated using the V2 image format. (3/31) + +lib/imio.h +sys/imio/immapz.x +sys/imio/immaky.x +unix/hlib/zzsetenv.def +unix/hlib/login.cl + Increased the default size of the user area (min_lenuserarea) to + 64000 (about 800 80 char cards). There was some ambiguity about + units for min_lenuserarea; it should be consistently chars now. + Also increased the "padding" added to the header when creating a + new copy of an existing image which has a large header. (4/01) + +sys/imio/immaky.x + When the header of an old image is copied during an open-new-copy, + IMIO now recomputes the length of the user area of the input header. + Formerly if the header had grown since the image was opened, the + added data could be lost in a subsquent new-copy operation. (4/01) + +sys/etc/oscmd.x + Changed an fclobber(outfile) to fclobber(errfile). (4/02) + +sys/imfort/bfio.x + The little Fortran-callable file i/o package BFIO used in IMFORT + was enhanced to support writing and reading of fractional file blocks + so that files can be any size. The default random and sequential + buffer sizes were increased. In addition to the old random access + i/o routines bfread/bfwrite there are now sequential i/o routines + bfseek/bfrseq/bfwseq. (4/02) + +sys/imfort/mkpkg +sys/imfort/imfort.h +sys/imfort/imhv1.h + +sys/imfort/imhv2.h + +sys/imfort/oif.h +sys/imfort/imcrex.x +sys/imfort/imfgpfn.x +sys/imfort/imfupdhdr.x +sys/imfort/imgl1r.x +sys/imfort/imgl1s.x +sys/imfort/imgl2r.x +sys/imfort/imgl2s.x +sys/imfort/imgl3r.x +sys/imfort/imgl3s.x +sys/imfort/imgs1r.x +sys/imfort/imgs1s.x +sys/imfort/imgs2r.x +sys/imfort/imgs2s.x +sys/imfort/imgs3r.x +sys/imfort/imgs3s.x +sys/imfort/imopnx.x +sys/imfort/impl1r.x +sys/imfort/impl1s.x +sys/imfort/impl2r.x +sys/imfort/impl2s.x +sys/imfort/impl3r.x +sys/imfort/impl3s.x +sys/imfort/imps1r.x +sys/imfort/imps1s.x +sys/imfort/imps2r.x +sys/imfort/imps2s.x +sys/imfort/imps3r.x +sys/imfort/imps3s.x +sys/imfort/imrdhdr.x + +sys/imfort/imswap.x + +sys/imfort/imwpix.x + +sys/imfort/imwrhdr.x + + 1. IMFORT was brought up to date with IMIO to read and write the new + version 2 ".imh" images. As with IMIO, the old V1 format is still + supported but new images are written using the new machine independent + V2 format. + 2. Image headers can now be any size (the old IMFORT had a very + strict limit on the image header size). Since BFIO now writes partial + blocks, headers are no longer blocked out to 32768 bytes. + 3. "min_lenuserarea" is now supported as for IMIO (since IMFORT is + host level it must be defined in the host environment). The builtin + default header buffer is 64000 chars, which is about 800 card images. + (4/02) + +sys/imfort/mii.x + + A version of the MII routines mii{read,write}[silrc] modified to + use BFIO was added to IMFORT. These are used to read and write the + machine independent headers. (4/02) + +dev/hosts + Aliased 'kf' for kingfisher at Al Fowler's request (4/3 MJF) + +lib/qpioset.h +lib/syserrmsg +sys/qpoe/qpio.h +sys/qpoe/qpoe.h +sys/qpoe/qpiogetev.x +sys/qpoe/qpiogetfil.x +sys/qpoe/qpiomkidx.x +sys/qpoe/qpioopen.x +sys/qpoe/qpioparse.x +sys/qpoe/qpiorpix.gx +sys/qpoe/qpioseti.x +sys/qpoe/qpiostati.x +sys/qpoe/qpiosync.x + QPOE was modified to allow event coordinate (X,Y) key fields to be + of type int as well as short. All event handling code will now + accept either type. Keys may be specified using "i" as the field + type as well as "s", e.g. "key=(i10,s14)". X and Y do not have to + be the same type. There should be no significant CPU runtime + penalty, although obviously events with integer coordinate fields + will mean larger event files (file i/o times will be affected + accordingly). (4/03) + +lib/qpioset.h +lib/qpset.h +sys/qpoe/QPOE.hlp +sys/qpoe/README +sys/qpoe/qpcopyf.x +sys/qpoe/qpio.h +sys/qpoe/qpiogetfil.x +sys/qpoe/qpiolwcs.x +sys/qpoe/qpioopen.x +sys/qpoe/qpioparse.x +sys/qpoe/qpioseti.x +sys/qpoe/qpiostati.x +sys/qpoe/qpmacro.x +sys/qpoe/qpoe.h +sys/qpoe/qpopen.x +sys/qpoe/qpqueryf.x +sys/qpoe/qpseti.x +sys/qpoe/qpstati.x +sys/qpoe/zzdebug.x + Added support for separate X and Y blocking factors. The "block" + parameter is still recognized as before and will set both the X and + Y blocking factors, or "xblock" and "yblock" can be used to set only + one or the other. All occurrences have been updated, including + expressions, the QPDEFS environment, and qp_set qpio_set. (4/04) + +sys/qpoe/qpiorpix.gx + [INTERFACE CHANGE] + The calling sequence for qpio_readpix was modified to replace the + "block" argument by the two arguments xblock and yblock. A scan + indicates that none of the layered packages we have installed at + NOAO (including xray) currently uses this routine. (4/04) + +sys/plio/plrio.x + The plrio package provides an efficient lookup-table-based means of + randomly sampling 2D pixel masks. The code which recursively divides + a region into 4 quadrants could fail if the region being subdivided + was 1 pixel wide in either axis. If this happens 2 of the "quadrants" + will be valid and 2 will be degenerate. Added a test to detect and + discard these degenerate subregions. (4/04) + +sys/plio/plsectne.x +sys/plio/plsectnc.x + Both of these routines had a bug that could prevent them from + examining the full region requested (the routines check for section + not empty and section not constant). Line lists are segmented in + segments of at most I_DATAMAX (4095) pixels. If the mask is large + and has large regions of constant value, the list will consist of + successive segments all at the same value. The routines were only + checking the first such segment. The corrected code reads successive + segments until all the pixels in the region have been examined. (4/04) + +sys/plio/zzdebug.x + Fixed a couple of bugs and added several new routines to test the + above fixes. SECNE and SECNC test pl_sectnotempty and pl_sectnotconst. + RIO tests plrio random mask access. INVERT inverts a mask. (4/04) + +sys/imio/implhdr.x + These routines, which copy an image header to and from an encoded title + string in a PLIO save file, were modified to save the ctime, mtime, + limtime, minpixval, and maxpixval static fields of the image header + in addition to the title string. (4/04) + +sys/qpoe/qpexeval.x + The value of "pass" was not being initialized before starting + subprogram execution when evaluating a complex LUT bin. Added the + initialization and also some comments giving an overview of how the + evaluation is performed (since it took me several hours to figure + this out again). (4/04) + +sys/imio/iki/qpf/qpfcopypar.x +sys/imio/iki/qpf/zfioqp.x +sys/imio/iki/qpf/qpfopen.x +sys/imio/iki/qpf/qpf.h + Modified to support separate x and y blocking factors. (4/05) + +sys/plio/plupdate.x + This routine contains code which collapses successive mask lines + in Y to a single encoded mask line if the mask lines are equal, + thereby compressing the encoded mask in Y. The encoded mask lines + are encoded in short integer arrays and a multiply referenced + line has a reference count which is stored in a short integer field. + The code was modified to stop when this counter reaches MAX_SHORT, + adding a new line to the encoded mask and starting over. Combined + with the X segmentation of lines into blocks of at most 4095 pixels, + this should allow masks to be nearly any size despite the use of + short integers for the encoding. (4/05) + +sys/qpoe/qpiolwcs.x + Modified the LTV_2 term of the logical transformation to set the + fractional pixel zero point resulting from blocking the input data. + If for example 2 input pixels map to 1 on output, the range of the + output pixel (e.g. 0.5 to 1.5) maps to the range covered by the two + input pixels (e.g. 0.5 to 2.5), and the center of the output pixel + (e.g. x = 1.0) maps to the center of the range spanned by the input + pixels (e.g. 1.5). For 3 to 1, 1.0 maps back to 2.0 in the input, + for 4 to 1, 1.0 maps back to 2.5, and so on as (block+1)/2. (4/05) diff --git a/doc/notes.v211 b/doc/notes.v211 new file mode 100644 index 00000000..4e5b8e98 --- /dev/null +++ b/doc/notes.v211 @@ -0,0 +1,7769 @@ +System Notes File for IRAF Version 2.11. +Begun 12 June 1995. +------------------------------------------- + +unix/hlib/motd +unix/hlib/zzsetenv.def + Develop system version number incremented to V2.11. (6/12) + +pkg/images/geometry/t_geotran.x +pkg/images/geometry/geotran.x +pkg/images/geometry/geotimtran.x + Fixed a bug in the buffering of the x and y coordinate surface + interpolants which can cause a memory corruption error if, the + nxsample or nysample parameters are > 1, and the nxblock or nyblock + parameters are less than the x and y dimensions of the input image. + Took the opportunity to clean up the code. (6/13/95, LED) + + +pkg/math/curfit/cvpower.gx +pkg/math/curfit/cvpowerr.x +pkg/math/curfit/cvpowerd.x +pkg/math/curfit/doc/curfit.hd +pkg/math/curfit/doc/curfit.men +pkg/math/curfit/doc/cvepower.hlp + Added the new routine cvepower to the curfit math library. Cvepower + computes the errors in the power series coefficients equivalent + to the fitted Legendre and Chebyshev coefficients. Cvepower is + available in both real and double precision versions. (6/13/95, LED) + + +pkg/images/fmedian.hlp +pkg/images/fmode.hlp +pkg/images/median.hlp +pkg/images/mode.hlp +pkg/images/fmedian.par +pkg/images/fmode.par +pkg/images/median.par +pkg/images/mode.par +pkg/images/filters/fmedian.h +pkg/images/filters/fmode.h +pkg/images/filters/median.h +pkg/images/filters/mode.h +pkg/images/filters/t_fmedian.x +pkg/images/filters/t_fmode.x +pkg/images/filters/t_median.x +pkg/images/filters/t_mode.x +pkg/images/filters/fmedian.x +pkg/images/filters/fmode.x +pkg/images/filters/median.x +pkg/images/filters/mode.x +pkg/images/filters/fmd_buf.x +pkg/images/filters/fmd_hist.x +pkg/images/filters/fmd_maxmin.x +pkg/images/filters/med_buf.x +pkg/images/filters/med_sort.x + Added minimum and maximum good data parameters to the fmedian, fmode, + median, and mode filtering tasks. Removed the 64X64 kernel size limit + in the median and mode tasks. Replaced the common blocks with + structures and .h files. (6/20/95, LED) + +pkg/images/frmedian.hlp +pkg/images/frmode.hlp +pkg/images/rmedian.hlp +pkg/images/rmode.hlp +pkg/images/frmedian.par +pkg/images/frmode.par +pkg/images/rmedian.par +pkg/images/rmode.par +pkg/images/filters/frmedian.h +pkg/images/filters/frmode.h +pkg/images/filters/rmedian.h +pkg/images/filters/rmode.h +pkg/images/filters/t_frmedian.x +pkg/images/filters/t_frmode.x +pkg/images/filters/t_rmedian.x +pkg/images/filters/t_rmode.x +pkg/images/filters/frmedian.x +pkg/images/filters/frmode.x +pkg/images/filters/rmedian.x +pkg/images/filters/rmode.x +pkg/images/filters/med_utils.x + Added new ring median and modal filtering tasks frmedian, rmedian, + frmode, and rmode to the images package. (6/20/95, LED) + +doc/ports/notes.osf1 + + Added notes file from DEC Alpha OSF/1 port. (6/21) + +sys/fio/fioclean.x +sys/fio/stropen.x + Two new internal routines str{set,get}mode were added to stropen.x. + These are used to set or query the file access mode as stored for + the string file, which represents these in a file-dependent way. + fio_cleanup was modified to force the access mode of a string file + to READ_ONLY before closing it during file cleanup, to prevent the + writing of the trailing EOS when closing a string file opened for + writing. The latter could cause a segmentation violation if the + string buffer was no longer in a mapped region of memory, as is + possible if the string file is still open (i.e. not closed normally) + following task termination when fio_cleanup is called. This problem + was found when testing the OSF/1 version of IRAF. (6/21, merged from + OSF1 revision of 6/06) + +dev/termcap + Added "lp" as an alias for "lpr". (6/26) + +dev/hosts + Added solstice to the downtown servers (tucana,ursa,gemini,orion,bigx) + at Ed Anderson's request (6/26 RLS) + +unix/hlib/mkpkg + Changed "mkshlib.csh" references to "./mkshlib.csh" to make the + script more robust in cases where the user has the path screwed + up. (7/03) + +dev/tapecap + Added support for device mtc|mtcc for BIGX, an HPDAT drive using the + ST driver. Also generic device st-hpdat, the HPDAT on ST. (7/18) + +dev/hosts + Added aten, volans, & musca to all servers, deleted vegemite (7/18 MJF) + +dev/hosts + Added soleil to all downtown server at Ed Anderson's request. (7/27 MJF) + +sys/fmtio/strdic.x + Was not ignoring leading whitespace on the string to be tested, when + computing the length "len" of the string. (7/31) + +pkg/proto/t_wcsreset.x + Added an error check to the mw_openim command so wcsreset can erase + the world coordinate systems of images with wcss that it cannot + read correctly. (1/8/95, Davis) + +pkg/xtools/inlfit/incopy.gx +pkg/xtools/inlfit/incopyr.x +pkg/xtools/inlfit/incopyd.x + Changed 4 MEMP (Memi) references to Mem$t references. (02/8/95, Davis) + +dev/tapecap + Modified gemini entry to change WangDat to an HP drive. (8/10) + +sys/fio/zzdebug.x + Replaced the t_ndopen debug task by a more recent version. (8/28) + +lib/gio.h +sys/gio/gplcache.x +sys/gio/gctran.x + The WCS transformation caching mechanism used in gctran was not + reliable and could fail in some cases where the WCS was changed more + frequently than gctran was called. To make caching of WCS related + information more robust a new field GP_WCSORD was added to the GIO + descriptor. This is set to a unique integer ordinal when a WCS is + fixed. If the ordinal changes any routines that cache WCS information + should invalidate their cache (unless they cache it on the basis of + WCSORD). WCSORD will differ for WCS stored in different graphics + descriptors, so testing WCSORD also does an implicit test that the + GP has changed. (8/28) + +sys/mwcs/iwewcs.x + Modified so that if an image contains a partial Lterm consisiting + of an LTV but no LTM, the missing LTM will default to the identity + matrix instead of the zero matrix (the latter causes a segvio if you + try to invert it). An image with a zero LTM is illegal but MWCS + should not die with a segvio in this case. (8/29) + +sys/imio/immaky.x +sys/imio/mkpkg + When copying an image section IMIO will call MWCS to update the Lterm + of the output image. This requires that it load any existing WCS + so that it can be modified and written out to the output image. IMIO + was modified to put the mw_open in an iferr block, printing a warning + message if the WCS cannot be loaded, rather than aborting the immap. + Aborting means that all IRAF imaging tasks fails to access the image + if it contains a WCS of a type not supported by IMIO. (8/29) + +sys/mwcs/iwgbfits.x + The code which reads in multiline FITS strings (WATi_j etc.) would + always read 68 characters per card. This was changed to read at + most 68 characters, terminating if newline, EOS, or a single closing + quote is seen in the input data. This allows the string on a line to + be less than 68 characters. It also avoids a bug seen with non-blocked + headers where the cards may contain less than 80 characters. (8/29) + +sys/mwcs/iwpstr.x + The final card of a multi-card string is no longer blank filled, i.e. + the closing quote will appear at the end of the string instead of in + column 80. (8/30) + +sys/mwcs/mwsaveim.x + The code which puts spaces between a sequence of attribute=value + keywords in a WCS attribute list was improved to avoid an unnecessary + space at the end of the list (spaces are now only used between the + members of the list). (8/30) + +sys/imio/db/impstr.x + When writing a string valued parameter the code checks for a trailing + quote and tries to add one if it is missing. The closing quote is + omitted if it would overwrite a data character - it isn't required + when reading cards unless the string ends before column 80. (8/30) + +sys/mwcs/mwsave.x + The DBUF offset in the save header was not being aligned to double. + (8/30) + +------------------------------------- +V2.10.4 patch 1 generated. (8/30) + +doc/rev2.hlp + Renamed this file to rev2.txt, it is not a help file. (9/03) + +unix/boot/bootlib/osfiletype.c + Added ".gz" to the list of "source" file types. Also added ".fit" + as an alias for ".fits". (9/03) + +mkpkg +noao/mkpkg + Added entries for linux and linuz architectures. (9/06) + +unix/hlib/strip.iraf +noao/lib/strip.noao + Replaced by updated versions, some files moved around and others + have been added. (9/06) + +local/.cshrc + Added "." and moved /usr/lang up in the hierarchy. (9/21) + +hlib/extern.pkg + Added the helpdb for the finder package on gemini and ursa. The + package is still loaded through the nlocal package. (10/12 RLS) + +sys/mwcs/imwcs.h + CROTA was being stored internally as an integer, causing small + truncation errors of non-integral rotational angles. (10/18) + +dev/graphcap +dev/imtoolrc + Added a new 8192x8192 frame buffer (imt7|imt8192). Redefined the + old imt7 (imt4x1) as imt19. (11/01) + +pkg/images/tv/imexamine/ierimexam.x +pkg/images/tv/imexamine/stfmeasure.x + +pkg/images/tv/imexamine/starfocus.h + +pkg/images/tv/imexamine/mkpkg +pkg/images/tv/doc/imexamine.hlp +lib/src/imexamine.key + New FWHM estimates based on the enclosed flux and a direct + measurement were added to the 'a' and 'r' keys. The weights for + the Gaussian fit were modified to reduce the influence of pixels + outside the half-maximum radius. The ? help and help page were + revised to described the new output and algorithms. (11/09) + +dev/hosts + Added 'inti' to all downtown servers. (11/20 MJF) + +pkg/images/median.par +pkg/images/rmedian.par +pkg/images/mode.par +pkg/images/rmode.par +pkg/images/fmedian.par +pkg/images/frmedian.par +pkg/images/fmode.par +pkg/images/frmode.par +pkg/images/doc/median.hlp +pkg/images/doc/rmedian.hlp +pkg/images/doc/mode.hlp +pkg/images/doc/rmode.hlp +pkg/images/doc/fmedian.hlp +pkg/images/doc/frmedian.hlp +pkg/images/doc/fmode.hlp +pkg/images/doc/frmode.hlp +pkg/images/filters/t_median.x +pkg/images/filters/t_rmedian.x +pkg/images/filters/t_mode.x +pkg/images/filters/t_rmode.x +pkg/images/filters/t_fmedian.x +pkg/images/filters/t_frmedian.x +pkg/images/filters/t_fmode.x +pkg/images/filters/t_frmode.x + Added a verbose parameter to the median, rmedian, mode, rmode, fmedian, + frmedian, fmode, and frmode tasks. (11/27/95, Davis) + +dev/hosts + Corrected path to irafks.e for cephus on all servers (11/30 MJF) + +unix/boot/spp/xpp/xppcode.c + Modified XPP to make keyword recognition case sensitive. Keywords + such as "int", "char", "procedure", etc. must be lower case to be + recognized. This permits macros to use the upper case versions of + these keywords. (12/05) + +pkg/cl/debug.c + Added INDXINCR and PUSHINDEX to the debug code. (12/14) + +pkg/cl/builtin.c +pkg/cl/compile.c +pkg/cl/debug.c +pkg/cl/exec.c +pkg/cl/grammar.y +pkg/cl/main.c +pkg/cl/opcodes.c +pkg/cl/opcodes.h +pkg/cl/prcache.c + 1. Fixed minor bugs in the CL array code which showed up on the 64bit + DEC Alpha. The array code had builtin assumptions about the size of + structures stored in CL memory, but on 64 bit systems the CL stack + and dictionary have a 64 bit memel size, rather than 32 bit. + + 2. Added a new builtin "d_trace" which permits instruction and + process tracing during execution. Typing d_trace without any + arguments toggles this feature. An optional argument 0 or 1 may be + used to disable or enable instruction tracing. A source line trace + feature might have been nicer, but instruction tracing should still + be of use for tracking down bugs in scripts, or otherwise revealing + what is going on when the CL executes a task. (12/16) + +sys/fmio/zzdebug.x + Added a parameter to the create datafile task to allow specification + of FM_MAXPTPAGES (max page table pages), for testing large datafiles. + (12/18) + +dev/hosts + Added new solaris machine oso to all servers. (1/29/96 MJF) + +pkg/images/imarith/imexpr.gx + Modified imexpr so that it will accept an image name that looks like + a number in the first few characters, but which is really an image + name. For example, "123.imh" or "../foo.imh". The previous version + of imexpr was treating any string which looked like a number in the + first few characters as a numeric constant. (2/8/96 LED 2/14 DCT). + +dev/hosts + Eliminated all references to /gemini and /ursa since all machines + have been updated such that /iraf is the correct path. Merged all + changes from other servers to tucana so all hosts files are now + identical, new machines added include ozzie, verdi, corondito and + pearl.kpno. Backups of previous files will be maintained. (2/14 MJF) + +pkg/images/geometry/t_geotran.x +pkg/images/geometry/geograph.x +pkg/images/doc/geomap.hlp + Corrected the definition of skew in the routines which, compute the + geometric interpretation of the 6-coefficient fit, compute the + coefficients from the geometric parameters, and in the relevant help + pages. (2/19/96, LED) + +sys/fio/zzdebug.x + Spiffed up the "daytime" debug/test task to permit entry of a host + name, so that one can use this to find out what time it is at some + site halfway around the world. (2/23) + +pkg/images/tv/imexamine/iejimexam.x +pkg/images/tv/jimexam.par +pkg/images/tv/doc/imexamine.hlp + There were several errors in this which only showed up when using a + world WCS. The parameter prompt and help now indicate the initial + sigma value is in pixels even when fitting in world coordinates. + (2/27/96, FV) + +pkg/images/tv/imexamine/iemw.x + The inverse WCS function was incorrect and is fixed. (2/27/96, FV) + +pkg/dataio/doc/rfits.hlp + Added a note about support for unsigned short integers to the + rfits help page. (2/27/96, LED) + +pkg/xtools/icfit/icvshow.gx +pkg/xtools/icfit/icshow.x +pkg/xtools/icfit/icerrors.gx + All output except the tabular part of :xyshow now begins with + the comment character. (2/29, Valdes) + +pkg/utilities/curfit.gx + Removed repeated output and added a comment character to the table + header line. (2/29, Valdes) + +dev/hosts + Changed GONG machines soi/mdi to use bin.ssun after solaris upgrades. + (3/8/96 MJF) + +sys/fmio/fmio.h +sys/fmio/fmlfopen.x +sys/fmio/fmlfbwr.x +sys/fmio/fmlfbrd.x +sys/fmio/fmioextnd.x +sys/fmio/fmclose.x + 1. Changed the lfile pagemap (LF_PAGEMAP) from type short to int. + This is entirely an internal array, created at lfile open time from + the global pagemap, and never written out, so there should be no + problem changing the datatype of the array. A type short lfile + pagemap limits the maximum datafile size by limiting the max file + offset to 32K datafile pages. This is not a problem for the global + page table as the global table stores the lfile number in each PTE, + with the offset of the PTE entry giving the associated file offset + (page number). + 2. Increased the default lfile pagemap size and increment on + overflow. (3/11) + +lib/qpset.h +sys/qpoe/qpoe.h +sys/qpoe/qpstati.x +sys/qpoe/qpseti.x +sys/qpoe/qpopen.x +sys/qpoe/qpmacro.x +sys/qpoe/qpbind.x + Added a new parameter "maxptpages" (QPOE_MAXPTPAGES) to QPOE. This + is a datafile control parameter similar to "maxlfiles" or "pagesize". + The pagesize and matptpages together determine the maximum datafile + size. In the past we have had to increase the pagesize to accomodate + very large datafiles, but beyond a certain point it is better to + increase the maximum page table size (maxptpages). Since QPOE files + can be very large it is necessary to allow control of this parameter + from within QPOE. (3/11) + +dev/hosts + Added Doug Geisler's machine kukita to all servers. (3/11/96 MJF) + +sys/fmtio/dtoc.x + Added some rounding to avoid printing numbers such as 12:29:60.0 + when formatting sexagesimal (HMS or MS) numbers. (3/12) + +sys/mwcs/iwewcs.x + Modified the code which computes the CD matrix from CDELT/CROTA. + The old code computed the diagonal (scale) terms correctly but the + rotation terms were evidently incorrect. The old code was based on + the 1988 Hanisch and Wells WCS paper and the new code is based on a + more recent paper by Mark Calabretta et. al. which supercedes the + 1988 representation. The affect of this change should be limited + as it only affects rotated images for which CDELT is given but no + CD matrix is defined. (3/13) + +pkg/images/tv/src/iecolon.x +pkg/images/tv/src/starfocus.h +pkg/images/tv/src/stfmeasure.x +pkg/images/tv/src/ierimexam.x +pkg/images/tv/rimexam.par +pkg/images/doc/imexamine.hlp +lib/scr/imexamine.key + The radial profile fitting and width measurements now have an option to + use a Gaussian or Moffat profile model. The model is selected by a + new "fittype" parameter. A new "beta" parameter may be specified as + INDEF to be determined from the fit or have a fixed value. The Moffat + profile model does better in producing consistent FWHM values so + this is the default. (3/16, Valdes) + +math/gsurfit/gsrestore.gx +math/gsurfit/gsrestorer.x +math/gsurfit/gsrestored.x + Changed the type declaration of the xmin, xmax, ymin, ymax variables + from real to PIXEL to avoid machine precision problems. (3/21 Davis) + +pkg/cl/builtin.c + Modified the clprintf code to support INDEF operands. (3/23) + +pkg/images/tv/imedit/epsearch.x +pkg/images/tv/imedit/epgcur.x + 1. The search algorithm produced incorrect results if part of the + aperture was off the edge (negative image coordinates). + 2. The rounding was incorrect when part of the aperture was off the + edge (negative image coordinates). + 3. A floating operand error occurs when a key is given without + coordinates. + (3/26, Valdes) + +pkg/plot/t_implot.x + When the vector being plotted was constant the 'l' and 'c' keys + selecting lines/columns from the right plot axis did not work. The + code was fixed for this case. (3/27, Valdes) + +pkg/images/geometry/xregister/rgxfit.x + Changed several Memr[] references to Memi[] in the rg_fit routine. + This type conversion bug was causing a floating point error + in the xregister task on the Dec Alpha machines if the coords file + was defined, and could potentially cause problems on other machines. + (Davis, April 3, 1996) + +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + Removed the type long variables gmtl, lstl and modified all calls to + localtime() so that the argument is of type time_t. This is standard + for all modern systems. Some older systems still require that the + argument be type long, but as this is nonstandard it should be + ifdef-ed in the source for these older systems. (4/04 1996) + +unix/hlib/libc/libc.h + The macros Memcptr and Memiptr included a "+ 1" which shouldn't have + been there. The one indexing correction was already being done in + the Memc/Memi macros and Memcptr/Memiptr take a zero indexed C pointer + as input. This was causing a bug in LIBC version of realloc, which + is not used anywhere in the IRAF system code. (4/05) + +pkg/images/tv/imexamine/ierimexam.x +pkg/images/tv/imexamine/stfmeasure.x + Fixed incorrect datatype declaration "real np" -> "int np" in various + related places. (4/9/96, Valdes) + +unix/os/zmain.c + Added a #ifdef SYSV conditional to change the calling sequence for + setpgrp() for SYSV and BSD systems. (4/24) + +sys/imio/iki/plf/plfopen.x + Fixed an imerr() call which had the wrong argument type. (5/06) + +sys/libc/realloc.c + Modified to work when called with a null pointer. (5/06) + +sys/gio/stdgraph/stgdrawch.x + The text drawing routines were not controlling the polyline width + when drawing characters in software mode using polylines. There is + no line width attribute for graphics text and we probably don't want + one, so the code was modified to force the line width to 1 when + drawing software characters. (5/10) + +unix/boot/bootlib/osgetenv.c + The envinit code calls _os_getenv to fetch the value of "pkglibs". + This code assumes that _os_getenv returns the string argument, but + nothing was being returned if the named environment variable was not + found. Changed it to return a NULL-terminated empty string in this + case. (5/10) + +sys/etc/mkpkg +sys/etc/onentry.x +sys/etc/main.x +unix/os/zmain.c + 1. The IRAF main (irafmn) was changed to an integer function and + modified to return an exit status. If a task aborts and the main + exits without running any more tasks (as when executing a task at + the host level where only a single task is run) then the error status + of the task is returned. In normal use as a connected process this + condition never occurs and the main always returns XOK as the status. + + 2. Several calls to sys_panic in various etc$ routines were modified + to ensure that a zero error code is not returned. sys_panic returns + the error code as the exit status of the process. + + 3. The process main (zmain.c) was modified to call IRAF_MAIN as an + integer function and to return its exit status. + 4. The call to exit() in zmain.c was changed to _exit(). (5/11) + +pkg/plot/t_graph.x +pkg/plot/graph.par +pkg/plot/doc/graph.hlp + Added parameters "ltypes" and "colors" to specify a list of line types + and colors when doing multiple data sets. (5/13, Valdes) + +---------------------------------------- +V2.10.4 patch 2 release. (5/22 1996) + +unix/boot/bootlib/envinit.c + Fixed a typo in some code that went "printf (stderr, ...)" (should be + fprintf), also changed following fflush to flush stderr. (5/27) + +unix/boot/bootlib/vfn2osfn.c + Deleted some unneeded semicolons from some stub routines, e.g. in + "KI_SEND(){};" the ; should not be there. (5/27) + +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/rpp/mkpkg.sh +unix/boot/xpp/mkpkg.sh +unix/boot/xyacc/mkpkg.sh + Replaced HSI_CF by HSI_LF in the link line (5/28) + +unix/hlib/irafuser.csh + Added a dummy definition of HSI_LF (not used in SunOS/IRAF but is + needed on other platforms). (5/28) + +unix/boot/rmfiles/mkpkg.sh + Added a (char *) declaration for vfn2osfn(). (5/28) + +pkg/cl/grammar.h +pkg/cl/globals.c + Added global definitions for parse_state, proc_script, and parse_pfile + to globals.c and modified grammar.h to define these as extern (found + with the IRIX 5.3 port). (6/03) + +pkg/obsolete/ - + The old (V2.9) IMCOMBINE task was removed. (6/14 FV) + +pkg/obsolete/t_fixpix.x + +pkg/obsolete/fixcol.gx + +pkg/obsolete/t_fixline.gx + +pkg/obsolete/ofixpix.par + +pkg/obsolete/doc/ofixpix.hlp + +pkg/obsolete/mkpkg +pkg/obsolete/x_obsolete.x +pkg/obsolete/obsolete.cl +pkg/obsolete/obsolete.hd +pkg/obsolete/obsolete.men + Moved the V2.10.4 version of PROTO.FIXPIX to OBSOLETE and renamed + it to OFIXPIX. (6/14 FV) + +pkg/proto/generic/ + +pkg/proto/imfunc.x -> generic/ +pkg/proto/imrep.x -> generic/ + Added a generic directory for generic files. The generic procedures + imfunc.x and imrep.x are now in this directory. (6/14 FV) + +pkg/proto/t_fixpix.x +pkg/proto/fpfixpix.gx +pkg/proto/fixpix.par +pkg/proto/text2mask.par + +pkg/proto/t_text2mask.x + +pkg/proto/t_mask2text.x + +pkg/proto/doc/fixpix.hlp +pkg/proto/doc/text2mask.hlp + +pkg/proto/mkpkg +pkg/proto/x_proto.x +pkg/proto/proto.cl +pkg/proto/proto.hd +pkg/proto/proto.men + Replaced the old version of FIXPIX by a new version that works with + mask images. Two new tasks were also added, TEXT2MASK and + MASK2TEXT, that convert from the old text file description to mask + images and back. The MASK2TEXT task is hidden to discourage + continued use of the text file description. (6/14 FV) + +unix/boot/spp/xc.c + Fixed a couple bugs in the PKGENV processing code. (7/05) + +doc/ports/notes.irix + + Installed the notes file from the IRIX 5.3 port. (7/07) + +unix/os/irafpath.c + Added entries for Solaris, Linux, FreeBSD. (7/17) + +unix/os/zfaloc.c +unix/os/zfiobf.c + Changed type of lseek() to off_f. (7/17) + +unix/boot/spp/xpp/xppcode.c + Changed warn() to a static function. (7/17) + +mkpkg +noao/mkpkg + Added an entry for the "freebsd" architecture. (7/17) + +pkg/images/filters/median.x + The routine mde_yefilter was being called with too many arguments. + (7/18 LED) + +pkg/xtools/inlfit/ingresults.gx + Changed several INDEFR references to INDEF references so that INDEF + as the correct data type (real or double) in the output .x files. + (7/18 LED) + +sys/gio/fpequald.x +sys/gio/fpequalr.x + Backed off the tolerance slightly, from 10*EPSILON to 32*EPSILON. + (7/25) + +sys/imfort/bfio.x + In zfaloc, the first arg to strpak was changed from fname (a Fortran + character variable which was incorrect) to sppname. (7/17(26)) + +pkg/images/imarith/icsort.gx + There was an error in the ic_2sort routine when there are exactly + three images that one of the explicit cases did not properly keep + the image identifications. See buglog 344. (8/1 FV) + +dev/hosts + Revised the list of Kitt Peak hosts. (8/7 RLS) + +pkg/proto/fields.par +pkg/proto/doc/fields.hlp + Changed the default lines in FIELDS to an open upper limit. (8/22 FV) + +pkg/images/tv/imexamine/stfmeasure.x + Fixed bug in evaluation of enclosed flux profile in which the scaled + radius was used for the gaussian subtraction stage instead of pixels. + This does not currently affect IMEXAM because the scale is fixed + at 1. (8/29, FV) + +unix/os/zfnbrk.c + Modified this routine to ignore file or directory characters other + than those it considers to be file or directory name delimiters. + On platforms that permit it, the effect is to permit characters (such + as + and -) in filenames other than simple identifier characters. + There is no expectation at this point however that all IRAF code will + permit this. (9/03) + +dev/hosts + Updated the hosts file on all Tucson servers for rainbow, Jim + Deveny's new Sun. (9/10/96 jb) + +pkg/system/phelp.cl + Modified to copy the "template" argument into a local variable since + it is referenced twice in the script. (10/10) + +sys/fio/fioclean.x + The file descriptor was being accessed after the file had been + closed. (10/11) + +unix/os/zfiond.c + Added a ":" field to the ND network driver. The only protocol + flags currently supported are "text" and "binary". If "text" is + specified then the datastream is assumed to consist of byte packed + ascii text, and the driver will automatically convert to and from + SPP chars during i/o. (10/29) + +sys/fio/zzdebug.x + Added a new debug task "http". Given a hostname and a HTTPD-root + relative file path the task will connect to the HTTP server on the + given host and fetch the file at the given path. The output + consists of the HTTP/1.0 protocol header followed by a blank line + and the contents of the requested file. (10/29) + +pkg/images/tv/wcslab/t_wcslab.x +pkg/images/tv/doc/wcslab.hlp + Added an "overplot" option to append to a plot but with a different + viewport. (11/06/96 Valdes) + +pkg/images/imarith/t_imcombine.x +pkg/images/imarith/icombine.gx + Changed the error checking to catch additional errors relating to too + many files. (11/12/96, Valdes) + +dev/hosts + Added driftwood to all downtown servers. (11/18/96 MJF) + +dev/hosts + Updated block of KPNO hosts on solaris tree on Gemini. + This was up to date on development system. (11/19/96 RLS) + +sys/fmtio/sscan.x +sys/fmtio/fscan.x +sys/fmtio/clscan.x +sys/fmtio/scan.com + Modified scan.com to dimension scanbuf locally as SZ_SCANBUF instead of + SZ_COMMAND, in the process increasing the size from 1024 to 4096. + Modified sscan to check for overflow of the scan buffer. (11/19) + +sys/ki/ki.h + Increased maximum network hosts in the in-core host table from 128 to + 256. (11/21) + +pkg/images/tv/imedit/epgsfit.x +pkg/images/tv/imedit/epcolon.x +pkg/images/tv/doc/imedit.hlp +pkg/images/tv/imedit/imedit.par + Added a median background if the xorder or yorder is zero. + (11/22/96 Valdes) + +dev/hosts + Cleaned up the hosts table: Deleted + adonis aldebaran auriga + columba crater irafdemo + libra noctua octans + omega serpens suntest + verdi vela + Fixed path names for mytoy and scorpius (11/21/96 MJF) + +pkg/images/imarith/icsetout.x +pkg/images/doc/imcombine.hlp + A new option for computing offsets from the image WCS has been added. + (11/30/96 Valdes) + +pkg/images/tv/display/sigm2.x + + Added a version of the spatial interpolation routines that allows masks + to interpolate the input across bad pixels. (12/5/96, Valdes) + +pkg/images/tv/display/t_display.x + 1. Fixed numerous problems with the coordinate system. + 2. Fixed a bug in how ztrans=log was done. + (12/5/96, Valdes) + +pkg/images/tv/display/iishdr.x +pkg/images/tv/display/iisers.x + Replaces SPP int -> short assignments by calls to achtiu because of + overflow problems with some VMS fortran compilers. + (12/6/96, Valdes as reported by Zarate) + +pkg/images/tv/display/imdmapfr.x +pkg/images/tv/display/imdputwcs.x + + Added two routines to hide knowledge of the channel structure and + other details from the calling routines. (12/11/96, Valdes) + +dev/hosts + Changed hohokam to ssun, updated all servers w/ master copy from + tucana to remove hosts and fix /gemini path names. (1/7/97 MJF) + +dev/hosts + Changed the following SWN machines to bin.ssun: + aquarius aten bokchoy + carina (new) hedgehog herbie + inti mdi potosi + soi soleil + Updated all servers. (1/15/97 MJF) + +pkg/xtools/dttext.x + Added the routine dtgetd to the text database package. (1/16/97 LED) + +dev/hosts + Changed norma to a solaris box. (1/24/97 MJF) + +unix/boot/bootlib/osfiletype.c + Added several entries for files considered to be "source" files. + These include .pl, .gif, .jpeg, and .tiff (.fits is already present). + There are cases where it may make sense to include these files in + the machine indendent source tree, e.g. for small test data files + or for online help. (1/11) 1997 + +dev/hosts + Added George's linux box aloe to all servers. (2/13/97 MJF) + +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c + The recent change of warn() to static in xppcode.c caused a problem + as warn is also used in decl.c. Changed warn() back to an external + function but changed the name to xpp_warn to avoid whatever the + platform-specific problem was that resulted in the original fix + (probably warn was an internal function in some platform system + library). (3/03) + +sys/mwcs/wfmspec.x + On line 327, changed din=log10(in[1]) to din=log10(din). (3/04) + +-------------------------------- +Did a diff/merge of recent tucana HSI changes into the Solaris/IRAF HSI. +Replaced the "unix" directory on tucana SunOS/IRAF by the version from +Solaris/IRAF. This HSI is supposed to work for both SunOS and Solaris +(SunOS compatibility was preserved but never tested during the Solaris/IRAF +port). Did a bootstrap and sysgen under both SunOS and Solaris. + +Mounted tucana iraf.develop as iraf.develop on Data. tucana iraf (irafx) +is now solaris/iraf as well as sunos/iraf, they are the same thing. One +benefit of this is that irafx is now available on solaris systems in the +building (although we do have to update the ssun binaries periodically or +it does no one any good). A complication is that since we have to update +the ssun binaries, it is now more likely that the architecture may be set +to something other than sparc. (3/19 1997) + +local/.cshrc +local/.login + Modified to work for both SunOS and Solaris. (3/19) + +unix/as.sparc/enbint.s + This file from Solaris/IRAF isn't used by SunOS/IRAF, but it is + probably better to provide it in the library than to add conditionals + to the build files in OS. (3/19) + +unix/boot/bootlib/osfiletype.c +unix/boot/bootlib/vfn2osfn.c +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c +unix/hlib/libc/kernel.h +unix/os/irafpath.c +unix/os/zfaloc.c +unix/os/zfiobf.c +unix/os/zfiomt.c +unix/os/zfiond.c +unix/os/zlocpr.c +unix/os/zzstrt.c + Assorted minor changes to make these files work for both SunOS + and Solaris. (3/19) + +unix/shlib/medit.c +unix/shlib/mkpkg +unix/shlib/mkpkg.sh +unix/shlib/mkshlib.sos4 +unix/shlib/mkshlib.ssol +unix/shlib/mkshlib.ssol-sc34 + Various file modifications and file name changes to make shlib + build for both SunOS and Solaris. (3/19) + +pkg/math/curfit/cvacpts.gx +pkg/math/curfit/cvacptsr.x +pkg/math/curfit/cvacptsd.x +pkg/math/curfit/doc/cvpower.hlp +pkg/math/curfit/cvpower.gx +pkg/math/curfit/cvpowerr.x +pkg/math/curfit/cvpowerd.x + The weights computed by the WTS_CHISQ option in the routines + cvacpts[rd] were not being forced to be positive as intended. (3/20) + + There was an inconsistency in the way the ncoeff argument to the + cvpower[rd] routines was being used internally. Ncoeff was intended + to be an output argument but was being used as an input argument by + one of the routines called by cvpower. (3/20) + +sys/mtio/mtgtyopen.x + MTIO was modified to add support for server-specific tapecap files. + When opening the tapecap file MTIO will now look for "tapecap." + followed by the default "tapecap". should be the hostname + (as used by IRAF networking) of the server hosting the tape drives + described by the tapecap file. For example if host "gemini" serves + up some tape drives it's tapecap file is named "tapecap.gemini". + If a server-specific tapecap file is not found the default "tapecap" + (on the possibly remote server node) is used. This feature allows + a single IRAF installation to be shared by multiple servers. (3/21) + +dev/README +dev/tapecap.sunos + +dev/tapecap.solaris + + Since the Sun/IRAF DEV is now shared by both SunOS and Solaris it + now contains the template tapecap files for both systems. The README + in DEV contains some pointers on configuring tapecap and other device + files. (3/21) + +pkg/images/tv/display.par +pkg/images/tv/display/t_display.x +pkg/images/tv/display/zscale.x +pkg/images/tv/display/sigm2.x + +pkg/images/tv/display/maskcolor.x + +pkg/images/tv/display/dspmmap.x + +pkg/images/tv/display/display.h +pkg/images/tv/display/gwindow.h +pkg/images/tv/display/mkpkg +pkg/images/tv/doc/display.hlp + 1. Improved the structure of DISPLAY. + 2. Fixed coordinate system errors. + 3. Added parameters to display bad pixel masks and overlay masks. + 4. The z scaling sampling may use a pixel mask or image section. + 5. The z scaling excludes bad pixels. + (3/20, Valdes) + +-------------------------------- +The following series of revisions were made to increase the size of various +system buffers. This included a full system reboot and recompile. (3/24) + +lib/fio.h +sys/fio/vfnmap.x +sys/fio/vfntrans.x + Various buffer sizes affecting filename mapping were increased. + SZ_VFNFN (max length of the root field of a VFN) went from 32 -> 127. + SZ_OSDIR (max length of the osdir field of a VFN) from 79 -> 255. + SZ_FFNAME, an internal filename buffer, went from 127 -> 255. + In an unrelated change SZ_SPOOLBUF, the intial size of a spool + buffer, was increased from 1024 to 4096. (3/23) + +unix/hlib/config.h + 1. MAX_ROOTLEN was increased from 32 to 128. This is supposed to be the + limit the host system places on the root portion of a filename (that + is, only the root name, not the pathname). Anything in the range + 128-256 is typical for unix systems today. + 2. The maximum number of open VOS files was increased from 128 -> 256. + (3/23) + +sys/fio/fntgfn.x + SZ_PATTERN, SZ_TEMPLATE, SZ_LDIR, SZ_PATSTR were all increased, + although so far as I know there has never been a case of pattern + buffers overflowing. The new limit for a pattern string is about + 1024. (3/23) + +unix/hlib/iraf.h + SZ_FNAME went from 63 -> 255. + SZ_PATHNAME went from 127 -> 511. + SZ_LINE went from 161 -> 1023. + SZ_COMMAND went from 1024 -> 2047. (3/23) + +unix/hlib/iraf.h +unix/hlib/mach.h + MAX_EXPONENTD went from 38 (same as real) to 308, the value for + IEEE double. MAX_DOUBLE increased from 0.99d37 to 0.99d307. + INDEFD was changed from 1.6d38 to 1.6d308 for IEEE systems. (3/23) + +unix/hlib/libc/libc.h +unix/hlib/libc/spp.h + FIO_MAXFD, INDEFD, SZ_LINE, SZ_FNAME, SZ_PATHNAME, SZ_COMMAND were + updated to agree with the SPP values. (3/23) + +sys/imio/iki/stf/stfrdhdr.x + Unrelated STF bug fix. stfrdhdr.x was modified to handle the case + where datamin/datamax were not defined in the GPB, but were defined + in the main image header. (3/24) + +unix/boot/spp/xpp/xppmain.c + Removed a redundant SZ_PATHNAME. (3/24) + +unix/shlib/mkpkg +unix/shlib/mkshlib.sos4 + Changed the address of the shared library from 0xa000000 to 0x10000000. + This increases the maximum available per-process dynamic memory from + 167 MB to 268 MB (much more is possible if the process is statically + linked). (3/24) + +unix/os/zzstrt.c + Changed some address-related ints to unsigned just to be safe. (3/24) + +sys/etc/pagefiles.x + Increased SZ_LONGLINE from 1024 to 4096. At 1024 it was the same as + the new SZ_LINE, causing a loop test to fail. (3/25) + +pkg/images/tv/rimexam.par +pkg/images/tv/doc/rimexam.par + Changed the zero point of the magnitude scale from 30.0 to 25.0 + for the sake of consistency with other photometry tasks. (3/31, LED) + +pkg/images/tv/imexamine/ierimexam.x + The log output for 'a' or 'r' has one line per measurement as in + previous versions. The standard output, however, uses two lines to + print nicely on 80 column windows. (3/31, FV) + +pkg/dataio/mkpkg +pkg/dataio/dataio.cl +pkg/dataio/dataio.hd +pkg/dataio/dataio.men +pkg/dataio/x_dataio.x +pkg/dataio/import/ + +pkg/dataio/import.par + +pkg/dataio/export/ + +pkg/dataio/export.par + +pkg/dataio/doc/import.hlp + +pkg/dataio/doc/export.hlp + + Installed the IMPORT/EXPORT task for general use. The images database + used by the IMPORT task is currently defined to be stored in + dataio$import/images.dat. (3/31/97 MJF) + +pkg/proto/proto.cl +pkg/proto/proto.men +pkg/proto/proto.hd +pkg/proto/x_proto.x +pkg/proto/mkpkg + The tasks imalign, imcentroid, imfunction, imreplace, wcsedit, and + wcsreset have been deleted from the proto package and moved to the + reorganized images package. (3/31/97 LED) + +lib/imhdr.h +lib/imio.h + The sizes of the pixel file, header file, title and imhistory strings + were increased. Defines were added for the image header file and + pixel file "magic' strings. A couple fields were added relating to + byte swapping. IM_SWAPPED, in the image header, tells whether the + pixels in the disk image are byte swapped. (3/31) + +sys/imio/iki/oif/imhv1.h +sys/imio/iki/oif/imhv2.h +sys/imio/iki/oif/mkpkg +sys/imio/iki/oif/oif.h +sys/imio/iki/oif/oifmkpfn.x +sys/imio/iki/oif/oifopen.x +sys/imio/iki/oif/oifopix.x +sys/imio/iki/oif/oifrdhdr.x + +sys/imio/iki/oif/oifupdhdr.x +sys/imio/iki/oif/oifwrhdr.x + +sys/imio/iki/oif/oifwphdr.x - + It was necessary to change the OIF kernel to increase the maximum + path length for header and pixel files. This made it necessary to + change the disk image format, since the old format only allowed 80 + characters for the pixel file pathname. In the process reading and + writing the disk header was separated out from the in-memory + header. Support for two versions of the image and pixel file + headers were added. The "magic" string in the image or pixel file + header identifies the version. Old (version 1) image headers have + "imhdr" at the head of the file, with the string in SPP chars. The + new (version 2) headers have "imhv2" as the magic string. V2 headers + are byte packed and machine independent. The path limit is 255. + (3/31) + +sys/imio/immaky.x +sys/imio/imrdpx.x +sys/imio/imwrpx.x + 1. Support was added for byte swapping pixels. With the machine + independent V2 image header, this allows .imh images to be read on + any node (integer) or any IEEE-compatible node (floating). The + pixels are written in the native swap order of the creating host, + but the order is recorded in the IM_SWAPPED field of the image header, + and IMIO uses this to determine whether or not the pixels need to + be byte swapped during i/o. + 2. Minor changes to trim junk data after EOS delimited strings. + Since the V2 headers are byte packed the string data in these headers + can be viewed with Unix tools such as "less" and "strings". (3/31) + + Some pointers: "strings foo.imh" (or other tools like less) can be + used at the Unix level to look at V2 image headers. New images are + always written with host-native binary format pixels, so there is no + byte swapping involved for images read and written on the same + host. Images can any other (IEEE) host can be read or written but + there may be some slight overhead for byteswapping. If the image is + rewritten however using imcopy, the bytes will be swapped to the + native ordering of the new host. + +pkg/images/imutil/src/imheader.x + The only change so far was to eliminate some histogram dependence, + since this unused feature was removed from the standard IMIO in-memory + image header. (3/31) + +dev/pix.imh +dev/pix.pix +dev/wpix.imh + Regenerated using the V2 image format. (3/31) + +lib/imio.h +sys/imio/immapz.x +sys/imio/immaky.x +unix/hlib/zzsetenv.def +unix/hlib/login.cl + Increased the default size of the user area (min_lenuserarea) to + 64000 (about 800 80 char cards). There was some ambiguity about + units for min_lenuserarea; it should be consistently chars now. + Also increased the "padding" added to the header when creating a + new copy of an existing image which has a large header. (4/01) + +sys/imio/immaky.x + When the header of an old image is copied during an open-new-copy, + IMIO now recomputes the length of the user area of the input header. + Formerly if the header had grown since the image was opened, the + added data could be lost in a subsquent new-copy operation. (4/01) + +sys/etc/oscmd.x + Changed an fclobber(outfile) to fclobber(errfile). (4/02) + +sys/imfort/bfio.x + The little Fortran-callable file i/o package BFIO used in IMFORT + was enhanced to support writing and reading of fractional file blocks + so that files can be any size. The default random and sequential + buffer sizes were increased. In addition to the old random access + i/o routines bfread/bfwrite there are now sequential i/o routines + bfseek/bfrseq/bfwseq. (4/02) + +sys/imfort/mkpkg +sys/imfort/imfort.h +sys/imfort/imhv1.h + +sys/imfort/imhv2.h + +sys/imfort/oif.h +sys/imfort/imcrex.x +sys/imfort/imfgpfn.x +sys/imfort/imfupdhdr.x +sys/imfort/imgl1r.x +sys/imfort/imgl1s.x +sys/imfort/imgl2r.x +sys/imfort/imgl2s.x +sys/imfort/imgl3r.x +sys/imfort/imgl3s.x +sys/imfort/imgs1r.x +sys/imfort/imgs1s.x +sys/imfort/imgs2r.x +sys/imfort/imgs2s.x +sys/imfort/imgs3r.x +sys/imfort/imgs3s.x +sys/imfort/imopnx.x +sys/imfort/impl1r.x +sys/imfort/impl1s.x +sys/imfort/impl2r.x +sys/imfort/impl2s.x +sys/imfort/impl3r.x +sys/imfort/impl3s.x +sys/imfort/imps1r.x +sys/imfort/imps1s.x +sys/imfort/imps2r.x +sys/imfort/imps2s.x +sys/imfort/imps3r.x +sys/imfort/imps3s.x +sys/imfort/imrdhdr.x + +sys/imfort/imswap.x + +sys/imfort/imwpix.x + +sys/imfort/imwrhdr.x + + 1. IMFORT was brought up to date with IMIO to read and write the new + version 2 ".imh" images. As with IMIO, the old V1 format is still + supported but new images are written using the new machine independent + V2 format. + 2. Image headers can now be any size (the old IMFORT had a very + strict limit on the image header size). Since BFIO now writes partial + blocks, headers are no longer blocked out to 32768 bytes. + 3. "min_lenuserarea" is now supported as for IMIO (since IMFORT is + host level it must be defined in the host environment). The builtin + default header buffer is 64000 chars, which is about 800 card images. + (4/02) + +sys/imfort/mii.x + + A version of the MII routines mii{read,write}[silrc] modified to + use BFIO was added to IMFORT. These are used to read and write the + machine independent headers. (4/02) + +dev/hosts + Aliased 'kf' for kingfisher at Al Fowler's request (4/3 MJF) + +lib/qpioset.h +lib/syserrmsg +sys/qpoe/qpio.h +sys/qpoe/qpoe.h +sys/qpoe/qpiogetev.x +sys/qpoe/qpiogetfil.x +sys/qpoe/qpiomkidx.x +sys/qpoe/qpioopen.x +sys/qpoe/qpioparse.x +sys/qpoe/qpiorpix.gx +sys/qpoe/qpioseti.x +sys/qpoe/qpiostati.x +sys/qpoe/qpiosync.x + QPOE was modified to allow event coordinate (X,Y) key fields to be + of type int as well as short. All event handling code will now + accept either type. Keys may be specified using "i" as the field + type as well as "s", e.g. "key=(i10,s14)". X and Y do not have to + be the same type. There should be no significant CPU runtime + penalty, although obviously events with integer coordinate fields + will mean larger event files (file i/o times will be affected + accordingly). (4/03) + +lib/qpioset.h +lib/qpset.h +sys/qpoe/QPOE.hlp +sys/qpoe/README +sys/qpoe/qpcopyf.x +sys/qpoe/qpio.h +sys/qpoe/qpiogetfil.x +sys/qpoe/qpiolwcs.x +sys/qpoe/qpioopen.x +sys/qpoe/qpioparse.x +sys/qpoe/qpioseti.x +sys/qpoe/qpiostati.x +sys/qpoe/qpmacro.x +sys/qpoe/qpoe.h +sys/qpoe/qpopen.x +sys/qpoe/qpqueryf.x +sys/qpoe/qpseti.x +sys/qpoe/qpstati.x +sys/qpoe/zzdebug.x + Added support for separate X and Y blocking factors. The "block" + parameter is still recognized as before and will set both the X and + Y blocking factors, or "xblock" and "yblock" can be used to set only + one or the other. All occurrences have been updated, including + expressions, the QPDEFS environment, and qp_set qpio_set. (4/04) + +sys/qpoe/qpiorpix.gx + [INTERFACE CHANGE] + The calling sequence for qpio_readpix was modified to replace the + "block" argument by the two arguments xblock and yblock. A scan + indicates that none of the layered packages we have installed at + NOAO (including xray) currently uses this routine. (4/04) + +sys/plio/plrio.x + The plrio package provides an efficient lookup-table-based means of + randomly sampling 2D pixel masks. The code which recursively divides + a region into 4 quadrants could fail if the region being subdivided + was 1 pixel wide in either axis. If this happens 2 of the "quadrants" + will be valid and 2 will be degenerate. Added a test to detect and + discard these degenerate subregions. (4/04) + +sys/plio/plsectne.x +sys/plio/plsectnc.x + Both of these routines had a bug that could prevent them from + examining the full region requested (the routines check for section + not empty and section not constant). Line lists are segmented in + segments of at most I_DATAMAX (4095) pixels. If the mask is large + and has large regions of constant value, the list will consist of + successive segments all at the same value. The routines were only + checking the first such segment. The corrected code reads successive + segments until all the pixels in the region have been examined. (4/04) + +sys/plio/zzdebug.x + Fixed a couple of bugs and added several new routines to test the + above fixes. SECNE and SECNC test pl_sectnotempty and pl_sectnotconst. + RIO tests plrio random mask access. INVERT inverts a mask. (4/04) + +sys/imio/implhdr.x + These routines, which copy an image header to and from an encoded title + string in a PLIO save file, were modified to save the ctime, mtime, + limtime, minpixval, and maxpixval static fields of the image header + in addition to the title string. (4/04) + +sys/qpoe/qpexeval.x + The value of "pass" was not being initialized before starting + subprogram execution when evaluating a complex LUT bin. Added the + initialization and also some comments giving an overview of how the + evaluation is performed (since it took me several hours to figure + this out again). (4/04) + +sys/imio/iki/qpf/qpfcopypar.x +sys/imio/iki/qpf/zfioqp.x +sys/imio/iki/qpf/qpfopen.x +sys/imio/iki/qpf/qpf.h + Modified to support separate x and y blocking factors. (4/05) + +sys/plio/plupdate.x + This routine contains code which collapses successive mask lines + in Y to a single encoded mask line if the mask lines are equal, + thereby compressing the encoded mask in Y. The encoded mask lines + are encoded in short integer arrays and a multiply referenced + line has a reference count which is stored in a short integer field. + The code was modified to stop when this counter reaches MAX_SHORT, + adding a new line to the encoded mask and starting over. Combined + with the X segmentation of lines into blocks of at most 4095 pixels, + this should allow masks to be nearly any size despite the use of + short integers for the encoding. (4/05) + +sys/qpoe/qpiolwcs.x + Modified the LTV_2 term of the logical transformation to set the + fractional pixel zero point resulting from blocking the input data. + If for example 2 input pixels map to 1 on output, the range of the + output pixel (e.g. 0.5 to 1.5) maps to the range covered by the two + input pixels (e.g. 0.5 to 2.5), and the center of the output pixel + (e.g. x = 1.0) maps to the center of the range spanned by the input + pixels (e.g. 1.5). For 3 to 1, 1.0 maps back to 2.0 in the input, + for 4 to 1, 1.0 maps back to 2.5, and so on as (block+1)/2. (4/05) + +sys/ki/kfmkcp.x +sys/ki/kfrnam.x + These routines use a locally dimensioned buffer which was causing + filenames to be truncated at 128 characters. Increased the file + length limit to 256. If both files are remote the sum of the two + file lengths cannot exceed 256. (4/06) + +unix/boot/spp/xc.c + The XC compiler was modified to improve support for multi-language + and host software development. These changes should be transparent + and should not affect conventional IRAF softwrae development. + + 1. Various buffer sizes were increased. + 2. The environment variables XC-CC, XC-F77, XC-LINKER can now be + specified to override the builtin default program name strings. + + 3. New command line flags: + -D Pass -D to the host compiler (does a #define). + -I Pass -I to the host compiler; for includes. + The directory name can be an IRAF VFN. + -Inolibc Disables -Ihlib$libc, which is the default. Use if + you want to use the host rather than LIBC . + -L Can be used to specify a directory to be searched + for library files. + -H This is used like -h to link a host program, but + unlike -h it causes the main IRAF libraries to be + searched. + -V Print the XC version number. + + 4. XC now reads the "pkglibs" environment variable after processing + all package includes, and converts this into a list of -I flags + which are passed to the host compilers. This allows host include + files to be placed in package libraries. As noted above, hlib$libc + is automatically included unless the -Inolibc switch is specified. + + Note that -/foo can still be used to pass "-foo" to the host + compiler. (4/07) + +unix/boot/bootlib/envinit.c + "loadpkgenv" is called by HSI programs like XC and MKPKG when a + package environment is loaded (-p pkname). loadpkgenv was modified + to allow it to be called as loadpkgenv(NULL) or loadpkgenv("iraf"). + This mode causes the package environment for the core IRAF system to + be loaded. This was done formerly as well, but only if a -p switch + was given causing loadpkgenv to be called (in other words the core + IRAF package environment was not being fully loaded consistently). + (4/07) + +unix/hlib/zzsetenv.def + Added a line "set pkglibs = hlib$libc/" to zzsetenv.def. This defines + hlib$libc as a default library directory to be searched (for C header + files) when compiling. (4/07) + +unix/hlib/libc/libc.h +unix/hlib/libc/setjmp.h +unix/hlib/libc/spp.h +unix/hlib/libc/stdio.h +unix/hlib/libc/varargs.h +unix/hlib/mkpkg.sf.SSUN + Various changes to better support host or host-like compilation. + + 1. libc.h will now include if it is not already included. + This is disabled in an old style compilation using import_spp. + libc.h is #ifdefed to not load if it has already been loaded. + + 2. setjmp.h autoloads and if not referenced in + import defines. + + 3. spp.h if #ifdefed to not load if already loaded. Various + definitions were #ifdefed to be skipped if already defined, e.g. + stuff like min and max. A define for abs was added. + + 4. stdio.h will automatically load (if not imported etc.). + Since libc.h autoloads spp.h this means that C files which include + from LIBC will automatically load spp.h and libc.h; these + contain the main LIBC definitions and often used IRAF defines such + as OK, ERR, INDEF, NEW_FILE, SZ_FNAME, etc. etc. A standard Unix + C source file which includes , if compiled with XC or with + -I$hlib/libc will automatically be compiled using LIBC and will be + usable in an IRAF program. + + 5. varargs.h now includes /usr/include/varargs.h explicitly instead + of , which causes an infinite preprocessor include loop. + On SunOS systems this causes a compiler warning message so the contents + of the SunOS varargs.h are included instead. For Solaris mkpkg.sf.SSUN + is used to employ a flag -erroff=XXX to disable the warning. (4/07) + +unix/hlib/mkpkg.inc + Added -DSUNOS to the XFLAGS for sparc, -DSYSV -DSOLARIS for Solaris. + (4/07) + +--------------------------------- +V2.11 beta-1 released. (4/08) + +pkg/images/tv/imexamine/iejimexam.x +pkg/images/tv/imexamine/iecolon.x +pkg/images/tv/kimexam.par + +pkg/images/tv/doc/imexamine.hlp +pkg/images/tv/tv.cl + Added a pset for the 'k' key rather than sharing with the 'j' key. This + was confusing to users since it was the only key without it's own pset. + Also there may be some reason to have the fitting parameters be + different along lines and columns. (4/11, FV) + +pkg/images/imcoords/doc/cctran.hlp + Fixed a bug in the cctran help page. (4/15, LED) + +pkg/images/tv/tvmark/mkmark.x + Made sure that the object label was initialized to "" in the call + to the mk_onemark procedure inside the a keystroke command. The lack + of initialization was causing tvmark to fail with a segmentation + violation when the coordinates file did not exist at task startup time, + and the label parameter was set to "yes". (4/17, LED) + +unix/hlib/libc/spp.h + Deleted the definition of abs(), which conflicts with the stdlib + definition. (4/22) + +unix/boot/spp/xc.c + There was a problem with the -h flag: due to the recent changes it + was referencing the VOS libraries (and linking shared by default). + This would cause IMFORT programs to fail to link. (4/23) + +pkg/images/imutil/src/imcopy.x + Changed the imcopy task so that it ignores the output image section + if the input and output root names are the same, making its behavior + consistent with other images package tasks which can overwrite the + input image. (4/24/97, Davis) + + +pkg/images/imgeom/rotate.cl + The nlines parameter was called nrows by mistake in the rotate + script calling sequence. This did not affect the execution of the + task but has been fixed anyway. (4/26/97, Davis) + +sys/ki/kfrnam.x +sys/ki/kfmkcp.x + Fixed a bug in calculating the offset to the second filename. (4/27) + +unix/boot/rtar.c +unix/boot/wtar.c + Fixed a bug where rtar could in some cases confuse tar file directory + entries with links (both have a nonzero linkflag). Also removed the + #ifdef BSDUNIX stuff relating to symbolic links, as I don't know any + modern systems that don't support symlink/lstat. Typing -v now + implies -t for both programs, as with unix tar. (4/29) + +dev/hosts + Added a new sparc machine surya. (4/29/97 MJF) + +pkg/images/immatch/src/geometry/t_geotran.x +pkg/images/immatch/src/geometry/geotran.x + Fixed various bugs triggered by the case where the user sets xmin, + xmax, ymin, or ymax, explicitly, and xmin > xmax or ymin > ymax. + Improved the precision of the flux conservation algorithm at the + same time. (4/30/97 LED) + +pkg/cl/cl.par +unix/hlib/login.cl + Updated the version parameter for V2.11. (4/29) + +pkg/images/tv/display/zscale.x +pkg/images/tv/display/dspmmap.x + 1. Now works with higher dimensional images (displays the first band) + and with image sections. + 2. Now ignores error when the image has an unknown WCS type. The + WCS is mapped to determine the physical coordinate transformation + for use with masks but this failed when someone imported an image + with the CAR projection type. (4/30 FV) + +lib/math/gsurfit.h +pkg/math/gsurfit/*.gx +pkg/math/gsurfit/*.x +pkg/math/gsurfit/doc/gsinit.hlp + Replaced the gsurfit package with a new version which support a + "half" cross terms option useful in computing plate solutions. + There are no package interface changes, old code should compile, + link, and run without changes, and old database can still be + read. Code changes are necessary to make use of the new feature. + (4/30/97 LED) + +pkg/images/immatch/geomap.par +pkg/images/immatch/skymap.cl +pkg/images/immatch/wcsmap.cl +pkg/images/immatch/sregister.cl +pkg/images/immatch/wregister.cl +pkg/images/immatch/doc/geomap.hlp +pkg/images/immatch/doc/skymap.hlp +pkg/images/immatch/doc/wcsmap.hlp +pkg/images/immatch/doc/wregister.hlp +pkg/images/immatch/doc/sregister.hlp +pkg/images/immatch/src/geometry/geoxytran.gx +pkg/images/immatch/src/geometry/geoxytran.x +pkg/images/immatch/src/geometry/t_geomap.gx +pkg/images/immatch/src/geometry/t_geomap.x +pkg/images/immatch/src/geometry/t_geotran.x +pkg/images/immatch/src/psfmatch/rgpbckgrd.x +pkg/images/immatch/src/xregister/rgxbckgrd.x +pkg/images/imcoords/ccmap.par +pkg/images/imcoords/doc/ccmap.hlp +pkg/images/imcoords/src/t_ccmap.x +pkg/images/imcoords/src/t_imcctran.x +pkg/images/lib/coomap.key +pkg/images/lib/geofit.gx +pkg/images/lib/geofit.x +pkg/images/lib/geograph.gx +pkg/images/lib/geograph.x +pkg/images/lib/geomap.h +pkg/images/lib/geomap.key +pkg/images/lib/rgtransform.x + Modifed the geomap, wcsmap, skymap, wregister, sregister, and ccmap + tasks to use the new cross terms option in the gsurfit library. + This involved changing two boolean parameters in each of the above + tasks to string parameters, making the interactive fitting software + shared by all these tasks aware of the change, and modifying the + gsinit calls to do the initialization properly. The default behavior + of all these tasks should be unchanged. (5/1/97 Davis) + +dev/graphcap + Modified the path to qsoli so that it was generic - since there is + only one graphcap file now for SunOS and Solaris there can not be + host dependent path names in this file for these two OSs. Made the + modifications on /shared on gemini and ursa and on tucana. + (5/1/97 jvb) + +unix/shlib/mkshlib.ssol (same as mkshlib.ssol-sc34) +unix/shlib/mkshlib.sos4 +unix/shlib/mkpkg + Modified the shared library build procedures for Solaris and SunOS + to work correctly regardless of the current architecture setting of + the core system. There is no reason that the architecture of the + core system should have to be set to the architecture of the shared + image being built, since the shared image depends only upon the + contents of the BIN directory for the target architecture. This + changes allows the shared library to be rebuilt regardless of the + current architecture of the core system. (5/05) + +dev/hosts + Made the following changes at Nigel's request: + + o added: eagle (new SWN), standard SunOS + o removed: gll1, hedgehog, sandalwood, solara + o change from SunOS to Solaris: enzo, humu, tofu + o also dyevushka is now a Solaris 2.5.1 Sun Ultra + + (5/9/97 MJF) + +pkg/images/tv/display/t_display.x + Fixed a typo in the mode used to map the display frame. When erase + is set the image is now mapped in WRITE_ONLY mode, otherwise it is + mapped READ_WRITE. This is how it previously worked. (5/14/97 MJF) + +unix/boot/spp/xc.c + The -h and -H switches, used to link a host task, now imply -Inolibc + as well. It doesn't make any sense to use IRAF LIBC if a host + program is being compiled and linked. (5/20) + +pkg/images/x_images.x +pkg/images/imcoords/starfind.par +pkg/images/imcoords/doc/starfind.hlp +pkg/images/imcoords/src/starfind.h +pkg/images/imcoords/src/t_starfind.x +pkg/images/imcoords/src/sftools.x +pkg/images/imcoords/src/sfconvolve.x +pkg/images/imcoords/src/sffind.x + The starfind task has been added to the images.imcoords package. + (5/22 LED) + +sys/imio/iki/oif/oifrdhdr.x + Added a check to omit a read if the size of the user area is zero. + This problem showed up as a failure to open imfort images produced + with IRAF V2.10. Imfort images often have no extra header keywords. + (6/01) + +sys/qpoe/qpiorpix.gx +sys/qpoe/qpiogetev.x +sys/qpoe/qpiomkidx.x + Fixed a mistyped pointer problem affecting integer event coordinate + keys. QPOE maintains event pointers internally as pointers to + short, to optimize event filtering where the event extraction fields + are type short. The recently added code to support integer + coordinates was correctly computing an integer offset for the field, + but the short int pointer to the event struct was still being used. + (6/02) + +sys/qpoe/qpiogetfil.x + Changed a few "pargc('s')" type calls to "pargi('s')" ('s' is an + integer not a character). (6/02) + +unix/as.sparc/bytmov.c +unix/as.sparc/amovs.c +unix/as.sparc/amovr.c +unix/as.sparc/amovl.c +unix/as.sparc/amovi.c +unix/as.sparc/amovd.c +unix/as.sparc/amovc.c + Added a check for a no-op copy where the input and output arrays + are the same; the copy operation is skipped in this case. The VOPS + version has always done this, but the optimized version in AS does + not, possibly because the first version of this used a bcopy() which + already had this feature. (6/03) + +unix/as.ssol/bytmov.c +unix/as.ssol/amovs.c +unix/as.ssol/amovr.c +unix/as.ssol/amovl.c +unix/as.ssol/amovi.c +unix/as.ssol/amovd.c +unix/as.ssol/amovc.c + Made the same change for the Solaris versions. This will need to + be propagated to the AS for the other platforms as well. (6/03) + +sys/fmtio/ctod.x + Changed the generic MAX_EXPONENT to MAX_EXPONENTD. (6/05) + +sys/fmtio/ctor.x + Since the exponent for double can now be larger than a real variable + can support, added a log10(x) > MAX_EXPONENTR check before converting + the value returned by ctod to a real. (6/05) + +dev/graphcap + Installed graphcap support for the STSDAS Postscript graphics kernel. + The actual kernel is still installed in STSDAS and its behavior is + unchanged. (6/06) + +sys/osb/ieee.gx +unix/as.sparc/ieee.gx +unix/as.ssol/ieee.gx + 1. Added a new interface routine ieegmap, used to query the current + input and output NaN-mapping flags. + 2. Changed the name of the old "ieemap" to "ieesmap" for consistency + with ieegmap. The old ieemap is retained for backwards compatibility. + + 3. [INTERFACE CHANGE] ieesnan no longer has the side affect of + enabling mapping by calling ieemap. (6/06) + + Note that all of these routines have both double and real versions + and that mapping must be handled separately for the two types. + (Although we use generic language above, there is no ieesmap, you + really have ieesmapr and ieesmapd). For example, enabling input + mapping for real data will not enable it for double as well. + +pkg/dataio/doc/export.hlp +pkg/dataio/export/excmap.x +pkg/dataio/export/cmaps.inc + Added the 'overlay' cmap as a builtin cmap. (6/6/97) + +pkg/dataio/export/expreproc.x + Removed a call to scale the colormaps when using the default values. + Cmaps are now only scaled when a brightness/contrast value is set in + the setcmap() function. (6/6/97 MJF) + +pkg/dataio/export/bltins/exgif.x + Fixed a small error in the output of GIF files causing some display + programs to complain. GIF images which would now be an odd number of + bytes have an extra trailing ';' delimiter. This should be harmless + as all processing is supposed to stop once that char is found. (6/6/97 MJF) + +pkg/dataio/rfits.par +pkg/dataio/wfits.par +pkg/dataio/doc/rfits.hlp +pkg/dataio/doc/wfits.hlp +pkg/dataio/fits/fits_cards.x +pkg/dataio/fits/fits_files.x +pkg/dataio/fits/fits_params.x +pkg/dataio/fits/fits_read.x +pkg/dataio/fits/fits_rheader.x +pkg/dataio/fits/fits_rimage.x +pkg/dataio/fits/fits_rpixels.x +pkg/dataio/fits/fits_wheader.x +pkg/dataio/fits/fits_wimage.x +pkg/dataio/fits/fits_wpixels.x +pkg/dataio/fits/fits_write.x +pkg/dataio/fits/mkpkg +pkg/dataio/fits/rfits.com +pkg/dataio/fits/rfits.h +pkg/dataio/fits/t_rfits.x +pkg/dataio/fits/t_wfits.x +pkg/dataio/fits/wfits.com +pkg/dataio/fits/wfits.h + Installed new versions of rfits and wfits. The new rfits and wfits + include support for: 1) reading and writing multi-extension fits files, + 2) reading and writing global headers, 3)and reading and writing ushort images. (6/9/97 LED) + +pkg/images/immatch/wcsxymatch.par +pkg/images/immatch/wcsmap.cl +pkg/images/immatch/wregister.cl +pkg/images/immatch/doc/wcsxymatch.hlp +pkg/images/immatch/doc/wcsmap.hlp +pkg/images/immatch/doc/wregister.hlp +pkg/images/immatch/src/wcsmatch/t_wcsxymatch.hlp + Added the transpose parameter to the wcsxymatch, wcsmap, and wregister + task to permit users to force an image transpose in cases where the + image wcs does not contain enough information, e.g. axtype is undefined + or set to the same units. (6/10/97, Davis) + +pkg/images/tv/imexamine/stfmeasure.x + 1. The background is now set to zero if there are no background points. + 2. Fixed an error recovery bug (attempting to free a pointer which + was not set). + (6/11/97, Valdes) + +pkg/images/tv/imexamine/ierimexam.x + The background widths needed to be passed to the PSF measuring routines + even if the background is turned off for the fitting in the 'a' and 'r' + keys. (6/11/97, Valdes) + +dev/hosts + Changed the following DMAC machines: + - anasazi, sol, mimbres, prometheus are now solaris + - changed path for dyevushka and humu + (6/15/97 MJF) + +pkg/images/lib/skywcs.x + Modified the code to initialize the physical and logical axis maps + to 1 and 2 respectively. (6/16/97) + +pkg/dataio/imtext/t_wtextimage.x + Cleared the format arrays prior to using them so old format strings + are overwritten. (6/17/97 MJF) + +pkg/dataio/fits/fits_read.x + Changed the code to add the extension number (as intended) not + the sequence number to the output file name if appropriate. + Removed some extraneous error messages from the output. (6/18/97 LED) + +pkg/dataio/fits/fits_write.x + The IRAFNAME keyword was not being initialized properly for the + global headers resulting in gargage being written into this + variable. (6/18/97 LED) + +unix/hlib/irafuser.csh + Added the flag -Inolibc to HSI_XF. The HSI C files are host level + and do not use libc. (6/17) + +unix/hlib/libc/knames.h +unix/os/zcall.c +unix/os/zfunc.c + Added zcall and zfunc routines for calls with ten arguments. The + new functions are called zfunca,zcalla (A is hex for 10; hex is used + to avoid 7 char names in kernel routines). (6/17) + +lib/syserr.h +lib/syserrmsg + Installed system error messages for the FITS kernel. (6/17) + +pkg/images/imutil/imheader.par +pkg/images/imutil/src/imheader.x +pkg/images/imutil/src/mkpkg + 1. Typing "imhead" with no arguments now lists the images in the + current directory (like "ls"). + 2. A new parameter "imlist" was added to support the above. + 3. Imheader now left-justifies text to avoid truncating long cards. + 4. The method used to test for a pixel file was changed to avoid + any pixel i/o. + +sys/imio/iki/fxf/ + Installed the new FITS image kernel. (6/16) + +sys/imio/iki/iki.com +sys/imio/iki/iki.h +sys/imio/iki/ikiaccess.x +sys/imio/iki/ikiclose.x +sys/imio/iki/ikicopy.x +sys/imio/iki/ikidelete.x +sys/imio/iki/ikiextn.x + +sys/imio/iki/ikiinit.x +sys/imio/iki/ikildd.x +sys/imio/iki/ikimkfn.x +sys/imio/iki/ikiopen.x +sys/imio/iki/ikiopix.x +sys/imio/iki/ikiparse.x +sys/imio/iki/ikirename.x +sys/imio/iki/ikiupdhdr.x +sys/imio/iki/mkpkg + 1. "imtype" now has a syntax such as "imtype=oif,noinherit" or + "imtype=imh", "imtype=fits". The default image type can be + specified either by any legal image extension or by giving the + internal kernel name (oif, fxf, plf, qpf, stf). If "inherit" is + enabled then the image type will be preserved in a new-copy + operation, as in pre-V2.11 versions of IRAF. The default in V2.11 + is OIF images with no inherit. No inherit means new images always + are of type imtype. + + 2. A new environment variable "imextn" specifies the mapping of + image file extensions to image types. For example, + imtextn = "oif:imh fxf:fits,fit plf:pl qpf:qp stf:hhh,??h" + Kernel names must be used here. For each kernel the list of valid + extensions or extension patterns is given. The first extension for + each type is the default extension when creating new images of that + type. + + 3. A "kernel" argument was added to many of the IKI routines. This + change was propagated to all the image kernels. + + 4. The fits kernel (fxf) was added to ikiinit. A call to + iki_extninit was added to ikiinit. imtype/imextn are only read + once, when the first image is accessed. A flpr is needed to use + the new values if the variables are changed at runtime after images + have been accessed. + + 5. The extension processing code is in the new file ikiextn. + (6/16) + +sys/imio/iki/oif/mkpkg +sys/imio/iki/oif/oifaccess.x +sys/imio/iki/oif/oifcopy.x +sys/imio/iki/oif/oifdelete.x +sys/imio/iki/oif/oifopen.x +sys/imio/iki/oif/oifrename.x +sys/imio/iki/plf/plfaccess.x +sys/imio/iki/plf/plfcopy.x +sys/imio/iki/plf/plfdelete.x +sys/imio/iki/plf/plfopen.x +sys/imio/iki/plf/plfrename.x +sys/imio/iki/qpf/qpfaccess.x +sys/imio/iki/qpf/qpfcopy.x +sys/imio/iki/qpf/qpfdelete.x +sys/imio/iki/qpf/qpfopen.x +sys/imio/iki/qpf/qpfrename.x +sys/imio/iki/stf/mkpkg +sys/imio/iki/stf/stfaccess.x +sys/imio/iki/stf/stfcopy.x +sys/imio/iki/stf/stfdelete.x +sys/imio/iki/stf/stfhextn.x +sys/imio/iki/stf/stfopen.x +sys/imio/iki/stf/stfrename.x + Numerous changes related to adding imtype/imextn, and adding a + kernel argument to the IKI driver entry points. (6/16) + +sys/imio/mkpkg +sys/imio/imaccess.x +sys/imio/imgimage.x +sys/imio/imgnln.x +sys/imio/imparse.x +sys/imio/impnln.x +sys/imio/iki/stf/stfopen.x + If the image number in a multi-extension group is not given this is + indicated by a value of -1. Formerly 0 was used. The listed + routines had to be changed to implement this. (6/16) + +sys/imio/imstati.x + An imstati on IM_PIXFD will now attempt to open the pixel file if + it is not already open. This is used by the revised IMHEADER task + to test for a pixel file. (6/17) + +--------------------------------- +V2.11 beta-2 released. (6/18) + +pkg/dataio/fits/fits_read.x + Fixed an error in the call to pl_gsize (output variable set to + constant) that was causing a segvio on Solaris. (6/19 LED) + +pkg/images/imutil/src/imheader.x +sys/imio/imstati.x + Removed the code from imstati to open the pixel file in an IM_PIXFD + query; ideally imstat should be purely an information service with + no action side effects. Instead, added an imopsf call in imheader + to test if the pixel file exists (this is done only if IM_PIXFD=NULL). + imopsf was not really intended to be in the public interface of IMIO, + but we can live with this for the system imheader task. (6/19) + +sys/imio/iki/fxf/fxfopen.x + Fixed a bug that would affect opening of simple (not multi-extension) + FITS files without specifying an extension. (6/19) + +sys/imio/iki/oif/oifopen.x +sys/imio/iki/plf/plfopen.x +sys/imio/iki/qpf/qpfopen.x + These kernels were updated to check the image extension index and + abort if an illegal extension is referenced. For a simple file with + one image the only extension permitted is [1] (or -1 which is what + the kernel gets if no extension is specified). Trying to open [0] + or [2] or higher is an error. This is necessary to provide a kernel + independent behavior if other kernels may support multiple extensions. + + There are still two unresolved issues here. The first is that STF + was not also updated, so its behavior is inconsistent compared to + the other kernels ([0] or [1] or not given will all return the first + image). This could not be modified due to the risk to STSDAS and + the tight schedule we have for V2.11. The second problem is that + the FITS kernel used in the simplest manner will produce a + multi-extension file with [0] as the first image. In this mode the + FITS kernel has images starting at [0] whereas the first image is + [1] for the other kernels. This is less of a problem if the PHU of + a FITS MEF file is a dataless file header, in which case the first + image is [1], and [0] is the file header, not an image. But there + is an inconsistency. Perhaps the default behavior of the FITS + kernel should not so easily create a multi-extension file with a PDU + instead of a dataless PHU. We might want to change the default + behavior to add a file PHU when a multiextension FITS file is + created, or add a kernel switch to force creation of a PHU. Simple + FITS files would remain a simple PDU with no extensions. Currently + the only way to get a PHU MEF file with the FITS kernel is to use + special facilities to write a dataless PHU before appending a data + image. (6/19) + +sys/ki/ki.h + Increased the max nodes from 256 to 320. This code needs to be + rewritten to use a dynamic table to eliminate this upper limit, + and improve efficiency. (6/19) + +pkg/images/imutil/doc/imheader.hlp + Modifed the imheader help page to include a description of the + new imlist parameter. (6/20 LED) + +pkg/dataio/wfits.par +pkg/dataio/fits/t_wfits.x +pkg/dataio/help/wfits.hlp + Added the parameter fextn to the wfits task. Wfits will append the + current value of fextn to any output disk files so that they + can be read with the fits kernel. The default value of fextn is "fits". + (6/20 LED) + +pkg/dataio/fits/t_wfits.x + Added a check to wfits so that it does not append a ".fextn" to + an output file name which already ends in ".fextn". + (6/21 LED) + +unix/boot/spp/xc.c + Modified the "isv3" code to be more flexible about the configuration + of the host compiler. (6/22) + +sys/qpoe/qpex.h + Increased DEF_PROGBUFLEN and DEF_DATABUFLEN to 65536. (6/22) + +sys/imio/iki/oif/oifopen.x +sys/imio/iki/plf/plfopen.x +sys/imio/iki/stf/stfopen.x + Added support for "imclobber" to these kernels (images can be + overwritten if imclobber=yes). The FITS kernel (fxf) already had + imclobber implemented. QPF is read-only so it is not an issue. (6/22) + +sys/mwcs/mwrotate.x + The sign of the x,y center of rotation was wrong in a call to + mw_translated. (6/22) + +sys/mwcs/mkpkg +sys/mwcs/mwcs.h +sys/mwcs/iwewcs.x +sys/mwcs/iwrfits.x +sys/mwcs/mwsaveim.x +sys/mwcs/wfait.x +sys/mwcs/wfcar.x +sys/mwcs/wfcsc.x +sys/mwcs/wfdecaxis.x +sys/mwcs/wfgls.x +sys/mwcs/wfinit.x +sys/mwcs/wfmer.x +sys/mwcs/wfmol.x +sys/mwcs/wfpar.x +sys/mwcs/wfpco.x +sys/mwcs/wfqsc.x +sys/mwcs/wfstg.x +sys/mwcs/wftsc.x +sys/mwcs/wfzea.x + 1. Added support for galactic, ecliptic, and super-galactic coordinates + to MWCS. + 2. Added the STG, ZEA, CAR, MER, PCO, PAR, AIT, MOL, CSC, QSC, TSC + projection functions to MWCS. These functions do not require any + projection parameters. We are using the G&C defaults for LONGPOLE + and LATPOLE. The CUBEFACE parameter in the COBE CSC, QSC, and TSC + projections is ignored for now since it is not required to evaluate + the functions. (6/22) + +unix/hlib/math.h + Added explicitly DOUBLE versions of the math constants. (6/22) + +pkg/images/imcoords/doc/imcctran.hlp + Modified the imcctran help page to reflect the 2.11 mwcs changes, + e.g. support for galactic, supergalactic, and ecliptic coordinates, + and the new function drivers. (6/23 LED) + +unix/boot/spp/xpp/decl.c + The line counter was not being updated in multiline declarations. + This would mess up SPP source code debugging. (6/23) + +pkg/system/rename.x +pkg/system/doc/rename.hlp + 1. The field=extn option can now add file extensions where none + existed before, or remove them. + 2. The filename field editing capability now works for single file + renames as well as file lists. (6/23) + +sys/imio/iki/ikiopen.x + Add an errchk for zcalla. Doesn't appear to matter in this case, + but there should be one as otherwise assumptions are made about the + value of the status argument when an error abort occurs. (6/23) + +sys/imio/iki/stf/stfopen.x +sys/imio/iki/plf/plfopen.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfksection.x +sys/imio/iki/oif/oifopen.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x + 1. Fixed a bug in fxfopen that was causing PHU inheritance to fail. + 2. Tweaked imclobber handling in all kernels. Fixed a bug related + to dev$null images in oif and plf. + 3. Some minor coding style changes, spelling errors. (6/23) + +pkg/images/x_images.x +pkg/images/imcoords/imcoords.par +pkg/images/x_images.x +pkg/images/imcoords/imcoords.cl +pkg/images/imcoords/imcoords.men +pkg/images/imcoords/imcoords.hd +pkg/images/imcoords/ccfind.par +pkg/images/imcoords/doc/ccfind.hlp +pkg/images/imcoords/src/t_ccfind.x +pkg/images/imcoords/src/mkpkg + Installed the new ccfind task in the images.imcoords package. + (6/24 LED) + +sys/imio/iki/fxf/fxfopen.x + More fixes to the fkinit/inheritance logic in the FITS kernel. (6/24) + +sys/imio/iki/ikiextn.x + 1. Modified the iki_extninit code to preserve the default extensions + for kernels not specified in a user defined imextn string. If the + user specifies extensions for a given kernel these however override + the builtin defaults (note though that not all kernels permit + arbitrary file extensions - fxf and stf are the main ones that do). + + 2. Added a new routine iki_debug. The init code was modified to check + for an environment variable "ikidebug". If this is defined and has + a yes value the IKI data structures are dumped at init time, allowing + the list of installed kernels and the mapping of extensions to kernels + to be reviewed. (6/24) + +sys/imio/iki/fxf/fxfrename.x +sys/imio/iki/fxf/fxfdelete.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfrfits.x + We had a problem with "rfits make-" failing with imtype=fits. This + opens dev$null as the image and a kernel must be able to deal with + this odd situation. There was a problem with the internal header + cache code as some of the code was searching the cache, but since we + were opening a new image the cache had not been initialized (it is + initialized in rfitshdr). Added a new routine iki_init in + fxfopen.x, and calls to this in all the external entry points for + the fits kernel. On the first call after a process startup, this + initializes the cache to empty and sets rf_cachesize=0 (the cache is + subquently reinitialized by rfitshdr). A number of instances of + the construct "do i = ... max(1,rf_cachesize)" were changed to + "do i = ... rf_cachesize" as otherwise the loop does not notice + that the cache is disabled. (6/25) + +unix/boot/spp/xpp/xppcode.c + Increased the output code buffer from 50000 to 131072. (6/25) + +dev/graphcap + The pen width parameter PW for sgi_apl was changed from 2.4 to 2.3. + This was fine tuning for the SGIKERN font changes below. (6/25) + +sys/gio/sgikern/mkpkg +sys/gio/sgikern/sgifont.x +sys/gio/sgikern/sgitx.x +sys/gio/sgikern/greek.com + +sys/gio/sgikern/font.com +sys/gio/sgikern/sgidrawch.x + The SGI graphics kernel was upgraded with a better roman font, and a + new greek font was added. Aside from the above minor change to + graphcap this should be transparent to anything outside sgikern. (6/25) + +unix/hlib/zzsetenv.def + Added an "imextn" entry to the default IRAF environment so that the + user can do a "show imextn" to see the current mappings of image + extensions to image kernels. (6/25) + +--------------------------------- +V2.11 Beta-2 installed on NOAO servers. (6/25) + +unix/hlib/zzsetenv.def + 1. Added "imclobber = no". + 2. Changed imtype to "oif,noinherit" to better document the new syntax. + (imtype=imh, imtype=fits etc. will still work so long as these are + valid extensions in imextn). + 3. Changed version from beta1 to beta2. (6/26) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2ueps.c + These routines could generate a "0 setlinewidth" in the output + postscript, which could cause a plot to abort without generating + any output. Added a simple max(1) to prevent this, without changing + the way a linewidth is scaled. (6/27) + +lib/syserr.h +lib/syserrmsg + Added a new error code SYS_IKIKSECTNS, used when a kernel section + is entered but it is invalid, e.g. because the kernel does not + support the image section syntax given. (6/28) + +sys/imio/iki/oif/oifopen.x + Now returns an error if the given kernel section is not legal. (6/28) + +sys/imio/iki/stf/stfopen.x + The imclobber stuff introduced a serious bug preventing image + sections such as "imcopy blah pix[3]" from being used to write a + multi-extension STF file (e.g. created with pix[1/4]). Modified + stfopen to permit such usage. Imclobber checking is only performed + if the whole file is affected. If an individual image is explicitly + referenced it can be overwritten and is not affected by imclobber. + (6/28) + +unix/hlib/zzsetenv.def + Set imtype back to "imh". Unfortunately we have IMRED scripts which + parse the value of imtype (an interface violation since it makes the + scripts dependent on details of the image kernels). Until these can + be fixed imtype will have to be left as it is. (6/29) + +sys/gio/sgikern/greek.com + Updated the greek fonts in the SGI kernel to a newer version. (6/29) + +pkg/images/imutil/src/imexpr.gx +pkg/images/imutil/src/imexpr.x + Fixed a bug affecting generating functions using I,J,K. (6/29) + +sys/imio/iki/fxf/fxfksection.x +sys/imio/iki/fxf/fxfopen.x + 1. Bug fix to avoid "unexpected EOF" error when reading dataless + PHU files. + 2. The extension number and extension name should now be + interchangeable in kernel sections. (6/29) + +lib/syserr.h +lib/syserrmsg + Added several new error messages for the FITS image kernel. (6/29) + +sys/mwcs/wfinit.x + Removed a bogus "msp" entry from the MWCS function table. This was + an alias for the older multispec. (6/30) + +--------------------------------- +V2.11 Public BETA release. (6/30) + +dev/hosts + Added 'sunset' to all downtown servers (7/2/97 MJF) + +dev/hosts + Changed path for 'deneb' (7/7/97 MJF) + +unix/hlib/zzsetenv.def + There was a typo (extra double quote) in the definition of imextn. + (7/24) + +pkg/images/imcoords/src/ccxytran.x +pkg/images/immatch/src/geometry/geoxytran.gx +pkg/images/immatch/src/geometry/geoxytran.x +pkg/images/immatch/src/geometry/t_geotran.x + Fixed a bug in the database reading code used by the cctran and + geoxytran tasks that was producing an "illegal xorder" message + if the x coordinate fit was linear and the y coordinate fits was + nonlinear or vice versa. (7/24/97 LED) + +pkg/images/immatch/src/xregister/rgxcorr.x + Fixed an initialization problem in the xregister task that ocurred + if: 1) the correlation parameter was set to "fourier", and, 2) one + of the correlation regions was entirely off the input image. In this + case all subsequent region shifts were being set to INDEF regardless + of whether or not the region was actually on the image. (7/25/97 LED) + +sys/libc/imaccess.x + +sys/libc/mkpkg + Added a new LIBC entry point "c_imaccess" which calls the IMIO imaccess + routine. (7/25) + +unix/hlib/libc/xnames.h + Added an entry for IMACCESS. (7/25) + +pkg/cl/unop.c +pkg/cl/param.h +pkg/cl/param.c +pkg/cl/operand.h +pkg/cl/builtin.c +pkg/cl/gram.c + Added two new intrinsic functions, "imaccess" and "defvar". imaccess + tests whether an image exists, e.g. (imaccess("dev$pix")) or + (imaccess(foo.fits[3])). defvar tests whether an environment variable + exists, e.g. (defvar("imextn")). (7/25) + +pkg/images/imcoords/doc/ccfind.hlp + Fixed a typo in the ccfind task help page. (7/28 LED) + +pkg/math/gsurfit/zzdebug.x + Added a zzdebug.x file to the gsurfit package. (7/28 LED) + +sys/imio/iki/stf/stfopen.x + Added a max(0,gr_arg) to map gr_arg values of -1 to 0 for use within + the STF kernel. (7/29) + +sys/imio/iki/stf/stfhextn.x +sys/imio/iki/fxf/fxfhextn.x + These routines will now inherit the file extension in a new-copy + operation only if inherit is enabled in "imtype". (7/29) + +sys/imio/iki/ikiextn.x + Added a new IKI extn routine iki_getpar(), used by IMIO code to + get IKI global parameters (such as inherit/defimtype). (7/29) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxf.h + 1. When a new FITS file is created the value of the EXTEND keyword + in the PHU is now set to F. When an extension is subsequently + added it is changed to T. + 2. A bug was fixed affecting files with many (hundreds) of extensions. + 3. A dev$null related bug was fixed (seen when displaying an image + with imtype set to fits). (7/29) + +noao/lib/mkpkg.sf + Fixed a typo in the $ifeq MACH section. (7/29) + +sys/gio/sgikern/font.com + Updated to a new version of the font file which improves the + inter-character spacing. (7/29) + +pkg/images/immatch/src/geometry/geotran.x + Some min/max statements were reordered in geo_imset to work around an + optimiser bug seen on Solaris. Normally this should have been fixed + by putting the file on the special file list, but since geotran is + very compute intensive the source file was modified instead. (7/29) + +pkg/images/imutil/src/hedit.x + Added a missing sfree() in he_deletefield(). (7/29) + +sys/imio/db/imgftype.x +sys/imfort/db/imgftype.x + Modified to check for a quoted string before checking if the keyword + is boolean (T/F). (7/29) + +--------------------------------- +V2.11 Public BETA release, patch-1. (7/29) + +pkg/images/imutil/src/imhistogram.x +pkg/plot/phistogram.x + Fixed a bug in the imhistogram and phistogram tasks that could produce + invalid floating point operation errors if the image pixel values are + outside the legal integer range. (7/31 LED) + +sys/imio/iki/fxf/fxfksection.x + There was a typo on line 177, PHULINES should have been EHULINES. + (7/31) + +pkg/dataio/fits/fits_read.x + Fixed a bug in the new global header reading code that could + result in the global image header being left in the tmp$ directory. + (8/6 LED) + +dev/emacs.ed + Fixed an ambiguity affecting MOVE_LEFT and DEL_CHAR. Added ctrl/d + as a second eof char (along with ctrl/z) as for vi.ed. (8/07) + +sys/imio/iki/fxf/fxfrfits.x + Fixed a bug which would cause unwanted blank lines to be added to a + header generated with INHERIT=T when there are blank lines near the + top of the existing extension header. (8/08) + +sys/mtio/mtrewind.x + The sequence close(mtopen()) was being used to rewind a device. + The close could fail due to an invalid file descriptor if the mtopen + failed, as when opening a device and no tape was loaded. Modified + to do the close only if the open succeeds. An attempt to rewind a + device when no tape is loaded will still fail with a "cannot open + device" message. There is no way to tell that a tape is not loaded. + (8/08) + +pkg/cl/builtin.c + [This was the solution to the so-called "imdkern" bug]. Stty has + the unusual side affect of writing to environment variables (to set + the screen size etc.). Environment variables set in the CL are + automatically passed to all connected subprocesses. This can cause + corruption of the IPC prototcol when stty is called in response to a + pagefiles() call in a running task and a connected graphics kernel + is running at the time. The safest thing is to have stty shutdown + any connected graphics kernels before executing, so a call to gflush + was added to the stty code in the CL. (8/10) + +sys/qpoe/qpaddf.x + A symbol reference (dsym) was being made before a stenter, but the + latter could cause symbol pointers to change. The code was reorganized + slightly to do the stenter before taking any symbol references. (8/10) + +sys/imio/iki/oif/oif.h +sys/imio/iki/oif/oifopen.x + The OIF kernel now recognizes an environment variable "oifversion" + which, if defined, specifies the file version for a new OIF image + (for example set oifversion = 2 produces format version 2 images). + If the variable is not defined, which is the default, the builtin + OIF default will be in effect and new-format images will be + generated. This variable is provided only for backwards + compatibility, e.g. when using V2.11 IRAF with old software which + cannot easily be updated. (8/10) + +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfctype.x +sys/imio/iki/fxf/fxfksection.x + 1. A bug was fixed that would leave open file descriptors behind + when trying to open extensions beyond the EOF, e.g. when searching + for the last extension in a file. + 2. An operation such as "imcopy foo.fits[3] new.fits" would fail + with imclobber=yes if "new.fits" already existed, due to a problem + with error recovery. + 3. A new fkinit parameter "padlines" was added. Along with the + existing "ehulines" this permits control of the number of blank + lines at the end of a header (used for expansion). Whereas ehulines + defines the minimum size of an extension header when a new extension + is added, padlines defines the number of lines of padding to be + added when a EHU overflows and has to be extended. + 4. The FK code supporting FILENAME was deleted. It is difficult + for the FK to maintain this reliably (e.g. if a temp image is created + and later renamed), and it is felt that it is better to let the + application which creates FITS files control this parameter. If the + FK insists on writing it this interferes with the use of FILENAME by + the application. (8/11) + +sys/imio/iki/fxf/fxfrfits.x + A buffer was improperly dimensioned affecting the OBJECT keyword. + This could cause long image title strings to be truncated. SZ_EXTTYPE + was changed to SZ_CARD on line 708. (8/12) + +lib/prstat.h +unix/hlib/libc/prstat.h + A new process status value P_BUSY was added. (8/13) + +sys/etc/prseti.x + + A prseti routine was added to the process control interface, which + already provided a prstati. (8/13) + +sys/etc/mkpkg +sys/etc/prupdate.x + The prupdate routine, used to broadcast messages/commands to all + subprocesses (e.g. for set environment or chdir requests), was + modified to check the process status and only broadcast to processes + for which the process status is P_RUNNING. The process status for + a running process can now be set to either P_BUSY or P_RUNNING. + P_RUNNING indicates that the process is running, but is idle and + read to accept commands. P_BUSY means that it busy executing in a + mode where it cannot accept standard IPC requests. (8/13) + +sys/etc/prclose.x + Prclose will now close any process for which the process status is + other than P_DONE or P_DEAD, that is, any running process. (formerly + it was checking for status=P_RUNNING but we now have to allow for + P_BUSY as well). (8/13) + +sys/gio/cursor/mkpkg +sys/gio/cursor/gtropenws.x + When a graphics subkernel is connected to the CL the process status + is now set to P_BUSY. Graphics subkernels execute in a loop reading + GKI instructions and cannot accept standard IPC requests, such as + environment change requests, without corrupting the IPC protocol. + (8/13) + +pkg/cl/config.h + Increased a couple of history buffer sizes. In particular SZ_CMDBLK + is supposed to be larger than a line buffer and it wasn't after the + recent increase in the line buffer size. SZ_CMDBLK was increased + from 512 to 2048, and the history buffer size was increased from 2048 + to 8192. (8/14) + +pkg/images/immatch/src/imcombine/t_imcombine.x + Fixed a segmentation violation caused by attempting to close the + mask data structures which are not defined if an error occurs opening + the input or output images. (8/14 FV) + +pkg/system/rename.x +pkg/system/rename.par +pkg/system/doc/rename.hlp + The rename task was rewritten to hopefully make the code clearer and + easier to follow. The task now checks for the $/ characters in + root or extn replacement strings and prints an error message if either + of these characters are found. For completeness the field-editing + feature now permits "ldir" to be modified as well as "root", "extn", + and "all" (modifying the ldir part of a filename is another way to + move the file to the named directory). (8/15) + +doc/notes.v210 + +local/notes.v210 - +local/notes.v211 + + Broke the old notes.v210 into a frozen v2.10 notes file and a new + notes.v211 file for IRAF V2.11 and revisions. (8/15) + +unix/hlib/motd +unix/hlib/zzsetenv.def + System version changed to V2.11EXPORT. (8/15) + +unix/hlib/mkiraf.csh + For the NOAO servers we use a version of mkiraf which permits imdir + to include hostnames, e.g. imdir=tucana!/d0/iraf (this is not + currently included in the export version of the system). It turns + out that while this mkiraf script was setting imdir correctly in the + login.cl, it was not actually creating the directory if it didn't + exist. The local version of mkiraf was modified to use the iraf + version of mkdir in x_system.e. This avoids the problem with host! + and the unix csh/mkdir, and also works when the directory is on a + different host than the one executing the script. (8/16) + +pkg/images/imcoords/src/sffind.x + Fixed a type mismatch in a call to atan2. (8/18 LED) + +sys/imio/iki/fxf/fxfrfits.x + In fxf_load_header, the calculation of "totpix" could overflow a 32 + bit integer for large (e.g. 8K by 8K) images. The calculation was + changed to avoid overflow. A bug was also fixed affecting the use + of PCOUNT in the expression. The value returned for "totpix" is not + actually the total pixels in the image as the name suggests, but the + size in 2880-byte FITS logical blocks of the data area of the image, + the data area being the pixel matrix plus PCOUNT data units. At the + moment we want to minimize changes, but later we should make more + general modifications to the code to change the name of this + variable to something more descriptive. (8/18) + +unix/boot/wtar/wtar.c + Added a call to memset to zero the file header structure before + setting the field values. Unix tar on at least one platform (Digital + Unix) was complaining about unused fields of the tar file headers. + (8/20) + +dev/hosts + Added the Jannuzi/Dey machine chomper to all servers (8/20 MJF) + +dev/hosts + Added beet (Sol2.4 machine), mosaic machines rush and driftwood + along with all their aliases (8/20 MJF) + +bin.ssun/S11_5.4.e + + Added a V2.11 shared image linked for Solaris 2.4. (8/20) + +pkg/images/tv/display/dspmmap.x + There was a bug in the code when using pixel masks which gives + "Warning: PLIO: reference out of bounds on mask". This was + introduced with the changes to allow masks and images to have + different binning. (8/21 FV) + +sys/mwcs/iwewcs.x + In the case of an image with more than 2 axes where CDELT/CROTA is + used instead of a CD matrix, the CDELT value for axes other than + the RA/DEC projection axes (or axes 1-2 if no projection) was + being discarded and replaced with cdelt=1.0. (8/21) + +pkg/images/imutil/src/t_imtile.x + Fixed a bug in the range decoding code that could produce an integer + divide by 0 if the range syntax in xtools$ranges.x was extended to + include zero (8/22 LED). + +pkg/cl/config.h + Increased the size of the stack and dictionary. The V2.11 changes to + SZ_FNAME affect storage allocation in compiled scripts, hence under + V2.11 scripts will use more space than they used to. (8/27) + +sys/mwcs/mwcs.h + Increased LEN_FC (the size of the compiled function call portion of + a runtime CTRAN descriptor) from 48 to 64. This descriptor is + internal to MWCS and the change should have no effect outside the + interface. (8/28) + +dev/graphcap +dev/imtoolrc + Updated a few of the KPNO instrument frame buffer entries in graphcap + and imtoolrc. Affected were cn# 26,27, 35-40. No others were + affected, only these KPNO-specific entries. (8/28) + +sys/imio/iki/fxfopix.x + Fixed a typo: IM_LEN(im) -> IM_LEN(im,1). Evidently the Sun Fortran + compilers didn't complain about this (it was found on AIX). (8/29) + +pkg/images/tv/imexamine/iepos.x + Added missing argument in fprintf call. (8/29/97, Valdes) + +pkg/images/imcoords/src/ccfunc.x +pkg/images/imcoords/src/t_ccsetwcs.x +pkg/images/imcoords/src/skyctran.x + Removed extraneous argument from 2 call to mw_stati. Removed extra + arguments from 2 call to printf. (8/29/97, Davis) + +pkg/images/lib/skywcs.x + Added missing argument to fprintf call. (8/29/97, Davis) + +pkg/images/immatch/src/linmatch/rglcolon.x + Added missing argument to call to rg_lstats. (8/29/97, Davis) + +pkg/cl/prcache.c + The pr_unlock() function was comment out. This has never caused a + problem as the CL does not currently use this interface routine, + however it was causing a compiler error on one platform due to a + malformed comment, so it was uncommented. (8/29) + +pkg/plot/impstatus.x + In sl_getstr, changed "Memc[sl]" to "int(Memc[sl])" to fix a mixed + type mod function problem. This routine is a bit on in that it stores + a variable nlines, the number of status line lines, in a char variable + in a char array (but it should work). (8/29) + + +--------------------------------- +V2.11 Public EXPORT release. (8/29) + +sys/imfort/imfort.h +sys/imfort/imcrex.x + Added support for the "oifversion" environment variable to IMFORT. + This is identical to what is in IMIO. The default is version 2 (new) + format images. (9/05) + +sys/imfort/imwrhdr.x + In the process of making the above fairly simple addition I found a + bug in writing V1 headers: IM_V1HDRLEN was not getting set correctly + as the pointer was "im" instead of "v1". This was preventing imfort + from writing valid V1 image headers (and it appears that IMIO may have + the same problem as well, seen as the user fields of the header not + being written, although other code may patch up the header field later + in the case of IMIO). We did not see this problem earlier in IMFORT + since it had no way to write V1 format images. (9/05) + +sys/imfort/db/imgnfn.x + In the process of making the above fairly simple addition I found + another header related bug, this one appears to have been there for + some time. The phead.f test IMFORT task was only printing the + standard fields of the header, not the user fields, although it was + supposed to print the full header. Updated the relevant section of + code in the IMFORT version of db/imgnfn.x with the code from the + IMIO version of the file, which does not have this problem. (This + causes a problem in phead.f now when it encounters a HISTORY card, + but I think that is a problem with the task, not with imfort). (9/05) + +unix/hlib/strip.iraf + Changed the -file entry for bin.ssol to bin.ssun. (9/22) + +pkg/utilities/urand.x +pkg/utilities/doc/urand.hlp + If the "seed" parameter is set to INDEF then the clock time (integer + seconds since 1980) will be used as the seed. This allows different + executions to produce different random numbers. (9/23, Valdes) + +local/login.cl + Updated logver to "IRAF V2.11 May 1997". (9/24) + +pkg/images/immatch/src/imcombine/icscale.x +pkg/images/immatch/doc/imcombine.hlp + When the zero offsets or weights are specified in a file the weight + adjustment for differeing sky levels is not done. (10/3/97, Valdes) + +pkg/plot/phistogram.x + Fixed an error in the previous bug fix that was causing phistogram + to die with a segmentation violation for text file input. (10/4, Davis) + +dev/hosts + Removed dyevushka, changed virgo to ssun, added mogollan as a ssun + for GONG and zippy as my home linux box. (10/17 MJF) + +pkg/images/immatch/src/imcombine/t_imcombine.x + When using STF images the failure error when there are too many images + is SYS_IKIOPEN rather than the others that occur with OIF, etc. + Added this error code to be caught and have the program build a + stacked image to combine. (10/21/97, Valdes) + +dev/hosts + Changed argo to a solaris machine (10/28/97 MJF) + +pkg/dataio/fits/fits_read.x + Fixed a bug in the tape listing code that was causing the entire + file to read instead of skipped if: 1) make_image = no, 2) there + was only 1 image per file, and 3) fe = 0. (11/3/97 LED) + +dev/hosts + Added new-tucana for testing (11/6/97 MJF) + +dev/hosts + Cleaned up the hosts file according to Nigel's list: + Solaris: aquarius, aten, bokchoy, carina, chomper, corvus, enzo, + herbie, humu, inti, kukita, kumbhakarna, mdi, mozart, norma, + oso, potosi, saguaro, soi, soleil, tofu, virgo, xari. + SunOS: arun, aspen, bruckner, caelum, charfman, condorito, eagle, + grus, jalapeno, jannu, jupiter, kale, katmai, loaner-1, + lonestar, mars, mintchip, mira, moraine, msgsun, musca, + mytoy, odysseus, pantera, radix, rainbow, sagittarius, seurat, + solarium, spud, surya, susanna, taco, tesla, video, vivalid, + volans + Machines not already in the file were not added as requested. Removed + retired machines madrona and hummel (11/7/97 MJF) + +sys/mwcs/wfinit.x + Removed a duplicate "extern" declarations line for the MSP function. + This was causing a compilation failure on Digital Unix. (11/07) + +unix/os/zfiopr.c + Added a check that the pipe file descriptors do not exceed MAXOFILES. + (11/07) + +pkg/cl/main.c + Changed the datatype of the variable old_onipc from int to PFI. + This is used as a function pointer in CL/LIBC but on 64-bit platforms + such as the DEC Alpha int and pointer are different sizes. (11/09) + +pkg/images/imfilter/src/t_median.x +pkg/images/imfilter/src/t_mode.x + Changed the type declaration of the boundary extension from int + (incorrect type) to real (the correct type) to avoid FPE errors + on the Dec Alpha. (11/11 LED) + +sys/imio/iki/stf/stfaccess.x +sys/imio/iki/fxf/fxfaccess.x + BTOI was being called on the value returned by iki_validextn without + converting the value to a boolean expression. (11/12) + +sys/imio/iki/stf/stfhextn.x +sys/imio/iki/stf/stfnewim.x +sys/imio/iki/fxf/fxfhextn.x + Added checks to make sure that the old image pointer o_im is not + used unless we have a new copy image and o_im is not NULL. (11/13) + +pkg/cl/builtin.c + When building up the command line for a foreign task, if an unquoted + INDEF was given an argument the CL would segvio on some platforms. + Technically, since INDEF is a keyword and is being used as a string + it should be quoted by the user, and things would work fine in this + case. But the CL should not segvio and it should check for an + indefinite operand in such a case so the code was modified to do so + and generate the string "INDEF" in this case, where a string argument + is being generated for an external command. This doesn't avoid the + need to quote other keywords however, e.g. "grep else" won't work + unless "else" is quoted. (11/13) + +sys/osb/ieee.gx +sys/osb/ieeed.x +sys/osb/ieeer.x +unix/as.sparc/ieee.gx +unix/as.sparc/ieeed.x +unix/as.sparc/ieeer.x +unix/as.ssol/ieee.gx +unix/as.ssol/ieeed.x +unix/as.ssol/ieeer.x + The IEEE i/o package was modified to detect IEEE subnormals on input + and map them to zero. This feature is enabled along with NaN + mapping; both are either enabled or disabled. The ieee statistics + however count only NaN mappings, not subnormals, since the latter + are considered the same as zero values. A subnormal is a number so + small (close to zero) that it cannot be accurately represented. For + example the smallest IEEE single precision real is about 1.175e-38. + Numbers from e-38 to e-45 or more gradually lose precision and are + considered subnormals which should be rounded to zero. An IEEE + subnormal is any floating point number which has an exponent of + zero. (11/14) + +sys/imio/iki/fxf/fxfhextn.x +sys/imio/iki/stf/stfhextn.x + Added an initializer for local variable "old_kernel". (11/15) + +sys/imio/iki/fxf/fxfksection.x + 1. A warning message is now issued if one writes to a new file and + the "overwrite" flag is set in the kernel section. + 2. When writing a new image to a file in new-copy mode, an extension + index is specified and overwrite is not set, append can be specified + to avoid an error trap (it is not clear why this does not apply to + case new-image as well). (11/16) + +sys/imio/iki/fxf/fxfopen.x + Several minor changes to improve error handling for the overwrite and + append parameters in the ksection. It is an error to try to overwrite + a nonexistent extension. Overwrite and append cannot be given in the + same ksection. If overwrite is explicitly given in the ksection to + overwrite a specific extension, this overrides any "append" option + in the fkinit. (11/17) + +sys/imio/iki/fxf/fxfopix.x + 1. A loop copying IM_LEN to FIT_LENAXIS was replaced by an equivalent + call to AMOVI. + 2. A temporary fix has been put in the fxf_byte_short routine to + create the temporary file in 'tmp' rather than in the working + directory (this should be replaced eventually by a runtime conversion + scheme which avoids writing any temporary files). (11/17) + +sys/imio/iki/fxf/fxfopix.x + The BSCALE/BZERO handling was modified to correct any precision + errors resulting from formatted input (CTOD) when checking for the + usual case of BSCALE/BZERO being 1.0/0.0. If the number is 1 or 0 + to within the allowable precision the converted number is replaced + by the exact number to eliminate the conversion error. Also, the + keywords are always preserved even if the scaling is unitary. (11/17) + +sys/imio/iki/fxf/fxfupdhdr.x + 1. The variable "group" was being used before its value was defined. + 2. This routine uses a temporary file in some cases when changing the + size of the header. "close(in_fd)" could be called in cases where + this temporary file was not used. + 3. Added one conditional to fxf_header_diff() to return zero on 'diff' + when the file does not exist and we want to have a dataless header. + This also works when the want to append only a header. (11/17) + +sys/imio/iki/fxf/zfiofxf.x + The fxf{zrd,zwr} routines were modified to avoid a case where the + number of bytes to read/write could be negative. (11/17) + +pkg/images/imutil/src/imcopy.x - +pkg/images/imutil/src/mkpkg +pkg/images/lib/imcopy.x + Two different versions of the file imcopy.x in the images package + were causing inconsistent behavior in the imcopy task. The version + images$lib/ was updated and the version in images$imutil/src/ was + deleted. (11/18 LED) + +sys/imio/mkpkg +sys/imio/imseti.x +sys/imio/imsetr.x + IMIO has long had the odd structure for imset where imseti would + call imsetr to set integer valued parameters. This worked, but it + is always a bad idea to involve the floating point unit in integer + computations, and we encountered a portability problem on one + platform in code that set a pointer value (SPP pointers are integers + but the value can be large enough to exceed the 24 bit integer + precision of a single precision real). Imseti and imsetr were + therefore broken out as two independent routines with integer or + real parameters set directly by one or the other. For backwards + compatibility either can still be used however to set any IMIO + parameter, subject to the implied conversion. (11/18) + +sys/imio/imstatr.x + + IMIO had imstati and imstats (string) routines but no imstatr, even + though there there is a imsetr. Added an imstatr. (11/18) + +sys/imio/db/imgnfn.x +sys/imfort/db/imgnfn.x + Modified the imgnfn code, which returns a list of named keywords + from the image header matching some pattern, to exclude lines in the + header user area which are not named keywords, i.e. not + keyword=value assignments. This would include history and comment + lines, or blank lines, none of which are considered header keywords. + (11/18) + +sys/imio/db/mkpkg +sys/imio/db/idbfstr.x + + Added a new internal IMIO routine idb_filstr which filters an input + string to remove tabs, newlines, or unprintable control codes. (11/21) + +sys/imio/db/impstr.x +sys/imio/db/imputh.x + These routines were modified to use idb_filstr to filter the input + text before placing it in the image header. In principle we should + not be doing this, but since most existing headers are subject to + FITS restrictions it is best to do so (also due to the way this code + writes the headers tabs could cause things to be misformatted). + (11/21) + +sys/imio/db/imaddf.x + The keyword name is filtered as above, also any embedded whitespace + is removed. (11/21) + +sys/imio/iki/fxf/zfiofxf.x +sys/imio/iki/fxf/fxfpak.x +sys/imio/iki/fxf/fxfupk.x + 1. The fxfzwr routine, used when the FITS kernel writes to a file, + would modify the input IMIO/FIO data buffer in some cases on some + platforms. This could cause data corruption, or if you were lucky + an invalid operand exception. + 2. fxfzrd was modifying the input argument boffset. + 3. In fxfupk.x, fxf_altmd, which converts from int to double when + applying bscale/bzero, would fail for in-place operations (which + is how it is being called by the FK). + + Some other minor changes. We will modify this code further later + to eliminate the temp file used when accessing byte image or short + images with non-unitary bscale/bzero. There may be some other + interim restrictions on updating byte images and so on. (11/24) + +sys/libc/scanf.c + Increased SZ_NUMBUF from 25 to 256. A number with a lot of leading + non-significant zeros (0.000012345) could overflow an internal + temporary string buffer. (12/07) + +pkg/cl/gram.c + 1. In caseset() the first argument is a pointer value but it was + declared as an int. Changed to memel. This was causing switch/case + to fail on 64 bit platforms like the Alpha. + 2. There was also an apparent bug in the case of a string case + which could prevent use of character constants as cases. (12/07) + +pkg/cl/mem.h +pkg/cl/stack.c + The stack utility functions push/pop/ppush are used to push and pop + operands from from the control stack, which is an array of memel + (generic integer type memory elements, used to store values of + various actual types). "push" is used in a generic way in the CL to + push both types of values, but this could cause portability problems + on machines where e.g. int and pointer are not the same size. + Rather than try to remember to always cast things properly when + calling push, the functions were changed to pushmem/ppushmem/popmem, + explicit type memel, and push/ppush/pop were changed to macros that + automatically coerce arguments of any type to memel. Hence common + usages such as "push(0)" and "push(stkop(v))" are still acceptable + and should now be portable. (12/07) + +pkg/cl/gram.c + Changed a sscanf call in the code which parses a sexagesimal number + to operate in double instead of float. This fixes a problem where + a statement such as "=1:12:34.567" would lose precision. (12/08) + +math/llsq/gen.f + This file produced compiler warning about unitialized variables, + and indeed some branches of an assigned goto (sorry) were using + unitialized variables. It seemed apparent what the author intended, + so the variable initializers were moved to above the assigned goto. + (12/10) + +sys/imio/iki/fxf/fxfksection.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x + Some missing sfree() calls were added. (12/10) + +sys/qpoe/qpio.h + Fixed a typo in a definition of "defyblock". (12/10) + +sys/mwcs/mkpkg +sys/mwcs/wfinit.x +sys/mwcs/wftnx.x + +sys/mwcs/wfzpx.x + +sys/mwcs/wfgsurfit.x + + Added two new, experimental WCS function drives for TNX (tangent plane + plus polynomials) and ZPX (zenithal radial polynomials). These are + used for optically distorted astrometric applications, e.g. the NOAO + Mosaic wide field camera. (12/10,12) + +pkg/images/immatch/doc/geomap.hlp + Added a entry for the verbose parameter to the geomap help page. + (12/11 LED) + +pkg/images/imgeom/doc/imtrans.hlp +pkg/images/imgeom/doc/rotate.hlp + Improved the discussion of 90, 180, and 270 degree rotations in the + imtranpose and rotate task help pages. + (12/11 LED) + +pkg/math/gsurfit/gsfree.gx +pkg/math/gsurfit/gsfreer.x +pkg/math/gsurfit/gsfreed.x + Fixed a typo in the gsurfit package cleanup routine. + (12/11 LED) + +pkg/images/imutil/src/t_imreplace.x +pkg/images/imutil/src/imrep.gx +pkg/images/imutil/imreplace.par +pkg/images/imutil/doc/imreplace.hlp + Added a radius parameter to also replace any pixels within a + specified distance of pixels within the replacement window. + (12/11 FV) + +dev/hosts + Added mars to hosts file for all server (12/12 MJF) + +sys/imio/iki/oifwrhdr.x + Fixed a typo, IM_V1HDRLEN(im) -> IM_V1HDRLEN(v1). (12/12) + +unix/shlib/mkshlib.ssol-sc34 + The shared library build would fail on Solaris if /opt/SUNWspro was + a link rather than a directory, due to "find" not following the link + in a file existence test. (12/13) + +unix/hlib/irafuser.csh + The variable OSRELEASE was changed to be insensitive to micro- + releases. For example, releases 2.5 and 2.5.1 would both be + considered to be "2.5". The effect of this change is that shared + libraries will, by default, only be generated to the minor release + level (generating a shared image on a Solaris 2.5.1 or 2.6.1 system + will result in a S11_2.5.e or S11_2.6.e being generated). (12/13) + +unix/os/zzstrt.c + The shared library mapping code was changed to add a check for minor + release shared images when searching for the shared image by OS + release. For example, for an IRAF version 11 shared image on a + Solaris 2.5.1 system, the search order will be "S11_2.5.1.e", + "S11_2.5.e", and "S11.e". With the related change above only the + "S11_2.5.e" shared image would be generated for a 2.5 system, but + one could manually install separate 2.5 and 2.5.1 shared images if + desired and the distributed linked images would automatically use + the microrelease version. (12/13) + + NOTE: Solaris IRAF is now being relinked using Solaris 2.6 instead + of 2.5.1. The Solaris 2.5 shared image, of course, is still being + linked on a 2.5.1 system. So far as we know there shouldn't be any + problem running Solaris executables on any version of Solaris so + long as the correct shared image is available. + +sys/imio/iki/iki.h +sys/imio/iki/ikiopen.x +sys/imio/iki/ikiaccess.x +sys/imio/iki/ikiparse.x +sys/imio/iki/ikirename.x +sys/imio/iki/ikidelete.x +sys/imio/iki/ikicopy.x + The iki_access routine was changed to query all image kernels to see + if they recognize a given image, and return ERR in this case. This + happens when there are multiple images with the same root name but + with different image types, and the image was referred to + ambiguously (e.g. a directory contains "pix.imh" and "pix.fits" and + the image name is given as "pix"). + + The IKI copy, delete, and rename operations will abort with an + "ambiguous image name" error if this situation occurs. The iki_open + routine (immap) will invoke the ambiguous image error when opening + an existing image and multiple images with the given name exist, + however it will allow multiple images to be created or existing + images to be clobbered (clobber control is implemented at the image + kernel level). + + A kludge had to be added to iki_parse to provide special treatment + for the standard testimage dev$pix. Otherwise an ambiguous image + error would result due to having dev$pix.imh and dev$pix.hhh in the + same directory, both matching "dev$pix". pix.hhh is not a real + image, merely a template used to construct new STF images, but it is + used in existing applications code (STSDAS) hence could not easily + be renamed. (12/13-14) + +sys/imio/iki/oif/oifaccess.x + To implement the above it was necessary to drop support for + imagefiles with no extension from the OIF kernel. It is time we got + rid of this feature anyway. There probably aren't any existing OIF + images that don't have an extension, but if there are they can be + renamed and still be read. (12/14) + +sys/imio/imaccess.x + The imaccess routine in IMIO will return YES if a single image + exists with the given name, NO if no image exists with the given + name, and will take an SYS_IKIAMBIG error exit (ambiguous image + name) if multiple images exist with the same name. I considered + having imaccess return ERR in the case of multiple images, but this + would have been an interface change, e.g. imaccess==YES could fail + even if the named image existed. An error handler can still be used + to detect this situation. (12/14) + +sys/libc/cimaccess.c + The LIBC routine c_imaccess (and the CL imaccess function) will return + ERR rather than abort, if the ambiguous image error occurs. (12/14) + +lib/syserr.h +lib/syserrmsg + Added the SYS_IKIAMBIG (ambiguous image name) error event. (12/14) + +sys/NAMES +sys/INDEX + + Installed an updated version of the old forgotten INDEX file and + added a new file NAMES. INDEX provides an index of all system + library procedures. NAMES provides the mapping between long source + file names and 6-character library names. NAMES can be used to + check for system library name collisions with applications procedure + names. (12/14) + +pkg/images/immatch/src/linmatch/rglscale.x + Fixed a floating point operand error that could occur if the + scaling algorithm was one of "mean", "median", or "mode", + and one or more of the reference image regions had a zero valued + mean, median, or mode. The error was in the bscale and bzero error + computation. (12/15) + +dev/graphcap + A few dozen lines at the end of the graphcap file somehow got + replaced with NULs; the size of the file did not change so it looks + like some sort of bizarre system problem. Replaced the file with + an earlier version after a diff/merge to verify that the bulk of + the file had not changed. Propagated to Lyra and Vega for platform + upgrade testing. (12/16) + +pkg/images/lib/skywcs.h +pkg/images/lib/geomap.h +pkg/images/lib/geofit.gx +pkg/images/lib/geofit.x +pkg/images/lib/rgccwcs.x +pkg/images/imcoords/ccfind.par +pkg/images/imcoords/ccmap.par +pkg/images/imcoords/ccsetwcs.par +pkg/images/imcoords/cctran.par +pkg/images/imcoords/ccxymatch.par +pkg/images/imcoords/src/t_ccfind.x +pkg/images/imcoords/src/t_ccmap.x +pkg/images/imcoords/src/t_ccsetwcs.x +pkg/images/imcoords/src/t_ccxymatch.x +pkg/images/imcoords/src/t_ccfunc.x +pkg/images/imcoords/src/ccfunc.x +pkg/images/imcoords/src/ccxytran.x +pkg/images/imcoords/doc/ccfind.hlp +pkg/images/imcoords/doc/ccmap.hlp +pkg/images/imcoords/doc/ccsetwcs.hlp +pkg/images/imcoords/doc/cctran.hlp +pkg/images/imcoords/doc/ccxymatch.hlp + Modified the astrometry routines to support the experimental function + drivers tnx and zpx as well as the other new function drivers. + (12/15 LED) + +pkg/images/immatch/src/linmatch/lsqfit.h +pkg/images/immatch/src/linmatch/rglscale.x +pkg/images/immatch/src/linmatch/rgliscale.x +pkg/images/immatch/src/linmatch/rglsqfit.x +pkg/images/immatch/src/linmatch/rglplot.x + Fixed several bugs in the linmatch bad regions handling code that + could result in floating point errors in the fit and other problems + if the reference image regions shifted to the input image coordinate + system were entirely or partially off the input image. Modified + the graphics routines to window the fits more appropropriately in + the case where the majority of the input data is bad for one reason + or another (12/19 LED). + +doc/newsfile +doc/v211revs.hlp + + Added the V2.11 revisions summary to the newsfile ("news" command in + IRAF) and to the DOC archive. (12/22) + +sys/fmtio/evvexpr.gy + In the xvv_quest code (the "?" conditional-expression operator) the + local variable nelem was not being initialized in certain + circumstances. (12/23) + +--------------------------------- +V2.11.1 patch released. (12/23 1997) + +dev/hosts + Added solaris machine mogollan (1/16/98 MJF) + +sys/tty/ttyopen.x + A corrupted termcap file with a few thousand zero bytes at the end + would cause ttyopen to segvio when attempting to fetch an entry not + found, and hence reading into the zero data region. (1/16) + +dev/termcap + This end of this file had been replaced by zero bytes. The first 79 + 512 byte blocks were valid data and the rest of the file was zeroed. + This is the same problem seen with graphcap earlier! It still looks + like a system problem. A rdist update a while back must have + propagated the error to lepus where it was causing a segvio in PC-IRAF. + Replaced this file with an older version on ursa, after a diff to + check for revisions. (1/16) + +sys/imio/iki/ikiextn.x + The iki_validextn() function, used to test whether a file extension + is valid for a given image format, was not rejecting extensions + such as "extnXXX" which match the first few characters of a valid + extension, but which are longer strings. (1/20) + +dev/hosts + Added IRIX machine almond at the WIYN (1/21/98 MJF) + +pkg/cl/login.cl + Changed the version check string for V2.11. (1/21) + +pkg/cl/modes.c + This routine was calling c_stggettline as (fd,buf,maxch) but since + stggetline is patterned after FIO getline it uses a SZ_LINE buffer + and takes no maxch argument. The CL code was using a 512 char + buffer, which is plenty large enough, but with the recent changes to + buffer sizes in V2.11, SZ_LINE is now 1023 and is hence larger than + 512. Even this would not normally be a problem as the actual string + read never exceeds 512 chars, however the string packing routine + called always sets the last char in the output buffer to EOS to + truncate strings that are larger than the output buffer. Hence, a + very subtle buffer overrun could occur. This showed up as a segvio + during CL logout on a Linux system. Since C allocates auto storage + on the stack, the memory overrwrite was overriting the frame pointer + for a function call in c_main, and the RET instruction in execute + was vectoring off into segvio land. Nasty stuff. (1/23) + +sys/unix/os/zwmsec.c + Replaced the setitimer-based zwmsec code by a version that can use + either usleep() or the old setitimer code. (1/23) + +sys/imfort/imcrex.x + Added a line of code to set IM_ACMODE to NEW_IMAGE. The imwrhdr + code, used to update the image header, sets certain fields only if + a new image is being created. (2/03) + +sys/imio/imsetbuf.x + Modified to disable "fast" i/o if swapping is needed. (2/05) + +pkg/images/lib/geograph.gx +pkg/images/lib/geograph.x + Modifed the plot labels to say "reject =" instead of "sigrej = " to + maintain naming consistency with the reject parameter. + (2/23/98 LED) + +unix/hlib/buglog.csh + Modified to create V2.11 bugs instead of V2.10 bugs. The buglog + file is in iraf/v211, but this is a link to the v2.10 buglog to + allow a common buglog file to be used for both. (2/24) + +sys/imio/iki/oif/oifwrhdr.x + Modified oif_trim() to check for a nonzero string count so that it + does not call alcrc with a negative char count, which could cause + it to corrupt memory. (2/27) + +noao/mkpkg + Added architecture enties for "irix", "rs6000", and "redhat". (3/03) + +images/lib/geogmap.gx +images/lib/geogmap.x + The calls to gt_colon were missing an argument so any gtools + command would cause the geomap or ccmap tasks to crash. It looks + as though the calling sequence for this routine changed a long + time ago but geomap never picked up the change. (3/11 LED) + +unix/boot/xyacc/y1.c +unix/boot/xyacc/y3.c +unix/boot/xyacc/y4.c + Cleaned up some poorly formed comments. These were of the form + /* ... /* ... */, i.e. the opening and closing forms didn't match. + This caused a problem with the C compiler on AIX4. (3/11) + +sys/gio/cursor/gtrwsclip.x + This file contained an expression ((tu <= 0) != (tv <= 0)) which is + technically illegal (in Fortran) as != is an arithmetic operator and + the operands are logical. Replaced the above expression by the + equivalent (! ((tu <= 0 && tv <= 0) || (tu > 0 && tv > 0))) which, + while less clear, avoids the type clash. (3/14) + +sys/gio/stdgraph/stggim.x + This file contained a couple instances of an AND of a short variable + and the constant 017B, an integer, causing a short/int type mismatch. + Changed the 017B to use a type variable of type short for the mask + value. (3/14) + +sys/plio/plp2l.gx +sys/plio/plp2r.gx + These files contained a couple of instances of max(0,) + constructs which caused an integer/short type mismatch. Had to + replace the numeric 0 instances by a short variable. (3/14) + +dev/hosts + removed virgo (4/13 MJF) + +dev/termcap + Added an entry for lwdp. (4/13) + +dev/hosts + added kalahari (5/7/98 MJF) + +pkg/system/references.cl + Added the switch "metacharacters=yes" (the default) to several calls + to the MATCH task in this script. A user had changed the default + value of this parameter, causing the references task to fail. (5/08) + +sys/gio/imdkern/idk.x +sys/gio/imdkern/imdpcell.x +dev/graphcap + Changed BPW from 8 to 32 (nbits used per integer word of the IDK + image bitmask); this increases the encoding efficiency of the + bitmask to the maximum to reduce the size of the internal IDK frame + buffer bitmask used for overlay graphics. Increased the maximum + frame buffer size from 2048 square to 8192 square. Changed the + max resolution for imdkern to 8192x8192 in the graphcap entry. (5/19) + +dev/hosts + Changed pisces to ssun (5/28/98 MJF) + +dev/hosts + added 'defiant' to the list (5/29/98 MC) + +pkg/images/immatch/src/imcombine/t_imcombine.x +pkg/images/immatch/src/imcombine/icombine.gx +pkg/images/immatch/src/imcombine/ic_rmasks.x + +pkg/images/immatch/src/imcombine/ic_log.x +pkg/images/immatch/src/imcombine/mkpkg +pkg/images/immatch/imcombine.par +pkg/images/immatch/doc/imcombine.hlp + Added a new output which is a pixel mask identifying which pixel in + which input image is rejected or not included in the final output. + (5/15/98, Valdes) + +pkg/images/tv/display/dspmmap.x + The steps to check if an image and mask have an integer relationship + (integer sampling and integer offsets) in their physical coordinate + systems could fail because real precision was not high enough + in MWCS transformation calls. Changed variables and MWCS calls + to double. (5/29/98, Valdes) + +dev/hosts + Added loaner-1 (6/3/98 MJF) + +pkg/images/imutil/doc/imexpr.hlp + Added an example of how to create a circular pixel mask. (6/8/98 MJF) + +dev/hosts + Added tesla (6/12/98 MJF) + +pkg/dataio/fits/fits_cards.x + Added a check for pre-existing IRAFNAME keywords to the wfits task. + (6/8/98 LED) + +sys/imfort/imopnx.x + The value of the user variable min_lenuserarea was being read but was + not being used correctly to allocate the header buffer. Changed the + calc of len_hdrmem to len_hdrmem = LEN_IMHDR + (len_ua / SZ_STRUCT). + (6/22) + +pkg/images/tv/imedit/epix.h +pkg/images/tv/imedit/t_imedit.x +pkg/images/tv/imedit/epcolon.x +pkg/images/tv/doc/imedit.hlp + The temporary editing buffer image was made into a unique temporary + image rather than the fixed name of "epixbuf". (6/30/98, Valdes) + +dev/hosts + Added makalu (7/8/98 MJF) + +unix/shlib/mkshlib.sos4 + Had to change a "-lresolv" to "-lresolv -l44bsd" to get things + to link due to recent changes in SunOS on tucana. (7/13) + +pkg/dataio/import/t_import.x + Modified to initialize the 'use_cmap' flag to on by default so 8-bit + colormap images will be converted more intuitively. (7/14/98 MJF) + +pkg/images/immatch/src/imcombine/t_imcombine.x + The internal calculation type was changed from the highest precedence + type of the input images to the highest of the input and output. + This allows setting the output type to be real to force computation + in real for integer input images. Not doing this could cause severe + truncation errors if the users specify their own scaling values. + (7/14/98, Valdes) + +dev/hosts + Removed: katmai jannu + Changed to Solaris: grus seurat + Added (Solaris): xari chopin bluemoon magenta matisse makalu mele gronk + Added (SunOS): grotrian (7/16/98 MJF) + +dev/hosts + Changed deneb to solaris (7/22/98 MJF) + +pkg/images/immatch/src/imcombine/icgdata.gx + Needed to initialize the number of pixels combined for the case where + there is initially no data. (7/29/98, Valdes) + +pkg/images/tv/imexamine/stfmeasure.x + The logic in STF_FIT for determining the points to fit and the point + to use for the initial width estimate was faulty allowing some bad + cases to get through. (7/31/98, Valdes) + +pkg/math/nlfit/nlchomat.gx +pkg/math/nlfit/nlchomatr.x +pkg/math/nlfit/nlchomatd.x + Modified the singular matrix test to make a comparison against EPSILON + instead of 0.0 to avoid floating point problems. (8/1/98, Davis) + +pkg/images/tv/display/t_display.x + Added checks for a data range of zero, or which rounds to zero for + short data, to avoid floating divide by zero errors. Rather than + resort to a unitary transformation in this case the requested + data range minimum is decreased by one and the maximum is increased + by one. (8/11/98, Valdes) + +unix/os/zfioks.c + Added a new environment variable "KSRSH". This can be used to define + the RSH command to be used to make network connections. The default + value is "rsh" (or the equivalent "remsh" on one old system). For + example, one can set KSRSH=ssh to cause IRAF networking to use ssh + instead of rsh (ssh is a more secure version of rsh that uses strong + authentication). (9/08) + +pkg/images/immatch/doc/geomap.hlp + Changed references to the old register task to gregister which is + the new task name. (9/10, Davis) + +pkg/images/imutil/src/t_imarith.x + Modified the imarith task so that header updating would only occur + if noact=no, to fix a segmentation violation error. (9/16, Davis) + +dev/hosts + Removed nonexistent benhur and monoceros (9/21, MJF) + +lib/time.h +sys/etc/cnvtime.x +sys/etc/cnvdate.x + Minor changes were made to print the year using 4 digits instead of + 2, to make this code Y2K compliant. (10/29) + +pkg/images/immatch/src/imcombine/icsetout.x + Fixed a problem with input images that have dimensional reduction. + (10/6, Valdes) + +sys/mwcs/wfmspec.x + The multispec format WCS driver was modified to normalize the + weights array (adjust the sum of the weights to 1.0) if they are + not already normalized. IRAF code should produce normalized weights, + but there were cases where unnormalized weights could get into the + WCS, and this could cause systematic errors in radial velocities. + (11/18) + +dev/hosts + Added solaris machine lilawati (12/1, MJF) + +pkg/math/iminterp/asitype.x +pkg/math/iminterp/asisinit.x +pkg/math/iminterp/asigetr.x +pkg/math/iminterp/doc/asitype.hlp +pkg/math/iminterp/doc/asisinit.hlp +pkg/math/iminterp/doc/asigetr.hlp + Three new routines were added to the 1D image interpolation package: + asitype, asisinit, and asigetr. (12/28 LED). + +pkg/math/iminterp/msitype.x +pkg/math/iminterp/msisinit.x +pkg/math/iminterp/msigetr.x +pkg/math/iminterp/doc/msitype.hlp +pkg/math/iminterp/doc/msisinit.hlp +pkg/math/iminterp/doc/msigetr.hlp + Three new routines were added to the 2D image interpolation package: + msitype, msisinit, and msigetr. (12/28 LED). + +pkg/math/iminterp/im1interpdef.h +pkg/math/iminterp/iminterp.h +pkg/math/iminterp/iminterp.hd +pkg/math/iminterp/iminterp.men +pkg/math/iminterp/iminterp.help +pkg/math/iminterp/iminterp.spc +pkg/math/iminterp/arbpix.x +pkg/math/iminterp/arider.x +pkg/math/iminterp/arieval.x +pkg/math/iminterp/asider.x +pkg/math/iminterp/asieval.x +pkg/math/iminterp/asifit.x +pkg/math/iminterp/asifree.x +pkg/math/iminterp/asigeti.x +pkg/math/iminterp/asigrl.x +pkg/math/iminterp/asiinit.x +pkg/math/iminterp/asirestore.x +pkg/math/iminterp/asisave.x +pkg/math/iminterp/asivector.x +pkg/math/iminterp/ii_1dinteg.x +pkg/math/iminterp/ii_cubspl.f +pkg/math/iminterp/ii_eval.x +pkg/math/iminterp/ii_pc1deval.x +pkg/math/iminterp/ii_polterp.x +pkg/math/iminterp/ii_sinctable.x +pkg/math/iminterp/ii_spline.x +pkg/math/iminterp/mkpkg +pkg/math/iminterp/doc/arbpix.hlp +pkg/math/iminterp/doc/arider.hlp +pkg/math/iminterp/doc/arieval.hlp +pkg/math/iminterp/doc/asider.hlp +pkg/math/iminterp/doc/asieval.hlp +pkg/math/iminterp/doc/asifit.hlp +pkg/math/iminterp/doc/asifree.hlp +pkg/math/iminterp/doc/asigeti.hlp +pkg/math/iminterp/doc/asigetr.hlp +pkg/math/iminterp/doc/asigrl.hlp +pkg/math/iminterp/doc/asiinit.hlp +pkg/math/iminterp/doc/asirestore.hlp +pkg/math/iminterp/doc/asisave.hlp +pkg/math/iminterp/doc/asisinit.hlp +pkg/math/iminterp/doc/asitype.hlp +pkg/math/iminterp/doc/asivector.hlp + The 1D interpolation routines were modified to support look-up table + sinc interpolation and drizzle resampling. Minor improvements in + weighting were made to the existing 1D sinc routines. (12/28 Davis) + +pkg/math/iminterp/im2interpdef.h +pkg/math/iminterp/iminterp.h +pkg/math/iminterp/iminterp.hd +pkg/math/iminterp/iminterp.men +pkg/math/iminterp/iminterp.help +pkg/math/iminterp/iminterp.spc +pkg/math/iminterp/mrider.x +pkg/math/iminterp/mrieval.x +pkg/math/iminterp/msider.x +pkg/math/iminterp/msieval.x +pkg/math/iminterp/msifit.x +pkg/math/iminterp/msifree.x +pkg/math/iminterp/msigeti.x +pkg/math/iminterp/msigetr.x +pkg/math/iminterp/msigrid.x +pkg/math/iminterp/msigrl.x +pkg/math/iminterp/msiinit.x +pkg/math/iminterp/msirestore.x +pkg/math/iminterp/msisave.x +pkg/math/iminterp/msisinit.x +pkg/math/iminterp/msisqgrl.x +pkg/math/iminterp/msitype.x +pkg/math/iminterp/msivector.x +pkg/math/iminterp/ii_bieval.x +pkg/math/iminterp/ii_greval.x +pkg/math/iminterp/ii_pc2deval.x +pkg/math/iminterp/ii_spline2d.x +pkg/math/iminterp/mkpkg +pkg/math/iminterp/doc/mrider.hlp +pkg/math/iminterp/doc/mrieval.hlp +pkg/math/iminterp/doc/msider.hlp +pkg/math/iminterp/doc/msieval.hlp +pkg/math/iminterp/doc/msifit.hlp +pkg/math/iminterp/doc/msifree.hlp +pkg/math/iminterp/doc/msigeti.hlp +pkg/math/iminterp/doc/msigetr.hlp +pkg/math/iminterp/doc/msigrid.hlp +pkg/math/iminterp/doc/msigrl.hlp +pkg/math/iminterp/doc/msiinit.hlp +pkg/math/iminterp/doc/msirestore.hlp +pkg/math/iminterp/doc/msisave.hlp +pkg/math/iminterp/doc/msisinit.hlp +pkg/math/iminterp/doc/msisqgrl.hlp +pkg/math/iminterp/doc/msitype.hlp +pkg/math/iminterp/doc/msivector.hlp + The 2D interpolation routines were modified to support sinc and + look-up table sinc interpolation and drizzle resampling. (12/28 Davis) + +pkg/images/imgeom/magnify.par +pkg/images/imgeom/src/t_magnify.x +pkg/images/imgeom/doc/magnify.hlp + Installed a new version of the magnify task which support 1D and 2D + sinc and look-up table sinc interpolation and 1D and 2D drizzle + resampling. Modified the out-of-bounds pixel handling algorithm to + conform to the other image resampling tasks. (12/28 Davis) + +pkg/images/imgeom/imshift.par +pkg/images/imgeom/src/t_imshift.x +pkg/images/imgeom/doc/imshift.hlp + Installed a new version of the imshift task which supports 2D sinc and + look-up table sinc interpolation and 2D drizzle resampling. + (12/28 Davis) + +pkg/images/imgeom/shiftlines.par +pkg/images/imgeom/src/t_shiftlines.x +pkg/images/imgeom/src/shiftlines.x +pkg/images/imgeom/doc/shiftlines.hlp + Installed a new version of the shiftlines task which supports 1D sinc + and look-up table sinc interpolation and 1D drizzle resampling. + (12/28 Davis) + +pkg/images/immatch/xregister.par +pkg/images/immatch/src/t_xregister.x +pkg/images/immatch/src/rgximshift.x +pkg/images/immatch/doc/xregister.hlp + Installed a new version of the xregister task which supports 2D sinc and + look-up table sinc interpolation and 2D drizzle resampling. + (12/29 Davis) + +pkg/images/immatch/geotran.par +pkg/images/immatch/src/geometry/geotran.h +pkg/images/immatch/src/geometry/t_geotran.x +pkg/images/immatch/src/geometry/geotran.x +pkg/images/immatch/src/geometry/geotimtran.x +pkg/images/immatch/doc/geotran.hlp + Installed a new version of the geotran task which support 1D and 2D + sinc and look-up table sinc interpolation and 1D and 2D drizzle + resampling. Modified the out-of-bounds pixel handling algorithm to + conform to the other image resampling tasks in the case where the + entire input image is in memory. (12/29 Davis) + +pkg/images/imgeom/rotate.par +pkg/images/imgeom/imlintran.par +pkg/images/imgeom/doc/rotate.hlp +pkg/images/imgeom/doc/imlintran.hlp + Installed new versions of the rotate and imlintran tasks (these + are scripts which run geotran) which support 2D sinc and look-up + table sinc interpolation and 2D drizzle resampling. + (12/29 Davis) + +pkg/images/immmatch/gregister.par +pkg/images/immmatch/sregister.cl +pkg/images/immmatch/wregister.cl +pkg/images/immmatch/doc/gregister.hlp +pkg/images/immmatch/doc/sregister.hlp +pkg/images/immmatch/doc/wregister.hlp + Installed new versions of the gregister, sregister, and wregister + tasks (these are scripts which run geotran) which support 1D and 2D + sinc and look-up table sinc interpolation and 1D and 2D drizzle + resampling. (12/29 Davis) + +dev/graphcap + Added an entry for 'clp2', a new color printer (1/2 MJF) + +pkg/images/immatch/src/wcsmatch/t_wcscopy.x + Modified wcscopy to update the RADECSYS, EQUINOX, and MJD-WCS keywords + as well as the mwcs keywords. (1/7/99, Davis) + +dev/hosts + Added solaris machine roadrunner (1/11/99 MJF) + +dev/devices.hlp + Updated devices.hlp to include clp, clp2, and clp2t. Propogated the + updated graphcap and devices.hlp files to ursa, gemini, and bigx. + (1/13/99 jb) + +dev/hosts + Changed tribble from sparc to solaris (1/13/99 MJF) + +lib/pkg/gtools.h +pkg/xtools/gtools/gtools.h +pkg/xtools/gtools/gtvplot.x +pkg/xtools/gtools/gtctran.x +pkg/xtools/gtools/gtplot.x +pkg/xtools/gtools/gtfree.x +pkg/xtools/gtools/gtcur.x +pkg/xtools/gtools/gtgui.x +pkg/xtools/gtools/gtcur1.x +pkg/xtools/gtools/gtswind.x +pkg/xtools/gtools/gtwindow.x +pkg/xtools/gtools/gtget.x +pkg/xtools/gtools/gtset.x +pkg/xtools/gtools/gtreset.x +pkg/xtools/gtools/gtcopy.x +pkg/xtools/gtools/gtcolon.x +pkg/xtools/gtools/gtinit.x +pkg/xtools/gtools/gtlabax.x +pkg/xtools/gtools/gtascale.x +pkg/xtools/gtools/gthelp.x - +pkg/xtools/gtools/gtpage.x - +pkg/xtools/gtools/mkpkg + A new version of the GTOOLS routines was installed. The internal + data structure was extended and colon commands and GUI messages + added to support GUI tasks (SPECTOOL, XRV, and XCURFIT). The + package interface, the public include file, and all colon and + keystroke commands remain unchanged for existing applications. Two + routines which were never used were deleted. (12/16/98, FV) + +pkg/xtools/icfit/icfit.h +pkg/xtools/icfit/icgui.x + +pkg/xtools/icfit/icguishow.gx + +pkg/xtools/icfit/icferrors.gx + +pkg/xtools/icfit/icfshow.x + +pkg/xtools/icfit/icfvshow.gx + +pkg/xtools/icfit/icgaxes.gx +pkg/xtools/icfit/icgcolon.gx +pkg/xtools/icfit/icgdelete.gx +pkg/xtools/icfit/icgfit.gx +pkg/xtools/icfit/icggraph.gx +pkg/xtools/icfit/icgnearest.gx +pkg/xtools/icfit/icgparams.gx +pkg/xtools/icfit/icgsample.gx +pkg/xtools/icfit/icgundelete.gx +pkg/xtools/icfit/icparams.x +pkg/xtools/icfit/icerrors.gx +pkg/xtools/icfit/icshow.x +pkg/xtools/icfit/icvshow.gx +pkg/xtools/icfit/mkpkg +pkg/xtools/icfit/names.h + The package was modified to add colon commands and GUI messages to + support GUI tasks (SPECTOOL, XRV, and XCURFIT). The package + interface for existing applications remains unchanged and no + changes are required to calling programs. (12/16/98, FV) + +pkg/images/immatch/doc/wregister.hlp +pkg/images/immatch/doc/sregister.hlp + Added an example of how to do images mosaicing with the wregister + and sregister tasks. (1/28/99, LED) + +bin.sparc/S.e + +bin.ssun/S.e + + The "S.e" link was restored. This link points to the Sun/IRAF shared + image for the development system. It is not required for execution, + but is required at compile/link time for edsym.e to be able to + update the symbols for the IRAF shared image. This is needed to + debug functions in the shared image. (2/11) + +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/rpp/ratlibc/mkpkg.sh + The ratlibc code was being compiled into a library "libc.a". This + caused problems linking rpp.e on Solaris 7, so the name of this + internal, temporary library was changed to libratc.a. (2/11) + +pkg/images/immatch/src/listmatch/t_xyxymatch.x +pkg/images/imcoords/src/t_ccxymatch.x + Fixed the xyxymatch and ccxymatch tasks so that they work properly when + the number of reference files is greater than one and equal to the + number of input files. In that case xyxymatch and ccxymatch are supposed + to pair up the input and reference files one to one instead of using the + last file in the reference file list, as they were doing. (2/22 LED) + +dev/hosts + Added sunos machine arun (3/4/99 MJF) + +dev/hosts + Deleted nonexistant hosts herbie, piscis, pictor, ozzie, and sonoma + (3/18/99 MJF) + +unix/hlib/r1mach.f +unix/hlib/d1mach.f +unix/hlib/i1mach.f + Installed updated versions of these files from the PORT package + on netlib. The values for the minimum and maximum IEEE floating + point normals were invalid (thanks to Steve Walton for pointing + this out). NOTE: even on a machine with IEEE floating point, the + file d1mach.f has to be modified to reflect the byte order of + the platform IRAF is being ported to. (4/08) + +lib/time.h +sys/etc/dtmcnv.x +sys/etc/gmtcnv.x +sys/etc/mkpkg +unix/hlib/libc/knames.h +unix/os/gmttolst.c +unix/os/mkpkg +unix/os/zgmtco.c + 1) A new kernel routine "zgmtco" was added to OS. This gives the + correction, in seconds, from LST to GMT. (LST here means local + standard time, or clock time). Since IRAF already returns the clock + time in LST seconds, this allows either LST or GMT to be determined. + Note LST corrects for daylight savings time, the GMT correction takes + this into account as well. In practice programs can just ignore + daylight savings time and let the kernel worry about it. + + 2) New routines gmttolst() and lsttogmt() were added to ETC. These + convert times (in seconds) to and from LST and GMT. A value of zero + can be input to get the correction value. + + 3) A set of four new routines dtm_encode, dtm_decode, dtm_encode_hms, + and dtm_decode_hms were added to ETC. A related flag value was + added to . "dtm" standard for date/time. These routines + convert time expressed in year, month, date, and time of day to and + from a string value. A flags value can be used to select the type + of time string to be encoded or decoded. Currently DATE-OBS in + FITS-Y2K and the old FITS formats are supported. (4/20) + +pkg/language/language.hd +pkg/language/language.men +pkg/language/doc/scan.hlp +pkg/language/doc/fprint.hlp + These help pages were updated to document the CL printf() and scanf() + functions added back in V2.10. (4/21/99 MJF) + +pkg/images/tv/imexamine/iepos.x + The output of the 'x' and 'y' keys was not being written to the log + file because of a typo. (5/7/99, Valdes) + +pkg/dataio/fits/wfits.h +pkg/dataio/fits/fits_cards.x +pkg/dataio/fits/fits_params.x + Modified wfits to write the DATE keyword values in the new format + (including a time field) and in units of GMT as specified by the + new standards. The new format will take effect Jan 1 at 00:0:00 GMT. + (5/8/99) + +pkg/images/lib/skywcs.x + Modified the image wcs decoding routines to support both the old + and new DATE-OBS format. All tasks in the imcoords and immatch + package which decode the image wcs should pick up the change. + (5/13/99) + +pkg/images/imcoords/doc/ccsetwcs.hlp +pkg/images/imcoords/doc/imcctran.hlp +pkg/images/imcoords/doc/skyctran.hlp +pkg/images/immatch/doc/skyxymatch.hlp + Added some information about the new DATE-OBS format to the help + pages for the ccsetwcs, imctran, skyctran, and skyxymatch tasks. + (Davis, May 13, 1999) + +unix/os/zglobl.c + Increased the size of SZ_PROCNAME from 32 to 256 chars. On some + systems this is a full pathname, and could overflow the buffer. + (5/13) + +pkg/dataio/import/images.dat + Added a database entry for the GOES weather satellite Unidata McIDAS + image format (5/14/99 MJF) + +lib/gio.h + This and the next several changes were part of an effort to change + GIO to allow long "device names" for GUIs (which may include a GUI + file name) to be passed through the graphics stream to the stdgraph + kernel. + + Increased SZ_UIFNAME from 99 to 199 chars. This also increases the + size of the dynamically allocated GIO descriptor. (5/14) + +sys/gio/cursor/gtr.h + Increased SZ_TRDEVNAME from 29 to 229. Increased SZ_KERNFNAME from + 59 to 259. This also increases the size of the dynamically allocated + GTR descriptor. (5/14) + +sys/gio/stdgraph/stdgraph.h + Increased SZ_GDEVICE from 31 to 256. Increased SZ_UIFNAME from 99 + to 199. Increased SZ_SBUF from 1024 to 2048. These changes did + not change the size of the dynamically allocated stdgraph descriptor, + as string space is dynamically allocated in the string buffer. + (5/14) + +pkg/images/imgeom/doc/imlintran.hlp + Fixed a bug in the imlintran.hlp page. (5/17 LED) + +dev/hosts + Added pecan and crunch (5/17 MJF) + +unix/os/zghost.c + This routine was calling gethostname() to read the hostname + directly into the caller's buffer. This could fail if the hostname + were longer than the output buffer. Changed to read the hostname + into an internal buffer, and copy this out to the caller's buffer + separately, truncating the hostname if necessary. (5/23) + +pkg/math/iminterp/msisqgrl.x +pkg/math/iminterp/msigrl.x + Fixed a couple of bugs in the 2D integration routines that I + inadvertantly introduced when I upgraded the image interpolation + software to handle sinc and drizzle resampling. (6/2 LED) + +pkg/images/immatch/src/geometry/geotran.x + Fixed a type mismatch problem in a call to max that was causing + compilation errors on the Dec Station. (6/2 LED) + +pkg/images/imcoords/src/t_ccsetwcs.x + Improved the error message handling in the case when a database + records either not be found or could not be successfully decoded + by the ccsetwcs task. + (6/3 LED) + +pkg/images/imcoords/src/t_wcsctran.x + Fixed a bug in the wcsctran task units initialization code. + (6/3 LED) + +dev/hosts + Added vissun-1, a sparc summer student machine (6/4/99 MJF) + +pkg/images/tv/display/sigm2.x + An argument to sigm2_setup was being changed by the routine and this + changed argument was then incorrectly used by the calling program. + The argument was made input only. (6/15/99, Valdes) + +pkg/images/immatch/src/imcombine/icsetout.x + Changed to better parse the offset types. The WCS correction for + offsets was incorrect. (6/17/99, Valdes) + +pkg/math/slalib/ + Upgraded slalib from version 1.6.3 to version 2.3.0. There are + seventeen new routines in the library. Most of these either deal + with converting between the FK5 to ICRS (Hipparcos) equatorial + coordinate systems, or with computing orbital elements for solar + system objects. (6/18/99, LED) + +pkg/images/immatch/src/geometry/t_geotran.x + Fixed a bug in the transform list decoding routine that was preventing + geotran from using the same transform for all the input images. This + bug was introduced when geotran was modified to use the image template + instead of the file template expansion code to manage the record list. + (Davis, June 18, 1999) + +pkg/images/immatch/doc/geomap.hlp + Added some notes and an example to explain and illustrate the role + of the reference and input coordinates for different applicatons, + i.e. image resampling and coordinate transformation. + (Davis, June 18, 1999) + +pkg/math/slalib/fk52h.f +pkg/math/slalib/fk5hz.f +pkg/math/slalib/h2fk5.f +pkg/math/slalib/hfk5z.f + Fixed a bug in the ICRS <-> FK5 conversion routines that was + producing incorrect results for right ascensions >= 12 hours. + (Davis, June 23, 1999) + +pkg/images/lib/skywcs.h +pkg/images/lib/skywcs.x +pkg/images/imcoords/src/ttycur.key +pkg/images/imcoords/src/skycur.key +pkg/images/imcoords/doc/ccfind.hlp +pkg/images/imcoords/doc/ccmap.hlp +pkg/images/imcoords/doc/ccsetwcs.hlp +pkg/images/imcoords/doc/skyctran.hlp +pkg/images/imcoords/doc/imcctran.hlp + Added support for the ICRS system to the images.imcoords package. + (Davis, June 24, 1999) + + +pkg/images/imcoords/src/t_starfind.x + Modified the starfind task default output file naming code to deal + rationally with fits image extension names. + (Davis, June 26, 1999) + +pkg/images/imcoords/src/t_ccsetwcs.x +pkg/images/imcoords/src/ccxytran.x + Modified the ccsetwcs and cctran tasks to read a zpx (or any other + wcs transform with parameters) from the database produced by ccmap. + These tasks had not been correctly updated when the changes were made + to the immatchx versions of these tasks. + (Davis, June 26, 1999) + +pkg/utilities/surfit.par +pkg/utilities/t_surfit.x +pkg/utilities/doc/surfit.hlp + Modified the utilities task surfit to support the surface fitting + package half cross-terms option. This involved changing the type + of the parameter xterms from boolean to string. + (Davis, July 6, 1999) + +unix/boot/bootlib/envinit.c + Restructured a variable initializer (*fname = ++ip) due to a + compiler warning. (7/09) + +unix/shlib/mkshlib.ssol-sc34 + Added support for the Version 5.0 Sun compilers. (7/09) + +pkg/language/doc/fprint.hlp + The help for "printf" wasn't working; added an entry to the .help + entry at the top of the help page to enable this. (7/10) + +sys/etc/dtmcnv.x + Fixed a minor typo in a comment. (7/11) + +sys/imio/iki/fxf/mkpkg +sys/imio/iki/fxf/fxfencode.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x + Installed the Y2K changes to the FITS kernel. The affected keywords + are "DATE" and "IRAF-TLM". "DATE" is the date the FITS image was + written by the FITS kernel; this is not to be confused with DATE-OBS, + which is the date of observation of the image. "IRAF-TLM" is the + FITS version of the IRAF time of last modification of the imagefile. + DATE is written in the old FITS date format through the end of 1999, + after which the Y2K/ISO format is used. IRAF-TLM, which is an + internal keyword to the FK, is always written in the new format in the + new version of the code. (7/11) + +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfclose.x +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfrdhdr.x +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfupk.x +sys/imio/iki/fxf/zfiofxf.x + Installed the changes for "on-the-fly" conversion of unsigned byte + images, and short images where the output pixel is real (FK has to + apply bscale/bzero scaling). The conversion is done in place in the + output buffer during an image read. The support for OTF scaling is + read-only, i.e., these images types can be read, but not written. + I don't think this is strictly necessary, but this is a limitation + of the current code (Note: read-write access to such images will + probably fail with the current implementation; read-only access to + e.g. byte images is still a useful feature however). The old + creation of a temporary image to do the scaling has been removed. + (7/11) + +dev/ypix.imh + A new version of the WCS test image (header) dev$ypix (prepared by + L.Davis) was installed. This version incorporates the new Y2K format + dates for testing, and has a year 2000 equinox FK5 WCS; otherwise + it is equivalent to wpix. The old version is still available as + dev$wpix, in addition to the old standard dev$pix. (7/12) + +sys/imio/iki/plf/plfupdhdr.x +sys/imio/iki/plf/plfopen.x + These routines were changed to use IM_HDRFILE instead of IM_NAME to + store the filename of the mask file. IM_NAME is used for the logical + image name in error messages, and only provides 80 chars, so mask + image pathnames could be truncated if if IM_NAME were used for a file + pathname. (7/12) + +sys/imio/iki/fxf/fxfupdhdr.x + In the process of reviewing and cleaning up IM_NAME usage, deleted an + unused reference to "imgcluster (IM_NAME(im), ...)". (7/12) + +sys/imio/immapz.x + Revised the code which writes IM_NAME to protect against overflow of + this string. The image name is formatted into a SZ_PATHNAME string, + and if the resultant image name is too long to fit in IM_NAME, is + regenerated using only the root of the image name. Previously bad + things would happen if the sprintf overflowed IM_NAME. (7/12) + +sys/imio/iki/fxf/fxfupdhdr.x + Fixed a minor bug what was causing the new format dates to be + written with some trailing blanks following the date string. (7/13) + +sys/imio/iki/fxf/fxf.h + Updated the FITS kernel version string (written to the ORIGIN kw) + to read "NOAO-IRAF FITS Image Kernel July 1999". (7/13) + +sys/gio/gmsg.x + This code was changed to use STDERR rather than STDOUT to send + messages to GUIs. Formerly, if the stdout of a GUI task was + redirected this could cause GUI messages (gmsg) to never reach + the GUI (this is of course still possible using STDERR, but it + is less likely that someone will need to redirect the STDERR of an + interactive GUI). The text stream are used for messaging because + messages can be any size; messages of hundreds of KB are possible, + e.g. when sending large GUI files, or documentation text. (Something + like the message bus is needed to fully address this problem). + (7/14) + +dev/graphcap + Added a new xgterm entry "xgterm-nogui", which is identical to the + xgterm entry but which has GUI messaging (gmsg) disabled. This + logical device will completely disable GUIs but still permit vector + graphics. It also disables the builtin default ED (xgterm.gui), but + the default xgterm GUI built into xgterm itself should kick in in + this case when graphics mode is entered. We don't plan to use + xgterm-nogui, but it could be useful as a fallback in case of + problems, or for testing. (7/14) + +sys/mwcs/iwewcs.x + The code which checks CTYPEi for known function types was tightened + to prevent confusion over names that share the same prefix. Hence, + function names like "linear", "sampled", and "multispec" must now + be exact matches. The prefixes "Xlon" and "Xlat" must now be "Xlon-" + and "Xlat-" to be recognized (where X is some character like "g"). + (LD Aug98, DT 7/14) + +sys/imfort/imcrex.x + Added the statement "Memc[IM_USERAREA(im)] = EOS" to initialize + the user area of a newly created image (as IMIO already does in + imio$iminie.x). Without this, there were cases where a new image + could be created with arbitrary junk in the user area. + (MC Aug98, DT 7/14) + +sys/plio/pllnext.x + After obtaining an opcode I_SH, the code does not update the value + of ld_ip(ld) even though ip has been incremented. Adding + ld_ip(ld) = ip + 1 + in the block 'case I_SH' statement solved the bug presented when + trying to copy a pixel list array into a subarray of an existent + pixel list array. (NZ Sep98, DT 7/14) + +sys/plio/plloadf.x +sys/plio/plsavef.x + Fixed a minor typo: various "mii_" names where the actual MII names + do not have an underscore. This is harmless as SPP omits the + underscores when it makes the external name, but it is preferable + to be more consistent. (7/14) + +sys/vops/asok.gx + The algorithm used in this routine was found to be extremely slow in + cases where many or all of the elements of the input area were equal. + Replaced by a different algorithm from Wirth which appears to avoid + the problem. (LD Mar 99, DT 07/14) + +sys/pmio/pmrop.x +sys/pmio/pmsten.x + pm_rop, used to perform a rasterop on an image mask, had a problem + where the operation could be performed on an area one pixel too + large in cases where an image section was in effect on the image + associated with the image mask. The code was revised to fix this + problem and add some more clipping logic in the process. + The pm_stencil routine is very similar to pm_rop (pm_stencil performs + a rasterop through a stencil mask) and was similarly modified. + (NZ Sep98, DT 07/15) + +unix/os/zfiotx.c + Fixed a case where the internal descriptor "port" (used for terminal + devices) could be referenced on a non-terminal device, causing a nil + pointer reference. This could occur when doing raw mode reads from + the terminal, but writing to an output text file instead of the + terminal. (NZ Feb99, DT 07/15) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfencode.x +sys/imio/iki/fxf/fxfupdhdr.x + While testing the new FK we found that files written under the + new system, using a new ISO Y2K format for DATE-TLM, could not be + read under earlier versions of IRAF. The fxf_encode_date routine + was changed to add support for formatting DATE-TLM in the old + format (which is already Y2K compliant in any case). The call + to fxf_encode_date in fxfupdhdr.x now calls it in such a way that + the old DATE-TLM format will continue to be used until 2010, by + which time one would hope that people will have upgraded to a + more recent version of IRAF so that the ISO format version of the + keyword can be used. (07/15) + +unix/os/zfiomt.c + Incredibly, this file would not compile in a bootstrap on tucana + (SunOS) even though it had not changed in a long time. It turned + out that zfiomt contained a structure field named "isset" which + aliased a system macro in . Something must have + changed in SunOS to cause this file to be included. The problem + was solved by changing "isset" in zfiomt.c to "valset". (7/15) + +lib/imio.h + Increased the default file buffer size used by IMIO a factor of 4 + from 65536 to 262144. The units are XCHAR, so in byte units the new + default image file buffer size increased from about 128 KB to about + half a megabyte (about the size of dev$pix). Note that applications + can override the default buffer size with an imset option, and any + such existing applications will be unaffected by this change + (imcombine for example probably controls the image buffer sizes in + order to have many images open at once). Ordinary imaging tasks + should function with fewer i/o operations however. (7/15) + +unix/hlib/config.h + 1. Increased the size of the file pushback buffer from 512 to 1024. + Not a big deal as it gets incremented anyway if overflow occurs. + + 2. Changed LEN_RANDBUF from 1 to 8. LEN_SEQBUF remains at 8 as + before. Random mode FIO buffers are LEN_RANDBUF*blksize, hence + these have increased in size from 512 bytes to 4KB (random mode + i/o is rarely used). Sequential mode FIO buffers are LEN_SEQBUF + *optbufsize, where optbufsize is returned by the file driver. + Sequential mode (fseti (fd, F_ADVISE, F_SEQUENTIAL) is also little + used however. Most file operations use the unscaled "optbufsize" + returned by the kernel driver (see below). + + Note config.h contains a few size definitions which are not actually + used any longer in the code, since these values now come from the + device drivers are are tuned for each device and host system. Hence + these older values were unchanged. (7/15) + +unix/hlib/libc/kernel.h + Increased the optbufsize for a binary file from 4096 to 32768. The + static file optbufsize was similarly increased, but static (mapped) + files are little used in the current system. All the other optbuf + sizes remained the same. The network devices, process communications + buffers, and so on all remain at 4KB since this value is a good + match for the buffer sizes used in the Unix kernel. + + Hence, ordinary binary file i/o operations now use 32 KB buffers + instead of 4 KB buffers. The special cases of random mode binary + file i/o and sequentially optimized binary file i/o have default + buffer sizes of 4 KB and 256 KB respectively. These should be + reasonable, safe, and efficient buffer sizes for most applications. + (7/15) + +sys/imio/iki//fxf.h +sys/imio/iki//fxfrdhdr.x +sys/imio/iki//fxfupdhdr.x + 1. The FK was revised to handle the case of writing to an image + which is being accessed using on-the-fly pixel conversion, e.g., a + byte image or a short image with scaling to real. The current + version of the FK only supports reading such images, so an attempt + to write pixels if OTF scaling is in effect causes an i/o error. + Opening the image read-write is permitted however, so that the + header can be edited. + + 2. The zfio code was reworked to eliminate the high level calls + which have crept in recently (syserr etc.). A FIO driver can make + only low level calls, e.g. to pure code routines or the iraf + kernel. Because the file driver is called by FIO, calling anything + that might call FIO can result in recursion and various nasty + situations we would prefer to avoid. To aid in implementing this a + status variable FIT_IOSTAT (as well as some extra space) was added + to the main FK descriptor. A read or write call will initially + set this to OK, but set a nonzero value if an error occurs or the + i/o operation is completed. The ZAWAIT routine later returns the + status to the caller. It appeared that the old code was not always + checking for and returning the low level i/o status. (7/15) + +pkg/cl/main.c +pkg/cl/cl.x +pkg/cl/cl.par + The CL was modified to add basic support for using the CL as a host + shell for shell scripts. When this is done the shell script + effectively replaces the login.cl file, hence startup is faster and + flexibility is maximized, but the script is responsible for any + initialization normally done by login.cl (e.g. loading packages). + This implementation is still fairly basic, e.g. the argument + handling facilities are limited, but it works. + + On a Unix system, the first line of a script which calls the CL as + a shell should be something like "#!/usr/local/bin/cl.e -f", where + /usr/local/bin/ would be either a copy of the cl.e executable, + or a link such as cl.e -> /iraf/iraf/bin.ssun/cl.e (don't call the + link "cl", as this name is already used for the shell script used + to start up an interactive iraf session). (RS, DT 7/15) + +pkg/system/references.cl +pkg/system/help/getoption.x +pkg/system/help/prhelp.x +pkg/system/help/prhlpblk.x +pkg/system/help/prfile.x +pkg/system/help/help.h + The REFERENCES task was modified to add the package name to the + output line for each task. Usage is unchanged, i.e., type + refer upd+ to regenerate the uparm$quick.ref file (using your + current list of defined packages) then "refer pattern" to find + all references matching the given pattern. (MF Jun98, DT 7/15) + +unix/hlib/zzsetenv.def + Changed the version string to "NOAO/IRAF V2.11.2EXPORT". (7/17) + +pkg/xtools/gtools/gtreset.x + This procedure was incorrectly declared as a function. (7/21, FV) + +pkg/xtools/icfit/icgfit.x + This routine is called with a graphics descriptor for interactive + fitting. The descriptor is set in an internal structure. Other + procedures, which may be called both for interactive and + non-interactive fitting, check if the descriptor is not NULL + before sending GUI messages. The problem occurs if this procedure is + first called interactively and then the non-interactive fitting + routine is called later (maybe after a deactivate workstation or + closing the descriptor) resulting in GUI messages being sent + when not in interactive mode. The solution is to return the + internal descriptor value to NULL after finishing the interactive + fitting and returning from this procedure. (7/22, FV) + +unix/hlib/mkfloat.csh + Revised the status messages slightly to make it more clear what + the program is doing. The new format is "Doing blah... done". + (7/27) + +dev/hosts + Added dbell's RH6 machine "shea". (7/28 MJF) + +pkg/math/iminterp/ii_greval.x +pkg/math/iminterp/asigetr.x +pkg/math/iminterp/msirestore.x + Fixed an uninitialized variable problem in the ii_grdriz routine + that was detected by the OpenVMS compiler. Also fixed a couple of + bugs in the new unused routine asigetr and in the new msirestore + that were detected with spplint. (8/3 LED) + +sys/imio/iki/fxf/zfiofxf.x + Added some conditional byte swapping for type short data in the + on-the-fly conversion code. (8/09) + +pkg/images/imutil/src/t_imarith.x + Added a check for division by zero in the header keywords. A warning + is printed, the keyword is not updated, and the task completes without + aborting. (8/10 FV) + +pkg/xtools/inlfit/inreject.gx +pkg/xtools/inlfit/inrejectr.x +pkg/xtools/inlfit/inrejectd.x + Rearranged the code slightly to avoid a missing sfree error detected + by spplint. (8/10/99 LED) + +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfupdhdr.x + Changed the cutover date for the DATE keyword from the fixed value + 2000 to 0. Added a new hidden, not normally used environment + variable "isodates" to allow this value to be explicitly specified. + What this means is that by default, v2.11.2 will use ISO (Y2K) + format consistently from the beginning, but if this causes a problem + for some reason "isodates" can be set to some future date to cause + old format date strings to be written. It doesn't appear that the + FK or any current IRAF code actually uses the DATE keywored generated + by the FK, so there shouldn't be a backwards compatibility problem + reading with older code, images written by a V2.11.2 system. + + The value of isodates it the year on and after which ISO format + dates will be written. For example, to generate ISO format dates on + or after Jan 1, 2000, the value "2000" would be used. The value "0" + (zero) is used by convention if ISO format dates are always + desired. (8/10) + +pkg/xtools/icfit/icggraph.gx + Rearranged the code to avoid a return without an sfree. (8/10 FV) + +pkg/xtools/fixpix/xtpmmap.x + Removed extra argument to imgl1i. (8/11 FV) + +pkg/xtools/imtools.x + Changed to correctly declare fnext as a function. (8/11 FV) + +pkg/xtools/xtanswer.x + Fixed incorrect number of arguments in getline call. (8/11 FV) + +pkg/xtools/gtools/gtcolon.x + Corrected definition of btoi. (8/11 FV) + +sys/gio/cursor/rcursor.x +sys/gio/cursor/gtrwritep.x +sys/gio/cursor/gtrundo.x +sys/gio/cursor/gtrstatus.x +sys/gio/cursor/gtrredraw.x +sys/gio/cursor/gtrpage.x +sys/gio/cursor/gtrgtty.x +sys/gio/cursor/gtrctrl.x +sys/gio/cursor/gtrbackup.x +sys/gio/cursor/grcwcs.x +sys/gio/cursor/grctext.x +sys/gio/cursor/grcpl.x +sys/gio/cursor/grcopen.x +sys/gio/cursor/grcinit.x +sys/gio/cursor/grccmd.x +sys/gio/cursor/grcclose.x +sys/gio/cursor/grcaxes.x +sys/gio/cursor/gtrinit.x + It turned to to not be needed, but in the process of checking out a + bug on another platform I beefed up the error checking in the GIO + cursor mode code. This is always a good idea, so I will leave the + changes in. (8/11) + +sys/etc/main.x +sys/etc/xalloc.x +sys/fio/diropen.x +sys/fio/fwtacc.x +sys/fio/osfnlock.x +sys/gio/sgikern/sgk.x +sys/imio/db/idbkwlu.x +sys/imio/iki/stf/stfwfits.x +sys/ki/kfchdr.x +sys/ki/kopdpr.x +sys/mtio/mtopen.x +sys/tty/ttygsize.x + Added a few missing sfree() calls, found with an automatic code + checking tool. (8/12) + +pkg/cl/history.c + Ehistory command: When UP is used a few times, followed by enough + DOWNS to get back to a "cl> " prompt, the next command entered is a + silent noop. The next command after that is fine. Adding an + execute=1 in get_command() when repeating input_ on an empty line + fixes this problem (08/12 SRo/RS/DT) + +sys/imio/impnl.gx + Fixed a typo in a comment block. (08/12) + +pkg/cl/history.c + Increased the maximum number of history commands to be listed from + 100 to 800 (the actual history buffer storage is 8192 which is + probably already enough to store 800-1000 or more commands, since + the average command is fairly short). (08/12) + +unix/gdev/sgidev/mkpkg.sh +unix/gdev/sgidev/README.gif + +unix/gdev/sgidev/sgi2gif.x + +unix/gdev/sgidev/sgi2xbm.x + + Added these two new SGI graphics translators, used to write IRAF + graphics to GIF or XBM files, e.g. to generate on-the-fly IRAF plots + to include in web pages. (08/12 MJF/DT) + +unix/os/zfiond.c + Modified the server-side code to set the socket option SO_REUSEADDR + when opening a socket and binding it to an IP address and port. + This avoids the annoying delay which is otherwise seen when a + server quits, but the socket it was using is not released for + some time until the kernel times it out and releases it. This + only affects server-side connections and currently I don't know + of any IRAF servers that use ZFIOND, but probably all server-side + socket code should use this feature. (setsockopt was added quite + some time after most of the socket code in IRAF was originally + written). (08/12) + +dev/graphcap + Added generic entries "g-gif" and "g-xbm" for the new sgi2gif and + sgi2xbm translators. (8/13/99 MJF) + +sys/imio/iki/fxf/zfiofxf.x + In fxfzst the "physical" file block size and buffer size parameters + were being returned as multiples of the FITS logical block size, + 2880. Low level file i/o however must observe the real physical + file block size and maximum transfer sizes as returned by zsttbf. + On Unix systems this would not matter as i/o transfers do not have + to be block aligned, however this would cause problems in some cases + on VMS. The 2880 related code was removed, and the file parameters + from zsttbf are now returned as-is without change. (This still may + not be entirely correct as the block size and max transfer size + should perhaps be scaled if the virtual file driver scales the + data, but this is complicated by the fact that the FITS header is + not also scaled; it is probably not going to be a problem). (8/16) + +sys/plio/plcircle.x + Tweaked up the circle drawing computation a bit. (8/16) + +unix/boot/spp/xc.c + XC was modified to, when linking -Bstatic, switch back to -Bdynamic + at the end of the link line so that -lc is linked dynamic. This is + always a good idea for Solaris systems, and turned out to be + necessary in order for one executable to be runnable on all Solaris + versions (2.5.1, 2.6, 2.7). Most other libraries are still linked + static, mainly so that the Fortran compiler does not have to be + installed to be able to run IRAF executables on a given platform. + + Supporting Solaris 7 was what forced the issue here. Note: Solaris + IRAF executables are linked under Solaris 2.5.1 and will run on + solaris versions 2.5.1 through 2.7. (8/18) + +--------------------------------- +V2.11.2 patch released. (18Aug99) + +dev/graphcap + Modified the g-gif entry to use a pid in the filename (8/19/99 MJF) + +language/doc/hidetask.hlp + The correct syntax seems to be 'hidetask task,[task,..]'. The + help file did not have the commas (nz aug 20,99) + +pkg/dataio/export/exrgb8.x + Fixed a bug causing the cmap() function to write a garbage line at the + top or bottom of the output image. (8/20/99 MJF) + +dev/devices.hlp + Added and entry for ursa!mtp at Taft's request (8/24/99 MJF) + +pkg/images/tv/wcslab/t_wcslab.x +pkg/images/tv/wcslab/wcslab.x + Fixed a couple of bugs in the wcslab task that were causing it + to fail with the message "ERROR: MWCS: coordinate system not + defined (physical)" on the DecAlpha when the usewcs parameter + was set to yes, and on Sun systems when the input image was + undefined. (8/28/99 LED) + +sys/imio/iki/fxf/fxfupdhdr.x + 1. An sfree was in the wrong place; moved to the end of the block + of code it was in. + 2. In the "diff" routine, the OBJECT keyword was not being accounted + for correctly in computing the new header size. + 3. If the new header were more than one FITS block (36 cards) smaller + than the old, the extra blocks were being filled with zeros instead + of blanks. + 4. Boy would this code be a lot better off it were using the new KWDB + interface to manage the headers... + (9/15) + +pkg/images/tv/wcslab/wcslab.h + Added an entry for tnx to the list of supported projections types. + This apparently fixed a garbled plot problem for tnx images, + espcially for thos around ra=0.0. + (9/17 LED) + +pkg/math/curfit/mkpkg +pkg/math/deboor/mkpkg +pkg/math/iminterp/mkpkg +pkg/xtools/inlfit/mkpkg + Added some missing file dependencies to the math library mkpkg files. + (9/20 LED) + +pkg/images/tv/display/mkpkg +pkg/images/tv/wcslab/mkpkg +pkg/images/tv/imedit/mkpkg +pkg/images/tv/imexamine/mkpkg + Added some missing file dependencies and removed some unecessary ones + from the tv package mkpkg files. + (9/21 LED) + + +pkg/images/imcoords/src/mkpkg +pkg/images/imgeom/src/mkpkg +pkg/images/immmatch/src/imcombine/generic/mkpkg +pkg/images/immmatch/src/imcombine/mkpkg +pkg/images/immmatch/src/imutil/generic/mkpkg +pkg/images/immmatch/src/imutil/mkpkg + Added some missing file dependencies and removed some uneccessary ones + from the image package mkpkg files. (9/21, LED) + +pkg/plot/mkpkg + Added some missing file dependencies and removed some uneccessary ones + from the plot package mkpkg files. (9/21, LED) + +pkg/proto/mkpkg + Added some missing file dependencies and removed some uneccessary ones + from the proto package mkpkg files. (9/21, LED) + +pkg/utilities/curfit.gx +pkg/utilities/curfit.x + Removed an unecessary include statement (9/22, LED) + +pkg/xtools/icfit/icshow.x +pkg/xtools/icfit/icvshow.gx + The gt pointer was not being used when called directly by + UTILITIES.CURFIT. If the task was run non-interactively, so there + was no prior call to the icfit graphics routines, then IC_GT structure + element was not set causing an error. These routines now set the + element with the gt argument passed by the calling routine. + (9/14, Valdes) + +pkg/images/imutil/imreplace.par +pkg/images/imutil/src/imrep.gx + Fixed a floating-point precision problem with short/int images in + which the lower cutoff could be rounded up. Also fixed a typo in the + parameter file. (9/22/99, MJF) + +imio/iki/fxf/zfiofxf.x + The routine fxf_cnvpx() was not offsetting properly to FITS + units other than one, e.g. giving a segvio when trying to access + the 2nd extension. This would only affect access to images of + type byte or short where on-the-fly conversion is required. + Adjusting to the beginning of the unit solved the problem. + (Some clean up done as well). (9/23 NZ/DT) + +imio/iki/fxf/fxfopix.x + In routine fxf_discard_keyw() a change was made to filter out the + keyword BLOCKED from obsolete GEIS files in FITS format. This was + causing problems when adding a keyword into a header that was full + to the 2880 bytes block and the INHERIT keyword was set to T. + (9/23 NZ/DT) + +imio/iki/fxf/zfiofxf.x + A buffer overrun could occur in fxfzwr, when writing to the output + image. This caused a SEGVIO when testing the new kernel on an + OpenVMS system. (9/29) + +pkg/images/tv/imexamine/mkpkg + Added a file dependency to the mkpkg file that was missed the last + time, (9/30 LED) + +pkg/images/tv/imedit/t_imedit.x + The use of a temporary image causes the output image type to be + set by "imtype" instead of any explicit extension. Changed to + use the xt_mkimtemp routine which tries to create a temporary image + of the desired output image type. (10/1 FV) + +pkg/images/immatch/src/imcombine/t_imcombine.x + Modified error recovery to avoid a tranfer out of an IFERR block + message. (10/14, FV) + +pkg/images/immatch/src/imcombine/t_imcombine.x + A call to IMUNMAP within the THEN clause of an IFERR replaces the + error string (inappropriately) so that a later ERRACT reports the + wrong error. The code was modified to get the error string before + calling IMUNMAP and then restores the error condition with an + ERROR call instead of an ERRACT. (10/21, FV) + +pkg/dataio/export/bltins/exeps.x + Fixed an array overrun when writing EPS trailer comments. (10/25/99 MJF) + +sys/imio/iki/fxf/fxfopen.x + The iferr handler for fxf_rheader was catching header read errors and + turning them into warning messages. These can be serious errors + though requiring the image open to fail. Added an erract(EA_ERROR) + to repost the error after the cleanup performed in the iferr block + in fxfopen. (10/26) + +sys/etc/mkpkg +sys/fmio/mkpkg +sys/gio/calcomp/mkpkg +sys/gio/cursor/grcstatus.x +sys/gio/mkpkg +sys/gio/nsppkern/mkpkg +sys/gio/stdgraph/mkpkg +sys/imio/iki/fxf/mkpkg +sys/imio/iki/oif/mkpkg +sys/imio/iki/qpf/mkpkg +sys/ki/mkpkg +sys/memdbg/mkpkg +sys/plio/tf/mkpkg +pkg/system/help/mkpkg + Fixed minor mkpkg library file dependency related problems or + oddities. (10/26) + +sys/mwcs/iwctype.x + Modified the code which recognizes the cards CDi_j, CDELTi, CRPIXi, + CRVALi, and CTYPEi to accept these cards only if the name is an + exact match, i.e., no trailing characters. Data in the draft FITS + WCS standard may have a character appended if there are multiple WCS, + and this could cause a secondary WCS to be confused with the primary. + (10/26) + +unix/os/zfchdr.c + This code trims any trailing "/" from a directory path before + doing a chdir to the new directory. This would fail if the path + were "/" (the unix root directory). Changed the code to trim the + trailing slash only if it is a trailing slash. (10/26) + +pkg/math/gsurfit/gsder.gx +pkg/math/gsurfit/gsderr.x +pkg/math/gsurfit/gsderd.x +pkg/math/gsurfit/gs_fder.gx +pkg/math/gsurfit/gs_fderr.x +pkg/math/gsurfit/gs_fderd.x +pkg/math/gsurfit/gs_deval.gx +pkg/math/gsurfit/gs_devalr.x +pkg/math/gsurfit/gs_devald.x + Fixed a bug in the code which computes the derivatives for non-linear + chebyshev and legendre polynomials surfaces. In the process + of fixing those bugs decided to rewrite the code using the same + recursion relations that are used to generate the original surface. + (10/27 LED) + +pkg/system/references.cl + Modified the task to filter the stderr as well as stdout, to eliminate + the "No help available" warning messages. (10/29) + +dev/hosts + Added new redhat boxes atand and omhah (11/3/99, MJF) + +pkg/dataio/import.par +pkg/dataio/export.par + Changed query param modes to auto to avoid prompt from epar :go + command. (11/4/99 MJF) + +--------------------------------- +V2.11.3 patch in BETA test. (11/05) + +dev/hosts + Added PC-IRAF systems vmware, slack40, suse62 and sol7 (11/16/99 MJF) + +pkg/images/immatch/src/imcombine/icombine.gx + An input array was declared with a value of 3 though it was passed to + the routine with 4 elements. Later there was a reference to + the 4th element. While this is legal as the size in the declaration + is a dummy this was a compiler error on one platform. Changed the + declaration to 4. (11/19/99, Valdes) + +pkg/images/imfilter/src/fmedian.x +pkg/images/imfilter/src/frmedian.x +pkg/images/imfilter/src/fmode.x +pkg/images/imfilter/src/frmode.x +pkg/images/imfilter/src/fmd_hist.x + Modified the fast median algorithm histogram storage from short to int + to avoid integer overflows in the case that xfilter * yfilter > 32767 + and more than 32767 pixels end up in 1 bin as is likely to happen + in bad pixel regions. (11/19/99, Davis) + +pkg/math/gsurfit/gsder.gx +pkg/math/gsurfit/gsderr.gx +pkg/math/gsurfit/gsderd.gx + After rewriting the derivative code to work correctly for the higher + order chebyshev and legendre cases, forgot to add back in the 4 lines + that do the final normalization to user (not -1.0 to 1.0 normalized) + coordinates, causing the derivatives to be way offscale. Found + by user running longslit. Only affects 2.11.3. (11/23/99 Davis) + +sys/fmtio/evvexpr.gy + The main routine of evvexpr dynamically allocates the output operand + structure. It was setting the flags O_FREEVAL+O_FREEOP for this + structure, overriding any flags in the operand returned by the + expression evaluator, but clearly only O_FREEOP is warannted as the + only thing this code allocates is the operand structure. Whether + or not any vector value buffer should be freed has to be determined + by the expression code which generates the operand returned by the + expression evaluator. Hence the O_FREEVAL flag was removed. (11/23) + +pkg/images/imutil/src/imexpr.gx + Several places in the code where a new operand structure is being + initialized, code was added to either clear the entire structure, + or explicitly set O_FLAGS(o)=0 in cases where we wanted to be sure + that any values from an earlier use of the same operand structure + were not unintentionally reused. In particular, in any case where + the operand structure is being reused the O_FREEOP flag should be + clear. In any case where the operand is vector-valued and the + data vector is a pointer returned by IMIO, O_FREEVAL should be + clear as it is up to IMIO to eventually free the buffer. (11/23) + +pkg/images/imutil/src/imexpr.gx + Changed the value of LEN_IMOPERAND from 16 to 17. This problem was + probably never seen as it would be a problem only for double + operands, which are probably not used all that often. (11/24) + +pkg/images/imutil/doc/imexpr.hlp + Fixed some typos in the imexpr task help page. (11/24 LED) + +unix/os/zfiomt.c + Changed one occurrence of zmtdbg1() to zmtdbg() as the call in + question did not have an argument. This was harmless, but incorrect + and caused a compiler warning on one platform. (11/24) + +--------------------------------- +V2.11.3 patch on verge of being frozen... (11/24) + +dev/graphcap +dev/imtoolrc + Added new frame buffers for Mosaic at full frame and with several + block averaging factors. New buffers are: imt41|imt8800=8800x8800, + imt42|imt4400=4400x4400, imt43|imt2200=2200x2200, and + imt44|imt1100=1100x1100 (11/25 MJF) + +sys/osb/ieee.gx +unix/as.sparc/ieee.gx +unix/as.ssol/ieee.gx + This routine was missing some {} braces around an IF clause in + ieevupk. Although the code was technically correct as there was + only one statement (a multiline do-loop) in the IF clause, it + needed braces to be safe against modifications. (11/30) + +sys/fmtio/evvexpr.gy + There was another bug in this routine which went undetected when it + was modified several days earlier. The code would set O_FLAGS on + the output operand to ensure that the operand structure is later + deleted. By this point the actual operand had been created by + the expression evaluator. The bug was that the code was simply + overwriting O_FLAGS in the output operand. Instead it needed to + preserve the existing flags, merely insuring that the O_FREEOP flag + was set (setting the flag to O_FREEOP would clear the O_FREEVAL + flag if already set in the operand). The code was modified to + "or" in the flag, rather than clobber the whole flag word. (12/01) + +sys/imio/iki/stf/stf.h + Increased MAX_PCOUNT (the number of keywords in a group header block + for STF images) from 50 to 99. (12/02) + +sys/libc/scanf.c + Added support for "%n". This returns to an integer output argument + the number of input characters scanned thus far (a feature of ANSI C + stdio). (12/02) + +sys/libc/printf.c + Modified the *printf routines to recognize 'l', 'E', and 'G' in + formatted prints, for enhanced compatibility with ANSI C. 'l' is + ignored since it is a no-op on our current platforms anyway (related + modifiers such as 'h', 'L', and 'q' are not supported). 'E' and 'G' + are permitted, but are handled the same as 'e' and 'g' since IRAF + already prints floating point numbers using 'E'. (12/02) + +sys/libc/zztest.c + Added support to the test routine for scan for %n, and ran some + simple tests. Seems to work. (12/02) + +pkg/images/imfilter/src/frmedian.x +pkg/images/imfilter/src/frmode.x + Changed 2 aclrs calls to aclri calls that were missed when the + frmedian / frmode tasks were upgraded to work with larger kernels. + (12/03 LED) + +--------------------------------- +V2.11.3 patch frozen. (12/03) + +--------------------------------- +From here on PC-IRAF revisions will be recorded here as well as those for +the reference Sun port. Both the Sun and PC-IRAF ports are equally reference +systems now and it is long past time to start recording revisions formally +for PC-IRAF. + +unix/hlib/install [pcix] + Fixed a typo in the install script. (12/09) + +dev/tapecap.linux [pcix] +dev/tapecap.freebsd [pcix] + The tapecap.linux file had a entry which referred to a + "generic-exabyte" entry, but this entry was named "generic-exb" + later in the file. Changed the later reference to generic-exabyte". + Modified tapecap.freebsd to use the same name, although the entry + is not used in tapecap.freebsd. (12/10) + +pkg/proto/t_bscale.x + Changed the type declarations for the functions imgnld/imgnlx + and impnld/impnlx from double/complex to int to fix a hangup + or floating point errors generated when bscale is run on double + or complex images. (12/11 LED) + +pkg/dataio/import/ipdb.gx +pkg/dataio/import/bltins/ipgif.x + Fixed a string overflow bug causing segvios on PC system, also + commented out an unneeded evvfree() (12/13 MJF) + +noao/mkpkg + The entries for the HP archiectures (hp700 etc.) were missing the + -d $(DIRS) argument listing the noao directories to be processed + for an architecture change. (12/14) + +dev/hosts + Added ssun machine zathras (12/14 MJF) + +pkg/images/immatch/src/fmcombine/icsetout.x + Fixed error with MWCS dimension mismatch when using offsets on + input images which have been dimensionally reduced. (1/12, FV) + +pkg/images/immatch/src/imcombine/icgdata.gx +pkg/images/immatch/src/imcombine/iclog.x +pkg/images/immatch/src/imcombine/icmask.x +pkg/images/immatch/src/imcombine/icombine.gx +pkg/images/immatch/src/imcombine/icscale.x +pkg/images/immatch/src/imcombine/icsetout.x + Changed declarations for the array "out" to be ARB rather than 3 in + some places (because it was not changed when another element was + added) or 4. This will insure that any future output elements + added will not require changing these arguments for the sake of + cosmetic correctness. (1/13, FV) + +pkg/images/tv/imedit/t_imedit.x +pkg/images/tv/imedit/epimcopy.x + Added some errchks. In particular, even though the output and working + images can be mapped without an error there could be an error in the + first I/O as when the imdir directory is not available/writeable. + (1/18, FV) + +pkg/images/immatch/doc/imcombine.hlp +pkg/images/immatch/imcombine.par + The "outtype" parameter can take the value "none" in addition to one + of the standard datatypes. The help page was incorrect/unclear what + was meant by not specifying an output type. + (1/18, FV) + +pkg/images/lib/skywcs.x + Incorrect values for the epoch of observation were being computed + and printed by tasks like skyctran and imcctran if: 1) the input + coordinate system was being read from an image, and 2) the input + coordinate system was galactic. The problem was that the epoch was + being converted to MJD twice instead of once resulting in strange + epoch values. Unless a proper motion correction was being computed + this problem should have little practical effect although it is + disturbing to odd units in the file headers. (1/31/00, LED) + +pkg/dataio/reblock/t_reblock.x +pkg/dataio/reblock/reblock_file.x + Fixed a bug in the block writing error checking code that could cause + problems if an write error occurred. Also modified the code to + open the output file only after the first non-zero byte read in + order to avoid a magtape driver problem with opening and closing + an empty magtape file for writing. In the process of doing this + noticed a potential initialization problem that could when switching + between record copy, record trim, or record pad modes. (2/10/00 LED). + +pkg/images/immatch/wregister.cl +pkg/images/immatch/sregister.cl + Changed the boundary option "refect" to the correct value "reflect". + (2/29/00 LED) + +pkg/images/imgeom/imlintran.cl + Changed the nrows argument names to nlines which is what it is + supposed to be. + (4/11/00 LED) + +sys/imio/iki/fxf/fxfupdhdr.x + After incrementing the header size, the old header and pixel offset + were still in memory causing data to be overwritten. The solution was + to change the modification date of the file to invalidate the cache + so that next time the header is read it will be done from disk. + From testing Gemini IRAF scripts. (nz feb.24.00) (04/11) + +sys/imio/iki/fxf/zfiofxf.x + BITPIX = 8 was not handled correctly. The number of bytes read needs + to be returned to awaitb() (which calls the FXF driver) for correctly + keeping the file offset. Also BITPIX = 16 with scaling that converts + the file to 4 bytes had the same problem. (04/11) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x + 1. The OBJECT keyword was causing havoc with some applications. + It was disappearing from an extension when it had the same + value as the global header. Now it will remain on the extension + regardless of its value and what INHERIT is. + 2. Clean up keywords from the PHU that belong to an extension only. + 3. Clean up EXTEND from an extension as well. (nz feb.24.00) + (04/11) + +sys/mwcs/wftsc.x +sys/mwcs/wfqsc.x +sys/mwcs/wfpco.x +sys/mwcs/wfpar.x +sys/mwcs/wfmol.x +sys/mwcs/wfmer.x +sys/mwcs/wfgls.x +sys/mwcs/wfcsc.x +sys/mwcs/wfcar.x +sys/mwcs/wfait.x + The car, mer, pco, gls, par, ait, csc, qsc, and tsc MWCS function + drivers were modified to correct a radian/degree conversion error + that would cause troubles for images with RA/LON < 180 and DEC > 0.0. + (04/11) + +pkg/images/imutil/src/imexpr.gx + Changed the offset of the IM_OP (operand value) field of the operand + structure to double align it. Increased the size of the structure to + reflex the increase in size. Also modified the main IMEXPR descriptor + to double align the IE_IMOP array of operands. (04/11) + +sys/imio/imt.x + The heuristic used to estimate the length of the internal array "fnt", + used to hold the edited image template string, could fail to produce + a long enough buffer in some cases. Modified the heuristic to be + more generous in estimating the maximum buffer size required. (04/11) + +qpgpar.x + The code which parses the input string and extracts a parameter name + was not checking for EOS and could cause a buffer overflow in some + circumstances. (04/14) + +dev/graphcap + Commented out the 'xtermold' entry which contained an unescaped colon + character and could cause parsing errors. (04/17 MJF) + +pkg/images/immatch/src/imcombine/icmedian.gx + Replaced with the faster Wirth algorithm as used in vops$asok.gx. + (5/16 FV) + +pkg/images/tv/display/dspmmap.x + When a pixel mask (overlay or bad pixel) needed to be matched to + the data in physical coordinates the internal generation of a + new mask was being doing in short integers. This would truncate + any masks with values greater than 16 bits. All uses of short + where changed to integer. (5/16 FV) + +pkg/dataio/export.par + Made the 'format' parameter automatic mode (5/16 MJF) + +pkg/dataio/export/expreproc.x + Modified so that the 'overlay' colors are not scaled. (5/16 MJF) + +pkg/proto/fields.x + Added 2 missing close statements and a missing sfree statement + that results in a "too many open files" error when the fields + task tries to process a long ~> 59 file list. (5/19 LED) + +imio/sys/iki/fxf/fxfupdhdr.x + When making a newcopy of an image and requesting a minimum number of + blanks lines using the PADLINES parameter in the output header, a + segmentation violation occurred. The problem was that at header + update time, the header and pixel offset arrays were not set, hence + we could nod determine the header size before adding the padline + amount. The solution was to use the 'diff' variable which has the + correct amount of blank characters to add to the output header to + insure padline. (5/29 NZ,DCT) + +imio/sys/iki/fxf/fxfrfits.x + With inheritance if an extension header keyword was also in the + global header but with a different value, the hedit task would get + the global header value and not the value from the requested + extension. The problem was that a previous problem with HIERARCH + keyword we started to compare the whole 80 characters rather than + the old SZ_KEYWORD. The solution is to compare the strings up to + the '=' sign. (5/29 NZ,DCT) + +unix/boot/spp/xc.c [sun, pcix] + This code contained some old hardcoded file path buffers which were + too small and could overflow. Updated these to use SZ_PATHNAME. + (5/30) + +unix/os/zfiolp.c [sun, pcix] +unix/os/zfiopl.c + Modified these routines to use the newer routine mkstemp instead of + the old mktemp. mkstemp not only generates a unique name but + atomically creates the file, avoiding a possible race condition. + (5/31) + +pkg/images/immatch/src/imcombine/t_imcombine. +pkg/images/immatch/src/imcombine/icimstack.x +pkg/images/immatch/src/imcombine/iclog.x +pkg/images/immatch/doc/imcombine.hlp + When there are a large number of images with bad pixel masks both the + input images and the bad pixel masks are stacked for combining. The + addition of stacking the masks allows for independent bad pixel masks + for each input image which was not supported previously. + (6/21 FV) + +pkg/dataio/export/bltins/expgm.x +pkg/dataio/export/bltins/exppm.x + Fixed a bug in writing the format header under PCIX. (6/23/00 MJF) + +sys/fio/filopn.x + Added some error handling to catch any errors from the internal + system routine ftwacc and map them to SYS_FOPEN (cannot open file). + This affects only standard disk files; a failure to open a special + device will result in a different error (SYS_FOPENDEV). (7/03) + +sys/imio/iki/ikiclose.x +sys/imio/iki/ikiopix.x +sys/imio/iki/ikiupdhdr.x + In each of these routines, added an IFERR handler for the called + image kernel routine, to catch any low level errors and map them to + the error action posted by the IKI routine. For example, any file + open or other system problems occurring in iki_opix will now ensure + that the SYS_IKIOPIX error is posted. The routines were already + trying to do this, but the IF-test employed could fail if an error + action was taken by the kernel routine. (7/03) + +dev/hosts + Added SunOS machine bruckner. (08/07 MJF) + +pkg/images/immatch/src/imcombine/t_imcombine.x + When there is an output mask or sigma image and the number of images + exceeds the maximum number allowed by the number of logical file + descriptors the task failed to delete the files when starting over + using the stacked image approach. This would result in an image + already exists error. This was fixed by deleting the files upon + error recovery. (8/09, FV) + +sys/imio/iki/fxf/fxfrfits.x + When reading a FITS file with PHU having NAXIS = 0 and no extensions + the FK would not record the PHU as already been read, leading to + further reading, which would result in and EOF error message. + (8/09 NZ/DCT) + +./sys/imio/mkpkg +./sys/imio/imopsf.x + imopsf (open pixel file) could be called more than once when + accessing a pixel mask as an image. The pixel mask code in this + file was not prepared for this, and could execute twice, causing + dev$null to be multiply opened. At image close time only one file + descriptor would be closed, causing a file descriptor leak. The + imopsf code was changed so that the pixel mask initialization code + is only executed once for an image. Note however that imopsf can + nonetheless be called more than once on an image in some cases, + e.g. the system does this to ensure that imsetbuf is called, so it + would not be correct to modify imopsf so that it simply returns + if called on an already open image. (8/16) + +./sys/imio/impmopen.x +./sys/plio/plloadf.x + Improved the error recovery in these routines so that all open files + are closed and buffers freed if a blatant error occurs, such as + trying to open a non-pixel mask file as a pixel mask image. (8/16) + +./lib/plio.h +./sys/plio/PLIO.hlp +./sys/plio/pll2p.gx +./sys/plio/pll2r.gx +./sys/plio/pllseg.h +./sys/plio/plupdate.x +./sys/plio/plopen.x +./sys/plio/plload.x +./sys/plio/plpoint.x +./sys/plio/plleq.x +./sys/plio/pllpr.x +./sys/plio/pldebug.x +./sys/plio/plssize.x +./sys/plio/plcmpress.x +./sys/plio/plclear.x +./sys/plio/plr2l.gx +./sys/plio/plp2l.gx +./sys/plio/pllrop.x +./sys/plio/pllsten.x +./sys/plio/zzlib.x + The LEN and BLEN fields of the encoded line list (LL) descriptor + would limit the length of a pixel area (and hence the size of a + pixel mask) to the max size of a signed short, 32768. This was due + to the use of a simple array of type short to encode the line list + (which simplifies handling considerably). Nonetheless the limit to + 32K was unacceptable. The fix adopted was to increase the LL header + from 3 to 7 words. Two 16 bit words are now used to encode each of + LEN and BLEN. A "version" word was added to allow the old, new, and + future encodings to be distinguished. A "hdrlen" word was added to + parameterize the length of the LL header, rather than fix it at + compile time as in the initial version. With this change, the + maximum length of an image line under PLIO is increased from 32768 + to 1073741824 (32768*32768). All the higher level PLIO code is + integer, so should already support larger masks. + + This was done in such a way that old line lists can still be read, + although PLIO will always write out new format line lists (pixel + mask files and images, QPOE, and MWCS all store encoded line lists + in external storage, so backwards compatibility is important; also + existing complied programs will continue to generate the old + format). The cost is 8 bytes per encoded line list. For most masks + this should only increase the size of the mask by a few percent at + most. (8/16) + +unix/os/zfiond.c + In the server-side code for a unix socket, "addrlen" was being + computed using an obsolete heuristic which was only correct for + older versions of the BSD socket interface. On newer systems this + could cause an "address already in use" error when opening a server + socket, due to the socket pathname getting truncated. (8/18) + +sys/fio/reopen.x + The FIO reopen routine, used to open an existing host file descriptor + on a new FIO file descriptor (e.g. providing indepedent buffered + streams for a single host file) had a bug which would cause it to + set up the new file descriptor incorrectly. (8/18) + +unix/os/zfiond.c + The ND driver supports a "text" mode which assumes that all program + data is XCHAR and converts to and from 1 byte chars on output. This + is useful for an IRAF program which communicates with an external + host program using only text. A FIO binary stream can be used, but + the external program sees only packed ASCII text while the SPP + program sees only normal SPP text. The :text mode was working for + reads, but broken for writes. On output zawrnd, given a buffer + containing say 128 SPP chars (256 bytes), would compress the data as + it should, but still write out 256 bytes. While incorrect, this + would actually work in many cases (especially when conversing with + external host programs) since the output would be a null terminated + 128 char string followed by 127 bytes of junk. (8/18) + +pkg/images/immatch/src/imcombine/t_imcombine.x + When a "cannot open image" error occurs for some other reason than + running out of file descriptors the task would go into an infinite + loop or given a segmentation error. The checking was improved to + avoid this. (8/31/00, Valdes) + +pkg/images/tv/imexamine/t_imexam.x +pkg/images/tv/imexamine/timexam.x + +pkg/images/tv/imexamine/iecolon.x +pkg/images/tv/imexamine/mkpkg +pkg/images/tv/imexamine.par +pkg/images/tv/doc/imexamine.hlp +lib/scr/imexamine.key + Added new key 't' to ouput an image section centered on the cursor. + (9/02/00, Valdes) + +dev/hosts + Added Buell Jannuzi's new ssun machine 'climber'. + Added Michael Brown's new ssun machine 'bunyip'. (9/5/00 MJF) + +pkg/cl/cl.par + Added the new CL parameter "release". This is a string valued + parameter with values such as "2.11.3a", "2.11.4", "3.0" etc. + This differs from "version" which is a descriptive string such + as "NOAO/IRAF V2.11.3 EXPORT". There can be multiple releases + of one version of the software, and "release" specifies exactly + what build the software is. The release strings are composed in + such a way that they can be used in expressions, e.g. (release >= + 2.11.3) would be true for IRAF V2.11.3 and all subsequent + releases and versions. (9/09) + +--------------------------------- +V2.11.3b limited patch release. (9/10 2000) + +pkg/images/immatch/src/imcombine/icombine.gx +pkg/images/immatch/src/imcombine/icgdata.gx + Additional errchk declarations were needed to catch out of memory + during image reading which were not caught during the initial + pass at reading the images. (9/11/00, Valdes) + +pkg/images/immatch/src/imcombine/t_imcombine.x +pkg/images/immatch/src/imcombine/icimstack.x + Error handling when running out of memory with immap (due to a very + large min_lenuserarea) and when trying to stack was fixed up to + report reasonable error messages and to not go into an infinite loop + trying to manage memory. (9/13/00, Valdes) + +pkg/images/imcoords/src/sffind.x +pkg/images/imcoords/doc/starfind.hlp + Modified the way starfind computes the background estimate used to + compute the first and second order moments so that it does not depend + on the value and density of the central pixel. (10/9/00, Davis) + +pkg/images/immatch/imcentroid.par +pkg/images/immatch/imalign.par +pkg/images/immatch/imalign.cl +pkg/images/immatch/doc/imcentroid.hlp +pkg/images/immatch/doc/imalign.hlp +pkg/images/immatch/src/listmatch/t_imctroid.x +pkg/images/immatch/src/listmatch/mkpkg + Added a new parameter maxshift to the imcentroid and imalign tasks. + Maxshift is the maximum permitted difference between the computed + and predicted shifts. Maxshift can be used to reject objects whose + centers have wandered too far from the expected center. By default + maxshift is undefined. (10/9/00, Davis) + +pkg/xtools/mkpkg +pkg/xtools/doc/xtools.men +pkg/xtools/doc/xtools.hd +pkg/xtools/skywcs/mkpkg +pkg/xtools/skywcs/skdecode.x +pkg/xtools/skywcs/sksavim.x +pkg/xtools/skywcs/skset.x +pkg/xtools/skywcs/skstat.x +pkg/xtools/skywcs/sktransform.x +pkg/xtools/skywcs/skwrdstr.x +pkg/xtools/skywcs/skwrite.x +pkg/xtools/skywcs/skywcs.h +pkg/xtools/skywcs/skywcsdef.h +pkg/xtools/skywcs/doc/ccsystems.hlp +pkg/xtools/skywcs/doc/skclose.hlp +pkg/xtools/skywcs/doc/skcopy.hlp +pkg/xtools/skywcs/doc/skdecim.hlp +pkg/xtools/skywcs/doc/skdecwcs.hlp +pkg/xtools/skywcs/doc/skdecwstr.hlp +pkg/xtools/skywcs/doc/skenwcs.hlp +pkg/xtools/skywcs/doc/skequatorial.hlp +pkg/xtools/skywcs/doc/skiiprint.hlp +pkg/xtools/skywcs/doc/skiiwrite.hlp +pkg/xtools/skywcs/doc/sklltran.hlp +pkg/xtools/skywcs/doc/sksaveim.hlp +pkg/xtools/skywcs/doc/sksetd.hlp +pkg/xtools/skywcs/doc/skseti.hlp +pkg/xtools/skywcs/doc/sksets.hlp +pkg/xtools/skywcs/doc/skstatd.hlp +pkg/xtools/skywcs/doc/skstati.hlp +pkg/xtools/skywcs/doc/skstats.hlp +pkg/xtools/skywcs/doc/skultran.hlp +pkg/xtools/skywcs/doc/skywcs.hd +pkg/xtools/skywcs/doc/skywcs.hlp +pkg/xtools/skywcs/doc/skywcs.men + Added the skywcs library to the xtools package. Skywcs is a + repackaging of code already used in the images.imcoords package + (10/12/00, Davis). + +pkg/images/lib/coomap.key +pkg/images/lib/geofit.gx +pkg/images/lib/geofit.x +pkg/images/lib/geogmap.gx +pkg/images/lib/geogmap.x +pkg/images/lib/geogmap.h +pkg/images/lib/geograph.gx +pkg/images/lib/geograph.x +pkg/images/lib/geomap.key +pkg/images/lib/liststr.gx +pkg/images/lib/liststr.x +pkg/images/lib/mkpkg +pkg/images/lib/rgccwcs.x +pkg/images/lib/rglltran.x + Added support for a :order command to the geomap task so that the + user can change all the fitting orders simultaneously. Fixed an + error checking bug in the geomap and ccmap tasks that could cause a + segmentation violation if there were too few points for a good fit + and the verbose switch disabled. Added a couple of new routines to + the list decoding tasks. Modified the code and mkpkg to use the new + version of skywcs (10/12/00, Davis). + +pkg/images/immatch/src/geometry/t_geomap.gx +pkg/images/immatch/src/geometry/t_geomap.x + Improved the error checking in the geomap tasks (10/12/00, Davis). + +pkg/images/immatch/src/wcsmatch/t_skyxymatch.x +pkg/images/immatch/src/wcsmatch/mkpkg + Modified the skyxymatch task to use the new skywcs library + (10/12/00, Davis). + +pkg/images/imcoords/imcctran.par +pkg/images/imcoords/doc/imcctran.hlp +pkg/images/imcoords/src/ccfunc.x +pkg/images/imcoords/src/ccxytran.x +pkg/images/imcoords/src/skyctran.x +pkg/images/imcoords/src/t_ccfind.x +pkg/images/imcoords/src/t_ccmap.x +pkg/images/imcoords/src/t_ccsetwcs.x +pkg/images/imcoords/src/t_cctran.x +pkg/images/imcoords/src/t_ccxymatch.x +pkg/images/imcoords/src/t_imcctran.x +pkg/images/imcoords/src/t_skyctran.x +pkg/images/imcoords/src/mkpkg + Modified the imcoords tasks to use the new skywcs library. + Added support for doing coordinate transformations accurately on + images with non-zenithal projections where rotating the CD matrix + does not work accurately. Added a new parameter longpole to the + imcctran task. If longpole =yes then coordinate transformations + with zenithal projections will be rotated using longpole rather + than the CD matrix. (10/12/00, Davis) + +pkg/images/x_images.x +pkg/images/imcoords/imcoords.cl +pkg/images/imcoords/imcoords.men +pkg/images/imcoords/imcoords.hd +pkg/images/imcoords/ccget.par +pkg/images/imcoords/ccstd.par +pkg/images/imcoords/doc/ccget.hlp +pkg/images/imcoords/doc/ccstd.hlp +pkg/images/imcoords/src/mkpkg +pkg/images/imcoords/src/t_ccget.x +pkg/images/imcoords/src/t_ccstd.x +pkg/images/imcoords/src/ccstd.x + Added the ccget and ccstd tasks to the imcoords package. + (10/12/00, Davis) + +dev/hosts + Added RedHat machine camille (11/23/00, MJF) + +pkg/images/tv/display/t_display.x + Changes to detect and use new WCS strings (12/04/00, MJF) + +pkg/images/tv/display/gwindow.h + Added struct element W_WCSVER (12/04/00, MJF) + +pkg/images/tv/display/iis.h + Added definitions for 16-frame support, increased the size of + the SZ_WCSTEXT to 1024 (12/04/00, MJF) + +pkg/images/tv/display/mkpkg +pkg/images/tv/display/imdwcsver.x + + Added a routine which does a WCS query with the X register set + to check whether the server can handle the new WCS strings. If + the reply is "version=" we use the new stuff, otherwise it's + a no-op and we use the old format strings. (12/04/00, MJF) + +sys/imio/imunmap.x + Added a test to see if the image being closed is a pixel mask image + (as opened by impmmap) with the IM_PLCLOSE flag set. If so, the + mask file must be closed at imunmap time. (12/12) + +pkg/images/lib/geomap.h +pkg/images/lib/geogmap.h +pkg/images/lib/geofit.gx +pkg/images/lib/geofit.x +pkg/images/lib/geogmap.gx +pkg/images/lib/geogmap.x +pkg/images/lib/geograph.gx +pkg/images/lib/geograph.x +pkg/images/lib/geomap.key +pkg/images/lib/coomap.key +pkg/images/immatch/geomap.par +pkg/images/immatch/doc/geomap.hlp +pkg/images/immatch/src/geometry/t_geomap.gx +pkg/images/immatch/src/geometry/t_geomap.x +pkg/images/imcoords$ccmap.par +pkg/images/imcoords/src/t_ccmap.x +pkg/images/imcoords/doc/ccmap.hlp + Added a new parameter maxiter to the geomap and ccmap tasks. Maxiter + defines the maximum number of rejection iterations and has a default + value of 0 for no rejection. Changed the default value of the ccmap + and geomap parameter reject from INDEF to 3.0. (05/01/01 LED) + +pkg/dataio/fits/fits_rheader.x + Fixed a bug in the MEF file reading error recovery code that could + case a segvio due to a too many open file descriptors conditions. + (05/01/01 LED) + +pkg/images/immatch/immatch.hd + Fixed a typo in the 'source' definition of imalign.cl (01/31/01 MJF) + +xtools$inlfit.gx +xtools$inlfitr.x +xtools$inlfitd.x +xtools$inlrefit.gx +xtools$inlreffitr.x +xtools$inlrefitd.x + Added a check for the condition case where the number of data points + minus the number of deleted points (i.e. those with weights of 0.0) + is less than the number of fitting parameters. The previous checks did + not task into account the number of deleted points and could produce + solutions that were correct but non-physical. (1/2/01, Davis) + +pkg/images/imcoords/doc/ccmap.hlp + Fixed an error in ccmap help page package definition. (02/09/01 LED) + +pkg/images/tv/display/t_display.x + Removed the code which stripped the path-prefix and section from the + image name displayed in the title string. This was originally done + to save space but confuses tasks like IMEXAM which rely on this to + map the image. (02/26/01, MJF) + +pkg/images/tv/display/iis.h + Somehow the SZ_WCSTEXT value got reset to 320, this was causing a + problem with TVMARK redrawing the display, reset to 1024. + (02/26/01, MJF) + +pkg/images/immatch/src/imcombine/icsetout.x + The physical coordinates of the output WCS are now reset. + (3/1/01, Valdes) + +pkg/images/imgeom/src/t_im3dtran.x +pkg/images/imgeom/src/t_imtrans.x +pkg/images/imgeom/src/t_imshift.x +pkg/images/imgeom/src/t_magnify.x + Modified the im3dtran, imtranspose, imshift, and magnify tasks so that + the output image, which is mapped NEW_COPY, is unmapped before the + input image. To the best of my knowledge this has not caused problems + to date but ... (3/1/01 Davis) + +sys/imio/impmhdr.x + When expanding the text version of the header stored in the PL image, + the newline in column 81 would not be seen when processing a full + line of exactly 80 characters, causing a blank line to be added + to the output image header. (3/05/01 LD,NZ,DT) + +pkg/images/tv/display/t_display.x +pkg/images/tv/display/imdgetwcs.x +pkg/images/tv/display/imdwcsver.x +pkg/images/tv/display/iis.h + Compatability fixes for the new WCS strings and "old" servers. The + WCS version query is now carried out with a read request using the + old WCS data size (320) to avoid blocked reads from old servers not + sending the 1024-char data. imd_getwcs() was modified to query the + server for the version before the actual wcs query and the request + is made with the appropriate size. In the case of a WCS query the + IIS 'x' register is used to signal that the new format is being + used, the WCS version is passed back if the 'y' register is + non-zero. Neither of these registers was used by the old protocol, + the new ximtool checks these registers and responds by using the + correct WCS buffer size. (03/12/01, MJF) + +sys/fio/zzdebug.x + Added new versions (written Aug 2000) of the "server" and "client" + debug tasks, which use the ND driver for fully streaming bidirectional + socket communications. (03/27) + +sys/mwcs/wfsamp.x + Fixed a couple minor bugs having to do with endpoint handling and + saving the last position to speed subsequent searches. Generalized + the code to remove the restriction that both arrays increase in + the same direction. (03/31 FV/DT) + +sys/etc/main.x + Modified the way command line arguments are parsed to make it easier + to set the value of a string parameter to the null string. If a + string parameter is set on the command line, e.g., "param=value", + whitespace is no longer permitted between the = and the value + string. Hence, in command line such as [a=foo b= c=bar] will be + treated the same as [a=foo b="" c=bar]. Whitespace is still + skipped in @par files as before. (03/31) + +sys/clio/clcache.x +sys/fmtio/clscan.x + 1. Modified the private internal system routine clc_fetch, which + fetches parameters from the in-task parameter cache, to return ERR if + a parameter is not found rather than zero. This makes it possible + to discriminate between parameters that have not been set, and ones + which have had the value string set to the null string. + 2. Modified clscan (called whenever a task gets a string-valued + parameter) to check the status returned by clc_fetch for ERR rather + than <=0 and to prompt for the parameter only if ERR (value not set) + is returned. + + Note - These changes have some risk and could affect existing + scripts. Only tasks with parameters that have null string or + uninitialized values should be impacted. Testing using irafx is + required. (03/31) + +sys/imio/db/imgnfn.x + The code which scans a header looking for keywords which match a + pattern was not skipping to the next card correctly when skipping + non-keyword cards (blank cards, COMMENT, HISTORY, etc.). (03/31) + +pkg/images/tv/display/dspmmap.x + Fixed problems with ds_match. The new version is more robust and + correct. A bad pixel for the displayed image is the maximum of all + pixels in the pixel mask which fall within the display pixel. This + version still does not allow any relative rotations but does allow + non-integer offsets. (4/24/01, FV) + +images$imutil/hedit.par +images$imutil/doc/hedit.hlp +images$imutil/src/hedit.hlp + Added a new addonly parameter to the hedit task. If addonly is set + a new field will only be added to the image header if it does not + already exist. (4/30/01, Davis) + +images$immatch/src/psfmatch/rgpfilter.x +images$immatch/src/psfmatch/rgpconvolve.x + Fixed a floating point error in the replace algorithm gaussian fitting + routine that can occurs if the FFT of the reference image is exactly + zero. Also fixed a symmetry error in the psfmatch convolve routine + that would results in a corrected psf that is flipped in x and y if + the psf matching kernel does not have mirror symmetry. The workaround + and bug fix is to rotate the convolution kernel 180 degrees before + applying it to the input image in that case. The matching kernel is + is correctly oriented and can be used directly with the fconvolve + task. (5/15/01 Davis) + +dataio$fits/t_rfits.x +dataio$imtext/t_rtextimage.x + Changed the clgetc calls o clgstr calls for the datatype parameter + (rfits task) and otype parameter (rtextimage. task) This change is + required to avoid an "ERROR: Parameter not a legal character constant + (parname)" error introduced by recent changes to the CL. "" is no + longer a legal argument for clgetc. (6/15/01 LED) + +images$immatch/src/imcombine/t_combine.x +images$immatch/src/imcombine/icombine.gx +images$immatch/src/imcombine/icgdata.gx +images$immatch/src/imcombine/icscale.x +images$immatch/src/imcombine/xtimmap.x + +images$immatch/src/imcombine/mkpkgx + When combining more images than there are IRAF FIO descriptors the + additional images are mapped and unmapped as needed. There is no + limit now on the number of images or that they be capable of being + stacked into a single image for combining by projection. The creation + of a temporary stack image is no longer done. (6/16/01, Valdes) + +images$imgeom/src/t_magnify.x + Fixed a bug in the magnify task that could cause a previous block + of lines to be repeated instead of a new block computed. This bug + was introduced when magnify was upgraded to use the new sinc / drizzle + interpolation code and to use imio boundary extension (IRAF 2.11.2). A + typo was made in the update which results the above error in the case + where the buffer does not update. Normally the buffer is supposed to + update for each group of lines but occasionally may not to integer + conversions, especially in the case that the magnification factors are + greater than the internal buffer size of 16 output image lines. + (6/21/01, Davis) + +pkg/images/tv/display/imdgetwcs.x +pkg/images/tv/display/imdputwcs.x +pkg/images/tv/display/imdsetwcs.x + Modified to allow read/write of the additional mapping information + during WCS i/o. If the iis_version flag is non-zero and a valid + mapping exists, the set/put wcs routines will automatically format + the WCS text to include this information, otherwise it writes the old + WCS text. If iis_version is non-zero and a server query returns mapping information this will be stored in the iis common for later retrieval + by the imd_getmapping() routine. (06/21/01, MJF) + +pkg/images/tv/display/imdwcsver.x + Removed 'frame' number argument form the procedure. The procedure + will now map frame one if no connection is already opened and query + the WCS. Returns non-zero if the server is capable of using the new + mapping structures. Required to be called explicitly by programs + using mappings to initialize the imd interface for this functionality. + A "disable_wcs_maps" boolean environment variable may be defined to + force this procedure to return zero if the old behavior is desired or + to workaround bugs in the new code. (06/21/01, MJF) + +pkg/images/tv/display/t_display.x + Removed earlier addition of ds_setwcs() function since this is now + handled by the standard imd_putwcs() interface. Mapping information + is set prior to the WCS write with imd_setmapping(). (06/21/01, MJF) + +pkg/images/tv/display/mkpkg + Updated dependencies (06/21/01, MJF) + +pkg/images/tv/display/imdmapping.x + + New routines imd_[sg]etmapping() allow a program to set the + mapping to be sent with the next imd_putwcs() call, or retrieve the + mapping info sent by the server with the last wcs query. The calls + are no-ops if the connected server doesn't know about the new + mappings, imd_getmapping() is an integer function which returns + non-zero if a valid mapping is available. A new imd_query_map() is + available to return the mapping information for a given WCS number. + The intent is that the mapping can be obtained for a wcs returned by a + cursor read, e.g. to get the image name associated with the mapping. + (6/21/01, MJF) + +pkg/images/tv/display/iis.com + Added new variables to the IIS common to hold the mapping + information for each WCS write. In order to preserve the imd inter- + faces it was necessary to save the mappings in the common, along with + a flag indicating whether the connected server can use them. + (06/21/01, MJF) + +pkg/images/tv/display/iisopn.x + Added initialization of the iis_version value at device open time + (6/21/01, MJF) + +pkg/images/tv/display/gwindow.h + Removed struct element W_WCSVER added earlier, no longer needed. + (6/21/01, MJF) + +pkg/images/tv/display/mkpkg +pkg/images/tv/display/t_display.x + Removed unused include files leftover from debugging. (7/2/01, MJF) + +pkg/lists/rimcursor.x + Modified to return actual WCS code. Previously hardwired with '01' + following the frame number. (7/3/01, MJF) + +dev/hosts + Changed equuleus to be a Solaris machine, added entry for it's + new incarnation as 'new-equuleus'. (7/6/01, MJF) + +pkg/system/cmdstr.x + Modified to handle the case of a redirected parameter value in + the input stream. (7/11/01, MJF) + +pkg/images/imcoords/src/t_ccmap.x + Fixed a bug in the ccmap task refpoint = "coords" option that could + produce a totally inaccurate tangent point estimate if the input + coordinate list spanned ra = 0.0 hours. (7/20/01, LED) + +pkg/images/tv/tvmark/t_tvmark.x + Added a call to imd_wcsver() to reset the 'frame' parameter max so + task can use all 16 frames (8/9/01, MJF) + +pkg/images/tv/display/imdgetwcs.x + Fixed a small bug in parsing the WCS return string, could sometimes + cause the WCS to be reset. (8/9/01, MJF) + +pkg/images/tv/display/imdwcsver.x + Initialized the iis_valid variable (8/9/01, MJF) + +pkg/plot/doc/contour.hlp + Clarified the use of the 'fill' parameter in the example when + overlaying contours to an image display. (08/10/01, MJF) + +pkg/images/tv/imexamine/mkpkg +pkg/images/tv/imexamine/x_imexam.x + +pkg/images/tv/imexamine/imexamine.par + + Added a mkpkg target to compile standalone; i.e. mkpkg standalone. + (8/13/01, Valdes) + +pkg/images/tv/imexamine/iecimexam.x +pkg/images/tv/imexamine/ieeimexam.x +pkg/images/tv/imexamine/iegcur.x +pkg/images/tv/imexamine/iegimage.x +pkg/images/tv/imexamine/iegnfr.x +pkg/images/tv/imexamine/iehimexam.x +pkg/images/tv/imexamine/ieimname.x +pkg/images/tv/imexamine/iejimexam.x +pkg/images/tv/imexamine/ielimexam.x +pkg/images/tv/imexamine/ieopenlog.x +pkg/images/tv/imexamine/ieqrimexam.x +pkg/images/tv/imexamine/ierimexam.x +pkg/images/tv/imexamine/iesimexam.x +pkg/images/tv/imexamine/ietimexam.x +pkg/images/tv/imexamine/ievimexam.x +pkg/images/tv/imexamine/imexam.h +pkg/images/tv/imexamine/t_imexam.x + IMEXAMINE has been modified to use multiple WCS mappings. The + full WCS number is now used. Based on the WCS number the image + associated with the mapping determines the image to examine. + This requires a display server which supports multiple mappings, + such as XIMTOOL V1.3, and a display tasks which uses + multiple mappings, such as MSCRED V4.5. For single displays and + other display servers it behaves as before. + (8/13/01, Valdes) + +pkg/obsolete/obsolete.cl +pkg/obsolete/obsolete.men +pkg/obsolete/obsolete.hd +pkg/obsolete/x_obsolete.x +pkg/obsolete/mkpkg +pkg/obsolete/odisplay.par - +pkg/obsolete$doc/odisplay.hlp - +pkg/obsolete$display/ - + Removed ODISPLAY task. (8/17/01, Valdes) + +pkg/obsolete/obsolete.cl +pkg/obsolete/obsolete.men +pkg/obsolete/obsolete.hd +pkg/obsolete/x_obsolete.x +pkg/obsolete/mkpkg +pkg/obsolete/oimcombine.par + +pkg/obsolete$doc/oimcombine.hlp + +pkg/obsolete$imcombine/ + + Added OIMCOMBINE from V2.11.3b. (8/17/01, Valdes) + +pkg/images/immatch/src/imcombine +pkg/imagess/immatch/imcombine.par +pkg/imagess/immatch/doc/imcombine.hlp + 1. New parameters "headers", "bpmasks", "rejmasks", "nrejmasks", + and "expmasks" provide additional types of output. The old + parameters "rejmask" and "plfile" were removed. The new + "nrejmasks" parameter corresponds to the old "plfile" and the + new "rejmasks" parameter corresponds to the old "rejmask". + 2. There is a new "combine" type "sum" for summing instead of + averaging the final set of offset, scaled, and weighted + pixels. + 3. There is a new parameter "outlimits" to allow output of a + subregion of the full output. This is useful for raster + surveys with large numbers of images. + 4. Additional keywords may appear in the output headers. + 5. The scaling is now done relative to the first image rather than + an average over the images. This is done so that flux related + keywords such as exposure time and airmass remain + representative. + 6. The environment parmaeter "imcombine_option" allows using an + algorithm that opens and closes images. This is very slow but + allows combining large numbers of images which are not the same + size. + 7. New help page. + (8/17/01, Valdes) + +lig/pkg/cq.h +pkg/xtools/catquery/ +pkg/xtools/mkpkg +pkg/xtools/cq.h +pkg/xtools/cqdef.h +pkg/xtools/cqdb.x +pkg/xtools/cqdtype.x +pkg/xtools/cqget.x +pkg/xtools/cqgfields.x +pkg/xtools/cqgqpars.x +pkg/xtools/cqgrecords.x +pkg/xtools/cqiminfo.x +pkg/xtools/cqimquery.x +pkg/xtools/cqistat.x +pkg/xtools/cqlocate.x +pkg/xtools/cqmap.x +pkg/xtools/cqnqpars.x +pkg/xtools/cqquery.x +pkg/xtools/cqrinfo.x +pkg/xtools/cqrstat.x +pkg/xtools/cqsetcat.x +pkg/xtools/cqsqpars.x +pkg/xtools/cqstat.x +pkg/xtools/cqwrdstr.x +pkg/xtools/doc/*.hlp + Added the catalog and image survey access tools and documentation to + the XTOOLS package. (8/27/01, Davis) + +pkg/obsolete/obsolete.cl +pkg/obsolete/obsolete.men +pkg/obsolete/obsolete.hd +pkg/obsolete/x_obsolete.x +pkg/obsolete/mkpkg +pkg/obsolete/oimstatistics.par +pkg/obsolete/oimstat.h +pkg/obsolete/t_oimstat.x +pkg/obsolete/doc/oimstat.hlp + Added OIMSTATISTCS from V2.11.3b. (8/30/01, Davis) + +pkg/images/imutil/imstatistics.par +pkg/images/imutil/doc/imstatistics.hlp +pkg/images/imutil/src/imstat.h +pkg/images/imutil/src/t_imstat.x + Added an interative rejection capability to the imstatistics task. Also + added a cacheing option that may speed up the performance of the task + if the midpt/mode statistic is computed or if iterative rejection + is enabled. (8/30/01, Davis) + +pkg/xtools/catquery/cqgfields.x +pkg/xtools/catquery/cqquery.x + Fixed an incorrect function and data type declaration in the + catquery library which showed up when compiling on Linux. + (9/17/01, Davis) + +pkg/images/imutil/src/t_imjoin.x + Changed the clgetc call to clgstr calls for the pixtype parameter in + imjoin. This change is required to avoid an "ERROR: Parameter not a + legal character constant (parname)" error introduced by recent changes + to the CL. Basically "" is no longer a legal argument for clgetc. + (9/17/01 LED) + +pkg/proto/mimstatistics.par +pkg/proto/doc/mimstat.hlp +pkg/proto/masks/mimstat.h +pkg/proto/masks/t_mimstat.h +pkg/proto/masks/mstcache.x +pkg/proto/masks/mimstat.x +pkg/proto/masks/mptools.x + Installed the new statistics through a mask task mimstatistics in the + proto package. (09/17/01, Davis) + +lib/pkg/pstools.h + +pkg/xtools/pstools/Notes + +pkg/xtools/pstools/font.com + +pkg/xtools/pstools/mkpkg + +pkg/xtools/pstools/psbreak.x + +pkg/xtools/pstools/pscenter.x + +pkg/xtools/pstools/psclose.x + +pkg/xtools/pstools/psdeposit.x + +pkg/xtools/pstools/psfont.x + +pkg/xtools/pstools/psjustify.x + +pkg/xtools/pstools/psopen.x + +pkg/xtools/pstools/psoutput.x + +pkg/xtools/pstools/pspos.x + +pkg/xtools/pstools/psprolog.x + +pkg/xtools/pstools/pssetup.x + +pkg/xtools/pstools/pswidth.x + + Added a new interface library for doing Postscript text output. + This is used by the lroff conversion code but is useful for any + application which needs to output blocks of text in a similar + manner. Because of the var- iable-width font used in the prolog it + is not that useful for producing tabular output. (09/17/01, MJF) + +pkg/proto/rskysub.par +pkg/proto/doc/rskysub.hlp +pkg/proto/masks/rskysub.h +pkg/proto/masks/t_rskysub.x +pkg/proto/masks/rsstats.x +pkg/proto/masks/rsmean.x +pkg/proto/masks/rsmmean.x +pkg/proto/masks/rscache.x +pkg/proto/masks/rsfnames.x +pkg/proto/masks/rsreject.x + Installed the new running mean or median sky subtraction task rskysub + in the proto package. (9/18/01, LED) + +pkg/images/imcoords/src/t_skyctran.x +pkg/images/imcoords/src/t_sffind.x +pkg/images/imfilter/src/mode.x +pkg/images/imutil/doc/hedit.hlp +pkg/images/imutil/doc/imdivide.hlp +pkg/images/tv/doc/Tv.hlp +pkg/images/tv/iis/doc/Cv.hlp +pkg/images/tv/iis/doc/cv.hlp +pkg/mage/tv/iis/ids/doc/Imdis.hlp + Fixed various missing/extra argument problems in the images package + code that were found with spplint. Also fixed miscellaneous images + package help page formatting problems. (9/19/01 Davis) + +pkg/plot/crtpic/t_crtpict.x +pkg/plot/crtpic/plotimage.x +pkg/plot/t_graph.x +pkg/plot/t_implot.x + Fixed various missing/extra argument and function/subroutine mismatch + problems in the plot package that were found by running spplint. + (9/19/01, Davis) + +pkg/proto/t_suntoiraf.x +pkg/proto/t_binfil.x +pkg/proto/t_hfix.x +pkg/proto/t_joinlines.x +pkg/proto/doc/irafil.hlp + Fixed various extra/missing argument, function declaration, and + subroutine/function mismatchs in the proto package that were + found with spplint. Also fixed an irafil task help page formatting + problem. (9/19/01, Davis) + +pkg/xtools/skywcs/doc/skdecim.hlp +pkg/xtools/skywcs/doc/skequatorial.hlp +pkg/xtools/skywcs/doc/sklltran.hlp +pkg/xtools/skywcs/doc/skultran.hlp +pkg/xtools/skywcs/doc/skywcs.hlp +pkg/xtools/catquery/doc/catquery.hlp +pkg/xtools/catquery/doc/cqsqpar.hlp +pkg/xtools/catquery/doc/cqsqparn.hlp + Fixed various formatting problems in the skywcs and catquery library + help pages. (19/09/01, Davis) + +pkg/lists/doc/Lcalc.hlp +pkg/lists/doc/Lcalc.hlp +pkg/lists/doc/Lists.hlp +pkg/lists/doc/unique.hlp +pkg/lists/doc/average.hlp + Fixed various formatting problems in the lists package help files. + (19/09/01, Davis) + +mkpkg + Added architecture entries for LinuxPPC (linuxppc) and MacOSX + (macosx) to the root iraf mkpkg file. (9/25) + +unix/hlib/libc/iraf.h +unix/hlib/libc/stdarg.h + + Added a new LIBC include . This is the successor to + , which is no longer supported on all platforms + (MacOSX). If a C file defines "import_stdarg" then will + be included. If this file defines USE_STDARG then the stdargs + mechanism for handling variable arguments lists should be used in + the code, otherwise the older varargs mechanism should be used (they + are NOT the same). Unfortunately it is necessary to #ifdef the code + to do this as variable argument handling has to be done at compile + time and only one version can be used; nonetheless the code will be + just as portable and platform independent as always. (9/25) + +pkg/cl/errs.c +pkg/cl/clprintf.c + Modified these files to use STDARG. (9/25) + +sys/libc/scanf.c +sys/libc/printf.c +sys/libc/sprintf.c +sys/libc/eprintf.c + Modified these files to use STDARG. (9/25) + +unix/mkpkg [pcix] + Added some comments on what version of F2C is used and where the + sources are maintained. (9/25) + +unix/as.macosx [pcix] + +unix/boot.macosx [pcix] + + Added AS and HBIN directories for the MacOSX port. (9/25) + +unix/boot/bootlib/ostime.c [pcix] +unix/os/gmttolst.c [pcix] + These routines were modified to use the cmtime.gmtime routine + to get the GMT offset. Required for MacOSX. ftime() is + normally used: while MacOSX has a manpage for this and says it + is in libcompat.a, there is no libcompat.a. gmtime() is probably + the more modern routine anyway, and perhaps we should move to + it for most platforms. (9/25) + +unix/boot/mkpkg/host.c [pcix] + In h_rebuildlibrary, added a call to resolvefname() so that + ranlib is passed an actual filename rather than a symbolic + link. (9/25) + +unix/boot/spp/xc.c [pcix] + Various changes to support MacOSX. (9/25) + +unix/boot/spp/xpp/xppcode.c + Added explicit initialization for the variable nstrings to fix a + runtime SPP compiliation problem seen on MacOSX. (9/25) + +unix/hlib/install [pcix] +unix/hlib/cl.csh [pcix] +unix/hlib/fc.csh [pcix] +unix/hlib/irafuser.csh [pcix] +unix/hlib/mkpkg.inc [pcix] +unix/hlib/mkpkg.sf.MACX [pcix] +unix/os/irafpath.c [pcix] + The usual minor changes to support a new platform, in this case + MacOSX. (9/25) + + +unix/os/zfchdr.c [pcix] +unix/os/zfgcwd.c [pcix] +unix/os/zglobl.c [pcix] + Moved the global variable oscwd to zglobl.c to avoid a linker + problem seen on MacOSX. (9/25) + +unix/os/zfioks.c [pcix] + MacOSX does not provide REXEC (it is in libcompat.a) so the KS + driver was modified to conditionally use RCMD instead. This routine + replaces the very old REXEC and should probably be used on most + platforms in any case. A USE_RCMD define was added at the top + of the file to select which routine is used on each platform. + (/9/25) + +unix/os/zxwhen.c [pcix] + Added support for MacOSX, which does not fully support the + modern sigaction, used for signal handling on most platforms + these days. (9/25) + +pkg/images/tv/imedit/epimcopy.x + Added a missing TY_USHORT branch to the image copy case statement. + (10/10 LED) + +pkg/system/help/hinput.x + Added a missing sfree before return. (10/10/01, MJF) + +pkg/system/help/houtput.x + ttyclear() was being called as a function, changed to call as a + subroutine. (10/10/01, MJF) + +pkg/system/help/prhelp.x + Added some extra braces around complex if statements. (10/10/01, MJF) + +pkg/system/help/help.h +pkg/system/help/t_help.x +pkg/system/help/t_lroff.x +pkg/system/help/prblkhdr.x +pkg/system/help/prhlpblk.x + Added new code to permit text/html/ps output options. Additional + code to handle standout mode properly. (10/10/01, MJF) + +pkg/xtools/mkpkg +lib/pkg/pstools.h + +pkg/xtools/pstools/Notes + +pkg/xtools/pstools/font.com + +pkg/xtools/pstools/mkpkg + +pkg/xtools/pstools/psbreak.x + +pkg/xtools/pstools/pscenter.x + +pkg/xtools/pstools/psclose.x + +pkg/xtools/pstools/psdeposit.x + +pkg/xtools/pstools/psfont.x + +pkg/xtools/pstools/psjustify.x + +pkg/xtools/pstools/psopen.x + +pkg/xtools/pstools/psoutput.x + +pkg/xtools/pstools/pspos.x + +pkg/xtools/pstools/psprolog.x + +pkg/xtools/pstools/pssetup.x + +pkg/xtools/pstools/pswidth.x + + Added a new interface library for doing Postscript text output. + This is used by the lroff conversion code but is useful for any + application which needs to output blocks of text in a similar + manner. (10/10/01, MJF) + +pkg/system/help/t_lroff.x +pkg/system/help/lroff.par + Added a new 'format' parameter and code to permit output of HTML + or Postscript. (10/10/01, MJF) + +pkg/system/help/lroff/mkpkg +pkg/system/help/lroff/lroff.h +pkg/system/help/lroff/lroff.x +pkg/system/help/lroff/nofill.x +pkg/system/help/lroff/nextcmd.x +pkg/system/help/lroff/lroff2ps.x + +pkg/system/help/lroff/lroff2html.x + + Added new converter code to create HTML or formatted Postscript from + lroff source. (10/10/01, MJF) + +pkg/system/help/t_help.x + Task was modified to call the XHELP code to run the GUI version of + the task if requested. Task output is the same if the device + remains the default 'terminal' value, however resetting the 'device' + parameter to one of 'gui', 'html', or 'ps' will either spawn the GUI + task under xgterm or print the converted help page to the stdout. + (10/10/01, MJF) + +lib/pkg/help.gui + +lib/pkg/help.html + +pkg/system/help/mkpkg +pkg/system/help/xhelp/ + +pkg/system/help/xhelp/help.gui + +pkg/system/help/xhelp/mkpkg + +pkg/system/help/xhelp/xhcmds.x + +pkg/system/help/xhelp/xhdir.x + +pkg/system/help/xhelp/xhelp.h + +pkg/system/help/xhelp/xhelp.par + +pkg/system/help/xhelp/xhelp.x + +pkg/system/help/xhelp/xhfiles.x + +pkg/system/help/xhelp/xhhelp.x + +pkg/system/help/xhelp/xhinit.x + +pkg/system/help/xhelp/xhofile.x + +pkg/system/help/xhelp/xhpkg.x + +pkg/system/help/xhelp/xhprint.x + +pkg/system/help/xhelp/xhqref.x + +pkg/system/help/xhelp/xhroot.x + +pkg/system/help/xhelp/xhsave.x + +pkg/system/help/xhelp/xhsearch.x + +pkg/system/help/xhelp/xhsort.x + +pkg/system/help/xhelp/zzdebug.x + + Installed GUI help support code. Slight modifications from the + stand-alone XHELP task were required, almost entirely in the task + main. Various bugs were fixed in the task initialization which + prevented repeated executions from displaying the correct package + information. (10/10/01, MJF) + +pkg/system/help/houtput.x + Removed an unused 'junk' variable. (10/10/01, MJF) + +pkg/system/phelp.cl +pkg/system/references.cl + Hardwired the 'device' parameter to be 'terminal' (10/10/01, MJF) + +lib/pkg/scr/help.gui + Numerous bug fixes and consistency tweaks to the GUI file. + (10/10/01, MJF) + +pkg/system/help/xhelp/xhsave.x + Added missing file descriptors to fprintf() calls. (10/10/01, MJF) + +pkg/system/help/xhelp.x + Removed an unused clgeti() declaration. (10/10/01, MJF) + +pkg/system/pathnames.x + Added a missing SZ_LINE arg to a gargstr() call. (10/10/01, MJF) + +pkg/system/protect.x +pkg/system/unprotect.x + protect() was being called as a subroutine, changed to be a call to + an int function as defined. (10/10/01, MJF) + +pkg/system/help/prhlpblk.x + Fixed a Postscript initialization bug which was preventing files from + being formatted as PS with the proper header. (10/10/01, MJF) + +pkg/system/help/lroff/lroff.x + Fixed a bug in the new .hr directive preventing the text from being + passed through to the output in the case of non-HTML. (10/10/01, MJF) + +pkg/xtools/mkpkg +lib/pkg/pstools.h - +pkg/xtools/pstools/Notes - +pkg/xtools/pstools/font.com - +pkg/xtools/pstools/mkpkg - +pkg/xtools/pstools/psbreak.x - +pkg/xtools/pstools/pscenter.x - +pkg/xtools/pstools/psclose.x - +pkg/xtools/pstools/psdeposit.x - +pkg/xtools/pstools/psfont.x - +pkg/xtools/pstools/psjustify.x - +pkg/xtools/pstools/psopen.x - +pkg/xtools/pstools/psoutput.x - +pkg/xtools/pstools/pspos.x - +pkg/xtools/pstools/psprolog.x - +pkg/xtools/pstools/pssetup.x - +pkg/xtools/pstools/pswidth.x - + The XTOOLS library is not built until after the SYSTEM executable + and so the PSTOOLS library that the new HELP depends upon was not + being found. PSTOOLS was elevated to be a new SYS interface, PSIO, + and so was deleted from the XTOOLS library. (10/12/01, MJF) + +lib/psio.h + +sys/psio/ + +sys/psio/README + +sys/psio/font.com + +sys/psio/mkpkg + +sys/psio/psbreak.x + +sys/psio/pscenter.x + +sys/psio/psclose.x + +sys/psio/psdeposit.x + +sys/psio/psfont.x + +sys/psio/psio.h + +sys/psio/psjustify.x + +sys/psio/psopen.x + +sys/psio/psoutput.x + +sys/psio/pspos.x + +sys/psio/psprolog.x + +sys/psio/pssetup.x + +sys/psio/pswidth.x + +sys/psio/zzdebug.x + + Added a new interface library for doing Postscript text output. + This is formerly the PSTOOLS library and is used by the lroff + conversion code but is useful for any application which needs to + output blocks of text. The README file explains the interface. + (10/12/01, MJF) + +pkg/system/mkpkg +pkg/system/help/lroff/mkpkg +pkg/system/help/lroff/lroff2ps.x + Removed the -lxtools flag from the system link line, small code + modification to make use of (10/12/01, MJF) + +unix/hlib/zzsetenv.def + Added a new 'pspage' variable which is used by the PSIO interface to + set the default page size. Acceptable values include "letter" (the + default) for US Letter, "legal" for US Legal, and "a4" and "b5" for + the most common European sizes. Pspage can be used by the new HELP + and LROFF tasks to automatically set the desired Postscript page + size. (10/12/01, MJF) + +lib/psio.h - +lib/psset.h + +sys/psio/psio.h + +sys/psio/* + Various minor tweaks to the PSIO code for consistency. The private + and public parts of the interface were split into a psio.h include + for the interface, and psset.h for applications. (10/14/01, MJF) + +pkg/system/help/lroff/mkpkg +pkg/system/help/lroff/lroff2ps.x + Changed to . (10/14/01, MJF) + +lib/scr/help.gui + Minor bug fixes to the HELP GUI. (10/14/01, MJF) + +dev/hosts + Updated hohokam's irafks path for GONG. (10/15/01, MJF) + +sys/mkpkg + Added an entry for PSIO. (10/15) + +pkg/images/immatch/src/xregister/rgxicorr.x +pkg/images/immatch/src/xregister/rgxcolon.x +pkg/images/immatch/src/xregister/rgxtools.x + Fixed a bug in the xregister multiple region handling code that was + preventing xregister from computing x-correlations on regions beyond + the first in interactive mode. (10/17/01, LED) + +dev/hosts + Added solaris machines nebula and bobcat. (10/30/01, MJF) + +pkg/images/imutil/src/imheader.x + Fixed imheader so it prints out an image size of 0 if IM_NDIM(im) is + is 0 instead of the contents of the first element of the IM_LEN(im,1) + vector which may be non-zero. (11/05/01, Davis) + +pkg/images/imutil/src/hedit.x +pkg/images/imutil/doc/hedit.hlp + For backwards compatability modified the precedence of the operator + switches from addonly / add / delete to add / addonly / delete. + Addonly is a new switch which adds a keyword only if it is not + already there. Also clarified the switch precedence rules in the + help page. (11/13/01, Davis) + +lib/plset.h +sys/plio/README +sys/plio/mkpkg +sys/plio/plsten.x +sys/plio/plsectne.x +sys/plio/plsectnc.x +sys/plio/plrop.x +sys/plio/plrio.x +sys/plio/plregrop.x +sys/plio/plpoint.x +sys/plio/plplr.gx +sys/plio/plplp.gx +sys/plio/plplls.x +sys/plio/pllinene.x +sys/plio/plglr.gx +sys/plio/plglp.gx +sys/plio/plglls.x +sys/plio/placcess.x +sys/pmio/pmaccess.x +sys/pmio/pmplls.x + The pl_access routine (which is private to the PLIO interface) + was changed to return a pointer to the line list rather than an + offset into the PLIO data buffer. A new routine pl_reference() + was added to do what pl_access used to do. All the affected + PLIO and PMIO code was updated (nearly all instances wanted the + pointer instead of the buffer offset). + + This change makes pl_access usable by external code, which has + no (legal) way to do anything with internal references to the + PLIO descriptor. (12/03) + +sys/plio/pllen.x + Added a new PLIO routine pl_llen(), which returns the length of + an encoded line list. (12/03) + +sys/plio/plemptyline.x + Added a new routine to return a pointer to the "emptyline" line + list for a mask. This can be used in conjunction with the newly + modified pl_access to check for a pointer to the empty line. + Applications should rarely need to do this, but it is needed in the + FITS kernel to compress empty lines, i.e., make the lines in the + FITS verfsion of the mask all point to the same "emptyline" line + list. (12/03) + +sys/fmtio/evvexpr.gy + Added support for the bitwise boolean operators: '&' (and), '|' (or), + '^' (xor), and '~' (not/complement). These can be used only with + integer type operands (short, int, long) and will return a result + of the same type, like an arithmetic operator, with the usual type + promotion semantics. (12/03) + +pkg/images/imutil/doc/imexpr.hlp + Added the new bitwise boolean operators to the operator list. (12/04) + +sys/ki/ki.h + Increased MAX_NODES (the max nodes in a local network for IRAF + networking) from 320 to 512. (12/04) + +sys/ki/kbzstt.x + Fixed some typos; no functional changes. (12/04) + +pkg/images/immatch/src/imcombine/src/icscale.x + Fixed a normalization bug. (12/04]) + +unix/hlib/config.h +unix/hlib/libc/libc.h + Increased FIO_MAXFD (the max number of open files in FIO) from + 256 to 4096. This is the "hard limit" on the maximum number of + open files in an IRAF process. + + Analysis of the FIO code indicates that there isn't any serious + efficiency issue here: there are only a few cases where a linear + search of the file list is performed, and these do not impact normal + usage. During i/o to a file there is no affect all since access via + a file descriptor is direct. The is some impact on file descriptor + allocation at file open time, however this only has an impact in + cases where there are many open files (if 4000 files are open 4001 + file descriptors may have to be examined to find the next open + slot). Such cases are unusual however, and in such a case however, + performance is likely to be governed by much more important + factors. + + The biggest impact of increasing the number of FIO descriptors is + static allocation of BSS storage (data memory space allocated when a + process is spawned). This is only about 100KB per process for 4096 + descriptors. This would have been an issue once, but is not + important today where even everyday PCs have hundreds of megabytes + of memory. (12/04) + +unix/shlib/mkshlib.sos4 +unix/shlib/mkshlib.ssol + It turns out that the FIO common (FIOCOM) is explicitly referenced + in the Sun/IRAF shared image. The parameters FIOCOMSZ, XERCOMSZ, + TOTCOMSZ, and CMSZ (rouned up to an integral number of pages) must + all agree with the actual commons. The new values are as follows: + + FIOCOMSZ = 0x24660 + XERCOMSZ = 0x810 + TOTCOMSZ = 0x24e70 + CMSZ = 0x26000 + + (12/04) + +sys/vops/awvg.gx + Changed the way the computation was done so that the value MEAN + is not forced to float when working on float data. It is replaced + by the expression (sum/ngpix) so that the computation is all done + in double precision internally. (12/04) + +unix/hlib/libc/kernel.h + 1. Increased MAXOFILES, the maximum number of host level open files, + from 64 to 256. This is the maximum number of files that can be + simultaneously open at the host level. It determines the maximum + number of files that can be simultaneously open by an IRAF process + in the usual case - that is, when FCLOSEFD is not explicitly set on + open files by the IRAF task (if FCLOSEFD is used, up to FIO_MAXFD + files may be open at the IRAF level). The actual maximum number + open files may be less if the host system imposes a lower limit. + For example, the default limit is 64 on SUNOS and Solaris systems. + On PC Unix systems it is much higher. Even on systems that impose + a lower limit by default, the "limit" shell command may often be + used to increase the limit. + + 2. Increased the following "optimum" buffer sizes: + + BF_OPTBUFSIZE 32768 -> 65536 (binary files) + SF_OPTBUFSIZE 32768 -> 65536 + KS_OPTBUFSIZE 4096 -> 65536 (iraf networking) + PR_OPTBUFSIZE 4096 -> 65536 (interprocess comm.) + ND_OPTBUFSIZE 4096 -> 65536 (network driver) + + 3. Removed the maximum buffer size limits for the PR and ND + devices. These were formerly set to 4096. 4K used to be the + system buffer size for devices like pipes, however that was a + long time ago and I don't know if it is still the case. Probably + not, and it doesn't matter anyway so long as a pipe doesn't + circle back on itself. This probably won't affect performance + much, but it could, especially for ND connections which can carry + a lot of traffic. + + The KS limit was already set to 0. Since the KI and binary device + limits are already 0, this means that large transfers can be used on + IRAF networking connections, e.g., for image access. Large transfers + (100K or larger) are needed to achieve the high bandwidth provided + by modern Fast Ethernet or Gigabit Ethernet network interfaces. + We should do some tests at some point to see if we can get high + performance for remote kernel server image access using fast + networking and the new version of IRAF. Potentially, accessing + images in this way could be as fast or faster than accessing them + on a local hard disk. (12/04) + +lib/imio.h +lib/imset.h +sys/imio/immapz.x +sys/imio/imsetbuf.x +sys/imio/imseti.x +sys/imio/imstati.x + The following changes were made to enable IMIO to use larger + buffer sizes to optimize i/o for large images. + + The default file buffer size set by IMIO is unchanged: it is still + about 512 MB, the value set for V2.11.2. However, a new parameter + IM_BUFFRAC was added. Both IM_BUFSIZE and IM_BUFFRAC are used to + help determine the FIO buffer size set when an image is opened. + The logic for this is implemented in imsetbuf.x. + + Backwards compatibility. If you do nothing about IMIO/FIO buffers + in your program, the system may transparently use a larger buffer + for larger images. If you set BUFSIZE in your program, the system + will by default use the value you give, or possibly a larger value, + if the image you are accessing is very large. If you set BUFSIZE + and you want to guarantee that the value you set is used (even + for very large images) then you should also set BUFFRAC=0 to ensure + that only BUFSIZE is used. + + How it works. BUFFRAC specifies the default FIO buffer size used to + access an image, expressed as a percentage of the size of the + image. For example, the builtin default value of BUFFRAC=10 will + try to make a FIO buffer 10% of the size of the image. The actual + value used will be given by BUFFRAC, but will be at least BUFSIZE, + and no more than a builtin default maximum value, currently 32 MB. + Given the builtin defaults, the buffer size will range from 0.5 to + 32 MB depending upon the size of the image being accessed. As noted + above, BUFSIZE and BUFFRAC can be set to force the buffer size to a + specific value if desired. + + Environment variables for both parameters are provided. The names + are "IMIO_BUFSIZE" and "IMIO_BUFFRAC". If specified, these override + (at image open time) the builtin default values for both + parameters. An IMSET call by the application will override all such + defaults. + + The FIO buffer allocated will not be larger than the size of the + image. The FIO buffer will also not exceed the maximum size set by + the file driver being accessed. For example, for PLIO images the + file buffer will not exceed about 2KB, even for a very large mask. + This is because the "pixel file" for a PLIO image is dev$null, the + driver for which specifies a maximum i/o buffer size of 2K (the real + file to load or save the mask will use a different descriptor). + + The intent here is to provide an adaptive mechanism for setting the + FIO buffer size used to access an image, which automatically adapts + to the size of the image being accessed. If you access a lot of + small images you will get smaller buffers - everything will be as + before. If you access very large images, you may get large buffers + up to the builtin maximum value of (currently) 32 MB. + + Using large buffers could cause a machine to run out of memory. + However, it is likely that if someone is working on 300 MB images + that they are using a machine which has a memory at least that + large - probably larger. If there are problems, the environment + variable overrides can be used to tune IMIO. + + The reason for large file buffers is to limit the number of disk + data transfers, and hence the number of disk seeks. Using buffers + larger than a certain amount (32 MB is generous) is probably + counterproductive. If the i/o system provides 20 MB/sec i/o + transfers, 32 MB will take 1.6 seconds. This should be more than a + large enough granularity to provide efficient i/o, hence is a + reasonable limit (at this point paging effects are likely to + dominate). (12/04) + +unix/boot/spp/xc.c +unix/boot/spp/xc.c [pcix] + The findexe() routine can modify the PATH variable in the program + environment to add IRAF HSI directories to the path (so that + stuff like f2c.e can be found). The buffer used to compute a new + PATH environment variable was dimensioned SZ_PATHNAME, which is + too small for PATH since it may contain many directory pathnames. + Changed the buffer dimension used here to 8192. (12/04) + +sys/plio/plgsize.x +sys/plio/plstati.x +sys/plio/plloadim.x + Changed the code which computes the mask depth from PL_MAXVAL so + that it will return a value of zero for a newly created but + unitialized mask (naxes, axlen, and depth will hence all be zero + for a newly created mask). (12/04) + +sys/vops/awvg.gx + Changed the way the computation was done so that the value MEAN is + not forced to float when working on float data. It is replaced by + the expression (sum/ngpix) so that the computation of SIGMA is all + done in double precision internally. (12/04) + +sys/imio/imopsf.x +sys/imio/iki/fxf/fxfopen.x + Both of these routines had code such as "IM_PFD(im) = open (...)". + If the OPEN call should take an error exit, IM_PFD could get set + to a garbage value. The code was changed to break the assignment + into two statements so that IM_PFD is not set if the file open + fails. (12/04) + +sys/vops/alork.gx + +sys/vops/alor.gx + +sys/vops/alank.gx + +sys/vops/alan.gx + +sys/vops/vops.syn +sys/vops/vops.men +sys/vops/vops.calls +sys/vops/mkpkg +sys/vops/lz/mkpkg + Added new vector operators alan, alank (logical AND) and alor, alork + (logical OR). These take any integer data as input (short, int, + long) and return a logical (expressed as int) result. (12/05) + +sys/fmtio/evvexpr.gy + The code for the logical AND and OR operations was modified to use + the new VOPS alan/alor routines. The old code was based on the + bitwise boolean operators: it would work if the input data had only + logical values (zero or one), but not if the input data was any + arithmetic integer value. The new routines will treat all input + integer data values as either zero (false) or non-zero (true). + Finally if a logical operation is performed the result image will + be type int rather than short as before. This is just to be + consistent in the treatment of TY_BOOL as int. The old code was + trying to save space by storing the 1-bit logical result in a + short image. (12/05) + +sys/vops/awvg.gx + The usage of INDEF to set mean/sigma was incorrect. The generic + code would use the INDEF appropriate for the target datatype, but + the datatypes of the internal variables mean/sigma were being + explicitly set. Changed the INDEF usage to explicitly match the + INDEF type to the datatype of the mean/sigma variables. (12/05) + +sys/imio/iki/ikiextn.x + Removed the call to strlwr() made when processing filename extensions + in IMEXTN, e.g., imextn = "oif:imh fxf:fits,fit,FITS plf:pl" should + now do what one would expect. (12/05) + +pkg/proto/proto.cl +pkg/proto/proto.men +pkg/proto/proto.hd +pkg/proto/x_proto.x +pkg/proto/mskexpr.par +pkg/proto/mskregions.par +pkg/proto/doc/mskexpr.hlp +pkg/proto/doc/mskregions.hlp +pkg/proto/maskexpr/t_mskexpr.x +pkg/proto/maskexpr/memkmask.x +pkg/proto/maskexpr/t_mskregions.x +pkg/proto/maskexpr/mesetreg.x +pkg/proto/maskexpr/mesetexpr.x +pkg/proto/maskexpr/meregmask.x +pkg/proto/maskexpr/peregfuncs.x +pkg/proto/maskexpr/megeom.x +pkg/proto/maskexpr/meregfuncs.x +pkg/proto/maskexpr/mskexpand.x +pkg/proto/maskexpr/gettok.x +pkg/proto/maskexpr/gettok.h + Installed the mskexpr and mskregions tasks in the proto package. + (12/06/01, Davis) + +pkg/images/imcoords/src/t_wcsctran.x +pkg/images/imcoords/src/rgstr.gx +pkg/images/imcoords/src/rgstr.x + Fixed a string_file error in the wcsctran task which may occur + if the input image is dimensionally reduced. The bug is due to + an uninitialized array error. The bug does not occur if by + chance the array values are 0. (12/06/01, Davis) + +sys/imio/imsetbuf.x + Changed the way the buffer size is calculated slightly to avoid + overflowing a 32 bit integer when calculating the buffer size as + a fraction of a very large (e.g. 1 GB) image. (12/10) + +sys/imio/immapz.x + Tweaked the handling of "IMIO_BUFSIZE" so that the value can be + input in bytes, rather than the SPP char units used internally + for the buffer size calculations. MB would be more convenient + for the user but would prevent the use of "small" buffers (e.g. + the default buffer size is "small" - 0.5MB). (12/10) + +pkg/images/imutil/src/t_imstat.x + Added a call setting IM_BUFFRAC to 0 to the memory caching code in + the imstatistics task in order to force the imio buffer to be the + size of the input image. + (12/10/01, Davis) + +pkg/proto/masks/mstcache.x +pkg/proto/masks/rsscache.x + Added a call setting IM_BUFFRAC to 0 to the memory caching code in + the mimstatistics and rskysub tasks in order to force the imio buffer + to be the size of the input image. + (12/10/01, Davis) + +lib/imio.h +lib/imset.h +sys/imio/imsetbuf.x +sys/imio/imstati.x +sys/imio/imseti.x +sys/imio/immapz.x + Added another IMIO parameter BUFMAX for tuning buffer size + allocation. This allows the builtin value of the maximum FIO buffer + size (DEF_MAXFIOBUFSIZE, currently set to about 32 MB) to be easily + overridden at the application or environment level, like BUFSIZE and + BUFFRAC. + + If you set BUFFRAC=0 then BUFSIZE alone determines the FIO buffer + size (subject to storage device limits if any). BUFMAX is not a + "hard" limit, it is just a parameter used in the BUFFRAC heuristic + to automatically tune the buffer size. If BUFFRAC is allowed to + automatically tune the buffer size for the image to be accessed + (the default), then BUFMAX specifies the largest buffer which IMIO + will create. (12/10) + +sys/imio/iki/fxf/mkpkg +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfaccess.x +sys/imio/iki/fxf/fxfctype.x +sys/imio/iki/fxf/fxfdelete.x +sys/imio/iki/fxf/fxfencode.x +sys/imio/iki/fxf/fxfksection.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfplread.x + +sys/imio/iki/fxf/fxfplwrite.x + +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/zfiofxf.x + The FITS kernel was modified to add support for storing images in + extensions as compressed pixel masks. The mask is stored as a + binary table using the "ZIMAGE" (compressed image) convention + proposed by White, Greenfield, Pence, and Tody in 1999: + + http://heasarc.gsfc.nasa.gov + /docs/software/fitsio/compression/compress_image.html + + In the current implementation only the "PLIO_1" compression + algorithm is implemented. Mask extensions may be read or written + directly by the kernel. When writing a new extension it will be + appended to the MEF file. To append an image to a MEF file as + a mask, include "type=mask" in the image kernel section when the + output image is opened. + + Masks are interfaced to the system as images and may be read and + written like any other image via IMIO. They have a normal image + header and can be manipulated with any program that deals with + images. The pixel type is INT. + + It is also possible to access a mask image as a PLIO mask. An + IMSTATI query for IM_PLDES parameter will return the PLIO mask + descriptor. While a mask extension is opened under IMIO it is + represented as a PLIO mask and may be accessed in this form like + any other mask. + + The mask image is stored in the FITS binary table (BINTABLE) + extension when the image is closed, and is loaded from the extension + when the image is opened. The compression representation used to + store the mask in the binary table is the same as is used within + PLIO. The new (V2.12) encoding is used, allowing very large masks + to be stored. Currently masks up to 3D are supported. Data on + each 2D mask plane will be compressed in both X and Y as with PLIO. + The depth of the mask is preserved. + + Although a mask is stored as a binary table the format of the + table is not completely general. In the current implementation + there can be only one column in the table (COMPRESSED_DATA). + This is an integer-valued variable length array column containing, + for each line of the N-dimensional image, the PLIO compressed + version of that image line. The actual compressed data is stored + in the heap area of the table. Multiple image lines may point to + the same compressed line list, e.g., to store the empty line or to + provide compression in Y. + (12/10 NZ+DT) + +sys/imio/iki/fxf/fxfrdhdr.x + Changes to fix and inconsistancy between the creation and modification + time of an image. The DATE keyword contains the creation date and time + and IRAF-TLM the modification date and time. (12/10 NZ+DT) + +sys/imio/iki/fxf/fxfexpandh.x + +sys/imio/iki/fxf/fxfupdhdr.x + The update header code was changed so that if a header has to be + expanded (hence forcing a rewrite of the full file) then all the + other extension headers will be expanded at the same time to + include at least "nlines" of blank cards. (12/10 NZ+DT) + +pkg/xtools/catquery/mkpkg +pkg/xtools/gtools/mkpkg + Added a missing "cq.h" file dependency to the cqsetcat.x declaration. + Added a missing file dependency to the gtlabax.x declaration. + (12/13/01 LED) + +pkg/proto/masks/mptools.x + Removed an unnecesary include statement from the mptools.x + file. (12/13/01 LED) + +pkg/utilities/mkpkg + Removed an unnecessary mkpkg file dependency from the + curfit.x declaration. + (12/13/01 LED) + +pkg/images/immatch/src/imcombine/mkpkg + Added a missing file dependency to the timcombine.x + declaration. (12/13/01 LED) + +sys/imio/imwrite.x + In some cases (FIO block size less than the length of an image + line), when appending to an existing image, it could be possible for + data at the end of the file to be overwritten. The code which + extends an imagefile was made more rigorous. (12/13) + +unix/gdev/mkpkg +unix/gdev/iism75/mkpkg +sys/fmio/mkpkg +sys/fmtio/mkpkg +sys/memdbg/mkpkg +pkg/softools/mkpkg + Added missing mkpkg dependencies to sources. (12/13) + +sys/gio/stdgraph/stgrcur.x + The int function stg_encode was being called as a subroutine. (12/13) + +sys/gio/cursor/grcinit.x + Deleted the unused argument 'stream'. All calls to grc_init + (there was only one, in rcursor.x) already omit the argument. + This is an internal function, hence this is not an interface + change. (12/13) + +sys/gio/gmprintf.x + Added a missing argument to a sprintf call in this (currently unused) + routine. (12/13) + +sys/mtio/mtclean.x + Removed an extra argument from a getline() call. (12/13) + +sys/mwcs/mwsctran.x + Fixed a problem in mw_sctran that would occur where there is a + mixture of axes with and without world functions. When transforming + between logical and world this would have the effect of transposing + one of the function axes with one of the non-function axes. (12/13) + +sys/proto/maskexpr/peregfuncs.x + Removed an extraneous argument that was no longer necessary and was + being used incorrectly in the pe_polygon function. (12/14/01 LED) + +unix/os/zwmsec.c +unix/os/zwmsec.c [pcix] + This code uses usleep() to implement the millisecond sleep, which + limits the maximum time delay to just over an hour. Changed the + code to use sleep() for delays longer than one hour (with a + precision of at most 1 second), and usleep() for shorter time + delays. (12/15) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfplread.x +sys/imio/iki/fxf/fxfupdhdr.x + Added support for creating a pixel mask extension in NEW_IMAGE mode. + (12/15 NZ+DT) + +unix/hlib/install +unix/hlib/install.old +unix/hlib/uninstall +unix/hlib/sysinfo +unix/hlib/install [pcix] +unix/hlib/install.old [pcix] +unix/hlib/uninstall [pcix] +unix/hlib/sysinfo [pcix] + Installed the new version of the install script, and the companion + uninstall and sysinfo scripts. The old install script is still + present as install.old. The new version of INSTALL is a major new + version which does a much more through job of checking the integrity + of the system during an install; it also has some post-install + capabilities for performing basic system configuration. The + SYSINFO script can be used after an install to verify the integrity + of a system. (12/14) + +lib/pmset.h +sys/pmio/miostati.x +sys/pmio/mioseti.x + Added a new parameter P_PMCLOSE to mio_seti and mio_stati. This + provides access to the already existing flag used to automatically + close an associated PMIO mask if the MIO object is closed. (12/16) + +sys/pmio/mkpkg +sys/pmio/pmstati.x + Added the routine pm_stati to PMIO. This was in the interface as + a redefinition of pl_stati, but this was confusing enough to warrant + a separate routine. (12/16) + +lib/syserr.h +lib/syserrmsg +sys/pmio/pmseti.x +sys/plio/plseti.x +sys/plio/plstati.x + Added a default: branch to all the PLIO and PMIO set/stat calls to + call syserr(SYS_PLINVPAR) (invalid mask parameter) if a bad parameter + code is referenced. (12/16) + +unix/os/zmain.c +unix/os/zmain.c [pcix] + Modified zmain (the host main for an IRAF task) to call exit() instead + of _exit(). This is necessary to flush the output streams and to + call any exit functions posted with atexit(). Most notably this is + required for profiling (-pg/gprof) to work for an IRAF process. + The ability of an IRAF task to return a exit status is unaffected. + (12/16) + +sys/imio/db/impstr.x + This code is used to edit an existing header keyword to replace the + value string (either a quoted string or a numeric/logical string + value) with a new value. It would replace only the text in the + usual value fields through column 30. In rare cases where an old + numeric value extended beyond column 30 this could result in a + malformed value being generated. The code was modified to clear the + old text in this case, up to an optional comment or end of line. + (12/18 LD+DT) + +sys/imfort/imrdhdr.x + Fixed several instances of the function bfseek() being called as + a procedure. (12/19) + +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfplwrite.x +sys/imio/iki/fxf/fxfplread.x +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxf.h + Fixed several FITS kernel bugs found during alpha testing. (12/21) + +unix/hlib/install +unix/hlib/uninstall +unix/hlib/sysinfo +unix/hlib/install [pcix] +unix/hlib/uninstall [pcix] +unix/hlib/sysinfo [pcix] + Installed the latest versions of these scripts. (12/21) + +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfplwrite.x +sys/imio/iki/fxf/fxfupdhdr.x + Fixes for further minor FK bugs found during testing. (12/26) + +sys/ki/kfiosf.x + Changed the kopnsf routine to use a "server" variable like the + other KI file device drivers. This does not change the function + of the routine. (12/28) + +unix/hlib/cl.csh +unix/hlib/cl.csh [pcix] + Modified the CL startup script to check that, if $iraf is defined, + it is valid (or at least, whatever directory or link it points to + exists). If $iraf is defined but is invalid a warning is printed + and $iraf will be set to the default value of /iraf/iraf/ for the + current session. (12/28) + +unix/os/zfiond.c +unix/os/zfiond.c [pcix] +sys/fio/ndopen.x + The ND driver was modified to provide better support for writing + network servers. A new open modifier "nonblock" was added. If this + is used when opening a server connection to a port then the + connection will open a server socket on the indicated port and + return immediately, without waiting for a client connection. Later, + when a client tries to connect to the server, the server can open + the port with a special pseudo-filename syntax to accept the client + connection and set it up on a new socket. This allows a server to + listen for client connections and open each on a separate socket. + Multiple client connections may simultaneously be open (we still + need to add a "select" type function to allow IRAF network servers + to be written which can service multiple simultaneous clients). + + For example, to open a server socket on port 5697 on the localhost + to be used for client connections: + + server = ndopen ("inet:5697::nonblock", NEW_FILE) + + A client would subsequently connect to server port 5697 to get a i/o + connection to the server. To accept the client connection on port + 5697 and open an i/o stream to the client on a new file descriptor: + + fd = ndopen ("sock:", NEW_FILE) + + where is the ascii representation of the server file + descriptor returned in the first ndopen. Note this second ndopen + _will_ block if a client connection is not pending; usually some + external means will be used to avoid opening the client connection + until a client has made a connection attempt. Once the NDOPEN + returns, a second file descriptor can be opened with REOPEN to get + separate buffered streams for reading and writing to the client. + Note that if we repeat the second NDOPEN for additional client + connections, each call will return a new file descriptor (the + private connection to the new client), although the "file name" + "sock:" will be the same in each call. (01/01/2002) + +unix/os/zfiobf.c +unix/os/zfiobf.c [pcix] +unix/hlib/libc/kernel.h +unix/hlib/libc/kernel.h [pcix] + The binary file driver was modified to add VMcache client support. + This adds two new capabilities to the driver: 1) built-in support + for direct i/o (on systems that support it), and 2) a client + interface to the VMcache daemon to permit the daemon to optimally + manage binary file i/o if a VMcache daemon is present. + + Direct i/o is file i/o which transfers data directly between the + disk and process memory, bypassing system virtual memory. For small + files or usage patterns which do not involve heavy i/o, direct i/o + will usually provide lower performance than allowing the system to + buffer data in virtual memory. For large files or usage pattern + which involve very heavy i/o, however, use of direct i/o can prevent + paging and will avoid cluttering up system virtual memory with data + that will be only accessed once. A limitation of direct i/o is + it is only possible when i/o transfers are block aligned and are + an integral number of device blocks in size - this means that + direct i/o cannot be used with the current version of the FITS + kernel, which currently uses a host device block size of 2880. + Direct i/o is currently only available on Solaris systems (versions + 2.6/5.6 or greater - 5.5.1 is not supported). + + Use of the VMcache daemon allows the daemon to control how file data + is cached in virtual memory. This makes it possible to optimize + file access to avoid excessive paging (by freeing space used by low + priority files when new VM cache space is needed), and makes it + possible to cache images in memory for very fast access even by + separate processes (even including non-IRAF programs in many + cases). The VMcache daemon can manage direct i/o on the behalf of + clients, telling the client whether to use normal (VM buffered) i/o + or direct i/o. VMcache can also pre-fetch files so that they are + memory resident by the time the application references them. + + The VMcache daemon is a separate system-level program outside of + IRAF. This is necessary to provide a central system-wide cache + controller. It also provides flexibility, allowing multiple + versions of the daemon to exist, e.g., to allow experimentation with + different types of caching algorithms. It also allows easy + customization of the daemon independently of the IRAF applications + using the VMcache client interface. + + The VMcache client interface was added to the BF driver (rather + than SF) because VMcache is a general low-level file i/o facility, + useful for all file i/o. FMIO files for example (used for QPOE + images) are large binary files but FMIO uses BF and not SF. + + For the moment the VMcache client interface has been added to + zfiobf.c since this is the only system component which uses it. + We may move it out to a separate file later. Two environment + variables have been provided for customizing the behavior of the + client interface: + + VMPORT The tcp/ip socket to be used. The built-in default + is 8677. Both IRAF and vmcached will respond to + this environment variable if defined. + + VMCLIENT Initialization of the VMCLIENT interface. The + string value should be a comma-delimited list of + keywords or keyword=value terms. For example, + VMCLIENT="disable" or VMCLIENT="debug,threshold=8m". + + The keywords currently recognized by VMCLIENT are the following: + + enable Enable use of the VMcache daemon, if any. Used + without the "=value". + + disable Disable use of the VMcache daemon. Used without + the "=value". + + debug Set the debug level. Can be used as either "debug" + or "debug=value". Higher values generate more + detailed debugging messages. + + threshold The file size threshold for use of the VMcache + daemon. Even if use of VMcache is enabled, the + daemon will be used only if the size of the file + being accessed equals or exceed the specified file + size threshold. Smaller files are handled using + normal i/o and do not result in any communication + with the daemon. Values may be specified in bytes + or in kilobytes (k or K suffix) or megabytes (m or M + suffix). + + directio Use of this keyword enables directio and disables + VMcache. The value specifies the file size + threshold for use of direct i/o to access a file. + Files smaller than this value use normal (VM + buffered) i/o. If directio is specified for a + client then use of VMcache is disabled, and no + communication with the daemon will occur. Values + may be specified in bytes or in kilobytes (k or K + suffix) or megabytes (m or M suffix). + + The builtin defaults are VMCLIENT="enable,threshold=8m". + + Normally there will be no VMcache daemon running on a system. If + the VMcache client is enabled a connection attempt will be made each + time a file larger than the threshold is accessed. This is harmless + if no daemon is present, and does not measurably affect execution + time. If a daemon is started after a process is already running, + the process will detect the daemon automatically in the next + connection attempt. If a process is connected to a daemon and the + daemon dies or is killed, the process will silently detect this and + close the connection to the server. If the daemon is subsequently + restarted the client will reconnect. (01/01) + +unix/boot/vmcached/README + +unix/boot/vmcached/notes + +unix/boot/vmcached/vmcache.c + +unix/boot/vmcached/vmcache.h + +unix/boot/vmcached/vmcached.c + +unix/boot/vmcached/README [pcix] + +unix/boot/vmcached/notes [pcix] + +unix/boot/vmcached/vmcache.c [pcix] + +unix/boot/vmcached/vmcache.h [pcix] + +unix/boot/vmcached/vmcached.c [pcix] + + The source for the developmental version of the VMcache library and + the VMcache daemon (vmcached) have been installed in BOOT. There + are no build files as this version is still under development. + The code is complete but only enough debug/test was done to support + development of the VMcache client interface for IRAF (the vmcached + code is debugged but the new version of the vmcache library code has + not been tested). Since the daemon can be worked with outside + the normal IRAF release we do not have to fully develop it for the + release. + + It should be stressed that VMcache is only useful or warranted for + systems that are very data intensive. The standard host operating + system file access heuristics are best for "normal" processing where + either the system is not really busy, or the datafiles are not + excessively large. On systems with very large physical memories + where massive amounts of data are being processed, VMcache can make + a significant difference in overall system performance. + + VMcache is too complex to document here. Without going into the + details, its function is to manage a cache of files in system + virtual memory. Files can be explicitly cached or uncached, or they + can be "accessed", and VMcache will decide whether or not to cache + the file in virtual memory. This is what the VMcache client + interface does: every time it accesses (opens or extends) a file + larger then the VM threshold it sends an "access" directive to the + VMcache daemon. The daemon sends back a response of 0 (file not + cached; use direct i/o to access the file), or 1 (file cached in VM; + use normal VM-buffered i/o to access the file). Even if a file is + not cached the daemon keeps track of all accesses. Files which are + frequently accessed will have a higher prority and are more likely + to be cached in memory. + + IRAF uses only the access directive to interact with VMcache since + a general IRAF task cannot know how it is being used. Higher level + clients may more explicitly control the cache: for example, the + Mosaic DHS will explicitly cache new images as they are read out, + and will cause other file accesses to be given a lower priority. + Any client code can connect to the VMcache daemon. For example we + could add a unix-level task to be called from scripts for explicit + cache control, or a GUI to dynamically display the operation of + the cache and the utilization of system memory. + + The builtin-default cache algorithm implemented in the new version + of VMcache uses the following heuristics to determine whether a file + is cached: + + Factors determining if a file is cached: + + user-assigned priority (0=nocache; 1-N=cache priority) + number of references + time since last access (degrades nref) + amount of available memory (cutoff point) + + Cache priority + + priority = userpri * max(0, + (nref-refbase - ((time - last_access) / tock)) ) + + Tunable parameters + + userpri User defined file priority. Files with a higher + priority stay in the cache longer. A zero + priority prevents a file from being cached. + + refbase The number of file references has to exceed + refbase before the file will be cached. For + example, if refbase=0 the file will be cacheable + on the first reference. If refbase=1 a file + will only become cacheable if accessed two or + more times. Refbase can be used to exclude + files from the cache that are only referenced + once and hence are not worth caching. + + tock While the number of accesses increases the cache + priority of a file, the time interval since the + last access likewise decreases the cache + priority of the file. A time interval of "tock" + seconds will cancel out one file reference. In + effect, tock=N means that a file reference + increases the cache priority of a file for N + seconds. A frequently referenced file will be + relatively unaffected by tock, but tock will + cause infrequently referenced files to age out + of the cache within a few tocks. + + For example, the cache could be configured to not cache a file the + first time it is accessed, causing direct i/o to be used for a file + which is only accessed once. The second time a file is accessed + it would be cached in memory. Files which are frequently accessed + would accumulate a high nref value and would stay in memory longer + than files which are only accessed once or twice. Files which are + explicitly given a high priority (userpri) would stick around even + longer (or could be prevented from ever being cached). Files which + have not been accessed for a long time will age out of the cache + unless they are given a very high priority. + + VMcache is not IRAF-specific. It is a stand-alone facility which + is well integrated with IRAF. IRAF is one possible client. (01/01) + +unix/os/mkpkg +unix/os/mkpkg.sh +unix/os/dio.c + +unix/boot/spp/xc.c +unix/hlib/irafuser.csh +unix/shlib/mkshlib.ssol-sc34 + Use of direct i/o for Solaris proved more difficult than expected + as the system routine required to control this feature (called + "directio") is only available in Solaris 5.6 and later. A 5.5.1 + system will fail to link if directio is used. To get around this + I had to add a compatibility library libcompat.a in HBIN. This + is linked after libc.a and can be used to provide versions of + any system routines not present in libc.a. If libc.a does contain + the routine then this is the version used. (01/01) + +unix/hlib/cl.csh + The logical expression to check for the definition of a $iraf and + it's validity was broken up into separate statements. On some + systems the full expression was being evaluated even if the first + test failed, leading to an 'undefined variable' message when checking + the path validity if it wasn't already defined. (01/02, MJF) + +sys/imoi/iki/fxf/fxfdelete.x + Adding a missing access mode argument to the call to fxf_access. + (01/02) + +lib/syserr.h +lib/syserrmsg +sys/imoi/iki/fxf/fxfplread.x + The miiread routines, which are integer functions, were being called + as procedures. Modified the code to use the return value to check + for a read error. Added call to syserrs and added a new FXF error + message to syserr for a read error on a mask extension. (01/02) + +sys/imio/impmmap.x +sys/imio/impmopen.x + These routines, used to map a pixel mask onto an image descriptor, + were modified to support mapping a mask stored as an image (e.g., + a mask extension in a FITS MEF file). im_pmmap was also modified + to fix a bug that would occur when the BOOLEAN_MASK and INVERT_MASK + flags were both set. (01/03) + +sys/plio/plsaveim.x +sys/plio/plloadim.x + These routines were modified to use PLIO to copy the image section + when saving a mask to an image or loading a mask from an image, and + the image is using a mask internally (e.g., a mask extension in a + FITS MEF file). (01/03) + +pkg/xtools/catquery/cqquery.x + Fixed a couple of typos in the code which detects the end of the + http header. (01/03 LED) + +unix/os/zfdele.c +unix/os/zfiobf.c +unix/boot/vmcached/vmcached.c +unix/os/zfdele.c [pcix] +unix/os/zfiobf.c [pcix] +unix/boot/vmcached/vmcached.c [pcix] + Added code to the VMcache client interface for a vm_delete method. + Modified zfdele (the delete file primitive) to call this function. + The purpose is to notify the VMcache daemon when a file is deleted + so that it can free the associated VM memory used and cache info, + if the file is cached. The usual VM client heuristics apply here, + e.g., nothing is done unless VMcache is enabled and the file size + exceeds the threshold. Also tested the VMcache code on Solaris + (it was tested on FreeBSD earlier) and made some more tweaks. (01/03) + +pkg/images/imutil/src/t_minmax.x + Removed extra aguments from the calls to clpstr. (01/07 LED) + +pkg/xtools/rngranges.x + Added missing rstr argument to 2 rng_error calls. (01/07/ LED) + +sys/ki/irafks.x + Fixed a couple of typos in the server-side code for ZOPDPR. (01/07) + +sys/tty/zzdebug.x +sys/plio/zzdebug.x +sys/pmio/zzinterp.x +sys/qpoe/zzdebug.x +math/interp/bench.x + Minor fixes to make spplint happy. (01/07) + +lib/syserrmsg +sys/imio/iki/fxf/fxfksection.x + Changed the system error SYS_FXFKSINVAL to read: + FXF: invalid value for kernel section parameter () + Also fixed a bug in the TYPE case of the kernel section parsing + code; it was identifying the parameter name in the error message + as "mask" when it should have been "type" (as in type=mask). (01/07) + +sys/imio/iki/fxf/fxfrfits.x + The computed calendar day was of off by one day. (01/07 NZ+DT) + +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfplwrite.x +sys/imio/iki/fxf/fxfopen.x + Fixes installed for problems involving copying an image section. + Also fixed another case of mask code that was limited to 2 dimensions. + (01/07 NZ+DT) + +unix/shlib/S.ver.sparc + Incremented the shared image version number to 8 (S8.e). (01/07) + +unix/shlib/S.ver.ssun + Incremented the shared image version number to 12 (S12_5.5.e, + S12_5.6.e, etc.). Installed the released (V2.11.3) versions of + the older shared images (S7.e in sparc, S11_5[567].e). (01/07) + +sys/imio/iki/fxf/fxfplwrite.x +sys/imio/iki/fxf/fxfopen.x + Fixed a bug affecting copying a section of a mask to a section of + a mask in a FITS extension. (01/08) + +unix/boot/mkpkg/tok.c +unix/boot/mkpkg/tok.c [pcix] + The MKPKG special file list facility was extended to add support + for custom platform-dependent linking of executables. In the + $special directive if the target is a ".e" file the "make object" + command string will be used to link the executable, instead of + whatever command is given in the mkpkg file in the source directory. + Special link directives are only recognized for files linked with + the $link directive in a mkpkg file. (01/09) + +unix/hlib/libc/kernel.h + Increased SZ_DEFWORKSET from 8m to 64m. SZ_MAXWORKSET will be + determined automatically on many recent systems so I did not change + the current default value, which is 256m. (01/10) + +unix/os/zawset.c + This routine (used by BEGMEM to try to get the maximum amount of + physical memory available on a particular computer) was modified to + automatically detect the physical size of system memory. The + technique used should work on most recent POSIX systems, including + Solaris and Linux. The maximum amout of memory that ZAWSET will + return is limited to 2GB even on machines with a larger physical + memory. (01/10) + +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfplwrite.x +sys/imio/iki/fxf/fxfopen.x + Installed a bug fix for the case of copying a section of an existing + mask to a mask extension where the dimensionality of the mask is + reduced. (01/11) + +unix/os/zawset.c +unix/os/zawset.c [pcix] + Made some more enhancements to this routine and tested it. To aid + testing, the routine now recognizes the environment variable + ZAWSET_DEBUG: if this variable is defined, debug messages will be + printed when zawset is called to indicate the total system memory + argument values, and other memory-related parameters. If the total + system physical memory can be determined the routine will + automatically reserve some fraction of the space for the system + to minimize swapping. (01/11) + +unix/hlib/mkpkg.sf.SSUN + Added a special file entry to link x_images.e nonshared (-z) for + Solaris. We probably don't need to do this for the SunOS version, + as any computers still running SunOS are older systems unlikely to + require more than 268 MB per process, and the shared version will + be smaller, use less memory and start up a little faster. (01/12) + +unix/boot/mkpkg/tok.c +unix/boot/mkpkg/tok.c [pcix] +unix/hlib/mkpkg.sf.SSUN + The special file list link support was further enhanced to allow + replacing LFLAGS (the link flags variable) as well as the entire + link line. Replacing LFLAGS is much easier than replacing the + entire link line in cases where all we want to do is change a + link flag (like adding -z to link nonshared), and it avoids + needless duplication of package information in the special file + entry. The SSUN mkpkg special file list of updated to use this + new syntax. (01/15) + +unix/os/zawset.c [pcix] + Installed the new version of ZAWSET on PC/IRAF. (01/15) + +sys/imio/imsetbuf.x +sys/imio/iki/fxf/zfiofxf.x + 1. Modified the FITS image kernel to respect (pass-through) the + device block size of the low level file driver. This is usually + a device sector (512 bytes), the physical storage unit of the + low level storage device. Formerly the FK was setting a pseudo + block size of 2880 bytes, however blocking and deblocking should + be done at the FIO level; if we try to do this in an IRAF file + driver then the host system is required to do blocking/deblocking. + Using transfers which are physically aligned at the hardware level + makes certain optimizations possible, such as direct i/o. + + 2. The imsetbuf routine in IMIO was modified to be a little smarter + in aligning the first file buffer for a pixel file. Formerly it + would only set the offset of the first file buffer if image lines + were aligned to device blocks. This is overly restrictive, and + doesn't work for FITS files. The code was changed to always set the + first file buffer offset for a pixel file, setting it to the offset + of the device block _containing_ the first image line. If the first + image line is not block aligned the FIO buf size is made larger by + the amount of the intra-block offset to ensure that it is big enough + to contain the computed number of image lines for which the buffer + was sized. (The point of all this is to minimize the number of file + reads or writes and the total i/o needed to span an image). (01/16) + +unix/os/zfiobf.c +unix/os/zfiobf.c [pcix.x] + Added another debug level 2 message to the directio directive, to + print debug messages whenever directio is turned on or off for a + file. Directio was tested for FITS files on Solaris and it appears + to be working now. (01/16) + +unix/hlib/cl.csh +unix/hlib/cl.csh [pcix] + Changed the "setenv d_iraf" to "set d_iraf =" since d_iraf is an + internal variable within the script and doesn't need to be exported + to the global environment. (01/19) + +unix/hlib/buglog.csh +unix/hlib/zzsetenv.def +unix/hlib/buglog.csh [pcix] +unix/hlib/zzsetenv.def [pcix] + Changed a couple of ID strings to read V2.12BETA. (01/19) + +unix/os/dio.c + [pcix] +unix/hlib/zzsetenv.def [pcix] +unix/hlib/libc/kernel.h [pcix] +unix/hlib/libc/iraf.h [pcix] +unix/hlib/cl.csh [pcix] +unix/gdev/mkpkg [pcix] +unix/gdev/iism75/mkpkg [pcix] +unix/boot/bootlib/envinit.c [pcix] + A diff/merge of the Sun/IRAF and PC-IRAF HSI was performed and the + following files were updated to merge in various changes from the + V2.12 Sun/IRAF revisions. (01/19) + +sys/mkpkg +lib/libmain.o - + The libmain entry in the system mkpkg was modified to check file + dates against bin$libmain.o instead of lib$libmain.o. It builds + directly into bin anyway so there is no need for the link entry + in lib. (01/19) + +../irafbin/bin.redhat-5.2 [pcix] +../irafbin/noao.bin.redhat-5.2 [pcix] +unix/bin.redhat-5.2 [pcix] + Deleted the RedHat 5.2 binaries. IRAF V2.12 no longer supports + RedHat 5.2. (01/19) + +cl/cl.par +images/images.cl +unix/hlib/login.cl +unix/hlib/login.cl [pcix] + Update cl.version (cl.par) and cl.logver (hlib/login.cl, images.cl) + to "IRAF V2.12 December 2001". hlib$login.cl was updated slightly + as well, adding entries for imextn and pspage, and some more unix- + oriented foreign tasks. Updating cl.version would normally force + the user to update login.cl. This is often not required for a new + release (as is the case this time) so I added a new cl.par parameter + cl.logregen which, if set to "yes" causes a message to be printed + whenever an IRAF session is started with an out of date login.cl. + With this change we can update cl.version and cl.logver in each + IRAF release and still control separately whether a new mkiraf + is required. (01/21) + +unix/os/zfiotx.c [pcix] + Modified the terminal driver code to use sigaction instead of signal + for signal handling on Linux systems. Use of signal was causing + a problem where ctrl/c would fail after using epar/ehist (raw terminal + i/o) on a Linux system. (01/21) + +dev/vdm.gki [pcix] + Replaced with an equivalent but byte-swapped version of the file + which is compatible with the PC architecture. (01/22) + +local/.xinitrc - [pcix] +local/.login [pcix] + Deleted the .xinitrc - there are two many optional desktop + configurations available for PC systems these days to make it + worthwhile trying to retain this. Updated the "win" and "win8" + aliases for compatiblity with recent versions of XFree86. (01/22) + +pkg/images/imutil/src/gettok.x + IMEXPR was incorrectly parsing numbers with exponents like "5.8503E-6". + (01/23) + +pkg/proto/maskexpr/gettok.x + MSKEXPR was incorrectly parsing numbers with exponents like "5.8503E-6" + (see above). At present it uses a private copy of images macro + expansion library. This library should probably be made a system or + xtools library at some point. (01/23 LED) + +---------------------------------------- +Cut V2.12 BETA release. (01/25/2002) + +unix/hlib/extern.pkg + Changed definition of NSO package to use /shared/iraf/extern. The + previous version pointed to a non-existant directory and broke the + package when the system was updated to the servers. (1/29/02, MJF) + +pkg/images/immatch/src/imcombine/src/xtimmap.gx +pkg/images/immatch/src/imcombine/src/icomb.gx +pkg/images/immatch/src/imcombine/src/icgdata.gx + The code to close unused images when they are not needed had an error + when there were y offsets. Rather than closing each image when it not + longer contributed to an output line due to an offset, it was instead + closing all images on every line and then mapping them again. + (1/29/02, Valdes) + +pkg/images/immatch/src/imcombine/src/icombine.x +pkg/images/immatch/src/imcombine/src/icomb.gx +pkg/images/immatch/src/imcombine/src/xtimmap.gx +pkg/images/immatch/src/imcombine/src/icombine.h + The buffer size management calculation based on the number of input + images was no longer working because unless IM_BUFFRAC is explicitly + set to 0, the requested buffer size is just a lower limit. The buffer + size calculation was modified and calls to set IM_BUFFRAC to zero were + added. (1/30/02, Valdes) + +unix/hlib/extern.pkg + Added definitions for the GRASP and GRASPO packages needed by + GONG. Also added NSO to helpd string. (1/31/02, MJF) + +pkg/images/immactch/doc/ccmap.hlp + Fixed a type in the ccmap help page package definition. + (02/01/02 LED) + +dev/hosts + Added solaris machine gongxx (2/1/02, MJF) + +unix/boot/spp/xc.c + Modified for Solaris systems to link the socket libraries dynamic + (at the Solaris level) when linking the IRAF executable nonshared + (at the IRAF level). This is necessary as the socket libraries + are incompatible in different versions of Solaris. (02/02) + +sys/imio/iki/fxf/fxfrfits.x + Modified to correctly handle the case where an embedded BINTABLE + extension is something other than a PLIO_1 pixel mask. (02/02) + +sys/imio/iki/fxf/mkpkg +sys/imio/iki/fxf/fxfplwrite.x + Removed the unused reference from fxfplwrite.x, and added + and to the mkpkg file entry as dependencies. + (02/02) + +sys/plio/mkpkg + Added as include dependencies to the mkpkg file entries + for plloadim.x and plsaveim.x. (02/02) + +unix/hlib/cl.csh [pcix] + Fixed a couple of obscure variable referencing errors. (02/02) + +---------------------------------------- +Updated V2.12 BETA release; public BETA release. (02/02/2002) + + +pkg/images/tv/display/sigm2.x + The routine to compute the maximum value as the interpolated quantity + was incorrect because the size of the input and output arrays were + treated as the same when they are not. This is used for overlay + display which produced the symptom of horizontal lines. + (2/5/02, Valdes) + +pkg/images/tv/display/dspmmap.x + Added the feature that the bad pixel mask or overlay mask may be + specified by a keyword value with the syntax !. This is + important for multiextension files where various masks are set + as keywords. The new task OBJMASKS also writes the object mask name + that is created for an image in the header. Use of !objmask then + allows the object mask to be used for the bad pixel mask (to set + the scaling using only sky pixels) and for overlay. + (2/5/02, Valdes) + +pkg/images/immatch/src/imcombine/src/icmask.x + If pl_loadf fails then pl_loadim is tried. This adds support for + masks in FITS extensions. (2/5/02, Valdes) + +pkg/images/immatch/src/imcombine/src/icmask.x +pkg/images/immatch/src/imcombine/src/icmask.h +pkg/images/immatch/src/imcombine/src/iclog.h +pkg/images/immatch/src/imcombine/imcombine.par +pkg/images/immatch/imcombine.par +pkg/images/immatch/doc/imcombine.hlp + The masktype parameter may now specify ! to select the keyword + to use for a mask. When this option is selected the mask value + interpretation is "goodval". (2/5/02, Valdes) + +pkg/images/immatch/src/imcombine/src/icaverage.gx +pkg/images/immatch/src/imcombine/src/icsigma.gx +pkg/images/immatch/src/imcombine/src/icomb.gx +pkg/images/immatch/src/imcombine/src/icscale.x +pkg/images/immatch/src/imcombine/src/icemask.x +pkg/images/immatch/doc/imcombine.hlp + If weights of zero are given for an image then that image will not + contribute to the output weighted average unless all of the + non-excluded images have zero weight. In that case the unweighted + average is output. The exposure mask is the sum of the exposure times + of the images with non-zero weights. These changes allow combining + only data which is considered good (photometric or good seeing) as + specified by the weights but still including non-good data in the + final image when there is no good data. The combinined zero weight + data will have an exposure time mask value of zero. (2/8/02, Valdes) + +sys/fio/close.x + This routine was supporting the F_CLOSEFD option incorrectly and + could attempt to close an already closed file in the special case + where F_CLOSEFD is enabled but later disabled, leaving the file + closed since it is not reopened until the next i/o occurs. (02/17) + +pkg/images/lib/imcopy.x + Added a missing sfree to the img_imcopy.x routine which fixed a segvio + error seen in the imcopy routine. (02/18, Davis) + +sys/imio/iki/fxf/fxfupdhdr.x + The FITS kernel would fail to expand the header in the case of a + single FITS file when there are more keywords in the IMUSERAREA than + space in the FITS header. (02/18) + +sys/imio/iki/fxf/fxfplwrite.x +sys/imio/iki/ikiaccess.x +sys/imfort/db/idbkwlu.x +sys/gio/nsppkern/zzdebug.x + Fixed some minor instances of mismatched or missing salloc/sfree + pairs. (02/19) + +pkg/images/lib/rgmerge.x +pkg/images/imutil/src/t_imstack.x +pkg/images/imutil/src/t_imsum.x + Fixed some minor instances of mismatched or missing salloc/sfree + pairs. (02/19 LED) + +pkg/images/tv/imexamine/iegimage.x + The changes to support multiple WCS per frame involved keeping track of + the full WCS frame id (i.e. 101) rather than just the frame number. + There was a minor error in this bookkeeping when incrementing the + the next display frame to be used. (2/19/02, Valdes) + +pkg/images/imutil/src/t_minmax.x + Fixed a floating overflow error in minmax which occurs when the + update parameter is set to yes but the input image has a dimensionality + of 0. In this case the min and max values are set to INDEFD but + must be converted to INDEFR before being stored in the image header. + (2/19/02, Davis) + +sys/plio/plsave.x + pl_save uses pl_p2li to encode the line index for a PLIO mask. + For a very large mask the integer values (which are indices into + the line list storage buffer) can be quite large, and will be + incompressible by PLIO unless the image contains zero lines or + duplicated lines. In the worst case it takes a "set high value + absolute) instruction for each index value, and 3 line list words + (6 bytes) to represent 1 integer index value in the encoded line + list. The line list buffer used was not sized for this worst + case value and could overflow. (02/19) + +sys/mwcs/mwsave.x +sys/qpoe/qpiomkidx.x + These routines use pl_p2li in a similar way to pl_save, so I made a + buffer size change as for pl_save above. (02/19) + +pkg/images/immatch/src/imcombine/src/icstat.gx +pkg/images/immatch/src/imcombine/src/xtimmap.gx + asum$t declared incorrectly as type PIXEL rather than real. xt_cpix + incorrectly defined as pointer function instead of a subroutine. + (2/20/02, Valdes) + +pkg/images/immatch/src/imcombine/src/xtimmap.gx + The header keywords were not being fully copied. (2/20/02, Valdes) + +pkg/images/tv/imexamine/iegimage.x + The 'p' was not properly updated for the multiple WCS changes. + (2/26/02, Valdes) + +pkg/xtools/fixpix/xtpmmap.x + The change to IMIO for mapping bad pixel files in FITS extensions + resulted in a different error code when failing to open the file. + This code needed to be recognized by this routine in order to + continue on to try other possible formats. (2/27/02, Valdes) + +pkg/images/imcoords/src/t_wcsctran.x + Fixed a bug the logical to tv coordinate mapping which could occur + if the section subsmapling parameter was > 1, the input image was a + section of a higher dimensioned image, and the first dimension was + not one of those extracted. (3/1/02, Davis) + +pkg/images/tv/imexamine/iegimage.x +pkg/images/tv/imexamine/t_imexam.x + When the frame buffer is used as the image source (when the image name + in the display frame cannot be mapped) the final imunmap would + attempt to unmap the same descriptor twice. (3/1/02, Valdes) + +pkg/images/tv/imexamine/iegimage.x + When imexmaine fails to map the image name returned by the display + server it uses the frame buffer. Previously there was no warning + message about failing to map the image. Now there is a warning. + This is only given once until there is no error or the error message + changes either by going to a new frame buffer or doing a new display. + (3/4/02, Valdes) + +pkg/images/tv/display/t_display.x +pkg/images/tv/display/imdmapping.x + Added a check for the image name being "dev$pix" and if so added the + ".imh" extension to the full node!prefix pathname to avoid an ambiguous + image name error in clients like IMEXAM which need to readback the + image name with a WCS query. The expansion was left in place to allow + iraf networking access to the image. (3/4/02, MJF) + +sys/imio/iki/fxf/fxfplwrite.x + Masks containing empty lines were not being handled correctly. (3/05) + +sys/imio/iki/fxf/fxfrfits.x + A FITS MEF containing an embedded binary table not recognized by + the FK (i.e., anything other than an embedded PLIO mask) would cause + a failure to read the file. Moved the code which detects this + condition so that the FK will skip over FITS extensions it doesn't + recognize, so long as it is not asked to read them. (3/05) + +unix/hlib/mkpkg.sf.SSUN + In addition to x_images.e, x_plot.e and x_tv.e are now linked -z + to avoid the 268 MB per-process memory limitation imposed by the + solaris/iraf shared image. In the case of plot and tv, this was + needed to deal with excessively large PLIO masks used for NDWFS + images. (3/05) + +pkg/images/imutil/src/hedit.x +pkg/images/imutil/src/hselect.x + Added missing xev_freeop calls to the hedit and hselect tasks and a + missing mfree call to the hselect task. (3/5/02, Davis) + +sys/plio/plloadim.x +sys/plio/plsaveim.x +sys/plio/zzdebug.x +sys/pmio/zzinterp.x + [INTERFACE CHANGE] Modified these two routines to add the + arguments title,maxch so that they can save and restore image + headers encoded in the "title" string, as for a PLIO mask + saved in a .pl file. If a mask is being created from an + image with pl_loadim then the "title" string will be encoded + and returned. If an image is being writen from a mask and + encoded "title" string with pl_saveim then the image header + is populated from the encoded title string. This was + necessary to handle image headers uniformly in im_pmmap (see + the discussion under im_pmopen below). These are obscure + routines which are currently only used by the system code in + IMIO (so far as I can tell) hence the interface change should + be a minor risk. (3/05) + +sys/imio/impmmap.x + Deleted the unused stack variables ksection and title. (3/05) + +sys/imio/impmopen.x + Modified im_pmopen (called by im_pmmap) to add the title,maxch + args to the call to pl_loadim, used to load a mask from an image. + The call to pl_loadf, used to load a mask from a .pl mask file, + already sets title,maxch, which is used by im_pmmap to load the + image header of the image it creates from the stored mask. (3/05) + +pkg/images/immatch/src/imcombine/src/iclog.x +pkg/images/immatch/src/imcombine/src/icmask.x +pkg/images/immatch/src/imcombine/src/icstat.gx + Rather than open all the masks at the beginning the masks are now + opened and closed as needed. For situations with offsets this + can reduce the amount of memory required for the masks. + (3/6/02, Valdes) + +pkg/images/immatch/src/imcombine/src/icombine.x + Added error checks for imunmap of the output files. In the final + stage of closing the output if an error occurs, principally in + writing mask, this will at least allow the primary combined output + image to be written. This is useful when an extremely large combining + operation is performed. (3/6/02, Valdes) + +unix/hlib/install + Fixed an error in the pathname prompts when the defaults values are + not accepted. (3/6/02, MJF) + +unix/hlib/install + Modified to permit setuid, setgid, and sticky-bit permissions in + the iraf directory files when doing validity checks. (3/6/02, MJF) + +unix/hlib/install + More small fixes and added checks found when building PC-IRAF systems. + (3/7/02, MJF) + +lib/syserr.h +lib/syserrmsg +sys/plio/plcmpress.x + Modified the pl_compress code slightly to add a sanity check for the + mask being compressed. We had a case where this code went into an + infinite loop in a process that was nearing the 2GB memory limit, + probably as a result of a pointer going negative. (3/10) + +unix/as.linux/zsvjmp.s [pcix] +unix/as.linux/zsvjmp.s.SL40 [pcix] + + Newer versions of Slackware require use of __sigsetjmp, like most + modern Linux versions (RedHat etc.). (3/10) + +unix/boot/mkpkg/host.c [pcix] + The resolvefname code could fail in some cases where the pathname + was a simple file name. (3/10) + +unix/hlib/install [pcix] + Various minor changes to support the PC-IRAF platforms. (3/10) + +unix/os/zgtime.c [pcix] + Added an include for to pick up the CLK_TCK definition + to get things to build correctly on some PC-IRAF platforms. (3/10) + +unix/bin.linux/f2c.e [pcix] +unix/bin.linux/f2c.e.SL40 [pcix] + + Replaced the LNUX f2c.e by the RHUX version, required by Slackware 8 + which uses glibc2. (3/10) + +unix/os/zopdir.c [pcix] + Added a new ifdef check for LINUX to the dirfd() usage as required + for newer Linux/IRAF (Slackware) systems. (3/11) + +---------------------------------------- +Updated V2.12 BETA release; second public BETA release. (3/12/2002) + + +dev/imtoolrc +dev/graphcap + Added new stdimage devices imt45-imt49 submitted by Gemini for + GMOS CCD displays at various sizes. (3/14/2002, MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + When copying an extension or subsection of an extension to a new + file some of the header keywords could be duplicated at the end + of the header. (3/15) + +sys/imio/iki/plf/plfupdhdr.x + If an error occurred while writing the header to a pixel mask + image the error handler in this routine would mask the error and + no error was being reported to the caller. (3/15) + +doc/newsfile +doc/v212revs.hlp + + Installed the V2.12 Revisions Summary and updated the 'news' command + files. (3/15/02, MJF) + +dev/hosts + Aliased 'ndws' to 'archive' (3/18/02, MJF) + +dev/hosts + Added new NDWFS RedHat machine 'dropbear' (3/19/02, MJF) + +pkg/images/tv/display/t_display.x + If an image section of a higher dimensional image is displayed the + image section is included in the image name sent to the display + server. Previously the section was stripped and so it was not + possible to know the 2D section displayed. For now we keep backwards + compatibility by stripping any section from 2D parent images. + (3/20/02, Valdes) + +pkg/images/tv/imexamine/iegimage.x + Image sections in the image name retrieved from the display server + are now handled more intelligently. In particular, 2D sections of + higher dimensional images will now examine the correct 2D section + rather than just the lowest 2D plane. (3/20/02, Valdes) + +pkg/dataio/export/export.h + Changed the zscale sampling parameters to use more points spread out + over more of the image. The old values would sometimes find an + innappropriate z1/z2 range causing problems when doing many images in + batch mode. (3/20/02, MJF) + +unix/hlib/install +unix/hlib/install [pcix] + A previous change that added a check for write permission on the iraf + tree (to edit paths) proved to be too restrictive when installing on + an NFS client node. The check was modified to allow the install to + continue without editing files if the user wanted, this would create + the local command links and device files but not edit the paths in + the iraf files. A '-noedit' option to force this behavior was also + added. (3/20/02, MJF) + +sys/imio/iki/fxf/fxfrfits.x + The limtime value calculated was off by a day after Feb 2002 and as + a result DATAMIN and DATAMAX were not being updated in headers. + Replaced the code which calculates limtime by a more robust calculation + based on the Julian day taken from asttools. (3/21) + +sys/imio/iki/fxf/fxfupdhdr.x + The update header code was modified to delete BSCALE and BZERO for + floating point images, just in case they are added to the header + by the application after the image has already been opened. + We may as well do this since the FK does not support use of scaling + when reading floating point images, and the presence of these + keywords in the header could cause an i/o error when the image is + later opened for reading (as seen in ST HSTIO code during testing + of V2.12). (3/21 NZ+DT) + +pkg/images/tv/tvmark/mkoutname.x +pkg/images/tv/tvmark/mktools.x + Fixed a bug in the default output image name code that would result + in hidden images with names like .snap.1, .snap.2, etc being written + if the display image name included a kernel or pixel section. + (3/21 LED) + +dev/hosts + Added redhat machines cholla and pym, removed pyxis (3/24/02, MJF) + +dev/hosts + Added the MacOS X host cetus. (3/24) + +doc/newsfile +doc/v212revs.hlp + Fixed some typos and formatting problems with the revisions (3/25, MJF) + +pkg/system/help/t_help.x + Fixed a bug with dev=text where the standout flags weren't being + properly disabled. (3/25/02, MJF) + +unix/hlib/install +unix/hlib/install [pcix] + Small change to allow a "no-edit" install to skip the configuration + stage (all of which require edit permissions). (3/25, MJF) + +noao/mkpkg + Added an entry for MACOSX. (4/02) + +pkg/images/imcoords/src/t_wcsctran.x + Added an error check for INDEF valued input coordinates. (4/04, LED) + +pkg/images/immatch/src/imcombine/src/icmask.x + There was a bug in the recent change to open and close masks as needed + where a possibly null filename pointer was being checked for being + a null string. (4/8/02, Valdes) + +pkg/lists/doc/Lintran.hlp +pkg/images/tv/iis/doc/Cv.hlp + The above files were rename to Lintran.spc.hlp and Cv.spc.hlp + respectively in order to work around upper / lower case file name + ambiguities in MACOSX. (4/11, LED) + +pkg/images/imcoords/src/t_ccget.x + Ccget was not transforming the units and applying the user supplied + formatting parameters if the input or output coordinate system, e.g. + ICRS, was the same as the catalog coordinate system. This bug does + not affect released code. (04/16/02, Davis) + +unix/hlib/install +unix/hlib/sysinfo +unix/hlib/install [pcix] +unix/hlib/sysinfo [pcix] + Mods and bug fixes needed for OS X (04/16/02, MJF) + +pkg/images/immatch/src/imcombine/src/icsetout.x + When computing offsets the registration point was the reference pixel + returned by mw_gwterm for the first image. The code then went on to + assume this was a logical pixel when comparing with the other images, + which is not true when there is a physical coordinate system. The + algorithm was fixed by converting the reference point to logical + coordinates. (4/18/02, Valdes) + +pkg/cl/main.c + The routines startup() and shutdown() in the CL main conflicted + with host library routines of the same name on MacOSX. Changed + these two routines plus login() and logout() to static functions. + Added a new external function cl_shutdown to allow the error + recovery code to get at the now static shutdown(). (4/21) + +pkg/cl/errs.c +pkg/cl/errs.h +pkg/cl/binop.c + Modified the interpreter binary divide operator to check for a + zero divisor and call cl_error if a divide by zero is attempted. + Added two new error actions for integer and floating divide by + zero. (4/21) + +unix/hlib/config.h [pcix] +unix/hlib/libc/spp.h [pcix] + Increased LEN_JUMPBUF to 1024 for this platform to allow for the + worst case jmpbuf for MacOSX (not sure why this can be so big but + it may be the altivec vector registers). (4/21) + +unix/boot/bootlib/rindex.c [pcix] +unix/boot/bootlib/index.c [pcix] + These functions conflicted with the host system versions due to + the dynamic libraries used on MacOSX. Redefined the names for + this platform to avoid the conflict (this is new since the initial + 10.0 port). (4/21) + +unix/os/zzstrt.c [pcix] + Minor modifications for MacOSX. Normally process startup exception + handling initialization is done in this file. For MacOSX nothing + is done at the moment (since the exception handling is mostly + done in software) but the LinuxPPC code had to be reworked somewhat + for MacOSX to build on both platforms. (4/21) + +unix/bin.macosx/mach.h [pcix] + + Installed a byteswap=NO version of in HBIN for MacOSX. + This allows the same PC-IRAF HSI to be used for both Intel and + PowerPC, which are byte swapped with respect to each other. The + default in HLIB is for Intel. Note that any versions + of the global system includes in the HBIN for a platform will + override the global HLIB versions. (4/21) + +unix/os/zzepro.c [pcix] + +unix/hlib/libc/knames.h [pcix] +unix/os/mkpkg [pcix] + Added a new routine ZZEPRO (ZZ End PROcedure) to the PC-IRAF OS. + This is present on all PC-IRAF platforms, but is a no-op (for now) + except on MacOSX. On MacOSX it calls an assembler routine to + read the PowerPC floating point status and control register (FPSCR) + to check if any floating point "exceptions" have occurred. + Currently the floating point exceptions are not enabled for MacOSX, + but the hardware will nonetheless set a bit in the FPSCR if one + of the IEEE-defined exception conditions occur. The ZZEPRO code + will check for a divide by zero, overflow, or invalid operand + exception condition, and if any of these have occurred, execute + a "software exception" by calling the exception handler in ZXWHEN. + The result is exactly the same as a real hardware exception, with + all the same semantics and error actions, except that the + exception condition is not detected until some time after the + instruction which caused it is executed. (4/21) + +unix/boot/spp/rpp/rpprat/endcod.r [pcix] +unix/boot/spp/rpp/rppfor/endcod.f [pcix] + Modified the SPP compiler to insert a call to ZZEPRO (see above) + to every SPP function or procedure. The call is made just before + the function exits. Note that since the check is only made at + the exit from a function, the exception condition often will be + detected in a routine called by the routine in which the + exception condition occurred. For example, if A does a 5.0/0, + then calls B, then B exits, the exception conditition will be + detected by the ZZEPRO call at the end of B. In all cases however, + it won't be very long before the exception condition is detected. + If external C or Fortran code is called an exception will not be + detected until execution resumes in an SPP function. (4/21) + +unix/os/zxwhen.c [pcix] + Added exception handling support for MacOSX. Also, ex_handler + (the exception handler) was changed from static to public so that + it could be called from ZZEPRO. (4/21) + +unix/as.macosx/zsvjmp.s [pcix] + 1. New version of ZSVJMP for MacOSX. This was very tricky to + implement for this platform but it appears to be working now. + ZSVJMP was difficult as it needs to call the host "setjmp" to + do the real work, but MacOSX has only dynamic libraries, so + the routine has to invoke setjmp from the system shared library + from the assembler code! (I think we need to do away with the + assembler version of ZSVJMP - might be possible by adding some + C code generation to e.g. F2C, so that the PC-IRAF implementations + at least could avoid assembler). + 2. New routines GFPSCR and SFPSCR added to get and set the FPSCR + register on MacOSX. (4/21) + +unix/as.macosx/ieee.gx [pcix] + Modified the invalid exception masking support for MacOSX. + Normally floating invalid exceptions are enabled, meaning that if + a NaN or Inf is encountered the invalid operand exception is + invoked. The invalid exception has to be masked in the IEEE + handling code, to allow IEEE NaN/Inf to be detected and replaced + when reading in floating data. (4/21) + +pkg/images/immatch/src/imcombine/t_imcombine.x +pkg/images/immatch/src/imcombine/src/icombine.x +pkg/images/immatch/src/imcombine/src/icsetout.x +pkg/images/immatch/src/imcombine/src/icmask.x +pkg/images/immatch/src/imcombine/src/iclog.x + The projection option was no longer working. There was a typo in + t_imcombine.x, the dimensionality of the image was not set + properly in icombine.x and icsetout.x, and the masks for projected + images was not correct. (4/22/02, Valdes) + +unix/hlib/install +unix/hlib/install [pcix] + Fixed a typo ('MAG' -> 'MSG' on line 1023). (4/22/02, MJF) + +unix/hlib/install +unix/hlib/install [pcix] + Modified to skip the /dev fifo and iraf user login checks which + aren't appropriate for OS X. (4/23/02, MJF) + +unix/boot/spp/xc.c + We had reports of XC not working properly with long filenames. + Changed a 256 char buffer in sys() to SZ_PATHNAME, and also + found a call to symlink() that was dimensioned 128 on the output + buffer even though the actual buffer was SZ_PATHNAME. (4/23) + +images$imutil/src/imadiv.gx +images$imutil/src/generic/imadiv.x + Fixed an error in the imarith code which evaluates an expression of the + form "inimage / 0". This was causing a bus error on the OSX but + apparently not on any other platform. (4/24/02, LED) + +local/.login [pcix] +local/.cshrc [pcix] + Modified to set proper environment for OS X (4/24/02, MJF) + +pkg/images/immatch/src/imcombine/src/icmask.x + The fix of 4/8/02 had been inadvertently undone. (4/25/02, Valdes) + +sys/imio/impmhdr.x + The im_pmldhdr code could go into an infinite loop when reading + a malformed PL imio save header. (4/25) + +sys/imio/iki/fxf/zfiofxf.x + The fxfzop routine had some invalid code at the end of the routine + which was incorrectly trying to set FPKOSFN in what it thought was + the parent file descriptor. (4/25) + +unix/hlib/install +unix/hlib/install [pcix] + 1) Not all failed tests were properly incrementing the error + counter leading to a confusing "successful" install. 2) Added a + new procedure to install symlinks to the .login/.cshrc files for + OS X installs where it's not easy to change the iraf user login + directory. Once the iraf path is edited into the files symlinks + are made in the account directory, which is normally /Users/iraf, + so the iraf user still have the proper environment. (4/26/02, MJF) + +unix/hlib/install +unix/hlib/install [pcix] + 1) The OS X csh didn't like if-stmts without a then/endif when the + test failed, changed all such occurrances. 2) Fixed small problem + with SunOS constructing the recommended hosts file entry. 3) Changed + the file ownership check from a fatal error to a warning. (4/30, MJF) + +pkg/images/imtuil/src/t_imstat.x +pkg/proto/masks/t_mimstat.x +pkg/proto/masks/rsstats.x + If nclip > 0 and the initial mean and standard deviation are INDEF + (a very unlikely occurence unless there is an input mask) the ksigma + limit computation in the imstatistics, mimstatistics, and rskysub + tasks could overflow. This does not affect released code. (5/01/02, + Davis) + +local/notes.solaris - +local/notes.linux [pcix] - +local/notes.freebsd [pcix] - +doc/ports/notes.linux + +doc/ports/notes.freebsd + +doc/ports/notes.solaris + + Moved these old platform porting files to doc/ports. (5/02) + +local/notes.v212 + + Created a new system notes file for V2.12. (5/02) + +---------------------------------------- +V2.12 EXPORT release. (May 2, 2002) diff --git a/doc/notes.v212 b/doc/notes.v212 new file mode 100644 index 00000000..10135899 --- /dev/null +++ b/doc/notes.v212 @@ -0,0 +1,2219 @@ +System Notes File for IRAF Version 2.12. +Begun with V2.12 code freeze 02 May 2002. +------------------------------------------- + +unix/hlib/motd +unix/hlib/zzsetenv.def + Changed system version to V2.12.1-DEVELOP. (5/19/2002) + +unix/hlib/install + Updated the script with several bug fixes found since the initial + V2.12 release. These fix problems with tapecap configuration and + the use of "which" in determining paths. (6/12/02, MJF) + +pkg/images/tv/display/t_display.x + Removed an unused extern declaration for ds_errfcn() which was + causing a link failure on the alpha (6/12/02, MJF) + +pkg/images/immatch/src/imcombine/src/xtimmap.gx + The size of image header data structures was computed incorrectly + resulting in the potential for segmenation violations. (6/14/02, + Valdes) + +pkg/images/immatch/src/imcombine/src/icsetout.x + Needed to disable axis mapping to handle cases where the input + images are dimensionally reduced. (6/14/02, Valdes) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2uhpgl.c +unix/gdev/sgidev/sgi2uimp.c +unix/gdev/sgidev/sgi2uqms.c + Converted some 'sgi' variables to 'sgip' to workaround pre-processor + name collisions on the SGI. This has always been needed on the SGI + system for updates, just moving this into the master system so it's + not forgotten in later updates (6/17/02, MJF) + +maskexpr/peregfuncs.x + Fixed various min / max data type mismatch problems. (06/19/02, Davis) + +pkg/images/immatch/src/xregister/t_xregister.x +pkg/images/immatch/src/xregister/rgxicorr.x + If the xregister task parameter interactive = yes and the output images + are defined then the computed shifts are not applied. This occurs + because the reinitialization routine triggered by the 'n' keystroke + command is in the wrong place. The work around is to run xregister + twice, once interactively to compute the shifts, and again + non-interactively to apply them. (6/20/02, Davis) + +pkg/system/doc/allocate.hlp +pkg/system/doc/devstatus.hlp +pkg/system/doc/deallocate.hlp + Clarified the dev$devices and dev$tapecap files. (7/9/02, MJF) + +pkg/cl/exec.c + Removed an extra argument to an eprintf() call. (7/9/02, MJF) + +dev/imtoolrc +dev/graphcap + Added a 2048x2500 frame buffer called 'imt50' or 'imtwttm' for + the WIYN Tip-Tilt. (7/9/02, MJF) + +sys/imio/iki/fxf/fxfopix.x + fxf_mandatory_cards(). We want to keep BSCALE and BZERO + in case we are editing the values. This is only valid for + access mode READ_WRITE. (7/9/02, Zarate) + +sys/imio/iki/fxf/fxfrfits.x + Load FIT_EXTEND value from cache header entry to + the current fit struct entry. It used to be the other way + around wich was a bug. (7/9/02, Zarate) + + Uncomment the reload code (~line 137) if the cache if younger + than 2 seconds.(7/9/02, Zarate) + +sys/imio/iki/fxf/fxfupdhdr.x + Fix the code to update the value of the keyword EXTEND. + fxf_update_extend(). Add code to update the FIT_EXTEND entry + when the header keyword have been changed to T. (7/9/02, Zarate) + +pkg/cl/cl.par +unix/hlib/motd +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed the cl.version and cl.logver to "IRAF V2.12.1 July 2002" + and updated the motd for the patch release (7/12/02, MJF) + +unix/hlib/install + Several last-minute bug fixes for the Alpha. Also made the query + for an iraf user a bit smarter. (7/12/02, MJF) + +local/login.cl + The logver set in this file was never updated (7/12/02, MJF) + +lib/scr/xgterm.gui +lib/scr/xgterm.gui [pcix] + Changed the default application name/class to 'irafterm' and + 'IRAFterm' respectively. On MacOSX the earlier value 'xgterm' + was conflicting with the app-defaults file due to the case- + insensitive filesystem. Since the filename is the same the + guidir environment variable can still be used to substitute the + GUI itself. (7/13/02, MJF) + +---------------------------------------- +V2.12.1 patch generated. (7/13/02, MJF) + +pkg/cl/cl.par +unix/hlib/motd +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed system version to V2.12.2-DEVELOP. (7/28/02, MJF) + +dev/hosts + Added new NDWFS linux box 'bonza' (8/8/02, MJF) + +pkg/dataio/export/exraster.gx +pkg/dataio/export/bltins/exppm.x + There was a bug in the generation of PPM files when using images with + and odd number of columns causing the line to be too long by one byte. + The output image will now truncate the last column to avoid this since + we cannot write byte data. (8/9/02, MJF) + +os/zgmtco.c +os/zgmtco.c [pcix] + This routine fails to return the number of seconds of correction + from LST to GMT. The error is 1 hour due to not considering the + daylight saving time for those times zones that do have it. This + problem affected the new routines in etc$dtmcnv.x given an + incorrect value for the hour time in DATE value of a FITS header. + The fix was to call localtime() with value time(0) and look + at the tm_isdst flag value. If dst is in effect we substract + 1hour in seconds. (8/19/02, NZ) + +pkg/images/tv/display/dspmmap.x + The matched mask was incorrectly returning the input mask when the + scale and offset matched but not the size. (9/10/02, Valdes) + +os/zgmtco.c + Had to add an #ifdef SUNOS to include for sparc (9/10/02, MJF) + +pkg/images/tv/display/dspmmap.x + A common case of matching a mask to an image is where the pixel sizes + are the same but there are offsets and/or different sizes. An optimized + mask matching based on using range lists and not calling mwcs was + added. (9/12/02, Valdes) + +pkg/images/imgeom/src/t_imshift.x + An incorrect shift of one pixel would appear when the specified shift + was near zero and less than the precision of a real; i.e. yshift=1e-9. + The code was changed to use double precision as appropriate. + (9/12/02, Valdes) + +pkg/plot/t_pradprof.x +pkg/plot/doc/pradprof.hlp + Added parameters "az1" and "az2" to select a range of azimuths for + the profile. (9/13/02, Valdes) + +sys/plio/pll2r.gx + These routines decode the internal pl line format to a range list + format. The decoding involves interpreting the various opcodes in + the pl line format. One of these opcodes, I_PN, says to output N-1 + zero values followed by a data value. However, if the requested + region cuts through the segment the conversion to a range list would + go wrong and output all data values. Fixed the bug (9/18/02, Valdes) + +sys/plio/plp2l.gx +sys/plio/plr2l.gx + If a segment of 4095 zeros followed by a single high value was + encountered the encoding would attempt to set the data value + to 4096 which overflows the data value segment of the encoding. + (9/26/02, Valdes) + +pkg/dataio/import/ipproc.gx + An operand pointer was possibly being freed twice, once in the + ip_wrline() procedure and again in the evvfree() call when processing + completed. This could cause a segfault on some system (9/27/02, MJF) + +unix/hlib/libc/libc.h [+pcix] +unix/hlib/libc/setjmp.h [+pcix] +unix/hlib/libc/stdio.h [+pcix] +unix/hlib/libc/varargs.h [+pcix] + Recent GCC compiler changes changed the way in which include files + were loaded depending on whether they were declared with quotes or + angle brackets. These files were changed to use the quote syntax + for e.g. '#include "stdio.h"' to guarantee the hlib$libc version of + the file was used as intented. (10/10/02, MJF) + +unix/os/zfiond.c [pcix] + Added a new 'nodelay' protocol flag to return an error when reading + a connection with no data or writing to a closed server connection. + This allows applications tasks to essentially poll a network + connection and respond only when data is available. + (10/10/02, Valdes/MJF) + +pkg/system/help/xhelp/xhdir.x + Modified how the file list was contructed to work around a limitation + of sprintf/pargstr for long directory listings. (10/23/02, MJF) + +dev/hosts + Added azure.kpno.noao.edu (ssun) (10/28/02, MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + A call to imputb() was improperly passing an integer value on line + 747, wrapped the value in itob(). (11/4/02, MJF) + +imio$iki/fxf/fxfopix.x + add fxf_not_incache routine to reload the current file in the cache. + An active cache can have the consequence that the file entry is + cleared to make room for another file. (11/4/02, NZ) + +imio$iki/fxf/fxfopen.x + when openning and image READ_WRITE we need to discard some + keywords that are not compatible with the FK. Is an image + is openned correctly then it shloud not have the keyword + GROUPS. (11/4/02, NZ) + +imio$iki/fxf/fxfexpandh.x + A new argument is needed to pass the number of blocks to + expand. (11/4/02, NZ) + +imio$iki/fxf/fxfupdhdr.x + add new argument to routine fxf_expandh(). + Add fxf_not_incache(). See fxfopix note above. (11/4/02, NZ) + +math/curfit/cvinit.gx + If one of the error checks caused an error return the cv pointer + would have been allocated (cv != NULL) but some of the pointer + fields could have garbage values since a malloc was used instead + of a calloc. A later call to cvfree could result in a segmentation + error. This was changed so that 1) a null cv pointer is returned + in the initial error checks cause an error return and 2) the + cv pointer is initially allocated with calloc so that no pointer + fields will be non-NULL until explicitly set. + (11/18/02, Valdes) + +pkg/xtools/icfit/icdosetup.gx + When there is only one sample range that is binned to a single + point this would result in the fitting limits (as introduced + 8/11/00) being equal. This causes cvinit to return an error and + the cv pointer is invald. The change is if the number of binned + fitting points is 1 then the full range of the unbinned data is + used. Note that a change was also made on this date to have cvinit + return a null pointer rather than a partially initialized pointer. + (11/18/02, Valdes) + +pkg/proto/ringavg.cl + +pkg/proto/doc/ringavg.hlp + +pkg/proto/proto.cl +pkg/proto/proto.men +pkg/proto/proto.hd + Added a script task to compute pixel averages in concentric rings. + (11/25/02, Valdes) + +sys/imio/iki/fxf/fxfrfits.x + Added code to reload IM_CTIME and FIT_MTIME values from the fstat() + when they are zero. This condition can occur when the keyword + IRAF-TLM is not present in the header. (1/16/03, Zarate) + +sys/imio/db/impstr.x + Replaced this routine with a version that takes care of updating + keywords with a free format. Fixes a bug reported by ST where HEDIT + wouldn't properly handle the comment if it came before column 30 + in the card. (1/16/03, Zarate/Valdes) + +sys/imio/iki/fxf/fxfrfits.x + Modified code to reallocate memory when a BINARY table is read. + If FIT_TFIELDS is greater than zero more memory is needed hence the + realloc is there now. This fix takes care of the bug reported by + jturner@gemini with their package running under rhux. (1/16/03, + Zarate) + +unix/reboot +unix/reboot [pcix] + Changed the warning message about a NOVOS build to check HSI_CF + where it's defined (1/24/03, MJF) + +pkg/images/tv/imexamine/iegnfr.x + The test for the number of frames needed to check imd_wcsver to avoid + trying to use more than four frames with DS9. (1/24/03, Valdes) + +pkg/images/tv/imexamine/t_imexam.x + Added some missing braces so that if a display is not used it doesn't + check for the number of frames to use. This is only cosmetic at this + time. (1/24/03, Valdes) + +sys/imio/iki/fxf/fxfplread.x +sys/imio/iki/fxf/fxfplwrite.x + To comply with the FITS Compressed Image schema in FITS Bintable + the offset value that is store in the BINTABLE data as the + second long word needs to be in byte units (byte-offset). + This fix will turn FK internal char-offset to byte-offset and + viceversa. (01/24/03, Zarate) + +unix/boot/spp/rpp/ratlibc/getarg.c +unix/boot/spp/rpp/ratlibc/getarg.c [pcix] + Fixed a potentional overflow bug where the EOS could be appended + after 'maxsiz' characters in the string. Changed the loop to go + up only to 'maxsiz-1' to leave room for the EOS. (1/27/03, MJF) + +lib/imio.h + The size of IM_VOFF was not sufficient to handle all 7 dimensions + leading to errors when using more than 5-D images. Changed the + offset of IM_VSTEP to accomodate (4/6/03, Zarate/MJF) + +dev/termcap +dev/graphcap + Added a dozen or so printers around NOAO which weren't accessible + (4/7/03, MJF) + +unix/os/zfioks.c +unix/os/zfioks.c [pcix] + The iraf kernel server code wasn't properly waiting for child + processes to exit when the parent quit leading to defunct processes + laying around. Added a wait() call to clean up the children. + Also move the debug code to the top of the routine so it can + be used to debug the connection and added intializations for + the ZOPNKS arrays so they print properly in the debug output. + (4/22/03 MJF) + +pkg/language/doc/scan.hlp + Added a definition for 'fscanf' to the .help declaration (5/6/03, MJF) + +pkg/language/language.hd +pkg/language/doc/scan.hlp + Added entries for 'nscan' help page (5/7/03, MJF) + +sys/libc/cgetuid.c + Fixed a number of problems with the procedure: 1) Added a "char *" + declaration for the procedure 2) Added type declarations for the + function arguments which were missing, 3) fixed an invalid reference + to c_stupak() in the return, changed to c_strpak() so pack the user + name correctly. (5/7/03, MJF) + +sys/gio/sgikern/font.com +sys/gio/sgikern/greek.com + Updated the sgikern font tables to include a missing 'gamma' in + the greek character set and to fix a spacing problem in the roman + font. (5/21/03, MJF) + +sys/gio/fonts/ + + Added a new 'fonts' subdirectory containing the data and programs + used to create the font tables in case things like this need to be + fixed in the future. See the README for details. (5/21/03, MJF) + +unix/os/zxwhen.c [pcix] + Interrupts were broken under OS X 10.2 due to changes in the signal + handling. Modified sigset() to define the flags required to get the + signal passed properly by defining the (SA_NODEFER|SA_SIGINFO) flags. + Changes are backwards compatible so source will still compile under + 10.1. (6/23/03, MJF) + +unix/hlib/irafuser.csh [pcix] + Added a check for the OS X version to set '-DOLD_MACOSX' on the + HSI_CF flags. Needed for the above signal compatability fix + (6/23/03, MJF) + +dev/graphcap + Modified the psi_def XO/YO values to 0.001 so the plot won't shift + off the page (6/23/03, MJF) + +unix/os/gmttolst.c [pcix] + The OS X code was incorrectly calling gmtime() to get the timezone + offset. This function returns the time adjusted for GMT and so the + timezone was always zero leading to an incorrect time() function in + the CL. Replaced with a localtime() call which sets the timezone + properly. (7/1/03, MJF) + +unix/os/mkpkg +unix/os/zfutim.c + +unix/hlib/knet.h +unix/hlib/libc/knames.h +unix/os/mkpkg [pcix] +unix/os/zfutim.c +[pcix] +unix/hlib/knet.h [pcix] +unix/hlib/libc/knames.h [pcix] + Added a new ZFUTIM() HSI routine on top of the system utime() call + for updating file access/modification times. This procedure and the + VOS tasks which use it are required by the FXF kernel as a means of + touching the file modify times to indicate that an image needs to be + reloaded. Since there is no communication between different processes + each having their own FITS header cache we have only the file info + structures available (at the moment). Modern systems are fast enough + now that the one-second granularity of the finfo() call is no longer + sufficient to indicate a file modification so we need a way to artif- + icially "age" a file to force a reload. (7/7/03, MJF) + +sys/fio/mkpkg +sys/fio/futime.x + +sys/fio/zzdebug.x + Installed new VOS futime() function to reset file modifcation time. + Function prototype is + + int futime (char *fname, long atime, long mtime) + + Time arguments are assumed to be in units of seconds from midnight on + Jan 1, 1980, local standard time. A file may be "touched" to update + it's modify time to the current clock time using the CLKTIME function + with a call such as + + stat = futime (fname, NULL, clktime(0)) + + Remote files are handled via the KI interface automatically. Also + installed a test procedure for the routine in zzdebug.x (7/7/03, MJF) + +sys/ki/mkpkg +sys/ki/ki.h +sys/ki/kfutim.x + + Install KI wrapper routine for the new futime() VOS function. We need + to include this function in the KI to touch remote files. NOTE: the + routine uses a new opcode KI_ZFUTIM with a previously unused value so + programs which use futime() should be prepared to catch an error return + when talking with older versions of the KI. (7/7/03, MJF) + +lib/syserr.h +lib/syserrmsg + Created a new SYS_FUTIME error message for futime() function + indicating the times couldn't be reset. (7/7/03, MJF) + +pkg/immatch/src/imcombine/src/generic/icstat.x + Fixed an incorrect declaration for asumd() (7/8/03, MJF) + +pkg/images/imgeom/src/t_imshift.x + Fixed and incorrect declaration for clgetd() (7/8/03, MJF) + +dev/hosts + Added new ssun machine 'tarat'. (7/11/03, MJF) + +pkg/cl/gram.c + Conversion of sexagesimal numbers such as "=89:59:59.99" was producing + incorrect results due to round-off garbage in the seconds value when + parsing the string with a scanf() call. Retained the scanf parse + to allow for continued checking of bad values, but returned the + converted sexagesimal number using the libc atof() routine. (7/31/03, + MJF) + +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x +sys/imio/iki/fxf/fxfopix.x +sys/imio/iki/fxf/fxfdelete.x +sys/imio/iki/fxf/fxfplwrite.x + Fixed a bug in the FITS header cache in which the images weren't + properly being marked as "dirty" when two processes were operating + on the same image and the first process updates the header within + the same clocktick second that another process the accesses the image, + e.g. MKHEADER updates and image and IMHEAD doesn't see the change. + The solution was to artificially change the modify time on the file + using futime() so the header update logic notices a difference in + the modify time. Also, reset the rf_fit[slot] to a sentinal NULL + value each time it is freed. This is the fix for the so-called + "mkheader bug" reported by Gemini. (8/1/03, Zarate/MJF) + +sys/imio/iki/fxf/fxfplread.x + Changed the code to handle both the old and new plio storage + formats automatically. The newer, correct, format is used to + write extensions but the kernel will not detect images containing + the bug and workaround it accordingly. (8/5/03, Zarate) + +unix/os/zfioks.c +unix/os/zfioks.c [pcix] + A previous change moving the debug open code had the side effect + of breaking the -log facility, moved it back (8/6/03, MJF) + +sys/ki/irafks.x +sys/ki/kfutim.x +unix/hlib/knet.h + A typo in the knet name was keeping the new utime() function from + properly using the KI interface (8/6/03, MJF) + +sys/ki/ki.h + File copies to remote machines has apparently been broken for a while. + What happened is that fcopy() set the SEQUENTIAL advice which caused + the optbufsize on the descriptor to go from 1K to 8K, but the fio + buffering would wait for the full 8K chars before writing to the KS. + This was larger than the 1K buffer allocated in the KI for the text + buffer and would trigger a write error the first time called, leaving + a null file on the remote machine. Modified SZ_TXBUF in to + be large enough for the sequential text file buffers, the change + appears to be backwards compatible to older irafks.e servers and did + not affect binary file i/o. (8/7/03, MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + If editing keywords in the PHU and the keyword EXTEND is T, its value + will change to F. Fixed. (8/20/03, Zarate) + +unix/hlib/mkfloat.csh +unix/hlib/mkfloat.csh [pcix] + Some new Linux distros such as RH9 no longer contain a 'compress' + command as part of the base system meaning this script would fail + when reconfiguring external package architectures or the core + system. Modified the script to work with either 'compress' or + 'gzip' and '.Z' or '.gz' extensions. Also added a warning message + for the longstanding failure when a package 'bin' is a directory and + not a symlink. (8/22/03, MJF) + +unix/os/zfiond.c +unix/os/zfiond.c [pcix] + When calling ZAWRND on a text-mode device the number of bytes being + converted was incorrect and could lead to a segvio. This is because + the VOS assumes this is a binary file driver and would multiply the + 'nbytes' arg by SZB_CHAR in awrite() before the call to the kernel, + passing the true number of bytes and not the number of chars. When + the routine converted the SPP chars to C chars it would then run off + the end of the array, producing garbarge. Fixed the loop index and + added some extra ERR return values. (8/22/03, Valdes, MJF) + +unix/os/zfiond.c + Imported the signal code to catch a SIGPIPE when the server has died + from the PC-IRAF version of the code. (8/22/03, MJF) + +imio/iki/fxf/fxfupdhdr.x + A statement (call fxf_not_incache) to re-read the PHU from the + current file was been called under the wrong condition. Repositioning + the call fixed the problem. (08/26/03 Zarate) + +dev/hosts + Added new Linux server 'crux' (8/26/03 MJF) + +unix/os/zfiond.c +unix/os/zfiond.c [pcix] + Added parens around the connect() call to workaround difference in + how the compiler evaluates the expression (9/3/03 MJF) + +pkg/images/tv/display/t_display.x + The image may be specified as a template provided it match only one + image. (9/11/03, Valdes) + +sys/imio/iki/fxf/fxfupdhdr.x + The statement 'call futime' has been moved from the previous + position in the source code, to update the value of mtime for the + file every time the file is modified. The value is modified by + adding 4 seconds. If one task updates the file, the mod time is + advance in 4 seconds. If another task updates the file again, its + mtime will be modified in 4 seconds. This way we will ensure that + if another tasks from another executable is updating the file, then + the mtime in the FITS cache will be differen, forcing a read of the + header fom disk. (9/15/03, Zarate) + +dev/hosts + Added Dick Joyce's new Linux box 'fungo' (9/23/03 MJF) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x + Fixed a problem in the use of IM_LENHDRMEM/IM_HDRLEN that was + causing a corrupted header card from IMCOMBINE for gemini. + (9/25/03, Zarate) + +pkg/proto/maskexpr/meregfuncs.x + Fixed an type decl/usage error for me_is_in_range() (9/29/03, MJF) + +pkg/proto/maskexpr/peregfuncs.x + Fixed a size decl error in a salloc call in pe_lines() (9/29/03, MJF) + +sys/imio/iki/fxf/zfiofxf.x +sys/imio/iki/fxf/fxfrdhdr.x + Changed bfloat = !(lscale && lzero) to !(lscale || lzero). It could be + that one header keywords BSCALE or BZERO are defined in the header. + If the value is not default then set 'bfloat'. (9/29/03, Zarate) + +sys/imio/iki/fxf/fxfopen.x + Made the access mode a read-only parameter (9/30/03, NZ/MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + Changed the behavior that the FK will delete the BSCALE/BZERO + keywords from the header for real/double images. If an image comes + in with bscale/bzero set for [rd] data the FK will refuse to open + the pixels since this is not supported/undefined by the standard. + Previously, something like adding a new header keyword would update + the header and remove the keywords, leading to a FITS image which + could be opened correctly but where the data values may not be + as intented. With this change the keywords are not removed and the + user must still correct the FITS image outside of the kernel and so + we avoid side effects which may lead to corrupt data. (9/30/03, NZ/MJF) + +unix/os/zfiond.c + Added some missing braces around the binary write in ZAWRND, and + incremented the jmpset flag to accomodate a previous change + (10/1/03, MJF) + +unix/os/zfiond.c [pcix] + Added some missing braces around the text write in ZAWRND to fix + a problem in how the nested if's were being interpreted which was + breaking the ND driver for text files. (10/1/03, MJF) + +unix/os/zgmtco.c [pcix] + Removed an #ifdef LINUX around , this include is needed + on all PC-IRAF systems. (10/7/03, MJF) + +sys/fmtio/patmatch.x + Added an initialization for nchars_matched in gpatmatch() to + properly handle the case of matching a null string (11/21/03 MJF) + +sys/imio/iki/zfiofxf.x +sys/imio/iki/fxfrdhdr.x + Changed bfloat = !(lscale || lzero) to (!lscale && !lzero). The + earlier change was made to handle the case where only one of the + bscale/bzero values was not the default, but the logic was wrong + when one of the value *was* the default. This would prevent the + scaling from being properly applied. (11/26/03, MJF) + +dev/graphcap +dev/graphcap [pcix] + Changed the offset/width for the uepsfl entry to use more of the + page and avoid clipping problems (11/26/03, MJF) + +dev/hosts + Added dtsn1/pipedevn (11/30/03, MJF) + +sys/psio/font.com + Changed type of 'i' index variable used in the common from short + to integer to satisfy some (g77) compiler complaints (11/30/03, MJF) + +sys/fio/vfnmap.x + Moved the vvfn_checksum() function to the end of the file to fix a + forward reference error (11/30/03, MJF) + +pkg/system/help/lroff/center.x +pkg/system/help/lroff/dols.x +pkg/system/help/lroff/getarg.x +pkg/system/help/lroff/lroff.x +pkg/system/help/lroff/lroff2html.x +pkg/system/help/lroff/lroff2ps.x +pkg/system/help/lroff/section.x + Renamed the 'getarg' procedure to avoid clash with intrinsic fortran + function name (11/30/03, MJF) + +dev/tapecap [pcix] + Changed the default symlink to point to tapecap.linux (12/3/03, MJF) + +pkg/cl/cl.par +unix/hlib/motd +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed the cl.version and cl.logver to "IRAF V2.12.2 December 2003" + and updated the motd for the V2.12.2 patch release (12/04/03, MJF) + +unix/hlib/install + Updated with recent bug fixes reported to site support (12/4/03, MJF) + +local/login.cl +local/login.cl [pcix] + Updated with changes made in the last few years to the default + hlib$login.cl as well as the logver string. The iraf account login.cl + is a handcrafted version which shouldn't be recreated w/ mkiraf. + (12/4/03, MJF) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x + Fixed a problem in which the IM_HDRLEN and IM_LENHDRMEM struct + elements could be out of sync when the header size was increased. + (12/4/03, Zarate/MJF) + +unix/boot/spp/xc.c + Newer versions of tcsh no longer allow a dash in an environment + variable, rendering the XC-CC type variable useless. Modified the + code to allow the variable with either a dash or an underscore. + Also, added support for XC-CFLAGS, XC-FFLAGS, and XC-LFLAGS (along + with the undercore complement) as a means of passing in flags + peculiar to the compiler being changed. (12/4/03, MJF) + +unix/boot/spp/xc.c [pcix] + Made the same set of environment changes. In addition, added minor + support for 'g77' as a compiler by checking the XC-F77 value and + modifying the link line to use -lg2c instead of -lf2c. (12/4/03, MJF) + +unix/bin.redhat/libcompat.a [pcix] + Added the object files ctype-info.o, C-type.o and C_name.o from + the glibc-2.2.5 libc.a. Newer systems such as RedHat 9 have moved + to glibc-2.3 where the standard string functions like isdigit() are + now defined in using new localization definitions, meaning + the symbol "__ctype_b" would be unresolved in libos.a. By importing + these object on RH9 systems the missing symbols are resolved and + iraf uses the old glibc-2.2 ctype behavior. (12/4/03, MJF) + +unix/boot/spp/xc.c [pcix] + Added a -lcompat library to the LINUX link lines so that this is + included following the system libos.a to pick up needed symbols on + glibc 2.3 systems. (12/4/03, MJF) + +unix/boot/spp/xpp/mkpkg.sh + Removed a comment preventing the executble from being properly + installed (12/4/03, MJF) + +unix/hlib/irafuser.csh [pcix] + Deleted static link from the HSI_LF for redhat/suse. Aside from the + unresovled symbol issue, many of the HSI binaries built statically + under older systems would segfault on new linux systems. Dynamic + linking against libc seems to solve this problem. (12/4/03, MJF) + +mkpkg + Modified the toplevel mkpkg to touch hlib$utime each time the system + is built. The purpose of the utime file is to act as a flag to the + CL to indicate when the uparm files may be out of date, the file time + is updated by the install script. However, many users with existing + installations simply overlay the new release and don't rerun the + install script so we see more parameters errors (indeed it's been + more than 6 years since utime was touch on tucana). By updating + the utime file w/ each build we're guaranteed to have a current + parameter update mechanism even on the development machines. + (12/4/03, MJF) + +unix/hlib/as.redhat/zsvjmp.s [pcix] + Testing under Fedora (gcc 3.3/glibc 2.3) showed the loader segfault + which has been reported recently on some newer SuSE systems. This + was traced to a elf procedure when loading zsvjmp.o, the problem is + apparently in the definition of 'mem_' to an absolute zero value. + The fix is to comment out the definition in zsvjmp and define the + value on the link line. (12/5/03, MJF) + +unix/boot/spp/xc.c [pcix] + Modified to add "-Wl,--defsym,mem_=0" to the link line for linux. + (12/5/03 MJF) + +---------------------------------------- +V2.12.2-BETA patch generated. (12/6/03, MJF) + + +local/.login [pcix] + Minor changes to define IRAFARCH for suse correctly (12/12/03 MJF) + +unix/hlib/f77.sh [pcix] + Generalized the -O and -f* optimizer flags to the script in order to + pass in more GCC options. Had to move the -f2c flag so it was + handled separately before the -f options. (12/17/03, MJF) + +unix/boot/spp/xc.c [pcix] + More changes to allow for runtime configuration: 1) The optimizer + flags were generalized to allow greater configuration on each platform. + The default is "-O3 -fstrength-reduce -fpcc-struct-return" but these + may be overridden by the user and will be tuned when the final system + is built. 2)The user-defined XC_[CFL]FLAGS were moved to be the last + things defined so they could override the hardwired options (primarily + the optimizer). 3) The addflag() procedure was renamed addflags() + and generalized to allow multiple flags to be passed in (such as from + XC_FFLAGS) as a single string - the routine splits into separate + arguments on whitespace (12/17/03, MJF) + +pkg/cl/gram.c +pkg/cl/unop.c +pkg/cl/binop.c +pkg/cl/operand.h + Added several new builtin functions to support the Gemini programming. + These include: + + isindef(expr) + Can be used to check for INDEF values in expressions. INDEF + values may be tested for equality, however when otherwise used + in a boolean expression the result of the boolean is also + INDEF. This function can be used to trap this particular + case, or for INDEF strings/variable directly. Result is a + boolean yes/no. + strldx(chars,str) + Complement to the stridx which returns the last occurance of + any of 'chars' in 'str'. Returns index of last char or zero + if not found. + strlwr(str) + Convert the string to lower case, returns a string. + strupr(str) + Convert the string to upper case, returns a string. + strstr(str1,str2) + Search for first occurance of 'str1' in 'str2', returns index + of the start of 'str1' or zero if not found. + strlstr(str1,str2) + Search for last occurance of 'str1' in 'str2', returns index + of the start of 'str1' or zero if not found. + + The new string functions are particularly use for dealing with + pathnames where one needs to find and extension, separate a file + from a path prefix, and so on. New builtin functions may be added + in the next release if needed. + + Also, modified the substr() function to allow a 'last' index greater + than a 'first' index, in which case the returned string is reversed. + (12/18/03, MJF) + +language/language.hd +language/doc/strings.hlp +language/doc/isindef.hlp + + Modified/added help text for the above functions. (12/18/03, MJF) + +lib$helpdb.mip +noao$lib/helpdb.mip + Rebuilt the help databases to pick up recent changes to .hd files. + (12/18/03, MJF) + +unix/boot/spp/xc.c + Ported the XC changes made to the PC/IRAF system above to the Sun/IRAF + version. We won't play with resetting the optimization levels for + this release, however the flags are in place to allow the system to + rebuilt to change these if needed. (12/18/03, MJF) + +unix/hlib/f77.sh [pcix] + Added support for flags beginning with '-m' to pass thru machine + optimizations used for platform-specific tuning. (12/18/03, MJF) + +unix/hlib/mkfloat.csh [pcix] + Use of "`which compress`" was causing problems on newer RH systems. + Code was modified to check in other ways (12/18/03, MJF) + +local/.login [pcix] + The login file sourcing the .cshrc file would cause a hang on linux + systems using LDAP. Commented this out since the it's redundant w/ + the way the .cshrc is loaded at login anyway. (12/19/03, MJF) + +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x + Backed out of earlier change which modified the IM_HDRLEN/IM_LENHDRMEM + values when trying to expand the userarea. This resulted in invalid + userarea sizes reported by IMHEAD as well as memory corruption problems + when dealing with extremely large headers. It was determined that the + correct fix was to increase on the size of the local image pointer + used during the header pre-read. (12/19/03, NZ+MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + Restored the removal of BSCALE/BZERO keywords from the header earlier + deleted on 9/30/03. While the problem mentioned then is still + possible, it's less likely than those caused by the HSTIO interface + circumventing the imio keyword interface which rewrites these + keywords to the header. Will look at the issue again for the + next release (12/19/03, NZ+MJF) + +sys/imfort/imdelx.x + The declaration for the 'image' argument wasn't done as an array + which could lead to a segfault or corrupted image name. (12/19/03, MJF) + +sys/imfort/imrnam.x + While tracking down a different problem, noticed that the args to + this function are fortran char*(*) typed but were being passed to + the strne() and imdelx() procedure which want the SPP char types. + Unpacked the strings for the strne() test, and changed the call to + imdele(). (12/19/03, MJF) + +sys/imfort/bfio.x + The int bfflsh() procedure could return without a value (12/27/03, MJF) + +pkg/images/immatch/imalign.cl + Restructured to avoid goto statements, no functional changes + (12/29/03, MJF) + +unix/hlib/as.suse/zsvjmp.s [pcix] +unix/hlib/as.linux/zsvjmp.s [pcix] + Commented out the global definition of mem_ as was done for RedHat. + The symbol is defined on the command line for all linux systems in + xc.c now so this shouldn't matter to most users. The one exception + to this is IMFORT users who build from a makefile or the command + line using something other than XC/FC to compile. These users will + now be required to add a "-Wl,--defsym,mem_=0" to their build command + to avoid an unresolved 'mem_' symbol when linking. This will likely + become a new FAQ but is unavoidable for the moment since recent + versions of binutils tools like 'ld' on some linux platforms crash + when linking zsvjmp.o with mem defined as a global symbol. + (12/29/03, MJF) + +unix/os/zzstrt.c [PCIX] + The definition of 'environ' would cause an error on some linux + systems as it was a redefinition from . Since this is + only used in the code when building shared libs the declaration + was moved to be under a "#ifdef SHLIB" which isn't used currently + for PC-IRAF (12/29/03, MJF) + +unix/boot/spp/xc.c + Fixed a small bug in the new addflags procedure affecting only + Solaris x86 (12/31/03, MJF) + +------------------------------------------------------ +V2.12.2-BETA -- second patch generated. (1/2/04, MJF) + +pkg/dataio/export/exraster.gx + Fixed a bug in computing the number of output pixels (1/5/04, MJF) + +pkg/images/immatch/src/geometry/t_geoxytran.x +pkg/images/immatch/src/geometry/trinvert.x + +pkg/images/immatch/src/geometry/mkpkg +pkg/images/immatch/geoxytran.par +pkg/images/immatch/doc/geoxytran.hlp + A new parameter "direction" was added to GEOXYTRAN to allow + evaluating the transformation in either the forward direction (the + previous behavior and default with the new parameter) or the + backward direction. The help page was updated to describe this new + feature and address confusion over the relationship between geomap, + geotran, and geoxytran. (1/7/04, Valdes) + +sys/ki/irafks.x + Minor changes to the debug output to make it easier to trace the + execution of the kernel server. A new routine was added to convert + the KI opcodes to human-readable strings. (1/7/04, MJF) + +unix/os/zfioks.c +unix/os/zfioks.c [pcix] + An earlier change designed to clean up zombie irafks.e processes could + sometimes result in the parent irafks.e being stuck in a wait() and + blocking any further connections. Backed out of the earlier change + and left in the development code which installs a specific SIGCHLD + handler, but still doesn't quite get it done it a reliable and + portable way so zombies are still possible. + + For most users the zombies won't be a problem since they'll go away + automatically once the parent times out. In situations such as the + pipeline where many zombies can be created it's possible to define + port=0 in the user .irafhosts file to fork a new parent irafks.e + for each connection (the so-called 'once-only' option in the code). + Each in.irafksd that gets spawned belongs to the same process group, + but a waitpid(0,...) fails to properly clean up all the children. + Whether this is a linux-specific problem or the semantics of how + the SIGCHLD is delivered when multiple processes exit at the same + time (such as with a 'flpr') is unclear. Since this is a non-fatal + problem it will be resolved for the next release, for now the problem + is no worse than it's always been and there is some extra debugging + code available to look at this again next time around. (1/7/04, MJF) + +sys/etc/cnvdate.x +sys/etc/cnvtime.x + Fixed a typo in the description of the iraf epoch (1/8/04, MJF) + +sys/etc/dtmcnv.x + Added a new dtm_ltime() procedure to convert a DATE-OBS string to + the number of seconds since the start of the iraf epoch. (1/8/04, MJF) + +sys/pkg/system/mkpkg +sys/pkg/system/system.cl +sys/pkg/system/system.hd +sys/pkg/system/system.men +sys/pkg/system/x_system.x +sys/pkg/system/touch.x + +sys/pkg/system/touch.par + +sys/pkg/system/doc/touch.hlp + + Added a new TOUCH task that can be used to update the access/modify + times of files, or create a zero-length file. Behavior is similar + to the unix command of the same name. Times may comes from the + current system clock, a user-specified string, or a reference file. + The task was needed by the pipeline project which needs to be able + to create trigger files on remote iraf nodes. (1/8/04, MJF) + +lib/helpdb.mip + Rebuilt to pick up the new TOUCH task. (1/8/04, MJF) + +local/login.cl [+pcix] +unix/hlib/login.cl [+pcix] + Removed the declaration of the unix 'touch' foreign cmd. Users who + don't do a new MKIRAF will continue to see the foreign command unless + the SYSTEM package is explicitly loaded. (1/8/04, MJF) + +pkg/cl/cl.par +unix/hlib/motd [+pcix] +unix/hlib/login.cl [+pcix] +unix/hlib/zzsetenv.def [+pcix] + Reset the value of cl.logregen to advise users to update with a new + MKIRAF. Also reset cl.version="IRAF V2.12.2 January 2004 and + cl.release="2.12.2" in preparation for the final release (1/8/04, MJF) + +local/.login [pcix] +unix/hlib/install [pcix] +unix/hlib/irafuser.csh [pcix] + Minor changes to define linuxppc arch (1/9/04, MJF) + +unix/bin.linuxppc/mach.h +[pcix] + Added version which set the proper byte swap for linuxppc (1/9/04, MJF) + +unix/os/zgcmdl.c [pcix] + Added ifdef's for xargv/xargv to use f__argv/f__argc defined + on linuxppc which uses libg2c (1/9/04, MJF) + +unix/hlib/libc/varargs-linuxppc.h [pcix] + Updated with newer version from YellowDog 3.0 (1/9/04, MJF) + +unix/boot/spp/xc.c [pcix] + Various changes needed for YDL linuxppc. (1/9/04, MJF) + +unix/hlib/sysinfo [pcix] + Minor changes to define linuxppc arch (1/11/04, MJF) + +pkg/images/immatch/src/imcombine/src/xtimmap.gx + Copying the IMIO structure to an internal structure required two + amovi calls in order to maintain alignment. (1/12/04, Zarate/Valdes) + +pkg/cl/gram.c + The sign wasn't being properly applied to sexagesimal strings due + to an earlier change. (1/12/04, MJF) + +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x + Changes to have the FITS files reflect the actual modify time + of the file. (1/12/04, Zarate/MJF) + +lib/gio.h +sys/gio/cursor/gtr.h + Increased the value of KSHIFT from 100 to 10000. This is the fix + for the latest "imdkern bug". The KSHIFT value is used to encode the + process slot and stream value to the pr_pstofd fio descriptor table + (etc$prc.com) using the expression ((pr * KSHIFT) + stream). A check + for redirection is done (in etc$prpsio.x and gio$cursor/gtropenws.x) + by checking this encoded value against the FIRST_FD/LAST_FD values and + if it falls in-between the cursor code assumes the stream has been + redirected to a file. + Prior to the V2.12 release, the max number of file descriptors + was raised from 256 to 4096 and so the code (-306 in this case, the + negative being a flag that the metacode should be filtered for GIO + workstation transformation, but the abs value is used for the redir + check) was mistakenly assuming the imdkern stream was always redirected + and not writing the data to the stream until a gflush occured. Inc- + reasing the KSHIFT puts the encoded value once again beyond LAST_FD + unless the stream truly has been redirected, in which case it gets a + normal fio descriptor value. (1/22/04, MJF) + +unix/hlib/mkpkg.sf.SSUN + Added DATAIO to the list of binaries linked nonshared. The EXPORT + task is sometimes used on large images and hits the 268Mb limit, + this is a fairly minor change to avoid that problem. (1/22/04, MJF) + +unix/bin.sparc/gterm.e - +unix/bin.sparc/imtool.e - + Deleted these old binaries from hbin$. It's doubtful they would + ever be used, and if the world ever reverts to SunView again we + can rebuild them or get the binaries from an old release (1/22/04 ,MJF) + +unix/hlib/login.cl +unix/hlib/login.cl [pcix] + Moved the loading of the 'clpackage' in front of the 'user' package + definition to allow loginuser.cl to override package definitions + and/or load packages defined in the clpackage.cl (1/23/04, MJF) + +----------------------------------------------------------- +V2.12.2 -- system frozen for final release. (1/23/04) + +local/login.cl + Fixed small typo in the logver string. (1/25/04, MJF) + +unix/hlib/motd + Updated the timestamp on the motd file. (1/25/04, MJF) + +sys/imio/iki/fxf/fxfrfits.x + A typo was accessing the FIT_MTIME struct with the wrong pointer. + (1/27/04, Zarate) + +unix/hlib/motd +unix/hlib/zzsetenv.def + Reset version strings to V2.12.2-EXPORT (1/29/04, MJF) + +unix/hlib/mkpkg.inc [pcix] +unix/hlib/irafuser.csh [pcix] + Removed static link flag from linux architecture. Originally + this was done to provide a platform that could be expected to + run on a number of distributions where versions of the shared glibc + libs could be unresolved. The problem is that now it's more + common to have a problem in the implementation of the glibc + making use of new kernel structs or POSIX interfaces leading to + a segfault from a simple C system call. (1/30/04, MJF) + +unix/hlib/fc.csh [pcix] + Added a missing architecture check for LinuxPPC (1/30/04, MJF) + +unix/boot/spp/xc.c + Added a '-G' flag to XC to force the task to link with '-lg2c' + instead of '-lf2c'. On LinuxPPC this is the required default + behavior, but when using e.g. the Absoft compiler the g2c lib is + required. (1/31/04, MJF) + +mkpkg [pcix] +noao/mkpkg [pcix] + Forgot to add a linuxppc architecture branch (2/1/04, MJF) + +pkg/images/immatch/src/imcombine/src/xtimmap.gx + An earlier change to increase the path length was somehow lost. + (2/3/04, Valdes) + +unix/hlib/cl.csh [pcix] + Last-minute testing under RHEL showed a segfault in nearly all + tasks. This was traced to a number of pointer values being returned + by the system at addresses outside of the process stack space. + This also affects Fedora systems and may well become a problem for + other distributions using newer kernels. Until this is better + understood, added a "limit stacksize unlimited" call to the cl.csh + startup script as a workaround for processes started from the CL. + This is still an issue for IMFORT tasks and will require the user + to do the same in their .cshrc file, however it should be a (mostly) + harmless change for most users. (2/5/04, MJF) + +----------------------------------------------------------- +V2.12.2 -- Final (really) release builds begun. (2/5/04) +V2.12.2 -- Public release. (2/7/04) +----------------------------------------------------------- + + +pkg/cl/cl.par +unix/hlib/motd [+pcix] +unix/hlib/login.cl [+pcix] +unix/hlib/zzsetenv.def [+pcix] + Incremented system version to V2.12.3-DEVELOP. Also reset cl.version + to "IRAF V2.12.2 February 2004 and cl.release to "2.12.3". (2/9/04, MJF) + +sys/imio/db/impstr.x + Fixed a problem where modifying a boolean keyword or a numeric + value could corrupt the comment string. (3/1/04, MJF) + +pkg/images/imcoords/src/t_wcsctran.x + An error in mw_openim was trapped but the garbage in the return value + caused a segmentation error during error recovery. A fix was made to + this and also to report, as a comment, the MWCS error. + (3/12/04, Valdes) + +sys/mwcs/mwopenim.x +sys/mwcs/mwloadim.x + Allocation of the WCS descriptor was moved from before reading the + WCS cards and before calling mw_loadim until after the cards + are read in mw_loadim to allow creating a descriptor based on the + WCS dimensionality rather than the image dimensionality. In + particular, it is no longer an error if the image dimensionality + is zero. (3/12/04, Valdes) + +sys/mwcs/iwrfits.x + The dimensionality returned from reading the WCS cards is now + set to the maximum axis seen when the image dimensionality + is zero and there is no WCSDIM card. (3/12/04, Valdes) + +pkg/images/imcoords/src/t_wcsctran.x + If the image dimensionality is zero then use the WCS dimensionality. + (3/15/04, Valdes) + +pkg/cl/binop.c + Fixed a bug in the new strstr()/strlstr() which could fail due to a + pointer increment side-effect when the last char of the search string + didn't match. (3/22/04, MJF) + +pkg/cl/binop.c + The concat operator could create garbage in the output string when + the first operand was not a string. The problem is that the operands + are popped from the stack in reverse order, but when the first op + is recast as a string it then gets a string storage area which can + overwrite the pointer of the second op. The popop() program comments + even warn that the string should be used before another pushop() (as + is done in opcast()) or else the string will be clobbered. Added code + to preserve the second string (3/22/04, MJF) + +pkg/cl/login.cl + Updated the 'logver' version. (3/22/04, MJF) + +unix/hlib/install + Updated the version string. (3/22/04, MJF) + +sys/mwcs/iwgbfits.x + Fixed a bug where WAT keyword strings could be concatenated inadvert- + antly, e.g. WAT1_001='wtype=linear' and WAT1_002='system=world' + could result in concatenated values without a separating space. Since + concatenation is needed in some cases (e.g. TNX projection coeffs), + a space is only added when the string terminates before col 80 of the + card, indicating a completed string. (3/23/04, MJF) + +pkg/images/imutil/src/hedit.x + The task could segfault when initializing/adding a new keyword with a + null value. The evexpr operator was being initialized as a scalar and + the string pointer wasn't allocated, added a check so string pointer + is always allocated to at least one char. (3/23/04, MJF) + +pkg/cl/builtin.c +pkg/language/language.hd +pkg/language/language.men +pkg/language/doc/which.hlp + + Implemented a new 'which' and 'whereis' set of commands. The 'which' + command searches the package list in reverse order and returns the + first package containing the task, 'whereis' returns a space-delimited + list of all packages containing that task. These are user-convenience + functions mostly, e.g. with many packages loaded and tasks multiply + declared it might not be obvious which instance of a task is actually + being called. + Note, these commands only search the list of loaded packages, in + some cases the user may actually want to find all instances of the + task in the system, but this is better left as a help/references + option (TBD). (3/25/04, MJF) + +sys/mwcs/iwgbfits.x + As earlier fix to this routine had an off-by-one error (3/30/04, MJF) + +sys/etc/main.x + Modified so the return of the ONENTRY call can contain a status value + in the higher bits. The test for PR_EXIT does a 'mod(i,2)' and so + tests only for the process return code. The optional status value + is recovered and returned to zmain(). (4/7/04, Valdes/MJF) + +pkg/cl/main.c +pkg/cl/builtin.c + Added an optional argument to the logout() command which will return + a status value to the shell in #!cl scripts. If no argument is + present the status is zero (OK) as before and the return of the + c_main() remains just PR_EXIT to the iraf main. Otherwise, the + status is shifted left one bit and or'd with the PR_EXIT so the + main still interprets the value correctly. In the iraf main, the + status is recovered and return to the zmain which calls exit() to + set the $status shell variable. (4/7/04, Valdes/MJF) + + +unix/hlib/libc/iraf.h [+pcix] + Added ifdef code for new import_fpoll directive. (4/7/04, MJF) + +unix/hlib/libc/xnames.h [+pcix] + Added definitions for NDOPEN and the new POLL interface functions + (4/7/04, MJF) + +unix/hlib/libc/knames.h [+pcix] + Added definition for new zfpoll() HSI routine. (4/7/04, MJF) + +unix/hlib/libc/fpoll.h [+pcix] + Added include file to define the kernel poll structure (4/7/04, MJF) + +unix/os/mkpkg [+pcix] +unix/os/zfpoll.c [+pcix] + Added new zfpoll() kernel routine. (4/7/04, MJF) + +sys/libc/mkpkg +sys/libc/cpoll.c + +sys/libc/cndopen.c + +sys/libc/creopen.c + + Added LIBC bindings for the network driver ndopen/reopen functions + and the new polling interface. (4/7/04, MJF) + +iraf/lib/poll.h + + Added VOS interface file. (4/7/04, MJF) + +sys/fio/mkpkg +sys/fio/poll.x + +sys/fio/zzdebug.x + Added a new FIO interface for polling file descriptors. The + interface is described in the fio$poll.x source comments and + consists mainly of routines to manage an internal data structure + of descriptors to be polled, along with the primary poll() procedure. + See the test programs in fio$zzdebug.x for usage examples. + This interface operates in a manner similar to the unix poll + command, i.e. it will block until the is activity (either input or + output) on one or more of the file descriptors in the set. Any + FIO file descriptor may be added to the polling set, including + ND descriptors. This makes it easier to now write iraf client/server + tasks with multiple inputs (e.g. accept a new connection, read + data on a socket, write to a file when it's ready, etc), or tasks + which can't afford to block waiting for input from a particular + source. The STDIN/STDOUT streams and any file descriptor returned + from FIO may be added to a poll set. Currently, polling on graphics + streams, or CLIO is not supported. + (4/7/04, MJF) + +pkg/cl/gram.c + Modified the addpipe() procedure to change the pipecode increment + to be 1000 rather than just one to avoid pid conflicts when multiple + CLs are started nearly simultaneously. Also, added code to pipefile() + to permit a user-defined 'pipes' directory to be used in preference + to uparm and tmp. (4/8/04, Valdes/MJF) + +sys/imio/iki/fxf/fxfopix.x + Under certain conditions when in APPEND mode, if the entry + FIT_PIXOFF(fit) is not set, then the 'write blanks' routine does + not append a blank header at the right location. Setting it to the + correct value solves this problem. (4/21/04, NZ/MJF) + +unix/hlib/iraf.h + Forgot a redefinition of 'poll' to 'xfpoll' in libsys.a (5/4/04, MJF) + +sys/mwcs/mwloadim.x +sys/mwcs/iwewcs.x + There is now a check when setting up the WCS from a FITS header + that the CD and LTM matrices have scales defined for all axes. + Note that when there are no keywords unit matrices are + automatically set. It is a problem only when there is a partial + set of keywords. A typical type of format error is when the the + 3rd or higher dimensions are degenerate and no WCS keywords are + included. Rather than waiting for a singular matrix error to occur + (and some applications don't catch this error and later seg fault + or do something else bad) MWCS will now add a unit scale in the + diagnoal element; e.g. CD3_3 = 1. The default action is to add the + scale and issue a warning. The "wcs_matrix_err" environment + variable may be set to 0 to eliminate the warning or 1 or 2 to + trigger an error that the application may trap or trigger an + abort. (5/5/04, FV) + +pkg/proto/interp.x +pkg/proto/doc/interp.hlp + Removed the limit of 200 points from the interpolation table. The + task starts out with a max of 4096 and will dynamically increase the + tables as needed (5/5/04, MJF) + +pkg/proto/intrp.f +pkg/proto/interp.x + The user requesting this task have the limit removed also had a + dataset which would fail due to floating point precision problems. + The task was modified to use doubles (5/6/04, MJF) + +sys/imio/db/impstr.x + An earlier fix to this routine wasn't properly cleaning up the + string when editing existing keywords leading to an indexin problem. + (5/17/04, MJF) + +dev/termcap +dev/graphcap + Added lw37 (6/29/04, MJF) + +unix/hlib/install + On DUNX systems the code creating the libiraf.so link was removing + the .so extension and so only the old version of the shared lib was + still being used. Fixed. (6/29/04, MJF) + +imio/iki/fxf/fxfupdhdr.x + If we need to write more than one block of blanks, substract + one line corresponding to the END keyword, since this will be + written after the blanks. (6/30/04, NZ) + +sys/plio/plssize.x + Changed the initial allocation for the PL_MAXLINE line list buffer. + Previously this was roughly the npix/2 which assumed some compression + would be achieved. However, for extremely complex arrays this would + lead to a short buffer and rather than rely on catching all places + where this may need to be checked we adopt a more conservative value + of the entire length of the line (6/30/04, Valdes/MJF) + + +pkg/cl/cl.par +pkg/cl/login.cl +unix/hlib/motd [+pcix] +unix/hlib/login.cl [+pcix] +unix/hlib/zzsetenv.def [+pcix] +unix/hlib/install + Updated the version to 'V2.12.2a-BETA' (7/1/04, MJF) + +pkg/proto/intrp.f +pkg/proto/interp.x + The earlier change to make the routines double precision had a + remaining use of a 'real' that was causing invalid calculations. + (7/2/04, MJF) + +------------------------------------------------------ +V2.12.2a-BETA -- patch generated. (7/2/04, MJF) + + +dev/hosts + Added new RH9 system denali (7/5/04, MJF) + +lib/helpdb.mip +noao/lib/helpdb.mip + Rebuilt the help databases. (7/6/04, MJF) + +sys/ki/irafks.x + Fixed typos in debug output strings. (7/6/04, MJF) + +pkg/dataio/export/exzscale.x +pkg/dataio/doc/export.hlp + Added a new operand zscalem to do an automatic zscale calculation + with a selection expression to allow excluding bad pixels which + would otherwise perturb the result. The selection expression would + typically involve a bad pixel mask or a selection range. + (7/8/04, Valdes) + +pkg/proto/maskexpr/t_mskregions.x + There was an error that did not allow the new mask to take on the + size of the reference image if one is specified. (7/8/04, Valdes) + +dev/hosts + Added solarch, fixed arch for solarium (7/12/04, MJF) + +unix/hlib/login.cl [+pcix] + Removed the check against TERM in the default terminal stty + command. The problem is that in most cases this will be set + by the user to 'xterm' whether it's correct or not (e.g. in their + unix environment or as a default for PC terminals like konsole). + Previously a TERM=xterm would do an 'stty xgterm' in all cases, + making the MKIRAF setting a no-op and effectively preventing users + from using XTerm properly. (7/14/04, MJF) + +unix/hlib/motd [+pcix] +unix/hlib/zzsetenv.def [+pcix] + Updated the version to 'V2.12.2a-EXPORT' (7/14/04, MJF) + +------------------------------------------------------ +V2.12.2a-EXPORT -- patch generated. (7/14/04, MJF) + +pkg/images/immatch/src/imcombine/src/icmask.x +pkg/images/immatch/src/imcombine/src/Revisions + + Added a feature to allow masks specified without a path to be found + either in the current directory or the directory with the image. This + is useful when images to be combined are distributed across multiple + directories. (7/16/04, Valdes, 8/31 removed unused declaration) + +pkg/images/imutil/src/imgets.x + Modified to allow getting strings with double quotes. + (7/27/04, Valdes) + +sys/imio/db/imgstr.x + Modified to handle strings with embedded single quotes as defined + by the FITS standard. (7/27/04, Valdes) + +pkg/images/immatch/src/wcsmatch/t_wcscopy.x + Removed a check that would not allow dataless WCS to be copied. + (8/25/04, Cooke & Valdes) + +math/gsurfit/gs_chomat.gx + The test for singularity would fail with certain kinds of problems + because the test used EPSILON (should have been EPSILOND for the + double precision) but this is for distinguishing numbers small + numbers from 1 and not from each other. The test is now done + with a comparison against the smallest real or double difference. + The place where this was found to be a problem was with CCSETWCS. + (8/31/04, Valdes) + +noao/lib/strip.noao +unix/hlib/strip.iraf + Updated with recent architectures and dirs in NOAO (9/2/04, MJF) + +local/src/doc/bswap.hlp + Removed execute permissions. (9/2/04, MJF) + +dev/hosts + Added new linux boxes beagle/barium/trout (9/6/04, MJF) + +dev/hosts + Added new linux boxes baires/marten (9/9/04, MJF) + +hlib/install + FreeBSD 5 systems now use a devfs /dev directory. Minor changes + to keep from trying to create the /dev/imt1 fifo pipes on these + systems (10/7/04, MJF) + +pkg/images/imcoords/src/t_ccsetwcs.x + The option to specify a list of images with a single plate solution + record, as described in the help, was not working. This was fixed. + (10/8/04, Valdes) + +pkg/plot/t_implot.x +pkg/doc/implot.hlp +lib/scr/implot.key + The "image" parameter may now be a list and the 'm' and 'n' keys + are used to move through the image. This is an alternate, and + more convenient, version of the 'i' key. + (10/29/04, Valdes) + +pkg/images/imutil/src/imexpr.gx + 1) Fixed a bug in which expressions containing multiple parameter + operands (e.g. a.foo and b.bar) would be evaluated using only the + value of the last operand specified. This was happening because + a pointer was being recycled rather than copied and when the code + went back to patch the parameters it used only the last operand + specified. + 2) Added the ability to use a parameter operand which references an + image operand not directly in the expression. For example, expr="b+c" + where a='dev$pix', b=a.foo, c=a.bar. This allows parameters from + e.g. a reference image to be used without requiring the image itself + to be used. (11/11/04, MJF) + +pkg/cl/binop.c + A string length was declared as a signed char for strldx/strlstr + and would overflow for long strings. (11/22/04, MJF) + +dev/hosts + Added new linux box 'leporis' (12/10/04, MJF) + +unix/hlib/install + Fixed a typo in a do_tapes flag setting for OSX (4/15/05) + +sys/imio/imloop.x + The loop construct would only work properly when the increment was + set to 1. Modified as: + + OLD> if (v[dim] - ve[dim] == vinc[dim]) { + NEW> if (v[dim] - ve[dim] > 0) { + + Now when the counter exceeds the VE by any amount the condition is + true. (5/3/05, Valdes/Fitz) + +pkg/images/imfilter/src/t_runmed.x +pkg/images/imfilter/src/runmed.x +pkg/images/imfilter/src/rmmed.x +pkg/images/imfilter/src/mkpkg +pkg/images/imfilter/runmed.par +pkg/images/imfilter/doc/runmed.hlp +pkg/images/imfilter/imfilter.cl +pkg/images/imfilter/imfilter.hd +pkg/images/imfilter/imfilter.men +pkg/images/x_images.x +pkg/xtools/rmsorted.gx +pkg/xtools/rmturlach.gx +pkg/xtools/xtsample.gx +pkg/xtools/xtstat.gx +lib/pkg/rmsorted.h + Installed new running median task. (5/6/05, Valdes) + +unix/hlib/install + Fixed a typo in an 'endiif' statement (6/7/05, MJF) + +pkg/ecl/ + + +images/imcoords/src/t_wcsedit.x +images/imcoords/wcsedit.par +images/imcoords/doc/wcsedit.hlp + Modified to allow a new data-less WCS header to be created of + dimensionality given by the new parameter "wcsdim". + (6/23/05, Valdes) + +images/immatch/src/wcsmatch/t_wcscopy.x +images/immatch/doc/wcscopy.hlp + Modified to allow creation of a new data-less WCS header. Also checking + on image sizes and dimensionality was commented out. + (6/23/05, Valdes) + +images/imcoords/src/mkcwcs.cl + +images/imcoords/src/mkcwwcs.cl + +images/imcoords/doc/mkcwcs.hlp + +images/imcoords/doc/mkcwwcs.hlp + +images/imcoords/imcoords.cl +images/imcoords/imcoords.men +images/imcoords/imcoords.hd + Two new tasks were added to create or modify simple and standard + celestial and celestial/wavelength WCS. The parameters are designed + to make it simpler for a user to specify WCS information in a + natural way without understanding the details of the WCS structure. + The tasks may be used to make data-less WCS for templates or to + add or update a WCS in an image. These scripts depend on the + changes to WCSCOPY and WCSEDIT which are the underlying interfaces + to the WCS. + (6/24/05, Valdes) + +pkg/xtools/xtargs.x + +pkg/xtools/mkpkg + Simple interface to parse an argument string consisting of a list + of whitespace separated keyword=value pairs. (8/31/05, Valdes) + + +unix/os/zfioks.c + Added a setsockopt to the file to set the REUSEADDR option on the + socket (2/22/06, MJF) + +images/immmatch/src/imcombine/src/icomb.gx + The addition of the sum option failed to add a case for selecting + how to set the keepids flag. Add SUM to the switch on line 229. + (2/28/06, Fitzpatrick, Valdes) + +unix/os/zfioks.c + Added few new environment variables designed to control the behavior + of the network connections. Also improved some of the debugging + messages and added a 'C' or 'S' to distinguish code marked as + 'client' or 'server' for easier tracing. + + The first new variable is KS_RETRY which, if defined, is the number + of retry attempts using the default rsh (or KSRSH) protocol. The + task will sleep for 1 second between attempts and then loop back to + try again to make the connection, this is meant to avoid potential + clashes between multiple machines connecting simultaneously as with + the pipeline. + + The second new variable is KS_NO_RETRY which when defined instructs + the task *not* to attempt a retry using the fallback rexec protocol. + This test is made after the KS_RETRY checks to allow for various + combinations of settings to allow the code to skip retries entirely + (i.e. define only KS_NO_RETRY), retry using the default protocol but + not with rexec (i.e. define KS_RETRY as some value and set KS_NO_RETRY), + or retry only with rexec (i.e. old behavior, don't define anything). + (3/20/06, MJF) + +sys/etc/environ.h + Increased the size of various environment buffers to allow for longer + strings. This fixes a long-standing problem in XC where an excessively + long $PATH would cause a segfault in the envputs() routine. Should + also help with long helpdb strings in user-defined packages. (3/21 MJF) + +lib/imio.h + Increased SZ_IMNAME from 79 to 128 per pipeline request. The extra + space is already allocated in the LEN_IMDES and this is the most we + can do without changing the runtime struct. (3/21/06 MJF) + + +unix/hlib/cl.csh + Fixed a bug in detecting the '-old' flag to start the CL rather than + the now-default ECL. + +unix/hlib/motd + Updated release date. + +====================================== +Include Mac/Intel Port Notes +====================================== + +Mac/Intel Port Revisions: +========================== + +local/.login +bin.macintel + +bin.macintel/IB.MACX.X86 + +noao/bin.macintel + +noao/bin.macintel/NB.MACX.X86 + +unix/bin.macintel + +unix/as.macintel + +unix/os/irafpath.c +unix/hlib/cl.csh +unix/hlib/fc.csh +unix/hlib/install +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf +unix/hlib/strip.iraf +unix/hlib/sysinfo + Set up architecture dirs/paths for port, added a '-DMACINTEL' to + HSI_CF. (1/30/06) + +local/.cshrc + Added some personal preference aliases. + +unix/os/zfiond.c + Ifdef'd a to get the definition of a struct timeval + for the select() call (1/30/06) + +unix/boot/mkpkg/host.c + Had to include "mkpkg.h" to pick up the struct symbol def in + extern.h (1/30/06) + +unix/bin.macintel/rpp.e + Issues with nested switch-case, using the macosx version for now + +unix/bin.macintel/f2c.[eh] + Copied from bin.macosx + +pkg/mkpkg + Added ECL to package list of directories to be built. + +pkg/utilities/mkpkg +pkg/utilities/pffctn.x +pkg/utilities/t_polyfit.x + Broke out the pf_fctn() to a separate file to work around the + extern declaration problems in f2c that couldn't be handled in + f2c.h.. + +unix/as.macintel/zsvjmp.s + Implemented the ZSVJMP procedure for this OS/arch. Appears to + be working as expected and according to the zzdebug routine. + +unix/as.macintel/zz_zsvjmp.c + + Renamed from zz.c. This is a demo code of what the zsvjmp.s is + supposed to do that can be used in future ports. Added more comments + to the header for reference. + +unix/as.macintel/f2c.tar.gz + Added a source distro of F2C used in building the binaries on this + system. We hadn't previously kept this in the tree and F2C is normally + installed on this platform. We can move to GFORTRAN at a later point or + as an option but that isn't yet ready for Mac/Intel or a standard part + of the Xcode. + +unix/bin.macintel/f2c.h + Modified typedefs for extern problem. + +unix/hlib/libc/stdarg.h +unix/hlib/libc/stdarg-osx.h + + Added the GCC stdarg.h to the libc directory so it will be included + properly. We can't simply include because the include chain + has hlib$libc at the head and this would lead to a recursive error. + Adding files to the special files list to compile -Inolibc is an option + but not for external packages so we compromise with a platform-specific + include in the libc directory. + +unix/boot/mkpkg/host.c + Needed to include "mkpkg.h" to get 'struct symbol' definition + properly. + +unix/boot/mkpkg/scanlib.c + Added support for the "4.4bsd archive extended format #1" used + on this system. Fixes a problem where everything in an archive would + always be rebuilt. + +sys/fmtio/evexpr.y +sys/fmtio/evvexpr.gy + Fixed a bug in the string-matching operator '?=' where the patstr + pointer wasn't initialized, and then wasn't used after translating a + pattern such as '*foo*' to use '?*foo?*' closures. + +sys/mwcs/mkpkg +sys/mwcs/wfzpn.x +sys/mwcs/wfinit.x + Installed a ZPN projection driver from the Cambridge Astronomical + Survey Unit. + +local/bugs.log +local/notes.v212 +unix/os/zfioks.c +noao/lib/helpdb.mip +pkg/images/Revisions +pkg/images/imcoords/src/mkcwcs.cl +pkg/images/immatch/doc/geotran.hlp +pkg/images/immatch/doc/imcombine.hlp + Sync'd with latest from tucana. + +pkg/images/immatch/src/imcombine/src/icomb.gx + Installed path for buglog 552. + +noao/nproto/Revisions +noao/nproto/nproto.cl +noao/nproto/nproto.hd +noao/nproto/nproto.men +noao/nproto/skysep.cl + +noao/nproto/skygroup.cl + +noao/nproto/doc/skygroup.hlp + +noao/nproto/doc/skysep.hlp + + Installed new NPROTO tasks. + +unix/hlib/cl.csh + Made ECL the default in response to the 'cl' command. + +local/login.cl +unix/hlib/login.cl + Fixed the problem with the access() error message that sometimes + appears. + +unix/hlib/install +unix/hlib/ecl.csh -> cl.csh + Modified the install script to create an 'ecl' command. Needed to + create a hlib$ecl.csh symlink to keep this simple. This is mostly a + nicety as 'ecl' is now the default command language. + +unix/boot/spp/rpp/rppfor/caslab.f + Initialized the 'caslab' return to be zero. Previously this procedure + was returning a -1 value causing the parent cascod() to read an EOF on + multi-value cases such as "case 1,2:" and would return an error message + about a missing label that was never generated. This is a different + behavior than the same code under linux/macosx, and even though this is a + newer version of F2C this was assumed to be a platform issue. NOTE: the + assciated RATFOR has not been modified. The RPP binary is now native + Intel rather than using the PPC binary as was done earlier. + +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed the version string to be V2.13. This was done such that + packages like GEMINI could still version-check without failing even + though the hlib$motd makes clear this is an iraf.net release. + +mkpkg +noao/mkpkg + Added 'macintel' architecture. + +unix/os/zxwhen.c +unix/os/zzepro.c +unix/os/zzstrt.c + Re-implemented the FPE handling for OSX using standard system + procedures (e.g. feclearexcept(), fegetexceptflag(), etc). The usual + errors are now caught again. + + +unix/os/zfioks.c + Added few new environment variables designed to control the behavior + of the network connections. Also improved some of the debugging + messages and added a 'C' or 'S' to distinguish code marked as + 'client' or 'server' for easier tracing. + + The first new variable is KS_RETRY which, if defined, is the number + of retry attempts using the default rsh (or KSRSH) protocol. The + task will sleep for 1 second between attempts and then loop back to + try again to make the connection, this is meant to avoid potential + clashes between multiple machines connecting simultaneously as with + the pipeline. + + The second new variable is KS_NO_RETRY which when defined instructs + the task *not* to attempt a retry using the fallback rexec protocol. + This test is made after the KS_RETRY checks to allow for various + combinations of settings to allow the code to skip retries entirely + (i.e. define only KS_NO_RETRY), retry using the default protocol but + not with rexec (i.e. define KS_RETRY as some value and set KS_NO_RETRY), + or retry only with rexec (i.e. old behavior, don't define anything). + (3/20/06, MJF) + +sys/etc/environ.h + Increased the size of various environment buffers to allow for longer + strings. This fixes a long-standing problem in XC where an excessively + long $PATH would cause a segfault in the envputs() routine. Should + also help with long helpdb strings in user-defined packages. (3/21 MJF) + +lib/imio.h + Increased SZ_IMNAME from 79 to 128 per pipeline request. The extra + space is already allocated in the LEN_IMDES and this is the most we + can do without changing the runtime struct. (3/21/06 MJF) + +unix/hlib/cl.csh + Fixed a bug in detecting the '-old' flag to start the CL rather than + the now-default ECL. + + +====================================== +Include Cygwin Port Notes +====================================== + +Port start (4/12/06) + +Port Revisions: +=============== + +local/notes.cygwin + + Started this file..... + +mkpkg +noao/mkpkg +local/.login +bin.cygwin + +bin.cygwin/IB.CYGW.X86 + +noao/bin.cygwin + +noao/bin.cygwin/NB.CYGW.X86 + +unix/bin.cygwin + +unix/as.cygwin + +unix/os/irafpath.c +unix/hlib/cl.csh +unix/hlib/fc.csh +unix/hlib/install +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf +unix/hlib/strip.iraf +unix/hlib/sysinfo + Set up architecture dirs/paths for port, added a '-DCYGWIN' to + HSI_CF. (4/11/06) + + +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + Changed the 'timezone' variable to '_timezone', ifdef'd code. + +unix/os/zawset.c + Ifdef'd the code definitions for RLIMIT not on this system. + +unix/os/zopdir.c + Cygwin dirent type doesn't include the 'd_ino' element so the usual + way to read directories and look for empty inodes doesn't apply here. + Made a trivial change which should effectively be a no-op since we won't + ever expect a null inode anyway. Need to check on how stat/lstat deals + with inodes, there is apparently a define that can be enabled in the dev + Cygwin version that will compute an inode hash of the filename to fake this + but we apparently don't need it now. + +unix/os/zxwhen.c +unix/os/zzepro.c +unix/os/zzstrt.c + Implemented the FPE handling using the libmingwex.a procedures. + +unix/hlib/libc/varargs.h +unix/hlib/libc/stdarg.h +unix/hlib/libc/stdarg-cygwin.h + + System uses but like on other systems this file is in + the GCC tree and not the public /usr/include. As before, made a local + copy we'll include in the libc directly. + +unix/as.cygwin/zsvjmp.s + + Implemented ZSJMP for this system, removed leading underscores on + symbol names. + +unix/bin.cygwin/f2c.e +unix/bin.cygwin/libf2c.a + Built the F2C libs for this platform. + +unix/bin.cygwin/libcompat.a + Pulled out the feclearexcept/fe[sg]etexceptflag procedures from the + /lib/mingw/libmingwex.a library so we can use the same FPE handling code + as for OSX. This lib isn't part of the base install for Cygwin so rather + than add a dependency to the platform we'll use the existing libcompat.a + +unix/boot/spp/xpp/decl.c + Fixed a problem in the XPP stage where a function as the first procedure + in a file would not emit the procedure name properly. This has been seen + sporadically on other platforms in the past and appears to be related to + a lexical context problem. Will investigate more later, did a quick fix + for now. + +unix/boot/spp/xc.c +unix/boot/spp/xpp/xppcode.c +unix/boot/spp/xpp/xppmain.c +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.CYGW + +unix/bin.cygwin/arch_includes/ + +unix/bin.cygwin/arch_includes/fio.h + +unix/bin.cygwin/arch_includes/pllseg.h + +unix/bin.cygwin/arch_includes/plrseg.h + + There is apparently a bug in the handling of multi-line define macros + such that the popcontext() is called at the end of the first line however + the remainder of the macro doesn't get emmitted until sometime later. + The buffering issue was too tricky to figure out for now so I took + advantage of the fact irafpath() will look in hbin$ before lib$ to allow + for an arch-specific version of a system include like that is + causing a problem. For local includes such as in plio, I added a new + '-A' flag to both XC/XPP to force the code to look in a hbin$arch_includes + directory first for local include files. For the plio cases the reference + was to e.g. "../pllseg.h" so the files need to be a the correct relative + location (TODO: strip path specs from local includes...). The affected + files were put on the special file list for this platform + +unix/bin.cygwin/fio.h + +unix/bin.cygwin/pllseg.h + +unix/bin.cygwin/plrseg.h + + These includes defined multi-line macros. Made arch_include versions + without the newlines. + +sys/fmtio/fprfmt.x + Crap, multi-line define in this one file we can't work around as + above. For now just change the macro..... + +unix/hlib/mkfloat.csh + Check for cygwin arch when defining the $COMPRESS var, cygwin doesn't + support the -f flag + + + +# --------------------------------------------------------------------------- + +Sysgen completes without errors, all seems to be working. (4/14/06) + +./zzclean +./zzmake +./zzsums +./zzsysgen +====================================== +V2.13 Second Beta Release (4/19/06) +====================================== + + +sys/vops/fftr.f +sys/vops/fftx.f + Increased the check for the power-of-2 dimension to 2^31 from the + current 2^15 (4/21/06, MJF) + +dev/graphcap +dev/termcap + Created generic devices using lpr/lp commands and the psikern for + color printers. (5/27/06, MJF) + +unix/os/zzepro.c + Fixed a bug in the FPE handling (7/26/06, MJF) + +sys/etc/syserr.x + Increased the SZ_ERRMSG from 80 to SZ_LINE for longer system error + messages (e.g. full paths to files). (8/15/06, MJF) + +pkg/images/imutil/hselect.par +pkg/images/imutil/src/hselect.x +pkg/images/imutil/doc/hselect.hlp + Added a 'missing' parameter to be used when keywords isn't in header + (8/15/06, MJF) + +unix/hlib/zzsetenv.def + Made 'fits' the default 'imtype' (8/17/06) + +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/glib/login.cl + Updated version and date to V2.13-BETA3 on 'August 2006' (8/18/06) + +local/bugs.log + Updated to latest version (8/18/06) + +============================================== +V2.13 Third Beta Release (8/18/06) (for NVOSS) +============================================== + +local/bugs.log + Updated to latest version (11/22/06) + + + +============================================== +V2.14 System Merge Notes -- Aug 23, 2007 +============================================== + +pkg/lists/raverage.cl + +pkg/lists/doc/raverage.hlp + +pkg/lists/lists.cl +pkg/lists/lists.men +pkg/lists/lists.hd + Added a new running average task. (5/4/07, Valdes) + +pkg/proto/t_imext.x + Removed supporting procedures which are now in the xtools library + in the file xtextns. + (3/20/07, Valdes) + +pkg/xtools/catquery/cqgfields.x + The documentation says that the offset field in the catalog description + file for simple text is the field number. However, the implementation + did not work this way. The changes makes the catalog parsing work as + described. (7/17/07, Valdes) + +pkg/xtools/xtextns.x + +pkg/xtools/doc/xtextns.hlp + +pkg/xtools/doc/xtools.hd +pkg/xtools/mkpkg + Routines for expanding MEF image extensions. The first version of + this functionality was developed for proto.imextensions and then + expanded for mscred.mscextensions. Since then these routines have + been used in other tasks and so these are now being escalated to + generic xtools routines. (3/20/07, Valdes) + +pkg/xtools/xtmaskname.x +pkg/xtools/doc/xtmaskname.hlp + +pkg/xtools/doc/xtools.hd + The case where masktype=pl and the input name doesn't have a .pl + extension was wrong. (3/19/07, Valdes) + +pkg/xtools/fixpix/ytfixpix.x + + This version uses an internal copy of the input mask rather than + modifying the input mask. (3/19/07, Valdes) + +pkg/xtools/fixpix/xtpmmap.x +pkg/xtools/fixpix/ytpmmap.x + +pkg/xtools/fixpix/mkpkg +pkg/xtools/doc/xtpmmap.hlp + +pkg/xtools/doc/xtools.hd + 1. Uses xt_maskname to handle mask names. + 2. Minor bug fixes. + 3. The xt_ and yt_ versions are the same but the yt_version is + present to allow external packages to check for the presence + of ytpmmap.x and if not present use their own copy of the file. + This allows these packages to be compiled with earlier versions. + Eventually the yt versions should be obsoleted. + (3/19/07, Valdes) + + +pkg/images/tv/display/maskcolor.x +pkg/images/tv/display/t_display.x +pkg/images/tv/display/ace.h +pkg/images/tv/display/mkpkg +pkg/images/tv/doc/display.hlp + The overlay colors may now be set with expressions as well as with + the earlier syntax. (8/16/07, Valdes) + + +pkg/images/tv/imedit/bpmedit.cl + +pkg/images/tv/doc/bpmedit.hlp + +pkg/images/tv/imedit/bpmedit.key + +pkg/images/tv/tv.cl +pkg/images/tv/tv.hd + A new script task for editing masks using imedit as the editing + engine was added. (8/9/07, Valdes) + +pkg/images/tv/imedit/t_imedit.x +pkg/images/tv/imedit/epgcur.x +pkg/images/tv/imedit/epreplace.gx + +pkg/images/tv/imedit/imedit.key + +pkg/images/tv/doc/imedit.hlp +pkg/images/tv/mkpkg +pkg/images/tv/tv.cl + 1. A new option to do vector constant replacement was added. This is + particularly useful for editing bad pixel masks. + 2. New options '=', '<', and '>' to replace all pixels with values + ==, <=, or >= to the value at the cursor with the constant value + was added. This is useful for editing object masks. + 3. The '?' help page is now set by an environment variable rather than + hardcoded to a file in lib$src. The environment variable is + imedit_help and is set in tv.cl to point to the file in the + source directory. + (8/9/07, Valdes) + +pkg/images/tv/display/maskcolor.x + There was an error that failed to parse the color string as required. + (8/10/07, Valdes) + +pkg/images/tv/display/sigm2.x + Buffers were allocated as TY_SHORT but used and TY_INT. (8/9/07, Valdes) + +pkg/images/tv/display/t_display.x +pkg/images/tv/display/maskcolors.x +pkg/images/tv/display/sigl2.x +pkg/images/tv/display/sigm2.x +pkg/images/tv/doc/display.x + 1. Overlay masks are now read as integer to preserve dynamic range. + 2. Mapped color values less than 0 are transparent. + 3. A color name of transparent is allowed. + (4/10/07, Valdes) + + +============================================== +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed version to V2.14DEV Aug07 (8/23/07 MJF) + +dev/graphcap.inet + + Added a copy of the dev$graphcap file with inet devices explicitly + given for the imt devices. This is because systems such as Cygwin don't + support fifos or unix sockets properly and inet sockets are the only option, + but aren't part of the default connection scheme. This will be installed + as the default dev$graphcap by the install script when it is run. (8/23) + +unix/hlib/install + Added code to install dev$graphcap.inet on cygwin. (8/23) + + +unix/os/zopdir.c +unix/os/irafpath.c +unix/boot/spp/xc.c +unix/hlib/cl.csh +unix/hlib/ecl.csh +unix/hlib/fc.csh +unix/hlib/install +unix/hlib/install.old +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +unix/hlib/strip.iraf +unix/hlib/sysinfo +unix/hlib/spy.cl +unix/as.suse - +unix/bin.suse - + Removed the SuSE architecture. We're moving towards a unified + Linux architecture and the special ifdef's didn't apply here so removing + the arch was simple. In the process, found a typo in the ifdef applied + in os$zopdir.c that was fixed (8/24/07, MJF) + +dev/imtoolrc +dev/graphcap +dev/graphcap.inet + Added new frame buffers for 10K, 11K and 12K sizes at imt55, + imt56, imt57 respectively. These can exceed the 32-bit limit but are + needed for ultra-large-format detectors when using DS9. (10/29/07, MJF) + +dev/graphcap +dev/graphcap.inet + In the process of the above changes, noticed an error in the + imt46 entry (full-frame GMOS) that would have prevented the config + from working. (10/29/07, MJF) + +pkg/cl/eparam.c +pkg/cl/eparam.c + Modified the ":r" key in eparam so that if it is used as ":r! file.par" + the parameters will be updated to disk automatically. This allows a + parameter file to be read in for editing and executed immediately with a + ":go". Otherwise, the parameters are simply read in for editing and must + be explicitly written back to the pfile to be used (current behavior). + (11/12/07, MJF) + +unix/hlib/mkiraf.csh + Added a check in the mkiraf.csh script that the imdir$ directory + exists and is writable to prevent orphaned imh images from being + created. If there is a problem with the imdir$ defined by the system + install, HDR is used instead. (11/12/07, MJF). + +unix/gdev/sgidev/sgi2uapl.c + Modified the Postscript init string to be '%!PS-Adobe-2.0' since + many newer printers still complain about just '%!PS' and don't recognize + the file (11/12/07, MJF). + +sys/imio/iki/zfiofxf.x + Added code to support scaled -64 data type on read. BSCALE and BZERO + will be read and data will be scaled before making it available to the + upper level code. Writing scaled -64 is not supported. (11/12/07 NZ) + +sys/imio/iki/fxfrfits.x + Close 'spool' file descriptor before calling syserrs. (line 451) + This was causing problems when reading BINTABLE extensions. (11/12/07, NZ) + +sys/imio/dbc + +sys/imio/mkpkg + Installed the 'dbc' routines from the FITSUTIL package. This is an + extension to the imgead header database routines that allow for a + comment field to be created/manipulated in the header. (11/14/07, NZ/MJF) + +pkg/xtools/mef + +pkg/xtools/mkpkg + Installed the 'mef' library from the FITSUTIL package for doing + general MEF manipulation. This will remove the dependency on FITSUTIL + from several external packages. (11/14/07, NZ/MJF) + +unix/os/zzstrt.c + Somehow in the porting process, the default FPE flag for linux was + changed from 0x332 to 0x336 and effetively disabled the FPE traps. + Restored the old value. (11/14/07, MJF) + +unix/hlib/libc/stdarg.h +unix/hlib/libc/stdarg-linux.h + + Added some extra code for compiling the stdarg.h stuff on newer GCC + compilers. We don't use this (yet) on tucana, but it's needed for e.g. + building the CL on newer systems. (11/17/07, MJF) + +sys/imio/imloop.x + An earlier change to this procedure broke the case where the increment + was negative. Changed the code to handle this case properly (11/25/07 MJF) + +unix/boot/spp/xc.c + There remains an unexplained optimizer bug in the system which has + the effect of disabling FPE handling on Mac Intel/PPC systems. For the + moment, the optimization on these platforms was disabled until this is + better understood or fixed in future GCC versions. Quick benchmarks + indicate a performance penalty of only ~6-7%, optimized binaries for those + willing to skip the exception handling will be made available as an option. + (11/30/07, MJF) + + + +-------------------------------------------------------- +System Frozen for V2.14 Builds (11/30/07) + +unix/hlib/motd + Updated the motd file for the release (11/30/07 MJF) + +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed version to V2.14 Nov07 (11/30/07 MJF) + + +Begin sysgen.....11/30/07 + +unix/boot/bootlib/ostime.c + Apparently this function hasn't been updated in a while and the + computation of the time zone wasn't compiling correctly. Affected the + linking of WTAR only and so went unnoticed. (11/30/07) + +unix/hlib/mkpkg.sf.LNUX + Increased the number of allowed symbols to 3072 from 2048 for + the LNUX architecture compile of fmtio$evvexpr.x (11/30/07) + +noao/rv/mkpkg +noao/rv/t_fxcor.x +noao/rv/rvimutil.x + Removed an unneeded include from these files. On Cygwin + there is an outstanding problem withe processing of multi-line macros + and rather than put these files on a special-files list, I simlply + removed the include statement (12/1/07) + +-------------------------------------------------------- diff --git a/doc/notes.v214 b/doc/notes.v214 new file mode 100644 index 00000000..3e12afc2 --- /dev/null +++ b/doc/notes.v214 @@ -0,0 +1,1645 @@ +System Notes File for IRAF Version 2.14. +Begun with V2.14 code freeze 03 Dec 2007. +------------------------------------------- + +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed version to V2.14DEV Dec2007 (12/07/07 MJF) + + +pkg/images/immatch/src/geometry/t_geomap.gx + Changed the output precision of the rotation angles from 3 to 5 + decimal places. (1/14/08, MJF) + +unix/os/gmttolst.c + On MacOSX systems the GMT offset includes the DST if it is in effect + and so added an ifdef so it wasn't added an extra time. This was causing + the time in Chile to be off by an hour as of this fix (i.e. DST in effect + in Chile) (1/14/08, MJF) + +sys/imio/imloop.x + Earlier changes to this routine were only partially correct and + fail for the case of a 1-D image section by truncating the last two + pixels of the section. This caused "black stripes" in e.g. XREGISTER + or otherwise bogus pixel values that lead in some cases to FPE errors. + This version is the latest one believed to be correct, note that because + of the scope of the problem a new set of binaries needed to be released + for V2.14. (1/14/08, MJF) + +pkg/xtools/inlfit/innlinit.gx + Removed an extra argument from the nlfree$t() call (1/16/08, MJF) + +images/lib/rgtransform.x +image/immatch/src/listmatch/t_xyxymatch.x + Changed the name of the rg_intersect() function to rg_intersection() + to avoid a possible conflict with an xtools procedure of the same + name. (1/16/08, MJF) + +images/tv/display/zzdebug.x + Added missing argument to sigl2_setup() call (1/16/08, MJF) + +images/tv/wcslab/wcslab.x + Pointer arrays were being allocated with TY_BOOL, changed to TY_INT + (1/16/08, MJF) + +sys/pmio/pmglp.gx + Removed extra argument from pl_pixrop$t() call (1/16/08, MJF) + +sys/fmtio/evexpr.y + Removed extra arguments to aclrc() calls (1/16/08, MJF) + +pkg/plot/crtpict/t_crtpict.x + Added missing argument to gscan() call (1/17/08, MJF) + +pkg/data/import/t_import.x +pkg/images/imcoords/src/t_ccmap.x +pkg/images/immatch/src/psfmatch/rgpsfm.x +pkg/images/imutil/src/t_imtile.x +pkg/images/tv/imexamine/t_imexam.x +pkg/proto/t_bscale.x +pkg/system/help/helpdir.x +sys/plio/placcess.x +sys/imio/iki/fxf/fxfrfits.x +sys/imio/iki/fxf/fxfupdhdr.x + Fixed various procedure type declaration problems (1/21/08, MJF) + +sys/imio/iki/fxf/fxfcache.com + Moved the rf_time/rf_mtime arrays to a separate common to avoid alignment + problems on 64-bit compilers (1/21/08, MJF) + +sys/imfort/mii.x +sys/imfort/imrdhdr.x +sys/imfort/imwrhdr.x + Prefixed the MII procedures with a 'i_' to avoid a potential clash with + the etc$ version of the procedures. (1/21/08, MJF) + +unix/boot/spp/xc.c + Fixed a typo in a variable name used for Sun (1/23/08, MJF) + +pkg/images/imcoords/src/t_ccfind.x + When using a ZPN projection, the transform code in mwcs tries to + reference the parent image to get the PV matrix keywords. This task + called sk_decwcs() to open the WCS, but for an image it then unmapped + the image. When the task later uses the 'mw' pointer to transform coords + the ZPN reference to the parent image is invalid and results in a + segfault. Changed the code to call sk_decim() directly and operate on + the currently open image instead. (1/23/08, MJF) + +pkg/dataio/doc/export.hlp +pkg/dataio/doc/import.hlp +pkg/dataio/doc/rcardimage.hlp +pkg/dataio/doc/reblock.hlp +pkg/dataio/doc/rtextimage.hlp +pkg/dataio/doc/t2d.hlp +pkg/dataio/doc/wfits.hlp +pkg/dataio/doc/export.hlp +pkg/dataio/doc/import.hlp +pkg/dataio/doc/rcardimage.hlp +pkg/dataio/doc/reblock.hlp +pkg/dataio/doc/rtextimage.hlp +pkg/dataio/doc/t2d.hlp +pkg/dataio/doc/wfits.hlp +pkg/language/doc/chdir.hlp +pkg/language/doc/cursors.hlp +pkg/language/doc/eparam.hlp +pkg/language/doc/error.hlp +pkg/language/doc/flprcache.hlp +pkg/language/doc/for.hlp +pkg/language/doc/intro.hlp +pkg/language/doc/next.hlp +pkg/language/doc/package.hlp +pkg/language/doc/prcache.hlp +pkg/language/doc/proc.hlp +pkg/language/doc/scan.hlp +pkg/language/doc/set.hlp +pkg/language/doc/strings.hlp +pkg/language/doc/stty.hlp +pkg/language/doc/switch.hlp +pkg/language/doc/unlearn.hlp +pkg/language/doc/update.hlp +pkg/language/doc/which.hlp +pkg/lists/doc/Lcalc.hlp +pkg/lists/doc/raverage.hlp +pkg/lists/doc/rgcursor.hlp +pkg/lists/doc/unique.hlp +pkg/plot/doc/contour.hlp +pkg/plot/doc/crtpict.hlp +pkg/plot/doc/gkidecode.hlp +pkg/plot/doc/graph.hlp +pkg/plot/doc/hafton.hlp +pkg/plot/doc/implot.hlp +pkg/plot/doc/pcol.hlp +pkg/plot/doc/pcols.hlp +pkg/plot/doc/phistogram.hlp +pkg/plot/doc/prow.hlp +pkg/plot/doc/prows.hlp +pkg/plot/doc/pvector.hlp +pkg/plot/doc/sgidecode.hlp +pkg/plot/doc/sgikern.hlp +pkg/plot/doc/showcap.hlp +pkg/plot/doc/surface.hlp +pkg/proto/doc/binfil.hlp +pkg/proto/doc/bscale.hlp +pkg/proto/doc/epix.hlp +pkg/proto/doc/fixpix.hlp +pkg/proto/doc/hfix.hlp +pkg/proto/doc/imalign.hlp +pkg/proto/doc/imcentroid.hlp +pkg/proto/doc/imextensions.hlp +pkg/proto/doc/imfunction.hlp +pkg/proto/doc/imreplace.hlp +pkg/proto/doc/mimstat.hlp +pkg/proto/doc/mskregions.hlp +pkg/proto/doc/rskysub.hlp +pkg/proto/doc/suntoiraf.hlp +pkg/proto/doc/wcsedit.hlp +pkg/proto/doc/wcsreset.hlp + Checked in numerous spelling corrections found by Jason Quinn using + automated tools (2/5/08, MJF) + +sys/mwcs/mwc2tran.gx +sys/mwcs/mwltran.gx +sys/mwcs/mwv2tran.gx + Allow the input and output vectors to be the same for a linear rotated + tranformation. Since other transformations allow this and it was + not clear what should be allowed this change is put in for protection. + In fact at least one bug is attributed to this mistake so this change + is to catch cases which may be undiagnosed in other applications. + (2/12/08, Valdes) + +math/gsurfit/gs_deval.gx +math/iminterp/mrider.x +math/iminterp/mrieval.x +pkg/images/immatch/src/imcombine/t_imcombine.x +pkg/images/tv/imexamine/ievimexam.x +pkg/plot/t_pvector.x +pkg/dataio/import/iplistpix.x +pkg/images/imutil/src/listpixels.x +noao/astcat/src/attools/atcathdr.x +noao/digiphot/apphot/fitpsf/apsffit.x +noao/digiphot/apphot/phot/apmag.x +noao/digiphot/apphot/phot/apremag.x +noao/digiphot/apphot/wphot/apwmag.x +noao/digiphot/apphot/wphot/apwremag.x +noao/digiphot/daophot/allstar/dpcache.x +noao/onedspec/odcombine/t_odcombine.x + Fixed some procedure calls being closed with a ']' instead of a ')' + (2/17/08, MJF) + +pkg/images/imutil/doc/imstack.hlp +pkg/images/imutil/doc/imheader.hlp +pkg/images/imutil/doc/sections.hlp +pkg/images/imutil/doc/imrename.hlp +pkg/images/imutil/doc/hselect.hlp +pkg/images/imutil/doc/imtile.hlp +pkg/images/imutil/doc/imexpr.hlp +pkg/images/imutil/doc/imsum.hlp +pkg/images/imutil/doc/imhistogram.hlp +pkg/images/imutil/doc/imfunction.hlp +pkg/images/imutil/doc/hedit.hlp +pkg/images/imutil/doc/imarith.hlp +pkg/images/imutil/doc/imstat.hlp +pkg/images/tv/doc/display.hlp +pkg/images/tv/doc/Tv.hlp +pkg/images/tv/doc/imexamine.hlp +pkg/images/tv/doc/tvmark.hlp +pkg/images/tv/doc/wcslab.hlp +pkg/images/tv/doc/imedit.hlp +pkg/images/tv/iis/doc/window.hlp +pkg/images/tv/iis/doc/blink.hlp +pkg/images/tv/iis/doc/ids/doc/Imdis.hlp +pkg/images/tv/iis/doc/cvl.hlp +pkg/images/tv/doc/bpmedit.hlp +pkg/images/immatch/doc/wcsmap.hlp +pkg/images/immatch/doc/xyxymatch.hlp +pkg/images/immatch/doc/psfmatch.hlp +pkg/images/immatch/doc/gregister.hlp +pkg/images/immatch/doc/skymap.hlp +pkg/images/immatch/doc/imcentroid.hlp +pkg/images/immatch/doc/geotran.hlp +pkg/images/immatch/doc/wcsxymatch.hlp +pkg/images/immatch/doc/wregister.hlp +pkg/images/immatch/doc/imcombine.hlp +pkg/images/immatch/doc/skyxymatch.hlp +pkg/images/immatch/doc/linmatch.hlp +pkg/images/immatch/doc/wcscopy.hlp +pkg/images/immatch/doc/sregister.hlp +pkg/images/immatch/doc/geoxytran.hlp +pkg/images/immatch/doc/xregister.hlp +pkg/images/immatch/doc/geomap.hlp +pkg/images/imfit/doc/fit1d.hlp +pkg/images/imfit/doc/imsurfit.hlp +pkg/images/imcoords/doc/wcsedit.hlp +pkg/images/imcoords/doc/ccget.hlp +pkg/images/imcoords/doc/mkcwwcs.hlp +pkg/images/imcoords/doc/skyctran.hlp +pkg/images/imcoords/doc/ccxymatch.hlp +pkg/images/imcoords/doc/imcctran.hlp +pkg/images/imcoords/doc/ccsetwcs.hlp +pkg/images/imcoords/doc/ccmap.hlp +pkg/images/imcoords/doc/wcsreset.hlp +pkg/images/imcoords/doc/starfind.hlp +pkg/images/imcoords/doc/ccstd.hlp +pkg/images/imcoords/doc/wcsctran.hlp +pkg/images/imcoords/doc/ccfind.hlp +pkg/images/imcoords/doc/cctran.hlp +pkg/images/imcoords/doc/mkcwcs.hlp +pkg/images/imfilter/doc/rmedian.hlp +pkg/images/imfilter/doc/rmode.hlp +pkg/images/imfilter/doc/gradient.hlp +pkg/images/imfilter/doc/boxcar.hlp +pkg/images/imfilter/doc/fmode.hlp +pkg/images/imfilter/doc/convolve.hlp +pkg/images/imfilter/doc/laplace.hlp +pkg/images/imfilter/doc/gauss.hlp +pkg/images/imfilter/doc/frmode.hlp +pkg/images/imfilter/doc/runmed.hlp +pkg/images/imgeom/doc/imshift.hlp +pkg/images/imgeom/doc/magnify.hlp +pkg/images/imgeom/doc/imlintran.hlp +pkg/images/imgeom/doc/rotate.hlp +pkg/obsolete/doc/orfits.hlp +pkg/obsolete/doc/oimcombine.hlp +pkg/obsolete/doc/owfits.hlp +pkg/softools/doc/mkttydata.hlp +pkg/softools/doc/mkmanpage.hlp +pkg/softools/doc/mktags.hlp +pkg/system/doc/head.hlp +pkg/system/doc/type.hlp +pkg/system/doc/diskspace.hlp +pkg/system/doc/gripes.hlp +pkg/system/doc/devstatus.hlp +pkg/system/doc/Sys.hlp +pkg/system/doc/files.hlp +pkg/system/doc/Sys_intro.hlp +pkg/system/doc/help.hlp +pkg/system/doc/news.hlp +pkg/system/doc/lprint.hlp +pkg/system/doc/references.hlp +pkg/utilities/doc/surfit.hlp +pkg/utilities/doc/urand.hlp +pkg/utilities/doc/split.hlp +pkg/utilities/doc/polyfit.hlp +pkg/xtools/doc/xtpmmap.hlp +pkg/xtools/doc/inlfit.hlp +pkg/xtools/doc/center1d.hlp +pkg/xtools/doc/ranges.hlp +pkg/xtools/doc/xtextns.hlp +$iraf/doc/doc/expressions.hlp +$iraf/doc/doc/spp83.hlp +$iraf/doc/doc/pkg84.hlp +$iraf/doc/doc/news.v28.hlp +$iraf/doc/doc/biblio84.hlp +$iraf/doc/doc/crib83.hlp +$iraf/doc/packages.hlp +$iraf/doc/news.v29.hlp +$iraf/doc/vmsprog.hlp +$iraf/doc/vmsiraf.hlp +$iraf/doc/aosvsiraf.hlp +$iraf/doc/news.old.hlp +$iraf/doc/v211revs.hlp +$iraf/doc/suniraf.hlp +$iraf/doc/unixiraf.hlp +$iraf/doc/pac_toc.hlp +$iraf/doc/v212revs.hlp +$iraf/doc/spp_toc.hlp + Another batch of documentation fixes from Jason Quinn. The + IMCOMBINE help was modified more recently and merged by hand. + (2/18/08 MJF) + +unix/os/mkpkg.sh + The architecture test was being done with '==' instead of '=' (4/16/08, MJF) + +unix/boot/bootlib/ostime.c + Modified to support timezones on Solaris x86. (2/19/08, MJF) + +unix/boot/spp/xc.c + Fixed a missing '#else' to compile for Solaris x86 (2/19/08, MJF) + +unix/hlib/libc/stdarg.h +unix/hlib/libc/stdarg-solaris.h + + Changes needed for Solaris x86 (2/19/08, MJF) + +sys/plio/mkpkg +sys/plio/plbox.x +sys/plio/plbox.h + +sys/plio/plubox.x + +sys/plio/plcircle.x +sys/plio/plcircle.h + +sys/plio/plucircle.x + +sys/plio/plpolygon.x +sys/plio/plpolygon.h + +sys/plio/plupolygon.x + +sys/tty/mkpkg +sys/tty/ttygdes.x +sys/tty/gttyload.x + +pkg/images/imutil/src/mkpkg +pkg/images/imutil/src/imexpr.x +pkg/images/imutil/src/iegsym.x + +pkg/proto/maskexpr/mkpkg +pkg/proto/maskexpr/peregfuncs.x +pkg/proto/maskexpr/peregfuncs.h + +pkg/proto/maskexpr/peregufcn.x + +pkg/proto/maskexpr/mskexpand.x +pkg/proto/maskexpr/megsym.x + +pkg/softools/mkpkg +pkg/softools/mktags.x +pkg/softools/tgutil.x + + Broke out functions used as extern to separate files. GCC 3.4.3 cannot + compile these files because of a bug that see 'extern int func()' and + 'int func()' as different types. (2/20/08, MJF) + +unix/bin.sunos/f2c.h + In the end the above changes weren't strictly required. A workaround + is to equivalence the 'int' and 'integer' types in the f2c.h file as + was done (but never documented) for the Cygwin port. For things like + the fmtio$evexpr.y file it wasn't possible to break out the gettok() + to a new file since it returned values generated by macros written + during the xyacc stage. (2/20/08, MJF) + +unix/hlib/install + Fixed a typo where 'copy' command should be 'cp' (2/20/08, MJF) + +pkg/ecl/gram.c +pkg/ecl/operand.h +pkg/ecl/binop.c + Implemented a new strdic(str,dicstr) builtin function. The first character + of 'dicstr' will be used as a delimiter to define a dictionary string, i.e. + a set of string values like "|foo|bar|rab|oof|". The function returns + the index of the 'str' that occurs in the dictionary, or zero if not + found. 'str' may be a substring of the dictionary string for a match + to be made. For example + + cl> =strdic ("bar", "|foo|bar|rab|oof|") + 2 + cl> s1 = "FOO" + cl> =strdic (strlwr(s1), "|foo|bar|rab|oof|") + 1 + + The second example shows how to do a case-insensitive match against + the dictionary. (3/12/08, MJF) + +pkg/ecl/binop.c + Fixed a bug in strstr() where a call like strstr("th","testthis") + would fail to find the string. Pointer was being incremented incorrectly. + (4/3/08, MJF) + + +sys/imfort/mii.x + An earlier change to this file to clarify procedure names inadvertantly + added the prefix the MII routines in the osb$ directory, leading to + unresolved references when actually linking a program (4/16/08, MJF) + +unix/hlib/clpackage.men +sys/fmtio/doc/fmtio.men +pkg/obsolete/obsolete.men +pkg/xtools/skywcs/doc/skywcs.men +pkg/xtools/doc/xtools.men +pkg/lists/lists.men +pkg/language/language.men +pkg/images/immatch/immatch.men +noao/artdata/mkexamples/onedspec.men +noao/onedspec/onedspec.men +noao/imred/argus/demos/demos.men +noao/imred/ctioslit/demos/demos.men +noao/imred/echelle/demos/demos.men +noao/imred/hydra/demos/demos.men +noao/imred/kpnocoude/demos/demos.men +noao/imred/kpnoslit/demos/demos.men +noao/twodspec/longslit/demos/demos.men +noao/imred/quadred/quadred.men +noao/imred/iids/iids.men +noao/imred/iids/irs.men +noao/imred/irs/irs.men +noao/artdata/mkexamples/onedspec.men +noao/onedspec/onedspec.men +noao/digiphot/photcal/photcal.men +noao/astutil/astutil.men +noao/astcat/astcat.men +noao/imred/specred/specred.men + Fixed some typos in help menus found by Jason Quinn (4/20/08, MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + Added some additional errchks (5/12/08, NZ/MJF) + +sys/ki/ki.com + Increased the size of SZ_SBUF from 255 to 1023 to permit more string + storage in instructions using long pathnames. (5/13/08, MJF) + +sys/ki/ki.com + Backed out of the change. (5/14/08, MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + Modified to use a shorter temp file name as a workaround to some pipeline + problems caused by long KI pathnames. (5/14/08, NZ/MJF) + +sys/imio/iki/fxf/fxfupdhdr.x + Fixed a problem affecting the number of pad lines corrupting images. + (5/23/08, NZ/MJF) + +pkg/cl/param.c +pkg/ecl/param.c + Fixed a bug in detecting ambiguous parameters (7/8/08, MJF) + +unix/boot/spp/xc.c + Forced the mode of a binary to be 0755 to avoid the problem on some + linux systems where binaries aren't group/world readable by default + (7/31/08, MJF) + +pkg/plot/hgpline.x + +pkg/plot/t_prows.x +pkg/plot/t_pcols.x +pkg/plot/t_graph.x +pkg/plot/t_pvector.x +pkg/plot/initmarker.x +pkg/plot/mkpkg +pkg/plot/graph.par +pkg/plot/pcol.par +pkg/plot/pcols.par +pkg/plot/prow.par +pkg/plot/prows.par +pkg/plot/pvector.par +pkg/plot/doc/graph.hlp +pkg/plot/doc/prow.hlp +pkg/plot/doc/prows.hlp +pkg/plot/doc/pcol.hlp +pkg/plot/doc/pcols.hlp +pkg/plot/doc/pvector.hlp + Added a feature where marker types of "lhist" or "bhist" draw line + or box histograms when not in point mode. In point mode these + values default to box and when not in point mode any other value + defaults to connected lines. (8/13/08, Valdes) + +sys/imio/iki/fxfopix.x +sys/imio/iki/fxfupdhdr.x + Changes to the header updates of temporary files. Related to earlier + fixes made for padlines problems and long KI filenames (8/13/08, Valdes) + +pkg/bench/bench.hlp +images/immatch/doc/geomap.hlp +images/immatch/doc/geotran.hlp +noao/digiphot/apphot/doc/center.hlp +noao/digiphot/apphot/doc/centerpars.hlp +noao/digiphot/apphot/doc/daofind.hlp +noao/digiphot/apphot/doc/datapars.hlp +noao/digiphot/apphot/doc/fitpsf.hlp +noao/digiphot/apphot/doc/fitsky.hlp +noao/digiphot/apphot/doc/fitskypars.hlp +noao/digiphot/apphot/doc/pexamine.hlp +noao/digiphot/apphot/doc/phot.hlp +noao/digiphot/apphot/doc/polymark.hlp +noao/digiphot/apphot/doc/polyphot.hlp +noao/digiphot/apphot/doc/qphot.hlp +noao/digiphot/apphot/doc/radprof.hlp +noao/digiphot/apphot/doc/ucache.hlp +noao/digiphot/apphot/doc/wphot.hlp +noao/digiphot/daophot/doc/addstar.hlp +noao/digiphot/daophot/doc/allstar.hlp +noao/digiphot/daophot/doc/centerpars.hlp +noao/digiphot/daophot/doc/daoedit.hlp +noao/digiphot/daophot/doc/daofind.hlp +noao/digiphot/daophot/doc/daopars.hlp +noao/digiphot/daophot/doc/daotest.hlp +noao/digiphot/daophot/doc/datapars.hlp +noao/digiphot/daophot/doc/group.hlp +noao/digiphot/daophot/doc/grpselect.hlp +noao/digiphot/daophot/doc/nstar.hlp +noao/digiphot/daophot/doc/peak.hlp +noao/digiphot/daophot/doc/pexamine.hlp +noao/digiphot/daophot/doc/phot.hlp +noao/digiphot/daophot/doc/psf.hlp +noao/digiphot/daophot/doc/pstselect.hlp +noao/digiphot/daophot/doc/substar.hlp +noao/digiphot/photcal/doc/apfile.hlp +noao/digiphot/photcal/doc/config.hlp +noao/digiphot/photcal/doc/evalfit.hlp +noao/digiphot/photcal/doc/fitparams.hlp +noao/digiphot/photcal/doc/inlfit.hlp +noao/digiphot/photcal/doc/invertfit.hlp +noao/digiphot/photcal/doc/mkapfile.hlp +noao/digiphot/photcal/doc/mkcatalog.hlp +noao/digiphot/photcal/doc/mkconfig.hlp +noao/digiphot/photcal/doc/mkimsets.hlp +noao/digiphot/photcal/doc/mknobsfile.hlp +noao/digiphot/photcal/doc/mkobsfile.hlp +noao/digiphot/photcal/doc/mkphotcors.hlp +noao/digiphot/photcal/doc/obsfile.hlp +noao/digiphot/photcal/doc/pcintro.hlp +noao/digiphot/ptools/doc/pconvert.hlp +noao/digiphot/ptools/doc/pdump.hlp +noao/digiphot/ptools/doc/pexamine.hlp +noao/digiphot/ptools/doc/pselect.hlp +noao/digiphot/ptools/doc/pttest.hlp +noao/digiphot/ptools/doc/tbselect.hlp +noao/digiphot/ptools/doc/tbsort.hlp +noao/digiphot/ptools/doc/txselect.hlp +noao/artdata/doc/gallist.hlp +noao/artdata/doc/mk1dspec.hlp +noao/artdata/doc/mk2dspec.hlp +noao/artdata/doc/mkechelle.hlp +noao/artdata/doc/mkexamples.hlp +noao/artdata/doc/mknoise.hlp +noao/artdata/doc/mkobjects.hlp +noao/artdata/doc/mkpattern.hlp +noao/artdata/doc/starlist.hlp +noao/astcat/doc/aslist.hlp +noao/astcat/doc/aimfind.hlp +noao/astcat/doc/ahedit.hlp +noao/astcat/doc/agetim.hlp +noao/astcat/doc/agetcat.hlp +noao/astcat/doc/afiltpars.hlp +noao/astcat/doc/adumpim.hlp +noao/astcat/doc/acatpars.hlp +noao/astutil/doc/astcalc.hlp +noao/astutil/doc/asthedit.hlp +noao/astutil/doc/asttimes.hlp +noao/astutil/doc/ccdtime.hlp +noao/astutil/doc/galactic.hlp +noao/astutil/doc/gratings.hlp +noao/astutil/doc/keywpars.hlp +noao/astutil/doc/obs.hlp +noao/astutil/doc/pdm.hlp +noao/astutil/doc/rvcorrect.hlp +noao/astutil/doc/setairmass.hlp +noao/astutil/doc/setjd.hlp + More documentation typo corrections from Jason Quinn (8/18/08, MJF) + +pkg/images/x_images.x +pkg/images/imutil/imutil.cl +pkg/images/imutil/imutil.hd +pkg/images/imutil/imutil.men +pkg/images/imutil/nhedit.par + +pkg/images/imutil/doc/nhedit.hlp + +pkg/images/imutil/src/nhedit.x + +pkg/images/imutil/src/getcmd.x + +pkg/images/imutil/src/mkpkg + Installed the NHEDIT task (HEDIT with comments) (8/19/08, MJF) + +unix/hlib/irafuser.csh + Added a -DPOSIX to HSI_CF for freebsd systems (8/19/08, MJF) + +unix/os/zgtime.c + Had to ifdef the type declaration of time() to be compatible w/ + FreeBSD 6.3 (8/19/08, MJF) + +unix/os/zfioks.c + FreeBSD doesn't define IPPORT_USERRESERVED (8/19/08, MJF) + +unix/hlib/libc/stdarg.h +unix/hlib/libc/stdarg-freebsd.h + + Usual varargs fun for the FreeBSD build (8/19/08, MJF) + +local/notes.v212 + Moved the the $iraf/doc directory (8/19/08, MJF) + +unix/hlib/buglog.csh + Fixed the script to once again worl (8/22/08, MJF) + +unix/hlib/motd +unix/hlib/zzsetenv.def +unix/hlib/login.cl +pkg/cl/cl.par +pkg/ecl/cl.par + Changed version to V2.14.1 (9/8/08) + +pkg/ecl/errs.c +pkg/ecl/builtin.c +pkg/ecl/clmodes.h + Added a 'beep' capability to the 'erract' variable (9/8/08, MJF) + +unix/boot/mkpkg/scanlib.c + Initialized a variable to fix a problem on FreeBSD systems where + garbage was causing library files to be read incorrectly. (9/8/09, MJF) + +pkg/ecl/mkpkg + Fixed a problem for 'sparc' systems in doing a 'mkpkg update) (9/15/08, MJF) + +------------------------------------------------------ +System Frozen for V2.14.1 Patch (9/15/08) +------------------------------------------------------ + +fio/fmkbfs.x +imio/iki/fxf/fxfopen.x + Added error checks to catch and pass on error in memory allocation + (basically MFULL). (10/15/08, Valdes) + +unix/os/zmaloc.c +unix/os/zraloc.c + Added check for negative IRAF pointer. + (10/23/08, Valdes) + +sys/plio/plcmpress.x +sys/plio/plupdate.x + Extra checking for a null pointer which might occur when memory + allocation fails (memory full). (10/23/08, Valdes) + +sys/imio/iki/fxf/fxfplread.x + The heuristic to determine whether the earlier (incorrect) byte + size was used was wrong. This heuristic gives a wrong answer with + very small or sparse masks. (10/28/08, Valdes) + +lib/pkg/rmsorted.h +pkg/xtools/rmmed.x +pkg/xtools/rmsorted.x +pkg/images/imfilter/src/runmed.x + Modified the running median library to allow running minimum and + running maximum. An argument addition required a change in the + runmed task but there was no functional change. The files are noted + here because of the include file being in a system directory. + (10/29/08, Valdes) + +sys/fmtio/evvexpr.x + The checking for compatible datatypes for mod, min, max, and median + functions used the argument pointer rather than the dereferenced + operand type resuling in an "incompatible types" error message. + (11/3/08, Valdes) + +sys/ki/kfmkcp.x + The set of combinations of from and to files did not include a case + where both files are remote (e.g. from node A do "move B!file C!file"). + This would result in the error + Warning: Cannot access template file or cannot make copy file + Added the missing case which is an obvious combination of the other + cases. (12/2/08, Valdes) + +sys/gio/gki/gkiwesc.x + Fixed two calls to amovs() that were using ARB as the size for the + move instead of the hdrlen/datalen being passed in. (12/3/08, MJF) + +pkg/images/tv/imexamine/t_imexam.x + Removed some accidental code that was causing the frame number to + be prompted for. (12/4/08, MJF) + + +pkg/dataio/lib/mkpkg + The getdatatype.x and ranges.x files were duplicates of those in the + XTOOLS library which is linked in dataio. These files should be the + versions actually linked in the binary, making XTOOLS unnecessary, but + I think the intent was to use XTOOLS. The getdatatype.x is identical + but there are slight changes in ranges.x. These files were left in + place in case there are problems found but the binary should now be + using the XTOOLS versions. (12/5/08, MJF) + +pkg/language/language.hd +pkg/language/language.men +pkg/language/doc/imaccess.hlp + + Added a missing help page for the imaccess() function (12/18/08, MJF) + +sys/fmtio/ctod.x + Modified to allow a space to be used to delimit sexagesimal values. + Multiple spaces are allowed to preceed/follow the string as well as + be used between values. (2/24/09, MJF) + +sys/gio/ncarutil/conrec.f +sys/gio/ncarutil/srface.f +sys/gio/ncarutil/threed.f +sys/imio/dbc/imputextf.x + Minor changes needed to compile using G77 (2/27/09, MJF) + +sys/fmtio/ctod.x + Minor bug fix to catch case where the input value may begin with one of + the characters allowed for sexagesimal. In order to allow the function + to be used to scan values up to the first non-number character we need + need to be sure the input doesn't begin with a stop character and then try + to convert anyway. (3/18/09, MJF) + +pkg/language/doc/fprint.hlp + Minor cleanup of the help page. (3/26/09, MJF) + +pkg/ecl/param.c + Modified to allow literal strings beginning with a paren (e.g. ")" + and ") test") to be handled without the normal parameter indirection. + Also changed to allow a '\' to be used to escape indirection for strings + that begin with a paren and might otherwise be confused (3/26/09, MJF) + +pkg/language/language.hd +pkg/language/language.men +pkg/language/doc/which.hlp +pkg/language/doc/access.hlp +pkg/language/doc/defpac.hlp + Minor cleanup to provide help for whereis/defvar/imaccess (3/27/09, MJF) + +pkg/ecl/builtin.c + Fixed a segfault when trapping errors from CL functions (3/27/09, MJF) + +pkg/images/immatch/doc/xyxymatch.hlp +pkg/images/immatch/doc/geomap.hlp +pkg/images/immatch/doc/geotran.hlp +pkg/images/immatch/doc/geoxytran.hlp +pkg/images/immatch/doc/gregister.hlp + Readability corrections from Jason Quinn (4/6/09, MJF) + +noao/astcat/doc/catalogs.hlp +noao/digiphot/apphot/doc/datapars.hlp +noao/digiphot/apphot/doc/radprof.hlp +noao/digiphot/daophot/doc/addstar.hlp +noao/digiphot/daophot/doc/allstar.hlp +noao/digiphot/daophot/doc/datapars.hlp +noao/digiphot/daophot/doc/group.hlp +noao/digiphot/daophot/doc/nstar.hlp +noao/digiphot/daophot/doc/peak.hlp +noao/digiphot/daophot/doc/phot.hlp +noao/digiphot/daophot/doc/pstselect.hlp +noao/digiphot/daophot/doc/substar.hlp +noao/digiphot/ptools/doc/tbdump.hlp +noao/imred/ccdred/doc/guide.hlp +noao/imred/quadred/src/quad/doc/guide.hlp +noao/imred/vtel/doc/mscan.hlp +noao/imred/vtel/doc/rmap.hlp +noao/onedspec/doc/specwcs.hlp +pkg/images/imcoords/doc/ccxymatch.hlp +pkg/images/imfilter/doc/frmode.hlp +pkg/images/immatch/doc/linmatch.hlp +pkg/images/immatch/doc/xregistry.hlp +pkg/images/immatch/doc/imcombine.hlp +pkg/images/immatch/doc/geomap.hlp +pkg/proto/doc/mimstat.hlp +pkg/proto/doc/rskysub.hlp +pkg/xtools/catquery/doc/catalogs.hlp +pkg/xtools/skywcs/doc/skdecwstr.hlp + Fixed missing quote messing up HTML translation (4/14/09, MJF) + +pkg/images/immatch/src/linmatch/rgltools.x + Arrays were being initialized with INDEF values using amov() procedures + instead of amovk. (4/24/09, MJF) + +unix/hlib/cl.csh + Merged the Sun/IRAF and PC/IRAF cl.csh files (6/3/09, MJF) + +pkg/plot/crtpict/t_crtpict.x + Fixed a typo (open (STDIN,...) to open("STDIN", ...)) (6/23/09, MJF) + +pkg/plot/t_hafton.x +pkg/plot/crtpict/minmax.x + Fixed bad type checking on min/max value (6/23/09, MJF) + +sys/osb/f77upk.f +sys/osb/f77pak.f + Added checks that the last char never exceeds maxch (6/23/09, MJF) + +pkg/plot/t_graph.x + Fixed ggeti() calls that should be gstati() (6/25/09, MJF) + +pkg/images/imutil/src/t_imstat.x +pkg/obsolete/t_oimstat.x +pkg/proto/masks/mimstat.x + fntopnb() was being called as fntopenb() (7/1/09, MJF) + +pkg/proto/t_fixpix.x + Fixed an IS_INDEF that should be IS_INDEFI (7/8/09, MJF) + +pkg/proto/t_bscale.x + The altax() procedure was incorrectly being called with complex() + arguments when scaling a TY_COMPLEX image (7/8/09, MJF) + +pkg/proto/t_hfix.x + The imtopenp procedure was incorrectly being used as imtopnp (7/9/09, MJF) + +pkg/utilities/t_curfit.x + The arcz[rd]() procedure was being called with an error function that + had an argument rather than the function name itself. Additionally, + in the case of CF_INSTRUMENTAL a separate function was required to + explicitly return 0.0. (7/9/09, MJF) + +plg/images/immatch/src/linmatch/rglscale.x + A bounds check was incorrectly being done against the number of columns + rather than the number of lines (7/10/09, MJF) + +noao/mtlocal/cyber/t_ridsfile.x + Fixed minor error in calling procedures. (7/11/09, MJF) + +noao/imred/dtoi/hdtoi.x + The hd_fogcalc() proc was called with too few args (7/12/09, MJF) + +pkg/fmtio/evvexpr.gy + The absolute value function for a scalar was wrong. Instead of the + absolute value, the negative of the value was returned. (7/14/09, FV) + (Made change to evvexpr.gy, MJF) + +pkg/ecl/history.c + The string returned by readline() was never freed (7/15/09, MJF) + +math/bevington/chifit.f +math/bevington/curfit.f +math/bevington/fderiv.f +math/bevington/gradls.f +math/bevington/gridls.f +math/bevington/regres.f + Added 'external' declarations for the user-supplied functn() + procedure to shut up compiler warnings. (7/17/09, MJF) + +unix/boot/bootlib/osfiletype.c + Added a few extra extensions to the lists of know src/bin and made + the comparison case insensitive. (7/20/09, MJF) + +sys/fmtio/ctod.x + An earlier change to allow conversion of sexagesimal values in various + formats allowed for a space-delimited string. However, this fails when + e.g. parsing WAT keywords containing coefficients. Changed to disallow + spaces as delimiters (8/12/09, MJF) + +pkg/ecl/readline/readline.c + Fixed problem in that the readline() procedure returns malloc'd pointer + of the result, but we can't free it in the calling procedure because + libc free() is expecting an SPP pointer. Changed the routine to return + a static buffer, and free'd the pointer in the readline() procedure + itself which is compiled without iraf libc. (8/12/09, MJF) + +unix/hlib/libc/ctype.h + Modified to cast the char to int to avoid compiler warnings (8/14/09, MJF) + +sys/libc + Updated completely with a new version that uses ANSI C prototypes. Code + was also cleaned up to remove all compiler warnings. Done as part of + 64-bit port. (8/14/09, MJF) + +unix/lib/libc/libc.h + Updated with new LIBC prototype definitions. (8/14/09, MJF) + +pkg/cl/errs.c +pkg/cl/clprintf.c +pkg/ecl/errs.c +pkg/ecl/clprintf.c + Removed use of USE_STDARG ifdef's. We no longer need to support the + since all modern systems now use . (8/14/09, MJF) + +unix/hlib/libc/iraf.h +unix/hlib/libc/varargs.h - +unix/hlib/libc/varargs-bsd.h - +unix/hlib/libc/varargs-linuxppc.h - + Removed use of from the system. (8/14/09, MJF) + +noao/lib/obsdb.dat + Added entry for Lulin Observatory (Taiwan) from Mike Yang (8/19/09, MJF) + +pkg/cl/mkpkg +pkg/ecl/mkpkg + Removed extraneous dependencies. (8/25/09, MJF) + +pkg/obsolete/icstat.gx +noao/imred/ccdred/src/icstat.gx + Fixed type problems for asum() (8/25/09, MJF) + +pkg/cl/mkpkg +pkg/cl/param.h +pkg/ecl/mkpkg +pkg/ecl/param.h + Increased the SZ_MAXLIN (max param file line size) from 132 to 512. + Also removed unneeded dependencies on varargs.h from the mkpkg + (10/12/09, MJF) + +pkg/images/imfilter/src/fmedian.h +pkg/images/imfilter/src/fmedian.x +pkg/images/imfilter/src/fmode.h +pkg/images/imfilter/src/fmode.x +pkg/images/imfilter/src/frmedian.h +pkg/images/imfilter/src/frmedian.x +pkg/images/imfilter/src/frmode.h +pkg/images/imfilter/src/frmode.x +pkg/images/imfilter/src/med_buf.x +pkg/images/imfilter/src/median.h +pkg/images/imfilter/src/mode.h +pkg/images/imfilter/src/rmedian.h +pkg/images/imfilter/src/rmedian.x +pkg/images/imfilter/src/rmode.h +pkg/images/imfilter/src/rmode.x + A pointer allocated as TY_REAL was being freed as TY_INT (11/26/09, MJF) + +pkg/ecl/param.c + Backed out of earlier change that broke indirection. (12/11/09, MJF) + +pkg/images/imfit/src/fit1d.x +pkg/images/imfit/fit1d.par +pkg/images/imfit/doc/fit1d.hlp + Added a new parameter, bpm, to use a bad pixel mask to exclude data + from the fitting. (2/10/10, Valdes) + +------------------------------------------------------ +Merged 64-bit port notes (3/1/10) +------------------------------------------------------ + + +mkpkg +noao/mkpkg +local/.login +bin.linux64 + +bin.linux64/IB.LNUX.X86_64 + +noao/bin.linux64 + +noao/bin.linux64/NB.LNUX.X86_64 + +unix/as.linux64 + +unix/bin.linux64 + +unix/hlib/cl.csh +unix/hlib/fc.csh +unix/hlib/install +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.LNUX64 + +unix/hlib/strip.iraf +unix/hlib/sysinfo +unix/os/irafpath.c + Set up 'linux64' architecture dirs/paths for port, added a '-DLINUX64' + to HSI_CF. (4/20/09, MJF)) + + +bin.redhat -> bin.linux +noao/bin.redhat -> bin.linux +unix/as.redhat -> as.linux +unix/bin.redhat -> bin.linux +unix/hlib/irafuser.csh + Removed the 'redhat' directories and consolidated into a single 'linux' + architecture. In order to maintain compatability with external packages + we retain the 'redhat' architecture in paths, the idea being that an + extpkg can still use redhat, but in the core system the links resolve to + the linux directory to saisfy the path. (4/20/09, MJF) + +sys/libc/scanf.c +sys/libc/printf.c +sys/libc/eprintf.c +sys/libc/sprintf.c +pkg/cl/errs.c +pkg/cl/clprintf.c +pkg/ecl/errs.c +pkg/ecl/clprintf.c +unix/hlib/libc/stdarg.h + Removed the ifdef'd USE_STDARG code. The is no longer + routinely used and support it problematic. (7/13/09, MJF) + +unix/hlib/libc/libc.h + Declared XERPSH/XERPOP for use in all procedures. (7/13/09, MJF) + +unix/hlib/libc/ctype.h + Cast the subscripts to (int) to avoid -Wall warnings. (7/13/09, MJF) + +sys/libc + Major changes to make ANSI C and clean compile. (7/13/09, MJF) + +unix/hlib/libc.h + Added prototype declarations for libc procedure. (7/13/09, MJF) + +pkg/cl/clprintf.c +pkg/ecl/clprintf.c + Declared eprintf() void to match libc prototype. (7/13/09, MJF) + +pkg/libc/stgio.c + Added a maxch arg to c_stggetline(). This is only used in cl$modes.c + (and ecl$modes.c) and a 3rd arg is supplied. (7/13/09, MJF) + +unix/hlib/libc/kernel.h + Added , , and definition to + get system prototypes (e.g. for the glibc strcmp()) (8/14/09, MJF) + +unix/hlib/libc/iraf.h +unix/hlib/libc/varargs.h - +unix/hlib/libc/varargs-bsd.h - +unix/hlib/libc/varargs-linuxppc.h - + Removed use of from the system. (8/14/09, MJF) + +unix/bin.redhat/f2c.h +unix/hlib/libc/kproto.h +unix/hlib/libc/vosproto.h + System prototypes ....... (8/24/09, MJF) + +unix/hlib/f77.sh + Added a '-P' flag to allow F2C to produce function prototypes in + files with '.P' extensions. We'll use this in building the system + library prototype files which have changed since the last time they + were generated and are in need of automation (8/24/09, MJF) + +unix/os/zgtime.c + Modified to use more modern CLOCKS_PER_SEC vs CLK_TCK (9/23/09, MJF) + +sys/nmemio + + New version of MEMIO interface supporting pointer bounds checking. + +lib/syserr.h +lib/syserrmsg + Added new codes for pointer under and overflow. () + +unix/boot/xyacc/debug/ytab.x +noao/obsutil/src/sptime/tabinterp.x +noao/obsutil/src/sptime/grating.x +noao/imred/vtel/destreak.x +noao/artdata/t_mk2dspec.x +noao/artdata/mktemplates.x +noao/onedspec/t_sapertures.x +noao/onedspec/t_tweak.x +noao/onedspec/dispcor/dcio.x +pkg/lists/lintran.x +pkg/images/imutil/src/imexpr.x +pkg/images/tv/display/imdwcs.x +pkg/images/tv/wcslab/wlutil.x +pkg/images/tv/wcslab/wllabel.x +pkg/images/tv/wcslab/wlwcslab.x +pkg/images/immatch/src/listmatch/t_imctroid.x +pkg/xtools/rmmed.x +pkg/xtools/rmturlach.x +pkg/xtools/rngranges.x +pkg/bench/xctest/lintran.x +sys/nmemio/zzfoo.x +sys/qpoe/zzdebug.x +sys/qpoe/gen/qpexcoder.x +sys/qpoe/gen/qpexparser.x +sys/qpoe/qpmacro.x +math/curfit/cverrorsr.x +math/nlfit/nlerrorsr.x +math/iminterp/asifit.x +math/gsurfit/gserrorsr.x + Modified to add P2R/P2P macros on Memr as neded. + +tables/lib/stxtools/xtwcs.x +tables/lib/stxtools/sp_util/sprote.x +tables/lib/stxtools/wcslab/wllabel.x +tables/lib/stxtools/wcslab/wlwcslab.x +tables/pkg/tbplot/igi/igi.h +tables/pkg/fitsio/stwfits/wfits.h +tables/pkg/fitsio/strfits/rfits.h +tables/pkg/tobsolete/r49fits/rfits.h +tables/lib/stxtools/wcslab/wcs_desc.h +tables/lib/gilib/gi.h + Modified to add P2R/P2P macros on Memr as neded. + +./noao/mtlocal/cyber/rrcopy/rrcopy.h +./noao/mtlocal/cyber/cyber.h +./noao/obsutil/src/starfocus/starfocus.h +./noao/obsutil/src/sptime/sptime.h +./noao/obsutil/src/specfocus/specfocus.h +./noao/imred/ccdred/src/ccdred.h +./noao/imred/ccdred/src/generic/ccdred.h +./noao/imred/quadred/src/ccdproc/ccdred.h +./noao/imred/quadred/src/ccdproc/generic/ccdred.h +./noao/imred/vtel/numeric.h +./noao/imred/dtoi/hdicfit/hdicfit.h +./noao/artdata/lists/starlist.h +./noao/digiphot/photcal/lib/obsfile.h +./noao/digiphot/photcal/lib/prstruct.h +./noao/digiphot/photcal/lib/lexer.h +./noao/digiphot/photcal/lib/apfile.h +./noao/digiphot/daophot/lib/psfdef.h +./noao/digiphot/daophot/lib/daophotdef.h +./noao/digiphot/apphot/lib/radprofdef.h +./noao/digiphot/apphot/lib/fitpsfdef.h +./noao/digiphot/apphot/lib/finddef.h +./noao/digiphot/apphot/lib/polyphotdef.h +./noao/digiphot/apphot/lib/noisedef.h +./noao/digiphot/apphot/lib/centerdef.h +./noao/digiphot/apphot/lib/photdef.h +./noao/digiphot/apphot/lib/fitskydef.h +./noao/digiphot/apphot/lib/apphotdef.h +./noao/rv/rvplots.h +./noao/rv/rvidlines/identify.h +./noao/rv/rvsample.h +./noao/rv/rvpackage.h +./noao/rv/rvcont.h +./noao/astcat/lib/aimparsdef.h +./noao/astutil/pdm/pdm.h +./noao/nproto/ace/acesky.h +./noao/nproto/ace/cat.h +./noao/nproto/ace/gwindow.h +./noao/nproto/ace/ace.h +./noao/nproto/ace/skyfit.h +./noao/nproto/ace/grow.h +./noao/nproto/ace/split.h +./noao/nproto/ace/detect.h +./noao/nproto/ace/objs.h +./noao/nproto/ace/skyblock.h +./noao/nproto/ir/iralign.h +./noao/onedspec/specplot.h +./noao/onedspec/irsiids/idsmtn.h +./noao/onedspec/ecidentify/ecidentify.h +./noao/onedspec/identify/autoid/autoid.h +./noao/onedspec/identify/identify.h +./noao/onedspec/sensfunc/sensfunc.h +./noao/onedspec/dispcor/dispcor.h +./noao/lib/smw.h +./noao/lib/units.h +./noao/lib/funits.h +./noao/twodspec/multispec/ms.h +./noao/twodspec/apextract/apertures.h +./pkg/obsolete/oimstat.h +./pkg/obsolete/fits/wfits.h +./pkg/images/imutil/src/imtile.h +./pkg/images/imutil/src/imstat.h +./pkg/images/imfit/src/imsurfit.h +./pkg/images/imcoords/src/starfind.h +./pkg/images/tv/tvmark/tvmark.h +./pkg/images/tv/imexamine/imexam.h +./pkg/images/tv/imexamine/starfocus.h +./pkg/images/tv/iis/src/gwindow.h +./pkg/images/tv/iis/lib/ids.h +./pkg/images/tv/imedit/epix.h +./pkg/images/tv/display/gwindow.h +./pkg/images/tv/wcslab/wcs_desc.h +./pkg/images/imfilter/src/median.h +./pkg/images/imfilter/src/fmedian.h +./pkg/images/imfilter/src/frmode.h +./pkg/images/imfilter/src/fmode.h +./pkg/images/imfilter/src/frmedian.h +./pkg/images/imfilter/src/mode.h +./pkg/images/imfilter/src/rmode.h +./pkg/images/imfilter/src/rmedian.h +./pkg/images/immatch/src/xregister/xregister.h +./pkg/images/immatch/src/psfmatch/psfmatch.h +./pkg/images/immatch/src/geometry/geotran.h +./pkg/images/immatch/src/linmatch/linmatch.h +./pkg/xtools/icfit/icfit.h +./pkg/xtools/inlfit/inlfitdef.h +./pkg/xtools/gtools/gtools.h +./pkg/plot/crtpict/wdes.h +./pkg/plot/crtpict/crtpict.h +./pkg/proto/maskexpr/peregfuncs.h +./pkg/proto/masks/mimstat.h +./pkg/proto/masks/rskysub.h +./pkg/dataio/fits/wfits.h +./pkg/dataio/export/export.h +./sys/psio/psio.h +./sys/mwcs/imwcs.h +./sys/imio/iki/oif/imhv1.h +./sys/imio/iki/oif/imhv2.h +./sys/imio/iki/fxf/fxf.h +./sys/imio/iki/qpf/qpf.h +./sys/plio/plcircle.h +./sys/imfort/imhv1.h +./sys/imfort/imhv2.h +./sys/gio/sgikern/sgi.h +./sys/gio/imdkern/imd.h +./sys/gio/calcomp/ccp.h +./sys/gio/stdgraph/stdgraph.h +./sys/gio/glabax/glabax.h +./sys/gio/nsppkern/gkt.h +./sys/qpoe/qpoe.h +./sys/qpoe/qpex.h +./sys/qpoe/qpio.h +./math/surfit/surfitdef.h +./math/curfit/curfitdef.h +./math/nlfit/nlfitdefr.h +./math/iminterp/im1interpdef.h +./math/iminterp/im2interpdef.h +./math/gsurfit/gsurfitdef.h +./lib/imio.h +./lib/evexpr.h +./lib/imhdr.h +./lib/gio.h +./lib/evvexpr.h +./lib/pkg/rmsorted.h + Modified to add P2R/P2P macros on Memr as neded. + +unix/boot/xyacc/debug/ytab.x +noao/obsutil/src/sptime/tabinterp.x +noao/obsutil/src/sptime/grating.x +noao/artdata/t_mk2dspec.x +noao/artdata/mktemplates.x +noao/onedspec/t_sapertures.x +noao/onedspec/t_tweak.x +noao/onedspec/dispcor/dcio.x +pkg/lists/lintran.x +pkg/images/imutil/src/imexpr.x +pkg/images/tv/display/imdwcs.x +pkg/images/tv/wcslab/wlwcslab.x +pkg/images/immatch/src/listmatch/t_imctroid.x +pkg/bench/xctest/lintran.x +sys/qpoe/qpmacro.x +math/curfit/cverrorsr.gx +math/nlfit/nlerrorsr.gx +math/iminterp/asifit.x +math/gsurfit/gserrorsr.gx + Added P2R macros where needed (11/23/09) + +lib/gio.h +lib/imio.h +lib/imhdr.h + Added P2R macros where needed (11/23/09) + +unix/gdev/sgidev/mkpkg.sh +unix/gdev/sgidev/sgi2svg.c + Added SVG translator. + +sys/plio/plload.x +sys/plio/plsave.x +sys/imfort/imioff.x +sys/imfort/imopnx.x +sys/imfort/imrdhdr.x +sys/imfort/imwrhdr.x +sys/imio/iki/oif/oifopen.x +sys/imio/iki/oif/oifopix.x +sys/imio/iki/oif/oifrdhdr.x +sys/imio/iki/oif/oifwrhdr.x +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfreblk.x +sys/imio/iki/fxf/fxf.h +sys/imio/iki/fxf/fxfopen.x +sys/imio/iki/fxf/fxfrfits.x + Uses of SZ_STRUCT in computing sizes were converted to SZ_MII_INT + +sys/libc/fgets.c + Modified to ignore '\r' used in DOS-style text files. Also now handles a + missing '\n' at the EOF as can sometimes happen with emacs-edited files. + + +noao/onedspec/odcombine/src/xtimmap.gx +noao/onedspec/odcombine/srcwt/xtimmap.gx +noao/twodspec/longslit/lscombine/src/xtimmap.gx +pkg/images/immatch/src/imcombine/src/xtimmap.gx + A pointer (Memi[ims+index-1]) wasn't being reset to NULL when + freed, leading to a segfault when run a second time from the cache. + +osb/bitfields.c + Added masks to accomodate 64-bit int sizes. Fixed a FDV problem + seen in NCAR tasks (e.g. contour) + +pkg/plot/t_implot.x + The impcom common block was being confused in the linker with the + impcom.o object (imio$dbc) in libex.a. Fixed implot bus error. + +lib/gio.h + Modified GP_WCSPTR to be properly aligned. + +lib/szpixtype.inc + + Added an equivalent to szdtype.inc for use with pixel-based applications. + The idea is that pixels will continue to be 32-bit ints regardless of + the platform. + +imcssz.x +imflsh.x +imggsc.x +imgnln.x +imgobf.x +imnote.x +impnln.x +imrbpx.x +imrdpx.x +imwbpx.x +imwrpx.x + Changed use of ty_size[] to pix_size[] + +imioff.x +imsetbuf.x +iki/fxf/fxfopix.x +iki/fxf/fxfpak.x +iki/fxf/fxfupk.x +iki/fxf/zfiofxf.x +iki/qpf/zfioqp.x +iki/stf/stfnewim.x +iki/stf/stfopix.x +iki/stf/stfrdhdr.x + Changed use of sizeof(IM_PIXTYPE(im)) to pix_size[IM_PIXTYPE(im)] + +lib/nmi.h +sys/etc/nmiread.gx +sys/etc/nmireadb.x +sys/etc/nmireadc.x +sys/etc/nmiwrite.gx +sys/etc/nmiwriteb.x +sys/etc/nmiwritec.x + Added a new Native Machine Integer (NMI) interface. This is similar to + the MII interface but is meant for use with external binary files that + don't require a (possible) byte-swap. The main point of this is to + provide a means to write native 32-bit ints distinguished from 64-bit + long. + +sys/osb/nmilen.x +sys/osb/nminelem.x +sys/osb/nmipak.x +sys/osb/nmipak16.x +sys/osb/nmipak32.x +sys/osb/nmipak8.x +sys/osb/nmipakd.x +sys/osb/nmipakr.x +sys/osb/nmipksize.x +sys/osb/nmiupk.x +sys/osb/nmiupk16.x +sys/osb/nmiupk32.x +sys/osb/nmiupk8.x +sys/osb/nmiupkd.x +sys/osb/nmiupkr.x + Support routines for the NMI interface. + +sys/fmtio/evexpr.gy +sys/fmtio/evvexpr.gy +sys/fmtio/xevgettok.x +sys/fmtio/xvvgettok.x + Broke out the xev_gettok() procedure into a new file. Newer GCC + compilers were complainint about the data type. + +sys/imio/dbc/imdcom.x - +sys/imio/dbc/imdrmcom.x + + Renamed the file containing the imdrmcom() procedure. This was causing + confusion with the 'imdcom' common block in the linker. + +unix/os/mkproto + Added utility script to generate IRAF kernel prototypes. + +unix/gdev/sgidev/sgi2svg.x + + Added new SGI driver for SVG graphics. + +unix/boot/spp/rpp/test.r + + Added new test file for RPP driver. + +unix/boot/spp/xpp/xpp.l +unix/boot/spp/xpp/xppcode.c + Attempt to try to manage new use of Memr[] macros, but one known to + break backward compatibility. A use such as "Memr[$1+N]" is obviously + part of a structure definition, so we automatically add a P2R() macro + so it reads "Memr[P2R($1+N)]" when being passed to RPP. This properly + aligns the struct on 64-bit platforms and is a no-op on 32-bit. + The complication is a simple case of "Memr[$1]" which may be either + the first element of a structure or a utility macro for a TY_REAL array. + In this case, we output an error indicating that a P2P or P2R macro is + required to resolve any ambiguity. + There are similar examples for 2-D arrays that aren't as easily parsed, + but since we can't trap them generally we can't do much to automatically + 'fix' the macro. + The overall utility of this change is questionable and may be pulled + from a later release. + +sys/osb/abs.c + Added an abs() function to avoid type conflicts between int/long. + +sys/osb/i32to64.c +sys/osb/i64to32.c + Imported int 32/64 pack/unpack from IRAF64 code. Note these are + MACHDEP on Intel byte order! + +sys/osb/urand.c +sys/osb/imul32.c + The urand() algorithm relies on 32-bit overflow to work properly. Needed + to add an 'imul32' function to do the multiplication with overflow. + +sys/osb/ipak32.c +sys/osb/iupk32.c + Added pak/unpak for 32-bit integers. + +pkg/images/imutil/src/t_chpix.x + Added an imflush() to the output image. + +pkg/plot/t_implot.x + Renamed the 'impcom' to 'implcom' to avoid a symbol name clash in the + linker. + +lib/gio.h +sys/gio/cursor/gtr.h + Increased the size of the WCS buffer. The size was previously calculated + as being 17 structure elements by assuming the SZ_INT was 2. Increased + to accomodate 64-bit sizes and will live with the wasted space. + +local/iraf_test.tar.gz + Added the "images test scripts" to the main distribution. These require + stty playback and so require the old CL to run. To use these, unpack + in a clean directory and begin with "stty playback=test.images", + successive tests will be run automatically. + +pkg/system/bench.cl + Added benchmark script to core distribution. + +pkg/cl/proto.h +pkg/ecl/proto.h + Function prototypes for the CL code. + +unix/hlib/libc/kproto32.h +unix/hlib/libc/kproto64.h +unix/hlib/libc/vosproto.h + Kernel prototype files. These are somewhat massaged by hand to remove + duplicate symbol names that cause errors but provide 98% coverage until + this can be addressed. + +unix/hlib/iraf.h -> +unix/hlib/mach.h -> +unix/hlib/iraf32.h +unix/hlib/mach32.h +unix/hlib/iraf64.h +unix/hlib/mach64.h + Added 32 and 64-bit definitions of the files defining primary data types. + Compilation is actually done using symlinks to the appropriate version in + hbin$ directory. The hlib$ versions are likewise a symlink that points to + the correct version when the architecture is set. + +/util + +/Makefile + + Top-level makefle and utility scripts for building the system. Makefile + targets are + + all alias for 'update' + sysgen do a complete sysgen + update update system since last sysgen + updatex update with debugging flags enabled + src clean system of current binaries + clean clean system of current binaries + pristine clean system of all binaries + tables compile the TABLES package + noao compile the NOAO package + summary print core/noao/tables spool file summaries + showarch show currently configure arch + reconfigure for named architecture + +unix/hlib/mkpkg.sf.LNUX64 + Special files list for new arch. + +unix/hlib/irafarch.csh + Utility script to determine proper platform architecture name. + +sys/osb/bitfieds.c + Added extra masks to accomodate 64-bit integers. + +pkg/xtools/ranges/rgfree.x + Added a check for a null pointer around the mfree. There were cases in + the ICFIT code that this was being called with a NULL pointer and would + trigger an error on newer libc, it seemed safest to allow the previous + behavior but just protect against it. + +sys/pmio/zzinterp.x + pm_create() was being called with too many arguments. + +unix/hlib/libc/libc.h + Added libc prototype definitions for automatic checking. This is also + where we look at the vosproto.h + + + +------------------------------------------------------ +V2.15-ALPHA release (3/2/10) +------------------------------------------------------ + +math/nlfit.gh + A leftover definition of P2R was causing problems. + +sys/nmemio/minit.x + Calls to fmkbfs() to create initialize the I/O buffers were not taking + into account that subsequent calls to the task in the prcache would + already have an i/o buffer. This was causing leading nulls to appear + in the stdout stream (e.g. redirection or scan-from-pipe) as well as + just output to appear in the CL stdout. Commented out the code until + it is better understood. The intent was to ensure that when reporting + memory usage we wouldn't see some arbitrary base value but could ensure + that memory allocated by an app was accounted for completely. + +noao/imred/ccdred/src/cosmic/crsurface.x +noao/imred/crutil/src/crsurface.x +pkg/images/tv/imedit/epsurface.x +pkg/images/tv/imexamine/iesimexam.x +pkg/plot/t_surface.x + There is apparenty a bug in the NCAR ezsrfc() routine that reaches beyond + the defined 'work' area (said to be twice the size of the data raster). + This was originally increased to be 4*data in the SURFACE task, but the + routine is called elsewhere and was failing in e.g. IMEXAM. Increased + the size for all instances but will need to track this down. + Pragmatically this can be ignored on modern systems as a minor waste of + space, it is much harder to debug the login of the NCAR code. + +sys/libc/cfredir.c +unix/hlib/libc/libc.h +unix/hlib/libc/xnames.h + Added a wrapper for frediro() from FIO to redirect open streams (7/5/10) + +bin.ipad + +noao/bin.ipad + +unix/as.ipad + +unix/bin.ipad + +hlib/install +hlib/irafarch.csh +hlib/irafuser.csh +hlib/mkpkg.inc +os/zmain.c +os/zopdir.c +os/zzepro.c +os/irafpath.c + Minor changes necessary for iPad port. (8/7/10) + +noao/lib/obsdb.dat + Added obsdb entry for Jack C. Davis Obs (8/31/10) + +unix/os/zgtime.c + Fixed a bug in the time calculation caused by a change in most systems + in the definition of clock ticks (8/31/10) + +unix/hlib/login.cl + Added dummy definition for 'imclobber'. (9/17/10) + +sys/imio/iki/fxf/fxfrfits.x + If the DATE keyword doesn't specify a time, the IM_CTIME is calculated + with INDEF values, leading to overflow (9/25/10) + +extern/tables/pkg/fitsio/strfits/fits_rpixels.x + The size of the 'spp' pointer was increased to avoid overflow. + +noao/artdata/lists/stplot.x +noao/obsutil/src/ccdtime/ccddb.x +noao/mtlocal/camera/cam_keywords.x +noao/onedspec/odcombine/srcwt/icombine.x +pkg/images/immatch/src/linmatch/rgldelete.x + Fixed various cases where Mem array were used as 'mem' (10/28/10) + +pkg/utilities/bases.cl + +pkg/utilities/utilities.cl +pkg/utilities/utilities.hd +pkg/utilities/utilities.men + Imported the BASES task from the NLOCAL extpkg (10/29/10) + +pkg/cl/exec.c +pkg/ecl/exec.c + Modified the findexe() procedure to allow use of compatable binaries. + For example, on linux64 we can use 32-bit linux/redhat binaries, on + macintel we might be able to use macosx. This also allows the system + to use external packages following the older architecture names without + change, e.g. on 32-bit systems where the arch is now 'linux', packages + with only 'redhat' binaries will be used automatically. (10/30/10) + +unix/os/zgtenv.c + Modified to allow a $HOME/.iraf.h file to be searched for if the system + cannot be found. This supports a "personal installation" of + IRAF on machines where users don't have root permission for a normal + install. The KI code will also pick up these definitions, and we allow + the personal file to override the system default so give users the + option of running a private version. (10/30/10) + +pkg/mkpkg +pkg/tbtables + + The TABLES v3.12 version of libtbtables.a (ported to 64-bit) is now + included in the core system. (11/4/10) + +pkg/utilities/mkpkg +pkg/utilities/utilities.cl +pkg/utilities/utilities.hd +pkg/utilities/utilities.men +pkg/utilities/utilities.par +pkg/utilities/nttools + + Imported the TABLES.TOOLS package as a new NTTOOLS package that is + loaded with UTILITIES. The KEYSELECT task is no longer available, + other TABLES libraries (e.g. stxtools/display) we also imported to + support specific tasks but are not generally exposed. The new package + name is to avoid a potential name collision when a standalone TABLES + package is also installed. (11/4/10) + + +noao/digiphot/ptools/mkpkg +noao/digiphot/daophot/mkpkg +noao/digiphot/ptools/ptools.cl +noao/digiphot/daophot/daophot.cl +noao/digiphot/photcal/photcal.cl + Removed dependency on TABLES external package (11/4/10) + +noao/digiphot/ptools/pttest.cl + Changed the check for the TABLES package to look for NTTOOLS (11/4/10) + +unix/gdev/sgidev/sgi2gif.c + Fixed an error where fclose called twice on same descriptor. (11/8/10) + +pkg/system/help/helpdb.x +pkg/system/help/helpdir.x + Fixed a segvio problem in MKHELPDB on 64-bit systems, also fixed a + problem with reading the helpdb.mip created on 'other' systems (11/13/10) + +lib/helpdb.mip +noao/lib/helpdb.mip + Rebuilt the help databases. (11/16/10) + +immatch/src/imcombine/src/ichdr.x + The step that stripped any directory from the image name for the $I + value of the imcmb parameter failed for extensions. (11/17/10, Valdes) + +misc help pages + Some 227 help pages were updated to correct spelling mistakes (including + in one case the word 'misspelled'. (11/17/10) + +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/hlib/login.cl +unix/hlib/zzsetenv.def + Changed the version to V2.15RELEASED. (11/18/90) + +unix/hlib/clpackage.cl +unix/hlib/zzsetenv.def +unix/hlib/extpkg.cl + +iraf/extern + +iraf/extern/configure + +iraf/extern/README + + Installed the 'dynamic package loading' mechanism. This feature + operates in concert with a 'repository' of files maintained on the + ftp archive. The scheme is that external packages are built to be + complete for a particular architecture, unpacking these in the + iraf$extern directory constitutes an installed package. The CLPACKAGE + script was modified to automatically declare any package in this + directory. + To bootstrap the system, a configure script downloads the repository + manifest from the server and creates skeleton directories for packages + available on that platform. Installing a package is then just a matter + of typing "make fitsutil" to download and unpack the package. Dependenc- + ies are likewise downloaded automatically, scripts in the iraf$util + directory and hand-crafting of the repository do all the heavy lifting. + Packages may be kept automatically up to date with a "make update" + command to compare the install dates with the contents of the repository. + The Makefile is generated automatically by the conigure script, more + details are available in the README file. + (11/19/10) + + +------------------------------------------------- +System Frozen for Final Build +Sat Nov 20 23:54:45 MST 2010 +------------------------------------------------- + +------------------------------------------ +V2.15 EXPORT release (November 21, 2010) +------------------------------------------ + diff --git a/doc/notes.v215 b/doc/notes.v215 new file mode 100644 index 00000000..a92fdfc5 --- /dev/null +++ b/doc/notes.v215 @@ -0,0 +1,602 @@ +System Notes File for IRAF Version 2.15. +Begun with V2.15 code freeze 22 Nov 2010. +------------------------------------------- + +unix/hlib/install + Fixed an old bug when creating the imtoolrc link in cases where the + system doesn't already have a /usr/local directory (11/23/10) + +unix/hlib/extpkg.cl + Changed the test used to define an external package to check for + either a ".installed" file (e.g. when using the makefile) or a + package .cl script (e.g. when pointing a symlink) (11/23/10) + +New distribution files cut..... +------------------------------- + +unix/hlib/irafuser.csh +unix/hlib/irafarch.csh + On 32-bit mac systems the arch wasn't being properly detected (11/24/10) + +New distribution files cut..... +------------------------------- + +util/pkginst +util/pkginit +util/pkgclean +util/pkgupdate + Updates to allow IRAFARCH to specify the architecture to be installed. + Also modified to update script to automatically update all currently + installed architectures regardless of IRAFARCH (11/30/10) + +unix/hlib/install + Added a fix to the '-m' flag + +sys/libc/cimdrcur.c + The 'wcs' field was not properly converted from int to/from XINT in + the interface, causing the value to always be returned as 0 on 64-bit + platforms (12/6/10) + +pkg/ecl/mkpkg + Changed the -ltermcap to -lncurses to use the newer form of this library + and eliminate problems with users having to manually created links to + satisfy the shared libs (12/6/10) + +pkg/ecl/mkpkg + Added changes needed for FreeBSD port. (12/23/10) + +unix/boot/spp/xc.c + Added changes needed for FreeBSD port. (12/23/10) + +unix/hlib/mkpkg.inc +unix/hlib/irafuser.csh + Added changes needed for FreeBSD port. (12/23/10) + +util/pkgget +util/mksrc +util/mkclean +util/mkbindist + An ERRMSG alias was being used but not defined (12/30/10) + +unix/hlib/irafarch.csh + Added 'power macintosh' as a valid uname value for 10.4 PPC systems. + (12/31/10) + +unix/hlib/irafarch.csh + The uname cmd for Solaris had an extra '|' pipe definition (1/3/11) + +unix/boot/spp/xc.c + The fork() procedure was declared as type int instead of pid_t (1/3/11) + +lib/libimc.a -> ../bin/libimc.a + +pkg/images/immatch/src/imcombine/src/generic/mkpkg +pkg/images/immatch/src/imcombine/src/mkpkg +pkg/images/immatch/src/imcombine/mkpkg +pkg/images/mkpkg + Converted the generic combining code into a core library so that + other versions of combine (such as in ccdred, mscred, nfextern) + will share the same code rather than have copies. (1/4/11, Valdes) + +pkg/tbtables/Revisions+ +tbhanp.x +tbhpnp.x +tbttyp.x + A couple of trivial changes (see the Revisions file) and: + 1. Changes to better control the types and extensions. The accepted + extensions are |tab|fits|fit|fxb|txt|dat|cat|tmp|. + 2. If no extensions is given the default is now text instead of STSDAS + table. + (1/7/11, Valdes) + +unix/hlib/extpkg.cl + Fixed a typo where 'dp' was defined instead of 'dpkg' (1/14/11) + +sys/vops/mkpkg + Forced the generation of the ACHT code when compiling the VOPS lib. + These routines are doubly-generic but allow for in-place conversion, + however there is a difference in the relative datatype size on 32- + and 64-bit system (e.g. real and int are the same on 32-bit, int is + larger on 64-bit) which causes the loop indexing to be different. + By forcing the regeneration of the code on each system we ensure that + during a sysgen the code appropriate for the platform will be used. + (1/18/11) + +unix/os/zzdbg.c + +unix/os/zzstrt.c + Moved all the (undocumented) debug print functions from the zzstrt.c + code into a separate zzdbg.c simply to collect them. These routines + can be used to debug low-level VOS routines but aren't generally used + outside of a port situation (1/18/11) + +sys/osb/mkpkg +sys/osb/ieee.gx +sys/osb/iand32.c + + IEEE NaN masking was being done using only a 32-bit mask. On 64-bit + systems this would lead to the interpretation of a double-precision + exponent as always being zero. This meant that all TY_DOUBLE FITS + files on 64-bit systems would appear to contain only zero pixels. (1/18/11) + +sys/imio/imfls.gx + Data types needed to be converted on 64-bit systems even when the types + are the same due to the need to pack/unpack int pixels (assumed to be + 32-bit values) (1/18/11) + +sys/imio/impak.gx +sys/imio/imupk.gx + Earlier 64-bit mods to these routines were attempts to work around the + in-place conversion bug discovered above. In impak.gx it is still nec- + essary to pack int/long into 32-bit values written to the file (1/18/11) + +pkg/images/imutil/src/nhedit.x + The comfile parameter check was modified to allow the "NULL" string as + an option to indicate no comfile was present (standard use is the null + string "", as was done when the task was first imported to the core + system). More time has been spent whining about this supposed + 'incompatability' than would have taken to resolve it but this change + should work for users even if the external package version of the + task is not available. I don't expect the whining will ever stop, + though. (1/18/11) + +unix/os/zgcmdl.c + Changed declaration of 'environ' to quiet warning messages. (1/19/11) + +pkg/ecl/readline/mkpkg + Changed the execution of the configure cmd to explicityly use "./" (1/20/11) + +sys/fmtio/evexpr.y +sys/fmtio/evvexpr.gy + A typo meant that the GT token precedence was set twice (1/24/11) + +Makefile + Added a 'self_update' target to allow future updates (1/25/11) + +.version + Added a file with a simple version string for use in scripts (1/25/11) + +util/pkgget +util/pkginit +util/pkgclean +util/pkgconfig + Minor error-code checks (1/25/11) + +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/irafarch.csh +unix/hlib/zzsetenv.def + Updated to v2.15.1 (1/25/11) + +pkg/utilities/nttools/stxtools/vexcompile.y + Added declaration of vex_gettok() to source grammar. (1/25/11) + +sys/fmtio/evexpr.y +sys/fmtio/evvexpr.gy +pkg/tbtables/selector/trsopen.y +noao/digiphot/photcal/parser/parser.y +pkg/utilities/nttools/tunits/parseunits.y +pkg/utilities/nttools/stxtools/vexcompile.y + Touched the file mod time to force regeneration of parsers. (1/25/11) + +unix/boot/xyacc/files - +unix/boot/xyacc/dextern - +unix/boot/xyacc/yaccnews - +unix/boot/xyacc/yaccdiffs - +unix/boot/xyacc/dextern.h + +unix/boot/xyacc/y[1234].c + +unix/boot/xyacc/cddllicense.txt + +unix/boot/xyacc/README + Replaced XYACC code with a version built from the OpenSolaris project + and distributed under the free 'Common Development and Distribution + License' (CDDL). Except for minor line number changes in the generated + parser, the production tables and variables used are identical to the + earlier XYACC. This version of XYACC is now free of license restrictions + other than those required by the CDDL. The README file has been updated + to reflect these changes. Total effort for the project was 1 day. (1/25/11) + +pkg/images/imutil/src/imexpr.gx + A use of Memr in the struct was not declared with P2R in the generic code. + (1/25/11) + +pkg/images/imutil/src/imexpr.gx + Modified the behavior of the task so that when a scalar expression is + used, all pixels are set to that value. Previously, only the first pixel + was set with the remainder of the image undefined. (1/25/11) + + +------------------------------------------------------ +System Frozen for V2.15.1 Patch (1/25/11) +------------------------------------------------------ + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2ueps.c + Declaration of the timestamp variable was failing on 64-bit system (2/4/11) + +sys/mwcs/wftnx.x +sys/mwcs/wfzpx.x +sys/mwcs/wfzpn.x + The interative inversion method could runaway leading to an arithmetic + exception. Added a maximum change to each iteration to avoid this. + (2/18/11, Valdes) + +sys/osb/ieee.gx +sys/osb/ieeed.x +unix/osb/ieeer.x +unix/as.linux64/ieee.gx +unix/as.linux64/ieeed.x +unix/as.linux64/ieeer.x +unix/as.macintel/ieee.gx +unix/as.macintel/ieeed.x +unix/as.macintel/ieeer.x + The earlier update to fix the double-precision problem left a debug + value in the generic code that was never updated in the patch build. + This meant that zero pixels in FITS files were being interpreted as + 128 (the debug value). (2/17/11) + +pkg/dataio/fits/fits_rpixels.x +pkg/dataio/fits/fits_wpixels.x + Buffer sizes were being computed using SZ_INT instead of SZ_INT32 (2/18/11) + +sys/fmtio/evexpr.y +sys/fmtio/evexpr.x +sys/fmtio/evvexpr.gy +sys/fmtio/evvexpr.y +sys/fmtio/evvexpr.x + An earlier change to the token declarations had the strange effect of + changing the processing of string comparison. This effectively broke + tasks like HSELECT. Fell back to the earlier (and original) code until + this is better understood, however it doesn't appear to be releated to + the XYACC changes. (2/18/11) + +pkg/images/tv/imexamine/imexam.h + The coordinates arrays in the main structure were improperly indexed + with the P2R macro (2/10/11) + +.version +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/irafarch.csh +unix/hlib/zzsetenv.def + Updated to v2.15.1a (2/21/11) + +------------------------------------------------------ +System Frozen for V2.15.1a Patch (2/21/11) +------------------------------------------------------ + +pkg/tbtables/fitsio/fttrnn.f + Disabled NaN checking for this function. It doesn't work properly on + 64-bit systems and NaN is seldom used anyway (2/22/11) + +sys/imio/imggsc.x + The pixels size indexing was incorrect in the case of e.g. 32-bit int + pixels and access as a real array. This was causing access to image + columns and higher dimensional data to get bogus values. (4/4/11) + +util/mkup + Added extra step to do the core "mkpkg update" (5/2/11) + +sys/etc/urlget.x + +sys/etc/zzdebug.x +sys/etc/mkpkg + Added a new url_get() procedure for downloading URLs to a named file. + Method signature is + + nread = url_get (char url[], char outname[], pointer reply) + + If a 'reply' pointer is supplied, the HTTP reply header is returned + as a string which must be allocated to at least SZ_LINE. (5/30/11) + +sys/imio/imt/ + + Added enhanced IMT expansion interface. See details in the + imio$imt/README file. (6/7/11) + +unix/hlib/libc/knames.h + Added definitions for imul32() and strsum() (6/17/11) + +sys/osb/imul32.c + Added code comments forgotten from the initial 64-bit port (6/17/11) + +sys/osb/mkpkg +sys/osb/strsum.c + Added a new strsum() procedure to return the 32-bit checksum of an + SPP string. This is used in e.g. generating the filenames for the + URL cache. (6/17/11) + +sys/fio/mkpkg +sys/fio/fcache.x + Implemented a proper URL cache mechanism for IRAF that provides + programmatic and application interfaces and can be shared with VOClient. + Cache names are generated from the filename/URI string (its checksum) + to map a URL to a local file resource, access is blocked until the + local resource becomes available for use. Names aren't guaranteed to + be unique but collisions should be rare and the mechanism allows URLs + to be dealt with easily at the application level. (6/21/11) + +unix/os/mkpkg +unix/os/zfrmdr.c + +unix/hlib/libc/knames.h +unix/hlib/libc/kproto.h + Added a new kernel routine to delete directories (6/21/11) + +sys/ki/mkpkg +sys/ki/ki.x +sys/ki/ki.h +sys/ki/kfrmdr.x + +unix/hlib/knet.h + Added KI routines to delete directories (6/21/11) + +lib/syserr.h +lib/syserrmsg + Added error messages for rmdir function (6/21/11) + +sys/fio/mkpkg +sys/fio/frmdir.x + Added VOS routine to delete directories. (6/21/11) + +sys/fio/open.x +sys/imio/immapz.x +pkg/tbtables/tbtopn.x + Modified file open to handle URLs. If the filename begins with "http" + the file is downloaded to the cache and the cached file is opened. (6/24/11) + +unix/hlib/login.cl +unix/hlib/mkiraf.csh +unix/hlib/install + Added user-specific cache directory name. (6/26/11) + +.version +pkg/cl/cl.par +pkg/ecl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/irafarch.csh +unix/hlib/zzsetenv.def + Updated to v2.16DEV (6/30/11) + +unix/os/zmaloc.c +unix/os/zraloc.c + Number of bytes was being cast as (int) meaning allocations > 2GB were + not being handled properly (6/30/11) + +unix/os/zgcmdl.c + On OSX systems apps can no longer reliably get the environ pointer, + meaning we can't get the argv vector of arguments using the old method. + Ifdef'd the code to use the _NSGetArgv() and _NSGetArgc() methods to + get pointers to these values from the dynamic libs. Fixes a problem + with cmdline args from IMFORT programs. (7/15/11) + +sys/etc/votable.x + Added a new file of VOTable utility procedures. (7/15/11) + +unix/os/zfacss.c + Modified to check if non-existent file is a symlink, if so, return the + access status of the link itself (9/6/11) + +unix/hlib/iraf32.h +unix/hlib/iraf64.h +unix/hlib/libc/spp.h + Added definitions for SYMLINK_FILE type (9/6/11) + +sys/fio/delete.x + Modified to allow deletion of zombie symlinks (9/6/11) + +sys/fio/open.x +sys/imio/immapz.x +pkg/tbtables/tbtopn.x + Modified to handle file:// URIs (9/6/11) + +sys/imio/imt/imxpreproc.x + Allowed file:// URIs, no longer confused with concatenation (9/6/11) + +sys/libc/strdup.c + +sys/libc/proto.h +unix/hlib/libc/libc.h + Added a binding for a strdup() function (9/14/11) + +*.hlp + Minor modifications to MANY help files to remove duplicate words (9/19/11) + +unix/hlib/login.cl + Added some (commented out) code to allow user control of SAMP startup + on login. The system-wide method is to turn on the 'samp_onstart' + variable in hlib$zzsetenv.def (9/21/11) + +ys/mwcs/wftnx.x +sys/mwcs/wfzpx.x +sys/mwcs/wfzpn.x + The maximum change revision (2/18/11) did not think through the units. + So the value was 1 degree which is probably too large. This was changed + to 30 arcsec. + (9/28/11, Valdes) + +sys/mwcs/mkpkg +sys/mwcs/wfinit.x +sys/mwcs/wftpv.x + + Added a new function driver for a WCS called TPV; tangent plane with + PV distortion coefficients as described by Calabretta & Greisen in 2000 + (http://www.astromatic.net/forum/showthread.php?tid=271). + (9/28/11, Valdes) + +lib/syserr.h +lib/syserrmsg +sys/etc/urlget.x + Added support for URL redirection (code 300) to access (10/5/11) + +system/system.hd +system/system.men +system/doc/bench.hlp + Added help page for the BENCH task, fixed src entry for SPY task. (10/24/11) + +util/fget + Added wrapper script around URLGET task that can be used as a backup + when there is no WGET command on the machine (11/19/11) + +pkg/tbtables/tbbnll.x +pkg/tbtables/tbfnew.x +pkg/tbtables/tbfopn.x +pkg/tbtables/tbfpri.x +pkg/tbtables/tbttyp.x + Commented out the equivalence statements being used to force alignment + of local variables. Was causing 64-bit problems. (12/1/11) + +pkg/tbtables/fitsio/fttdnn.f + Disabled NaN checking for this function. This was done previously for + the real-value function but missed for doubles. Will need to be + revisited once there is more time. (12/2/11) + +sys/imio/imrbpx.x + Fixed a problem with getting 'nearest' boundary extension values from + int images on 64-bit systems (12/14/11) + +sys/imio/iki/fxf/fxfupk.x + Fixed a problem on 64-bit systems where BITPIX=32 data with bscale/bzero + values was garbage values. Needed to unpack int array before scaling + (12/20/11) + +local/cache + +local/login.cl + Updated the login.cl file for the iraf user, added a 'cache' directory + to be used for the account (1/4/12) + +unix/hlib/install + Turned off the installation of the /dev fifo pipes as a default since + these are rarely used any more. If needed, "install -f" will create + them on platforms that support FIFOs (1/15/12) + +unix/hlib/install + Added code to install the voclientd/voclient.jar files in the local + bindir as a symlink. (1/15/12) + +unix/hlib/iraf.h + Increased the size of SZ_FNAME to 511 to accomodate lengthy URLs. The + max HTTP URL size is typically 1024, but this seemed escessive (1/15/12) + +sys/etc/main.x + Added checks for a "hlib$zzsetenv.def" file or a file pointed to by an + 'irafinit' environment variable to set or override the system + zzsetenv.def file. The first case allows for an alternate 'hlib' + definition (as is used in the pipeline), the second for a file that + may only partially override the environment (1/17/12) + +sys/etc/prpsio.x +sys/gio/gki/gkiopen.x +sys/gio/gki/gkiclose.x +sys/gio/gki/gkideact.x +sys/gio/gki/gkireact.x +sys/gio/gki/gkisetwcs.x +sys/gio/gki/gkigetwcs.x + The pseudofile i/o to the graphics stream has been broken all this time. + When opening the GKI stream, set/get wcs etc the xmit packet is preceeded + with the file descriptor number, written as SZ_INT in the GKI code and + read as SZ_INT in the prpsio.x code. In cases where a 32-bit task binary + is being used on a 64-bit system, the CL is trying to read a 64-bit int + from a stream written with a 32-bit value, leading to a corrupted + descriptor number and usually a segfault. Modified so the descriptor is + written/read as SZ_INT32 to be compatible. (2/2/12) + +local/COPYRIGHTS +local/LICENSES + + Modified the COPYRIGHTS statement and included the text for the CDDL + and UCAR licenses. As far as we now know, IRAF is now "free". (2/17/12) + +sys/imio/imflsh.x + Fixed a bug in which TY_INT images weren't being handled properly by + the system (2/24/12) + +sys/etc/urlget.x + Added support for Content-Length header values to avoid a socket + timeout behavior from some web servers (3/2/12) + +.version +pkg/cl/cl.par +pkg/ecl/cl.par +pkg/vocl/cl.par +unix/hlib/motd +unix/hlib/install +unix/hlib/login.cl +unix/hlib/irafarch.csh +unix/hlib/zzsetenv.def + Updated version strings to final export (3/5/12) + +unix/boot/mkpkg/tok.c + Modified the $ifnewer behavior to return a 'true' value if the + second argument doesn't yet exist. (3/6/12) + +sys/osb/mkpkg +sys/osb/iscl32.c +sys/osb/iscl64.c +unix/hlib/libc/knames.h +sys/imio/iki/fxf/fxfupk.x + Added a new OSB routine ISCL32/ISCL64 that applies the FITS bscale/bzero + to pixel data. This is required in the FITS kernel where the buffer + is a XCHAR array but there are alignment issues on linux systems when + passing arrays between spp/C codes. (3/7/12) + +sys/imio/imt/imxexpand.x +sys/imio/imt/imxpreproc.x + The use of "@file" and the contents of the file contained extns or + sections on the images, was broken. The file was being read correctly, + however the square brackets weren't being properly escaped when + passed to the fntgfn code to create the list. (3/9/12) + +Makefile +util/iraf_update + +util/iraf_latest + +util/self_update + Added stub routines to permit simple updates of the system. New Makefile + targets include: + + latest Update entire system + check_latest Check system update status + latest_src Update source code only + latest_core Update core system only + latest_noao Update NOAO package only + latest_vo Update VO package only + + The 'iraf_latest' script is the workhorse for the update, but the details + of how the patches will be built or packaged are still TBD. Because the + first thing done is to update the build/util scripts, we can defer this + until the first release. (3/11/12) + +sys/imio/imrbpx.x + There was still a problem with boundary extension using constant values. + For int data, the IM_OOBPIX value was being converted to int in impakr() + but was packed as a 32-bit value. However, it was not then being + unpacked to a 64-bit INT in imrbpx() as was done for the nearest pixel + values. (3/12/12) + +------------------------------------------------------ +System Frozen for V2.16.0 Release (3/12/12) +------------------------------------------------------ + +sys/imio/imrbpx.x + Use of constant boundary extension wasn't being properly unpacked on + 64-bit systems (3/12/12) + +sys/imt/imt.x +sys/imt/imxexpand.x +sys/imt/imxpreproc.x + Fixed a bug in which @files containing files with section/extension + info weren't being properly expanded. (3/14/12) + +imcoords/src/t_ccmap.x +imcoords/ccmap.par +lib/geofit.x +lib/geogmap.gx + Updates to the previous changes. A new option "tweak" was added to + the values for the "refpoint" parameter to allow controlling whether + to tweak the input tangent point. (3/16/12, Valdes) + +noao/lib/obsdb.dat + Added an entry for the Langkawi National Observatory (Malaysia) submitted + by user. (3/18/12) + +------------------------------------------------------ +System Frozen for V2.16.0 Release (3/18/12) +------------------------------------------------------ + diff --git a/doc/notes.v23 b/doc/notes.v23 new file mode 100644 index 00000000..cfc63af4 --- /dev/null +++ b/doc/notes.v23 @@ -0,0 +1,4955 @@ +UNIX/IRAF, starting 11/30/85 + +Goals: Restructure the system to better isolate machine dependence, make + installation and updating easier (there are many subtleties at + present). Merge in many revisions from VMS/IRAF, SUN/IRAF, + and AOS/IRAF. +-------------------------------------------------------------------------- + +Major Problems at present: + + Root Directory dependencies + CL, XC, Mklib, etc. must be recompiled whenever the root + directory is changed. The root directory name must be changed + in all the Makefiles, and eventually in all the zzsetenv.def + files. + + Installed Tasks + A number of tasks must be installed in UNIX directories outside + of IRAF; these tend to get lost whenever someone works on UNIX. + + Links + Links are used for libraries, executables, and include files. + These can get lost when a file is altered, or when the system + is moved in pieces on a tar tape. At present someone must know + where all the links are and go through and remake them by hand. + + Scattered machine dependencies + There are a number of assembler files scattered about the system + and referenced in the Makelib files. When installing the system + on a new host one must search out all these files, and either write + new assembler modules or comment out the optimized versions in + the Makelib files. + + Automatic System Creation Procedure + The "sysgen" capability for the VOS is good, but other than that + the autogeneration facilities are rudimentary. There is no + automated full system generation capability. There is no easy + way to relink all the packages when important kernel changes are + made. The UNIX/IRAF development system (other than the VOS) has + never been fully recompiled due to the lack of these faciltities, + hence there is old code that will no longer compile hidden in the + system. + + Makefiles + UNIX/IRAF currently uses the UNIX Make facility for package + generation. The result is many UNIX dependent Makefiles scattered + about the system. When moving IRAF to a non-UNIX system some other + facility must be developed to make the packages. This prevents + automated installation of new versions of IRAF, since all of the + make files must be translated for the new system. + + Awkward Machine Dependencies + The magtape device table is currently wired into the kernel; should + be table driven at runtime. The ALLOCATE stuff is awful, and + depends upon an external, non-standard UNIX program. The graphics + system requires NCAR metacode translators which are not part of + the IRAF system. + +These problems are awkward enough to require the assistance of an IRAF guru +for system installation and updating; installations and updates consume limited +manpower resources; maintenance starts to take so much time that new software +initiatives suffer. A more easily maintained system is required, now that we +have versions of IRAF running so many host machines. + +Strategies: + + [1] Collect ALL machine dependent files together in one place, so that + the major parts of the system can be updated by merely reading in a + TAR tape. + [2] Develop an automated full system generation procedure so that the + system can be automatically regenerated after an update. This requires + doing away with the Makefiles and the use of Make (and of DCL and + mkpkg.com files on VMS). + [3] Do away with the links. + [4] Do away with the remaining root directory dependence. + +The major new developments are the creation of the HOST directory system, and +the replacement of Make, Mklib, DCL/mkpkg.com etc. by a new portable IRAF +bootstrap utility called MKPKG. +------------------------------------------------------------------------------ + +iraf$unix/* [VAX/UNIX version of IRAF] +iraf$vms/* [VAX/VMS version of IRAF] (to be added) +iraf$sun/* [SUN/UNIX version of IRAF] (to be added) +iraf$aos/* [AOS/VS version of IRAF] (to be added) + + Created a new directory tree off the iraf root, to be used to hold ALL + machine dependent code in IRAF. This will make it possible to update + entire directory trees automatically, without need for an expensive + merge operation in those directories (the system dependent directories + will still require occasional merges). The name "unix" reflects the + host dependence of this directory system. Other systems have a + different root directory name. The logical name for the active host + interface directory is "host$". (12/1) + + Subdirectories of host$: + + as assembler stuff (optimized operators) + boot bootstrap utilities (XC, Mkpkg, etc.) + hlib text files (include files, etc.) + os the iraf kernel + + The DEV directory is to be retained and will contain the device tables + for the local system. These are site dependent, unlike the HOST files, + which are machine/os dependent. OSB remains in the VOS because it is + part of LIBVOPS.A, and is mostly portable anyhow. + +host/boot +host/boot/bootlib + Moved the softools$boot directory to host$boot, since it contains much + machine dependent stuff. Moved the RTAR host interface routines out + into the "bootlib" directory, as the start of a host interface library + for the boot utilities. Started on a complete rewrite of MKLIB, to + be replaced by a more comprehensive utility called MKPKG. (12/1) + +unix/os/zgtenv.c + Modified to get the values of certain well known environment variables + at run time from the file, after first searching the UNIX + environment. This eliminates the need to recompile the bootstrap C + programs (including the CL) when the value of a fundamental variable + like "iraf$" is changed. (12/3) + +sys/ki/kignode.x + There were problems when installing a binary version of IRAF on a + new system, when the binary version was configured with networking + turned on. If the installer, thinking that they would not be using + networking, did not update the dev$hosts table, then the networking + software would not find an entry for the local host (i.e., we would + be running with the host name table for a different site). + Not surprisingly this would cause problems, but to avoid the trap + I modified kignode.x to effectively disable networking if no entry + for the local host (as named by ZGHOST) is found in the host name + table. When this situation occurs, all node names are assumed to + be aliases for the local node, causing all file references to be + resolved locally. This also makes it easy to turn off networking + temporarily, by simply commenting out the entry for the local host + in the dev$hosts file. (12/3) + +sys/fmtio/ctol.x + Would interpret "-" as a number, value zero, length one char. + This was causing image sections to fail, e.g., "[*,-*]". Fixed to + treat a lone minus sign as not a number. (12/3) + +unix/os/zfpath.x +unix/os/str.c + ZFPATH was making calls to the VOS procedures GSTRCPY and STRUPK. + Added the equivalent local services to the kernel. (12/5) + +pkg/gio/gumark.x + The call to GGSCALE was using unit square marker polyline point coords + X,Y instead of the center coords of the marker XCEN,YCEN. (12/5) + +unix/os/zfchdr.c + When called with the name of a subdirectory, would cache the subdir + name rather than the pathname of the new directory, causing a + subsequent call to ZFGCWD to fail. This has not been a problem + because ZFCHDR is not supposed to be called that way, but it seemed + safer to change it to handle this case. (12/6) + +unix/os/prwait.c + The subprocess exit code (argument to exit()) was not being returned + properly (wrong byte of exit longword). (12/8) + +unix/os/zoscmd.c KERNEL CHANGE +------------------------------------------------------------------------------- + When a host system command is interrupted the exit status returned + by the subprocess is now ignored, with ZOSCMD returning a special + code indicating interrupt instead. This is the only reliable way + of signalling interrupt to the parent process, because the exit status + returned by foreign tasks is not defined. (12/8) + + The ZOSCMD for all kernels should return the INTERRUPT exit code + (SYS_XINT=503) when the OS command is interrupted, e.g., due to a + . +------------------------------------------------------------------------------- + +host/boot/mkpkg/* + The new MKPKG task is now tested and installed. MKPKG replaces both + MKLIB and MAKE (and the mkpkg.com files in VMS/IRAF. The task is + upwards compatible with MKLIB but is much more powerful; see the task + documentation for details. This is a bootstrap utility, hence it is + written in C and makes calls only to LIBBOOT.A (a new library for the + bootstrap utilities) and LIBOS.A. + + Unlike MKLIB, which was originally written as an experiment and which + was never a very good program (it was closely tied to UNIX), MKPKG was + carefully written. In particular, the machine dependent parts were + isolated (as far as possible) to make it relatively easy to port the + utility to new systems, and extensive diagnostics are built in. When + used to update libraries, MKPKG is several times as fast as the original + MKLIB since it uses a file date cache. (12/8) + +host/bootlib/* + A new directory and library (lib$libboot.a). The concept here is to + isolate the machine interface for the C language bootstrap utilities. + As functions are needed by these utilities, new modules are added + to this library. Some of the modules talk directly to the host system, + others to LIBOS, others to both, etc. To bootstrap the utility tasks + (XC, MKPKG, etc.) one must first make the libraries libboot.a and + libos.a. Once these are up the bootstrap utilities can be linked + and used to make the VOS. Once the VOS is up the bootstrap utilities + can be relinked with LIBSYS and LIBVOPS to get full filename mapping. + On a UNIX host the bootstrap version of VFN2OSFN is all that is needed. + (12/8) + +sys/etc/main.x + When a task is run standalone, will now look for the ZZSETENV.DEF in + the system library hlib$ if not found in the current directory. + This will get rid of the (partially system dependent) ZZSETENV.DEF + files scattered about the system, but still make it possible to have + a special version of the file in the local directory for debugging. + (12/8) + +lib/* +hlib/* + Moved the following files to unix/hlib (= host$hlib). The new MKPKG + facility will find the header files in either directory; all files + are still referenced as in source file includes. (12/8) + + cllogout.cl (standard iraf stuff) + clpackage.cl + config.h + iraf.h + libc/ + login.cl + mach.h + math.h + zzsetenv.def + + generic.e (bootstrap utilities) + mkpkg.e + rpp.e + xc.e + xpp.e + + cidir.sh (real UNIX dependent stuff) + dgrep.sh + dupdir.c + dupdir.e + irafuser.csh + mkiraf.csh + nightly.sh + + Now that all these things are out of lib$, a new version of lib$ from + the UNIX development system can be installed on another system by a + simple copy operation, without a time consuming and error prone merge + operation. + +host/boot/spp/xc.c + Removed the IRAFDIR pathname, -r irafdir, etc. stuff. Added references + to the libraries libboot.a and libos.a in the Makefile. Got rid of the + link on the executable and replaced it by a "make install". + The utiltity now makes VFN's of the form "iraf$..." or "host$..." and + calls vfn2osfn() to get a pathname. The latter calls ZGTENV which + references either the environment or the file (as discussed + earlier), hence XC no longer needs to be recompiled when the root + directory is changed. Since vfn2osfn is used references to include + files in subdirectories of a system library (e.g., lib$pkg or lib$math) + are now fully supported. (12/8) + +host/boot/spp/xpp/xppmain.c +host/boot/spp/xpp/xppcode.c + All the same changes as in XC, above. Also added a call to os_sysfile() + to go searching for system include files, which can now be in either + lib$ or hlib$. (12/8) + +host/boot/generic/* + The GENERIC utility was moved into its own subdirectory. Added a + makefile. Got rid of the link to the executable in lib$. Added a + make install to move the .e instead. (12/8) + +host/boot/xyacc + Changed SPP-Yacc subdirectory name to xyacc. Brought Makefile up to + date; added make install to move executable into hlib$. This utility + is really only supported in the UNIX version of IRAF for system software + development, hence did not make it fully autogenerating. (12/8) + +unix/os/* + Made a mkpkg file to maintain LIBOS. Deleted the linked copies of the + kernel.h and kname.h include files, so that now there is only the one + copy in libc. Added an "mkpkg.csh" to bootstrap the library before + the mkpkg utility is up. (12/8) + +host/hlib/clpackage.cl + Added defines for as$ and hlib$. Deleted the define for tmp$ since + this is now a system dependent definition (like iraf$ and host$). + Added a define for imdir$ since this now defaults to tmp$. Added + comments pointing out what is system dependent and what isn't. (12/8) + +sys/vops/apowk.x + Case **0 was setting the output vector to zero rather than one. (12/9) + +sys/etc/sysid.x + If the value of the "userid" environment variable is "USER" (the + default login.cl value), SYSID will now call getuid() to get the + user's host system login name, and use that in the output string + rather than having labels come out as "USER@lyra". (12/9) + +host/boot/generic/* + Cleaned up the code somewhat and added a new $FOR preprocessor + directive for expanding generic sections of code inline. Formerly + the expanded code sections where always written to separate files; + this led to use of UNIX tasks in the Makefiles to generate the files + and concatenate them into a single file. Also added a mkpkg.csh + for bootstrapping the task. (12/9) + +sys/clio/* +sys/etc/* +sys/fio/* +sys/fmtio/* +sys/gio/* +sys/imio/* +sys/ki/* +sys/memio/* +sys/mtio/* +sys/osb/* +sys/tty/* +sys/vops/* + The following were done for each source directory in the VOS: + + o Added a mkpkg file, deleted the Makelib file. In each case + the library module list with include file dependencies was + generated fresh to make sure that all include file depenencies + were noted (these tend to get left out as code is modified). + + o Deleted the local copy of a global files, leaving only the + lib$ version, to avoid problems with links. Converted all + "file" references to local copies of global files to + references. Note that include files which are only referenced + locally do not appear in the system library and are referenced + as "file" in the source and mkpkg files. + + o Deleted all zzsetenv.def files (no longer needed). + + o Deleted any junk files found. + + The mkpkg files are set up in such a way that the library can be + updated either locally, by simply typing "mkpkg", or by running mkpkg + from a higher level in the directory system, e.g., sys$. This + obsoletes the "update" utility. (12/9) + +sys/gio/cursor/keys.hlp +lib/scr/cursor.key + Create a new library directory lib$scr to hold files required at + runtime for output on a terminal screen. Moved the cursor mode keys + file there. This makes it possible to get cursor mode help after + the sources for the VOS have been deleted to save space. (12/9) + +sys/gio/ncarutil/sysint/ishift.s +sys/gio/ncarutil/sysint/i1mach.f + Moved ishift.s to as$. Moved i1mach.f to hlib$. Set up the mkpkg + file to conditionally compile as$ishift.s if found, else it uses the + local ishift.x (which is much slower). (12/9) + +sys/gio/ncarutil/tests + Changed the filenames *.t.f to *t.f for portability reasons. Changed + the names of the files containing tasks from x_file.x to file.x; only + the file x_ncartest.x should have an x_ prefix since it is the only + executable. There was an old version of "strmln" in the directory + which is not used and should probably be deleted (or moved somewhere + else), but I left it in for Suzanne to decide what to do with it. + Set up a mkpkg to make the test package, got rid of the Makefile. + (12/9) + +sys/gio/nspp/* + These directories formerly contained the graphics library used by the + original GRAPH, CONTOUR, SURFACE, etc. programs. These programs have + since been converted to use the new NCAR/GKS/GIO stuff, so most of the + code in these directories was no longer used. The only program in the + system still using the LIBNSPP.A library is the GIO/NCAR graphics + kernel, which talks directly to the NCAR system plot package (nspp) + (I think there may be other package which reference the library, but + they do not need too). + + Accordingly, the gio$nspp directories were pared down to just the + system plot package and associated interface routines. Extensions to + the system plot package used by the NSPP kernel (cell array, etc.) + remain in the gio$nsppkern directory. The system interface code for + LIBNSPP uses some of the same code as ncarutil/sysint; both share the + same machine dependent files off in hlib$ and as$. (12/9) + +host/boot/spp/xc.c +lib/libboot.a +lib/libos.a + Added calls to os_sysfile to generate the library names in XC, allowing + libraries to reside in either lib$ or hlib$. Moved LIBBOOT and LIBOS + to hlib$. (12/10) + +host/boot/spp/xc.c + When linking an executable "file.e", the unix version of XC will now + generate a executable called "T_file.e" in the current directory. + If the link completes successfully the target executable is deleted + and the temp is renamed. This achieves the following: + + [1] If the link fails, the old exectable is not affected and is + still available (particularly useful on the development system + when people may be using the package someone is working on). + + [2] The link will not fail if someone is using the installed + executable, since the linker is not being asked to replace the + installed executable. For similar reasons, the link will not + fail if the installed executable was created by someone else. + + The temporary executable is not deleted if the link fails, since one + might want to examine its symbol table. (12/10) + +sys/imio/imfort* + Move the imfort stuff (Fortran callable image interface) to the + pkg$local directory, since it is only a prototype local interface. + (12/10) + +sys/gio/ncarutil/sysint + Deleted the reference to i1mach.f, since this module is already + present in the VOPS library. (12/11) + +sys/osb/* + Moved the machine dependent files into as$ and hlib$ and set up the + mkpkg to automatically reference these. (12/11) + +sys/tty/* + Moved the "cacheg.dat" and "cachet.dat" files to dev$ and changed the + names to "dev$cacheg.inc" and "dev$cachet.inc" (inc = include file). + This is permissible now since XC calls vfn2osfn() to map the names of + include files, and is desirable since this is a site dependent file. + Combined files zzmktty.x and ttycomp.x and changed the name to + x_mkttydata.x. Set up the mkpkg to install the x_mkttydata.e in lib$ + like all the other system executables. (12/11) + +unix/os/zsvjmp.s + Moved zsvjmp.s to as$. On a UNIX host this was the only machine + dependent file in the kernel. (12/12) + +unix/os/zfpath.x +unix/os/zfsubd.x +unix/os/zfxdir.x +unix/os/zfnbrk.x + Replaced the above files by equivalent C language procedures. This + results in an all-C kernel and eliminates the chicken before the egg + problem on a new system. The C procedures work directly on the XCHAR + strings just like the SPP procedures did, hence their is no + computational penalty (although the use of unpacked strings in the + four procedures is certainly inconsistent with the rest of the kernel, + and I question whether the gain in efficiency is worth it). Deleted + the str.c file introduced a couple of days ago to get a local strcpy. + (12/12) + +unix/os/zfioks.c + Changed a reference to the old symbol IRAFDIR to a call to ZGTENV + to get the pathname of "iraf". (12/14) + +host/boot/spp/rpprat/baderr.r +host/boot/spp/rpprat/synerr.r + The "% character" escapes to pass character*(*) declarations on to the + Fortran did not have the 6 leading spaces required by good ole Fortran, + causing a syntax error. (12/14) + +host/boot/spp/rpp/rppfor +host/boot/spp/rpp/ratlibf + Did a "make fortran" to update the Fortran sources. Several + modifications were made in recent months without updating the Fortran + and testing the software. (12/14) + +(Have completed testing of the automatic bootstrap procedure for the HOST +(directories, and the sysgen procedure for the SYS direcories. The former +(uses "mkpkg.csh" files to bootstrap the bootstrap utilities, and the latter +(of course used MKPKG.) +... + +pkg/system/allocate.cl +pkg/system/deallocate.cl +pkg/system/devstatus.cl +pkg/system/diskspace.cl +pkg/system/gripes.cl +pkg/system/spy.cl + Moved the above machine dependent CL scripts and their associated + parameter files to the HLIB directory, and changed system.cl to + reference the tasks there. (12/14) + +pkg/system/_magtape.x +pkg/system/x_systest.x + Deleted the mtdevlist task which referenced a procedure which has + been dropped from MTIO. (12/15) + +pkg/cl/cldate.c +pkg/cl/builtin.c + Deleted the task version() and the C file cldate.c. This feature + has not been very useful (the date the CL itself was last compiled + or linked is not very interesting) and some machine dependent + machinations are required to generate the date string. (12/15) + +pkg/cl/Makefile +pkg/cl/Makelib +pkg/cl/mkpkg + Deleted the Makefile and Makelib and added a "mkpkg" file. This calls + Yacc and Lex to translate the .l and .y files, but this does not make + the package machine dependent since the translated .c files are all + that is required on machines other than the software development VAX. + The CL should now be 100% portable (except for C bugs). (12/15) + +pkg/cl/tests/ + Deleted the tests subdirectory since the contents were just a bunch + of junk tasks that the authors (including myself) have long since + forgotten about. This stuff should be made to order during testing + by the tester in their own directories, outside of the production + system. (12/15) + +pkg/cl/login.cl + Cleaned up somewhat so that is should work on other systems; removed + all unix pathnames. (12/15) + +pkg/cl/binop.c + Deleted reference "import_mach" to nonexistent include file. (12/15) + +pkg/cl/edcap.c + Deleted reference "import_fio" to nonexistent include file. (12/15) + +pkg/cl/main.c + Deleted the envinit() procedure since we now assume that the essential + environment variables (e.g., iraf, host, tmp, hostid) are provided + somehow by ZGTENV. Changed the library references for the CL login + and logout files (clpackage.cl, cllogout.cl) to reference HLIB rather + than LIB, since these files are site dependent. (12/15) + +pkg/cl/sizes.c + Discovered and deleted this junk (nonfunctional) file. (12/15) + +lib/clpackage.men + Deleted this junk file (the real one is in pkg$clpackage/). (12/15) + +lib/gvset.h +lib/gwindow.h + Deleted these header files as the code which used them (in gio$nspp) + has since been deleted. (12/15) + +lib/xstdgraph.e +lib/xstdimage.e +lib/xstdplot.e +dev/graphcap + The names of these tasks were changed back to x_*.e for consistency + with the rest of IRAF; both UNIX and VMS permit underscores in file + names. (12/15) + +dev/*.tbi + Deleted all the .tbi files (part of termcap, used to initialize tab + stops on terminals). We will probably never use these and they can + be regenerated if ever needed. (12/15) + +sys/vops/acht.x + Added a generic $ifdef to conditionally declare the loop variable I, + so that it is not declared if the loop is not used (else the compiler + generates a warning message). (12/15) + +sys/gio/nspp/portlib/flushb.f + Variable idummy not used; commented out. (12/15) + +pkg/cl/debug.c + Changed the reference to "lib$iraf.h" in d_f() to "hlib$iraf.h". + (12/16) + +pkg/cl/edcap.c + The get_editor() function was opening but not closing the edcap file, + eventually causing the CL to run out of file descriptors and crash. + Also, get_editor() was not saving the name of the editor in the + field "command[EDITOR_ID].keystroke" (not my choice for a name), + hence get_editor was being called every time EHIST or EPARAM was + called. (12/16) + +host/hlib/mkpkg.inc +host/hlib/libc/iraf.h +unix/os/zgtenv.c +host/boot/mkpkg/* + Deleted the logical name "hostid" from ZGTENV and the file. + Only "iraf", "host", and "tmp" are left now at the lowest level. + It turns out that "hostid" is used only in the MKPKG files. Rather + than use a predefined host environment variable I set up MKPKG to + read the system include file "hlib$mkpkg.inc" at startup time. + This makes it easy to set up the system with all sorts of machine + dependent MKPKG configuration parameters and switches, if necessary. + The current list includes HOSTID, XFLAGS (compile), LFLAGS (link), + USE_CCOMPILER, and USE_GENERIC. I anticipate adding switches to + conditionally build various graphics kernels and the like, as these + may reference libraries not present on all systems, and it is a waste + of time to keep a graphics kernel up to date if it will never be + used. (12/16) + +sys/vops/asel.x + The "$t" suffix was missing from the procedure name. (12/16) + +host/boot/generic/generic.c + We have been naming generic SPP and C files with ".x" and ".c" + extensions. This is misleading; the extensions should be ".gx" and + ".gc". Modified the generic preprocessor to generate a file with + a ".X" extension when a generic file with a ".gX" extension is input. + (12/16) + +sys/osb/* +sys/vops/* + Changed the names of all generic sources in OSB and VOPS to use the + extensions ".gc" and ".gx". (12/16) + + +(The following is a copy of some mail sent to the IRAF group) +------------------------- +Anyone calling the generic preprocessor via the new MKPKG facility should look +at OSB or VOPS for an example of how to set it up. The major points are the +following: + + [1] Generic SPP files should have the extension ".gx". The GENERIC + preprocessor has been modified to make ".x" output files when fed + ".gx" input files (in general, ".gX" -> ".X"). + + [2] The generic preprocessor is not a required bootstrap utility except + on our software development VAX; that is why we always keep the + preprocessed output files around. The MKPKG files should be set + up as follows: + + tfiles: + $ifolder (fi.x, f.gx) $generic ... f.gx $endif + (etc) + ; + + libpkg.a: + $ifeq (USE_GENERIC, yes) $call tfiles $endif + @subdir + file.x + (etc) + ; + + Note that the USE_GENERIC symbol is available to test if the local + system has a generic preprocessing capability. This symbol and a + few others are defined in the MKPKG include file hlib$mkpkg.inc, + which is automatically included whenever MKPKG is run. This file + should be very useful for machine dependent conditional compilation, + e.g., we will only build the calcomp graphics kernel (etc) on a system + that sets a switch saying it wants the kernel (if the system does + not have a -lcalcomp library, the package would not even link). + + [3] A new preprocessor directive $FOR (types) ... $ENDFOR has been added + to the generic preprocessor for expanding generic sections of code + inline. This should be used in conjunction with the -o switch to set + the output filename, e.g.: + + $generic file.gx -o file.x + + And inside the file "file.gx", e.g.: + + + + $for (silrdx) + + $endfor + + + ... + +sys/gio/calcomp/mkpkg +sys/gio/nsppkern/mkpkg +sys/gio/mkpkg +sys/mkpkg +host/hlib/mkpkg.inc + Modified the NSPP and Calcomp graphics kernels to keep the kernel + library in lib$, like the stdgraph kernel already does. This is + necessary if an external task is to be able to use the kernel as an + inline kernel. Added switch symbols to the MKPKG include file to + conditionally compile the NSPP and Calcomp kernels, as these will + not be used on some systems. (12/17) + +math/*/mkpkg +pkg/*/mkpkg + The IRAF group members started writing mkpkg files for these + directories, and we began testing. (12/17) + +host/boot/rmbin/ + Added a new utility RMBIN for descending directory trees and deleting + binary files. This is needed to strip the system down to only sources + for a complete rebuild. (12/19) + +unix/os/zfacss.c + The test for a directory file was not correct. (12/19) + +-------------------------- +Numerous changes to the MATH and PKG software were made in the process of +getting the MKPKG based full system generation facilities to work. In the +process many awkward things were fixed, e.g., all the assembler files were +moved to AS, local .x or stubbed out versions were added with MKPKG +conditionals to use them if the AS versions are not found, all old code was +made to use the new lib$pkg and lib$math subdirectories, most of the library +member lists were regenerated, many dead files were deleted, old code that +had not been recompiled in years was recompiled and bugs fixed, etc. The first +error-free full system rebuild (rmbin followed by mkpkg at the root) took place +on the UNIX/750 on 12/21, taking 20 hours single user. +-------------------------- + +unix/boot/wtar/* +unix/boot/rtar/* +unix/boot/bootlib/tape.c (etc.) + Added WTAR to the suite of portable bootstrap utilities. Fixed RTAR + so that it can read from tape as well as disk on non-UNIX systems, + and shares bootlib library procedures with WTAR (and also RMBIN, which + is a lot like WTAR). Only a little of the VMS version of WTAR could + be used due to VMS dependencies spread throughout the code (even if + under #ifdefs). The new version also fixes a number of problems with + the VMS version: IRAF file and magtape names are now used consistently, + case is preserved when transferring filenames to the tape, etc. + + Most importantly, the new RTAR and WTAR are portable above LIBBOOT and + LIBOS (the ZFIOMT driver is used), hence they can be used on systems + like AOS as well as on UNIX and VMS. WTAR is useful even on UNIX + systems due to its ability to omit binary files, e.g., when making + source tapes on the UNIX/VAX for the SUN (not having to remember what + /dev/rmtXX to use is also nice). The old VMS version of WTAR, by the + way, uses a nonstandard VMS/C printf format (e.g., %6.8o) for encoding + the file headers. (12/23) + +unix/os/ufstat.c +unix/os/zfacss.c +unix/os/zfinfo.c +unix/os/zfiobf.c +unix/os/zfiotx.c [UNIX] + Added cacheing of the "stat" information from the last call to the + UNIX system service STAT. This can significantly reduce the number + of system calls in applications that access a lot of files. (12/24) + +host/boot/rtar/rtar.c + Added a switch "-s" to RTAR to strip the extra whitespace added to the + end of text files by WTAR (on VMS). This causes compiles to fail on + UNIX, causes diffs to fail, and in any event the tape utilities should + not modify files. (12/24) + +images/tv/* + Installed the entire TV package from VMS/IRAF, since all the recent + development work has been done there. Reorganized CV with the task + at the top and the libraries in subdirectories, so that it can have + a standard mkpkg. Set up mkpkg to conditionally compile either the + UNIX or VMS device i/o interface. (12/24) + +unix/os/zfiotx.c [UNIX] + Discovered that the unix text file driver will append to any existing + file when called to open a file in NEW_FILE mode. This was never + discovered before because the VOS will always delete any existing file + before opening a new file, but the bootstrap utilities (RTAR) are not + so careful. (12/24) + +images/tv/* + Discovered many declared but not used variables. Also found one used + but not declared variable ("frame" in display/t_display.x). Evidently + these are not found by the VMS compiler. File zsnap.x in CV/iism70 + was referencing ASEL when ASELS was intended. (12/26) + +images/tv/* +host/gdev + The "m70unix" and "m70vms" subdirectories in DISPLAY and CV were + bothersome due to the duplication of code, protrusion of system + dependence into the pkg sources, and limited networking support + for the VMS version of the IIS interface (which was bypassing the + IRAF kernel). To address these problems I added a new device driver + ZFIOGD for binary graphics devices, e.g., image displays, versatec + plotters, and the like. + + This driver is the i/o interface to binary graphics devices; it isolates + the host system dependence of the interface but does nothing about the + device dependence. The GIO driver, on the other hand, deals with the + device dependence but should not be host system dependent. The ZFIOGD + interface is a streaming binary file interface, hence provides a + data driven interface even if the host system device driver is control + driven. The data driven nature of ZFIOGD and its ZFIOBF semantics + make it trivial to support network access via the kernel interface. + + The ZFIOGD driver is logically part of the kernel, but is programmed + in SPP, may share header files with the GIO kernel, and wants to use + high level functions (e.g., memory allocation, string ops), hence is + maintained in LIBSYS rather than LIBOS. The sources are in HOST$GDEV + since this is partially system dependent code. ZFIOGD can support + any number or set of actual graphics devices without change to the KI. + Currently only the IIS M70/M75 is supported. The new interface for + UNIX has the advantage of permitting an IOCTL call to master clear + the IIS at device open time (since we no longer assume that it is a + simple binary file, we can do anything we want). (12/26) + +sys/imio/imdmap.x +pkg/images/tv/display/* +dev/*.imh + Setup up IMDMAP to open the image header in memory (as a NEW_IMAGE) + without accessing the .imh file in DEV. Deleted the .imh files; + once the MTIO lock file is gone we can remove world write permission + and quota on DEV$. IMDMAP now uses graphcap to get the device + parameters and initializes the in-core image header structure + accordingly. (12/27) + +sys/fio/delete.x + DELETE will now ignore attempts to delete "dev$null". (12/27) + +unix/as/*.s [UNIX] + It turns out that the UNIX assembler makes branch labels global unless + they begin with an "L". Renamed a number of branch labels with + cryptic LXX names so that they will not be kept in the symbol table + (they would come out looking like functions in profiles) (12/28) + +unix/as/aclr.s + Added a fast assembler version of ACLR. (12/28) + +pkg/images/tv/display + Tested, debugged, optimized. (12/28) + +pkg/images/tv/cv/* + Brought up to date, now uses same bottom end as display. (12/28) + +------------------------- +[Begin diff/merge of revisions from VMS/IRAF] + +sys/etc/maideh.x + Message buffer size increased from 64 to SZ_LINE. (12/28) + +sys/etc/propdpr.x + New version with support for queueing of bkg jobs installed. (12/28) + +sys/etc/tsleep.x + ztslee -> zwmsec. (12/28) + +sys/fio/fgetfd.x + Added "int or()". (12/28) + +sys/fio/fwtacc.x + Modified to return not accessible for directory files; such files + cannot be read as ordinary files on some systems. (12/28) + +sys/fio/osfnlock.x + Modified to temporarily override ONECASE_OUT; no longer does any + case conversion at all. This is necessary for the kernel interface + and is fairly safe since few systems with case insensitive filenames + permit only single case names as input (if such is the case, the + kernel will probably do the case mapping in any case). (12/28) + +sys/fio/vfnmap.x +sys/fio/vfntrans.x + Installed vms/iraf versions without change. Numerous minor bug + fixes, ztslee -> zwmsec, bug fix in initialization of extn map, + etc. (12/28) + +sys/fmtio/ctol.x + Modified to permit + as well as - (but much more than that is req'd + before IRAF permits + in numbers everywhere). (12/28) + +sys/fmtio/dtoc.x + IS_INDEF -> IS_INDEFD. (12/28) + +sys/fmtio/parg.x + The int(dval) would cause integer overflow when DVAL was a floating + point number with a very large exponent. (12/28) + +sys/fmtio/strtbl.x + Array argument declaration buf[nstr] changed to buf[ARB] to avoid + VMS/Fortran runtime error if nstr==0. (12/28) + +sys/gio/glabax/glbfind.x + Two bug fixes: invalid tick calculation causing floating point + overflow; inability to turn tick drawing off with GSET option. (12/28) + +[[[[ I am finding a lot of revs and bug fixes in unix/iraf that have not yet +[[[[ made it into vms/iraf; we need to update vms/iraf as soon as the merge +[[[[ is completed and mkpkg, etc. is working in vms/iraf.... + +sys/gio/nsppkern/pixels.f + Arguments to ISHIFT were not both of the same type. (12/28) + +sys/imio/imsetr.x + Min/max argument type mismatch. (12/28) + +sys/imio/imwrite.x + When extending the pixel file at EOF, would write one too many chars, + causing pixels to be written and then read back at different file + offsets (never happened on UNIX/IRAF because pixel files are always + preallocated). (12/28) + +sys/ki/kbzstt.x + Now returns the min of the max network transfer size and the max + device transfer size, rather than the value of the device parameter, + which can be larger than the network interface can handle. (12/28) + +sys/ki/kopdpr.x + Added support for queued bkg jobs. (12/28) + +sys/libc/cfmapfn.c + Argument maxch passed by value rather than reference. (12/28) + +sys/libc/cprdet.c + Added support for queued bkg jobs. (12/28) + +sys/libc/ctype.c [TEMPORARY] + Added #ifdef vms globalvalue junk for the VMS linker. (12/28) + +sys/libc/cxwhen.c + Deleted the code for c_xgmes, since it has been moved out into a + separate file. (12/28) + +sys/libc/isatty.c + + New operator added to LIBC. Used by the CL to test if the process + stdin is a terminal. (12/28) + +sys/libc/cfnames.c + + New operator added to LIBC. Used to parse filenames. (12/28) + +sys/fio/vfntrans.x + The filename extension map common was still not portable, since the + map string itself was being initialized in the common with a data + statement. Also, the compiler would give a harmless but annoying + warning message about mismatched lengths for the common. The code + was modified to fix both of these problems. (12/29) + +sys/ki/kbzstt.x + Local variable status never used. (12/29) + +sys/osb/f77pak.f + The exit test in the last loop (for blank fill) would do a "next" + rather than a "break", causing the loop to needlessly run on until + the top index was reached. (12/29) + +sys/osb/xor.x + The expression for the exclusive-or in terms of AND and OR was + incorrect. (12/29) + +sys/vops/aiftrx.x + Replaced the amovr(a,b,npix) by amovx(a,b,npix/2+1), since the input + vector is the complex transform. (12/29) + +sys/vops/acnv.x +sys/vops/acnvr.x + In the npix=5 case, K4 was being assigned into instead of K5. (12/29) + +hlib/libc/knames.h +lib/knet.h +sys/ki/irafks.x +sys/ki/kfiogd.x +sys/ki/mkpkg +sys/ki/ki.h + Added network support for the ZFIOGD driver. (12/29) + +os/alloc.c + [UNIX] +os/zalloc.c + [UNIX] +hlib/alloc.e + [UNIX] +hlib/libc/alloc.h + +hlib/libc/iraf.h +hlib/libc/knames.h +hlib/knet.h +ki/kdvall.x +ki/kdvown.x +ki/ki.h +ki/irafks.x +dev/devices KERNEL CHANGES +----------------------------------------------------------------------------- + Added two new routines ZDVALL and ZDVOWN to the kernel. These are + used to allocate and deallocate (and mount) devices, and to query + device allocation. Allocation over the network is implemented but + will not currently work for a VMS host due to the process structure + (it will work for UNIX, as usual). + + zdvall (device, status) + zdvown (device, owner, maxch, status) + + A device table DEV$DEVICES was also added to runtime parameterize the + allocatable devices. This table is read by the VOS, passing only + host system device names to the kernel. The table will also be used + to get the host device name to open a magtape. + +sys/zfiomt.c + The logical drive argument to ZZOPMT and ZZRWMT is now the physical + drive name as the VOS does the mapping using the dev$devices table. + +hlib/libc/kernel.h + Deleted magtape device table. With this change the last of the + compile time device tables are gone from IRAF. (12/31) +----------------------------------------------------------------------------- + +dev/termcap + Added an entry for the Visual 500 terminal (contributed by Skip + Schaller, Steward Obs.) (12/31) + +sys/fio/getlline.x + Added a new utility procedure to the FIO package. GETLONGLINE is + like GETLINE except that it knows about comments, blank lines, help + sections, and backslash newline continuation. Comments, blank + lines, and help text are ignored and long lines are joined, returning + long lines of a user specified maximum length to the caller. (12/31) + +lib/xalloc.h +sys/etc/xalloc.x +sys/etc/xgdevlist.x + Added a device allocation package to the VOS. + + xallocate - allocate device + xdeallocate - deallocate device + xdevowner - determine if device is allocated + xgdevlist - get device list from dev$devices + + status = xallocate (device) + status = xdeallocate (device, rewind) + status = xdevowner (device, owner, maxch) + status = xgdevlist (device, devlist, maxch) + + status: + OK operation succeeded + ERR cannot allocate device + error i/o failure, e.g., dev$devices file not found + + DV_DEVFREE device is free and can be allocated + DV_DEVALLOC device is already allocated + DV_DEVINUSE device is in use by someone else + DV_DEVNOTFOUND device not in device table + + If the device is a magtape, xallocate will call mt_allocate to create + the "lock" file (not actually used as a lock anymore, just to record + the position), and xdeallocate will call mt_deallocate. (12/31) + +sys/mtio/* +unix/os/zfiomt.c [UNIX] + The following changes were made to MTIO. + + [1] The "lock" file is still used to keep track of the tape + position after task termination, but it is no longer used + to lock the device (the XALLOC code performs that function). + Any existing lock file will be overwritten at allocate time. + The lock file can be deleted while the drive is in use without + harm; MTIO will merely rewind the tape to get to a known + position. + + [2] The lock file is now written into UPARM rather than DEV, and + world write permission has been removed from DEV forever. + With this change, the only place world write permission is + still required is for the gripesfile. + + [3] The lock file is no longer read and written every time the + drive is opened and closed. Instead, MTIO caches the position + between opens and only updates the lock file at task + termination time (or if error recovery takes place). Hence, + a DEVSTATUS after reading a tape will work as before, but + accessing multiple files in a single call to a task should + be speeded up considerably. (12/31) + +sys/etc/onerror.x +sys/etc/main.x + Procedures posted with ONERROR during task execution are now called + at task termination, whether the task terminates normally or abnormally. + The task termination code will be OK if the task terminates normally, + else it is the error code passed to ERROR, FATAL, SYSERR, etc. This + feature is used by MTIO to update the lock file at task termination + time. It appears that there was also a bug in the old implementation, + i.e., the posted error handlers were not getting cleared following + normal task termination. (12/31) + +sys/etc/error.x + The system will now quietly do a max(errcode,1) to guarantee that an + error exit will not be confused with normal task termination, in case + the lazy programmer is calling ERROR with errcode=0. (12/31) + +pkg/dataio/fits/read_fits.x + When just reading the fits headers (make_image=no) will now immap + DEV$NULL rather than a real disk file, to eliminate the overhead + associated with writing and then deleting a scratch image header. + (1/2) + +unix/os/zfiomt.c [UNIX] + The unix MTIO driver will now backspace over the first tape mark when + writing at EOT, to save one interrecord gap between files. The skip + record forward primitive was changed to do a READ rather than an IOCTL + since all drivers do not return EOF when an IOCTL skip record passes + a tape mark. (1/2) + +(new MTIO tested and debugged, 1/2) + +sys/fio/diropen.x +unix/os/zopdir.c [UNIX] + Changed the VOS to skip "." prefixed files (as well as the normal + hidden files with reserved extensions) if a directory is opened with + skipping of hidden files enabled. Change ZOPDIR to NOT filter out + .xxx files. This makes it possible for the VOS to access .xxx files, + and eliminates a difference between the UNIX and VMS versions of the + system. (1/3) + +hlib/libc/xnames.h +sys/libc/callocate.c + Added C language bindings for the VOS device allocation facilities. + (1/3) + +pkg/cl/builtin.c + Revised the device allocation stuff to use the new VOS facilities. + (1/3) + +hlib/allocate.cl +hlib/deallocate.cl + Modified these scripts to call the hidden CL tasks _allocate and + _deallocate, which do the real work. The new scripts are actually + machine independent and do not really need to be scripts, but have + been kept as scripts to avoid changing the user interface and to + provide scope for adding machine dependence if necessary. (1/3) + +unix/os/zfiotx.c [UNIX] + I had thought that the unix fseek returned the new file position in + the case of a successful seek (like lseek), but evidently it returns + zero instead. This would cause the file position to be lost if there + were more than one seek on a text file. This explains part of the + problems we have been having with PROCEDURE scripts in the UNIX/IRAF + CL. (1/3) + +pkg/cl/grammar.l + In the process of fixing the above bug, I thought I had found a problem + with comments in the command mode lexical analyzer. I changed the + comment eater to fix what turned out not to be a problem, but left the + revision in because it should process comments more efficiently than + the previous code (which used .* to match the comment). (1/3) + +sys/mtio/mtstatus.x + +etc/xalloc.x + Added a new procedure XDEVSTATUS to ETC to print the status for a + device; if the device is an allocated magtape, this calls MTSTATUS + to print the contents of the lockfile. (1/3) + +pkg/cl/builtin.c +hlib/devstatus.cl + Added a new hidden task _devstatus to the CL; modified the DEVSTATUS + script in the SYSTEM package to call this. (1/3) + +(MTIO revision completed and tested) +-------------- +Begin merge VMS/IRAF CL revisions into UNIX CL (1/4) + +pkg/cl/bkg.c + Installed vms version; contains modifications for bkg job queues. + +pkg/cl/builtin.c + Minor revs from vms version merged in (documented in vms notesfile), + plus of course the all-new device allocation stuff from unix/iraf. + +pkg/cl/cmain.c + Deleted this obsolete junk file. + +pkg/cl/decl.c +pkg/cl/eparam.c +pkg/cl/exec.c +pkg/cl/grammar.y +pkg/cl/lexicon.c +pkg/cl/modes.c +pkg/cl/prcache.c + Replaced by vms versions. + +pkg/cl/grammar.l + Merged in &queue modifications. + +pkg/cl/lex.sed + Added sed command to increase YYLMAX allocation from 200 to 2048. + +pkg/cl/main.c + Merged minor revs in both versions. + +(end merge) (1/4) +---------------- + +pkg/cl/eparam.c + Replaced a STRCHR by INDEX; would not compile on UNIX as there is no + STRCHR function. (1/4) + +pkg/cl/modes.c + There was an unmatched { and the file would not compile; went and + looked at the vms version and the same bug was found there. Probably + the VMS Mklib failed to recompile the file, so I never found the + bug. (1/4) + +pkg/cl/builtin.c + Deleted unused variable buf in clsleep(). (1/4) + +pkg/cl/system.c + Deleted unused variable stat. (1/4) + +pkg/cl/edcap.c + Function what_cmd would return an undefined function value if the + match loop terminated at nchars. Added a return(0) at end of + function. (1/4) + +pkg/cl/eparam.c + eparam.c(139): warning: op unused in function ep_setoptions + eparam.c(590): warning: out unused in function e_check_vals + eparam.c(744): warning: argument maxch unused in function e_getfield + eparam.c(1012): warning: op unused in function eh_setoptions (1/4) + +pkg/cl/exec.c + Variable ip unused in execnewtask(). (1/4) + +pkg/system/_magtape.x - +pkg/system/x_system.x +pkg/system/system.cl + Deleted tasks mtallocate and mtdeallocate, and file _magtape.x (1/4) + +pkg/system/directory.x + Now calls strtbl only if nfiles > 0. (1/4) + +pkg/system/system.hd + Various changes to bring it up to date. Added a couple of new manual + pages to system/doc. (1/4) + +pkg/language/doc + Updated from vms/iraf. We plan to edit these at some point to more + closely approximate our standard manual page format. (1/4) + +host/boot/bootlib/tape.c + Now knows about DEV$DEVICES. Accepts either logical drive names + such as "mta" or "mta.1600", or host names such as "mt.MUA0:" or + "mt.mua0.1600" (e.g., if dev$devices is not up yet). (1/4) + +sys/gio/cursor/grcpage.x +sys/gio/cursor/grcwaitp.x + + Moved grc_waitpage out of grcpage.x into a separate file to fix a + circular library reference preventing topological sorting of the + library LIBCUR. Circular library references such as this have + not been a problem on UNIX or VMS since the libraries are randomly + accessed at link time, but some systems (e.g., AOS) access libraries + sequentially, and in any event linking from a topologically sorted + library is faster, and circular references are probably dangerous. + (1/4) + +(sys/gio/cursor/prpsio.x) +pkg/cl/main.c +hlib/libc/xnames.h +sys/gio/cursor/gtr.com +sys/gio/cursor/psioinit.x + +sys/gio/cursor/psioxfer.x + +sys/gio/cursor/psioisxt.x + + PRPSIO is the traffic controller for pseudofile i/o. There is a + circular library referencing problem with this routine, wherein + prpsio might call gtrctrl which might call gtropenws which references + the entry point address of prpsio in a call to LOCPR if the GKI + kernel is a subkernel (gtropenws does not actually call prpsio, + however, so the reference is not reentrant). + + This can be fixed by computing the EPA of prpsio at a higher level + and letting the lower level code use the value as data. This will + fix the topological ordering problem, but the fact that the problem + occurred at all makes one wonder if reentrancy is really ruled out. + Investigation of GKI reveals that it is indeed possible for PRPSIO + to call itself indirectly by calling GIOTR which calls GKI (but only + if certain graphics instructions are encountered at run time when + a subprocess is talking to a subkernel). + + This problem can be resolved by some restructuring of PRPSIO, and + will probably have to be resolved before we have fully functional + i/o to graphics subkernels. The problem is however too complex + and too risky of solution to be dealt with at the present time, + and aside from the library ordering problem we have not had any + problems with the present code. + + The temporary solution is for the CL to put the EPA of the PRPSIO + procedure in the GTR common at startup time. This gets around the + circular library reference problem for the moment, but does nothing + about the reentrancy problems. The two PRPSIO subprocedures were + also moved out into separate files. (1/4) + +sys/gio/gadraw.x +sys/gio/wcstogki.x + +sys/gio/gplflush.x + + Moved the gpl_wcstogki and gpl_flush procedures out of gadraw.x into + separate files to fix a library ordering problem. Deleted the + gpl_gviewport procedure at the tail of the gadraw.x file, since it + is an internal procedure which is apparently no longer used anywhere. + (1/4) + +sys/gio/ncarutil/concom.f - +sys/gio/ncarutil/conterp.f - +sys/gio/ncarutil/conlib/ + + Unpacked the two NCAR files concom.f and conterp.f in the subdirectory + conlib, one subroutine per file, to permit topological ordering of the + libncar library. (1/4) + +sys/fio/fstati.x +sys/fio/ffilsz.x + Removed the syserr() calls from FSTATI (which calls FFILSZ) due to + library ordering problems, and probably reentrant code problems too. + FSTATI is too low level to be calling higher level code, e.g., + it is called by ENVGETS, by the ZFIOCL driver, and other low level + codes. (1/4) + +sys/etc/environ.x +sys/etc/envinit.x + +sys/etc/envgets.x + + Moved the ENVINIT and ENVGETS procedures out into a separate files + since they call high level functions. (1/4) + +sys/fio/xerputc.x + Changed this routine to use a local array to buffer the output line, + rather than the FIO pathname buffer, just to make sure no conflict + ever occurs. (1/4) + +sys/etc/erract.x + Replaced the call to PUTLINE to output the warning message to STDERR + by a call to ZAWRPS, for obvious reasons. (1/4) + +sys/memio/malloc.x +sys/memio/realloc.x + Replaced all ERROR, SYSERR, FATAL, etc. calls by calls to SYS_PANIC. + Dynamic memory allocation is fundamental, and is used even in the KI. + The error handling code calls the kernel zroutines to talk to files + and the CL, the zroutines use the KI, which calls MEMIO, which used + to call the error handling code causing circular library references + and possible error recursion. (1/4) + +sys/ki/kigchan.x + FATAL replaced by call to sys_panic. (1/4) + +sys/ki/ktzopn.x + Had an IFERR, which calls XERPOP, which calls .... (1/4) + +--------------------- +Begin merge of AOS revs. + +pkg/cl/bkg.c + Added declaration: extern long c_clktime(); (1/5) + +pkg/cl/task.h +pkg/cl/mem.h + The macros NEXT_TASK and DEREFERENCE coerce a pointer to unsigned + and add a byte offset. This does not work on byte addressed machines + since we are then adding a byte offset to a word pointer. Replaced + the "(unsigned)ptr" references by "(unsigned)(char *)ptr". (1/5) + +pkg/system/help/nomore.x +pkg/system/delete.x +pkg/system/match.x +pkg/system/page.x +sys/fio/fclobber.x [IMPORTANT PORTABILTY NOTE] +sys/fio/vfnmap.x +sys/fmtio/evexpr.y +sys/fmtio/evexpr.x +sys/gio/stdgraph/stgrcur.x +sys/tty/ttyopen.x + It turns out that the Fortran standard does not permit expressions + of the form BOOL.EQ.BOOL, although most real compilers are not so + stupid. Fortran requires that such expressions be written as + BOOL.EQV.BOOL, i.e., the .EQV. and .NEQV. operators must be used + to compare booleans for equality. The current preprocessor is not + capabable of fixing such expressions, hence all occurrences of such + equivalences must be fixed in the code; fortunately the construct + is rare. (1/5) + +host/boot/spp/rpp/rpprat/gtok.r +host/boot/spp/rpp/rppfor/gtok.f + The B = 10 * B + C - 48 would cause fixed point overflow for large + numbers. Radix conversion is not needed in RPP (since it is done + in XPP) hence the code was changed to simply accumulate the numeric + token. The Fortran translation file was updated. (1/5) + +sys/fmtio/dtoc3.x + For the AOS compiler, had to convert + + v = v + 0.5 * 10. ** -no_digits + to + v = v + 0.5 * 10. ** (-no_digits) + + This is a bug in the AOS compiler, but we loose nothing by changing + the SPP code to workaround it. (1/5) + +sys/os/*.c + Changed all occurrences such as "return (*status = XERR);" to the 2 + statement form which does not return a function value, since the Z + routines are Fortran callable subroutines not functions (this caused + a problem with the AOS Fortran optimizer, i.e., not saving a register + or something - AOS uses part of the UNIX kernel as is). (1/5) + +------------------ +End of AOS bug merge. + +------------------ +(begin SUN merge) + +host/boot/spp/xpp/decl.c + Modified to break output declaration lines when they exceed 80 columns. + Formerly lines were broken arbitrarily after 8 arguments; this would + fail, of course, when the argument names or the procedure name were + large. (1/5) + +[IMPORTANT PORTABILITY NOTE] + The SUN version of 4.2BSD buffers the C stderr output when redirected + just like stdout. Output to stderr is not automatically flushed when + a newline is seen. If the output from a program which writes to both + stdout and stderr is redirected, output will come out mixed up unless + fflush(stderr) is called after every write to stderr. 4.3BSD UNIX + also buffers stderr for efficiency reasons, hence this change in the + semantics of C stdio may be permanent. + + (all of the new bootstrap utilities call fflush, but some of the old + (ones probably don't, yet). + +host/boot/spp/*.c + Added fflush(stderr) after all writes to stderr in C files in these + directories. (1/5) + +------------------- +End of SUN revisions (so far). + +host/hlib/iraf.h +host/hlib/libc/iraf.h +host/hlib/libc/libc.h +host/hlib/libc/knames.h +host/hlib/libc/names.h +host/hlib/libc/knames.no_ +host/hlib/libc/names.no_ + Added a new define F77_NO_ to . This is defined to tell LIBC + that Fortran external names do not use the trailing underscore. If so, + loads the .no_ files instead of the .h files. This does not + solve the problem of machine dependent external names, but should help + quite a bit since it works for our major systems. I also change the + names of all the VOS procedures with names likely to collide with host + or C library names if the underscores are removed. The names are also + redefined in the SPP iraf.h, and the redefined names are used whether + they are needed or not (i.e., they are used on UNIX, too). This should + simplify debugging as one need only learn one set of funny names. (1/5) + +sys/libc/fseek.c + Changed the LIBC unix emulation FSEEK to return OK or ERR to conform + to UNIX. It formerly was a long function returning the new position, + which is not the way UNIX does it (see ZFIOTX bug above). No existing + C code was affected by this semantic change. (1/6) + +pkg/cl/builtin.c + GFLUSH was flushing only STDPLOT; modified to flush all three std + graphics streams. (1/6) + +sys/gio/gopen.x + Changed argument one of gexfls_set from FD to OUTFD. (1/6) + +sys/gio/gclose.x + The test for a pseudofile output stream was based on READ permission + on the output file. That seems like a poor criterion, so I changed it + to a simple numerical test (regular file if fd > STDPLOT). Also, if + GOPEN opens the stdvdm file then GCLOSE had better close it, so I + added a test for that case. Note that GCLOSE does not normally close + the output file, since the user would normally open it before calling + GOPEN. (1/6) + +sys/fio/fdebug.x + Added pargstr for APPEND mode. (1/6) + +sys/tty/ttyopen.x + Formerly used a construct "while (IS_WHITE (getc (fd, ch)))" which + is illegal because the IS_WHITE macro makes multiple calls to the getc + function. (1/6) + +sys/etc/lpopen.x + Now recognizes the special device "text", which has a termcap entry + and is used to get ascii LPRINT output on the standard output. (1/7) + +sys/tty/tty.h +sys/tty/ttyputl.x + Optimized TTYPUTLINE for the common case where the output line of text + contains no special control characters. This routine was probably the + main contributor to the inefficiency of LPRINT. (1/7) + +dev/termcap + Changed the number of lines per page from 66 to 64 for the Versatec + entries, as otherwise formfeed sometimes causes entire blank pages to + be output. Also, overstrike does not appear to work for the Versatec, + so the OS capability was removed from the termcap entries for these + devices. This will cause standout mode text to be printed in upper + case. (1/7) + +pkg/system/lprint.x + Lprint moves pages of text one tab to the right if the output device + is a printer with a wide page. This would cause problems if the + first char on a line was a formfeed, since formfeed breaks a line. + The remainder of the line following the formfeed would come out one + tab to the left; this was causing manual page headers to be misaligned + when printed on the Versatec. Added a test for a formfeed at the + beginning of a line to fix the problem (not a very general solution). + (1/7) + +sys/etc/main.x +sys/etc/onerror.x +sys/etc/onexit.x + Added runtime initialization of the commons of the ONEXIT and ONERROR + procedures. Formerly we were depending upon the linker to initialize + the commons to zeros; this is the case on most systems, but cannot be + assumed in portable code. (1/10) + +hlib/libc/error.h + Added defines for the SYS_XXXX error codes, as in . (1/10) + +unix/os/zoscmd.c +host/boot/mkpkg/* + Modified ZOSCMD to return SYS_XINT in the event of an interrupt, and + to guarantee that it is not returned if an interrupt does not occur. + Changed the value of the INTERRUPT status code in MKPKG to SYS_XINT. + The ordinary value in use at first was getting returned on occasion + when an interrupt did not occur, causing MKPKG to terminate when it + should not. (1/10) + +host/boot/spp/xpp/xppcode.c + Modified to output the SAVE statement before any DATA statements. + We discovered this violation of the F77 standard in a recent experiment + trying to compile IRAF code on a beta release of 4.3BSD UNIX, which + is evidently more strict about the F77 standard than 4.2BSD. (1/11) + +sys/imio/imopsf.x + Moved the call to function FDEVBLK in the argument list of IMIOFF + out into a separate statement and added an ERRCHK for it, so that + IMIOFF is not called if an error occurs in FDEVBLK, causing it to + return a zero block size. (1/11) + +sys/imio/imioff.x + Replaced the BLKSIZE variable in the call to the MOD function in + IMALIGN by max(1,blksize), to avoid integer divide by zero if the + block size is zero. (1/11) + +host/as/zsvjmp.s [UNIX] [IMPORTANT KERNEL NOTE] + It turns out that UNIX only aligns commons on longword boundaries + by default (as does VMS). This can lead to pointer misalignment + problems when accessing data of type DOUBLE or COMPLEX in a buffer + with page alignment, e.g., a FIO or IMIO data buffer. In other + words, forcing page alignment on a dynamically allocated buffer + will result in the buffer not being aligned for SPP pointer references + of type DOUBLE and COMPLEX, if the MEM common is not also page aligned. + This has turned out to be a problem on both UNIX and VMS, although + in both cases there has been a simple solution. + + In the case of UNIX I have arranged for the MEM common to be located + at location zero at link time. This has the following results: + + [1] Since MEM is at virtual address zero, it is aligned for all + machine datatypes as well as page aligned. + + [2] Debugging is easier since MEM is not at some arbitrary offset. + SPP pointers become almost equivalent to real pointers. To + convert an SPP pointer into a virtual address, subtract one + and multiply by the number of bytes (2, 4, or 8) per element. + For example, if X is a pointer to INT, the ADB address of + the integer pointed to by X is given by + + byte_address = (x - 1) * 4 + + [3] Having MEM located at zero has the significant benefit that + uninitialized pointer references are likely to cause a memory + fault, rather than causing some arbitrary region of memory to + be overwritten. In particular, dereferencing a NULL pointer + will cause a reference to location -2, -4, or -8, causing a + memory violation. Also, address 0 is in the read protected + text segment, so small pointer values should also cause a + memory fault when writing to the referenced location. + + The assembler directives required to locate MEM at location zero have + been placed in ZSVJMP.S for Berkeley UNIX, for the simple reason that + it is the only assembler module in the kernel, and it is linked into + every process. This is obviously a very machine dependent solution to + the problem. (1/11) + +dev/vi.ed + I'm not sure how, but ^P and ^N were being used for MOVE_START and + MOVE_END, rather than the more logical PREV_PAGE and NEXT_PAGE. + The latter commands were not even in the menu. Added NEXT_PAGE and + PREV_PAGE as ^N and ^P, and changed the escape sequences for the + MOVE commands to something more obscure (in the process of tracing + this down I found an obscure bug in the new ttyputline; EPARAM is + great for finding bugs, as the i/o is so complicated). (1/11) + +pkg/cl/grammar.y +pkg/cl/gram.c + In grammar.y, changed posit and inarglist variables from static to + global. In gram.c, modified crackident() to treat keywords as ordinary + identifiers in argument lists and expressions. Formerly the CL would + abort on a syntax error upon entry of commands such as + + help xxx.hlp file+ + or + wcardimage alpha,beta for=i5 + + The point is that it is easy to accidentlayy enter a keyword name when + abbreviating a parameter name or entering an unquoted string; when this + happens the user has no idea what they did wrong. A syntax error is + easily avoided by making crackident() context sensitive. I could also + have turned keywords off in declaration lists, but did not do so to + minimize future merge problems with the ST version of the CL. (1/12) + +sys/gio/stdgraph/stginit.x + The device name string was being saved by stg_init(), but the pointer + to the string was not being set in SG_DEVNAME(g_sg). The bug was + harmless but would cause the stdgraph kernel to reinitialize itself + from the graphcap on every call to open workstation. (1/12) + + This is the first uninitialized pointer bug caught by the loc(mem)=0 + revision noted above! + +sys/gio/cursor/rcursor.x + Another uninitialized pointer problem. In rcursor, grc_open() was + being called before the descriptor pointed to by RC was allocated + and initialized by grc_init(). (1/12) + +pkg/cl/exec.c + Replaced call to prparamval() in printcall() by lower level procedures + which do not call cl_error(). Printcall() is called by killtask() + during CL error recovery, and error recursion followed by panic + shutdown will result if cl_error is called during killtask. (1/12) + +pkg/cl/builtin.c + Fixed a bug in clflprcache() so that everything is not flushed if + the named task is not found in the cache. (1/12) + +sys/fmtio/lexdata.inc + This was a fix to lexnum for a bug reported by ST. The fix made at + ST was not correct. The entry for cc=ED in state 10=RFR was QRX + but should have been RFX. The routine is almost impossible to figure + out by just studying the code; you need to look at the state diagram + in fmtio/doc/lexnum.hlp. A more serious problem is that the routine + is not very efficient. While in the neighborhood I made a couple + of simple optimizations which should speed it up significantly, + although it is still not very efficient. A simple brute force, + special case recognizer would probably have been fastest, but the + current code is reasonably compact and correctly handles a lot of + special cases. (1/12) + +pkg/system/help/help.hlp + Fixed a typo. (1/12) + +pkg/system/help.par +pkg/system/help/help.h +pkg/system/help/help.hlp +pkg/system/help/modtemp.x +pkg/system/help/t_help.x + Modified the default action of HELP to print help only for the first + module matched by the template, rather than all modules matching the + template. Since the current package is searched first, the first + module matched is likely to be what the user expects. If user wants + help for a task for which there is no help file in the current + package searching will continue elsewhere, but this is not considered + a bug since there should be help for every task in a package. + A package does not have to be loaded to get help on a module therein. + A new boolean parameter ALL was added to the help parameters with + default value NO. If the value is set to YES, HELP will behave as + before, i.e., it will print help for all modules in the help database + matching the given template. The value of ALL automatically defaults + to YES if a pattern matching metacharacter is present in the module + template entered by the user. (1/12) + +pkg/local/mkpkg +pkg/local/local.cl +pkg/local/x_local.x +pkg/local/t_mpc.x + +pkg/local/imcntr.par + +pkg/local/radplt.par + + Installed the interim MPC-like image centering and radial profile + plotting tasks (contr. by G. Jacoby) in the LOCAL package. (1/12) + +pkg/local/peritek/* + Cleaned up the package. Fixed it to get OS channel codes correctly + whether or not the KI is in use. Move the UNIX peritek IOCTL defs + file into the directory so that it will compile on all hosts. Set + up LOCAL mkpkg so that the Peritek stuff will not be compiled at all + except at NOAO. (1/12) + +pkg/vops/*.x +pkg/vops/*.gx + Replaced all "a[npix]" type variable array dimension declarations + by "a[ARB]". The former declaration would cause a runtime abort + on VMS if the procedure were called with NPIX=0. (1/13) + +lib/gio.h +sys/gio/gopen.x +sys/gio/gclose.x + GCLOSE would close the output file if GOPEN opened device "stdvdm", + but did not open the output file (i.e., if the user opened the output + file before calling GOPEN). Added a new flag word GP_GFLAGS to the + GIO descriptor and allocated one of the bits for a flag to tell + GCLOSE whether or not to close the output file. This removes all + ambiguity and should rule out any more bugs. (1/13) + +unix/os/zfiobf.c [IMPORTANT KERNEL NOTE] +sys/fio/fgetfd.x + When opening a binary file in APPEND mode, FIO has to read the partial + block at the end of the file in order to append data to it. Read + permission is therefore required on a binary file opened in APPEND mode. + The read perm bit was restored in FGETFD, and ZOPNBF was modified to + open the binary file with read-write permission. Note that this + requires that ZOPNBF create the file if it does not already exist, + since the UNIX open() will abort when trying to open an nonexistent + binary file for read-write access. (1/14) + + NOTE -- Appending to an odd size binary file did not work at all prior + to this bug fix (except back when FIO was first written). + +pkg/cl/exec.c + The following command would cause a syntax error: + + cl> printf ("!cat junk") | cl + + The lexmodes=yes lexical analyzer was not recognizing beginning of + line, causing the ! operator to be interpreted as YOP_NOT instead + of YOP_OSESC. Added a lexinit() when a new cl() is pushed in + execnewtask(). (1/14) + +host/os/zoscmd.c [UNIX] + Fixed a bug that was calling bkg MKPKG jobs to see interrupts. The + special zoscmd interrupt handler was being posted even when interrupts + were already disabled in the parent process. (1/15) + +sys/vops/amap.gx + Was using integer arithmetic to calculate the mapping coefficients. + (1/15) + +sys/gio/glabax/glbsview.x + Increased the amount of space at the left of the plot to avoid + truncation of numbers printed in scientific notation (unfortunately, + the plot will also be smaller as a result). There was also an error + in the computation, the presence of the x label and ticks was being + used to compute the xwidth, whereas it is the y label and ticks which + affects the x width of the plot. (1/15) + +pkg/system/beep.x +pkg/system/clear.x +pkg/system/sleep.x +pkg/system/time.x +pkg/system/revisions.cl +pkg/system/revisions.par +pkg/system/doc/... + Deleted the above files and their manual pages (these tasks were moved + to the language pkg some time ago). The REVISIONS task will come back + later in a more useful and efficient form. (1/15) + +sys/imio/imunmap.x +sys/imio/imdelete.x + IMIO has been modified to set file protection on image header files + at imunmap time on a new image or new copy image. This will prevent + creation of zombie pixel files by accidental use of DELETE rather than + IMDELETE to delete images. Unfortunately, this also prevents use of + file protection to protect an image from deletion by IMDELETE, but + at least at NOAO, few if any users ever explicitly protect images. + (1/15) + +host/os/zfrnam.c [UNIX] + In testing out the rename operation on the new protected image header + files, I discovered that the original protect link is not being + deleted because ZFPROT cannot find the named file, which has been + renamed at the host level by the time ZFPROT is called to unprotect + the original file. Modified ZFRNAM to remove protection from the + original file before renaming it, and to restore protection if the + rename fails. (1/15) + +host/boot/rtar.c + Added explicit initialization statements for all the switches, and + made the default action to strip trailing whitespace and blank lines + at the end of a text file (necessary when unpacking a tar archive + written on VMS). Switch -n defeats stripping. Also increased size + of pad buffer from 1024 to 8196, for very large text files. (1/16) + +host/os/zxwhen.c [UNIX] + Added a new debugging tool to the exception handler. If the external + variable debug_sig is set nonzero with the debugger before running + a process, then the action SIG_DFL will be set for all UNIX signals. + This will cause the process to core dump and die when the first + signal occurs. One can then go in after the fact with the debugger + and figure out what the process was doing when the exception occurred. + This is very useful when the exception only occurs when the process + is being run from the CL, in which case ADB cannot be used during + process execution. + + Example: + cl> adb -w x_pkg.e + debug_sig?w1 + $q + cl> (enter command; process runs and core dumps) + cl> adb x_pkg.e core + $c + (get stack trace showing where exception occurred) + + Note: adb -w works only if the process is not currently executing. + (1/16) + +host/boot/spp/xpp/xppcode.c +sys/tty/ttyopen.x + The above mentioned diagnostic, in concert with the MEM=0 revision made + earlier, enabled me to find the following subtle bug in the SPP + compiler. In TTYOPEN, the load device entry routine was taking an + error action due to a bad device name, causing the error handler to + be entered. The error handler was doing an MFREE on the tty + descriptor and then calling ERRACT(EA_ERROR). The problem was that + the ERRACT was not error checked, hence processing would continue. + The MFREE sets the input pointer to NULL, hence a couple statements + down we were assigning to a structure pointed to by a null pointer, + causing a segmentation violation (fun, huh?). + + I spot checked other parts of the VOS and found that RETURN was + called only occasionally after ERRACT, hence the same type of bug + could occur in other parts of the system. The language specifies + that one is supposed to explicitly ERRCHK the ERRACT subroutine, + but it is harmless (and safer) to have the system do so automatically, + so I changed the compiler to automatically ERRCHK all calls to ERRACT. + This involved modifications to only 2 lines of code in xppcode.c. + (1/16) + +sys/tty/ttygdes.x +sys/tty/ttyodes.x +sys/etc/envindir.x + + The graphcap search failure leading to the bug mentioned above was + caused by ttyopen being called for the device "@terminal". Obviously, + the higher level code could have resolved the indirection, but for + reasons of defensive programming I added the capability to ttyodes + and ttygdes. The new procedure ENVINDIR was added to ETC to resolve + any indirection in the name (not value) of an environment variable. + (1/16) + +host/hlib/mkiraf.csh + Modified to reference hlib$login.cl, rather than lib$login.cl. (1/16) + +sys/osb/mkpkg + The mkpkg file would pass bytmov.c to the library module list even + though it had already passed bytmov.s. (1/17) + +sys/osb/bytmov.c + Was not using AOFF and BOFF; would work only provided the offsets were + 1 (which is usually the case). (1/17) + +general + The @terminal syntax for specifying the stdgraph device is causing so + many problems thoughout the system that I think we should just drop it, + if its that hard to do, its probably not a good idea anyway. (1/17) + + +Begin simultaneous port to SUN and VMS!! +(Document here only notes which affect the master system; SUN or VMS specific +(revisions are docmented in their respective notes files). +----------------------------------------------------------- + +host/boot/bootlib/_bytmov.c +host/boot/bootlib/osamovb.c +host/boot/bootlib/mkpkg +host/boot/bootlib/mkpkg.csh + Changed the bootlib procedure os_amovb() to use BYTMOV instead of AMOVC. + Added a local C version of BYTMOV so that the assembler version can be + optional. Added conditionals to mkpkg.csh and mkpkg to use the local + C version if the assembler version cannot be found. All assembler + modules are now optional except ZSVJMP.S. (1/18) + +host/mc6800/README +host/mc6800/ishift.s +host/mc6800/zsvjmp.s + Documented the host$* changes required for a MC68000 based machine + (e.g., the SUN workstation). Put a couple of SUN/UNIX assembler sources + in the directory so that they can be moved into place during + installation. Note that these will not work on an ISI/UNIX due to + differences in the two assemblers. (1/18) + +host/hlib/mkiraf.csh [UNIX] + Extracted the machine dependent pathnames into SET definitions at the + head of the file, and eliminated all site dependence from the remainder + of the script. (1/18) + +host/boot/boot/mkpkg.csh +host/boot/boot/bootlib/mkpkg.csh [UNIX] + The bootlib mkpkg.csh file has a multiline if then else, hence was + made into an executable .csh and called directly as a task in the + boot bootstrap-mkpgk.csh, rather than with sh -x. (1/18) + +host/boot/mkpkg/pkg.c + In push_context(), should not call ftell() if cx->fp is NULL, i.e., + when executing do_include from the main at startup time. (1/18) + +host/boot/bootlib/gmttolst.c - + Deleted this file, it is not used anywhere and got forgotten about. + (1/18) + +sys/fio/delete.x +sys/fio/falloc.x +sys/fio/frename.x +sys/fio/protect.x + These routines now recognize and ignore attempts to delete, rename, + protect, etc. the null file "dev$null". (1/19) + +host/hlib/zzsetenv.def + When a task is run from the host it initializes its environment from + the zzsetenv.def file in hlib$; the CL is such a task. I removed the + definition of UPARM from the default zzsetenv.def, because it is + referenced by the CL during startup when looking for cl.par, and the + uparm definition referenced home$, causing a "env.home: " query during + process startup. (1/19) + +lib/syserrmsg + Replaced SYS_FUNPROTECT by a more informative message. (1/19) + +host/hlib/libc.h + Added a libc style u_ definition for ISATTY. Without this, the CL + crashed badly on the SUN because the UNIX stdio code was calling the + LIBC version of isatty(). (1/19) + +sys/ki/kdvall.x +sys/ki/irafks.x + All references to ZDVALL and KDVALL in this directory were missing the + second argument. (1/20) + +host/os/zalloc.c + Was calling ZGTENV to get the path to hlib$. Changed to get the path + to host$, and construct the pathname to hlib$, since hlib$ is not + defined in . (1/20) + +host/boot/mkpkg/host.c + The UNIX version of mkpkg used to do nothing when asked to check out + a file, if a local copy of the file already existed. This would cause + problems when the system was moved to a new root directory, as the + already checked out version, a symbolic link on unix, would contain + a pathname which was no longer correct. Changed to delete the local + copy and always check out a new version. (1/20) + +host/boot/bootlib/tape.c + In the decoding of the density number, changed "*ip + '0'" to + "*ip - '0'". Also, in the call to sprintf, replaced "density" by + "*density". (1/20) + +pkg/cl/eparam.c + Paramget() was being used to fetch the parameter value string. This + would cause eparam to lock up the CL in terminal raw mode when one + of the parameters in the parameter file was indirect. Replaced the + call to paramget() by a call to the lower level routine sprop(). + (1/21) + +host/boot/mkpkg.c/scanlib.c + In working on the VMS version of MKPKG, I coded a hash table package + for the scanlib() library module list database. I had to test this + anyway, so I merged it into the UNIX version of scanlib, in place of + the old linear search scheme used formerly. Performance improved + significantly for large libraries, as one would expect, e.g., for + a null mkpkg on vops$: + + make .files + 1:02 (old make + mklib) + 20.2u 16.6s 0:49 (new mkpkg, linear search) + 7.9u 16.6s 0:32 (new mkpkg, hash table) + + An entire null sysgen on the VOS (from directory sys$) now takes + 1:26 (86 clock seconds, 13 libraries) on my unix 750, when running + single user. + + Given the name translation and fdate caches already in use, and now + the library module hash table, MKPKG probably isn't going to get + much faster; it is probably 4-8 times faster than the original + combination of Make plus MKLIB. The VMS version, which actually + physically reads each file, is much slower still. (1/21) + +host/boot/xyacc/Makefile [UNIX] + Replaced machine dependent pathnames with offsets. (1/22) + +host/boot/mkpkg/host.c + add_objects() was being called with one too few arguments. (1/22) + +host/hlib/login.cl + Added a default USER package to the default login.cl. (1/22) + +host/boot/spp/xpp/xppcode.c +host/boot/spp/xpp/xppmain.c + Changed include "iraf.h" to include . (1/22) + +host/boot/spp/xpp/xpp.h +host/boot/spp/xpp/xppmain.c + Parameterized the success code returned by XPP in xpp.h, to avoid + having xppmain.c be different in unix and vms (success=1 in vms, + 0 in unix). (1/22) + +sys/fmtio/lexnum.x + Changed stk_ip[] from short to int. (1/29) + +pkg/cl/builtin.c + Two instances of + + flags != LT_PFILE; + + were changed to + + flags &= ~LT_PFILE; (1/29) + +pkg/system/help/t_help.x + Added , to the list of pattern metacharacters, so that help will not + stop after printing only the first help page when given a command + such as "help taska,taskb". (1/29) + +sys/ki/irafks.x + Changed all the "call ki_error()" to "call ks_error()"; a typo. Added + KI_FIOGD (the graphics binary file device driver) to the case list in + the main routine. (1/29) + +sys/gio/cursor/gtropenws.x + Moved the strcpy to set TR_DEVNAME until after the new kernel has been + successfully opened. Before, if the open failed (e.g., because no + x_*.e kernel executable was found), then the second attempt to open the + kernel would result in a misleading "bad file descriptor" error + message. (2/5) + +sys/fio/rename.x + RENAME will copy a file if the zfrnam fails. Added code to transfer + file protection to the new file, and remove it from the old file + before deletion so that the delete will not abort. (2/7) + +pkg/system/help/lroff/lroff.h +pkg/system/help/lroff/lroff.x +pkg/system/help/lroff/do_ls.x -> dols.x +pkg/system/help/lroff/section.x + (etc.) + LROFF would learn new values for the .ls indent, .sh nlines to skip, + etc., which would remain in effect after task termination, causing + subsequent text to be formatted incorrectly if that text used the + default values. The offending static variables were moved into the + lroff common, and code was added to lroff() to initialize these when + lroff() is called. In the process I eliminated the ENTRY constructs + in section.x. (2/7) + +pkg/system/help/lroff/dols.x + Fixed a bug that was causing 2 ".ls" directives in a row to output + two blank lines, rather than one. (2/7) + +pkg/system/help/help.hlp + This manual page was moved to system$doc/help.hlp. (2/7) + +pkg/system/doc/*.hlp + Went through all these manual pages, fixing grammatical and other + errors, clarifying the discussions, improving the examples, checking + the examples to make sure they work, adding entries for parameters + not mentioned, correcting the names of misnamed parameters, and so + on. This led to the lroff and help bug fixes noted here, most of + which have been known for some time in any case. (2/7) + +pkg/system/help/t_help.x + When called to process a file_template (text process an ordinary file, + rather than a module in the help database), will no longer query for + the name of the help database and all the parameters associated with + formatting manual pages. Formerly the task would abort if there were + no help database, even when called as a simple text formatter. (2/7) + +sys/etc/main.x + Fixed a bug that I admit I have known about for years but never got + motivated to track down until now. The bug showed up when PAGEing + help output in a pipe; if one quit early in PAGE, and then ran page + again in a pipe, the first output seen would sometimes be from the + whatever was previously being paged. This was traced to a problem + with task termination. The IRAF main was changed to not only flush + the STDOUT when a task terminates, but to also F_CANCEL any unread + input on STDIN. (2/7) + +iraf$bin + +pkg/cl/exec.c add call to findexe +pkg/cl/main.c IRAFLIB->IRAFBIN +pkg/cl/builtin.c add call to findexe in clprcache +unix/hlib/zzsetenv.def add set bin = iraf$bin/ +unix/hlib/clpackage.cl add set bin = iraf$bin/ +unix/hlib/irafuser.csh lib/cl.e -> bin/cl.e +dev/graphcap all lib$ -> bin$ +dev/hosts all lib$ -> bin$ + + Created a new directory iraf$bin, logical bin$, to hold "installed" + exececutables. A new function findexe() was added to exec.c, and + a reference to it was added to the call to pr_connect(). The CL will + first look in BIN for the executable when connecting a subprocess, + and if it is not found there, use the pathname given in the TASK + statement. This allows us to install the executables all in a single + directory without need to change the TASK statement or move the + parameter files (which still must be in the directory referenced in + the TASK statement). Note that there need be no executable file in + the package directory; a "mkpkg install" or "mkpkg update" will $move + it to bin$. + + In addition to permitting installed executables, this revision also + allows multiple tasks, each with its own parameter file, to share the + same executable. For example, we currently copy the ONEDSPEC + executable to the IMRED directories for the IIDS and IRS, since while + these packages can share the executable they need independent parameter + files. By installing the executable all packages can share the same + executable and still have separate parameter files. + +sys/libc/cfnroot.c +sys/libc/cfnextn.c + Changed the FNLDIR references to calls to FNROOT and FNEXTN. (2/10) + +sys/libc/cfnames.c + Deleted this file, since c_fnldir, c_fnroot, and c_fnextn are already + present in the library in separate files. (2/10) + +pkg/cl/main.c + Changed several debugger eprintf calls to printf calls, to avoid + use of eprintf until the CL has finished starting up. (2/10) + +lib/cl.par -> pkg/cl/cl.par + Since the CL is now installed just like any other executable, its + parameter file is kept in the source directory rather than lib$. (2/10) + +all mkpkg files + The "update:" entries now do a "$move x_pkg.e bin$". (2/10) + +dev/pix +dev/pix.pix + Installed the "standard test image" and its associated pixel file (for + testing software and new installations) in dev$. (2/10) + +-------------------- +Begin merge of V2.2 VMS/IRAF changes into UNIX/IRAF. +See the VMS notes for additional details. + + +unix/os/zfnbrk.c + Can now handle \X in filenames, without interpreting the \ as a + directory delimiter. (2/10) + +unix/hlib/libc/xnames.h +unix/hlib/libc/xnames.no_ + Added a define for VFNUNMAP. (2/10) + +unix/os/zzinit.c - +unix/os/zzstrt.c + +unix/hlib/libc/knames.h +unix/hlib/libc/knames.no_ + Added the (no-op) procedures ZZSTRT and ZZSTOP to the UNIX kernel. + These are called by the bootstrap utilities, or any other program + which does not have a ZMAIN but which uses LIBOS, to perform any + necessary kernel initialization. (2/10) + +unix/boot/... + Changed all the _zstartup, _zshutdown references to ZZSTRT, ZZSTOP. + Added references to a couple programs that did not have them yet. + (2/10) + +unix/boot/bootlib/osfpathname.c + Added a call to vfn2osfn before the call to ZFPATH. (2/10) + +unix/boot/bootlib/oschdir.c + Replaced call to os_fpathname by call to ZFSUBD. (2/10) + +unix/hlib/libc/spp.h + Added #define for OSOK. (2/10) + +unix/hlib/libc/libc.h + Added #ifdef for NOLIBCNAMES. (2/10) + +sys/mkpkg + Replaced with VMS version. (2/10) + +unix/boot/mkpkg/* + Replaced all the "portable" files with the VMS versions, which will + work on either system. (2/10) + +unix/boot/bootlib/* + Updated with code from VMS version where appropriate. (2/10) + +vms/boot/bootlib/osgetenv.c + Added code for bin$. (2/10) + +unix/boot/generic/* + Numerous changes to enhance the portability of this code. (2/10) + +unix/boot/rmbin/rmbin.c +unix/boot/rtar/rtar.c +unix/boot/rtar/wtar.c + Replaced by the VMS versions. (2/10) + +unix/boot/spp/xpp/lex.sed + +unix/boot/spp/xpp/Makefile + Now postprocesses the lexyy.c file to convert certain nonportable + constructs into a more portable form. (2/10) + +pkg/mkpkg + Added a conditional purge [...] for VMS, and a $purge bin$ for + all systems. (2/10) + +pkg/cl/scan.c +pkg/cl/opcodes.c +pkg/cl/main.c +pkg/cl/globals.c + Merged VMS changes into these files. Scan: tab as well as blank in + whitespace; the rest, #ifdef globalgarbage for VMS linker. (2/10) + +unix/hlib/devstatus.cl + Added a verbose option like that for VMS; isn't worth much, but it + make the task parameters match on both systems. (2/10) + +sys/etc/syserr.x + In syserrs, added a check for overflow on the error message string. + (2/10) + +sys/ki/kiconnect.x + Added a call to ki_gethosts() to read the host name table if it has + not yet been read. (2/10) + +sys/clio/zfiocl.x + In zardps, repaired some code that was confused about bytes and chars + and was overwriting memory as a result. (2/10) + +dev/graphcap + Merged in changes from VMS version. (2/10) + +sys/tty/* + Replaced the entire directory by the VMS version, which adds TTYWRITE + to permit null padding in control strings. (2/10) + +sys/gio/stdgraph/stdgraph.h +sys/gio/stdgraph/stgencode.x +sys/gio/stdgraph/t_showcap.x + Replaced by the VMS versions. Adds !! operator for generating + millisecond delays in graphcap control strings, etc. (2/10) + +pkg/images/tv/* + Replaced all of the TV code by the VMS version, except the tv/doc + directory and tv/cv/ids/iis.doc, which had been modified recently + in the UNIX version. (2/10) + +(did a full reboot of UNIX/IRAF) + +unix/boot/mkpkg/pkg.c +vms/boot/mkpkg/pkg.c + Open_mkpkgfile() would die on a bus error if the mkpkgfile did not + exist. Made the call to k_fseek conditional upon the successful + open of the mkpkgfile. (2/10) + +unix/os/zfsubd.c + If the input directory is null, will now immediately fetch the current + directory and fold the subdirectory into that. (2/10) + +sys/gio/calcomp/mkpkg +sys/gio/nsppkern/mkpkg +sys/gio/stdgraph/mkpkg +sys/tty/mkpkg + Changed to move exe to bin$ instead of lib$. (2/10) + +pkg/cl/builtin.c +pkg/cl/edcap.c +pkg/cl/eparam.h +pkg/cl/globals.h + Added a new attribute EDITOR_CMD to EDCAP. This defines the command + sent to the host to run the editor (not necessarily equivalent to the + logical name of the editor). The commands are defined in the dev$*.ed + files, and are host system dependent but not site dependent. (2/11) + +dev/*.ed + Added an EDITOR_CMD entry to each file for UNIX. (2/11) + +doc/* + This directory contained a lot of internal memos, etc., of value only + for iraf management. These were moved out of the system, leaving only + the sources for those documents which might be of general interest. + (2/12) + +local/* [UNIX] + Added a new subdirectory LOCAL to to the UNIX version of IRAF. This + serves the same purpose that it does in VMS/IRAF. Sites installing + IRAF for the first time should create a new account "iraf" for the + IRAF system, with login directory $iraf/local. The UNIX distribution + tape will contain a default .login etc. for the IRAF account (this is + needed to bootstrap the system, should it be necessary to do so). + Mail to IRAF will accumulate in the "mbox" in local, the "notes" file + will be stored in local, and so on. This directory will not be + modified when an update of the system is installed. (2/12) + +pkg/cl/builtin.c + Added a call to findexe() whereever _pname is used. If this not done, + tasks like prcache and flprcache may fail to find the process in the + cache. (2/12) + +unix/hlib/clpackage.cl +unix/hlib/zzsetenv.def + Since the zzsetenv.def file is always loaded now when the CL starts + up (because the CL is run from the host), and since a lot of the set + environment defs in clpackage.cl redefine those in zzsetenv.def, + I moved the remaining non CL-specific SET defs from clpackage.cl to + zzsetenv.def. The file clpackage.cl is now machine and site + independent and can safely be forgotten about. Also, since the system + package is now loaded at login time, I replaced the fscan stuff, + used to print the message of the day, by a call to PAGE. (2/12) + +iraf$mkpkg + Added an "update" entry point, to avoid having to run separate mkpkg's + in sys and pkg to relink all the system executables. (2/12) + +sys/ki/kishownet.x + +pkg/system/netstatus.x +pkg/system/x_system.x,system.cl,etc. + Added a new function ki_shownet to KI to print the network status. + Added a new task NETSTATUS to the system package to bring this to + the user level. NETSTATUS tells if the network is active, lists + the nodes on the local net, and lists the aliases for each node. (2/12) + +dev/edt.ed +dev/emacs.ed + Updated with the VMS versions, which now include the PREV_PAGE and + NEXT_PAGE entries. (2/12) + +dev/hosts +dev/uhosts + Brought these up to date; added a bunch of new hosts. (2/12) + +unix/os/zgtenv.c + An optimization; is not read unless the named environment + variable is a known one. (2/12) + +sys/sys.hd +host/os/doc/os.hd + Replaced the references to sys$ by host$ so that HELP can find the + manual pages. (2/13) + +pkg/images/tv/cv/ids/idsfont.x +pkg/images/tv/cv/iism70/idsoptn.x - + There was a name collision of the procedures ids_open and ids_optn. + The second was a no-op anyhow, so I deleted it, and commented out + the call in ids_font. (2/13) + +sys/gio/cursor/grcwaitp.x + Modified to display another "wait" message after the user responds + to the first wait with the space bar, causing the system help + to be printed. (2/13) + +unix/os/zopdpr.c +unix/os/zmain.c + Fixed a bug in zopdpr that was preventing KILL from killing bkg jobs + on UNIX. Also added the ability to use an &NN argument to set the + priority at which the bkg job is to run. (2/13) + +dev/termcap +dev/graphcap + Several new entries were added to each file (contributed by our early + release sites). (2/13) + +pkg/language/ + The manual pages for the language package were extensively revised, + corrected, and extended. (2/12-13) + +pkg/softools/ + Manual pages were added for all the softools tasks, including all + the bootstrap utilities. (2/13) + +host/spp/xpp/xppcode.c + The size of the output buffer was increased by a large factor to + avoid overflow when compiling large procedures, e.g., procedures + with a lot of data statements. (2/13) + +pkg/lists/* + The names of the tasks GCURSOR and IMCURSOR were changed to RGCURSOR + and RIMCURSOR. The manual pages for these and all other tasks in + the package were revised and printed. (2/13) + +host/boot/rmfiles/ + +iraf/mkpkg + Added a new bootstrap utility RMFILES. This is similar to RMBIN, + but is driven by a script and is not limited to deleting binary + files. Two new entries "strip" and "stripall" were added to the + root mkpkg file for stripping production versions of the system. + The results: + + full system 41.493 Mb + mkpkg strip 19.838 + mkpkg stripall 17.062 + + Stripall differs from strip in that it deletes the libraries as + well, preventing software development but still permitting full + use of the standard system. (2/16) + +doc/* + Renamed some files with .doc extensions to make it easier to + delete them with the stripper. (2/16) + +doc/gripesfile +doc/newsfile +lib/motd + These files were moved to HLIB, since they are system dependent, + and should not be clobbered when a new version of the system is + installed. (2/16) + +(Skip made tape for AOS/VS) + +hlib/zzsetenv.def + Changed host$osb/ to sys$osb/. (2/17) + +unix/os/zfmkcp.c + An argument was being passed to ZFPROT by value rather than by + reference. (2/28) + +sys/imio/imfort + Tested the Fortran/IMIO interface for UNIX. One of the Fortran + test programs had to be modified before it would compile on UNIX, + and another had a bug (misplaced continue in do loop). The only + serious problem was the linker conflict (see below). (3/5) + +unix/os/mkpkg + Added an $ifeq (USE_LIBMAIN to the mkpkg to not put zmain.o in the + library if libmain.o is used. The library version is not used + anyhow, as XC explicitly references lib$libmain.o during linking. + The unix zmain.o contains the external "main"; when using libos.a + in a Fortran program, the linker would use the iraf zmain instead + of the Fortran main, causing the Fortran program to fail to link. + (3/5) + +unix/hlib/newsfile +unix/hlib/gripes.cl + Installed the vms/iraf versions. (3/5) + +unix/os/zgcmdl.c + Added this new kernel primitive; used to get the host system command + used to invoke the process, e.g., in a foreign task. This is used + by the IMFORT interface to allow host Fortran programs to get the + CL foreign task command line. (3/5) + +unix/os/zmaloc.c +unix/hlib/kernel.h + Added a #ifdef DEBUGMEM to zmaloc.c and a #define DEBUGMEM to + kernel.h so that compilation of the special version of MALLOC can + be easily defeated. The debug version is useful on the VAX, but + should be disabled on the SUN to permit use of the standard UNIX + version when using the SUN graphics libraries. (3/5) + +------------------------- +(V2.2 was sent out sometime near here) + +unix/mc68000/ishift.SUN + Would not right shift properly. (3/14) + +sys/osb/miiupk16.x +sys/osb/miiupk32.x + These subroutines were modifying (byte swapping) the input array. + (3/14) + +sys/ki/kireceive.x + Modified to deal with out of band data by checking to see if the out + of band data is a character string (usually an error message), printing + the message on STDERR if so, and then returning ERR on the channel. + (3/14) + +dev/graphcap + Modified DD entries for the versatecs and the dicomed to queue the + print jobs to these devices. (3/15) + +pkg/cl/lexicon.c + Modified to permit inclusion of {} inside unqoted strings. The change + was made in a way which does not interfere with the use of {} to + delimit compound statements. (3/18) + +sys/imio/imrename.x + + Added a new operator IMRENAME to IMIO, so that people won't have to + use the FIO rename to operate upon images, which is a violation of + the IMIO interface. (3/18) + +pkg/cl/lexicon.c +pkg/cl/debug.c +pkg/cl/opcodes.c +pkg/cl/compile.c +pkg/cl/main.c +pkg/cl/builtin.c +pkg/cl/prcache.c +pkg/cl/exec.c +sys/gio/cursor/gtropenws.x + Added redirection for the standard graphics streams. The syntax is + as follows: + + >(G|I|P)+ file # (create file) + or + >>(G|I|P)+ file # (append to file) + + e.g., ">G file" to redirect STDGRAPH to "file", or ">GI file" to + redirect both STDGRAPH and STDIMAGE to file. Note that multiple + redirection arguments may be given on the command line. The >GI, + etc., is lexically a token, hence there must be no space after the >, + and the GIP must be upper case. (3/24) + +pkg/cl/config.h + Increased the size of the stack and dictionary. (4/13) + +pkg/cl/main.c + Fixed a bug in the calls to FDOPEN, dating back to the installation of + the graphics redirection code, above. (4/13) + +unix/hlib/[dir]1mach.f + Added (commented-out) lines for the IEEE machine constants, determined + on the Sun-2. (4/15) + +sys/osb/miiupk16.x +sys/osb/miiupk32.x + Would not write into output array if byte swapping was not used on the + host machine (not found until code was run on 68000 series machine). + (4/23) + +------------------- +Package reorganization (add package tree NOAO) 26-27 Apr) +Detailed notes were not kept for this as hundreds of files were edited. + +pkg/* +noao/* + Added a new directory NOAO off the root. Moved all the optical + astronomy packages from PKG to NOAO. (4/26) + +lib/pkg/ +lib/scr/ +noao/lib/scr/ +noao/lib/scr/stdlines/ + Created a library noao/lib for the NOAO package. Moved all NOAO + related files from lib/pkg and lib/scr to the new library. All the + XTOOLS library global includes remain in lib/pkg. (4/26) + +pkg/utilities +noao/astutil + Created a new package ASTUTIL in NOAO. Moved all the astronomy tasks + from the UTILITIES package to the new ASTUTIL package. (4/26) + +pkg/dataio +noao/mtntape + Created a new package MTNTAPE in NOAO. Moved all the mountain tape + readers from DATAIO to the new MTNTAPE package. (4/26) + +pkg/local -> noao/proto, iraf$local + Broke the old LOCAL package up into two packages PROTO (in NOAO) and + LOCAL. The PROTO package is essentially the old LOCAL package, but + the concept of the package has been changed to reflect its usage. + The new LOCAL package is in the directory iraf$local/tasks, i.e., in + the local (site dependent) directories. This is all set up as a + package in the root, ready for the individual sites to add their own + collection of packages. (4/26) + +pkg/clpackage +lib/clpackage.hd +lib/root.hd +unix/hlib/clpackage.hd + The help directories were restructured to make it easier to tie + local or add-on packages into the help database. The old pkg$clpackage + directories were deleted and the files moved into hlib$. Entries for + the LOCAL and NOAO packages were added to hlib$clpackage.hd. To add + a new help tree to the help database, all the user need do is make an + entry in this file to for the root .hd of the new help tree, and run + mkhelpdb. (4/26) + +unix/hlib/clpackage.men +unix/hlib/clpackage.cl + Removed the entries for all the NOAO packages. The 'page motd' entry + was moved to hlib$login.cl since the terminal type may not have been + set properly until after the user login.cl has been processed. This + also makes it possible for the user to omit the message of the day if + they wish. (4/27) + +unix/hlib/mkiraf.csh + Changed all the USER, HOME, etc. entries to U_USER, U_HOME, etc., + to avoid unintended editor script substitutions. Added an unalias + command to protect the user from their own folly if they have + aliased rm, etc. (4/27) + +unix/hlib/zzsetenv.def + Moved all the NOAO logical directory definitions to noao$noao.cl. + Added SET defines for the NOAO, LOCAL, and SDAS directories. (4/27) + +unix/hlib/login.cl + Changed all the USER, HOME, etc. entries to U_USER, U_HOME, etc., to + avoid unintended editor script substitutions. Moved the page motd + code in from clpackage.cl. (4/27) + +pkg///*.hlp +noao///*.hlp + All manual pages were modified to give the package path in the + manual page header. (4/27) + +pkg///*.men +noao///*.men + All "Revisions" entries were removed from the menu files, since this + is a temporary thing and it prevents the long form menu from matching + the multicolumn menu. In the future, any non-task manual pages should + be listed separately from the task list. (4/27) + +sys/mkpkg +sys/imio/mkpkg + Added entries for libfort.a; must have forgotten to put these in when + the IMFORT package was added. (4/28) + +unix/hlib/mkmlist.csh + Changed the bgrep to fgrep for increased portability. This utility is + not used often enough to make the use of bgrep worth the loss of + portability. (4/28) + +pkg/images/tv/display/iisers.x +pkg/images/tv/cv/iism70/zclear.x +pkg/images/tv/cv/iism70/iiscursor.x + There were several cases of a 32 bit signed integer containing a 16 bit + unsigned integer value being assigned into a 16 bit signed integer + variable. This works on machines that do the assignment at runtime, + truncating the value in the process. It would cause a compile time + error on the SUN-3, which carries out the initialization at compile + time. Changed to [short = andi (intval, 177777B)], which forces a + runtime assignment. (4/28) + +sys/gio/nspp/portlib/flush.f +sys/gio/nspp/portlib/flash[13].f +sys/gio/nsppkern/gktcancel.x +sys/gio/nsppkern/gktclear.x +sys/gio/nsppkern/gktclose.x +sys/gio/ncarutil/sysint/spps.f + Changed the name of the NSPP routine "flush" to "mcflsh" to avoid + library conflicts with the Fortran FLUSH. (4/28) + +unix/hlib/libc/finfo.h + The fi_owner field of the finfo structure was not dimensioned + properly, causing the storage allocated for the structure to be + overrun. This was found in a call to pfileopen/filetime in the + CL; the finfo structure is allocated space on the stack, hence the + stack was being corrupted (found on the SUN). This is a fairly + serious bug which has been in the system for a long time. (4/28) + +sys/gio/stdgraph/stgdrawch.x + The sgch_flush procedure was being called with a short argument (op/2) + when an integer argument was expected. (4/29) + +sys/gio/stdgraph/stgrcur.x + The cursor read algorithm was enhanced by the addition of a general + pattern matching capability, used to improve the detection of botched + cursor reads, permitting automatic retries. The old algorithm was + fine for fixed size cursor strings, but did not work well for + variable length cursor value strings such as returned by Regis. (4/29) + +pkg/cl/* + Starting with the new version of the CL from ST, did a diff of the + local changes to the CL since V2.2 (graphics redirection, {} in command + mode) and merged these into the ST version of the CL, which has been + worked on extensively since last fall, adding improved error handling, + a better logfile capability, eparam enhancements, parser improvements, + and so on. (5/2) + +pkg/cl/gquery.c + Added (char *) declarations for strcpy() and index(). (5/2) + +pkg/cl/cl.par + Moved the mode parameter to the end of the CL parameter list, where it + is for most parameter sets. Eparam does not print the query mode + params before the hidden ones (it should, like lparam, to indicate the + calling sequence), but since most pfiles are already ordered that way, + this is good enough for now. + + Also changed the default values for EPINIT and EHINIT. Not using + standout mode in ehistory is simply a matter of preference; neither + the Cshell nor DCL uses standout mode either, and I find it distracting. + I never have understood what the noshowall option in eparam is good + for; I suspect this has something to do with SDAS not using hidden + parameters in the way they were designed to be used. With regular + IRAF tasks one always wants to see the hidden parameters too; most + of the parameters are generally hidden. (5/2) + + [See the hlib$clpackage.cl mod below to personalize these parameters + for your site]. + +unix/hlib/login.cl + In the login.cl template, changed the call to `page' to a call to + `clear;type'. The "more" query in page() causes problems if the user + types ahead and the motd is longer than one screen. If the user does + not want the screen cleared, or does not want the motd at all, they + can now easily change the login action. (5/2) + +pkg/cl/eparam.c + Some problems are apparent in using the new EPARAM. Some of these + were fixed before and must have gotten lost in the merge. + + To the strings "PACKAGE = %s\n" and "TASK = %s\n" in the screen + repaint function, added a \r before the \n. This is necessary because + the Eparam screen is updated in raw mode, and no output processing + is done in raw mode, hence newlines are not converted to CRLF. + This causes the next line to be printed at the END of the last line, + one line down on the screen (!!). + + In drawkey(), would clip the prompt string at the right margin of + the terminal only if the VALUE string was too long to fit in the + value field. Parameters with long prompt strings but short values + would wrap around, stepping on the next line. + +unix/hlib/clpackage.cl +unix/hlib/login.cl + Deleted the ehinit, epinit environment definitions. Added commented + out cl parameter assignments to the login.cl file. (5/2) + + NOTE - `editor' should remain an environment variable, rather than + being changed to a CL parameter, because the CL is not the only + task in the system which needs to know the user's editor preference. + The VOS facilities, e.g., DBMS, will use this variable too. + +pkg/cl/cl.par +pkg/cl/config.h +pkg/cl/prcache.c +pkg/cl/modes.c + Added a new "active" CL parameter `szprcache' to the CL parameter file. + Changed NFGPROC in config.h to MAXSUBPROC, the maximum rather than + actual number of cached processes. Modified the prcache.c and modes.c + codes to dynamically change the size of the process cache when this + parameter is set. This was done because the optimal size of the process + cache depends upon the host operating system, upon whether the system + is single user or multiple user, upon on the per user quota, and so on. + The system manager can now set the default cache size to the optimum + value for each individual host, by editing hlib$clpackage.cl. (5/2) + +pkg/cl/cl.par +unix/hlib/clpackage.cl + Changed the default value of the `lexmodes' parameter to yes in cl.par. + In clpackage.cl, added commented out assignments for all the CL + parameters for which a site might want to change the default values. + This makes it easy for sites to provide their favorite default values + for EHINIT, EPINIT, SZPRCACHE, KEEPLOG, etc. (5/2) + +pkg/cl/cl.par + Changed the default value of `logfile' to "home$logfile.cl". The HOME + directory seems a better default for the logfile than UPARM, so that + the user won't forget that this potentially very large file is around, + and so that they can find it easier. (5/3) + +unix/hlib/cllogout.cl +unix/hlib/clpackage.cl + Added a new task declaration $_logout = home$logout.cl in clpackage.cl. + Added code to hlib$cllogout.cl to call this task at logout time if a + logout.cl file is present in the user's home directory. (5/3) + +cl syntax errors - + The new facility to help give the user some insight into syntax errors + is great, and I notice the reduce/reduce conflicts are gone from the + grammar now too. + +pkg/cl/history.c + Eliminated the unused 4 spaces at the left in the logfile. (5/3) + +pkg/cl/builtin.c +pkg/cl/eparam.c +pkg/cl/modes.c [EXPERIMENTAL] +pkg/cl/exec.c +pkg/cl/pfiles.c +pkg/cl/param.h + Added a "menu mode" to the CL. This was the easiest to implement of + the many EPARAM related changes recently discussed, which is the main + reason it was done now. The main revisions were: [1] moved pfilecopy + code from eparam.c to cleparam() in builtin.c, so that eparam() now + simply edits a pfile structure in memory (it should have been done + that way originally). Added a status return to eparam() to indicate + what type of exit was taken. Added M_MENU mode all over the place. + Added a conditional call to eparam() to execnewtask(), after the pfile + has been copied, the command line parameters processed into it, etc. + Modified effmode() to not query when a task is run in menu mode. + Added a new function taskmode() to modes.c to determine the effective + mode for a task. + + Menu mode may be set only at the task or package level (setting menu + mode at the CL level is not useful since even simple tasks like DIR + will then cause eparam to be called). Menu mode is available only for + tasks which are called interactively, hence tasks called from within + scripts or in batch mode will not call eparam(). When menu mode is + disabled in this context, it is as if the mode were auto instead. + If menu mode is not asserted, everything behaves as it did before + there was such a thing as menu mode. Note that the task mode must + be set to "a" or "al" if setting the package mode to "m" or "ml" is + to have any effect. Setting the task mode to "m" or "ml" will always + work, of course. + + When a task is executed in menu mode eparam() is called after the + argument list (if any) has been processed, and immediately before the + task is executed. Exiting eparam() with ctrl/z runs the task, exiting + with ctrl/c aborts everything and does not update the parameters. + To simply edit the parameters, one runs task EPARAM explicitly. (5/3) + +pkg/cl/task.c +pkg/cl/param.c +pkg/cl/modes.c + Turned off the fancy context dependent checks to see if abbreviations + are to be permitted; abbreviations are now permitted in scripts etc. + if enabled by the CL parameter. Modified ltasksrch() to return a + match if an acceptable abbreviation is found in the current package, + without searching all the other loaded packages to see if the abbrev. + is unique. Eliminated the kludgy code in newltask() which would + directly fiddle with and later restore the CL parameter `abbrev...' + to disable abbreviations while checking for a redefined task. + This was done by adding an argument to ltaskfind(). (5/3) + +pkg/cl/modes.c + LEARN mode is now enabled only for tasks which are called + interactively. Tasks called by scripts, etc., or in batch mode, + do not have their parameters learned. This should speed things + up a bit and avoid mysterious changes to parameter values when + tasks are called as subroutines in scripts. (5/3) + + Note that a pfile will *always* be updated if a parameter is set in + an explicit assignment, or on eparam. + +pkg/cl/param.c + Moved the call to parse_clmodes() to before, rather than after, the + value of the CL parameter is modified, in case the new value is + illegal and parse_clmodes aborts. (5/3) + +pkg/cl/builtin.c (clpackage) + The PACKAGE builtin was not initializing the package descriptor + properly, causing the package parameter file to be misplaced and + preventing package parameters from being found in ambiguous (task, + package, cl) searches. 5/4) + +pkg/cl/param.c (lookup_param) +pkg/cl/modes.c (effmode searches for parameters too) + Parameter searches now look in the package parameter file properly; + possibly this has never worked up until now. Ambiguous parameter + references of the form "=param" are resolved as follows (searching + for the named parameter): + + Case 1: current task = `cl' (interactive) + - look in pfile of current package + - look in pfile of CL + + Case 2: current task != `cl' (e.g., a compiled or script task) + - look in pfile of task + - look in pfile of package to which task belongs + - look in pfile of CL + + Note that in case 2, the pfile to which the task belongs is NOT + necessarily the same as the current package. Indirection to a + package parameter can be achieved merely by omitting the parameter + declaration from the task's parameter set, although explicit + indirection is normally preferable to permit a command line override. + + Note: If the current package redefines any CL parameters, this can + be confusing. The prime example of this is the "mode" parameter, + present in each task, each package, and in the CL. Interactively + typing "=mode" or "mode=value" will set the mode of the current + package, not the mode of the CL. Type "cl.mode=value" to set the + mode of the CL (or use eparam). (5/4) + +unix/os/zfiotx.c + Modified the UNIX terminal driver to read the cursor in cooked rather + than raw mode, using a signal handler to catch interrupts and convert + them into ordinary character reads. It appears that raw mode is very + raw, i.e., even ctrl/s ctrl/q is turned off, which can cause data to + be lost or unsolicited characters to be seen. (5/4) + +sys/fio/zfiott.x +sys/fio/finit.x +sys/clio/clopen.x +sys/etc/ttopen.x +lib/ttset.h +unix/hlib/ttset.h +unix/hlib/xnames.h,xnames.no_ +unix/hlib/iraf.h + Added a new portable driver to the VOS and made it the standard terminal + driver for the high level code. If the iraf main is called by zmain + with the kernel terminal driver, clopen() maps the stdio streams to the + TT logical terminal driver. The TT driver is a place to implement any + VOS logical terminal functions; currently it is used only to support + monocase terminals, or dualcase terminals with the shift lock on (for + people who are fond of entering everything in upper case). The package + TTOPEN in ETC contains a direct terminal open routine (will be used + for screen editors implemented in subprocesses) plus TTSETI and TTSTATI + routines, used to set and query terminal driver options. FINIT was + modified to always load the TT driver as well as the TY driver. + + The logical terminal driver currently supports two options: + + ucasein Map input to lower case. A character may be + prefixed by ^ to enter an upper case character, + e.g., "PAGE ^MAKEFILE" -> "page Makefile". + To shift to upper case, "^+"; to shift back + to lower case, "^-", e.g., "PAGE ^+README" -> + "page README". The ^ character must be + doubled to be passed through. Note that ^ + is also the history metacharacter, but there + are only so many keys to work with. + + ucaseout Map all terminal output to upper case (may be + needed for some terminals). + + Case mapping is disabled in raw mode. A user requested this capability + because they have a lot of old monocase terminals. It also should + be useful for people who like to work with the shift lock on. (5/5) + +pkg/cl/builtin.c +pkg/system/stty.cl +pkg/system/stty.par - + Added a new builtin _stty, used to set/stat the VOS logical terminal + driver, and modified the system.stty task to use it (STTY should + probable be written as a builtin at some point). For example, + "stty ucasein" turns on monocase mode. STTY is now a procedure + script, hence the .par is gone. (5/5) + +pkg/cl/eparam.c +sys/gio/cursor/rcursor.x +sys/gio/stdgraph/stgopenws.x,stgclws.x,stgdeact.x,stgreact.x + Minor changes to support `stty ucase...' modes, which require some + support in routines that do raw i/o to the terminal (case mapping, + etc., is disabled while in raw mode). (5/5) + +miinelem.x + +miipksize.x + +miireadc.x + +miireadi.x + +miireads.x + +miiwritec.x + +miiwritei.x + +miiwrites.x + + Added the following routines to the MII package. The MIIPKSIZE routine + returns the size in chars of a packed MII array of the given MII type, + and obsoletes the old MIILEN function (miilen is still in the library, + however). The MIINELEM function returns the number of elements of the + given MII type in a packed array of the given size in chars. The read + and write routines are like the corresponding FIO routines, but are + used to read and write data stored externally in MII format. (5/7) + +sys/etc/symtab/stsave.x +sys/etc/symtab/strestore.x + Modified these routines to use the new miiread/miiwrite facilities to + save the symbol table externally in a machine independent format. + This makes it possible to use the symbol table package as a kind of + mini-database facility, providing a quite efficient interface for a + certain class of applications. (5/8) + +sys/gio/ncarutil/sysint/erprt77.f + In a couple of places, moved SAVE statements to before DATA statements + in the same procedure - required by Fortran standard. (5/8) + +sys/fio/ztiott.x +lib/ttset.h +hlib/libc/ttset.h +pkg/system/stty.cl +pkg/cl/builtin.c + Added a new option "logio" to the VOS logical terminal driver. This + is used to log all i/o to the terminal in a text file home$ttyio.log. + ALL i/o is logged, including graphics and raw mode i/o. Control codes + are rendered into printable form for output to the logfile. This + feature is most useful as a debugging tool when trying to figure out + why the system is not talking to a new terminal correctly. To turn + logging on, type `stty logio' in the CL. To turn it off, type + `stty clear logio'. The data passed in each ZGETTT or ZPUTTT call + is logged as one line of text; newlines in the data are logged as \n. + Long lines are broken, with the continuation line indented 4 spaces. + (5/9) + +sys/gio/gki/gkisetwcs.x + Modified to always write a copy of the SETWCS instruction to the output + metacode stream, even if writing to a standard graphics stream. (5/12) + +sys/fio/fexbuf.x +sys/fio/open.x +sys/fio/fgetfd.x +unix/hlib/iraf.h + Modified FIO to support the SPOOL_FILE file type. This type of binary + file spools data in a buffer in memory. Typically, a routine writes to + the spool file, the spool file is rewound, and another program reads + the data back out, after which the data may be cancelled and the + process repeated. Spool files have long been in use in by GIO; this + revision makes the facility available to applications software. (5/12) + +unix/os/zfiomt.c + Changed value of the count field in the mtop structure for the rewind + function from 0 to 1. (5/14) + +unix/boot/spp/rpp/(baderr.[rf],synerr.[rf]) + vms/boot/spp/rpp/(baderr.[rf],synerr.[rf]) + These routines are called with obsolete Hollerith character strings, + e.g., 5Habcde, in the argument list. Sometime ago we changed the + declarations for the Hollerith arguments to character*(*), thinking + that that was the correct specification. Both the UNIX and VMS + Fortran compilers, however, implement Hollerith as a single address + in the argument list pointing to a null delimited character string + (like a C string). Character*(*) is something quite different on + VMS, hence the XC/rpp error messages were getting garbled. Changed + the declaration for the Hollerith character string back to INTEGER, + which causes the pointer to be passed on to the low level interface + procedure correctly. (5/14) + +sys/fio/fdevblk.x + Modified to accept any pathname as input, not just directory pathnames. + The directory prefix is extracted and a temporary file created to + determine the device block size, as before. If an error occurs a + special error message is now generated, instead of the former message + "cannot open file (zbk12345)", which was rather cryptic. (5/14) + +sys/fio/fseti.x + In the case F_CANCEL, added the statement `boffset[fd] = 0'. This + ensures that FIO will not under any circumstances consider the contents + of the buffer to be valid. Also added LNOTE/LSEEK calls to preserve + the file offset over the cancel operation. Formerly the file offset + was set to be beginning of the buffer by the cancel. Preserving the + file offset means that a cancel when reading from a blocked file is + harmless but will pick up any recent changes to the file if shared. + Modifications to a file can likewise be cancelled provided the FIO + buffer has not been flushed in the interim. (5/19) + +unix/hlib/stripper +unix/hlib/stripall + No longer deletes the .hd (help directory) files. (5/16) + +sys/fio/fioclean.x + This routine, which cleans up during error recovery, deletes any + partially written new files if an error occurs. This would cause a + misleading message when the file being deleted was a special device. + Added a check for special devices. (5/19) + +sys/fio/fseti.x + When the file type is set to SPOOL_FILE, the FBLKSIZE parameter is now + also set to zero to indicate that the file is a streaming file. Spool + files are considered to be streaming binary files. (5/20) + +sys/fio/fwtacc.x + The sleep time of 60 seconds when waiting for a file to become + accessible was too long. Changed to a short interval which gradually + increases to a long interval. (5/23) + +pkg/plot/implot.keys +pkg/plot/implot.x + Moved the implot.keys file to lib$scr/implot.key, modified the implot.x + file accordingly. (5/23) + +lib/imhdr.h +lib/imio.h +sys/imio/* +sys/imio/iki/ + IKI Image Kernel Interface +sys/imio/iki/oif + OIF "old iraf format" kernel +sys/imio/iki/stf + STF "space telescope format" kernel + + Installed the newly revised IMIO interface, which was developed outside + the system without logging the revisions due to the extensive nature of + the revisions required. IMIO has been restructured to isolate all + knowledge of the physical image format into a new interface called the + image kernel interface (IKI). The IKI in turn can support any number + of image kernels, each of which provides an interface to a specific + host image format. These image kernels function very much like the + FIO device drivers and can even be dynamically loaded like the FIO + device drivers, to do IMIO to a device for which the full system is + not configured (linked). + + Two image formats are supported by the current interface, i.e., the + old IRAF format and the STScI GEIS format (FITS group format images). + IMIO automatically determines the image type at image open time. + A new environment variable IMTYPE determines the default type image + when a new image is created, but this may be overridden by simply + including the filename extension in the image name. + + A number of useful extensions were made to the semantics associated + with the use of the IMDIR environent variable. All IMIO datafiles + now have filename extensions by default. Existing code should require + no changes to use the new interface, only relinking. Existing images + can be read without reformatting. The new IMIO is documented more + fully elsewhere. (5/23) + +sys/imio/db/idb.h +sys/imio/db/idbfind.x + The IDB interface can now work with either a fixed record size user + area (80 char cards plus newline) or a variable length record size + as before. Keyword searches will be faster if fixed size records are + used. The interface automatically senses the record type at image + open time. When searching for a keyword, IDB will now reference the + FIRST keyword matched, rather than the last as before. (5/23) + +sys/fio/close.x + For the SPOOL_FILE case, replaced the call to frmbfs() by a call to + frtnfd(), to return the file descriptor allocated by open(). (5/24) + +pkg/images/iminfo/imheader.x + Modified to print group information if multigroup image, e.g., + [group/gcount] in section name. Also replaced file template expansion + by image template expansion to permit use of [] in image names. (5/24) + +sys/fio/fcopy.x + Added some minimum copy buffer size logic to avoid copy failure when + copying a file for which fstati(fd,F_BUFSIZE) returns zero for some + reason. (5/24) + +sys/fio/fntgfn.x + Made a couple of major extensions to the file template code to permit + the use of filename templates to generate the names of output files. + Also debugged the backslash escape logic in this code so that pattern + metacharacters (e.g., []) can be escaped in templates. + + The new features are: [1] new filename construction by string + concatenation, and [2] filename editing by string substitution. + Some examples follow. + + n_ // *.x Prepend `n_' to all .x files + nite1.* // .flat Append `.flat' to all nite1.* files + *.c // _X_ // *.h E.g., `builtin.c_X_bkg.h' (real useful, huh) + + *%%_1%.imh Append `_1' to the ROOT name of all .imh + files, e.g., `pix.imh' -> `pix_1.imh' + *.%x%gx Change extn from `.x' to `.gx' + + As before, more complex templates can be built up by forming a list + of patterns such as those shown, delimited by commas. The @listfile + notation may be used to read list files. The number of concatenatable + fields and edit operations is arbitrary and is currently set to 8 + concatenatable fields and 8 string substitutions per list element. + When concatenating successive elements from different lists, the length + of the output list is the length of the shortest input lists, hence the + input lists need not all be the same length. + + Added a new entry point FNTRFNB to the package, used to randomly read + the file list, unlike FNTGFNB which reads the list sequentially. (5/26) + +sys/fmtio/patmatch.x + Added an indexing feature to support the FNTGFN string substitution + capability discussed above. The character % may be embedded in + patterns to index the marked fields of the matched string. Note that + this is not trivial as the index depends upon the data being matched, + e.g., * may expand to any number of characters, and fields may be + anchored either at the left or the right (hence this feature had to + be built directly into the pattern matching code). Inclusion of the + % in patterns does not affect the match, i.e., the % is not matched + against anything. At match time, the pattern matching engine saves + the current character index in the encoded pattern buffer whenever + the INDEX (=%) instruction is encountered in the pattern. The index + values may be recalled after a successful match with the new PATINDEX + function. (5/26) + +pkg/xtools/imt.x - +sys/imio/imt.x + + Deleted the old image template package from XTOOLS and installed the + new template code in IMIO. The new code uses the revised filename + template and pattern matching code, supports the expanded image name + syntax, and supports metacharacter escapes that actually work. (5/27) + +sys/imio/imgclust.x +sys/imio/imgimage.x +sys/imio/imgsect.x + Added three new procedures to IMIO, to be used to parse image + specifications. These may be called to get the cluster name, the + image name (including the cluster index if any), or the image section. + These routines call IMPARSE which does the real work, but are more + convenient to use in applications programs. (5/27) + + Sample imspec: pix[3][*,-*] + + procedure returns + + imgcluster (imspec, cluster, maxch) pix + imgimage (imspec, image, maxch) pix[3] + imgsection (imspec, section, maxch) [*,-*] + +sys/fmtio/strdic.x + Now ignores whitespace at the beginning of the input keyword. (5/27) + +unix/os/zfiotx.c + It turns out that read-write mode is desirable for text files in the + IKI/STF kernel, so I made it legal in the UNIX kernel (it is also + legal in the VMS kernel). This mode was not legal under FOPEN in old + UNIX systems, but probably that is a thing of the past and even then + one could have gotten around it by modifying the UNIX FOPEN. Read + write access is now considered legal for text files; a seek or flush + is required when changing modes to synchronize the i/o system. + Currently RW mode is used only for file locking purposes and use of + this mode for i/o is not recommended. (5/27) + +pkg/cl/lexicon.c + The escape sequence handler in this code would map \c into c, + preventing the \ from being passed on to the code that needs it. + It now maps \c into c if c is one of the characters "&;=+-\"'\\#><()|", + i.e., the token delimiters recognized by the lexical analyzer, + otherwise \c is mapped to \c. (5/28) + +pkg/cl/history.c + The escape sequence handler in the history mechanism, which works over + the input text even before it gets to the lexical analyzer, would strip + the \ from \c when c was one of the characters ^$*. For example, \$ + would be converted to $, preventing the escape from reaching the lower + level software. Modified to recognize only \^, mapping it to ^, + since ^ is the only real history metacharacter. (5/28) + +sys/imio/immaky.x + Would name the new image when the old was intended, in the history + message. (5/28) + +sys/fio/fcopy.x + Modified to close the input file if the call to fmkcopy fails. (5/29) + +sys/fio/fmkcopy.x + Was issusing the open-failure message if the mkcopy failed. Added a + special error message for fmkcopy. (5/29) + +unix/hlib/gripes.cl +vms/hlib/gripes.cl + Now uses USERID instead of HOME to record who the gripe is from. (5/29) + +pkg/cl/grammar.h +pkg/cl/param.c + The .p_length parameter attribute is now treated properly. (5/29) + +pkg/cl/unop.c +pkg/cl/operand.h + Added a new intrinsic function STRLEN. (5/29) + +pkg/cl/param.c + In validparamget(), revised the `parameter is undefined' message to + read `the requested field of parameter .. is undefined', since I + thought the parameter itself could not be found when I saw the first + message. (5/29) + +pkg/system/lprint.x +pkg/system/page.x +pkg/system/type.x +pkg/system/help/houtput.x + In a number of calls to ttyputline(), the argument map_cc was being + passed as a boolean when an integer was expected. (5/29) + +pkg/cl/prcache.c +pkg/cl/builtin.c +pkg/cl/exec.c +pkg/cl/task.h + Added some new code to clpack(), restor(), the process cache, etc., + to automatically flush all processes connected since a package was + loaded, when the package exits. These idle processes consume + resources needlessly and it is best to free up the process slot + immediately, just as we already free dictionary space, environment + name slots, etc. (5/29) + +(Ongoing testing and development of the IKI/STF interface, not recorded here +(since this is a new interface. It is clear that bug fixes and further +(development will go on for some time - this is a complex interface). + +vms/boot/spp/xc.c +vms/boot/spp/xc.com +vms/boot/spp/mkpkg +vms/boot/spp/mkpkg.com + Installed revised version of VMS/XC from ST. (6/1) + +vms/hlib/irafemacs.com + Installed new version from ST. (6/1) + +vms/dev/hosts + Removed quotes around .exe file names in VMS node entries. (6/1) + +vms/hlib/irafuser.com + Changed a few of the job logicals to process ones to save job table + space; they don't all need to be job logicals. (6/1) + +pkg/system/doc/directory.hlp + Fixed typo, \fb -> \fB. (6/1) + +vms/as/README +vms/as/cstr.s + + Added assembler optimized versions of C string ops. (6/1) + +sys/libc/mkpkg + Revised to use as$cstr.s if available. (6/1) + +vms/boot/mkpkg/mkpkg.hlp +unix/boot/mkpkg/mkpkg.hlp + Fixed typo, \fmkpkg -> \fBmkpkg. (6/1) + +math/mathgen/mkpkg + Added a `$purge lib$' at the end of mathgen:. (6/1) + +vms/boot/bootlib/dcl.c + Installed revised version from ST. (6/1) + +vms/boot/bootlib/vfn2osfn.c +unix/boot/bootlib/vfn2osfn.c + Added check to return the null string if an error occurs mapping the + file; formerly it would return the most recent file successfully + mapped. (6/1) + +pkg/language/* + New manual pages added for logging, putlog task; others were modified + to reflect the recent changes in the CL. (6/1) + +vms/os/mkpkg +vms/os/zfiopl.c +vms/os/mcsub.c + + Installed the VMS NCAR/MCVAX version of zfiopl (the plotter interface) + from ST. (6/1) + +vms/os/rms.c + Assorted epN() changed to _epN(). (6/1) + +vms/os/str.c + Minor cosmetic changes. (6/1) + +vms/os/vms.h + Size parameters for zfiopl were changed. (6/1) + +vms/os/zxwhen.c + Modifications to permit traceback output to be spooled in a file for + debugging purposes. Default is no traceback. (6/1) + +vms/os/zmain.c + Installed the ST version; minor changes, e.g., correcting erroneous + comments. (6/1) + +vms/os/net/decnet.c + Minor fix in a comment. (6/1) + TODO: Compile both for decnet and tcp/ip; runtime switch depending + upon node. + +(System moved to VMS on 6/1. Merged all recent hlib,libc revisions into the +(VMS hlib,libc. System bootstrapped successfully on 6/2, started full sysgen +(on 6/2. + +vms/hlib/libc/xnames.h,.no_ +vms/hlib/libc/xnames.no_ +unix/hlib/libc/xnames.h +unix/hlib/libc/xnames.no_ + Added entry for ENVINIT, called by the bootlib routines on VMS. (6/2) + +sys/gio/gclose.x + Added a declaration for and(). (6/3) + +vms/hlib/lib/iraf.h [DISCUSSION] + There was a note in the ST notes file concerning the removal of the + IRAF,HOST,TMP pathnames from the C , which gets installed in + sys$library. Of course it would be nice if the logical names always + got propagated to subprocesses and this file were never referenced, + in which case it would not matter what values were put in . + At present, however, this is not the case and the file is getting + referenced at runtime to resolve pathnames. This is evident when + there are two versions of IRAF in the system, as the operation of + mkpkg is affected, of at least the operation of subprocesses called + by mkpkg. The ZGTENV routine only reads if logical name + resolution fails. If we can figure out why it fails then we can do + away with the pathnames, but for the moment I have to leave them in + to ensure that IRAF programs know where the IRAF runtime files live. + + More information on this item - we just discovered that the quota + on the size of the job table can cause logical name propagation to + subprocesses to fail. Perhaps this is the source of the problems + we have experienced in the past. I still choose to leave the + pathnames in , since it does little to impress the customer + with the reliability of our software when something fundamental like + mkpkg fails due to a quota problem on the job table. The fact is + that VMS does not reliably propagate logical names to subprocesses, + so we need a backup mechanism to ensure reliable operation. (6/3) + +vms/hlib/mkiraf.com + Added a couple queries to give the user more control over the operation + of MKIRAF. The first query asks if the uparm files are to be deleted. + The second asks for the name of the terminal; if nothing is entered + it picks a default and prints it on the terminal. Deleted the code + to delete the old login.cl file; this is not necessary on VMS since + it has file versions, and mkiraf.com is a very VMS dependent utility. + (6/3) + +sys/fio/fntgfn.x + Modified to perform string concatenation only on the root of the + filename, i.e., rather than after the filename extension. Hence, + the template `*.imh // _2' produces filenames `*_2.imh'. The + extension is defined to be the first . delimited field encountered + in any of the strings being concatenated. If there are multiple + such fields, the first such encountered is the extension of the + output filename. (6/4) + +vms/os/zopcpr.c + Changed the value of WSEXTENT for the subprocess from 1000 to 4096 + pages. This seems harmless since all it does is allow the system + to give the process that much working set if the process needs it + and the load on the system permits it. (6/4) + +dev/cacheg.dat +dev/cachet.dat + These files were updated to pick up any recent changes in the graphcap + and termcap entries for the cached devices. (6/4) + +sys/fio/ffault.x + Modified to return the number of chars available to be read in the + buffer after the iop, rather than in the entire buffer. This causes + ffault to return EOF when faulting at a seek offset beyond EOF on a + blocked binary file. (6/4) + +lib/evexpr.h +sys/fmtio/evexpr.y + An awkward feature of the way operand structure storage is mangaged + led to a "memory corrupted" bug in HEDIT. Reworked the EVEXPR code + to do the operand structure storage management in a set of procedures, + rather than by direct manipulation of the structure in the code. + EVEXPR no longer tries to reuse the same output operand structure, + it now allocates a new one on every call, leaving it up to the caller + to deallocate the operand structure returned. All allocation and + deallocation of string storage for string operands is now handled by + the operand structure procedures. (6/6) + +sys/fmtio/mkpkg +unix/hlib/irafuser.csh + Set up the FMTIO mkpkg to automatically run xyacc to remake evexpr.x + from evexpr.y if out out date, so that I don't have to remember what + command to enter (only on UNIX hosts). (6/6) + +images/imutil/hedit.x +images/iminfo/hselect.x + Modified as necessary for recent EVEXPR revisions. As far as I know, + these are the only programs currently using EVEXPR. This fixed the + HEDIT "memory corrupted" bug, which was due to having two operand + structures pointing to the same string buffer which was therefore + being deallocated twice. (6/6) + +sys/fio/fnullfile.x+ +sys/fio/protect.x +sys/fio/open.x +sys/fio/frename.x +sys/fio/falloc.x +sys/fio/delete.x +sys/imio/iki/ikimkfn.x + Added a boolean function fnullfile() to FIO, called to test if the + named file is the nullfile. Modified the listed procedures to use + the new primitive. The new procedure was added as a simple string + equality test for "dev$null" is not a reliable test, i.e., the file + name may have been mapped before being passed to the procedure which + tests for the nullfile. (6/7) + +sys/fio/fntgfn.x + The first version of the filename template package would consider + the first dot delimited field encountered to be the filename extension. + This no longer seems the best choice when dot-fields are used within + a filename for other purposes. FNT was changed so that only alpha + dot fields are considered to be extensions. Hence, "pix.01 // .44" -> + "pix.01.44", and "pix.01.imh // ".44" -> "pix.01.44.imh". (6/7) + +sys/imio/iki/ikirename.x +sys/imio/iki/ikicopy.x + If the old and new names are the same, now does nothing. Also fixed + some bugs in the logic for generating the root and extn fields of the + new image name. (6/7) + +sys/imio/iki/oif/oifrename.x + Added code to rename pixel file as well as header file. This has to + be done as the pixel file may reside in the same directory as the + header file, and the rename operation may move the header to a + different directory. (6/7) + +vms/boot/mkpkg/* + Merged in changes from ST. These were minor - XC called as a + subroutine, and a bug fix in one of the $if's. (6/7) + +vms/boot/mkpkg/tok.c + Changed SZ_LINE to SZ_PBBUF in getargs(). (6/7) + +unix/boot/mkpkg/tok.c +unix/boot/mkpkg/host.c + Merged in recent additions to vms/mkpkg so that these high level files + can be identical on the two systems. (6/7) + +vms/os/zopcpr.c + Installed a bug fix to increase the termination mailbox buffer quota + to hopefully fix the RWAST/RWMBX hung process problem. (6/7) + +vms/boot/bootlib/dcl.c + Modified to return OK only if the VMS status received from the oscmd + is 1. Return status is thus OK|ERR, which is what the calling code + (mkpkg) expects. (6/7) + +vms/boot/spp/xc.c + Now checks for the existence of files before trying to compile them. + (6/7) + +sys/tty/ttysubi.x + Was not handling the format "%+" properly. This would cause the + VT52 termcap entry to fail. (6/7) + +pkg/images/imarith/t_imarith.x + Checked if a change recently noted had gotten installed. Cleaned up + the code slightly but did not make any functional changes. (6/7) + +dev/hosts [VMS] + On our clustered VMS system, set up the satellite 750 vela as an + alias for the central host draco. This makes the networking software + work with the cluster. (6/7) + +pkg/cl/history.c + In putlog(), modified to prevent overflow of the output line buffer. + Also added a crude facility to break long output lines into multiple + lines with backslash escapes. Should be redone sometime to break lines + at whitespace, indent continuation, etc., using a VOS `putlongline' + procedure (there is already a getlongline). (6/7) + +sys/fio/osfnlock.x + Modified osfn_pkfname() to strip all backslash escapes from the final + output OS filename. Most of the code leaves the \ in to protect the + escaped character from the transformations to follow, hence the \ + often make it all the way down to this last routine. With this last + revision, \$, \[, etc. now work in the limited tests thus far run on + VMS/IRAF. (6/8) + +sys/fio/fntgfn.x + Now that \ can appear harmlessly in filenames during translation, + modified the template code to leave the \ in in more cases. This + makes it possible to use OS pathnames in templates in many cases, + provided the metacharacters are escaped. By the way, in the process + of doing the recent filename template modifications the template + code was modified to recognize / as well as $ as a directory + delimiter, hence templates such as `xx/*.h' are now legal. (6/8) + +sys/fio/fchdir.x + Fixed a comment, deleted a commented out block of code. (6/8) + +sys/fio/diropen.x + Added an errchk for syserrs(). Would continue on if could not open + directory, calling fstati on an unitialized file descriptor, leading + to a segmentation violation in the case which led to discovery of the + bug. (6/8) + +sys/fio/unread.x +sys/fio/ungetline.x +sys/fio/rename.x +sys/fio/fredir.x + Due to the above errchk bug, looked for the same problem in the other + FIO files and made minor changes to the files listed. (6/8) + +sys/fio/fdirname.x + On VMS, if fed the name of a subdirectory `subdir' would return + `subdir]'. Modified to return the concatenatable virtual path of + the given directory operand. (6/8) + +pkg/system/directory.x +pkg/system/directory.par [NEW DIRECTORY PROGRAM!] +pkg/system/isdir.x + Wrote a completely new directory lister program to replace the horrible + old thing we have been stuck with the last few years. The new program + only does the simple (most commonly used) things, but at least it works + correctly. Can now list subdirectories, or any directory by pathname, + also logical directories, directories on remote nodes, files by + template, etc. Prints "no files found" rather than echoing back the + unmatched filename. The syntax has been changed to be more terse, and + a number of new options have been added. Example: + + dir *.x l+ (long form listing) + + The old "options" parameter is gone. New parameters allow + specification of number of columns, whether or not to sort (not + needed on VMS probably), max chars of each filename to print (useful + when directory contains a few very long filenames), option to show + hidden files, etc. The new program is also more efficient and faster + than the old one. (6/8) + +sys/fio/vfnmap.x + In vfnunmap(), modified the code which deletes a trailing . (null + filename extension) to not do so if the previous character was also + a ., to avoid mapping `..' into `.'. (6/8) + +lib/protect.h + +sys/fio/protect.x + Reworked the fio.protect function so that it can be used to set, + remove, or query file protection, using the action codes defined + in the new file . Smartened up the code to know about + directory files; formerly, an attempt to query protection on a + subdirectory would cause a "nonexistent file" error due to the + .dir extension in VMS. (6/9) + +sys/imio/iki/oif/oifclose.x +sys/imio/iki/oif/oifdelete.x +pkg/system/directory.x +pkg/system/unprotect.x +pkg/system/protect.x + Modified to use . (6/9) + +sys/fmtio/patmatch.x + The metacharacters ^ and $, when found inside a pattern, were not + being encoded as regular characters properly. This would cause a + "cannot happen" message later when trying to apply the encoded + pattern. (6/9) + +sys/imio/iki/oifmkpfn.x + Fixed an interesting bug in the make-pixfile-filename routine. + The root image name was being tacked onto the OS directory name + where the pixfile would go. FIO does not translate filenames + that have an osdir prefix, so the result was that filenames were + being produced which were illegal on the host system (VMS). + This is kind of subtle - have to be on the watch for this sort + of bug in the future. (6/9) + +sys/imio/db/imget*.x + Added errchk declarations for the lower level imget routine. + Would cause a floating point exception when attempting to get the + value of a nonexistent parameter, e.g., when attempting to convert + an unitialized double to a real. (6/9) + +vms/hlib/install.com +vms/hlib/installr.com + Made entries for all iraf executables in the script, commenting out + all but those we wish to have actually installed (hope the install + utility accepts the comments). (6/10) + +dev/pix.hhh [VMS] + Installed the real pix.hhh header template file in the DEV directory + on vms/iraf. This is a funny format file peculiar to VMS, hence if + DEV is restored from a TAR tape the file type will be lost. The + template file is required to create new STF header files in the + correct format. I also read in the SCIDAT test image files and + tried out the STF kernel with them for the first time in VMS/IRAF + (the software was all developed on UNIX). Amazingly, it worked + the first time, at least as far as I can tell. (6/10) + +unix/boot/mkpkg/pkg.c + Modified to accept either "-f stdin" or "-f STDIN". (6/11) + +unix/boot/mkpkg/char.c + In getcmd(), $ would delimit the command even when used as a character + within an identifier. Modified to recognize $ as the command delimiter + only when it occurs as the first character in a new token. This fixes + the problem of $ characters in filenames in $SET macros. (6/11) + +unix/boot/mkpkg/pkg.c +unix/boot/mkpkg/tok.c + The $include directive was not working properly when called from within + a module. The module name was being passed into the context of the + include file, causing mkpkg to search the include file for the named + module and then abort with a module not found message. Modified the + push_context() function to set the module name to the null string + (disabling the module search) if the special module name "BOF" is + given. (6/11) + +sys/imio/iki/oif/oifdelete.x + Now checks if the pixel file exists before trying to delete it. + No warning message is issued if there is no pixel file, only if the + pixel file exists but cannot be deleted. An image opened new-image + or new-copy and then closed without writing any pixels will not have + a pixel file. (6/11) + +pkg/images/doc/imrename.hlp + +pkg/images/images.cl +pkg/images/images.hd +pkg/images/x_images.x +pkg/images/images.men +pkg/images/imutil/mkpkg +pkg/images/imutil/t_imrename.x + +pkg/images/imrename.par + + Added a new task IMRENAME to the IMAGES package. (6/11) + +vms/boot/mkpkg/pkg.c +vms/boot/mkpkg/tok.c + Installed the new versions of these files from unix/iraf with the + bug fixes. (6/11) + +unix/boot/bootlib/osgetenv.c +vms/boot/bootlib/osgetenv.c + One of our users edited the pathnames in the file, rendering + the file unreadable by ZGTENV. Since VMS logical name passing was + also failing (probably due to insufficient quota on the job table) + OSGETENV would fail when MKPKG tried to start up, making it impossible + to relink the system. This showed up a bug in osgetenv - the zgtenv + failure would lead to a segmentation violation since osgetenv calls + itself recursively without checking for a NULL function value. + Rewrote osgetenv to read the values of IRAF and HOST into static + storage when first called, printing an error message if the zgtenv + call fails. (6/12) + +vms/hlib/mkiraf.com + Since IRAF can now accept \$, modified mkiraf to escape $ in device + names in the login.cl. (6/12) + +vms/hlib/irafuser.com + For testing purposes, modified the irafuser.com to define our local + IRAFDISK with the $ in the name. This $ CANNOT be escaped since the + logical name is also used directly at the VMS level. It does not + need to be escaped for the high level code since all high level + references resolve into references to IRAFDISK itself, not its value. + The $ in IRAFTMP, however, must be escaped since IRAF fetches the + value of this variable, but it is not used by the VMS level code. + This inconsistency is bound to cause problems but I do not have time + to resolve it just now. (6/12) + + +[Snapshot of system sent to ST] +---------------------------------- + + NOTE regarding $-in-osdir problem: ideally, one should just be able + to include $ in OS directory names defined in the environment without + having to worry about it. There appear to be several possible ways + to achieve this: + + [1] Make the user or system manager escape the $, e.g., in + irafuser.com, login.cl, and when SET defs are entered + interactively. This is the current solution. + + [2] Escape the $ when the entry is made in the environment table. + This is unacceptable because the env. is a general purpose + facility and is not used just for filenames. + + [3] During VFN translation when an ldir is substituted, call zfxdir + to check if the substitution string is an osdir. This is bad + because of the runtime expense in recursive logical directory + expansion. + + [4] Add a new function ENVGFN to the environment package, and use + this in filename translation instead of ENVGETS. The first + time an ldir is fetched, envgfn would check it the value is + an osdir and set a flag one way or the other. Thereafter, + the expense and semantics are the same as for envgets. + + Scheme 4 appears to be the best, since there is no efficiency penalty + and no dangerous modifications to the FIO code are required. Some + modifications to the ENV package are necessary; these should be done + when the RESET function is added. Since the environment facilities + are critical to the functioning of the system, there is not sufficient + time before the next release to test such ENV modifications, hence + these revisions will have to be postponed to the next version of the + system. + +unix/boot/mkpkg/pkg.c + In parse_modname(), added a break after the call to parse_fname, + and modified the call to parse_fname to receive the entire pathname. + (6/12) + +unix/boot/bootlib/oschdir.c + Modified to accept rooted directory references as well as subdirectory + references. (6/12) + +unix/boot/bootlib/osgetenv.c + The system directory SYS was somehow missing from the list of builtin + logical directory names. (6/12) + +unix/boot/mkpkg/pkg.c +unix/boot/mkpkg/main.c +unix/boot/mkpkg/mkpkg.h + Modified mkpkg slightly (mostly in push_context and pop_context) to + remove the restriction that mkpkg modules in the call tree have to + reside physically in subdirectories. Hence, calls such as the + following are now permitted: + + $call update@pkg$cl/mkpkg + + A call such as this will return to the caller's context in the usual + way. This feature has not been extensively tested since the system + mkpkg tree matches the directory tree, but basic tests were run + without any problems. (6/12) + +[Released VMS/IRAF V2.3 as the standard system on the NOAO 8600 on 6/13] +------------------------- + +vms/hlib/install.com +vms/hlib/installr.com + Changed the ".e" extension to ".exe" for VMS. (6/13) + +vms/hlib/zzsetenv.def +vms/hlib/sdas.cl + + Added a stubbed out sdas.cl to print "not yet available" rather than + abort because it cannot find the file. (6/13) + +vms/boot/bootlib/oschdir.c +vms/boot/bootlib/osgetenv.c + Installed the new versions from unix/iraf. (6/13) + +vms/boot/mkpkg/mkpkg.h +vms/boot/mkpkg/main.c +vms/boot/mkpkg/pkg.c + Installed the new versions from unix/iraf. (6/13) + +vms/boot/mkpkg/mkpkg + Set up a new mkpkg driver file to separate the relink and install + operations. Also includes a "mkpkg debug" entry. (6/13) + +sys/fio/vfntrans.x + In vfn_decode, added code to escape any $ in the OS filename being + decoded. This allows host filenames containing $ to be read from + a directory and passed back to the system successfully. (6/13) + +vms/iraf - XC compiler [NOTE] + Just logging a note on the VMS version of XC. This version of XC + preprocesses and then compiles each .x file in the argument list + and then moves on to the next file. The UNIX XC, on the other hand, + converts all the x. to .f and then calls the Fortran compiler to + compile all the .f. I don't know why the same thing is not done for + VMS; the VMS Fortran compiler is much faster when called to compile + several files at once. This would have a much more significant impact + on performance than the business of making XC callable as a subroutine. + (6/13) + +sys/imio/iki/ikiaccess.x +sys/imio/iki/ikidelete.x + Added code to check for the null image (dev$null). This was the + source of the "Cannot open image (dev$null)" bin in RFITS. (6/13) + +vms/os/zfinfo.c + When called to get info on a directory with a name ending in ], would + fail if there was a ".;N" file in the named directory. This was + because the sys$search would find the .; file which is the filename + you get if you sys$parse a [] directory name (this probably has + something to do with why these files get created in the first place). + Added code to skip the sys$search if sys$parse returns zero length + root and extn fields. (6/13) + +vms/os/zopdir.c + In ZGFDIR, modified to return the filename ".;" rather than the null + string, when a .;N file is encountered in a directory. A `dir all+' + is still required to actually see the file. (6/13) + +dev/cacheg.dat [UNIX] +dev/cachet.dat + Updated the cache files on unix. Evidently these were only updated on + VMS earlier. (6/13) + +vms/hlib/irafuser.com + The \$ in IRAFTMP caused a problem after all, since the damn thing is + used in a VMS pathname in mkiraf.com. As a temporary workaround, + added a logical IRAFTEMP which is just the same thing without the + escape. (6/13) + +sys/fio/fioclean.x + The "stddev = ..." statement was being executed before the FP==NULL + test, causing a segmentation violation on the SUN (but not on the vaxes + for some reason). Moved it to after the test, to just before it is + used. (6/14) + +sys/fio/fntgfn.x + In fntrfnb(), added a check for an index < 1 as well as > nfiles. + (6/14) + +sys/clio/clcmdw.x + + Added a synchronous version of CLCMD. (6/14) + +pkg/system/page.x +pkg/system/page.par +pkg/system/doc/page.hlp + Extensively rewrote the PAGE task to improve the interactive aspect of + the user interface. The program is now keystroke driven in raw mode + and the old cl boolean parameter "more" is gone. Type space bar or + "f" to go to the next page, return to display the next line, N or P + to go to the next or previous file in the list, ? for help, e to edit + the current file, q or ctrl/c to quit, etc. (6/14) + +pkg/system/help/houtput.x +pkg/system/help/nomore.x - +pkg/system/help.par + Added keystroke driven page control similar to that used in PAGE to + the HELP program. (6/15) + +pkg/cl/builtin.c + In the clclear() function, added a call to c_fseti to disable RAW + mode, just in case one of the new raw mode tasks bombs out leaving + the terminal in raw mode. (6/15) + +unix/hlib/newsfile +vms/hlib/newsfile + Made an entry noting the revisions to directory, page, and help. + (6/15) + +sys/osb/miireadi.x +sys/osb/miireads.x + Added an "nints = EOF" at the top; this variable was not getting + initialized when EOF was read on the input file, causing the function + to fail to return EOF. (6/17) + +sys/gio/sgikern/* + The SGI kernel has been extended to support raster devices. The kernel + will now generate either SGK metacode output or bitmaps. All that + the user need add to interface either type of device is a graphcap + entry and a host program to process the metacode file or bitmap to + the device. On some systems host facilities will already be provided + for writing bitmap files to raster devices (e.g., UNIX). This kernel + provides an attractive alternative to the NCAR/MCVAX kludge for + interfacing new devices. (6/17) + +pkg/plot/plot.cl +pkg/plot/sgikern.par + +pkg/plot/sgidecode.par + +pkg/plot/plot.hd +pkg/plot/plot.men +pkg/plot/doc/sgikern.hlp + +pkg/plot/doc/sgidecode.hlp + + Installed the new tasks SGIKERN and SGIDECODE in the plot package. + (6/17) + +sys/gio/mkpkg + Added an entry in the update: section for @sgikern. (6/17) + +sys/gio/sgikern/sgk.h +sys/gio/sgikern/sgk.x +pkg/plot/doc/sgikern.hlp + Changed the value of the opcode for the draw line instruction to 4, + so that the metacode opcodes will form a simple sequence 1-4. No need + for different classes of opcodes in this kernel. (6/18) + +sys/gio/sgikern/sgk.x + Added support for a new graphcap flag DB. If present in the graphcap + this causes the SGI kernel to print debugging messages at runtime. + (6/18) + +dev/graphcap + Finished up the entries for the NOAO/UNIX versatec devices and tested + the new kernel both as a task and as a pseudofile i/o subkernel. + The principle disadvantage of the SGI kernel is that it does the + rasterization on the fly rather than as a queued batch job, hence + operations like the cursor mode :.snap take longer, e.g., 10 seconds. + The actual rasterization process is actually about five times more + efficient than the NCAR/UNIX software, but to the user it will appear + somewhat slower when writing to a raster device. When writing to an + intelligent device (e.g., QMS or IMAGEN) the delay should not be + noticeable. (6/18) + +sys/gio/sgikern/sgk.x + Performed the obvious optimizations, i.e., + + [1] Substituted a call to ACLRI to clear the frame buffer for + the do-loop used formerly. This function is optimized in + assembler on the VAX using the movc3 instruction (should + have had sense to use this in the first place). + + [2] In the vector drawing primitive, added optimal code for the + special cases of vectorizing horizontal and vertical vectors, + e.g., for the plot box and ticks. + + This did not take long and the running time for my test plot decreased + from 7.5 to 5.1 cpu seconds. Currently, 2.8 seconds are spent clearing + the frame buffer and writing it out, compared to 2.1 seconds to do the + actual vectorization (the clear and write operations must process the + entire raster), so probably there is little further room for + improvement. (6/18) + +SGI device/host interface status [DISCUSSION] + An SGI VMS/Fortran translator for the calcomp has been written. + No host task had to be written for UNIX for the versatec since lpr + will take bitmaps directly; the dispose command merely disposes of the + bitmap to lpr. An SGI translator for the versatec on VMS is being + worked on - it looks like it will be only a couple pages of code, + one merely has to change the record structure of the bitmap file and + copy it to the device. A translator for the Imagen will be ready + soon; this should also be a simple little program, the main problem + being trying to make sense of the "impress" language. We are looking + for someone to write a QMS translator, since this appears to be a + popular device. + +pkg/language/doc/logging.hlp + + Added this mislaid manual page to the language package help directory. + (6/21) + +------------------------------------- +Revs notice printed in newsletter. +System work stopped for several weeks due to vacation. + +pkg/plot/* + Installed a new version of the PLOT package. Most of the changes were + cosmetic, e.g., changes to parameter names in old tasks to make them + conform to GIO nomenclature. There were also a few bug fixes. (7/14) + +sys/imio/imsetr.x + When called to set NBUFS (the number of input buffers) will now free + any existing buffers before changing the size of the buffer pool. + This makes it possible to change the number of input buffers after + doing i/o to an image; the FIXPIX program was doing this, causing an + apparent memory corruption problem leading to a panic abort. Note + that a bad pointer will result if an input routine is called before + the call to IMSET since the buffer will have been returned. The output + buffer, if any, is not affected by a change in NBUFS. (7/15) + +sys/imio/iki/oif/oifdelete.x +sys/imio/iki/oif/oifrename.x + Added a check for IM_PIXFILE(im)==EOS (no pixel file) so that these + operators will not attempt to rename or delete the pixel file if there + isn't one, i.e., the image was created but never written into. (7/15) + +pkg/cl/unop.c + In a couple of sscanf() calls, changed the %d and %f to %ld and %lf, + since the output variables are type long and double. (7/15) + +sys/gio/cursor/grcread.x +sys/gio/cursor/grcwrite.x +sys/gio/cursor/giotr.x + The :.write command would formerly write the binary WCS structure at + the beginning of the output metacode file, followed by the frame + buffer, and the :.read would expect the same structure when reading + a file. This was bad because the resultant metacode files were not + in the standard GKI metafile format, hence problems would result when + :.write files were input to other programs, or when standard metafiles + were read by :.read. Also, the whole business was no longer necessary + since the SETWCS instruction is now included in the metacode in the + frame buffer. Removed the write/read WCS code from grcread/grcwrite, + and added a case to GIOTR to reset the WCS when the SETWCS instruction + is encountered in the frame being redrawn. (7/15) + +sys/libc/isatty.c + This LIBC interface routine was the source of the bug causing + or bye to logout of the cl, rather than printing the "use `logout' to + log out of the CL" message - end of file must always cause logout if + the CL command input is not the terminal. The recent introduction of + the new VOS virtual terminal driver ZFIOTT was causing the isatty() + test to fail, since isatty() was using the driver associated with the + stream to determine if the stream was connected to a terminal. + Modified isatty() to recognize either ZFIOTY or ZFIOTT as a terminal + driver. (7/15) + + vms/hlib/libc/knames.h + vms/hlib/libc/knames.no_ +unix/hlib/libc/knames.h +unix/hlib/libc/knames.no_ + Added an entry for ZGETTT to these files. Put the define in knames + rather than xnames since it is a kernel driver, even though it resides + in the VOS rather than the kernel. (7/15) + +pkg/cl/binop.c + The STRIDX function would not work properly when there was more than + one character in the first argument string (had to invert the nested + loop). (7/15) + +lib/gio.h +sys/etc/oscmd.x +sys/gio/sgikern/sgk.x +sys/gio/cursor/prpsio.x +sys/gio/cursor/proscmd.x +sys/gio/cursor/gtrdiscon.x + The SGI kernel relys upon the use of the ZOSCMD facility to permit + use of a host or foreign task to dispose of the metacode or raster + file to a host plotter device. This was a problem on VMS since the + VMS version os ZOSCMD cannot be called from a subprocess; only the + root (CL) process can spawn a sub-DCL. + + To get around this problem OSCMD now determines whether the calling + process is a connected subprocess, and if so, sends the OS command to + the parent process via CLOUT, as a command line of the form "!oscmd". + The PRPSIO and GTR_DISCONNECT routines (which handle the pseudofile + XMIT/XFER requests) were modified to intercept OS escapes and process + them directly. Synchronization is achieved by returning the ZOSCMD + exit status via IPC to the OSCMD procedure in the subprocess. + If necessary the command will be passed all the way back up a + multilevel process tree to the root process before submission to the + host system. Note that these semantics are available only in the + VOS routine OSCMD; the kernel routine ZOSCMD will always try to send + a command directly to the host system. (7/16) + +sys/gio/glabax/glbencode.x + This routine trims insignficant trailing zeros and decimal points from + tick labels to produce a more concise label. This led to a bug in + exponential format, as a label such as 1.0E10 would be trimmed to + "1.0E1". (7/16) + +sys/imio/imt.x + The image template code will automatically escape any image notation + metacharacters present in the filename returned from the FNT package. + This was causing the @listfile type of image template to fail since + the image templace code thought the [...] sections in the image + listfile were part of the filename, and would escape them, causing + IMIO to interpret them as part of the filename rather than section, + and hence fail to find the image. This was fixed by turning off + all image template translation of the strings returned from a listfile, + hence any escapes needed must be explicitly included in the listfile + elements. (7/16) + +------------------------------------------- +VMS/IRAF system updated from lyra. (7/16) + +vms/os/net/zfioks.c + Changed the "Password:" prompt to "Password (user@node):" so that the + user will know which login and node the password is being requested + for when spawning a kernel server on a remote node. (7/17) + +pkg/system/page.x + Fixed a bug that would cause the last line in the file to be repeated + when a continuation keystroke is erroneously entered at the end of file. + Modified page to quit without a prompt when displaying a single file + small enough to fit all on one screen. Smartened up the ":line N" + syntax to permit omission of the space, and added a [+/-]N syntax for + relative offsets. Finally gave in to the temptation and added + backwards movement in files (but not in pipes yet), e.g., `u' (up) is + the opposite of `d' (down), `k' goes up a line while `j' goes down, + and so on. (7/17) + +pkg/system/lineoff.x + + Added a new package LNO (line offset package) in the SYSTEM directory + for keeping track of the file offsets of a subset of the lines in a + text file. This is used by the PAGE program but is a general purpose + package which can be copied and reused in other similar programs. + + lp = lno_open (maxlines) + lno_close (lp) + lno_save (lp, line, loffset, ltag) + OK|ERR = lno_fetch (lp, line, loffset, ltag) + + The package does not actually know anything about text files - its' + function is to associate a pair of long integer tag values (the file + offset and some other value) with each of a set of up to maxlines + integer keys (the line numbers). (7/17) + +pkg/cl/* + The current PAGE program cannot be used in the keystroke drive mode + when reading from a pipe, since the only way a subprocess can read + from the terminal in raw mode in by reading from an unredirected STDIN + in raw mode. After some study it appears that the best solution to + this problem is to add a new parameter type to the CL which reads from + the terminal in raw mode to satisfy a query. This avoids the use of + STDIN, eliminates the need to mess with raw mode in simple keystroke + driven programs, eliminates the need to worry about UCASEIN mode in + every keystroke driven program, makes keystroke driven interaction + possible in CL scripts, and so on. + + Accordingly, a new abstract datatype UKEY has been added to the CL. + UKEY is identical to GCUR except in the way the query is performed + and in the format of the returned value string. Also in analogy to + GCUR, a new list-structured parameter `ukey' has been added to the + CL global parameter set. Referencing the `cl.ukey' parameter (or any + parameter of type UKEY) in an expression will cause a raw mode + keyboard read, e.g., + + = ukey + or + while (fscan (cl.ukey, key, strval) != EOF) + ... + + A UKEY type parameter returns a "struct" value (i.e., a string) with + the format + + key [strval] + + where the `strval' is the null string unless the key is :, i.e., + a colon escape as in cursor mode. A new CLIO procedure CLGKEY will + be added to CLIO in analogy to CLGCUR for use in keystroke driven + loops in applications programs. (7/18) + +sys/clio/clgkey.x + + Added the CLGKEY function to CLIO. The function of CLGKEY is to + perform a raw mode read of a keystroke from the keyboard on the + user terminal. Single keystrokes are not echoed and the cursor is + not moved. The key ":" causes the cursor to move to the beginning + of the current line, the ": " prompt to be issued, and the `strval' + to be read. KEY is returned an integer value. EOF is returned if + end of file is detected on the input list, or if the key + or is typed. Interrupts are disabled during a raw mode + keystroke read, hence interrupt is returned as \003. + + nitems|EOF = clgkey (param, key, strval, maxch) + + CLGKEY is equivalent to CLGCUR except that the coordinate information + is omitted. CLGKEY flushes any buffered STDOUT or STDERR output before + reading from the terminal. The CL parameter may be local to the + calling task and of type "*ukey" to permit redirection of keyboard + input to a list file. (7/19) + +pkg/system/page.x + Modifed PAGE to use the new CLGKEY facilities so that the keystroke + driven interface is available in pipes as well as on disk files. + Added a pattern searching capability, accessed via the colon escape + ":/" rather than with a simple / as one might expect + (because the clgkey interface only supports string arguments for + colon escapes). + + PAGE is now fairly complete except for backwards movements in pipes, + which would require buffering of the input data, and except for + upscrolling, which is currently not implemented (backwards motions + are implemented by repainting the full screen). The revisions to PAGE + have already consumed so much time that I suppose I should have just + scrapped the original program and written a new, fully featured one + from scratch. (7/19) + +pkg/system/help.x + Modifed to use CLGKEY. (7/19) + +pkg/system/doc/page.hlp + Updated this manual page. (7/19) + +unix/os/zfiotx.c + Changed the ioctl TIOCSETP to TIOCSETN to avoid discarding pending + terminal input when switching to "raw" mode (`cooked' in unix). + This makes type ahead possible in programs like PAGE and HELP which + are constantly switching between the raw and normal terminal modes. + It may also make cursor reads safer, since it might be possible for + a terminal to begin transmitting the cursor value sequence before + the program switches to raw mode, causing part of the return value + to be lost. (7/19) + +-------------- +Upgraded vms/iraf (7/19). + +sys/tty/ttyputl.x + The optimized code was breaking long lines and writing them out in + chunks the width of the terminal screen, but was not adding a newline + at the end of each output line, hence text was being lost on terminals + not set to wraparound in hardware. (7/20) + +pkg/system/count.x + The line count would be off when counting a file containing lines + longer than SZ_LINE. Modified to bump the line counter only when + newline is seen. In general, however, IRAF cannot be expected to + work correctly on text files containing very long lines. (7/20) + +local/tasks/README + The old README file in this directory was copied from PROTO and was + useless. Replaced it by a new README file explaining what the LOCAL + package is, and outlining the steps to be taken to install a new + task. (7/20) + +unix/boot/mkpkg/char.c + vms/boot/mkpkg/char.c + In k_fgets(), return NULL rather than `ch' if a read error occurs. + (7/20) + +pkg/cl/modes.c + In proc_params(), if called for a procedure with a null argument + list, will now initialize to hidden the mode of all parameters for + which the mode was not explicitly set when declared. Formerly, + such parameters would end up with a default mode of auto. (7/20) + +sys/imio/iki/stf/stfrgpb.x +sys/imio/iki/stf/stfwgpb.x + Added support for a boolean/logical data type. (7/20) + +sys/imio/iki/stf/stfopen.x + For the moment, modified to always reblock the old header in a + NEW_COPY operation, else an VMS/RMS file write error may occur + when updating the header. This should probably be done at update + time instead. (7/20) + +pkg/system/page.x + Fixed PAGE to run noninteractively if its STDOUT has been redirected. + Unfortunately, this redirection test fails when PAGE is called from + another task such as NEWS, and the output of the calling task has + been redirected. No easy solution to this at present. (7/20) + +sys/imio/iki/stf/stfwgpb.x + Was not blank filling character variables when updating the group + parameter block. (7/20) + +-------------------- +vms/iraf updated (7/20) + +vms/boot/spp/xc.c + In mktemp(), added a `static' to the declaration for the char buffer + in which the output filename goes. (7/21) + +doc/suniraf.hlp +doc/unixiraf.hlp +doc/vmsiraf.hlp [MISSING?] + Moved the installation guides to the doc directory so that they won't + get lost (but where is the VMS one?). (7/21) + +doc/ports/* + Moved all the old notes files from the LOCAL directory in VMS/IRAF to + the doc/ports archive. Deleted some other old files in LOCAL. (7/21) + +sys/fio/ungetline.x + Fixed typo: `fiodes (fd)' -> `fiodes[fd]'. (7/21) + +sys/fio/fcanpb.x + +sys/fio/* + Added a new FIO internal procedure fcanpb(fd), called to cancel out + any pushback and return the file i/o pointers to their normal state. + Added calls to this procedure in various places throughout FIO. + The new routine is a no-op if there is no pushback, so this should be + relatively risk free. This was found by the new PAGE program, which + is one of the few programs to use the FIO pushback facilities. (7/21) + +vms/os/qio.c + This bug showed up in MTIO, which was not seeing the end-of-tape mark, + causing the tape to run off the end of the reel, or worse, the + program to appear to work while actually writing nothing at the end + of the tape. The AST routine was returning a count of zero when + end-of-tape was encountered, causing _zflush() to return a zero in + the same circumstance, when this was really an error condition. + Modified so that _zflush() returns XERR when an end-of-file status + is returned in a write operation. (7/21) + +sys/mtio/mtrdlock.x + If the lock file does not exist or cannot be read from some reason, + a new lock file will now be written and the position will be returned + as undefined, causing MTOPEN to rewind the drive. The new MTIO will + do i/o to the drive even if the lock file does not exist, but would + abort at close time since the lock file must exist to be updated. + Creating a new lock file at open time should permit i/o even if the + drive has not been allocated within IRAF. (7/21) + +sys/imio/imaccess.x + This new function (currently unused) was calling iki_access() with + the wrong number of arguments. (7/22) + +imfit/fit1d.x +imfit/t_lineclean.x +imutil/imdelete.x + The above tasks were all incorrectly using the FIO access() function + to test for the existence of images. Replaced by a call to the + imaccess() function. (7/22) + +MTIO - discussion + A number of changes were made to fix some problems/complaints received + in past months regarding MTIO. There was a bug where the user would + allocate/mount the tape in VMS, get into IRAF, run a program which + would successfully do i/o to the drive (this would work) and then + when it was all done, an "cannot close file" error would occur. + This would happen because the kernel level MTIO routine called to + udpate the tape position needs the old lock file to update the tape + position in the lock file. The fact that the drive was allocated + outside of IRAF is not really a problem because the new allocation + software in the CL knows if a device is allocated/mounted, regardless + of whether this was done in IRAF or the host system. + + MTIO was modified in such a way that it should no longer matter + whether the user allocates the drive in IRAF or before running the CL + (I'm not sure what happens if an OS escape is used; did not test that). + If there is no lock file because the drive was allocated/mounted at + the host level, MTIO will simply write a new lock file which records + the tape position as undefined. The following changes were made to + implement this scheme. + +mtio/mtalloc.x + Changed to record the initial tape position as file 0 (position + undefined) rather than file 1, since we do not really know how + the tape is positioned at allocate time. Setting the tape position + to 0 in the lock file is harmless; the effect is to require MTOPEN + to rewind the tape to get to a known position at open time. This + change will be visible to the user who runs `devstatus' after + allocating the tape drive. (7/22) + +mtio/mtrewind.x +mtio/mtstatus.x + If called when there is no "lock" (save-position) file, will now + write one indicating that the position is undefined, rather than + abort. In the case of mtrewind, it is then immediately updated + to indicate that the tape is at file 1. (7/22) + +unix/hlib/login.cl + vms/hlib/login.cl + After the call to TYPE to type the message of the day, added a call + to DELETE to delete any old "mt?.lok" files in UPARM. This is + essential, as otherwise MTIO might use an old lock file for a new + tape and erroneously position to the wrong file. The delete operation + is performed at login time rather than logout time because [1] doing + it at logout is not safe, as the CL or host may crash and never go + through logout, [2] login takes so long the extra time will not be + noticed, [3] the call to DELETE occurs immediately after the call to + TYPE to type the message of the day and immediately after connecting + the subprocess, hence everything will be paged in and it should go + fast. It would have been nicer to do this in hlib$clpackage.cl, + but that is not possible since UPARM is not yet defined when that + file is read. (7/22) + +sys/mtio/mtdevall.x + +sys/mtio/mtopen.x +sys/mtio/mtrewind.x + Added a new internal routine mt_devallocated() to MTIO. This is called + by MTOPEN and MTREWIND to ensure that the drive has been physically + allocated before proceeding further. This is necessary because the + presence of the "lock" file can no longer be used to test if the device + has been allocated. If the device has not been allocated a message + is printed to that effect, rather than proceeding further and printing + a misleading i/o error etc. message. (7/22) + +unix/hlib/stripper +unix/hlib/stripall + vms/hlib/stripper + vms/hlib/stripall + Will no longer delete the .hd files or the .key. A number of other + protected extensions were dropped and replaced by the single + extension .dat. (7/22) + +---------------------------------------------------- +Snapshot of new V2.3 system sent to CTIO. + +sys/etc/xalloc.x + In xdeallocate(), the MTIO deallocate command was being called after + the device was deallocated at the host level. This was backwards + because the MTIO routine may rewind the device, hence must be called + before the device is physically deallocated (dismounted). (7/23) + +sys/mtio/mtrdlock.x + When called with no lock file present, mt_allocate() was being called + with the drive name minus the "mt" prefix, e.g., device "b" rather + than "mtb". (7/23) + +---------------------------------------------------- +Snapshot of new V2.3 system sent to STScI. + +sys/imio/imsetr.x + The variable `ibdes' is used to test if an input buffer descriptor + had been allocated before NBUFS was changed, as a new one must be + allocated in that case after the change. The bug was that the old + one was being freed by an `mfree (ibdes, ...)' which zeros `ibdes', + causing the test to fail. Replaced the ibdes by IM_IBDES in the + call to mfree. This bug would cause the FIXPIX task to fail, + since this wierd task likes to change the value of NBUFS after + doing i/o on the image (technically illegal but I am trying to + make it more user proof). (7/23) + +sys/imio/iki/iki.h +sys/imio/iki/ikiparse.x +sys/imio/iki/stf/*.*;* + It turns out that the ST folks have reserved an entire large class + of filename extensions for their images, rather than a finite set. + The legal header extensions are ".??h" and the matching pixel file + extensions are the same with a "d" as the last character. Modified + the iki_parse() routine and various routines in the STF package to + implement this scheme. Since IKI checks for an OIF (.imh) image type + first, it will recognize OIF images even though the OIF extension + is a legal STF extension. + + Only the changes to the iki_parse() routine affect OIF format images, + and the iki_parse() routine has been tested as a unit, hence bugs may + have been introduced into the STF interface, but the changes do not + require retesting of the IRAF image operators. (7/23-24) + +dev/devices [VMS/IRAF] + Added an entry for `mtg' (MSC0:), the TS11 recently added to the DRACO + cluster. (7/24) + +dev/graphcap +vms/gdev/sgidev/* +vms/hlib/irafuser.com + Several system revisions were made over the past week or so to install + the SGI translators. I have waited until now to document this so that + testing of the new interface could be completed. + + An SGI translator is a host system program which disposes of an SGI + metacode or bitmap raster file to a specific device. The programs + may be as host specific as desired; for VMS, we have written a couple + template programs for the versatec (bitmap interface) and the calcomp + (metacode interface) which are VMS Fortran with all the extensions + and even a little assembler in places if necessary. Similar programs + can be written at user sites with little or no knowledge of IRAF + internals. The translator programs are only a few pages of Fortran, + most of which can be reused for new devices. + + The source for these programs resides in vms$gdev/sgidev. + The mkpkg.com and mkpkg in this directory compile and link the + translators and install them in hlib$. A graphcap entry must be + added to dev$graphcap and a VMS foreign task declaration must be + added to irafuser.com, then the device is fully interfaced and + available for use with all IRAF graphics software. (7/24) + +vms/os/zopcpr.c + In prinit(), called to get the quotas of the parent process when the + first subprocess is spawned, the value of the parent's WSEXTENT was + being assigned into the wrong slot of the `quotas' array, causing + this feature to fail. Fixed this bug and added additional entries + for WSDEFAULT and WSQUOTA, so that the subprocess will inherit + all these nondeductable quotas from the parent. The system default + working set of 200 is hopeless for IRAF processes; on a busy system, + large memory batch jobs, for example, will quickly gobble up the + pages of an idle x_system.e, causing little system tasks (like DIR) + to take a minute or so to run each time. It seems better to let + the user/system manager control the working set parameters for the + entire process tree (on a per-user basis depending upon what they + need) rather than only for the CL process. (7/24) + +vms/os/zoscmd.c + Added a badly needed multiple-command capability to the VMS ZOSCMD + kernel procedure. The command separator character chosen was the + DCL comment character !, which is not likely to be useful in the + context of OS escapes. For example, + + cl> !show time !show users + + would issue the two commands "show time " and "show users" in that + order. This may eliminate the need to use a DCL .com file in some + applications, possibly simplifying and condensing table driven + interfaces, and making things somewhat more efficient. The feature + should be useful in foreign task definitions, the editor interfaces, + the graphcap entries for SGI devices, and other places where OS + commands are used. The revision was made to the VMS kernel procedure + rather than to etc$oscmd.x for reasons of efficiency, to avoid the + blank line output to the terminal after every command by the VMS + ZOSCMD, and to permit selection of a metacharacter suitable for the + host system. (7/24) + +vms/hlib/irafuser.com +vms/hlib/mkiraf.com + Deleted the temporary workaround logical IRAFTEMP, replacing it by + IMDIRDISK and TEMPDISK. There are now three system logicals which + must be set up in IRAFUSER.COM, e.g.: + + IRAFDISK USR$0: ! Disk IRAF resides on + TEMPDISK SCR$2: ! Runtime (scratch) files go here + IMDIRDISK SCR$1: ! User image subdirectories go here + + IRAFTMP is now defined in a site independent way in terms of these + logicals, like IRAFHOST, IRAFHLIB, and so on: + + IRAFTMP TEMPDISK:[IRAF] ! scratch files + + This should help to eliminate any confusion about when and when not + to escape $ characters, since this is no longer necessary for anything + in IRAFUSER.COM. The MKIRAF script will automatically escape the $ + when generating the user login.cl file. MKIRAF now creates the default + user image storage (IMDIR) directory as IMDIRDISK:[USER] rather than as + IMDIRDISK:[IRAF.USER], since this appears to be closer to the way + things are usually done in VMS. + + TEMPDISK and IMDIRDISK are no longer the same as IRAF uses tmp$ (on + TEMPDISK) for runtime scratch files that can be deleted on a daily + basis if desired, whereas the image pixel files may need to be kept + around longer. Files created by IRAF in tmp$ are normally deleted + immediately by IRAF unless a program is aborted, in which case the + host system is expected to clean things up. That is why a public + device is preferred for TEMPDISK. + + Sites which do not permit public directories or devices will have to + make IRAFTMP point to a user directory. This can be done in many ways, + e.g., by defining IRAFTMP in the user's LOGIN.COM file. IMDIR is only + used by the runtime IRAF system, hence need only be defined in the + user's login.cl, where it can be set to any of a number of values, + e.g., `uparm$', `home$imdir/', `HDR$', or `HDR$pixels/'. If the user + has their own private IRAFTMP it will probably not be the same as the + value in the installed version of , but this may not be a + problem as the latter may not be accessed except by the IRAF login + when doing heavy duty operations with the HSI, e.g., sysgens. (7/24) + +vms/os/zopcpr.c [discussion] + The system paging activity seems much improved following yesterday's + change to ZOPCPR (to pass the parent's working set parameters on to + the child). Formerly, the child would inherit the system default + WSQUOTA of 200 and a WSEXTENT of 1024 (due to the bug). A busy + process would fault up to 1024 and then rapidly drop back to 200, + causing virtually the entire process to have to be paged back in + every time a task was run in the process. Since other VMS processes + would often have much larger quotas, the performance of the IRAF + processes would seem poor by comparison. Things should be improved + somewhat now, with the next major improvement to come if and when + shareable libraries are introduced. (7/25) + +dev/graphcap + In the entry for the 4014, added a | and a comment after the `tek4014' + on the header line so that the device name `tek4014' would be usable + externally. (7/25) + +vms/os/net/zfioks.c + Replaced the recently introduced (mistakenly) call to sprintf() by an + equivalent series of calls to strcpy() and strcat(), to avoid use of + the DEC C runtime library. (7/25) + +pkg/cl/modes.c +pkg/cl/gquery.c + Deleted the `%newmode' feature, used to change the mode of a parameter + in response to a query. This feature has not proven useful (it is + inadvisable to change the mode of a parameter in any case) and has + lately become a problem since % is now used as the string edit + metacharacter in image templates. Responding to a query for an image + template with a perfectly legal template, e.g., `%im%im_%...' would + cause an obscure `bad mode spec' error message. If anyone ever wants + to change the mode of a parameter they can still do so by an explicit + assignment into the .p_mode field of the parameter. (7/25) + +----------------------------------------------- +Partial updates sent to CTIO, STScI (7/28 am) + +doc/vmsiraf.hlp + + Found a copy of the VMS installation guide in a scratch directory on + another computer. Dusted it off and put it in the DOC library. (7/28) + +sys/gio/sgikern/sgk.x +sys/gio/sgikern/sgk.com +sys/gio/sgikern/sgipl.x +sys/gio/sgikern/ltype.dat + +sys/gio/sgikern/mkpkg + Added software generation of polyline linetypes (dotted, dashed, etc.) + to the SGI kernel. Added a new SGI graphcap parameter NB, specifying + the number of bits per byte for packing the output raster data. Also + added more documentation in the file describing the meaning of all the + parameters used to control the generation of bitmaps. (7/28) + +sys/etc/xalloc.x + The ZDVOWN kernel primitive was being passed the device list string + from the dev$devices file when the host device name was intended. + This would work fine on VMS since the device list on that system + contains only one device name, but on UNIX there are many /dev entries + for each physical drive hence it would fail. (7/29) + +sys/osb/bitfields.c +sys/osb/zzdebug.x + The portable versions of BITPAK and BITUPK in bitfields.c were overly + general, allowing bitfields to be read and written in a bit array of + arbitrary length. Since the assembler versions are currently limited + to operations upon integer scalars, the bit-array generality was not + needed and I replaced bitfields.c by a simpler and more efficient + version which only deals with a single longword at a time. Brought + the zzdebug.x up to date as well. (7/30) + +pkg/xtools/icfit/doc +noao/onedspec/identify/icfit/doc +noao/onedspec/identify/uparmbkgXXX + Deleted these garbage files. The DOC files were regular binary files + that were once UNIX directory files. (7/30) + +sys/imio/imsetr.x + Yet another imset(IM_NBUFS,.. bug. Must reset IM_NGET(im) to zero + when the number of buffers is changed. (7/30) + +iraf/local/notes.st [UNIX] +iraf/local/suninstall.hlp [UNIX] + Deleted these files as there are already copies in doc$. (7/30) + +iraf/local/login.com [VMS] +vms/hlib/mkpkg.inc [VMS] + Sometime back, I removed the LNK$LIBRARY reference to the C runtime + library from the IRAF LOGIN.COM file. This was done in case C + library references creep into the kernel, to cause the linker to + flag such references. One result is that the CALCOMP kernel no + longer links under mkpkg on VMS. This is easy to get around on + those rare occasions when this host system dependent executable + needs to be relinked, until I have time to figure out the best way + to reference sys$library:libcrtl.olb directly via mkpkg. For now, + turned off the USE_CALCOMP switch in the mkpkg.inc so that remote + sites do not get the error messages when relinking the system. (7/30) + +------------------------------------------------------------------------ +Cut and mailed distribution tapes for the six VMS/IRAF V2.3 early test sites. +Make UNIX source only archive tape and started SUN/IRAF upgrade. (7/31) + +vms/hlib/irafuser.com + Changed the definition of the IRAFTMP logical from TEMPDISK:[IRAF] to + TEMPDISK:[IRAFTMP], and changed the name of the corresponding public + directory on our system as well. This was purely a name change to + avoid having multiple [IRAF] directories on different disks used for + different purposes. Of course, the system installer can change the + name to anything they want if desired, since knowledge of the actual + directory is confined to IRAFUSER.COM (and ). (7/31) + +unix/boot/rtar/doc +unix/boot/rtar/doc/std.ms + Deleted this garbage test directory and the file therein. (7/31) + +pkg/dataio/fits/spool +noao/onedspec/doc/tmp +noao/onedspec/log.plotx +noao/twodspec/multispec/spool +noao/twodspec/multispec/make.log +noao/twodspec/longslit/doc/tmp +noao/twodspec/longslit/transform/spool +noao/twodspec/longslit/spool +noao/mtlocal/camera/header + Deleted the above junk files. (8/4) + +unix/boot/rmfiles/rmfiles.c +unix/boot/rmfiles/rmfiles.hlp + Made two modifications to the RMFILES utility: [1] the root of the + directory to be pruned need no longer be an immediate subdirectory, + and [2] the program file can contain lines of the form + + -file filename + + to delete individual files that do not fit into any particular class. + This will make it possible to build stripper files that prune even + more off the tree. (8/4) + +unix/hlib/stripper +unix/hlib/stripall +vms/hlib/stripper +vms/hlib/stripall + Examined a list of the files left after running the original stripper + scripts, and added entries (using the new RMFILES capabilities) to + strip more files here and there. In particular, did away with a lot + more stuff in the HOST directories, and all the manual pages dealing + with subroutines rather than CL callable tasks. (8/4) + +sys/gio/cursor/gtrgflush.x + I may have found the old STDGRAPH/STDPLOT/STDGRAPH segmentation + violation bug, which we have not been able to reproduce in recent + times. It showed up on the sun. The GTR code caches the descriptor + for a stream, saving the FD of stream in a variable TR_STREAM to + indicate what is in the cache. The low level GFLUSH routine would + initialize a stream, but was not setting TR_STREAM to null if the + stream being initialized was the one in the cache. Calling GTR_INIT + to cache the descriptor for another stream would result in the code + trying to move the old descriptor from the cache to the dynamically + allocated descriptor, which was deallocated by the GFLUSH, zeroing + the pointer and causing the segmentation violation. (8/5) + +sys/gio/cursor/prpsio.x + If an unsolicited command is received from a graphics subkernel (when + an XMIT or XFER is expected) the command is printed on STDERR with + a call to putline, followed by the `unsolicited command input' error + message. The bug was that the FIO buffer is passed to PUTLINE as + is, and at this level in the system the string is not EOS delimited, + causing garbage to be printed after the data string. Modified to add + the EOS before calling putline. This bug would only be seen when a + subkernel aborts for some reason. (8/5) + +sys/gio/cursor/prpsio.x + The same problem (no EOS) as above, except this time in the string + passed to OSCMD. (8/5) + +sys/gio/nsppkern/gktopenws.x +sys/gio/sgikern/sgiopenws.x + When opening the first device after process spawn, the STARTFRAME + field of the GKT/SGI descriptor was being accessed before the descriptor + was allocated and initialized, leading to a zero-pointer bug. (8/5) + +sys/gio/sgikern/sgk.x +sys/gio/sgikern/sgk.com + Added two new bitmap formatting options to the SGI kernel, BS and WS, + for swapping every 2 (BS) or 4 (WS) bytes of the bitmap at output + time. (8/6) + +dev/graphcap + Added a `dver' entry, and the `vtri' entry from VMS/IRAF. Tuned up + the versatec plotting window parameters to provide a unity aspect + ratio. (8/6) + +sys/gio/sgikern/sgk.x +sys/gio/sgikern/sgk.com + Added yet another new SGI bitmap formatting option, NF. The NF (new + file) option, if set, causes the individual frames of a multiframe + set to be written into separate files named $F.[1-MF], i.e., $F.1, + $F.2, ..., $F.MF. This option is also supported for metacode output. + It makes it possible to use LPR to dispose of the raster output + directly without a translator (on UNIX). This is very efficient + since no reformatting is required and the LPR job is queued. (8/6) + + Also discovered and fixed a bug in the SGK kernel. If XO was nonzero, + the x scale factor was not being computed correctly, causing the plot + to be truncated at the right. (8/6) + +sys/etc/main.x + The iraf main would not accept redirection on STDPLOT. Added it to a + case statement. (8/7) + +pkg/cl/builtin.c +pkg/cl/edcap.c +pkg/cl/eparam.h +pkg/cl/globals.c + Fixed a bug in the editor interface that would cause it to fail when + attempting to edit more than one file at a time. Also, string storage + in the command list was limited to 10 and 12 characters with no overflow + checking when the file is read in; added #defines to parameterize + these (rather small) numbers, and modified the initialization code to + truncate long strings rather than run off the end of the array. + + Also changed the way EDITOR_CMD (the command to be sent to the host + system to invoke the editor) is implemented internally. The string + is no longer stored in the command list, since the string storage there + is limited to only 10 characters, and EDITOR_CMD is not an editor + command anyway. The actual command string can now contain whitespace + provided it is quoted, can be up to SZ_LINE chars long, and most + importantly, may contain a %s somewhere in the string to be replaced + by the filelist. If no %s is present then " %s" is added at the + end, making it all compatible with the old edcap files. + + In combination with the multiple commands per os-escape feature + recently added, this makes it possible for the command sequence sent + to the host system to consist of several commands with the file list + embedded in there somewhere. This makes it possible to eliminate + a .COM and two wasteful process spawns from the VI editor interface + on VMS. (8/7) + +vms/hlib/irafuser.com +vms/hlib/irafvi.com +dev/vi.ed [VMS] + Redid the VI interface on VMS to eliminate the use of the IRAFVI.COM + script and the calls to STTY therein. VI is now called with the + following OS escape: + + "set term/pasthru/passall!vi %s!set term/nopasthru/nopassall" + + where the %s is replaced by the list of files to be edited. This + speeds things up considerably and eliminates the dependence on the + STTY task. (8/7) + +vms/boot/rmfiles.c +vms/boot/rmfiles.hlp + Merged the new version of the RMFILES bootstrap utility into the + VMS HSI. The link failed the first time since the C runtime library + was not defined as a LNK$LIBRARY: need to add defines for this to the + bootstrap .COM files, or maybe make the user type it in. (8/7) + +---------------------------------------------------- +Updated VMS/IRAF (8/7) + +vms/hlib/irafuser.com +vms/hlib/sgiqueue.com + +dev/graphcap + Modified the VMS SGI interface to submit the translation jobs to the + `fast' queue. This eliminated the SGI definitions in IRAFUSER.COM. + The single command script SGIQUEUE is used for all SGI devices. (8/8) + +sys/fmtio/patmatch.x + The match at end of line metacharacter $ will now work at EOS as well + as at newline. (8/8) + +sys/gio/stdgraph/stgrcur.x + Fixed the bug that was probably causing the cursor read failure where + successive cursor reads return garbage keys. The delimiter pattern + (CR for the tektronix) was being matched anywhere in the returned + cursor value string. If a character were lost somehow, e.g., due to + insufficient delay after sending a command to a slow terminal, then + the cursor read routine would read 6 characters, find the CR in there + somewhere, and accept the garbage cursor value. The left over + characters would cause the next cursor read to fail, and so on. + Modified the cursor read routine to match the delimiter (CD) only + at the END of the accumulated cursor value string, if the number of + chars in a cursor value (CN) is positive. More precisely, if CN > 0, + the cursor value will be accepted if len(valstr) >= CN and the pattern + CD//$ matches valstr. (8/8) + + Fixed a second bug: the routine is designed to restart the cursor if + a cursor value still has not been matched after 15 characters have + been accumulated. Instead, it was decoding the 15 character garbage + value and returning (usually harmless, as the program would beep and + the cursor would be restarted). Modified to discard the input and + restart the cursor read without returning. (8/8) + + (USER NOTE - if you lose the cursor for some reason, type any key ) + (except [RETURN] until the cursor comes back. ) + +dev/graphcap +dev/cacheg.dat (rebuilt) + The above bug was discovered due to the lack of soft delays (null + padding) in the graphcap entry for the VT640. The symptom was that + the cursor value was coming back minus the first character. What + was happening was that graphics was being deactivated, a couple + of lines of text output were written, and then graphics was immediately + reactivated and a cursor read issued. It was taking the terminal a + while to draw all the text, and this was still going on when the + graphics add-on board was reactivated, causing the cursor read to + terminate early. The above fix to the read cursor routine ensures + recovery, but to avoid the cursor read failure I added a 150 msec delay + to the GE (reactivate workstation or graphics enable) graphcap entry + for the VT640 and several other terminals. (8/8) + +dev/README +dev/vdmfile.gki +dev/vdmplot.gki + Replaced dev$mc by a file dev$vdm.gki containing a slightly different + selection of plots. Rewrote the README file for the directory as it + was completely out of date - it now contains some useful information + about the files in the directory. (8/8) + +sys/gio/cursor/gtrinit.x + If a very large plot is processed, the cursor mode frame buffer will + overflow and data will be discarded. An environment variable is + available to the user to increase the maximum size of the frame + buffer should this be a problem. Changed the name from the rather + verbose and non specific `maxlenframebuf' to `cmbuflen' (goes with + `cminit'). Name change should be no problem as I don't think anyone + knew about this parameter. (8/8) + +pkg/cl/history.c + At long last, brought the argument substitution feature of the history + mechanism up to date, i.e., modified it to work on whitespace rather + than comma delimited argument lists. Also added the ability to specify + arguments by number (^[0-9]). The possible argument symbols and their + meanings are therefore now: + + ^^ first argument of last command + ^$ last argument of last command + ^* all arguments of last command + ^0 taskname of last command + ^N argument N of last command (1 <= N <= 9) + + This conventional CSH-like history mechanism, simple as it is, is often + much more effective than the history editor and it is a pity that more + people do not know how to use it. (8/9) + +vms/boot/*/mkpkg.com +vms/boot/spp/*/mkpkg.com + Have not tried a full bootstrap of the VMS/HSI for a while, so thought + I had better make sure it still works before V2.3 goes out. Made the + following changes first: + + [1] To all MKPKG.COM and MKPKG files which call the linker, added a + DEFINE/NOLOG LNK$LIBRARY entry to cause the linker to search the + C runtime library, required by the current version of the VMS/HSI + (but not by the runtime system). This was necessary because the + original define statement was recently removed from the IRAF + LOGIN.COM file to prevent references to the C rtl from accidentally + creeping into the runtime system. + + [2] In all HSI linker calls, added the switch /NOSYSSHR. This + causes the system object modules referenced by the HSI + executables to be copied into the new executable, rather than + using an indirect reference to the system shareable library. + The effect is to make each executable about 40 Kb larger, + but rumour has it that these executables will run on older + versions of VMS without relinking. If true, this makes the + entire IRAF system runnable on old versions of VMS, since the + runtime system can be relinked with MKPKG provided the HSI is + runnable. + + [3] In the RPP mkpkg.com, fixed a bug in the IF (...) THEN GOTO LINK + which would cause the library to always be rebuilt. + + Ran MKPKG on boot/bootlib and boot/mkpkg to make the .MLB files, + purged all and lib/compress-ed the new libraries in HLIB. (8/9) + +------------------------------------------ +VMS/IRAF updated from lyra. +Sysgen performed (also served to test rebuilt HSI). (8/9) + +doc/*.doc + Deleted; can be regenerated from the .hlp. (8/11) + +doc/cluser.tex +doc/cluser/* + Installed the manuscript for the V2.3 CL User's Guide. Deleted the + entire cluser subdirectory, only the TEX file is needed. (8/11) + +osb/mkpkg +lib/libvops.a +osb/miiread[csi].x - +osb/miiwrite[csi].x - +etc/mkpkg +etc/miiread[csi].x + +etc/miiwrite[csi].x + + The miiread and miiwrite procedures use FIO and hence cannot be in the + VOPS library (OSB), else a linker unresolved reference will occur. + In any case, they are portable and do not need to be in OSB, so moved + them to ETC. The potentially machine dependent MII primitives remain + in OSB. (8/11) + +sys/gio/stdgraph/t_showcap.x + Fixed an argument type mismatch: `call pargc (char (intval))' does + not coerce the argument to type char due to limitations in the + preprocessor. The solution was to eliminate the call to CHAR, and + replace the PARGC by a PARGI. (8/12) + +pkg/system/directory.x + Fixed a portability bug, discovered on AOS/IRAF. The dir_putci() + routine, which has a boolean argument, was being called with an integer + argument in one case. Changed the argument type to integer. (8/12) + +dev/graphcap +vms/gdev/mkpkg +vms/gdev/mkpkg.com +vms/gdev/sgi2vptx.f + +vms/hlib/sgiqueue.com + Installed the SGI translator for the Printronix on VMS. (8/12) + +vms/gdev/iism75/m75put.x +vms/gdev/iism75/zrdm75.x + The M70 has an 10 bit DAC driving the guns, whereas the M75 only has + an 8 bit DAC. Modified these routines to scale the 10 bit M70 OFM + values to and from 8 bits for the M75. (8/12) + +pkg/images/tv/display/iisofm.x + Modified to set the full 1024 elements of the lookup table; formerly + it was setting only the first 256 elements. (8/12) + +unix/os/mkpkg.csh + In checking out IMFORT in the new system, the link failed due to the + undefined external irafmn_. This turned out to be be due to the + presence of zmain.o in libos.a. The zmain.o module contains a C + main(), which was being selected in preference to the Fortran main(). + This occurred because zmain.c got installed in the library during + the bootstrap by mkpkg.csh. Modified the OS mkpkg.csh bootstrap so + that this module is not inserted into the library. (8/13) + +sys/imio/iki/oif/oifdelete.x + If the image header file is not protected, the delete would fail + because the file protection could not be removed. Modified to proceed + to delete the file if it is not protected. (8/13) + +sys/imio/imfort/* + Brought IMFORT up to date for the new IMIO. New images are created + with the extension .imh. The extension is optional when referencing + an image. Pixel files are always created in the same directory as + the header file (for IMFORT), so the HDR$ form of the pixfile name + is stored in the image headers. The IMFORT created images are not + file protected, unlike the IMIO images, since IMFORT users may be + working outside of the IRAF environment. (8/13) + +dev/pix.imh + Changed the pixel file name in the image header from dev$pix.imh to + HDR$pix.imh, since that is how the new system does this sort of thing + (and I could not read the image from IMFORT). (8/13) + +local/noao [VMS/IRAF] +local/noao/gmr27 + Created a new directory [LOCAL.NOAO] on VMS/IRAF and put the Grinnell + display interface code there. (8/13) + +----------------- +Updated VMS/IRAF; rebooted VMS/IRAF; sysgen. (8/13) + +pkg/images/iminfo/imheader.x + The size of the user area was being computed incorrectly, leading to + STROPEN being called on a string of length zero. Since stropen + returns EOF at EOS, I merely changed it to call stropen with the + length of the string as ARB. This was the source of the problems + with IMFORT generated images on VMS/IRAF, as these images have an + empty user area (which is completely legal). (8/14) + +sys/fio/stropen.x + Changed the argument string dimension from `maxch' to ARB to avoid + a possible runtime array dimension error in VMS/IRAF. (8/14) + +============================================================================ +Version 2.3 of IRAF frozen; began distribution (8/14 pm). +============================================================================ + +unix/boot/mkpkg/tok.c + In getcmd(), there was still one case where $ was being recognized as + a special character even though it occurred inside a token. This was + causing the OSB mkpkg file to fail in a call to $generic. The argument + list for $generic had a `\$$' embedded in a filename which was supposed + to map to `\$'. This is correct for mkpkg, because with very few + exceptions, the only special metacharacter in mkpkg is $, and it is + escaped by doubling (as in make). Backslash is just another character + in mkpkg scripts. (8/15) + +pkg/plot/doc/sgikern.hlp + [TODO] diff --git a/doc/notes.v25 b/doc/notes.v25 new file mode 100644 index 00000000..dd9ba6c1 --- /dev/null +++ b/doc/notes.v25 @@ -0,0 +1,6367 @@ +============================================================================ +Version 2.3 of IRAF frozen; began distribution (8/14 pm). +Begin Version 2.4. +============================================================================ + +unix/boot/mkpkg/tok.c +vms/boot/mkpkg/tok.c + In getcmd(), there was still one case where $ was being recognized as + a special character even though it occurred inside a token. This was + causing the OSB mkpkg file to fail in a call to $generic. The argument + list for $generic had a `\$$' embedded in a filename which was supposed + to map to `\$'. This is correct for mkpkg, because with very few + exceptions, the only special metacharacter in mkpkg is $, and it is + escaped by doubling (as in make). Backslash is just another character + in mkpkg scripts. (8/15) + +unix/boot/mkpkg/pkg.c +vms/boot/mkpkg/pkg.c + In parse_modname(), modified to map \$ or \/ (the possible vfn + directory delimiter characters) into $ and /, rather than leaving + the backslash in the filename. This did not cause a bug, but I + noticed it while fixing above bug, and it did not look right. (8/15) + +lib/*.h +lib/clpopn.h - + Deleted the file , which I don't think is used anywhere + anymore. Made minor edits to the headers of the global include files + to eliminate the blank first lines in some of the older files, and add + the filename in caps to the file header comment, so that they all look + the same. Of course, this will cause much of the system to be + recompiled, but it is time for a sysgen of the master system in any + case. (8/15) + +------------------ +Full bootstrap and sysgen (from the sources) of UNIX/IRAF and VMS/IRAF; set up +version 2.4 of the system. SUN/IRAF updated to V2.3. (8/15-16) + +local/mkpkg + [VMS] + Added a mkpkg file to the LOCAL directory on VMS, so that a sysgen + will find its way into the local/tasks directory. (8/16) + +dev/graphcap + Deleted the `co' and `li' entries from the SGI graphcap entry for the + versatec; don't see why these would be needed for this device. (8/17) + +unix/os/zfiomt.c + In zzrfmt(), the read packet size of 32 would cause read() to return + ERR on the Sun when reading a large record, whereas it would return + 32 on the VAX. Changed the 32 to 32768 to ensure that it is larger + than the maximum record size on the tape. This is a pretty big buffer + to put on the hardware stack, but it should be safe. (8/19) + +-------------------------- +No system modifications during the period 20 August through 5 September. +(At DAO doing the port of IRAF to the Alliant vector superminicomputer). + +pkg/plot/doc/sgikern.hlp + Updated the manual page for the `sgikern' task. (9/6) + +sys/osb/f77upk.f + Added stripping of the blank fill at the right to the F77UPK primitive. + The F77PAK primitive already blank pads at the right, so F77UPK ought + to remove the padding. Use CHRUPK if this is not desired. (9/6) + +pkg/utilities/split.x + + Added a new task SPLIT to the utilities package. SPLIT is used to + break large, unmanageable files up into smaller files. (9/6) + +pkg/plot/mkpkg +pkg/utilities/mkpkg + I am not happy with either the ..x.e or ..1.e suffixes currently in + use to flag temporary package local executables before installation. + The former does not stand out enough, and the latter does not suggest + its purpose. Changed the above packages to use an "xx_" prefix instead. + The "xx_" prefix means "test (experimental) executable". (9/6) + +doc/ports/alliant_86.doc + Installed the notes file from the Alliant port. There was some + problem with the backup/tar file I made on the Alliant, hence it was + not easy to get the notes file off the tape. I had to use the new + SPLIT task to split the 24 Mb archive into 49 512000 byte segments, + and eventually determined that the notes file was at line 11115 of + segment 39! The problems with the tape are almost certainly not with + the tape itself, since I did a backup/compare at DAO, and backup did + not report any problems when the tape was read. + + I think the most likely culprit is the FTP software, which had to be + used to move the archive to the VMS VAX, since the DAO Alliant did not + have a tape drive. FTP (binary mode) insisted on making a file with + an undefined VMS record type; this would cause RTAR to crash the VAX + if I tried to look at the file on the VMS VAX at DAO. The 24 Mb archive + file has one enormous section of about 3.5 Mb which is all zeroes, + causing tar (or rtar) to get a premature end-of-tar indication (two + zeroed file blocks). I tried the exact same operation (with a smaller + test file) using our Eunice FTP and everything worked fine. The DAO + TELNET also gave problems; it would hang up if fed too much data too + fast, and would occasionally crash with a stack trace. Based on these + experiences, I would certainly have to recommend the Wollongong + networking software over the other vendor. (9/6) + +--------------- +Begin merge of fixes from Alliant/IRAF port. + +unix/hlib/i1mach.f +unix/hlib/r1mach.f + Commented out calls to ULIBER. (9/7) + +unix/mc68000/zsvjmp.FX + + Added the zsvjmp/zdojmp code for the Alliant. (9/7) + +unix/os/zgtime.c +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + Changed all references to the 4.2BSD include to . + There is also a file on our system and on the Sun, but the + form appears to be the standard. (9/7) + +unix/os/zxwhen.c + The hardware exception list in this code is very hardware dependent + and often needs to be changed for a new UNIX host, so I replaced the + code by a version which is set up to make it easy to add a machine + dependent list of hardware exceptions. The default exceptions are + those for the VAX. Also replaced the symbol `vector' by `vvector' + as on the Alliant, since the latter serves our purposes just as well. + (9/7) + +unix/os/zfiomt.c + To zzrfmt_() (skip record forward), added a comments section noting + the portability aspects of the routine, which has failed on three + machines thus far (due to differences in the device drivers or C + compilers). Changed the size of the auto buffer from 32768 to 29184, + since the former cause a compile time error on the Alliant. This + means that the largest tape block size UNIX/IRAF can handle is + something close to but less than the 15 bit unsigned limit (32768). + For example, 28800, i.e., FITS blocked to 10, is acceptable. (9/7) + +unix/boot/spp/rpp/ratlibf/dsfree.f + On line 20, the hollerith string contained a tab where a space was + intended. (9/7) + +unix/boot/mkpkg +unix/boot/bootlib/mkpkg.csh + Figured out a way to replace the CSH script mkpkg.csh in bootlib + by a equivalent series of SH commands, one per line, so that the + "sh -x mkpkg.csh" construct used throughout the rest of the unix + bootstrap can be used in this case too. Besides being more consistent, + this is safer, because the bootstrap no longer depends upon execute + permission on the bootlib mkpkg.csh file. (9/7) + +sys/gio/gki/gkigca.x + The min() intrinsic function was being called with operands of mixed + type, i.e., int and short. Also, a Mems[] reference was missing the + `gki' pointer. (9/7) + +sys/vops/lz/mkpkg + Added $checkout etc. directives to the file header. (9/7) + +unix/boot/generic/tok.l +unix/boot/generic/generic.c + Made two fixes in the generic preprocessor: [1] changed the declaration + of the external `xtype_string' in tok.l from (char *) to (char []). + The former would work on most machines, but is not correct, and not + portable; [2] modified so that "0$f" will be expanded for type complex + to (0.0,0.0) rather than (0,0). The latter assumes that the Fortran + compiler can handle the implied type coercion, which is not true for + all compilers. (9/7) + +sys/vops/ak/a*x.x +sys/vops/lz/a*x.x + Deleted the following files so that their complex versions will be + regenerated by the new generic preprocessor in the next sysgen: + + ak/abeqki.x, ak/abgeki.x, ak/abgtki.x, ak/ableki.x, ak/abltki.x, + ak/abneki.x, ak/aclri.x, ak/adoti.x, ak/advzi.x, lz/allni.x, + lz/alogi.x, lz/arcpi.x, lz/arczi.x, lz/assqi.x, lz/asumi.x + (9/7) + +pkg/system/help/t_lroff.x + Added an extern declaration for `getline'. (9/7) + +pkg/cl/task.h + Eliminated the (unsigned) type coercion from the next_task macro. + This should not be necessary, since (char *) is already an unsigned + quantity. I checked the macro currently in use on AOS and it appears + that the unsigned coercion was causing problems on that machine too, + and that the present macro will probably work. (9/7) + +unix/hlib/mkpkg.inc +sys/vops/mkpkg + Added a new variable XVFLAGS to the global mkpkg include; these are + the compile flags for VOPS and any other vector processing packages. + Added a reference to the VOPS mkpkg to pick up the flags. (9/7) + +sys/gio/gki/gkiopen.x +sys/gio/gki/gkititle.x + The pointer `gki' was also omitted in Mems[] references in these + routines. (9/7) + +sys/fio/osfnlock.x + Changed the procedure osfn_initlock() from an integer function to + a subroutine. (9/7) + +sys/vops/amap.gx + Broke the min/max expression into two statements to fix a mixed + type problem for case short. (9/7) + +sys/osb/mkpkg +sys/osb/achtb.gc +sys/osb/achtu.gc +sys/osb/achtzb.gc +sys/osb/achtzu.gc + Modified the above files to treat type complex properly, and restored + type complex to the call to generic in the mkpkg. Also deleted some + old acht*.c files that were being referenced in the mkpkg and installed + in the library, but which were not being regenerated from .gc generic + sources. (9/7) + +sys/ki/irafks.x + Changed the procedure kserver() from an integer function to a + subroutine. (9/7) + +pkg/images/imdebug/mkimage.x + Changed the procedure immake() from an pointer function to a + subroutine. (9/7) + +pkg/images/tv/display/iiswnd.x + Contained constructs such as `max (0, lut[i])', where `lut' is a short + integer array. This caused a min/max type mismatch error. Also, a + statement had a nonfunctional C like ; at the end. (9/7) + +pkg/images/tv/cv/iism70/iishisto.x + Same problem, short integer variable `offset'. (9/7) + +pkg/images/tv/cv/iism70/iisrange.x + Lots of problems mixing int and short in calls to AND, OR. (9/7) + +pkg/images/tv/cv/iism70/zsnap.x + This module caused the fortran compiler to core dump with an internal + error; it was trying to resolve mixed int/short operands in expressions + and couldn't handle this code, evidently. (I feel much the same way + trying to read it.) + + Deleted `int min(), max()' intrinsic function declarations. Added an + itemp temporary to fix a couple min/max statements which mixed int + and short operands. (9/7) + +pkg/images/tv/cv/iism70/iishisto.x + Lots and lots of compile time problems with short variables. (9/7) + +unix/hlib/libc/kernel.h + Changed HZ from a float constant to an int constant. (9/7) + +unix/os/zgtime.c +sys/etc/sysptime.x + Rewrote the system timer code to use only integer arithmetic; there + is no good reason for low level system code to have any dependence + on floating point. (9/7) + +-------------- +(end merge of Alliant/IRAF mods and bug fixes) +(did a bootstrap and sysgen) + +sys/imio/iki/oif/oifopen.x + The oif_open procedure was setting IM_HDRFILE, but then reading the + image header from disk into the imhdr structure, overwriting the + new header file name. This would cause an invalid pixel file name + to be generated when accessing an image that used HDR$ in the + pixel file name field, but which had been moved to a new directory + or node. Modified oif_open to set IM_HDRFILE after reading in the + header from disk. (9/8) + +sys/gio/stdgraph/stgopen.x + In the call to stg_openws to open the workstation at kernel open time, + changed the mode from NEW_FILE to APPEND to avoid the screen clear + that would otherwise occur. (9/10) + +dev/termcap + Changed the entries for the noao versatec devices to use LPR rather + than VPR and /dev/vp0. (9/11) + + +LYRA UPGRADED TO 4.3BSD UNIX +Begin port of UNIX/IRAF to 4.3BSD (on aquila, 9/11/86) +------------------------------------------------------------------- + +installed new system (stripped to source only) at /tmp2/u on aquila +set .login, .cshrc up for new root +set /usr/include/iraf.h to point to new system +old command links in /local/bin left pointing to /iraf + +unix/hlib/libc/iraf.h + Changed root to /tmp2/u/. + Commented out the `#define BSD42' and added `#define BSD43'. (9/11) + +---------------------- +(begin bootstrap) + + Several files failed to compile in the kernel. + +unix/hlib/libc/kernel.h + Added a `#ifdef BSD43' section to the header of kernel.h. First entry + is a `#define _NFILE 64' for 4.3BSD. Max number of open files increased + from 20 to 64, yeah! (9/11) + +unix/os/zfiopr.c + Changed the name of the variable `sigmask', used in zfiopr.c to save + the old signal mask, to `sigmask_save'. The name `sigmask' is now a + defined macro in . (9/11) + +unix/boot/spp/rpp/ratlibc/initst.c + Changed the _NFILE to a `10'. The RPP never has many files open at + any one time, this should be fine. (9/11) + +--------------------- +(bootstrap completed; begin sysgen) + +unix/hlib/iraf.h +unix/hlib/mach.h +unix/hlib/libc/spp.h + The Fortran compiler would refuse to compile modules containing INDEFS + or INDEFL, which were set to -2**15 and -2**31 for the VAX, as + indicated in the VAX Architecture manual. A fatal `integer overflow + in constant expression' would result. This is a bug in the compiler, + but the the modules would not compile, so changed the values of these + constants in the above files to one less in both cases. Probably the + number is being accumulated as a positive number and the sign applied + later, hence the integer overflow (since 2**31 - 1 is the largest long + on a vax). (9/11) + +sys/gio/nspp/sysint/errprt77.f + Moved SAVE statements on lines 374 and 410 to before the DATA + statements. (9/12) + +pkg/dataio/fits/fits.h + This file contains as explict integer contstants the values of FITS + `blank' pixels, -2**15 and -2**31. These cause integer overflow on + 4.3BSD since they are the same values as the IRAF indefinites. Also, + these values should not occur in supposedly machine independent code. + A 2/4 byte rather than numeric comparison should be used to test for + FITS magic values instead. For the moment, I changed the values + slightly to enable compilation - this does not solve the problem. (9/12) + +pkg/images/filters/med_sort.x + In the second procedure, local variable `i' not used. Also, the + underscore should be removed from the filename. (9/12) + +noao/mtlocal/idsmtn/read_varian.x + This file contained a number of cases of very large explicit integer + constants that would cause integer overflow at compile time in the + 4.3BSD compiler. The values were not arbitrary hence could not easily + be changed, so for the moment just deinstalled the idsmtn directory + so that the remainder of MTLOCAL could be linked. (9/12) + +sys/imfort/* + +sys/imio/imfort/* - + Installed an all new IMFORT in sys, and deleted the old version in + imio. The new IMFORT is much more comprehensive than the original, + and includes more image i/o routines, access to image header parameters, + and access to and decoding of command line arguments. (9/12) + +unix/boot/spp/xc.c +unix/boot/spp/xc.hlp + I want to use XC to compile and link host Fortran programs that use + IMFORT, so added a switch `-h' to link host programs, i.e., to link + without the IRAF main (a command line module must contain a main + routine), and without searching the IRAF libraries unless explicitly + referenced on the command line. Also added a reference to the Fortran + library -I77 to XC, required to link host Fortran programs. Library + references (-llib) would cause a link even if -c was given on the + command line; now will not link if -c flag is given, regardless of + any other flags that might be present. + + This switch was formerly called -Np in the UNIX XC, and was absent in + the VMS XC, and the old `-h' would cause a nonstandard SPP header + definitions file to be used. Changed the old `-h' (which is very + rarely used) to `-Nh'. + + xc -hO prog.f ... -limfort -lsys -lvops -los + + The above command line suffices to compile and the host Fortran program + PROG.F and link it with the IMFORT and other IRAF libraries. This can + be defined as a foreign task `fc' or whatever in the USER package to + minimize typing. (9/12) + +pkg/cl/builtin.c + Modified the code used to construct the host command line for a foreign + task to support optional argument substitution. The sequences $1, $2, + etc. (up to $9) refer to the individual arguments on the IRAF foreign + task command line, $* refers to the entire argument list, and $0 is + replaced by the IRAF taskname. A sequence $(N) or $(*) causes each + input argument to be treated as a virtual filename and mapped into its + host system equivalent for insertion into the host command line. + + For example, this permits foreign task definitions such as the + following, used to define a new task FC to compile and link host + Fortran programs which use the IMFORT interface: + + task $fc = "$xc -hO $* -limfort -lsys -lvops -los" + + The facility should also be useful whenever an IRAF foreign task causes + more than one host command to be executed, e.g., in combination with + the ! os escape command delimiter in VMS (or ; in UNIX). An argument + or the argument list may be referenced any number of times in the + command template. Whitespace is not added before or after the argument + reference, hence sequences such as `$1.o -o $1.e' will work. + + For backwards compatibilty the argument list is simply appended to the + command template if no $arg sequences are encountered. The new + facility is not completely backwards compatible, however, because any + $ in the command template must now be escaped to be included in the + final host command. (9/13) + +---------------------------------- +(system moved back to lyra which now runs 4.3BSD) +(files modified on lyra version of IRAF in past two days merged into 4.3BSD +(version of the system) + +sys/mkpkg +sys/imfort/* + +sys/imio/imfort/* - +sys/imio/mkpkg + The new IMFORT package contains more than just image access routines, + hence was installed in sys rather than imio. Deleted the old package + in imio and modified the mkpkg files to reference the new package. + (9/14) + +sys/etc/erract.x +sys/etc/xerfmt.x +sys/etc/xerpue.x + + Examination of the symbol tables of host Fortran programs using IMFORT + showed that a lot of things were being linked in that should not be, + i.e., much of IPC and KI. I have also noticed this before with the + HSI programs, but did not bother to track it down. The problem proved + to be in the xer_putline routine in erract.x, and in xer_fmterrmsg in + xerfmt.x, both in ETC. I removed the xer_putline routine from erract.x + and rewrote it to access the file driver connected to STDERR remotely + through the FIO device table. This avoids a link time reference to + the IPC file driver and the KI (which ordinary IRAF subprocesses must + use for error recovery since they can run on a remote node). + In xerfmt, I merely removed the `include ' reference - this + requires that lib$syserrmsg be available on the local node, which + seems like a safe bet if an iraf kernel server is available. With + this change Fortran/IMFORT programs can be as small as 60Kb on UNIX, + and they should be even smaller on VMS with the Fortran shared library. + (9/16) + +unix/os/zfiotx.c + The uio_bwrite() procedure was written explicitly for the 4.2BSD stdio + system to provide greater textfile i/o efficiency for block transfers. + Without checking into it carefully, it appeared that this code (which + has intimate knowledge of the 4.2BSD stdio internals) was not working + on 4.2BSD. I was expecting that that would be the case when 4.3 came + along, and anyhow the 4.3 version of fwrite() has been optimized to + use block transfers, so I changed the code to use fwrite and deleted + the old code. 4.2BSD is history now anyhow. (9/17) + +unix/boot/spp/xc.c + Now accepts -f as the equivalent of -F; HSI tasks should not be case + dependent for portability reasons. Added a switch -x which maps into + the debug switch for the host system. These changes make the most + commonly used switches the same for both the UNIX and VMS versions + of XC. (9/19) + +lib/names + + Added a file lib$names, containing a sorted list of all the external + Fortran callable library names in the libraries libimfort.a, libex.a, + libsys.a, libvops.a, and libos.a. MATCH can be used to ask all sorts + of interesting questions about this database. In particular, the + user/programmer can check to see if a name is already used by the + system to avoid library conflicts with external names in their own + programs. (9/20) + +-------------------------- +Updated VMS/IRAF: all files modified in the past 35 days. + Complete new versions of the following directories installed: + sys/imfort + sys/gio/ncarutil + noao/imred/dtoi + noao/mtlocal/idsmtn + noao/onedspec/identify + noao/twodspec/apextract + +Also merged all recent UNIX/IRAF HSI changes into the VMS/IRAF HSI. + These included bug fixes in generic and spp, addition of the -h + flag to XC, addition of a set for imfort to zzsetenv.def, + bug fixes in the [ir]1mach.f files in hlib, addition of a + define for FC to the default hlib$login.cl, and addition of + XVFLAGS to hlib$mkpkg.inc. (9/21) + +vms/boot/spp/xc.c + Added an alias -m for the -M (make link map) flag. + Changed the default to optimize and added a flag -q to turn + optimization off. Hence, the -O is no longer needed. (9/22) + +vms/hlib/mkpkg.inc +vms/hlib/login.cl + Changed the "-cO" to "-c". (9/22) + +unix/boot/spp/xc.c + Changed the default to optimize, and added the `-q' flag to turn + optimization off. (9/22) + +unix/hlib/mkpkg.inc +unix/hlib/login.cl + Changed the "-cO" to "-c". (9/22) + +vms/boot/bootlib/dcl.c + This routine uses SHOW STATUS to get the status back from a command + sent to DCL. The output from the command followed by SHOW STATUS is + scanned, and when the output from SHOW STATUS is seen, that output + line is filtered out and used to set the exit status to be returned + to the HSI code. The problem is that a very explicit string compare + was being used to match the output of SHOW STATUS, and the output + string changed in 4.4 VMS. The old format was + + " $STATUS = %Xdddddddd" (VMS 4.3) + + this changed to + + " $STATUS == %Xdddddddd" (VMS 4.4) + + This would cause the status to be missed, and one of the above messages + would appear mixed in with the output of the program for every command + sent to DCL. I modified dcl.c to be a little more forgiving of + changes to the exact format of this string. (9/22) + +sys/imio/iki/oif/oifmkpfn.x + The / was being included in the subdirectory name, causing ZFSUBD + to fail on VMS, although it would work on UNIX. (9/22) + +dev/pix.imh [VMS] + Changed the pathname for the pixel file to HDR$pix.pix. The previous + value, dev$pix.pix, was set manually with HEDIT and is illegal since + it is a virtual filename, and low level programs like IMFORT programs + cannot handle that. (9/22) + +vms/hlib/init.dbg [VMS] + Had to change the window assignments because the old values were + inappropriate for the V4.4 version of the debugger - DEC just can't + leave the thing alone! (9/22) + +sys/ki/mkpkg +sys/ki/kilnode.x + + Added a new function to KI (used by vfntrans, see below). + + yes/no = ki_localnode (nodename) + + The function is used to test if the named node is an alias for the + local node. (9/28) + +sys/fio/vfntrans.x + Made a fix for the following problem. Start with a logical directory + such as + + set dd = node!usr0:[user.imdir] + + File references will then be of the form "dd$pathname", rather than + "node!ldir$pathname". We do not discover that the file is on a + remote node until the logical directory has been expanded. The fix + was to convert "dd$pathname" into "node!dd$pathname" during logical + directory expansion, i.e., as soon as the reference to the remote + node is detected, the translation is discarded and the whole thing + turned into a remote file reference. The process repeats on the + remote node, but when the logical directory is expanded on the + remote node the node name is an alias for the "local" node, and + filename translation completes normally, resolving into a server-local + file reference. (9/28) + + TODO: will have the same problem for non-filename resources. + +sys/ki/kgfdir.x + Filename mapping and unmapping has to take place on the node on which + the resource physically resides. The problem here is filename + unmapping; when a directory is read, the kernel server on the remote + node unmaps the filenames into IRAF names, return IRAF filenames to + the server code on the client node. These filenames were being + passed up into the VOS, which would immediately "unmap" them again, + causing constructs such as .e, .o, etc. to be mapped to .\e, .\o, + and so on. This is necessarily so since the VOS must unmap host + filenames returned by the kernel (or the KI). The fix was to map + the filenames for the local host in the client, i.e., the remote + kernel server maps the remote host filenames into IRAF names, sends + the IRAF names to the client, the client maps them into local host + name, returns these to the VOS, and the VOS unmaps them using the + translation tables for the local host. (9/28) + +sys/imio/iki/oif/oifmkpfn.x + Added an `include ' reference since the file references KFSUBD. + (9/28) + +vms/os/net/zfioks.c + When connecting to a remote node, the "Password (...): " prompt could + be printed on the terminal before pseudofile output was flushed via + IPC and the CL, since both processes would be talking directly to the + terminal. This lack of synchronization could confuse the user, so + added a 50 millisecond delay before prompting for the password to + allow the i/o streams to empty. (9/28) + +sys/fmtio/patmatch.x + There were two cases where a procedure had a char argument but was + being called with an integer character constant. (10/2) + +sys/gio/sgikern/mkpkg +sys/gio/sgikern/sgk.h +sys/gio/sgikern/sgiinit.x +sys/gio/sgikern/sgipcell.x + Added support for cell array output to the SGI kernel. The kernel + takes 8 bits in and renders it into a 1 bit display for the output + plotter device. The algorithm is suitable for both raster devices + and metafile devices. (10/4) + +pkg/proto/imsqr.x + +pkg/proto/imfunction.x +pkg/proto/doc/imfunction.hlp + Added support for the SQRT function to the IMFUNCTION task. (10/4) + +sys/gio/stdgraph/stgpcell.x + Added support for cell array output to the STDGRAPH kernel. (10/6) + +lib/gio.h +sys/gio/gstatr.x +sys/gio/gsetr.x + In , the GP_ASPECT field, which is the desired aspect ratio + for the GLABAX viewport and not the physical device aspect ratio, + was defined as in integer field. Changed to a Memr reference. + In gsetr, the field was being assigned into with an integer value, + rather than the floating point value. (10/5) + +dev/vdm.gki + [UNIX,VMS] + Restored the standard test metacode file, which was accidentally + deleted at some point on the lyra version of the system. On VMS, + the file was present but had the wrong VMS file type, hence was + unreadable. Restored the file on both the UNIX and VMS versions + of the system. (10/6) + +sys/ki/kignode.x + Will now skip leading whitespace at the beginning of the resource name. + Whitespace or any other nonalphanumeric characters encountered while + extracting the node name prefix will cause node name extraction to + terminate, causing the system to treat the resource as present on the + local node. (Hence, "abc!..." is a reference to resource `...' on node + `abc', while "abc !..." is a reference to resource `abc !...' on the + local node). (10/6) + +sys/ki/mkpkg +sys/ki/koscmd.x + +sys/ki/irafks.x +unix/hlib/knet.h +unix/hlib/libc/knames.h +unix/hlib/libc/knames.no_ + Added support for ZOSCMD to the kernel interface. If the host command + string is prefixed by a node prefix (e.g., "node!...") the command + will be passed to the host command interpreter on the remote node. + The remote kernel server spools the output of the command in a text + file, returning the name of the spool file to the KI on the local + node. The KI (KOSCMD) then copies the spooled output to either the + stdout_file named in the KOSCMD argument list, or the terminal if + no file was named. + + This feature was added to provide network support for the SGI kernel, + but of course it makes remote execution of a command possible wherever + an OS escape occurs. The syntax can be a bit confusing, but there is + no alternative. For example: + + cl> !node!w + + will execute the command `w' on node `node', whereas + + cl> !node !w + or + cl> !node\!w + + will execute the command `node !w' or `node!w' on the local node. + On a UNIX node, if the first character to ZOSCMD is a !, /bin/sh + will be used to execute the command, hence + + cl> !node!!w + + will execute the `w' command on the remote node with the Bourne shell. + Just in case you aren't totally confused by now, on a VMS node, + a leading ! is used to fire up a new DCL and is also the multi-command + delimiter, so it is possible to create such atrocities as + + cl> !vmsnode!!show time!show users + + Since both UNIX and VMS nodes do something fairly harmless if the + first character in the OS command is a !, one can type "!!oscmd" to + force a command to be executed on the local node without stripping + of the node prefix, unintentionally or otherwise. + + Note that this feature may also be used to execute foreign tasks + on remote nodes, by including the node prefix in the foreign task + declaration. This allows the output of the remote command to be + redirected elsewhere by the local CL, although the process is not + very efficient due to the use of several temporary spool files. (10/6) + +sys/etc/xerpue.x + Fixed a bug discovered when testing the above mentioned feature. + In xer_putline(), the char count being sent to ZPUTTX or ZPUTTY + was being multiplied by SZB_CHAR, causing extra junk to be printed + at the end of the output data string. This routine is also called + to print error messages during error recovery, and the bug could + produce erroneous output when a task is run standalone, e.g., when + the CL is run. When a task is run as a subprocess the output is + not a text device, so the bug would not matter. (10/6) + +sys/ki/irafks.x +sys/ki/kiopenks.x + The KI support for ZOSCMD requires creation of a temporary file on + the remote server node to spool the oscmd output. SGI also wants + to write into TMP on the remote node. It turns out that the kernel + server, being an IRAF process, will automatically call ZGTENV to + read the local values of the HOST, IRAF, and TMP environment + variables from (or the logical name table, or wherever) + provided they are not already defined in the environment table. + I modified the code which transmits the client's environment list + to the server to exclude the local definitions for HOST, IRAF, and + TMP, so that the server will use the values for the server node + instead. I also deleted the SETROOT code, formerly used to reset + the value of IRAF after transmitting the environment list, because + it is no longer needed. (10/7) + +sys/gio/sgikern/sgk.x + Modified to recognize a node prefix in the device name ("node!device") + and include the node prefix in the spoolfile and dispose strings, + causing the plot file to be written and disposed of on a remote + node. (10/7) + +lib/syserrmsg + Changed the "No entry in termcap database file..." error message so + that it is suitable for both termcap and graphcap devices. (10/7) + +sys/etc/xgdevlist.x + This facility is used to fetch the entry for a device from the DEVICES + table, given the logical name of the device. The procedure was doing + only a counted string compare, hence it would return the first device + entry for which the device name given was a prefix. For example, "mt" + would match the first magtape device in the table, no matter what it + was. Modified to match only whitespace delimited device names. (10/8) + +----------------------------------------- +VMS/IRAF updated from lyra. (10/8) + +vms/os/tranlog.c + Broke up _createlog into the three procedures _createlog, _createjoblog, + and _mklognam. These allow the caller to specify which table the + logical name is to be added to. (10/9) + +vms/os/net/zfioks.c +vms/os/net/kutil.c + Added a process tree global password cacheing mechanism to the get + password code. Once the password for a given node and login is + entered by the user (due to a ? in the .irafhosts file) it is + encrypted and saved in the user's memory space in a place that can + be accessed by all processes in the process tree. Subsequent network + accesses to the same node by other processes in the same process + tree used the cached entry and hence the user is not repeatedly + queried for the same bit of information. (10/9) + +pkg/plot/doc/sgikern.hlp +sys/gio/sgikern/sgk.x + The DD string for an SGI device may contain the sequence $F, which + is replaced by the plot file name at open time. I added a more + general macro replacement facility $(CC). If this is encountered + in the DD string, the string value of the graphcap capability CC + is substituted. For example "-w $(xr)" would map to "-w 1024" if + capability `xr' were defined as ":xr#1024:". (10/10) + +unix/boot/rmbin/rmbin.c + The -o flag, used to specify the extensions of the files to be + selected (deleted), was not working properly. Despite the threatening + name, sequences like `rmbin -n -o .cl dir dir' are useful for finding + all files with a certain extension in a directory tree (this is not + for everyone). (10/11) + +pkg/... +noao/... +unix/hlib/clpackage.cl + To all the package-tasknames in TASK statements in package script + tasks, added the extension ".pkg", e.g., "task tv.pkg = tv$tv.cl". + This is not used in the current CL, but was required for testing + the new CL which is currently under development. (10/11) + +unix/os/ufstat.c - +unix/os/*.c + Removed the fstat cache. This is inherently unreliable and such + cacheing should be done at the applications level, if at all. (10/13) + +noao/noao.par + + Added a parameter file for the noao package; discovered it was missing + while testing new CL pset code. Evidently the old CL didn't care if + it couldn't find the pfile. (10/13) + +sys/gio/sgikern/sgk.x + The sgk_vector() procedure was not recognizing the special case of + a vector of zero extent (dx=dy=0), i.e., a point, as occurs when + plotting a polymarker. Added a third case on the if-else to handle + this. (10/15) + +hlib/*.cl +pkg/.../*.cl +noao/.../*.cl + As part of an experiment with a feature in the new CL, added comments + of the form #{ to the header area of all compute mode scripts. In the + new CL, this sequence asserts compute mode on the stream (regardless + of the value of `lexmodes') until a matching #} is seen to clear + compute mode. This allows us to make command mode the default on + all command input streams, without having to suffer the trauma of + rewriting all our old CL scripts as procedure scripts. Note that the + #{ and #} are special only if they occur at the beginning of a line. + (10/15) + +pkg/cl/* + Installed the new version of the CL. The primary changes in this + version are the addition of `pset' tasks and parameters, the addition + of colon commands to eparam (to read and write psets to from files, + edit a new pset, run the associated task, etc.), a new cl option + `showtype', default =no, to cause a type suffix character to be added + to special tasks to indicate their type, and the extension of command + mode to all input streams as the default (formerly, all script input + was in compute mode). (10/19) + +sys/clio/clopset.x +sys/clio/clcpset.x +sys/clio/cl[gp]set.x +sys/clio/cl[gp]set[bcsilrdx].x +sys/clio/clpsetnm.x +sys/clio/clpset.h + Added support for named parameter sets to CLIO. The `clpset' + procedures are equivalent to the clget/clput procedures, but they + take care of the details of concatenating the pset name and parameter + name in references to parameters in named psets. + + ********************************************************************* + This is a major revision to the CL, fully documented in the paper + "CL Parameter Set Extensions", Oct 21, 1986. (doc$pset.ms). (10/19) + ********************************************************************* + +unix/hlib/motd +unix/hlib/zzsetenv.def +pkg/cl/cl.par + Incremented the system version number to 2.5. V2.4 was just released + on draco, and the new CL is a sufficiently major change to warrant a + new version of the system. I am going to continue to add to the + V2.4 notes file, however, until the AOS/IRAF bug fixes have been + merged in and the UNIX/IRAF system settles down while I work on the + SUN/IRAF system. (10/19) + +unix/hlib/mkiraf.csh + Initialization of the uparm directory is now an option. (10/20) + +dev/hosts [node lyra, UNIX/IRAF] + Removed the `plot' alias for carina - set up back when we switched + to 4.3BSD due to problems with lpr. We should be able to do our + ncar plot processing on lyra now. (10/22) + +sys/imfort/db/imastr.x + This procedure had not yet been modified to be consistent with the + other db/imadd procedures, i.e., the datatype arg was a domain + string rather than a type code, and there was no comment string. + This would cause the imfort procedure imaddc to create a new + field with an invalid datatype. (10/24) + +------------------------------- +Begin merge of AOS/IRAF revisions from AOS/IRAF port. + +unix/hlib/libc/knames.no_ - +unix/hlib/libc/xnames.no_ - +unix/hlib/libc/libc.h +unix/hlib/libc/iraf.h + Deleted the #ifdef F77_NO_ stuff in libc.h and iraf.h, and deleted the + no-underscore versions of the knames.h and xnames.h files. There is + too much variation in the machine dependence of the Fortran external + names to be represented by this scheme. It is simpler and safer to + just have the UNIX version of the external names in the UNIX kernel, + and modify that for each new system. (10/27) + +unix/hlib/libc/knames.h + Removed duplicate define for ACHTUU. (10/27) + +unix/os/zfiopl.c +unix/os/zfiolp.c + Added a (char *) cast to the second argument to strncpy(). (10/27) + +unix/os/zopdir.c + There was a bug which was causing the trailing / to be included in + the directory name passed to opendir(). This is harmless on unix + but might cause problems on some systems. (10/27) + +unix/os/zmaloc.c +unix/hlib/libc/kernel.h + Deleted the ZMEMCK memory allocator debug code, and the associated + #ifdef flag in kernel.h. The 4.3BSD memory allocator is completely + new hence the old debug code will no longer work. The new 4.3 BSD + memory allocator, by the way, looks to be a lot more sophisticated + and efficient than the old one. (10/27) + +unix/os/zpanic.c + Added [] to the declaration of osfn_bkgfile. (10/27) + +unix/os/zxwhen.c + Two occurrences of ZWHEN in the comments were changed to ZXWHEN. (10/27) + +sys/imio/imaccess.x + Modified to deal with sections and cluster indices. (Not AOS related + revision). (10/28) + +unix/os/zfioty.c + Sometime back, when the VOS terminal driver was added, a new file + TTOPEN.X was added to sys$etc. This file contains a routine TTOPEN + which can be used to open a terminal directly as a device. The + special device name "dev$tty" denotes the user terminal. This feature + was evidently never fully implemented; I added a few lines of code + in the UNIX terminal driver (ZOPNTY) to recognize dev$tty and open + the device /dev/tty when the special device name is seen. Note that + the device name dev$tty is not filename mapped since FIO does not + map the names of special devices, and the name is therefore passed + on without modification from the user program to the kernel. + + The TTOPEN function has not yet been used in IRAF, but it will be + needed at some point for programs like screen editors that need + efficient raw i/o to a terminal. On machines where this type of + direct access cannot be implemented IPC to the CL can be used + instead, at a considerable loss in efficiency for very interactive + applications. The TTOPEN facility should NOT be used in ordinary + applications software. (10/29) + +sys/fio/zfiott.x + This file is the VOS terminal driver. Modified the i/o logging code + to record ^ as \^ so that the actual character is not confused with + the ^[ type notation used to render control characters, and to record + spaces a \40 rather than as an (invisible) space. Hereafter, any + whitespace in the log file was put there only to improve readability, + and is not data. (10/29) + +pkg/cl/mkpkg + Modified the `relink' entry as follows: + + relink: + + link: + $set LIBS = "..." + $link cl.o ... + ; + + The `link' symbol is thus an entry point into the `relink' subprogram, + used when one does not want to check if all the object files are up + to date (that is what does). This note is partially to + document this little used mkpkg construct. See also the mkpkg in + imfort$tasks for another unusual but occasionally useful construct. + (10/29) + +sys/tty/ttyputl.x + The ttyputline() procedure would break lines (add a newline) that were + exactly 80 chars long, terminated by an EOS but no newline. This was + the bug causing EPARAM to scroll on AOS/IRAF, not anything in the + eparam code itself. (10/29) + +sys/etc/pagefiles.x + +sys/etc/lineoff.x + +pkg/system/page.x +pkg/system/lineoff.x - + The PAGE task was repackaged as a library subroutine and installed in + the ETC package so that the interactive file paging capability will + be available to applications programs. + + pagefiles (files) + pagefile (fname, prompt) + gpagefiles (files, device,prompt,firstpage,clearscreen,mapcc) + + The procedure `pagefiles' pages through the files in a file template, + `pagefile' pages a single file and allows the end-of-page prompt to + be something other than the filename, and `gpagefiles' is the fully + generalized routine. The global `ukey' cl parameter is used for + keyboard input, transparently to the calling program (but it can be + redefined with a local task parameter if desired). (10/30) + +sys/etc/pagefiles.x + Smartened up the pager to deal properly with very long lines, i.e., + lines of text that require several terminal lines to display, as in + mkpkg output. (10/30) + +sys/fmtio/ctocc.x + Modified to always output octal control codes as 3 digit octal numbers, + e.g., \040 rather than \40. This is necessary for the inverse + operation, as the escape sequence may be embedded in a string + immediately followed by a printable digit, e.g. "\04089". (10/30) + +unix/hlib/libc/xnames.h + Added entries for TTSETS and TTSTATS, used to set/stat string valued + terminal driver parameters. Also added an entry for STTYCO, the + main entry point for the new VOS STTY routine (see below). (10/31) + +sys/clio/clopen.x +sys/clio/clcmd.x + I turned off the FLUSHNL (flush at newline) bit for the CLOUT stream, + to allow parameter-set requests to be batched to speed up tasks that + set the values of a lot of parameters at runtime. It was necessary + to add an explicit flush to CLCMD since the flush is no longer implied. + This appeared to be the only place where a flush would need to be + added. (10/31) + +unix/boot/spp/xpp/lex.sed +unix/boot/spp/xpp/xppcode.c + In xppcode.c, increased the size limits for defined strings and + string constants to 8192 chars for string constants, 4096 chars + for defined strings, and up to 128 defined strings. In lex.sed + added an edit command to increase the size of the yytext token + buffer from 200 to 1024 chars. This limits the maximum length of + a string constant or defined string. (10/31) + +sys/fmtio/pargb.x + Modified to print the %b `yes' and `no' strings in lower case + rather than upper case. (11/2) + +pkg/cl/builtin.c + A recent change to this file, made in support of the new terminal + driver, fixes an old problem with foreign tasks. Formerly, arguments + to foreign tasks of the form "keyword=value" would be translated + as "value" in the generated host command line, since a foreign task + has no pfile. The "keyword=" is now preserved. (11/2) + +lib/syserr.h +lib/syserrmsg +lib/ttset.h [*] +pkg/cl/builtin.c +pkg/cl/login.cl +pkg/cl/mkpkg +pkg/cl/tags +pkg/language/doc/stty.hlp + [*] +pkg/language/language.hd +pkg/language/language.men +pkg/system/doc/stty.hlp - +pkg/system/mkpkg +pkg/system/system.cl +pkg/system/system.hd +pkg/system/system.men +pkg/system/x_system.x +sys/clio/clcmd.x +sys/clio/clopen.x +sys/etc/mkpkg +sys/etc/sttyco.x + [*] +sys/fio/zfiott.com [*] +sys/fio/zfiott.x [*] +sys/gio/cursor/mkpkg +sys/gio/stdgraph/mkpkg +sys/gio/stdgraph/stdgraph.com +sys/gio/stdgraph/stgclose.x +sys/gio/stdgraph/stgopen.x +sys/gio/stdgraph/stgopenws.x +sys/gio/stdgraph/stgrcur.x [*] +sys/libc/cttset.c +sys/libc/mkpkg +unix/hlib/libc/ttset.h [*] = major changes +unix/hlib/libc/xnames.h + The above files were modified in support of the new VOS terminal driver. + The main source files for the driver are etc$sttyco.x, zfiott.x and + zfiott.com in fio$, and lib$ttset.h. The file gio$stdgraph/stgrcur.x + also received a substantial amount of new code; the revisions to the + remaining files were minor. + + To summarize the revisions: the actual source for the driver in + fio$zfiott.* was extensively revised. A new STTY driver task was + added to etc$sttyco. The old STTY task in the system package, a CL + script, was deleted, as was the _stty builtin in cl$builtin.c. + A front end to the VOS STTY was added to the language package + (cl$builtin.c). The new architecture concentrates all knowledge of + the driver functions into the VOS files, with the CL front end + serving merely to concatenate the argument list string and pass + it on to the VOS routine. + + The new VOS terminal driver is fully documented in the manual page + for the STTY task in the language package. Aside from cleaning up + the architecture of the terminal driver interface and making everything + execute faster, the major revisions were to the logging features of + the terminal driver. + + The old `stty logio' function is retained with slight modifications + to eliminate ambiguities in the recorded data, e.g., the characters + ^ and \, if present in the data stream, are logged as \^ and \\, + and spaces are logged as \s (rather than be invisible). + + Two new features, `stty login' and `stty logout' were added to + permit logging of the input and output streams in separate files. + The name of the logfile may now be specified on the command line + as an option. + + A major new feature `stty playback' was added to permit terminal + input to be taken from a logfile. One types `stty login[=file]', + executes an arbitrary sequence of commands, then terminates input + logging. The resultant script may be read back any number of times + with `stty playback'; this is different from an ordinary CL script + because all interactive queries, EPARAM keystrokes, cursor mode + input, etc. is logged as well as command lines. + + The playback feature was added with two goals in mind. First, we + hope that it will be a useful aid for testing software. One can + exhaustively test a package with input logging on, entering any + arbitrary sequence of commands, and then repeat the sequence + automatically at a later date or on a completely different IRAF + host, possibly logging the terminal output and diff-ing it with + the original. The logfile is a printable and editable text file, + hence can be patched manually to reflect minor changes to the + software being tested, if necessary, without having to regenerate + the entire thing. + + The second purpose of the playback feature is for demos and + tutorials. A user at a remote site can playback an stty script + to be led through a detailed tour of any program or package. + The scripts can be annotated with explanatory comments, to be + written directly to the terminal at runtime (such comments are + never seen above the driver). Playback can proceed either in a + fully automatic mode, with a programmable delay after each input + data record, or in a synchronized mode where the user must tap + the space bar to pass each record to the calling program. (11/2) + +sys/etc/sysid.x + Deleted the call to GETUID if "userid" is not found in the + environment. By now, everyone will have a "userid" defined in + their login.cl file. Also, I want this routine to call only + low level functions so that it can be called by other low level + code w/o recursion. (11/2) + +unix/boot/spp/xc.c + Added some code to recognize a new form of a command line switch. + The construct `-/xxx' will cause a `-xxx' to be included in the + command lines of the f77 and cc commands, i.e., `-/' is used to + escape switches to be passed to the host programs. In particular, + this is necessary to pass switches which are words rather than + single characters, e.g., `xc -cf -/f68881 ...'. (11/3) + +math/minpack/ + + Installed the raw sources for an older, non-proprietary version of + the MINPACK package in the math package. There has been no attempt + as yet to review the sources for portability and compile and install + the library. (11/4) + +sys/etc/pagefiles.x + Added a new colon command ":spool ". One positions to the + desired line in the file or stream being displayed and then turns + on spooling to the named file. Thereafter, as each line is displayed + on the screen it is also appended to the spool file. (11/4) + +sys/vops/alut.gx +sys/vops/mkpkg +sys/vops/lz/mkpkg + The ALUT routine was extended to provide lookup tables for datatypes + real and double, using an integer index array as input. (11/5) + +sys/etc/main.x +sys/clio/clcache.x +sys/clio/clio.com +lib/clio.h + Revised the CLIO parameter cache code to automatically search the + psets for a task if no entry is found for the named parameter. + For example, if the parameter is "xxx" and the task is T with + psets A and B, CLIO will look first for "xxx" and then for "T.xxx", + "A.xxx", and "B.xxx". The effect is that the psetname may be + omitted without invalidating the cache, and the parameter search + path used in the CL is used in CLIO as well. (11/6) + +(back to AOS/IRAF merge) + +unix/boot/bootlib/osfn2vfn.c +unix/boot/bootlib/vfn2osfn.c +unix/boot/bootlib/osdir.c + No changes here for the present. It is easier for the moment to + follow the original concept of a different bootlib for each host + than to try to devise a portable one. At some point we do need + to make more of an effort to produce a more generic UNIX/IRAF HSI. + (11/7) + +unix/boot/bootlib/osaccess.c +unix/boot/bootlib/oschdir.c +unix/boot/bootlib/oscmd.c +unix/boot/bootlib/oscrfile.c + Minor changes, mostly adding type casts. (11/7) + +unix/boot/spp/rpp/ratlibc + Changed the remark() argument type to (int *) and deleted the + old interface files which are not used by the preprocessor. (11/7) + +unix/boot/wtar/wtar.c + Deleted u_finfo() declaration. + Cast arg to ZFINFO as (PKCHAR *). (11/7) + +unix/boot/rtar/rtar.c + Once call to cchksum() did not cast the argument as (char *). (11/7) + +unix/boot/mkpkg.csh +unix/boot/spp/* + Added mkpkg.csh files to the SPP source directories. This will force + everything to be recompiled when a bootstrap takes place, eliminating + the problem of foreign binaries being used when + +sys/mkpkg + Modified the entries for libmain.o, which was using the $checkout / + $checkin directives in a way which was inappropriate for an object + module. (11/7) + +sys/gio/elogr.x +sys/gio/elogd.x + Changed some (10.0 ** -x) constructs to the form (10.0 ** (-x)) to + avoid a shortcoming of the AOS/VS Fortran compiler. (11/7) + +sys/gio/aelogr.x + +sys/gio/aelogd.x + +sys/gio/elogr.x +sys/gio/elogd.x + Moved the anti-elog functions out into separate files for a better + UNIX library structure, and to avoid a topological sorting conflict. + (11/7) + +unix/boot/xyacc/mkpkg.csh + + Added a mkpkg.csh file for XYACC; the entire UNIX bootstrap is now + driven via these shell scripts and make is no longer used. (11/8) + +unix/.../mkpkg.csh + Reviewed all the mkpkg.csh files and made the following changes: + [1] eliminated use of environment variables, e.g., $hlib; constructs + like ../../hlib used instead; [2] scripts delete all binaries after + making whatever they make; [3] switches like "-cO" were changed to + "-c -O", which is more portable. These changes were made to favor user + sites, so that the bootstrap works if there is no $hlib, and user + sites rarely do software development in the HSI hence do not need + to have the objects and package libraries left behind. (11/8) + +unix/mkpkg.csh +unix/gdev/mkpkg.csh +sys/mkpkg + GDEV is now handled somewhat differently. During the bootstrap, + the gdev/mkpkg.csh script is run: this calls sgidev/mkpkg.csh to + compile and install the SGI translators. During a sysgen, there + is now an entry in sys$mkpkg which runs the mkpkg in host$gdev to + update the GDEV device drivers in libsys.a. This is kind of a + weird structure, but is less error prone than the old structure + (libsys.a can be deleted and it will be completely reconstructed + by a sysgen). (11/8) + +pkg/cl/main.c + Changed declaration of bkgfile to (PKCHAR *). (11/8) + +sys/libc/eprintf.c +sys/libc/sprintf.c +sys/libc/printf.c +sys/libc/scanf.c + Installed the versions of these files from AOS/IRAF, which were + modified to use to elminate the dependence on how the + compiler compiles argument lists. (11/8) + +sys/libc/mkpkg +sys/libc/cstropen.c + + Added a new function c_stropen() to LIBC. (11/8) + +pkg/cl/clprintf.c +pkg/cl/errs.c + Modified to use . Used AOS/IRAF version of clprintf.c, + but did a merge on errs.c, and set it up to use the new c_stropen + procedure and fdopen() rather than duplicating the low level interface + code for sprintf. (11/8) + +pkg/images/tv/cv/ids/idsinit.x +pkg/images/tv/cv/iism70/iisrd.x +pkg/images/tv/cv/iism70/iiswr.x + Eliminated type declarations for intrinsic function max(). (11/8) + +pkg/images/tv/cv/iism70/iispio.x +pkg/images/tv/display/iispio.x +pkg/images/tv/display/iisio.x + The ands() function was being called with short and integer arguments. + (11/8) + +unix/boot/bootlib/osgetenv.c + Added a (char *) coercion to the call to strncpy. (11/8) + +(boolean expressions) + The AOS/IRAF notes state that the SPP compiler translates expressions + such as (! clgetb(...)) as (clgetb (...) .EQ. .FALSE.). This is not + the case: ! is translated as ".NOT.", which makes sense, since the RPP + always does the easy thing. Nothing changed. (11/8) + +pkg/images/tv/cv/iism70/iiscursor.x +pkg/images/tv/cv/iism70/zclear.x + Lots of problems with and, andi, etc. Not going to fix this garbage + code, which will soon be dumped. (11/8) + +pkg/images/tv/cv/iisers.x + This has a statement "andi (ERASE, 0177777B)". The original statement + used and() and had problems with integer overflow in a compile time + constant expression. The problem resurfaced again on AOS/IRAF due to + andi() being defined onto an AOS intrinsic function in iraf.h. The + workaround solution is to NOT define the type specific functions onto + host intrinsics. ANDI is an ordinary external function; if I wanted an + intrinsic I would have used AND instead. (11/8) + +unix/boot/spp/rpp/rpprat/defs +unix/boot/spp/rpp/rppfor/* + Increased the sizes of a number of buffers in RPP as we have managed + to overflow storage recently, and it is all paged anyway. Regenerated + the Fortran sources in rpp/rppfor. (11/13) + +sys/libc/isatty.c +sys/etc/isatty.x + +unix/hlib/libc/xnames.h + The isatty() routine in LIBC had a builtin assumption about how + external function entry point addresses are passed hence was not + portable. Fixed by doing the test with a new VOS isatty() routine + in ETC, which is called by the LIBC routine. (11/14) + +sys/osb/achtb.gc +sys/osb/achtzb.gc + In these functions the SPP arrays containing packed unsigned bytes + were being declared as unsigned byte, which is not correct for SPP. + Changed the argument declarations to XCHAR and added type coercion + internally to coerce the loop pointers to unsigned byte. (11/14) + +sys/etc/urand.x - +sys/osb/urand.x + +lib/libsys.a [DELETE OBJECT FILE] +sys/osb/mkpkg + Fixed a (evidently harmless) bug in urand and moved the routine from + ETC to OSB since it is based on integer overflow during multiplication + and hence will not work on all machines. Added some $iffiles to the + mkpkg to permit machdep versions in AS. (11/14) + +sys/tty/ttygets.x +sys/fio/zfiott.x +pkg/cl/edcap.c + Changed those routines which interpret control codes represented as + `^X' to compute the binary value of the control code by masking the + lower 5 bits, rather than by subtracting a base value. This allows + a ctrl/c, for example, to be represented as either ^C or ^c. (11/15) + +sys/osb/shift.c + +sys/osb/mkpkg +unix/hlib/libc/knames.h + Added a set of bit shift operators to OSB. In many cases multiplying + or dividing by a power of two will be preferable, but a multiply can + result in integer overflow in which case the left shift operator must + be used instead. Also, for large shifts it is more convenient to shift + by so-many bits than to try to figure out which power of two to use, + so clearly the VOS should have a set of shift operators to go along + with the and/or/not primitives. The shift operators are semantically + equivalent to the << and >> operators of C; they do not perform the + same as the NCAR ishift primitive. (11/15) + +sys/gio/sgikern/sgk.x + Modified to use SHIFTI rather than (2 ** N) to initialize the bit-flip + bit mask array, to avoid the integer overflow which occurs on some + machines (DG) when the arithmetic technique is used. I would expect + that a bitwise instruction should be immune from arithmetic exceptions, + but there is no way to be certain. (11/15) + + NOTE -- The entry for 8/19 in the AOS/IRAF notesfile appears to list + some files which were not mentioned by name earlier in the notesfile. + If a file revision is not explicitly mentioned in the notes file, it + will not be merged into the master system. + +pkg/cl/*.c + Reviewed all the buffers dimensioned SZ_FNAME and increased a number + of them to size SZ_PATHNAME to reduce the chance of a buffer overflow. + (11/15) + +sys/fmtio/parg.x + There were a number of cases in pargg() where the double value was + being coerced to int or long without first checking for INDEF. (11/15) + +sys/memio/realloc.x + Now copies the nelems and dtype arguments into local variables before + reallocating the block of memory, in case the arguments are stored + in the block of memory being reallocated. (11/15) + +sys/etc/maideh.x + Moved the next_handler assignment to before the switch statement, + as it was unreachable due to an implied return in the switch. (11/15) + +sys/fio/zfiott.x + Modified to render nulls (used for null padding to generate delays) + as ^@ rather than \000, to save space in ttyio or ttyout log files. + (11/15) + +sys/gio/cursor/gtrwaitp.x + Was not reactivating the workstation, e.g., after the user would + respond to the "more help" query with a `q'. This could result in + a cursor read without the workstation being reactivated, which would + put the terminal in graphics mode, but then the next deactivate + workstation would be a no-op since the workstation was never + explicitly reactivated, causing text to be output in graphics mode + and lost. (11/15) + +unix/boot/generic/generic.c + In main(), nfiles was not being initialized to zero. (11/15) + +dev/null + Removed file protection from the dev$null dummy file; this is done + with a link in UNIX/IRAF and will be messed up when the directory + is moved to another host os. (11/15) + +lib/lib*.a + Ran `lorder | tsort' on all the libraries. Found two circular + references in libex.a (see below). (11/15) + +sys/gio/gadraw.x +sys/gio/gplcancel.x + +sys/gio/gplreset.x + +sys/gio/gplcache.x + +sys/gio/gplstype.x + + Unpacked all the gpl_ (polyline cache) subroutines in gadraw.x into + separate files to avoid a tsort cycle. (11/15) + +sys/imio/imrename.x +sys/imio/imdelete.x +sys/imio/imcopy.x +sys/imio/imaccess.x +sys/imio/immapz.x + +sys/imio/immap.x +sys/imio/iki/ikiopen.x + [1] Fixed a tsort-cycle bug oif_rename -> immap -> iki_open -> + iki_init -> oif_rename. This was done by removing the call to + iki_init from iki_open, adding a call to iki_init to immap, + and breaking immap up into a user procedure immap and an + internal procedure immapz. Now oif_rename, which is actually + quite a high level procedure, can call immapz without a circular + reference. Added a call to iki_init() to imrename, imdelete, + imcopy, and imaccess, just to be doubly safe, although it is + not necessary. (11/15) + +----------------------- +(end AOS/IRAF merge) + +----------------------- +(begin fixing all bugs and minor feature additions reported/requested in +(the past several months.) + +lib/lib*.a + As an experiment, tried reordering the object modules in the IRAF + libraries in topological order, to see if it would speed up linking. + It did, somewhat, although of course it took forever to reorder the + larger libraries. Results (cd cl; time mkpkg): + + unordered: 56.5 14.8 1:32 1001+112io + ordered: 44.2 11.7 1:09 684+114io + + Guess it was worthwhile. Here is the csh reorder script for Berkeley + UNIX (`reorder libXX.a'): + + ar xo $1 + rm __.SYMDEF + ar cq _lib.a `lorder *.o | tsort` + rm *.o + ranlib _lib.a + mv -f _lib.a $1 + + Did not try linking without a library symbol table. Still need to + optimize the UNIX ld program for maximum linker speed. (11/15) + +sys/etc/pagefiles.x + Modified to print an error message without changing the position + within the file if a pattern search fails, rather than position to + the end of file as previously. Also found and fixed a bug introduced + when the long-line code was added, which was causing the %done to be + computed incorrectly. (11/16) + +/bin/ld + I have been planning for a long time to optimize the UNIX linker, + which is inefficient for large libraries such as IRAF uses. This is + less important in 4.3BSD as the linker had already been optimized + for this latest release of Berkeley UNIX, but I was still able to + speed it up by another 20-30 percent by optimizing the code which + reads the symbol table. With this improvement, the timings for a + CL link are as follows: + + ordered, opt: 33.1 11.4 1:00 671+119io + + This is for a VAX 11/750. For comparison, the time for our 8600 + is 1:34 (clock), i.e., UNIX running on a 750 is faster than the + VMS 8600, once again! (11/16) + +sys/fmtio/evexpr.y +pkg/images/imutil/hedit.x + Fixed a couple of bugs that have been reported in HEDIT. + The principal one was due to real input tokens being returned by + the lexical analyzer in EVEXPR with a real value but an integer + datatype. This would produce what would appear to be garbage + results - a large integer number. Also added some additional type + checking to xev_binop, and modified HEDIT to eliminate whitespace + at either end of the value expression. (11/16) + +sys/etc/main.x + The IRAF main command interpreter now recognizes the argument syntax + `@fname', causing a set of param=value assignments to be read from + the named file. These should be one assignment statement per line, + in the form + + param = value + param = value + ... + + Blank lines and comment lines are ignored. This feature is used to + save typing, e.g., when testing programs which have a lot of parameters. + Multiple @fname arguments may be given, e.g., if the task has multiple + named psets, and they may be mixed with any of the other constructs on + the command line. For example, an explicit assignment may follow an + @fname to change the value of one of the parameters set in the file, + e.g., `plot @_plot title="abc"'. (11/17) + +sys/gio/cursor/rcursor.x + Changed the 'S' key to 'W' (fix wcs), to agree with the documentation + and the list of recognized keystrokes defined in grc.h. (11/17) + +dev/termcap + Added an entry for the SUN console. (11/18) + +sys/fmtio/evexpr.y + The lexical analyzer would accept `=' as an ordinary character within + a string constant, causing boolean expressions such as `param==value' + to be treated as strings, causing a `parameter not found' error message + in HSELECT. (11/21) + +pkg/cl/exec.c +sys/etc/main.x + In another HSELECT bug, command line arguments such as '@"m-flag" ...' + would result in a syntax error from the IRAF main. This was due to + the parameter cacheing code in exec.c, which would quote the value + string of string valued parameters by simply enclosing the string + in double quotes. The defective routine was modified to escape any + double quote characters included in the string as data. The code + in the IRAF main which extracts a string was modified to recognize + such escapes and convert them back into data characters. (11/21) + +pkg/cl/history.c +pkg/cl/eparam.c + EHISTORY had trouble dealing with abbreviations other than `ehi', + as the latter turned out to be wired into the original edit_history_ + directive code. I modified the code so that "ehistory" is + functionally equivalent to `^'. The command `ehistory' is special in + that any abbreviation is accepted, including `e'. Thus, + + ehistory meta + + e ^ # edit last command + e 3 ^3 # edit command number 3 + e xc ^xc # edit last command beg. with `xc' + e ?p ^?mkp # edit last command containing `mkp' + + and so on. (11/21) + +pkg/cl/history.c + In testing EHISTORY, found and fixed another minor bug. If the entire + command were deleted a newline token would be returned to the parser, + causing a syntax error since the history code is assumed to filter out + blank lines in the input. Modified to get another command line if the + command line being edited is deleted. (11/21) + +pkg/cl/param.c +pkg/cl/param.h + Indirection to the package pfile, e.g., ")_.param" would go to the + current package rather than to the package to which the task associated + with the referenced pfile belongs. Fixed this, and also modified the + code to accept ").param" as an alternative to ")_.param": the latter + conveys no more information than the former; both imply a reference + to the package pfile. (11/21) + +sys/imio/oif/oifrename.x + The oif_rename operator would open the image header, change the name + of the pixel file therein, update and close the image header, and + then rename the header and pixel files. If the header or pixel file + rename then failed (e.g., due the disk being full) the header would + be left no longer pointing to the pixel file. Modified to only update + and rename the header file if the pixel file can be successfully + renamed. Even if the header rename then fails, the header will still + be pointing to the pixel file. (11/21) + +lib/fio.h +lib/syserr.h +lib/syserrmsg +sys/fio/filopn.x +sys/fio/finit.x +sys/fio/fgetfd.x +sys/fio/open.x +sys/imio/iki/oif/oifopix.x +sys/imio/iki/oif/oifrename.x +unix/hlib/iraf.h + Modified the OIF image kernel to use the static file driver. This was + done by adding support for the STATIC_FILE file type to FIO, and then + merely changing the file type from BINARY_FILE to STATIC_FILE when + opening a preallocated pixel file in the OIF kernel. The static file + driver is now loaded during FIO initialization and is recognized as a + standard file type, although it is expected to be rarely used. In + UNIX/IRAF the static file driver is currently just mapped onto the + binary file driver, so this change is relatively safe. In VMS/IRAF + there is a separate driver, but currently it is also mapped into RMS + calls like the binary file driver, rather than using mapped sections. + The SUN also uses the binary file driver currently, but this will + change sometime soon. (11/21) + + NOTE -- Did not install the static file driver in the STF kernel; + will hold off on this until it is well tested via the OIF kernel. + +vms/os/zfacss.c +vms/os/zfinfo.c + If a file cannot be opened but it exists and posesses the necessary + permissions, FIO will issue the `waiting for access' message and + wait for the file to become accessible. This situation would occur + mistakenly in VMS/IRAF when trying to open a file template as a file, + e.g., "file*". ZFACSS was calling SYS$PARSE with the template, and + RMS would expand the template, but the subsequent RMS file open on + the template would of course fail. Modifed ZFACSS and ZFINFO to check + for the * character in the input filename, and return NO or ERR if + it is found. Programs which are passed a file template operand but + which are not set up for a template should now respond with + + cannot open file (filename) + + rather than + + waiting for access to file (filename) + + UNIX does not permit templates at the kernel level, so this was not a + problem there. (11/22) + +pkg/cl/builtin.c + The CL checks to see if any devices are still allocated at logout time, + and prints an error message if all previously allocated devices have + not been deallocated. Formerly the CL would rely entirely upon its + internal table of allocated devices to determine if a device was still + allocated. This seemed reasonable since the allocate and deallocate + functions are now CL builtins, but the user could fool the system by + running deallocate in the background, or by deallocating the drive at + the host system level. The code was modified to physically verify that + previously allocated devices are still physically allocated at logout + time, clearing the entry for a device from the internal device table + if that device has since been deallocated by another process. (11/22) + +unix/os/alloc.c + Now checks to see if the effective user id is 0 (root), printing a + message telling the installer what command to enter to fix the problem, + and returning an error code to the calling program. This frequently + happens after a bootstrap when one relinks alloc.e but then forgets to + reset the uid, which is changed to the user uid by the bootstrap. + This should happen less often now in any case, since the alloc.e + executable is now produced as the first step of a bootstrap, allowing + the user to go in and change the uid a few seconds after starting the + bootstrap, before they forget to do so. (11/22) + +unix/os/zalloc.c + In ZDVALL, the status of ZOSCMD, and hence alloc.e, was not being + returned due to multiple indirection on the `status' variable. (11/22) + +sys/etc/xalloc.x +sys/mtio/mtdealloc.x + In xdeallocate() an invalid test of the status value returned by + ZDVOWN was preventing rewinding of tape devices. I also changed the + datatype of the `rewind' arguments from bool to integer, since we + try to avoid the use of boolean outside a function. (11/22) + +sys/imio/iki/ikiparse.x + Occasionally, operations involving 3 digit numeric pseudo-extensions + in the image name would fail, e.g., + + cl> imcopy pix.002[*,100] pix.002 + + The typical symptom was that the .002 would be missing from the output + image name. + + This turned out to be due to a bug in the iki_parse routine, which + decides whether the .002 is part of the image name or an image + filename extension. This was a fairly nasty bug - the pattern for + the string match could not be extracted correctly - I am a little + surprised that we have not had more problems. Part of the reason + it was not more serious was that the field would immediately be + assumed to be part of the root image name unless it were exactly + 3 characters long, i.e., the same length as ".imh". (11/22) + +sys/gio/sgikern/sgk.x + A bug was fixed which was preventing points (zero length vectors) + from being plotted. (11/23) + +pkg/cl/builtin.c + The call to c_ttyodes to open the termcap database for the CLEAR + builtin was not error checking the returned value. (11/23) + +sys/etc/miireadc.x + The second call to read() was reading `nchars' chars when it should + have been reading `pksize' chars, i.e., it would read twice as much + data as it should since the chars are stored externally in bytes. + (11/23) + +pkg/cl/decl.c + Modified do_option() to permit { length = N } in string declarations, + as well as { len = N } as previously. The manual pages use the + full term `length', but this was not being accepted by the actual + CL code. The correct usage is `length' in accord with the `p_length' + used in expressions. (11/23) + +vms/boot/spp/xc.c + Added file existence checks as per 20 August ST mail. (11/23) + +unix/boot/rtar/rtar.c +unix/boot/rtar/rtar.hlp +vms/boot/rtar/rtar.c +vms/boot/rtar/rtar.hlp + Added a new switch `-p pathprefix' to the RTAR program. This is used + to relocated files to a different directory than that specified in the + archive, e.g., when the user has written an archive tape with absolute + pathnames on it, in which case something like this is required to be + able to read the tape at all. For example, if the archive `ldx.arc' + contains the files + + /u2/jones/ldx/_new + /u2/jones/ldx/ld.c + /u2/jones/ldx/ld.o + + then the command + + rtar -p /u2/jones/ -xrtvf ldx.arc + + will create the subdirectory `ldx' and the files + + ldx/_new + ldx/ld.c + ldx/ld.o + + The option should also be useful for extracting deeply nested + subdirectories without creating a path of empty directories leading + to the directory of interest. (11/23) + + +sys/fio/mkpkg +sys/fio/access.x +sys/fio/vfntrans.x +sys/fio/nowhite.x +sys/fio/open.x + There was a report of the following error message from someone at ST: + + OPEN: File does not exist + + Naturally, the complaint was that the file was not named. This message + is generated by FIO, which always includes the filename in the error + message, but the error formatting code (syserrs) will omit the "(fname)" + field if FNAME is the null string, hence the defective filename must + have been the null string. + + To avoid this sort of thing we have to verify input filenames, checking + for the null string. We also need to strip whitespace at either end of + the filename, but we need to do that anyway to check for the null or + blank filenames. To try to address this problem I [1] added the file + nowhite.x, which returns the input string minus any whitespace, and [2] + modified access, open, and vfntrans (fmapfn etc.) to call NOWHITE and + take an error exit if the null string is input. FIO should now detect + the null string filename and ignore any whitespace in a filename, not + only at the beginning but also at the end or anywhere else in the + filename string. (11/23) + + IMPORTANT NOTE -- The filename translation code will no longer permit + null string filenames, a significant semantic difference which may break + some programs. + +sys/imio/iki/stf/stfopen.x + When opening a new image and IM_HDRFILE is the null file (dev$null), + will no longer call fmkcopy to try to create a new header file. (11/23) + +vms/hlib/mkiraf.com + The script will now force the terminal name string entered by the user + to lower case before generating the LOGIN.CL file. (11/23) + +vms/os/str.s + The comments describing the calling sequences for _strpak and _strupk + where missing the third argument, `&maxch'. (11/23) + +vms/os/zfiopr.c + In the call to _strupk in _log_ipc(), the third argument `&nchars' was + missing. (11/23) + +vms/os/zfsubd.c + The case ../ when at the root VMS directory DISK:[000000] was not + working properly, the returned path would be DISK:000000]FILE due to + a pointer problem. (11/23) + +sys/fio/fpathname.x +sys/etc/oscmd.x + Had to add code to deal with the special case of a null string + filename, to avoid the error checking introduced into the filename + translation code above. It is a nusiance to be introducing bugs + into the system with this mod, but I think the benefits of runtime + checking for null filenames will be worth it. (11/23) + +pkg/cl/exec.c + In restor(), added some code to go through each loaded pfile and + lop off any parameters defined above the new topd. This can happen + when a declaration is entered to add a parameter to an existing + loaded pfile. (11/24) + +pkg/plot/plot.cl + Removed the reference to the IMAGES package. The new prow, pcol, + etc. no longer use _imaxes. (11/24) + +sys/gio/stdgraph/stgpl.x +sys/gio/stdgraph/stgpm.x + There was a bug in the stdgraph kernel which would occasionally + prevent line segments from being drawn (or erased). This was due + to the unresolved point clipping code used in these routines. + The last point drawn in one polyline or polymarker was being remembered + and used for clipping when drawing the first point of the next polyline + or polymarker. This would fail when drawing two two-point polylines + where the first points (move to) were different but the second points + (draw to) were the same, or when redrawing a two-point polyline in a + different line style, i.e., to clear the polyline. + + The solution was to clip unresolved points only in the interior of + the polyline or polymarker being drawn; the "last x,y" variables are + cleared before entering the drawing loop. This fixes the cursor + mode bug where several line segments are drawn with the D key, and + then erased interactively with the B or U keys. (11/24) + +unix/boot/mkpkg/tok.c +vms/boot/mkpkg/tok.c + In do_osescape, changed the expression (ch = '(' ? ')' : ch) to + (ch == '(' ? ')' : ch). This bug would cause the OS command to be + extracted with the wrong delimiter character in some cases. (11/24) + +vms/os/vms.h + Changed the value of MAXCPROC (the maximum number of connected + subprocesses) from 4 to 10, to be the same as in the VOS. This + was artificially limiting the maximum number of possible connected + subprocesses on a VMS/IRAF system to 4, and was undoubtedly + responsible for some of the process spawn failures we have seen + in the past, especially when increasing the size of the process + cache, e.g., to run a complex script. It has not been a serious + problem since we normally run with a 3 process process-cache with + space left over for one GIO subkernel. (11/24) + +unix/boot/mkpkg/tok.c +vms/boot/mkpkg/tok.c + Given mkpkg file as follows: + + $call test + $exit + + test: + $ifdef (...) $ifeq () + ... + $end + $set STUFF = "..." + $echo " $(STUFF) " + ; + + If called as `mkpkg', would work. If called as `mkpkg test', prints + error message "macro STUFF not found". + + This was happening becasue the do_end() code (the $end directive) was + a no-op if called from within the main file, i.e., when there was no + context pushed onto the mkpkg context stack by a $call, $update, etc. + A `mkpkg test' is not the same as a $call because it is a simple goto + and no new context is entered. The error message would be printed + because the $set is not executed if found in the false part of a $if + sequence. The $end directive now zeros the if-stack if called from + the main file context, else restores the if-stack to the value it had + when the current context was entered. (11/24) + +vms/os/zgtenv.c + Changed ev_cacheloaded and ev_table to static variables. This was + necessary to permit generation of a shareable image of the SDAS + libraries (which use CLIO). (11/24) + +pkg/cl/opcodes.c +pkg/cl/debug.c +pkg/cl/compile.c +pkg/cl/opcodes.h +pkg/cl/grammar.l +pkg/cl/grammar.y + Added the operator //=, since it is described in the documentation, + is useful, and is required for completeness (although I don't think + there is a **= either). (11/24) + +pkg/bench/bench.hlp + Updated the documented root pathname for the BENCH package, which + is now "pkg$bench/". (11/24) + +sys/gio/glabax/glbsview.x + If there were no ticklabels, axis labels, or plot title, the routine + would use the full device viewport without taking the desired aspect + ratio into account. A viewport with the desired aspect ratio should + now be generated regardless of the values of the other options (unless + the viewport is set explicitly by the user). (11/25) + +lib/gio.h +sys/gio/gplstype.x +sys/gio/gpmark.x +sys/gio/gpl.com +sys/gio/gadraw.x + Polymarkers are currently drawn using the clipping code in gadraw. + This was fine for large markers since these are drawn as a series + of line segments, but for point polymarkers the line segment clipping + code used by GADRAW was inappropriate. This code will add a point + at the boundary of the viewport when clipping a line segment that + crosses the boundary, so that the part of the line which is visible + is drawn. When plotting points, one gets an extra point at the + boundary, however, which is not correct. Added some extra logic to + the clipping code to omit the fancy clipping when drawing pointmode + polymarkers. (11/25) + +sys/gio/cursor/gtrwstran.x + The clipping logic in the cursor mode workstation transformation code + had the same problem with clipping point mode polymarkers as did + gadraw. (11/25) + +pkg/cl/modes.c + The UKEY code was modified to deal with stty playback mode in a way + similar to that provided for the cursor code. In playback mode with + verify enabled, after reading the logged UKEY response, the string + " [key=X]" is printed and a keystroke is read from the terminal in + raw mode, i.e., space to continue, q or ctrl/c to quit, or g to + continue with verify disabled. (11/25) + +pkg/cl/history.c + Whenever a CL prompt is generated, the CL now checks to see if raw + mode is in effect on STDIN and clears it if so. This ensures that + raw mode is cleared following a program abort. (11/25) + +vms/os/net/zfioks.c +vms/os/net/kutil.c +vms/os/tranlog.c + Added a pair of delete logical name primitives to tranlog.c. One of + these is used in ZFIOKS (the network device driver) to delete the cached + logical name if the connection attempt fails, e.g., because the user + entered an invalid password. If this were not done it would be + necessary to logout (or enter a DCL command) to recover from the + invalid password entry. If the connection fails and the password + was entered interactively, the user is given a chance to reenter + the password without leaving the kernel. (11/25) + +[networking and default directories] + This is to clarify a bug report regarding the default directory for + network accesses. In a reference `node!dir' the file `dir' could be + either a subdirectory or a logical directory. Currently, the default + directory of the kernel server on the remote node defaults to the + user's login directory on that node, and is not affected by change + directories on the local node. Hence, if `dir' is a subdirectory of + the user's root directory, the usual search mechanism will reference + the subdirectory rather than any logical directory of the same name. + This did not use to work as expected (hence the bug report), but was + fixed by a modification to the kernel server some time back. (11/25) + +pkg/cl/config.h + Increased the stack and dictionary sizes, i.e., + + stack: 8000 -> 20000 + dict : 30000 -> 40000 + + This is all paged memory on most systems, hence there is little reason + to worry about the static size of the array. (11/25) + +sys/etc/pagefiles.x + Fixed a bug in the ":f fname" file-positioning command, which would + cause it to position to the wrong file in some cases. (11/26) + +sys/fio/zfiott.x + In stty playback mode, the ZFIOTT terminal driver was not dealing with + the case of an EOF on the STDIN stream, when reading from the terminal. + It now returns and EOF indication (nchars=0) to the calling program, + and prints "[EOF]" on the terminal. (11/26) + +unix/boot/spp/xc.hlp +vms/boot/spp/xc.hlp + Updated the XC manual page. Added -d, -v, -m to the list, and modified + to reflect the recent switch to optimization by default. Recall that + the new switch to defeat optimization is -q. The -O switch is still + recognized. The principle reason for making optimization the default + was to avoid the need to use a case sensitive switch. (11/26) + +unix/boot/mkpkg/main.c +vms/boot/mkpkg/main.c + Modified the way the mkpkg argument list is parsed, to be a bit more + permissive on the grouping of single character switches behind a + single `-'. Previously, + + mkpkg -nd -f stdin + + would work, while + + mkpkg -ndf stdin + + would not. Now, both will work, and even combinations like + + mkpkg -dfn stdin + + where it is understood that the embedded -f uses the next token. + Processing will continue following the `stdin' argument. (11/26) + +pkg/utilities/utilities.cl +pkg/system/system.cl +pkg/softools/softools.cl +pkg/plot/plot.cl +pkg/images/images.cl + Deleted the SET declarations for the package logical directories + in all these scripts. These directories are already defined in + hlib$zzsetenv.def, hence redefining them in the package script + tasks is unnecessary, and prevents one from redefining the package + directory before loading the package, to permit use of a private + version of the package. (11/26) + +noao/imred/imred.cl +noao/astutil/astutil.cl + Also deleted the SET declarations from these package script tasks. + The package logical directories are defined when the NOAO package + is loaded. (11/26) + +sys/gio/cursor/mkpkg +sys/gio/cursor/rcursor.x +sys/gio/cursor/gtrgtty.x + + If the HJKL keys were used to attempt to position the cursor on a + terminal that did not support the write cursor (WC) capability, the + software position would be updated as if the cursor had moved, which + of course it wouldn't if the terminal did not support write cursor. + Added a new function gtr_gtty() to return the graphcap descriptor + for a cursor mode stream, and modified the cursor read loop in + rcursor() to use this plus ttygetb() to test if the WC capability + exists before updating the cursor position in software. (11/26) + +sys/tty/ttysubi.x +sys/tty/ttygoto.x + This is the cursor positioning code for terminals. The case %+C was + not being handled correctly in all cases. It would work for printable + characters, but when (X|Y)+C was a control code the formatting code + being used would output it as \NNN. Moved the case `%+' to the code + which handles case `%.', which should fix the problem. Also replaced + the ttyputs() calls in ttygoto() by calls to ttywrite(), in case the + output string contains any embedded nulls. When testing this on a + terminal that uses control code adressing (e.g., 0-23 binary), note + that if a control code is generated which is special to the driver + (e.g., LF) the TTY code will position to a point near the desired + location, and then use character level positioning to move the rest + of the way in. The reserved tty driver chars are defined in file + tty$tty.h. (11/26) + +sys/imfort/imfort.h +sys/imfort/imcrex.x +sys/imfort/imemsg.x +sys/imfort/doc/imcrex.hlp + Added code to verify the `naxis', `axlen[]', and `pixtype' input + arguments to IMCREX (the create image operator). (11/26) + +vms/boot/bootlib/dcl.c +vms/os/zoscmd.c + Added a call to _zerror() to print an informative VMS error message + if the DCL spawn fails or a mailbox create fails. This can happen + easily if the user account has insufficient quota, and without a + specific VMS error message it is almost impossible for the user to + figure out what is going on. (11/26) + +sys/gio/wcstogki.x + Added clipping of the transformed coordinates to the range zero to + GKI_MAXNDC. The input world coordinates could be anything, potentially + causing the transformed GKI coordinates to fall outside of the 16 bit + GKI space, causing integer overflow or truncation errors when the + coordinates are eventually converted to integer. (11/26) + +sys/fio/zfiott.x + Previously, if the user typed `stty playback' while in `stty login' + mode (recording the input keystrokes), playback mode would actually + be started with input logging still in effect. Usually the login + file would still be in a file output buffer and the actual file + would be zero length. Playback would reopen the file and immediately + see EOF, terminating playback mode. The `stty playback' command + would be logged, however, causing a loop when the login file was + later played back. This is what would happen on UNIX; on most other + systems a file open error would result, due to trying to reopen a + file already opened for writing by someone else. + + I decided the loop "feature" makes sense and might actually be useful + for exhaustively testing software or hardware. If one wants to + terminate login mode and enter playback mode that is already possible. + Hence, the terminal driver was modified to log but not execute the + playback command, if entered during `stty login' mode. A message + is printed to warn the user that something out of the ordinary has + occurred. (11/26) + +sys/imfort/imfparse.x + Had the same bug as sys/imio/iki/ikiparse.x, which could cause + non-filename extension dot delimited fields to occasionally be + stripped from the output image name. (11/26) + +sys/imfort/imcrex.x + The image header field IM_HDRFILE was not being set to the header + file pathname before calling imf_gpixfname to generate the pixel + file name. This would cause the pixel file to always be created + in the current directory, which was fine unless the image header + file was created in a directory other than the default. (11/26) + +pkg/system/help/nomore.x - + Deleted this obsolete file, no longer used. (11/27) + +sys/clio/clgkey.x + The maxch argument was not being used, allowing the output string to + be overrun. This would happen when responding to the HELP prompt + with a : command, since the HELP code does not use any colon commands, + and hence calls clgkey() with a very small maxch. (11/27) + +sys/clio/clgcur.x + A check of the clgcur() cursor read routine, from which the clgkey() + code was derived, revealed that maxch checking was not being performed + here, either. This is the original bug, inherited by clgkey, which + was added later. (11/27) + +sys/etc/prupdate.x + Added some parenthesis to a boolean expression to ensure that it will + be evaluated as desired (just insurance, not a bug). (11/27) + +sys/etc/sttyco.x + The new STTY task would set the terminal environment variables in the + CL process, but the new values were not being propagated to child + processes. Added calls to prenvset() to set the environment variables + both in the parent and in all connected child processes. (11/27) + +sys/etc/envreset.x + # new function +sys/etc/environ.x # modified to allocate more storage +sys/etc/environ.h # added one field to list element struct +sys/etc/mkpkg + Added a new function ENVRESET to the environment list package. The + new function is used to update, in place, the value of an environment + variable when one wants to permanently change the value. To keep it + simple and minimize changes to the package this was done by always + allocating at least a minimum amount of storage for the value string + when a new environment variable is defined. Currently, space is + allocated for at least 20 chars; this is more than twice as long as + any of the device names currently used on our development system. + If the new string won't fit ENVRESET will silently call ENVPUTS to + redefine the variable instead. A large amount of storage can be + allocated for a variable by the simple expedient of defining it + initially with a dummy value longer than the largest real value + expected, and then "reseting" the actual value. + +sys/etc/sttyco.x + The STTY terminal driver user interface was modified to use the new + envreset function rather than redefining the device names and + characteristics, since a redefinition is usually not what is desired + in this case. + +sys/etc/envscan.x + The ENVSCAN procedure is used by the IRAF main to initialize the + environment list during process startup, as well as to handle SET + statements received from the parent process during process execution + via IPC, when new SET statements are issued in the CL. The environment + mechanism has long had a defect in that while new SET statements are + propagated to any connected child processes to temporarily redefine + old variables, there was no mechanism for discarding temporary + redefinitions in child processes when a CL context is popped (e.g., + when exiting a package). + + As a first step in fixing this problem, ENVSCAN was modified to use + ENVRESET rather than ENVPUTS. The idea is to have the CL reissue the + SET statements for any uncovered redefinitions to all connected + subprocesses when a CL context is popped. The master environment + list in the CL will maintain all redefinitions (it already does), + while the environment lists in the child processes will keep only + the most recent value of each variable. This scheme seems simpler + and more reliable than complicating the IPC mechanism so that it + can deal with the full semantics of the environment mechanism, i.e., + redefinitions, mark and free, and the new reset function. Another + solution would be to flush the process cache when redefined values + are uncovered, but that is too inefficient. (11/27) + +sys/imfort/imcrex.x + The code used to generate the pixel file name would have had a problem + with multiple . delimited fields. These are permissible on UNIX + systems but not VMS systems (recall that IMFORT, being a low level + interface, can deal only with host filenames, unlike the VOS interaces). + The problem was such that, when creating an image named `pix.001', + the header file would be named `pix.001.imh' but the pixel file + would be named `pix.pix', due to the use of file rather than image + operators to extract the root filename from `pix.001'. The new code + will generate the pixel file name `pix.001.pix'. (11/27) + +sys/etc/environ.x + Modified the calling sequence of the envfree() procedure as follows. + Envfree() is used to discard recently defined or redefined environment + variables following a prior call to envmark() to mark the top of the + environment stack. + + old: nredefs = envfree (marker) + new: nredefs = envfree (marker, userfcn) + + where `userfcn' is the integer zlocpr entry point address of a user + supplied function to be called when a redefinition is uncovered. + If `userfcn' is zero no function will be called. + +sys/etc/prenvfree.x + + Added a new function PRENVFREE to facilitate updating the values + of redefined environment variables uncovered in an envfree() operation + in the specified connected subprocesses. The new function is + equivalent to envfree() except that it updates the environment of + the specified connected suprocesses as well as the current process. + The calling sequence is: nredefs = prenvfree (pid, marker). + +sys/etc/zzdebug.x +sys/libc/cenvmark.c +sys/libc/cenvget.c + These files contained calls to envfree() for which the calling + sequences had to be modified. Also added an entry c_prenvfree() + to the file cenvmark.c, and an entry c_envreset() to cenvget.c. + (11/28) + +unix/hlib/libc/xnames.h + Added entries for PRENVFREE and ENVRESET. (11/28) + +pkg/cl/builtin.c + Added the new builtin task RESET. This is equivalent to SET except + that it will (if possible) update the most recently defined value of + the named environment variable in place, rather than adding a new + definition or redefinition which could later be discarded. The only + exception to this occurs when the new value string is too large to fit + in the space allocated when the original variable was defined, in + which case a new entry is added redefining the old one. In practice + the update should virtually always be in place. If the new value + string is 20 chars or less in length than the update is guaranteed + to be in place (the 20 chars is of course a compile time variable and + can be increased if necessary). Note that STTY automatically uses + RESET to update the environment variables describing the terminal. + A RESET in the CL will automatically be propagated to all child + processes. (11/28) + +pkg/cl/exec.c + The calls to c_envfree() and flprcache() in poptask() (called when a + task terminates) were replaced by a single call to c_prenvfree(). + This discards any redefinitions of environment variables made during + the execution of a task, e.g., a package script task. New definitions + are discarded in the CL but actually still exist in the subprocess + environment tables, but this is harmless and is a hidden detail of + how the environment mechansism is implemented which may safely be + ignored. (11/28) + +unix/hlib/login.cl + Replaced the `set terminal = U_TERM' entry by a call to STTY. This + is necessary to pick up the correct ncols/nlines values from the + termcap entry for the device. The new STTY is very fast provided + the termcap entries for the terminals in common use at a site are + cached with MKTTY. (11/28) + +sys/ki/kiopenks.x +sys/ki/kienvreset.x + +sys/ki/irafks.x + Added a new function KI_ENVRESET, to be used to update environment + variables piecemeal on call the connected kernel servers serving a + given client process. This is done using the ENVINIT network + function, which is also used by ki_openks() to transmit the entire + initial environment set when a server is first connected. To provide + reasonable efficiency for single variable updates, the kernel server + (irafks.x) was modified to eliminate the status return for ENVINIT + when used for single variable updates. This makes it possible to + pipeline a number of ki_envreset() packets without waiting for the + server to process them and respond. A status packet is still used + when the full environment list is transmitted initially, mostly + because if I eliminated it now then old versions of IRAF would + deadlock when trying to talk to >V2.5 kernel servers. + + In the process of making these mods I noticed and fixed the following: + in kiopenks.x, the environment value strings were not being quoted, + which would have caused value strings containing whitespace to be + truncated in the server. + +sys/etc/environ.x +sys/etc/envreset.x + Modified the envputs() and envreset() functions to call ki_envreset() + to update the environment in any connected kernel servers if the + environment list of the client process is modified. + + With these last two changes, the environment list will now be kept up + to date at all times in all the processes in a process tree, including + any kernel server processes on remote nodes in the network. All of + the processes in a process tree (with either an interactive or bkg + CL at the root) share the same environment list, with the exception + of the three variables IRAF, HOST, and TMP, which are defined + independently for each node. (11/28) + +unix/boot/spp/xc.c [XC, FC] + Given the two files `file.e' and `file.f' in the current directory, the + UNIX version of XC (or FC), when called accidentally as `xc file.e', + would delete the file `file.f'! (fortunately, I discovered this and + not some poor user). It turned out that the UNIX Fortran compiler + f77 was the culprit; for some reason it likes to delete .f files when + it sees a .e file in the file list, probably because it thinks the .e + file is an EFL source file. The UNIX XC was modified to produce a + fatal error and abort if a .e file is seen in the file list. (11/28) + +unix/boot/rmbin/rmbin.c +vms/boot/rmbin/rmbin.c + Commands such as + + rmbin -n -o .cl . + + would fail because the directory `.' was being taken to be one of + the . prefixed filename extensions associated with the -o switch. + (11/29) + +pkg/.../*.cl +noao/.../*.cl +unix/hlib/*.cl + To all non-procedure CL scripts that use { } command grouping, + added a #{ at the top of the script to force compute mode. (11/29) + +pkg/cl/lexicon.c + Deleted the bracelevel test, formerly used to switch to compute mode + inside curly braces. Command mode is now in effect everywhere except + in procedures or within parenthesized expressions or argument lists, + unless the #{ construct (or a lex=no assignment) is used to force + compute mode. This should eliminate much of the confusion people have + been experiencing regarding the two lexical modes. (11/29) + +pkg/system/cmdstr.x + Increased the size of the output buffer from 1000 to 4096 and converted + all character arrays from static to stack storage. (11/29) + +sys/etc/sttyco.x + Modified the STTY program to look for the parameter `gd' in the + termcap entry for a terminal when a new terminal type is set. + This parameter, if given, is used to set a new value for the + `stdgraph' environment variable, allowing everything to be set + with a single call to the STTY command. If only the boolean + capability is given, e.g., ":gd:", the stdgraph device name is + assumed to be the same as the termcap device name, otherwise the + stdgraph device name must be given, e.g., ":gd=4012:". If the `gd' + capability is not defined stdgraph is set to "none". + + For example, if we set the terminal as follows: + + cl> stty vt100 + + and then enter the following command, the output shown will be + generated: + + cl> implot dev$pix + ERROR: Terminal does not support vector graphics + + Also added a call to TTYINIT to output the initialization sequence to + the terminal when the terminal name is set. The initialization + sequence, if given, is used to set the terminal to a known state, + e.g., set the font and character size, the type of emulation to be + used, disable reverse video, and so on. (11/29) + +sys/tty/ttyinit.x + Rewrote this ancient code somewhat. The funny filename business is + gone, it now simply opens the file named in the termcap entry, and of + course the filename may be either an IRAF virtual filename or a host + system pathname. The file open is error checked and a warning message + printed if the file cannot be opened, and the file is now copied with + the FCOPYO routine. (11/29) + +sys/gio/cursor/gtropenws.x + When the open workstation command is first issued for a new device + on a stream, this routine now checks for the special device name + "none" and prints a message to the effect that the terminal does + not support vector graphics, no stdimage devices are available, + or whatever. Terminals which do not support vector graphics may + either omit the `gd' capability from the termcap entry for the + device, or set the capability to `:gd=none:'. If no standard image + devices are available at a site, the system manager can set the + value of `stdimage' to `none' in the hlib$zzsetenv.def file, to + give the user an error message which is easier to understand than + at present, if they should try to access the stream. (11/29) + + NOTE: the old termcap entries for graphics terminals should be + modified to add the `gd' parameter to make things easy for the user. + Alternatively, the value of the `stdgraph' environment variable must + be reset after calling STTY to set the terminal type. + +dev/termcap [UNIX/IRAF] + Added the :gd: capability to the entries for the more obvious graphics + terminals. Deleted a sequence from the initialization sequence for + the vt100 and vt220 which was moving the cursor to the lower left + corner for some unexplained reason; all that it does now is disable + the scrolling region, if any is set. Added an initialization sequence + to the entry for the vt640 (vt100+retrographics) which sets vt100 + mode and then resets the scrolling region. (11/29) + +dev/termcap + The vt240/vt220 entries in the termcap file did not load when I + tried to cache them - there was a reference to a nonexistent entry + for the vt200. Deleted the vt200 series entries and replaced them + by the versions in the UNIX /etc/termcap. (11/29) + +dev/cachet.dat + Rebuilt the termcap cache to reflect the changes to the termcap file. + (11/29) + +sys/etc/sttyco.x +dev/termcap + This terminal initialization stuff is just too obnoxious, given the + initialization sequences given in the standard termcap file. + Initialization is no longer performed by default, instead I added + a new option `init' to STTY. The commands + + cl> stty init + or + cl> stty vt100 init # (for example) + + will cause the initialization sequence to be output to the terminal. + Of course this can be indicated in the STTY command line in the + LOGIN.CL file, if desired. Restored the goto to the termcap entries + for the vt100 and vt200 classes of devices. (11/29) + +sys/gio/gopen.x + Added code to check for the special device name "none", and to generate + an error abort if a program attempts to open a graphics kernel on a + stream which is connected to a nongraphics device or no device. (11/29) + +lib/fio.h +sys/fio/fseti.x +sys/gio/cursor/prpsio.x +sys/fio/zfiott.x + Added a RAWON escape sequence to go along with the RAWOFF already + recognized by the IRAF terminal drivers. The length of both sequences + is defined by LEN_RAWCMD, and the first character of the sequence is + guaranteed to be ESC (escape), to permit rapid comparisons. FSETI + was modified to transmit the RAWON sequence when raw mode in enabled, + as well as transmitting the RAWOFF sequence when raw mode is disabled, + which it has always done. The virtual terminal driver ZFIOTT was + modified to recognize the new control sequence. This change was made + to that raw mode can be enabled without having to read from the + terminal, which is not possible if input is not expected. Raw mode + is useful for output only (as when the terminal initialization sequence + is issued) because output processing of tabs and newlines etc. is + supposed to be disabled when raw mode is in effect. (11/29) + +sys/fio/ttyinit.x + Modified to turn raw mode on while transmitting the terminal + initialization string. (11/29) + +unix/hlib/libc/kernel.h +unix/os/zfiotx.c + Modified the UNIX OS terminal driver to recognize the new RAWON + sequence. (11/29) + +vms/os/vms.h +vms/os/zfioty.c + Modified the VMS OS terminal driver to recognize the new RAWON + sequence. The driver now also disables output processing during + rawmode output, i.e., newlines are output as newlines and not + mapped into CRLF. (11/29) + +unix/boot/spp/xpp/xppcode.c + In the function hashtbl(), changed the MAX_KEY to MAX_KEY-1. + This was evidently done on VMS/IRAF some time ago, but the + change was never propagated to the UNIX/IRAF HSI (and evidently + it has never caused any problems). (11/29) + +-------------------------------- +(begin update of VMS/IRAF [IRAFX@USR$1] to V2.5) + +dev/termcap [both UNIX, VMS] + Set up the printers like in the graphcap file, e.g., a system + independent entry `ver' with tc= pointing to uver for UNIX and + vver for VMS, and so on for each device. When new versions of + the file are moved to VMS, one only has to go down a column and + change a few `u's to `v's. (11/29) + +dev +vms/... + Merged in all recent changes into the VMS/IRAF HSI. These were + mostly in hlib and hlib/libc (#{ changes, .pkg extensions, libc/*.h + changes for new tt driver), and in XPP and RPP (larger buffers). + (11/29) + +-------------------------------- +(Did a full bootstrap of VMS/IRAF) +(Deleted the entire contents of the doc,lib,math,noao,pkg,sys directories +(on VMS/IRAf and replaced these by the V2.5 versions from lyra. Started up +(a full sysgen to run overnight. 11/29) + +sys/etc/pagefiles.x + Fixed a problem with files containing formfeeds; would not be able + to advance beyond the formfeed in some cases due to interaction + between seeks and pushback. (11/30) + +sys/tty/tty.h +sys/tty/ttyodes.x +sys/tty/ttyputl.x + The ttyputline() procedure was modified to know how to deal with + terminals that have an automatic right margin (the `am' capability + of termcap). On these terminals when the last character on a line + is written the terminal automatically advances to the next line, + and the newline which normally ends a line must be omitted or the + output will come out double spaced. On terminals without automargins, + the line must be broken and an extra newline output, or the rest of + the line will be lost. (11/30) + +------------------------------- +(VMS/IRAF did not come up on the first attempt...) + +pkg/cl/mkpkg + The object opcodes.o must be explicitly linked on the command line + on VMS, like globals.o (on AOS, only globals.o needs to be referenced + on the command line). Modified the mkpkg file to link both objects + explicitly and to maintain them in the package directory independently + of the package library. (11/30) + +pkg/cl/clprintf.c +pkg/cl/errs.c +sys/libc/printf.c +sys/libc/eprintf.c +sys/libc/sprintf.c +sys/libc/scanf.c + The initial attempt to use in the C files which deal + with variable numbers of arguments was not quite correct. We have + been setting things up as follows (for example): + + eprintf (fmtstr, va_alist) + char *fmtstr; + va_dcl + { + va_list argp; + + The correct usage is the following: + + eprintf (va_alist) + va_dcl + { + va_list argp; + char *fmtstr; + + va_start (argp) + fmtstr = va_arg (argp, char *); + + Specifically, the va_alist must replace the entire argument list, + not just a portion of it. The VMS implementation ignores the + va_alist entirely and instead calls a library subroutine written + in assembler to set argp to point to the first argument, regardless + of where the va_alist appears in the function declaration. To be + fair, it does appear from the UNIX specifications for + that the va_alist should denote the entire argument list. + + In each of the affected files, made the changes noted above, and also + replaced the "#include " by an "#define import_varargs" + so that the HSI will have control over the varargs interface. (11/30) + +unix/hlib/libc/varargs.h + +unix/hlib/libc/iraf.h + Added an include file for varargs.h in hlib/libc. For UNIX, this + just does a "#include " to pick up the UNIX definitions. + (11/30) + +vms/hlib/libc/varargs.h + +vms/hlib/libc/iraf.h + The VMS version of uses a library function to implement + the va_start() macro. I implemented this in macro and it works, but + in studying the two interfaces there seem so reason not to use the + simpler UNIX macros, thereby eliminating the dependence upon the + quirky VMS/C interface. Hence, varargs.h is the UNIX file, i.e., + it is the real thing, it does not do a #include. (11/30) + +pkg/cl/grammar.y +pkg/cl/grammar.h +pkg/cl/lexicon.c + The lexmodes switch had to be taught about procedures. (12/1) + +sys/etc/isatty.x +sys/libc/isatty.c +unix/hlib/libc/xnames.h +vms/hlib/libc/xnames.h + Changed the name of the VOS ISATTY routine to XISATTY. Using the + UNIX name was asking for trouble, and indeed it caused problems on + VMS/IRAF, although in an unexpected way. The VOS name with no + underscore mapped to `isatty', the LIBC and UNIX name. This would + cause infinite recursion in the VMS version of IRAF. (12/1) + +-------------------------------------------------------------------------- +SDAS installation, December 4, S.R., VMS (Draco!irafx, usr$1 only) + +vms/hlib/clpackage.cl + Changed SDAS definition to point to sdasdisk:[sdas.sysiraf]sdas.cl. + (12/4) + +vms/hlib/zzsetenv.def + Added definition for "sdasx". (12/4) + +vms/hlib/clpackage.hd + Added SDAS help file pointers. (12/4) + +mkhelpdb (vms) + Ran softools.mkhelpdb to pick up SDAS stuff. (12/4) + +vms/hlib/mkpkg.inc + Added $include for SDAS macros. (12/4) + +vms/hlib/stripper + Changed "math -all" to "math -allbut .hd" for SDAS inst. (12/4) +---------------------- + +dev/termcap + Merged in entry for the Sun apple laserwriter (printer), and added + host printer entries for the Sun. (12/18) + +sys/fio/zfiott.x + Increased the maximum size of a playback record from 1024 to 4096. + The buffer is dynamically allocated and only used during playback + mode. (12/19) + +sys/memio/begmem.x + Replaced the "text_size" output parameter, formerly returned by + BEGMEM, by a "max_size" parameter. The new parameter gives the + hard limit on the amount of physical memory available to a process + at runtime, taking into account the dynamic working set adjustment + facilities available on many systems. A process which exceeds its + allocated working set but not its hard limit can be expected to + page some or heavily depending upon system load; if the hard limit + is exceeded it will either page heavily or malloc will fail. (12/22) + +unix/os/zawset.c +unix/hlib/libc/kernel.h + Rewrote the ZAWSET code to use the 4.2BSD+ set/getrlimit facilities + rather than the obsolete 4.1BSD vlimit. Increased the default + advisory working set to 500K. There does not appear to be any + reliable way to determine the physical memory size in 4.XBSD UNIX, + so the kernel parameter SZ_MAXWORKSET is used to set an upper + limit on the value of the "max_size" parameter returned by BEGMEM. + (12/22) + +vms/os/zawset.c + Replaced the text_size parameter by max_size (WSEXTENT). (12/22) + +sys/imio/imsetr.x +sys/imio/imunmap.x +sys/imio/imrmbufs.x + +lib/imset.h + Added a new imset option IM_CANCEL, the function of which is to + free up all pixel data buffers previously allocated when i/o was + done on an image. This is occasionally useful when very large + buffers (e.g., large subrasters) are accessed by a program. (12/22) + +pkg/system/help/houtput.x + The HELP program would leave the last line or two on the screen empty + when paging through a manual page (this was especially evident on a + workstation since the window boundary is so clearly defined). + Modified so that each screen is filled. Will also pick up changes + to the number of lines per screen (ttynlines) as soon as the value + of the environment variable is changed, e.g., in an stty call. (12/24) + +pkg/system/help/t_help.x + Now checks the create date on the help database file every time HELP + is run, and re-reads the database if a new database has been created + and installed. This should eliminate the need to flush x_system.e + from the process cache when mkhelpdb is run. (12/24) + +sys/vops/amed.gx + This routine calls ASOK to compute the median of a vector in the + general case of npix>3. Since the ASOK routine partially sorts + the input vector in place, this would result in AMED also sorting + the input vector, which is probably not what the user expects. + Accordingly, AMED was modified to copy the input data vector into + an internal salloc-ed temporary buffer so that it no longer modifies + the input vector. If the slight inefficiency introduced by this + modification is unacceptable the ASOK routine should be called + directly instead. (1/8) + +dev/termcap +dev/graphcap + The entry for the calcomp was modified to give the calcomp a standard + landscape mode aspect ratio like everything else. (1/9) + +dev/termcap +dev/graphcap + Added new entries gterm,gterm40,gterm34,gterm24 for the GTERM virtual + graphics terminal running on a Sun workstation. These are currently + identical to the "sun" entries with the addition of a "gd=gterm" + capability indicating that the terminal supports graphics. (1/10) + +dev/cacheg.dat +dev/cachet.dat + The termcap and graphcap entries for the GTERM Sun virtual graphics + terminal were added to the cache. (1/10) + +sys/gio/stdgraph/mkpkg +sys/gio/stdgraph/stdgraph.com +sys/gio/stdgraph/stgactive.x + +sys/gio/stdgraph/stgctrl.x +sys/gio/stdgraph/stgdeact.x +sys/gio/stdgraph/stgdraw.x +sys/gio/stdgraph/stgmove.x +sys/gio/stdgraph/stgopen.x +sys/gio/stdgraph/stgoutput.x +sys/gio/stdgraph/stgpcell.x +sys/gio/stdgraph/stgpl.x +sys/gio/stdgraph/stgpm.x +sys/gio/stdgraph/stgrcur.x +sys/gio/stdgraph/stgreact.x +sys/gio/stdgraph/stgreset.x +sys/gio/stdgraph/stgtx.x + The stdgraph kernel was modified to eliminate unnecessary deactivate + workstation calls. When writing to an dual frame, either/or terminal + like Sun/GTERM, the deactivate workstation directive may cause the + graphics frame to be turned off and the text frame turned on. If the + next thing that happens is that the graphics is turned back on, this + is a great waste of time and if one of the frames is not retained its + contents are lost. The nature of the modification was to cause the + deactivate workstation call to set a flag. If the next command + received by the kernel is a i/o command the deactivate workstation + control sequence is issued to the terminal and the flag is cleared. + If the next command received is reactivate workstation the flag is + cleared and no other action is taken, i.e., the workstation remains + activated. [This revision was actually made on 3 Jan]. (1/10) + +sys/gio/cursor/giotr.x +sys/gio/cursor/grcclose.x +sys/gio/cursor/grcopen.x +sys/gio/cursor/grcwaitp.x +sys/gio/cursor/grcwcs.x +sys/gio/cursor/gtr.h +sys/gio/cursor/gtrctrl.x +sys/gio/cursor/gtropenws.x + The cursor mode code also had to be modified to eliminate unecessary + close/open deactivate/reactivate workstation commands. A number of + cases were defined which had to be dealt with carefully: cursor + mode may be entered [1] from within an interactive program after the + workstation has already been opened with GOPEN, [2] while the kernel + is connected to the stream but after GCLOSE has been called, [3] while + the stream is in its initial state, i.e., no kernel connected. + Furthermore, a distinction had to be made between kernel control + directives (DEACTIVATEWS etc.) issued at runtime by an interactive + program, and those present in GKI metacode being played back. + + It is difficult to describe the actual revisions precisely here, + but briefly, the list of control directives handled by the pseudofile + i/o controller (gtr_control) was expanded to include CLOSEWS, + DEACTIVATEWS, and REACTIVATEWS, the controller now passes all runtime + control directives directly on to the graphics kernel, and GIOTR was + modified to filter out all control directives except OPENWS. In other + words, control directives such as close or deactivate workstation + present in spooled GKI metacode are ignored when the metacode is + retransmitted to a graphics kernel following a `0' or `:.read'. + The open workstation directive is still recognized when replaying + spooled metacode, and is all that is required to cause a frame advance + or screen clear between successive graphics frames. (1/10) + +sys/gio/gki/gkiclose.x +sys/gio/gki/gkideact.x +sys/gio/gki/gkireact.x + These GKI primitives were modified to send a copy of their GKI + instruction to the PSIOCTRL stream as well as to the output graphics + stream. The PSIOCTRL version is the one which causes some action at + runtime, whereas the data version is included in the output GKI + metacode stream only for the sake of completeness (some program may + wish to make use of it) and for debugging purposes. (1/10) + +sys/gio/stdgraph/t_stdgraph.x + The STDGRAPH kernel (PLOT task) was modified to [1] filter all close + workstation, deactivate workstation, and reactivate workstation + directives out of the input metacode stream, and [2] explicitly add a + close workstation directive before task termination to ensure that the + terminal is left in text mode. (1/10) + +sys/etc/pagefiles.x + The clear_screen option is now used to defeat screen clears only when + sequentially advancing through a file, e.g., with space bar or 'f'. + All backwards motions or seeks cause a screen clear followed by output + of the data. The file or object name in the end-of-page prompt is + no longer changed to EOF at the end of file, rather, the percent done + indicator is changed to -(EOF). This was necessary for it to be + possible to always see what was being paged. (1/14) + +unix/hlib/iraf.h +unix/hlib/SUN_kludge/precomp.csh [SUN/IRAF] + Changed the definition of IS_INDEFX so that it no longers uses a + complex comparison; it now does only a single precision real + comparison of the real part of the complex number, i.e., + + define IS_INDEFX (real($1)==INDEFR) + + The complex comparison would cause the Sun fortran compiler to crash + when used with the hardware floating point options. (The floating point + equality used here and in the other IS_INDEFs has yet to cause any + problems when comparing magic numbers, but will be replaced by an + order comparison in a future version of the system to eliminate the + risk). On the Sun systems, removed the entries for gctod.x and xtoc.x + from the precomp.csh file, since complex comparison is no longer used. + (1/14) + +os/mkpkg +os/net/mkpkg +boot/bootlib/mkpkg +boot/mkpkg/mkpkg +sys/mkpkg (module libmain.o:) + Added a $set XFLAGS = "-c" statement to each of these mkpkg files. + This is needed on systems like the SUN to override any host dependent + compiler options used for the main IRAF system, e.g., floating point + compiler options like -f/68881 etc. The HSI wants to be compiled + without any special options, e.g., it should use only software + floating point (if floating point is used at all), for maximum + portability of the binaries. (1/15) + +unix/boot/spp/xc.c + The f77 command line switch "-cu" was changed to "-c -u". The Sun + f77 does not permit clustering of switches, and hence the -u switch + was not being seen and the Sun XC was not checking for undefined + variables and functions. (1/15) + +unix/os/zfiopr.c +unix/os/zopdpr.c +unix/os/zoscmd.c +unix/os/zmain.c + Modified these routines to use fcntl() to arrange for file descriptors + other than stdin, stdout, and stderr (0-2) to be closed in the child + if the execl succeeds, and deleted the loop over close() in zmain. + This was necessary for the Sun-3 fpa and was necessary before for the + Sun-2 skyfpa; I thought I had merged the changes into the master system + but evidently not. (1/15) + +--------------------- +(The following revisions are from the first installation of SUN/IRAF at the +(KPNO 4-meter telescope on 21 January 1987). + +/usr/lib/suntools + Installed latest version of GTERM in suntools. (1/21) + +dev/graphcap + Changed MF from 8 to 1 for the apple laserwriter. There is no need + to spool plots for this device. Also added the aliases "lw" and "lws" + for the two apple laserwriter entries, since the device name on the + Sun is "lw" rather than the "apple" currently used in IRAF. (1/21) + +sys/gio/cursor/grccmd.x + Modified to do an automatic gflush if MF is <= 1. In the process of + making this modification and testing the new system, discovered [1] + this routine was calling grc_open() as a subroutine, while it is a + function, and [2] the code which calls grc_command assumes that the + stream data structures are left intact by the call. Added a call to + gtr_init() at the end, before exiting, to insure that the latter + assumption is correct. (1/21) + +sys/gio/cursor/gtr.h +sys/gio/cursor/rcursor.x +lib/scr/cursor.key + Added a new key "=" to cursor mode. This is shorthand for the commonly + used function :.snap. A prior call to ":.snap dev" is needed to set + the output device, else the default stdplot device will be used. (1/21) + +sys/gio/cursor/gtrinit.x + There was a bug in this code, when called immediately after a :.gflush + on some other stream. The gflush would invalidate the cache but + gtr_init would find the stream already inited and would not reload + the cache for the new stream. The logic was changed so that it always + reloads the cache for the new stream if it is not already set up for + the correct stream, moving the conditional which used to check for an + invalidated cache to the code which saves the cache in the descriptor + for the formerly cached stream. In other words, the old cache contents + are now saved only if they are valid, and the cache is always set up + correctly for the new stream, which was what was not being done + formerly. (1/21) + +---------------------- +(Begin the final bug-fixing pass for V2.5) + +unix/os/zpanic.c + Modified zpanic to core dump the current process if called when the + debug_sig flag is set. (This revision need not be made in all V2.5 + IRAF versions). (2/4) + +sys/gio/cursor/prpsio.x + Modified to discard graphics control output via stream PSIOCTRL when + the associated graphics stream has been redirected to a file. This + is the fix for the graphics stream redirection bug (>G). What was + happening was that the call by pr_psio to gtr_control would take an + error action when the stream had been redirected and hence the graphics + kernel had never been activated. UNIX stdio (LIBC) converts getc errors + to EOF, and the CL lexical input stream does not check EOF's to see if + they are really i/o errors, hence the CL would see a premature EOF on + the command input stream from the graphics task. The task would be + terminated at the CL level without reading the graphics output and + writing it to the redirection file, hence the file size would be zero. + The next time a task was run in the subprocess (e.g., x_plot.e), the + graphics output from the previous task would be read and passed on to + the graphics kernel connected to the stream of the new task. (2/5) + +pkg/cl/gquery.c + EPARAM could not be used to set the value field (list file name) of a + list structured parameter, due to some muddled code in gquery(), which + was originally derived from query(), but which is not used in the same + way for list structured params (since it is used to assign a new value + to a param, rather than verify the current value). (2/5) + +sys/imio/iki/stf/stfopen.x + Now forces the datatype of a NEW_COPY image to real if a new physical + image is being created. This fixes the bug where + + imcopy dev$pix[*,1] pix.hhh + + would create a type real image with short integer pixels. For some + reason this would work correctly if the section were omitted. (2/5) + +sys/imio/imt.x + Disabled sorting of image template lists. Image templates are often + used to generate both input and output lists from the same database. + The lists must be of the same length and in the same order for this + to work as expected. The problem is that the output list is often + edited with a // or %%, and it is the edited list which is sorted, + hence it is possible for the input and output lists to be sorted + differently if the output list is edited. (2/6) + +sys/fio/filopn.x + After the call to zopen_proc (the device driver open procedure for the + file), added an fp=fiodes[fd] statement to reinitialize the file + pointer, in case it is clobbered by the called procedure. In the case + tested, the LPOPEN device open procedure was clobbering fp in the fio + common, and an open failure was not getting caught. (2/7) + +dev/hosts + For the VMS nodes, changed the kernel server pathnames to the UNIX + syntax, since the REXEC server used in the tcp/ip network interface + uses the unix syntax even on VMS. (2/7) + +sys/ki/irafks.x + Added some new debug conditionals. (2/8) + +vms/os/net/zfioks.c + Replaced the network channel by input and output channels, which can + be the same but do not need to be. (2/8) + +bin/irafks.e [VMS] + I tried various experiments to get the VMS TCP/IP kernel server going, + without success. The main conclusion appears to be that use of the + REXEC daemon is not the way to go for VMS. The process tree to the + actual kernel server is as follows: + + rexecd.exe + csh.exe + irafks.exe + + where rexecd.exe is itself spawned by the INET_SERVERS daemon. This + hardly seems an efficient process structure. Furthermore, the Eunice + REXEC server does not read the user LOGIN.COM file, hence the IRAF + logical names will not be defined and some things will not work. + + Ignoring all that, I was able to execute the kernel server but could + not make the network connection. The irafks.e SYS$INPUT was set to + "_INET28". The system knows about a logical network device _INET0: + (the Eunice tcp/ip device driver), but trying to sys$assign a channel + to _INET28: causes a "no such device" error. Beats me why the process + would be spawned with an invalid SYS$INPUT device. Another bothersome + thing was that the 28 counted up from a smaller number during the first + few trials, then pegged out at 28, suggesting a channel was not being + freed or something within INET_SERVERS or REXECD. RSH from a UNIX host + continued to work, but the SYS$INPUT for tasks spawned via the RSH + daemon was a mailbox rather than the _INET device, so this proves + nothing. I was tempted to try rebooting to see if the 28 was reset to + a smaller number, but was unable to do so. + + It appears to me that the best solution for network access to a VMS + node is to use DECNET, if DECNET software is available from a UNIX + node. Barring that, a special daemon should be written which spawns + the LOGINOUT process to login with the given name and password, start + up a DCL, read the user's LOGIN.COM file, and execute a user specified + command file which runs irafks.e (like the DECNET interface). This + appears to be possible, although the VMS hooks required to make it + work are incompletely documented and are noted in the documentation + as "intended for use by VMS system software". (2/8) + +dev/hosts +dev/uhosts [discussion] +unix/os/zghost.c + Looked into the long node name problem. It was reported that filename + mapping would fail on UNIX systems where gethostname() would return a + host name longer than the builtin KI limit of 9 characters; this is + evidently common on 4.3BSD systems which use a long host name + containing several . delimited fields. + + As our system has short node names, I simulated the problem by faking + the call to gethostname() in zghost.c. I was unable to duplicate the + bug, and in fact it appears that there should be no problem. If a + long node name is returned it will be truncated to 9 characters. + If the system does not use the IRAF networking facilities this should + be harmless. If the system does use networking the KI should still + function correctly, provided the node names in dev$hosts and dev$uhosts + are also truncated to 9 chars. The only requirement is that the system + be internally consistent; the local node names are independent of the + integer internet address, which is what goes out on the network to + actually connect to a remote node. (2/9) + +sys/clio/clpset.h +sys/clio/clpsetnm.x + If the pset name is null, the CLIO pset package will now return just + the param name, rather than ".param". (2/9) + +sys/tty/ttyodes.x + If either the "li" or "co" parameter is missing from the termcap (or + printcap) entry, a default value is assumed (previously the value would + be zero, which could cause programs to misbehave). (2/9) + +sys/gio/gopen.x + Deleted the code for the now obsolete "@stddevice" redirection feature, + e.g., it used to be possible to set stdgraph = "@terminal" to use the + same device name for both the stdgraph and terminal devices. The STTY + task now handles this in a better way, and the @ feature proved to be + difficult to implement consistently throughout the system, hence was + never fully implemented. (2/9) + +pkg/cl/debug.c + Fixed an off-by-one array overrun bug in d_f which could cause a + segmentation violation on systems with large numbers of file + descriptors. (2/9) + +pkg/cl/pfiles.c +pkg/cl/param.c + Fixed a bug in the CL that would cause list files to fail to be closed + at task termination. The list file pointer p_listfp was not being + copied back by pfcopyback(), and hence the list file was not being + closed by restor(). (2/9) + +sys/osb/chrpak.c +sys/osb/chrupk.c +sys/ki/kiencode.x + The base 128 integer encoding scheme employed in this kiencode.x had + a bug that would cause it to lose the signedness of -128 and its + integer multiples. There was also a problem with integer overflow. + The bugs were discovered when networking was brought up under AOS/IRAF, + however, I did not fix them quite the same way. The new AOS/IRAF + code assumed that SPP chars are unsigned values and generated values + in the range 0-255, whereas the SPP language specification defines + SPP chars as signed quantities (since they are usually implemented as + integer*2, which is signed). I kept the negative char values in the + the encoding, and instead changed the chrpak/chrupk primitives in OSB + to explicitly preserve the signedness, since the C specification does + not specify the signedness of chars. The new versions of chrpak/chrupk + map SPP chars into unsigned bytes, using ranges to restore any negative + values in the unpack operation. + + The new routines are upwards compatible with the original encoding + (except for negative numbers, which are not currenty used anyhow hence + should not matter) hence network communications with older versions of + IRAF should not be affected by this change. (2/9) + +unix/os/net/zfioks.c +unix/os/net/kutil.c + Merged in some bug fixes from the AOS/IRAF network interface. Note + that the routines in the UNIX/IRAF os$net are not actually used in + the runtime system, but are provided only as a template to be used + to contruct the network interface for a new system. (2/10) + +sys/imio/immapz.x + Added a runtime check for an environment variable "min_lenuserarea"; + if no such variable is defined the value of MIN_LENUSERAREA in + will be used instead to size the IMIO user area, i.e., the amount of + buffer space available for user header parameters. The new environment + variable may be defined by the user or the site manager (e.g., in + hlib$zzsetenv.def) if images with very large numbers of user params + (or history cards) are to be processed. Note that applications which + simultaneously open many images, e.g., IMSUM, may run out of memory if + the value is set arbitrarily large. (2/10) + +vms/os/zpanic.c + Changed sys$exit error code to SS$_ABORT. This should get rid of the + strange error messages like "SYSTEM-F-UNSAFE, drive unsafe", which we + have occasionally been seeing following panic shutdowns. (2/10) + +sys/vops/amed.gx + Modified the file header comment to agree with the recent addition of + stack allocation to avoid modifying the input vector. (2/10) + +vms/hlib/gripes.cl + Added a NOAO site specific command to cause gripe mail to be forwarded + to the master iraf mail file on lyra. (2/10) + +sys/imfort/imioff.x +sys/imfort/imcrex.x + Changed the name of the imioff procedure to imf_initoffsets, as used + in IMFORT, to avoid a shared library conflict on VMS (IMIO uses a + procedure of the same name). This is just as well but should actually + not be necessary, as IMFORT programs are not supposed to be linking + with libex. (2/10) + +unix/os/zfioty.c + Replaced the string constant "/dev/tty" by the macro TTYNAME. (2/10) + +unix/os/zfiotx.c [discussion] + There was a question about the (*op = XEOS) statements herein writing + beyond the maxch characters specified for the output string. In all + IRAF code, a "maxch" for the output string specifies the maximum number + of characters to be returned, excluding the EOS. For example, if maxch + is 80 and the output string is filled, 80 chars will be returned + followed by an EOS in element 81. The only exception to this is + operators which return raw character data, rather than a string. + Strings are always EOS delimited, but data may consist of exactly so + many chars and no EOS. I thought that ZGETTX, as a low level kernel + routine, returned a data array with no EOS, but evidently this is not + the case. Since it does return an EOS, it MUST be at buf[*maxch] (or + before, if the data array is shorter). It may be that the routine + should be modified to not return any EOS at all, but since everything + seems to be working I am not going to modify anything at present. (2/10) + +unix/bootlib/osfcopy.c + Changed datatype of "buf" to XCHAR, and added (char *) casts in the + calls to read() and write(). (2/10) + +pkg/images/tv/display/t_display.x + In the calculation of the "unitary_greyscale_transformation" flag, + replaced several (abs(x-y) < EPSILON) floating point comparsions by + fp_equalr(x,y) calls. The latter performs the comparison correctly + regardless of the magnitude of the quantities being compared. (2/10) + +sys/tty/ttygets.x + Fixed an argument type mismatch (char,int) in a call to the mod + intrinsic function. (2/10) + +sys/imio/db/impstr.x + Fixed an off-by-one bug in a format statment which would cause the + closing quote of a short string valued keyword to be placed in column + 19 rather than 20, contrary to the FITS standard. (2/10) + +sys/imio/db/idbfind.x +sys/imfort/db/idbfind.x + The keyword search code would formerly match the first keyword for + which the given keyword name was any abbreviation, rather than + requiring that the full name match. Modified to require an exact + match. (2/10) + +pkg/images/imutil/hedit.x + Fixed an uninitialized variable bug in the call to lexnum() which would + cause new numeric parameters to be added as type string rather than as + integer or real parameters. (2/10) + +pkg/cl/globals.c + Set the default editor type to the null string rather than "emacs", + to force the .ed file to be read when the editor is first used. + If this is not done and the default editor is the same as in globals.c, + then changes in the .ed file have no effect. (2/10) + +sys/vops/amap.gx + Fixed point overflows were reported in the short integer version of + this routine, so I modified it to perform the computation internally + in integer for type short arrays. No doubt there will be other VOPS + operators which should do this, too. (2/10) + +sys/imio/db/impstr.x + More problems with updating string parameters in image headers: when + replacing a long string, e.g., '...................', by a short + string, e.g., 'abc', the old value would not always be cleared. + Also, in image headers with variable length records (< 80 chars), + it was possible to overwrite the newline at the end of the record, + clobbering the next record and joining the two. All of these problems + derive from the storage of header paramters internally in ascii. (2/10) + +pkg/cl/pfiles.c + Added a "long filetime()" declaration to the file header. (2/10) + +pkg/proto/imreplace.x - +pkg/proto/mkpkg + Deleted this obsolete file. (2/10) + +pkg/proto/imrep.gx + Was coercing INDEFR to INDEFD, rather than testing for INDEFR and + doing an assignment. (2/10) + +pkg/cl/task.c + The addltask() function was not explicitly returning a pointer to the + new task, although it is supposed to. It was probably working because + the second to the last statement is a call to newltask(), which is + leaving the desired task pointer in the function return value register. + This will (accidentally) work provided the register is not clobbered + before the function returns. (2/10) + +sys/mtio/mtparse.x + Modified to handle a drive syntax like "mta.1600". It would handle + "mta1600" or "mt.a.1600" (a special case of "mt.*.1600"), but could + not handle an unmatched . delimiter as in the first example, and as + in the dev$devices file. Note that the syntax "mta.a.1600" cannot be + used unless it appears that way in the dev$devices file, which will + probably be the case only if the 'a' is some more complex multi- + character device name. (2/10) + +vms/boot/bootlib/osfpathname.c + Now checks for a null string vfn and calls vfn2osfn() only if a nonnull + vfn is given. (2/12) + +dev/graphcap + Added ":kf=x_sgikern.e:tn=sgikern:" fields to the entries for the + logical devices sgimc and sgibi; these work now and never did up until + now. Also changed the MF count from 8 to 1, so that one file is + generated for each output frame. (2/12) + +sys/gio/sgikern/sgk.x + - Increased the bitmap buffer size to 2550 lines by 3300 columns, + sufficient for an 8.5x11 plot at 300 dpi, and larger than all + currently supported bitmap plotter devices. + - Moved the $(XX) substitution code so that it is the first operation + performed on the DD string. This allows parameter substitution to + be performed on the node, device, and spoolfile fields, as well as + the dispose string. + - If the dispose string is null, oscmd() is no longer called. + (2/12) + +sys/ki/kignode.x + This is the procedure used to extract a node name prefix and determine + whether a resource resides on the local node or a remote node. It was + modified to return immediately indicating that the resource is local + if the first character in the resource name is the node delimiter + character, i.e., '!'. This was the source of the bug whereby the !! + were being stripped from OS escape commands such as "cl> !!!oscmd". + (2/12) + +unix/hlib/login.cl [HSI] +vms/hlib/login.cl + Added a statement to the code which builds the "user" package which + will cause commands to be read from a file LOGINUSER.CL, if such exists + in the user's home directory at login time. This makes it possible for + the user have a custom login.cl file without having to edit the login + file every time they do a mkiraf. The file is read in command mode and + must end with a KEEP statement if it contains any declarations. (2/12) + +unix/boot/mkpkg/main.c +vms/boot/mkpkg/main.c + In the default case, in the second call to strcat there was an invalid + argument *ip. (2/12) + +sys/gio/cursor/prpsio.x + This code calls the stdgraph kernel to deactivate the workstation if + a task writes to STDOUT or STDERR while in graphics mode. This was + not taking effect immediately any longer, due to the recent revision + to the stdgraph kernel, whereby transmission of deactivate-ws commands + is delayed until the next graphics command is received, so that no-op + deactivate/reactive ws commands can be eliminated. Added a call to + stg_active() after the call to stg_deactivate() to flush the deactivate + ws command to the terminal, ensuring that error messages and such will + come out in readable form. (2/12) + +pkg/system/help/lroff/center.x + The lroff (help) text formatter was not centering text properly. + Evidently the page width and margin parameters used on our development + system would just happen to cancel out the logical error in the code; + with different parameters, the centering error was obvious. (2/13) + +pkg/system/help/help.par +pkg/system/doc/help.hlp + Changed the default number of lines per page (nlpp) for HELP pages + from 60 to 59. This was the cause of "help | lprint" producing a + blank page every other page. It turns out that the laser printer + (at least ours, an imagen) is 60 lines per page, with an automatic + formfeed after line 60. Help output includes an embedded formfeed, + so you get a blank page if pages are exactly 60 lines long followed + by a formfeed. A recent bug fix in HELP caused it to fill a page, + whereas before it was not completely filling each page, i.e., it was + this bug FIX which caused the blank-page bug. + + NOTE - The value of the help parameter 'nlpp' should be set smaller + than the size of the device page on which the document will be printed. + The HELP task has no way of knowing this, e.g., documents formatted + by help are often spooled in a .doc file and can be printed later on + any device. We will distribute the system with the default value of + 'nlpp' set for the shortest printer page size we know about. + + TODO - This fix is really a bit of a kludge. The real solution is for + lprint to know whether the device auto-formfeeds after so many lines, + so that it can omit the formfeed if the page is filled. The 3 line + page footer built into lprint should also be a device parameter. + I do not want to get into all this now. I plan to move the printer + stuff out of the termcap file into a "printcap" file, with a set of + device parameters defined especially for printer devices; these LPRINT + modifications are best left until the printcap file is set up. (2/13) + +pkg/system/help/t_help.x +pkg/system/help/manout.x + Added a test to eliminate the formfeed preceeding the first page of + manpage output; a formfeed before the first page can cause a blank + page on some printers. Also added a "man_init()" procedure, and a + call to it in the program main, to clean up the manpage internals if + manpage output is interrupted. (2/13) + +sys/gio/stdgraph/stgpm.x + The stdgraph polymarker code was used for the first time in the + non-polypoint mode for the vt240 terminal, which needs to draw points + as , and so on, repeated for each point. + The polymarker code was modified to draw the polymarker as a series + of primitive vector move/draw commands, if the marker start (MS) + sequence is not defined for the device. MS (and ME if needed) should + only be defined for a device if it can draw a multipoint polymarker + following a single control sequence at the beginning. + (2/14) + +sys/gio/cursor/prpsio.x +sys/gio/stdgraph/stgwtty.x + +sys/gio/stdgraph/stgrtty.x + +sys/gio/stdgraph/stgactive.x [IMPORTANT CHANGE TO GIO] +sys/gio/stdgraph/deact.x +sys/gio/stdgraph/onerr.x +sys/gio/gdeact.x + +sys/gio/greact.x + + A number of changes were made to the stdgraph kernel and to the + pseudofile i/o system, as used while the workstation is active (i.e., + in graphics mode). The changes affect only programs which write to + STDOUT or STDERR, or read from STDIN, while doing interactive graphics + to STDGRAPH. All i/o is completely normal if the workstation is not + activated, i.e., if the terminal is not in graphics mode. + + The pseudofile i/o system now completely controls i/o to STDIN, STDOUT, + or STDERR while in graphics mode. Since this type of i/o is now under + the complete control of the i/o system it may be used safely in + applications programs, with more predictable and consistent results. + This revision addresses the major device dependency remaining in the + old graphics terminal interface. + + 1. Device model + + Our logical device model assumes that the terminal has separate + text and graphics planes. Some terminals will display both planes + simultaneously, i.e., as transparent overlays, some will display one + plane or the other but not both simultaneously; some will display both + planes simultaneously as separate windows, and some will have only a + single plane which must be used for both text and graphics. We assume + that there is a "status line" in the graphics plane which is cleared + and prepared for text output by the graphcap GD (graphics disable) + function. Graphics mode is later restored with GE (graphics enable). + The OW (open workstation) function places the terminal into graphics + mode and causes the graphics plane to be displayed (OW will be + equivalent to GE for most terminals). The CW (close workstation) + function restores the terminal to normal text mode, causing the + graphics plane to be turned off and the text plane to be displayed. + + 2. Write to STDOUT, STDERR + + These streams are treated equivalently by the low level i/o system. + A write to either stream while the graphics workstation is activated + will cause one or more lines of text to be written to the "status line" + in the terminal graphics plane. Text lines should be delimited by + newlines in the usual way, but the newline will not be output, i.e., + no carriage-return line-feed will occur. If multiple lines of text + are output they will be written successively to the status line, + with each line overwriting the previous one, and possibly not giving + the user time to read the first N-1 lines of text. + + In the usual case where a single newline delimited line of text is + output, the text is written to the status line minus the newline and + the terminal is restored to graphics mode, i.e., no mode switch takes + place and the terminal is NOT left in text mode following output to + the status line. + + 3. Read from STDIN + + If the text written to STDOUT while in graphics mode is not newline + delimited, e.g., in a prompt string such as "prompt: ", the GE sequence + will not be issued and the terminal will be left in text mode with the + text cursor positioned at the end of the line of text in the status + line. The application may then read the user response string from + STDIN. The i/o system performs the read in raw mode to prevent echoing + of the newline character, which might cause the terminal to scroll. + The read terminates when the user types carriage return, line feed, or + an end of file character. Backspace and delete may be used to delete + single characters, and or may be used to delete the + entire string. The GE sequence is issued when the read terminates, + completing the sequence and leaving the terminal in graphics mode. + + 4. Raw i/o to the status line + + Although the i/o system always reads from the status line in FIO + raw mode, this is transparent to the application, which receives full + lines of text with normal input processing. Actual raw i/o at the + applications level is also supported. Raw mode is initiated by calling + fseti to set F_RAW to YES on STDIN. The first write to the status line + in raw mode clears the status line and outputs some text; additional + text, e.g., single characters, may be output in successive calls, with + output being appended to the status line (in the normal mode, the + status line is erased and overwritten in each call). Raw mode reads + return single characters with no input processing and with no echo. + Writing a newline character to the status line reenables graphics (GE). + Raw mode is cleared with fseti(STDIN,F_RAW,NO). + + 5. Deactivate, reactivate workstation + + Two new commands have been added to GIO, to be used to deactivate + and later reactivate the workstation, following a call to GOPEN. Note + that GOPEN does an open-workstation, which implicitly activates the + workstation, hence it is not necessary to explicitly reactivate the + workstation at GOPEN time. + + gdeactivate (gp, flags) # deactivate workstation + greactivate (gp, flags) # reactivate workstation + + flags (): + + AW_CLEAR # clear tty screen on CW + AW_PAUSE # waitpage prompt on OW + + The deactivate workstation directive, when called for a STDGRAPH device, + causes the CW (close workstation) directive to be issued to the + terminal, leaving the terminal in text mode like GCLOSE, but without + affecting the graphics state. Note that it is the CW directive which + is issued, NOT the GD directive, which is only used to write to the + status line in the graphics plane. Any amount of conventional text i/o + may be performed while the workstation is deactivated, with graphics + i/o resuming following a call to greactivate. The FLAGS argument + should be either zero, or the inclusive-or (arithmetic sum) of some + set of the AW_ flag bits defined in . For example, to clear + the text screen and display a page of text, pausing at the end for + the user to type a key before reentering graphics mode: + + call gdeactivate (gp, AW_CLEAR) + + call greactivate (gp, AW_PAUSE) + + 6. Paging a file in cursor mode + + Help text may be generated either on the fly by a program, using + the g[dr]eactivate calls to control the workstation, or help text may + be paged from a file. A new routine has been added to GIO to make + the latter case very easy: + + gpagefile (gp, fname, prompt) + + This routine pages the named file (which should be in noao$lib/scr, + lib$scr, or some such directory) using the library version of the PAGE + task. The graphics state is not affected by the call. + + 7. Cursor mode help + + The key '?' is no longer treated specially. Existing applications + programs must be modified to use the facilities described in [5-6] + above. Aside from this one change, all the GIO modifications + discussed herein should be upwards compatible. + + Cursor mode itself now uses the file pager to display the cursor mode + keystrokes, hence the text will no longer scroll off the screen. + Note that escapes to the CL do not work while the pager is running + within the context of the CL. + + 8. Cursor reads + + Reading the graphics cursor while the workstation is open no longer + has any effect on the graphics state, i.e., the workstation is not + deactivated. + (2/15) + +sys/gio/stdgraph/*.x + A number of little changes were made to the stdgraph routines in accord + with the revisions mentioned in the previous item. The de/re activate + workstation filtering code, added only a few weeks ago in an early + attempt to fix the confusion over what deactivate workstation means, + was deleted since we now have a precise definition and extra + deactivate/reactivate workstation calls are no longer generated. + The simplified the stdgraph kernel code significantly. (2/15) + +sys/gio/cursor/*.x + A number of litte changes were also made to this code, mostly dealing + with the few deactivate/reactivate workstation calls remaining in the + code. The workstation is no longer deactivated when cursor mode exits + while the workstation is active, i.e., following a gopen; this is of + course the way it should always have been. Since the workstation is + no longer deactivated unless it really needs to be, the automatic + reactivate workstation call was removed from GIOTR. Calls were + eliminated in several other places as well. Once again, things got + somewhat simpler and make more sense now. (2/15) + +gcancel.x +gclear.x +gclose.x +gdeact.x +greact.x + The calls to flush() in the routines were technically incorrect; these + were replaced by calls to gki_flush() in all routines listed except + gclose(), which will have already issued a gki_closews. The flush call + in gclear was deleted as it is not needed, and it can be annoying to + wait a second for something to happen (e.g., the next block of graphics + output to be transmitted) after the screen clears. (2/15) + +sys/clio/clgkey.x +sys/clio/rdukey.x + +pkg/cl/modes.c + Moved the rd_ukey() code out of modes.c and into the VOS, as the SPP + subroutine clio$rdukey.x (this is interesting, by the way, as a direct + comparison of C and SPP). Modified clgkey() to call rdukey() if the + calling process is run standalone. This was done so that pagefiles() + can be called from within the CL. (2/16) + +sys/libc/crdukey.c + +unix/hlib/libc/xnames.h [HSI] + Added an entry c_rdukey() to the VOS C language binding. (2/16) + +sys/gio/cursor/grcpage.x - +sys/gio/cursor/grcwaitp.x - +sys/gio/cursor/gtrwaitp.x + +sys/gio/cursor/rcursor.x +sys/gio/cursor/gtrctrl.x +sys/gio/cursor/crccmd.x + Modified the cursor mode code to use pagefiles() to page the cursor + mode help file. Added support for the deactivate-ws waitpage function + to the PSIO controller. (2/16) + +sys/gio/gpagefile.x + + Added the gpagefile() cursor mode file pager, discussed above. (2/16) + +pkg/system/page.x +sys/etc/pagefiles.x + Changed the name of the "general" file pager from gpagefiles to + xpagefiles, to avoid confusion with the GIO gpagefile() routine. + As far as I know, this relatively new routine has not yet been used + anywhere other than in the system PAGE task, which was modified to + use the new name. (2/16) + +unix/os/zfioty.c + Added a (char *) typecast to the first arg to strcmp. (2/16) + +unix/os/zxwhen.c + Fixed a typo: "if (unix_signal = ..." --> "if (unix_signal == ...). + The effect was to cause any stdout data buffered at the unix level to + be discarded whenever an exception occurs, rather than only when an + interrupt occurs. (2/16) + +lib/gki.h +sys/gio/gki/gkideact.x +sys/gio/gki/gkireact.x +sys/gio/gki/gkiexe.x +sys/gio/gki/gkiprint.x + These files were modified to implement the changes to the gki_[rd]eact* + instructions. (2/16) + +sys/clio/clcmd.x +sys/clio/clcmdw.x + These routines now look for a ! at the beginning of the CL command; + if present, OSCMD is called directly instead of sending the command + to the CL. This allows the routine to be used to send OS escapes + when running a process standalone. If the command must be passed to + the CL, the code now checks to see if the process is a connected + subprocess, and if not (e.g., run standalone), an informative error + message is printed. (2/16) + +sys/etc/pagefiles.x + Now error checks CLCMDW, printing a warning message if an error occurs. + (2/16) + +sys/gio/cursor/rcursor.x +sys/gio/stdgraph/stgrtty.x + Modified these routines so that typing delete or rubout at the start of + a colon prompted sequence which requires text entry (colon command or + "text: " prompt) will cause a silent exit back to cursor mode (without + ringing the bell and/or flashing the screen and punishing the user for + changing their mind). (2/16) + +sys/gio/stdgraph/stgscur.x +sys/gio/stdgraph/stggcur.x +sys/gio/stdgraph/stginit.x +sys/gio/stdgraph/stdgraph.h +sys/gio/doc/gio.hlp + Added a new STDGRAPH device capability UC (update cursor). If this + capability is defined for a device, every time the cursor is read or + written the new position is saved by the kernel, and used to manually + reset the cursor position before the next cursor read. This is + desirable on devices which modify the cursor position as an unwanted + side effect of other, unrelated graphics operations. In general, it + is undesirable for the cursor to move other than under user or program + control. (2/16) + +vms/boot/mkpkg/modlist.c + The hash function was modified so that only the first 20 characters + of an identifer are used to compute the hash value. This was necessary + to prevent integer overflow (resulting in an exception and/or a + negative hash key value depending upon the system) when hashing very + long identifiers. (2/16) + +pkg/cl/gram.c +pkg/cl/eparam.c + Looked into the problem of multiline parameter prompts, which were + causing problems for EPARAM. Actually found two problems: + + [1] For normal terminal output with fputs etc., one should not + write into the rightmost column as on terminals with autowrap + this will cause every other line to be blank. Note that as + long as output is filtered through ttyputline() this is not + a problem, but the low level i/o facilities cannot handle this + device dependence. + + [2] EPARAM could not handle multiline prompts correctly in all + cases. It was working in the case when the prompt occurred + in a parameter in the first screen. The only problem I found + was one of display; it was always possible to edit the param. + + To address these problems, I [1] replaced some (maxcols) by (maxcols-1) + in gram.c (for LPARAM and ?), and [2] in EPARAM, I rewrote the code + which displays multiline prompts, discarding the e_indent_prompt() + function, and rewriting the e_display function to break the prompt + into lines, outputting each separately with e_goto and e_putline, + and truncating each at the right margin. The old code was invalid + for terminals with automargins. (2/16) + +sys/gio/stdgraph/* +sys/gio/cursor/* + In testing the new support for the status line and text/graphics io + in the graphics system, a few bugs were fixed and some tuning was + done. The changes were as follows: + + [1] Gdeactivate will now clear the text screen if the AW_CLEAR bit + is set, even if the workstation has already been deactivated. + + [2] The AW_CLEAR and AW_PAUSE actions are now recognized by both + the gactivate and gdeactivate routines. + + gdeactivate: + + PAUSE: Print "[Hit return to continue]" on status + line and wait for return to be typed before + deactivating the workstation. + CLEAR: Clear the text plane after deactivating the + workstation (disabling graphics). On some + terminals this may also cause the graphics + screen to be cleared; this is determined by + the "cl" capability in the termcap entry. + + greactivate: + + PAUSE: Print the "[space=cmhelp,...]" message on the + text screen and pause until the user types a + key before reactivating the workstation. + CLEAR: Erase the graphics plane after reactivating + the workstation. + + Since these are bit flags, multiple flags may be passed, + as follows: + + call gdeactivate (gp, AW_PAUSE+AW_CLEAR) + + Other flags may be added in the future. + + [3] Setting ":.page-" in cursor mode disables the AW_CLEAR page + in gdeactivate (this has no effect on the gpagefiles() screen + clear). This option is sometimes useful on terminals with + transparent graphics overlays. On these terminals, since the + graphics plane cannot be turned off, both planes are cleared + when either a full page of text or a graph is to be drawn. + Disabling ":.page" in cursor mode defeats the initial screen + clear and the graphics redraw. The text is displayed beneath + the plot, and is erased after the greactivate prompt (AW_PAUSE) + with a series of line clears in the text plane. This option + permits greater speed, but one has to try to read the text + through the graph. A bug in ":.clear" was also fixed; it now + uses the same technique to clear the screen. + + To try out nopage mode, try the following on a terminal with + a transparent graphics overlay like the vt100+retrographics: + + :.page- + :.show + (show text appears underneath plot) + q + (text is erases and cursor comes back) + + Unfortunately, this does not work for ?, :.help, etc., unless + the clear screen entry in the termcap file does not clear the + graphics screen. A special terminal entry can easily be + prepared which does not clear the graphics plane, if desired. + + [4] When writing to stdout|stderr, you can now append to the status + line. The status line is cleared when changing from graphics + mode to status line mode. Since writing a newline causes a + switch from status line mode to graphics mode, lines of text + overwrite each other, but if the newline is omitted you can + append to the status line. + + [5] Graphics output or reading the cursor automatically resets + graphics mode from status line mode, in case one forgets the + trailing \n when writing to the status line. + + Important Notes: + + o When mixing status line graphics output, remember to call + gflush before writing to stdout or stderr, otherwise graphics + output will not be flushed and a synchronization error will + occur. + + o Remember to flush stdout or stderr after writing to the status + line, else you won't get any output until later, and it might + go to the wrong place. + + call gline (gp, x1, y1, x2, y2) + call gflush (gp) + call printf ("status line message\n") + call flush (STDOUT) + call gline (gp, x1, y1, x2, y2) + + A gdeactivate automatically flushes graphics output, and greactivate + automatically flushes stdout and stderr, so explicit flushing is not + necessary when writing to the text plane, but when you write to the + status line you are in graphics mode, so flushing is not automatic. + Reading the cursor with clgcur will also automatically flush any + buffered standard output. (2/17) + +pkg/plot/implot.x + Modified the IMPLOT task to use the new 'gpagefile' facility to page + the .key file, to add \n to some of the status line output, and so on. + (2/17) + +sys/gio/gki/gkifflush.x + + Added a new procedure gki_fflush() to the GKI library package. This + differs from gki_flush() in that its only function is to perform a + FIO flush of the file connected to the named standard graphics stream, + whereas the gki_flush() procedure issues the GKI_FLUSH graphics + instruction to the remote kernel, and then does the file flush. + The new operator is a no-op for an inline kernel. (2/17) + +sys/gio/gcancel.x +sys/gio/cursor/gtrctrl.x + Modified these routines to use gki_fflush() rather than gki_flush(), + since all I want to do is flush a control directive on to the kernel, + rather than flush any grahics output buffered by the kernel. (2/17) + +dev/termcap + Removed the "am" capability (automargins) from the termcap device + entry for the imagen. This would cause lines exactly 80 cols long + to be output without a trailing \n, causing the next line to be + discarded. Not putting the capability in when the device does have + automargins would have caused an extra blank line instead. This bug + only showed up recently due to the recent bug fix in ttyputline(). + (2/17) + +sys/gio/stdgraph/stgrcur.x [** IMPORTANT CHANGE TO GIO **] + Since we have already made so many changes to GIO in V2.5, I decided + to go ahead with another major change to the GIO user interface (for + the better, hopefully). The change is in the cursor read code - the + carriage return key is no longer mapped into EOF, but both the common + EOF chars, and , are. If the application wants to + use return to exit a cursor loop it can still do so, but now it has + the choice. The problem with return as an alias for EOF is that it + is too easy to type by mistake, particularly since return is commonly + used for other purposes, and one extra return can easily cause one to + accidentally exit a routine. (2/17) + +sys/gio/stdgraph/stgrtty.x +sys/gio/stdgraph/stgwtty.x + Added the two functions stg_putline() and stg_getline() to these + routines. These are used to read and write lines of text to the + graphics terminal, whether or not the terminal is in graphics mode. + When the terminal is not in graphics mode, they do normal i/o, + otherwise they read and write the status line. These functions + are for use only within processes which are linked with the STDGRAPH + kernel, i.e., the CL. (2/18) + +sys/libc/stgio.c + +sys/libc/spf.c +unix/hlib/libc/xnames.h [HSI] + Added two small packages to LIBC. The first, STGIO, is just the C + binding for the stg_putline() and stg_getline() routines mentioned + in the last section. The second, SPF, is provided to make STROPEN + style file i/o to a string buffer more convenient to use in a C + program. The VOS provides convenient facilities for this, but some + sort of C interface was needed to provide a similar facility in C, + for use in the CL code. (2/18) + +pkg/cl/modes.c + Modified query() to use the new STGIO facilities to do terminal i/o + to satisfy an interactive query. This provides equivalent + functionality to what we had before for normal queries, and adds + support for CLIO parameter queries to the graphics terminal status + line while in graphics mode. Note that in the case of multiline + parameter prompts, only the last line will be printed, but this + should not be a problem since the programmer knows when they prepare + the parameter file which parameters might be called interactively + during the execution of a graphics program. (2/18) + +sys/libc/fdopen.c + No longer performs file access mode compatibility checking unless the + file is a conventional text or binary file (e.g., not a string file). + (2/18) + +pkg/plot/implot.x +pkg/plot/doc/implot.hlp +lib/scr/implot.key + Modified the IMPLOT task to recognize the 'q' key for a quick exit. + (2/18) + +sys/gio/gqverify.x + + Added a new utility procedure to GIO, for use in interactive cursor + loop programs to verify the quit command via an interactive query. + The procedure prints a query on the status line and the user types + 'q' again to verify the quit, or 'return' to abort the quit and + return to the cursor loop. (2/18) + +Exiting Interactive Cursor Loops (discussion) + The following standards have been defined for dealing with EOF/quit in + interactive cursor loops. + + EOF + End of file is indicated for a cursor list either by an actual + end of file in the case of a true cursor list, or by typing the + , , or interrupt character in an interactive + cursor read. The 'Q' alias for EOF has been deleted. The argument + is that a true EOF on the cursor list is to be taken seriously by + the applications program, and not treated as just another key, + hence it should not be something that one types all the time. + If a program gets EOF back as the value of CLGCUR it should exit + immediately, without any verification queries etc, since it may + well have been run in batch mode with input redirected to a cursor + list file. + + q + The standard interactive cursor loop exit character is 'q'. + All interactive graphics programs should recognize this character + and take some action to exit the cursor loop, e.g.: + + while (clgcur (...) != EOF) + switch (key) { + case 'q': + break + case ... + + The 'q' character is intended to be handled directly by the + application program, rather than mapped into EOF by the system + (like Q was, and CR and the gt_gcur 'q' before that), to + distinguish this case from a hard-EOF and to provide maximum + flexibility in how the program treats a request from the user + to exit. If the user would suffer from an accidental program + exit then the 'q' key action should do something before exiting, + e.g., ask that the user first update the database, ask that CR + be hit to verify the quit, and so on. In general, if it would + take the user more than a minute to recover after an accidental + program exit, one should consider coding some sort of verification + action to be executed before exiting when 'q' is typed (but not + when EOF is seen on the list). + + A new procedure gqverify() has been added to GIO for the simple + case where only verification is desired. Note that "lightweight" + tasks or submenus which can easily be reentered should not bother + even with this, but should just exit. Example: + + case 'q': + if (gqverify() == YES) + break + + As a more complex example, suppose the program is used to edit or + create some database which could be lost or damaged in an accidental + exit, if not updated first. We do not want to update the database + automatically because this would overwrite the former contents of + the database. The program might be set up as follows. + + 'q' program prints error message on status line, e.g., + "No write since last change (:quit! overrides)" + :w[rite] updates the database; q will execute silently + :q[uit]! force a quit w/o an update; discard changes + + This example, as you may have guessed, is from the VI editor, upon + which the colon escapes, EPARAM colon commands, etc., are loosely + modeled. This model should be used in applications programs as + well, where appropriate. (2/18) + +sys/gio/stdgraph/stgrcur.x + Found an obscure bug in the cursor read code while testing. Interrupt + is defined to be just another character in a raw mode read. In a cursor + read, interrupt is one of the keys mapped into EOF, since it is a + type of quit request. What was happening was that when the interrupt + key () was typed on the terminal during a cursor read, the + terminal would treat it as a normal cursor read, returning a 6 char + sequence to the computer. The cursor input loop was terminating + immediately after seeing the interrupt character, without reading the + remaining 5 characters, returning an EOF cursor read to the high + level code. The program would exit, and the CL would then see the + 5 extra characters as the command "0 ,&", which would cause a syntax + error abort. The fix was to exit the interpreter only if a true EOF + is seen on the input stream, otherwise accumulate all 6 chars. The + only problem is, I am not sure why one doesn't also see the extra chars + when the EOF character is typed, but it wouldn't make a lot of sense + to continue reading after seeing EOF on the input stream. (2/18) + +pkg/system/files.x + Just typing "files" with no arguments is supposed to list the files + in the current directory; it was querying for the file template + parameter instead. (2/19) + +sys/fio/fdirname.x + This routine would formerly return the input name unmodified if it + started with the node name prefix of a remote node. This would cause + tasks like DIRECTORY to misbehave if the directory name did not end + with a path delimiter like $, /, or a host delimiter. The routine + was modified to always concatenate a / to the supplied string if the + last character is a normal filename (identifier) character, e.g., a + letter. For example, + + dir node!iraf$bin + + would fail, whereas + + dir node!iraf$bin/ + + would work. FDIRNAME will now add the trailing /, given a name like + "node!iraf$bin" as input. This will work only the remote directory + name is a VFN; a more rigorous solution must wait until there is time + to change the way the kernel interface treats general filename + translation. (2/19) + +unix/os/net/kutil.c + In ku_gpasswd(), ZGETTX was being called to read a single character + into a scalar output variable, with no space reserved for the EOS + delimiter currently associated with the string (array) value returned + by ZGETTX. The code was modified to read each character into an + array, with adequate room for the EOS. (2/19) + +pkg/cl/bkg.c + The command string printed by the JOBS task, the CL task which shows + the status of background jobs, would occasionally print garbage + characters following the last command string. This was due to a + missing EOS in cases when the command string copied by strncpy + completely filled the output buffer. I increased the size of the + allocated string array from SZ_CMD to SZ_CMD+1; since the buffer is + statically allocated and initialized to zero, this should be sufficient + to ensure that the string is EOS delimited, but just to be sure I added + an explicit EOS assignment as well. In general in CL code, all strings + should be dimensioned to whatever+1 (like SPP strings) to avoid this + sort of problem. (2/19) + +unix/hlib/mach.h [HSI] + Added the following new machine constants: + + MAX_EXPONENTR + MAX_EXPONENTD + MAX_DOUBLE + + The related values MAX_EXPONENT and MAX_REAL were already defined. + The new values were added to remove the assumption that the real and + double datatypes have the same number of bits in the exponent, which + is certainly not the case on all machines. More work needs to be done + to define the optimum set of machine constants. (2/19) + +pkg/cl/decl.c +pkg/cl/pfiles.c + Increased the default amount of storage allocated for a string type + parameter from SZ_FNAME to SZ_LINE. The shorter size was causing + truncation of long string values, e.g., file or image templates, + when the value on the operand stack was assigned into the parameter + during initialization of the task argument list. The default amount + of storage allocated for filename type parameters is still SZ_FNAME; + filename parameters are equivalent to string parameters in nearly + all cases, hence these may be used to reserve storage for objects + for which SZ_FNAME is sufficient. This is similar to the situation + in SPP, where SZ_FNAME is used for a lot more than just filenames, + and really means something more like "general operand name". (2/19) + + NOTE - A few tests were made following this change, running compiled + tasks which have template strings dimensioned SZ_LINE or larger + internally. In all cases I was able to enter a template string of + a least two lines of text (which is what SZ_LINE is). On some systems, + one will need to use backslash continuation to enter the long string + on two host lines, and this works too. If longer file lists are + desired, one must use an @file or something similar. A file list + entered with an @file can be arbitrarily large, e.g., I have run tasks + using an @file containing a list of all the files in IRAF (about 7000), + each by their full pathname. + +sys/tty/ttysubi.x + There was a bug which came into play when %. was used with %r. The %r + would swap the [x,y] coordinates upon input, but would not swap the + deltas returned on output by the special character avoidance code. + The routine was modified to swap the deltas before returning, if a %r + was executed while processing the output sequence. (untested) (2/20) + +dev/termcap + Added a device `textw', a wide (132 column by 60 line) version of + the generic textfile device `text'. (2/20) + +pkg/system/help/t_help.x + This code was restricting rmargin (the right margin) to the value of + `ttyncols', preventing wide or right-shifted output on wide printer + devices. The task was modified to use `ttyncols' only if the device + type is `terminal'. (2/20) + +sys/etc/main.x + When using the @parfile syntax to enter task parameters while running + a task standalone, an illegal parameter assignment line would cause + the task to abort with an IRAF main syntax error. Changed this to a + warning message with a copy of the offending line of text. (2/20) + +unix/os/zfiotx.c [UNIX HSI] + Fixed the following obscure bug in the UNIX HSI, which surfaced + because the stg_getline()/stg_readtty() code services STDIN reads + from a subprocess while the workstation is in graphics mode by + reading the terminal raw mode, rather than the usual line oriented + mode. In UNIX, when EOF is seen on a stdio stream, the EOF bit is + set on the stream. This must be cleared, e.g., with clearerr(), + or all subsequent reads will see EOF as well. The terminal driver + was doing this for line mode reads, but was not doing so for raw + mode reads, so a raw mode read following a raw mode read which + returned EOF (because the user typed ) would return a + spurious EOF, causing the reader to terminate prematurely. Fixed + this, and also replaced the line mode code which was clearing the + flags _IOEOF|_IOERR explicitly by name by an equivalent + call to the clearerr() macro, for greater independence of the local + UNIX implementation. (2/20) + +sys/gio/cursor/rcursor.x + The 'E' key in cursor mode is supposed to expand the plot only in X + or Y if the range is negligible in the other axis, i.e., if the cursor + is moved along only one axis when marking the expand rectangle. The + range tolerance used for the test was .001 ndc, which was too small + for some devices. Increased the range to .01 ndc. (2/21) + +pkg/plot/implot.x + Added a similar feature to the 'e' key in IMPLOT. If the range marked + has a negligible Y extent the data is plotted with autoexpansion in Y. + This feature depends upon the ability to set the cursor position in + software via the HL keys; if the terminal does not support this, the + ":x" command may be used instead. (2/21) + +sys/gio/ginit.x - +sys/gio/gfrinit.x + +sys/gio/greset.x + +sys/gio/gframe.x + +sys/gio/gcancel.x +sys/gio/gclear.x +sys/gio/gdeact.x +sys/gio/gopen.x +sys/gio/greact.x +sys/gio/doc/gio.hlp + The GCLEAR routine not only clears the screen (or whatever), it also + resets the internal state of GIO to the GOPEN state. This is desirable + when making plots which are fairly independent of one another, since it + automatically resets the line style, glabax parameters, and so on, + eliminating the possibility that the plot currently being drawn will + be accidentally affected by the parameters used to draw the previous + one. + + In some cases, however, particularly when using GSET calls to set + the glabax options, it is desirable to not reinitialize everything, + as then one must keep a state table independent of GIO and reset the + prior state after a GCLEAR. Two new routines have been added to GIO + to give the application a choice of how they want to do this. + + The GFRAME routine, like GCLEAR, clears the screen, but it does not + reset anything in the internal state of GIO, including even the WCS + (some flags are however set to cause the GIO state to be retransmitted + to the graphics kernel when i/o occurs). An additional routine GRESET + has also been added to selectively reset the internal state of GIO. + The GRESET call is as follows: + + greset (gp, flags) + flags: + GR_RESETALL reset everything + GR_RESETGIO reset only GIO drawing parameters + GR_RESETWCS reset the WCS to wcs=1, all NDC + GR_RESETGLABAX reset the GLABAX parameters + + A GCLEAR is equivalent to a GFRAME followed by a greset(gp,GR_RESETALL). + This revision is upwards compatible and should not require any changes + to existing code. (2/21) + +sys/gio/stdgraph/stgtxset.x + Deleted the "- GT_ROMAN + 1" conversion that was being applied to the + font code, as this is already done when the code is passed to the + encoder for output, and the text drawing code assumes throughout that + the font code is as defined in . (2/21) + +sys/gio/stdgraph/stgplset.x +sys/gio/stdgraph/stgpmset.x + In stg_plset(), the polyline width is passed via GKI as a packed + integer, but was not being unpacked into an int. Fixed this, and + also added a max(1,width) to both stg_plset() and stg_pmset() to + prevent zero linewidths. (2/21) + +sys/gio/cursor/grcaxes.x + Changed the font for the cursor mode 'A' tick labels from roman to + bold, for consistency with the glabax code. (2/21) + +dev/graphcap +dev/cacheg.dat + Added an LW (polyline linewidth) capability for the GTERM entry. (2/21) + +sys/tty/ttyopen.x + If the routine returned with an error exit it was not closing the + termcap/graphcap file, causing a wasted file descriptor. (2/21) + +lib/gio.h +lib/gset.h +sys/gio/gactivate.x + +sys/gio/*.x + The GOPEN procedure now supports a new open mode modifier, AW_DEFER, + which allows activation of the workstation to be deferred until i/o + to the workstation is ready to take place (AW = Activate Workstation). + The workstation may then be activated either explicitly by calling + the new GACTIVATE procedure, or implicitly by calling greactivate, + gclear, or by doing i/o to the workstation. If the AW_DEFER mode is + not indicated the workstation is activated at GOPEN time, i.e., + physically placed into graphics mode, and clearing the graphics plane + if NEW_FILE mode is also specified. This feature is intended for use + in interactive graphics applications and will most likely be ignored + if graphics is redirected to a noninteractive device. An example + illustrating when this might be useful is shown below. + + include + + gp = gopen (device, NEW_FILE+AW_DEFER, STDGRAPH) + + for (;;) { + call greactivate (gp, AW_CLEAR) + + call gdeactivate (gp, AW_PAUSE) + + } + call gclose (gp) + + This is an example of an application which executes alternately in + terminal and graphics mode. Since the application wishes to start + out in terminal mode, activation of the workstation is deferred; + if one were going to start out in graphics mode, there would be no + reason to open the workstation in deferred-activate mode. + The workstation is later explicitly reactivated when a new plot is + to be drawn, and subsequently deactivated to return to terminal mode. + This sequence can be repeated any number of times. + + The same thing can be acomplished somewhat simpler by replacing the + calls to g[rd]eactivate by calls to gopen and gclose and dropping the + outer set of calls, i.e., closing the graphics stream completely off + when not actually in graphics mode. The main reason for using + g[dr]eactivate instead, with or without deferred-activate mode, + is one of efficiency in highly interactive applications, to avoid + the need to repeatedly access the graphcap file, particularly if the + graphcap entry for the user's graphics terminal is not cached. (2/21) + +lib/fio.h +lib/fset.h +sys/fio/areadb.x +sys/fio/awriteb.x +sys/fio/filopn.x +sys/fio/fseti.x +sys/fio/fstati.x +sys/fio/fgetfd.x + Added a new FSET option to FIO called F_CLOSEFD. If this option is + set for a file, the host file descriptor or channel will be closed + whenever the channel is inactive, i.e., the channel will be open + only while an AREAD or AWRITE operation is actually taking place. + This is used when a program must be able to simultaneously access a + larger number of files than can be opened simultaneously at the host + system level, e.g., when one needs to median-sum 100 images and the + host system only provides 20 file descriptors. Note that the maximum + number of open files will still be limited by FIO; the builtin limit is + currently 70, but this will probably be increased to 128 or larger in + the future. Naturally, it is inefficient to have to open and close a + file for every i/o operation, but since it is done at the lowest + possible level without closing the FIO file descriptor or returning + any buffers, the expense is not too bad, particularly if large + transfers are used to minimize file accesses. + + The F_CLOSEFD option is permitted only for existing (not NEW_FILE) + binary files. Special devices are supported, e.g., the static file + driver, but only if there are no significant changes to the file state + when it is closed and later reopened. For example, the F_CLOSEFD + option cannot be used in conjunction with mapped segments and the + static file driver, since the data in the FIO buffer must remain + intact when the file is closed and later reopened at the host system + level, and closing a mapped file would cause the mapped pages (the FIO + buffer itself) to be unmapped. (2/22) + +lib/imio.h +lib/imset.h +sys/imio/imopsf.x +sys/imio/imsetr.x +sys/imio/imstati.x +sys/imio/immapz.x +sys/imio/imsetbuf.x + Added two new IMSET options IM_CLOSEFD and IM_BUFSIZE to IMIO, and + modified the way the IM_ADVICE parameter is treated: + + IM_ADVICE + If the value given is RANDOM, the FIO buffer size will be set to + the size of an image line, rather than passing the RANDOM advice + parameter on to the pixel file, as previously. Otherwise, the + advice parameter is ignored and IM_BUFSIZE (default 64KC=128Kb) + is used as a starting point to set the FIO buffer size. + + IM_BUFSIZE + The recommended FIO buffer size for the pixel file. The value + given is taken as a starting point to compute the actual buffer + size, which will normally be an integral multiple of the size of an + image line (assuming image lines are blocked to fill an integral + number of device blocks). + + IM_CLOSEFD + Setting this on an image descriptor causes IMIO to set F_FCLOSEFD + on the pixel file descriptor when the pixel file is opened. This + may be useful in applications which must simultaneously open a + large number of images, to save host file descriptors. + + In most applications there is no need to fiddle with these parameters. + They are provided primarily for programming image operations which + require either very large amounts of memory, or simultaneous access + to very large numbers of images. (2/22) + +lib/fio.h +lib/fset.h +sys/fio/ffault.x +sys/fio/ffilsz.x +sys/fio/fseti.x +sys/fio/fstati.x + Carefully adjusting the FIO buffer size to an integral number of image + lines does one no good if the first image line in the pixel file is + not aligned to the offset of a file buffer. With the OIF format, for + example, the first image line will begin at some offset like 1025 (due + to the pixel file header record), whereas the first file buffer will + by default begin at file offset 1. It turns out that the file offset + to which the FIO buffers are aligned is pretty arbitrary as far as + FIO is concerned; one need only replace a "1" (in ffault.x) by an + offset variable defined in the file descriptor. The new offset option + is implemented as an FSET option named F_FIRSTBUFOFF, default value 1. + Setting F_FIRSTBUFOFF causes any existing buffers to be destroyed. + Setting the first buffer offset to a value greater than 1 causes the + file data to the left of F_FIRSTBUFOFF to become inaccessible. (2/22) + +sys/imio/imsetbuf.x + Added a call to FSETI to align the first file buffer to the file offset + of the first image line. By the time this is called the image kernel + will already have written the pixel file header (if any), hence the + fact that the first part of the file will be inaccessible is not a + problem - in fact it is probably an advantage. (2/22) + + NOTE - This revision should make IMIO somewhat more efficient in + general. It also fixes a potential file fault thrashing problem that + could occur when BT_NEAREST boundary extension was used on an image, + and the first or last line of the image was not wholly contained in + a file buffer. This behavior has actually been observed with the + ROTATE image operator, when an image happened to be just the right + size. If ROTATE (or any similar geometric operator) has been observed + to be particularly slow, file faulting as decribed here may have been + the cause. (2/22) + +unix/hlib/mkmlist.csh + No longer returns references to in the module list; since + this file is frequently modified and the error codes never change, + it should not be referenced in library module dependency lists. (2/22) + +------------------------------ +(All caught up with current bugmail, minor feature enhancement requests, etc.) +VMS/IRAF HSI updated. +VMS/IRAF (IRAFX) bootstrapped. +VMS/IRAF - all MIP files deleted and replaced via tar from lyra. +VMS/IRAF - started full sysgen. (2/22) + +sys/memio/*.x +sys/memio/kmalloc.x + +sys/memio/krealloc.x + + Extensively revised the MEMIO sources, moving all the procedures out + into separate files. The major functional change was to modfiy MALLOC, + CALLOC, and REALLOC so that they take a normal error action (causing + error restart if not caught in an error handler) instead of causing + a fatal error and process shutdown. The new procedures KMALLOC and + KREALLOC were added for use in low level code where the calls to the + error recovery code in MALLOC and REALLOC would cause reentrancy + problems. (2/22) + +sys/ki/ktzopn.x +sys/ki/kopdir.x +etc/envinit.x +etc/environ.x + These files were modified to use the new KMALLOC and KREALLOC procedures + to avoid reentrancy problems with the error recovery code. (2/22) + +sys/*/*.x +sys/*/*.gx + Added errchk declarations where needed for MALLOC, CALLOC, and REALLOC. + (2/22) + +sys/etc/main.x + Replaced the calls to CLCMD by calls to putline(CLOUT,...), to avoid + the error checking recently put into CLCMD. (2/22) + +--------------------- +VMS/IRAF - full sysgen completed without incident. +Updated VMS/IRAF again from lyra. (2/23 2 pm) +Updated SUN/IRAF (pavo), and started a full sysgen. (2/23) + +unix/hlib/config.h +unix/hlib/libc/libc.h +vms/hlib/config.h +vms/hlib/libc/libc.h + Increased the number of VOS file descriptors from 70 to 128. This + number needs to be 10-20 larger than the maximum number of host file + descriptors (e.g., 64 on 4.3BSD). (2/23) + +sys/gio/cursor/gtr.h +sys/gio/cursor/grcopen.x +sys/gio/cursor/grcclose.x +sys/gio/cursor/gtrctrl.x + Cursor mode is supposed to leave the terminal in the same state it + was in when cursor mode was entered, e.g., when the cursor is read + following a GOPEN, with the terminal in graphics mode, the terminal + is left in graphics mode. This works fine, but there was one case + which was not being dealt with properly - if the cursor was read with + the workstation open but deactivated, i.e., in terminal mode, the + workstation was not being reactivated for the cursor read, nor was it + being restored to deactivated mode. The cursor read would nonetheless + work for the vt640 since the graphcap read-cursor control string forces + the terminal into graphics mode, but since the graphics system did not + explicitly reactivate the terminal it would not deactivate it either, + causing it to be left in a funny mode - deactivated but in graphics + mode. The code was modified to keep track of reactivate/deactivate + calls, with cursor mode automatically reactivating and deactivating + the workstation if necessary, when cursor mode is entered and exited. + (2/24) + +sys/gio/greact.x +sys/gio/cursor/gtrctrl.x + When greactivate is called in AW_DEFER mode before the workstation has + been activated, it automatically does an activate (OPENWS) rather than + a REACTIVATEWS. The problem was that the "flags" argument was being + ignored in this case, thus defeating AW_PAUSE and possibly causing + the graphics plane to be activated before the user has a chance to + read the text. Added some code to handle the pause function in this + special case. + + Also, in this routine and gtrctrl.x, added some IF statements so that + page and waitpage are ignored except for the STDGRAPH stream; one does + want an interactive pause prompt if graphics is sent to a batch plotter + device. We may want to recognize this type of interaction for STDIMAGE + too, but I will wait until later to decide about that. (2/24) + +pkg/cl/eparam.c + There were some problems with EHIST, probably due to the recent bug + fixes for EPARAM (the eparam code is rather convoluted). The cursor + was coming up one line too high; deleting a "- 1" seemed to fix this. + Also added a clear-to-end-of-line in e_display so that short history + commands completely overwrite longer ones when moving up or down in + the history list, and added a newline at the end when ehist exits so + that the command output does not overwrite the command. Some of these + problems were probably in the eariler code, too. (2/24) + +--------------------- +Sun/IRAF, VMS/IRAF systems updated (incremental). (2/24) +Skip made wtar tape for AOS/IRAF. (2/25) + +unix/hlib/zzsetenv.def [SUN/IRAF only] + On the Sun systems pavo and tucana, changed the default devices in + the environment (hlib$zzsetenv.def) to stdplot=printer=lw, + terminal=gterm40, and so on. (2/25) + +unix/os/zfiomt.c + When a tape read fails on UNIX, at least with the driver I used for + testing, evidently the read aborts immediately when the hardware + error occurs, leaving the current record partially read. Since the + VOS assumes that the tape has been positioned to the next record + following the bad record, I had to add a skip record forward to the + ZZRDMT primitive. This causes the routine to work correctly most + of the time, but unfortunately it does not appear to reliably do the + same thing. This needs further investigation. (2/25) + +sys/fio/filbuf.x +sys/fio/fseti.x + Modified the way the F_VALIDATE fseti option is implemented slightly. + This option is used to validate the data in the FIO buffer following + a read error on the input device, e.g., magtape. It was working the + way I had it, but the data for two records would be returned in the + single read following the failed read and buffer validation. The + purpose of the modification was to preserve the record structure of + the tape for those application which count on a FIO read to return + one tape record at a time. The fix was for FSETI to set a flag for + FILBUF to validate the buffer, rather than having FSETI immediately + validate the buffer itself. This was tested and it works fine + provided the kernel succeeds in detecting the bad read and positioning + the tape properly to the next record following the bad one. (2/25) + +sys/fio/zfiott.x +sys/fio/zfiott.com + Modified the playback code in the terminal driver (ZGETTT) to permit + multiple data chars in each input line of text when reading in raw + mode. In playback mode, each input line is saved in an internal + buffer, and characters are returned out of this until it is exhausted + and another line of the log file is read. In the process of testing + this, I also found and fixed a char/int mismatch bug in a call to + cctoc(). (2/26) + +pkg/cl/errs.c + Added code to check during error recovery if the terminal is in raw + mode, and reset it to normal line-buffered mode if so. (2/26) + +sys/gio/gactivate.x +sys/gio/greactivate.x +sys/gio/cursor/gtr.h +sys/gio/cursor/gtrctrl.x +sys/gio/cursor/gtropenws.x + Had to scrap the changes made to greactivate(), etc., on 2/24. The + main revision made at that time was to have greactivate() implement + the AW_PAUSE feature directly, when opening the workstation in + response to a call to greactivate() in AW_DEFER mode. The problem + with this is that the GIO code must be metacode output only, with no + direct interaction with the user terminal. I put the code in with an + IF-test on the stream, disabling interaction if not writing to + STDGRAPH, but of course that is not sufficient. Just goes to show + how easy it is to mess the system up if you don't really know whats + going on (or if you forget). + + Interaction with the user in interactive graphics is permitted only + in the cursor mode code. Recognition of the activate workstation + flags (AW_PAUSE, etc.) in the initial activate workstation implied + in the GKI_OPENWS directive is possible in cursor mode, but would + have required a change to the external format of the GKI_OPENWS + instruction, so I did not do it. The GKI metacode format will + probably suffer some changes in the upcoming GIO imaging extensions + project, but I did not want to change the metacode format at this time. + The AW_PAUSE code was removed from greactivate(), and for the moment + the pause flag will simply be ignored when opening the workstation + in defer mode. A flags argument was added to the GIO gactivate() + function, so that greactivate() can pass the flags argument to OPENWS + via gactivate(), so that the calling sequence of this routine will + not have to be changed when OPENWS is modified to include a flags + field. + + The IF-test on STDGRAPH in gtrctrl.x, used to test if the AW_PAUSE + flags are to be executed or ignored, was replaced by a test on a new + descriptor flag field TR_INTERACTIVE(tr). This is set when the + workstation is opened in gtropenws.x, if the graphics device is the + user terminal. Otherwise, the interactive deactivate/reactivate + workstation flags are ignored. (2/27) + +sys/gio/stdgraph/stgrtty.x + [1] When reading from STDIN with the workstation activated, characters + are read in raw mode. EOF was not being detected since the raw EOF + character is returned as data when in raw mode, and the code was + checking for a FIO EOF, rather than looking at the character itself. + [2] This routine was not performing a graphics disable (GD), hence + a series of reads to the STDIN while in graphics mode, with no + associated writes to STDOUT or STDERR, would execute with the entered + lines text echoing as if they were appended to the previous line. + (2/27) + +vms/gdev/sgidev/mkpkg.com + Modified to move the executables to the HLIB directory, so that this + happens automatically when doing a bootstrap. (2/27) + +sys/fio/fntgfn.x + Found an obscure bug in the filename template code, which has probably + been there since the code was written. The bug would cause an infinite + loop when trying to expand a filename template with FNTGFN (or any of + the routines which call it). The routine which returns the next token + from the template, upon reaching EOS on the template string, was + incorrectly looking at the "last" character in the output string. + Since the output string would be the null string, the "last" character + was one char off the front end of the array, and could contain any + random data. The code was looking for one of the chars $/, and the + bug would be harmless unless one of these characters just happened to + be at that location. (3/4) + +unix/hlib/SUN_kludge/precomp.csh [SUN/IRAF] + Added a compile-no/optimize entry for main.x (the IRAF main). Did not + fully analyze the problem, but an address is being saved in a register + and then the register is clobbered before it is used (while building + up the argument list to a FSETI call). (3/5) + + Analysis, 3/6/87 --- + + This bug fix bothered me, so I went in and analysed it in detail to + see what was really causing the problem. The actual compiler bug + turned out to be in the module pds_apdp8s in the RPDS task in mtlocal. + This is a trivial little procedure, the body of which is so small that + I will include it here for reference: + + for (i=1; i <= npix; i = i + 1) + b[i] = (a[i] / 400b) * 100b + mod (int (a[i]), 400b) + + What is happening is that the compiler is using the register D2 to + evaluate the mod function, but the procedure preamble/postamble is + not saving and restoring the contents of this register (the bug + probably has something to do with the code used to do inline + expansion of the MOD intrinsic function). It turns out that the Sun + procedure calling sequence requires a procedure to save and restore + the contents of registers D2-D7, etc., if they are used in a procedure, + so that a procedure which calls a subprocedure can assume that its + registers are intact when the called procedure returns (this is + common practice on many systems). + + This can lead to some very obscure bugs like the one we have here. + The register D2 is used in the IRAF main; the main calls a task, the + task calls a number of procedures, and so on for hundreds of procedure + calls before returning to the main. If any of those procedures uses + register D2 but does not save and restore it, then the FSETI call in + the main either bombs out with a segmentation violation, or FSETI + causes a fatal panic shutdown due to an illegal file type code. + (Actually, the bug could be masked if any of the intermediate + procedures leading back to the main also use, and hence save and + restore, the register). In a procedure other than the main, the same + bug could occur with completely different results, possibly resulting + in improper execution rather than an obvious program crash. + + Compiling the main without optimization defeats register allocation + in the main and the bug goes away (because the main is no longer using + the register), but this is treating the symptoms and not fixing the + actual bug. Clearly, it is extremely important on machines with + calling sequences like that on the Sun that registers be properly + saved and restored by called procedures (particularly hand written + assembly code procedures), else extremely obscure bugs may result. + +------------------- +(Begin fixing bugs reported since the new V2.5 was ported to Sun,VMS,AOS). + +pkg/cl/exec.c + In oneof(), added a counter so that the "use logout to logout of the + CL" error is only taken a finite number of times. It was still + possible to get into a loop when the CL input was a terminal, but the + user managed to logout of the computer somehow, causing an infinite + sequence of EOF's on the input stream. (3/7) + +sys/gio/cursor/gtrctrl.x + Removed the call to gki_fflush(), which would flush the control + instruction to the graphics kernel. This must not be called from + within gtr_control() since it involves a call to prpsio() (the + pseudofile i/o controller) when writing to a connected subkernel + (e.g., the stdplot device), and gtr_control() is itself called from + prpsio(), resulting in a reentrant call to prpsio and thus immediate + brain damage to the pseudofile i/o system. This was the bug which + was causing graphics tasks run with dev=stdplot to fail. (3/7) + + NOTE - One wonders, if prpsio() reentrancy occurs here, why doesn't + it occur in the other calls to gki_flush() and gki_fflush() in the + cursor mode code. The reason is that when prpsio() is called to read + the next CL command from a subprocess (the user graphics task), a + cursor read takes the form of a CL statement like "=gcur". This is a + CL command, hence prpsio() will exit back to the CL interpreter. + Then when cursor mode is entered and one does something like a snap, + which writes to a subkernel and hence involves a call to prpsio(), + the routine is called afresh. + +sys/gio/mkpkg +sys/gio/gactivate.x + Added a "include ". When opening a graphics stream in APPEND + mode, the routine was checking the file driver of the output stream + to see if it was zardbf, to know whether to get the old WCS from the + CL or from UPARM. The test would fail because without , + zardbf would be the real routine, rather than the KI version kardbf, + used with networking. This was the cause of the bug which would cause + a task to hang up reading from CLIN when opening a metacode file in + APPEND mode. (3/7) + +vms/gdev/sgidev/sgi2vccp.f +vms/gdev/sgidev/sgi2vimp.f +vms/gdev/sgidev/sgi2vptx.f +vms/gdev/sgidev/sgi2vqms.f +vms/gdev/sgidev/sgi2vtri.f +vms/gdev/sgidev/sgi2vver.f +vms/gdev/sgidev/sgitranlib.f [+] +vms/gdev/sgidev/mkpkg.com + Standardized the support routines common to most of the translators + and relocated them in sgitranlib.f; modified mkpkg.com to link with + it. Detabbed and rewrote fortran continuation lines to make shipment + of translators by electronic mail more reliable. Made all translators + that can submit to a VMS queue recognize the special queue name 'none', + to better support nonspooled devices. (3/2 SRo/SH) (3/7) + +sys/fio/fseti.x + In the F_FIRSTBUFFOFF case, added a call to flush() to flush any + buffered file output before calling frmbfs() to return the file buffer. + (3/8) + +sys/imio/db/mkpkg + The module list was missing a reference to for idbfind.x. + The library module was out of date (on lyra) and was not correctly + referencing the IM_UABLOCKED(im) field, causing header parameter + searches to fail. (3/8) + +sys/.../mkpkg + Went through and rebuilt most of the module lists in the VOS, to avoid + more problems of this type. There were some errors, but did not notice + any other serious ones. (3/8) + +pkg/cl/eparam.c + The e_display() function, used by EPARAM to display parameter prompt + strings, had a bug which would cause the first character to be + repeated in all lines after the first when displaying multiline + prompts. I also added a feature which allows a prompt line to take + over the whole terminal line if the first char is \r; otherwise, the + prompt is displayed in the prompt area at the right of the screen. + (3/8) + +pkg/cl/history.c + The #{ ... #} sequences, used to switch to and from command mode on a + stream, were not being recognized in "interactive" command streams, + i.e., for commands typed in interactively from the terminal. (3/8) + +pkg/cl/param.h + Discovered that the parameter type flags (field p_type in the param + structure) were overflowing the allocated storage word (type short) + by one bit. The bit that didn't fit was PT_ARRAY, which explains why + arrays haven't been working recently in the new CL. Changed the + allocation to a full integer and rebuilt the CL. (3/8) + +pkg/cl/grammar.y + Modified the grammar so that compute mode is automatically enabled when + typing a parameter declaration in interactively, e.g., "int woof[3]". + (3/8) + +pkg/plot/implot.x + Modified so that a ":x" or ":y" with no x/y range arguments both + reenables autoscaling and replots the current line or column with + autoscaling, rather than merely reenabling autoscaling, as previously. + (3/8) + +unix/os/net/kutil.c + Fixed a typo: "text[1] -> text[0]". (3/8) + +sys/tty/ttysubi.x + Replaced the last two occurrences of "argnum" by "revstart" in the code + which reverses the deltas; overlooked this when I made the original bug + fix on 2/20. The code has now been tested (by Skip). (3/8) + +sys/clio/clputx.x +sys/clio/clputr.x +sys/clio/clputi.x +sys/clio/clputd.x +sys/clio/clputc.x +sys/clio/clputb.x +sys/clio/clpstr.x +sys/clio/clcache.x + Modified the CLPUT procedures to update the cached value of a parameter + as well as the CL value. If this is not done subsequent CLGET calls + during the execution of the same task will continue to return the + same value. (3/8) + +--------------------- +(End last round of bug fixes - all bugs reported since 2/24 now fixed.) +(VMS/IRAF updated 3/8) +(SUN/IRAF updated 3/8) + +vms/hlib/sgiqueue.com +dev/graphcap + As part of the current effort to standardize the sgi translators, + I changed sgiqueue.com to have a maximum of 4 DCL parameters for + each entry. Devices affected are vver, vtri and vptx. Graphcap + entries for those devices were updated accordingly. (3/10 SH) + +sys/osb/f77pak.f + Was not blank filling the last character in the F77 output string. + (3/10) + +sys/fio/fntgfn.x + There was a problem in the filename template code, when using string + substitution to edit a file list expanded upon a logical directory. + The pattern matching would be always be performed on the filename + ignoring the directory prefix, but the edit would be performed on the + full filename including the directory prefix if any, causing the + edit to be performed so many chars to the left of where it should be. + For example, "lib$*%%_o%.com" should expand to "lib$fio_o.com", + "lib$prc_o.com", etc., but "lib_o$fio.com", "lib_o$prc.com" was being + produced instead, a 4 char left shift of the insertion, since the ldir + prefix is 4 chars long. With no ldir prefix there was no problem, + which is why this has gone unreported until now. (3/10) + +sys/imio/imsetbuf.x + The FIO first buffer offset cannot be set to the offset of the first + image line unless the offset of that line is aligned on a device block + boundary. Added a test to omit the call if the first image line is + not aligned in this way (as in STF images). (3/11) + +dev/graphcap +dev/termcap + Entries were added for the Graphon 140 terminal. Both entries were + originally created by Raymond Talbot of the Aerospace Corp. in L.A., + then later modified by George Kaplan at U.C. Berkeley, Space Sciences + Lab. The entries have now been tested extensively at UCB. Users + should note that they may have to set the GIN terminator to CR in + local setup mode. (3/11 SRo) + +sys/imio/iki/stf/stfopix.x +sys/imio/iki/stf/stfwgpb.x + Back when the STF image kernel was first written, the GEIS format + required that group parameter block header parameters be ordered or + sized to avoid holes in the structure, caused by alignment of double + floating values to quadword addresses (or so I recall). Anyhow, the + STF kernel was written to order the GPB of new images in this way, + but it would assume that the GPB of existing images was already ordered + this way. STF images have recently appeared which do not adhere to + these alignment restrictions for double values, causing the STF kernel + to mess up the GPB when opening an existing image READ_WRITE and + subsequently updating the header. + + For example, + + DATAMIN real + DATAMAX real + CRPIX1 real + CRVAL1 double + + would cause problems, since there are 3, rather than 2 or 4, reals + before the double, causing the double to fail to be aligned to a + quadword offset relative to the start of the GPB. + + I am going to assume that there are no longer any special alignment + restrictions on the GPB fields; maybe there never was and this was a + misunderstanding on my part. The write-GPB code was modified to work + regardless of the field alignment, and the open-pixfile code was + modified to skip the reorder-GPB step when create a new image. + This will also avoid the annoying reordering of the group parameters + for new images, which was being done by the kernel in the past to + enforce the alignment restrictions when the input GPB specification + was not doing so. (3/13) + +unix/gdev/mkpkg +unix/gdev/zfiogd.x +unix/gdev/iism75 + A UNIX version of the IIS model 75 interface (M70 data stream filter) + was installed. This was tested remotely working with the group at + AT&T (Tony Tyson), since we do not have a model 75 here. (3/14 DT/SRo) + +vms/boot/mkpkg/host.c + The $purge function now checks for a missing directory name argument, + and avoids the call to vfn2osfn(), which would produce an error message + if called with the null string. Also, the VMS PURGE is called with the + /LOG switch if mkpkg is executed in debug mode. (3/14) + +dev/termcap +dev/graphcap +dev/cacheg.dat +dev/cachet.dat + Updated the termcap and graphcap files on lyra and draco, and rebuilt + the cache files to capture the updated device entries. (3/14) + +unix/os/zfiomt.c +vms/os/zfiomt.c + Following a long series of tests to determine the best way to recover + from parity errors when reading magtapes, the ZZRDMT primitive was + modified to scrap the attempt to zero out the user buffer and repeat + the read, which would cause the tape to be left at an unpredictable + position. It now simply returns ERR for the first few bad reads, and + then starts doing skip record forwards to attempt to recover if a bad + read causes the driver to enter an infinite loop trying to read the + same record. If a large number of read errors are seen on a tape the + driver eventually just returns EOF on the file. We were still getting + unpredictable results when trying to read tapes with bad records, but + this works in most cases and seems to be the best we can do; the rest + is really the responsibility of the host driver and the hardware + controller. (3/14) + +vms/os/net/zfioks.c + Someone reported that they could not access a remote node over the + network, using a 22 character password on the remote node. God only + knows why anyone would want to have a 22 character password, and I + guess the Berkeley people didn't expect that either, since the problem + turned out to be a 16 char limit imposed by the REXEC daemon. + Allowing for the EOS, the maximum password length when calling into + a remote UNIX node should thus be 15 chars; in actual tests this + failed too, but a 12 char password was ok (maybe a bit longer, I didn't + try). The ZFIOKS (IRAF) limit is 32 chars, and I verified that the + password string was being written out over the network correctly. + + I also modified the ZFIOKS open procedure to only ask for the password + for a remote node twice, if the same string is entered both times. + This prevents the user from being repeatedly asked for the password + for a remote node if the node is physically unreachable for some + reason, e.g., because the machine is down. The disadvantage is that + if the same mistake is made the second time, causing an invalid + password to be entered into the password cache, it will be necessary + to log out of VMS to clear the error. Note that rubouts are permitted + when entering a password, so it should not be difficult to enter a + password without any typing errors. (3/14) + +------------------ +The following changes were made mostly to eliminate library conflicts for the +VMS/IRAF shared libraries, and do not involve any functional changes to the +affected routines. This initial implementation of VMS shared libraries closely +follows that done by Dennis Crabtree last December. + +pkg/cl/scan.c +pkg/cl/opcodes.c + Changed the name clscan() to cl_scan(), to avoid a library conflict + with the CLSCAN procedure in FMTIO. (3/15) + +pkg/cl/gram.c +pkg/cl/edcap.c +pkg/cl/builtin.c +pkg/cl/clprintf.c + Changed all occurrences of 'strsrt' to 'strsort', and all occurrences + of 'strtbl' to 'strtable'. (3/15) + +pkg/system/sort.x + This program contained two internal routines GTEXT and GOPEN which + conflicted with the GIO procedures of the same name. Went through and + cleaned up this ancient code, adding a package prefix to all internal + routines (which solved the name problem), and in general bringing the + code up to modern IRAF standards. (3/15) + +vms/gdev/iism70/mkpkg +vms/gdev/iism70/m70wti.f - + Deleted the M70WTI routine, which was not used anywhere, and which + referenced a lower level routine RBUTN which was not present in the + library, causing an unresolved module reference when building the + shared library. (3/15) + +sys/imio/imdmap.x + This routine had an illegal backwards library reference to the IMDOPEN + procedure (FIO device open procedure for the display device) in the + TV package code. Since the routine bypasses the IMIO interface and + has explicit knowledge of the IMIO internal data structures, it needs + to be part of the IMIO interface and it was not really correct to move + it to a package source directory. I solved the problem by deleting the + old, unused min_lenuserarea argument and replacing it by a reference + to the imdopen() external function, so that the application can pass + this in at runtime. (3/15) + +pkg/images/tv/display/dsmap.x + Modified the call to the IMDMAP procedure in accord with the above + change to the calling sequence. Note that all the other hacked + versions of the display task (grinnell@ctio, iism75@steward/cti, + deanza@stsci) will also need to be modified. (3/15) + +pkg/images/imutil/t_imcopy.x +pkg/images/imutil/imcopy.x +pkg/images/imfit/t_lineclean.x + Added a local package prefix to the internal procedure name 'imcopy', + to avoid a name conflict with the (as yet partially implemented) IMIO + procedure of the same name. (3/15) + +------------------------- +(end of shared library related changes to the VOS and applications) + +unix/boot/rtar/rtar.c +vms/boot/rtar/rtar.c + In the switch/case which processes the argument list flags, case 'f', + added a test for (*argp==NULL) to avoid a segmentation violation in + tape_open in the event of a missing filename argument. (3/15) + +------------------------- +(All systems updated; on draco, deleted all binaries and did a full sysgen +(to ensure that all old objects were removed from the libraries.) (3/15) + +local/login.cl [UNIX/IRAF] + Regenerated the login.cl file for V2.5. (3/16) + +------------------------- +System moved to node GLL1 (microvax/gpx); Ultrix 1.2 port begun. (3/16) + +dev/hosts +dev/uhosts + Brought these files up to date for our local network. (3/17) + +unix/os/zfiotx.c +pkg/cl/errs.c +pkg/cl/history.c + Minor changes were made in these files to improve the ability of the + CL to recover (restore line mode i/o) when an error occurs in a + program which uses raw mode i/o. The OS terminal driver would save + and restore the terminal mode bits when setting raw mode, which is + great, but if raw mode somehow got physically set on the device then + it could never be cleared. Now, when the terminal driver is commanded + to disable raw mode it will do so, regardless of the previous state + of the device. Also, if the terminal driver receives the raw mode off + escape sequence it will clear raw mode even if it was never set at the + driver level. (3/17) + +------------------------- +Initial port of IRAF to Ultrix 1.2 completed without incident. (3/17) + +gio/cursor/rcursor.x + Added calls to gtr_page() and gtr_waitpage() to take the workstation + into and out of terminal mode when executing a :! os escape from + cursor mode. (3/18) + +gio/cursor/grccmd.x +gio/cursor/grcread.x +gio/cursor/grcwrite.x +gio/cursor/grcwarn.x + + There were still situations where messages written by low level code + in the CL process could end up in alpha mode text in the graphics + plane, while processing a :. command in cursor mode, e.g., :.read, + :.write, :.snap, and so on. For example, error messages would come + out in the graphics plane, as would the enter password prompt when + sending graphics output to a remote node for the first time. + + This would happen because when a colon command is read, the GE sequence + is issued when newline is seen, i.e., when the user types carriage + return. This is not a problem for colon commands in applications code + since all pseudofile i/o is processed through the stdgraph kernel, + but the low level code in the CL process can read and write directly + to the terminal. The solution was to echo the colon command on the + status line without the newline terminator. Any subsequent text is + then appended to the text already in the status line. One nice benefit + of this is that when the user types the "=" key to do a snap, the + command ":.snap" is echoed on the status line, providing positive + feedback to the user. I also added some code to intercept error + messages (grcwarn.x) and print them in the status line. (3/18) + +pkg/plot/implot.x + IMPLOT now includes the system banner (etc.sysid) in the plot title. + (3/18) + +vms/os/zfchdr.c + Modified ZFGCWD to return the current directory in lower case, rather + than upper case. This was breaking the new MKPKG special file search + code described below (directory string comparisons were failing due to + a case mismatch). Anyhow, pathnames have long been coming out in + mixed case on VMS (e.g., "[IRAF.SYS.OSB]f77pak.for"), which is + inconsistent and unaesthetic. (3/19) + +unix/boot/mkpkg/char.c +unix/boot/mkpkg/main.c +unix/boot/mkpkg/mkpkg +unix/boot/mkpkg/mkpkg.csh +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/mkpkg.hlp [UNIX,VMS,SUN] +unix/boot/mkpkg/pkg.c +unix/boot/mkpkg/sflist.c +unix/boot/mkpkg/tok.c + Made several enhancements to MKPKG, the major one being the addition + of a new "special file list" capability. Other, minor enhancements + include reorganization of the main to permit multiple subprograms on + the command line, e.g., "mkpkg relink install", and some improvements + to the detection of interrupts. + + The special file list capability makes it possible to flag any source + file in the system for special processing in a host specific fashion, + without making any changes to the portable system. This is done by + declaring all the special files for a given host operating system in + the new file "mkpkg.sf" in HLIB. Examples of files needing special + processing are files which have been optimized in assembler for a + specific host system, and files which need to be compiled in a + nonstandard way to avoid bugs in a host compiler. The special file + list replaces both the "$iffile as$file.s" type constructs in portable + mkpkg files, as well as compiler bug scripts like the "precomp.csh" + file in the "hlib$SUN_kludge" directory in SUN/IRAF. (3/19) + +unix/as/*.s +unix/hlib/mkpkg.inc [UNIX,SUN] +unix/hlib/mkpkg.sf + +vms/as/*.s +vms/hlib/mkpkg.inc [VMS] +vms/hlib/mkpkg.sf + + Added the mkpkg.sf special file list for each system (it is similar but + different for every system), and a $include for it in hlib$mkpkg.inc + so that the special files are defined regardless of who runs mkpkg, + or from what directory. Some changes were also required in the AS + directory, e.g., bitpak.s/bitupk.s were combined as bitfields.s, + to provide a one to one file mapping with bitfields.c in OSB. (3/19) + +sys/osb/mkpkg +sys/libc/mkpkg +sys/gio/nspp/sysint/mkpkg +sys/gio/ncarutil/sysint/mkpkg +sys/vops/lz/mkpkg +sys/vops/ak/mkpkg + These mkpkg files were modified to remove $iffile references to + special source files in AS, since this is now handled by the special + file list capability. (3/19) + +pkg/xtools/mkpkg + Added a "$purge lib$" to get rid of the new version of libxtools on + VMS. (3/19) + +----------------------- +Updated all systems. (3/19) + +bin/s_iraf.e + +vms/hlib/linkiraf.opt + +vms/hlib/irafuser.com [VMS/IRAF SHARED LIBRARIES] +vms/hlib/login.cl +vms/boot/spp/xc.c +vms/hlib/share/* + Modified VMS/IRAF to use shared libraries. For this to work, the + system manager must install the image bin$s_share.e when IRAF is + installed. The use of shared libaries reduced the amount of disk + consumed by the IRAF executables (BIN) from around 30000 blocks (15Mb) + to less than 10000 blocks (5Mb), i.e., slightly more than a factor + of 3; this should be a real boon to our microvax users with small + disks. Memory usage and link time should be correspondingly reduced, + and process startup should be speeded up somewhat, although most of + the time is probably spent on things other than paging. + + The XC task can be used to link images either with the shared library + image (-n) or as a fully resolved image (-z). I set the default to be + to use the shared library, since that is fastest and most efficient, + and is bound to be what people want most of the time. The principle + disadvantage is that symbol table information is not available for the + shared library, hence it is more diffiicult (but still possible) to + wander around in the system libraries with the debugger. To get around + this I added the -z flag to the foreign task definition for MKDEBUG; + it is necessary to run MKIRAF or edit your LOGIN.CL file to pick this + up. If one only wants to debug user code, "xc -x" will use the shared + library, giving a much faster link but no system symbols. + + The code used to generate the shared library is a bit of a kluge at + present. In particular, the shared library must be generated manually; + it is not done automatically in a sysgen. This will be remedied in a + future release. (3/21) + +sys/fmtio/strsrt.x +sys/fmtio/strcmp.x + + Added a new routine strcmp (more efficient than using strncmp with + maxch=ARB), and made minor optimizations to the code of the other + routines. The calling sequence of STRSRT (the string sorter) was + chanaged slightly, after first searching the system for all the + routines that use it; the routine is relatively new and is currently + only used in system code. The new string sorter chooses the pivot + element for the quick sort algorithm differently, to avoid quadratic + behavior when sorting an already sorted array. (3/22) + +sys/fio/fntgfn.x +sys/imio/db/imgnfn.x +sys/imfort/db/imgnfn.x +pkg/system/directory.x + These routines all referenced STRSRT, and had to be modified to agree + with the change to the calling sequence noted above. (3/22) + +sys/fmtio/str*.x +sys/fmtio/gstr*.x +sys/fmtio/zzdebug.x + All of these old routines used for-loops rather than do-loops to march + down the string. Where appropriate, converted these to use do-loops + to trigger the Fortran optimizer. In many of the string comparison + operators (strlt, strge, strncmp, etc.) I was also able to simplify + the logic considerably, making them somewhat faster. STRTBL was + rewritten to use the more efficient putline rather than putc to format + the output table. Since some of the routines were either extensively + revised or completely rewritten, I added a set of test programs to + zzdebug.x and tested all the routines. An old bug was found and fixed + in the process: strmatch was not recognizing EOS for an end of line + match ($). This was added to patmatch() a while back, but evidently + I forgot to add it to strmatch too. (3/22) + +pkg/system/directory.x +pkg/system/doc/directory.hlp + The directory lister was reworked extensively to recognize and execute + specially optimized code for the most common cases. The most important + of the low level routines called by the directory program were also + optimized, as noted above. A new "horizontal" (VMS like) file ordering + format was added as an option to supplement the default "vertical" + format. + + In common cases the directory lister is now about 50% faster than + previously. I also determined that there were a couple of cases where + the old program would perform especially poorly. The first case was + when listing very large directories, since the way the old program was + constructed it would always read the entire file list into memory + before formatting the output table. The new "horizontal" format is + provided as an option to address this case. + + The second case where poor performance could result was when listing + very large directories that are stored by the host system in sort order + (as in VMS). The quick sort algorithm used would exhibit quadratic + behavior when sorting an already sorted list, i.e., the sort time + would grow as the number of files squared if the file list was already + sorted. For small directories (less than 100 files) the effect was + not significant, but when listing very large directories this could + be a major effect. + + The latter problem was solved in two ways: [1] the new non-sorting, + "horizontal" listing option avoids the problem entirely, and [2] the + new STRSRT subroutine avoids the quadratic behavior. With the revised + quick sort algorithm, the expense of sorting typically runs only about + 3% of the total run time. + + The pattern matching code was also optimized. Simple "*.xx" style + filename extension templates are recognized as a special case and a + very fast custom inline pattern matching scheme is used in this case. + + The "horizontal" format option is enabled by setting the directory.sort + parameter to NO (the default is YES, which is faster and nicer in most + cases). If sorting is disabled, the task will print the listing out + line by line as files are physically read from the directory, in much + the same way that the VMS directory lister does. In addition, if the + standard output is not redirected the output will be flushed after + every 1 to 4 lines. + + The only significant optimization remaining to be made would be to + move the directory program into the CL process, but provided that the + system is not paging heavily the performance should be fine with the + current process structure, i.e., the directory listing should appear + in few tenths of a second for modest sized listings, even on an 11/750. + (3/22) + +pkg/system/sort.x +pkg/system/sort.par +pkg/system/doc/sort.hlp + Modified the quick sort code in the SORT program to avoid quadratic + behavior on an already sorted list. (3/22) + +sys/etc/qsort.x +sys/vops/asrt.gx + Put the same fixes into these quick sorters. (3/22) + +------------------- +(All systems updated.) (3/22) + +local/notes.v24 [all systems] + Changed the name of the system notes file to notes.v25. Actually, + it contains the notes for both IRAF revisions 2.4 and 2.5. (3/23) + +unix/*/mkpkg +unix/*/mkpkg.csh +unix/hlib/irafuser.csh + Changed the name of all the 'mkpkg.csh' files, used to bootstrap the + UNIX HSI, to 'mkpkg.sh', since they are SH command files. Added system + definable switches HSI_CF and HSI_FF to all calls to compile or link + HSI C or Fortran code, e.g, "cc -c $HSI_CF file.c". These are defined + as environment variables in hlib$irafuser.csh. An additional variable, + HSI_XF, is also defined and is used as XFLAGS in all the HSI mkpkg + files. This feature makes it possible to control the compilation and + linking of all the HSI programs by changing a single file. + + [SUN/IRAF]: I tried to use this new feature to compile the HSI + bootstrap programs for SUN/IRAF with the -mc68010 option, so that + the HSI could be run on the old Sun-2s, but it turns out that this + does not work because all the Sun system libraries were compiled + for the mc68020. Hence, sites with Sun-2s will need to do a bootstrap, + but that is not a big deal. The Sun HSI uses only software floating + point (if it uses any at all), so most sites will not need to do a + bootstrap, although it may be necessary to do a full sysgen. (3/23) + +unix/rmbin.sh + + Added a new shell script to the UNIX HSI, to be used to strip the + binaries from the HSI if the RMBIN task is not runnable for some + reason, e.g., if the binaries were compiled on an incompatible host, + or if the bootstrap is aborted. (3/23) + +------------------ +The standard VMS/IRAF user system (IRAF) updated to V2.5 on draco. (3/23) +V2.5 is now the standard user system at NOAO. + +pkg/cl/gram.c + Changed the trailing "EOF" output by DPARAM to "# EOF" so that naive + programs will ignore it, but it will still be there to mark the end + of the list. This is really just a workaround though; the IPC + mechanism should provide better support for list and array i/o. (3/24) + +pkg/system/directory.x + Fixed a bug in the special case extension matching code which would + cause it to accept a partial match of the extension string, rather + than requiring a full match. (3/25) + +vms/hlib/login.cl + For VMS/IRAF, added a -z to the FC foreign task definition to prevent + use of the IRAF shared library, which is not needed (the IMFORT + interface is layered directly upon the kernel), and which causes name + conflicts. (3/25) + +sys/fio/fwtacc.x +sys/fio/zzdebug.x + Added code to fwtacc (the "waiting for access to file" code) to check + if the maximum number of physical file descriptors for the process has + been exceeded. If this occurs a file open error will occur, returning + errcode = SYS_FTOOMANYFILES to the caller. (3/25) + +sys/imio/imt.x +sys/fio/fntgfn.x + Modified both the image template and file template packages to permit + the input template string to be any arbitrary size. (3/26) + +unix/hlib/stripper +unix/hlib/stripall + Deleted the reference to the cryomap map data file, since the file no + longer exists. Also modified the stripall script to not delete the .h + files in hlib and hlib$libc. (3/26) + +doc/aosvsiraf.hlp + + Added the installation guide for AOS/IRAF (courtesy of Skip Schaller, + Steward Obs.) to the system docs file. (3/26) + +local/tasks/lnews.cl + +local/tasks/local.cl [VMS/IRAF only] +local/tasks/local.men + Added a new task LNEWS to the LOCAL package on VMS/IRAF. This task + uses the IRAF pager to page the local (NOAO) VMS system news file. + Although this can also be done with !news, the IRAF pager is much + more sophisticated, and it works for non-DEC terminals. (3/26) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2uimp.c +unix/gdev/sgidev/sgi2uqms.c + Replaced the #define SWAP_BYTES with code to determine whether + we are running on a byte-swapping machine at runtime. (3/27 SRo) + +------------------------- +Nodes aquila and carina were updated to V2.5. (3/27) +Draco, pavo, tucana, octans updated. (3/28) + +/etc/printcap +/usr/spool/lw + +/local/bin/sgi2uapl + +unix/hlib/sgi2uapl.e + +unix/hlib/sgi2uqms.e + + Installed the Apple laserwriter as an lpr device under UNIX on lyra, + and compiled and installed the appropriate IRAF/SGI translator in + HLIB, with link in /usr/bin. (3/30) + +dev/termcap +dev/graphcap + Added tek 4010 entry, identical to 4012 except that it uses 74 + text columns instead of 75. (3/31 SRo) + +dev/graphcap +dev/termcap + Merged the AOS graphcap and termcap files, contributed by Skip + Schaller, into the lyra graphcap and termcap files. (3/31 SeH) + +pkg/cl/grammar.y + The grammar was not permitting + + switch (xxx) { + case 1: + + ... + + as the newline following the "case 1:" was not allowed for in the + grammar. Modified the grammar to permit the newline. (3/31) + +dev/hosts + Added entries for the three U. of A. nodes, recently added to our + Ethernet (solpl, cti, taurus). (4/1) + +pkg/images/tv/display/iispio.x +pkg/images/tv/display/zsttim.x +pkg/images/tv/cv/iism70/iispio.x + Egad! Found a quite serious bug in the display code which must have + been there quite a while. Probably hasn't shown up because it only + affects display access over the network, and the network was probably + placing enough of a limit on the max transfer size to hide the problem. + The size of the intermediate buffer which is malloc'ed in the IISPIO + code was being calculated improperly. The code was assuming the value + IIS_MAXBUFSIZE to be in units of xchars, whereas it is actually in + units of bytes since it is an FIO parameter. The buffer being + allocated would therefore be too small by a factor of two, causing a + segmentation violation on the Sun. (4/4) + +pkg/images/tv/display/t_display.x + In the call to AMAPS, the z1,z2 etc. arguments, which are supposed to + be of type short, were being passed as short(z1),short(z2), etc. + This ought to work, but coercion to type char or short in SPP argument + lists is not currently supported, and it is easier to just use + temporary variables of type short in the code. (4/4) + +------------------------------- +All systems updated; first version of IMTOOL installed on the Sun systems. +(4/5) + +dev/termcap + Added a missing `=' to the `cl' parameter for the vt640. (4/14 SRo) + +sys/gio/doc/gio.hlp + Updated the GIO documentation; fairly extensive modifications, + accurately describes all recent GIO revisions and fixes many ancient + errors in the documentation. (4/22) + +pkg/language/language.hd +pkg/language/language.men +pkg/language/doc/eparam.hlp +pkg/language/doc/set.hlp +pkg/language/doc/lparam.hlp +pkg/language/doc/dparam.hlp + +pkg/language/doc/edit.hlp +pkg/language/doc/task.hlp +pkg/language/doc/commands.hlp +pkg/language/doc/cursors.hlp + Updated the LANGUAGE package manual pages. (4/23) + +[shared library name collisions] [DISCUSSION] + I did a cross reference of all symbols in the 4 main IRAF libraries + used to build the shared library (sys,ex,vops,os) against all the + other libraries and all the .o and .a files in PKG and NOAO, to + locate any redefinitions of system symbols by applications code. + This was done on UNIX node pavo (using the UNIX tools, of course), + with the following results: + + pkg/cl/cl.o:0000023c T _onenty_ + pkg/images/libpkg.a:shiftlines.o:0000046c T _shifti_ + pkg/images/libpkg.a:shiftlines.o:00000000 T _shifts_ + + These symbols collide with system symbols of the same name; not bad + out of the 5000 or so procedures in the system. The _onenty_ (ONENTRY) + is well understood, and is already allowed for in the shared libraries. + The _shift[is]_ collide with bit shift procedures in OSB, and it + turns out that this problem has already been discovered and fixed in + the master lyra system, so for the moment at least, there are no + name collisions in the system (except possibly between applications + code and the math and tools libraries). (4/23) + +sys/gio/cursor/prpsio.x + Fixed a bug which was causing the OPENWS instruction to be lost when + writing to a GIO subkernel. When the GTRCTRL routine sees OPENWS it + physically connects the kernel and deposits the OPENWS instruction in + the stream spoolfile, but does not flush the metacode to the subkernel + as this would result in a reentrant call to PRPSIO. The bug was that + the PRPSIO routine was unnecessarily cancelling the graphics stream + before calling GIOTR to process input metacode through the workstation + tranformation and depositing the transformed metacode in the stream, + ready to be ready by the subkernel in an XFER request. Logically, it + should only be necessary to cancel the graphics stream once, when the + kernel is connected to a stream, and thereafter only AFTER the reader + has read the data formerly posted to the stream. (4/23) + +sys/imfort/imps3s.x + Fixed a typo; the procedure name was given as 'imps2s', whereas of + course it should have been 'imps3s'. (4/23) + +unix/os/alloc.c + Made a couple of minor changes to the device allocator for system + security reasons. The old program would allow the knowledgeable user + to specify by pathname the files to be allocated. Now only files in + /dev can be allocated, and since /dev is protected the process should + be secure. Furthermore, the old program would allow files to be + allocated to the user regardless of their former permissions, allowing + the user access to raw devices or kernel memory. The new program only + allows device files to be allocated which have world read/write + permissions prior to allocation. (4/23) + +dev/pix.imh +dev/pix.pix + Replaced the old standard test image, dev$pix, by a new picture of M51 + (the whirlpool nebula). The new image is more interesting, and also + has the advantage of being the canonical image size, 512 square (this + was interpolated up from a 508 square CCD frame). The pixel type is + short integer. (4/23) + +sys/imio/imdmap.x + Modified this procedure (used to open a image display as an image file) + to look for a graphcap parameter "z0", used to set the zero point for + the output device pixel range. If the value is not given a zero origin + is assumed. (4/25) + +pkg/images/iminfo/t_imstat.x + Hacked the IMSTAT code to make the inner loop somewhat more efficient, + and to add package prefixes to internal procedure names. (4/25) + +dev/graphcap + Added an entry for the IMTOOL display server. (4/25) + +unix/hlib/irafuser.csh + In the entries HSI_XFLAGS etc., deleted the "-c" flag, as this is + supplied where needed by all the HSI mkpkg.sh files, and it must not + be there unless needed (it can cause an object file to be installed + in the system as an executable, causing myserious runtime problems, + to say the least). (4/25) + +unix/gdev/zfiogd.x [SUN/IRAF] +unix/hlib/mkpkg.sf [SUN/IRAF] +local/sun/iisopn.x [SUN/IRAF] + The current prototype IMTOOL display server on the SUN systems uses + the standard DISPLAY program with very minor changes, in particular, + the file iisopn.x was hacked. To avoid having to modify the portable + part of the system I put the hacked file in local/sun and added the + file to the SUN/IRAF special file list. This is all temporary, + probably the next step will require more significant changes. (4/25) + +dev/termcap [SUN/IRAF] +dev/graphcap [SUN/IRAF] + Updated from Lyra. (4/25) + +---------------------------------- +VMS/IRAF Updated. Full compile of IRAF performed to correct optimizer +problem. (4/25) + +pkg/images/mkpkg [VMS/IRAF, usr$2 only (production system!)] + The mkpkg file had a -x flag in the $link, which someone had obviously + added for debugging and then forgotten to delete. Note that there is + no reason to do such a dangerous thing, since 'mkdebug' is already + available (as a foreign task), and it does the same thing. (4/25) + +vms/hlib/mkpkg.sf [VMS/IRAF] +unix/hlib/mkpkg.sf [VAX UNIX/IRAF] + In the MKPKG special file list, the reference to vops$lz/amov*.x had + to be changed to an explicit series of references amovi.x, amovs.x, + etc., since amov*.x matches the amovk*.x as well. (4/25) + +vms/hlib/mkpkg.inc +vms/hlib/install.com [VMS/IRAF] + Although there is not supposed to be any interaction between the + production iraf system 'IRAF' and 'IRAFX', when the sysgen of IRAFX + completed it turned out that IRAF no longer worked. I eventually + decided that one cannot have more than one version of VMS/IRAF on + the system which uses shared libraries, unless of course they both + use the same identical shared library. Without resorting to reading + the VMS manuals, I think what may be happening is that the shared + library defines a number of global sections which are literally + global. If two different shared libraries define different global + sections with the same names, the one which is actually used at runtime + depends upon the order in which they were installed or something, + hence a completely wrong section may be referenced, causing an + access violation, illegal instruction, or whatever at runtime. + + The solution for the moment is to use the shared libraries only in the + production IRAF system. In IRAFX, I set LFLAGS to "-z" in mkpkg.inc, + causing all the executables to be linked stand alone. I found that + even so much as installing one of the non-shared library linked IRAFX + executables would cause IRAF processes to fail (despite being on + another disk), so at present none of the IRAFX executables are even + installed. (4/26) + +lib/imset.h +sys/imio/imstats.x + + Added a new procedure IMSTATS to IMIO, and a new imstat parameter code + IM_IMAGENAME to . This is used to return the image (section) + name, as passed to IMMAP at image open time. (4/27) + +sys/imfort/doc/imfort.ms + The pathname of the OS library was incorrectly given as "lib$libos.a" + rather than "hlib$libos.a". (4/27) + +local/tasks/mkpkg + Added a '$purge bin$' statement to purge the newly installed x_local.e + executable in bin. (4/27) + +------------------------------- +Archive tapes made for ISI, Masscomp ports. (4/28) + +sys/gio/gtick.gx + Fixed a bug that in a special case (negative axis limits, negative step) + would cause the wrong first tick to be selected. (4/28) + +sys/gio/glabax/glbfind.x + Added protection against INLEFT ever being set to a negative value when + setting up the drawing parmeters for an axis. This should not be + possible, but was happening as a result of the above bug, and would + result in an infinite loop. (4/28) + +------------------------------------------------- +Archive tapes made for SAO Ultrix site (limited disk). (4/29 SRo) + +unix/gdev/sgidev/sgidispatch.c + +unix/gdev/sgidev/mkpkg.sh +unix/hlib/sgi.tab + +dev/graphcap +local/bin/sgidispatch -> hlib$sgidispatch.e + +local/bin/sgi2uimp - +local/bin/sgi2uapl - + Modified the UNIX SGI translator mechanism to require only one link, + sgidispatch, which gets passed the name of the translator from the DD + string in graphcap and locates its pathname from the sgi.tab file. + This simplifies device installation in UNIX and no longer requires + one to remember which systems require which links in /local/bin. + (4/29 SRo) + +----------------------------------- +Updated {IRAFX,IRAF}@draco, tucana. (4/30) + +---------------------------------- +Updated gll1 Ultrix/IRAF (5/1 SRo) + +lib/scr/implot.key + Implot was exhibiting different behaviour on draco from lyra when + requesting task help with `?'; the implot.key file on draco had a + more recent file date and had one fewer screen line (22 rather than + 23, the latter a blank line). Since the user of a 23-line terminal + experiences one less keystroke with a 22-line help page, the lyra + version was edited to match that on draco. (5/8 SRo) + +sys/imfort/imakwd.x + Fixed a typo; the comment string was being unpacked into the keyword + name string, overwriting it, with the actual comment string never + being initialized. (5/15) + +unix/boot/generic/chario.c + +unix/boot/generic/lexyy.c +unix/boot/generic/mkpkg.sh (VMS generic preprocessor bug) +unix/boot/generic/generic.c +unix/boot/generic/lex.sed + The $for ... $endfor construct was not working in the VMS version of + the GENERIC utility due to the old FSEEK bug in the VMS C compiler, + which I ran into back when MKPKG was developed. I ended up developing + a set of routines k_getc, k_fseek, etc., to get around this problem + in MKPKG; the code for these was copied to file chario.c, and the + other files modified to make use of the new routines instead of calling + the C library routines directly. (5/16) + +vms/boot/generic/chario.c + +vms/boot/generic/lexyy.c +vms/boot/generic/mkpkg.com +vms/boot/generic/generic.c + Updated the VMS version of GENERIC. (5/16) + +sys/etc/maideh.x + Changed the default action for an arithmetic exception to a fatal error + (causing task termination), like the other classes of exceptions. + There is no way an arithmetic exception can be caught and handled + in an IFERR reliably anyhow, due to limitations on the semantics of + ZXWHEN imposed by different host systems. An arithmetic exception + occurring within an IFERR could lead to an infinite loop on some + systems. (5/17) + +sys/imio/db/idbgstr.x +sys/imio/db/idbpstr.x +sys/imio/db/imgftype.x + Modified so that the "i_" prefix is optional, to be consistent with + idb_kwlookup(). (5/17) + +sys/imio/db/imgftype.x + Changed the "if (numeric)" at the end to "if (!numeric)". (5/17) + +dev/vi.ed + Made various changes to this file so that either or + can be used to exit from EPARAM when editor=vi. (5/18) + +pkg/cl/eparam.c + Made minor changes, deleting a few redundant fflush() calls (reduced to + only one per output line) to speed things up a trifle. (5/18) + +pkg/bench/bench.hlp + Updated the document, adding/deleting a few paragraphs here and there, + fixing some erroneous pathnames, and so on. Still need to update the + actual benchmarks section. (5/19) + +sys/ki/irafks.x + Fixed several bugs in the (never before used) device allocation and + remote magtape access code. These bugs were found when the KI was + used (at Steward Obs.) to access magtape devices on a Data General + MV/10000 from IRAF programs on a Sun workstation. (5/20) + +unix/os/gmttolst.c + Fixed a bug in the way daylight savings time was calculated. (5/20) + +unix/os/mkpkg +unix/os/net/mkpkg +unix/boot/bootlib/mkpkg +unix/boot/mkpkg/mkpkg + Changed the '$set XFLAGS = "$(HSI_XC)"' definitions in these files to + '$set XFLAGS = "-c $(HSI_XC)"', since the definition of HSI_XC in + hlib$irafuser.csh no longer includes the -c (since it is used to make + executables as well as compile objects). (5/21) + +unix/os/zfacss.c + Modified the heuristic used to discriminate between text and binary + files to increase the amount of file data inspected, and to require + the presence of newline characters in text data for the file to be + considered a text file. This is required to discriminate between + text files and binary files containing text, e.g., card image files + or FITS files. (5/21) + + [The VMS version of this routine does not use the heuristic, since VMS + [makes a distinction between text and binary files at the host system + [level, hence did not have to be modified. + +unix/os/zfioks.c +unix/os/net/zfioks.c +vms/os/net/zfioks.c + Modified the code which parses the .irafhosts file to permit arbitrary + characters (other than just alphanumerics and underscores) in whitespace + delimited tokens, e.g., host names, login names, and passwords. (5/21) + + [Ran a test and verified that node names (and presumably also login + [names and passwords) may contain arbitrary characters such as '-'. + +sys/fmtio/parg.x + Added some errchk declarations to PARGG. (5/21) + +sys/imio/db/idbkwlu.x +sys/imfort/db/idbkwlu.x + This code was permitting abbreviations of the standard keywords; + modified to require a full match. (5/21) + +sys/etc/oscmd.x + This routine was not recognizing dev$null as an output file, causing + foreign tasks executed with their output redirected to the null file + (e.g., "mkpkg >& dev$null") to do a physical file write. To avoid + having to mess with null files at the ZOSCMD level, I set the routine + up to spool the output into a temporary file, deleting the file at + the end to dispose of the output. (5/22) + +sys/gio/stdgraph/stginit.x + Added a check for the capability "tx", used to indicate whether or + not the device implements text generation in hardware. If the + capability is not defined, the kernel will now set software character + generation automatically. (5/22) + +sys/ki/irafks.x + Fixed a typo in the kernel server code for ZFRNAM (the file rename + primitive). The first filename was being used twice, ignoring the + second filename and causing the rename to be a no-op. (5/22) + +unix/boot/mkpkg/host.c + Modified the h_direq() function, used to compare to host directory + pathnames for equality, to ignore everything to the left of the + "iraf/", if both strings contains such a substring. This was necessary + for VMS, and now it turns out to be necessary for UNIX too. The + problem occurs when a UNIX directory name like "/usr" is a symbolic + link to some other directory. Directory pathnames will appear to be + rooted off "/usr" in MKPKG, but the get-cwd primitive will always + return the physical pathname, causing the directory comparison to fail + when it shouldn't. This happens on our Sun systems currently when + a fileserver system accesses the same version of IRAF as the primary + system, e.g., because the physical directory name is "/usr.MC68020" + but appears as "/usr" in all the IRAF files. Replacing the "/usr" in + the IRAF files (.login etc.) did not solve the problem, as the + physical directory name was "/usr" on the diskless node. (5/24) + +unix/boot/mkpkg/pkg.c +unix/boot/mkpkg/tok.c +unix/boot/mkpkg/host.c + If a file was checked out of a remote directory which had the same name + as a file in the local directory, the local file would be deleted and + replaced by the checked out file, and the latter would be deleted when + the update finished. This is appropriate for checking out libraries, + but not for checking out source files on the special file list, as this + could result in the standard source file being deleted if the file was + on the special file list. Modified h_outcheck and h_incheck to add + a "clobber" parameter to h_outcheck noting whether any local copy is + to be clobbered or preserved, with the extension ".cko" being added to + the local file if the file is to be preserved. At checkin time, if the + pointer to the remote directory name is NULL the file is not actually + checked back in, rather the local copy is deleted, renaming the .cko + file, if present, back to its orignal name. (5/25) + +vms/boot/mkpkg/pkg.c +vms/boot/mkpkg/tok.c +vms/boot/mkpkg/host.c + Merged above bug fix into the VMS version of mkpkg. (5/25) + +sys/ki/kzopmt.x + Was calling ki_getchan() to assign a channel slot even if the kernel + open procedure returned ERR, causing the high level open procedure to + fail to see the open failure. (5/25) + +sys/fio/fseti.x + To the F_VALIDATE case, added an assignment into field FNBYTES of the + FIO file descriptor, so that a fstati(fd,F_SBBLK) will return the + validated record size in bytes. (5/25) + +unix/os/zfiomt.c +vms/os/zfiomt.c + For technical reasons (reliable detection of EOT) when positioning to + a file, files are skipped by executing a record skip forward followed + by a file skip forward for each file to be skipped. If a read/parity + error occurred while doing the skip record on the first record of a + file, the driver would formerly abort the file open. Since the record + skip is followed by a file skip it is probably harmless, so the driver + was changed to print a warning message, ignore the error, and proceed + with the file skip. (5/25) + +unix/os/zmaloc.c + Restored the source for the old 4.1BSD memory allocator. This will be + used in place of the host system memory allocator (malloc,free,realloc) + if any of the following are defined (in ): DEBUGMEM, BSD42, + BSD43. It turns out that the memory allocator used in 4.[23]BSD, + while undoubtedly a very fast allocator for applications using zillions + of very small buffers, utilizes storage extremely inefficiently in + applications which use a few possibly very large buffers. + + The old allocator used a circular list allocation scheme which could + be very time (and working set) inefficient for applications with + zillions of small buffers, but which would allocate no more space than + needed and would reclaim, join, and reuse freed buffers efficiently. + The new allocator is time efficient but requires that storage be + allocated internally in units of 2**N bytes, allowing freed buffers + to be reused but not changed in size. This could lead to gross + inefficiencies when allocating large buffers, e.g., the actual space + allocated might be twice as large as what is needed, and once the + space was allocated the no-resize restriction would prevent it being + used again for a large number of small buffers. + + Note that use of a non-standard memory allocator may not be possible + on some UNIX systems, because applications may link with modules in + host libraries which assume the existence of a different (host system) + memory allocator with special properties. Unless there is good reason + to do otherwise, the memory allocator provided should only be used with + 4.[23]BSD systems. (5/26) + +dev/devices [UNIX,VMS] +sys/etc/xgdevlist.x +sys/etc/xalloc.x +sys/mtio/mtio.h +sys/mtio/mtopen.x +sys/mtio/mtosdev.x +sys/mtio/mtrewind.x +sys/mtio/zsttmt.x + Added an optional new parmeter to the entry for a device in the + dev$devices file. The new parameter, if present, specifies the + max transfer size for the device, or the maximum record size for + magtape devices. If the parameter is not present MTIO will indicate + to FIO that there is no max record size, leaving it up to the + application to determine the actual record size to be used. + + Old dev$devices syntax: + + device device_driver_text + + New syntax: + + device [%NNNN] device_driver_text + + e.g., + + mta.1600 %8192 nrmt8 mt0 mt4 ... + + The % notation was used to make the parameter optional, making the + change upwards compatible with the existing device tables. (5/26) + +sys/vops/alui.gx + This vector operator (lookup and interpolate) is not supposed to do + bounds checking, but this sets a subtle trap as the case X = exactly + NPIX will cause a reference one pixel off the right end of the input + array. Even though the out of bounds pixel value is only multiplied + by zero, this can cause an arithmetic error as the garbage pixel can + have any value. To detect and avoid this case, and also speed up the + case where the interpolation points are integral, I added a check to + see if the fractional offset from the leftmost pixel of an interval + is near zero, using the value of the leftmost pixel directly without + interpolation in this case. Note that the routine still does not do + actual bounds checking. (5/26-27) + +unix/as/aluis.s +unix/as/aluir.s +unix/hlib/mkpkg.sf + This change obsoletes the VAX-optimized assembler versions of these + routines. The UNIX f77 compiler is now good enough that we do not + need the hand optimized routines anyhow, so I commented out the entries + for them in the mkpkg.sf file. The assembler sources will be kept + around for a while with [OBSOLETE] comments in the code. These + routines are not optimized in assembler on any other system. (5/27) + +------------------------ +Updated IRAFX, tucana/pavo. (5/26) + +unix/os/zfiomt.c + If the drive is opened with newfile=0, the tape will not be moved. + The VMS/IRAF version of the magtape driver was already set up this + way. (5/27) + +sys/mtio/mtopen.x +sys/mtio/mtrdlock.x +sys/mtio/mtparse.x + If a tape is opened explicitly to file zero, e.g., "mta[0]", MTIO will + now try to open the drive without moving the tape, by ignoring the + information in the .lok file, and by calling the kernel driver with + newfile=0. Since the actual file position is unknown, the tape is + arbitrarily assumed to be at file=1, record=1 following the open. + + NOTE that this feature may not be implemented, or be implementable, + on all systems. The intended use of the feature is to allow recovery + of bad tapes which cannot ordinarily be read by the portable IRAF + readers, by using a host dependent utility to manually position the + drive, which is then opened at file "[0]" and read without being moved. + (5/27) + +sys/mtio/mtopen.x + When writing to a tape, a warning message is now printed if the record + size (FIO buffer size) requested in a MTOPEN call exceeds the maximum + record size (F_MAXBUFSIZE) for the device. Nothing is done on a read + since it is routine to open tape devices with a very large input + buffer, to accomodate arbitrarily large records. Reader programs + which must be able to read or write a certain size record may wish + to check F_MAXBUFSIZE themselves (any time after the MTOPEN). (5/27) + +sys/fio/read.x + READ is not supposed to read more than one record at a time when + reading from a streaming (record structured) device. This would + always work previously because we sized the buffer to be larger + than the largest possible device record. If a max record size + parameter is now defined for the device, however, the FIO buffer + will be set to the size of the max transfer permitted for the + device. This case was not being recognized, causing READ to read + lots of physical device records to satisfy a large logical read + request, if the FIO buffer size happened to be exactly the same as + the device block size. (5/27) + + [All MTIO, dev$devices file revisions were tested, 5/27] + +sys/imio/iki/stf/stfmerge.x + When a new parameter is merged into the GPB of a new copy image, the + STF_PSIZE and STF_SZGROUP fields of the GPB descriptor for the new + image are now updated, along with STF_PCOUNT. This bug was fixed + originally by STScI; the original fix appeared to be using + P_PSIZE(n_pp) before it was being set, so I made the fix slightly + differently, and this should be tested. (5/28) + +sys/imio/iki/stf/stfopix.x + The WCS data structure will not be copied (call stf_copywcs()) if + the pointer o_im (old image, e.g., for a NEW_COPY operation) is null. + (5/28) + +pkg/images/imdebug/mktest.x + Modified the make-test-image program slightly to avoid integer + overflow when creating a short integer test image. (5/28) + +pkg/images/imdebug/mkimage.x + Made a minor change to avoid a possible char/int argument mismatch + problem (no bug ever actually observed). (5/28) + +pkg/cl/builtin.c + Modified the code for Keep to search back down the call stack to find + the earliest task reading command input from the same place as the + task which called Keep, then execute "keep" for every task back to + that point (unless the task calling Keep is reading commands from + stdin). Formerly only the context of the tasking calling Keep would + be preserved. + + With this change, ***** IT IS NOW PERMISSIBLE TO PERMANENTLY LOAD + PACKAGES FROM WITHIN A SCRIPT, E.G., THE LOGIN.CL FILE *****. (5/28) + +unix/hlib/login.cl +vms/hlib/login.cl + A [commented out - 5/29] command to load the NOAO package at login + time was added to the default LOGIN.CL file (NOAO also loads PLOT and + IMAGES). A comment was added to tell users how to list additional + packages to be loaded at login time. It is expected that users will + personalize the set of packages to be loaded at login time, and that + system installers will modify the default LOGIN.CL to load whatever + standard and local packages are in common use at their site. Note + that packages loaded in this way can only be discarded by logging out. + (5/28) + +--------------------------- +Updated IRAFX, tucana+pavo. (5/28) + +unix/os/zfiotx.c + If a process (e.g., the CL) is suspended while the terminal driver is + set for raw mode, the terminal driver will now be restored to normal + mode while the process is suspended. Note that only the state of the + terminal driver is affected, not the state of the terminal itself, + e.g., reverse video highlighting will not be automatically cleared if + in effect when a process is suspended. (5/29) + + [Although this feature will prove useful to expert users, it is + [essential on Berkeley UNIX systems to avoid leaving the terminal + [in raw mode with no echo if the novice user accidentally types the + [suspend process control code. + +lib/fio.h +lib/fset.h +unix/hlib/libc/fset.h +sys/fio/fseti.x +unix/os/zfiotx.c + Added a new terminal driver and FSET option named F_SETREDRAW. + The statement + + call fseti (STDIN, F_SETREDRAW, ch) + + will cause the terminal driver to return 'ch' (integer!) as the + value of any pending GETC when a temporarily suspended process + resumes execution. The intention is that screen oriented applications + programs such as EPARAM, PAGE, etc., will make such a call to enable + transmission of their screen redraw keystroke (ctrl/l, ctrl/r, etc.). + This will be returned to the application if the process is suspended + while awating input in raw mode, causing the screen to be automatically + redrawn when the process resumes execution without the user having to + manually type the redraw character. Programs which make use of this + feature should call FSETI twice, once at the beginning to enable the + automatic redraw, and once at the end with ch=0 to disable the feature, + as other programs may not be prepared to deal with the unexpected + input. (5/29) + +sys/etc/xisatty.x + This routine is called to determine if a text stream is connected to a + terminal rather than a text file. Added logic to return yes (is a tty) + if the file is standard stream, the stream has not been redirected, + and the process is running as a connected subprocess. In this case + the stream is highly likely to be connected to a terminal in the CL + process, and transmission of terminal driver control sequences (like + F_SETREDRAW and F_RAW) is a reasonable thing to do. (5/29) + +sys/etc/pagefiles.x +pkg/system/help/houtput.x + Added calls to set F_SETREDRAW to these routines, which call CLGKEY + to read keystrokes from the terminal in raw mode. The pager can be + suspended and restarted with full recovery; HELP does not (yet) buffer + previously displayed text, so the redraw action is temporarily set + to cause the next page of help text to be displayed. (5/29) + +pkg/cl/edcap.c +pkg/cl/eparam.c + In EDCAP, routines edtinit/edtexit (called upon entry and exit from + a screen routine to initialize the terminal), added calls to + F_SETREDRAW to enable the redraw keystroke defined in the dev$*.ed + file for the user's favorite editor. In EPARAM, deleted countless + calls to e_ctrl to set/clear standout mode, and replaced them by a + few calls to set standout mode only when text needs to be drawn in + standout mode. The original code was leaving the terminal in standout + mode most of the time and only restoring normal mode when drawing + normal text, causing the terminal to be left in standout mode if the + CL was suspended (the new code is also simpler and more efficient). + (5/29) + +---------------------------- +Deleted all machine independent files on IRAFX and tucana and started a full +recompile sysgen on both systems, to get rid of any junk files left by the +incremental updates, and to ensure that everything still compiles. (5/29) + +unix/boot/mkpkg +unix/boot/mkpkg.hlp +unix/boot/scanlib.c +unix/boot/main.c +unix/boot/pkg.c +unix/boot/extern.h + Merged the revisions for the '-u' option (forcibly update library + module dates) into the master version of MKPKG. This option, currently + fully implemented on AOSVS/IRAF, causes the dates of all library + modules looked at during a mkpkg run to be updated to be no older than + the file "hlib$iraf.h", which is assumed to have been "touched" after + system installation to mark the system installation time. This option + is needed on systems like AOS/VS which cannot restore the modify dates + of source files; when the system is installed on such a system, all + files will appear to MKPKG to have been modified at system installation + time. Updating the library module dates to a time shortly after the + system was installed prevents recompilation of the entire system, + without interfering with the ability of MKPKG to detect changes to + files which have been modified since the system was installed, which + should force recompilation. (5/31) + +vms/boot/mkpkg + Updated the machine independent files changed in the above revision. + (5/31) + +sys/ki/ktzsek.x + Modified to mark the internal KI text data cache empty when a seek + occurs on a file, so that the next read will force the buffer to be + refilled at the new file offset. This was the reason why randomly + paging a file over the network was not working properly. (5/31) + +sys/imio/imioff.x + Changed the code which checks the value of 'ndim' to allow opening + images with ndim=0, i.e., a header file with no pixels. (5/31) + +sys/osb/f77upk.f + Changed the "lastch=nchars" to "lastch=0" so that a blank f77 string + would be returned as an SPP null string (the routine is supposed to + trim blank padding at the right). (5/31) + +sys/osb/f77pak.f + This routine was not blank padding to the full length (len(str)) of + the Fortran string, as the F77 standard requires. (5/31) + + [Carefully tested, 6/2] + +unix/boot/generic/generic.c +vms/boot/generic/generic.c + In the code for outstr(), replaced the call to fprintf() by a call to + fputs(). There was no evident reason to use fprintf, and if the string + being output contained any % characters it would be mangled. (5/31) + +vms/os/net/zfioks_obj.dna + + This file is the zfioks.obj (binary object file) of zfioks.c, + configured for DECNET. A precompiled version of the file is provided + so that sites which do not have a C compiler can reconfigure the + IRAF network software for DECNET. (5/31) + +--------------------- +Updated all systems. (5/31) +Deleted the standard production VMS/IRAF system on draco (IRAF), and installed +the "final" V2.5 system (more bug fixes are sure to follow during testing). +(5/31) + +sys/gio/ncarutil/*.f + On the request of UCAR, we added a 12 line copyright banner to the + header of each Fortran source file. (6/1) + +sys/mtio/mtcache.x + Fix a bug which could cause the tape position cache to still be + considered valid following an error abort during a tape operation, + which is supposed to render the tape position undefined. The mt_sync + procedure will now invalidate the entire cache if called during + error recovery. In the process of fixing this I changed the file + number used to indicate an undefined position from 0 to -1. (6/1-2) + +vms/hlib/login.cl + 1. Added a $(1) argument reference to the foreign task definition for + vdir (the interface to the VMS directory lister), to allow use of the + routine with IRAF logical directory pathnames, and to give the user + a more sophisticated example of the foreign task syntax. + 2. Added a new foreign task VFILE (with a $(1) filename reference to + permit use of IRAF virtual filenames) to allow use of the VMS command + DUMP/HEADER to examine in detail the header of VMS files. (6/2) + +vms/* [lyra] + Updated the copy of the VMS HSI maintained on lyra. (6/3) + +sys/imio/db/imaddf.x + In the course of testing the error recovery that occurs when the user + area of the image header overflows, found and fixed a minor bug in + this routine. The max size of the user area was off by one SU hence + the descriptor buffer could be overwritten if overflow of the user + area occurred. Also, the use of F_CANCEL to cancel the string buffer + if overflow occurred seemed questionable and obscure and was removed. + This appeared to have been put in originally because a CLOSE on a + string buffer which had overflowed would cause an error in the STRCLOSE + (see below). (6/3) + +sys/fio/stropen.x + In STRCLOSE, replaced the putci(fd,EOS) by an explicit assignment to + avoid a possible error condition. If a string buffer of length N chars + overflows during a write, the EOS will be written into char N+1, in + accord with the usual SPP stringop semantics. (6/3) + +sys/imio/imunmap.x + This routine contained a section of code to compute the value of + IM_HDRLEN which was redundant with the equivalent section of code + in oif/oifupdhdr.x, and irrelevant in the STF kernel. Since this is + an expensive operation for images with large headers, I removed the + code. (6/3) + +------------------------------------- +Updated all systems. (6/3) +Kitt Peak 4-Meter system updated; full SUN/IRAF system recompiled for -ffpa. + (6/4) + +unix/boot/mkpkg/modlist.c.NU + + Added a copy of the library module list filename/date database file + from ASOVS/IRAF to the UNIX mkpkg, with a NU (not-unix) suffix to + indicate that it is not an active file. Although not used for UNIX, + this code is machine independent and hence it is probably worthwhile + to maintain the source in the master system. (6/5) + +local/Gterm.install [SUN/IRAF] + Added additional user oriented documentation to the installation notes + for the GTERM and IMTOOL Sunview tools. (6/5) + +sys/vops/ak/mkpkg +sys/vops/ak/apow*.x + Deleted a set of APOW files in the AK subdirectory. These were not + supposed to be there, as the real sources are maintained in LZ. (6/7) + +---------------------- +Updated all systems. (6/14) + +unix/gdev/sgidev/sgi2uimp.c [lyra] +vms/gdev/sgidev/sgi2vimp.for [irafx] +vms/hlib/sgiqueue.com [irafx] + Added "prerasterization on" to Impress document header in both + SGI translators, and removed it from IMPRINT command in VMS + (sgiqueue.com). Formerly this was done only in VMS, for the 300dpi + imagen, in IMPRINT. A recent experience at AT&T on a UNIX 11/785 + running a 300dpi Imagen showed that prerasterization is a builtin + function of the Imprint engine, rather than a separate VMS IMPRINT + task option. (6/17 SRo) + +sys/etc/errget.x + Replaced the call to strcpy, used to return the error message string + in the xer common to the caller, by a call to xer_fmterrmsg. + The latter will expand error message encoded as "XXX opstr" into + the more readable format, using the system error message in the + lib$syserrmsg file. I discovered this when testing the cursor mode + ":.snap" with garbage device names; everthing was working correctly, + i.e., the error was being detected and recovered from properly, but + the error message being printed was just a number, similar to what + :.snap prints when it is working correctly, possibly causing the + error to go unnoticed. (6/17) + +unix/hlib/install + + Added an INSTALL script for UNIX/IRAF. Starting with the system read + into an $iraf directory somewhere, and an $iraf account, this completes + the basic installation, modifying pathnames in all the necessary files, + and installing all the necessary symbolic links in UNIX land. It can + also be run anytime after the initial installation to verify that all + is ok. The user must still configure the device tables, default + login.cl, and so on, but the system should run once the tape has been + read in and the INSTALL script run, assuming the binaries are + compatible with the local host (not necessarily true for SUN/IRAF). + (6/17) + + Added a SUN/IRAF version of the script, identical to the UNIX/IRAF + version except for some extra stuff at the end to do the custom + suntools installation. (6/18) + +sys/gio/cursor/grccmd.x +sys/gio/cursor/grcopen.x +sys/gio/cursor/gtropenws.x +sys/gio/cursor/gtrreset.x + 1. In gtropenws.x, rearranged the statements which shut down the old + kernel and open a new one. There was a problem with error recovery + the way the code was originally. The code would partially close down + the old kernel and then abort if an unknown device name were entered + in :.snap. The abort, causing an immediate exit from the routine, + of course, would cause the data structures to indicate that the old + kernel was still connected, when in fact it had been partially shut + down. This was causing a segmentation violation or other error when + a valid snap was entered after a failed snap. + 2. In gtrreset.x, updated the code which closes down the old kernel + to be like the equivalent code in gtropenws.x. In particular, the + graphcap descriptor was not getting closed off in a reset, e.g., when + doing a GFLUSH. This was harmless, but would leave an unused malloc-ed + buffer behind which would never be freed. + 3. In grccmd.x, added a "- done" message to the :.snap code, to + indicate that the snap has completed successfully. + 4. In grcopen.x, fixed a grammatical error in a comment. (6/18) + +lib/syserr.h +lib/syserrmsg +sys/tty/ttyindex.x + Added a system error code/message SYS_TTYINVDES ("invalid or null tty + descriptor") and a check for a null descriptor to the tty_find_cap* + procedure, called by all ttyget* procedures. This will avoid a + segmentation violation in the future if a ttyget routine is called + with a null descriptor. (6/18) + +--------------------------- +Updated tucana, irafx@draco. (6/18) + +unix/hlib/mkiraf.csh + Removed the trailing '/' from the 'set iraf = /iraf/'. This is not + needed and has confused people. (6/19) + +unix/hlib/install + This is to document the use of the INSTALL script, used to install + UNIX/IRAF on a UNIX host. + + The install script is used + + [1] During the initial installation, to automatically modify those + iraf configuration files containing pathnames, and to make all + the necessary links in UNIX land to get IRAF to run. + + [2] After the initial installation, to verify that the system is + still correctly installed. The script will examine all the + files and links to verify that each is correct and still in + place. This may be necessary, for example, after UNIX itself + has been updated, which may cause the IRAF links to be lost. + + The installation procedure for UNIX/IRAF is greatly simplified by the + install script. To install the system from scratch: + + [1] Create an account for user 'iraf', with a root directory such + as /usr/iraf, and a login directory such as /usr/iraf/local + ($iraf = /usr/iraf, $home = /usr/iraf/local). The actual + pathname is arbitrary but should be kept as short as possible + to speed up runtime pathname resolution. + + [2] Login as 'iraf', cd to $iraf, and read in the distribution + tar tape or tapes, e.g., tar -xpf /dev/nrmtXX. + + [3] Cd to $iraf/unix/hlib, become superuser, and type 'install'. + To get a default installation, just hit return to accept the + prompted response to each query. To see what the script will + do without actually doing anything, run 'install -n' once + before running it for real. + + [4] The install script may have modified the .login file, so login + again, and do a 'mkiraf' to initialize the IRAF runtime + environment for user 'iraf', then 'cl' to run IRAF. + + That is all that is necessary for the basic installation of a binary + distribution. It will still be necessary to manually modify the device + tables in hlib and dev, interface any local terminals, printers, + plotters, etc., as described in the installation guide. (6/19) + +gdev/sgidev/sgi2vln03.c + [VMS] +gdev/sgidev/mkpkg.com [VMS] + Added DEC C sgi translator for the ln03+ in Tektronix (extended + addressing) mode. (6/24 SRo) + +vms/gdev/iism70/m70.h +vms/gdev/iism75/m75.h + Changed the value of IIS_MAXBUFSIZE from 16384 to ((32768-512)/2), + i.e., 16384-256. This was necessary to avoid having sign extension + when converting from long to short and back to long from promoting + 16384*2=32768 to a negative number. This would happen when doing i/o + to the IIS on the local node on VMS, since byte packing is not used + and the byte count is 32768 rather than 16384. (6/24) + +sys/gio/ncarutil/sysint/support.f + In subroutines ENCODE and ENCD, the declaration of a dummy array was + changed from character*11 to character*(*). When these subroutines + were called with an argument of fewer than 11 characters, memory was + inadvertently being overwritten. (6/24 SHJ) + +pkg/cl/lists.c + Modified scanlist() to permit comments and blank lines in formatted + lists, e.g., all but simple string or struct type (unformatted) lists. + This permits cursor or filename lists, for example, to have embedded + blank lines or comments without affecting the operation of programs + which read these lists. (6/25) + +unix/hlib/install + 1. Modified to remove any trailing / from the old 'iraf' and 'imdir' + pathnames present in the existing system sources (taken from the + mkiraf.csh file). These strings are used as input to SED pattern + matching, and if the trailing / is included but is not present in + the substitution string, it will be omitted from the output string. + The strategy for trailing slashes in INSTALL is that everything in + INSTALL is done according to UNIX conventions (no trailing slashes), + but if the trailing slashes are present in the files being edited + they are retained. This hides this issue from the user and preserves + the trailing slashes where they are needed in the IRAF system + configuration files. + 2. For the SUN/IRAF version of the INSTALL script, added some code + at the end to check that there are entries for devices 'gterm' and + 'imtool' in the termcap and graphcap files. (6/25) + +pkg/images/tv/display/iisrd.x +pkg/images/tv/display/iiswr.x +pkg/images/tv/cv/iism70/iisrd.x +pkg/images/tv/cv/iism70/iiswr.x + The recent change to the FIO buffer size used in the display code + lead to a problem, as the buffer size chosen did not fit into the + display frame an integral number of times. This was causing a problem + as the last write, at the end of the frame buffer, would overflow + causing garbage to be written to the display. I could have worked + around the problem by simply halving the buffer size to 8192, but the + larger buffer is more efficient and code which runs off the end of the + display is not very robust, so I added clipping to the above routines + instead. (6/27) + +sys/gio/cursor/giotr.x +sys/gio/cursor/gtrctrl.x + Changed the AMOVI calls used in these routines to move the WCS + structure to AMOVS calls. The former code should have been ok since + the array references get turned into byte or word addresses in the + procedure call, but a site reported a portability problem so I + converted all array references and the procedure call to type short. + (6/27) + +sys/tty/ttyputl.x + The formfeed handling code was not breaking lines properly when the + formfeed occurred as the first character in a line and the device had + the 'am' (automargin) capability. An extra newline would be output + followed by the formfeed. When printing a large file containing + several pages of text delimited by formfeeds, this would effectively + add a line of text to each page, potentially causing page overflow + (output of a blank page) on the output device. (6/27) + +---------------------------- +Updated all systems. (6/27) + +dev/termcap +dev/graphcap [VMS/IRAF] + Merged in latest stuff from lyra. (6/27) + +dev/cacheg.dat +dev/cachet.dat + Rebuilt these files to make sure they were up to date. (6/27) + +vms/boot/spp/rpp/ratlibc/readf.c +vms/boot/spp/rpp/ratlibc/writef.c + ---------------------------------------------------------------------- + Deleted all binaries from the VMS directories and did a full bootstrap. + ---------------------------------------------------------------------- + Unfortunately, a new DEC C compiler was installed recently and there + were minor problems. + + 1. In vms/boot/mkpkg, trying to compile XCSUB.C, I got the following + message: + + $ cc/nolist host.c,modlist.c,scanlib.c,xcsub.c + # include fab + %CC-F-LIBLOOKUP, "fab" was not found in any of the specified\ + libraries. + At line number 4 in SYS$COMMON:[SYSLIB]RMS.H;4. + + The problem went away when I compiled the file interactively. + Probably some sort of quota problem, or a bug in the VMS software. + UNRESOLVED. MKPKG came up when I compiled it interactively, so I + will ignore this one for now. + + 2. In vms/boot/spp/rpp/ratlibc, files READF.C, WRITEF.C, got messages + such as (for both fread() and fwrite()): + + $ cc/nolist readf.c + unsigned fread(), count; + %CC-W-CONFLICTDECL, This declaration of "fread" conflicts + with a previous declaration of the same name. + + This was a reasonable warning message; edited the two file to delete + the unnecessary function declarations. + + With these changes I appeared to have a successful bootstrap of all + the latest software. (6/27) + +vms/os/mkpkg.com + ---------------------------------------------------------------------- + Rebuilt the VMS HSI - 'IRAF' system. + ---------------------------------------------------------------------- + To make life even more difficult, I next deleted all the VMS files + in 'IRAF' (USR$2) and moved a copy of the new VMS HSI over from the + 'IRAFX' system. Only the IRAFUSER.COM and MOTD files had to be edited + to install the new copy. + + Next, since LIBOS had been completely rebuilt I attempted to rebuild + the IRAF shared library. This failed with lots of error messages + complaining that _MCSUB was not found. This turned out to be due to + the lack of an entry for MCSUB.C in the MKPKG.COM bootstrap-the-os + file, so I added one and all was well. (6/27) + +--------------- +Standard VMS/IRAF ('IRAF') now up to date. (6/27) + +sys/vops/ahiv.gx + Was computing the minimum rather than the maximum value of the array. + This operator has not been used up until now, obviously. (6/28) + +sys/fmtio/dtoc3.x + This routine would use a 'D' rather than an 'E' for exponential format + when the number being output exceeded single precision. Changed it to + always output an 'E'. (6/29) + +sys/imio/iki/stf/mkpkg +sys/imio/iki/stf/stfordgpb.x - + Deleted this file and its entry in mkpkg, since the routine therein + is no longer used and is not likely to be used ever again. (6/29) + + +sys/imio/iki/stf/stf.h +sys/imio/iki/stf/stfwfits.x +sys/imio/iki/stf/stfreblk.x +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfordgpb.x +sys/imio/iki/stf/stfopix.x +sys/imio/iki/stf/stfopen.x +sys/imio/iki/stf/stfnewim.x +sys/imio/iki/stf/stfmerge.x + Merged in the new versions of these files, developed by Dave Ball at + STScI. Changes were made to stfmerge.x and stfnewim.x, other than + that the code was kept pretty much as is. + + 1. The principal change was to allow the STF interface to read and + write images in datatypes other than real. In general, the datatype + of the input image is now preserved, whereas before it was being + forced to type real, since the STF image format is used for SDAS, + and the old SDAS software could only be used with type real images. + Since the new SDAS software is being layered upon the VOS this + restriction is no longer needed. + + 2. As far as possible, the order of group parameters is preserved when + making a new copy image. (6/29) + +vms/os/net/kutil.c + A bug in this routine was causing the characters "rA" to be printed on + a new line, after entering the password for a remote node when + establishing a network connection. The values of the variable 'nchars' + was not being set before the final call to ZPUTTY, causing extra + characters to be sent to the terminal. (7/1) + +unix/hlib/install + The INSTALL script how checks for the existence of the executable files + in HLIB (mkiraf.csh, mkmlist.csh, rmbin.e, xc.e, etc.) and verifies + that they have the correct file permissions, in particular, execute + permission for everyone. When restoring files from tape, or copying + files from one computer to another, it is possible to lose the file + permissions. (7/1) + +local/.login + 1. Deleted the 'users', since this command is not available on Ultrix. + 2. Changed the name of the 'page' alias to 'pg', to avoid modifying the + behavior of a standard command, and because the referenced local + command 'less' is not available in standard UNIX. (7/1) + +---------------------------- +All systems updated. (7/1) + +sys/imio/iki/ikiopen.x + When creating a new "clustered" (group) image, this routine has a built + in restriction that the cluster index must be 1, e.g., newim[1/10] to + write to image 1 of a new cluster-image containing 10 images. People + have complained about the restriction to writing to image [1], so I + am looking at the file to see if the restriction can be lifted. + + 1. In the process of looking into this, fixed a typo in a comment. + No functional modifications yet. + + 2. The revision suggested by ST to remove the restriction on writing + image [1], i.e., to delete the "cl_index <= 1" from the two + expressions, does not handle the case where the input and output + image formats are not the same. I think the code can be modified to + remove the restriction, but it is too tricky to do this and test the + software sufficiently for the version 2.5 release, so this change is + postponed to a future release. (7/5) + +dev/termcap + Added entries for `wyse' and `414a'; added `:gd' to go140. (7/6 SRo) + +pkg/bench/bench.hlp +pkg/bench/bench.ms + +pkg/bench/bench_tab.ms + + Installed a heavily revised version of the benchmarks paper, including + comparative benchmarks for nearly all current IRAF host machines. + (7/6) + +unix/gdev/iism75/m75put.x +unix/gdev/iism75/zrdm75.x + These files both contained a "short = short-expr" construct which was + being evaluated at compile time and causing a short integer overflow, + preventing compilation of these files on the SUN (harmless, but + annoying). Replaced by two statements with an intermediate assignment + into an integer temporary to get truncation to a short. (7/6) + +unix/gdev/* [SUN/IRAF only] +os/zxwhen.c +os/net/kutil.c + Did a full diff of the UNIX/IRAF and SUN/IRAF HSI sources to see if + there were any revisions to standard UNIX/IRAF which had not made it + into SUN/IRAF yet. Did find several, although all were harmless. + Fixed these to minimize unnecessary diffs. + 1. Added the iism75 code to gdev. Note that the SUN/IRAF version + of zfiogd.x temporarily includes support for IMTOOL. + 2. Updated the source for the sgi2uimp.c SGI translator, which was + older than the UNIX/IRAF version (prerasterization rev). + 3. In zxwhen.c, fixed a classic C typo, "=" -> "==". + 4. In os/net/kutil.c (which is not active code), changed a C array + reference text[1] -> text[0]. + All other diffs were as they should be. (7/6) + +------------------------------- +Updated all systems (including bug fixes in NOAO). (7/6) +Hopefully, this is the frozen V2.5 release. diff --git a/doc/notes.v27 b/doc/notes.v27 new file mode 100644 index 00000000..5c2a05f6 --- /dev/null +++ b/doc/notes.v27 @@ -0,0 +1,2848 @@ +System Notes File for IRAF Version 2.6. +Begun 8 July 1987. +------------------------------------------- + +doc/notes.v25 + +local/notes.v26 + + Moved the V2.5 system notes file to the documentation library and + started a new one (this file). (7/8) + +unix/hlib/motd +pkg/cl/cl.par + Incremented the IRAF version number to 2.6. (7/8) + +local/bugs.v25 + +unix/hlib/buglog.csh + +unix/hlib/irafuser.csh +unix/hlib/login.cl + Set up a system bugs file for V2.5, to be used to record bugs in the + frozen V2.5 system as they are discovered. Added a new HSI utility + task (UNIX/IRAF only) called 'buglog', used to log new bugs. (7/8) + +unix/hlib/login.cl + Added a new foreign task to the user package called 'nbugs'. + This may be used to page the tail of the system bugsfile, to see + if any new bugs have been added. The new utility task is only + available on UNIX/IRAF and as defined will only work if the + nonstandard pager 'less' is installed, as it is on all NOAO + systems. (7/9) + +pkg/bench/bench.hlp + Added IMLOAD and IMLOADF measurements to the Sun benchmark entries. + (7/10) + +unix/hlib/buglog.csh + Will now send a copy of each bug as it is logged to the iraf mail, + as well as appending it to the system bugs file. This ensures that + all subscribers to the iraf mail see the bug report promptly. (7/10) + +doc/vmsiraf.ms + + Added a completely new, more comprehensive VMS/IRAF Installation Guide + to the docs directory. (7/20) + +GTERM (Sun/IRAF) + Made a number of obscure, mostly minor tuning enhancements to GTERM; + these have accumulated over the last couple of months. Most of these + are little things that one does not notice if things are working right. + + 1. Incremented the version number to V1.1 for the first official + release of V2.5 SUN/IRAF. + 2. Setup/reset now resets the user settable parameters to their + command line values, rather than to the builtin defaults. + 3. I discovered that due to an oversight, there was no way to set + reverse video for the graphics plane on the command line. Added + the new switches -[no]rev[erse], e.g., -rev or -norev (the default). + + 4. One can now add the sequence [task [args]] to the end of the + GTERM argument list to directly execute TASK in the window, even if the + command follows the -G in the command line. This is different than + the already provided [-I command], which executes a shell in the + window and passes it the given command. A shell process is eliminated, + and exiting the named task causes the window to quit (e.g., if the + command is "cl", logging out of the CL terminates the window). + A disadvantage (or advantage depending upon how you look at it) is + that since there is no csh, there is no job control in the window. + + 5. The F8 and F9 function keys are now recognized when the mouse is + in either the text or graphics window. Hence if one types F8 to get + into graphics mode (perhaps by accident), then closes the graphics + window, typing F9 in the text window will restore text mode. + Previously one had to get the graphics frame back in setup mode in + order to type the F9 to restore text mode. Also, typing L7 while + in graphics mode (which makes the graphics plane go away) will now + automatically restore text mode. Hence if one types F8 by accident + while in text mode, typing L7 restores everything, including making + the graphics plane go away. + + 6. Typing F8 to get into graphics mode no longer clears the graphics + plane; typing F8 WHILE in graphics mode still clears the graphics + plane. Hence, to switch to graphics mode AND clear the screen, one + can type F8 twice. Typing F8 once while in text mode merely brings + up the graphics plane, providing a handy way to get the graphics plane + back without clearing it, without having to call up the setup panel. + + 7. Fixed a problem with the -Wh (-height) frame arg, used to set the + height of the tty window in lines of text. For example, -Wh 40 may + be used to start up GTERM with the IRAF standard 40 line window. + + 8. GTERM now catches the suspend signal (SIGTSTP) and stops itself when + this signal is received. Evidently, standard sunview window processes + (such as shelltool) do not do this since the window stops responding + to mouse and keyboard events, but it is necessary for GTERM to stop + itself when so commanded in order to be able to do a (,'bg') + of a running gterm job in a cshell (e.g., another gterm window running + a shell), i.e., to stop the job and put it in the background. + Conversely, if SIGTSTP is not caught, typing 'fg' by accident on a + background gterm job causes the cshell to hang up, requiring a + abort to recover (killing whatever the gterm process was running, + e.g., a remote login to a computer on the other side of the world). + + 9. I tested GTERM on a monochrome terminal (3/110 overlay plane). + Modified the setup menu so that it says "mono only" when working on + a monochrome terminal, instead of indicating that color is an option. + Could not get reverse video to work on a monochrome monitor, although + it works fine in monochrome mode on a color monitor. Decided to leave + it as it is for the moment (black polylines on a white background + unless entire screen is inverted). + + 10. Fixed a minor bug: when specifying frame colors for both the text + and graphics frames, the graphics frame colors would clobber the text + frame colors before the code would allocate a private colormap segment + for the second window. + + 11. Checked out a report than when printing very long lines, GTERM + might be losing characters during the wraparound. The problem was + not duplicated and all characters were printed with autowrap as + expected, both in the left column on a cleared screen, and on the + half-screen column after a vertical screen wraparound. + + 12. Added a new command line option -T, and a set of related options + in the setup panel. The options specify how the terminals responds to + graphics commands and data. If -T is specified the graphics plane is + disabled, and graphics characters are printed in the text frame as on + a non-graphics terminal. Another option allows graphics data to be + discarded entirely. These options should be useful when debugging + graphics programs, or when working over a noisy line. + + 13. All gterm specific command line arguments and switch values now + permit minimum match abbreviations. + + 14. Added a new command line argument "-ginterm [ch [ch]]", where the + [ch] are the octal values of the GIN mode terminators. Also added + support for setting the GIN mode terminators to the setup panel. + This is not required for IRAF, but for running foreign graphics + programs which require no GIN terminator, or a different value. + + 15. Reworked the setup panel code somewhat so that selecting one item + in the panel causes actions to be performed which affect only that one + item. Formerly, the setup event procedure would fetch the value of + each setup item and perform some action if the value had changed. + This could result in unnecessary actions in some cases. + + 16. Fixed another suspend-process bug. When running a command like CL + or SH which does not do job control in the gterm window without benefit + of an intermediate shell, typing the suspend character would cause the + process (and terminal) to hang, requiring a kill to recover. Added a + new command line option "-ignore" to allow filtering out of the suspend + control characters, and also a new frame menu option "continue" which + when selected, sends SIGCONT to the process group currently associated + with the terminal. This will restart a process which is accidentally + stopped by typing the suspend control character. Note that SHELLTOOL + also has this problem. + (7/23+) + +local/mail.mai - +local/mbox.txt - +local/tasks/daophot/image.dst - + Deleted these files in VMS/IRAF. (7/27) + +unix/hlib/stripper +unix/hlib/stripall [UNIX,VMS,SUN] +vms/hlib/stripper +vms/hlib/stripall + Revised the stripper scripts for V2.5 IRAF. This reduced the size + of the stripped V2.5 VMS/IRAF system from 18.7 to 14.9 Mb (with shared + libraries). The main changes were deletion of all files in the + following directories: + + local/noao + vms/hlib/share + + In addition, a dozen or so modest size files, mostly .hlp files used + to generate printed manuals, were added to the list of special files + to be deleted in the stripper scripts. (7/27) + +unix/hlib/install +local/sun/Makefile [SUN/IRAF] +local/suntools -> local/suntools.e + Changed the name of the main 'suntools' executable in the IRAF system + login directory to 'suntools.e'. This is necessary to prevent + execution of this local master copy of the suntools executable, when + entering the command 'suntools' when logged in as 'iraf'. This is + wasteful of memory, as iraf/local/suntools is run for the root window, + but /usr/bin/suntools is used for most everthing else. (7/30) + +pkg/cl/param.c + Fixed a serious bug in the code which searches for parameters where + no containing task has been specified, i.e., "param" rather than + "task.param", requiring a search of all pfiles in the search path. + There were two problems with the old code (lookup_param in param.c): + + [1] If "param" was an ambiguous abbreviation for two or more of the + parameters in one of the pfiles in the search path, the search was + being terminated and an illegal value was being returned to the + calling routine (paramsrch), causing the error message + + ERROR: task `' has no param file + + to be printed, aborting the task. The actual error would be an + ambiguous parameter name abbreviation, but even this is incorrect + since an exact match might be found in a pfile further on in the + search path. This would commonly happen when referencing the CL + parameters i,j,k,x,y,z, etc., in complex scripts, since it is easy + in a complex script to have two or more parameters whose names begin + with one of these characters. + + [2] If "param" was an unambiguous abbreviation for one of the + parameters in a pfile in the search path, that parameter would be + referenced, even though the actual parameter name given was the + exact name of a parameter in a pfile further on in the search path. + In other words, the search routine would stop as soon as it found + a parameter for which the given name was an abbreviation. Clearly, + if searching for one of the CL global params i,j,k,x,y,z, etc., + it is easy for this to occur, causing the script to fail. + + The bug has been fixed, but the workaround is simply to not use the + global CL parameters in scripts. This has always been considered + poor practice due to possible coupling problems between nested scripts + that access the same global parameters. It is also more efficient + to define the parameters as local variables, as the search path is + shorter. (7/31) + +IMTOOL (SUN/IRAF) + 1. The hardware color table is now updated twice a second on a timer + loop, allowing the displayed image to be viewed normally even while + the mouse is not in the display window. + 2. Added a rate option to continuous random pseudocolor. Also, this + maptype option will now work when the mouse is not in the display + window, due to revision 1 above. + 3. Added a command line option -maptype for setting pseudocolor options + etc. on the command line. (8/4) + +local/sun/gterm.man + +local/sun/imtool.man + +local/sun/* + I cleaned up these directories, deleting the old ./save directory, + adding a README with installation instructions, adding a Makefile, + and so on. Also, manual pages were added for both GTERM and IMTOOL. + (8/4) + +unix/gdev/sgidev/sgi2uapl.c + 1. Added code to add the tiny timestamp/logo to the corner of each + output plot, so that the machine of origin, owner, and time are + recorded automatically on each plot when generated. A -t switch + was added to disable printing of the logo (the default is to print it). + + 2. I also optimized the generated Postscript so as to speed up plotting. + This turned out to be tricky, as the Postscript interpreter is not all + that fast, hence even with the serial interface the laserwriter can + easily be cpu bound. For a test vector plot with labelled axes, plot + title, and 3 512 point vectors overplotted, the following results were + obtained. + data size, bytes clock time + ---------------- ---------- + original code 90578 1:45 + 4 byte encoding 25877 1:43 + 7 byte encoding 37956 1:12 + + The original code was clearly generating a lot more data than it + needed to to describe the plot (17 bytes per vector point), which was + the motivation for this optimization. At 9600 baud, it should take + 1:15 seconds to transmit 90Kb, suggesting that the plotting might be + i/o bound. Hence in my first attempt at optimization I used a + sophisticated encoding scheme which used only 4+ bytes to encode each + vector point to be plotted. This resulted in a very compact + representation of the plot, but the running time worked out about + the same, indicating that the processing was cpu bound due to the + overhead of the Postscript interpreter, and the relatively low speed + of the 68000 chip used in the current laserwriter. In my second + attempt I streamlined the Postscript code, increasing the encoding to + 7 bytes per vector point, with some loss of data compression, but a + significant improvement in processing time. + + The conclusion is that Postscript, due to its very general and flexible + interpreter can sometimes be slower than one would like, and there is + little that can be done about it. In many cases adding the more + expensive parallel interface would not help; the bandwidth of the + serial interface is rarely a problem, except perhaps for 1 to 1 bitmap + transfers. As faster chips are used in the laserwriters there may + come a point where the 4 byte encoding is the fastest. If the + Postscript output is to be used to save plots on disk or transmit them + via modem to remote computers, the 4 byte encoding may again be + preferable. The ideal solution would be if Postscript were to provide + direct support for a polyline primitive, rather than relying on the + Postscript interpreter to draw polylines. + + By default, the 7 byte encoding is used since it is faster. The new + switch "-4" was added to enable the optional 4 byte encoding (the + translator supports both). (8/9) + +pkg/images/tv/display/t_display.x + A new routine ds_setwcs() was added which writes a WCS descriptor file + to the directory 'wcsdir' (uparm if not defined) when an image or + image section is displayed. The WCS file contains two lines: the + first line is some text describing the image (image name and title + string), and the second line is a rotation matrix to be applied to + screen coordinate to get image coordinates. The rotation matrix + undoes the affects of the image section or display mapping + transformations. The filename is "wcsdir$_.wcs", + e.g., "uparm$imtool_1.wcs". (8/12) + +doc/unixiraf.ms + + Installed the all new UNIX/IRAF Installation Guide in doc. (8/24) + +vms/os/zfioty.c + Modified the VMS terminal driver to recognize the special device name + "dev$tty", passed by the VOS to indicate the user terminal. Checked + out the operation of the TTOPEN routine (used to do i/o directly to + the terminal). (8/25) + +unix/boot/mkpkg/host.c + The u_fmove function ($move) will now physically copy the file if + necessary to move it to a directory on a different device. (8/27) + +local/tasks/mkpkg +local/tasks/peritek - + Deleted the @ccdred reference and peritek references from this mkpkg + file on Sun/IRAF. (8/27) + +dev/termcap + Added an entry for the unixpc. (8/27) + +unix/hlib/install + Extracted the file lists and moved them to the head of the file as + SET statements so that they may more easily be modified for different + machines. Added some more files to these lists for the Sun/IRAF + version of install. (8/28) + +unix/hlib/stripper +unix/hlib/stripall + Modified Sun/IRAF versions to delete the archived object files for + each floating point option during a strip operation. (8/28) + +mkpkg +unix/hlib/mkfloat.csh +unix/hlib/cl.csh +unix/hlib/irafuser.csh +unix/hlib/login.cl + Added support to Sun/IRAF for multiple binary versions of the system, + e.g., to support multiple floating point options with a single copy + of the system. There are two reasons for doing this. + + [1] When multiple nodes must access the same copy of IRAF, the + different nodes will often have different floating point + hardware. + + [2] It would be nice to not require user sites to recompile the + full system because they have different floating point + hardware then we do on our development system. + + This could have been done (could still be done by user sites if + desired) by recompiling the system with -fswitch, but this would + result in a significant loss of efficiency in some programs. + Our solution instead is to have multiple copies of the runtime + system executables. This is transparent to the user, with the + best choice being made depending on the floating point hardware + available on the machine on which IRAF is being run. + + Implementation is as follows: + + iraf$bin.f68881 Binaries for -f68881 option. + iraf$bin.ffpa Binaries for -ffpa option. + iraf$bin link to either of the above. + cl link to hlib$cl.csh, defines IRAFBIN + login.cl resets 'bin' to value of IRAFBIN + + There are two bin directories, BIN.F68881 and BIN.FFPA, compiled + -f68881 and -ffpa respectively (the HSI executables are separate + and are compiled -fsoft). The old BIN directory is now a symbolic + link to one of these two directories. On our systems, bin.f68881 + and bin.ffpa are also symbolic links to directories on a separate + device, in order to provide more flexibility in allocating such a + large amount of storage. + + The command 'cl' is now a link to the script hlib$cl.csh, rather than + a link to bin$cl.e. The script defines an environment variable + IRAFBIN giving the path to the bin directory to be used, and then + runs the cl.e in that directory. The fpa bin will be used if it + exists and if the file /dev/fpa exits, indicating that the local + node has an fpa. The revised LOGIN.CL file fetches the value of + IRAFBIN defined in cl.csh, and uses it to 'reset' the value of the + IRAF logical directory BIN. + + While it is easy to switch bin directories, it is much harder to + maintain two separate copies of all the objects and package libraries. + The system has been set up so that it can easily be configured with + either f68881 or ffpa objects, but not both at the same time. + This is done as follows: + + cd $iraf + mkpkg ffpa (configure for -ffpa objects) + mkpkg f68881 (configure for -f68881 objects) + mkpkg showfloat (show current float option) + + MKPKG is used to configure the entire system for either float option. + Once this is done, that version of the binaries are updated by the + mkpkg. The system is normally configured for f68881 so that software + development may take place on any node. Periodically the ffpa objects + and executables are updated by the following commands: + + cd $iraf + mkpkg ffpa (configure for -ffpa) + mkpkg (update libraries and relink) + mkpkg f68881 (restore to -f6881) + + This updates the ffpa version of the system, and restores the system + to f68881 when done. When not in use, all the system and package + objects and libraries are stored in the file OBJS.arc in one of the + bin.f* directories. + + IMPORTANT NOTE -- Since bin, bin.f68881, and bin.ffpa are all + symbolic links, a tar archive of $iraf no longer includes any + executables. The real bin directories (/tmp2/bin.f68881 and + /tmp2/bin.ffpa on our system) must be explicitly referenced on + the tar command line to be included in the archive. A tar of $iraf + is now only about 35 Mb, and the bin directories are about 24 Mb. + + When configuring the system for a particular site, the bin directories + may be located wherever there is space, and either directory may be + deleted if it will not be used. Of course it is always possible to + delete both and compile the system for -fswitch, etc., if desired. + + I am considering adding a gprof version of OBJS.arc for profiling + purposes, now that we have an easy mechanism for maintaining multiple + versions of the system binaries. (8/28) + +unix/hlib/install + Modifed the Sun/IRAF part of the install script to install or update + the GTERM and IMTOOL manual pages. (8/30) + +unix/hlib/zzsetenv.def + Added an entry "set stdimcur = text", so that image cursor reads will + come to the terminal by default, rather than trying to spawn the + stdimage kernel and dieing on a process not found error. (8/31) + +unix/boot/mkpkg/host.c + Thanks to the recent change to a remote bin directory on Sun/IRAF, + which causes $move to call u_fcopy, we have found a bug in u_fcopy. + The variable "totchars", used to check if the file changes size + during the copy, was not being initialized before each copy. (9/1) + +---------------------------- +Sun/IRAF V2.5 frozen and archived on tape. (9/3) + +vms/boot/mkpkg/host.c + I had to add the /NOCONTIGUOUS qualifier to the COPY command, as COPY + would issue a warning message and return an error (warning) status + code, when trying to copy an input file which was contiguous and the + output file could not be created contiguous. This was happening even + though there was no /CONTIGUOUS qualifer on the command line. (9/4) + +local/sun/gterm.c +local/sun/gtermio.c + Added a new, experimental feature to GTERM. Selecting "logging on" in + the frame menu causes all output from that point on to be logged in a + file. Selecting "logging off" disables logging. The log file filename + may be set in the setup panel if desired. Any utility such as 'cat' + may be used to replay the logfile. "Page mode" may be set in the + text window to page the played back output. This feature is useful + to spool terminal output for later review, e.g., during a terminal + session on a remote or non-UNIX node where i/o redirection is + difficult, or to provide a means of spooling the output of interactive + programs which do not provide such a facility as a builtin (e.g. a + file pager). (9/8) + +doc/pkg.hlp + Deleted some ^N, ^O control codes which were embedded in the text, + causing the file to appear to be a binary file. (9/9) + +sys/clio/clgcur.x + CLGCUR will now accept either X-Y-WCS-KEY-SVAL or KEY-SVAL as valid + input cursor value strings. In the latter case, X-Y-WCS will be + returned as INDEF INDEF 0. It is assumed that if the latter case is + used, the coordinate information is to be ignored, e.g., because the + function selected by the key does not use the coordinate information. + This is convenient when entering interactive commands in cursor mode, + e.g., with stdimcur set to "text", (or possibly in cursor lists when + the coordinate information would be meaningless for a given key). + Note that omission of X-Y-WCS is possible only when the given key + is nonnumeric. (9/10) + +doc/aosvsiraf.hlp + Installed a new version of the AOSVS/IRAF Installation Guide. (9/11) + +sys/gio/stdgraph.com +sys/gio/stgres.x +sys/gio/mkpkg +sys/gio/stgpl.x +sys/gio/stgpm.x +sys/gio/stgencode.x +sys/gio/stdgraph.h +sys/gio/stginit.x + Someone (Dyer) discovered that the graphics system was noticeably + slower than specialized test code when used to plot very long vectors, + e.g., 4096 points. Normally the software is faster than the hardware, + but for these very long vectors clipping of unresolved points becomes + a significant factor, as does all the processing needed to generate + all those points. + + Investigation showed that virtually all of the time was being spent + in three routines: gadraw, the main point drawing routine in GIO, + and stg_polyline and stg_encode, the principle polyline drawing + routines in the stdgraph kernel. + + The gadraw routine uses the most time, but examination of the code + showed that it was already fully optimized, with caching of the WCS, + use of integer rather than floating point where possible, and provision + of code to optimize the common special cases, e.g., linear WCS, + successive points all inbounds with no clipping, and so on. I don't + seem much possiblity for improvement here, it just takes a little + while to plot all those thousands of points (i.e., 0.68 seconds for + all the GIO operations for 4096 points on my 16.7 MHz diskless Sun + node with f68881 fpa). + + There was room for improvement in the polyline drawing code in the + stdgraph kernel, however, since most of the time was being spent in + a single routine. I [1] added code to the inner loop to handle the + special case of Tek-4012 encoding inline, rather than calling the + encoder, [2] substituted lookup tables for the tek encoding, rather + than computing the 4 bytes each time with divides, mods, adds, etc., + [3] substituted integer for floating point in the unresolved point + clipping code, and [4] replaced the FOR loop by a DO loop. With these + changes, I was able to reduce the running time for drawing 100 4096 + point polylines in the stdgraph kernel from 37.9 sec to 18.0 sec on + the 16.7 MHz f68881 Sun. The most significant change occurred with + optimization [3], since for these long vectors clipping is the major + operation, and the f68881 floating point is quite slow compared to + 68020 integer operations. + + In repeating the same tests on the 11/750, my 4096 point test plot + took 11 seconds to draw both before and after installing the optimized + stdgraph kernel. It appeared that the GIO time was about 2.2 sec + per plot, and the stdgraph time about 0.7 sec, indicating that the + operation was very much limited by the drawing speed of the terminal. + By decreasing the software resolution of the plot in cursor mode, + I was easily able to decrease the drawing time to 4 seconds, with + only slight degradation of the plot. Hence, it appears that the most + significant factor affecting plotting time is actually the point + elimination algorithm, which is probably more conservative in the + stdgraph kernel than in the specialized test code mentioned above. + + I conclude that, although a significant inefficiency in the polyline + drawing code was discovered and fixed, the graphics system has been + i/o limited all along (on conventional graphics terminals), and that + the differences in plotting speeds observed earlier were due to + differences in the point elimination algorithms, causing one program + to plot at a slightly different resolution than the other. (9/12) + + [Addendum 9/14: In repeating the plotting speed tests mentioned + [earlier, we discovered that the real difference was that Dyer's + [program was *subsampling* the data by 4, and hence only plotting 1024 + [points, whereas all my tests were plotting the full 4096 points. + [Repeating the IRAF test with an [*:4] image section eliminated the + [problem - and I suspect the IRAF code, despite its generality, is now + [more efficient than Dyer's specialized test code.] + +sys/gio/gactivate.x +sys/gio/greactivate.x +sys/gio/gdeactivate.x +sys/gio/gki/gkigca.x +sys/gio/gki/gkifetch.x +sys/gio/gki/gkigetwcs.x + Added some errchk declarations. (9/14) + +dev/graphcap +lib/syserr.h +lib/syserrmsg +sys/gio/gopen.x +sys/gio/cursor/gtropenws.x + 1. In the graphcap file, for device 'iis', deleted the kf and tn + capabilities (kf=bin$x_stdimage.e etc.) since there is no GIO + kernel yet for this device, and it is therefore incorrect to + indicate that there is such a kernel in the graphcap (this causes + misleading error messages). + 2. Added a new system error message SYS_GNOKF, and modified gopen.x + and cursor/gtropenws.x (GIO) to check that a device has a GIO + kernel before trying to connect it, printing an informative error + message and taking an error exit if no kernel is found. + + NOTE: All graphics devices accessed via GIO must now have the 'kf' + capability in their graphcap entry, specifiying the GIO kernel to + be used. Previously, the value of kf would default to 'cl' if no + kernel were found, but this has been changed to an error condition. + As far as I know, all graphcap entries to date have explicitly + specified the kf so this should not cause any problems. (9/15) + +pkg/cl/exec.c +pkg/cl/pfiles.c + Fixed a PSET related bug that would occasionally cause segmentation + violations in the CL when "executing" a pset task. The segmentation + violation was occurring due to an indirect reference (by pfileload() + in pfiles.c) to the param file pointer in the task structure, occurring + in the code in callnewtask() in exec.c which was in the process of + setting that very parameter. (9/20) + +pkg/cl/binop.c +pkg/cl/opcodes.c +pkg/cl/unop.c +sys/etc/envreset.x +doc/ports/notes.sun4 + +unix/mc68000/zsvjmp.SPARC + + Merged in some changes from the port of IRAF to the Sun-4, the new + RISC architecture (sparc) machine. + 1. The changes to the three CL files were to avoid use of the VALU + macro to fetch the value of an operand, when evaluating boolean + operands. The datatype of VALU, due to the union in the operand + struct, is double, and evaluation of boolean expressions in double + on the sparc cpu was not working (and obviously should be avoided). + 2. In envreset.x, the maxch argument to a strcpy was being passed as + a short rather than an int, and this was causing a bus error on the + sun-4. + 3. Saved copies of the notes file from the port, and the zsvjmp.s + (10/1) + +sys/gio/gopen.x + The recent addition of code to check for the kf parameter interfered + with the gopen action for the special device 'stdvdm'; fixed this. + (10/1) + +sys/gio/doc/gio.hlp +sys/gio/stdgraph/stgrcur.x + Added a new graphcap device parameter RE. This goes with RC, and if + defined for a device, is sent to the terminal after the cursor value + has been successfully read. This is necessary on terminals which + ignore characters coming back from the computer (e.g., due to echo + not being turned off in the terminal driver) while transmitting the + cursor position characters during a cursor read. (10/1) + +sys/clio/clgcur.x + The clgcur revision of 10 Sept (about 3 week back) introduced a bug + which would cause cursor reads returning negative x values to fail. + This has been fixed on lyra and tucana. Our policy of not exporting + code from our test systems should have prevented this bug from being + propagated to any external sites, or even to our production systems + in Tucson. (10/2) + +local/sun/Makefile +local/sun/gtermio.c + 1. Discovered and fixed a serious bug in GTERM which would cause the + terminal to lock up when trying to do graphics over a modem connection + to an external computer (evidently this was the first time this has + been tried). In this mode of operation, characters are delivered one + at a time; receipt of the GS character alone would cause the input + code to get into an infinite loop, exiting immediately each time + called, posting a callback to the notifier, which would evidently call + the input procedure back BEFORE reading pending input on the pty. + 2. Modified the makefile to strip the suntools.e executable in the + "make install" rather than when it is made, to make it easier to get + at an unstripped version for debugging. (10/3) + +doc/cluser.tex +doc/vmsiraf.ms + Corrected the spelling of Fred Romelfanger's name. (10/7) + +sys/gio/gopen.x + Corrected another problem having to do with raw metacode output. + This was diagnosed as a stdvdm problem, but wasn't really. A program + was opening device "stdvdm", but directing output to a binary file + opened by the application, and it was bombing because in this case + GIO is not writing to the stdvdm file, but to the user file. + The change was to disable checking for the existence of a graphics + kernel whenever output is directed to a stream other than STDGRAPH, + STDIMAGE, or STDPLOT. If the user is controlling where the metacode + goes, it is inappropriate to make such a check, as probably no kernel + is being used. (10/22) + +--------------------------------------- +Orion (Sun-4) updated (port actually) from lyra on 24 Oct. This was with the + BETA1 release of SunOS for the RISC Sun-4, hence will have to be redone + when we get the correct, current operating system software in. +Tucana updated from lyra on 26 Oct (both f68881 and ffpa). + +unix/boot/wtar/wtar.c + I wanted to use the -o (omit binary) feature to make a source only + update tape given a long list of individual files and directories. + This failed due to the restrictions in the unix/iraf HSI on changing + directories. I hacked away on WTAR until it could handle this + properly, and had to generalize the library routines listed below + as well. (10/27) + +unix/boot/bootlib/oschdir.c + The case which folds a subdirectory into the pathname of the current + directory was being called incorrectly when passed a directory name + of the form "path/subdir". (10/27) + +unix/boot/bootlib/osfpathname.c + The special code in this routine for vfns "." and ".." was checking + only for such a prefix, and incorrectly matching filenames such as + "./path". (10/27) + +----------------------------------- +IRAFX (draco) updated from lyra on 27 Oct. + +sys/gio/gclose.x + Added a call to gki_redir(fd,0,0,0) to cancel any redirection of a + graphics stream to an inline kernel or subkernel, when the stream + is closed. This has never been a problem, but could be required in + some circumstances. (11/2) + +sys/gio/gki/gkiredir.x + May now be called with fd < 0 to obtain the redirection information + for a stream without changing anything. (11/2) + +sys/gio/gopen.x + Checking for a kernel file in graphcap is now disabled if a graphics + stream is opened on an inline kernel or subkernel, in which case no + external kernel could possibly be needed. (11/2) + +pkg/images/tv/cv/load1.x + The CVL task was issuing the following sequence of calls: + + gki_inline_kernel + gopen, gclose + gopen, gclose + + Since gclose now resets the default GKI stream type, a second call + to gki_inline kernel is necessary before the second call go gopen, + to setup GKI for an inline kernel. (11/3) + +sys/gio/gvmark.x + Bug fix: replaced the single "marksize" argument by the "xsize, ysize" + specified in the documentation, etc. (11/6) + +sys/fio/nowhite.x +sys/fio/open.x +sys/fio/vfntrans.x + The NOWHITE procedure, used to eliminate whitespace and newlines from + a string operand, was using maxch on the output string as a terminator + and ignoring EOS on the input string (most likely harmless, but + inefficient). In the process of fixing this it appeared that it + would be useful to return the length of the output string as the + function value, and the procedure was only used in the two files + listed above, so the procedure was converted into a function. (11/6) + +sys/gio/stdgraph/stgpm.x + The STDGRAPH kernel polymarker code would draw the polymarker and then + go into an infinite loop, due to a bug in the loop termination test + introduced when the optimized polyline drawing code was transferred + to the polymarker drawing routine some time back. (11/7) + +sys/imio/imaccess.x + If an image section is specified, imaccess calls immap to see if the + image specification is legal as well as test if the image exists, + in order to avoid having to deal with the complexity of parsing image + sections etc. The problem was that the 'mode' argument to imaccess + was being passed to 'immap' directly, and thence on to the file open. + Hence, the image header file was being opened with access mode 0, + causing an error exit to be taken in FIO (see below). Changed imaccess + to open the image with mode READ_ONLY if the access mode specified + to the imaccess is 0, otherwise the user specified access mode is + used. (11/13) + +sys/fio/fgetfd.x + In the process of fixing the above bug, I found and fixed a serious + bug in FIO, which has been there since the code as written! If a file + were opened with an illegal mode or type, the FGETFD routine would + take an error exit sure enough, but it was not dealling the file + descriptor and marking the file slot unused, hence was leaving the + file descriptor allocated and half filled in. This would go undetected + until the task terminated, normally or otherwise, at which time the + file cleanup routine would find the "open" file and try to close it, + causing a segmentation violation due to the partially filled in file + descriptor. Note that this error would only be seen when attempting + to open a file with an illegal mode or type (a bug in the calling + program), hence it has probably rarely been seen. (11/13) + +unix/os/zfiomt.c + I had to make a couple of subtle mods to the MTIO driver to workaround + peculiarities in the SunOS mtio driver on the Sun-4 (GAMMA release of + SunOS). Note that none of these bugs is present on the Sun-3 or any + other UNIX system thus far tested. + + 1. On the Sun-4, it turns out that an MTBSR ioctl (back skip record), + if used to backskip over a tape mark, returns ERR, as does MTFSR, + with errno=EIO. To workaround this it was necessary to ignore ERR if + errno=EIO following a forward or backward skip record. The driver is + not technically at fault here, since the BSD mtio documentation does + not specify what the driver should do in this case, but all other unix + drivers thus far tested permit BSR to backspace over a tape mark. + + 2. This one was more subtle, so subtle in fact that I cannot be certain + I have diagnosed it properly, although everything fits my theory well. + For forward record skips, the IRAF magtape driver uses a read into a + large dummy record buffer for which space is automatically allocated on + the machine stack at function entry, e.g.: (a read rather than FSR is + used here to reliably detect tape marks) + + char buf[29184]; + int nb; + nb = read (fd, buf, 29184); + + What would happen is that in the first call to this code following + process startup, the read would fail, returning errno=14 (EFAULT, + bad address causing fault during execution of system call). What I + suspect is happening is that the page fault required to allocate + space on the process hardware stack for BUF is occuring during + execution of the dma read in the SunOS mtio device driver. Once the + stack grows large enough to provide space for BUF, the error goes + away. Adding a "buf[0] = 0" statement before the read fixes the + problem by causing the stack page fault to occur in the user process + before entering the kernel device driver. (3/12) + +sys/mtio/mtio.h +sys/mtio/mtpos.x +sys/mtio/mtlocknam.x +sys/mtio/mtfile.x +sys/mtio/mtparse.x +sys/mtio/mtosdev.x +sys/etc/xalloc.x +sys/etc/xgdevlist.x +sys/ki/kzrdmt.x +sys/ki/kzwrmt.x +sys/ki/kzwtmt.x +sys/ki/irafks.x +sys/ki/kiextnode.x + Revised these files to finish adding support to the VOS for network + access to remote magtape devices. Remote devices are accessed merely + by prefixing the device name with the node name, e.g., "orion!mta" + to access the A tape drive on node "orion". For example, to list the + headers on a FITS tape on a remote drive, + + cl> alloc o!mta + cl> rfits o!mta 1-99 make- + + The dev$devices file on the remote node is used to obtain the device + information, hence no network information is required in the device + files, and device names need not be unique in a network sense. + Performance, as measured by the clock time, ranges from 30-90% of + what is achieved using the tape drive on the local node. These + revisions also included a couple of bug fixes, e.g., the KI magtape + access bug logged sometime back, and a newly discovered missing + argument bug in some error recovery code in the device allocation + code in etc. (12/5) + +pkg/dataio/mkpkg +pkg/dataio/cardimage/conversion.x +pkg/dataio/cardimage/t_rcardimage.x +pkg/dataio/cardimage/t_wcardimage.x +pkg/dataio/cardimage/tabs.x +pkg/dataio/fits/fits_write.x +pkg/dataio/fits/t_rfits.x +pkg/dataio/fits/t_wfits.x +pkg/dataio/imtext/rt_rwpix.x +pkg/dataio/mtexamine/t_mtexamine.x +pkg/dataio/reblock/reblock_file.x +pkg/dataio/reblock/t_reblock.x +pkg/dataio/t2d/t_t2d.x + 1. Modified all programs in DATAIO to use the MTFILE operator to test + if a file is a magtape file. Formerly, these routines were using + an explicit strncmp of the "mt" prefix, which is poor information + hiding and does not work with network access. + 2. The cardimage and reblock programs were writing verbose output + to STDOUT but flushing STDERR. (12/5) + +---------------------------------------------------- +Updated tucana and orion from lyra. (12/5) + +local/sun/imtool.c +local/sun/imtool.man + Modified the way the coordinate file name is entered via the setup + panel, to make this feature easier to use. The string displayed and + entered via the setup panel is now a printf style format specification + rather than the actual file name, with the default being "frame.%d" + (the %d, if given is replaced by the frame number). There is now + visible feedback when the user types return to enter the new string, + i.e., the window frame label is updated. (12/6) + +sys/ki/kilnode.x +sys/ki/kifndnode.x [LOGICAL NODE NAMES] +sys/ki/kinode.com +sys/ki/kignode.x + Modified the KI to add support for logical node names that can be + defined in the environment. These may be used interchangeably with + the node name aliases defined in the dev$hosts; the main advantage + is that since the environment is used, the values may be changed on + a per user basis. Logical node names (similar to plot! etc.) may be + defined in the standard system, with the local node being assumed if + the given logical node name is not currently defined. (12/6) + +unix/gdev/zfiogd.x +pkg/images/tv/display/iisopn.x + Added support for IMTOOL to the master system on lyra. (12/6) + +sys/imio/imdmap.x + Noticed and fixed a harmless bug in this file. The graphcap descriptor + for the image display was being opened but never closed. (12/6) + +dev/graphcap + Added a "node!" prefix to the DD string for device 'imtool'. + The logical node name "node" is supposed to refer to the primary node + the user is logged in on. With this and the other changes noted + above, it is possible to use IMTOOL over a network connection + (there may be a byte swapping problem yet on the VAXes). (12/6) + +--------------------------------------- +Updated orion and tucana from lyra, including propagating a bug fix in +apextract. (12/7) + +local/sun/imtool.c + Modified to automatically sense whether the input data is byte swapped, + to allow generation of the display data stream on remote, possibly + architecturally incompatible nodes on the network (e.g., VAXes). + Also added code to verify the checksum of each IIS header and print + an error message on the console if a bad checksum is seen. Non-byte + packed data is now recognized and the difference in the size of the + data block allowed for (avoiding a possible data stream synchronization + problem), but currently only every other pixel will be displayed if + the data is not byte packed. (12/9) + +dev/hosts + Added entries for all the new Sun nodes, and updated the file on most + or all unix nodes in the local network (it is getting hard to be sure + if one has gotten them all). (12/9) + +sys/ki.h +sys/kigchan.x +sys/kighost.x +sys/kifchan.x +sys/kishownet.x + Adding the new nodes to the hosts table caused the internal KI node + table to overflow, revealing two bugs in the KI (sufficient to prevent + IRAF from running at all!). + 1. In kighost.x, the test for a full table was not being performed + correctly, allowing an overflow by one error. + 2. In ki[gf]chan.x, the value of 'server' was being used to index the + node tables when allocating a KI channel descriptor for a resource. + Unfortunately, when a resource is local 'server' is set to NULL. + This was causing an array to be indexed [0], overwriting the final + element of the node table (harmless until the table is full). + + I fixed these bugs and tested for overflow on an overfull host table, + then increased the maximum number of nodes from 20 to 64 (I hate to + reserve the table space, but the KI is a major interface). If there + are too many hosts the system will simply ignore the extra entries + once the internal node table is full. No error message is given, + but if the system.netstatus task is run, the warning message + + HOST NAME TABLE IS FULL + + will be seen. At some point we need to modify the code to permit a + runtime access to the host table (perhaps using the current node + table only as a cache), in order to support an arbitrary number of + nodes as is necessary in large networks. (12/10) + +pkg/system/mkpkg +pkg/softools/mkpkg +noao/mtlocal/mkpkg + Modified these mkpkg files to generate an xx_*.e executable, and rename + it to x_*.e when installing it in BIN. (12/10) + +--------------------------------------------- +Updated irafx on draco (VMS). (12/11) + +dev/hosts + In the kernel server pathnames for the Sun-3 nodes, changed the "bin" + to "bin.f68881" so that a runnable server will be selected regardless + of the floating point configuration of the system. (12/12) + +local/sun/imtool.c +vms/gdev/zfiogd.x +unix/gdev/zfiogd.x +dev/graphcap +pkg/images/tv/display/t_display.x +pkg/images/tv/display/mkpkg +pkg/images/tv/display/findz.x +pkg/images/tv/display/iis.com +pkg/images/tv/display/iis.h +pkg/images/tv/display/iisers.x +pkg/images/tv/display/iisopn.x +pkg/images/tv/display/iispio.x +pkg/images/tv/display/iisrcr.x +pkg/images/tv/display/iisrd.x +pkg/images/tv/display/iisstt.x +pkg/images/tv/display/iiswcr.x +pkg/images/tv/display/iiswr.x +pkg/images/tv/display/maxmin.x + Modified IMTOOL to add support for an 800 square display format option. + 1. Added logical devices 'imt512' and 'imt800' to the graphcap and + to gdev/zfiogd.x. + 2. Modified the DISPLAY program to eliminate all occurrences of 512 + or 511 as a constant, dimensioning everthing instead from the + graphcap entry for the device (all changes should be backwards + compatible for a standard IIS). + 3. Modified IMTOOL to add the 800 square option. This may be set + in the setup panel, but more commonly it will be set automatically + when the user writes to the device imt512 (imtool) or imt800. (12/12) + +------------------------------------------ +Updated all systems. (12/12) + +unix/os/zfioks.c + There was a bug in the UNIX/IRAF zfioks (kernel server) driver which + would cause it to needlessly open a host file descriptor every time it + was called to attempt to open a connection to a remote node. + This bug has gone undetected until now because once a connection to a + remote node has been opened, it tends to remain open for the lifetime + of the client process, and a process is not likely to connect to very + many nodes. + + The bug was found on our diskless sun nodes, due to a circumstance + which was causing the connect to fail, resulting in a connection + attempt (and additional wasted file descriptor) every time a remote + file was accessed. This rapidly used up the available file + descriptors. What was happening was that a large number of images + were read from tape to disk on the server node (tucana). The user + then logged in on a diskless node and attempted to access the images. + The user did not have a .irafhosts file, hence dev$hostlogin was + used, but this old file did not contain any login information for the + node in question, hence the connection would always fail. If a resouce + cannot be accessed over the network the KI currently tries to access + it on the local node (probably not a good idea). In this case this + would work, since the images were created on a disk which was shared + by the two nodes via NFS. + + This problem occurs because of the pixel file pathname in the image + header. This pathname includes the name of the node on which the + pixel file resides, i.e., it is the network pathname of the file, + as is needed in the general case if the file is to be accessed from + any node. In the case described here the pixel file could be + accessed via either IRAF networking or NFS; in the general case only + IRAF networking would work. The recommended solution is to either + use a .irafhosts file and IRAF networking, or use the imdir=HDR$pix/ + option to eliminate the network pathname. (12/19) + +dev/irafhosts + The original contents of this file contained a list of NOAO network + nodes with login information for the now defunct login 'ace' on each + node. This has been changed to the system and user independent form + + * : ? + + meaning for an attempted connection to any node (*), try to login with + the user name as used on the local host system (), prompting for + the password. I also added comments to the file describing the syntax + and usage of the file. (12/19) + + NOTE -- Since this file is now system independent and will result in + a reasonable action for any user on any node, it is no longer necessary + for each user to have a .irafhosts file unless they with to specify + the password or they wish to use a different login on remote nodes + than is used on the local node. + +unix/os/zfioks.c +unix/os/net/zfioks.c +vms/os/net/zfioks.c + Modified to add support for the "" syntax. This symbol, + appearing in the username field of a .irafhosts or dev$hostlogin + node entry, is replaced by the current login name of the user on + the client node. (12/19) + +vms/hlib/gripes.cl +vms/hlib/gripesfile +/u2/sites/sitelog.c [noao only] + 1. The site mail logging facility (used internally to the IRAF project) + was not logging mail from VMS addressed as + + To: "IRAF" ... + + The program was modified to ignore the quotes. + + 2. Modified the GRIPES facility for VMS to use the "Subject:' text + entered by the user as the subject for the VMS mail as well as in + the gripe header. Commented out the code which would append the gripe + to hlib$gripesfile, since it can be assumed that this file will not + be writable on many VMS nodes, and the code is being disposed of via + mail anyhow. (12/19) + +sys/imio/iki/oif/oifrename.x + The imio.imrename primitive was not working properly for an OIF type + image, when moving the image to a different directory. The header + file would be moved but the name of the old pixel file was being + generated improperly, causing it to fail to be moved. This would + affect not only the IMRENAME task, but any in place image operation + where the output image was created in a temporary image in the current + directory, then renamed to replace the old image. (12/19) + +sys/imfort/imps3r.x + This routine would appear to function correctly, but when used to + output a 3 dimensional section, would replicate the first line of + the input section to fill the first output band, then fill the second + output band with the second line of the first input band, and so on + (the pointer into the input section was being incremented in the + outer, rather than inner, loop!). All other IMFORT 3-dim i/o routines + were checked as well, but the bug was present only in the one routine. + (12/20) + +pkg/images/tv/display/t_display.x + Modified the code which output the WCS file to: + 1. Take account of reduced dimension sections such as [5,*,*], + defining the WCS relative to the two dimensional section specified in + such a case. + 2. Fixed a bug (oversight) which would cause the WCS matrix being + output to be incorrect if the image were loaded anywhere but at + xcen=ycen=0.5. + 3. Output greyscale transformation information in addition to + the spatial information already output. (12/20) + +sun/imtool.c [SUN/IRAF] + 1. In constant coordinate readout mode, will now print the intensity + of the pixel underneath the cursor, in addition to the x,y values + already output. The pixel intensity is given in image intensity units + if the display transformation was linear, in display pixel units + otherwise. + 2. The display window can now be resized without affecting cursor + readout or control, or the visibility of the WCS coordinate output + box. If the displayed image is loaded into the upper left corner of + the imtool window, the window may be resized to exactly fit the + displayed image regardless of its shape. + 3. The gclear function in the setup panel (graphics clear) now works + properly. (12/20) + +-------------------------------------- +All systems updated (lyra, tucana, orion, irafx@draco). (12/20) + +sun/imtool.c [SUN/IRAF] + 1. If the cursor is positioned to an area of the display window which + has not been loaded with image or colorbar data, the pixel value is + output as 0. rather than some miscellaneous fictious value. + 2. If the pixel value is being output in raw display units for some + reason (e.g., because the WCS file could not be read, or a nonline + greyscale transformation was used to load the image), the pixel value + is displayed as an integer to flag this condition for the user. + 3. Added an option to make the display window background color (the + color to which the window is set when the image is cleared) black, with + white being the default as before. Settable via either a command line + argument or the setup panel. (12/21) + +dev/hosts +dev/termcap +dev/graphcap + Changed the names of the logical node names "print" and "plot" to + "lpnode" and "plnode" (line printer node and plotter node). The node + name "plot" was no longer working due to the recent modification of + the networking code to permit logical node names to be defined in the + environment; "plot" is already defined in the environment as a logical + directory. (12/22) + +sun/imtool.c + Decreased the cursor gap from 10 to 6 pixels in response to a user + complaint that it was hard to center the cursor precisely on objects + due to the gap being too wide. (12/24) + +sun/screendump.c + 1. The output image is now fractionally scaled to fill the page. + Formerly an integer scale factor was used in the hopes that this would + be faster (it permits simple pixel replication), but there is little + speed difference, and having the output always scaled to fill the + page is nicer. + 2. The screendump code now knows about devices like the 3/110 and 3/60 + which have 10 bit frame buffers (8 bit color plus 1 bit overlay plus + 1 bit overlay enable mask). Hence, textcopy, graphcopy, and screencopy + will now work for all current Sun workstations. (12/24) + +sun/gterm.c +sun/gterm.man +sun/imtool.c +sun/imtool.man + 1. Incremented the GTERM version number to V1.2 and updated the + manual page. + 2. Added a "pan" capability to IMTOOL. Provided that the display + window is smaller than the image, the middle mouse button may be + used to mark a position to be moved to the center of the display + window. Panning is either instantaneous or via a smooth scroll; + the latter is selected by holding the control key down while pressing + and releasing the middle mouse button. (12/26) + +pkg/images/tv/display/sigl2.x +pkg/images/tv/cv/sigl2.x + Fixed a short/int datatype mismatch bug in a call to adivks. The bug + had already been fixed in plot/crtpict/sigl2.x (the only other copy of + this routine I know about), but evidently the bug fix had not been + propagated to the other routines. (12/28) + +unix/os/zfiobf.c [SUN/IRAF] + Added support for FIFO (named) pipes, as are used by the display server + code (gdev$zfiogd.x) on Sun/IRAF. + 1. Files opened read only or write only are opened with the O_NDELAY + flag, necessary to prevent the client process from blocking until the + server makes a connection (which in my case was not until the client + requested the connecton, leading to deadlock). + 2. A close on a FIFO opened for reading by the client was causing the + error EPERM (insufficient permission) to be returned for the close. + This was highly inconvenient, so I modified ZCLSBF to ignore this + error. Hopefully the file descriptor is actually getting freed; I did + not take the time to check. (12/28) + +sun/gtermio.c +sun/gterm.esc +sun/gterm.man + Added support for the ESC ENQ function to GTERM. This was necessary + to get GTERM to work for FORTH graphics. (12/30) + +sun/gterm.c + Looked into a bug reported by Joe Schwarz at CFA. While in cursor + mode, the mouse was moved into the gterm text window and the user + tried to exit the program (implot) by typing the usual 'q'. This was + ignored, but typing 'q' three times would do the trick, but would + leave GTERM in a funny state, requiring a setup-reset to recover. + + The reason typing 'q' three times would terminate cursor mode + is because this produces a six character sequence ending with CR, + which is what a tek cursor sequence is. The reason GTERM got + confused was because it thought the cursor read was still in effect, + since cursor mode was not exited normally. + + The suggested fix was to make input equivalent in either window, + hence typing 'q' in the text window would terminate the cursor loop + and applications program. The problem is that a valid cursor sequence + requires an [x,y] position as well as a keystroke, and the cursor + position for a cursor read is invalid when the mouse is in the text + window. Of course in this case the application does not need the + [x,y] to do a quit, but there is no way that the terminal could know + that. Nonetheless, GTERM should not get into a funny state, so I + fixed the bug by having the text window discard ascii input entered + in the text window during a cursor read (rather than passing it on to + the application program as it was). (12/30) + +pkg/images/tv/display/iispio.x + In testing the new display code (to be documented here shortly) I + found that it was easy to lose datastream synch to the display server + (an IIS or IMTOOL), when a user interrupt would arrive while a data + transfer was in progress, i.e., due to the user interrupting the + display program while loading the display. I had to add calls to + intr_disable,intr_enable around the code which does i/o to the + display, to ensure that complete data packets are always sent. + This makes the display process immune to interrupts, but if an + interrupt arrives during a data transmission it may be ignored, + making it necessary for the user to type interrupt several times to + abort the task. (12/31) + + TODO: Modify the interrupt disable/enable code to queue interrupts + for later delivery, rather than discard interrupts as at present. + +sys/fio/zfiott.x + Made some changes affecting the 'playback' feature of STTY: + 1. Fixed a bug that would cause logfile lines containing only control + directives but no data, i.e., \{...\} alone on a line, to cause + premature EOF on the logfile, terminating playback. + 2. There was a bug in the ztt_query code, used to process and execute + \{...\} control directives. In effect, the way the code was written + embedded playback control directives could not be used while reading + text in raw mode. + 3. Carriage return as well as space bar may now be used to continue + execution following a verify-pause. (1/1-1988) + +pkg/language/doc/stty.hlp + Extensively revised the help page for STTY (the terminal driver), + mostly to add a discussion of the playback facilities. (1/1) + +dev/graphcap +local/sun/imtoolrc +unix/hlib/install + 1. Replaced the IMTOOL device entries in graphcap by a set of a + dozen or so logical device entries imt512, imt800, imt1024, imt2048, + etc., defining the set of defined frame buffer configurations for + the IMTOOL display server (this is site configurable). + 2. To local/sun (Sun/IRAF), added the file imtoolrc, which is read + at startup time by IMTOOL to get the set of defined frame buffer + configurations. This file is intended to be copied into a public + library at 'install' time, e.g., /usr/local/lib/imtoolrc. The entries + in this file must have corresponding entries in the graphcap. + 3. Modified the install script to install the imtoolrc file in + /usr/local/lib. (12/26-1/3) + +sys/imio/imdmap.x + Modified to save the value of the graphcap parameter 'cn', the IMTOOL + frame buffer configuration number (if defined) in IM_LEN(im,3). + This is then picked up by the DISPLAY code and passed on to the + display server to specify the frame buffer configuration to be used. + (12/26-1/3) + +unix/gdev/zfiogd.x + Deleted the IMT512 and IMT800 logical device entries, and added a + capability to parse the display device frame buffer width and height + from the DD string. (12/26-1/3) + +local/sun/imtool.c +local/sun/imtool.man +pkg/images/tv/display/iis.com +pkg/images/tv/display/iisers.x +pkg/images/tv/display/t_display.x + A new, and hopefully final (for a while) version of the IMTOOL display + server has been completed and installed, along with a few corresponding + changes to the DISPLAY task. The latter will still work for ordinary + IIS displays as well as with IMTOOL. The major revisions were the + following. + + 1. The scheme of a "standard" configuration (512 square) and a "large + format" configuration (800 square) has been scrapped and replaced by + a more general scheme. There can now be up to 64 different frame + buffer configurations defined at any one time, with no restrictions + upon the sizes of the frames other than that they be defined when + IMTOOL is started up (a SunView restriction also requires that the + frame width be even). An "imtoolrc" file, with corresponding entries + in the IRAF graphcap, is used to define the possible frame buffer + configurations for both IMTOOL and IRAF. These may be modified or + extended by a site, and the user may have private, custom copies if + desired. + + The default configuration file is stored in /usr/local/lib/imtoolrc. + The contents for our system are as follows at present: + + # IMTOOL -- Defined frame buffer configurations. Note... + # is only a starting point, and may be modified during... + # values are preferred. The configuration numbers may... + # but must be unique and in the range 1-64. + # + # Format: configno nframes width height + + 1 2 512 512 # imt1|imt512 + 2 2 800 800 # imt2|imt800 + 3 2 1024 1024 # imt3|imt1024 + 4 1 1600 1600 # imt4|imt1600 + 5 1 2048 2048 # imt5|imt2048 + 6 1 4096 4096 # imt6|imt4096 + 7 1 4096 1024 # imt7|imt4x1 + 8 1 1024 4096 # imt8|imt1x4 + 9 2 1142 880 # imt9|imtfs full screen... + + 20 2 384 576 # imt20|imtgec GEC CCD detector format + 21 1 3040 976 # imt21|imtkpca KPCA detector format + + The frame size to be used is defined by the client program (the DISPLAY + task) at image load time. In the case of IRAF, this is done via the + stdimage environment variable, e.g., + + cl> reset stdimage = imt1600 + + This is converted into the frame buffer configuration number (via the + 'cn' parameter in the graphcap entry) and passed on to IMTOOL via a + a few unused bits in the otherwise IIS compatible datastream headers. + + 2. Multiple frame buffers are now supported by IMTOOL. As far as + IMTOOL is concerned there could be any number of frame buffers (subject + to memory limitations), but DISPLAY task limitations currently limit + us to up to 4 frames; this will be plenty for most applications. + + 3. The display window is now completely decoupled from the frame buffer + size, i.e., the same modest sized window is typically used regardless + of the frame buffer size, relying upon pan to access the full frame. + + 4. A frame blink option has been added. Frame selection for viewing + may be done either under program control or with the mouse or keyboard + in any of several ways. + + 5. A "smooth pan" feature has been added. This smoothly pans the + image to the new center, insteadof going there in one step. The big + step pan is still the most useful, however. + + 6. The colorbar is now implemented differently, allowing it to always + be visible on the screen regardless of the window size or pan offset. + The colorbar may be turned off an on via the setup panel if desired. + + 7. The setup panel and frame menu now contain a number of new items, + e.g., register all frames, turn blink on and off, enter a list of + frames to be blinked, adjust the size of the display window to fit + the full frame, display the next frame in sequence, save the current + frame in a Sun rasterfile, load the current frame from a Sun + rasterfile, and so on. + + 8. The setup panel has been made shorter so that it will fit "behind" + most display windows. If you use it frequently, it may be most + convenient to leave it open all the time, and use the L5 function + key to display it (move it to the front) when needed. It can also + be repositioned to an otherwise unoccupied area on the screen if + desired. + + 9. Output of the pixel intensity in cursor readout mode was added in + an earlier revision. + + 10. I/O to the server is now bidirectional (image data can be read + back as well as written to the server), allowing use of the erase- + option in the DISPLAY task to write into subregions of the frame + buffer, e.g, for mosaics. Only the last WCS is saved. + + 11. The manual page has been updated. + + The parameters for the different frames, e.g., monochrome or + pseudocolor, slope and offset of the transfer function, pan offset, + WCS, coordinate lists, etc., are independent. When you change frames + all the values appropriate for that frame are set. + + There were many other changes and bug fixes probably not worth noting + here. Basically, while the prototype display server is still pretty + limited in some ways (full interaction with applications programs is + not supported, no graphics and text overlay support), it now does the + most basic things fairly well. Probably all of this will change in + six months or so when SunOS 4.0 comes out - the NeWS/X in this will + probably trash both GTERM and IMTOOL, and when the features in IMTOOL + and the X based CFA XIMAGE are merged into the final display server. + Read the new manual page for additional details. (written 1/3) + +------------------------------------ +Updated tucana, orion, irafx@draco from lyra. (1/6) +Updated pegasus and octans from tucana. (1/7) + +sun/screendump.c + For Sun rasterfile output, the colortable length was being output as + NGREY*3 (256*3) rather than NGREY, due to a confusion about the use + of the length parameter in rasterfiles (usage differs in the rasterfile + header and in a colormap struct). This is a bug, but the generated + rasterfiles would actually be legal rasterfiles, since the colortable + length was being recorded correctly - it was just that more than 256 + bytes of data were being stored for each colortable. (1/7) + +sun/imtool.c +pkg/images/tv/display/iisers.x + 1. In imtool.c, added some protection against being passed a negative + or zero config number. + 2. In iisers.x (DISPLAY), added a max(0,... to the code which encodes + the frame buffer configuration number in the TID field, to avoid + passing a config of -1 to the display server, if the 'cn' field is + absent from the graphcap entry for the device for some reason. (1/7) + +sys/etc/symtab/mkpkg +sys/etc/symtab/README +sys/etc/symtab/stsize.x + +sys/etc/symtab/zzdebug.x + Added a new routine STSIZE to the symbol table package. The new + routine is used to determine the number of chars of file storage + required to store the symbol table in its external form, e.g., before + a call to STSAVE to save the table in a file. (1/8) + +local/sun/imtool.c + In remark_objects(), modified a test used to test if the next file + line begins with a number to permit the first character to be a minus + sign, e.g., a negative number. (1/15) + +sys/osb/shift.c + There was an error in the way the shift-negative case was handled. + Replaced (a >> bits) by (a >> -bits) in the three routines. (1/27) + +unix/as/zsvjmp.s +unix/os/zdojmp.c + +unix/os/mkpkg + Currently one of the hardest parts of a UNIX port is writing the + ZSVJMP/ZDOJMP routines, since the routines are complex and must be + coded in assembler. In an attempt to simplify this task I have + rewritten the routines to interface to the standard C library + setjmp,longjmp routines. Some assembler code is still required, + since setjmp cannot be called as a function, but must instead be + called in the context of ZSVJMP by a jump. This appears to work, + but more testing is required. At present I am making the change + only on tucana (the Sun/3 - MC68020). (1/29) + +unix/os/zgcmdl.c + This routine is called from IMFORT (host level) programs to get the + command line as a string. Since the routine is in a support library + and does not have ready access to the main, it cannot access ARGC and + ARGV directly, but must instead use a heuristic to guess where the + arrays are stored, relative to some well know landmark. The technique + used to do this was working on the VAX and the Sun-3, but would fail + on the Sun-4. A different heuristic was substituted which works in + all cases. In this, the well known landmark is 'environ', which points + to the environment list array. We assume that ARGC and ARGV are + stored immediately before the environment list array. This holds on + all the machines currently at hand, but the routine should be regarded + as potentially host system dependent. (1/31) + +unix/hlib/mkpkg.sf.SUN4 + Added an entry to the list of files requiring special compilation due + to optimizer bugs. In file imfort$imemsg.x, the length of a Fortran + character*(*) string is passed as an argument in an input register. + The register value has been modified by the time the register is later + used to pass the string length on to _i_len (the F77 len intrinsic + function), causing an incorrect string length to be computed, resulting + in string overflow in a subsequent call to F77PAK. (1/31) + +local/sun/imtool.c + IMTOOL will now print "cannot be used on monochrome displays" and exit, + rather than dump core on a segmentation violation during startup. + (1/31) + +unix/boot/wtar/wtar.c [lyra,tucana] +vms/boot/wtar/wtar.c + The WTAR program was incorrectly writing a short block at the end of + the tar file, contrary to the tar format specification. Now it always + writes a full block. (2/4) + +sys/mkpkg + In the module libmain.o, changed the + + $set XFLAGS = "-c" + to + $set XFLAGS = "-c $(HSI_XC)" + + since this entry compiles os$zmain.c, which is part of the HSI. (2/4) + +local/sun/imtoolrc +dev/graphcap + Added some more entries to the site-specific section of the imtoolrc + file (predefined frame buffer configurations). (2/5) + + # Some site specific formats for NOAO. + 20 2 384 576 # imt20|imtgec GEC CCD d... + 21 1 3040 976 # imt21|imtkpca KPCA dete... + 22 1 1520 128 # imt22|imt2df1 2D-Frutti + 23 1 1520 256 # imt23|imt2df2 2D-Frutti + 24 1 1520 512 # imt24|imt2df5 2D-Frutti + 25 1 1520 960 # imt25|imt2df9 2D-Frutti + +dev/termcap +dev/cachet.dat +pkg/cl/builtin.c +pkg/system/help/t_help.x +sys/libc/cttset.c +sys/gio/mkpkg +sys/tty/mkpkg +sys/tty/ttygsize.x + +sys/tty/ttyread.x + +sys/etc/mkpkg +sys/etc/pagefiles.x +sys/etc/sttyco.x +sys/etc/xttysize.x + + Modifications and extensions were made to STTY and the TTY package to + support terminals which can dynamically change size at runtime, e.g., + workstation windows. This was done using a status query, i.e., an + escape sequence is written to the terminal commanding it to send the + screen size, and then the response is read back and decoded. This + technique raises the possibility of blocking if a character is lost + (easily recovered from by having the user type return), but has the + advantage that it works over remote network connections to possibly + foreign host machines. + + 1. The new routine XTTYSIZE was added to ETC, and calls to this routine + were added in pagefiles.x and t_help.x. XTTYSIZE recompute the screen + size and resets the values of the ttyncols and ttynlines environment + variables. If the terminal supports querying of the screen size, the + screen size is determined by such a query, otherwise the default values + given in the termcap entry for the device are used. This routine is + not intended to be called in regular applications code; applications + should continue to access the environment variables directory, or use + TTYSTATI (which does the same thing). This will still work, since once + any system task like PAGE or HELP is called after the screen size + changes, the environment variables are updated, and all subsequent + tasks which use these variables automatically pick up the new screen + size. + + Note that calling XTTYSIZE globally updates the values of the ttyncols + and ttynlines environment variables for the entire process tree. If + the procedure is called from within a task executing in a connected + subprocess, the task posts a command to the STTY task in the CL which + is where the actual querying of the terminal takes place. + + 2. The new routine TTYGSIZE and the associated routine TTYREAD were + added to the TTY package. These are the low level system routines + called by XTTYSIZE (when called from the STTY task in the CL) to do + the actual i/o to the terminal to determine the screen size. Two new + termcap parameters are defined to describe terminals which support + this capability. + + qs Command sequence to be sent to the terminal to query + the screen size in characters. + + wh A string used as input to the pattern matching + facilities to determine when the full response to + the screen size query has been received, as well as + to decode the response. + + The qs capability is a simple fixed control sequence. The wh string is + more complicated, serving both as a pattern and as a decoding format. + For example, here is the entry for the GTERM SunView virtual graphics + terminal: + + :qs=\E[18t:wh=\E\[8;%H;%Wt: + + The %H and %W fields tell where the screen width and height appears + in the response sent by the terminal. All other characters appearing + in the string must match what is actually sent by the terminal. Note + that this string is used as input to the pattern matching code, hence + all the usual pattern matching characters are recognized (the %H and + %W fields are a special case, and are preprocessed into sequences of + the form "%[0-9]*" before patern matching takes place). Any data read + from the terminal before the pattern is matched is probably type-ahead, + and is pushed back into the input stream minus the matched substring. + + 3. A new option "resize" was added to the STTY task, i.e., to sttyco.x + in ETC. "stty resize" causes the values of ttyncols and ttynlines to + be reset; the terminal is queried for the screen size if such queries + are supported, otherwise the termcap defaults are used. This feature + is not really intended for the user (although it can be used), and was + provided mainly for XTTYSIZE. Setting the terminal type with STTY will + also cause the screen size to be queried if possible. + + For example, + + cl> stty resize show + gterm40 ncols=80 nlines=47 + + will cause the terminal to be queried for the current screen size, + update the environment accordingly, with the current settings being + displayed as shown. + + 4. In LIBC and ETC, the calling sequence for the STTYCO procedure was + modified to add the arguments "ttin" and "ttout", the file descriptors + of the input and output streams to the terminal. Formerly STDIN and + STDOUT were assumed. + + 5. In the termcap, the logical device entries 'gterm24', 'gterm34', + 'gterm40', etc., were all converted into aliases for 'gterm'. All are + equivalent now, and use of only 'gterm' is recommended. The .ttyswrc + function key definitions, used to quickly change the screen size, + are retained as they are still useful for quickly resizing the screen, + but it is no longer necessary to run STTY after a resize to set the + new screen size. A new entry 'gterm-nqs' was added for using GTERM + with auto screen size querying disabled. This may be desirable when + working over a noisy modem connection, which could prevent the screen + size from being determined reliably. + +sys/gio/gpagefile.x + Modified to call gdeactivatews and greactivatews only if the + workstation is activated when the routine is called. (2/6) + +sys/fmtio/parg.x + When printing negative integer numbers of type short or char in octal + or hex, the number of digits actually printed would correspond to type + long, with way more sign extension than is valid for a machine word. + Added some special case code to eliminate the extra sign extension, + which is only an artifact of the use of GLTOC to encode the number. + (2/7) + +unix/hlib/login.cl +vms/hlib/login.cl + Modified to print the message + + set terminal type to U_TERM... + + immediately before executing stty U_TERM, to warn the user that the + terminal type is being set to the indicated type. (2/10) + +pkg/images/tv/display/t_dcontrol.x + Added some code to set the values of iis_[xy]dim and iis_config from + the graphcap entry. (2/11) + +sys/tty/ttygsize.x + Disabled the screen size query when STTY login or playback mode is in + effect. (2/12) + +dev/termcap +dev/cachet.dat + Making the gtermNN (gterm24,gterm34,etc.) simple aliases for 'gterm' + was a mistake. When autosizing is disabled the termcap entry + determines the default screen size, hence the separate entries are + still needed; they have been restored. The gtermXX entries are set + up to disable autosizing, hence entry 'gterm' must be specified to + make use of the autosize feature. (2/17) + +pkg/cl/eparam.c +sys/libc/cxttysize.c + +unix/hlib/libc/xnames.h +vms/hlib/libc/xnames.h + 1. Added a new routine c_xttysize() to the LIBC package. + 2. Modified EPARAM to call c_xttysize to read the screen size, + allowing autosizing. (2/17) + +unix/boot/rtar/rtar.c +vms/boot/rtar/rtar.c + This code contains a heuristic used to determine whether a file on the + tape is a text or binary file, which it must know in order to create + the file on disk on systems like VMS. This heuristic was failing for + FITS files, which have an ASCII card iamge header which resembles a + text file except for the lack of line delimiters. I had to make the + same change to the RTAR code as was made to ZFACSS some time ago, for + it to recognize this case of a binary file. (2/17) + +pkg/system/help/t_help.x + XTTYSIZE is now called only when paging the output and the output is + not redirected, to avoid the terminal query when screen oriented + terminal output is not desired (as in a pipe, or in a background job). + (2/17) + +iraf/sys/fmtio/dtoc.x + The input format-code argument (fmt) was being used directly in a + logical test, rather than the internal lower case version, causing + the routine to be partially case sensitive to the floating point + format code character (efg etc.). (2/19) + +unix/os/zfacss.c + When called to test the file type, this routine would hang when called + on a unix FIFO type file, due to the blocking-open associated with this + type of file. The routine stats the file and only looks at it if it + is a regular file, but it was unnecessarily opening and closing the + file whether or not it needed to read from it. (2/19) + +--------------------------------- +Version 2.6 of Sun/IRAF was frozen and taped. (2/24) + +sys/fmtio/gstrcat.x + Fixed a bug in gstrcat - the string length being returned was one + greater than it should be. (2/25) + +sys/gio/nspp/portlib/flash1.f +sys/gio/nspp/portlib/flash2.f +sys/gio/nspp/portlib/flash3.f +sys/gio/nspp/portlib/flash4.f +sys/gio/nspp/portlib/flushb.f +sys/gio/nspp/portlib/preout.f +sys/gio/nspp/portlib/z8zpii.f +sys/gio/nspp/sysint/packum.x +sys/gio/nspp/sysint/loc.x +sys/gio/nsppkern/writeb.x + The NCAR code used a function LOC, evidently a non-standard intrinsic + function on the ancient Cyber machine the code was originally developed + on. We ported the code by emulating the function, but it turns out + that the new Fortran compiler on the Sun-4 has its own LOC intrinsic + function which doesn't behave quite the same way, hence the 'stdplot' + gio kernel was failing on the Sun-4. I fixed the problem by changing + all LOC references to LOCI. (2/28) + +sys/vops/mkpkg + Horrible bug! A user reported that the VOPS routine aiftrx (inverse + fourier transform) was not working properly. Careful testing showed + that the code was correct, but that the combiled object in the VOPS + library did not agree with the code, even though the module dates + looked ok! This turned out to be due to a bug in the mkpkg file, + which has probably been there since the file was written around 1985. + In the $ifolder clause, the actions were "cp file.x ak", which is a + UNIX, not MKPKG, command, which MKPKG was evidently ignoring every + time it tried to updated the ./AK versions of the files. This was + changed to "$copy file.x ak/file.x", and all is well. (3/2) + +unix/boot/spp/mkxc.csh + Renamed to mkxc.sh. (3/9) + +unix/hlib/libc/kernel.h +unix/os/irafpath.c + +unix/os/mkpkg +unix/os/zalloc.c + I added a new utility routine IRAFPATH to the UNIX/IRAF kernel. Given + a filename, this routine searches the standard IRAF runtime directories + for the file, and returns the absolute system pathname of the file if + found. In particular, on hosts like the Sun which can have multiple + bin directories for different architectures, the routine will find the + (HSI) executable appropriate for the current host. (3/10) + +unix/boot/spp/xc.c + Modified XC to use IRAFPATH to determine the pathnames of the XPP and + RPP executables. (3/10) + +mkpkg +unix/mkpkg.sh +unix/hlib/install [SUN/IRAF only] +unix/hlib/irafuser.csh + For Sun/IRAF, modified the HSI to permit multiple copies of the HSI + executables. This is necessary to be able to use a single copy of IRAF + to support multiple incompatible binaries, e.g., sparc and mc68020. + + 1. To the 'unix' directory (host$), added subdirectories bin.sparc and + bin.mc68020. The second field is what is returned by "mach" on a Sun. + The bin directory appropriate for a particular node is called HBIN, + and is defined as such in the irafuser.csh file, although HBIN need + not be defined to run the system. + + 2. All the .e files formerly in HLIB are now kept in HBIN. The .csh + executable files are still in HLIB, since we can use one copy for both + architectures. Runtime selection of the appropriate HBIN is via + symbolic links set by INSTALL (see below), or via the IRAFPATH routine. + + 3. The INSTALL script was extensively modified to support multiple + HSI binaries. A Sun-4 server configured for both sparc and mc68020 + hosts will have separate /usr.SPARC and /usr.MC68020 directories; + these are the "/usr" directories for the two types of machines. + IRAF can be installed anywhere, provided it is on a disk partition + which can be accessed from all nodes, either directly or via NFS. + Each machine type is assumed to have its own local/bin directory, + e.g., /usr/local/bin, where /usr is linked to /usr.MACH. + + Since root can only modify files on the local node, the INSTALL script + must be run on the central file server. To install the local (sparc) + copy of IRAF, one runs INSTALL in the usual way, e.g., + + % cd $hlib + % install + + To install the MC68020 version of IRAF on the fileserver, for access + by all Sun-3 nodes, + + % cd $hlib + % install -m mc68020 + + For this to work properly, one must carefully enter the correct + pathnames, since the defaults will be for sparc rather than for + the mc68020, e.g., + + iraf root can be made the same for both systems + imdir can be made the same for both systems + tmp can be made the same for both systems + + /usr/bin /usr.SPARC/bin or /usr.MC68020/bin + /usr/local/bin /usr.SPARC/local/bin or /usr.MC68020/local/bin + + When run on the Sun-4 host, /usr/bin is the same as /usr.SPARC/bin, + and /usr/local/bin (if there is one) is /usr.SPARC/local/bin. + For the Sun-4 installation, the script will put links to the + host$bin.sparc executables into /usr/bin, and install the suntools + executable into /usr/bin. For the Sun-4 (MC68020) installation, + the links in /usr.MC68020/local/bin will point to host$bin.mc68020, + and the MC68020 suntools executable will go into /usr.MC68020/bin. + + As before, although all versions of the executables are maintained + online and any version of the system may be executed, only one version + of the objects and libraries is online at any one time, and the system + must be reconfigured before a version of the system can be updated. + For example, assume the system is currently configured with the SPARC + objects. Typing + + % cd $iraf + % mkpkg f68881 + + would reconfigure the system for the f68881 binaries. One could then + log onto a Sun-3 diskless node and update the f68881 binaries, after + which the SPARC binaries could be restored with mkpkg sparc. + + A boostrap of the HSI will automatically update the binaries in the + appropriate HBIN directory. If a single directory is subsequently + updated, however, the new executable will be placed in HLIB, and after + testing one must manually move the executable to the appropriate HBIN + directory. (3/10) + +unix/sun/Makefile +local/sun -> unix/sun + 1. The custom suntools sources (formerly local/sun) have been moved + to unix/sun. + 2. The suntools.e executables are now installed in the host$bin.XX, + rather than in LOCAL. (3/10) + +local/.login + FLOAT_OPTION is not used for the Sun-4 (it will cause an error if + defined), hence this is now conditionally defined depending upon the + machine type. (3/10) + +local/notes.orion - +doc/ports/sun4_sep87.doc + Appended the contents of the "notes.orion" file to the record for the + Sun-4 port, and deleted the orion notes file, which we won't need + anymore. (3/10) + +dev/hosts + Changed the iraf/bin in the entry for orion to iraf/bin.sparc. Updated + on all nodes. (3/10) + +unix/gdev/sgidev/sgidispatch.c +unix/gdev/sgidev/mkpkg.sh +unix/hlib/sgi.tab - + Simplified SGIDISPATCH considerably by using IRAFPATH. The "sgi.tab" + file is no longer used; the translators may be anywhere irafpath can + find them, but are expected to reside with the other HSI executables. + (3/11 SRo) + +unix/os/zfioks.c + I made an attempt to use RCMD and the /etc/hosts.equiv mechanism to + implement connections to friendly hosts in the local network without + requiring login authentication. Unfortunately, for this to work the + process calling RCMD must have uid=root, and it is not possible to + set root ownership on the IRAF executables, hence IRAF cannot use the + equivalent host mechanism (at least, without some sort of intermediary, + which would be too inefficient). (3/12) + +unix/boot/spp/rpp/rpprat/defs +unix/boot/spp/rpp/rppfor/*.f + I had a problem with "too many characters pushed back" in a compile, + and upon investigation discovered that the pushback limit was set to + 100 characters, a very small amount. I increased this and a number + of other size limiting parameters affecting macros - the maximum + definition size is now 2048, the max pushback is 3192 chars, and the + total amount of storage reserved for definitions was increased by + 50%. (3/13) + +unix/os/zfiopl.c +unix/os/zfiolp.c + The ZOSCMD primitive, used to send commands to the host shell, provides + filename arguments which may be used to save any stdout or stderr + output in a file. If the filenames are omitted the stdout and stderr + are left alone, i.e., left connected to the streams inherited from + the parent process. The bug occured in the printer and plotter drivers + ZFIOLP and ZFIOPL, when called from a connected subprocess, i.e., a + child process of the CL. In the case the standard i/o streams are + the IPC channels to the CL, and any output from the shell would be + sent to the CL, possibly corrupting the CL IPC prototol. I changed + the calls to ZOSCMD in the two drivers (in the dispose spoolfile code) + to open /dev/tty for shell output, rather than inheriting the streams + from the CL, if the process is a connected subprocess. (3/25) + +pkg/images/tv/display/t_display.x + Modified the DISPLAY program to accept either "wcsdir" or "WCSDIR". + (3/28) + +--------------------------------- +Updated all Sun/IRAF systems. (3/25,28) + +unix/as/zsvjmp.s +unix/os/zdojmp.c [VAX only] +unix/os/mkpkg + Installed the more portable version of ZSVJMP/ZDOJMP, which transform + into calls to the UNIX setjmp/longjmp, in the BSD (VAX) UNIX/IRAF HSI. + The original code was more compact and faster for the VAX, but the BSD + code is often used as a starting point for ports to new machines, and + the more portable version is a much simpler technique to code. (3/28) + +sys/fmtio/ctowrd.x + This routine was returning an incorrect function value, the number of + non-white characters converted from the standard input. There was + also a problem with how quoted strings were handled. (3/31) + +sys/osb/miipak8.x +sys/osb/miipak32.x +sys/osb/miipak16.x +sys/vops/achtgen/*.x + Added entries for TY_POINTER and TY_STRUCT to the TY_INT switch in the + case statements (one for each SPP datatype) in these routines. (4/2) + +sys/etc/symtab/stalloc.x + Modified to align to double, rather than int, buffers allocated in the + symbol table. (4/2) + +--------------------------------------- +IRAFX updated. (4/3) + +unix/portkit + +unix/mc68000 - + Replaced the old MC68000 directory by a new directory PORTKIT, + containing updated notes and replacement source files for porting + the 4.3 BSD version of UNIX/IRAF to new machines. (4/4) + +unix/os/irafpath.c +unix/boot/bootlib/ossysfile.c +unix/boot/spp/xc.c + 1. In BOOTLIB, modified os_sysfile() to call irafpath(). + 2. In XC, replaced the calls to irafpath() with calls to os_sysfile(), + so that all file-searching is done through this one call. + 3. Modified irafpath() to add support for searching user defined + libraries, in addition to the default action of searching the + standard libraries. To make use of this feature the user must + define the environment variable IRAFULIB, the value of which + consists of a whitespace delimited list of directory pathnames + (trailing underscore optional). + + The purpose of this change is to provide greater flexibility for + debugging software developed outside of the standard system, e.g., + during testing and before the software has been installed. This + allows VOS software which includes style include file + references to be tested outside the system without having to modify + the installed versions of the referenced include files. It is not + intended as a means of adding new system libraries to the standard + search path. (4/5) + +pkg/images/imdebug/mkpkg + Modified to produce the local executable "xx_imdebug.e" rather than + "x_imdebug.e", with the named changed to the latter at install time, + as per current standard practice. (4/7) + +sys/vops/mkpkg +sys/vops/tf/mkpkg +sys/vops/aveq.gx + + Added a new vector,vector->scalar operator, AVEQ, used to compare two + vectors for equality, returning a boolean result. (4/11) + +unix/boot/mkpkg/tok.c +vms/boot/mkpkg/tok.c + 1. Modified MKPKG so that system file names of the form "" can + appear in the argument lists of $IF directives. (4/14) + 2. Generalized further to include most other macro statements. (4/15) + +unix/hlib/install +unix/sun/imtool.c [SUN/IRAF] +unix/sun/mksuntool.csh + 1. Modified IMTOOL to use "HOME" rather than "home" as the user login + directory. + 2. Fixed a bug in mksuntool.csh that would cause it to unnecessarily + rebuild the suntools subdirectory. + 3. Updated the Sun/IRAF INSTALL script, changing the pathname of the + imtoolrc and manual page files from $iraf/local/sun to $iraf/unix/sun, + to reflect the recent move of the code to the HSI. (4/16) + +unix/sun/imtoolrc +dev/graphcap + Added two new IMTOOL logical devices: + + imtcryo 512x800 + imtgcam 348x800 (4/16) + +unix/boot/spp/rpp/rpprat/defs +unix/boot/spp/rpp/rpprat/declco.r +unix/boot/spp/rpp/rppfor/declco.f + Modified RPP to conditionally output the IMPLICIT NONE statement + (a nonstandard extension to Fortran) in every subroutine or function + declaration. The define IMPNONE in the 'defs' file should be + uncommented and the Fortran for declco.f generated, to enable this + feature. This was added for Convex/IRAF, but should be of general + utility since IMPLICIT NONE is a common extension. (4/17) + +vms/* + Updated the VMS/IRAF HSI. Copied to lyra and did a diff/merge, leaving + an up to date copy on lyra. About the only thing affected was the RPP + sources; everthing else has been kept up to date. (4/17) + +---------------------------- +Updated IRAFX@draco. (4/17) + +unix/hlib/mkpkg.sf [VAX-UNIX/IRAF] + Commented out the special file list entries for the aadd*, amap*, and + awsu* VOPS entries. The hand optimized versions of these routines + date back to the early days of BSD UNIX (4.1), when the compiler was + not so good, but nowadays the optimizer is good enough so that they + are probably not worth maintaining. (4/20) + +pkg/images/tv/display/dsulut.x +pkg/images/tv/display/display.h +pkg/images/tv/display/t_display.x + Added a capability for a user defined lookup (intensity transformation) + table. (Coded by SH). (4/21) + +sys/gio/stdgraph/stgrtty.x +sys/gio/stdgraph/zzdebug.x + The routine which reads from the status line was modified to echo \r\n + when either \n or \r is typed in by the user to terminate an input line + of text. Since writing a newline to the status line erases the line, + this will cause the text input up to that point, e.g., a prompt + followed by the user's response, to be cleared, giving the user some + positive feedback to indicate that the newline was seen. Clearing the + line is also consistent with the model of the status line as a one-line + terminal screen. This change to the semantics of status line i/o may + affect some programs, although it should be harmless. (5/1) + +--------------------------------- +Updated tucana and irafx@draco. (5/1) + +sys/fio/vfntrans.x + Change directory commands such as the following would not work: + + cl> cd imio.pl/plio + + This turned out to be due to the filename mapping code, which was + losing the .pl when it occurred as part of a subdirectory name + followed by a /. The code was changed so that any . delimited fields + occuring in a / delimited subdirectory name are considered part of + the root subdirectory name, rather than being parsed off and treated + as filename extensions. (5/2) + +sys/mtio/mtalloc.x + Fixed a typo in the file header. (5/9) + +unix/sun/imtoolrc + Changed the frame buffer width for the GEC format from 384 to 386. + (The actual width is 385 but imtool requires that it be rounded to + an even number; a user complained about the missing column). (5/10) + +unix/os/alloc.c +unix/os/getproc.c + +unix/os/mkpkg +unix/os/mkpkg.sh + Fixed a bug which would cause device allocation (magtape) to fail + over the network. What would happen is that a remote user using the + magtape would not be logged in on the local node, even though they + had a kernel server executing with the device allocated. A local + user could then reallocate and "steal" the device from the remote + user (or vice versa). This was fixed by adding code to alloc.e to + test if the given user has any processes executing on the server node + for the device. (5/10) + +unix/os/zmain.c +unix/os/zfioks.c + 1. In Sun/IRAF, if one submitted a bkg job from a CL running in a + terminal window and then subsequently selected "Exit Suntools" in the + root Sunview menu to give the parent CL the axe, the bkg CL job + would be killed too; this would not happen if one logged out of the + foreground CL before exiting suntools. This was probably due to + suntools sending SIGTERM to all processes in the same process group + as the terminal window. The fix was to modify ZMAIN.C to put a + detached process (such as a bkg CL) in its own process group. + This fixes the signal problem, and also prevents a detached process + from reading from the terminal of the foreground process, e.g., to + satisfy a password query (the detached process will now be suspended + indefinitely (SIGSTOP) if it attempts such a read). + + 2. ZFIOKS.C was modified to prevent a detached process from trying + to access the foreground process's terminal for a password query. + The server connect will fail, causing KI to attempt to access the + resource on the local node. This is questionable (it has always + been that way), but it works out well if the resource is a file on + a shared (NFS) disk, since the result will be a valid file access. + (5/16) + +pkg/softools/mktags.x + Someone suggested that we make an alphabetized index of all the + procedures in the VOS. I used the MKTAGS task to do just that, but + had to increase the size of the internal tables to accomodate such + a large number of files and procedures. (The index files are stored + in /u2/sites on lyra, and were not installed in the main system). + (5/17) + +pkg/cl/cl.par +vms/hlib/motd +unix/hlib/motd +vms/hlib/zzsetenv.def +unix/hlib/zzsetenv.def + Incremented the version number to 2.7 - will continue to note system + changes here until this version stabilizes. (5/21) + +-------------------------- +Updated tucana and irafx@draco. (5/21) + +sys/fio/nowhite.x + This procedure, used to delete whitespace from filenames, evidently + was not working at all, due to a (ch < ' ') test which should have + been a (ch <= ' '). (5/25) + +sys/gio/gascale.x +sys/gio/grscale.x + These routines were not checking for INDEF when computing the min and + max values of the data arrays. (6/2) + +unix/sun/gterm.c + Changed the default "close workstation" action to NO_ACTION. Most + people seem to be annoyed when the graphics plan automatically gets + obscured at the end of a plot, and would prefer to control the + windows manually with the keyboard function keys. (6/2) + +pkg/lists/rgcursor.x +pkg/lists/rimcursor.x + These tasks would abort if they could not GOPEN the stdgraph or + stdimage stream. This was not necessary, since may still be possible + to read either cursor even if a graphics kernel cannot be connected, + so I put iferr() conditionals around the gopen's to ignore any errors. + (6/2) + +unix/sun/Makefile +unix/sun/imtool.cursor +unix/sun/imtool.c +unix/sun/mouse.c +pkg/images/tv/display/iis.h +pkg/images/tv/display/mkpkg +pkg/images/tv/display/zzdebug.x +pkg/images/tv/display/imdrcuro.x +pkg/images/tv/display/imdrcur.x +sys/libc/mkpkg +sys/libc/cimdrcur.c +unix/hlib/libc/xnames.h +unix/hlib/zzsetenv.def +pkg/cl/mkpkg +pkg/cl/modes.c + Added a simple interactive image cursor readback mechanism (=IMCUR). + For the moment, this bypasses both cursor mode and the whole of GIO, + and goes directly to the display server to carry out a logical cursor + read. While the interface is limited, it does provide a working + =imcur, and it remains device independent (or as much so as the rest + of the "display" interface), and uses the network interfaces, allowing + cursor readback from a display server on a remote node. + + 1. Modified IMTOOL to add support for another pseudo-IIS subunit 020, + used for logical cursor reads (a logical cursor read knows about the + WCS and can return image pixel coords, and can use the keyboard or + mouse to trigger the cursor read). When a cursor read is initiated + the mouse is grabbed and moved into the IMTOOL window, and the regular + 2 Hz "plus" cursor becomes an 8 Hz circular cursor, with the rapid + blinking intended to indicate to the user that a cursor read is in + progress (there is no other indication). A key or the left mouse + button (if aliased to a key) is used to terminate the cursor read, + at which time the cursor value is returned to the client program, + the regular IMTOOL cursor is restored, and the mouse position is + restored to what it was before the cursor read began (usually a + different window). Sampling and frame buffer coordinate cursor + reads are also supported. + + 2. To the DISPLAY package I added a new routine IMDRCUR, used to + read the logical image cursor of the named device (a lower level + routine imdrcuro is used for multiple reads on an open device). + Since the new routine needs to be called from the CL for a cursor + read, the display package library was exported to lib$libds.a. + Note that these new routines are temporary and will go away in + the future, but not until the new display interfaces are in place. + + 3. Added a C binding routine c_imdrcur to LIBC. + + 4. In the CL, modified the query code in modes.c to call c_imdrcur + to satisfy a physical image cursor read. Note that the image cursor + (stdimcur) may still be redirected to either stdgraph, the terminal, + or a list file. In the future, image cursor reads will be performed + in cursor mode, using the (currently nonexistent) stdimage kernel + to access the physical device. + + 5. The default value of the environment variable "stdimcur" was + changed from "text" to "stdimage", but only on Sun/IRAF for the + moment, since people running IRAF on other systems are likely to + be accessing a display device that does not yet have cursor input. + + reset stdimcur = stdimage + + To use the new image cursor facilities, make sure that "stdimcur" is + set to "stdimage", and then type "=imcur", or run any program which + reads the logical image cursor, e.g., lists.rimcursor or apphot.*. + (6/2) + +-------------------------- +All development systems updated. (6/2) + +unix/sun/gterm.c + Added a new function key F7 (to go with F8 and F9 which are already + used). This key toggles the graphics between fullscreen mode and + some other size window. (6/5) + +unix/sun/imtool.c + Added multiple cursor marker types (the marks drawn at the cursor + position when a cursor read is terminated). The 'Cursor mark' entry + was deleted from the frame menu and replaced by a choice option in + the setup panel. The choices are None, Circle (the cursor pixrect), + Cross, and Square. The default is Square. Circles are the most + visible, Squares are modest and unobtrusive, and Crosses are real + small. (6/5) + +dev/graphcap + Added a couple of new device kernel parameters for the image display + devices. LC, if present, indicates that the display server supports + the new logical cursor operation, described under the IMTOOL revision + of 5 June. This parameter was added to all IMTOOL entries in the + system graphcap file. A second parameter BS specifies whether the + device is byte swapped. (6/7) + +sys/mkpkg + Added an entry for the new library LIBDS. (6/7) + +pkg/images/tv/display/mkpkg +pkg/images/tv/display/iishdr.x +pkg/images/tv/display/iisio.x +pkg/images/tv/display/iispio.x +pkg/images/tv/display/iisrcr.x +pkg/images/tv/display/iiswnd.x +pkg/images/tv/display/imdrcuro.x +pkg/images/tv/display/imdrcur.x +pkg/images/tv/display/imdgetwcs.x + 1. Modified the DISPLAY read cursor code to add support for cursor + reads to the standard IIS device with no LC (logical cursor) operation + at the server level. The cursor read sequence is very similar to that + for a LC read with IMTOOL, i.e., + + - Enable cursor blink (the shape does not change in this case). + There is currently no prompting other than the blinking cursor. + + - Enter a loop (raw mode ukey read) waiting for the user to type + a key on the *terminal keyboard* to signal the end of the + cursor read. If the key is : the : is echoed and a string + value may be entered. If the key is ctrl/z or ctrl/d EOF is + returned as the cursor value. + + - When a key is typed to terminate the cursor read, IIS cursor + blink is turned off, and a small square mark is draw at the + position of the cursor, by overwriting the pixels in the + image frame buffer (the graphics overlay is not used). No + marker type options are provided for the IIS. The marker + is displayed with z=1 pixels, i.e., white with a negative + transfer function, or black with a positive transfer function. + + While in "cursor mode" (not the normal cursor mode, which isn't + implemented yet for =imcur) the following keys are special: + + ctrl/f display next frame (N' = N+1) + ctrl/r display prev frame (N' = N-1) + ctrl/[dz] EOF + + The same keys are recognized by IMTOOL, but in the case of IMTOOL + they are recognized at all times, whereas for an IIS cursor read + they are recognized only while the cursor is blinking. + + To invoke cursor mode for the IIS, the user merely types "=imcur", + or calls some program such as lists.rimcursor which reads the image + cursor, after setting STDIMAGE to an IIS device, e.g., + + reset stdimage = iism70l + + If the IIS is on a remote node the system will prompt for the login + name and password to be used to access the display on that node. + + Note that the DISPLAY code generates an "IIS compatible" datastream + (similar to a "Tektronix compatible" datastream for graphics + terminals), hence anyone who is desperate for interactive cursor + readback and doesn't want to wait for the full display interfaces + could in principle interface a different device. + + 2. The DISPLAY program and the TV tasks may now be used to drive the + IIS display from a Sun terminal. This feature requires special + support since the IIS is configured for a VAX, hence the bytes are + swapped relative to the Sun. The CV* programs are not currently + supported on Sun/IRAF. (6/9) + +--------------------- +All development systems updated. (6/9) + +pkg/images/tv/display/sigl2.x +pkg/images/tv/display/t_display.x +pkg/images/tv/display/display.par +pkg/images/tv/doc/display.hlp + Modified the DISPLAY program to add support for image scaling via + pixel replication, to supplement the bilinear interpolation already + provided. This was done by adding a new parameter "order", specifying + the order of the interpolator. Order 0 gives pixel replication, 1 + gives bilinear interpolation. Other changes were made to ensure that + the coordinate system of a greatly expanded image is accurate. The + coordinate system used is such that the coordinates [i,j] refer to + the *center* of the displayed pixel [i,j]. Since the range of the + display window goes from 1 to N, only half of each pixel on the edge + of the window is displayed, and the extent of the window is N- + (expanded) pixels. This is consistent with the IRAF convention, + and preserves the information content of the image, but may not be + what is expected. (6/13) + +pkg/images/doc + Edited the EXAMPLES section of a number of these manpages to make the + formatting more consistent (they still need work). (6/13) + +--------------------- +Updated all UNIX development systems. (6/13) + +pkg/cl/builtin.c + A CHDIR command to a directory with a name such as 123 would't work + unless the directory name string was explicitly quoted. CHDIR was + modified to accept an argument of any type, coercing the operand to + type string before trying to access it. (6/17) + +--------------------- +Updated all development systems. +Started a full bootstrap and recompile of IRAF on tucana (need to do this +occasionally to catch compile bugs that creep in). (6/17) + +unix/os/mkpkg.sh + Added an "rm alloc.o" before building the library; this object is + the main for a task and should not be in libos.a. (6/17) + +unix/hlib/buglog.csh +unix/hlib/mkiraf.csh +unix/hlib/mkmlist.csh + Added a "#! /bin/csh" to the top of each script. (6/18) + +--------- +All development systems updated. (6/25) +All development systems updated. (6/28) +All development systems updated. (7/1) + +unix/os/alloc.c +unix/os/zalloc.c + The fix recently made to alloc.c to prevent a user on one node of the + network from stealing a device already allocated by a user on another + node was fine, but this still left the primitives in zalloc.c, called + by iraf programs, unable to determine accurately if the allocation + status of a device in a network. The VOS would check to see if the + device could be allocated, and if it were allocated to a user on a + different node than the node serving the device, the VOS (via zalloc.c) + would think that the device could be allocated, then when it tried to + actually allocate it, the alloc.e would refuse to do so, causing a + confusing error message. + + Fixing this was not trivial, since the test for network device + ownership requires reading the system process table, which requires + reading /dev/kmem, which can require root priviledge. The solution + was to add a new flag -s (stat) to alloc.e, and modify the code in + zalloc.c to execute the alloc.e task to check the device status in + the one case where it mattered. (7/7) + +--------- +All development systems updated. (7/14) + +sys/etc/miireadc.x +sys/etc/miireadi.x +sys/etc/miireads.x + These routines could return more than the requested number of data + elements in some cases. (7/25) + +--------- +All development systems updated. (7/27) +All development systems updated. (7/28) + +============================================================================== +31 July 1988 - the TUCANA complex, a Sun-3 server plus iraf software +development workstations, replaces the BSD 4.3 VAX 11/750 LYRA as the +master IRAF software development machine. +============================================================================== + +Did a full file inventory on lyra, looking for junk files to be deleted. + +vms/hlib/share/common.map - +vms/hlib/share/makeshare.cl + Modified the makeshare script to delete the large "common.map" file + after the shared library has been built. (7/31) + +LYRA + No changes after today. Will be archived automatically when the system + is taken down for the final time tuesday. (7/31) + +CARINA + Deleted the entire carina version of iraf and replaced it by the full + lyra system. Carina now contains the exact same system as lyra except + for the devices and motd files. Hereafter, carina will be used to + maintain BSD VAX/UNIX IRAF, and will be maintained as a (sporadically + updated) irafx development system. (7/31) + +TUCANA + Tucana becomes the new master development system. Deleted doc, lib, + math, noao, pkg, and sys and restored from lyra. Most files are now + owned by the responsible programmers rather than by iraf, as on lyra. + Diff/merge check of dev, local, and unix. Did a full bootstrap. + A full recompile of the entire system will follow later today. (7/31) + +/u2/sites + Moved the extra.v25 stuff to /iraf/extra on carina. + Moved everything else to /u2/sites on tucana. (7/31) + +Moved irafmail facility. +Moved sitemail facility. +Moved aipsmail facility. +Moved vms mail facility. +Moved buglog facility. +Moved emaildb facility. +Moved assorted /local tasks. + (7/31) + +-------------------------- +Did a full bootstrap and sysgen of both f68881 and ffpa on tucana. (8/1) + +dev/vi.ed [VMS] + The set/terminal command in the host command used to run VI was + modified (by Nigel) to get around a problem with VI that was causing + the terminal driver to be left in a funny state - flow control was + being turned off or something. The symptom was that after running + VI, the user would get into a graphics cursor loop, and the raw mode + cursor read would read a great deal of garbage characters (ctrl/s's), + causing the cursor mode to get repeated bad cursor reads, beeping + the terminal for an extended time. (8/3) + +vms/boot/bootlib/osfdate.x + As an experiment, I changed this to use the file modify date rather + than the create date to test when a file was last modified. This may + cause problems, as we have found in the past that on VMS, the file + modify date is often changed even when the file data is not modified. + (8/4) + +pkg/lists/* + Deleted the COLUMNS task. (8/11) + +---------------------------- +Updated IRAFX@draco. (8/13) + +vms/gdev/sgidev + All the VMS/SGI translators have been modified so they require only an + input file name. This fixes the problem of two $F filename expansions + (input and output files) causing the submit command from the graphcap + DD string to be truncated. (8/15 ShJ) + +dev/graphcap +vms/hlib/sgiqueue.com + These files were modified to accomodate the change made to the + VMS/SGI translators documented above. (8/15 ShJ) + +unix/sun/Makefile +unix/sun/imtool.c +unix/hlib/install + Modified these files to add support for separate compilation of GTERM + and IMTOOL under SunOS 4.0. In the new operating system, which has + shared libraries, GTERM and IMTOOL are just regular programs and there + is no "custom suntools" executable. The new sun directory sources and + install script will automatically sense the OS version and do the right + thing on any version of SunOS. (8/28) + +unix/boot/spp/rpp/rpprat/deftok.r +unix/boot/spp/rpp/rpprat/entdkw.r +unix/boot/spp/rpp/rpprat/initkw.r +unix/boot/spp/rpp/rpprat/swend.r +unix/boot/spp/rpp/rpprat/common +unix/boot/spp/rpp/rpprat/defs +unix/boot/spp/rpp/rppfor/*.f +unix/boot/spp/rpp/mkpkg.sh + Added (experimental) support for a new SPP compiler directive, PRAGMA. + This is used to advise the compiler about succeeding statements to + modify the default behavior of the compiler, e.g., to optimize the + code is some nonstandard way. The only pragma currently supported is + 'pragma switch_no_range_check', which is used to eliminate the range + check in a SWITCH statement in cases where the extra efficiency makes + it worthwhile and it can be shown that the switch will always be in + range. The keyword `pragma' is treated as data if the pragma is not + recognized, so that existing code using this keyword as a variable or + whatever will not be affected. (9/5) + +unix/sun/imtoolrc +dev/graphcap + Modified the 2D-Frutti entries after discussions with Steve Heathcote. + The long (dispersion) axis of the 2D-Frutti is y, not x, as the + previous entries assumed, and so the x and y dimensions of imt22 + through imt25 entries were interchanged. An additional entry for the + largest format of the 2D-Frutti was added (imt28). + + CN# device alias dimensions + + imt22 imt2df1x1 imt2df1 128 x 1520 + imt23 imt2df2x1 imt2df2 256 x 1520 + imt24 imt2df5x1 imt2df5 512 x 1520 + imt25 imt2df9x1 imt2df9 960 x 1520 + imt28 imt2df9x3 976 x 3040 + + The current set of frame sizes and aliases for the 2D-Frutti are + summarized in the figure above. (9/6 ShJ/dct) + +sys/fio/fstati.x + Added an entry for F_BUFPTR, which seems to have been inadvertently + omitted. (9/6) + +unix/hlib/clpackage.cl +unix/hlib/zzsetenv.def + Changed all references to 'sdas' to 'stsdas'. (9/6) + +unix/boot/spp/xpp/decl.c +unix/boot/spp/xpp/xppcode.c + Increased the size of the string buffer used to store procedure + declarations text from 2048 to 4096. (9/19) + +pkg/images/tv/display/dsulut.x +pkg/images/tv/display/t_display.x + 1. With the user lookup table option, the buffer for the lookup table + was being allocated but never freed. + 2. Fixed a typo in a call to pargstr made in an error handler - the + pointer ztrans was not being dereferenced. (10/4) + +unix/hlib/d1mach.f + Modified to use the IEEE rather than PDP values (presumably we don't + have any software which actually uses these double constants yet). + (10/14) + +pkg/images/tv/display/gwindow.h +pkg/images/tv/cv/gwindow.h + The offset to the W_IMSECT string was being calculated incorrectly, + causing the 4th WCS structure to be overwritten. This bug was only + recently detected following addition of some code which looks at all + the WCS at shutdown time, and which was expecting to find NULLs in + the high numbered, unused WCSs. (10/14) + +---------------------------- +Updated the IRAFX systems (irafx@draco, carina, tucana f68881/ffpa). (10/14) + +unix/sun/screendump.c + Removed the -s flag from the lpr command in the default R_DISPOSE, + as this doesn't work any more under SunOS 4.0 (when writing to a + remote node and the link cannot be made, lpr is sending mail back + to the user, rendering the option effectively unusable). (10/17) + +lib/nspp.h +sys/gio/nspp/sysint/packum.x + Delted the SWAP_MCWORDS definition from nspp.h, and modified packum.x + to use the standard definition BYTE_SWAP2 in mach.h. (10/18) + +sys/libc/csalloc.c + This file contained a reference to a nonexistent routine STKCMP, + intended for order comparision of buffers on the stack. This has + never been used and it is not clear why we need such a routine, + so I deleted c_stkcmp and the reference to STKCMP. (10/19) + +---------------------------- +Begin merge of revisions from SunOS 4.0 and RoadRunner (386i) ports into +Sun/IRAF. (10/19) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Increased LEN_JUMPBUF from 16 to 64, to accomodate the worst case + save buffer size. (19/19). + +unix/hlib/libc/kernel.h + Added a definition of PFI (pointer to function returning int). This + is used in a number of OS files. (10/19) + +pkg/cl/main.c + Changed the definition of the variable "cldebug" from + int cldebug; + to + int cldebug = 0; + to allow initialization with "adb -w cl.e" to enable debugging. + Some systems, including SunOS 4.0, don't allocate storage in the + executable unless the value of the variable is explicitly initialized. + (10/19) + +unix/as.i386 + +unix/bin.i386 + + Created these new directories. (10/19) + +unix/boot/spp/xc.c + 1. Hacked XC to use F77 only to compile Fortran source files, and to + use CC for everything else. + 2. Added /usr/local/bin to the list of directories to be searched for + commands like XPP and RPP. + 3. Changed the defined names from "xpp.e" and "rpp.e" to "xpp" and + "rpp", since this is how they appear in /usr/local/bin. + (These changes originated in the 386i port). (10/20) + +------------------- +Sysgen-ed tucana (f68881,ffpa) and updated draco as well. (10/20) + +------------------- +During the period 21-27 October, the NOAO Sun systems were down for the +upgrade to SunOS 4.0. The Sun/386i port of IRAF was also completed during +this period. Some of the following changes were made as a result of these +efforts. + +unix/boot/mkpkg/scanlib.c + Had to add + + #ifdef i386 + #define PORTAR 1 + #endif + + at the top of the file to get include to define the appropriate + library format. Also, on the 386i, the code which scans the library + has to deal with the following peculiarities: + + o The first "file" in the archive is a dummy entry containing + symbol information; the name field is null, hence the code + can skip this entry by checking for archive members with + null-string names. + + o The names of the archive members now have a trailing /, + e.g., "file.o/", followed by blank padding. Previously + only the blank padding was there. I modified the code to + accept either / or blank as the name delimiter. + + I also added some debug code which prints the name and date of each + archive member as the library is scanned, if debug > 1. These + changes should be portable to other systems. (10/19) + +SUNBUG - f77 + The command "f77 -c -O file.c" produces the following: + + Assembler: /tmp/optim.01231.5.s + aline 1 : Warning: cannot field update- '.file' not + on first line + + This prevents use of f77 to compile C files, at least on the 386i! + (It works if the optimizer is not used). Will have to modify XC to + use CC instead. (10/19) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.I386 + + Added code for case FPU = i386 (not really an fpu), plus a special + file list for the 386. (10/19) + +unix/hlib/cl.csh + Added a case for the i386, similar to that for sparc. (10/19) + +--------------------- +Sysgen completed with a half a dozen files with errors, but no executables +were linked due to a library conflict with the dummy zsvjmp.s I wrote. (10/20) + +unix/as.i386/zsvjmp.s +unix/as.i386/zzdebug.c + Wrote a ZSVJMP.S for the 386i (80386), plus a little test program to + make sure it works. (10/20) + +--------------------- +Linked x_system.e and it runs on the first attempt!! (10/20) +Start another sysgen - ignore files that didn't compile for now, until we +see which executables they prevent from being linked. + +sys/vops/acht.gx + On the 386i, statements of the form "b[i] = a[i]", where B was + COMPLEX and A was INTEGER*2, revealed a compiler error in the + 386i Fortran compiler (the error was a syntax error in the assembler + code input to the system assembler). I decided that assigning + an integer*2 to a complex in a straight assignment wasn't a very + safe thing to do anyhow, so the generic source was changed to + generate "b[i] = complex(real(a[i]),0.0)" instead, whenever B + is complex and A isn't. (10/20) + +sys/vops/amod.gx + No changes here, just logging the compiler bug. The code is as + follows: + + do 110 i = 1, npix + c(i) = mod (a(i), b(i)) + + where A, B, and C are integer*2. Once again, the compiler is + generating incorrect assembler for this case, causing a "syntax error" + from the assembler (evidently, because of the rather restrictive + instruction set of the 80386). I am not sure there is anything in + IRAF that uses this routine anyhow, so we will try to ignore it for + now. (10/20) + +noao/astutil/pdm/pdmstatistics.x pdmstats.x +noao/digiphot/apphot/center/apcentercolon.x apcencolon.x +noao/digiphot/apphot/center/aprefitcenter.x aprefitcen.x +noao/digiphot/apphot/center/apfitcenter.x apfitcen.x +noao/proto/t_mkhistogram.x t_mkhgm.x + Shortened the names of the above source files. These will not compile + on the 386i, which has a limit of 14 characters for the names of + modules in object libraries (which are COFF format libraries from + Sys V, hence the 14 char limit). (10/21) + +unix/hlib/mpkg.sf.I386 + Turned off the optimizer for conrec.f, srface.f, pwrzi.f. An apparent + optimizer bug was causing declaration of an external which would cause + an unsatisfied exernal error at link time. (10/21) + +pkg/images/iminfo/t_imstat.x + Replaced some ==INDEF constructs by IS_INDEF, and took the n=n+1 out + of the inner loop, since it isn't needed. (10/21) + +unix/boot/mkpkg/host.c + Disabled the ranlib (library rebuild) on the 386, since it uses COFF + type libraries, which don't need to be ranlib-ed. (10/21) + +unix/hlib/mpkg.sf.I386 +unix/as/amods.s + + Edited the assembler for the VOPS amods routine (to work around the + compiler bug mentioned above) and placed the assembler version in + AS and added the file to the special file list for the 386i. (10/21) + +--------------------------------- +Restored IRAF on the ORION complex (Sun-4 plus Sun-3 nodes), now running +SunOS 4.0. Booted up the system and sysgen-ed the sparc, ffpa, and f68881 +binaries. (10/23-25) + +--------------------------------- +Following a period of outage due to hardware problems, the TUCANA complex +came back on the air, also under SunOS 4.0. Moved the ffpa and f68881 binaries +over from orion, and udpated the few files that had been modified. (10/27) + +sys/ki/kishownet.x + ki_shownet, and hence the task NETSTATUS, now checks for name + collisions between node name aliases and the system environment + list, and prints a warning message if the same name is found + in both name spaces. (10/28) + +unix/sun/gterm.c + Several users pointed out that if enough GTERM windows are opened + up, the system will run out of some critical resource and it won't + be possible to open any more windows (for some reason this did not + happen until we upgraded to SunOS 4.0). This was traced to the + system actually running out of /dev/win* entries. According to + /etc/pstat -i, GTERM was using 11 entries, whereas SHELLTOOL was + using only 2. This is somewhat reasonable since GTERM does provide + more windows, but a factor of 5 is too much. It turns out that + things like the setup panel and "pause" panel in GTERM were using + window descriptors, even when not in use. GTERM was modified to + create the windows each time they need to be used, reduing the number + of window descriptors used from 11 to 5. (11/2) + +sys/fio/mkpkg +sys/fio/close.x +sys/fio/filbuf.x +sys/fio/ungetci.x + + The hitherto little used pushback feature of FIO has come into use + recently, leading to the following bugs being fixed. + 1. filbuf.x did not permit pushback on a string or spool file, + although it worked for ordinary files. + 2. A bug in close.x was causing fcanpb (cancel pushback) to be + called with the wrong file descriptor. + 3. Added a new routine UNGETCI to complement the already existing + routine GETCI. (11/7) + +sys/memio/salloc.x + Found and fixed a horrible bug, while testing the QPOE code on the + 386i. The alignment logic in the stack allocation code (SALLOC) + had an error which would cause it to work for types up to the size + of an int or real, but which would cause misaligned buffers for types + double or complex. The MALLOC code was correct, however. (11/8) + +pkg/cl/builtin.c + Added a new builtin "d_m" which prints some information on memory + usage, i.e., the dictionary and stack. (This is like the old d_d, + except that since it is not built into the gramar with lookahead, + the incomplete input '>>>' nonsense is avoided). (11/8) + +unix/hlib/libc/make.h - + Deleted this obsolete file, a make template used back in pre-mkpkg + days when makefiles were used to maintain IRAF. (11/10) + +----------------------- +Snapshot of development system sent to CFA. (11/14) + +unix/os/irafpath.c + Added a #ifdef i386 case so that irafpath() would be able to find + bin.i386. (11/14) + +unix/boot/mkpkg/host.c + Added support for IRAFULIB (a user defined private library) to + the $checkout and $checkin directives. For example, in + + $checkout libex.a lib$ + + if file libex.a is found in IRAFULIB, that version is checked out, + rather than the one in the system directory lib$. (11/15) + +sys/fio/fseti.x +sys/fio/fstati.x + Added the case F_FILESIZE so that low level systems programs which + extend files by direct calls to the kernel routines can update the + file size in the FIO file descriptor. (11/17) + +unix/hlib/mkpkg.sf.S34 + Added a special file list for SunOS 3.4, with the SunOS 4.0 files + thrown in so that it will work for both systems. (11/18) + +unix/boot/bootlib/osfiletype.c + Added ".fits" and ".mip" as known "source file" extensions, i.e., + file types not deleted by rmbin, and movable between machines with + wtar -o. These are really binary file types, but they are closer + to text in their usage. (.mip is something just invented to denote + a machine independent file of some type). (11/18) + +--------------------------------------- +Updated tucana.ffpa(Sun-3/OS4.0), pegasus(Sun-386i/OS4.0), and +serpens(Sun-3/OS3.4). (11/17-18) + +pkg/cl/edcap.c + Removed a pointless restriction to 10 characters on the length of + the editor name. (11/19) + +unix/gdev/sgidev/sgidispatch.c + Fixed an automatic coredump if called with no arguments. (11/22 SRo) + +sys/imio/db/idb.h +sys/imio/db/idbfind.x +sys/imio/db/idbfind.x +sys/imio/db/idbdelf.x +sys/imio/db/idbaddf.x + Modified these routines to automatically truncate the keyword passed + in by the caller to 8 characters, in accord with the FITS conventions + used to format user keywords. (11/28) + +------------------------ +Updated orion. (11/28) + +sys/imfort/db/impstr.x + In the call to amovc, added a 1 to the computed offset of the output + string; numeric values were being output shift one space to the left + of what the FITS format requires. (12/2) + +pkg/system/directory.x + Removed an extra argument from a call to getline(). (12/2) + +------------------------ +Updated tucana (Sun-3, f68881,ffpa), orion (Sun-4, Sun-3 nodes), serpens +(Sun-3 under 3.4, f68881, ffpa), pegasus (386i) and carina (BSD/VAX). +(VMS/IRAF update to follow tomorrow). (12/2) + +vms/boot/bootlib/osfiletype.c + Added ".mlb" to the list of known binary file types, and ".fits" and + ".mip" to the list of known "source" file types. (12/3) + +vms/hlib/share/mkpkg +vms/hlib/share/irafcom.x + 1. Modified irafcom.x to add a ,QUAD to the entry for the MEM psect. + 2. Added an entry "mkpkg x_mkshare" to automatically build the + mkshare executable, which is needed before the shared library can + be built. (12/4) + +VERSION 2.7 EXPORT diff --git a/doc/notes.v29 b/doc/notes.v29 new file mode 100644 index 00000000..4176b95f --- /dev/null +++ b/doc/notes.v29 @@ -0,0 +1,2502 @@ +System Notes File for IRAF Version 2.9. +Begun 9 July 1989. +------------------------------------------- + +doc/notes.v28 + +local/notes.v29 + +unix/hlib/motd +unix/hlib/zzsetenv.def +vms/hlib/motd +vms/hlib/zzsetenv.def + Switched IRAFX development systems to version 2.9. (7/9) + +unix/os/zfiobf.c +unix/os/zfiotx.c + Changed a couple of to . (7/9) + +unix/as.vax/* + Replaced directory by version from BSD/IRAF (carina). (7/9) + +dev/hosts + Changed the bin in the pegasus entry to bin.i386. (7/9) + +dev/graphcap + In the process of updating carina I discovered another set of + dpp/psdump entries in graphcap; modified as was done for the termcap + entries a while back. (7/10) + +doc/bugs.v25 + +local/bugs.log + Archived the old V2.5-V2.7 buglog in doc and started a new buglog + for V2.8. (7/14) + +doc/suniraf.ms +doc/sunsmg.ms + + Installed all new Sun/IRAF installation and site manager's guides. + (7/21) + +doc/vmsiraf.ms -> vmsiraf.ms.v25 +doc/vmsiraf.ms + Installed new v2.8 VMS/IRAF combined installation & site manager's + guide. (7/25 SRo) + +doc/unixiraf.ms + Fixed a couple of typos: {IS,NS}.SOS4.GEN -> {IS,NS}.PORT.GEN. (7/26) + +doc/ports/notes.mips + Saved a copy of the notes file for the DECstation (MIPS cpu) port. + (7/26) + +dev/devices [tucana only] + Replaced missing cartridge drive entries (old devices had July 24 + date). (8/7 SRo) + +unix/boot/spp/xpp/xppcode.c + Rewrote the HMS routine in this file, to use integer rather than + floating point to perform the HMS to decimal floating translation. + This appears to have been the only floating point code in the HSI, + and we don't want any floating in the HSI if it can be avoided. (8/8) + +unix/hlib/buglog.csh + Changed the default system to V2.8. (8/9) + +unix/hlib/extern.pkg [orion] + Uncommented stsdas stuff. (8/9 SRo) + +unix/hlib/extern.pkg [orion] + Added rv package, currently pointing to /tucana/u2/fitz/...; + this is a temporary measure. (8/11 SRo) + +unix/hlib/install + Added $host/reboot to the list of files for which execute permission + is required. (8/15) + +doc/unixsmg.ms + +doc/bsdiraf.ms + +doc/v28revs.ms + + Added the source for the UNIX/IRAF Site Manager's Guide to doc. (8/16) + Installed the BSD IRAF Installation Guide in doc. (8/17) + Installed the V2.8 revisions summary. (8/17) + +dev/hosts [orion] + Changed the entry for pegasus to point to `.../bin.i386/...', + not just `.../bin/...'. Must have happened when system was + made generic. (8/31 RS) + +/local/iraf/unix/bin.mc68020/alloc.e + Changed ownership to root, though at present this is not necessary + as there are no magtape drives on the Sun-3 complex hosted by orion + disks. Argo was reporting the error message must change ownership + to root for alloc.e when a user logged onto argo tried to alloc mta + (user should have been using orion!mta). Curiously, pictor, also + using same hbin, simply reports 'cannot allocate device', the usual + message when the drive does not exist. (9/1 SRo) + +unix/hlib/mkfloat.csh + Replaced by the version developed for Convex/IRAF, which has the + following features: + 1. RM can no longer be called to deleted a null list of files. + 2. A call to RMBIN was omitted, making the script run about twice + as fast. (9/4) + +------------- +Updated the f68881, ffpa, and sparc binaries on tucana (sparc update still +in progress). There was something wrong with some of the binaries, e.g., +some of the objects were missing from the bin.ffpa OBJS.arc - maybe someone +accidentally deleted these when attempting to change architectures. (9/4) +Completed tucana (irafx) bin.sparc update. (9/5) + +sys/imio/iki/qpf/qpfaccess.x + Would supply a missing .qp extension automatically when called with + mode NEW_IMAGE or NEW_COPY. This was inconsistent with the + specification of an image access routine as defined by IKI, and would + cause IMACCESS to fail when called to test the legality of an object + name not containing an extension. + 1. Modified to return NO if called with an object name with no + extension and one of the NEW_ access modes. + 2. If called with an access mode other than NEW_xxx and no extension + is supplied, and an image with extension .qp exists, will now output + the .qp extension in the EXTN argument. This was another minor + deviation from the IKI specification. (9/5) + +dev/graphcap + Corrected the "vapl" (generic laserwriter printer queue for VMS) + entry: there was an "irafhlib:sgiqueue.com", which needed to have + the ":" as "\072". (9/8 SRo) + +vms/hlib/libcalcomp.a [iraf, irafx] +vms/bin/x_calcomp.e [iraf, irafx] + Added calcomp libraries to hlib on draco and relinked the calcomp + graphics kernel to accommodate some user requests (USE_CALCOMP is + still set to NO in mkpkg.inc, as it should be for distribution). + Had to link by hand with "-z" to avoid fatal linker conflicts with + the C runtime library, which is used in the hacked kpno version of the + calcomp library; a user site with a standard calcomp library probably + would not have this problem. (9/13 SRo) + +doc/bsdiraf.ms + Fixed error in example showing how to make a symbolic link to + $iraf/bin.vax. (9/13) + +sys/fmio/fmfcache.x + Modified to close and reopen an lfile if already open, and accessed + with a mode requiring write permssion and lfile is currently opened + read only. (9/14) + +sys/qpoe/qpgpar.x +sys/qpoe/qpppar.x + These routines use a static data array PVAL as intermediate storage + for the parameter value, returning a pointer to this buffer to the + calling program. Misalignment would occur when reading or writing + values of type DOUBLE if the PVAL buffer was not double aligned. + Double alignment of a statically allocated buffer cannot be guaranteed + portably. The solution was to make the buffer 1 double larger, + compute a char pointer to pval[2], then double align this pointer. + (9/16) + +sys/qpoe/qpsizeof.x + Fixed a typo in the procedure header comment. (9/16) + +sys/qpoe/qpppar.x +sys/qpoe/qpiowb.x + Added a QP_MODIFIED(qp)=YES in a couple of places to ensure that + the QPOE file header is marked for updating. (9/16) + +unix/shlib/edsym.c + Commented out the code which deletes "file.o" type symbols. + It appears that deleting these may cause trouble for DBX. (9/17) + +----------------- +Did the first full bootstrap under SunOS 4.0.3, with no apparent problems. +Did a sysgen/relink of the f68881 binaries on tucana. (9/20) + +local/.login + Cleaned up a bit, e.g., added a commented out version of "irafarch" + for the Sun-4 and 386i (omits the FLOAT_OPTION), and commented out the + call to irafarch for the Sun-3 (to avoid the possibility of it being + set wrong). (9/21) + +sys/fio/getlline.x -> glongline.x +sys/fio/getlline.x + + 1. Changed the name of the source file for GETLONGLINE from getlline.x + to glongline.x. Modified the routine to reconstruct long lines broken + by the SZ_LINE limit of getline. If the text returned by getline is + not newline terminated another line will be fetched, and so on until + the original newline delimited line has been reconstructed. The + linenumber argument is not incremented until a newline delimited + logical line has been reconstructed. + + 2. Added a new routine GETLLINE, for get-logical-line. This is like + getlongline except that it does not do anything fancy, like skip + comment lines or join lines with backslash continuation. All it does + is eliminate the SZ_LINE restriction when reading lines of text from + a file. Lines longer than SZ_LINE are reconstructed, returning the + full newline delimited line to the caller. (9/26) + +sys/etc/main.x + Modified the iraf main to use getlline rather than getline to read + input lines, to allow reconstruction of very long lines of text. + Note that this is independent from the use of backslash continuation + to enter very long task invocation commands containing many arguments. + The main advantage of getlline is that it allows task *arguments* + that are longer than SZ_LINE. (9/26) + +hlib$extern.pkg [pegasus] + Changed the local package pathname to `/orion/local/kpnolocal/' + from `/orion/u2/kpnolocal/', where it used to be. (9/26 RLS) + +-------------------- +Updated tucana.f68881, irafx@draco. (10/2) + +/orion/local/stsdas/stsdas.cl +usr$2:[stsdas]stsdas.cl +usr$2:[stsdas.pkg.problems]newspr.temp + Added comment about sending SPR's and contacting SDAS group for + help to package header. Copied orion version of newspr.temp to + draco, as it was lacking there (shouldn't have been! - mystery). + (10/4 SRo) + +unix/shlib/mkshlib.csh + 1. Replaced a couple references to "unix/hlib" by "unix/bin.`mach`", + to allowing linking the shared library regardless of which BIN + directory the link unix/bin points to. + 2. Modified the command "cc medit.c -o medit.e" to include the + -fsoft switch when compiled on mach=mc68020. Otherwise, if the + architecture were set to ffpa but there was no fpa on the host, + the executable would fail to run. (10/4) + +unix/sun/fifo.c + The FIFO program is a debug-server which emulates the DISPLAY/IMTOOL + datastream, writing to a frame buffer implemented as an array in + memory. As the program executes all commands are logged to the + stderr to provide a record of the server-client communications. + Since the program does not use the window system, it can be run + remotely on any node to test the fifo/datastream interface. + + 1. Updated to the datastream protocol and fifo pipe semantics used + by the V2.9 DISPLAY/ZFIOGD. + 2. Fleshed out the program a bit, to make it more useful as a + datastream debugger, in particular added an interactive cursor + capability. The original version of the program was written mostly + to debug fifo i/o. (10/7) + +------------------- +Updated tucana.{f68881,ffpa,sparc}. +Configured the first scientist workstation (bokchoy) to run irafx. +Added entries for all the scientist workstations to the iraf dev$hosts +file on all major iraf server nodes. (10/7) + +sys/etc/envgetd.x + Fixed a typo: the variable dval, which should be of type double, + was inadvertently declared as int. (10/7) + +dev/termcap +dev/graphcap + Added a site local additions section to the top of each file. + In the graphcap, moved the host dependent plotter device name section + to near the top of the file, since it has to be modified more often + than what follows. (10/7) + +pkg/cl/bkg.c +sys/libc/csppstr.c + Found and fixed another place where long environment strings would + be truncated. This was occuring when spawning a background job + in the CL, due to a SZ_LINE buffer limitation in the CL bkg.c code, + and an 128 char limitation in the LIBC routine c_sppstr.c. + Increased both buffer sizes to 1024 chars. (10/7) + +unix/hlib/strip.iraf + Fixed a typo iraf$bin.68881/OBJS.arc -> iraf$bin.f68881/OBJS.arc. + Added entries for sparc and i386. (10/12) + +unix/boot/spp/xc.hlp +unix/boot/mkpkg/mkpkg.hlp + Added documentation for the "-p pkgname" flag. (10/16) + +unix/hlib/buglog.csh + Modified to add a blank line between the BUG: and STATUS: fields + of the buglog entry to improve readibility, since these sections + are often large, multiline paragraphs. (10/19) + +unix/os/zgcmdl.c + This routine uses a highly system dependent (BSD43) technique, + depending upon the layout of argc/argv/environ in process memory, + to reconstruct the argument list of the process. This can fail + on systems that don't lay out variables in the assumed order. + Accordingly, code was added (for systems that define BSDUNIX in + ) to import the global variables xargc/xargv, defined by + the BSD routine getarg(3), and use these to reconstruct the argument + list. The variables must be present in an object or library + (normally libU77.a) for processes to link successfully. + + The variables are initialized to argc/argv by a Fortran main. + If xargv is zero when ZGCMDL is called, the old scheme will be used + to try to locate the process argv (hence C programs that don't + initialize xargc/xargv should still run). This scheme is still + not ideal as it is implementation dependent, but is better than + what was being done previously. (10/20) + + NOTE - zmain.c should possibly also be updated to initialize or + define and initialize xargc/xargv, however due to complications + having to do with the shared library (global variables are tricky) + I am going to hold off on this. ZGCMDL should continue to work + from SPP programs (which don't initialize xargv) as it has in the + past. + +dev/hostlogin + Expanded on the comments somewhat. (10/20) + +dev/hosts [orion, tucana, draco] + Changed .f68881 to .sparc in irafks.e pathname for pictor, now + a sparcstation. (10/24 SRo) + +vms/gdev/sgidev/sgi2vhpp.for [irafx only] + Added a declaration integer for function str_len in module + parse_command (bug discovered by j.eisenhamer at ucla). (10/27 SRo) + +dev/pix.imh +dev/pix.pix [vms/iraf] + Somehow the standard test image in VMS/IRAF got its file type + changed to Stream_LF, instead of fixed 512 byte records. Restored + to its normal state by doing an imcopy/imdel/imren. (11/1) + +sys/osb/bitfields.c + Corrected a misstatement in a comment in BITUPK. (11/4) + +dev/termcap + Changed the names "gterm-nqs", "g-lpr", and "g-enscript" to omit + the minus. (11/10) + +unix/boot/generic/tok.l + The generic preprocessor would translate symbols such as "FOO_PIXEL", + as, e.g., "FOO_int", making it awkward to manipulate generic macro + definitions in applications code. The translator was modified to + replace the string "PIXEL" occurring as part of an upper case + identifier, as the type name in upper case. (11/11) + +lib/mii.h +sys/etc/miiread.gx +sys/etc/miiwrite.gx +sys/etc/mkpkg +sys/etc/gen/ + +sys/osb/miilen.x +sys/osb/miinelem.x +sys/osb/miipak.x +sys/osb/miipak16.x +sys/osb/miipak32.x +sys/osb/miipak8.x +sys/osb/miipakd.x + +sys/osb/miipakr.x + +sys/osb/miipksize.x +sys/osb/miiupk.x +sys/osb/miiupk16.x +sys/osb/miiupk32.x +sys/osb/miiupk8.x +sys/osb/miiupkd.x + +sys/osb/miiupkr.x + +sys/osb/mkpkg + Added support for single and double precision IEEE floating to the + MII interface. The new datatypes are MII_REAL and MII_DOUBLE, + as defined in . The new routines miipak[rd] and miiupk[rd] + convert to and from the native floating point format and the + machine independent IEEE (non byte swapped) format. (11/11) + +sys/osb/mkpkg +sys/osb/ieee.gx + +sys/osb/bswap8.c + +unix/hlib/mach.h +unix/hlib/libc/knames.h + Add support for low level IEEE/native floating point conversions to + the host interface. + + 1. The following definitions were added to : + + IEEE_SWAP4 byte swapping required for 32 bit IEEE + IEEE_SWAP8 byte swapping required for 64 bit IEEE + IEEE_USED local host uses IEEE format + + 2. The following conversion primitives were added to OSB: + + ieepak[rd] (datum) + ieeupk[rd] (datum) + ieevpak[rd] (native, ieee, nelem) + ieevupk[rd] (ieee, native, nelem) + + The first two routines handle scalar conversions, the second vectors. + The routines in ieee.gx are the "portable" versions. The "portable" + solution it to merely copy the array - this works on any modern IEEE + host. If the local host does not use IEEE floating, a host specific + version of this file should be written and placed on the MKPKG special + file list, with the source in AS. + + 3. Also added a new routine BSWAP8 to OSB, for swapping doubles. + (11/11) + +sys/imfort/imrnam.x +sys/imfort/imcrex.x +sys/imfort/imfmkpfn.x + +sys/imfort/imemsg.x +sys/imfort/imfort.h +sys/imfort/mkpkg +sys/imfort/imdelx.x + +sys/imfort/imdele.x +sys/imfort/imfparse.x +sys/imfort/oif.h + A number of modifications and enhancements were made to IMFORT in + order to fix the following bug. In the original IMFORT, the pixel + file was always placed in the same directory as the header hence no + effort was made to ensure a unique pixel file name. When support + for specifying "imdir" was added, it became possible for images of + the same name in different directories to reference pixel files in + the same imdir, making pixel file name collisions possible. In the + event of a collision, the pixel file of the new image would clobber + the old one, resulting in two images in different directories pointing + to the same pixel file, a very dangerous situation. + + 1. A new internal routine IMFMKPFN was added to determine a unique + pixel file name in the current imdir. IMCREX and IMRNAM were modified + to use this, fixing the problem described above. + + 2. Since the above change provides clobber checking for pixel files, + it was necessary to add clobber checking for entire images at create + or rename time (evidently the original interface did not provide this). + Clobber is disabled by default, causing a nonzero IER to be returned + in a IMCREA or IMRNAM operation if the new image already exists; the + variable "clobber" may be defined in the user environment to permit + new images to clobber existing ones (deleting both the header and + pixel files). + + 3. Examination of interlibrary object module references indicated that + a limited amount of VOS filename mapping could be added without greatly + increasing executable size or link time. A call to vfn_translate was + added in a couple of places to cause the root and extn fields of all + image names to be escape sequence encoded. This should fix the + problems of mixed case image names and image names with embedded + numeric fields (.0001 etc.) translating differently in IRAF and VMS + (this is not a problem with UNIX since it is so similar to IRAF). + + 4. A new routine IMDELX was added, which is an SPP version of IMDELE. + 5. Several new error codes and error messages were added. + (11/28) + +sys/imfort/tasks/tasks.cl - +sys/imfort/tasks/tasks.unix + +sys/imfort/tasks/tasks.vms + + Replaced the file "tasks.cl", which contains the host dependent + CL task statements for the IMFORT test programs, by reasonably + portable UNIX and VMS versions which can be used without modification + on most IRAF hosts (for the others they will at least serve as + useful examples). The UNIX version requires that $iraf be defined + in the host environment, the VMS version requires the logical IRAFDISK. + (11/29) + +unix/hlib/install + Fixed a bug in the portion of INSTALL which updates the imtoolrc + file. If a local version of the file already exists, and it is + different than the default iraf version, the old file is renamed + to .OLD and replaced by the new version. The problem was that the + new file was being installed with MV rather than CP! Hence, the + first time this happened the correct file would be installed, but + the source file would be removed from unix/sun. The next time + install was run the files would again be different (since the source + file would be missing) and the old file would be moved to .OLD + but not replaced, causing the imtoolrc to be removed from both + the source directory and local/lib. (12/1) + +sys/fmio/zzdebug.x + Added a new debug task mkfile, used to make zeroed lfiles of the + indicated size in Kb. (12/2) + +lib/syserrmsg +sys/fmio/fmsync.x +sys/fmio/fmioextnd.x +sys/fmio/fmdebug.x + Modified FMIO to improve the way datafile overflow is handled. + The FMIO data structures impose a limit on the size of the datafile + when the datafile is first created; the largest possible datafile + depends upon the page size chosen and the number of page table index + entries. These may be specified by the user, but the default values + of page=512bytes and maxpti=256 will yield a max datafile size of + 32 Mb, enough for most applications (ROSAT QPOE files have already + exceeded this however). + + 1. Previously, the datafile-too-large condition was detected only + at datatype sync time, when the PTI was updated. Added code to the + lfile file driver to check for PTI overflow and return a file write + error if this occurs while writing to an lfile. + + 2. An effort was made to improve the recovery from such an error. + Enough space is always reserved to permit a sync of the principal + datafile data structures. If a write to an lfile fills the datafile + to capacity, a write error is return to FIO, and a FMIO error is + posted so that a subsequent FM_CLOSE will complain about + datafile-too-large, after syncing the datafile containing the + truncated lfile. No further writes to the datafile which try to + extend an lfile will be possible, but it should still be possible + to read the lfile, or rebuild it with a larger page size or whatever. + (12/2) + +unix/boot/spp/xpp/xpp.l +unix/boot/spp/xpp/xppcode.c +unix/boot/spp/xpp/decl.c + Modified the preprocessor to add a statement to the executable body + of every REAL or DOUBLE procedure to initialize the procedure value + to zero upon procedure entry at runtime. The problem is that on + some systems (e.g., a Sun-4) if a procedure which returns a floating + point function value exits without setting the function value, e.g. + during error processing, the function value may be random garbage. + In the case of a floating point function even a simple copy of the + function value may result in a floating point exception, causing + program termination, if the garbage value is not a legal floating + point number. This is despite the fact that the program may be + perfectly correct in that it detects the error return and never uses + the function value. Having the preprocessor initialize the function + value to zero is a simple solution to the problem which does not + require any modifications to applications code, although there is a + very slight performance penalty. + + In addition to modifying the compiler as indicated above, I recompiled + all the floating point functions in the bin.sparc version of the VOS + on tucana (use of which led to the above fix). (12/3) + +unix/hlib/libc/setjmp.h + Uncommented the old #pragma undefined_control_flow(zsvjmp_), which + again seems to be necessary for the CL on a Sun-4. (12/3) + +dev/hosts [tucana, orion] + Changed bin.sparc to bin.ffpa for new Sun3/160 node libra. (12/6 SRo) + +unix/os/zfiotx.c + Modified to ignore the file write error which occurs when a process + attempts to write to the terminal after the user has logged out. + This would cause unix/iraf background jobs submitted without + redirecting the output to die after the user logged out, if any + program output occurred. I could also have reopened the stdout and + stderr on a text file in the user's home directory to save the output + in the event that this error occurred, but it would seem that if the + user wanted such output saved they would have redirected it to a file + explicitly. (12/9) + +pkg/system/cmdstr.x + This hidden system task, used by MKSCRIPT to construct command strings + to build batch scripts, will abort if a task contains a parameter + which does not have a value. The error message which appears if this + happens was modified to identify the task and parameter name causing + the problem. (12/11) + +unix/os/alloc.c + Made some modifications to make the task more secure. (12/13) + +gio/imdkern/ + +pkg/plot/plot.cl +pkg/plot/plot.hd +pkg/plot/plot.men +pkg/plot/imdkern.par + +pkg/plot/doc/imdkern.hlp + +dev/graphcap + Installed a new GIO graphics kernel IMDKERN (prepared by Zolt Levay + at STScI, by modifying the SGI kernel operating in bitmap mode). + This kernel draws into the image display device frame buffer, using + the IMD interface. The new kernel is plot.imdkern. Plots may be + directed directly to the display device graphics overlay by + specifying one of the logical graphics device "imd[wrgby]", + (white/red/green/blue/yellow), or just "imd" (defaults to green). + More control over the color is possible by running the kernel + directly as a task. + + [...details to be added... system integration still in progress] + (12/21) + +pkg/plot/t_contour.x +pkg/plot/t_hafton.x +pkg/plot/doc/contour.hlp +pkg/plot/vport.x + The following changes were made to the CONTOUR program. These changes + affect only the semantics of the "perimeter" and "fill" parameters + and are disabled if the parameters have their default values (draw + perimeter, don't fill). + + 1. If perimeter drawing is disabled, no perimeter is drawn. This + seems logical, but previously, if perimeter drawing was disabled, + the "crtpict" style perimeter was disabled, but the NCAR grid + perimeter box was still drawn. + 2. If fill is enabled and perimeter drawing is disabled, and no user + viewport is specified, the contour map is scaled to fill the entire + device viewport, and all axis and plot labelling is disabled. When + used with the new IMDKERN gio kernel, this allows overlaying of + contour plots on the image display. (12/21) + +dev/hosts + Changed "f68881" to "ffpa" for octans entry, now that only the ffpa + executables live on octans (to save space). (12/26 SRo) + +pkg/cl/config.h + Increased the stack size from 20K to 32K. + Increased the dictionary size from 40K to 128K. (12/29) + +sys/imio/db/imputd.x + Modified this routine to use NDIGITS_DP-1 instead of NDIGITS_DP to + format printed numbers with the format "%0.*g". The machine precision + estimate is only an estimate, and often trying to print that last + digit results in making up garbage. This causes numbers such as + 1.000000000000000001 to be printed when the actual number is 1.0. + (12/31) + +sys/imio/db/idbcard.x + + Added a little package for reading the internal IMIO FITS header. + This package is used in the WCS code and is not intended for use + outside of the system code. (12/31) + +sys/mwcs/ + + Installed the new VOS interface MWCS, or mini-WCS (world coordinate + system). This is a general interface for coordinate system + representation, management, and evaluation, for use both in + applications and as an embedded interface in system code. + Although MWCS addresses the general WCS problem, several important + problems were left unsolved, and a second major version of the + interface is planned for the future. MWCS is NOT regarded as a + frozen VOS interface at this point. (1/3/90) + +sys/imio/iki/stf/stf.h +sys/imio/iki/stf/stfget.x +sys/imio/iki/stf/stfopen.x +sys/imio/iki/stf/stfwfits.x +sys/imio/iki/stf/stfrfits.x + Modified the STF image kernel to preserve the comment field of + PTYPEi cards when the FITS header is read and later rewritten to + disk. + +sys/imio/iki/stf/stfupdhdr.x +sys/imio/iki/stf/stfrgpb.x +sys/imio/iki/stf/stfreblk.x +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfopix.x +sys/imio/iki/stf/stfnewim.x +sys/imio/iki/stf/stfaddpar.x + Went through all the STF code and added ERRCHK statements where they + were missing. At least the files listed above were affected. (1/4) + +sys/imio/iki/stf/stfwcs.x - + Deleted the little WCS package used in the STF kernel. This was + used to apply the section transform to the WCS when making a newcopy + image. Since this function is now performed by IMIO using the more + general MWCS package, it is no longer necessary to do this in the + kernel. (1/4) + +sys/imio/iki/stf/stfhdrextn.x -> stfhextn.x +sys/imio/iki/stf/stfmkpixfn.x -> stfmkpfn.x + Renamed these files to shorten the file names. (1/4) + +sys/imio/iki/stf/mkpkg +sys/imio/iki/stf/stf.h +sys/imio/iki/stf/stfopix.x +sys/imio/iki/stf/stfopen.x +sys/imio/iki/stf/stfcopyf.x +sys/imio/iki/stf/stfwfits.x +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfnewim.x + The original STF code would build the FITS "user area" of the header + by writing out the GPB (group parameter block) cards, marking the + size of the GPB area, then writing the contents of the old user area + or FITS header. When the header was later updated the GPB cards would + be read to get any new values, then the cards following the GPB area + would be output to the image header. This approach turned out to + have the following problems. + + 1. Since the size of the GPB area at the start of the user area was + fixed at image open time, runtime edits of the header affecting this + area, e.g., deleting of a GPB card, could in effect change the size + of the GPB area, causing user cards to be lost. This should not + happen and would normally result in an error when trying to read the + GPB card to update its value, but if a user card happened to redefine + a GPB card, an incorrect value could result. I don't know of any + occasion where this happened, but it was possible. + + 2. It was possible for user area cards to redefine GPB area cards. + This is normally harmless since IMIO uses the first occurrence of + a card, but could confuse the user. The problem was particularly bad + because in an image copy involving a format change such as STF -> OIF + and later OIF -> STF, the GPB cards would become OIF user area cards + in the first copy, appearing as duplicate cards in the OIF -> STF + conversion. + + This problem was fixed by scrapping the idea of a fixed size FITS/GPB + area at the beginning of the user area. Instead, a filtering scheme + is now used which can, e.g., copy the user cards while deleting any + cards which redefine GPB area keywords. The expense is about the same + as before, as the FCOPYO operation, used to spool user cards and later + copy them back to the user area, was replaced by a copy/filter + operation (stf_copyfits) of comparable expense. The order of non-GPB + cards is never changed; any user defined GPB cards will be deleted + and replaced by system generated cards at the beginning of the FITS + header. All references to the STF_SZGPBHDR field of the STF + descriptor were deleted. + + In the process of fixing this I also discovered a large block of + code in stf_opix which would make 5 passes through the entire header + (two fcopyo operations and one strlen), but which was totally + redundant since the stf_mergegpb code was deactivated some time ago. + The whole mess was simply commented out for now. (1/4) + +sys/gio/ncarutil/conbd.f +sys/gio/ncarutil/conrec.f + Increased the size of the contour work area (STLINE work area overflow + bug) from 5000 to 20000. (1/4) + +sys/imio/iki/stf/stfnewim.x +sys/imio/iki/stf/stfrgpb.x + 1. In the process of testing the new STF code I discovered that the + WCS in the first element of a new multigroup image is initialized to + a pixel WCS, whereas subsequent groups are initialized to zero (the + parameters are entered into the descriptor but do not describe any + valid WCS). I modified stfrgpb.x to set up the default pixel WCS + in this case too. + 2. The default pixel WCS was modified to set CRVAL=CRPIX=0 rather + than CRVAL=CRPIX=1 as before. The two forms are equivalent, but + zero is more consistent with MWCS practice. (1/5) + +sys/imio/iki/qpf/qpf.h +sys/imio/iki/qpf/qpfcopypar.x +sys/imio/iki/qpf/qpfwfilter.x + +sys/imio/iki/qpf/mkpkg + 1. Modified QPF to propagate any WCS information in the QPOE file to + the image header. The MWCS, stored in the QPOE header as a variable + length binary array, is loaded into a MWCS descriptor and then "saved" + in the image header as the standard set of FITS cards. + 2. Added code to QPF to record in the header the QPIO filter used to + generate the image. This is recorded as a series of FITS cards, + however many it takes, of the form QPFILTnn, where the nn goes 01, + 02, etc. (1/5) + +sys/qpoe/README +sys/qpoe/qpoe.h +sys/qpoe/qpsavewcs.x + +sys/qpoe/qploadwcs.x + +sys/qpoe/qpiolwcs.x + +sys/qpoe/mkpkg +lib/syserr.h +lib/syserrmsg + Added two new routines qp_[save|load]wcs to QPOE. These are used to + save or load a MWCS type world coordinate system in a QPOE variable + length binary header parameter "qpwcs". A QPOE file can contain any + number of WCS parameters, e.g., each for a different physical system, + but at present only "qpwcs" will be used by the system code, e.g., + QPF and IMIO. + + qp_savewcs (qp, mw) + mw = qp_loadwcs (qp) # aborts if no WCS + mw = qpio_loadwcs (qpio) # aborts if no WCS + + A new routine qpio_loadwcs was also added to QPIO. This is like + qp_loadwcs, except that it also sets up the Lterm of the WCS to + reflect the current blocking factor and rect set for the QPIO + descriptor. The logical coordinate system of the resultant WCS + will give the pixel coordinates of the defined rect. Note that + the physical system (event coordinates) and world system (e.g., + TAN projection) are not affected. + + It is qpio_loadwcs which is used by QPF to load the WCS for a QPOE + file. In this case the physical image matrix is described by the + logical coordinate system, since the physical system for QPOE data + is always event coordinates. Any IMIO image section applied to a + QPOE file opened under IMIO modifies the Lterm, so in such a case + the Lterm is formed from the QPIO rect and blocking factor and the + IMIO section as successive transformations, leaving the physical + system unaffected and still referring to the original event coordinate + system. (1/5) + +sys/mkpkg +sys/gio/mkpkg + Added entries for the new IMD (GIO kernel) code, so that IMD will be + automatically updated in a sysgen. (1/6) + +sys/imio/immaky.x + Added code to this routine, called when a NEW_COPY image is created, + to apply the section transform to the WCS of the new image (since the + WCS itself is currently stored as data in the header it is automatically + propagated). This is the only place in IMIO which knows anything about + MWCS. Although the code added to IMIO is very simple (a mw_loadim on + the old image followed by a mw_saveim in the new image), much of MWCS + gets involved. Since MWCS is not yet sufficiently well tested I set + things up so that if "nomwcs" is defined in the user environment, + the calls to MWCS are skipped. Note that in any case, for OIF and + STF images, MWCS is called only 1) in a NEW_COPY operation, 2) if the + input image was opened with an image section. For QPOE images, MWCS + is called for every image open, but only if a WCS is stored in the + QPOE file. (1/6) + +-------------------------- +Updated f68881, ffpa, and sparc binaries on tucana. +Copied snapshot of V2.9 system to DECstation. +Started DECstation V2.9 full bootstrap and sysgen. (1/6) + +pkg/plot/t_graph.x + This file contained a routine im_projection with the same name as as + identical routine in file improject.x, causing multiple entries for + the same routine in the in package library (caused a warning message + from the MIPS compiler on the DECstation). (1/7) + +unix/hlib/mach.h + Changed NDIGITS_DP from 17 to 16 (for IEEE double precision). This + corresponds to a mantissa of 52 bits (IEEE double uses an 11 bit + exponent). The value of 17 set a while back was not correct. (1/20) + +unix/hlib/iraf.h + Increased the value of ARB to a larger "arbitrarily large value" (about + 1 billion; the max signed integer is about 2 billion). This won't + take affect globally until the entire system is recompiled, but this + allows selective recompilation of objects for which the smaller value + was a problem. This change should be transparent, but will likely + root out any errant programs that are using ARB improperly, e.g., to + dimension a static array. (1/28) + + Also manually recompiled the objects for a number of files in FMTIO, + FIO, IMIO, etc., for the f68881, ffpa, pg, and sparc architectures + on tucana, where a small ARB could unnecessarily limit the size of + an operation. A full sysgen will be needed eventually. + +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfreblk.x + These files were setting IM_LENHDRMEM, the current image descriptor + length minus the base descriptor, to the current header length plus + space for 20 cards. The problem was that this would override the + max_lenuserarea specification, used to set the max header size at + image open time. The code was modified to reallocate the header + only if more space is needed, thus allowing more than 20 cards to + be dynamically added to an open STF image. This also eliminates + yet another full pass through the header, if the header gets copied + in a realloc operation. (1/28) + +local/.suntools [Sun/IRAF HSI] +local/.sunview + Replaced the sample pathnames used to source the .login file by the + path $home/.login. When these were first set up I didn't think this + worked, but evidently it does now. (1/29) + +pkg/lists/rimcursor.x +pkg/lists/rimcursor.par + +pkg/lists/doc/rimcursor.hlp +pkg/lists/lists.cl +pkg/lists/mkpkg + The RIMCURSOR task was completely rewritten to add support for world + coordinate systems. Coordinates may be output in any WCS defined for + the reference image. Currently, this is not being done quite as it + should be, since the image cursor read code (using libds) is an interim + facility which differs from what is planned. Nonetheless this should + provide a useful tool for reading out image locations in world + coordinates until integration of WCS support into the system is more + complete. (1/29) + +sys/tty/ttygsize.x + If the terminal device does not support the runtime screen size query, + this routine would make a couple of ttygeti() calls to get the screen + size from the termcap entry for the terminal. This would effectively + override the use of the environment variables ttynlines/ttyncols, + or "stty nlines=NN" etc., to specify a screen size other than the + default. The ttygeti() calls were replaced by ttystati() calls to + permit the user to override the termcap screen size defaults. (1/29) + +sys/tty/ttygdes.x + Modified the defaults mechanism for querying the environment, termcap, + etc., for the screen size at termcap entry open time. The defaults + are still much the same, i.e., the environment is used if the device + being opened is the user terminal device, else the termcap entries + are used if found, else the default screen size 24x80 is used. The + main change was to search the termcap if the environment variables + are not defined (unlikely since they are in zzsetenv.def), and to avoid + a possible error abort if li/co are not present in the termcap entry. + This was not a functional change, the code is merely a bit more robust. + (1/29) + +unix/hlib/install +unix/hlib/mkmlist.csh +unix/hlib/mkiraf.csh +unix/hlib/buglog.csh +unix/hlib/mkfloat.csh + Revised the "unalias" lists in these scripts to unalias more of the + unix commands that users might possibly have redefined. (1/31) + +unix/sun/imtool.c +unix/sun/imtool.icon +unix/sun/gterm.icon + 1. Replaced the GTERM and IMTOOL icons by the latest creations. + 2. Modified the IMTOOL source to conditionally compile a cursor rop + which avoids the famous "chicken scratch" bug on the SS1. This option + is the default for the sparc version of imtool, until the bug gets + fixed (it is still present in sparcstations shipping today, under + 4.0.3). (2/2) + +sys/fmtio/strdic.x + Modified slightly to optimize the dictionary string compare. (2/3) + +sys/imio/iki/stf/stfrdhdr.x +sys/imio/iki/stf/stfrfits.x +sys/imio/iki/stf/stfctype.x + +sys/imio/iki/stf/mkpkg +sys/imio/iki/stf/stf.h +sys/imio/iki/stf/stfopen.x + The STF image kernel was optimized for the case where the same image + is repeatedly read, as when successively accessing the individual + images in a large group image. This was done by adding a header file + cache. Whenever the kernel tries to read the FITS header of an STF + image, it looks first in the internal STF header cache and uses the + cached version if there is a cache entry for the given file, and the + cached entry is up to date. If the cached entry for a header file is + valid the cache and disk versions are identical and the disk file need + not be opened or read. Modifying the disk version of a header file + automatically invalidates the cache entry in all processes with an + active header cache (by updating the file modify date). Since a cache + access is functionally equivalent to a header file read, the cache + will speed up all types of image accesses, e.g., occasional access + to the same image, and sequential access to all the elements of a group + image, for both reads and writes (so long as the header file is not + modified, forcing a cache slot reload). The cache operates as an LRU + cache with a fixed number of cache slots, by default 3. The default + number of slots may be overridden by defining "stfcache=" in + the user environment. Due to the amount of memory required for the + headers, there is a builtin limit of 5 cache slots per process. + Setting stfcache to zero disables the cache. + + A profile of STF with the cache enabled shows that, for repeated + immap calls on subimages of a single group format image, most of the + cpu time is now consumed by the read group parameter block code. + Image header keyword accesses, e.g. to define the GPB header entries, + are still relatively expensive due to the sequential-FITS nature of + the current imio/db code. (2/3) + +unix/bin.mc68020/bytmov.c +unix/bin.mc68020/amovs.c +unix/bin.mc68020/amovr.c +unix/bin.mc68020/amovl.c +unix/bin.mc68020/amovi.c +unix/bin.mc68020/amovd.c +unix/bin.mc68020/amovc.c + Added an IF test to do nothing if the input and output arrays are + the same (copy is a no-op). (2/4) + +--------------------- +Begin full bootstrap and sysgen of V2.8 for tucana/f68881. This is the first +full compile since a new version of the Sun Fortran compiler was installed +with SunOS 4.0.3. (2/4) + +sys/fmtio/patmatch.x + There were several occurrences of assignments such as "cval = ARB" + in this code, where CVAL is of type char. This is illegal since ARB + can be a large number, and the bug was found and flagged by the + compiler now that ARB is larger than the max value of an integer*2 + char. Changed the ARB to 0; it appears that the value is a mere + placeholder, being filled in later by a real value at runtime, hence + the value in the code is indeed arbitrary. (2/4) + +unix/hlib/mkpkg.sf.SUN3 + Added sys$gio/ncarutil/autograph/agstup.f to the list of files to be + compiled with the optimizer turned off. The f77 optimizer core dumps + on this file. (2/4) + +lib/syserrmsg + Added verbose error messages for FMIO, QPOE, and MWCS. (2/4) + +--------------------- +Updated (incremental) sparc and ffpa binaries as well. +Snapshot of beta system made for STScI. (2/5) +--------------------- +Did a full sysgen (recompile) of the NOAO packages for SPARC. (2/6) + +sys/mwcs/wftan.x + Modified to check for ra > 360, and subtract 360 if this occurs. (2/7) + +local/.forward - +unix/hlib/gripes.cl + 1. Deleted the .forward file in iraf/local. + 2. Modified GRIPES to attempt to send gripes to iraf via email to + the internet or via span, depending upon the system. (2/8) + +sys/plio/README +sys/plio/mkpkg +sys/plio/plrio.x + +sys/plio/plsectnc.x + +sys/pmio/README +sys/pmio/mkpkg +sys/pmio/pmrio.x + +sys/pmio/pmsectnc.x + + 1. Added a new routine PL_SECTNOTCONST to PLIO and PMIO. This is + patterned after pl_sectnotempty(), but checks to see if the given + mask section is constant valued, rather than zero. If the section + is constant valued the mask value assigned to the region is returned + as an output argument. + + 2. Added a new mini-package PLRIO, used to efficiently random access + any 2D plane of an existing pixel list or image mask. The mask is + opened for random access on a special descriptor which incorporates + a scaled, active 2D lookup table. Most subsequent plr_getpix(plr,i,j) + calls will return the given mask value directly from the table with + very little overhead; only if the referenced pixel occurs in a region + too complex to be described by a single table entry is the value + computed by direct evaluation of the mask. A special 2D binary + recursive algorithm (using pl_sectnotconst above) with log2(N) + performance is used to calculate the scaled lookup table. These + algorithms provide efficient table generation and random mask pixel + access even for very large masks. (2/10) + +sys/qpoe/qpiogetev.x +sys/qpoe/qpioclose.x + Modified qpio_getevents() to make use of PLRIO to randomly sample a + region mask when performing event filtering of a nonindexed event list. + The problem here is that in a nonindexed event list, events need + not be sorted positionally, and successive events can have random + coordinates (this is guaranteed to be the case, for example, in a + time sorted QPOE file). If a region mask is being used for extraction + with such data, the mask must be evaluated to a single pixel for each + event in the event list. Since a large event list might contain + 10E6 events or more, some sort of lookup table is required for + efficient extraction. The old code was using a static lookup table, + but this failed for ROSAT data, where a region mask is 8192 pixels + square, requiring a 128Mb static lookup table! By using the scaled + active lookup table provided by PLRIO, we can provide comparable + runtime efficiency (table generation is actually more efficient), + using a table of only 256x256 or so. (2/10) + +sys/qpoe/qpexopen.x +sys/qpoe/qpioparse.x +lib/syserr.h +lib/syserrmsg + 1. QPIO_PARSE now checks that brackets, parenthesis, etc., match at + the end of an expression, and takes an error exit if this is not the + case. + 2. QPEX_OPEN now checks the error status of the QPEX expression + compiler, and takes an error exit if any errors occurred during + expression compilation (additional warning messages appear during + compilation for each error encountered). (2/10) + +sys/qpoe/qpiogetev.x + The event i/o code was not working at all for the case of indexed + extraction, with a bounding box (rect) and a region mask. The call + to the mask code to determine if a line segment is empty had the + endpoint of the segment set to the start point, hence was testing + only a single pixel (column of the rect). (2/11) + +sys/plio/plupdate.x +sys/plio/plcmpress.x +sys/plio/zzdebug.x + The following changes were made to fix the "PL_LLFREE inconsistent" + warning seen when editing complex PLIO masks. + + 1. The code in plcmpress.x which computes the space used by a mask + was incorrect; this would cause the warning message to be printed + even if the descriptor value of PL_LLFREE were correct. The code was + using LP_BLEN (the line list buffer length) to accumulate the mask + length, rather than LP_LEN (the amount of words of the line buffer + actually used to store the current line). + 2. There was a bug in plupdate.x which could cause PL_LLFREE to be + computed incorrectly in certain cases. When the reference count of + a line buffer went to zero, causing the buffer to be freed, the entire + buffer space was being added to the free space count, which was + incorrect because any line buffer space unused at the time the + reference count went to zero would already have been counted as free. + 3. Added a new debug task "scripts" to the PLIO zzdebug.x This task + is used to create drawing scripts for PLTEST, making it easier to + test complex mask drawing operations. + + Both of these bugs reflected special cases that occur only when editing + complex masks. In the actual tests run, a test case of 1500 circle, + box, and point region draws in a 1024sq mask, bug #1 did not show up + until over 4000 line edits had occurred, and bug #2 did not show up + until over 14000 line edits had been made. (The final test, which + ran to completion with no errors, involved 60,000 region draws or about + 3 million line edits). (2/12) + +sys/qpoe/QPOE.hlp +sys/qpoe/qpadd.gx [INTERFACE CHANGE] +sys/qpoe/qpastr.x [INTERFACE CHANGE] +sys/qpoe/README + The calling sequences of the qp_add[bcsilrdx] and qp_astr routines, + used to set the value of a header parameter while creating it if it + does not already exist, were modified to add a COMMENT argument (the + comment field of the parameter if it is created). Although this is + an interface change, few applications exist yet which use QPOE, and + the few that have written have avoided use of the qp_add and qp_astr + routines due to the inability to specify the comment field if the + parameter is created. (2/12) + +sys/qpoe/mkpkg +sys/qpoe/gen/mkpkg + While updating QPOE after the above change, I noticed that only + gen/qpaddb.x was getting built due to omission of the other types in + the mkpkg. Added the mkpkg support for the missing types. (I guess + we don't have to worry about this interface change affecting any + existing applications!). (2/12) + +------------------ +sparc and f68881 binaries updated. +Beta test snapshot of V2.9 sent off to CFA. (2/14) +STScI beta system updated. (2/15) + +imio/iki/stf/stfrgpb.x + Modified the cannot group parameter block to suggest that if this + occurs, it may be because there is no such group. (2/15) + +pkg/lists/rimcursor.par +pkg/lists/doc/rimcursor.hlp + The default value of the "cursor" parameter (type *imcur) was changed + to the null string. (2/15) + +sys/qpoe/qpio.h +sys/qpoe/qpiogetev.x + The QPIO code was ignoring the region mask if the portion of the mask + within the bounding box or rect (by default the full area) was empty. + Modified to treat this, and the case of a null event list, as a + special case which will cause all subsequent qpio_getevents calls on + that QPIO descriptor to return immediately with EOF, without actually + doing any i/o. (2/16) + +doc/ports/notes.convex + + Added the notes on the Convex/IRAF port, which appear never to have + been archived in this directory. (2/16) + +unix/hlib/fc.csh + +unix/hlib/login.cl +unix/hlib/install + The task FC, a front end to XC used to compile host programs which + may or may not use IMFORT, was modified to call an intermediate + script hlib$fc.csh, rather than calling XC directly. The purpose + of the fc.csh script is to determine the current iraf architecture + and add a command such as -/ffpa, -/f68881 etc. to the XC command + line to ensure that the architecture of any objects compiled with + the command will match that of the iraf architecture. This is + whatever is defined by IRAFARCH, else an appropriate architecture + is selected. There are potential problems with this approach, e.g., + if the user specifies a different architecture on the command line + the task can get confused, but short of making more extensive host + dependent changes to XC this is an easy way to make the IMFORT + interface a bit more resistant to user confusion over multiple + architectures, which will solve the problem for most users (the + rest probably don't use FC anyway). (2/16) + +unix/hlib/mkiraf.csh + MKIRAF now renames any old login.cl to login.cl.OLD before creating + the new one, rather than clobbering the original file. (2/16) + +unix/boot/spp/xc.c + The Sun/IRAF XC now searches -lU77 when linking a host program (-h + switch). (2/16) + +unix/boot/spp/mkxc.sh + The call to CC to compile and link XC was not using $HSI_CF. (2/16) + +unix/hlib/cl.csh + Modified to define IRAFARCH if not already defined. (2/16) + +unix/hlib/mkfloat.csh + 1. Modified to use a compressed architecture save file OBJS.arc.Z. + Will still work if an existing save file is not compressed. + 2. Will no longer make an empty OBJS.arc (.Z) file if there are no + files to be saved, as when backing up the generic architecture. + 3. Modified the code which uses "tar -tv" to verify the save file + to ignore directory name listings. On some systems (Ultrix) TAR + lists directories as archive members, even though only a filename + list may have been used to generate the archive. This makes a + file list compare fail even if the archive is good. (2/17) + +noao/mkpkg +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.MIPS + + Added support for the "mips" architecture (the DECstation). (2/17) + +local/notes.i386 - +doc/ports/notes.i386 + + Moved notes on Sun386i port to doc/ports. (2/17) + +-------------------- +Updated DS3100/IRAF to V2.9BETA. +Full bootstrap and sysgen-recompile. (2/17) + +sys/osb/ieee.gx +sys/osb/miipakr.x +sys/osb/miipakd.x +sys/osb/miiupkr.x +sys/osb/miiupkd.x + The MII routines for IEEE to native floating point conversions were + modified to assume that the IEEE conversion primitives handle byte + swapping as part of the IEEE-native format conversion. (2/17) + +noao/lib/FC.mips + +noao/lib/mkpkg.sf.MIPS + The MIPS Fortran compiler failed on a couple more large files in the + NOAO sysgen-recompile. This is a parser error, hence turning off the + optimizer (or changing any other compiler switches) has no effect. + The NOAO files currently affected by this bug are the following: + + dtoi$database.x + digiphot$apphot/aplib/aprcursor1.x + digiphot$apphot/aplib/apverify1.x + + When this problem occurred earlier my solution was to manually + compile database.x and place the .o in noao$lib. Since this approach + is prone to error and there are now several files, I changed the + special file list to use the new script FC.mips in noao$lib to + automate the custom compile, e.g.: + + $set FC = "$(iraf)noao/lib/FC.mips" + $special "noao$imred/dtoi/": + database.x & "!(chmod +x $(FC); $(FC) database.x)" + ; + $special "noao$digiphot/apphot/aplib/": + aprcursor1.x & "!(chmod +x $(FC); $(FC) aprcursor1.x)" + apverify1.x & "!(chmod +x $(FC); $(FC) apverify1.x)" + ; + + The script FC.mips may be useful to send to users if this problem + occurs elsewhere, e.g., in add-on packages. Hopefully the bug will + be fixed in the next release of the MIPS compilers. (2/17) + +noao/digiphot/apphot/qphot/mkpkg + This mkpkg file had a bad special file list. The same source file + was listed twice, causing the object to be entered into the libpkg.a + twice. This resulted in a warning message from ranlib when the + package was built on the DECstation. The bug was actually harmless, + since both objects were identical. (2/17) + +unix/x11 + [DECstation/IRAF] +unix/x11/saoimage + + Installed the latest version of SAOimage in the DECstation HSI. (2/17) + +------------------ +DECstation update completed. (2/17) + +sys/fmio/fmfcache.x + If an lfile was already open READ_ONLY in the FMIO cache, and an + attempt was then made to open it APPEND, a no write perm error + would result on the lfile. The bug was that the code which checks + to see if a file opened read only needs to be reopened with write + perm was not checking for APPEND mode as one of the file modes + requiring write perm. (2/17) + +sys/qpoe/qpmacro.x + When opening a compiled macro save file and restoring the saved symbol + table therein, qp_access() was not freeing the old symbol table, + causing a sequence of qp_open/qp_close calls to gradually consume + more memory. (2/17) + +pkg/cl/prcache.c + The CL process cache code was modified to check the date of the + executable file associated with a cached process whenever a task + in that process is run. If the modify date of the executable file + is more recent than the time when the process was cached, the cache + entry is automatically invalidated and the process is restarted + (provided it is not actively being used). This avoids the confusing + situation where someone doing software development from within the + iraf environment relinks a process, but then unknowingly tests the + old process which is still in the cache. (2/19) + +pkg/cl/unop.c + This code automatically prepares both real and integer versions of + input operands as part of its standard preamble, regardless of which + version is used for processing. This could result in a numeric + conversion exception on some machines if the input operand was real + and the value was too large to coerce to an integer. For the CL + such an invalid conversion produces an INDEF, so the code was modified + to check for very large real values and set the integer version to + INDEFL if overflow occurs. In most cases where this occurs it is + likely that the integer version will never be used in any case. (2/19) + +sys/gio/gsetr.x +sys/imio/db/idbpstr.x + These files contained the construct "[il]val = nint ([rd]val)", which + could result in a numeric conversion exception if the real value were + very large. The solution was to delete the [il]val and instead use + nint([rd]val) directly in the code. (2/19) + +sys/etc/environ.x + Fixed an obscure bug in the system environment code. When overwriting + the value of an existing variable with reset, if the length of the + new value string was exactly the right size (normally 21 chars for + small value fields) the replacement value could write off the end of + the allocated space by one char. This would overwrite the E_NEXT + field of the entry immediately following, in storage order, the entry + being reset. E_NEXT is the index of the next entry on the hash + thread to which the entry being clobbered belongs. For the typical + iraf environment list which contains approximately as many entries + as there are threads, most threads are either empty or have only a + single element, hence E_NEXT is NULL. When E_NEXT is overwritten it + is overwritten with EOS, which is equivalent to NULL, so if the hash + thread contains only a single value the problem will go unnoticed. + If a non-null E_NEXT link is clobbered the thread is effectively + truncated, causing the remaining entries on that thread to become + invisible in further table lookups (i.e., the entries would become + undefined). + + This was a serious bug since the environment code is fundamental to + the system, but it is unlikely that the problem has been seen very + often because 1) environment resets are relatively uncommon at the + CL level, and normally involve items with short values strings like + stdimage, 2) the replacement value would have to be exactly the right + length, e.g., 21 chars, for an overwrite to occur, and 3) the entry + following the entry being reset would have to have a nonnull thread + link for the overwrite to make any difference. (2/19) + +sys/qpoe/qpadd.gx +sys/qpoe/qpastr.x +sys/qpoe/qppopen.x + These routines were calling qp_addf() with a numeric datatype code + (e.g., TY_INT) but the calling sequence requires a symbolic code, + necessary in order to specify user defined types. (2/20) + +unix/hlib/zzsetenv.def + Added an entry for the system logical directory MWCS. (2/20) + +sys/imio/db/idbcard.x + The routine idb_nextcard(), called by the MWCS code to read a FITS + image header, had a bug which could result in an infinite loop when + a *nonblocked* image header (lines not all blocked to 80 chars) + contained a blank line. This bug was fixed, and I also made the + end of header checking more robust, checking for a pointer beyond + the end of data, as well as checking for EOS on the header area. + Note that MWCS is not called during most image operations unless + a NEW_COPY image is made from an image section of the input image, + hence this bug would only be seen if 1) calling a task which makes + a NEW_COPY image with an image section, 2) the image header of the + input task is not blocked to 80 chars per line (not supposed to + happen, but evidently it does occasionally), and 3) the header + contains a blank line. (2/20) + +sys/etc/envgetb.x + The operation of this operator in the case of a variable which exists + but has no value string was not well defined. false would be returned + if the parameter did not exist, but false would also be returned if + it existed but had no value string. The routine will now return true + if the parameter exists but has no value string, allowing the existence + of the parameter in the environment to be used as a switch. If a yes + or no value is given, then that will be used instead to determine the + boolean value. (2/21) + +sys/imio/immaky.x + Modified to use envgetb() instead of envfind() to test for the + environment switch "nomwcs", to be consistent with the planned use + of an envgetb() test for nomwcs in the IMAGES tasks. (2/21) + +----------------- +V2.9BETA installed at CFA and updated to this point. (2/21) + +sys/imio/iki/stf/stfnewim.x +sys/imio/iki/stf/stfopix.x + The STF descriptor was being reallocated in stf_newimage without + updating the pointer to the STF descriptor in the image header. (2/24) + +sys/gio/gki/gkiprint.x + Modified to print the marker width field in a PM_SET call. (This is + not used in any GIO kernel at present, but since it is a defined + attribute it may as well be printed). (2/24) + +sys/etc/cnvdate.x + Added an errchk for stropen. (2/24) + +pkg/images/geometry/t_blkrep.x +pkg/images/geometry/t_geotran.x +pkg/images/geometry/t_imshift.x +pkg/images/geometry/t_shiftlines.x +pkg/images/geometry/t_magnify.x +pkg/images/geometry/t_blkavg.x +pkg/images/geometry/t_imtrans.x + The above IMAGES tasks were modified to call MWCS to modify the + Lterm of the image coordinate system. As a temporary insurance + measure until MWCS can be fully tested, the code was written in + such a way that the WCS update is skipped if "nomwcs" is defined + in the iraf environment. The "nomwcs" switch will be deleted + in the next iraf release. (2/24) + +sys/fmtio/gargi.x +sys/fmtio/gargl.x + These routines contained a construct such as "ival = dval" which + would perform a blanket conversion from double to int. There could + result in a numeric exception if dval were INDEF or very large. + The procedures were modified to check for these cases and explicitly + set the output value to INDEF if such a case occurs. (2/24) + +sys/fmtio/dtoc.x + Changed in a couple of places to replace several long(val) constructs + by a single, precomputed lval variable, to guarantee that the value + is the same in all cases. (2/24) + +sys/ki/kfsubd.x + Added code to check for an error return from ZFGCWD and exit + immediately with an error status return in this case. (2/24) + +pkg/plot/doc/implot.hlp + Modified to include mention of the usage of the 'l' and 'c' colon + commands to plot averages of lines and columns, e.g. ":l 30 40" to + plot the average of lines 30 through 40. (2/24) + +vms/hlib/sgiqueue.com + There were a number of lines in this file of the form + + print/que=foo/delete 'p2.foo' + + These were changed to the form + + print/que=foo/delete 'p2'.foo + + i.e., it is the 'p2' which must be quoted, since in DCL the function + of the quotes is to perform variable substitution. (2/24) + +lib/sysruk.x +sys/etc/main.x + 1. In sysruk, the >6 char arguments "arglist_offset" and "interactive" + were renamed to minimize the likelihood of a name mapping collision + with the procedures in the same same file as the TASK statement. + Also renamed the "eawarn" environment variable to avoid the suggestion + that this is EA_WARN with a missing include . + 2. Added aliases cd for CHDIR, and reset for SET. chdir is somewhat + of an anachronism these days, and it is nice if reset is recognized + since one gets used to using it in the CL. (2/25) + +unix/hlib/iraf.h +unix/hlib/libc/spp.h +sys/clio/clgfil.x +sys/etc/prupdate.x +sys/etc/prenvset.x +sys/etc/prchdir.x +sys/etc/oscmd.x +sys/fmtio/clscan.x +sys/fmtio/fscan.x +sys/fmtio/scan.com +sys/ki/kienvreset.x +sys/libc/sprintf.c +sys/libc/printf.c +sys/libc/cungetl.c +sys/libc/cttset.c +sys/libc/csppstr.c + Added a new global SPP define SZ_COMMAND (similar to SZ_FNAME, SZ_LINE, + etc.) in iraf.h and libc/spp.h. Modified all the VOS routines I could + find which use large command buffers to make use of this new system + parameter. Also in fscan.x, replaced the getline() by a getlline() + to allow for file lines longer than SZ_LINE. (2/25) + +unix/hlib/install + 1. The alloc.e code now checks the file mode to ensure that set-uid + mode is set on the file. (2/25) + 2. [more work to be done here...] + +sys/etc/environ.h +sys/etc/environ.x +sys/etc/main.x + 1. Increased the default initial environment list size parameters + and doubled the number of hash threads. The new values are about + right for the typical iraf environment list in the present system. + 2. In environ.x and main.x, replaced all getline() calls by getlline() + reads into a SZ_COMMAND line buffer. This is necessary to allow + "set name = value" commands longer than SZ_LINE to be passed in via + IPC from the CL. (2/25) + +pkg/system/help/help.h +pkg/system/help/t_hdbexamine.x +pkg/system/help/mkpkg + 1. hdbexamine had its own private definition of SZ_HELPDB; deleted + and added an include for help.h. + 2. Increased the size of the helpdb buffers used within HELP to 1024 + chars. (2/25) + +sys/fmtio/fmt.com +sys/fmtio/fprntf.x + Increased the size of the "format" buffer from SZ_LINE to SZ_OBUF + (1024 currently). The printf commands can be used for output like + getline(), with any amount of data, and often the "format string" is + mere data. The code should probably be revised to scan the format + string and immediately output data until the first % format specifier + is encountered (to avoid the 1024 char limit, and for enhanced + efficiency) but this was tricky enough that I did not want to risk + it at this time. (2/25) + +sys/imio/db/idbcard.x + There was another problem in the code used for headers with variable + length cards (most headers are blocked 80 characters per card, or + should be). The idb_nextcard() routine would return a pointer to + the \n preceeding a card, rather than to the first character of + the card. This was preventing MWCS from seeing any of the WCS + cards in a header with an existing WCS, if the header happened + to be nonblocked. (2/26) + +sys/mwcs/iwparray.x +sys/mwcs/mwsaveim.x + 1. Added an "index" argument to the internal routine iw_putarray, + used to update array parameters in image headers, and modified + mw_saveim() accordingly. An index value of zero (match all indices) + was being used when checking to see if a given header card existed + to determine if, e.g., adding a card was necessary. This could fail + when updating an array parameter because then there can be multiple + cards which differ only in the index. The result was a message such + as "image header parameter not found" when trying to update the value + of an indexed card when 1) another card of the same type existed in + the header, and 2) a card with the given index did not yet exist. + + 2. Deletion of obsolete WCS cards following a header update was not + working. The code which checks the C_UPDATED flag to see if a + card is to be preserved was referencing the wrong descriptor, causing + the test to fail. (2/26) + +sys/qpoe/qpcopyf.x + The loop which copies an array valued parameter in large chunks with + qp_read/qp_write, was not incrementing the data offset in each pass + through the loop. This would only have affected copies of array + parameters with greater than 8192 elements. (2/26) + +sys/qpoe/zzdebug.x + Modified the HLIST task to output the lfile number and lfile offset + of the stored parameter value, in addition to the information already + output. (2/26) + +sys/fmio/fmfcache.x + When opening an lfile in APPEND mode and the lfile was already in + the file cache with write permission, a seek to EOF was not being + performed. (2/26) + +sys/imio/iki/stf/stfcopyf.x + The stf_copyfits() procedure copies the user area (a series of FITS + cards), optionally separating the cards into reserved or group + parameter cards, which are generated and controlled by the program, + and user cards. The routine was handling cards defining GPB fields + properly, but it turns out that the STF interface also defines the + cards GROUPS, GCOUNT, PCOUNT, and PSIZE in the user area for the + benefit of someone reading the header. The result was that a NEW_COPY + copy of an STF image would contain two copies of these four cards, + since stf_wfits() explicitly outputs all GPB definition cards or + other reserved FITS cards during a header update. The fix was to + modify the stf_copyfits() filter to recognize these four cards in + addition to the GPB cards, and treat them the same way (e.g., omit + them in a copy operation). (2/27) + +-------------------- +f68881 and sparc binaries updated. +CFA and STScI upgraded to this point. (2/27) + +pkg/cl/builtin.c +sys/libc/cenvget.c + Changed a couple of 512 byte buffers to use SZ_COMMAND. (2/27) + +sys/etc/envscan.x + Increased the size of the input line buffer to SZ_COMMAND+SZ_LINE. + This is because getlline() requires at least SZ_LINE of space at + the end of the buffer for a read - to read the full SZ_COMMAND chars, + an extra line of space is needed (or SZ_COMMAND should be redefined + to be an integral multiple of SZ_LINE, but that is getting pretty + tricky for something that just defines an arbitrary truncation point + anyhow). (2/27) + +sys/etc/main.x + 1. Modified the error message "IRAF Main: Unknown task name" to include + the name of the unknown task. + 2. Increased the size of the input buffer used in the main to 2048, + to ensure that command truncation will not occur. (2/27) + + I tested the system with a 980 char environment variable defined in + extern.pkg. With the above changes, most importantly the change to + the main, everthing works fine. Truncation will occur somewhere + between 960-1024 chars with SZ_COMMAND set to 1024 (the 960 is the + nearest multiple of SZ_LINE). It was necessary to increase the + size of the input command buffer used in the IRAF main to avoid + command truncation, which causes loss of synchronization on the + input command stream and a nasty "Unknown task name" error from + the main (if this occurs during process startup, e.g. during + environment initialization, the process is fried, and if the process + is x_system.e you can't even login to the CL). (2/27) + +sys/fmtio/fpradv.x + Escape sequences (\n etc.) embedded in the format string were not + being processed correctly. The sequences were being converted into + escape characters but then the original character (\) was being + output. (2/27) + +unix/os/zzstrt.c + The code which maps the shared image into memory during process + startup could fail on the sparcstation with a segmentation violation + due to an unmapped page between the data and bss segments. The + problem was that for the Sun-3 and Sun-4, a.out aligns segment + boundaries to 8192 bytes (defined as PAGSIZ and SEGSIZ in a.out.h). + The hardware page size on the Sun-3 and Sun-4 is 8192 bytes, but on + the sparcstation it is 4096!. The zzstrt code was using PAGSIZ to + determine where the first page of the bss segment begins; on the + sparcstation this could lead to the computation of the first page + of the bss segment being off by one, with the unmapped page causing + a segmentation violation when the bss segment is zeroed after the + mapping operation. The fix was to use the hardware page size (given + getpagesize()) to align the first page of the bss segment. (2/28) + +unix/hlib/mkfloat.csh + Changed the compress command to "compress -f" to ensure that any + existing compressed file gets clobbered. (2/28) + +sys/imio/iki/stf/stfrfits.x + The STF header file cache code had a bug that would cause it to + continually reuse the same cache slot, even though multiple slots + were available. In the case of an operation which involved repeated + accesses to two STF files (e.g., copying all the elements in a + group file) each header file would be alternately loaded into the + cache for every group element, defeating the cache entirely. (2/28) + +mkpkg +unix/mkpkg.sh +unix/setarch.sh + + A "mkpkg " at the iraf root for a UNIX/IRAF system with multiple + architecture support will now set the AS and BIN links in iraf/unix + to the appropriate values for the new core system architecture. (3/1) + +sys/mwcs/mwsaveim.x +sys/mwcs/iwewcs.x + When a WCS is saved in a FITS format image header, MWCS must combine + the Wterm and Lterm to produce the FITS representation CRPIX-CRVAL-CD, + since FITS specifies what is, in MWCS terminology, the transform from + logical to world coordinates, whereas in MWCS the Lterm and Wterm are + independent and the Wterm specifies only the physical to world + transformation. Full system testing revealed that the linear algebra + used to compute the FITS representation was incorrect. The forward + and inverse transforms were consistent, hence the saved MWCS could be + reconstructed, but the forward transform was wrong and the values of + the FITS CRPIX and CD were being computed incorrectly if the Lterm + was not the identity transformation. (3/1) + +sys/mwcs/mwsaveim.x + MWCS will now save or update the values of CDELT1 and CDELT2 in the + image header. This is in addition to the CD matrix values, which + are always output. The CDELTn are output only if 1) the image + dimension is 2 or less, and 2) in the case of a two dimensional image, + the CD matrix is diagonal. Hence CDELT1 is always output for a + one dimensional image, and for a two dimensional image, the CDELTn + are not output is the image has been rotated (this includes transpose), + or if the CD matrix contains off diagonal terms for any other reason, + e.g., skew. It would not be difficult to output CROTA2 in addition + to the CDELT for a two dimensional image, but I am going to try to + leave this out to discourage the use of CROTA2, which many programs + which use CDELTn are probably not equipped to deal with in any case. + (3/3) + +sys/imio/iki/stf/stfwgpb.x +sys/imio/iki/stf/stfcopyf.x + 1. Fixed a bug in the new stfcopyf.x code introduced in the 2/27 + revision. The GPB cards were not being loaded into the reserved + keyword table, causing filtering of GPB cards to fail. + 2. In stfwgpb.x, I commented out the warning messages for "image + header parameter not found" when updating type real or double GPB + parameters. At least at present, MWCS omits WCS parameters that + have zero values from the header, to avoid large numbers of zero + valued cards for things like identity matrices in which zero elements + are very common. Hence parameters like CRVAL, CDi_j, may be + omitted from the header even though these are defined GPB parameters. + The interface will merely assume a zero value with no warning message + if such a card is not found (formerly, it would assume a zero value + and output a warning message). (3/3) + +sys/imio/iki/stf/stfopen.x + When opening the first group of a new group formatted image, opened + NEW_COPY, the GPB cards of the inherited image header were being + extracted with stf_copyfits() using the GPB parameter list in the + STF descriptor of the *new* image, before the new STF descriptor was + initialized by stf_rdheader(). The fix was to use the STF descriptor + of the old image to extract the GPB cards of the old image from the + inherited user area. (3/5) + +sys/imio/iki/stf/stfiwcs.x + +sys/imio/iki/stf/stfopen.x +sys/imio/iki/stf/mkpkg +sys/imio/iki/stf/stfrgpb.x + The old version of the STF image kernel had some code stfwcs.x which + was used to propagate WCS information to a new image, applying the + section transformation if necessary. This was removed in the new + version of STF since IMIO and MWCS now perform these functions. + When this was done some code was added to stfrgpb.x to set up the + default unitary pixel WCS reading a zeroed GPB when preparing the + header of a NEW_COPY image. This would work in the case of, e.g., + copying dev$pix into a new element of a group format image, avoiding + having the new image end up with a zeroed WCS, which is invalid. + This scheme was incorrect, however, because it would edit the WCS + *after* inheriting the FITS cards from the old image in a NEW_COPY + operation. If the old image had a valid WCS it would be modified, + which is incorrect. Furthermore, there were cases where the WCS + editing could fail with an "image header parameter not found" error + when trying to change the values of nonexistent WCS parameters. + + The fix was to rip the WCS editing code out of stfrgpb.x. A new + routine stf_initwcs() (stfiwcs.x) has been added. This is called + in stfopen.x when a NEW_COPY image is created, after the new header + has been constructed, to check for the case of an uninitialized WCS + and set up the default unitary pixel WCS in that case. The WCS is + modified only if all elements of the CD matrix are zero, indicating + an unitialized WCS. (3/6) + +unix/boot/bootlib/envinit.c +unix/boot/bootlib/osgetenv.c +unix/boot/mkpkg/tok.c + Changed some SZ_LINE buffers to SZ_COMMAND buffers. (3/6) + +unix/boot/bootlib/ossysfile.c + Made a minor modification to ensure that filenames extracted from + the "pkglibs" file list do not contain any whitespace. (3/6) + +unix/boot/bootlib/envinit.c + The HSI layered package environment facility defines an environment + variable "pkglibs" which is the list of libraries (directories) to + be searched (in addition to the system libraries and IRAFULIB) to + satisfy a -llib or file reference in mkpkg or xc. pkglibs + is normally defined in the lib/zzsetenv.def of each layered package, + which is loaded at runtime when a HSI task is called with the -p + switch. This works fine so long as only a single layered package + environment is loaded. When multiple package environments are loaded + however, each package redefines pkglibs with the result that the + libraries of the packages already loaded will not be searched. + + To avoid this, loadpkgenv() (which is what is called to process a + -p switch) was modified to treat "pkglibs" specially, + concatenating new values onto a cumulative file list, rather than + redefining the "pkglibs" variable each time. This is a bit + questionable since this is inconsistent behavior for an environment + variable, but "pkglibs" is an integral part of the load-package- + enviroment facility and the special behavior occurs only when a + package environment is loaded. + + A note on the semantics of pkglibs and of environment varibles in + the HSI in general. In the HSI tasks, an environment variable + defined at the host level (or in the system wide file zzsetenv.def + in hlib) will override a variable defined in the package environment. + Hence for example, the logical directory of a subpackage of a + layered package can be redefined during development of a private + version of the package. In the case of "pkglibs", a host or system + wide definition of pkglibs is used only as the initial list of + package libraries to be searched; additional libraries defined by + -p pkg versions of pkglibs are concatenated to this list, with the + user defined libraries being searched first (IRAFULIB will override + all of this by being searched first, if defined). (3/6) + +----------------------- +Updated STScI to this point. (3/7) + +unix/boot/bootlib/envinit.c + Replaced the ENVPUTS by an ENVRESET, to be consistent with the + other routines which modify the environment list. Also, because the + HSI never deletes definitions from the environment list there is no + need to use ENVPUTS. (3/8) + +sys/gio/imdkern/imdclose.x + Added a call to "call ttycdes (g_tty)" to close the graphcap + descriptor at kernel close time. Probably this is not being done + in the other kernels either (altough it probably doesn't matter, + since about the only time a kernel is closed is when the process + shuts down). (3/8) + +sys/gio/imdkern/imdclws.x + Modified the closews function for the IMD kernel to call imd_close, + to fully close the kernel down. This causes any buffered graphics + to be flushed to the output device, and unmaps the frame buffer. + For the IMD kernel there is no reason to keep the frame open waiting + for append mode graphics, as the graphics is always drawn into the + frame buffer in "append" (overlay) mode anyhow, and we want graphics + to appear immediately without having to do a gflush. (3/8) + +dev/graphcap + Added the alias "imdkern" for device entry "imd". (3/8) + +unix/sun/imtool.c + The "sample" type (nonblocking) image cursor reads were not working, + in the sense that the coordinate value returned was always the same. + This was due to the routine returning the coordinates of the last + blocking cursor read, rather than the current cursor position. + Modified to return the coordinates of the most recent event (e.g., + mouse button press) seen in the image window. In SunView the locator + position is available to the application only when an event occurs. + (3/8) + +sys/gio/imdkern/imd.com +sys/gio/imdkern/imdclear.x +sys/gio/imdkern/imdopenws.x + idk_open() was being called with the wrong argument list in this + routine. The old calling sequence (device,tty) was being used, + instead of the IDK calling sequence (frame,color,tty). (3/8) + +dev/graphcap +sys/gio/imdkern/idk.x + The IMD kernel was modified to draw into the *current display frame* + if no output display frame is specified. This is the case, for + example, when the IMD kernel is used as a connected subkernel. + + For example, + + prow dev$pix 101 dev=imdg + + will plot line 101 of dev$pix in green on the current display frame. + This feature makes it possible to control both the graphics color + and the frame in which it is drawn when plotting directly to the + image display from a graphics task. (Note that it is also possible + to :.snap graphics output to the display device). + + The frame in which graphics is to be drawn is determined as follows. + If the frame specified by the IMDKERN parameter "frame" is greater + than zero then that frame is used, else if the fname number given by + the parameter "FN" in the graphcap is greater than zero that that + frame is used, else the current display frame is used. Hence, FN + must be absent or set to <= 0 in the graphcap for automatic output + to the current display frame to work. (3/8) + +pkg/plot/doc/contour.hlp + Modified the help page for CONTOUR to note that contours may not + appear to be centered on objects if a large blocking factor is used. + (3/8) + +pkg/plot/doc/imdkern.hlp + +pkg/plot/imdkern.par + When I went to edit the IMDKERN help page to document the new + semantics regarding the output frame, I discovered that there wasn't + any help page! I added a help page for IMDKERN, and modified the + default parameters in plot/imdkern.par. (3/8) + +sys/gio/imdkern/imdcancel.x +sys/gio/imdkern/imd.com + These files still contained some vestiges of the SGIKERN origins of + IMDKERN. The IMD common was still called /sgicom/ (harmless so long + as the kernels are in separate processes, but incorrect) and the + imdcancel.x procedure header comment was still calling the procedure + SGI_CANCEL. (3/9) + +unix/hlib/mkfloat.csh + This routine is supposed to print out the names of any "dreg .e files + left lying about in the source directories" if it finds any. An + otherwise harmless problem with the use of "tee" in the script was + preventing these filenames from being echoed. (3/9) + +sys/imio/iki/stf/stfrfits.x + The STF header file cache logic could fail to invalidate the cache + if the header was entered in the cache, modified on disk, and then + reread all within one second, the time resolution of the timer used + for the cache. To avoid this it was necessary to force a reload if + the file modify time is equal to the cache time. This means that + if a file is created and then immediately loaded into the cache, + the cached entry will not be valid even if the image has not been + modified since it was created. The next reload (provided it occurs + a second or more later) will however result in a valid cache entry. + (3/9) + +sys/imio/iki/stf/stf.h +sys/imio/iki/stf/stfopen.x +sys/imio/iki/stf/stfupdhdr.x + The semantics of the STF kernel regarding updates to the FITS header + (global header for all images in the group) was modified to clarify + the distinction between the global header, which pertains to all images + in the group, and the GPB, which by definition contains any header + parameters which can vary for each element of the group. + + The new strategy for FITS header updates is to always update, unless + we are explicitly updating an existing group of a multigroup image. + Hence, the FITS header is always updated for an STF image with only + one group, or when writing the first group of a new multigroup file. + The FITS header of an existing STF multigroup image can still be + updated, but only if the image is not opened to any particular group, + e.g., as "pix" rather than "pix[i]", I > 0 (i.e., "pix" and "pix[1]" + are not equivalent when it comes to global header updates!). An image + opened NEW_[IMAGE|COPY] or READ_WRITE to access "pix[i]" will update + only the GPB header. + + It is suggested that to avoid confusion, multigroup STF images be + regarded as read-only once created. If the multigroup image is + created with IRAF the FITS header should be fully defined when the + first group is written, opening the image [1/NGROUP]; subsequent + writes to subimages [i] will write only the GPB of the subimage. + During interactive reductions the user should create only single + group images. These should be functionally compatible with OIF + images in all respects including header updates (except that the + contents of the header will not in general be the same, e.g., OIF + does not define a default PIXEL WCS). (3/9) + +---------------- +Updated DECstation/IRAF. (3/10) + +unix/boot/bootlib/osputenv.c + 1. Replaced a 1024 by SZ_COMMAND. + 2. Merged in #ifdef ultrix stuff for the DECstation. (3/10) + +sys/osb/ieee.gx + The BSWAP routines were being called improperly. (3/10) + +pkg/system/help/manout.x + Increased the maximum number of lines per page from 128 or so so + 1024. (3/10) + +sys/etc/pagefiles.x + 1. When paging a text file and 'G' was typed to go to the end of the + file, the pager would actually go one line too far, causing one line + less than a full screen to be displayed. + 2. The pager was revised so that the 'N' and 'P' keys now have a + dual meaning. When paging a list of files they are used to move to + the next or previous file in the list, as before. When paging a + single large file, they are used to move to the next or previous + formfeed delimited page. The character, line, and page number + accounting was also revised and extensively tested to ensure that + seeks, searches, next/previous screen/page, etc., get to the right + place and report the right line number. (3/11) + +pkg/system/phelp.cl + +pkg/system/doc/phelp.hlp + +pkg/system/system.cl +pkg/system/system.hd +pkg/system/system.men + Added a new task PHELP to the system package. PHELP is a CL script + front end to HELP, which runs HELP with the output redirected to a + tmp file, then pages the tmp file with PAGE. The simple usage is + "phelp task" but more complex usages such as "phelp proto.*" are + also possible (in the latter case the 'N' and 'P' keys are used + to view successive formfeed delimited help pages in the tmp file). + + All this seems to work fine, except for an as yet unresolved bug + in HELP which is causing some packages to appear twice. For example, + PLOT appears twice in the help database for some reason, and typing + "phelp plot.*" works, but one gets all the help pages and then all + of them all over again. Harmless, but annoying. (3/11) + +sys/etc/pagefiles.x + Added an upscroll capability to the file pager. This seems to work, + but the pagefiles code is a mess and there may still be special cases + or combinations of commands where things don't work quite as expected. + This code has grown far beyond its original design and should be + junked and reengineered eventually. (3/12) + +pkg/lists/rimcursor.x + 1. Modified the task so that if only the first 2 or 3 fields of the + cursor value are input (e.g., x and y) only those fields are output. + 2. If the reference image open failed, a non-NULL pointer ct could + be returned. (3/13) + +dev/graphcap +dev/cachet.dat + The default "xterm" entry in graphcap now disables the "am" (auto + margin) capability. Evidently xterm will indeed autowrap at the + right margin, but it is clever and eats up any cr/lf/tab characters + which follow the autowrap. If the following line begins with one + or more tabs, these are eaten by xterm and the line will not + indented properly. If one dumps the same file to xterm with the + unix "cat", things work as expected as cat ignores details like + automargin and dumps out the newline at the end of the line. Hence, + although the terminal does implement something like AM, it appears + that this can be safely ignored and a newline sequence output after + writing a character in the right margin. It is possible that the + iraf terminal output code is not interpreting AM properly, but for + the present I am going to disable the AM in the iraf version of the + termcap entry (the unix version enables AM). (3/13) + +~sites/logmail.c + The LOGMAIL support utility (part of the iraf/site mail) was modified + to strip the "Received:" lines and continuation lines out of logged + site mail. (3/13) + +--------------------- +Updated stsci to this point. (Tried to update cfa but couldn't get in). +Updated ffpa binaries on tucana. (3/13) + +unix/sun/imtool.c + The IIS datastream reserves 9 bits (resolution 512) for the X and Y + addresses in an image memory write or read. The IMTOOL code was using + a 10 bit mask (01777 = resolution 1024) of the X/Y values for reads, + and a 12 bit mask (07777 = 4096) for writes. Hence, normal write + only image display with IMTOOL (or SAOIMAGE) would work fine for + images up to 4096 square, but read back would fail for images larger + than 1024 square. It turns out that the IIS datastream protocol + (which IMTOOL/SAOIMAGE emulate) can actually support X and Y bitfields + of up to 14 bits, so there should be no problem increasing the size + of these bitmasks. I increased the size of the X and Y address bitmask + used in IMTOOL to 077777 (max 32768 resolution) for both reads and + writes. SAOIMAGE should be similarly modified. The DISPLAY code + does not limit the size of X and Y addresses so there should be no + problem there. (3/14) + +----------------- +Updated decstation (cephus). +Installed the 13Mar beta system for CFA. (3/14) + +----------------- +Begin VMS/IRAF update to V2.9. (3/17) +Rebuilt system from tucana sources and VMS/IRAF HSI. +Merged in V2.9 HSI revisions. +Begin bootstrap and sysgen. + +vms/os/zopcpr.c + The struct "acc$record", defined in , is used for the + mailbox termination message at process exit. For VMS5, the name + of this structure is evidently changed to struct accdef. Changed + the source accordingly (and we are no longer source compatible with + VMS4). (3/17) + +generic/mkpkg.com +mkpkg/mkdebug.com +mkpkg/mkpkg.com +mkpkg/mkpkg +rmbin/mkdebug.com +rmbin/mkpkg.com +rmfiles/mkpkg.com +rtar/mkpkg.com +spp/xc.com +spp/mkpkg.com +spp/rpp/mkpkg.com +spp/xpp/mkpkg.com +wtar/mkpkg.com + In the first attempt to link the HSI utilities under VMS5, all the + links failed with the message + + undefined symbol LIB$FIND_IMAGE_SYMBOL... + + After looking around at the system libraries for a bit, purely on + a guess, I changed the line + + $ define/nolog LNK$LIBRARY sys$library:vaxcrtl.olb + + to + + $ define/nolog LNK$LIBRARY sys$library:vaxcrtl.olb + $ define/nolog LNK$LIBRARY_1 sys$library:imagelib.olb + + in all the mkpkg.com and mkpkg files in the HSI. Evidently a C + runtime library routine now references the system run time library + LIBRTL in VMS5, so this (in the system shared image) has to be + searched now if VAXCRTL is used. (3/17) + +unix/boot/spp/xpp/decl.c + The VMS Fortran compiler barfed on the use of ARB for array argument + declarations, complaining about the array dimension exceeding + addressable memory. I expected problems with this construct anyway, + so it was necessary to change the SPP preprocessor to avoid the + problem. Several other improvements were made in the process. + + 1. ARB in array argument declations is now replaced by the Fortran * + symbol, e.g. "int foo[ARB]" becomes "integer foo[*]". + 2. +1 is no longer added to char arrays that are procedure arguments. + This is now only done for local arrays. (The +1 is added by the + preprocessor to allow space for the EOS in an SPP string). + 3. Dimensioning a local array ARB is now considered an error and will + result in a compile time error message from the preprocessor. (3/18) + +sys/mwcs/wfinit.x + The VMS Fortran compiler didn't like the duplicate definition of + wf_smp_tran(), originally used since the same function appears twice + in the function driver. (3/18) + +pkg/dataio/fits/fits_rpixels.x +pkg/dataio/fits/fits_wpixels.x +noao/mtlocal/camera/cam_rpixels.x +noao/mtlocal/pds/pds_rpixels.x +noao/mtlocal/r2df/r2dfrpix.x +noao/twodspec/multispec/msextract.x +noao/twodspec/multispec/fitgauss5.x + These files contained routines with ENTRY points wherein an array + argument was dimensioned ARB. This fooled the SPP compiler, which + now checks for local arrays dimensioned ARB. ENTRY points should + probably be considered illegal in SPP code (certainly they are + discouraged, as they are a common source of compiler problems). + As a workaround for the present I changed the code to dimension + the entry point arrays [1] rather than [ARB]. (3/18) + +noao/astutil/t_setairmass.x + This file contained several occurrences of the construct mod(dble,24.). + VMS Fortran insists that the arguments to intrinsic functions all be + the same type, and even a double and a real as in this case is not + permitted. Changed the 24. to 24.D0 and it compiled ok. (3/18) + + Linking this process on VMS took so long that I ran a timing test + comparing the VMS 8600 to the Sun-3 180 (tucana). Linking -z on + both systems tooks 5 minutes on the 8600 vs 1 minute on the Sun-3. + +vms/uis/* + Installed the latest version of the UIS display program for VMS + (the VAXstation), contributed by Nigel Sharp. (3/18) + +[vms shared libraries note] + The following error message appears on our system when some of the + iraf processes are linked. So are as I can tell it is harmless, + and probably not worth trying to track down. + + %LINK-I-DATMISMCH, creation date of 14-JUN-1989 11:48 in shareable + image SYS$COMMON:[SYSLIB]DISMNTSHR.EXE;2 + differs from date of 10-MAY-1989 17:37 in shareable image library + SYS$COMMON:[SYSLIB]IMAGELIB.OLB;1 + +vms/gdev/mkpkg +vms/gdev/zfiogd.x +vms/gdev/zfiovi.c + + Installed a new version of ZFIOGD (graphics or image device i/o driver) + for VMS. The IMTOOL device code in this VMS version uses VMS mailboxes + (rather than fifo pipes as in unix) to talk to the display server + process. This new driver was written by Jay Travisano of STScI. + It is used to interface SAOIMAGE to VMS/IRAF, but it could be used for + any other display server as well (e.g., UISDISPLAY could use this + interface too if suitably modified). At this point, the new driver + has only been installed. Checkout will have to wait until we are + ready for full system testing with a display server. (3/18) + +------------------------ +V2.9BETA shapshot of DECstation/IRAF and VMS/IRAF sent to STScI. (3/19) +Update of Sun386i/IRAF begun. (3/19) + +sys/etc/pagefiles.x + 1. Fixed a bug in the pager which would allow one to upscroll past the + beginning of file. + 2. Typing space at the end of a file causes the pager to move to the + next file in a file list, i.e., the space is turned into an 'N'. + This could cause problems when paging a single file, in which case the + 'N' is interpreted as go to next page. On VMS this was leading to a + seek error on the file being paged (not clear why that was but I did + not have time to pursue it further). (3/19) + +pkg/cl/builtin.c + A command such as "flpr beep" would cause a segmentation violation + in the CL. This command is pointless since BEEP is a builtin task + (no process in the cache) but the CL should complain a bit more + gracefully. Modified the FLPRCACHE builtin to check for script, + foreign, builtin, and pset tasks and abort with "task `foo' not in + cache" if flprcache is called with the name of such a task. (3/19) + +sys/etc/pagefiles.x + The string length of an output line of text was being used to compute + the number of terminal lines required to display a long line of output + text. This computation could fail when the line being displayed + contained a large number of control characters, e.g., tabs, or font + control or enhancement codes. Not a serious problem, but the number + of lines output to fill a screen could be wrong. (3/20) + +pkg/system/news.cl +unix/hlib/newsfile - +doc/newsfile + +doc/news.old.hlp + +doc/news.v28.hlp + + The NEWS facility was reworked to provide more up to date information + about the system. The NEWS program merely pages the system news file, + now moved to doc$newsfile. At present all this consists of is a + concatenated sequence of revisions summaries. Formfeeds separate + successive revisons summaries. The revisions for the current release + of the system are paged first, with the 'N' key providing access to + the old news. (3/20) + +pkg/system/help/lroff/texout.x + Another ancient file that uses ENTRY points, had to change a "local" + [ARB] to [1]. (3/20) + +pkg/images/iminfo/t_imstat.x + This program contained a statement [format = clgetb("format")], where + "format" is type integer. This fails on VMS because the internal + values used for boolean (Fortran logical) are not 0/1 as in UNIX. + The construct is always illegal of course, it merely happens to + work on UNIX because the internal representation of bool and the + SPP YES/NO are identical. (3/20) + +sys/fio/ffilsz.x + The file size code (e.g., fstatl(fd,F_FILESIZE)) did not support + file types STRING_FILE and SPOOL_FILE at all. A call to the binary + file driver was being made even though there was no physical file + associated with the file descriptor! The routine ffilsz.x was + modified to add support for the memory buffer file types. The new + STF image kernel uses fstatl to query the size of the spool file + used to store the image header, and the bogus file size being returned + could lead to a segmentation violation in some circumstances. (3/20) + +sys/fio/fexbuf.x + The amount by which a spool file buffer size is incremented if + overflow occurs was increased from 1024 to 4096 chars. This is + arbitrary, but will be slightly more efficient when writing large + spool files. (A call to fseti(fd,F_BUFSIZE,n)) can be made before + writing to the spool file if the amount of space needed is known + in advance). (3/20) + +unix/os/zfacss.c + Modified ZFACSS, used to test whether a file is binary or text, + to permit a narrow range of control codes in text files. This is + necessary in order to allow iraf text files containing standout mode + control characters or form feeds to be considered part of the source + distribution. (3/20) + +--------------------- +All local beta test systems (f68881, sparc, 386i, decstation, vax/vms) +updated to this point. (3/20) + +unix/hlib/zzsetenv.def + Added an entry for "nomwcs". Currently, this is commented out on + the irafx systems, but defined (MWCS is disabled) for the user + systems. (3/21) + +--------------------- +V2.9BETA installed on NOAO/Tucson Sun network (orion, gemini). (3/21) + +dev/hosts + Added several new "scientist workstation" entries from gemini, on + all local nodes. (3/22/90 SRo) + +dev/devices.hlp + Updated to include the three tape drives on gemini. (3/22/90 SRo) + +sys/imio/iki/stf/stfopen.x + This routine contained an illegal call to ERRACT at the end of the + procedure, in the error exit code. The call was illegal because + ERRACT can only be called from within an error handler, to take an + action based on the error currently being processed. The correct + thing to do in the case of stfopen was merely to return an error + status, since this procedure uses a status output argument. (3/21) + +unix/os/zdojmp.c + This routine would pass a zero status on to the ZSVJMP call at the + other end of the jump buffer. This is incorrect, since ZSVJMP/ZDOJMP + are modeled after the unix setjmp/longjmp, and setjmp must not return + a zero status when the return is via a longjmp. This bug could lead + to an error condition going undetected when error recovery resulted + in a jump back into the iraf main. Calling ZDOJMP with a zero error + code is very rare, i.e., it does not happen in the normal execution + of the system, but it was occuring as a result of the STFOPEN bug + above. (3/21) + +doc/ports/notes.mips + Replaced by a later version of the file containing a few notes on + the second update (hereafter, decstation revisions will be documented + in the master systems notes file). (3/21) + +sys/imio/iki/stf/stfopen.x + When an STF image is opened new-copy, the old STF header is copied + to the new image in stfopen.x. This was being done by copying the + maximum size descriptor LEN_STFDES, but in the new V2.9 STF kernel + the STF descriptor is reallocated once an image is opened to save + space. Hence the actual descriptor length can be less than LEN_STFDES, + and the amovi operation used to copy the descriptor could result + in a segmentation violation if the old descriptor buffer happened + to be located near the end of dynamic memory. (3/21) + +---------------- +DECstation updated. (3/21) + +unix/boot/rtar/rtar.c + Made the same change to the file type heuristic as made in the + ZFACSS revision on 3/20 (certain formatting control codes are now + considered legal in text files). (3/24) + +---------------- +VMS/IRAF updated. (3/24) + +unix/hlib/motd + Revised the standard motd to include mentioned of the revamped NEWS + facility. (3/24) + +pkg/system/doc/news.hlp + Updated the help page for NEWS. (3/24) + +unix/boot/mkpkg/char.c +unix/boot/mkpkg/mkpkg.hlp + The syntax "$(@file)" can now be used to substitute the contents of + a text file during mkpkg file interpretation. (The old macro + replacement forms are "$(symbol)" to substitute the value of a + symbol or environment variable, and "$(?symbol)" to interactively + query for the value of a symbol). (3/24) + +unix/shlib/mkpkg +unix/os/zzstrt.c + Modified the the shared library facility to support multiple shared + image versions. The shared image, instead of being named "S.e" is + now named "Si.e", where "i" is the major version number. For example + the current shared library version for most V2.9 architectures is 4, + and the shared image is named S4.e. The name "S.e" is reserved for + the V2.8 shared image (since that is what V2.8 executables will be + looking for, lacking version number support). (3/24) + +-------------------- +tucana{f68881,ffpa,sparc}, orion, pegasus updated. (3/25) + +noao/lib/strip.iraf + 1. Added ".fits" to the list of files to be retained in the strip + operation. + 2. Changed the OBJS.arc in the special files area to OBJS.arc.Z, + changed a .68881 to .f68881, added sparc and i386 entries. (3/26) + +-------------------- +V2.9BETA updated at STScI. (3/26) + +sys/imio/iki/oif/oifmkpfn.x + FATAL was being called in this file with a missing argument, causing + a segmentation violation in the unlikely event that the call was ever + made (due to failure to generate a unique pixel file name). Replaced + by a call to IMERR. I cannot recall why the call to FATAL was being + made, unless it was because it is supposed to be impossible under + normal conditions to fail to generate a unique file name, indicating + some serious problem if this occurs. (3/27) + +-------------------- +gemini incrementally updated from orion, including layered pkgs. (3/28 SRo) + +sys/imio/iki/stf/stfrfits.x + The STF caching code had a nasty hidden assumption which could lead + to repeated cache reloads in some circumstances. When a header file + is loaded into the cache, the clock time on the local cpu is stored + in the cache slot to mark the time of the load. When the cache is + subsequently searched for a cached header file, the file modify date + of the header file is compared to the time when the cache slot was + loaded, and the header is reloaded if the modify date is greater than + or equal to the cache load time (the equal-to is needed due to the + limited resolution of the clock). + + The hidden assumption is that the clock used for the file modify time + is the same as that used to mark the time when the cache slot is + loaded. If the file being accessed is on a different machine with a + different clock (due to a NFS access), the file modify clock and the + local clock can easily differ by several minutes! This could lead + to two problems: 1) if the remote clock was ahead, the file modify + time could be greater than the local ttime, causing the cache to be + continually reloaded (due to a repeat loop in the code) until the + time difference was made up, or 2) if the remote clock was behind, + file modifications occuring during the interval defined by the + difference between the two clocks could go undetected. + + The solution adopted was to reload the file into the cache if the + modify time *changes*, rather than comparing it to some other time + which could be on a different time base. To avoid the problem of + file modifications going undetected which occur quicker than the 1 + second resolution of the clocks, the local timer is used to measure + the time since the file was loaded into the cache. If the cache slot + is less than 1-2 seconds old, the file is reloaded into the cache + (the 2 seconds is necessary to ensure that 1 full second has passed). + If the file is reloaded within the 1-2 second interval the timer is + not restarted, hence so long as the file modify time does not change, + the cache slot will be considered valid within 1-2 seconds after the + initial load. (Amazing how tricky these things can be). (3/29) + +--------------------- +Updated tucana{f68881,ffpa,sparc}, orion{f68881,ffpa,sparc,i386}, +pegasus{i386}, draco/irafx. (3/30-31). + +--------------------- +IRAF V2.9 RELEASE FROZEN - except for installation of a few things completed +but not yet checked out and installed (IEEE support for VMS, new version of +PLOT, online release notes, etc). (4/2) + +unix/as.vax/ieeer.s + +unix/as.vax/ieeed.s + +vms/as/ieeer.s + +vms/as/ieeed.s + +vms/hlib/mkpkg.sf + Installed VAX versions of IEEE/native floating point conversion + primitives. (4/2) + +sys/osb/ieee.gx + The IEEE conversions package was modified to add the two routines + + iee[sg]nan[rd] (NaN) + e.g. + call ieesnanr (INDEFR) + + to set NaN to INDEFR (the default is zero). NaN is the native + floating point value to which IEEE NaN, +/-Inf, exponent overflow, + and so on are mapped when converting IEEE values to native floating + point values. + + Since the "portable" routines in osb$ieee.gx have no way of detecting + the IEEE not-a-number values or of dealing with overflow, the default + iee[sg]nan[rd] routines do nothing even though they are included in + the interface. For these routines to do anything, and for NaNs to + be trapped during IEEE input, machine dependent versions of the files + osb$ieee[rd].x must be provided in host$as, with an entry on the + special file list to cause the system to use the host dependent + versions of the files. + + While the new routines provide a simple way of dealing with NaNs which + is consistent with our current applications, this is not the end of the + story. In the future we will probably need to add a function-callback + capability, which will allow the application to dynamically post a + function to be called by the host level conversion primitives when a + NaN is detected or generated. Use of a callback will allow efficient + generation of a bad pixel list as well as replacement of NaN values + by a constant or data dependent value. (4/2) + +pkg/cl/prcache.c + The process cache code checks the file date of a cached process + whenever a task is run to see if the process has been relinked and + needs to be restarted (often the case when doing software development + from within the iraf environment). It occurred to me that this + probably suffers from the same assumption as did the STF cache code + (3/29), i.e., the test can fail if the process resides on a remote + system being accessed via NFS, and the clocks of the local and remote + systems differ. Checking the code this was indeed the case, so I + modified the cache test code to mark the cache slot with the file + modify time rather than with the local cpu time when the process was + cached. (4/4) + +unix/hlib/login.cl + Changed the template login.cl to define "grep" rather than "bgrep" + in the default user package. (4/4) + +pkg/plot/doc/pvector.hlp +pkg/plot/getdata.x +pkg/plot/mkpkg +pkg/plot/pvector.par +pkg/plot/t_contour.x +pkg/plot/t_pcol.x +pkg/plot/t_pcols.x +pkg/plot/t_prow.x +pkg/plot/t_prows.x +pkg/plot/t_pvector.x +pkg/plot/t_surface.x + 1. The tasks PROW,PROWS,PCOL,PCOLS were largely rewritten. Outwardly + they will appear much the same as before, but they will now work with + group (STF) data, QPOE filters, image sections, and in general any + image specification that uses []. + 2. SURFACE and CONTOUR were modified to work with image specifications + containing []. + 3. PVECTOR now provides an option to output the vector as a text file + or image, rather than always making a plot. (4/4) + +qpqueryf.x +qpiolmask.x +qploadwcs.x +qpiolwcs.x +qpsavewcs.x +zzdebug.x + 1. Added a new debug task SETWCS to the QPOE zzdebug.x. The new task + was used to test qp_savewcs, which saves a MWCS wcs object in a QPOE + file. + 2. In qpiolmask.x qp_read was being called with the datatype field + TY_OPAQUE. In qp_loadwcs.x and qp_savewcs.x qp_read and qp_write + were being called with a datatype field of TY_CHAR. Both of these + cases were wrong, as the datatype field is a string in these calls. + Changed all calls to use the datatype "opaque", since that is what + the encoded PLIO and MWCS objects are. + 3. The linear transformation vector in qpiolwcs.x wasn't quite right; + the bounding box coordinates were used directly to form the translation + vector, but those coordinates are one indexed so I had to subtract + one to get the translation. + 4. In qpqueryf.x, fixed a typo: the datatype of an opaque parameter + was being returned as "oqaque". + + Performed a full system test, using the zzdebug.setwcs task to save + a wcs in a test qpoe file, and imheader to load and display the wcs + through the higher level code. [Only QPOE could be affected by these + changes]. (4/10) + +vms/x11/0readme.xterm + +vms/x11/xterm.e + +vms/x11/xterm.hlp + +vms/x11/saoimage.e + +vms/x11/saoimage.hlp + +vms/x11/setup.com + + Installed a minimal set of executables and help files for the VMS + versions of SAOIMAGE and XTERM in vms/iraf. These are very + preliminary, the release is incomplete, and there are known bugs, + but someone may find the shapshot versions of these tasks useful + while a more carefully prepared release is readied. (4/15) + +vms/os/queue.c +vms/os/jbcmsgdef.h + Following the upgrade to VMS-5, VMS/IRAF had a bug wherein once a + job submitted to a batch queue completed, an abnormal termination + message JSB$_NOSUCHENT would be written to the terminal, and a + subsequent "jobs" would cause the CL to panic with an access violation. + The reason for the access violation is not clear, but the NOSUCHENT + termination code is evidently new in VMS-5, and the job queue code + in the VMS HSI wasn't prepared for such a status return. Changed + the code in queue.c to check for and ignore both the old VMS-4 status + return JBC$_NOSUCHJOB and the new VMS-5 code JBC$_NOSUCHENT. The + kernel also had a local file jbcmsgdef.h from VMS-4 which did not + contain the new VMS-5 codes; it was not clear why the kernel needs + a private copy of these definitions, so a dead code comment was + placed in the file and the #include in queue.c was changed to use + the system version instead. (4/15) + +doc/newsfile +doc/news.v29.hlp + +doc/v29revs.ms + + Installed the revisions summary or release notes for IRAF V2.9. (4/15) + +------------------------- +The V2.9 distribution was made and placed into distribution sometime back. +The following bugs are being fixed retroactively, with patches for the +original V2.9 distribution. (5/5) + +unix/spp/boot/spp/xpp/decl.c + This code was not processing multidimensional char array declarations + properly. There were actually three problems: for a multidimensional + array passed as an argument, [1] +1 was not being added to the first + axis to allow for the EOS, and [2] the axis was not being counted, + causing +1 to be added to the *final* axis later in the code. + [3] for all multidimensional char arrays the code was not checking to + see which axis it was on before adding the +1, so +1 would be added + to each axis, instead of only the first axis as it should be. (these + bugs were contstrained to only several lines of code, it takes more + lines to describe them here!). Note that ONLY multidimensional char + arrays were affected by these bugs, and for char arrays of ndim=2, + ONLY arrays declared as arguments to procedures. (5/5) + +unix/shlib/mkshlib.csh +unix/shlib/S.ver.f68881 +unix/shlib/S.ver.ffpa +unix/shlib/S.ver.sparc +unix/shlib/S.ver.i386 + Sun release SunOS 4.1 about a week after Sun/IRAF V2.9, built on + SunOS 4.0.3, was frozen and prepared for distribution. We subsequently + found that V2.9 would not run under SunOS 4.1, failing with a "cannot + map shared image" error during process startup. This was traced to + an overlap of the region of virtual memory used by the hardware stack + and the IRAF shared image; in OS 4.1, Sun has moved the hardware + stack to a lower address. The following changes were made to deal + with this. + + 1. The base address of the IRAF shared image was changed from + 0x0e000000 to 0x0a000000. The base address of the shared image + is arbitrary so long as the region of process virtual memory occupied + by the shared image does not conflict with anything else, so this + change should not affect the functioning of V2.9. + 2. The shared image version number was incremented to 5, i.e., the + new shared image is S5.e. This was necessary because with a different + base address, the new shared image cannot be used with applications + linked with the old shared image. (5/5) diff --git a/doc/pac_title.ms b/doc/pac_title.ms new file mode 100644 index 00000000..89acd85f --- /dev/null +++ b/doc/pac_title.ms @@ -0,0 +1,25 @@ +.RP +.TL +IRAF Applications Packages +.br +Package Structure and Requirements +.AU +IRAF Group +CSAC +.AI +.K2 "" "" "*" +September 1983 +(draft) +.AB +The IRAF applications software is decomposed into a set of modular +\fIpackages\fR, i.e., collections of related CL callable programs. +The requirements for each package are outlined, and the interdependence of +the separate packages are described. This document concentrates on the +scientific capabilities of the IRAF system, i.e., on the form of the system +as viewed by the user at the command language (CL) level. Though an attempt +has been made to include descriptions of all packages currently planned +for the system, we have presented only the minimum requirements for each +package. Finally, the current KPNO reduction and analysis software is +summarized, giving for each existing program the name of the corresponding +IRAF package which will provide comparable functionality. +.AE diff --git a/doc/pac_toc.hlp b/doc/pac_toc.hlp new file mode 100644 index 00000000..6470e945 --- /dev/null +++ b/doc/pac_toc.hlp @@ -0,0 +1,84 @@ +.help packages Sep83 "IRAF Package Structure" +.ce +Contents + +.rj 1 +1. Introduction + +.rj 1 +2. Top Level Packages + +.rj 1 +3. Notes on Individual Packages +.in 5 +.rj 2 +3.1 Package ARTDATA +.rj 3 +3.2 Package ASTROMETRY +.rj 3 +3.3 Package DATABASE +.rj 3 +3.4 Package DATAIO +.rj 5 +3.5 Package DIGIPHOT +.rj 6 +3.6 Package DTOI +.rj 7 +3.7 Package FILTERPHOT +.rj 8 +3.8 Package FOCAS +.rj 8 +3.9 The HELP Utility +.rj 9 +3.10 Package IMAGES +.in 5 +.rj 9 +3.10.1 Image display load +.rj 10 +3.10.2 Display control +.rj 11 +3.10.3 Image graphics (plotting) +.rj 13 +3.10.4 The image calculator +.rj 15 +3.10.5 Grayscale mapping operators +.rj 16 +3.10.6 Geometric transformation operators +.rj 18 +3.10.7 Filtering operators +.rj 19 +3.10.8 Background or bias fitting and removal +.rj 19 +3.10.9 Image editing operators +.in -5 +.rj 20 +3.11 Package IMRED +.rj 22 +3.12 Package LANGUAGE +.rj 22 +3.13 Package LISTS +.rj 23 +3.14 Package ONEDSPEC +.rj 25 +3.15 Package SOFTOOLS +.rj 26 +3.16 Package NSURFBRT (to be renamed) +.rj 27 +3.17 Package SYSTEM +.rj 28 +3.18 Package TWODSPEC +.in 5 +.rj 28 +3.18.1 The MULTISLIT package +.rj 29 +3.18.2 The LONGSLIT package +.in -5 +.rj 31 +3.19 Package UTILITIES +.rj 31 +3.20 Special Packages +.in -5 + +.rj 32 +4. Correspondence of existing KPNO software to IRAF Packages +.endhelp diff --git a/doc/packages.hlp b/doc/packages.hlp new file mode 100644 index 00000000..9077fa68 --- /dev/null +++ b/doc/packages.hlp @@ -0,0 +1,1986 @@ +.help packages Aug83 "IRAF Package Structure" +.sh +1. Introduction + + This document is a first attempt to fully define the decomposition of +the IRAF system and applications software into packages. The functions +to be supplied by each package are summarized. The names of some of the +individual packages are likely to change. Given the package structure +detailed below, the IRAF root menu would appear as follows: + +.nf +cl> ? + artdata digiphot help lists system + astrometry dtoi images nsurfbrt twodspec + database filterphot imred onedspec utilities + dataio focas language softools +.fi + +.sh +2. Top Level Packages + + If the command HELP is typed without any arguments, the default action +is to print out a summary of the contents of the current package, giving +a one line description of the function of each package. The nonspecific +HELP documentation for the root package, i.e., the package "clpackage", +might appear as follows: + +.nf + artdata artificial data generation + astrometry astrometric routines + database database management utilities + dataio data format conversions (FITS, card image, etc.) + digiphot digital stellar photometry + dtoi density to intensity transformations + filterphot filter photometry reductions + focas faint object classification and analysis + help online help utility (not a package) + images general image processing and display + imred image reductions + language language stuff (task, kill, set, etc.) + lists list processing utilities + onedspec one dimensional spectra + softools software tools + nsurfbrt new surface brightness package + system system utilities (files etc.) + twodspec two dimensional spectra + utilities miscellaneous utilities +.fi + +.sh +3. Notes on Individual Packages + + Each top level package may contain any number of tasks or second level +packages. As we proceed lower into the hierarchy, the tasks and packages +become more specific in the type of data they deal with. An individual +task should not be duplicated in several packages; a task which is needed +in more than one package should be defined at a higher level in the hierarchy. +Examples of such general purpose tasks include HELP, and the tasks in the +LISTS and SYSTEM packages. + +.sh +3.1 Package ARTDATA + + The ARTDATA package shall provide routines for the generation of +artificial data. The principal use of artificial data is for testing +reduction and analysis software, making objective comparison of algorithms +and packages possible, and quantifying the non-systematic errors of such +software. The package shall meet the following requirements: +.ls 4 +.ls (1) +It shall be possible to model the noise functions of various detectors. +.le +.ls (2) +It shall be possible to add noise to an image, by randomly sampling +a gaussian or poisson distribution, the width of which is some function +of pixel intensity (this is determined by the noise model). +.le +.ls (3) +It shall be possible to analytically model line and point spread functions. +.le +.ls (4) +It shall be possible to model the characteristic curve of photographic +plates (and possibly other nonlinear detectors). +.le +.ls (5) +It shall be possible to generate diagnostic rasters, including constant +rasters, gaussian or poisson noise rasters with a constant noise function, +multidimensional smooth distributions (i.e., two dimensional gaussians, +ellipses, and legendre surfaces), stepwedge, stairstep, ramps, and so on. +.le +.ls (6) +It shall be possible to generate artificial starfields, optionally including +scaled galaxy images randomly selected from an digital library, wherein +the noise function, luminosity function, point spread function, spatial +distribution, and non-linearity are all modeled. +.le +.ls (7) +It shall be possible to generate artificial one and two dimensional spectra, +wherein the noise function, line spread function, line list, dispersion, +and geometric distortions (pincushion, s, and tilt) are all modeled. +.le +.ls (8) +All model parameters used to generate an artificial image shall be saved +in such a form that they can be compared with the parameters derived by +reduction and analysis software to compute errors. It shall be possible +to export model parameters on a FITS or cardimage tape, along with the +artificial image. +.le +.le + +.ks +.nf +Subpackages: + + artstars artificial starfield generation + artspec artificial 1&2 dim spectra generation +.fi +.ke + +.sh +3.2 Package ASTROMETRY + + A collection of routines for performing astrometry. Coordinate +input generally comes from other packages; the astrometry routines +determine the image coordinate system and transform object coordinates +in pixels into other coordinate systems. The following functions shall +be provided: +.ls +.ls (1) +It shall be possible to determine the coordinates of an object or objects +within an image by fitting gaussians or discrete psf marginal profiles to +the marginal profiles of the image. +.le +.ls (2) +It shall be possible to determine the transformation from pixel to user +coordinates for an image given the pixel and user coordinates of 1, 2, +or 3 or more stars in the image. The computation of the coordinate +transformation shall be decoupled from the generation of object coordinates. +It may be desirable to provide several types of transformations to model +the geometric distortions of various detectors. +.le +.ls (3) +The transformation parameters shall be saved in such a form that they +can be edited by the user or supplied by external programs. +.le +.ls (4) +It shall be possible to apply the coordinate transformation to convert +a list of coordinates from one coordinate system to another, +given the input list, the names of the input and output coordinate systems, +and the transformation descriptor. +.le +.le + +.sh +3.3 Package DATABASE + + The IRAF database management utilities. Routines shall be included for +inspecting, editing, copying, and otherwise manipulating the contents +of datafiles. The IRAF system does not yet have a database capability; +the requirements for the DATABASE package will be defined when the +form of the IRAF database facilities have been worked out. + +.sh +3.4 Package DATAIO + + Routines for data format conversion. The essential thing here is +format conversion; although files will often be read or written to magtape, +we should not build conversion routines so that they work only on magtape +devices. As networking becomes more widely used on our systems, we will +wish to use the same conversion routines to read and write data transmitted +electronically between machines. DATAIO shall provide the following +capabilities: +.ls +.ls (1) +It shall be possible to convert a FITS file into an IRAF imagefile, +and vice versa. +.le +.ls (2) +It shall be possible to convert a PDS file into an IRAF imagefile. +.le +.ls (3) +It shall be possible to convert a CAMERA file into an IRAF imagefile. +.le +.ls (4) +It shall be possible to convert a card image file into a text file, +and vice versa. +.le +.ls (5) +It shall be possible to convert a binary file containing only text into +a text file, and vice versa. +.le +.ls (6) +It shall be possible to copy a binary file, changing only the blocking +factor. +.le +.ls (7) +Each conversion routine shall be able to operate on either magtape +resident or disk resident files (this capability is already provided +by the IRAF magtape i/o interface). +.le +.le + +Note that function (6) in combination with requirement (7) provides a +means of copying a file from magtape to disk or vice versa, or from one +tape drive to another. In the process the tape record size and density +may be changed if desired. + +The conversion routines for FITS, PDS, and CAMERA formats may involve +some loss of information, at least initially. The problem is that these +are different image formats, with different image headers, and it is +not always possible to preserve all fields of the header across a +transformation. The following additional requirements should be +met eventually, but need not be addressed in the first implementation: +.ls +.ls (8) +The image format conversion routines shall permit a user defined mapping +of fields in the input header to fields in the output header. In the case +of the FITS and IRAF imagefile image headers, it shall be possible for the +user to define additional fields beyond those in the standard header. +The name and datatype of the two fields in a mapping need not be unique. +.le +.ls (9) +When converting from an external image format into the IRAF imagefile +format, blank or indefinite pixels shall be replaced by values which +approximate the underlying distribution. These values may be artificially +generated if necessary (i.e., by interpolation). The coordinates of each +bad pixel shall be added to the bad pixel list for the image. +.le +.le + +Most IRAF applications code will work only on the standard IRAF data +structures. The user is expected to use the DATAIO routines to get data +into the system, and to convert data for export. Applications which +reduce data from instruments with unique data formats may need to provide +special conversion routines. DATAIO will provide conversion routines only +for data formats which provide data for more than one package. + +.sh +3.5 Package DIGIPHOT + + A package of routines for digital stellar photometry, in both crowded +and uncrowded fields. A range of routines shall be provided, ranging from +simple aperture photometry of sparse or moderately crowded fields, though +single star psf-fitting techniques, to simultaneous surface fits of +blended images. +.ls +.ls (1) +It shall be possible to perform aperture photometry on linearized images +via fractional pixel techniques, using circular apertures and annuli. +It is desirable to be able to perform aperture photometry using elliptical +apertures and annuli, but this is not a requirement. +.le +.ls (2) +It shall be possible to perform photometry on linearized images using +single star psf-fitting techniques. +.le +.ls (3) +It shall be possible to subtract the fitted psf from the data. +.le +.ls (4) +All photometry routines shall be usable either interactively or in a +batch mode, to process an arbitrarily long list of objects on a single image. +.le +.ls (5) +All photometry routines shall produce accurate estimates of the uncertainties +in object centers and magnitudes. +.le +.ls (6) +A routine shall be provided to automatically locate all objects in an image +which are sufficiently bright and well resolved (unblended) to be measured +by aperture or single star fitting techniques. +.le +.ls (7) +Routines shall be provided to determine the PSF of an image by either +empirical or analytical techniques. It shall be possible to accurately +determine the PSF even if the data is undersampled (up to the limit defined +by the sampling theorem). +.le +.ls (8) +Given a set of images, each of which has a different PSF, it shall be +possible to compute and apply a transformation to each image which +will result in all output images having the same PSF. +.le +.le + +.ks +.nf +Subpackages: + + apphot aperture photometry + new_richfld single star psf-fitting techniques + nstar deconvolution of blended images + psf psf generation and modification +.fi +.ke + +The requirements and specifications of the APPHOT package have already +been written and are available as a separate document. The "new richfld" +package will be similar in operation to APPHOT, but centering and scaling +will be done by psf-fitting techniques, providing more precise centers +and magnitudes, the ability to work in slightly more crowded fields +than is possible with APPHOT, and the ability to fit partial images. +The new richfld program will be a considerable improvement over the existing +IPPS version, providing a better background fitting algorithm, greater +efficiency, better error estimates, an improved user interface, and +probably the ability to perform accurate photometry on undersampled data. + +The NSTAR problem is still a research project, and it is unlikely that +we will have the manpower to address this problem for quite some time yet. + +.sh +3.6 Package DTOI + + A collection of routines for computing and applying the density to +intensity transformation for photographic data, and for linearizing other +types of data as well. The requirements are as follows: +.ls +.ls (1) +It shall be possible to determine the H-D curve for photographic data, +by any of the following techniques: +.ls o +By fitting a set of data points (the calibration "spots"), each of which +is described by a modal value and a standard deviation or weight, +and where the upper bound on the number of data points is arbitrary. +The data points shall be input in the form of a list file or list structured +parameter. +.le +.ls o +By analysis of a single image containing many star images. Since stellar +images must scale linearly if the data is linear, the H-D curve of an +image can be derived from an analysis of the data itself. +.le +.ls o +By use of an external program, or by direct entry of the transformation +by the user. +.le +.le +.ls (2) +A convenient routine shall be provided for generating the spot list file +from the calibration spots in digital form. +.le +.ls (3) +It shall be possible to determine the departure from linearity of +digital detectors by analysis of a set of images of the same field, +where successive images differ only in the total exposure time. +Each image is in effect a calibration "spot". +.le +.ls (4) +A function shall be provided to apply the transformation, linearizing an image +or images. +.le +.ls (5) +A function shall be provided to apply the reverse transformation, producing a +nonlinear image or images for test purposes. +.le +.le + +.sh +3.7 Package FILTERPHOT + + A package of routines to reduce data from single or multichannel +photometers. The function of the package is to read raw data from +a photometer, average multiple observations of an object to produce +a single record, then determine and apply extinction and transformation +corrections. +.ls +.ls (1) +Functions shall be provided to read data from all optical photometry +acquisition programs currently in use at KPNO (#4-16, PPIII, Photom). +.le +.ls (2) +The internal data format shall be independent of the raw data +format, making it straightforward to add additional data format +conversion routines to read data produced by non-KPNO instruments. +.le +.ls (3) +Once data has been read and converted into the internal form, +the primary functions of the package shall be to: +.ls o +Average multiple observations of a single object, producing a single +sky subtracted record. +.le +.ls o +Compute the instrumental magnitudes or colors. +.le +.ls o +Compute and the first and second order extinction coefficients. +.le +.ls o +Compute the transformation coefficients. +.le +.ls o +Apply the extinction corrections, transforming instrumental magnitudes +or colors into natural system magnitudes or colors. +.le +.ls o +Apply the transformation corrections, transforming natural system +magnitudes or colors into standard system magnitudes or colors. +.le +.le +.ls (4) +The package shall be able to reduce data for the BVRI, HBETA, UBV, +UBVR, UBVRI, UVBY, and UVBYHBETA photometric systems. +.le +.ls (5) +It shall be straightforward to extend the package to reduce data in +other photometric systems, provided they are reasonably similar to the +standard systems. +.le +.le + +.sh +3.8 Package FOCAS + + A more or less direct conversion of the existing FOCAS package to +IRAF, excluding those routines which duplicate functions already provided +by the IRAF system, such as data i/o, image reductions, image display load +and control, etc. The package shall provide the following functions: +.ls +.ls (1) +Automatic detection of faint objects, producing a catalog of objects +as output. +.le +.ls (2) +Measurement of various position, shape, and photometric parameters for +each object. +.le +.ls (3) +Automatic classification of objects (i.e., as stars or galaxies), +based on the information determined in steps (1) and (2). +.le +.ls (4) +Display and analysis of the various parameters in the catalogs. +.le +.le + +.sh +3.9 The HELP Utility + + The HELP utility shall be used to retrieve and display documentation +on-line, i.e., while at the terminal using the system. Documentation shall +be organized by package; "manual pages" shall be available for both CL and +library level packages. A manual page shall be available on-line for each +item appearing in a CL menu. +.ls +.ls (1) +The command "help" with no arguments shall cause a one line description of +each routine in the current package to be printed. +.le +.ls (2) +A command of the form "help task" shall cause the manual page for the +named task to be printed. The task must be defined in the dictionary at +the time HELP is executed to be recognized. +.le +.ls (3) +A command of the form "help package.task" shall retrieve the manual page +for the named task regardless of whether the associated package is loaded. +This form must be used to get help on library procedures. +.le +.ls (4) +It shall be possible, as an option, to print only the calling sequence for +the task, to print only detailed information for a particular parameter, +or to print the source for the task. +.le +.le +.le + +.sh +3.10 Package IMAGES + + General image processing. Included are routines for displaying and +plotting images and image sections, for image arithmetic, editing, and +filtering, and for performing geometric and other transformations. +.ls +.ls (1) +A routine shall be provided for mapping an image or image section into +the user specified frame of the default image display device. The mapping +or display routine shall have the following features: +.ls (a) +The function of the display routine shall be to map an image or image section +into the specified frame of the default image display device. +The following simple calling sequence shall suffice to display an image +or image section: + + display (image, frame) + +where "image" is the name of an image or image section, and "frame" is +the frame to be used, numbered 1, 2, 3, etc. For example, if "cube" +is a three dimensional image cube, the command + + display ("cube[*,-*,5]", 1) + +would map the entire fifth band of the cube into frame number 1, with the +y-axis flipped (the IMIO interface transparently processes image sections). +Default transformations would be used to map image coordinates into +display coordinates, and image pixel values into display pixel values. +.le +.ls (b) +The following options shall be available, under control of hidden +parameters with default values: +.ls o +Erase frame before displaying image. +.le +.ls o +Scale the x,y dimensions of the image to fit the physical frame of the +display device (autoscale in x,y). The aspect ratio should be maintained +at unity, unless an option is added to permit independent scaling of +the two axes. +.le +.ls o +Do not autoscale in x,y, i.e., map the image 1 to 1 in x,y (into center +of window). +.le +.ls o +Enter explicit x,y scaling factors (magnification). Map image into +center of frame using these fixed scaling ratios. +.le +.ls o +Enter Z1 and Z2, the range of intensities to be mapped into the +8 bits (or whatever) available on the physical device. +.le +.ls o +Reuse the spatial and greyscale transformations used the last time +the display routine was called. +.le +.ls o +Autoscale, using the minimum and maximum pixel values. +.le +.ls o +Autoscale, by computing a full or partial histogram for the image, +and then automatically computing the values of Z1 and Z2 which straddle +the main peak of the histogram (if there is a single peak). +It may be desirable to subsample the image for the sake of efficiency. +.le +.ls o +Both logarithmic and linear grayscale transformations shall be +available. +.le +.le +.ls (c) +Though the implementation of the display routine will necessarily be +device dependent at some level, the functions provided by the routine +shall be reasonably device independent. +.le +.ls (d) +The default image display device shall be specified in the +CL environment table (normally set when the CL starts up). +.le +.le + +.ls (2) +A routine shall be provided to control and adjust the image display +device. The following functions shall be provided: +.ls +.ls o +Select frame to be displayed. +.le +.ls o +Erase graphics frame. +.le +.ls o +Erase image frame. +.le +.ls o +Adjust windowing (frame lookup table). +.le +.ls o +Zoom and roam. +.le +.ls o +Blink frames. +.le +.le + +The display control routine will provide rudimentary control of the image +display device, but will not exercise any of the advanced features commonly +found on sophisticated modern display devices. This routine will eventually +be supplanted by a control program driven by a dedicated terminal with a +touch screen overlay. The latter interface will exercise the advanced +features of the display, but will necessarily be more device dependent +and therefore less transportable. + +In the long run we will wish to keep both interfaces, using the simple +interface for simple display devices, for workstations which do not have +a dedicated display control terminal, and to provide rudimentary control +at installations which cannot afford to implement the more sophisticated +interface. +.le + +.ls (3) +Routines shall be provided for plotting image data in a variety of ways, +on a variety of devices. +.ls (a) +The following types of plots shall be provided: +.ls o +Vector plots along a single dimension, optionally performing a boxcar +average over the other image dimensions. +.le +.ls o +Vector plots of the histogram of an image or image section. +.le +.ls o +Mark, vector, and text drawing on an existing plot, where the position, +size, orientation, etc., of a mark or text string are specified by the user. +.le +.ls o +Two dimensional contour plots of an image or image section. +.le +.ls o +Two dimensional hidden line plots of an image or image section. +.le +.ls o +Three dimensional hidden line plots of an image or image section. +.le +.ls o +Grayscale or simulated grayscale plots of a two dimensional image or +image section (depending on the output device). +.le +.le +.ls (b) +The following types of graphics output devices shall be supported: +.ls o +Graphics terminals (e.g., VT100, Tek 4012). +.le +.ls o +Raster plotters (e.g., Versatec). +.le +.ls o +Pen plotters (e.g., Calcomp, Imagen). +.le +.ls o +Grayscale devices (e.g., Dicomed, IIS). +.le +.ls o +Files (for spooling graphics). +.le +.le +.ls (c) +The following options shall be available to control the form of +a vector plot: +.ls o +Overplot without changing the scale. +.le +.ls o +Plot to a user specified scale. +.le +.ls o +Plot vector points as dots. +.le +.ls o +Plot vector points as marks, where the type and size of a mark +is specified by the user. +.le +.ls o +Connect the points of a plotted vector with line segments. +.le +.ls o +Connect the points of a plotted vector with dashed line segments, +where the dash pattern is specified by the user. +.le +.ls o +Set the plotting window, i.e., the position and size of the rectangle +in which the plot will be drawn on the output device. +.le +.ls o +Specify whether or not data may be plotted outside of the plotting window. +.le +.ls o +Enter labels for the axes. +.le +.ls o +Specify whether or not a box with ticks is to be drawn to define the +plotting window. +.le +.ls o +Specify whether the axes are to be labeled in pixel or user coordinates +(user coordinates might be right ascension and declination, wavelength +versus flux, or whatever). +.le +.ls o +Select linear or log scaling in either axis (with appropriately labeled +ticks). +.le +.ls o +Other options, such as line color, line brightness or width, depending +on the characteristics of the final graphics interface (GIO). +.le +.le +.ls (d) +Due to the complexity of the vector plotting options, the vector plot +task shall be command driven. A simple language shall be defined for +specifying vector plots and for drawing mark and text strings, and a +plot shall be generated by entering a sequence of commands which are +interpreted by the plotting task. + +All plotting options shall have default values. These default values +may be set by having the plot task read a user specified initialization +file (containing normal plot commands) upon startup. The simplest +plot command will have the form + + plot image_section + +i.e., the command + + plot "cube[5,*,9]" + +would plot column 5 of band 9 of the image "cube". If only a single +command is needed to generate a plot, it shall be possible to pass the +command as a string argument to the vector plot task when the task is +invoked from the CL. Otherwise, commands shall be read from the +standard input. +.le +.ls (e) +The two tasks PLINE and PCOLUMN shall be provided for making simple line and +column plots of images, without the extra overhead associated with the +vector plot task. Thus, a command such as + + pline image,10 + +would suffice to plot line 10 of the image "image". +.le +.ls (f) +It shall be possible to specify the default graphics device in the +CL environment table (normally set when the CL starts up). +.le +.ls (g) +It shall be possible to redirect the plot to a device other than the +default graphics device by means of command line redirection. +.le +.ls (h) +It shall be possible to select an output "device" which spools the low +level plotting instructions in a disk file. +.le +.le + +.ls (4) +Simple pointwise image operations, i.e. picture arithmetic, functions, +line and column flipping, subraster extraction, and so on, shall be +performed by the image calculator task. The image calculator approach +has two major advantages: (1) a great deal of function is provided +via an interface which is simple and easy to remember, and (2) the +image calculator is efficient, since it eliminates may intermediate +images which would otherwise have to be written, read, and deleted. +For all but the most trivial expressions the image calculator will be +cpu bound, an ideal candidate for optimization with a bit-mapped array +processor. +.ls (a) +The image calculator task shall be command driven. If only a single +command is to be executed, it shall be possible to pass the +command as a string argument to the image calculator task when the task is +invoked from the CL. Otherwise, commands shall be read from the +standard input. +.le +.ls (b) +The function of the image calculator task shall be to execute commands +of the form + + output_image = expression + +where "output_image" is either a new image which will be created by the +image calculator or a section of an existing image, and where "expression" +is an algebraic expression wherein the operands may be any of the following: +.ls +.ls o +Images or image sections of any dimension or datatype. +.le +.ls o +Numeric constants. +.le +.ls o +Calls to intrinsic functions. +.le +.le + +For example, the command + + cl> imcalc "subras = image[40:50,33:43]" + +would extract a subraster from the image "image" into the new image +"subras". The command + + cl> imcalc "image = image[*,-*]" + +would flip the columns of the two-dimensional input image. The command + + cl> imcalc "avg = (a + max(b,0) + c) / 3" + +where "a", "b", and "c" are the names of images, +would produce the new image "avg" which is the average of the images +"a", "c", and the image "b" with all negative pixels set to zero. +Finally, + +.nf + cl> imcalc "image[50,*] = (image[49,*] + image[51,*]) / 2" +.fi + +would replace column 50 of the named image by interpolation over the +neighboring columns. Many other examples could be given, +but this should suffice to demonstrate the range of operations the +image calculator will be able to perform. +Common operations, or repetitive operations on large data sets, +can be performed by writing CL scripts to generate sequences of commands +to drive the image calculator. +.le +.ls (c) +The operation of the image calculator when evaluating "mixed mode" +expressions involving images which differ in size, number of dimensions, +datatype, or which involve out of bounds references, has not yet been +fully defined. +.le +.ls (d) +The function of the image calculator shall be limited to pointwise +image operations (no interpolation, filtering, etc.). +.le +.ls (e) +The syntax of an expression in the image calculator shall be the same +as for the SPP language (and Fortran 77). +The image calculator shall recognize the following operators: + +.ks +.nf + + addition + - subtraction + * multiplication + / division + ** exponentiation + - unary negation + < <= > >= == != boolean comparison + ! boolean negation +.fi +.ke +.le + +The result of a boolean expression shall be of type short integer, +where zero corresponds to false and one to true. Boolean expressions +are useful for thresholding and mask generation. + +.ls (f) +The image calculator shall implement the following intrinsic functions: + +.ks +.nf + abs atan2 cos int min sin + acos ceil cosh log mod sinh + aimag char double log10 nint sqrt + asin complex exp long real tan + atan conjug floor max short tanh +.fi +.ke +.le +.ls (g) +The image calculator shall merge the bad pixel lists of the input images +to produce the bad pixel list of the output image. +.le +.ls (h) +A set of CL callable subroutine-like tasks shall also be provided for +performing simple arithmetic operations on images (two images in, one out), +without incurring the overhead associated with the image calculator. +.le +.ls (i) +A specialized routine shall be provided for averaging a set of registered +images. +.le +.le + +.ls (5) +General pointwise operations are required to modify the intensity scale +of an image in ways that are difficult or impossible to perform with the +image calculator. The following operators are required: +.ls +.ls o +General pointwise mapping operator. The mapping of input intensity to +output intensity shall be defined by a user supplied transformation curve. +The transformation curve shall consist of a list of data points giving +output intensity versus input intensity. +.le +.ls o +Histogram equalization operator. +.le +.ls o +Histogram matching operator. +.le +.le +.le + +.ls (6) +Operators are required to perform various geometric transformations. +These transformations move pixels about, but do not change the values +of the pixels. The geometric transformations shall be implemented as +separate tasks. +.ls (a) +Operators shall be provided for the following transformations: +.ls o +Transpose. Note that 90 degree clockwise and counterclockwise +rotations may be effected by combining the transpose operator +with an image section subscript as follows: + +.ks +.nf + transpose ("in[*,-*]", out) (cw rotation) + transpose ("in[-*,*]", out) (ccw rotation) +.fi +.ke +.le +.ls o +Fractional pixel shift along any dimension or dimensions. +.le +.ls o +Expand or contract by any factor along any dimension or dimensions. +.le +.ls o +Expansion by pixel replication. +.le +.ls o +Contraction by block averaging. +.le +.ls o +General linear transformation; a fraction pixel shift followed by a +rotation though an arbitrary angle about an arbitrary center. +.le +.ls o +General geometric distortion, or "rubber sheet", where the transformation +is defined by means of an externally generated lookup table. +The transformation shall be described by giving the coordinates of a set +of grid points in the input image, and the corresponding coordinates of +the same grid points in the output image. The distortion routine shall +compute the mapping for non-grid points by interpolation. +Note that this operator may be used to implement rotations or translations, +to register images, to remove or induce geometric distortions, +to convert from Cartesian to polar representation and vice versa, and so on. +.le +.ls o +Distortion table generation. Given the coordinates of a set of grid points in +the input image, and the corresponding coordinates of the same grid +points in the output image, an analytic surface is fitted, and a new set +of grid points are generated by sampling the analytic surface. +This step is necessary when too few grid points are available to span +the image, or when a smooth or constrained transformation is desired. +Note that this operator is very similar to that used for astrometry. +.le +.ls o +Image registration: given a list of images, compute the unique transformation +required to register the images with minimum loss of data. +The linear transformation routine may subsequently be used to perform the +actual registration. Operation shall be restricted to linear transformations +(translation and/or rotation). It shall be possible to restrict the +transformation to a simple translation if desired. +.le +.le +.ls (b) +All operations which involve interpolation shall offer the following +choice of interpolators: +.ls o +Nearest neighbor. +.le +.ls o +Linear interpolation. +.le +.ls o +Third order interior polynomial. +.le +.ls o +Fifth order interior polynomial. +.le +.ls o +Cubic spline. +.le +.ls o +Sinc function. +.le +.le +.ls (c) +All operations which involve out of bounds references (i.e., a rotation +or a geometric distortion) shall offer the following options for out of +bounds references: +.ls o +Add the pixel to the bad pixel list. +.le +.ls o +Return the value of the nearest boundary pixel. +.le +.ls o +Return a constant value. +.le +.ls o +Generate value by reflection about the boundary. +.le +.ls o +Generate value by projection about the boundary. +.le +.ls o +Generate value by wrapping around to the opposite side of the image. +.le +.ls o +Apodize (for fourier analysis). +.le +.le +.ls (d) +Operations which change the spatial scale of the data (i.e., expand, contract, +or distort) shall by default scale the value of the output pixels so as +to conserve the volume integral. +.le +.ls (e) +All linear transformation operators shall also transform the axes descriptor +in the image header, so that the user coordinate system associated with +the image remains accurate. +.le +.le + +.ls (7) +Operators are required to perform various filtering operations on images. +These transformations change the values of the pixels, but do not move +pixels about or change the spatial scale of the image. The filtering +operators shall be implemented as separate tasks. +.ls (a) +The following filter operators are required: +.ls o +Gradient (first derivative). +.le +.ls o +Laplacian (second derivative). +.le +.ls o +Circular median filter. +.le +.ls o +Rectangular median filter. May be used for median filtering of lines +and columns. +.le +.ls o +Circular modal filter. +.le +.ls o +Rectangular modal filter. +.le +.ls o +Convolution via a gaussian kernel of arbitrary size. +.le +.ls o +Convolution via a flat topped rectangular kernel of arbitrary size +(boxcar smoothing). +.le +.ls o +Convolution via a user specified kernel of arbitrary size. +.le +.ls o +Lucy smoothing using boxcar smoothing or a user supplied convolution +kernel. +.le +.ls o +General lowpass filter operator. +.le +.ls o +General highpass filter operator. +.le +.ls o +General bandpass filter operator. +.le +.ls o +General bandstop filter operator. +.le +.ls o +A routine which converts a transfer function in the frequency domain into the +corresponding convolution kernel in the spatial domain. +.le +.ls o +Forward fourier transform. +.le +.ls o +Inverse fourier transform. +.le +.ls o +Power spectrum. +.le +.le +.ls (b) +The choices for dealing with out of bounds pixel references shall be +the same as given in section 6(c). +.le +.le +.ls (8) +Special operators are required for background or bias fitting and removal. +The following fitting operators are required: +.ls (a) +Line polynomial fit to a user defined set of regions. This operator shall +perform the following operations for each line in the image: +.ls o +Compute the median, mode, or mean of each region in the line, +optionally with automatic pixel rejection and region growing. +.le +.ls o +Fit a polynomial to the resulting set of points, where the order of the +polynomial is greater than or equal to zero and is specified by the user. +.le +.ls o +Evaluate the fitted polynomial to produce the output line. +.le +.le +.ls (b) +Surface polynomial fit to a user defined set of regions in a two +dimensional image. As above, but regions are defined along the columns +as well. +.ls o +Compute the median, mode, or mean of each subraster, +optionally with automatic pixel rejection and region growing. +.le +.ls o +Fit a two dimensional polynomial to the resulting set of points, +where the order of the polynomial in each dimension is greater than +or equal to zero and is specified by the user. +.le +.ls o +Evaluate the fitted surface to produce the output image. +.le +.le +.ls (c) +One or two dimensional surface fit to the pixel data directly, +without computation of the mode, median, or whatever. +A number of regions may be defined as in the other routines, +or the entire raster may be fit. A two dimensional Legendre polynomial +is fitted, pixel rejection with region growing is performed if enabled, +and the process iterates until convergence (two or three passes through +the image are required). The fitted surface is evaluated to produce +the output image. +.le +.le + +.ls (9) +A range of operators are required for editing rasters. Raster editing +may be used to remove artifacts or blemishes, to salvage calibration frames +containing contaminating objects, to implement nonlinear filtering in the +fourier domain, and so on. The image calculator provides a rudimentary +but powerful raster editing capability, allowing lines, columns, subrasters, +and pixels to be copied or directly modified. The filtering operators may +also be used for a certain class of editing operations. Additional special +purpose operators are required for detecting and removing extended artifacts. +.ls (a) +The following operators are required: +.ls o +An operator is required to automatically detect and remove spikes. +Pixels which exceed the median of a circular or rectangular region by +more than a certain amount, and optionally all neighboring pixels out +to a given radius, shall be replaced by artificial values. +.le +.ls o +An operator is required to automatically detect and remove extended +objects. Region growing should be available as an option to insure +that all contaminated pixels are replaced. +.le +.ls o +An operator is required to automatically detect and remove transient defects, +given a series of exposures of the same field taken at different times. +.le +.ls o +An interactive editing routine is required, wherein the user interactively +marks the region to be edited with a cursor. +.le +.le +.ls (b) +It shall be possible to replace pixels by any of the following +techniques: +.ls o +By the median of the neighboring pixels, out to a user specified +radius, with optional additive noise. +.le +.ls o +By interpolation (linear or spline), with optional additive noise. +.le +.ls o +By adding the pixels to the bad pixel list for the image. +.le +.ls o +By substituting a user defined value, with optional additive noise. +.le +.le +.le + +.sh +3.11 Package IMRED + + The Image Reductions package (IMRED) will provide streamlined or +"canned" procedures for reducing the data from specific KPNO digital +imaging detectors. As far as possible, the IMRED procedures shall be +written as CL scripts calling compiled procedures in other packages. +Most of the functionality needed to reduce direct and spectroscopic +imaging data will be provided by the general purpose routines in the +IMAGES package. + +The advantages of writing IMRED procedures as CL scripts are the following: +(1) the high level IMAGES tasks, such as the image calculator, can be used +directly instead of calling lower level library procedures, +(2) staff and users can modify CL scripts more easily than compiled +procedures, and (3) we can provide specialized routines for common reduction +tasks, without sacrificing generality. The principal disadvantage is that +it is harder to access data dependent fields in the image header, +such as the filter number or IPS parameter for Video Camera images. + +Canned procedures shall be provided to reduce data from the following +KPNO instruments: +.ls +.ls (1) +CCD direct. Bias determination is via the polynomial fitting routines +in the IMAGES package; trim, bias subtraction and flat field division is +via the image calculator, cleaning is via the image editing routines, +and so on. A special routine will probably be required for defringing. +.le +.ls (2) +Echelle CCD. Reductions are much the same as for the CCD direct. +A different defringing algorithm is required. Cleaning and order +extraction is via the MULTISPEC procedures. +.le +.ls (3) +HGVS (High Gain Video Spectrometer). The basic operations are the +same as for the CCD's. An additional call to a polynomial fitting routine +is required to compute the slit profile. Distortion mapping is via the +LONGSLIT procedures. +.le +.ls (4) +Cryogenic Camera. Reductions are the same as for the HGVS, +except than an additional rotation or transposition step is required. +.le +.ls (5) +Video Camera. Reductions are very similar to those for the CCD direct, +except that there is no defringing problem. The reduction procedures should +be able to make use of the filter number and IPS parameter for each frame. +Distortion mapping need be done only once for a given image tube, +and hence is not part of the normal reduction sequence. +Distortion removal is via the geometric distortion routine in IMAGES. +.le +.ls (6) +Coude CCD. Standard CCD reductions, followed by compression to one +dimensional spectra for subsequent analysis in ONEDSPEC. +.le +.le + +Although canned procedures will not be provided (at least initially) for +reducing data from non-KPNO digital detectors, it should not be difficult +for users to modify the standard scripts to reduce data from other +detectors. + +.sh +3.12 Package LANGUAGE + + The command language itself. Not a normal package, in that the tasks +are built into the CL process, rather than into separate processes. +The contents of this package are always "loaded". The purpose of the +LANGUAGE package is to summarize the language facilities, and to prompt +the user with the names of the language "tasks", so that HELP may be +called to obtain additional information. + +.sh +3.13 Package LISTS + + Routines for operating upon lists. A list is a text file wherein +each line is a record consisting of one or more columns. Lists may be +produced by output redirection, editing, and many other means. Examples +of lists are lists of object coordinates, lists of images, lists of +regions, lists of transformation points, the graphics and image cursors, +and so on. Lists are used throughout the system. +.ls +.ls (1) +For maximum flexibility, all list operators shall be implemented as filters. +.le +.ls (2) +Operators shall be provided to perform the following functions: +.ls o +Copy selected columns from the input list to the output list. +.le +.ls o +Concatenate lines from a list of input files (merge records from several +lists). +.le +.ls o +Sort a list, alphabetically or numerically, in increasing or decreasing +order, by the contents of any column. +.le +.ls o +Merge several sorted lists, alphabetically or numerically, +in increasing or decreasing order, by the contents of any column. +.le +.ls o +Filter a list, passing or stopping only those lines which are within +the specified numeric or alphabetic range. +.le +.ls o +Filter a coordinate list, passing or stopping only those coordinates +which are within a certain radius of a certain origin. +.le +.ls o +Filter a list, passing or stopping only those lines which contain a +substring matching a user defined pattern. +.le +.ls o +Break the input list up into a stream of words. +.le +.ls o +Organize a stream of words into a neatly formatted table. +.le +.ls o +Copy the special list GCUR (the graphics cursor) to the output list. +.le +.ls o +Copy the special list IMCUR (the image cursor) to the output list. +.le +.ls o +Graph the contents of one or more lists, producing a plot on the +standard graphics device. If more than one list is input, the individual +curves (lists) shall be overplotted. +.le +.ls o +Perform arithmetic upon the columns of lists (e.g., OPSTRM). The output +columns are functions of the input columns. +.le +.ls o +Average a list of numbers, each of which may have an associated weight. +.le +.ls o +Average a list of coordinates, each of which may have an associated weight. +.le +.ls o +Convert a list to upper case. +.le +.ls o +Convert a list to lower case. +.le +.ls o +Perform a user specified mapping of the characters within a list. +.le +.ls o +Count the number of lines, words, and characters in a list or in a +list of files. +.le +.le +.ls (3) +When appropriate, the list operators should be set up to operate either +upon a list of input files, or upon the standard input. +.le +.le +.le + +.sh +3.14 Package ONEDSPEC + + The one dimensional spectral reduction and analysis package. +A general purpose package or packages, with a separate set of higher level +"canned" procedures for reducing data from specific KPNO instruments. +The basic requirements are as follows: +.ls +.ls (1) +Spectra shall be stored as one dimensional images with an extended header +containing special fields used by ONEDSPEC. This will permit use of the +standard image calculator and graphics utilities to manipulate and plot +spectra. +.le +.ls (2) +An assortment of routines are needed for data input. Routines are required +to convert data from the following formats into ONEDSPEC images: +.ls o +FITS. The standard FITS reader should be sufficient, provided it can +handle mapping of nonstandard keywords into the application specific +part of the image header. +.le +.ls o +IIDS, IRS. +.le +.ls o +REDUCER. +.le +.ls o +Text files. The standard DATAIO card image reader will suffice to convert +card image files into text files, but a special routine will be needed +to convert a text file spectrum (format yet to be defined) into an image. +.le +.le +.ls (3) +Only the standard FITS and text file (hence card image) formats will be +supported for output of spectra. +.le +.ls (4) +The image calculator shall be used for arithmetic and other operations upon +spectra, unless special handling of the extra fields in the image header +is required. +.le +.ls (5) +The standard IMAGES graphics utilities shall be used for plotting spectra, +except within interactive analysis procedures. The user coordinate systems +in the image header (x, y, and flux) must be initialized by ONEDSPEC if user +coordinates are desired on graphics output. The standard graphics utilities +(the image header) support only linear coordinate transformations. +.le +.ls (6) +A routine shall be provided for editing the special fields of the ONEDSPEC +image header. +.le +.ls (7) +Operators shall be provided for the following standard reduction +operations: +.ls o +Line identification. +.le +.ls o +Dispersion solution. +.le +.ls o +Dispersion correction. The data is interpolated and rewritten to +a user defined dispersion scale (linear, log lambda, etc., in units of +angstroms, wave number, inverse cm., etc.). +.le +.ls o +Flux calibration. +.le +.ls o +Coincidence correction. +.le +.ls o +Atmospheric extinction correction. +.le +.ls o +Merging of spectra (i.e., Echelle orders), to form a single +spectrum. +.le +.le +.ls (8) +Analysis functions shall include at least the following: +.ls o +Velocity measurement of individual lines. +.le +.ls o +Velocity measurement by cross-correlation. +.le +.ls o +Continuum estimator. +.le +.ls o +Intensity measurement. Equivalent width via aperture integration, +profile fitting, pseudo-filter. +.le +.ls o +Analytical and empirical generation of line profiles. Modeling of +line profiles. +.le +.ls o +Deconvolution of blended lines. +.le +.ls o +Fourier transforms, power spectrum, filtering, etc., mostly via the standard +routines in the IMAGES package. +.le +.le +.ls (9) +The package shall be able to handle spectra up to several million +pixels in length. +.le +.ls -5 (10) +Canned reduction procedures shall be provided for the following +KPNO instruments: +.ls o +IIDS, IRS +.le +.ls o +McMath FTS +.le +.ls o +4-Meter FTS +.le +.le + +The ONEDSPEC package will be one of the most heavily used packages in +the system, and should be sufficiently general to handle the reduction +and analysis of one dimensional spectra from a variety of instruments. +.le + +.sh +3.15 Package SOFTOOLS + + Software tools. A collection of tools used to develop and maintain +software systems. +.ls +.ls (1) +The following tools shall be provided: +.ls o +A compiler for the SPP language. +.le +.ls o +A portable, general purpose editor (probably the "tools" editor, +converted as required for IRAF). +.le +.ls o +Tools for making, updating, and accessing archives. +.le +.ls o +A simplified IRAF version of the MAKE utility (required to automatically +generate packages on non-UNIX systems). +.le +.ls o +The SYSGEN utility, used to maintain the IRAF system. +.le +.ls o +A utility which lists the names of all procedures and commons +defined in a set of SPP source files on the standard output. +.le +.ls o +A utility which compares a list of external identifiers with those used +in the IRAF libraries, and passes the names of only those identifiers which +redefine library routines (if any). +.le +.ls o +A utility which produces a cross reference list for the SPP source +files in a package. +.le +.le +.ls (2) +All tools shall be written in the SPP language as standard CL callable +IRAF tasks, and shall be as transportable as possible. +.le +.le + +.sh +3.16 Package NSURFBRT (to be renamed) + + Digital surface brightness analysis of extended objects, such as +galaxies. +.ls +.ls (1) +The main function of the package shall be to fit ellipses to the isophotes +of extended objects (galaxies), without artificially constraining the +center, position angle, or ellipticity of the fitted curves. +.le +.ls (2) +Output shall consist of a set of isophotes, defining the shape, orientation, +magnitude, and position of the object as a function of major and minor +axis radius. +.le +.ls (3) +The fitting routine shall optionally be able to detect contaminating +objects such as stars, and exclude them from the fit. +.le +.ls (4) +All analysis routines shall be usable either interactively or in batch +mode, processing an indefinitely large list of objects. +.le +.ls (5) +All analysis procedures shall exclude bad pixels from the fit. +.le +.ls (6) +Accurate estimates of the uncertainties of all calculated parameters +shall be computed. +.le +.ls (7) +Graphics utilities shall be provided for producing contour like plots +of the fitted isophotes, for plotting radial profiles, ellipticity +gradients, migration of the major axis, and so on. +.le +.ls (8) +Output from the main analysis routine shall be in the form of a +table printed on the standard output, permitting use of the standard +list processing utilities for general analysis, and of the card image +utilities for data export. +.le +.le + +.sh +3.17 Package SYSTEM + + The SYSTEM package shall provide general purpose routines for file +manipulation and status, directory listing, device allocation and +deallocation, time and date, and so on. +.ls +.ls (1) +The following functions shall be provided: +.ls o +Allocate a device (i.e., magtape). +.le +.ls o +Deallocate a previously allocated device. +.le +.ls o +Print status information for an allocatable device. +.le +.ls o +Clear the terminal screen. +.le +.ls o +Beep the terminal (useful for wakeup after a long command or command +sequence). +.le +.ls o +Concatenate a list of files. +.le +.ls o +Copy a file, copy a list of files to a directory. +.le +.ls o +Delete a file or files. +.le +.ls o +List the names of the files in the current directory, in one or more named +directories, or just give information about one or more named files. +A short form shall be provided, wherein only the name of the file is given. +A long form shall also be provided, giving the name, access and delete +permissions, file type (text or binary), file size, date of last modify, +and so on for each file in the list. +.le +.ls o +Summarize the amount of disk space currently available. +.le +.ls o +Echo command line arguments on the standard output (which can be redirected +to do useful things). +.le +.ls o +Print the first few lines of a file or files. +.le +.ls o +Print the last few lines of a file or files. +.le +.ls o +Page through a file or files, pausing at the end of each screen of text. +.le +.ls o +Print a file or files on the standard line printer device. +.le +.ls o +Protect a file or files from deletion, accidental or otherwise. +.le +.ls o +Remove protection from a file or files. +.le +.ls o +Rename a file, or move a list of files to a different directory. +.le +.ls o +Print information on who is using the system, what they are doing, +how much cpu time, etc., they have used, and so on. +.le +.ls o +Tee the standard output. +.le +.ls o +Print the time and date on the standard output. +.le +.ls o +Type the contents of a text file or files on the standard output. +.le +.ls o +Change the current directory. +.le +.le +.ls (2) +Some of these routines will necessarily be machine dependent. +.le +.ls (3) +Whenever possible, a routine will be set up to operate either on a list +of files specified by pattern matching, or to read from the standard +input if so directed on the command line. +.le +.ls (4) +All routines which operate on files shall accept either virtual file +names, which are machine independent, or operating system dependent +pathnames. +.le +.ls (5) +It shall be possible, at the discretion of the user, for a newly created +file to silently clobber an existing file of the same name; otherwise, +the system will refuse to clobber an existing file (the routine will +abort and an explicit delete will be required). +.le +.le + +.sh +3.18 Package TWODSPEC + + Two dimensional spectral reduction and analysis. A set of general purpose +packages, with separate canned procedures for reducing the data from standard +KPNO two dimensional spectrographic instruments. Two main subpackages +shall be provided: (1) MULTISPEC, which fits and extracts one dimensional +spectra from two dimensional images, and (2) LONGSLIT, which reduces +true two dimensional spectra (the names of these packages may change). +.ls +.ls (1) +The main function of the MULTISPEC package shall be to extract flattened +one dimensional spectra from two dimensional images. The following +functions shall be provided: +.ls o +Production of flat field frames by fitting quartz calibration images. +.le +.ls o +Flat field correction of multispectral data. +.le +.ls o +Cleaning of the spectra. +.le +.ls o +Extraction of the individual object spectra for further processing in +ONEDSPEC. +.le +.le +.ls (2) +It shall be possible to extract blended spectra via deconvolution +techniques. +.le +.ls (3) +It shall be possible to extract spectra superimposed on a slowly varying +background. +.le +.ls (4) +It shall be possible to accurately fit spectra even though the PSF +varies slowly over the image. +.le +.ls (5) +It shall be possible to reliably and accurately trace spectra +in the presence of geometric distortions (pincushion, s, shear, etc.). +.le +.ls (6) +It shall be possible to compute the residual of the data image minus +the fitted image, to evaluate the quality of the fit. +.le +.ls (7) +The program shall compute accurate estimates of the uncertainties in the +fitted parameters. +.le +.ls (8) +The routines in the MULTISPEC package shall be general purpose, i.e., +not tied to the data from any particular instrument. +.le +.ls (9) +Canned procedures which are instrument specific shall be provided for +the reduction of data from the following KPNO instruments: +.ls o +Multiaperture CRYOCAM. +.le +.ls o +Multiaperture HGVS. +.le +.ls o +Echelle. +.le +.le +.le + +The LONGSLIT package shall reduce true two dimensional spectrographic +data. The primary input is a flattened two dimensional spectrum +(wavelength versus arcseconds on the sky), and various spectral and flux +calibration images. The primary output is a distortion corrected, +sky subtracted one or two dimensional spectrum. The LONGSLIT package +shall also provide a two dimensional spectral analysis capability. + +The LONGSLIT package shall provide the following reduction functions: +.ls +.ls (1) +Geometric distortion mapping. The basic procedure is as follows: +.ls o +A stellar-like object frame or (fully resolved) multislit frame is traced +to determine the distortion in the cross dispersion direction. +.le +.ls o +A full slit arc frame is traced to determine the distortion along the +direction of the dispersion. +.le +.le +.ls (2) +Line identification. Given an arc frame to be used to perform the +dispersion solution, identify the individual arc lines, assign wavelengths, +and generate a line list to be used for the dispersion solution. +.le +.ls (3) +Dispersion solution. It shall be possible to determine the two dimensional +dispersion for the image (wavelength versus x,y) by fitting a full slit +arc frame, or by analysis of selected regions of an arc frame. +.le +.ls (4) +Remove geometric distortions and correct the dispersion. A transformation +table shall be prepared and used to drive the geometric distortion routine +provided by the IMAGES package. +.le +.ls (5) +It shall be possible to remove only the geometric distortions, or to both +remove geometric distortions and correct the dispersion scale. The user +shall be able to specify the following parameters for the output dispersion: +.ls o +Starting and ending wavelength. +.le +.ls o +Dimensions of the output spectrum in pixels. +.le +.ls o +Type of output dispersion curve desired (same dispersion, linear, +log lambda, etc.). +.le +.le +.ls (6) +Slit correction. The slit function is determined by fitting a polynomial +to an arc line or lines, and used to produce a calibration frame. +The slit function is then removed by an arithmetic operation (this can +all be done with standard IMAGES procedures). +.le +.ls (7) +Sky subtraction. A smooth sky image is prepared and subtracted from the +data (this can all be done with standard IMAGES procedures). +.le +.ls (8) +Flux calibration. A standard star spectrum is reduced to a one dimensional +spectrum, flux calibrated by ONEDSPEC, and the result is used to calibrate +one or more two dimensional spectra. This requires the following +operators: +.ls o +Convert a two dimensional spectrum into a one dimensional spectrum in +ONEDSPEC format. +.le +.ls o +Generate a dummy one dimensional ONEDSPEC spectrum which is subsequently +calibrated by ONEDSPEC. +.le +.ls o +Use the calibrated dummy spectrum to flux calibrate one or more two dimensional +spectra. +.le + +The two-to-one conversion routine may also be used if one dimensional output +spectra are desired. +.le +.ls (9) +Canned procedures are required to perform the above reductions for the +following KPNO instruments: +.ls o +Multislit (final output is normally one-dimensional dispersion corrected, +sky subtracted spectra). +.le +.ls o +Long slit spectrographs (output is usually true two dimensional, +dispersion and distortion corrected, sky subtracted spectra). +.le +.le +.le + +In addition to the LONGSLIT reduction procedures, the following two dimensional +spectral analysis procedures are required: +.ls +.ls (1) +A two dimensional continuum estimator. +.le +.ls (2) +A routine to trace emission or absorption lines, computing line center, +radial velocity, and equivalent width across the dispersion. +.le +.ls (3) +The line tracing procedure shall be able to trace faint lines out into +the sky, and shall be able to deconvolve blended lines. +.le +.ls (4) +A frequency domain cross-correlation routine is required to compute +radial velocity across the dispersion, using all spectral information +within a user specified range of wavelengths. +.le +.le + +.sh +3.19 Package UTILITIES + + Miscellaneous utilities. Includes routines for precession, computing +airmass, making finding charts, and so on. + +.sh +3.20 Special Packages + + The discussion has thus far been limited to those IRAF packages which +are expected to be of general interest to astronomers (and others) around +the country and the world, and which should therefore be included in the +general distribution. In addition, other packages will be developed in +the IRAF which will probably be used only at KPNO. Example are the HOLES +program and the Vacumn Telescope reductions package; there are probably +other similar packages which I cannot remember at the moment. I expect that +many special purpose packages will ultimately be developed by the staff +that do not make it into the general distribution. + +.sh +4. Correspondence of existing KPNO software to IRAF Packages + + In this section we go through Harvey and Jeannettes memo of July 1, 1983, +and describe how the functionality provided by each existing KPNO program or +system is provided by the IRAF package structure outlined above. + +.nf + Index Old Program IRAF Package + + 4M PF photography + + I.A.1 PDSLIB dataio + I.A.2 DTOI dtoi + I.B.1 ASTRO astrometry + I.B.2 IPPS IRAF + I.B.3 RICHFLD digiphot + I.B.4 AUTOPHOT digiphot + I.B.5 SURFBRT nsurfbrt + I.B.6 GRASP nsurfbrt + I.B.7 FOCAS focas + I.B.8 MPC digiphot + + 4M PF / 1-0.9 CCD + + II.A.1 DEBIAS,FPS,FGEN,MEDIAN imred + II.A.2 CCDPROC imred + II.B.* (analysis) (all image packages) + + Video Camera + + III.A.1 VIDCAM imred + III.A.2 PROCESS imred + III.A.4 DIODE,DISTORT imred + III.B (analysis) (all image packages) + + IIDS/IRS + + IV.A.1 IDS(IPPS) onedspec + IV.A.2 REDUCE(varian) onedspec + IV.B.1 IDS(analysis) onedspec + IV.B.2 TV onedspec + + RC / White Spectrograph, Long Slit + + V.A.1 PDSLIB dataio + V.A.2 RV twodspec.longslit + V.B.1 RV twodspec.longslit + V.B.2 FOURIER twodspec.longslit + + ICCD, Long Slit + + VI.A.1 HGVS imred + VI.B.1 RV twodspec.longslit + VI.B.2 FOURIER twodspec.longslit + + Cryo Cam, Long Slit + + (same as ICCD) + + Cryo Cam, Multi-Aperture Data + + VIII.A.1 HOLES twodspec + VIII.A.2 MAP twodspec.multispec + VIII.A.3 TV onedspec + VIII.B.1 TV onedspec + + Echelle, Photographic + + IX.A.1 PDSLIB, DTOI dataio, dtoi + IX.A.2 FASTSCAN twodspec.multispec + IX.A.3 ECHORD,TRACE twodspec.multispec + IX.B.1 ATLAS,WIDTH (no plans at present) + IX.B.2 MOOG (no plans at present) + IX.B.3 DECOMP onedspec (perhaps) + + Echelle, CCD + + X.A.1 ECH imred + X.B.1 TV onedspec + + FTS instruments + + XI.A.1 GRAMMY onedpsec + XI.A.2 FTSER onedpsec + XI.A.3 REDUCER onedspec + XI.A.4 ATLAS (no plans at present) + + IR and Visible Photometers + + XII.A.1 Hbeta, 4COLOR, etc. filterphot + + Coude, photographic + + XII.A.1 PDSLIB dataio + XII.A.2 SPEC1,2,5 onedspec + XII.A.3 DISP,DISP5 onedspec + XII.B.1 (analysis) onedspec + + Coude, CCD + XIV.A.1 SPECRED imred + XIV.A.2 fourier fitting imred + XIV.B (analysis) onedspec + + McMath Spectrograph + + XV.A.1 REDUCER onedspec + XV.A.2 DECOMP onedspec, maybe + XIV.B (analysis) onedspec +.fi +.endhelp diff --git a/doc/pkgreorg.ms b/doc/pkgreorg.ms new file mode 100644 index 00000000..6750b050 --- /dev/null +++ b/doc/pkgreorg.ms @@ -0,0 +1,107 @@ +.OM +.TO +distribution +.FR +Doug Tody +.SU +IRAF package reorganization +.PP +The system was extensively revised over the weekend to implement the new NOAO +package discussed earlier. For those not familiar with the issue, this was +necessary for the upcoming STScI/SDAS release. The NOAO optical astronomy +software is now nicely packaged in a single directory tree like SDAS and any +similar packages added in the future. There is a clean interface to the +IRAF system software, making it easier for outside sites to add new packages. +Having the NOAO science software in a single directory tree will make it +easier to install future updates of the science software without affecting +the system software. +.PP +Due to the extensive nature of the revisions required (325 files were edited!), +the reorganization was carried out in a temporary copy +of the system located at \fL/tmp2/u/\fR on lyra. It is possible that a bug +or two may have crept into the system in the process of editing that many +files, so some testing is advisable before we install the system at \fL/iraf\fR. +In particular, make sure the \fL.keys\fR cursor mode files are accessible, +the runtime linelist files, and any other runtime files. +Some existing packages were extensively modified (the old \fBdataio\fR, +\fButilities\fR, and \fBlocal\fR, as discussed below) and should therefore +get special attention. +.PP +Recall that it is necessary to add a \fL.cshrc\fR file to your UNIX login +directory when working with an experimental version of the system installed +at a nonstandard root directory. This is the only time you need such a file. +I suggest making a copy of the file \fL/u2/tody/.cshrc\fR (this is just +hlib$irafuser.csh with the new root declared). The \fBmkiraf\fR task should +be run before logging in under the new system, since there were some login.cl +changes in the new system. +.PP +The new directory structure concentrates all source and runtime files used +by the new NOAO package tree into a new directory tree \fLiraf$noao\fR. +The NOAO directories include a local library which is used for all runtime +files (cursor mode and linelists). The old \fLlib$pkg\fR and \fLlib$scr\fR +directories still exist but all the NOAO files therein were moved to the +new NOAO library. Note that the XTOOLS library still uses \fLlib$pkg\fR +since XTOOLS is an IRAF library (it is used by \fBimages\fR, etc.). +At some point in the future we may add a similar library for use only by +the NOAO package, but probably not until XTOOLS has been cleaned up. +.LP +The new CLPACKAGE (root) menu is as follows: +.DS +\fLdataio images lists noao sdas system +dbms language local plot softools utilities\fR +.DE +The NOAO menu is as follows: +.DS +\fLartdata astutil focas mtntape proto twodspec +astrometry digiphot imred onedspec surfphot\fR +.DE +.LP +Most of these packages were unaffected by the modifications, except for +changes to the manual pages, help directory files, package script tasks, +and an occasional source file to reflect the new pathname (noao$imred etc.). +All manual pages were updated to show the package pathname in the manual +page header. This has been our policy for several months but many old +manual pages were out of conformance; please try to remember to do this +in the future (it helps users determine what packages to load to run a task). +All the "revisions" entries in the \fL.men\fR package menu files were deleted +since this is feature will soon go away, and we will be reprinting the +documentation soon and I want it to be as accurate as possible. In any event, +a system wide facility should not be documented in the user interface of +every package. +.PP +Three new packages were added and three old packages were extensively +revised. The NOAO mountain tape readers were moved from the \fBdataio\fR +package into the new \fBmtntape\fR package. The astronomically oriented +utility tasks were moved from the \fButilities\fR package to the new +\fBastutil\fR package. The old \fBlocal\fR package was renamed \fBproto\fR, +and a new \fBlocal\fR package was added in the directory \fLiraf$local/tasks\fR. +.PP +The concept of the new \fBproto\fR package is appropriate for what the old +\fBlocal\fR package was used for, i.e., prototype, temporary, or contributed +tasks which are part of the NOAO package and which are exported with the +system, but which are expected to eventually disappear or be replaced by +planned system facilities. The new \fBlocal\fR package is a place to put +tasks of strictly local interest, or tasks which are not portable, e.g., +foreign tasks and the Peritec package. The \fBlocal\fR package should be +particularly useful for outside sites as it gives them a place to put locally +added tasks which will not be affected by future updates of the system. +Also, the framework (\fLmkpkg, local.cl\fR, etc.) is all set up, making it +easier for outside sites to add their own software without having to figure +out how to set up an IRAF package. +.PP +All code in the PKG and NOAO directories was newly compiled and linked over +the weekend. I would like to install the new system at /iraf by the middle +of the week (before I make the IMIO, etc. modifications), so lets try to +get the basic testing done Monday. Despite the number of files edited, +very little actual code needed to be modified by this revision, hence only +minor problems should be encountered. +.CT +IRAF group +E. Anderson +J. Barnes + +D. Phillips (CTIO) +S. Ridgway (info) +S. Grandi (info) +P. Seitzer (info) +G. Jacoby (info) diff --git a/doc/ports/README b/doc/ports/README new file mode 100644 index 00000000..7e077261 --- /dev/null +++ b/doc/ports/README @@ -0,0 +1,23 @@ +This directory contains notes on the various IRAF ports. Most of these +files do not contain an up-to-date record of the current ports, but rather +these are historical notes taken during each port. The name of the host +operating system is contained in each filename, while most files contain +the relevant dates of ports or upgrades inside them. Some of this material +may be of use to persons contemplating future ports. + +Conventions: + + aos AOSVS (Data General MV/10000) + ctio Cerro Tololo Interamerican Observatory + isi Integrated Systems; Jupiter workstation at IPAC + nso National Solar Observatory + st Space Telescope Science Institute + sun Sun Microsystems + sun2 SUN-2 hardware, SUN V2.0 + sun3 SUN-3 hardware, SUN V3.0 + v22 IRAF V2.2 (etc.) + +Where different files would otherwise have the same name, they are +distinguished by the date of the last modification to the system that +was part of the original "notes" file. For example, "sun3_062486.doc" +is the "notes" file as it existed on a Sun-3 on June 24, 1986. diff --git a/doc/ports/alliant_86.doc b/doc/ports/alliant_86.doc new file mode 100644 index 00000000..9b372493 --- /dev/null +++ b/doc/ports/alliant_86.doc @@ -0,0 +1,589 @@ +Notes on the port of IRAF V2.3+ to the Alliant FX vector workstation, +beginning 25 August 1986 (dct). This is a continuation of a port started +by Dennis Crabtree on 12 August, with some of the problems found then being +fixed before the bootstrap or sysgen in this port. +--------------------------------------------------------------------------- + +Read tape onto VAX 780 using IRAF `reblock' task. Worked great, except + that I allocated the drive in vms before running IRAF: this caused + the IRAF allocate to fail, causing a read error on the first + attempt to run reblock (confusing). (8/25) + +Copied archive to the Alliant via the ethernet which runs the Excelan + network software. The first attempt to unpack the archive on the + Alliant failed with a checksum error message from tar; this turned + out to be due to not specifying a binary transfer in TELNET before + copying the file (a newline was being inserted after every 512 + bytes). After retransmission to fix this, unpacked everything + successfully at /u2/iraf. (8/25) + +Notes - + There is a bug in the Excelan network software that causes it to + hang up the terminal if too many characters are transmitted, + forcing one to login on another terminal and STOP the process. + + The Alliant died on a kernel panic (mfree failure) during one + of these network crashes and had to be rebooted. Another time + it hung up in a hard loop when tyring to delete the large archive + file (bad disk block?) and had to be rebooted. + + DAO uses Plessey PT-100G graphics terminals. These have an awful + keyboard with keybounce and keylost problems. A screen redraw takes + 3 seconds. The screen color is orange - not as bright as amber, + green, or white. Other than that they seem fine - have not tried out + the graphics yet. (8/25) + + Tried the graphics finally, on VMS/IRAF. The graphics resolution is + good (480x1000?) and vector drawing is fast. Hardware cursor setting + is better than on the vt640 (shift and ctrl as used as accelerators, + and 45 degree motions are supported), but unfortunately there is no + software write cursor function, so the HJKL and other cursor write + features (as in in a zoom) do not work. The alpha and graphics + memories are separate and can be displayed together, as on the vt640. + + The main problems of this terminal are the keyboard, slow screen + redraw, and lack of a software write cursor function (but it is + better than a vt240!). (8/30) + +local/.login + Set up the .login for the new system. (8/25) + +Notes - + Tried using the vms COPY to copy the tar file to disk, to see if + that would work. COPY produced a variable length, 10240 byte max + record length, carriage control etc. file as output, i.e., a text + file. This explains why the initial attempt to read the tar tape + failed. Probably the best way to distribute tar archives to VMS + sites is by making a BACKUP tape of a disk tar file. This avoids + this type of confusion, and also gains access to the error recovery + provided by BACKUP. (8/26) + +/usr/include/iraf.h +/usr/bin/cl,mkiraf,etc. + Changed to point to /u2/. (8/26) + +unix/hlib/[dir]mach.f + Commented out pdp-11 entries and uncommented IEEE entries. In two of + the files, commented out the call to ILIBER; I don't think we want + that (should be fixed on Lyra). (8/26) + +unix/hlib/iraf.h +unix/hlib/mach.h + Changed the values of epsilonr, epsilond to the IEEE values. Set the + byte swap flags to NO. (8/26) + +unix/hlib/iraf.h + Set defines for and,or,xor to iand,ior,ieor. Not is not. (8/26) + +unix/hlib/mkiraf.csh + Changed iraf root directory to /u2/iraf. (8/26) + +unix/hlib/mkpkg.inc + Set siteid to `dao', turned off ncar, calcomp kernels. XC flags will + probably also have to be changed, but leave that for later. (8/26) + +unix/as/zsvjmp.s +unix/hlib/config.h +unix/hlib/libc/spp.h + Wrote the ZSVJMP/ZDOJMP for the Alliant (as$zsvjmp.s), and set the + jump buffer size parameters in config.h and spp.h. The current routine + saves the exception mask and all the floating point and vector + registers as well as the 68000 registers, which is more than is really + necessary. (8/26) + +unix/os/zgtime.c +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + From looking at Dennis's notes I see that time.h is in + rather than on the Alliant. In fact it is referenced both + ways in the VAX/UNIX kernel, so I changed all references to + , don't know what the official answer to this one is. + Removed the link (added by Dennis) in /usr/include. (8/26) + +unix/hlib/libc/iraf.h +unix/os/zxwhen.c + In iraf.h, added a #define ALLIANT for use in HSI code. In zxwhen, + replaced the array of vax exceptions by an #ifdef-ed array of + alliant specific hardware exceptions (hwx_). (8/26) + +unix/os/zxwhen.c + The Alliant C compiler produced a syntax error for the declaration + for the pointer to function `vector'. Presumably this was due to + vector being a reserved keyword to the Alliant C compiler; changed + the name to `vvector' and it compiled. (8/26) + +unix/boot/spp/xc.c + Replaced f77 by the Alliant task `fortran' (the Alliant Fortran + compiler) to compile Fortran files. Modified to use cc rather + than f77 to compile all other files. Modified to add the .f + files produced from .x sources to the Fortran file list, rather + than the general source file list input to the C compiler (formerly + these files were processed by f77, which can compile anything). + Parameterized the names of the fortran compiler, the C compiler, + and the linker. Deleted the "-u" flag, which is not supported on + the Alliant. Changed the Fortran library name from `-lF77' to + `-lfortran'. (8/26) + + In the long run, XC needs to be rewritten to be more portable, + like mkpkg. This is still the original unix compiler, which was + never intended to be ported. + +unix/boot/spp/rpp/ratlibf/Makefile +unix/boot/spp/rpp/rppfor/Makefile + Modified to call `fortran' rather than `f77'. (8/26) + +--------------------------- +(first attempt to bootstrap) + +unix/os/zfiomt.c + C compiler error. The declaration of the automatic array in + the skip record forward function, i.e., + + char buf[32768]; + + caused the fatal error `too many local variables' from the + C compiler. I reduced the size to [28800]. Recall that this + used to be a small buffer, but I had to make it larger than the + maximum tape block size to avoid i/o errors on the SUNs. Use + of malloc is undesirable since skip record forward might be + called many times in a loop. In any case, this is an indication + that the Alliant C compiler has limited symbol table storage and + may have problems with large programs or modules. (8/27) + +Note on Alliant Fortran compiler (task `fortran'). + The compiler cannot handle a "-cO" flag on the command line. + The "-O" must be given as a separate flag. (8/27) + +unix/boot/spp/rpp/ratlibf/dsfree.f + On line 20, the hollerith string contained a tab instead of a space, + causing the line length to exceed 20 characters. (8/27) + +unix/boot/bootlib/mkpkg.csh + The executable nature of this .csh is a nusiance; a different way + should be found to do this. (8/27) + +unix/hlib/mkpkg.inc + Changed the default compile flags to "-c -Ovg -AS -OM" for the Alliant. + (8/27) + +--------------------------- +(bootstrap completed) + +unix/hlib/alloc.e + Changed owner to root. (8/27) + +sys/gio/gki/gkigca.x + The min() instrinsic function was being called with operands of mixed + type, i.e., int and short. Restructured so that both operands were of + type int. (8/27) + +sys/gio/gki/gkigca.x + In this case, the Alliant compiler found a real bug in a module. + The warning message `subscript out of range' was being produced + because Mems[] was being referenced with a compile time constant + subscript, caused by omission of the pointer variable from the + expression. The bug was harmless, however, since the affected + argument (the device name string) was not being used by the called + procedure (close workstation). (8/27) + +sys/vops/lz/mkpkg + Added $checkout libvops.a, etc., to the file header. (8/27) + +sys/vops/ak/*.x +sys/vops/lz/*.x +unix/boot/generic/generic.c + The Alliant fortran compiler complains about use of (0,0) as a + complex constant. This string is generated by the generic + preprocessor when the sequence 0$f is encountered (actually, + any sequence NN$f is permitted). Modified the generic preprocessor + to turn NN$f into (NN.0,NN.0) for the complex datatype, and + deleted all the complex files (and associated integer files) in ak + and lz containing the string (0,0). These will be automatically + regenerated by the preprocessor in the sysgen provided the integer + family member is not found - the mkpkg only checks the date (and + existence) of the integer file. (8/27) + +pkg/system/help/t_lroff.x + Added an extern declaration for `getline', since it is passed by name + to the lroff function. (8/27) + +pkg/cl/task.h + In the #define next_task, deleted the (unsigned) coercion. This should + not be necessary as a pointer is already an unsigned quantity, and the + Alliant C compiler would fail with the message + + `expression causes compiler loop: try simplifying' + + when trying to compile the file (although the same macro was used in + lots of other places without problems - maybe it was causing parser + stack overflow in the problem cases, due to a complex context). (8/27) + +unix/hlib/mkpkg.inc +sys/vops/mkpkg + As an experiment, added a new environment variable XVFLAGS to + mkpkg.inc; this is used when compiling vectorized code to get + whatever compiler options are desirable for such code. Added + a $set to the vops mkpkg to redefine XFLAGS as XVFLAGS so that + the vops package will be compiled for vectorization. At present, + the value of XVFLAGS is the same as XFLAGS, i.e., vectorization + is permitted in both cases, except that the vectorization warning + messages are not turned off by the XVFLAGS. (8/27) + +--------------------------- +(started the first full system sysgen) + +sys/gio/gki/gkiopen.x +sys/gio/gki/gkititle.x + More `subscript out of bounds' errors, caused by omission of the + pointer `gki' from gki instruction field references. (8/27) + +sys/fio/osfnlock.x + The procedure osfn_initlock was declared as an integer function but + the return value was never set, causing the fortran compiler to + complain `FUNCTION return value is not defined in this program unit'. + It turns out that the procedure is called as a subroutine everywhere, + so evidently the function declaration was not intended. Changed it + to a subroutine. So far, the Alliant fortran compiler is finding + more bugs in IRAF than IRAF is finding bugs in the compiler, a pleasant + turn of affairs. (8/27) + +sys/vops/amap.gx + Broke the min/max expression in the do loop up into two statements + to defeat a compiler warning message for case short; an integer + expression was being used as one of the min/max operands for case + short. (8/27) + +unix/boot/generic/tok.l + The external string variable xtype_string[] was declared as (char *) + rather than (char []) in tok.l, causing a runtime bus error on the + Alliant. This construct works on the VAX because the linker is smart + enough to figure out what is going on, but clearly the construct is + not portable and should be avoided. Probably it is always safe to + use (char *) in argument lists since a pointer value is always pushed + on the stack, but in extern declarations the array notatio must be + used. (8/27) + +sys/osb/mkpkg +sys/osb/achtb.gc +sys/osb/achtu.gc +sys/osb/achtzb.gc +sys/osb/achtzu.gc + A warning message from the C compiler led to the disovery of some + old complex ACHT procedures in OSB. There was a bug in these files + which had been fixed in the source .gc files, but type X had been + removed from the call to generic in the mkpkg, hence the complex + files were never regenerated. It appears that type complex was dropped + at some point from the mkpkg, but the complex files were never + deleted. The other file are more permissive with type coercion, + hence the problem was never discovered. I restored type complex to + the mkpkg and added a complex case (requires special processing) to + each of the .gc files. (8/27) + +sys/gio/ncarutil/sysint/ishift.x + This file contains source for two procedures IAND and IOR. This would + not compile since the Fortran compiler already has intrinsic functions + with the same names; commented the offending procedures out as a + workaround. (8/27) + +sys/ki/irafks.x + The procedure `kserver' was declared as a function but the return + value was never set, and the function was being called as a + subroutine. Changed to a subroutine. (8/27) + +math/iminterp/arider.x + This file contained the three procedures ii_pcpoly3, ii_pcpoly5, + and ii_pcspline3. These were all declared as functions had no + return values and were always called as subroutines, hence I changed + them to subroutines. Also, the same external names were used with + a different argument list in the file `mrider.x', leading to a very + serious library conflict - surprised it has not caused noticeable + runtime problems to date. As a temporary solution, I changed the + names to ia_* in the file arider.x to avoid this library conflict. + (8/27) + +pkg/xtools/icfit/icgdelete.gx +pkg/xtools/icfit/icgundelete.gx +pkg/onedspec/identify/icfit/icgdelete.gx +pkg/onedspec/identify/icfit/icgundelete.gx + Each file contained two procedures which were declared as functions + but which did not return function values and which were called as + subroutines, hence I changed them to subroutines. (8/27) + +pkg/images/imdebug/immake.x + Subroutine immake2 declared as a function. (8/27) + +pkg/images/tv/display/iiswnd.x + Contained constructs such as `max (0, lut[i])', where `lut' is a short + integer array. This caused a min/max type mismatch error. Also, a + statement had a nonfunctional C like ; at the end. (8/27) + +pkg/images/tv/cv/iism70/iishisto.x + Same problem, short integer variable `offset'. (8/27) + +pkg/images/geometry/blkav.gx + Main procedure blkav$t declared as a function but used as a subroutine + everywhere. (8/27) + +pkg/plot/gkiextract.x + In gke_make_index, `nchars_max = min...', contained an integer constant + and a short integer array element, causing a min/max argument type + mismatch. (8/27) + +noao/onedspec/t_dispcor.x + Procedure dcorrect declared as a function is really a subroutine. + Also, it has a ridiculously large number of arguments. (8/27) + +--------------------------- +(All compile time bugs found in this pass fixed. Stripped all non-HSI +(binaries and started another full sysgen to run overnight). + +kernel problems + When I came in in the morning the sysgen had completed successfully, + but the machine seemed rather sluggish. Trying to work, I immediately + found that processes which used to run would hang up on a pseudo-run + state, completely uninterruptable, sometimes unstoppable, unkillable, + and so on. Clearly a problem with the unix kernel, so I rebooted and + the symptoms went away. Most likely this was a bug in the Alliant + unix kernel, which is common with new unix ports. (8/28) + +math/interp/arider.x [OBSOLETE] + Missed one: the three procedures iidr_poly[35] and iidr_spline3 were + declared as functions but were really subroutines. (8/28) + +pkg/images/tv/cv/iism70/iisrange.x + Lots of problems mixing int and short in calls to AND, OR. (8/28) + +pkg/images/tv/cv/iism70/zsnap.x + This module caused the fortran compiler to core dump with an internal + error; it was trying to resolve mixed int/short operands in expressions + and couldn't handle this code, evidently. (I feel much the same way + trying to read it.) + + Deleted `int min(), max()' intrinsic function declarations. Added an + itemp temporary to fix a couple min/max statements which mixed int + and short operands. (8/28) + +pkg/images/tv/cv/iism70/iishisto.x + Lots and lots of compile time problems with short variables - took + several iterations to find them all. (8/28) + +pkg/images/imarith/imsum.x + In module MXMNSS, the Fortran compiler coredumps when run with + global optimization (-Og). Returns `error code 138': examination + of the corefile for `fortran1' (the first pass I presume) with adb + gives the reason as `bus-error page violation'. Saved the offending + segment of code in local$bugs for a bug report to Alliant, and compiled + the routine without optimization. (8/28) + +noao/mtlocal/cyber/cy_rbits.x + This file also causes the Fortran compiler to coredump and return + error code 138 - bus error page violation. Generated the minimum + Fortran module that would demonstrate the bug and installed it in + local$bugs. Hand compiled routine without optimization. (8/28) + +noao/mtlocal/cyber/cyber.h, *.x + The data structure for this package included a field named POINTER. + This is a reserved keyword, and is converted by the preprocessor + into `int', eventually causing a compile time error on the Alliant + (and a memory overwrite problem on the VAX). Aside from being a + reserved keyword, POINTER is not a very illuminating name for a + field of a structure: pointer to what? After a little investigation, + changed the name to COEFF, since it appears that the field contains + a pointer to some sort of coefficient array. (8/28) + +--------------------------- +All compile time problems have now been dealt with and all executables linked +and installed in bin. I tried running a couple of the executables, and +incredibly, they ran without apparent error on the first attempt! Of course, +that is too good to be true, the next step is runtime testing of the system. + +dev/graphcap +dev/termcap + Installed the local DAO additions to termcap and graphcap. Rather + than have a modified version of the vt640 entry for DAO, changed the + name of the new logical device to vt640d. (8/28) + +unix/hlib/mkiraf.csh + Set the default image storage directory to /u2 since it will be + empty when iraf is moved back to /iraf, and since there does not + seem to be any dedicated scratch area. Added a comment for the + pt100g graphics terminal. (8/28) + +unix/hlib/zzsetenv.def + Changed the names of the stdgraph and terminal devices to `pt100g'. + Did not set stdplot, stdimage, printer, since no such devices are + currently available from the Alliant. (8/28) + +local/login.cl + Ran `mkiraf' to set up a new CL login for IRAF. Tried starting the + CL and it hung up in pseudo-run mode as above. The problem is + definitely in the unix kernel, but it appears likely that the bug + occurs when an IRAF VOS (not HSI) process runs - possibly it is + related to the call to the internal Alliant `setcontext' routine + (which traps to the kernel), called from ZSVJMP. The system slows + way down when this occurs, so evidently it is hung in some sort of + tight kernel loop. (8/28) + +(rebooted) + +process spawn problem + This is turning out to be a hard problem to locate. ZSVJMP turned + out not to be the problem, and in fact it works fine. The difference + between the IRAF processes and the UNIX processes is that the IRAF + processes use the fancy vector compiler. The Alliant process header + contains a flag bit word describing the attributes of the process to + be run; the standard UNIX processes do not use any of the fancy + Alliant vector stuff, and in fact do not even use 68020 instructions. + The IRAF processes use 68020 instructions, vector instructions, + and something called multiple stacks. Once the kernel gets corrupted, + processes with these attributes enter the pseudo-run state when we try + to exec them. (8/29) + +(rebooted countless times) + +unix/os/zfiopr.c + After a lengthy battle, finally determined that due to some bug in + the Alliant kernel, ONLY A NORMAL PROCESS CAN EXEC A VECTOR PROCESS. + A vector process can exec a normal process with no problem, and a + normal process can exec a normal process, but if a vector process + execs a vector process the exec hangs in a tight kernel loop. + The workaround is for the vector process to exec a normal process + and have it turn around and exec the desired vector process. + I tried this, and it works, although there appear to be other less + serious bugs with IPC to be faced tomorrow. (8/29) + + [8/30 - IPC bug was not a real bug, just caused by "-c" switch not + [being passed to connected subprocess by `execute'.] + +unix/os/exec.c + +unix/hlib/exec.e + +unix/os/zfiopr.c +unix/os/mkpkg.csh +unix/os/mkpkg + Resolved the process connect problem as follows: [1] added a new + file exec.c (source for hlib$exec.e), which compiles into a nonvector + process to be called by the CL to spawn vector subprocesses; + [2] replaced the execl call in zfiopr.c/ZOPCPR by a call to execve + to spawn hlib$exec.e, which in turn spawns the IRAF suprocess. + Added entries to the mkpkg files to make the new modules. (8/30) + +-------------------------------------- +ALLIANT/IRAF is now up and ready for runtime testing, Saturday morning, +30 August. Spent two days on the port and one and a half days figuring +out the process connect problem. + +unix/hlib/iraf.h +unix/hlib/mach.h + In checking out some operations upon indefinites, discovered that + the values of INDEFR and INDEFD in had accidentally been + set to the values of EPSILON[RD]. This was causing INDEF comparison + failures for files that included since INDEF is also defined + there. INDEF should not be defined in if it is already + defined in , so I deleted the entries in and restored + the old values to . (8/30) + +unix/as/zsvjmp.s + Discovered a minor problem with the new ZDOJMP routine. The address + of the error code was being returned, rather than the value, causing + error messages to come out as ERROR (*****, ".."). (8/30) + +(full sysgen and relink due to and zsvjmp edits) + +Fatal Alliant hardware problem + Right away when trying to test out the IRAF science software I + ran into serious problems with floating point operations. A little + investigation showed that the Alliant floating point hardware is + faulty. Simple test programs were written in both Fortran and C to + print out the numbers 1.0, 2.0, 3.0: both failed. Testing of the + floating point instructions with ADB revealed that add and subtract + are ok, but 1.0 * 2.0 is 2.1375, and 1.0 / 2.0 is 0.53125. A simple + board swap should fix the problem (in fact it is probably a single + chip), but unfortunately this will prevent further testing of the + science software during this visit; virtually all programs that use + floating point produce invalid results, including all graphics + programs. Testing of the system software can continue, as can + execution of most benchmark programs. (8/30) + + IMPORTANT NOTE -- Once this problem is fixed it will be necessary to + recompile the entire system (and any other non-IRAF software as well), + since any floating point decode operations performed by the compilers + will likely have failed, causing invalid floating point numbers to be + compiled into programs. Hence these programs will fail even after the + hardware is fixed. + +unix/os/zopdpr.c + Had to make the same change here as in zfiopr.c, i.e., add a call to + the intermediate `exec.e' process to exec the bkg cl. Note that this + is not necessary for zoscmd, since zoscmd execs one of the unix + shells, both of which are nonvector processes. (8/31) + +Note on FTP +vms/boot/rtar + A binary file transfer via FTP to VMS resulted in creation of a file + with an undefined record type. Trying to unpack this file with RTAR + would immediately crash the VAX due to an exexpected exception during + a system call in the ACP (RMS). This should not happen, of course, + but the real question is why FTP created a file with an undefined + record type. Sure would be nice to have the IRAF networking software + up... (9/1) + +unix/os/zgtime.c +unix/hlib/libc/kernel.h (HZ) +sys/etc/sysptime.x + Rewrote the timer utility routines to use only integer arithmetic, + so that I could run some benchmarks of the vector hardware. (9/1) + +(relink) + +-------------------- +Timing tests + The Alliant documentation claims that use of the vector hardware will + increase performance by about a factor of 4. This is borne out by my + tests. The factor of 4 is determined by the ratio of the startup + time for a vector segment versus the time required to execute a + vector segment, where the segment length (number of elements in a + vector register) is 32 for the Alliant. + + aaddr, 512x512 + vectorized: 0.184 cpu + nonvector: 0.617 cpu + +(Moved new system to /iraf; deleted old system, it should be archived +(somewhere and probably won't be looked at again anyhow. I saved a copy +(of the original Alliant notes file as notes.den. Modified the links in +(/usr/include and /usr/bin to point to /iraf. Modified the pathnames in +(hlib and hlib/libc). (9/1) + +cleanup + Ran (most of) the standard benchmarks. Deleted the /u2 version of + iraf. (9/2) + +------------------------------ +Back at NOAO. Problems reading tar file on VMS backup tape brought back from +DAO. This is probably due to problems with the DAO software so I shall +document it here (copied from noao/lyra notes file). + +doc/ports/alliant_86.doc + Installed the notes file from the Alliant port. There was some + problem with the backup/tar file I made on the Alliant, hence it was + not easy to get the notes file off the tape. I had to use the new + SPLIT task to split the 24 Mb archive into 49 512000 byte segments, + and eventually determined that the notes file was at line 11115 of + segment 39! The problems with the tape are almost certainly not with + the tape itself, since I did a backup/compare at DAO, and backup did + not report any problems when the tape was read. + + I think the most likely culprit is the FTP software, which had to be + used to move the archive to the VMS VAX, since the DAO Alliant did not + have a tape drive. FTP (binary mode) insisted on making a file with + an undefined VMS record type; this would cause RTAR to crash the VAX + if I tried to look at the file on the VMS VAX at DAO. The 24 Mb archive + file has one enormous section which is all zeroed, and then in the + remainder of the archive all ascii zeroes appear to have been deleted + from the archive, causing the 512 byte TAR file headers to be much + shorter. I tried the exact same operation (with a smaller test file) + using our Eunice FTP and everything worked fine. The DAO TELNET + also gave problems; it would hang up if fed too much data too fast, + and would occasionally crash with a stack trace. Based on these + experiences, I would certainly have to recommend the Wollongong + networking software over the other vendor. (9/6) diff --git a/doc/ports/aos_ctio.doc b/doc/ports/aos_ctio.doc new file mode 100644 index 00000000..0fcc099c --- /dev/null +++ b/doc/ports/aos_ctio.doc @@ -0,0 +1,233 @@ +System notes file for CTIO AOS/VS IRAF installation. +9-17 April 1987 + +System installed by Gary Lee Webb on 9 April. +CL came up and ran with minor problems. + +Did not start keeping this notes file until 16 April (D.Tody). +May have missed some important mods. + +Extant Bugs +------------ + +1. OS escapes. + + Interrupting an OS escape often causes the escape mechanism to + get in a state where subsequent escapes will return immediately, + even though the command has been sent to the cli, sh, or whatever. + This leads to the CL and the host task reading from the terminal + at the same time, seizing alternate lines of input. + +2. Magtape i/o problem + + CTIO has a standard DG tape drive and two Cipher tape drives. + The standard tape drive will accept transfers up to 32768 bytes + (or maybe 32767 bytes), which is what the zfiomt.c driver code + is written for. The Cipher drives, however, have a maximum transfer + size of 8192 bytes, hence the max transfer size is device dependent + rather than just system dependent. As a kludge fix for this I + added some site dependent logic to zfiomt.c, but a real fix will + probably require addition of the max transfer size to the dev$devices + file, and changes to the VOS code to deal with this. + +3. Path and script problems + + There were a number of problems with missing directories and + confusion between executables and macro script tasks, leading to + failure of mkpkg, xc, etc. I will try to get Gary to document these + better. + One of the problems (glw) was the use of directories C_DIR and + F77_DIR to find the executable C and FORTRAN compilers. Unfortunately, + there are no standard directories for these (other than they should be + in :UTIL), perhaps the standard C and F77 macros should be used rather + than having IRAF write its own? + +4. File dates + + After the system installation, a mkpkg on any package results in + compilation of all of the files therein. Evidently the file modify + dates are not being restored properly when a backed up system is + restored from tape. + +5. Installation (glw) + + The current link initialization macro will delete /TMP and link it + to /DEV. I see no reason to combine these and did not do so. + For a user to be able to generate any processes under IRAF, he also + had to be a valid MV/UX user (i.e., have an entry in /ETC/PASSWD). If + this is not a bug, it should be documented in the installation guide! + There are !SOLPLs all over the place: a list of files to be changed + would be nice. + +6. Worries... (glw) + + I note that the editor description files end with a .ed, just like + the SED temporary files, making them likely to be deleted accidentally. + + +System Revisions +-------------------- + +aosvs/os/zfiomt.c + Did a kludge fix to set the max transfer size down to 8192 bytes + for devices other than mtb0. (4/15 dct) + +dev/vi.ed + Changed the OS escape for VI from "vi" to "!vi" to cause the command + to be executed by CSH rather than CLI. Also added an entry for the + vi500 to /etc/termcap, but I could never get VI to find the entry + for the device. Tried setting TERMCAP in .cshrc to point to another + file, or directly to the vi500 termcap entry, but none of this made + any difference. (4/16 dct) + +aosvs/os/prwait.c + The include file was not being found; it turns out to + be in /usr/include on this system. I had to reference the file as + "/usr/include/wait.h" rather than the expected to get the + module to compile. It appears that the real include files are + coming from some other place (maybe a text library?) and that the + wait.h file is missing. (4/16 dct) + +aosvs/boot/rtar/mkpkg + Added a "-B" flag to the $link call. Without this the link fails + with a multiple reference to main.o, and unresolved externals for + all the bootlib routines. It looked like this was missing from + most of the other boot packages too. (4/16 dct) + +dev/slate.ed (glw) + Added this file (guessing a lot!) to provide Dan's favorite editor. + It must work -- that's how I'm adding this comment! + Where is the documentation for the *.ed format? + +dev/sed.ed (glw 16 IV 87) + Modified the command line to be SED/NOED to avoid leaving *.ed files + all over the place. + +dev/termcap (glw 16 IV 87) + Added lpt1, lpt4, and lpt5 printers, a/k/a adservs, diablo, laser. + +pkg/images/imdebug/mktest.x + Would integer overflow when creating a large image. This is harmless + on the other systems, but it has to be guarded against on the MV as + it causes the task to abort. (4/17) + +pkg/images/iminfo/t_imstat.x + Installed an optimized version of the IMSTAT task. (4/18) + +aosvs/boot/mkpkg/*.[ch] + AOS/VS evidently cannot restore the modify dates of files when reading + a tape onto disk. This causes mkpkg to try to recompile everything + when run for the first time on a newly installed system. Modified the + mkpkg program to add a new flag "-u". This flag, if present, causes + the dates of library modules to be forced to be no less than the date + of a magic file (currently hlib$iraf.h). It is assumed that the date + of the magic file is about the same as the date at which the system + was installed. To be precise, the file should be touched after the + tape is read in (already done for the CTIO system), and the first + time mkpkg is run on a package the -u flag should be used to forcibly + update the library module dates. (4/18) + +--------------------------------------------------------------------- +From SKIP@SOLPL.AS.ARIZONA.EDU Thu May 28 12:14:58 1987 +Received: from noao.arpa by noao-lyra.arpa.noao (5.51/SAG.7) + id AA08983; Thu, 28 May 87 12:14:53 MST +Received: from solpl.as.arizona.edu by noao.arpa (5.51/SAG.7) + id AA03426; Thu, 28 May 87 12:14:46 MST +Received: by SOLPL.AS.ARIZONA.EDU (1.00/1.0) + id AA00065; Thu, 28 May 87 12:14:20 mst +Date: Thu, 28 May 87 12:14:20 mst +From: Skip Schaller +Message-Id: <8705281714.AA00065@SOLPL.AS.ARIZONA.EDU> +To: chile@noao, tody@noao +To: Dan@SOLPL.AS.ARIZONA.EDU, Smith@SOLPL.AS.ARIZONA.EDU, + Gary@SOLPL.AS.ARIZONA.EDU, Webb@SOLPL.AS.ARIZONA.EDU +Fm: Skip Schaller + + I will be leaving Tucson on June 18 for Chile. I will call you +on Monday morning June 22. I expect to be able to pitch in immediately +if you so desire. I will be in Chile until August 16. Let me know as +soon as you know what it is exactly that you want me to do for you. If +I can prepare anything here ahead of time, so much the better. + + Please send me any AOSVS/IRAF bug reports as soon as possible. It +will be much easier for me to fix them here. + + + The following are my responses to the CTIO AOSVS/IRAF installation +notes that I got from Doug Tody: + +1) Keyboard interrupt during OS escape. + I duplicated this problem at solpl. I will try to fix during +this next update. It may be an AOSVS problem and not fixable. + +2) Magtape maximum record size for certain drives. + Doug changed the IRAF VOS just the other to deal with this problem. + +3) Pathname problems. + As far as I can tell (by looking at other AOSVS systems), +F77_DIR and C_DIR are the standard DG directories for those languages. +In any case, the installation manual tells you which scripts to check +and modify to agree with your system. (I had to do this for the +Tenerife installation. It was trivial.) Unfortunately, the standard +scripts cannot be used due to their lack of functionality and interface +to mkpkg. + +4) File dates. + Hopefully by the next release, Doug's changes to mkpkg to update +file dates for library members without recompiling, will be incorporated. +Many DG sites have complained about AOSVS not restoring the original +file modification times. + +5) Link installation problems. + The link installation script does NOT delete /TMP and link it to /DEV. +Read it again. With MV/UX installed, that part of the script does nothing. + +6) Problems with /etc/passwd. + I could not reproduce this problem at solpl. I did reproduce it +during the Tenerife installation. I found out that the minimum needed +was to have this file present with one entry for user "iraf". + Sometime ago I tried to eliminate IRAF dependence on this file +by avoiding the use of those C subroutines given in the DG documentation +that access this file. Apparently, there is at least one more, execl (). +In any event, the DG C subroutines should do something more graceful when it +can't access the information it wants. I will take this matter up with +DG. In the meantime, all current AOSVS/IRAF sites now have MV/UX so they +should really keep this file up to date for all users. + +7) Node name changes. + There are NOT solpl!'s all over the place. They are confined to +the files which may contain site dependence. In any event, since CTIO +does not have any networking software, the IRAF networking is automatically +turned off and the solpl!'s are harmless and need not be changed. If there +are any files that particularly bother you, give me their names and I'll +see what I can do. + +8) Editor descriptor files (.ed). + The editor descriptor 'edit' was already provided so that SED +does not generate files with conflicting extensions. + +9) Vi. + We execute vi directly from the CLI. We use a slightly different +entry for the vi500 in /etc/termcap than the one used by IRAF, so as to +get around some DG bugs. The user needs a .exrc file in his home directory +to set the terminal type. + +10) Wait.c + The include file wait.c is missing from the DG C release and +should be copied from :usr:include:wait.h to :util:c_dir:sys. + +11) Mkpkg -B flag. + The -B flag was present in the mkpkg file in the immediately superior +directory, but I will put it in all the subdirectory mkpkg files as it +should be. + +12) No documentation for dev$*.ed files. + I agree with you, Gary. However it turns out that most of it +is not necessary to change. + +13) image$imdebug/mktest.x + I reported the integer overflow problems to Doug some time ago +when I ran the benchmarks. + + +NNN diff --git a/doc/ports/aos_port.doc b/doc/ports/aos_port.doc new file mode 100644 index 00000000..fa88fcd2 --- /dev/null +++ b/doc/ports/aos_port.doc @@ -0,0 +1,223 @@ +/iraf/lib + clpackage.cl Changed terminal name + config.h AOSVS changes (HOST_CASE, etc.) + iraf.h AOSVS changes (added defines for and, or, etc.) + mach.h MV/10000 changes + make.h MV/UX changes +/iraf/lib/libc + iraf.h AOSVS changes + kernel.h AOSVS changes + The buffer size for IPC was changed from 4096 + to 1024, because of the error: + Warning: File Read Error (STDIN) when doing + set | match tty ... or ... type x | type + where x was 1024 or more bytes long. This error was followed by a hangup on logout, apparently + waiting for the sub-process to die after sending it 'bye'. The kernel routine ZFIOPR was tested + to record lengths of 4096 with no problems. I + don't understand this; it looks like a weird + problem in FIO. + knames.h AOSVS changes + libc.h AOSVS changes + math.h Added conditional for C math functions (nint) + spp.h AOSVS changes + xnames.h AOSVS changes +/iraf/math/bevington + chifit.f line 103 Ambiguous transfer of control to statement 70 +/iraf/math/curfit + OK +/iraf/math/deboor + cwidth.f line 112 Dummy argument declaration order + dtblok.f line 18 " + factrb.f line 25 " + fcblok.f line 29 " + sbblok.f line 15 " + shiftb.f line 33 " + slvblk.f line 119 " + subbak.f line 16 " + subfor.f line 21 " +/iraf/math/gsurfit + OK +/iraf/math/iminterp + Makelib ii_spline mentioned twice +/iraf/math/interp + interp.h Renamed to interpdef.h + clginterp.x Not found +/iraf/math/llsq + sva.f lines 179 & 181 Comma needed after P edit descriptor +/iraf/math/surfit + OK +/iraf/pkg/cl + bkg.c 2 places Declaration added for long c_clktime() + grammar.y Yacc conflicts: 8 shift/reduce + main.c The declarations for "rootpackage" & "clpackage" were made consistent with those in builtin.c so + that the "btbl" static table of builtins could + be properly initialized. + main.c envinit() 'lib/' changed to 'lib:' ????? + pfiles.c line 563 In addparam() prevent dereferencing a possibly + NULL pointer. + task.h prevtask and tp++ (or ++tp) didn't work due to + builtin.c (2 places) AOSVS alignment of pointers. Note: the fix for + debug.c VMS was not machine independent. + errs.c + exec.c (2 places) + pfiles.c + mem.h dereference() Changed to be machine independent. Previous + definition assumed byte addressing. +/iraf/pkg/help + nomore.x .f line 39 Relational operator with logical operands. + manout.x In man_breakpage(), identifier "nlines_per_page" was changed to "n_per_page" to shorten length of subroutine statement. (RPP maximum output line + length is set to 74.) +/iraf/pkg/help/lroff + output.x (3 places) 'col' multiply defined +/iraf/pkg/softools/boot/mklib + makefile AOSVS changes + mklib.c AOSVS changes + scanlib.c AOSVS changes +/iraf/pkg/softools/boot/spp + makefile AOSVS changes + readme AOSVS comments added + xc.c AOSVS changes + xc.c procedure "fatal" Missing argument to fprintf +/iraf/pkg/softools/boot/spp/rpp + makefile AOSVS changes +/iraf/pkg/softools/boot/spp/rpp/ratlibc + amove.c Changed link/unlink to amove for AOSVS + getnow.c Removed milliseconds + initst.c Changed _NFILE to 16 + makefile AOSVS changes + ratdef.h Added RF defines + readf.c Removed declaration for fread + writef.c Removed declaration for fwrite +/iraf/pkg/softools/boot/spp/rpp/ratlibf + caslab.f line 32 Warning: unreachable code + ctomn.f Changed and to iand + gitoc.f Changed and to iand + makefile AOSVS changes +/iraf/pkg/softools/boot/spp/rpp/rppfor + baderr.f Declared argument to be character*(*) + errchk.f line 78 Missing argument to call to GNBTOK + gtok.f line 132 Commented out B = 10 * B + C - 48 + to avoid fixed point overflows. + Not needed since radix conversion is done in XPP makefile AOSVS changes + synerr.f Declared argument to be character*(*) +/iraf/pkg/softools/boot/spp/xpp + decl.c Set MAXSYM = 200. Needed to compile + /iraf/sys/gio/nsppkern/gktopenws.x because of + include file nspp.com. Note: the overflow + check in d_enter is wrong. + makefile AOSVS changes + xppcode.c After MACHDEP, changed int to int2, int4, etc. + xppmain.c Check for NULL after calling getenv +/iraf/pkg/system + delete.x line 48 Relational operator with logical operands + match.x line 42 Relational operator with logical operands + line 76 Relational operator with logical operands + page.x line 204 Relational operator with logical operands + sort.x line 290 "answer" declared twice +/iraf/sys + OK + tsort cycle: libex.a gamove, gadraw, elogr + tsort cycle: libsys.a error, erract, xerfmt, environ, realloc, + malloc, syserr, itoc + environ, realloc, malloc, xerpop, erract, + xerfmt, gstrcpy + xerpop, erract, putci, flsbuf, fexbuf, + realloc, malloc + putci, flsbuf, fexbuf, realloc, xerpop, + erract, putline +/iraf/sys/clio + OK +/iraf/sys/etc + environ envgets broken out, to avoid tsort cycle +/iraf/sys/fio + fclobber.x .f line 67 Relational operator with logical operands + vfnmap.x .f line 546 Relational operator with logical operands +/iraf/sys/fmtio + dtoc3.x .f line 118 Parentheses needed for unary arithmetic operator evexpr.x .f line 393 Relational operator with logical operands +/iraf/sys/gio + elogd.x .f line 29 Parentheses needed for unary arithmetic operator elogr.x .f line 29 Parentheses needed for unary arithmetic operator/iraf/sys/gio/cursor + OK + tsort cycle : libcur.a gtrctrl, gtropenws, prpsio, giotr. +/iraf/sys/gio/gki + OK +/iraf/sys/gio/glabax + OK +/iraf/sys/gio/nspp + i1mach.f Copied from /iraf/sys/osb + r1mach.f Copied from /iraf/sys/osb + ibit.s substituted ishift.f + IAND - ignored + IOR - ignored + ISHIFT - calls ishiftc +/iraf/sys/gio/nspp/mctr + OK +/iraf/sys/gio/nspp/nspp + OK +/iraf/sys/gio/nspp/utilities + conrec.f line 387 Character constant broken over 2 lines + conterp.f line 1518 Compilier warning: padded short constant: 2HLO + line 1656 " +/iraf/sys/gio/nsppkern + nspp.com Changed all () to []. + pixels.f line 58 Arguments to intrinsic function not of same type/iraf/sys/gio/stdgraph + stgrcur.x .f line 66 Relational operator with logical operands +/iraf/sys/imio + OK +/iraf/sys/imio/db + idbpstr.x .f line 77 IM_NAXIS not defined in imio.h +/iraf/sys/imio/tf + OK +/iraf/sys/ki + kinode.com Added arrays n_local and n_nrefs. +/iraf/sys/libc + mathc.c Added conditional for C math functions (nint) + printf.c & The machine dependent technique of handling + scanf.c a variable number of arguments was only + very obscurely documented. All the + appropriate references of argp++ (sic) + were changed to argp-- for AOSVS. + OK +/iraf/sys/memio + OK +/iraf/sys/mtio + OK +/iraf/sys/os + MANY like zfaloc, zfiomt, zfiopr, zfrnam, zlocva, zmaloc, zmfree, + zopdir, zopdpr, zraloc : return (*status = XERR); etc. + C returning a value when CALLed by F77 causes + problems, at least with OPTimized code. + MANY AOSVS versions: zawset, zfacss, zfaloc, zfchdr, + zfgcwd, zfinfo, zfiomt, zfiopr, zfiost, zfmkcp, zfmkdr, zfpath, + zfprot, zfrnam, zfsubd, zfxdir, zglobl, zgtenv, zgtime, zinit, + zmain, zmaloc, zopdir, zoscmd, zsvjmp, zxwhen + makelib Dependencies corrected, and updated for AOSVS + zcall.c Dereference usage of PFI + Declare all arguments to be pointers + zfiolp.c line 116 Defererence "dispose" + line 129 ZOSCMD called with character arguments + zfiopl.c line 101 Same as zfiolp line 116 + line 114 Same as zfiolp line 129 + zfiopr.c line 55 Cast osfn as (char *) + zfiotx.c line 376 Dereference "status" + zlocpr.c An extra dereference was needed for AOSVS + zmain.c line 118 Cast osfn as (char *) + zopdir.c Modified input argument +/iraf/sys/osb + acht??.c Modification of input argument + bytmov.c Bug concerning undefined variable "otop" + bytmov.s MV/10000 version + d1mach.f Added entries for Data General MV/10000 + i1mach.f " + r1mach.f " + makelib AOSVS version + mii.x Removed call to high level routine "error" +/iraf/sys/tty + ttyopen.x .f line 208 Relational operator with logical operands + ttyputs.x .f line 43 Arguments to intrinsic function not of same type/iraf/sys/vops + OK +/iraf/sys/vops/achtgen + OK +/iraf/sys/vops/ak + Makelib Replaced .s modules with .x +/iraf/sys/vops/lz + Makelib Replaced .s modules with .x diff --git a/doc/ports/aux_port.doc b/doc/ports/aux_port.doc new file mode 100644 index 00000000..743d453c --- /dev/null +++ b/doc/ports/aux_port.doc @@ -0,0 +1,978 @@ +Begin IRAF port to Macintosh A/UX 2.0, 26Jan91. +----------------------------------------------- + +unix/as +unix/as.mac + +unix/bin +unix/bin.mac + +unix/hlib/irafuser.csh + Set up a new "mac" architecture. (01/26) + +unix/hlib/libc/iraf.h + Set the iraf root to point to /u1/iraf. (01/26) + +unix/as.mac/ishift.s +unix/as.mac/zsvjmp.s + Modified for the GNU assembler (GAS). (01/26) + +unix/hlib/*.csh + Modified for A/UX. (01/26) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Checked that LEN_JMPBUF was large enough to handle the setjmp + buffer used by A/UX. (01/26) + +unix/boot/bootlib/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/rpp/ratlibc/mkpkg.sh +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/os/mkpkg.sh +unix/shlib/mkpkg.sh + Changed all occurrences of "cc" to "$CC" and all occurrences of + "f77" to "$F77". Changed all occurrences of "ranlib" to $RANLIB. + (01/26) + +unix/hlib/irafuser.csh + Added definitions for CC, F77, and RANLIB (set to "echo ranlib" for + A/UX, which uses COFF). For the first attempt to compile the system + I am using gcc and the Absoft A/UX Fortran compiler. Later I would + like to try f2c (Fortran to C translator) with gcc as an alternative + to the Absoft Fortran. Early tests indicate that this should work, + and may produce better optimized code than the Absoft compiler. I + have already verified that the A/UX f77 cannot be used to build iraf + - there were serious problems just trying to compile the files in + one directory. (01/26) + +------- +Begin bootstrap. For this I have the GCC flags set to fairly restrictive +values, enabling some optional warning messages, to flush out any +questionable coding constructs. GCC is also an ANSI C compiler, which may +mean additional problems. (01/26) + +unix/os/mkpkg.sh + GCC doesn't echo the filename (as in "file.c:") during compiles, + which I found annoying, so I changed the mkpkg.sh to use the Bourne + shell FOR construct to compile each file separately. (01/26) + +unix/setarch.sh + The A/UX version of "test" does not have the -h flag to test for + symbolic links, so the existing script did not work. Still trying + to a portable way to do this, I changed the script to use the + construct: if [ "`ls -d as`" = "as" ]; then ... (01/26) + +unix/os/alloc.c + 1. The file header comment section contained the sequence "for the + /dev/* entries...". The "/*" would cause a warning from gcc that + there might be a comment buried in another comment, which can cause + a comment to terminate prematurely. In this case it was harmless + and indeed there was no error, but I changed the text to eliminate + the warning. + 2. Moved the #include to before the #include , + as the A/UX version of the latter requires the former. (01/26) + +unix/os/getproc.c + 1. Had to add + + #ifdef AUX + #include + #include + #include + #endif + + before the #include , to get the latter to compile. + + 2. In the A/UX nlist facility n_name is an array rather than a + pointer to char, so entries such as + + nl[0].n_name = "_proc"; + + had to be changed to + + strcpy (nl[0].n_name, "_proc"); (01/26) + +unix/os/prwait.c + In pr_getipc(), deleted unused variables error_code, error_status, + waitpid. (01/26) + +unix/os/zalloc.c + 1. In ZDVALL, deleted unused variable x_status. + 2. Deleted unused variable i in loggedin(). (01/26) + +unix/os/zfioks.c + 1. Deleted the old, commented out code for rcmd(), as variables + defined for this were being reported as unused. Added a comment + explaining that rcmd and friendly-host authentication cannot be + used without making the process suid root. + 2. Added #ifdef SYSV support for SysV termio. Terminal driver + ioctls are used in this routine to set raw mode for the password + prompts. + 3. GCC was complaining that the setjmp/longjmp used in zardks, + zawrks could cause certain register variables to become undefined + (op and nbytes in zardks, ofd in zawrks), so I changed the storage + class from register to auto for these variables. (01/26) + +unix/os/zfiolp.c + I had to change the declaration + + static PKCHAR xnullstr[1] = XEOS; + to + static PKCHAR xnullstr[1] = { XEOS }; + + (PKCHAR=short and XEOS=0) or GCC would complain about an invalid + initializer. Must be a feature of the ANSI C syntax. (01/26) + +unix/os/zfiotx.c +unix/hlib/libc/kernel.h + 1. Modified to add #ifdef SYSV support for SysV terminal i/o. + 2. GCC complained about some functions which were used (default + storage class extern) and later declared static; added static + declarations for these functions to the file header to eliminate + these (harmless) warning messages. (01/27) + +unix/os/zfxdir.c + Deleted unused local variable "ch". (01/27) + +unix/os/zgcmdl.c + Deleted unused local variable "ev". (01/27) + +unix/os/zgcmdl.c + Produced a coupld of "/* within comment" warning messages due an + example of some code in the header comment. Changed /* in + the example to /@ to avoid the (harmless) warning. (01/27) + +unix/os/zgtime.c + Had to #ifndef SYSV the #include as this file does + not exist on SysV systems. (01/27) + +unix/os/zmain.c + Deleted unused local variables "junk" and "wsetsize". (01/27) + +unix/os/zwmsec.c + Added "static" to explicitly specify the storage class in the first + declarations of "napmsx", which is declared static in the source + given later in the file. (01/27) + +unix/os/zxwhen.c + 1. The system dependent definition "fcancel" would not work for A/UX; + added a #ifdef AUX version. + 2. GCC did not realize that the call to kernel_panic in zxwhen was + an exit, and would warn that the value of variable "vex", used later + in the procedure, could be unitialized. Added a statement to init + this to null to avoid the warning message. + 3. In zxgmes, the char pointer to the returned error message was + not being initialized if no error had occurred. Modified to return + the null string in this case. (01/27) + +unix/os/zzstrt.c + Added #ifdef SUNOS4 conditionals around certain declarations which + are used only the #ifdef SUNOS4 code which follows, to avoid unused + variable warnings. (01/27) + +unix/boot/bootlib/envinit.c + Deleted the unused variable "osfn" in loadpkgenv. (01/27) + +unix/boot/bootlib/bootlib.h + Deleted the commented out #define NOVOS definition, which causes + a /* in comment warning and doesn't need to be in this file anyhow. + (01/27) + +unix/boot/bootlib/osfcopy.c + 1. Deleted the unused variable "binary_file". + 2. Added a return at the end of the function, to guarantee that + a function value was returned. (01/27) + +unix/boot/bootlib/ostime.c + Modified with #ifdef SYSV for SysV. This whole business needs to + be redone sometime to provide rigorously correct time primitives + for iraf. (01/27) + +unix/boot/bootlib/vfn2osfn.c + Local variable "first_time" defined but never used. (01/27) + +unix/boot/generic/generic.c + 1. In copy_comment(), added an entry time initializer for the + local variable "flag". + 2. GCC complained about the variable "ch" in evaluate_expr() possibly + being used before being initialized. This looked harmless in this + case, but I added a global initializer to eliminate the warning + message. (01/27) + +unix/boot/mkpkg/host.c + Deleted a couple of unused "exit_status" variables. (01/27) + +unix/boot/mkpkg/host.c + Deleted unused variable "ip" in search_mkpkgfile(). (01/27) + +unix/boot/mkpkg/mkpkg +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/scanlib.c + 1. Added a #include "mkpkg.h" to scanlib.c. This file includes extern.h + which references a structure defined in mkpkg.h. + 2. Deleted unused local variable "key" in h_scanlibrary(). (01/27) + 3. Replaced the MAX_SYMBOLS definition in scanlib.c by MAX_LIBFILES, + as there is also a MAX_SYMBOLS in mkpkg.h which means something + quite different. (01/29) + +unix/boot/mkpkg/sflist.c + In sf_scanlist, the GCC static analysis indicated that variable "tail" + could possibly be used without being initialized. Added code to + initialize tail=head before scanning the list. (01/27) + +unix/boot/mkpkg/tok.c + 1. In do_if(), in the event of a syntax error the local variable "bval" + could be used without being initialized. Once again probably harmless + but it makes GCC complain. + 2. Unused variable "ch" in do_call(). + 3. Module do_include() was not returning an exit status in all + cases. (01/27) + +unix/boot/rmfiles.c + 1. Unused variable "i" in main(). + 2. Another warning from GCC static analysis suggesting that local + variable "fp" might be being used before being initialized (definitely + not in this case, but I added an initializer to avoid the message). + (01/27) + +unix/boot/wtar/wtar.c + Unused variable "op" in putheader(). (01/27) + +unix/boot/spp/xc.c + 1. Unused variable "cmdbuf" in main(). + 2. Variable "append" in sys() could be used before being + initialized. (01/27) + +unix/boot/spp/xpp/xppcode.c + 1. Unused variable "irafdefs" in do_include(). + 2. parse_task_statement() did not return a function value in all cases. + 3. accum() did not return a function value in all cases. + 4. Unused variable "digit" in charcon(). Function did not return + a value in all cases. + 5. Variable "value" not initialized in all cases (when an error + occurs, but it causes a warning message). (01/27) + +unix/boot/spp/xpp/decl.c + Local variable "sp" was not being initialized in all cases (i.e., + when an error occurred). (01/27) + +unix/boot/spp/rpp/ratlibc/getlin.c + The local variable "c" was not being initialized in all cases. (01/27) + +unix/mkpkg.sh + Commented out the SHLIB build code, as there is no shared library + support for Mac/IRAF yet. (01/27) + +unix/gdev/sgidev/sgidispatch.c + Deleted unused local variables "maxch" and "status". (01/27) + +-------------------------- +Second bootstrap attempt. (01/27) + +unix/os/gmttolst.c + Added #ifdef SYSV support. (01/27) + +unix/os/mkpkg.sh + Changed the "rm alloc.o" to "rm -f alloc.o", as the .o file is + not being left behind on this system, using GCC. (01/27) + +unix/os/zfioks.c +unix/hlib/irafuser.csh + GCC still warns that longjmp could clobber the values of several + local variables in this routine. Evidently this is a feature of + ANSI C. The values of automatic variables not declared "volatile" + are not guaranteed to be preserved in a longjmp. Added a -DANSI + to irafuser.csh and some #ifdef ANSI code to zfioks.c to provide + the necessary (but not non-ANSI backwards compatible) definitions. + (01/27) + +unix/os/zfiotx.c + Another longjmp warning, this time in ZGETTX. Variable "op" might + not be saved over a longjmp. In this case I was able to avoid the + problem merely by moving the op initialization statement to after + the setjmp. (01/27) + +unix/os/zfiopl.c + In zclspl, another case of an array aggregate initializer "= val;" + having to be changed to "= { val };" when initializing an array of + length 1. (01/27) + +unix/os/zoscmd.c + Modified so that if SYSV is defined, "fork" is used instead of + the BSD-ism "vfork". (01/27) + +------------------------- +Third bootstrap attempt. + +unix/boot/spp/rpp/ratlibf/*.f +unix/boot/spp/rpp/rppfor/*.f + The Fortran compiler I am using (Absoft) is case sensitive by default + and does not append an underscore to symbol names. For testing + purposes it would be most useful to have the Fortran names occupy + the same name space as the C library names, so I translated the + contents of all the above files to lower case. (01/27) + + [In retrospect this wasn't the best way to do this, the Fortran + compiler has a switch which does it more simply. (01/29)] + +unix/boot/spp/rpp/ratlibc/ratdef.h + Removed the trailing underscore from the names of the Fortran + routines. (01/27) + +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + Edited to remove the trailing underscore from all names. (01/27) + +unix/boot/spp/rpp/ratlibr/defs +unix/boot/spp/rpp/rpprat/defs + It probably doesn't matter, but these directories both have a copy + of the "defs" file and the files should be the same, but they aren't. + The version in rpprat has been changed to increase the size of + various size limiting buffers. The fortran sources should be + regenerated using compatible defs files. (01/28) + +unix/boot/spp/rpp/mkpkg.sh + RPP failed to link in the first bootstrap attempt. To fix this + it was necessary to modify the $CC link command in the mkpkg.sh, + as follows: + + $CC $HSI_CF -t rpp.o librpp.a libf.a libc.a -lf77 -o rpp.e + + The -t flag had to be added to avoid warnings about the inconsistent + sizes for the cdsmem common (see "defs", above). The -lf77 had to + be added for the Absoft compiler, as evidently it uses library + functions for a few simple things like ABS that some RPP code + references. (01/28) + +unix/boot/mkpkg/host.c + Added a #ifdef SYSV to the code which calls RANLIB, since this is + not used on SYSV (COFF) systems. (01/28) + +unix/os/irafpath.c + Added a #ifdef AUX conditional to search the "unix/bin.mac" directory + for Mac/IRAF system files. (01/28) + +unix/spp/rpp/rppfor/poicod.f + The HSI bootstrap completed successfully, although some things are + probably still not working correctly. XC now runs but in my very + first compile test I ran into a nasty problem in the third party + Absoft Fortran compiler. The compiler complains about the following + statement in fio$areadb.x being out of order: + + memi(fp+15) = 0 + + Evidently it thinks this array assignment is a statement function + or something. I was further able to isolate the problem with the + following source: + + subroutine areadb (fd) + integer fd + integer Memi(1) + real Memr(1) + equivalence (Memi, Memr) + common /Mem/ Memi + save + memi(fd+15) = 0 + end + + The compiler barfs on a syntax error on line 8 of this file, the + lone assignment statement. With a little further testing I was + able to establish that this is due to case sensitivity in the + compiler! Changing the memi to Memi causes the problem to go away. + To fix the problem in RPP I had to replace the file poicod.f by + a version that uses "mem" rather than "Mem" in the data strings. + (01/28) + +unix/hlib/libc/libc.h + The Absoft compiler prefixes the names of Fortran commons with C + (e.g., "Cfiocom", "Cmem", etc.) and omits the trailing underscore + as in C. Modified libc.h to reflect the above naming scheme. (01/28) + +--------------------------------- +Started first core system sysgen. (01/28) + +sys/plio/plr2l.gx +sys/plio/plp2l.gx +sys/plio/pllsten.x +sys/plio/pllrop.x + The Absoft Fortran compiler could not handle the following type of + statement in these files: + + ll_out[op] = M_DH + -dv + + It was necessary to place parens around the (-dv) to avoid the + problem. (01/29) + +unix/hlib/iraf.h +unix/boot/spp/xpp/decl.c + 1. There were a lot of problems in PLIO in the initial sysgen due to + the use of bitwise boolean intrinsics in these files. The Absoft + compiler does have some bitwise functions but 1) they are typed, + not generic functions, and 2) a function which takes two short + integer arguments as input can return an integer result (contrary + to the documentation). Also, this is not a problem but a comment, + but the compiler generates function calls for the bitwise operators, + which is rather inefficient. The only way I could come up with to + work around these limitations was to define the bitwise intrinsics + in hlib$iraf.h as follows: + + define and iand(int($1),int($1)) + define or ior(int($1),int($1)) + define not jnot(int($1)) + define xor ieor(int($1),int($2)) + + 2. Unfortunately the argument expansion in the above definitions + would cause problems with functions that declare the bitwise + intrinsics, i.e., that contains statements such as "int and()". + It was necessary to modify decl.c to add special processing for + function declarations so that any declarations of the bitwise + intrinsics could be omitted. This may be a generally useful + addition as special processing of intrinsic functions might be + required on any system. (01/29) + +sys/mwcs/mwtransd.x + This file also contained a "foo + -bar" construct requiring + parenthesis to get by the Absoft parser. (01/29) + +sys/imfort/imemsg.x + This file contained four Fortran escapes (error message strings) + which ran over the 72 character line limit of Fortran, causing the + Absoft compiler to complain. (01/29) + +unix/hlib/mkpkg.inc + Added the following default compile time flags: + + -f Fold all symbol names to lower case. This is needed + for some of the Fortran sources. + + -k Restore all registers when a procedure returns. + This is necessary if Fortran modules are to be + called from C code. + + Mac/IRAF also needs the -z link flag. (01/29) + +sys/gio/nspp/portlib/gridal.f + The equivalence on line 4 was incorrect (or at least ill-advised) + due to a dimension error. The code "mfmtx(1),ifmt(1))" should + have been "mfmtx(1),ifmt(1,1))". (01/29) + +sys/gio/nspp/portlib/z8zpbd.f +sys/gio/nspp/portlib/z8zpii.f + The Absoft compiler didn't want to permit use of DATA to initialize + variables in common so I had to move all the remaining DATA + statements out of z8zpbd.f into run time initialization statements + in z8zpbd.f (01/29) + +unix/boot/spp/xc.c + 1. The routine printargs() was printing one more argument then there + was, due to a <= that should have been a < in a FOR loop. + 2. Modified XC to use GCC for linking. (01/29) + +----------------------- +This took care of all the problems with the sysgen up to the attempt to +link the first task. Trying to build the system task, there was a file +that did not compile. Inexplicably the system hang twice requiring a +reboot, once while linking and the other time while trying to do a mkpkg +on the system task (the system hand requiring a reboot in my first attempt +to link an iraf task!). No idea why this happening. (01/29) + +The above problem was due to the rebuilding of XC after the first sysgen. +libsys.a and libvops.a existed this time so XC was not built NOVOS, which +was no good as the entire kernel needs to be consistent one way or the +other, and I haven't done runtime checks of the iraf libraries yet anyhow. +(01/30) + +unix/hlib/mkfloat.csh + The tar -x flags are "tar -xpf" for BSD systems, and "tar -xof" for + SysV systems. Added a new SET at the top to document the dependency + and set the value to -xof for AUX. (01/30) + +unix/hlib/irafuser.csh +unix/hlib/fc.csh +unix/hlib/cl.csh + Set up two different architectures for Mac/IRAF. These are the + following: + + mf2 Absoft MacFortran II binaries + f2c F2C/GCC binaries + + F2C is a publically available Fortran to C translator, and GCC is + the GNU C compiler. These can be combined to yield an interesting + Fortran compiler constructed from only publically available sources. + This is particularly interesting since we are already using GCC + as our C compiler for A/UX. Initially I am building with the Absoft + compiler but I plan to try F2C/GCC later. (01/30) + +mkpkg +noao/mkpkg +bin.generic + + Edited the root mkpkg file to add entries "mf2" and "f2c" for setting + the bin.mf2 and bin.f2c architectures. Deleted all the Sun + architecture entries. Added a bin.generic subdirectory. (01/30) + +pkg/system/help/lroff/textout.x + Modified to eliminate the ENTRY point. (01/30) + +----------------------- +First successful iraf process link on A/UX - xx_system.e (01/30) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + The Absoft compiler does not append an underscore to function names + hence SPP/Fortran function names occupy the same name space as C + names. Probably there are a number of SPP procedure names which + redefine standard C library or other host system names (this has also + been a problem with VMS/IRAF so fixing that system will be another + benefit of dealing with this here). The first such name collision + found is GETPID. Since the SPP getpid was calling the host getpid + an infinite loop would result. This is probably what was causing + the system to hang up when XC was run earlier. (01/30) + + Summary of redefined names (to be added to as I locate them): + + getpid + + All such name collisions are handled by remapping the name in iraf.h + and libc/xnames.h. + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + Modified XC to use CC for linking (I was using GCC) and change the + "-/t" link flag in mkpkg.inc to "-/Wl,-t", which instructs CC to + hand off the flag -t to the linker. (01/30) + +unix/os/zzstrt.c +unix/os/zxwhen.c + Digging into the A/UX internals to see how A/UX handles the IEEE + exceptions I find that a function "initfpu" is called during process + startup. It turns out though, that this function is a no-op! + From the assembler it appears that the current version is initfpu(){}. + Must be a placeholder for a future version of A/UX when it will be + done "right". No changes to zzstrt/zxwhen yet until I figure out + how... (01/30) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.MF2 + Uh oh... Absoft compiler bug, and a troublingly simple one. The + memio$sizeof.x procedure is only one line long: + + return (ty_size[dtype]) + + but the Absoft compiler with default optimization enabled is + eliminating most of the code and producing something which does + not even use the ty_size array. Added the file to the mkpkg + special file list to be compiled without optimization. (01/30) + +-------- +unix/hlib/mkpkg.sf.MF2 + On March 27 I finally got a few more hours to play with this port; + looked into the next runtime bug in x_system.e. It turned out to + be necessary to recompile file fio$fgetfd.x without optimization. + Once again, the bug was disturbing as it did not look like an + especially subtle bug. It looked like the compiler was allocating + the same location on the stack in two places and the second reference + would overwrite the first. After working around this one, I tried + running x_system.e and it failed again with another startup bug, + still trying to execute all the code in clopen.x. It begins to + look bad for the Absoft compiler; if we can't get any further than + this I suspect the system will be riddled with optimizer bugs. (3/29) + +-------- +I think it is time to give up on the Absoft compiler, at least for now, and +try F2C instead. (4/3) + +unix/hlib/irafuser.csh +unix/hlib/mkpkg.sf.F2C + + Configured for F2C architecture. (4/3) + +unix/hlib/libc/libc.h +unix/hlib/libc/xnames.h +unix/hlib/libc/knames.h +unix/boot/spp/rpp/ratlibc/ratdef.h +unix/as.mac/zsvjmp.s + Restored the trailing underscores, since F2C adheres to this + convention. (4/3) + +unix/hlib/iraf.h + Commented out the definitions for and,or,not,xor, since F2C uses + the SPP versions (which came originally from UNIX f77). (4/3) + +sys/fmtio/ctotok.x + Local variable numch never used (this is old code so I don't know + why no other compiler has found this). (4/3) + +sys/fmtio/evexpr.y +sys/fmtio/evexpr.x + The second argument (a debug flag) to yyparse (xev_parse) is a + boolean, but xev_parse was being called elsewhere with an integer + argument. Changed to a boolean since the Y*cc code contains many + if (yydebug) constructs. (4/3) + +sys/etc/main.x + FREDIR is a subroutine but was being called as a function in one + place in this file. (4/3) + +sys/tty/ttyputl.x + This file contained a statement call putci (fd, "_") which was + incorrect, since the argument "_" is type char but is supposed to + be integer. (4/3) + +sys/gio/gopen.x + The pointer array graphcap_file was not being used. (4/3) + +sys/pmio/pmplls.x + The second call to pl_plls was missing the ll_depth argument. (4/3) + +sys/qpoe/qpppar.x + The second call to qp_sizeof was missing an argument. (4/3) + +sys/imfort/bfio.x + There was an extra "status" argument to one of the calls to + zsttbf. (4/3) + +unix/boot/spp/xc.c + Built the CC link time flag "-Wl,-t" directly into XC, since it + is needed to link iraf programs and is too much of a nusiance to + have to type when XC is used manually. The flag turns off a linker + warning message warning about inconsistent lengths for commons. + (4/3) + +sys/gio/ncarutil/conran.f + Local variable LNGTHS not used. (4/3) + +pkg/plot/crtpict/t_crtpict.x + A call to gardwrd was missing the maxch argument. (4/3) + +unix/hlib/install + 1. Had trouble with the $hbin/sgi2* $hlib/sgi2* stuff in MODEFILES. + The second did not expand to anything and the string "$hlib/sgi2*" + was left in MODEFILES with the * unexpanded, causing problems later + when appended to a directory prefix. Since there are not supposed + to be any executables in hlib anyhow I deleted the second reference. + 2. In the code which checks the MODEFILES, I added a test to see + if the file exists as named, before looking for it in each of the + directories. Referencing a nonexistent directory can cause the + script to bomb on A/UX (it shouldn't, but it does - a bug in csh). + 3. Had to change /etc/chown to /bin/chown. (4/3) + +pkg/plot/getdata.x + The statement if(nxrows) was incorrect as nxrows is integer. (4/3) + +pkg/xtools/intrp.f +unix/hlib/mkpkg.sf.F2C +unix/as/intrp.c + + F2C failed to produce correct C code for this file (which contains + multiple ENTRY points). Hand edited the C version and added it to + the special file list. (4/3) + +pkg/dataio/fits/fits_wpixels.x +unix/hlib/mkpkg.sf.F2C +unix/as/fits_wpixels.c + + Same bug as above. (4/3) + +pkg/plot/t_graph.x + Variable window declared but not used. (4/3) + +pkg/plot/t_velvect.x + Variable nset declared but not used. (4/3) + +sys/fmio/fmlfundel.x + The two calls to fmio_bind and fmio_errck were both lacking the + fm argument. (5/3) + +sys/ki/kireceive.x + A call to strcpy was missing an argument. (5/3) + +sys/imio/imopsf.x + The call to pl_ssize had an extra unused argument. (5/3) + +sys/etc/pagefiles.x + ttyctrl, which is an integer function, was being called as a + subroutine. (5/3) + +sys/gio/gopen.x + Local string variable graphcap never used. (5/3) + +sys/imio/iki/oif/oifclose.x +sys/imio/iki/oif/oifdelete.x + The integer function protect() was being called as a subroutine. + (5/3) + +sys/plio/plglr.gx + The routine pl_rangerop was being called incorrectly. (5/3) + +sys/plio/plprop.gx + The VOPS routine argt (replace if greater than) was being + called incorrectly in three places. (5/3) + +sys/plio/plascii.x + The subroutine pl_glpi() was being called as a function. (5/3) + +sys/plio/pldebug.x + The integer function pl_l2ri() was being called as a subroutine. + (5/3) + +sys/pmio/pmglp.gx + The routine pl_pixrop was being called incorrectly. (5/3) + +sys/qpoe/qpioopen.x + A call to syserr was being made where syserrs was intended. (5/3) + +unix/os/zzstrt.c + Added a call to "setcompat (COMPAT_BSD)" to be executed upon + process startup. This tells the kernel to use BSD semantics + when executing system calls. This fixed a problem I was having + with ZWMSEC, which would result in the process being killed + with a SIGALRM when the interval timer interrupted, even though + a signal handler had been posted earlier with sigvec. (5/4) + +unix/os/zzstrt.c + Here is another problem that, like the previous one, was very + indirect and hence difficult to track down. The time-task feature + of iraf, e.g., "$imstat dev$pix", when run for the first time + in a new process, would return a clock time such as "-416:+0" + instead of "0:13" or whatever. Thereafter it would be ok, until + the process was restarted. This turned out to be due to the + clock time returned by the first call to ZGTIME being wrong. + The eventual solution was to add a call to TZSET to zzstrt to + initialize the SysV time stuff before any time calculations + take place. What I suspect was happening is that in gmt_to_lst + I was accessing "timezone", which is a global data variable in + SysV, but the value was being changed sometime later in an + indirect call to TZSET. Using a global variable for something + like this that is evidently not constant is a very questionable + feature of SVID (unless it is a bug in A/UX). (5/5) + +unix/hlib/mkpkg.sf.F2C + It turns out that the A/UX version of bcopy does not work (is + destructive) for overlapping arrays, so I had to remove all the + entries for amov$t and bytmov from the special file list. This + problem showed up as a segmentation violation in HELP. (5/5) + + All three of these last bugs were very difficult to track down - + essentially, in each case I eventually just guessed what it might + be, after tracking the problem down to a region of code. + +math/curfit/cvpower.gx + Changed a "amovk$t(INDEFR,...)" to "amovk$t(INDEF,...)". The former + causes a real to be passed where a double is expected. (5/6) + +sys/gio/cursor/grccmd.x + External pr_psio() declared but never used. (5/6) + +sys/gio/stdgraph/stgclws.x + External std_onerror() declared but never used. (5/6) + +sys/libc/qsort.c + The static function qst() was being used before being declared, + resulting in an extern/static declaration inconsistency. (5/6) + +math/gsurfit/gs_f1deval.gx + In the line: call amulk$t (Mem$t[sx], 2., Mem$t[sx], npts) + The real constant "2." was changed to the generic form "2$f". (5/6) + +sys/ki/irafks.x + The "task irafks = onentry" was incorrect since ONENTRY is an integer + function. This was harmless since the purpose of the task statement + was merely to get an iraf main, but I set up a dummy t_irafks task + to avoid the type clash. (5/6) + +pkg/cl/bkg.c + Static function bkg_close() used before being declared static. + Added a static function declaration to the file header. (5/6) + +pkg/cl/debug.c + Same as above, function dd_f(). (5/6) + +pkg/cl/edcap.c + Same as above, function map_escapes(). (5/6) + +pkg/cl/pfiles.c + Same as above, function mapname(). (5/6) + +pkg/cl/cl.x + Same problem as in irafks, above. ONENTRY is a function and should + not be referenced as a subroutine in the task statement. Added a + dummy t_cl procedure to avoid the type clash. (5/6) + +unix/hlib/login.cl + The line + + if (access ("home$loginuser.cl") cl < "home$loginuser.cl" + + causes the following statement to be ignored if the IF is true. + This is a CL bug, but for now the workaround is to add a null + statement ; to the line following the IF. (5/6) + +pkg/cl/gram.c + dumpparams() modified to write to t_out instead of t_stdout. + ccdphot related experiment. (6/21) + +------------------ +Rebuilt HSI with VOS facilities. (7/19) +Started build of NOAO packages. (7/20) + +unix/hlib/irafuser.csh + Added "-Wl,-t" to the HSI_CF flags. This gets rid of a linker + warning about xercom changing size. (7/20) + +-------------------- +System upgraded to V2.10. Started with the SunOS version of the system +from tucana, merged A/UX stuff back in, which many minor changes. (10/01) + +unix/hlib/irafuser.csh + Added -traditional to the GCC flags, to avoid some problems + in the A/UX system includes, probably introduced in the upgrade to + A/UX 2.0.1. (10/02) + +lib/libex.a + After the sysgen I had to do a "ar ts" on this file to regenerate + the symbol table; not clear why this library and no other. Until + the reason is clear, no action. (10/02) + + [This appears to be a bug in AR; it is failing to properly generate + [the symbol table for very large libraries. A manual "ar ts" seems + [to fix the problem, but this bug will cause problems with a sysgen.] + +sys/gio/ncarutil/pwrity.f + Unused variable LEN on line 335. (10/02) + +sys/gio/ncarutil/pwrzi.f +sys/gio/ncarutil/pwrzs.f +sys/gio/ncarutil/pwrzt.f + Variables HIGH,WIDE,WHITE, and LNGTH not used (same problem in + all three files). (10/02) + +math/gsurfit/mkpkg + Contained a statement $ifeq (USE_GENERIC, YES) which was incorrect, + as a lower case "yes" is required since $ifeq uses a simple string + comparison. (10/02) + +math/nlfit/nlzero.gx + Multiple problems; two calls to aclr had an extra argument, but + invalid pointer references too. (10/02) + +mkpkg + The special file list wasn't being used; this was traced to the + use of a symbol link to the iraf root directory. One cannot + reference the iraf root via a link or directory path comparisons + will fail. (10/03) + +sys/fio/fntgfn.x + A pattern such as "*%" would match all filenames, a potentially + disastrous feature if used, say, to delete host filenames containing + the % character. % is dangerous because it is just another character + in a unix filename, but in iraf it is one of the the pattern + matching metachacters (substring editing). The filename template + code was modified to 1) require at least two unescaped % characters + in a pattern for the % to be recognized as a metacharacter, and + 2) to allow the % character to be escaped (the code was supposed + to do this but it was only partially implemented). (10/14) + +---------------------------------------------------------------------- +Summer 1992 - Mac system upgraded to A/UX 3.0. New versions of F2C and GCC +installed. V2.10 upgrade resumed Oct 13-14 1992. There were a number of +minor changes most of which are probably not worth recording here. The +main changes were to "f77" and "xc". f77 is a script in /usr/local/bin +which calls f2c and gcc to act as a Fortran compiler. This was tuned to +improve the integration of f2c and gcc. XC was modified to support gcc +better, e.g. omit .o files from compiles to avoid annoying gcc warnings, +use gcc rather than cc for linking, search the right directories, etc. +The new version of GCC (2.2.1) is quite a bit changed from what I used +last year. I had to make one bug fix to cpp to get source level debugging +to work for .f files compiled with f77/f2c/gcc. + +diff/merged the HSI and did a fresh bootstrap, pretty routine. (10/13) +installed and built tables and noao. (10/13-14) +diff/merged the DEV directory. (10/14) + +unix/hlib/install + Changed the code which checks the ownership and permissions of alloc.e. + On a/ux, ls -l prints the group by default, and this was causing the + old string comparison to fail. (11/21/92) + +unix/os/zfioks.c +unix/os/zfiotx.c + Changed some TCSETAF ioctl's to TCSETAW ioctl's. The TCSETAF ioctl + claims to flush the output buffer before changing the terminal driver + settings, but output data was being lost. Using TCSETAW appears to + avoid this problem. (01/13 1993) + +unix/hlib/iraf.h +unix/hlib/libc/spp.h + Changed the values of INDEFR and INDEFD to the following. + + INDEFR 3.4e38 + INDEFD 1.7d308 + + and IS_INDEFR and IS_INDEFD were changed to + + IS_INDEFR (($1) > 3.3e38) + IS_INDEFD (($1) > 1.6d308) + + This was necessary as the floating point equality tests used to + check for INDEF were failing using F2C/GCC. (01/15 1993) + +math/iminterp/arbpix.x +math/interp/arbpix.x +noao/astutil/t_setairmass.x +noao/digiphot/photcal/evaluate/phprint.x +noao/mtlocal/cyber/cykeywords.x +noao/mtlocal/cyber/t_ridsfile.x +noao/onedspec/ecidentify/ecline.x +noao/onedspec/irsiids/t_bswitch.x +noao/onedspec/irsiids/t_flatdiv.x +noao/onedspec/irsiids/t_flatfit.x +noao/onedspec/irsiids/t_sums.x +noao/twodspec/apextract/peaks.x +noao/twodspec/multispec/fitclean.x +noao/twodspec/multispec/fitsmooth.x +noao/twodspec/multispec/intgauss5.x +noao/twodspec/multispec/peaks.x +noao/twodspec/multispec/solve.x +noao/twodspec/multispec/t_fitfunc.x +pkg/bench/xctest/lintran.x +pkg/images/lib/sigl2.x +pkg/images/tv/display/sigl2.x +pkg/images/tv/iis/src/sigl2.x +pkg/lists/lintran.x +pkg/plot/crtpict/sigl2.x +pkg/proto/t_imscale.x +sys/clio/clgeti.x +sys/clio/clgetl.x +sys/clio/clgetr.x +sys/clio/clgets.x +sys/clio/clglpi.x +sys/clio/clglpl.x +sys/clio/clglpr.x +sys/clio/clglps.x +sys/clio/clputi.x +sys/gio/calcomp/t_calcomp.x + The above files were modified to replace "equals-INDEF" style + constructs with "IS_INDEF" constructs. (01/15) + +unix/hlib/install + Added a number of "rm -f $TEMP" statements to delete any old $TEMP + files before attempting to create new ones. (2/01) + +unix/os/zzstrt.c + Added #ifdef AUX code to enable the IEEE exceptions in the 68882. + There is no A/UX support for this so it had to be done in assembler + by writing to the FP control register. (3/09 1993) + +unix/os/zxwhen.c + Added #ifdef AUX code to decode SIGFPE and print error messages + appropriate to the exception. There is no A/UX support for this so + it was necessary to write assembler to read the FP status register + and test which exception occurred. (3/09) diff --git a/doc/ports/notes.aix b/doc/ports/notes.aix new file mode 100644 index 00000000..203cff47 --- /dev/null +++ b/doc/ports/notes.aix @@ -0,0 +1,456 @@ +# Begin AIX IRAF configuration. 30Mar91. +# RS/6000 Model 530, deskside, 24 Mb RAM 355+670 Mb disk, 24bit color. + +# lslpp -h bos.obj says the following. This means our current OS is +# 3001. From the net I see that the latest release is 3003, so we +# are a bit behind. Also, the system was configured on 19-20 Sep 90. + +Option Name State Event Date/Time Release User Name +-------------------- ---------- ---------- --------- --------------- ---------- +bos.obj INACTIVE COMMIT 02/02/90 03.01.0000.0000 root + INACTIVE APPLY 09/19/90 03.01.0001.0003 root + ACTIVE COMMIT 09/19/90 03.01.0001.0003 root + +unix/as +unix/as.rs6000 + +unix/bin +unix/bin.rs6000 + + Set up AS and BIN directories for the machine architecture "rs6000. + (3/30) + +unix/as.rs6000/zsvjmp.c + +unix/os/mkpkg.sh +unix/os/mkpkg + It won't be easy to generate the assembler version of zsvjmp.s for + the RS6000, so I set up a C version temporarily just to get things + to link. The AIX CC doesn't have a -S flag and neither the AIX + assembler or architecture is simple, so it will take some work to + generate the assembler version. (3/30) + +unix/hlib/libc/iraf.h + Set the iraf root to point to /u1/iraf. (3/30) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Checked that LEN_JUMPBUF was big enough for this machine; it wasn't, + had to increase it from 64 to 65. (3/30) + +unix/hlib/irafuser.csh +unix/hlib/mkiraf.csh +unix/hlib/fc.csh +unix/hlib/cl.csh + Made changes to reflect the new iraf root and architecture. (3/30) + +unix/shlib/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/bootlib/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh +unix/boot/spp/rpp/ratlibc/mkpkg.sh +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/os/mkpkg.sh + Replaced all the "cc" calls by $CC, the "f77" calls by $F77, and the + "ranlib" calls by $RANLIB. (3/30) + +unix/hlib/irafuser.csh + Set the architecture (MACH) to rs6000. Added definitions for CC, F77, + RANLIB. (3/30) + +--------------- +Begin bootstrap attempts. (3/30) + +unix/os/mkpkg.sh + Changed the "rm alloc.o" to "rm -rf alloc.o". The AIX CC doesn't + leave the .o file behind. (3/30) + +unix/hlib/irafuser.csh + Added compile time switches -D_BSD -D_NO_PROTO -D_BSDINCLUDES to + make the port go a little easier. (3/30) + +unix/os/zfiomt.c + AIX has modified the unix tape interface as follows: 1) mtio.h is + not tape.h, 2) MTIOCTOP is STIOCTOP (ST = streaming tape), 3) struct + mtop is struct stop, 4) all the MTfoo ioctls are now STfoo, 5), + BSF/BSR are RSF/RSR. Other than that things look very much the + same, just a few gratuitous name changes. (3/30) + +unix/os/zfiopl.c +unix/os/zfiolp.c + AIX CC insists that initializers be enclosed in { }. Added brackets + to the initializers for the variable xnullstr in these two files. + (3/30) + +unix/os/zgtime.c +unix/hlib/libc/kernel.h + Changed the macro define HZ to CLKFREQ. The former is defined in + AIX and was causing a redefined symbol warning. (3/30) + +unix/os/zxhwen.c + Modified the fcancel macro for the AIX stdio.h. (3/30) + +AIX + 1. The problem with pwd hanging the process in an infinite loop + recurred. Once this happens any pwd will hang. Evidently the only + way to clear the problem is to reboot. + 2. Once a task hung and after a while I get an error message about + an NFS timeout, server felis not responding. felis is the system I + am working on, the file access should be direct rather than NFS. + (3/31) + +unix/os/zwmsec.c + AIX likes signal handers to be declared type void rather than int. + Changed the #ifdef SUNOS4 to #ifdef _AIX. (3/31) + +unix/boot/spp/rpp/ratlibc/ratdef.h + Removed the trailing underscores from all the Fortran callable C + externals. AIX C and Fortran externals share the same name space + and both are preceeded by a leading period (rather than underscore) + in the host level symbol table. (3/31) + +unix/hlib/libc/libc.h +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + Same as above. (3/31) + +unix/hlib/libc/setjmp.h + Commented out some SunOS #pragma stuff. (3/31) + +unix/mkpkg.sh + Commented out shared library stuff. (3/31) + +unix/hlib/libc/knames.h + Restored the trailing underscore to ushlib_,vshlib_,vshend_ to avoid + a name conflict on vshlib in zzstrt.c. Since these are not Fortran + generated externals we can have a trailing underscore or not as we + wish. (3/31) + +unix/boot/mkpkg/scanlib.c + AIX uses COFF libraries (actually something called extended COFF) + but for some reason they changed the symbols ARMAG, SARMAG, + and SARAMAG to AIAMAG, SAIAMAG, and SAIAAMAG (they changed the R to + IA in each name). It was not clear what was the reason for this + change. A perhaps more justifiable one was that ar_fmag and ar_name + are now elements of the union _ar_name. With these changes the file + at least compiles. (3/31) + +unix/os/irafpath.c + Added #ifdef _AIX conditional to cause bin.rs6000 to be searched. + (3/31) + +unix/boot/spp/xc.c + Modified for AIX. The fortran compiler is xlf, host libraries are + -lxlf, -lm, [-lbsd]. Default no shared library (yet). (3/31) + +unix/hlib/iraf.h + Bitwise intrinsic functions are AND,OR,NOT,XOR (same as SPP!) no + changes needed. (3/31) + +unix/hlib/mach.h + An "od" test appears to indicate that the RS6000 byte ordering is + big-endian (same as Sun) so no byte swapping needed. (3/31) + +AIX + The system IS pretty fast - only takes about 10min for a bootstrap. + (3/31) + +unix/hlib/install + 1. Added #!/bin/csh at the top of the file. The default root shell + is ksh and ksh was trying to exec the file. + 2. Commented out the line with `mach` and added one set to rs6000. + 3. Uncommented the exit 0 to skip the Suntools stuff. (3/31) + +--------------------------- +Start sysgen attempts. (3/31) + +unix/boot/spp/xpp/decl.c + XLF cannot compile integer*[2|4] functions (types char, short, and + long in SPP). Upon enountering a routine declared, e.g., + + integer*4 function foo (args) + + the compiler returns the message + + 1.17 1514-105: (S) Variable functionfoo was declared as + array of type OBJECT-TIME. This type of array is not + permitted in a main program. + 1516-036: (S) Variable foo has undefined type. + + this only happens for integer*2 and integer*4 functions. The + Fortran manual states that only integer functions are allowed + (excluding the other types such as real etc.). The compiler is + clearly treating the declaration as that of a variable rather + than a function. + + This is potentially a very serious problem - we may not be able to + use integer*2 if it is not fully implemented. As a workaround I am + going to try modifying the preprocessor to declare all integer-like + (char,short,int,long) functions as type integer. This should + almost work, but will probably fail at runtime if char or short + functions are passed in the argument list to another procedure. + (3/31) + +unix/boot/mkpkg/scanlib.c + The archive file changes for AIX turned out to be far more extensive + than mere name changes, and I ended up spending several hours + figuring out how AIX archives work and rewriting this file. A major + misconception that it took me some time to get over was that AIX + archives have a linked list of members, whereas UNIX systems have + a sequential list of members. You HAVE to follow the links. (3/31) + +AIX + The AIX implementation of symbolic links is funny, or at least the + "ls" task is. A while back I had to add the -L flag to ls to get + it to list directories pointed to by symbolic links, but with that + flag set it will always follow links, and a command such as "ls -l" + on a link lists the pointed to file, not the link. So far I have + not figured out how to get it to behave like "other" unix systems I + am familiar with (it is not clear AIX is really a unix variant so + I am not sure the "other" is accurate). (3/31) + +unix/gdev/iism75/zrdm75.x + Towards the end of the file there were a couple of calls to MOD + with mixed type arguments (short and int). It was necessary to + add an INT to the short arguments to make both argments integer + before XLF would accept the statements. (3/31) + +----------------- +Completed the first sysgen, although with many errors which I haven't begun +to check out yet. This thing IS fast - the full core system sysgen took +only 2:26. (4/1) + +AIX + A funny thing about the initial sysgen is that it produced libraries + and executables even in cases where there were serious errors. This + may be big system policy (VMS is like this too to some extent) but + it is not standard for unix. It causes problems because the objects, + even though broken, were produced with recent file, dates which + causes utilities like make/mkpkg to be useless for recompilation + following errors. Maybe I can find a way around this but I shouldn't + have to. (4/1) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + Added definitions to map the VOS name "getpid" to "xgtpid" at the + host library level. On AIX Fortran and C names share the same name + space, and a name collision on getpid was causing infinite recursion. + (4/1) + +pkg/system/help/lroff/textout.x + This file failed to compile due to a complaint about the declaration + for the argument out to the ENTRY point textout. Rather than look + into this I installed a version of the file from the AUX port which + eliminates the entry point, and the problem went away. (4/1) + +dev/hosts + Added columba to hosts table. (5/22/91 SRo) + +------------------------------------- +Begin AIX/IRAF update to V2.10. (8/10/92) +AIX version 3.2.2. Fortran version 2.2. + +unix/as.rs6000/zsvjmp.s + Added the RS/6000 version of zsvjmp.s. It took over a day to learn + how to program in assembler on this machine (do to limited and + misleading documentation and tools) and about 20 minutes to write the + routine... (8/09) + +------------------------------------- +Performed a diff/merge of the HSI and merged changes into the V2.10 HSI. +The bootstrap proceeded with only minor problems. Started sysgen. (8/10) + +unix/hlib/mkpkg.inc + Still tuning default fortran compilation switches. Current set is + as follows: "-/qhalt=e -/qflttrap -/NQ20000". (8/10) + +sys/gio/gki/gkiclosews.x + In the call to zcall2, "Mems[...]" was changed to "Mems[gki+...]". + (8/10) + +sys/imio/imsetr.x + There were a couple of occurrences of IM_PLFLAGS(im) where the (im) + was missing. (8/10) + +lib/plio.h +sys/plio/* + Assorted changes to resolve type clashes; see notes above from + original port. (8/10) + +sys/qpoe/qpiomkidx.x + Type clash in two calls to min, referencing type short field of + bucket header. (8/10) + +sys/mwcs/mwtransd.x + The AIX compiler did not like a "... * -ltv_1[i]" expression, had to + put parens around the -ltv_1[i] term. (8/10) + +sys/vops/fftx.f + This routine contained a declaration "x(2), y(2)" where the arrays + X,Y are of arbitrary length. Later on in the code the third and + fourth elements of each array were referenced and this caused a + compiler message about an incorrect constant array subscript. + Changed the declaration to "x(*), y(*)". (8/10) + +sys/gio/ncarutil/agdflt.f +sys/gio/ncarutil/agdash.f +sys/gio/ncarutil/aglbls.f +sys/gio/ncarutil/agsetp.f + The AIX compiler doesn't like the CHARACTER*504 declarations in these + files. Had to change these to CHARACTER*500 to get the files to + compile. That could be incorrect, but IRAF doesn't use this code + anyhow (but we will keep it around until the ncar stuff is phased + out). (8/10) + +pkg/images/tv/display/iisofm.x + Added the "int" in "max (int(y[i]),..." to fix a type clash. (8/10) + +pkg/images/tv/iis/ids/idsinit.x + Fixed a type clash in two calls to MIN. (8/10) + +pkg/images/tv/iis/iism70/iissplit.x + Another type clash in a call to MIN. (8/10) + +pkg/images/tv/imexamine/iejimexam.x + Type clash - same one as seen earlier on cephus with the DEC + compiler. (8/10) + +pkg/images/imarith/iccclip.x +pkg/images/imarith/icsclip.x +pkg/images/imarith/icstat.x +pkg/images/imarith/icaclip.x + More type clashes, again the same as seen on cephus. (8/10) + +pkg/plot/t_gkidir.x + Another short/int type mismatch for MIN (that has been that way since + the dawn of time). (8/11) + +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.AIX3 + + Added artdata/t_mkechelle.x and astutil/t_gratings.x to the NOAO + package special file list. These files have to be compiled with the + optimizer turned off on the RS/6000 or the compiler generates the + following message. + + 1500-008: (S) COMPILER LIMIT EXCEEDED in astgrg: Program too + complicated to be compiled. Compilation ended. Reduce the + complexity of the program and recompile, or lower the level of + optimization and recompile. + (8/11) + +noao/digiphot/daophot/daolib/erf.x +noao/digiphot/daophot/daolib/dpevalpsf.x +noao/digiphot/daophot/psf/dpgaussfit.x +noao/digiphot/daophot/psf/dpsubgauss.x +noao/digiphot/daophot/psf/dpwritepsf.x + This code defines and uses a function called ERF, but ERF is a + Fortran intrinsic function (at least on the IBM compiler). Changed + the name to DAOERF. (8/11) + +noao/onedspec/dispcor/refgspec.x + Mixed real/double in call to MOD. (8/11) + +noao/onedspec/splot/fixx.x +noao/onedspec/shdr.x +noao/onedspec/t_deredden.x + Type clashes in intrinsics, already found and fixed on decstation. + (8/11) + +noao/onedspec/t_deredden.x + This file had another problem on the RS/6000 - syntax error in + expression. Had to add parens in "y * (-2.09002)". (8/11) + +noao/rv/coloncmds.x + The IBM compiler (like the decstation) also complained about cmd_write + being a function but no value was being returned. (8/11) + +noao/rv/fftutil.x + The IBM compiler generated the following messages for this file: + + 1514-047: (S) No initializations for this DATA statement will be + done because of presence of syntax error. + 1515-019: (S) Syntax is incorrect. + + Evidently this was due to the use of the name "data" for an argument + to the procedure fft_fixwrap. There was nothing wrong with the code, + the compiler was in error in this case. To workaround the problem + I changed the name of the data vector "data" to "v" in fft_fixwrap + and in the previous procedure. (8/11) + +noao/imred/ccdred/src/icstat.x + Type mismatch problems, already run into on cephus. (8/11) + +noao/imred/vtel/mscan.x + The function mtneedfileno() was declared boolean but used as an integer + function (which it is). (8/11) + +unix/os/zzstrt.c +unix/os/zxwhen.c + Added #ifdef _AIX code to these routines to enable and handle the + IEEE exceptions. This is quite difficult on the RS/6000, compared + to most systems. There really aren't any IEEE exceptions on this + machine. To catch things like floating divide by zero it is necessary + to compile code -qflttrap, which causes a test-and-branch and trap + instruction to be compiled in line *after every floating point + instruction*. If the floating instruction overflows, underflows, + or whatever, the branch will be skipped and the application generates + a SIGTRAP. The ex_handler routine in zxwhen gets called by the trap. + At that point the floating point status register can be examined to + determine what "exception" occurred. This appears to work but I + am still a bit uncomfortable about all this; the IBM documentation + is not very definitive and thus far I am unable to determine exactly + how the RS/6000 hardware works (e.g., no where does it say exactly + what happens when, for example, floating underflow occurs). (8/11) + +unix/boot/mkpkg/scanlib.c + While relinking the CL to test the exception handling code I noticed + a problem with mkpkg not reading the libpkg.a file. This was traced + to a problem in scanlib.c, used to read AIX archive files. The code + assumed that the first library member followed the file header. This + is normally, but not always the case. In reality the library member + list is a linked list and the offset to the list head is stored in + the file header. (8/12) + +unix/hlib/mkpkg.sf.AIX3 + I had a lot of trouble getting the integer divide-by-zero exception + to work. Finally I determined (by studying assembled code with adb, + not from the info-hider) that the compiler needs to generate extra + instructions to check for a divide by zero. The Fortran compiler + does this by default but the C compiler does not. Studying the + C compiler documentation I could not find a switch to enable this + option, but fortunately a query to usenet revealed that "-qcheck" + was what I was looking for. I inserted this in hlib$mkpkg.inc and + tried to rebuild the CL and got a number of messages such as the + following. + + compile.c: + *** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT... + *** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT... + *** PROGRAM ERROR *** No OTHERWISE or WHEN for execution in SELECT... + cc: 1501-230 Internal compiler error; please contact your IBM repr... + + Obviously some sort of compiler bug (C doesn't have these statements). + The workaround was to add only unop.c and binop.c, the CL files that + evaluate arithmetic expressions in scripts, to mkpkg.sf.AIX3. + Fortunately these files compile without the error messages. (8/12) + +unix/os/zgcmdl.c + Modified this file to pick up the argument list on AIX systems. + There is no portable way to do this, one does it by linking an + executable and studying the symbol table with nm and adb, looking + for something which will give the address of the argument list. + So far every system has proved to have a way to do this (on AIX + there is a symbol called p_argv). (8/12) + +unix/os/alloc.c + AIX magtape devices have names like "rmt.1", so I had to change + the code which checks for simple filenames to permit period. + This still excludes names like ../path, since / is not permitted. + (10/17) diff --git a/doc/ports/notes.convex b/doc/ports/notes.convex new file mode 100644 index 00000000..d6582383 --- /dev/null +++ b/doc/ports/notes.convex @@ -0,0 +1,761 @@ +Begin V2.8 CONVEX/IRAF BETA port, 6-8 August 1989. +See also notes from October 1987 ALPHA port (appended). +------------------------------------------------------- + +Summary: + Installation of V2.8 was straightforward except for a nasty bug + involving the host routine BCOPY. I originally tried to use the + C code versions of AMOVC etc. (installed in AS). This caused the + system environment list to become mangled, due to BCOPY modifying + the data it was copying during a copy used to shift by one char + to align the buffer in a REALLOC of the environment buffer. The + speculation is that the BCOPY uses vector instructions, and if the + input and output arrays are aligned to within less than one vector + register length data can be corrupted due to the whole vector + segment being copied at once. + + Aside from that, things came up fine. There were several compiler + crashes with core dumps, but all but one of these were a result of + problems with the IRAF code or system configuration. In general + the compiler seems to be in much better shape than during the + alpha port. + + The final system is configured as follows: the HSI is generic (no + floating point, can run on any Convex), and two architectures are + supported, IEEE and NATIVE, corresponding to the two floating point + architecture options available for the Convex. + + Detailed notes on the modifications made to port V2.8 BSD/IRAF follow. + +unix/as.convex/ +unix/as.convex/zsvjmp.s +unix/bin.convex/ + Added AS and BIN directories to the HSI for the Convex. Installed + the zsvjmp.s written for the alpha port. + +unix/boot/bootlib/osputenv.c + Commented out the call to putenv() - there is no comparable facility + on the Convex. + +unix/boot/spp/mkxc.sh + Fixed a bug - the call to CC was not referencing $HSI_CF. + +unix/boot/spp/rpp/rppfor/declco.f + Replaced by a version that enables IMPLICIT NONE, which is how + undeclared variable detection is handled by the Convex compiler. + +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh + Replaced the F77 by FC, the Convex fortran compiler. There is no + F77 on the Convex. + +unix/boot/spp/xc.c + 1. Replaced all F77 references by FC. + 2. The link library list for the Convex is + -lF77 -lI77 -lD77 -lm -lmathC1 + 3. Modified the list of directories searched by sys() (for XPP and + RPP) to include /local/bin, /usr/local/bin, and /iraf/local/bin. + Merely another hack until the problem is fixed properly. + 4. Modified the list of directories searched by run() (for FC) to + include /usr/convex, which is where FC resides on the Convex + (another hack until the problem is properly resolved). + +unix/boot/spp/xpp/xppcode.c + This HSI file turned out to have code in it (for converting HMS to + decimal floating) that used floating point. Replaced by an + equivalent routine which uses only integer calculations. + +unix/hlib/iraf.h + The bitwise intrinsics for the Convex are IAND, IOR, IEOR, and NOT. + +unix/hlib/i1mach.f +unix/hlib/r1mach.f +unix/hlib/d1mach.f + Replaced by the Sun versions. + +unix/hlib/mkpkg.sf.CX +noao/lib/mkpkg.sf.CX + Added special file lists for the Convex. At present there is only + one special file, images$geometry/geofit.x, which has to be compiled + at O1 due to a fortran compiler bug. + +unix/hlib/irafuser.csh +unix/hlib/libc/iraf.h +unix/hlib/libc/libc.h +unix/hlib/mkiraf.csh +unix/hlib/mkpkg.inc +unix/hlib/motd + Routine changes for the Convex. Added a #define CONVEX to . + MACH is set to `convex' in the irafuser.csh. The HSI flags are + + setenv HSI_CF "-O -fx" + setenv HSI_FF "-sa -fx -O0 -na -nv -nw" + setenv HSI_XF "-q -/sa -/fx -/O0 -/na -/nv -/nw -z" + + The MKPKG flags for the IEEE architecture are + + $set FLOAT = "fi" + $set XFLAGS = "-c -q -/sa -/fi -/O2 -/na -/nw -/nv" + $set XSFLAGS = "-c -q -/sa -/fi -/O1 -/na -/nw -/nv" + $set XVFLAGS = "-c -q -/sa -/fi -/O2 -/na -/nw" + $set LFLAGS = "-z -/fi" + + and similarly for the NATIVE (Convex floating point) architecture. + +unix/os/getproc.c + This file, part of the tape drive allocation code, would not compile + on the Convex (it reads the kernel process table which is fairly + system dependent). Commented out the offending code (a status value + is returned indicating that the user does not have any processes) + until the tape drive allocation problem can be resolved for the + Convex. + +unix/os/irafpath.c + Modified to look for files in unix/bin.convex if the machine type + is convex. + +unix/os/zxwhen.c + Added FPE hardware signal codes from . + +mkpkg +noao/mkpkg +bin.ieee/ +bin.native/ +noao/bin.ieee/ +noao/bin.native/ +noao/lib/mkpkg.inc +unix/hlib/cl.csh +unix/hlib/mkpkg.inc + Configured the system for two architectures, IEEE and NATIVE, + corresponding to the two floating point options on the Convex. + The HSI is compiled generic (no floating point dependencies), + hence is runnable on either type of Convex. + +dev/pix.imh +dev/pix.pix +dev/vdm.gki + Installed versions for the Convex (IEEE architecture only!). + +sys/gio/nspp/sysint/encd.f + Fixed a bug in this file - this was fixed once before but evidently + never got merged back into the master system. The problem is the + statement + + if (len (char (ns + ichar ('0'))) .eq. 2) then + + which is evidently unnecessary and which makes an illegal or at + least very questionable use of CHAR. + +sys/gio/ncarutil/sysint/ishift.x +sys/gio/nspp/sysint/ishift.x + Commented out the code for IAND and IOR, since these are intrinsic + functions in Convex/Fortran. + +unix/hlib/install + Changed the machine type from `vax' to `convex'. + +---------- +Basic BETA port completed. (8/8) + +---------- +August 8-10: on site at the VLA testing IRAF on the VLA system, which +includes two Convexes (plus some Suns and VAXes). + +dev/devices + Configured for the Convex. (8/11) + +unix/hlib/login.cl + Added EDT and EMACS as foreign tasks to the default USER package. + (8/11) + +unix/as/zsvjmp.s + An IMAGES task failed during testing while trying to create a type + DOUBLE image, indicating that the MEM common was not double word + aligned. I was able to fix this by setting the symbol __mem_ (the + mem common) to the absolute value 0, which not only double word + aligns the common, it aligns it to any size, and simplifies + debugging by arranging for SPP pointers to directly index process + virtual memory. This technique (setting __mem_ to zero) did not + work for the Convex back when the alpha port was attempted. (8/12) + + [Postscript] Setting mem to zero evidently was the cause of a + number of mysterious program crashes that occurred once the system + was relinked with the new zsvjmp.o with mem=0. The problems went + away when things were relinked with the mem=0 commented out, + indicating that the mem=0 was the problem. There was not time + to check this out, but my guess is that since on the Convex program + memory begins at 0x80000000, setting mem=0 causes very large pointer + offsets which can overflow to negative integer values. I changed + zsvjmp.s to set mem=0x80000000 and the problems seem to have gone + away, and we still get double word alignment. (8/13) + +unix/hlib/ic.csh + +unix/hlib/install +unix/hlib/login.cl +unix/boot/spp/xc.c + Had problems getting IMFORT programs to link. + 1. The solution was to modify XC (FC) to link against the Convex + library -lU77 when linking a host program. This can only be done + when XC is called with the -h flag as the library will result in + a multiply defined loader error message if searched when linking + an SPP program. + 2. The iraf foreign task FC now calls a new cshell script ic.csh, + which calls XC after first determining the floating point option + switch required to link IMFORT programs so that they are consistent + with IRAFARCH. For example, if Convex/IRAF is running the IEEE + binaries, XC will be called with -/fi. + 3. Modified the install script to make a link for ic.csh. The new + task name stands for imfort-compile, and is not called FC because + that is the Convex Fortran compiler. Possibly FC should not be + used as the command name in the USER package either, but I did + not want to change that as it is shown as FC in all the user + documentation. (8/12) + +unix/hlib/cl.csh + Modified to define IRAFARCH if not already defined. (8/12) + +unix/os/alloc.c + Modified to support the Convex tape allocation facilities. Uses + the Convex TPALLOC and TPDEALLOC utilities to perform the actual + tape allocate/deallocate. As a result, alloc.e no longer needs + to have suid-root, although the install script will still install + it that way. Verified that local as well as remote network + allocation works. (8/12) + +pkg/images/imarith/imcmode.gx + IMCOMBINE would fail when presented with a section containing pixels + that all had the same value. The program would go into an infinite + loop in the code at the end of imcmode.gx. Modified to avoid a + floating point equality test, and to add some limit checking in + a couple of places to avoid infinite looping. (8/13) + +unix/hlib/mkfloat.csh + 1. While using "mkpkg [ieee|generic]" etc. on teh Convex, the message + "usage: rm -[rif]" would sometimes appear. This turned out to be due + to calling rm with a null file list when restoring from generic. + The fix was to to delete the file list file in the same command + which deletes the listed files, ensuring that there is at least + one file in the command. + 2. Also reorganized the code somewhat to use only one RMBIN rather + than two, which speeds it up by a factor of two. (8/14) + +unix/os/zmaloc.c + IMFORT programs would die on a memory allocator error: this was + traced to the fact that the custom memory allocator used for + BSD4.3/IRAF was still present in Convex/IRAF (which was built from + the BSD version). Commented out the memory debug code in zmaloc.c + and all was well. We will leave the applications relinked with the + custom memory allocator in for now, since they have already been + tested and did not show any problems. (8/14) + +---------- +ALPHA port notes follow. + +CONVEX/IRAF Port. D.Tody, beginning 26 October 1987. +Using machine in Greenbelt, MD, as follows: +----------------------------------------------------------------------------- + ********************************************************* + WELCOME TO C1EAST + ********************************************************* + SYSTEM MANAGERS: BRIAN CHRISTIANSON & DALE LANCASTER + +C1EAST IS A CONVEX C1-XP MINI-SUPERCOMPUTER. + + - 128 MEGABYTES OF PHYSICAL MEMORY + - 1.5 GIGABYTES OF DISK SPACE + - 40 MFLOPS PEAK PERFORMANCE + +C1EAST IS CONFIGURED WITH: + + - 25.6 MEGABYTES OF DISK BUFFER CACHE + - 64 USER SYSTEM + - ETHERNET + - IMAGEN LASER PRINTER + + - 4.2 BSD UNIX, CONVEX RELEASE 6.1.1 + - VECTORIZING FORTRAN VERSION 3.0 + - VECTORIZING C VERSION Beta 2.0 (vc 1.0 is still around) + - ANSYS VERSION 4.2 +----------------------------------------------------------------------------- + +Snapshot of V2.6 IRAF restored to disk (/extra/iraf) by Convex. (10/26) +Logged in via modem, took a look at Convex/UNIX, configured the IRAF login. + +unix/as -> unix/as.vax +unix/as/zsvjmp.s + Renamed the VAX assembler directory, and set up a new one for the + Convex. Wrote ZSVJMP/ZDOJMP for the Convex. This took a while, + and was one of the harder ones I have done, as the architecture and + the C setjmp/longmp are complex. The machine has a RISC architecture + but nonetheless is fairly complex (and fast and expensive). (11/2) + +unix/os/zxwhen.c + Modified the hardware specific exception codes table for the Convex. + In the process of doing this, discovered that the old code assumed + that hardware codes were distinct, while in fact they can be + numbered similarly for different signals. Modified the ZXGMES + routine to work with hardware codes of the form SIGNAL+HWCODE rather + than the old HWCODE. (11/2) + +unix/boot/spp/rpp/ratlibf/mkpkg.sh +unix/boot/spp/rpp/rppfor/mkpkg.sh + Replaced "f77" by "fc". (11/2) + +unix/hlib/irafuser.csh + Added an "-sa" flag for fc (the Convex Fortran compiler). This flag + prevents static compilation of argument lists and is necessary if C + code is to be called from Fortran. (11/2) + +unix/hlib/libc/spp.h +unix/hlib/libc/libc.h +unix/hlib/libc/iraf.h + Replaced the vax spp.h by the Sun version, which should be good + enough for now, and may even be correct (Convex evidently supports + IEEE floating as well as their native (Cray?) format). Modified + the Fortran COMMON external names in libc.h to add the extra + leading underscore, used by the Convex Fortran compiler to make + common external names distinct from other Forran externals. + Edited the iraf.h file for the new $iraf (= /extra/iraf). (11/2) + +unix/hlib/motd + Modified logo for the Convex. (11/2) + +------------------------------------- +Started up a bootstrap of the HSI. This completed without incident, except +for a great many copies of the following warning messages from FC: + + Obsolete flag '-O' - flag '-no' assumed. + fc: Warning on line X of Y.f: label defined but never referenced. + +Modified HSI_FF (fc flags) in hlib$irafuser.csh to "-O1 -sa -nw" and repeated +the bootstrap starting in the SPP directory. This worked, but now the +optimizer was enabled, and it helpfully produced a zillion of the following +advisory messages: + + fc: Advisory on line X of Y.f: more optimization is possible if this + function call has no side effects. + +Changed the flags to "-O1 -sa -nw -na" to fix this. Tested the main HSI +tasks (rmbin, rtar, wtar, mkpkg, xpp, rpp) and they all passed basic tests!. +(11/2) + +unix/hlib/i1mach.f +unix/hlib/d1mach.f +unix/hlib/r1mach.f + Installed the versions for the Sun (IEEE floating etc.) for now. + This will probably need to be tweaked later. (11/3) + +unix/hlib/iraf.h + Modified the name mappings for the bitwise intrinsic functions (and, + or, etc.). For the Convex they are the same as in VMS Fortran. + Set values of INDEFR and INDEFD, as below. (11/3) + +unix/boot/spp/xpp/xppcode.c + Changed the Fortran mappings of the SPP "char" and "short" type + coercion functions to "int2", which is implemented on the Convex. + (11/3) + +unix/boot/spp/xpp/decl.c + Convex Fortran supports IMPLICIT NONE, so I modified the code which + processes a procedure declaration to output this statement. (11/3) + +unix/hlib/mach.h + Modified the values of various numeric constants. The max exponent + for real is 38, for double is 307. The INDEF values were modified + slightly. The EPSILON values were very similar to those for the Sun. + Byte swapping is no - most significant byte first. (11/3) + +unix/hlib/mkpkg.inc + Set the default compiler flags as follows: + + XFLAGS = "-cq -/O2 -/nw -/na -/nv" + XSFLAGS = "-cq -/O1 -/nw -/na -/sa" + XVFLAGS = "-cq -/O2" + + I have added a new global flag variable XSFLAGS, to be used for the + VOS routines, i.e., for pure system code. XFLAGS is for normal + scientific applications code, which is pure SPP or SPP/Fortran code, + and which would often benefit from vectorization. System code may + call C routines (e.g., the kernel routines), and rarely involves + vector operations. Distinguishing between the two broad classes + of codes is necessary on the Convex in order to permit static + allocation of procedure argument lists in Fortran (SPP) code. + If Fortran code is to call C routines, all arguments must be pushed + on the stack, hence this optimization option cannot be used in VOS + code (flag -sa disables static allocation of argument lists). + + Optimization level O2 includes vectorization, O1 provides only local + and global scalar optimization but no vectorization. The -n flags + turn off various compiler informative and warning messages, which one + normally will not want to see (except perhaps once during development). + These messages are enabled by default only for the VOPS routines. + (11/3) + +iraf$mkpkg +sys/*/mkpkg + Added the line '$set XFLAGS = "$(XSFLAGS)"' to each VOS mkpkg file, + to override the default xflags with the xsflags. In the root mkpkg, + added the $set to the "syslibs" program. (11/3) + +unix/boot/spp/xc.c +unix/boot/spp/mkxc.csh -> mkxc.sh + Modified XC to use "fc" rather than "f77" as the compiler; omitted + the -u flag, since this is done differently for Convex Fortran. + To the "run" code, added /usr/convex to the search path, since that + is where fc is located (a better solution would probably be to put + the path in the #define). (11/3) + +local/bin/ + +local/bin/xc -> $hlib/xc.e (etc.) + Only for the purposes of the port, set up a local/bin directory for + iraf, and put it on PATH in the .login. This will work only for iraf, + but avoids having to make a request to the local system manager. + (11/3) + +------------------------------------ +Started up the first full sysgen. (11/3) + +Summary of results of first full sysgen: + The sysgen ran to completion, but not without problems. The spool file + was 19305 lines, 7205 lines when summarized (the extra stuff was + mostly advisory information about vectorizing the VOPS routines). + There were 23 serious runtime compiler errors of the form: + + fc: >>>>> C O M P I L E R E R R O R <<<<< + >>>>> See your system manager for help <<<<< + Error : Compiler error on line X of Y.c. + + These were distributed as follows: + + #times Error Message + + 16 Error : Compiler error on line 396 of misc.c. + 6 Error : Compiler error on line 155 of allocSReg.c. + 1 Error : Compiler error on line 584 of callintr.c. + + Note that these are errors in the Fortran compiler, not errors in + the Fortran source. The compiler routine which generated the error + is given in the message. These errors prevented compilation of the + affected source file. + + Other errors in the sysgen were [1] fc cannot compile .c files, + hence xc will have to be modified to call cc directly, and [2] in + sys/gio/ncarutil/sysint/ishift.x, functions IAND and IOR are defined + which appear to call themselves recursively, when the macros AND and + OR are expanded. These are dealt with further below. (11/4) + +local/bugs/ +local/bugs/spool.full +local/bugs/spool.bugs + Created a BUGS directory for the Convex and stored therein copies of + all the Fortran sources which cause compiler time compiler failures, + plus copies of the full spooled output from the first sysgen, and an + edited digest of the same containing only the compiler error messages. + Verified that the files cannot be compiled even at optimization level 0. + All files compiled with optimization turned off EXCEPT one, the + sysint/support.f file from gio/ncarutil. (11/4) + +sys/gio/ncarutil/sysint/support.f + The subroutine ENCD in this file contained a statement which would + cause the compiler to crash even with all optimization turned off. + The culprit is as follows: + + if (len (char (ns + ichar ('0'))) .eq. 2) then + + This is a pretty strange statement, and after staring at it for + a while I decided that it would always be false (NS can take on + values only between 4 and 6) and commented it out. Of course it + should not cause the complier to bomb, and I will report it to + Convex, but I think the code is incorrect and should be fixed. (11/4) + +sys/gio/ncarutil/ishift.x + This file contains source for the functions IAND and IOR, written in + SPP and defined in terms of the SPP intrinsics AND and OR, which are + implemented as macro defines in hlib$iraf.h. On the Convex these are + defined as the Fortran intrinsics IAND and IOR, but they are declared + as external functions, hence the Fortran compiler quite correctly + flags them as recursive references and fails to compiler the file. + A simple fix is to replace the calls to AND and OR by calls to the + OSB library functions ANDI and ORI; this is inefficient, but on the + Convex the calls in the NCAR code map directly to the Fortran + intrinsics anyhow, and if this were not the case the routines should + be encoded in assembler and put on the special file list. (11/4) + +unix/hlib/mkpkg.sf + Added the 22 or so files with runtime compiler failures to the special + file list for CONVEX/IRAF. Specifically: + + $set noao = "iraf$noao/" + $set XCP = '& "$xc -cq -/no -/nw -/na &"' + $set XCS = '& "$xc -cq -/no -/sa -/nw -/na &"' + + $special "sys$fio/": fseti.x $(XCS); + $special "math$iminterp/": msifit.x $(XCP); + $special "pkg$dataio/fits/": fits_rheader.x $(XCP) + fits_wheader.x $(XCP); + $special "pkg$images/imarith/generic/": imcmode.x $(XCP); + $special "pkg$images/filters/": t_convolve.x $(XCP); + $special "pkg$plot/": prows.x $(XCP); + $special "pkg$utilities/": t_curfit.x $(XCP); + $special "$(noao)proto/": t_bscale.x $(XCP) + t_imscale.x $(XCP); + $special "$(noao)onedspec/": t_addsets.x $(XCP) + t_bswitch.x $(XCP) + t_dispcor.x $(XCP) + t_flatfit.x $(XCP) + t_sums.x $(XCP) + t_widstape.x $(XCP); + $special "$(noao)twodspec/apextract/": excextract.x $(XCP) + excstrip.x $(XCP) + t_apnormalize.x $(XCP); + $special "$(noao)twodspec/longslit/": ilsetbins.x $(XCP); + $special "$(noao)imred/ccdred/src/generic/": imcmode.x $(XCP); + $special "$(noao)imred/dtoi/": hdtoi.x $(XCP); + (11/4) + +unix/boot/spp/xc.c + Modified to sort out .c source files and compile these separately + with CC (the original XC used f77, which would accept anything). (11/4) + +unix/as/zsvjmp.s + This file contains the code which attempts to set the address assigned + by the linker to the symbol __mem_ (the MEM common in Fortran) to 0. + This is not yet working on the Convex; get multiply defined symbol + errors. I have commented this out for the moment in order to proceed. + (11/4) + +------------------------------------ +Second attempt at a sysgen. Special files all compiled ok, but got loader +errors as noted above, hence no executables. After fixing zsvjmp.s I was +able to successfully link an executable. Tried running it, and wonder of +wonders, it actually ran and produced a prompt! The process did not quite +run correctly, but most of the iraf main stuff was evidently working if we +got that far, so this is encouraging. (11/4) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf + I just remembered that there are a number of VOPS routines coded in + C in the OSB directory, which can be called by any applications code. + Fortran code compiled with static argument lists enabled cannot be + call C routines directly, so until the OSB routines can be recoded + in Fortran for Convex, I have added the -sa switch for applications + code as well as VOS code. (11/4) + +---------------------------- +Third attempt at a sysgen. Deleted all non-HSI binaries and started up a full +sysgen. Should work this time with all the above bug fixes. (11/4) + +The sysgen completed normally, and this time suceeded in producing most of +the executables. The cl runs and most basic things work ok! There are a +number of runtime problems however, which need to be checked out. Looking +over the spooled output I find four more files that caused the compiler to +crash, this time with a core dump, without even a compiler error message. +The message from FC (indicating abnormal termination of a subprocess) is + + fc: System error in /usr/convex/fskel + +The files causing the problem were t_imarith.x in images, and in math, +gsaccum.x, gsrejectd.x, and isresolve.x. Dale, my contact at Convex, +says that there is a major new version of the Convex Fortran compiler, +currently in beta test, and that I should try that. I will proceed a bit +further with the current binaries before starting up another full sysgen, +as these have been running 8-9 hours. (11/5) + +unix/hlib/mkpkg.sf + Added the above four files to the special file list, to be compiled + with optimization level -O1 rather than -O2 (no vectorization). (11/5) + +unix/hlib/mkpkg.sf + After adding the above files to the special file list and resuming + the compile of the gsurfit and surfit packages, more files requiring + special treatment were uncovered. The total is now 34. (11/5) + +----------------------------- +With the math libraries now built, I was able to finish building the IMAGES +package and tried out a few things - IMSTATR was about 3.5 cpusec, IMSHIFTR +around 6+ cpusec. Interactive plotting is not yet working due to some +problem in the CL. Error recovery in the CL is not yet working due to a +problem in ZDOJMP, which has not yet been debugged. Until this is fixed, +any error will cause the CL to die. (11/5) + +unix/boot/spp/xc.c + Modified to use version 4.0 of the Convex Fortran compiler. (11/5) + +------------------------------------ +Sysgen 4. Archived (local/oldfc.arc) and deleted all the old non-HSI binaries. +Ready to start a full sysgen with the new compiler. Will do this in such a +way that the current executables remain intact for people to play with +tomorrow. (11/5) + +local/bugs.newfc + +local/bugs -> local/bugs.oldfc + Set up separate bug directories for the old and new FC. (11/5) + +unix/hlib/sf + +unix/hlib/sf/main.x + +unix/hlib/mkpkg.sf + The new sysgen has thus far compiled all the system libraries without + any compile time errors, hence looks much better (sysgen still in + progress; stay tuned). Even with the new compiler, however, I am still + getting an incorrect warning message "illegal transfer out of IFERR + block" from the iraf main. This was traced to the following code in + the main: + + iferr (...) + ; + or + call xerpsh + ... + if (.not.xerpop()) then goto NN + NN continue + + Even with the optimizer turned completely off, FC is chucking out the + call to XERPOP, causing the error message noted above. Since this is + not an optimizer problem, the only way to fix it was to hack on the + source file. The hacked version is in hlib$sf, and the file has been + added to the special file list for the new-fc. This is a particularly + worrisome bug, as there may be cases such as this scattered all over + the system. (11/5) + +----------------------------- +Sysgen with new FC looks pretty good. There was one fskel coredump (vectorizer +evidently) which I will check out below. (11/6) + +noao/onedspec/sensfunc/mkpkg +noao/onedspec/sensfunc/sfgraphs.x - + Deleted this zero length junk file and fixed up the mkpkg. (11/6) + +unix/hlib/mkpkg.sf + Added an entry for file dataio$reblock/reblock_file.x, which causes + fskel to coredump when compiled with level O2 optimization. Entered + in special file list for level O1 optimization. (11/6) + +unix/as/zsvjmp.s + Finished debugging ZSVJMP/ZDOJMP (this was the cause of the CL crashing + upon logout and during error recovery). The Convex version of this + routine was easily the most complex I have thus far encountered. + The Convex architecture and instruction set is simple, no problem; + the problem here as the complexity of the longjmp() code used to + make ZDOJMP. Instead of saving and restoring the machine context, + the routine actually pops successive stack frames off the machine + stack until it gets back to the stack frame of the ZSVJMP. There + are special cases, e.g., the stack frame pushed by the OS for an + interrupt handler. Twas a mess! (11/12) + +------------------------------------------------- +Resumed work on Convex port on 5 March - don't know how much time I have to +spend on this, but a little anyhow, and maybe the compiler is better. + + Cleaned up the some somewhat; moved some files to a save directory, + deleted a lot of junk test files scattered about the system. + Redid the bootstrap without incident. + Deleted all binaries and started a full sysgen. As of now (5 March + 5 pm) this is still in progress. The CL and x_system.e are up + and look fine. + +Here is the /etc/motd for the current Convex system: +------------------- + ********************************************************* + WELCOME TO C1EAST + ********************************************************* + SYSTEM WINGNUTS: BRIAN CHRISTIANSON & DALE LANCASTER + +C1EAST IS A CONVEX C1-XP MINI-SUPERCOMPUTER. + - 128 MEGABYTES OF PHYSICAL MEMORY + - 1.5 GIGABYTES OF DISK SPACE + - 40 MFLOPS PEAK PERFORMANCE + +C1EAST IS CONFIGURED WITH: + - 12.8 MEGABYTES OF DISK BUFFER CACHE + - 64 USER SYSTEM + - ETHERNET + - IMAGEN LASER PRINTER + - 4.2 BSD UNIX, CONVEX RELEASE 6.1 + - VECTORIZING FORTRAN VERSION 4.0 with In-Lining + - VECTORIZING C VERSION Beta 2.0 (vc 1.0 is still around) + - ANSYS VERSION 4.2 + + CONVEX COVUEshell V7.0 installed. Look in /usr/doc for + new release notices. + + +---------------------------------------------- +Resume testing yet again, this time with a new version of the Fortran +compiler. + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + 1. Added a new flag "-N" to XC. Setting this flag causes XC to try to + use the beta test Fortran compiler, which is called as + + /usr/convex/newfc/fc -B/usr/convex/newfc ... + + 2. Added the -N flag to the flag macros in mkpkg.inc. (4/16) + +unix/as/zsvjmp.s +unix/os/zdojmp.c + +unix/os/mkpkg + Replaced the nativ ZSVJMP/ZDOJMP I originally wrote for the Convex + with a much simpler version which "piggybacks" on the C setjmp/longjmp. + The old file is zsvjmp.CONVEX. (4/16) + +---------------------- +Deleted the main system binaries and started a new sysgen. Will use the old +HSI for now. (4/16) + + The sysgen ran to completion with minor problems. One was the + appearance of the following warning message for every file, regardless + of the fact that none of our code uses any Convex Fortran preprocessor + facilities: + + fpp: WARNING: Use of fpp is being phased out; please update + your program by removing uses of #define, #if, #ifdef + + The second problem, more serious, what that a number of modules failed + to compile due to the IMPLICIT NONE statement being out of order; in + pointer functions, the Mem declarations were being output before the + IMPLICIT NONE (see below). (4/17) + +unix/boot/spp/xpp/decl.c +unix/boot/spp/rpp/rpprat/defs +unix/boot/spp/rpp/rpprat/declco.r +unix/boot/spp/rpp/rppfor/declco.f + 1. In decl.c, deleted the code previously added to generate the + implicit none statement. This is not the right place for it, as it + doesn't work for pointer functions. + 2. In declco.r, added code to output theIMPLICIT NONE immediately + after a function or subroutine statement. + 3. In defs, added a switch IMPNONE, which if defined, causes the + IMPLICIT NONE statements to be output. + 4. Processed the fortran for declco.r and put it in rppfor/declco.f. + The defs and declco.r files were not updated on the Convex; I made + the changes on lyra since this is a generally useful mod, and only + copied the processed Fortran to the Convex. (4/17) + + ... incremental sysgen now in progress... + +[Ran all benchmarks except [24]USER, networking, and IMLOADs. No errors.] +[4/18 SRo] +[Ran all test procedures except magtape i/o; no errors. 4/27 SRo] + +hlib/mkpkg.sf + Added the following files to the special file list, to be compiled + with the old fc compiler, to avoid a fatal bug in the new 4.1 fc. + + sys/imfort/clargs.x + sys/imfort/imemsg.x + sys/imfort/imokwl.x + sys/imfort/impixf.x + sys/imfort/imtypk.x + sys/gio/ncarutil/conlib/congen.f + sys/gio/ncarutil/conran.f + sys/gio/ncarutil/conrec.f + sys/gio/ncarutil/isosrf.f + sys/gio/ncarutil/threed.f + sys/gio/ncarutil/velvct.f + noao/onedspec/t_standard.x + + (5/13 SRo) + +[Relink sysgen to replace the missing executables in bin$ prior to having ] +[a tape cut for mailing to NOAO. (5/13 SRo) ] diff --git a/doc/ports/notes.dsux b/doc/ports/notes.dsux new file mode 100644 index 00000000..0f132092 --- /dev/null +++ b/doc/ports/notes.dsux @@ -0,0 +1,282 @@ +Begin port to DECstation 3100. 23 July 1989. +Start with source only archive of VAX/Ultrix system. +[note - rsh/tar hung up mysteriously while loading files onto decstation, +[and had to be restarted]. +-------------------------- + +unix/as.mips + +unix/bin.mips + + Created AS and BIN directories for Dec/MIPS. (7/23) + +unix/as.mips/zsvjmp.s + Prepared a dummy version of zsvjmp for the moment. All this does is + set the output status value to zero. (prepared by using the compiler + to generate the assembler source for a small C program). (7/23) + +unix/boot/spp/xc.c + It appears that for some reason, the MIPS C compiler or linker will + not accept a file with a .e extension as the output (-o) file. + Had to modify XC to output a .E file temporarily, which is renamed + to .e after the link. (7/23) + +unix/mkpkg.sh +unix/os/mkpkg.sh +unix/shlib/mkpkg.sh +unix/boot/bootlib/mkpkg.sh +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/rpp/mkpkg.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh +unix/boot/xyacc/mkpkg.sh +unix/gdev/sgidev/mkpkg.sh +unix/bin.mips/fixnames + + Modified all the mkpkg.sh files to generate .E files. Added a + fixnames script to bin.mips to rename any .E files therein to .e, + and added code the the root mkpkg.sh to call fixnames at the + end of the bootstrap. (7/23) + +unix/hlib/cl.csh +unix/hlib/mkiraf.csh +unix/hlib/install +unix/hlib/libc/iraf.h + 1. Modified the iraf root pathnames in these files. + 2. In the install, also deleted the entries for edsym.e to avoid + an error message during the install. (7/23) + +unix/hlib/extern.pkg + Commented out the stsdas entries. (7/23) + +unix/hlib/mkpkg.inc +unix/hlib/irafuser.csh +unix/hlib/mkpkg.sf.MIPS + Set MACH to MIPS. Added a case for machine type MIPS. Added an + empty special file list. (7/23) + +unix/hlib/motd + Modified to say DECstation/IRAF. (7/23) + +unix/os/zxwhen.c + Added a #ifdef mips section with some hardware exception codes for + the MIPS. (7/23) + +-------------------- +Start bootstrap. (7/23) + +unix/hlib/irafuser.csh + Linking of RPP produced a "gp relocation out of range" error message. + It was necessary to compile with "-G 0" (no global variables indexed + by global pointer) in order to get this to go away. (7/23) + +unix/boot/bootlib/mkpkg.sh + Modified to mv libboot.a to $hbin (../../bin) rather than $hlib, + since the libboot.a in $hlib is a symbolic link. (7/23) + +-------------------- +Start sysgen. (7/23) + +unix/as/gkiprint.o + +unix/hlib/mkpkg.sf.MIPS + The file gkiprint.x would fail with a slew (like, 700) syntax and + other errors. There was nothing wrong with the code and the few + workarounds I tried had no effect. I finally managed to compile + the file by breaking it up into half a dozen pieces, compiling each + separately, and linking the resultant objects into a single large + object gkiprint.o. Since this bug will probably go away before long + I merely placed the manually generated object file in AS, and made + an entry in the special file list to use this object. (7/23) + +unix/as/imsetr.f + +unix/hlib/mkpkg.sf.MIPS + In this case the file imsetr.f would cause the first pass of f77 + to core dump (not an optimizer problem). I had to hack the fortran + code to workaround the bug, placing the hacked file in AS. The + offending statement was: + + memi(im+33) = and (memi(+33) , not(1 )) + + the following version is ok: + + i = not(1) + memi(im+33) = and (memi(+33) , i) + + The bug must have something to do with the bit intrinsics. (7/23) + +unix/as/fseti.f + # FIO +unix/as/fmfcache.f + # FMIO +unix/as/fmlfbrd.f + +unix/as/fmlfbwr.f + +unix/as/fmlfcopy.f + +unix/as/fmlfundel.f + +unix/hlib/mkpkg.sf.MIPS + Modified to work around the same compiler bug as above. The NOT of + any compile time integer constant used in an expression seems to + always cause a core dump. (7/23) + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + 1. In the first sysgen, x_images.e failed to link with a "gp relocation + out of range" type problem. Recompiling the IMAGES package libpkg.a + with -G 0 fixed the problem. + 2. Passing this flag through XC, however, was not possible without + a code change to XC, as there was no way to pass two consecutive + arguments such as "-G 0". In order to support this XC was modified + to permit flags of the form "-/#flag", which are passed as "flag". + This is similar to "-/flag" which is passed as "-flag", except that + it allows flags with no "-" to be passed. Hokey, but backwards + compatible and it solves the problem. (7/23) + +----------------- +Started sysgen of NOAO packages. (7/23) + +noao/lib/database.o + +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.MIPS + The database.x file in DTOI would cause the compiler to become + terminally confused, as with gkiprint above. Manually constructed + the database.o object, placed the latter in noao$lib, and modified + the NOAO special file list to use this object rather than try to + compile the file. (7/24) + +unix/hlib/config.h +unix/hlib/libc/spp.h + Set the size of the ZDOJMP jump buffer to 84 (83 ints for the jmp_buf + buffer plus 1 for the address of the status variable). (7/24) + +unix/as.mips/zsvjmp.s + Wrote and installed the real zsvjmp.s. (7/24) + +------------------- +Sysgen/relink with new zsvjmp. +Everything appears to work now. (7/24) + +bin.mips +noao/bin.mips + Stripped the BINS to save disk space, as it appeared that the symbol + table information is unusually large on the decstation. (7/25) + + Normal Stripped + + core system bin 21.5 16.0 + noao bin 18.0 12.3 + ------- -------- + 39.5 28.3 + +unix/as/zsvjmp.s + Modified slightly to eliminate a delay slot. This failed to work + at first and I eventually discovered that the reason was that the + *assembler* was modifying my assembler code, reordering the + instructions and inserting nop's in delay slots, producing invalid + code! I had to add a "noreorder" directive to get it to leave the + code alone. (7/25) + +unix/os/zxwhen.c + As a first step in testing exception handling I tried the following + in the CL: + + cl> = 5 / 0 + + This caused the CL to core dump on the uncaught signal SIGTRAP. + On all other unix systems thus far, integer divide by zero has been + mapped to SIGFPE, but on the MIPS it is a trap. Modified zxwhen.c + to map SIGTRAP onto the VOS exception class X_ARITH. (7/25) + +unix/os/zzstrt.c + Added the following #ifdef mips code to zzstrt, to enable the overflow, + invalid, and divzero IEEE exceptions: + + set_fpc_csr (get_fpc_csr() | 07000); + + The {set|get}_fpc_csr() routines appear to be undocumented but I + found them anyhow by searching the symbol tables of the host libraries + in /usr/lib. (7/25) + + [LATER] Well, enabling the IEEE exceptions works, but somehow this + is making the software misbehave in a way I do not yet understand + and do not have time to look into right now. Completely unrelated + things like "stty vt100", "imheader dev$pix" fail mysteriously with + the IEEE trap enable bits set in the FPU context and status register. + This doesn't make any sense and we will have to do without the IEEE + traps for now. Possibly this is due to a bug in the OS which will + go away in the next release. + +unix/hlib/mkfloat.csh + The code in this script which lists the tar archive back with + "tar -tf", to verify that a good archive has been generated before + deleting the files, does not work on the DECstation. The problem + is that tar -tf produces different output here than on the other + systems; the directories are listed as files in addition to the files. + I had to change the + + tar -tf + to + tar -tf | grep -v '/$' + + to get things to work. (7/26) + + +unix/bin.mips +noao/bin.generic +bin.generic + Stripped all the executables (HSI, IRAF, NOAO). + Made IRAF and NOAO generic. (7/26) + + +Summary of various problems encountered. +------------------- + + fortran compiler core dumps + c compiler core dumps + cannot -o to a .e file + rsh|tar hung once + NO ADB!! + dbx dies occasionally with internal error: stack overflow + 2 user limit on logins - prevents even having two windows + open from Sun with a different rlogin session in each. + System is very fast single user; much slower if anything else + is running on the machine (memory too small?). + System crashed on first day of testing with 2 users busy doing things. + (there did not seem to be a system message file). + Some routines which use floating point produce different results on + the MIPS than on other systems. Examples thus far are the FITS + programs, and IMHISTOGRAM. No doubt more will be discovered. + IEEE exception handling is not working currently. + + +---------------- +V2.8BETA system frozen and archived. (7/26) + +---------------- +Begin upgrade to V2.9ALPHA, 6 DEC 1989. +Working with newly arrived IRAF DECstation 3100! + + Installed the V2.8ALPHA HSI. + Merged in all relevant V2.9 modifications to the HSI. + +unix/boot/spp/xc.c + Changed the syntax "-/#foo" -> "foo" to "-//foo" -> "foo" for + escaping command line arguments to XC. (1/6) + +---------------- +Started a bootstap. (1/6) + +mkpkg + Extended the mkpkg summary filter in the root mkpkg to filter out + the great number of "local variable iyy never used" warning messages + produced by the MIPS compiler. (1/6) + +pkg/plot/t_graph.x + This file contained a routine im_projection equivalent to a routine + of the same name in file improject.x, resulting in two externals of + the same name in the package library. (1/7) + +unix/boot/spp/xc.c + To avoid a circular reference problem in the DS3100 Fortran libraries, + which causes an undefined symbols "s_abort" problem when linking some + programs, added a second search of libF77 to the end of the XC host + library link list, after the -lm. (1/7) diff --git a/doc/ports/notes.freebsd b/doc/ports/notes.freebsd new file mode 100644 index 00000000..35cb36e0 --- /dev/null +++ b/doc/ports/notes.freebsd @@ -0,0 +1,215 @@ +FreeBSD/IRAF (PC-IRAF) port +Tue Jul 16 18:38:15 MST 1996 +------------------------------------------------------------------------------- +FreeBSD lepus 2.2-960612-SNAP FreeBSD 2.2-960612-SNAP +Gateway P5-166, 64 MB RAM, 2 GB disk, Matrox MGA, 21" Vivitron +HP DAT, SMC PCI-bus 10 Mb/s Ethernet + +This port to FreeBSD is being done using IRAF V2.11DEVELOP and the Linux HSI. +The goal is to produce a single version of IRAF which can run on both Linux +and FreeBSD, using separate architectures for each. +------------------------------------------------------------------------------- + +mkpkg +noao/mkpkg + Added "freebsd" architecture. (7/16) + +bin.freebsd + +noao/bin.freebsd + + Added "bin.freebsd" bindirs. (7/16) + +unix/hlib/motd + This IRAF release will be called "PC-IRAF" rather than FreeBSD/IRAF, + since the intent is to support all PC-IRAF operating systems as + architectures. (7/16) + +unix/hlib/irafuser.csh + 1. Now supports both Linux and FreeBSD. + 2. Compile flags are -O -DBSD -w -Wunused. + 3. Link flags -static -lcompat. Currently using the compatibility + library -lcompat for rexec (and ftime). BSD doesn't like rexec but + there doesn't appear to be much of any alternative. (7/16) + +unix/hlib/cl.csh +unix/hlib/fc.csh +unix/hlib/install + Modified to autosense the system type and to support both Linux and + FreeBSD. (7/16) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.FBSD + Added support for FreeBSD. (7/16) + +unix/as.freebsd/zsvjmp.s + Using the Linux (i386) version of this file; the only difference is + that the jump point is _setjmp for BSD, ___setjmp for Linux. (7/16) + +unix/os/irafpath.c + Added "freebsd". (7/16) + +unix/os/zfaloc.c +unix/os/zfiobf.c +unix/os/zfioks.c +unix/os/zfiotx.c + Added , lseek type changed to off_t. This appears to be + the new standard. (7/16) + +unix/os/zxwhen.c + Extensive changes/additions for BSD. FreeBSD appears to have fairly + complete exception handling facilities (including the IEEE exceptions). + Linux was weak in this area. (7/16) + +unix/boot/mkpkg/host.c + BSD does not use ELF, but does use ranlib. Symbolic link resolution + appears to be required. (7/16) + +unix/boot/spp/xc.c + Since both BSD and Linux are GNU/F2C-based XC is very similar for + both systems. Minor changes to support FreeBSD, such as adding + -lcompat to the host libraries, and disabling the ELF/aout stuff + except for Linux. (7/16) + +unix/boot/spp/xpp/xppcode.c + Changed "warn" to a static function. BSD has a library function + called warn, caused linker conflicts. (7/16) + +pkg/dataio/fits/fits_wheader.x +pkg/images/filters/median.x +pkg/images/imarith/icscale.x +pkg/images/tv/imexamine/iepos.x +pkg/xtools/gtools/gtcolon.x +pkg/xtools/inlfit/ingresults.gx + Assorted bugs detected at compile time by F2C. (not sure the warnings + are getting disabled). (7/16) + +sys/imfort/bfio.x + In zfaloc, the first arg to strpak was changed from fname (a Fortran + character variable which was incorrect) to sppname. (7/17) + +noao/artdata/lists/stcolon.x + Variable lumfuncs not used. (7/17) + +noao/digiphot/daophot/psf/dpmkpsf.x + dp_addstar called incorrectly. (7/17) + +noao/onedspec/dispcor/dcio.x + Variable axis never used. (7/17) + +noao/onedspec/identify/idshift.x + Function/subroutine confusion. (7/17) + +noao/onedspec/sensfunc/sfoutput.x + Variable axis never used. (7/17) + +noao/onedspec/splot/getimage.x + gt_setr called with an integer value. (7/17) + +noao/onedspec/t_fitprofs.x + pargi called with boolean argument. (7/17) + +noao/rv/rvfgauss.x + A couple of _old varables were declared but never used. (7/17) + +noao/twodspec/apextract/apids.x + Variables ra, dec declared double but used as both pointers and + doubles. (7/17) + +noao/twodspec/longslit/transform/t_transform.x + Variable axis not used. (7/17) + +noao/imred/ccdred/src/t_ccdmask.x + Procedure cm_mask called with wrong arguments. (7/17) + +noao/imred/ccdred/ccdtest/t_mkimage.x + Variable pixtypes not used. (7/17) + +noao/imred/dtoi/hdicfit/hdicebars.x +noao/imred/dtoi/hdicfit/hdicfit.h +noao/imred/dtoi/hdicfit/hdicgfit.x +noao/imred/dtoi/hdicfit/hdicggraph.x + Various type related problems. (7/17) + +dev/hosts + Updated entry for lepus, which is no longer an A/UX system. (7/19) + +unix/boot/mkpkg/host.c +unix/boot/mkpkg/main.c +unix/boot/mkpkg/mkpkg.h +unix/boot/mkpkg/scanlib.c + Various mods to support source code debugging. Mkpkg now supports + the -x flag. If this is seen -x will be added to all flag defines + (XFLAGS, XVFLAGS, LFLAGS). Mkpkg, whenever a library is referenced, + will check for a debug version of the library. For example if the + library is libsys.a the debug version is libsys_p.a. Calling mkpkg + as "mkpkg -x" automatically causes the _p.a versions of all libraries + to be updated, creating them and doing a full recompile if necessary, + without having to edit any mkpkg or mkpkg.inc files to modify the + compile/link flags. The normal and debug versions of all libraries + are maintained independently. (7/20) + +unix/boot/spp/xc.c + XC was also modified to support debugging via the -x switch. Defining + the -x switch causes it to be passed on to xpp, rpp, and f77 which + is necessary to compile for debuging. The -x switch also causes XC + to look for _p.a (debug) versions of any libraries. For example, + if the command line is "-x libpkg.a -lstg" then XC will look for + libpkg_p.a and libstg_p.a, falling back on the normal versions of + the libraries if the debug versions are not found. (7/20) + +unix/hlib/f77.sh + If the -x switch is given the intermediate C file is edited to replace + any "file.f" references with "file.x". (7/20) + +unix/boot/spp/rpp/rpprat/common +unix/boot/spp/rpp/rpprat/errchk.r +unix/boot/spp/rpp/rpprat/initkw.r +unix/boot/spp/rpp/rpprat/outdon.r +unix/boot/spp/rpp/rpprat/ratfor.r + RPP was modified to generate "#line file.x" statements in the output + Fortran code to support source code debugging. This is done only if + the -x flag is set. F2C supports #line but most Fortran compilers + do not. (7/20) + +unix/boot/spp/rpp/rpprat/Makefile + Added a call to sed to workaround a ratfor bug (generates an + unreachable statement). This makes "make fort" fully automatic. + This is used to generate the .f files from the .r files. (7/20) + +-------------------------- +The PC-IRAF (FreeBSD) HSI was erased in a botched rdist update from tucana. +Reloaded from a 3-Sep-96 backup tape. Tue Oct 29 16:05:37 MST 1996 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +-- diff --git a/doc/ports/notes.i386 b/doc/ports/notes.i386 new file mode 100644 index 00000000..0ab05de0 --- /dev/null +++ b/doc/ports/notes.i386 @@ -0,0 +1,1124 @@ +Sun 386i (RoadRunner) Sun/IRAF port. Begin 5 Oct 88. +-------------------------------------------------------- + + o Created the IRAF root directory at /files/vol/iraf in accordance + with the recommendations in the administration guide for 3rd party + software. + + o Moved in a copy of iraf from tucana. + o Installed the SunOS 4.0 mods made earlier on taurus. + +sun/hlib/libc/iraf.h + Manually edited for the new root. + +/etc/fstab +/usr/include/iraf.h + + Installed a symbolic link for iraf.h in /usr/include. In order to + do this on the 386i, I had to remount the /usr file system read-write; + it was read-only at first for some reason. + +unix/bin.i386 + +unix/as.i386 + + Added these directories. "mach" is "i386" on the 386i. + +unix/as.i386/zsvjmp.s + Figured out enough of the 386i assembler to write a stubbed out + zsvjmp routine. Will have to write a real one later. + +unix/sun/Makefile + Changed the float option to -fsingle as for the Sun4. + Added a "-o `mach` = "i386" condition to test for SunOS 4.0. + +------------------------ +Compiled GTERM and IMTOOL. They seem to work!. +Did a bootstrap. Completed normally except that the library scanning code +in MKPKG did not compile, no doubt due to the COFF objects on the 386i. +Did an INSTALL to install the iraf links, GTERM, IMTOOL, etc. + + o Configured /usr/local. + o Reconfigured my .sunview file (used to be .suntools) to use GTERM and + IMTOOL as on the Sun-3; came up ok. + +PROBLEMS + Window refresh is abysmally slow on the 386i. + Perfmeters sometimes core dump and die after running fine for a while. + +unix/hlib/irafuser.csh + Deleted the "-fsoft" entries - not used on the 386i. (10/19) + +unix/boot/mkpkg/scanlib.c + Had to add + + #ifdef i386 + #define PORTAR 1 + #endif + + at the top of the file to get include to define the appropriate + library format. Also, on the 386i, the code which scans the library + has to deal with the following peculiarities: + + o The first "file" in the archive is a dummy entry containing + symbol information; the name field is null, hence the code + can skip this entry by checking for archive members with + null-string names. + + o The names of the archive members now have a trailing /, + e.g., "file.o/", followed by blank padding. Previously + only the blank padding was there. I modified the code to + accept either / or blank as the name delimiter. + + I also added some debug code which prints the name and date of each + archive member as the library is scanned, if debug > 1. These + changes should be portable to other systems. (10/19) + +SUNBUG - f77 + The command "f77 -c -O file.c" produces the following: + + Assembler: /tmp/optim.01231.5.s + aline 1 : Warning: cannot field update- '.file' not + on first line + + This prevents use of f77 to compile C files, at least on the 386i! + (It works if the optimizer is not used). Will have to modify XC to + use CC instead. (10/19) + +unix/boot/spp/xc.c + 1. Hacked XC to use F77 only to compile Fortran source files, and to + use CC for everything else. + 2. Added /usr/local/bin to the list of directories to be searched for + commands like XPP and RPP. + 3. Changed the defined names from "xpp.e" and "rpp.e" to "xpp" and + "rpp", since this is how they appear in /usr/local/bin. (10/19) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.I386 + + Added code for case FPU = i386 (not really an fpu), plus a special + file list for the 386. (10/19) + +unix/hlib/cl.csh + Added a case for the i386, similar to that for sparc. (10/19) + +--------------------- +Sysgen completed with a half a dozen files with errors, but no executables +were linked due to a library conflict with the dummy zsvjmp.s I wrote. (10/20) + +unix/as/zsvjmp.s +unix/as/zzdebug.c + Wrote a ZSVJMP.S for the 386i (80386), plus a little test program to + make sure it works. (10/20) + +--------------------- +Linked x_system.e and it runs on the first attempt!! (10/20) +Start another sysgen - ignore files that didn't compile for now, until we +see which executables they prevent from being linked. + +sys/vops/acht.gx + On the 386i, statements of the form "b[i] = a[i]", where B was + COMPLEX and A was INTEGER*2, revealed a compiler error in the + 386i Fortran compiler (the error was a syntax error in the assembler + code input to the system assembler). I decided that assigning + an integer*2 to a complex in a straight assignment wasn't a very + safe thing to do anyhow, so the generic source was changed to + generate "b[i] = complex(real(a[i]),0.0)" instead, whenever B + is complex and A isn't. (10/20) + +sys/vops/amod.gx + No changes here, just logging the compiler bug. The code is as + follows: + + do 110 i = 1, npix + c(i) = mod (a(i), b(i)) + + where A, B, and C are integer*2. Once again, the compiler is + generating incorrect assembler for this case, causing a "syntax error" + from the assembler (evidently, because of the rather restrictive + instruction set of the 80386). I am not sure there is anything in + IRAF that uses this routine anyhow, so we will try to ignore it for + now. (10/20) + +unix/hlib/mach.h + 1. Set the BYTE_SWAP[24] flags to YES - forgot to do that before the + sysgen, unfortunately. + 2. Changed MAX_EXPONENTD and related variables (MAX_DOUBLE, INDEFD) + to reflect the fact that the max exponent for IEEE double is 2**1023 + or 10**307. (10/21) + +unix/hlib/mkpkg.sf.I386 + Commented out the entries for as$ishift.s for now. (10/21) + +noao/astutil/pdm/pdmstatistics.x pdmstats.x +noao/digiphot/apphot/center/apcentercolon.x apcencolon.x +noao/digiphot/apphot/center/aprefitcenter.x aprefitcen.x +noao/digiphot/apphot/center/apfitcenter.x apfitcen.x +noao/proto/t_mkhistogram.x t_mkhgm.x + Shortened the names of the above source files. These will not compile + on the 386i, which has a limit of 14 characters for the names of + modules in object libraries (which are COFF format libraries from + Sys V, hence the 14 char limit). (10/21) + +unix/hlib/mpkg.sf.I386 + Turned off the optimizer for conrec.f, srface.f, pwrzi.f. An apparent + optimizer bug was causing declaration of an external which would cause + an unsatisfied exernal error at link time. (10/21) + +pkg/images/iminfo/t_imstat.x + Replaced some ==INDEF constructs by IS_INDEF, and took the n=n+1 out + of the inner loop, since it isn't needed. (10/21) + +unix/boot/mkpkg/host.c + Disabled the ranlib (library rebuild) on the 386, since it uses COFF + type libraries, which don't need to be ranlib-ed. (10/21) + +unix/hlib/mach.h + For the moment, restored the former, incorrect for IEEE, values of + the machine constants for type double. There are obviously a number + of bugs in the system where code assumes that the values for types + real and double are the same. This will have to be addressed later + when there is more time to debug this. (10/21) + +unix/hlib/mpkg.sf.I386 +unix/as/amods.s + + Edited the assembler for the VOPS amods routine (to work around the + compiler bug mentioned above) and placed the assembler version in + AS and added the file to the special file list for the 386i. (10/21) + +------------------- + As far as I know, all bugs are now fixed and the system is up on + the 386i, although there is still a lot of work to be done on improving + the installation procedures, optimization to reduce paging, etc. + A full system mkpkg/relink (no compiles) took 23 minutes on the 386i. + (10/21) + +buglog + Cannot access 5!mta, although page 5!dev$devices works. (10/22) + (May be VOS bug not 386i bug?). + +sys/fio/mkpkg +sys/fio/ungetci.x + + Added a new routine UNGETCI to FIO. Since there is an ungetc for getc, + there should be an ungetci for getci. (10/22) + +buglog + The statement + + if (1) + ... + + does NOT result in any errors or warnings from the Fortran compiler. + (10/22) + +unix/hlib/libc/*.h +unix/hlib/irafuser.csh + In order to remove the need to modify anything in /usr (which wants + to be mounted read-only in the latest SunOS), I modified the HSI to + call the C compiler in such a way that $hlib/libc is searched for + include files, as well as the system directories. This is done via + the HSI_CF environment definition in $hlib/irafuser.csh, which adds + $hlib/libc to the list of directories to be searched. The C compiler, + presented with #include , will load $hlib/iraf.h To avoid + having the compiler resolve files like etc. to $hlib/libc + as well, I had to prefix the names of all these files with a "u", + e.g., "ustdio.h", modifing the references in as well. + Since the files are referenced only in , this change should + be completely transparent. (10/23) + +sys/memio/salloc.x + Hard to believe, but it appears that buffers allocated on the stack + are not necessarily aligned to TY_DOUBLE (proper alignment would + result for anything smaller). (10/24) + +unix/boot/spp/xc.c + Added a link time -align mem_ switch to double word (actually page) + align the MEM common. (11/11) + +unix/os/irafpath.c + Added a #ifdef i386 case. (11/14) + +unix/boot/mkpkg/host.c + Added support for IRAFULIB (a user defined private library) to + the $checkout and $checkin directives. For example, in + + $checkout libex.a lib$ + + if file libex.a is found in IRAFULIB, that version is checked out, + rather than the one in the system directory lib$. (11/15) + +------------------------- +Log of changes for the Sun/IRAF shared library facility. This was developed +on the 386i initially. This log was written on 28 December and summarizes the +revisions made during the period Tue 20 Dec to Wed 28 Dec 1988. + +[background] + Although SunOS 4.0 supports dynamic linking, mapped files, and shared + libraries, currently only the C compiler can generate position + independent code (PIC). Sun Fortran does not currently support shared + libraries since it cannot yet generate PIC code. In any case, PIC + code executes less efficiently than nonrelocatable code, and the + dynamic linking required by relocatable shared libraries slows down + process startup. + + Our strategy is to implement the equivalent of a shared library by + building a *nonrelocatable* shareable image (executable process), + and mapping it to a fixed address in the address space of client + processes at process startup time. A transfer vector is used to + vector procedure calls to arbitrary offsets in the shared image, + allowing new shared images to be installed without having to relink + client processes (in most cases). The mapped file feature of SunOS + 4.0 is the only thing essential for this scheme to work, and it is + the lack of the mapped file capability which has prevented us from + implementing a shared library up until now. + + Even when (and if) Sun/Fortran eventually adds support for PIC and + shared libraries, the mapped image approach we have followed here + may still be the best choice. Despite the slight loss of execution + efficiency caused by the use of position independent code, use of + PIC is not likely to be a serious drawback. More serious drawbacks + derive from the use of global data, and dynamic linking at runtime. + Dynamic linking, e.g., to set the address of a global variable for + which the location is not known until runtime, requires the + modification of every text page containing code which references the + variable. Aside from the obvious time penalty during process startup + while this linking and page copying is taking place, modification of + a text page defeats shared text, increasing memory and paging + requirements. + + Trying to avoid this problem in a relocatable shared library can be + very difficult, requiring modification to source code if it can be + done at all. The nonrelocatable approach we have followed guarantees + sharing of the entire text of the shared image and does not require + any changes to system or applications source code (provided no + interfaces have been violated). There are other advantages which + derive from the facility being part of the Sun/IRAF HSI, e.g., if + iraf is linked on an NOAO node and later installed with a different + root on a remote node, there is no problem locating the shared library + at runtime. Furthermore, since our approach requires on the part of + the host system only the ability to map files to fixed addresses, + and the ability to specify the base address of the text segment of + an image at link time, it should be applicable to other (non-Sun) + systems which may provide these capabilities but not shared libraries. + +unix/as.i386/zsvjmp.s + After a little experimentation I found that the .SET assembler macro + could be used to set the value of absolute symbols. This allows MEM + to be located at virtual address 0, making shared libraries possible + for the 386i, and improving assembly level debugging as well. + +unix/shlib/README +unix/shlib/S.nm.i386 external names in 386i shared library +unix/shlib/S.nm.mc68020 external names in Sun-3 shared library +unix/shlib/S.ver.i386 386i shared library version number +unix/shlib/S.ver.mc68020 Sun-3 shared library version number +unix/shlib/Slib.c support code +unix/shlib/aout.c utility to decode a.out format process headers +unix/shlib/coff.c utility to decode COFF format process headers +unix/shlib/edsym.c called by XC to edit symbol table of .e file +unix/shlib/mkpkg mkpkg tie-in +unix/shlib/mkpkg.sh called to boostrap edsym.e +unix/shlib/mkshlib.csh script which does it all +unix/shlib/omit.i386 external names to be excluded from 386i shlib +unix/shlib/omit.mc68020 external names to be excluded from Sun-3 shlib + + This directory contains all the code needed to build and maintain the + shared library. The shell script mkshlib.csh, normally called via + the mkpkg, does all the work. This constructs a name list for the + shared library, generates the assembler required for the transfer + vector modules (V.s and S.s), and links the shared image (S.e). + + When building a new shared library, mkshlib checks to see if any + externals have been deleted from or added to the name list of the + old shared library. If any externals have been deleted, the version + number is incremented and any applications linked with the shared + library will have to be relinked. If there were no changes to the + name list or new externals have been added, then the version number + is not incremented, and existing applications are permitted to use + the new shared image without having to be relinked. The shared image + is linked -Bstatic, meaning that any required host library procedures + are bound at link time. + + Only Fortran or Fortran-like externals are permitted, i.e., exported + from the shared image to the client via the transfer vector. This is + necessary to permit clients to be linked -Bdyamic, allowing use of + the host system shared libraries (otherwise name conflicts would + occur at link time). + + The objects produced by the SHLIB code are libshare.a (the shared + library) and S.e (the shareable image), discussed further below. + +bin/S.e + + The shared image. This gets mapped into the address space of any + process linked with the shared library. It is also a runnable process + in its own right; if run directly, it prints out some information + about itself and exits. The full contents (minus the omitted + externals) of the EX, SYS, VOPS, and OS libraries are currently + linked into this image; other libraries may be added in the future, + e.g., some of the MATH libraries. The transfer vector module V.o, + located at a fixed (absolute) offset in the image, is used to vector + procedure calls from the client process into the shared image. + +lib/libshare.a + The shared library. This contains several object modules, including + a single object S.o consisting of a short header plus a name list + containing all the externals exported by the shared image. Each + external (i.e., VOS procedure such as 'clgeti' etc.) appears in S.o + as an absolute symbol, pointing to a fixed location in the transfer + vector in the shared image. Note that externals appear in S.o only + as symbols, hence no actual executable code gets linked into the + client process. To link with the shared library, XC links with + libshare.a instead of libex.a,libsys.a,libvops.a,libos.a. + +unix/os/zmain.c + The zmain is the main procedure for an iraf process. The first thing + the zmain does now is call ZZSTRT, which is described below. Some + code was moved out of the zmain into ZZSTRT, and all references to + global variables in the kernel had to be eliminated, since the zmain + is no longer linked with the kernel procedures (which are off in the + shared image). Other changes included the addition of calls to ZZSETK + to set the values of the kernel variables, and changes to the calling + sequence of IRAFMN to permit the address of SYSRUK and ONENTRY to be + passed in the argument list, rather than being bound at link time. + +unix/os/zzstrt.c + The function of this procedure, which has been a no-op in UNIX/IRAF + up until now, is to perform any runtime initialization of the kernel. + Currently, ZZSTRT maps and initializes the shared image, sets the + desired IEEE exceptions (partially implemented at present), sets the + process working set soft limits, and sets the default values of the + kernel variables via the new ZZSETK procedure. + + Mapping and initializing the shared image is similar to what unix + does during startup of a normal process. The shared image file is + opened, and the header is read to determine the sizes of the text, + data (initialized data), and bss (unitialized data) segments. + IRAF uses an additional shared image header segment containing the + file header and the FIO common (fiocom), which has to be directly + accessed by the client, making it necessary to locate it at a fixed + address in virtual memory. + + The header segment containing the FIO common is then mapped read-write + private, meaning that if any pages are modified the client gets a + private copy of the page. The text segment of the shared image is + mapped read-only shared. The data segment is mapped read-write + private; pages are shared until modified by the client at runtime. + The BSS segment is then mapped onto an arbitrary file offset (zero) + and promptly zeroed, causing all of the pages to belong to the client. + Finally, the addresses of the unix malloc, realloc, and free procedures + are passed into the shared image (dynamic memory allocation must be + in the data space of the client), and the environment pointer in the + shared image is set to point to the environment of the client, so that + the VOS will see the host environment and command line arguments seen + by the client. + + Both ZMAIN and ZZSTRT are linked directly into each client process, + since they are required to map in and initialize the shared image. + (S.e has its own private copies, of course). + +unix/os/zlocpr.c + ZLOCPR had to be modified to deal with the transfer vector. + The problem is that calls to ZLOCPR in the client image and in the + shared image must return the same value, since equality comparisons + of procedure entry points are are used to determine, e.g., if a + particular file driver is referenced. ZLOCPR was modified to check + if the referenced procedure is actually a transfer vector entry, + returning the address of the actual procedure in the shared image + if so. Since this is a host level procedure, this is done by + disassembling the JMP instruction in the transfer vector. + +unix/os/zshlib.c + + This object contains everything needed to link a process against the + standard libraries, ignoring the shared library. Dummy shared image + descriptors and procedure entry points are defined so that the code + in ZMAIN and ZZSTRT will link properly. At runtime, the startup code + determines that the shared library is not in use, skipping the map and + initialize operations. + +unix/os/zzsetk.c + + This new kernel procedure is used to initialize the values of all the + global kernel variables formerly initialized via EXTERN references in + the zmain. A procedure (with transfer vector) must be used instead + of a series of global data references in order to be able to link + against the shared library. + +unix/boot/spp/xc.c + 1. XC was modified to link against the shared library by default. + The new switch -z (as in VMS/IRAF) is used to link without using + the shared library. Both the shared library and the shared image + may be in an IRAFULIB directory if desired. + + 2. If linking against the shared library, XC will by default call + EDSYM to edit the symbol table of the new executable, renaming the + symbols pointing to transfer vectors by prefixing a "V", and adding + new symbols to point into the shared image to the actual locations + of the VOS procedures referenced by the transfer vector. This provides + symbols for debugging executables that used the shared image. + + New XC switches: + + -e do not call edsym to do symbol editing + -s strip executable (UNIX linker switch; for XC, defeats + call to edsym). + + edsym switches (accepted by XC): + + -d print symbol table + -k do not delete "uninteresting" symbols + -n do not modify any files + -t omit transfer vector symbols to save some space + -T delete all symbols associated with the shared library + + 3. The -align switch, formerly passed to the 386i linker to page + align the MEM common, was deleted since MEM is now assigned to + location zero with a .SET. + +sys/etc/main.x +sys/etc/xmjbuf.x + + 1. The calling sequence of the iraf main was modified to add sys_runtask + (SYSRUK) and onentry (ONENTY) as arguments, allowing a runtime rather + than link time reference. This was necessary for the shared library + since SYSRUK and ONENTY are client symbols but are called by the iraf + main, which is in the shared image. The new scheme is more flexible + in any case. + 2. The new procedure XMJBUF is used to get an XCHAR pointer to the + zsvjmp/zdojmp context vector used by the iraf main for interrupt and + error recovery. Again, a runtime procedural reference using a pointer + is necessary since the global data area cannot be referenced at link + time. The CL uses both a custom onentry and a custom zdojmp context + vector in order to gain full control over command interpretation. + +unix/hlib/libc/libc.h +unix/hlib/libc/knames.h +unix/hlib/libc/xnames.h + 1. In libc.h, the ZJUCOM reference was deleted since the XMJBUF + procedure is now used to access the interpreter context vector. + 2. Entries for the new VOS and kernel procedures were added to + [xk]names.h. + +unix/hlib/irafuser.csh +unix/hlib/mkpkg.inc +mkpkg [at iraf root] + 1. The -z flag (no shared library) was added to the HSI_XF flags in + irafuser.csh, so that HSI executables will not use the shared image. + 2. The mkpkg.inc now includes a switch USE_SHLIB, which if set causes + mkpkg to automatically update the shared library and shared image + during a sysgen. This switch does not actually determine whether the + shared library is *used*, since that is determined by the -z switch + to XC at link time. + 3. For Sun/IRAF, the switch -/Bstatic was added to LFLAGS so that + the iraf executables will be statically linked, rather than using the + SunOS shared library (e.g., libc.a). This was not necessary - there + is no conflict between the iraf and SunOS shared libraries - but was + done to save disk space (see CAVEATS, below). + +unix/mkpkg.sh +unix/shlib/mkpkg.sh + Will build the edsym.e utility and install it in HBIN during a + bootstrap. + +unix/hlib/install + Will make a link for EDSYM in the local/bin directory. + +pkg/cl/main.c + A call to XMJBUF was added to convert to a vectored procedure reference + to the main interpreter context vector. + +sys/gio/cursor/prpsinit.x +sys/gio/cursor/mkpkg +sys/etc/mkpkg +sys/etc/prfindpr.x +sys/etc/propcpr.x +sys/etc/prsignal.x +sys/etc/prfilbuf.x +sys/etc/prgline.x +sys/etc/prupdate.x +sys/etc/prclcpr.x +sys/etc/prstati.x +sys/etc/prredir.x +sys/etc/prgredir.x +sys/etc/prclose.x +sys/etc/proscmd.x [moved from gio/cursor to ETC] +sys/etc/prpsio.x [moved from gio/cursor to ETC] +sys/etc/prc.com [moved from LIB to ETC] +sys/etc/prpsload.x + + Most of the "pr" prefixed files, e.g., PRPSIO, were moved from + gio/cursor to ETC, and the file prc.com (the PR common) was moved + from LIB to ETC, making it a private common. This was necessary + to avoid the global data reference, which would cause the process + control code to fail at runtime due to the client and shared image + having separate copies of the PRC common (another reason to not use + commons!). PRPSIO was modified to use a loadable driver to provide + a runtime technique for linking to the graphics pseudofile i/o + procedures in gio/cursor. In addition to making the shared library + cleaner to implement, this collects all of the process control code + together in one place in the VOS (in ETC - libsys.a), avoids some + circular library references, and makes it possible to use LIBC/stdio + in applications processes without an unresolved linker reference + to PRPSIO (STScI has run into this). + + PRPSINIT is a procedure called by the CL at startup time to load + the gio/cursor graphics pseudofile i/o driver into PRPSIO. + +lib/syserr.h +lib/syserrmsg + A new error SYS_PRPSIOEPA was added, in support of the above + modifications. + +pkg/images/filters/mkpkg +pkg/images/filters/convolve.x +pkg/images/filters/radcnvr.x [used to be called acnvrr.x] + This code contained a routine ACNVRR which redefined a VOPS library + procedure, causing a multiply defined linker error when linking with + the shared library. The offending procedure was renamed CNV_RADCNVR + (radially symmetric convolve, type real). Applications should not + use reserved package prefixes. + +unix/os/zfunc.c + + A set of new kernel primitives ZFUNC1, ZFUNC2, ... ZFUNC9 were added. + These are similar to ZCALL[1-9], but allow calling of functions by + their LOCPR entry point address, as has long been possible with + subroutines and ZCALL. + +CAVEATS - Shared libraries + Several interesting things about SunOS were learned in the process of + implementing the Sun/IRAF shared library. + + 1. Linker Bug. There is a bug in the SunOS linker. The size of the + BSS area is not being computed accurately. For processes with a very + small BSS section, this can lead to a BSS size of zero being computed. + Normally this does not cause a problem, since a small BSS area will + usually fit into the last page of the data area. In some cases, + however, the small BSS area is in an additional page, but since BSS + is zero no BSS area is allocated during process startup, causing a + segmentation violation when the unix code tries to set the value of + the BSS global variable "environ" during process startup. I managed + to avoid this problem by the subtle kludge of adding the following + declaration to the ZZSTRT object (which is linked into every iraf + process): + + int BSS_kludge[256]; + + This provides the process with enough BSS storage (statically allocated + unitialized data space) to avoid having the size of the BSS segment + being set to zero at link time. + + 2. Does using the SunOS shared libraries really save space? + For some reason which I was not able to determine, a small iraf + process linked -Bdyamic (the default, i.e., use the SunOS shared + libraries) always has a text segment of 75-85 Kb, even though the + sum of all the objects therein may be much less. It appears that + the linker may be incorrectly computing the size of the text segment, + causing it to effectively be padded out to a size considerably larger + than what it should be. Linking the process -Bstatic (no SunOS + shared libraries) avoids the bug, yielding a much smaller executable + file, even though more text space is actually required due to the + need to link in modules from the SunOS libraries which would otherwise + be shared. + + 3. Processes with a large BSS segment execute slowly. One thing which + became very clear to me while working on image execution was that + processes with a large BSS segment take a long time to execute. + The reason is that the BSS segment must be zeroed during process + startup. Zeroing a large region of mapped memory involves both the + cpu time required to zero the storage, plus all the mapped file i/o + (paging) required to initialize the mapped swap file pages. This is + not a big deal for processes with a BSS segment in the N*10K region, + but if the BSS is N*100K or N*1000K, then it can take seconds. The + moral is USE DYNAMICALLY RATHER THAN STATICALLY ALLOCATED BUFFERS. + I am going to modify some of the system code as a result of this + lesson, e.g., the CL currently statically allocates about 250K of + combined stack and dictionary buffer space. In applications, BSS + storage is most commonly found as declarations of the form + + char fname[SZ_FNAME] + char line[SZ_LINE] + + and so on. This is of no consequence for small individual programs, + but can add up to a lot of BSS for large packages. The unix "size" + utility may be used to determine the BSS requirements of a process. + +unix/boot/mkpkg/tok.c + An unrelated bug in MKPKG was fixed, which would cause one or the + other of IFOLDER or IFNEWER to fail, when presented with a list of + files to be compared. The bug was that IFOLDER is not equivalent + to !IFNEWER when more than one file must be compared. (12/28) + +unix/as.i386/README +unix/as.i386/aclrb.c +unix/as.i386/aclrc.c +unix/as.i386/bytmov.c +unix/as.i386/aclrs.c +unix/as.i386/aclri.c +unix/as.i386/aclrl.c +unix/as.i386/aclrr.c +unix/as.i386/aclrd.c +unix/as.i386/amovc.c +unix/as.i386/amovs.c +unix/as.i386/amovi.c +unix/as.i386/amovl.c +unix/as.i386/amovr.c +unix/as.i386/amovd.c +unix/hlib/mkpkg.sf.I386 + In an unrelated optimization, the above zero and move procedures + were added to AS. These are written to use calls to the host + BZERO and BCOPY functions to zero or copy blocks of memory, taking + advantage of the special repeat-string-op instructions provided by + the 80386 cpu. (12/28) + +sys/ki/irafks.x + In the open-binary-file code, the fprintf debug message was incorrectly + passing arg1 rather than arg2 as the file access mode. (12/29) + +unix/boot/mkpkg/tok.c + In the $ifeq code, strcmp() would be called with a NULL string pointer + if the referenced environment variable was undefined. (1/2)(1989) + +--------------------- +Moved shared library stuff to tucana (Sun-3) over the period 30Dec-2Jan. +Reworked mkshlib.csh, edsym.c, zzstrt.c etc. for the "a.out" format object +files used on the Sun-3; these are quite different than the Sys V COFF +object format used on the 386i. + +--------------------- +Moved everything back to the 386i, rebuilt the shared library, and relinked +the system. Merged in all recent changes from tucana. (1/3) + +--------------------- +Begin changes to better support layered external software. (1/28) + +unix/os/zgtenv.c +sys/etc/environ.x +sys/etc/envgets.x + ZGTENV, ENVFIND, and ENVGETS were changed to make it possible to + discriminate between undefined environment variables, and variables + that have a null string value. ERR is returned if the variable does + not exist; 0 if exists but has a null value. Since most programs + do a <= 0 test to check for valid environment definitions, this should + be a fairly safe change, although some programs may be affected + (i.e., any program that only does an == 0 test). (1/28) + +sys/libc/cenvget.c +pkg/cl/builtin.c + Minor changes to allow for null valued environment variables. (1/28) + +sys/fio/vfntrans.x + Added a new feature to virtual filename translation, to provide general + environment symbol replacement during translation. This was needed to + support multiple architectures, e.g., different version of the PKG and + LIB directories, but it is a general facility which will be useful + for multiple versions of other types of directories and files as well. + + For example, one might make the following definitions: + + set arch = "" + set bin = iraf$bin(arch)/ + set lib = iraf$lib(arch)/ + + Which become iraf$bin/ and iraf$lib/ by default. If arch is defined + as, for example, ".ffpa", then we have iraf$bin.ffpa/ and likewise + for lib. The default case, where arch is the null string, is what + required the revisions discussed earlier. (1/28) + +----------------- +The following revisions were made all together over a period of a couple +of weeks and summarized on 2/21. + +pkg/system/help/helpdb.x +pkg/system/help/helpdir.x +pkg/system/help/modlist.x +pkg/system/help/modtemp.x +pkg/system/help/prdir.x +pkg/system/help/prfile.x +pkg/system/help/prhlpblk.x +pkg/system/help/prsummary.x +pkg/system/help/t_help.x +pkg/system/help/tlist.x +pkg/system/mkhelpdb.par + 1. The compiled help database files are now stored externally in a + machine independent format. + + 2. HELP now permits multiple compiled help database files. The + parameter / environment variable `helpdb' is now a file template + (e.g., a comma delimited list of files) specifying the helpdb files + to be combined to produce the composite help database to be used + at runtime. HELP takes a little longer to respond the first time + while it is reading and combining all the files, but once the + composite database has been generated in-core all is as it was before. + If any of the helpdb files are modified, or if new files are added, + the incore composite database is automatically regenerated. + + It is still necessary that all package names be unique; this + restriction will be removed in a future implementation but it is + too difficult to fix in the current program. + +dev/help.db - +lib/helpdb.mip + + The old core sytem help database file dev$help.db has been deleted + and replaced by the new machine independent file lib$helpdb.mip, + which now contains only entries for core system help modules. + Each external layered package (noao, local, stsdas, etc.) will + have its own lib/helpdb.mip. + +mkpkg + 1. All references to the noao and local packages have been removed + from the root mkpkg file. Layered packages are maintained + independently of the core system and separate mkpkg sysgens, + etc, are required for each package. + 2. The `stripall' entry has been deleted leaving only `mkpkg strip' + for stripping the system. + +noao/README + Completely new README for the reorganized NOAO package. + +noao/bin + +noao/bin.i386 + + NOAO now has its own BIN directory. For Sun/IRAF, `bin' is a + symbolic link to the bin directory for the architecture for which + the system is currently configured, bin.i386 on my development + system. + +noao/lib/helpdb.mip + compiled help database +noao/lib/mkpkg.inc + global mkpkg definitions for noao +noao/lib/mkpkg.sf.I386 + special file lists for various architectures +noao/lib/mkpkg.sf.SUN3 + " +noao/lib/mkpkg.sf.SUN4 + " +noao/lib/root.hd + root help directory for the noao packages +noao/lib/strip.noao + stripper file for the noao directories + + The above files were added to noao$lib, the global library for the + NOAO packages. All files are maintained in a machine independent + format and may be included in distributions. Files like the mkpkg.* + include machine dependent information but are easily modified or + extended to support new architectures - there is no better way, + one must have things like special file lists for different + architectures (if there isn't one, as in a new port, the application + will still sysgen but there is a real possibility of undetected + compiler bugs). + + The helpdb.mip is machine independent as well, and should be generated + by the developers of an exportable package, and included in the + distribution. The ".mip" extension tells the HSI utilities such as + WTAR that it is a machine independent file and can be included in + "source only" archives. It can be generated under V2.8 with a command + such as + + cl> mkhelpdb helpdir=noao$lib/root.hd helpdb=noao$lib/helpdb.mip + + By default, MKHELPDB will generate the core system help database. + +noao/mkpkg + Added a `mkpkg strip' entry. Other entries will need to be added + in the future to support multiple architecture switching for Sun/IRAF. + +noao/noao.cl + Added the following lines to the noao.cl file: + + set noaobin = "noao$bin(arch)/" + package noao, bin = noaobin$ + + The bin= argument to package is required to tell the CL that noao + has its own bin directory and is discussed below. The `noaobin' + definition permits user redefinition of the noao BIN directory, + as well as specification of the architecture for all packages + via the environment variable `arch', which is defined in terms + of `mach', which defines the machine architecture. + +pkg/cl/bkg.c +pkg/cl/builtin.c +pkg/cl/exec.c +pkg/cl/main.c +pkg/cl/prcache.c +pkg/cl/task.c +pkg/cl/task.h + The CL was modified to generalize the BIN directory scheme. Formerly + executables could be stored either in the package directory or in BIN. + The same is true now except that there can be multiple BIN directories. + By default bin is iraf$bin/. This may be overridden for a package by + specifying the package bin directory with a bin=bindir argument to + the PACKAGE directive (see example above). The new bin will be used + for the referenced package and all subpackages of that package, unless + overridden by another PACKAGE directive. Note that no bin-path + searching is involved; the CL never has more than two directories to + look in for a given executable, since every package has a well defined, + unique BIN directory. + +sys/etc/envgets.x +sys/etc/environ.h +sys/etc/environ.x +sys/etc/envscan.x + 1. ENVFIND will now return ERR if the named variable does not exist, + and a string length of zero if the variable exists but has a null + string value. + 2. ENVSCAN now permits newline to be escaped in the value field, + permitting arbitrarily long value strings. Leading whitespace is + discarded in each continuation line, allowing continuation text to + be left justified at any arbitrary column for readibility. + 3. ENVSCAN recognizes both SET and RESET. + 4. ENVSCAN now supports the "set @filename" syntax for inclusion + of other files containing set environment definitions. All non + set or reset statements are ignored. + 5. The max size value string is increased to 512 chars. + + All of these changes hold also for the HSI version of ENVSCAN + (see the bootlib.envinit.c notes below). + +sys/fio/vfntrans.x + General environment variable replacement is now supported within + virtual filenames via the syntax "(envvar)", which is replaced + by the value of the named environment variable "envvar". This is + different from logical directory replacement which replaces + everything to the left of the $. (Perhaps we should have simply + used the unix symbol replacement syntax in the first place, but + it is too late to change now). For example, + + set mach = f68881 + set arch = .(mach) + set bin = iraf$bin(arch)/ + + This point of this facility is that it allows any field of a filename + to be parameterized with an environment variable. If the named + variable does not exist the null string is used. + +sys/imio/iki/ikiopen.x +sys/libc/cenvget.c + Replaced an "envfind() == 0" by "envfind() <= 0" to reflect the fact + that ENVFIND can now return a negative value. + +unix/boot/bootlib/mkpkg +unix/boot/bootlib/bootlib.h +unix/boot/bootlib/osfn2vfn.c +unix/boot/bootlib/vfn2osfn.c + The UNIX/IRAF HSI has been modified to use VOS filename mapping, + to facilitate use of the zzsetenv.def and extern.pkg logical directory + definitions, as well as all the other semantics of general filename + mapping. Note that this requires use of libsys.a (etc.), but it + was done in such a way that if the library does not exist, bootstrap + filename mapping is used. VOS filename mapping is used only if the + environment variable NOVOS is not defined at HSI bootstrap time; this + variable is defined in the file hlib$irafuser.csh which is assumed + to be referenced at login time by the account of whoever is doing + the bootstrap (normally user iraf). + + A true bootstrap is performed with VOS filename mapping disabled, + and then repeated once a sysgen has been performed to generate the + VOS system libraries. The HSI bootstrap filename mapping facilites + are adequate to compile the VOS but do not support external layered + packages. + +unix/boot/bootlib/envinit.c + This routine is used by the HSI to read the zzsetenv.def file. + This cannot be done with the VOS, even when VOS filename mapping + is in use, because the VOS routine envscan uses FIO (the filename + mapping primitives are much lower level, being layered on the kernel). + I made all the same changes as for ENVSCAN above, so that the + environment variables defined in hlib$extern.pkg will be defined + in the HSI. + +unix/boot/bootlib/osfpathname.c + 1. Modified to avoid the null filename bug that appeared in VMS/IRAF + long ago (VMS/IRAF also uses VOS filename mapping). + 2. Fixed a second bug that would probably only affect UNIX/IRAF. + The filename ".." was not being mapped properly on UNIX/IRAF, whereas + it worked fine on VMS/IRAF. This was because on UNIX/IRAF the call + to vfn2osfn to translate the ".." to the pathname of the previous + directory, whereas on VMS/IRAF all it would do is pass it on, to be + used in the later call to ZFSUBD. + +unix/boot/bootlib/ossysfile.c + Added support for an applications defined system library search path, + e.g., for XC command line -llib library references, or global + include file references. LIB, HLIB, and any other system libraries + are searched first, followed by any package libraries as specified + by the environment variable `pkglibs'. The latter is defined in + extern.pkg and this mechanism is intended as a way of extending the + global library mechanism to support applications libraries. There is + a flaw - a search path opens the possibility of file name collisions, + resulting in the wrong file being used. At least this will be obvious + if it occurs, and the search path is the simplest mechanism in this + case. + + This HSI level library search path mechanism should not be confused + with the IRAFULIB facility used in UNIX/IRAF. Any IRAFULIB directories + are searched *before* the system libraries, allowing custom versions + of system library files for testing or development purposes. In the + case of the `pkglibs' the system libraries are searched first, with the + full search order being the IRAFULIBs, followed by the system libraries + (LIB, HLIB, and also BIN, bin.`mach` etc. for Sun/IRAF), and lastly + the package libraries in the order in which they appear in pkglibs. + There should be minimal execution time penalty from adding pkglibs + searching, since most global file references will be satisfied early + in the search by a system library. + +unix/boot/bootlib/osgetenv.c + Added VOS and NOVOS cases. The VOS case calls ENVFIND to lookup + environment names. This is required to make the environment used + for VOS filename mapping available in the HSI utilities, e.g., + in mkpkg. + +unix/boot/mkpkg/mkpkg +unix/boot/generic/mkpkg.sh +unix/boot/mkpkg/mkpkg.sh +unix/boot/rmbin/mkpkg.sh +unix/boot/rmfiles/mkpkg.sh +unix/boot/rtar/mkpkg.sh +unix/boot/spp/mkpkg.sh +unix/boot/spp/mkxc.sh +unix/boot/spp/xpp/mkpkg.sh +unix/boot/wtar/mkpkg.sh + All these files had to be modified to parameterize the list of + libraries to be used to link HSI executables. Formerly libboot + and libos were being referenced explicitly, but now that the HSI + can be linked either VOS or NOVOS, the list can also include + libsys and libvops. The parameter is the unix environment variable + HSI_LIBS defined in hlib$irafuser.csh. + +unix/hlib/clpackage.cl +unix/hlib/clpackage.hd + Removed all references to local, noao, and stsdas. External packages + now have their own root help directories and help database files, so + no entry in the clpackage.hd is required. The external packages are + picked up by clpackage.cl by the following statements: + + # Define the external (user-configurable) packages. + cl < hlib$extern.pkg + + which executes the TASK statements in the extern.pkg to define the + external packages. The environment variables in extern.pkg will + already have been defined by the zzsetenv.def @extern.pkg include, + so they are reset harmlessly when extern.pkg is reinterpreted by + the CL. + +unix/hlib/extern.pkg + +unix/hlib/zzsetenv.def + 1. Removed all references to noao, local, and stsdas from zzsetenv.def, + replacing these by the statement + + set @hlib$extern.pkg + + which includes set (actually reset) statements defining the root + directory of each external package. + + For HELP, deleted the entries for helpdir and helpdb. The helpdir + environment variable is no longer used, and helpdb has been moved + to extern.pkg. + + 2. Added the file hlib$extern.pkg, which is the sole link between the + core system and external packages. To install an external package, + ALL that should be required is to make an entry in this file, after + reading the files onto disk (a mkpkg at the package root will also + be required if the package is distributed in source only form). + To deinstall a package, all one need do is comment out or delete + the related entries in extern.pkg, and backup and delete the external + package directory tree. The core iraf system can be updated without + affecting external packages. + + These things are possible ONLY if we strictly localize package files + to package trees, i.e., do not install library files and executables + from an external package in core system directories, do not rebuild + a central help database file, etc. A further major advantage for + NOAO is that we can easily maintain private LOCAL packages, have + STSDAS on disk for our users, etc., without making modifications to + our export systems which would affect our distribution tapes. + By localizing the changes required to interface an external package + to a single file, we need only replace that one file to make a + distribution tape from one of our master systems. + + For software maintenance purposes, developers should assume that ONLY + the root directory of their package tree is globally defined in the + HSI, and use only references such as "noao$lib/", "-llib", or + "" in their applications (any VOS pathname relative to the + package root is acceptable). Note that a package global library + may be set up by adding the path of the library directory (e.g., + "noao$lib/") to the `pkglibs' entry in the extern.pkg. + + Additional logical directories may be defined in the global package + mkpkg.inc and used in mkpkg files, but these logical directory names + will not be propagated to XC hence cannot be used in include file + references etc. Additional environment variables could in principle + be added to the entry for the package in the extern.pkg, but I would + like to keep the interface as small as possible, localizing all + package information in the package itself as far as possible. + + VMS/IRAF users should note that since XC executes in the context of + MKPKG in VMS/IRAF, mkpkg definitions may be propagated to XC (I + haven't tested this), but to make use of this side effect of how XC + is implemented in VMS/IRAF would be nonportable. + +unix/hlib/gripes.cl +unix/hlib/gripesfile- + Commented out the code which appends gripes to the gripesfile, and + deleted the gripesfile. We will use only electronic mail to enter + gripes from here on. + +unix/hlib/irafuser.csh + 1. Added NOVOS and HSI_LIBS entries to define whether or not VOS file + name mapping is to be used in the HSI, and to list the libraries + to be searched to link HSI executables. If libsys.a does not exist + NOVOS is automatically set, hence bootstrapping UNIX/IRAF on a source + only system will automatically generate the HSI without the VOS. + Redoing the bootstrap once the VOS is compiled will cause the HSI + to be rebuilt with VOS filename mapping, as may be required to compile + any external packages (the core system does not require VOS filename + mapping in the HSI). + + 2. Added a couple of utility command aliases. `mkv' runs mkpkg with + the link flags set in such a way that the resultant executable has + symbols for the transfer vector entries. This is necessary to be + able to see what VOS routines are being called from an application + when debugging (otherwise one sees an offset from vshlib_). Perhaps + I should make this the default on our development system, even though + it almost doubles the size of the symbol table in each executable. + + A second utility definition `mkz' runs mkpkg, linking without the + shared library (like xc -z). These name may change but they should + serve to illustrate how to use the linker options for debugging. + +unix/hlib/libc/knames.h + Made several new entries. + +unix/hlib/login.cl + Added commented out commands to load the `noao' and `tv' packages. + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.I386 +unix/hlib/mkpkg.sf.OS4 +unix/hlib/mkpkg.sf.S34 +unix/hlib/mkpkg.sf.SUN3 + 1. In the mkpkg.inc, changed the FPU definition to MACH, since FPU + is too restrictive a name for what we use this switch for; MACH for + machine architecture comes closer. Possible values of MACH are + f68881, ffpa etc. for Sun-3 hardware options, sparc for the Sun-4, + i386 for the Sun-386, vax for the VAX, and so on. This switch is + used to select default compile and link flags, determine which + special file list to load, etc., allowing the generation of relatively + machine independent mkpkg definition files. + +unix/hlib/strip.iraf + 1. Changed the name from stripper to strip.iraf (strip.noao etc. for + other packages.). Deleted the stripall since I have never been happy + with what that level of stripping anyhow. Still need to review the + action of the strip file to ensure that everything that can be deleted + is being deleted, to add something to strip executables on unix + systems, and so on. + 2. Deleted all entries for the noao and local packages. These packages + now have their own strip files. + +unix/os/zfacss.c + Modified to test for the null filename and return NO in that case. + +unix/os/zgtenv.c + Will now return ERR for a undefined variable, and 0 for a defined + variable with a null string value. + +unix/os/zmain.c +unix/os/zshlib.c [DEBUGGING POINTER] +unix/os/zzstrt.c + Added a new command line switch "-w" to the zmain. Currently this is + only used in Sun/IRAF. Specifying -w causes the shared image text to + be mapped with write permission, allowing breakpoints to be set in + VOS routines. This cannot be done by default because one has to + reserve swap space for the entire shared image text segment in order + to have write (copy on modify) permission. + +unix/shlib/mkpkg + Fixed a bug in the code used to delete old versions of the S.e shared + image files in BIN. + +--------- (end of accumulated notes) ------------ diff --git a/doc/ports/notes.irix b/doc/ports/notes.irix new file mode 100644 index 00000000..487d3093 --- /dev/null +++ b/doc/ports/notes.irix @@ -0,0 +1,158 @@ +Begin IRIX/IRAF port/upgrade. +Thu May 30 13:31:15 MST 1996 +------------------------------------------------------------------------------ +Host - almond (WIYN remote observing host) +IRIX almond 5.3 11091812 IP22 mips +150 Mhz MIPS R4400 +64 Mb RAM +Indy 8-bit +Vino video +A2 Audio Processor +IRIX 5.3 + +Graphics board 0 is "NG1" graphics. + Managed (":0.0") 1280x1024 + 8 bitplanes, NG1 revision 3, REX3 revision B, VC2 revision A + MC revision C, xmap9 revision A, cmap revision C, bt445 revision A + Display 1280x1024 @ 72Hz, monitor id 2 + +Note - use "iiv" to view CD-ROM documentation. +------------------------------------------------------------------------------ +The following are notes from the IRIX 5.3 port, which was done mostly during +June 1-2 1996. Sun Jul 7 13:01:50 MST 1996 + +./local/notes.irix + + +./local/.4Dwmrc +./local/.cshrc +./local/.exrc +./local/.login + Customized for IRIX. This includes a workable desktop via .4Dwmrc. + +./unix/hlib/extern.pkg + Minimal package list for the port. + +./unix/hlib/install + Changed "mach" (the HSI machine type) from ssol to irix. + +./unix/hlib/irafuser.csh + 1. MACH is generated from uname differently than for Solaris. + 2. IRIX/IRAF compile flags are -/DSYSV -/DSOLARIS. + 3. IRIX/IRAF link flags are -lelf -lfpe. + 4. No -Bstatic flag for IRIX. + +./unix/hlib/login.cl + FC calls XC directly in the conventional manner rather than using + hlib$fc.csh. + +./unix/hlib/mkiraf.csh +./unix/hlib/mkpkg.inc +./unix/hlib/motd + Minor customization. + +./unix/hlib/mkpkg.sf.IRIX + + Pretty standard, did need to increase size of compiler tables for + fmtio$evvexpr.x and cl$ytab.c. + +./unix/os/irafpath.c + Added "irix" for #ifdef sgi. + +./unix/os/mkpkg +./unix/os/mkpkg.sh + Deleted enbint.s (a solaris special routine). + Modified to use $CC to compile the assembler files, as we have done + recently on other platforms (allows compile flags to be used). + +./unix/os/zawset.c + Minor compile time customization (nuke solaris #define RLIMIT_RSS + RLIMIT_VMEM). Poking arount it appears that IRIX handles the + set/getrlimit stuff ok. + +./unix/os/zxwhen.c + The error handler code was remarkably similar to Solaris (i.e. SYSV + I suppose), down to the codes for the arithmetic exceptions. All I + had to change was a sigaction structure definition: solaris uses + sig.sa_sigaction, IRIX uses sig.sa_handler. + +./unix/os/zzstrt.c + Include for IRIX. + The IEEE exception handling initialization for this platform consists + of: + + > sigfpe_[_UNDERFL].repls = _ZERO; + > handle_sigfpes (_ON, _EN_OVERFL|_EN_DIVZERO |_EN_INVALID, + > 0, _ABORT_ON_ERROR, 0); + + This enables exceptions for overflow, divide by zero, and invalid + operand. It is also supposed to be possible to arrange for things + to underflow to zero, however it is not clear if it is possible to + do this without enabling the underflow exception. I didn't have + time to look into it further, and the system passes all tests with + the underflow handling disabled. + +./unix/as.irix/zsvjmp.s + The DECstation (MIPS) version works also for IRIX - the SGI of course + uses a MIPS chip. + Checked size of SETJMP/ZSVJMP buffer; the Solaris value is larger than + needed for IRIX so I left it unchanged. + +./unix/boot/mkpkg/host.c + The ELF library code for solaris works fine for IRIX too. The only + problem encountered was that during library updates the link mkpkg + creates to the actual library would be clobbered by the updated + library file which would subsequently be deleted, causing the mkpkg + to be a no-op. Linux/IRAF had the same problem so I merged in the + "resolvefname" code from Linux/IRAF. This takes a library name and + checks to see if it is a link and keeps this up until a fully + resolved filename is obtained. This is then used to perform the AR + updates. + +./unix/boot/spp/xc.c + Sysbindir (default compiler location) is /usr/bin. + System libraries are the conventional U77,F77,I77,U77, plus fpe, isam. + Implemented the -// syntax for passing on host switch arguments. + +./unix/boot/spp/xpp/xppcode.c + Had to declare errflag an external. + +./unix/gdev/sgidev/sgi2uapl.c +./unix/gdev/sgidev/sgi2uhpgl.c +./unix/gdev/sgidev/sgi2uimp.c +./unix/gdev/sgidev/sgi2uqms.c + Various local variables named "sgi" caused problems here. Changed + the names to "sgip". + +./dev/hosts + Replaced with newer version. + +./dev/pix.imh + Someone modified this on Tue 17:56:52 04-Jun-96. I don't know who or + why, but the image appears the same. + +./dev/tapecap + Modified for IRIX 5.3. The default configuration should provide + variable block size support ("v" in device name) so long as the + host level support for the device permits it. See "man tps" for + information on the IRIX SCSI tape driver. + +./pkg/cl/globals.c +./pkg/cl/grammar.h + Added global declarations for parse_state, proc_script, parse_pfile, + and changed the declarations in grammar.h to extern. + +./unix/boot/spp/xc.c.NOSHARE +./unix/shlib/README +./unix/shlib/mkpkg +./unix/shlib/mkshlib.csh +./unix/shlib/so_locations + The shared library code in IRIX looked remarkably similar to that in + DEC Alpha OSF/1 (including quickstart etc.) so I did an experiment + to implement shared libraries for IRIX/IRAF. This pretty much worked, + but I had to set it aside due to some obscure runtime error occurring + during process startup, which I didn't have time to investigate. + The code is still there in case we get time to go back and look into + this further. + +------------------------------ +Fri Jul 5 18:04:26 MST 1996 +IRIX/IRAF distribution built. diff --git a/doc/ports/notes.linux b/doc/ports/notes.linux new file mode 100644 index 00000000..241dc3b0 --- /dev/null +++ b/doc/ports/notes.linux @@ -0,0 +1,325 @@ +Begin Sat Apr 29 21:05:25 MST 1995 Linux 1.1.93. +Files actually set up initially last weekend. +----------------------------------------------------- + +unix/hlib/irafuser.csh MACH is "linux", architecture is "linux" compiler is + GCC. Set up generic compile and link flags for the moment. (4/23) + +unix/hlib/mach.h + x86 boxes are little-endian so all the SWAP flags are set to YES + on this platform. (4/23) + +unix/os/mkpkg.sh + 1. Was using HSI_LIBS to link alloc.e, but the iraf libraries are not + used in this file. Changed to use HSI_OSLIBS instead. + 2. Deleted the reference to as$enbint.s, not used for Linux. (4/29) + +(linux) + 1. After booting typing "cd unix", which uses cdpath to go to + $iraf/unix, would hang the xterm. The problem went away following + a reboot. + 2. Got a bunch of failures to compile when doing a reboot of the + HSI, no apparent reason (message said couldn't write .o files). + Started another reboot and the problem went away. + 3. Manpages can be very brief and do not fully specify system or + library routines. + 4. Problems with cut and past, not resolved. + +unix/os/zfiomt.c + The structure "mtpos" used in this file redefines a different + structure defined in . Changed zfiomt.c to use _mtpos + for its internal structure. (4/30) + +unix/os/zfiomt.c + Linux doesn't have SIGEMT. Changed to use SIGABRT. (4/30) + +unix/os/mkpkg + Commented out enbinit.s. (4/30) + +unix/boot/gdev/sgidev/sgi2uapl.c + Added a #undef SOLARIS to cause the routine to use gethostname() + rather than sysinfo which is implemented differently in Solaris + and Linux. (4/30) + +unix/hlib/install + Minor changes for Linux. (4/30) + +unix/hlib/motd + Modified for Linux/IRAF V2.10.4BETA. (4/30) + +unix/boot/mkpkg/host.c + Added #undefs for SYSV and i386 to cause this code to use ranlib. + (4/30) + +---------------------------------------------- +Completed HSI bootstrap. (4/30) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.LINUX + + Modified mkpkg.inc for Linux, no compile/link flags of note yet at + this point. Add a base special file list for Linux, currently only + references the C files in AS. (4/30) + +unix/boot/spp/xc.c + Modified the code which compiles "other" files (not .x or .f) to + explicitly compile only .c and .s files. This prevents unrecognized + command line flags from confusing the code and causing a command to + be issued that contains nothing to be compiled. (5/03) + +(linux) + Another Linux oddity with libraries: on linking the CL _zawrim_ would + always come up undefined, even though an "ar tv" of libds.a showed + it looked fine. Deleting zawrim.o and updating the library made the + problem go away. (5/03) + +unix/os/zfiond.c + Added a #include , needed to pick up the FD_SET etc. + definitions on Linux. (5/03) + +unix/as.linux/ieee.gx + Installed the little-endian version (from OSF/1). F2C complained + about statements following DATA so I had to rearrange the code in + ieemap$t a bit. (5/03) + +unix/hlib/cl.csh +unix/hlib/fc.csh + Deleted the uname stuff and just fixed MACH=linux. Added linux + case code where needed. (5/03) + + +unix/as.linux/zsvjmp.s + I had to change the reference to `__setjmp' to `___setjmp' (3 under- + scores) to get the routine to call the function `__setjmp'. (5/03) + +unix/os/zawset.c +unix/hlib/libc/kernel.h + Installed the zawset (begmem) changes from tucana. (5/03) + + +Begin Sat Jul 22 20:24:16 MST 1995 +The Linux port was set aside for a time while IRAF V2.10.4 was prepared +and our Linux system was upgraded to Slackware 2.3 and Linux 1.2.11. +The port is being redone using Solaris/IRAF V2.10.4. The above revisions +will be merged before we resume taking notes. +--------------------------------------------------------------------------- + +unix/hlib/spy.cl + Added a Linux clause and set this to use "ps -axuf" for Linux. The + "-f" option provides a parent/child ordering similar to sps. (7/22) + +unis/os/zawset.c + Added an ifdef for Linux to cause it to uset {set|get}rlimit. (7/22) + +unix/os/zgtime.c + Modified to use CLK_TCK (100 Hz), as on Solaris. (7/22) + +unix/os/zpanic.c + Use SIGABRT on Linux rather than SIGEMT, which doesn't exist. + The Linux documentation doesn't specify which signals cannot be + caught, hopefully ABRT will do it. (7/22) + +unix/boot/mkpkg/host.c + Linux uses the GNU "ar" to maintain object libraries. This turns out + to have a bug which prevents it from properly updating a library which + is a symbolic link to the actual library. The library is updated in + the current directory, and the symbolic link is replaced by the + updated library, hence the actual (remote) library is never updated. + To work around this a new internal function "resolvefname" was added + to host.c This back traces any symbolic links and returns a fully + resolved library name. (7/24) + +unix/os/zxwhen.c + I noticed during testing that when interrupting the cl or a task + run stand alone, while waiting for command input, that following + the interrupt processing the most recent block of input would be + reread and executed. Evidently what happens is that Linux stdio + partially initializes the stdin file descriptor before the read, + and then never finishes initializing it since the read is interrupted + and never returns (in other words no critical section protection for + stdio). The workaround was to extend the fcancel() macro in zxwhen + to reset both the input and output buffer pointers, and add a fcancel + for stdin to the error handler to cancel the input buffer if an + interrupt occurs. (7/24) + +unix/os/zzstrt.c +unix/os/zxwhen.c + These routines were further modified to implement exception handling + for Linux. This turned out to be hard to do properly as about all + Linux provides is a simple signal() interface. + + 1. The first problem was that interrupts were being disabled after + the first interrupt, as signals are "one-shot" by default. The fix + here was to re-register the signal handler after each signal, and + to reinitialize the FPU control register during process startup and + during exception recovery. + + 2. After getting some Intel hardware manuals and some time digging + around in the Linux kernel to see how signals are handled I finally + found that the kernel pushes a frame on the stack before entering the + user exception handler. The EBP register can be used to get the + address of this frame. This frame describes the cpu state at the + time that the exception occurred and includes the hardware trap + number. This is sufficient to identify all system traps but only + identifies floating point exceptions to the coprocessor trap level. + The floating point unit status register has been cleared by the time + the user exception handler is entered and so far I haven't discovered + how to differentiate the floating point exceptions, but at least + things like the integer divide by zero and overflow exceptions are + properly diagnosed. The kernel is saving the information on the + FPU status internally, but so far I haven't found out how to access + this information from the application. (7/29) + +unix/boot/spp/xc.c + The f77 command on Linux, which is a shell script based on F2C, + erroneously returns an exit status of 4 when successfully compiling + a Fortran file. This would cause commands such as "xc foo.x" to + fail to link the output program thinking that the compilation had + abort on an error. To workaround this bug XC was modified to ignore + an exit status of 4 when calling f77 under Linux. (7/30) + +unix/os/zgcmdl.c + Linux also uses xargc,xargv. (7/30) + +dev/termcap + Added "lp" alias for "lpr", as used in zzsetenv.def. (7/30) + +------------------------- +Downloaded and built TABLES without incident. (8/01) +Built NOAO packages without incident. (8/01) + +unix/os/zmain.c + Changed the call to exit() to _exit() for Linux. I was having trouble + with tasks in NOAO and TABLES doing horrible things during process + shutdown (hanging up the console for minutes with the disk thrashing + heavily, or doing a panic shutdown). Although I did not check it out + fully, this appeared to be due to an "onexit" feature of the GNU exit() calling + calling random parts of process memory with essentially unpredicable + results. The simplest solution was to simply use _exit instead, which + avoids this feature. (8/01) + +unix/hlib/f77.sh + + Copied the default "f77" script that comes with Linux to $hlib/f77.sh. + The script was modified to eliminate the "f2ctmp_" prefix that it was + prepending to Fortran file names before compiling with GCC. This + feature (used by the script to implement Fortran includes) breaks + source code debugging since the file which is actually compiled has + the f2ctmp prefix and this file no longer exists after compilation. + This fix also eliminated the "exit 4" problem mentioned above in the + xc.c fix. (8/02) + +unix/boot/spp/xc.c + Modified XC to use the f77.sh script as the Fortran compiler, instead + of "f77". It will still fall back and use f77 if it can't find + f77.sh. (8/02) + +unix/hlib/f77.sh + 1. Modified so that the -w flag inhibits warning messages from both f2c + and gcc. This is necessary to get rid of a few warning messages seen + when compiling the IRAF code which do not indicate any real problems. + 2. Added a call to sed in the f2c call to workaround a bug in f2c + where -w fails to strip out all the lines of a multiline warning + message. (8/02) + +----------------- +Wed Aug 16 13:00:13 MST 1995 +System has been in testing since last thursday. + +dev/tapecap + Modified this file for Linux. Linux has a nice tape interface + supporting variable block sizes, behavior is very standard, however + there is no support for compression or any non-generic tape features, + and the default maximum block size on a read is 32K. (8/15) + +local/ + Installed a Linux specific set of startup files for the IRAF + account. (8/24) + +mkpkg +noao/mkpkg + Added "linux" targets. (8/28) + +unix/hlib/irafuser.csh + Added "-static" to the link flags for the HSI. (8/28) + +unix/os/zfiotx.c + Added #ifdef LINUX code in a couple of places to cancel the input + stream if an interrupt occurs (workaround for same bug as in zxwhen + above). (9/02) + +--------------------------------------- +Installed V2.10.4 patch1. Bootstrap, sysgen-update. (9/02) + +unix/hlib/install + Added "chmod -t /tmp" to allow multiuser deletion of files, e.g. + magtape lock files, in /tmp. (9/03) + +local/* + Configured the login files for the IRAF account, including setting + up the window system. Installed gzexe-compressed binaries for xgterm, + ximtool, and the tin newsreader in $iraf/local/bin. Set up window + system to start up by default 5 seconds after logging in, using fvwm + as the window manager. An "ADASS news" entry in the root menu accesses + the ADASS news using the tin executable provided. (9/03) + +unix/boot/bootlib/osfiletype.c + Added ".gz" to the list of source file types. (9/03) + +doc/rev2.hlp + Renamed this file to rev2.txt, it is not a help file. (9/03) + +unix/hlib/strip.iraf +noao/lib/strip.noao + Various minor enhancements and updates. (9/03) + +bin.linuz + +noao.bin.linuz + +unix/hlib/cl.csh +mkpkg +noao/mkpkg + Added a new architecture "linuz", which is a gzexe (gzip compressed) + version of bin.linux. (9/03) + +---------------------------------------------------------------- +V2.10.4 Linux/IRAF release cut. (9/04) + +unix/hlib/install + Deleted reference to edsym.e, which is not used on Linux/IRAF. (9/18) + +unix/boot/rtar/rtar.c + RTAR would immediately die on a segvio. This was traced to the use + of a local variable "setuid" which evidently conflicts with some + Linux include file definitions. Changed a number of local variables + in the program to static local variables and this fixed the problem. + (9/20) + +unix/hlib/f77.sh + Added a -b flag to allow calling f77 with the "-b i486-linuxaout" flag + to build a.out executables on ELF systems. (1/03/96) + +unix/hlib/irafuser.csh + Added "-b -i486-linuxaout" to the HSI compile and link flags. (1/03) + +unix/boot/spp/xc.c + Added "-b -i486-linuxaout" flags to all compile and link instances. + (1/03) + +unix/bin.linux/libf2c.a + + Added a copy of the a.out version of libf2c.a to HBIN since this is + not present on Slackware ELF systems, and possibly other Linux + verisons. (1/03) + +unix/os/mkpkg.sh + Changed the call to "as" to use $CC -c $HSI_CF instead, to cause any + platform specific flags to be used to assemble the files. (5/29 1996) + + +---------------------------- +TODO + +*** Provide sh/bash equivalent of irafuser.csh. + +Wed May 29 11:11:00 MST 1996 + New version of spp/xpp/xppcode.c does not work on Linux - some problem + with tokens. Using old version for now. + + diff --git a/doc/ports/notes.mips b/doc/ports/notes.mips new file mode 100644 index 00000000..c00dd6b0 --- /dev/null +++ b/doc/ports/notes.mips @@ -0,0 +1,398 @@ +# MIPS/IRAF alpha port. +# System arrived on thursday 17 May. + +----------------- +Configure UNIX (RISC/os 4.10) + +/etc/passwd +/etc/hosts +/etc/group +/etc/fstab +/etc/local_hostname +/tucana/ + +/u2 + + 1. Usual local configuration of passwd,hosts,group,fstab. NFS + mounted a number of tucana disks. + 2. local_hostname is a MIPS special, used to set hostname (columba + in this case) and network parameters (netmask, broadcast). (4/17) + + [didn't do anything more with the system for several days...] + +/usr/adm/periodic/daily/10.makehosts.system +/usr/hosts + Sometime later I discovered that /usr was 99% full and the directory + /usr/hosts contained over 8000 files totalling about 9 Mb. There + turned out to be a crontab file which makes a link to rsh in /usr/hosts + for every node alias in /etc/hosts. We like to keep a very large + hosts file around for reference, so this would end up producing an + enormous /usr/hosts. It is not clear if /usr/hosts is needed; the + node name entries can be executed to rsh to the node so perhaps that + is what it is for. Rather than disable the facility entirely, I + edited the makehosts script to make entries only for the local hosts. + (4/26) + +login customization + The MIPS is a nearly pure SysV UNIX machine with the default login, + which provides the SysV ls, ps, etc., the old unix kill, erase, etc. + characters for the terminal driver, and so on. A bit of hunting + turned up the following interesting items. + + /bds43/bin + /usr/ucb + Contains 200 or so BSD commands which are no where else to be + found, e.g., nroff, troff, lpr, head, etc., as well as BSD + versions of popular commands like ls, stty (in some cases there + are merely front ends to the SysV versions, like stty). + + /usr/new + Contains some interesting utilities, including LESS and PATCH, + and a couple of things I hadn't seen before, VSAR (a screen + oriented version of the SysV SAR) and VMSBACKUP (claims to be + able to read VMS BACKUP tapes). + + man pages + PAGER can be defined as "less -cqm" to use less to page man + pages. There are two man programs, /bsd43/bin/man or /usr/ucb/man, + which prints the BSD man pages, and /usr/bin/man, which prints + the SysV man pages followed by other entries for the named topic, + prompting each time the pager is exited. Given the default search + path, you have to type /usr/bin/man explicitly to get the SysV + version. + + If the SysV STTY is used one needs to use "winsize" to set the + screen size for programs like LESS and VI. (4/26) + +/usr/lib/cmplrs + This directory contains the runtime files for the compilers. It + appears that the system as delivered by MIPS does not have the + latest (2.10) versions of the compilers installed. The installed + versions are all 2.0. I sent mail off to MIPS to see if we can + get the 2.10 compiler tape (we already have the 2.10 Fortran tape, + but this is useless on the MIPS without the 2.10 compiler backend + programs). (4/26) + +/etc/printcap + +/usr/spool/* + +/etc/rc2.d/S01noao + + Configured LPR for the noao devices. (4/26) + +/usr/lib/tmac/tmac.s +/usr/local/bin/itroff* + +/usr/local/bin/vpr + +/usr/local/bin/qdplot + + Configured nroff/troff and the local noao troff and printer queues. + (4/26) + +/usr/lib/aliases + Installed the noao mail aliases file. (4/26) + +------------------------ +Begin IRAF port to the MIPS. +Start with DECstation/IRAF sources, since these are already set up to +use the MIPS compilers. +Using MIPS BSD43 programming environment. (5/27) + +local/.login +unix/hlib/cl.csh +unix/hlib/irafuser.csh +unix/hlib/libc/iraf.h +unix/hlib/mach.h +unix/hlib/mkpkg.inc + 1. Set new iraf root. + 2. In mach.h, change the byte swap parameters to NO. + 3. Checked size of setjmp buffer; DECstation value is larger + than needed for MIPS, so leave it as is. (5/27) + +bin.mips + +noao/bin.mips + +mkpkg +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.MIPS + +noao/mkpkg +noao/lib/mkpkg.inc +noao/lib/mkpkg.sf.MIPS + +unix/mkpkg.sh +unix/setarch.sh + +unix/bin.mips + +unix/as.mips + + Add support for architecture "mips". (5/27) + +unix/os/irafpath.c +unix/os/zgcmdl.c +unix/os/zxwhen.c + 1. irafpath.c and zgcmdl.c modified to discriminate between Ultrix + and RISC/os operating systems: #ifdef mips is true for both systems. + On a DECstation the architecture is known as "dsux", on a MIPS it + is "mips". + 2. Modified zxwhen for the MIPS hardware exception codes. (5/27) + +unix/boot/bootlib/osputenv.c + The MIPS does not have putenv, but it has setenv. (5/27) + +unix/boot/mkpkg/host.c + The MIPS has COFF libraries, so disabled ranlib. (5/27) + +unix/hlib/install + It turns out that when using the BSD version of CC, the include + files in /bsd43/usr/include are used rather than /usr/include. + Modified INSTALL to make an link in both places (and + manually created the link in order to complete the bootstrap). (5/27) + +------------------- +Bootstrap successfully completed, except for alloc.c which failed to +link. Will take a look at that later. (5/27) + +unix/boot/spp/xc.c + The MIPS is unusual in that it has two sets of compilers (or at + least compiler front-ends) and two sets of programming environments + for BSD and SysV. For our purposes it is simplest to use the BSD + environment. This necessitated a change to XC since we want to + use the versions of CC and F77 in /bsd43/bin rather than the SysV + versions in /usr/bin. + + 1. Modified "run" in XC to search /bsd43/bin before /usr/bin (we + should, of course, be using PATH instead). + 2. Modified XC to link with F77 instead of CC. Using CC is awkward + since the F77 libraries are hidden away in /bds43/usr/lib/cmplrs/... + (5/27) + +------------------- +Begin sysgen. + + The initial sysgen went well except for some problems with the F77 + compiler, which was not installed properly when the system was set + up. First I had to modify XC to use the /bsd43/bin versions of the + compilers (see above). Even when this was done links would still + fail, due to the compiler being only partially installed. I was + able to continue by faking a BSD F77 compiler by combining the 2.10 + F77 front end and libraries with the cc2.0 back end. The full compile + sysgen will have to be redone when the new compilers are properly + installed, and there is little point in pursuing any bugs until + this is done. (5/27) + +math/deboor/mkpkg +math/deboor/setdat.f - +math/deboor/setdat2.f - +math/deboor/setdat3.f - + The DEBOORT math package turned out to have a set of files setdat.f, + setdat2.f, setdat3.f, all of which defined the same routine "setdat" + and which were being redundantly loaded into the library. It turns + out that these routines are not part of the math library anyhow, and + are only used to generate test data for the test programs. I moved + them to deboor/progs (the test programs source library) and deleted + the entries in the mkpkg file. (5/27) + +sys/gio/gks/gcas.x + The MIPS librarian found another duplicate library entry here. The + GKS emulation library has two files gca.x and gcas.x, both of which + define the same routine "gca". Changed the gcas.x version to define + a subroutine "gcas" instead. (These are integer and short versions + of the cell array routine - GCAS is a nonstandard IRAF extension to + GKS, which is not used anywhere to my knowledge). (5/27) + +------------------- +Sysgen complete. + + With these changes the first sysgen completed, except for x_images.e + which failed to link, probably due to the F77 compiler problems + discussed above. Other than that the sysgen went remarkably well. + None of the problems we had with the MIPS compilers on the DECstation + were present on this system. IRAF is up and running, minus IMAGES, + although from browsing the MIPS manuals I see that there are still + some subtle items to take care of. (5/28) + +dev/hosts + Added an entry for node columba and tested iraf networking. (5/28) + +unix/os/zmaloc.c + RISC/os uses the BSD 4.3 memory allocator, which allocates storage in + units that are a power of 2. This can be very wasteful of space for + large buffers, so we don't want to use the default memory allocator. + MIPS provides a couple of other allocators as options, but I had + trouble using these with the BSD43 environment due to unresolved + symbols resulting from the SysV libraries not being searched. + The solution was to replace zmaloc.c by the version used on BSD 4.3 + and Ultrix, which includes an older, simpler, and better behaved + memory allocator. (5/28) + +unix/hlib/libc/iraf.h +unix/os/zzstrt.c +unix/os/zxwhen.c +unix/os/zgcmdl.c +unix/os/irafpath.c + Added a #define MIPS and a commented out #define DSUX. This is more + direct than trying to use #ifdef mips (which is defined by the system) + since this is defined for both the MIPS and DECstation (at least) and + doesn't really tell us what system we are compiling for. (5/28) + +MIPS bug + Running NM on a library with the output redirected causes a + segmentation fault when the process exits. (cd /lib; nm *.a | ...). + +unix/os/zzstrt.c +unix/os/zxwhen.c + Enabled the IEEE exceptions (overflow, divide by zero, and invalid + operand) for MIPS/IRAF processes. Modified ZXWHEN to detect and + decode the floating point exceptions (this required doing bit tests + on the floating point control and status register). + + To figure out how to do this I first did a "man -k ieee". This + turned up a man page for fp[get|set][round|mask|sticky], which + looked like it would do the trick, except that evidently this routine + doesn't exist anywhere in the system (maybe it is a standard SysV + feature which MIPS doesn't support; the man page mentions the default + behavior on 3B systems). By doing an "nm *.a | grep fp" on the system + libraries I eventually turned up set_fpc_csr/get_fpc_csr which is + what is actually implemented on the MIPS. This seems to do the + trick; thus far, setting a nondefault FPCSR doesn't seem to introduce + any new problems. (5/28) + +/etc/init.d/netdaemons +/etc/rc2.d/S01noao +/usr/local/bin/ntp + +/usr/spool/cron/crontabs/root + 1. Had to add a command "route add default gateway 1" to allow network + access to the outside world. + 2. Commented out the gated/routed daemons, which we don't need. + 3. Installed a copy of NTP in local/bin, and set up cron to run it + once a day. This sets the system clock from atomic clock at another + site, by requesting the time via the internet from a network time + daemon running on the remote node. (Forgot to log it, but the timezone + had to be changed to MST a while back too). (5/31) + +----------------------- +New compilers (V2.10) installed and the system bootstrapped and fully +recompiled from scratch. Lacking a tape drive on the system, the compilers +had to be installed manually from the raw distribution tape: I think I set +up all the necessary links etc., but the installation was complex enough +that it is difficult to be sure. (6/19) + +Perusing the output of the sysgen, it appears that there were a number of +problems with the V2.10 compile, whereas the sysgen with the V2.0 compilers +went almost flawlessly. At this point, from the nature of the errors I think +they are real and not something induced by errors in the installation of the +compilers. Another problem was that the disk filled up during the sysgen, +a dangerous problem which can cause errors such as zero length objects being +inserted into libraries. + +At least one compiler bug was observed, this one harmless. Some of the old +NCAR and math library Fortran code contains statement functions. The dummy +variables in such statements functions result in "local variable X never used" +warning messages. (6/20) + +unix/hlib/mkpkg.inc + Added -Olimit 1024 to the default sysgen flags. This sets the max + size in blocks of a procedure to be optimized. With the default + value of 500 the compiler issued warnings for 7 files during the full + sysgen, and failed to optimize 9 procedures. (6/20) + +math/deboor/core +sys/gio/ncarutil/autograph/core +sys/vops/core +pkg/dataio/cardimage/core +pkg/images/tv/cv/core +pkg/images/geometry/core +pkg/plot/core +pkg/xtools/ranges/core +pkg/xtools/core +noao/imred/ccdred/src/generic/core +noao/imred/vtel/core +noao/onedspec/dispcor/core +noao/twodspec/multispec/core + Discovered why the sysgen ran out of disk space - 12 Mb of core + files from compiler optimizer (uopt) crashes! Deleted. (6/20) + +---------------- +I tried recompiling a couple of the files that were associated with +optimizer core dumps in the first sysgen, but could not duplicate the +problem. Started an incremental sysgen to compile the files skipped +in the first sysgen, and this completed without any errors. The system +comes up and runs, ready for runtime testing. (6/20) + +---------------- +/usr/local/bin/saoimage + Installed saoimage. 7.6 Mb left in /usr. As there was so little + disk space, the RISC/os source for saoimage is currently in + /tucana/tmp3/rooke/sao/riscos. (6/21 SRo) + +/usr/man/manl/saoimage.man + Created /usr/man/manl, and placed saoimage manpage in it. (6/21 SRo) + +---------------- +Resume testing on alpha port, 16 July 90. + +sys/vops/amov.gx + This routine could fail, corrupting the data array, in some cases + when the input and output arrays overlap. The same problem exists + in standard V2.9 iraf except that in most iraf implementations, + a host optimized version of AMOV is used, hence the bug has not + been seen. (7/16) + +unix/hlib/mkpkg.sf.MIPS + I added entries for the host optimized versions of AMOV, ACLR, etc., + using the C versions in AS that use bcopy/bzero. Unfortunately + it turned out that the MIPS version of bcopy also cannot be used + when the input and output arrays overlap in a certain way, hence + I had to copy out the entries for the AMOV and BYTMOV routines. + The optimized versions of the ACLR routines are still used. (7/16) + +unix/as.mips/zsvjmp.o + I tried setting the address of MEM to zero and it worked on the MIPS. + The same code failed on the DECstation with a linker error. (7/16) + +unix/os/zmain.c +unix/os/zzsetk.c +unix/os/zfiopr.c + Added a new facility to UNIX/IRAF for debugging interprocess + communication (IPC). This feature will also be useful for debugging + tasks standalone, particularly in cases where a bug seen when the + task is run from the CL is difficult to reproduce when the task + is run standalone. If LOGIPC is defined in the host environment, + the input and output IPC streams of each connected process with + process id PID are logged to the files PID.in and PID.out. (7/18) + +unix/hlib/mkpkg.sf.MIPS + Added system/help/lroff/textout.x to the list of files requiring + compilation without optimization (actually it is the first such file + for this system). Evidently the use of multiple entry points in + this procedure is running into an optimizer bug. The argument "out", + which should be the address of "putline" was being transformed to + the address of "getline" somewhere in this routine, causing output + via textout to be discarded. (7/18) + +sys/imfort/tasks/pcube.f + This file contained a subroutine containing the following sequence of + statements (irrelevant statements ommitted): + + subroutine pcuber (pix, nx,ny,nz, i1,i2, j1,j2, k1,k2) + real pix(nx,ny,nz) + integer nx, ny, nz + + On the MIPS, this produced a warning about nx/ny/nz already having + been declared. Probably when the compiler processes the REAL + statement it assumes the parameters are type integer. This seems + reasonable, so I moved the INTEGER card up before the REAL and the + warning went away. (7/19) + +unix/os/zxwhen.c + While looking into a problem of a task aborting on a floating point + exception, I noticed that the IEEE exception being reported was + "floating inexact", which iraf does not enable. It turned out that + both inexact and overflow were being signalled, but due to the way + the zxwhen code was written only the inexact was being reported. + Since we are not very interested in those exceptions which are not + enabled, I changed the code to check the exception bits for the + enabled exceptions before checking the others. + + In this case the exception of interest was floating overflow, which + is occuring in the routine DET called by SPLOT. It appears that + the matrix being input to this routine is garbage. Since only the + one application is affected I will leave it to someone else to check + into it further. (7/19) + +------------- +Full system testing has been in progress for the past week or so. Things +looks pretty good. One task is dying with an out of memory error; after +hunting around a bit, I determined that the MIPS/SysV command used to +monitor swap space usage is "swap l", which gives the free space in 512 +byte blocks. (7/30). diff --git a/doc/ports/notes.osf1 b/doc/ports/notes.osf1 new file mode 100644 index 00000000..09bb2399 --- /dev/null +++ b/doc/ports/notes.osf1 @@ -0,0 +1,409 @@ +DEC Alpha OSF/1 V2.0 port. Begun 28 December 1994. +Based in part on the preliminary port done by Nelson Zarate of STScI. +Starting point is the Solaris/IRAF system at V2.10.3. +This platform is BSD-oriented with only partial SYSV support so we +will use the BSD code in the HSI. +-------------------------------------------------------------------------- + +unix/hlib/motd + Edited the motd to indicate that the system is DEC-ALPHA/IRAF, + alpha test version. (12/28) + +unix/hlib/irafuser.csh + Edited this file sufficiently to allow it to be sourced during login. + 1. Set MACH to "alpha" using `uname -m`. + 2. Set HSI flags to define "OSF1" for compile time ifdefs. For the + moment set all other HSI compile and link flags to null. + 3. Added some code to try to automatically determine $iraf if not + defined in the user's environment when the script is run. A list + of standard root directories are searched for; these can be links + to the actual location and it will still work. (12/28) + +unix/hlib/libc/spp.h + 1. Set LEN_JUMPBUF to 2*(84+1) for the Alpha (the 2 is because IRAF + uses type int for the array while OSF1 uses type long). (See also + hlib/config.h below). + 2. Set XLONG to int (=32 bits) for this 64 bit machine. + 3. Compiled osb/zzeps2.f and verified that the IEEE epsilons work. + 4. OSF1 f77 evidently uses trailing underscores so it should not + be necessary to modify the Fortran/C name mappings. (12/28) + +unix/hlib/libc/kernel.h + 1. SIGFUNC is a pointer to void for OSF1. + 2. OSF1 has bcopy but the manpage does not say whether it can handle + overlapping arrays, so we will use memmove/memset instead. (12/28) + +unix/hlib/libc/setjmp.h + Comment out the #pragma unknown_control_flow, not support for OSF1 + and there doesn't appear to be anything comparable. (12/28) + +unix/os/getproc.c + Added an #ifdef OSF1 to cause the nlist-based code to be used. (12/28) + +unix/os/irafpath.c + Added a #ifdef __alpha for the alpha architecture. (12/28) + +unis/os/zfioks.c + Changed a number of #ifdef SOLARIS conditionals to #ifdef OSF1 + where appropriate. (for example use the select macros, updated + typing for socket calls). (12/28) + +unis/os/zfiond.c + Modified to use the socket macros as above. (12/28) + +unix/os/zgcmdl.c + Modified similarly to the Ultrix version, using the external __Argv + to pick up the host argument list. (12/28) + +unix/os/zopdir.c + 1. Modified to use . (12/28) + 2. zopdir would pass back a pointer coerced to an int as the "file + descriptor" but this would fail on 64 bit systems where pointers + don't fit in 32 bits. Modified the routine to allocate a kernel + file descriptor for the directory and pass back a normal fd instead. + (12/29) + +unix/os/zxwhen.c + Modified for OSF. OSF1 has sigaction, so this is used for handling + the floating point exceptions (as with Solaris). (12/28) + +unix/os/zzstrt.c + Modified to call the OSF1 function ieee_set_fp_control to enable the + invalid, divide by zero, and overflow exceptions. (12/28) + +unix/os/zdojmp.c + Had to modify to treat jmpbuf as pointer to long rather than to int, + in order to retrieve the quadword address of the status variable + from jmpbuf[0] and to correctly compute jmpbuf[1]. (12/28) + +unix/as.alpha + +unix/as.alpha/zsvjmp.s + + Set up an AS directory for the alpha/osf HSI. Wrote an Alpha version + of zsvjmp. The trick with this one, which I missed at first, was + to set register 27 (pv) to the address of setjmp before branching + into it. The alpha procedure calling sequence assumes that the caller + of a procedure does this and it is required to set the global pointer + correctly for the procedure being executed. + + The STScI version of zsvjmp (produced by technical support at DEC) + could not be used as it was just setjmp with the name changed. + The status argument used by zsvjmp was being ignored, and setjmp + was being called with the wrong jump buffer address. (12/28) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.OSF1 + + Set up a basic mkpkg.inc for OSF1. (12/28) + +unix/.../mkpkg.sh + The OSF1 compilers refuses to produce a file with the extension ".e", + so all the HSI mkpkg.sh files were modified to use .E instead. When + the executables are moved to $hbin the extension is changed to .e. + (12/28) + +unix/os/prwait.c + Like Solaris, OSF1 wait() wants an int exit_status argument. (12/28) + +unix/os/zgtime.c + time() is of type time_t in OSF1. (12/28) + +unix/os/gmttolst.c +unix/boot/bootlib/ostime.c + These routines use ftime() which on OSF1 is only available in an + optional compatibility library. Added a #ifdef OSF1 case which + uses localtime() instead of ftime to compute the timezone in + seconds west of GMT. (12/28) + +unix/hlib/irafuser.csh + 1. Set the default optimization level for Fortran files to -O3, to + disable inter-procedural optimization which causes a warning when + compiling files for a library. + 2. Added a -lots reference to HSI_F77LIBS, this library is evidently + used internally by the Fortran compiler. (12/28) + +unix/boot/wtar/wtar.c + Fixed a bug in WTAR involving coercion of a pointer to an integer + (line 536, bp = ...). (12/28) + +unix/boot/spp/xc.c + Modified for OSF1. The Solaris version pretty much works, about + all I had to modify was the list of Fortran libraries. Also set + the default optimization to -O3 for f77 (-O1 for cc) and set up to + produce a .E output executable which is renamed to the .e version + internally. (12/28) + +--------------------------- +Completed bootstrap. (12/28) +Attempted the first sysgen, numerous errors to be tracked down. + +unix/boot/spp/xc.c + Modified XC to call f77 with "-warn nounreachable" when compiling + SPP generated Fortran files. Technically unreachable statements + occur naturally and harmlessly in some cases in SPP generated Fortran. + (for example in compile time conditionals). (12/29) + +sys/gio/gks/gcas.x + Changed the procedure name from "gca" to "gcas". There is already + another procedure in the same library called "gca". "gcas" is + supposed to be the type short version. (12/29) + +sys/gio/ncarutil/autograph/agrstr.f + Commented out statements number 901, 902: "no path to this statement". + These statements are never called as the code that calls them is also + commented out. (12/29) + +sys/gio/ncarutil/autograph/agsave.f + Same thing, statement 901. (12/29) + +sys/gio/ncarutil/conlib/consld.f + Commented out statement functions SCRTCH and IARVL. These are never + called and result in a warning message. (12/29) + +sys/gio/ncarutil/conrec.f + Commented out three lines around line 1226. These lines were no + longer used because other code had been commented out, and were + resulting in a "Variable XX is used before it value has been + defined" warnings. (12/29) + +sys/gio/nspp/sysint/encd.f + Commented out several lines that were no longer used and were causing + a "no path to this statement" warning. (12/29) + +math/deboor/setdat2.f +math/deboor/setdat3.f + This library contains three files setdat.f, setdat2.f, setdat3.f + all of which contain a procedure "setdat", causing library conflicts. + These routines are not really part of the library anyway and are + only used to generate data for examples in DeBoor's book, but to + avoid the library conflicts I changed the names of the second and + third procedures to setdt2, setdt3. (12/29) + +pkg/xtools/icfit/icdosetupd.x + Problem with mixed type real and double arguments in calls to + the min and max intrinsic functions for xmin, xmax. (12/29) + +pkg/cl/bkg.c +pkg/cl/builtin.c +pkg/cl/compile.c +pkg/cl/config.h +pkg/cl/debug.c +pkg/cl/decl.c +pkg/cl/errs.c +pkg/cl/exec.c +pkg/cl/gram.c +pkg/cl/main.c +pkg/cl/mem.h +pkg/cl/modes.c +pkg/cl/opcodes.c +pkg/cl/opcodes.h +pkg/cl/operand.c +pkg/cl/param.c +pkg/cl/prcache.c +pkg/cl/scan.c +pkg/cl/stack.c +pkg/cl/task.c + The CL has long defined the dictionary and stack as arrays of + unsigned integer. This causes problems on a 64 bit machine like + the Alpha where integer and pointer are not the same size. + To avoid this problem a new type "memel" was defined in a typedef + in config.h. The CL code was modified as necessary to declare + all dictionary and stack storage and references using this new + type. (12/29) + +pkg/cl/scan.c + The varargs code in this routine failed to compile on the Alpha, + which defines va_list as a structure rather than a variable. + This caused a (va_list) cast to fail. After studying this for + a while I couldn't find any way to safely and portably use varargs + to fake an argument list as an array. The solution adopted was + to just make a normal call to sscanf, putting the variable number + of arguments on the argument list in the normal fashion as v[0], + v[1], v[2], and so on. The current implementation imposes a + limit of at most 32 arguments for a CL scan operation. (12/29-30) + +unix/as.alpha/ieee.gx +unix/as.alpha/ieeed.x +unix/as.alpha/ieeer.x + Installed the DEC little-endian versions of the IEEE conversion + routines. (12/29) + +mkpkg +noao/mkpkg + Added an entry for the "alpha" architecture. (12/29) + +unix/hlib/mkfloat.csh + 1. Modified to look for .E files as well as .e files. + 2. The script was failing because tar -tf would output file names + with a trailing space after the filename (surely a bug in OSF1 tar). + Had to add a filter to trim the whitespace. + 3. Modified the script to treat the "generic" architecture specially, + avoiding any attempt to restore any binaries etc. (12/29) + +sys/libc/zzdebug.c -> zztest.c + Renamed zzdebug.c zztest.c to avoid a name conflict with the zzdebug.x + in the same directory. (12/29) + +unix/hlib/libc/stdio.h + In struct _iobuf, changed the type declarations from long and int + to XLONG and XINT. (12/29) + +unix/hlib/config.h + Also set LEN_JUMPBUF here (see above). (12/29) + +dev/hosts + Added an entry for "lyra" to the hosts table. (12/29) + +--------------------------- +Completed sysgen. Core system runs now but a few bugs are evident and remain +to be tracked down. (12/29) + +dev/pix.imh +dev/pix.pix +dev/wpix.imh + Replaced these files with the little-endian versions from Ultrix/IRAF. + Having unreadable images was a major source of the "system" problems! + (12/30) + +lib/helpdb.mip +noao/lib/helpdb.mip + The help system would not read these files... Had to rebuild them + to get things to work. Woops - I forgot to set the byte swap flags + in the HSI before building IRAF. (12/30) + +unix/hlib/mach.h + Set all the SWAP variables to YES. Did a sysgen update. (12/30) + +unix/hlib/install + Modified the install script for OSF1. (12/30) + +unix/boot/spp/xc.c +unix/hlib/mkpkg.inc + Moved the "-taso" flag into XC. This is needed to compile all + iraf programs on the Alpha, and users shouldn't have to type it + when running XC standalone outside of mkpkg. (12/30) + +--------------------------- +Core system is up and running now with no serious bugs evident. +Built bin.alpha for TABLES package. The libraries built (all IRAF uses) +but the compiler core dumped trying to link the executables. Haven't +looked into it yet. Started a sysgen of NOAO. + +noao/artdata/t_mk1dspec.x + Fixed two cases of MAX called with arguments of different types, + in this case the real constants 1. and 0. were being compared to a + type double expression. (12/30) + +noao/mtlocal/cyber/pow.inc +noao/mtlocal/cyber/rrcopy/pow.inc - +noao/mtlocal/cyber/rrcopy/rcrbits.x + The include file pow.inc contained some very small real constants + in the E-38 or E-39 range, which caused compile time evaluation errors. + The offending values in the table were replaced by the value 0.0. + Probably other platforms that don't report this problem have been + underflowing to zero when evaluationg the these values. Deleted + the rrcopy of pow.inc and modified the include in rcrbits.x to + reference the version in the root directory instead. (12/30) + + This program is pretty much obsolete and should probably be retired, + but it is easier to fix the compile time problems for now. + +unix/hlib/mkpkg.sf.OSF1 + Added cl$ytab.c to the list of special files for OSF1. This file + needs to be compiled with -Olimit 2048 to have enough table space + to optimize such a large file. (12/30) + +unix/hlib/fc.csh + Modified for OSF1. The main change required was that the file + /usr/lib/cmplrs/fort/for_main.o must be explicitly included on the + link line in order to link the Fortran program. (12/30 1994) + +--------------------------- +Merged in latest 2.10.3 revisions from tucana. (2/16 1995) + +dev/tapecap + Modified the Ultrix/IRAF tapecap to add support for OSF/1. Added + compressed and uncompressed DAT (TLZ06) unit 0, 1 entries. These + worked on the first try, although I did have to add an ":se" to + make appending work after readting to EOT. (3/01) + +unix/as.alpha/ieee.gx + I did not actually modify this file for the problem noted below, + but wanted to record this oddity of the Alpha architecture. (3/01) + + The inconsistency seen on the Alpha with the IEEE test files is not + due to the NaN values, which are handled correctly, but to the + special case negative zero (-0) value included in this test data. + For some reason the Alpha fp unit is generating an exception for an + operation comparing zero and negative zero. Other platforms have + not had a problem with this (although one wonders what the correct + result should be in this case). It does seem rather an odd problem + and it is not clear if it is worth worrying about. If necessary we + can modify our IEEE i/o routines to map such values to positive zero + but I don't know if it is worth it, unless we find out that such + values can occur in real world data. + +--------------------------- +Merged in latest 2.10.4 revisions from tucana. (4/20 1995) + +unix/os/mkpkg.sh + Modified the OS boot mkpkg.sh to use as$zshlib.s rather than + os$zshlib.c. The mkpkg special file list was set up to do this, but + the wrong version was used when the system was bootstrapped. (4/21) + +unix/hlib/mkpkg.sf.OSF1 + Modified to compile as$zshlib.s without optimization, the default xc + flags produce a warning message when used to compile as$zshlib.s. + (4/21) + +unix/os/zxwhen.c + This code was modified to use signal instead of signal plus sigaction. + I was having problems with signals not being caught resulting in + infinite loops. See the comments in the code. (5/03) + +unix/os/zawset.c + Installed new version from tucana. (5/03) + +unix/hlib/libc/kernel.h + Modified values of SZ_DEFWORKSET and SZ_MAXWORKSET to 8 Mb and 256 Mb + as was done on tucana for ZAWSET above. (5/03) + +unix/hlib/zzsetenv.def + Default printer changed to "lp". (5/03) + +unix/os/mkpkg.sh + Fixed a couple minor problems found in redoing the bootstrap. + 1. Changed HSI_LIBS to HSI_OSLIBS for building zalloc.e, which doesn't + use the IRAF libraries. + 2. The "set zsrc = ..." was incorrect for the Bourne shell, changed + to BS syntax. (5/03) + +unix/os/zawset.c + This routine would not work properly on OSF/1 even though it should + according to the docs (behavior should be the same as on other + systems). Any attempt to set RLIMIT_RSS would fail, causing the + value 50 to be returned. Modified the code to merely comment out + the setrlimit. getrlimit still works and the routine will still + return an accurate indication of the physical memory available to a + process. Probably this problem with setrlimit() explains why the + "limit" command in the cshell doesn't work either. (5/09) + +unix/hlib/spy.cl + Updated to use ps -ef instead of px -axu. (5/23) + +sys/fio/fioclean.x +sys/fio/stropen.x + Two new internal routines str{set,get}mode were added to stropen.x. + These are used to set or query the file access mode as strored for + the string file, which represents these in a file-dependent way. + fio_cleanup was modified to force the access mode of a string file + to READ_ONLY before closing it during file cleanup, to prevent the + writing of the trailing EOS when closing a string file opened for + writing. The latter could cause a segmentation violation if the + string buffer was no longer in a mapped region of memory, as is + possible if the string file is still open (i.e. not closed normally) + following task termination when fio_cleanup is called. (6/06) + +--------------------------- +V2.10.4 release June 07 1995. + +unix/hlib/install + Changed /etc/mknod to /usr/sbin/mknod. (6/21) diff --git a/doc/ports/notes.solaris b/doc/ports/notes.solaris new file mode 100644 index 00000000..46a5fed2 --- /dev/null +++ b/doc/ports/notes.solaris @@ -0,0 +1,514 @@ +Begin IRAF port to Solaris 2.3 +Wed May 25 15:38:55 MST 1994 +---------------------------------------- + +bin.ssun + +bin.ssun/IB.SSOL.SUN + +bin.sf2c + +bin.sf2c/IB.SSOL.F2C + +noao/bin.ssun + +noao/bin.ssun/IB.SSOL.SUN + +noao/bin.sf2c + +noao/bin.sf2c/IB.SSOL.F2C + + Set up the Solaris platform (SSOL = Sun Solaris) and the two planned + Solaris architectures, SUN (Sun unbundled compilers) and F2C (F2C + and FSF compilers). (5/25) + +unix/hlib/irafuser.csh + 1. Replaced the `mach` reference by something that will work on both + SunOS and Solaris, using uname. + 2. Modified to define either SUNOS or SOLARIS in HSI_CF, so that + kernel code can support both systems. (5/25) + +unix/os/getproc.c + Added a Solaris version of uid_executing(). This reads /proc and + scans the process files to see if any belong to the given uid. (5/25) + +unix/hlib/irafuser.csh +unix/os/mkpkg.sh + 1. alloc.e would no longer link without linking against the library + -ldl. Note that -ldl can only be linked dynamic (no -Bstatic). + 2. Added a new definition HSI_LFLAGS to irafuser.csh and modified the + mkpkg.sh in OS to use this to define the link flags for alloc.e. + This will probably have to be done for other HSI executables as well. + (5/25) + +unix/os/prwait.c + Solaris defines the exit_status argument to wait() differently and + the code had to be modified to allow for this. (5/27) + +unix/os/zfioks.c + The select facility on Solaris uses fd_set, FD_SET, etc. and it + was necessary to add #ifdef SOLARIS code to reflect this. (5/27) + + +Fri Jun 24 14:23:32 MST 1994 +---------------------------------------- +Resume port (elsewhere for the past month) + +unix/hlib/libc/kernel.h + Added a definition PFV; PFI is now a pointer to function returning + int, and PFV is a pointer to a function returning void. Also added + a new definition SIGFUNC, which is whatever type signal() refers to + on the local system. (6/24) + +unix/os/zfioks.c + 1. Changed a number of PFI instances to SIGFUNC. + 2. Changed the second two arguments to ks_onsig to type int*. These + are not used and the actual type is different on Solaris than other + systems. Probably the args should just be omitted but it may be + more portable to define a couple of dummy args. + 3. The second argument to bind() is type (struct sockaddr *) in + Solaris, was (caddr_t) on other systems. (6/24) + +unix/os/zfiotx.c + 1. Deleted the import_fset, which apparently isn't used and which + contains a #define which conflicts with a Solaris one. + 2. Changed a bunch of PFI instances to SIGFUNC. Added some + (SIGFUNC) declarations to the signal handler arguments to signal(). + 3. Replaced the two dummy arguments (same as item 2 above) in three + instances of event handlers with dummy args declared (int *). (6/24) + +unix/os/zopdir.c + Modified to use Solaris version of opendir/readdir. (6/24) + +unix/os/zoscmd.c + Modified to use SIGFUNC instead of PFI, and to declare generic + dummy arguments for an event handler. (6/24) + +unix/os/zshlib.c + Fixed a syntax error on the last line, an extra ';' following a + stubbed out function declaration. (6/24) + +unix/os/zwmsec.c + 1. Modified to use signal instead of sigvec; the latter is BSD specifc. + 2. sigpause() takes a signal number instead of a signal mask. Omitted + sigblock, which is no longer needed since we aren't using a mask, and + which doesn't exist on Solaris. + Possibly this routine should be completely rewritten on Solaris, + there may be better facilities for small timed delays. (6/24) + +unix/os/zxwhen.c + 1. For Solaris we must include and . + 2. fcancel macro modified to use the constant BUFSIZ. + 3. The table of hardware exceptions was modified to omit all + codes other than those for SIGFPE; the other codes (at least on + Solaris) alias with the FPE codes, and aren't used anywhere in + zxwhen anyway. Added Solaris SIGFPE codes. + 4. Modified calling sequence of exception handler ex_handler to + the form Solaris requires. Added a statement to get the hardware + exception code out of the siginfo argument. + 5. Replaced a number of PFI's by SIGFUNC's. (6/25) + +unix/os/zfiomt.c + Modified signal handling code to use type SIGFUNC. (6/25) + +unix/os/zzstrt.c + Made a few changes to get this code to compile, although the shared + library support isn't expected to work at this point. (6/25) + +unix/hlib/irafuser.csh +unix/os/zzstrt.c + Added a new define SHLIB, used to conditionally compile zzstrt for + shared library support. (6/25) + +unix/boot/bootlib/bootlib.h + This file had a #ifdef UNIX in it, but this define is not defined + anywhere. Modified to #ifdef VMS but assume unix otherwise. (6/25) + +unix/hlib/irafuser.csh + Modified to define RANLIB as "echo ranlib" for Solaris. (6/25) + +unix/hlib/kernel.h + Solaris doesn't have bcopy/bzero, so added a couple of #defines to + kernel.h to map these functions onto the equivalent Solaris versions + memmove/memset. (6/25) + +unix/os/zoscmd.c +unix/os/zopdpr.c +unix/os/zfiopr.c + Replaced all calls to getdtablesize() by corresponding calls to + getrlimit(). (6/25) + +unix/os/zfgcwd.c + Replaced getwd() by getcwd(). (6/24) + +unix/boot/mkpkg/scanlib.c + It was necessary to add an (int) cast to (int)fread(...) > 0 + to avoid a warning message from the compiler, because fread has an + odd type on Solaris. (6/25) + +unix/hlib/irafuser.csh + Added -lsocket -lnsl (the Solaris socket emulation library) to the + list of HSI host libraries used to link the HSI utilities. (6/25) + +unix/boot/spp/xc.c + Made some minor changes to xc for Solaris - not clear yet what all + will be needed. Most of it looks like it will work. Added a #ifdef + conditional for the Solaris F77 libraries, taking the SunSoft + compiler as the builtin default. Modified signal handling to use + SIGFUNC to be more portable. (6/25) + +unix/boot/rmfiles/rmfiles.c + Added an "extern char *vfn2osfn()" declaration. (6/25) + +unix/boot/spp/rpp/ratlibc/initst.c + Added a #ifdef conditional to access the stdio streams on Solaris. + (6/25) + +unix/gdev/sgidev/sgi2uapl.c +unix/gdev/sgidev/sgi2uhpgl.c +unix/gdev/sgidev/sgi2ueps.c + 1. These files contained a number of cases where the file descriptor + "out" was declared int where (FILE *) was intended. + 2. Replaced an instance of gethostname() in sgi2uapl.c by a call + to sysinfo(). (6/25) + + +Sat Jun 25 23:26:24 MST 1994 +---------------------------------------- +Completed first bootstrap. Try initial sysgen of core system. + +unix/boot/spp/xc.c + Modified xc to automatically do a "-t" when linking. This disables + linker warnings about different size commons. (6/26) + +unix/os/irafpath.c + Added a case for Solaris/sparc. (6/26) + +mpkg +as.ssol + +bin.ssol + +unix/setarch.sh +unix/hlib/irafuser.csh + For Solaris/sparc the HSI AS and BIN are as.ssol and bin.ssol. + Hopefully it will be possible to use a single set of directories + for both the ssun and sf2c binary architectures. (6/26) + +unix/hlib/install + Added some code to set the platform architecture automatically for + either SunOS or Solaris. On a Solaris system the suntools stuff is + skipped. (6/26) + +unix/boot/bootlib/envinit.c + Fixed a bug/typo in this code: "printf (stderr, ...)". (6/26) + +unix/boot/bootlib/vfn2osfn.c + Several more cases of a null statement ";" at the end of this file. + This happens in dummy function constructs like "foo(){};". (6/26) + +unix/hlib/mkpkg.inc + Added cases for IRAFARCH=ssun and sf2c. (6/26) + +unix/hlib/mkpkg.sf.SSUN + +unix/hlib/mkpkg.sf.SF2C + + Added starter special file lists for the two Solaris architectures. + (6/26) + +unix/as.ssol/zsvjmp.s + This assembler source appears to assemble ok, but I had to remove the + leading underscore from _zsvjmp_ as the SunSoft Fortran compiler + doesn't use leading underscores. (6/26) + + +Sun Jun 26 20:18:48 MST 1994 +---------------------------------------- +Completed first core system sysgen: system starts up and runs, but a number +of bugs are evident. + +unix/hlib/irafuser.csh + HSI_XF now includes flags such as -/DSYSV -/DSOLARIS etc., so that + mkpkg can be used to update HSI libraries such as OS. This is only + a temporary solution, ideally XC should accept HSI_CF. (6/27) + +sys/fio/fdirname.x + There was an actual bug in this file that showed up during testing + of the new port. zfxdir (kfxdir) was being used incorrectly to + test for the existence of host directory pathnames. (6/27) + +unix/os/zopdir.c + The above testing also revealed a bug in this file. This was + preventing commands such as "dir /" from working, due to a bug in + the code which strips trailing slashes from directory names. (6/27) + +unix/os/zfiotx.c + 1. Raw mode terminal i/o was not working properly on Solaris; output + data was being lost when raw mode was entered, even though the ioctl + used would (presumably) wait for the output to drain before changing + the terminal mode. It is not clear what the connection might be, + but this was fixed by deleting the iflag=0, i.e., not resetting the + iflags, when entering raw mode. Evidently clearing one of the + default input flags was the source of this problem, even though + ICANON was disabled. Since ICANON is disabled we shouldn't need + to change the iflags anyway, so it should be safe to omit this. + In fact, it is probably safer to preserve all default terminal flags + by default and change only those affecting raw i/o, but at present + I will leave it fully setting the oflags and lflags, since this + is working. + 2. Solaris also provides the POSIX termios interface which is the + recommended interface. This appears to be a simple front end to + the termio ioctl interface. I decided to avoid this for the moment + since the SYSV termio interface appears to be widely available. + (6/27) + + +Sun Jul 3 23:08:27 MST 1994 +---------------------------------------- +Resume work on Solaris port. + +unix/as.ssol/enbint.s + +unix/os/zzstrt.c +unix/os/zxwhen.c + After a bit more research got IEEE floating point exception handling + working under Solaris. The new routine enbint.s is used to enable the + exceptions. sigaction turned out to block SIGFPE when the handler + was called and it proved necessary to add the SA_NODEFER flag to + prevent this. (7/03) + +unix/os/zfioks.c +unix/os/zfiond.c + Fixed a couple bugs that were keeping networking from working. + "RSH" was not being defined correctly in zfioks, and it was necessary + to add FD_ZERO calls to zero the select fd arrays before calling + FD_SET. (7/04) + +sys/imfort/tasks/ +unix/hlib/fc.csh + Tested FC on the imfort tasks. This worked without incident following + minor changes to the fc.csh script. The only thing unusual is that + an IEEE retrospective is printed when the task exits, indicating + that the IEEE divzero,overflow,invalid exceptions were enabled. + This is annoying but is not exactly a bug (ieee_retrospective is always + called by Fortran programs, it just doesn't usually generate any + output), so for the moment I don't see the need to change anything + at present. (7/04) + +Build of ssun binaries for TABLES proceeded without incident. (7/04) + +unix/boot/bootlib/ossymlink.c + This file used #ifdef BSDUNIX incorrectly, preventing the #ifdef-ed + code from compiling on UNIX systems for which BSDUNIX was not set. + Changed the statement to #ifndef VMS. (7/05) + +unix/shlib/zzzend.c + Deleted ";" at the end (empty declaration). (7/10) + +unix/shlib/medit.c + Added a #define for bcopy, which doesn't exist in Solaris. (7/10) + +unix/shlib/mkpkg + Modified to avoid use of ranlib on Solaris platforms. (7/10) + +unix/boot/spp/mkxc.sh + Modified to do the compile and link in separate steps. (7/14) + +unix/gdev/sgidev/sgi2uapl.c + Modified to put "%!PS" in the Postscript file header. (7/19) + +dev/tapecap + Added Solaris support. (7/20) + +unix/boot/spp/xc.c + Added -lintl to the list of builtin host libraries. (7/23) + +unix/os/zfiotx.c + Rather than leaving iflags unmodified when raw mode is entered, + now clears several input processing flags, in particular CR is not + mapped to NL. (7/23) + +unix/hlib/zzsetenv.def + Changed the default printer device to "lw". (7/25) + +unix/shlib/Slib.c +unix/shlib/edsym.c +unix/shlib/elf.c + +unix/shlib/medit.c +unix/shlib/mkpkg +unix/shlib/mkpkg.sh +unix/shlib/mkshlib.csh.ssol + +unix/shlib/zzzend.c +unix/os/zzstrt.c + There were many changes here, especially to mkshlib.csh, edsym.c, + Slib,c, and zzend.c, to support IRAF shared libraries under Solaris. + Most of the changes were made earlier but I did not keep detailed + notes during development. The changes are not fully backwards + compatible, so it will be necessary to configure separate shlib + directories for SunOS and Solaris. (7/25) + +unix/hlib/mkpkg.inc + A wfits problem was traced to a bug in the Fortran optimizer using + SunSoft Fortran 2.0.1. Compiling -O2 avoids the problem. (7/29) + +unix/hlib/install + The install script was modified earlier to just exit when it came + to the gterm/imtool config stuff. Modified this to continue on + with this, but to do only the X11 related configuration. This + consists of making the /dev/imt fifos, installing the imtoolrc, + and checking that termcap and graphcap are sufficiently up to date + to contain xgterm and imtool entries. (7/30) + +unix/hlib/libc/kernel.h +unix/os/zfiotx.c +unix/os/zzstrt.c + Replaced the terminal driver by a version which maintains a unique + descriptor for every hardware terminal device, regardless of the + file descriptor used to access the terminal. (8/02) + +dev/graphcap + The xgterm graphcap entry now recognizes either CR or LF as the + trailer code for a cursor read. (8/02) + +unix/boot/mkpkg/mkpkg + Changed "cc" to "$(CC)". (8/17) + +unix/boot/spp/xc.c + XC now supports multiple packages in PKGENV. (8/18) + +----------------------------------------------------- +Solaris 2.10.3 release +*** apus upgraded to Solaris 2.4, SunSoft V3.0 compilers *** + +unix/os/zfiotx.c + Installed the tty_reset bugfix. (9/17) + +unix/os/getproc.c + This routine was omitting the "/proc" from pathnames of process + files in the /proc directory, causing uid_executing to always + return zero. (10/05) + +----------------------------------------------------- +Merged in V2.10.4 revisions from tucana. (4/22 1995) + +unix/hlib/mkpkg.sf.SSUN + Added explicit $xc build commands to the special file list entries for + C files. The default compile flags from mkpkg.inc would cause a + warning when applied to C files, as CC doesn't understand -O2. (4/26) + +unix/shlib/mkshlib.ssol-sc2 +unix/shlib/mkshlib.ssol-sc3 + + Renamed mkshlib.csh.ssol to mkshlib.ssol-sc2. This is the version for + the version 2x SunSoft compilers. Started a variant mkshlib.ssol-sc3 + for the version 3x compilers. In this made various minor changes: + 1) File header size increased from 0x74 to 0x78. + 2) Compiler libraries and objects are now in /opt/SUNWspro/SC*/lib + instead of /opt/SUNWspro/SC*. + 3) There is a new library -lsunmath which follows -lF77. (4/26) + +unix/boot/spp/xc.c + Modified to add the -lsunmath library if used with the Version 3 or + greater SunSoft compilers. XC attempt to automatically distinguish + Version 2 and Version 3 and do the right thing. (4/26) + +unix/hlib/mkpkg.inc + Removed the -O2 switch from the standard compile flags in mkpkg.inc. + This was put in for an older version of the compilers and probably + isn't needed any longer. This also avoids the problem of passing -O2 + to the C compiler when compiling C code. (4/26) + +----------------------------------------------------- +Completed a full bootstrap and sysgen of V2.10.4 Solaris/IRAF using +Solaris 2.4 and the SunSoft V3 compilers. (4/26) + +unix/hlib/zzsetenv.def + Updated "version" to 2.10.4EXPORT. (5/18) + +unix/hlib/spy.cl + Rewrote spy.cl to work on both BSD and SYSV systems (SunOS and + Solaris in the case of Solaris/IRAF). (5/19) + +unix/os/zgtime.c + Modified for Solaris systems to use CLK_TCK (which does a runtime call + to sysconf) to get the clock frequency, instead of the compile time + kernel constant CLKFREQ. On our development system CLK_TCK is 100, + rather than 60 which is the value compiled into the kernel. (5/19) + +unix/os/gmttolst.c + In the internal routine get_timezone added a call to "tzset()" + before accessing the external variable timezone. This is necessary + to set the value of timezone in the first call after process + startup. (5/19) + +unix/os/zoscmd.c + This fix was made to resolve a problem where EMACS or VI would + hang up when run from the CL and ctrl/g or ctrl/c was typed. + Evidently this was due to the code in zoscmd.c which pretends to + ignore interrupts while the child is executing, but in reality was + catching interrupts and setting a flag then continuing to wait for + the child process to terminate. Evidently on SysV systems, or at + least on Solaris, the interrupt handler was causing the process + to read from the terminal, and wait() was not being reentered + folowing an interrupt causing both the parent and the child to read + from the terminal at the same time. The fix was to modify zoscmd.c + so that on SYSV systems the parent does not post any interrupt + handler. (5/19) + +unix/os/zzstrt.c +unix/shlib/mkpkg +bin.ssun/S10_5.4.e + + It appears that the system library libsocket.a in Solaris is + incompatible between Solaris 2.3 and 2.4. Networking is broken if + an IRAF executable linked under Solaris 2.3 is run on 2.4 and vice + versa. Our workaround, at least for the moment, is to have different + versions of the IRAF shared image for different versions of solaris. + During startup an IRAF process will query the OS release number, + e.g. 5.3 (Solaris 2.3) or 5.4 (Solaris 2.4) and map the corresponding + shared image. A mkpkg in unix/shlib updates the version of the + shared image corresponding to the OS release on which IRAF is + currently running. The new shared image file names are S10_5.3.e + for Solaris 2.3 and S10_5.4.e for Solaris 2.4. If the release + dependent version is not found the system will automatically fall + back to S10.e. (5/22) + +----------------------------------------------------- +Did another sysgen-relink and rebuilt the distribution files. (5/22) + +unix/boot/spp/xc.c + Modified to compile only C and assembler files in the catch-all + compile phase. Prevents compile attempts where the file list + contains only object files. This was a problem under Solaris 2.5. + (10/19) + +unix/shlib/mkshlib.ssol-sc3 + Modified to suport the SC4.0 compilers under Solaris 2.5. There was + a bug in the script if both SC3.0.1 and SC4.0 compilers were present + in the same system. The link line was slightly different for the + new compiler. (10/19) + +unix/shlib/mkshlib.ssol-sc3 - +unix/shlib/mkshlib.ssol-sc34 + + 1. Changed the name of this file to sc34 since it supports both the SC3 + and SC4 compilers. Updated the comments accordingly. + 2. I tried changing the page alignment for the shared image from + 0x2000 (8K) to 0x4000 (16K). The intent was to support Sparc clones + with 16K pages. It worked (at least on a Sun sparc), but would + produce a bogus version match please relink error message on startup + for old executables, due to relocation of the transfer vector. I had + to set things back to 0x2000 as we can't afford to break old + executables for a patch. (3/25 1996) + +unix/os/zmain.c + Added a #ifdef SYSV conditional to allow for different calling + sequences for setpgrp() on SYSV and BSD systems. (4/24) + +unix/os/zfinfo.c + Commented out the setpwent/getpwent, they are not needed on Solaris + and appear to cause an associated Solaris bug to crop up. (8/16) + +------------------------------------------- +V2.10.4 patch 2 released. (5/22 1996) + + +TODO + o Tue Nov 21 12:50:24 MST 1995 + XC assumes /opt/SUNWspro in isv3(). + + o Thu Feb 1 11:54:17 MST 1996 + Skip reports networking failure - AA05224 + + o Mon Mar 11 12:24:55 MST 1996 + Modify zawset.c to use actual physical memory as determined by sysconf. + + o Mon Mar 11 12:25:10 MST 1996 + Change SHLIB address from 0a000000 to 03c000000 to allow 1 Gb process + data segment. This requires that all applications be relinked so + cannot be done until V2.11. diff --git a/doc/ports/notes_orig.hp b/doc/ports/notes_orig.hp new file mode 100644 index 00000000..da07675f --- /dev/null +++ b/doc/ports/notes_orig.hp @@ -0,0 +1,657 @@ +1 February 1988, HP/UX port, HP 9000 Series 800 Model 850 +Steve Rooke, NOAO + +[read tape from NOAO/lyra; source tape cut 30 Jan 88. +[at least the last file, probably the whole last block worth of the tape +[was missing, including the root mkpkg file. Have been unable to dial in +[to NOAO to recover. +[Had to do this several times, trying dd then tar; couldn't write with +[tar xp due to existence of an account with same group, user id, so had +[to read as root, then chown/chgrp afterwards, in order to preserve file +[dates. + +local/.login + Set iraf root to /aura/iraf; commented out mail command (didn't + like $user); modified stty to get rid of a bunch of Berkeley stuff. + This works: + stty tabs intr ^C kill ^U susp ^X eof ^Z erase ^H + (2/1 SRo) + +unix/* + Spliced Sun HSI into lyra source system, on the theory that there + will be less editing A#pqthan for a VAX. (2/1 SRo) + +hlib/libc/iraf.h +hlib/mkiraf.csh + Reset iraf root. (2/1 SRo) + +/usr/include/iraf.h + Copied in from libc/iraf.h; there are no symbolic links in HP/UX + V1.2. They will arrive in HP/UX V2.0 in March '88. + **TODO** remember to remove copy in /usr/include and replace + with sym.link when available. (2/1 SRo) + +vms/* + Removed vms directory. (2/1 SRo) + +hlib/mkfloat.csh - +hlib/cl.csh - + Removed these sun-specific files. The 9000 800 series has only + one kind of floating point hardware. (2/1 SRo) + +osb/zzeps.[fe] + Compiled and ran zzeps; machine single & double precision same as + on the Suns (IEEE standard works, apparently). (2/1 SRo) + +hlib/libc/spp.h + Increased LEN_JUMPBUF from 16 to 51, as /usr/include/setjmp.h + allocates 50. (2/1 SRo) + +local/.login +local/ranlib + Removed /usr/ucb, /local/bin, and /usr/local/bin from search path + (not present here), and added $iraf/local. Created a dummy shell + script called RANLIB, to avoid having to edit out the ranlib command + all over the system. In HP/UX, AR performs the ranlib function. (2/1) + +unix/os/zdojmp.c +unix/os/mkpkg + Added Doug's new zdojmp.c from tucana (hardcopy), which uses UNIX + longjmp call, replacing some assembler code formerly used in + as$zsvjmp.s. (2/1 SRo) + +hlib/libc/iraf.h +/usr/include/iraf.h + Commented out BSD43 define; "hpux" automatically defined for all + C files. (2/2 SRo) + +os/zxwhen.c + Included FAULT and TRAP hardware exception codes from + /etc/conf/h/signal.h. (2/2 SRo) + +hlib/libc/kernel.h + Set _NFILE to 60 for HP/UX, MAXPROCS to 25 (as per maxuprc in + /etc/conf/gen/S800). (2/2 SRo) + +hlib/irafuser.csh + Set all HSI compiler flags to "-O", which is optimization level 2, + the highest of 0,1,2. (2/2 SRo) + +[Begin first bootstrap attempt. cd $host; sh -x mkpkg.sh] +unix/mkpkg.sh + Commented out "test" command and symbolic link from as.MACH to + as; no "test" in HP/UX, currently no symbolic links. (2/2 SRo) + +unix/os/mkpkg.sh +unix/as/zsvjmp.c + Temporarily replaced as/zsvjmp.s with as/zsvjmp.c in order to + get past compiler error. Apparently if an error occurs in one + of the source modules listed on a cc command line, none of the + objects is produced (also see next entry). (2/2 SRo) + +os/zxwhen.c + Modified reference to fp->_bufsiz; (HP/UX no longer has _bufsiz as + structure element; rather it is defined in terms of an external + bufendtab[] and existing structure elements): fp->_bufsiz becomes + _bufsiz(fp) as per #define in stdio.h. (2/2 SRo) + +os/alloc.c + Moved the #include after the #include , as + the time_t symbol is defined in the former in HP/UX. (2/2 SRo) + +hlib/libc/iraf.h +hlib/libc/hpux.h + Added an `if hpux, include hpux.h' directive, and created the + latter. Without symlinks, difficult to keep modifying iraf.h. + Iraf.h seems to be the best place to include special redefinitions + of system calls and the like that are in the HSI but not present + in HP/UX (or SysV). This seems safer for later updates than editing + a dozen files all over the HSI. hpux.h now contains: + + #define MAX_IPATHLEN 127 /* max IRAF pathlen */ + #define getwd(a) getcwd(a,(MAX_IPATHLEN+2)) + +unix/boot/spp/rpp/mkpkg.sh + Removed the "kludge for Sun-4" code which used the command "mach", + apparently a SunOS command. (2/2 SRo) + +unix/boot/bootlib/mkpkg.sh +unix/boot/bootlib/rename.c + Added routine to simulate BSD "rename" call; we tried this with + macros, but turned out to be too complicated with error checking. + Mkpkg.sh only compiles rename.c if test "`uname`" = "HP-UX". (2/2 SRo) + +local/.login + Added /usr/local/bin to path. (2/2 SRo) + +unix/os/zfiotx.c + Removed "struct sgttyb ttystat;" statement from ZCLSTX, where + it was declared but not used. (2/2 SRo) + +unix/os/zfgcmd.c +hlib/libc/hpux.h + Added ifdefs hpux around getwd(x), which is now getcwd(x,MAXPATHLEN). + Removed similar redefinitions from hpux.h, which now has nothing + in it, and should be removed later if nothing further is added. + **TODO** Remove hlib/libc/hpux.h and include for it in iraf.h?? + (2/2 SRo) + +hlib/libc/kernel.h + SysV does not use the sgttyb structure, and ioctl flags are different. + added #ifdefs to redefine part of the FIODES structure if hpux. Should + later modify for a more general way to determine whether SysV at + compile time. (2/2 SRo) + +unix/os/zfgcwd.c + SysV uses getcwd(p,maxlen) rather than getwd(p). Ifdef'd. (2/2 SRo) + +unix/os/zfiotx.c + Extensive modifications to support SysV termio, using #ifdefs, so + should still work with BSD. (Would not compile with any references + to the BSD sgttyb structure.) (2/[23] SRo) + +unix/os/zfioks.c + Added ifdefs around ioctl call for no echo while getting password. + (2/3 SRo) + +unix/boot/bootlib/ossettime.c + Ifdefs for hpux; in SysV utimes becomes utime, and the tv_sec + structure element from timeval has become UNSIGNED long. (2/3 SRo) + +unix/boot/mkpkg/host.c + Same for another utime[s] call, unsigned long tv_sec. (2/3 SRo) + +hlib/libc/kernel.h + Added extra structure element initialization for hpux (SysV) + fiodes structure (zglobl.c wouldn't compile). (2/3 SRo) + +boot/spp/rpp/ratlibc/ratdef.h + HP-UX does not tack on trailing underscores to fortran + external identifiers. Removed same from all identifiers + in this include file. (2/3 SRo) + +hlib/libc/knames.h +hlib/libc/xnames.h + Removed trailing underscores from fortran external identifiers. + (2/3 SRo) + +unix/boot/spp/xc.c + Replaced FORTLIB[1-3] values with "-lcl", "-lm", and "" for HP-UX. + Symptom was unresolved external symbols "$$lr_wa_[8-13]", or + hpux "millicode" routines; "cl" stands for "compiler library". + (2/3 SRo) + +unix/boot/spp/rpp/mkpkg.sh + Added explicit "-lcl" after user libraries on CC command line. + The CC compiler in HP-UX does not automatically pass this + flag on to the loader (not set up for arbitrary mixing of C + and F77). (2/3 SRo) + +[Bootstrap finally completes error-free.] + +unix/os/mkpkg.sh +unix/as/zsvjmp.s + Installed Jim Dillon's just-completed zsvjmp assembler routine + (had a stub in there before), and restored os/mkpkg.sh to its + initial state. (2/3 SRo) + +[Ran rmbin on the HSI and performed another bootstrap.] + +unix/hlib/mkpkg.inc + Removed Sun stuff; the hppa has no special compiler flags for + floating point. (2/3 SRo) + +[Began sysgen at 16:55. Proceeding smoothly at 18:00 except for numerous ] +[warnings: WARNING: TEST MAY FAIL DUE TO FLOATING POINT IMPRECISION (781)] + +[Thursday Feb. 4. +[Sysgen completed at 02:03 2/4; this was a 9-hour sysgen. There were 1011 +[of the fp imprecision warnings, and about 2 dozen errors of various kinds. +[The spoolfile summary contained 2569 lines! There was one fatal compiler +[error plus several compiler deaths due to my having forgotten to map the +[intrinsics AND etc. +[The fp imprecision warnings result from "if (variable .eq. CONST)" in +[HP-UX f77, and there is nothing we can do about them except turn off all +[f77 compiler warnings with "-w". + +unix/hlib/iraf.h + Defined and=iand, or=ior, xor=ixor for HP-UX. (2/4 SRo) + +TODO: Remember to search for and delete .BAK files in the HSI. + +unix/boot/spp/xc.c + Modified to compile C source files with CC rather than F77. There + were several places in the sysgen where we attempted to compile C + source with f77 (mkpkg.inc: USE_CCOMPILER is YES), in addition to + the CL C source. HP-UX f77 does not recognize C source. Desinger + feels that it should, and suspects it never came up before. (2/4 SRo) + +sys/imfort/imemsg.x + This file contained a half dozen "% msg = '...'" statements, + where the quoted string exceeded column 72 (assuming the leading + tab got expanded into 8spaces). Abbreviated each offending + character string to fit into 72 columns. Obviously, only these + "%" source statements that bypass the preprocessor could possibly + exceed 72 columns, however we would not have noticed any that would + not have ended in a missing quote, so TODO: filter all spp source + files for ^% lines longer than 72 chars, after expanding tabs. + (2/4 SRo) + +sys/gio/ncarutil/conbdn.f + There was an uncommented DATA statement at line 342, following + assignment statements, and the f77 compiler complained. (2/4 SRo) + +sys/gio/ncarutil/conbd.f + Had to move a "data first" statement up into its proper position + (it followed some assignment statements). This was lower case, so + it looked not to be a typo as in the previous case. + Also had to add dummy variable in data statement as cannot init + variables or arrays via data statement in named common in HP-UX. + (2/4 SRo) + +sys/gio/ncarutil/gridal.f + Compiler warned about compile-time algrbraic expressions that can + be reduced; there are stmts at lines 1554,1566 subtracting 0. from + an expression (harmless, no mods made, just noting). (2/4 SRo) + +sys/gio/ncarutil/srfabd.f + Compiler complained (error) about illegal initialization of "first", + which was in a data statement and also in common. Added a dummy + variable in data stmt, and subsequent assignment to "first". (2/4 SRo) + +sys/gio/nspp/portlib/gridal.f + "ifmt" was declared to be two-dimensional, but it appeared in an + equivalence statement at line 217 with only one subscript. (2/4 SRo) + +sys/gio/nspp/portlib/z8zpbd.f + More arrays & variables in common initialized in data statement + (mfmt[xy]). (2/4 SRo) + +noao/onedspec/dbx/dbmore.x + This routine initializes an array with DATA that is in common. + Hacked for now, leaving to Frank V for later. (2/4 SRo) + +noao/imred/dtoi/hdicfit/hdicgdelete.x + The int procedure icg_deleted() did not return a function value, + causing a proper error message from f77, but generating a fatal + error and infinite loop in the optimizer. Hacked for now to + return (0). TODO: investigate hdicgdelete.x to see what, if + any, return value should be generated. (2/4 SRo) + +unix/boot/mkpkg/host.c + Finally noticed that the system libraries were disappearing instead + of being checked into lib$. There is code in host.c that attempts + to copy the file if it cannot be moved any other way, but it must + never have been tested for moving a file to a directory, because the + creat() call took as its new file name just the host pathname of lib$, + lacking the name of the library. Since u_fcopy() looked like it was + intended to be a general copy routine, I added a strcat in the calling + routine to append the library to the directory. This ought to be + investigated (TODO), in case anything other than a file in the local + directory is the "old" file. + (2/4 SRo) + +[Began new sysgen at 17:21:22 PST 2/4/1988. Still leaving in the compiler ] +[warnings; when all have been checked out, the flag "-w" ought to be added ] +[to mkpkg.inc; there is no way to ignore just the floating-compare warnings.] + +math/interp/arider.x + Compiler objected that real function did not return value. Kludged + the three returns to "return (0.0)". (2/4 SRo) + +unix/boot/spp/xc.c + XC was correctly compiling C source with "cc" rather than "f77" now, + but immediately afterwards was also trying to compile them with f77. + Fixed the subsequent filter that I hadn't noticed earlier. This will + necessitate a followup sysgen (mostly a relink), as XC thought it + shouldn't try to link after getting run errors from UNIX. (2/4 SRo) + +[This doesn't look so good... dates of object modules do not appear to +[be in the object libraries, and mkpkg is recompiling all files regardless. +[Getting too late to fix tonight. Also, using cc to link (passed from XC) +[results in a fatal /bin/ld error... + +unix/os/zawset.c + Finally (manually) got past enough loader problems to find the + unresolved symbols... [gs]etrlimit() not implemented in SysV. + As this is not critical code for basic port purposes, merely + stubbed out for now. TODO: find some way to implement this in + SysV/HP-UX. Investigate plock() for HP-UX only (real-time programming + manual) (2/5 SRo) + +unix/os/zwmsec.c + In SysV, sigvec() is sigvector(), with no other changes. Used ifdefs. + (2/5 SRo) + +unix/boot/spp/xc.c + Set FORTLIB3 to "-lbsdipc", the HP-UX library containing the likes + of rexec(); networking probably won't work anyway, but it might be + worth a try. (2/5 SRo) + +unix/os/zfprot.c + Added #ifdef hpux to redefine rindex(). (2/5 SRo) + +[HIATUS -- Accidentally trashed this entire notes file last night with +[a typo (redirecting some error output to the end of this notes file +[with ">&" rather than ">>"). File recovered from Friday (2/5) noon backup +[by Bob Desinger. There were about 11 hours of time during which a moderate +[number of notes file entries were made that were lost. The following are +[from memory but will have to be verified by diff'ing back in Tucson. + +unix/os/zawset.c + Could not immediately find a way to alter the working set size on this + system, so simply ifdef'd out the entire body of the routine to get + past unresolved symbol (getrlimit) at load time. + TODO: adjust workingset size in SysV? (2/5 Sro) + +unix/os/zopdpr.c + No way to alter the timesharing (as opposed to HP-UX extended realtime) + priority of another process. Ifdef'd around the [gs]etpriority calls. + (2/5 SRo) + +unix/boot/mkpkg/scanlib.c + In HP-UX, the object libraries have a different structure than under + BSD. The symbol table is the first "module", immediately after the + 8-byte magic header, then is followed by N modules. When the space + allocated to the first symbol table entry is full, apparently, a symbol + table extension is tacked on. Since module names are terminated with a + "/", and none of the symbol table entries has a module name, module + names beginning with "/" are always symbol table entries, so we check + each module to see if it is the latter, and skip file_size bytes if so. + Also, in exercising the code: + while (fread (&arf, 1, sizeof(arf), fp) > 0) { + it was apparent that the structure was not being passed correctly. + Though the size and number of instances seemed to be reversed, that + should have been harmless, but the structure itself was not being + passed correctly to fread. Solved with the following: + while (fread (arf, sizeof(arf), 1, fp) > 0) { + (2/5 SRo) + +unix/os/zlocpr.c + The CL was dying at startup time, after trying to set an entry + point address in fseti(). Determined that the f77 EXTERN declaration + generates an address pointing to the address of the external function. + Modified zlocpr.c to use onenOxD extra level of indirection. For some + reason, the typedef PFI declaration does not work; left the declaration + of proc as "int *proc" (something to do with how the compiler handles + "()" as part of a declaration??). (2/5 SRo) + +unix/hlib/mkpkg.inc + Added "-w" flag to turn off all compiler warnings. All such warnings + have already been investigated and accounted for, and the 1011 floating + compare warnings clutter up the spoolfiles unnecessarily. (2/5 SRo) + +unix/boot/mkpkg/host.c + Cleaned up a bug I had introduced earlier in moving file to directory. + (2/6 SRo) + +sys/gio/nspp/sysint/ishift.x +sys/gio/ncarutil/sysint/ishift.x + Both these files had their own "iand" and "ior" functions, generating a + compiler error, as "and" -> "iane:rtd" already, in hlib$iraf.h; as it + is the last day, I don't have time to recompile the whole system + by placing some redefinition in iraf.h; the procedure calls are + the same as those supplied by HP-UX, so just commented out the + ncar equivalents. (2/6 Sro) + +noao/astutil/asttools/pdmstatistics.x +noao/twodspec/apextract/t_apnormalize.x + Ha! Just like the Masscomp, TAR will not write files that have + a "." in the 14th position, and reports no error message. These + files are missing from the system. (2/6 SRo) + +noao/imred/dtoi/hdicfit/hdicebars.f +unix/hlib/mkpkg.sf + This file generates a fatal internal error in the 2nd pass of the + optimizer, after staying in a loop for a very long time. Left + f77 source with HP. Added to special file list. (2/6 SRo) + +noao/twodspec/multispec/fitclean.f +noao/twodspec/multispec/fitsmooth.f +unix/hlib/mkpkg.sf + These files generate fatal address compiler errors in 2nd pass + of optimizer. Left with HP. Added to special file list. (2/6 SRo) + +noao/imred/dtoi/hdicgundelete.x +noao/imred/ccdred/t_badpiximage.x +noao/imred/ccdred/t_mkfringecor.x +noao/imred/ccdred/t_mkillumflat.x + Files missing; "." in 14th column. (2/6 SRo) + +[Several minor errors in new relink-sysgen; didn't compile newly-added +[files in mkpkg.sf w/o pass2 optimization, irafks tried to call rename. +[Still getting: + + dictionary starts at 1073968624 (010000672760) + pfileload, task cl + task `cl' has no param file + Fatal startup error. CL dies. + +[irafks.e failed to link because our kludged "rename" routine is in +[bootlib, not libos, of course. TODO: investigate better way to handle +[rename(); getting late, so won't try anything now. + +[Continuation of notes file begin 2/1/88 for HP-UX port] + +unix/os/mkpkg.sh + Separate compilation of zsvjmp.s; pass 2 of the optimizer causes the + routine to fail! (2/11 SRo) + +sys/fio/open.x +sys/fio/filopn.x + After grubbing around for a while trying to figure out what was + wrong with file descriptors and/or os channels, tried compiling + these routines without optimization. For the first time, this + permitted getting all the way to the "cl>" prompt, but with all + the CL debugging turned on. I used ADB to turn off debugging + (cldebug/W 0), but it kept getting turned on automatically. + I was able to have the system task do a successful long directory + listing of hlib$motd, but was unable to type it out. Everything + looked so badly garbled, that: + +unix/hlib/mkpkg.inc + Set optimization flag to "O1" rather than "O2". If all works well + tomorrow morning, I'll at least know I'm looking at optimizer, not + system, bugs. (2/11 SRo) + +[Ran RMBIN from the root; started new sysgen.] + +[5-hour sysgen, only minor incidents, mostly due to missing >14char filenames] +[Same startup symptoms firing up CL: + + dictionary starts at 1073968624 (010000672760) + pfileload, task cl + task `cl' has no param file + Fatal startup error. CL dies. + +[Recompiling fio$filopn.x with NO optimization (rest of system is now at +[opt level 1 rather than 2 originally) gets past that problem but again +[cldebugging is turned on automatically so at 1200 baud you have to wait +[about 5 minutes for the prompt. A lot of things are still screwed up -- +[can't access hlib$motd (can from system process run standalone); the +[command "show iraf" generates an error with no return to the prompt; +[^C then causes error recursion and the CL dies. + +unix/hlib/config.h + Finally realized there was another LEN_JUMPBUF after seeing the + global variable cldebug get trashed by setjmp after 16 words, same + as the old LEN_JUMPBUF in the Sun HSI. Increased to 51, started + another sysgen. (2/12 SRO) + +[CL comes up fine now, and all the builtins I tested work fine. "directory" +[results in an eventual core dump, with possible error recursion. Running +[the system process standalone just generates a segmentation violation. +[As I am working from home, without access to printouts or another terminal, +[I decided to take advantage of another 48 hours before getting back to the +[office by stripping all binaries and recompiling everything with NO +[optimization (last sysgen was with -O1). Since filopn.x generates a fatal +[error even compiled with -O1, I consider it reasonable to gen the whole +[system without opt, then fix all the non-opt bugs, then start increasing +[the level of optimization to see just how bad it is. (2/14 SRo) + +Best so far. CL comes up fine, can do direN |ctory listings etc. without +system process dying. IMDEBUG/MKIMAGE still coredumps with no warning to6\D5| +the CL, and when "bye" is given, the CL warns about an error in the subprocess +then hangs. 2 ^C's generate error recursion with CL death. Apparently there +are some routines causing fatal problems even with optimization level 1, but +at least there are some other bugs to isolate first before tackling opt. +(2/15 SRo) + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h + Defined getpid as xgetpd; with no trailing underscores in HP-UX, + SPP getpid collides with UNIX getpid. (Symptom was infinite + recursion in getpid->zgtpid->getpid...) (2/16 SRo) + +unix/hlib/motd + Updated banner page for HP-UX. (2/16 SRo) + +unix/as/zsvjmp.s + Set value of "status" to zero, as this had been neglected originally. + Symptom was infinite error recursion in the CL for commands such as + "lpar junk" (not infinite stack accumulation, due to the nature of + setjmp/longjmp). (2/18 SRo) + +[Another relink sysgen, as everything links with zsvjmp.s] + +[MKHELPDB got stuck; name collision between spp rename and faked UNIX +[routine. + +unix/hlib/iraf.h +unix/hlib/libc/xnames.h +unix/os/zfrnam.c +unix/boot/bootlib/rename.c - + Defined RENAME as xfrnam to avoid name collision, removed earlier + rename.c, which didn't belong in bootlib in the first place, and + added u_rename() function to zfrnam.c. (2/19 SRo) + +pkg/cl/main.c + Modified memneed() to add memory on 64-bit boundaries. Otherwise, + there is a bus error whenever a double floating point word that + is not 64-bit aligned (in actual memory, not just relative to + some data structure) is loaded into a floating point register. + Must also have next fix as well. (2/25 SRo) + +pkg/cl/pfiles.c + In one place, after a call to memneed(), there was verification + code to assure synchronization; this failed when memneed() was + modified to be 64-bit aligned. Current fix is a shameless hack. + (2/25 SRo) + +[Success!! I can load packages, stat images, get graphics in a gterm +[window over the phone lines from "urand | graph", etc. There will +[doubtless be further bugs when more exhaustive testing is undertaken, +[but things look far better than at any time up til now. + +dev/pix.imh +dev/pix.pix + Due to tape problems when I originally prepared the source tape, + the standard dev$pix 512*512 short image was not on tape. I brought + a separate tape with the binary image in FITS format, but forgot + to read it in before I had to dash off to the airport, so I built + the image from a Mandelbrot set test program I copied over the + phone line into local/sr/mandel.x. (2/29 SRo) + +unix/hlib/alloc.e + Had Jim Dillon change ownership to root. (2/29 SRo) + +unix/hlib/iraf.h + Name collision with getuid(); defined as xgetud. Symptom was + segmentation violations in wfits and in the CL when attempting + to allocate the drive. (2/29 SRo) + +dev/devices + Cleaned up and added all relevant aliases. SysV uses /dev/rmt/* + and /dev/mt/* for raw and block special device names respectively; + only the sysmgr is supposed to be able to use /dev/mt/* devices, + so these need not be added as aliases. However, the standard + AT&T device installation leaves the tape head positioned after + the 2nd EOF mark during write/close; if special minor device + names are added, the interface is "berkeley style". Convention + adopted here was a trailing "b" for those device names, for lack + of anything better. The device bits are as follows for Berkeley: + + crw-rw-rw- (...) 0x140000 Mar 1 17:39 /dev/rmt/0hb + crw-rw-rw- (...) 0x1c0000 Mar 1 17:39 /dev/rmt/0hnb + crw-rw-rw- (...) 0x120000 Mar 1 17:38 /dev/rmt/0mb + crw-rw-rw- (...) 0x1a0000 Mar 1 17:39 /dev/rmt/0mnb + + IRAF entry for drive 0 on the "hpufoca" machine is as follows: + + mta rmt/0hnb rmt/0hb rmt/0mnb rmt/0mb \ + rmt/0hn rmt/0h rmt/0mn rmt/0m + mta.6250 rmt/0hnb rmt/0hb rmt/0mnb rmt/0mb \ + rmt/0hn rmt/0h rmt/0mn rmt/0m + mta.1600 rmt/0mnb rmt/0mb rmt/0hnb rmt/0hb \ + rmt/0mn rmt/0hn rmt/0h + + The numeral is the drive number, h=high, m=medium, and l=low + density, "n" is for no-rewind. This does appear more rational + than BSD UNIX. (3/1 SRo) + +noao/astutil/pdm/pdmstats.x +noao/astutil/pdm/mkpkg + Transferred this file over the phone, formerly called + pdmstatistics.x, >14 chars; lost during 1st sysgen. (3/1 SRo) + +noao/twodspec/apextract/t_apnorm.x +noao/twodspec/apextract/mkpkg + Transferred from noao; >14 chars. (3/1 SRo) + +noao/ccdred/src/t_badpixim.x +noao/ccdred/src/mkpkg + Same. (3/1 SRo) + +[Ran RMBIN and began a new sysgen to ensure recent changes to iraf.h +[get picked up everywhere (just relinked a couple of executables by hand +[after getuid() change). (3/1 SRo) +[Tue Mar 1 19:47:39 PST 1988 --> Wed Mar 2 00:48:55 PST 1988 +[5-hour sysgen (full recompile & relink); roughly same as on Model 850. + +noao/imred/dtoi/hdicfit/hdicgundel.x +noao/imred/dtoi/mkpkg + Re-transmitted this file (formerly named hdicgundelete.x), which + got deleted during one of the last sysgens, as it still had >14 + chars, and the .o file replaced the .x file during compilation. + Although renamed back on lyra, it still was not returning function + values, so just added 2 "return(0)"'s. (3/2 SRo) + +noao/imred/ccdred/src/t_mkfringe.x +noao/imred/ccdred/src/t_mkillumft.x +noao/imred/ccdred/src/mkpkg + Transferred these files with shortened names from Tucson; >14 char + files were trashed earlier. (3/2 SRo) + +[Ran IRAF test procedures, including tape drive ones, and using the +[dev$pix created from the Mandelbrot Set, as original one didn't make +[it. No problems encountered. (3/2 SRo) + +[Ran benchmarks over dialin, excluding image display, networking, and +[multiple-terminal graphics ones. No software problems encountered. (3/2 SRo) + +unix/os/zfrnam.c + Had neglected to unlink oldfile when implementing BSD rename() + with link/unlink. (3/2 SRo) + +local/terminfo +local/terminfo/s/sun +local/terminfo/s/sun24 +local/terminfo/s/sun34 +local/terminfo/s/sun40 + Created this directory to hold private terminfo descriptions. + A new description may be compiled by first using untic(1M) to + decompile one of the existing entries in /usr/lib/terminfo/?/file, + editing the result, setting the environment variable TERMINFO + to a pathname, and running tic(1M) to compile the entry. Tic + actually creates the single-letter subdirectory, and names the + resulting file from EACH alias in the untic'd file. To use a + non-standard terminfo description, here sun40: + + % setenv TERMINFO $iraf/local/terminfo + % setenv TERM sun40 + + (3/8 SRo) + +[ Tar tape cut for CFHT; no further work expected to be done on hpufoca +[ system at Foster City. HP-UX/IRAF maintenance & update will now be done +[ on Model 825 at CFHT. (3/8 SRo) diff --git a/doc/ports/notes_v22.st b/doc/ports/notes_v22.st new file mode 100755 index 00000000..230ab876 --- /dev/null +++ b/doc/ports/notes_v22.st @@ -0,0 +1,1185 @@ +Space Telescope Science Institute iraf$local/notes.st + +[ Many of the below notes and bugs have long been fixed, however the CL ] +[ changes have yet to be fully integrated into both ST and NOAO versions, ] +[ so we'll keep them around for a little longer. Some notes have been ] +[ added below (in [[ ]]) where necessary/appropriate. JJT 8-Mar-1986 ] + +-------------------------------- +Monday 23-DEC-1985 17:32:26.42 + +Subject: CL Changes Nov-Dec 1985 + (T.McGlynn, J.Travisano) + +grammar.y + - delete opnl's in procedure declarations to eliminate s/r conflicts. + - create LP and RP for parentheses to eliminate some expressions. + - repositioned initialization processing. + - modified var_decls slightly. + - if/else fixes, so don't need { if ... }. + - better syntax error reporting in scripts: gives (correct) line number, + points to offending position, and continues parsing script for errors. + +history.c gram.c + - changes to support above grammar changes + +history.c exec.c pfiles.c decl.c + - changes to deal with script line numbers correctly, i.e. + task->t_scriptln, which is used in syntax error messages; also, + a fix in the skip_to() function in decl.c. + +history.c + - problem of getting a "begin" in the history when running (or parsing) + a procedure script was fixed. The original command is now recorded + in the history (and logfile) correctly. Unfortunately, there is + one case where this does not work -- when get an error parsing the + parameter declarations in a procedure script. + +eparam.c + - format changes for real arrays (so exponent shows up) + - tried to fix MOVE_END problem when going across page boundaries; + can't seem to find the bug, so for now just print out a message that + says to use NEXT_PAGE a few times instead of MOVE_END. + +pfiles.c param.c gram.c + - added support for '\r' and '\f', so can be used in prompt strings + for better formatting control (\f not fully supported in EPAR yet) + +modes.c decl.c pfiles.c + - whitespace-only filename parameters are turned into null strings; + so users can check null filenames easily in a script (fn != "") + without having to deal with whitespace. Filenames with whitespace + only are not really legal anyway (?). + +modes.c + - bug fix to prevent trashing of enumerated parameters in certain + instances. + +param.h + - minor typo 'ai' --> 'ar' + +-------------------------------- +Friday 27-DEC-1985 14:47:48.01 + +Subject: CL history editor [[ known feature ]] + +The following is another lexmodes=yes problem: + + pl> contour img1[*:16,*:16] + ... + pl> surface ^^ + surface img1[*:16 + Warning: ... + +The get-arguments code in pkg/cl/history.c checks for comma-delimited strings. +Putting the whole argument in quotes, i.e. "img1[*:16,*:16]", and then using +^^ works fine. (No fix/change was made.) + +-------------------------------- +Friday 3-JAN-1986 14:59:06.87 + +Subject: Local vars in CL procedure scripts + +It is generally assumed that local variables in CL procedure scripts, i.e. +those after the "begin" statement, will be initialized by the user with +simple assignment statements. There is one (possibly more) case where this +assumption can cause problems. For example, + + ... + begin + string buf + + if (fscan (plist, buf) != EOF) ... + ... + +Here, "buf" is used before being initialized, and the result is an error +saying "Attempt to use uninitialized local variable 'buf'". Perhaps local, +uninitialized variables should be initialized automatically by the CL, but +have done nothing to fix/change this yet; just making a note of it. + +-------------------------------- +Tuesday 7-JAN-1986 15:37:59.59 + +Subject: Miscellaneous + +These are various notes and suggestions by IRAF users at STScI and elsewhere. +I decided to finally add them all here since they were beginning to pile up +on various scraps of paper on my desk. Some of them are minor bugs, but most +are suggestions of some kind. Nothing has been done with any of them in terms +of IRAF changes. Most of the text is from mail messages or typed in verbatim +from paper copies. Any notes by me (JayT) are indicated in brackets []. + + +From ST users: + +CL + Would it be possible to put a feature into iraf whereby you say +'task=xxx', which would then set a default so that you could just +type lpar, or an input, without having to specify which task? +Ie, instead of having to type 'xxx.infile=etc', you could specify +the task and then just type 'infile=etc', with iraf filling in +the task name. This would not interfere with those who like the +system as it is, but could streamline things for those of us who +like the way AIPS does things. + +Integer parameters + We have encountered another peculiar feature of IRAF. Suppose you have a +parameter that is declared as integer in a .par file, and the user attempts +to put in a value for that integer that exceeds the range of INT*4. The cl +fills in that parameter with the value 'indef', a character string. When +SDAS goes to read the parameter, we get a crash because the parameter is not +in integer form. Now, it seems that a parameter declared as an integer ought +to be an integer no matter what, not a character string. Wouldn't it be better +to leave the parameter value unchanged from its current or default value rather +than put in this string? + + +From RAL users: + +CL Parser + li> ?? | words | match ':' stop+| sort | table + + does NOT work correctly, but separating the "+|" to "+ |" works okay. + +Help on parameter prompt + It is very complicated to provide additional help at the prompt for + parameter stage especially for non-string parameters. This facility + is almost essential to provide a user-friendly interface. + For example: + A string specified in the parameter file is output if ? is + typed in response to a prompt or possibly even enter the help + system. + + [NOTE: One can make the prompt quite verbose, up to something + like 2K characters; e.g., many SDAS prompts are long and multiline.] + +Range check and default display in sexagesimal + There needs to be an option in the parameter file to cause the range + check and default information to be output in sexagesimal. For example, + it is ugly to type in 12:34:56.7 and have it reappear as 12.582417. + +Date type + I think there ought to be special facilities for handling dates. At + present you can't enter a date all in one line (except using a + grotty fudge involving sexagesimal, which precludes proper range + checking), and if you enter the Y,M,D separately you can get things + like 1985 2 30 past the range checks. + + +From U. of Cal/San Diego (Doug Tudhope): + +lists.gcursor [and imcursor] [[ fixed in feb release ]] + Get syntax error line 2. [known "feature" since CL2 grammar] + + [NOTE: doing an "lpar gcursor" activates the graphics cursor, + but then get an error of "EOF encountered in list parameter..."] + +plot.graph task + If only 2 points are given, only the axes are drawn, e.g. + + pl> graph STDIN + 10 10 + 20 20 + + axes, but no line! + pl> + +images.imtranspose + Made a transposed output file of a real 190*800 image -> 800*190 + but neither onedspec.splot nor images.implot would work on it. + they stopped with "reserved operand fault". + When imcopy run on transposed image, got "pixel storage file truncated". + +-------------------------------- +Tuesday 7-JAN-1986 15:51:02.98 + +Subject: pkg/softools/boot/spp/xc.c [VMS] [[ now in vms/boot/spp/ ]] + +Added EXTEND_SOURCE option for calling Fortran compiler from XC. This lets +source statements go up to column 132 (instead of 72). One line added to +source: + +fcompile() { + ... + sp = strcpy (outbuf, F77); ++ sp = strcpy (sp, "/EXTEND"); /* Allow statement in cols 1-132 */ + if (portable) + ... +} + +-------------------------------- +Tuesday 7-JAN-1986 16:11:20.85 + +Subject: pkg/images/tv/display/deanza/* [[ updated in march ]] + +Deanza now works with tv/display under VMS! All of the source files and Deanza +libraries are here. See the README file for more detailed information. + +Also changed "pkg/image/tv/display/mkpkg.com" to make the Deanza code instead +of the IIS-dependent code. + +-------------------------------- +Wednesday 8-JAN-1986 12:21:09.73 + +Subject: pkg/imred/.../*.e [[ fixed with new iraf$bin/ dir ]] + +The ONEDSPEC executables are copied all over the place into IMRED. Comments in +the mkpkg.com files say this is to use different par files for different +directories. There's GOT to be a better way, as this eats up a lot of +diskspace (and tape as well at distribution time), which we always seem to be +running up against here. + +-------------------------------- +Friday 10-JAN-1986 15:29:37.13 + +Subject: More SDAS concerns/suggestions + +Environment variables [[ discussed, to be resolved ]] + When a script task ends or a user bye's from a package, all "set" + declarations made in the task or since the package started are + "popped" during task restoration. Comments in pkg/cl/exec.c indicate + that this is for keeping the environment the same across processes. + + However, this can lead to confusion. If a user does a "set stdgraph=" + and later bye's out of a package, stdgraph reverts back to the + previous value, just as any other environment variable. The same + thing occurs in script tasks during the restore, making it difficult + to have global environment variables. Putting a "keep" in scripts at + various places can get around this to some degree, but it's sometimes + awkward. + +Process cache + SDAS has been set up under IRAF such that the user can choose which + version of SDAS he wants (baseline|standard|develop). This choice + can be made when starting the sdas package or any of its packages. + There is a problem, however, when running a package from 'standard' + and then running the 'develop' version when the executable is already + out there. When a task is invoked, it will simply use the subprocess + already in the cache, even though it's a different executable (with + the same IRAF logical name). + + The suggestion that came up was to do an implicit "flprcache" whenever + there is a "bye" to a package, i.e. when all the tasks associated with + the executable are gone. I've looked at this a little bit and don't + see an easy way of determining when we're bye'ing from a package which + has tasks that are in an executable. I imagine there's a decent amount + of overhead associated with checking all the tasks associated with + an executable as well. In general, getting rid of old executables + does make sense if they're not longer referenced, since it frees up + system and user resources (especially important on VMS given the + large process and executable sizes). + +Table parameters + SDAS and CDBS now have a new type of input file, a table, which may or + may not have a header as well. They have asked if it would be easy + to add a new parameter (or two) to IRAF, i.e. a table parameter and + possibly a table-with-header parameter. + + I don't think this is a good idea, as it is something which only + benefits SDAS and CDBS, and does very little if anything for IRAF. + I have encouraged the SDAS people to find an SDAS-only solution to + this problem using existing IRAF facilities. One simple way is to + have tasks which use tables to have a 'type' parameter which tells + if the input file is a table or something else. + +-------------------------------- +Tuesday 14-JAN-1986 08:48:36.11 + +Subject: doc/clintro* [[ missing again, noao has most recent version ]] + +Copied the TeX source for the CL User's Intro doc from Peter's directory +to the general IRAF DOC directory. + +-------------------------------- +Tuesday 14-JAN-1986 10:49:06.01 + +Subject: Size of IRAF... [[ resolved w/ Feb release ]] + +A concern has risen, once again, on the size of IRAF. Garrett Jernigan +(Berkeley Space Sciences Lab) has mentioned problems finding diskspace to +handle all of IRAF. The suggestion he made to Peter was "to split the source, +obj and executables into separate libraries for the distribution, or at least +put them into different sub-directories. If either a tape could be generated +that only had executables, or that had the whole works, but allowed only the +required files for execution to be loaded it would be a real boon." I guess +this means having something analagous to the bin/, src/ scheme in Unix. + +I think a better solution to this is to add something to the installation docs +to describe how to load only parts of IRAF, i.e. everything, or no source, +etc., so the IRAF installer can load only the parts needed/desired. Both Tar +and Backup can handle selective copying in some manner. + +-------------------------------- +Tuesday 14-JAN-1986 11:37:46.40 + +Subject: CL strings + +It is currently impossible to get the length of a string in the CL. This +should be quite trivial to implement, but it is not. The documentation on +"paramaters" states that p_length contains the maximum length of the string, +though in reality, saying =param.p_length simply prints the string, just as +=param does. + +There should be some way of getting the current length of a string, since it +could be used as the 'last' parameter in stridx, for getting the rest of a +string starting at column n. ST users have continually asked me about ways to +get the current length of a string parameter (e.g., from within a CL script). + +One solution is to change the meaning of some of the parameter attributes for +string parameters to something which makes more sense: + + p_length -- contains the current string length, updated whenever + the parameter is changed. + p_max -- contains the maximum string length + +These would require changes primarily in param.c and gram.c. + +Also, currently trying an =param.p_min or p_max on a string parameter results +in an access violation. + + +===> Released new Public version of IRAF at STScI, Mon Jan 13, 1986 <=== + +===> Sent Notes, CL changes, SDAS-related items to KPNO, Thu Jan 16, 1986 <=== + + +-------------------------------- +Thursday 16-JAN-1986 13:58:15.69 + +Subject: pkg/cl/config.h + +Changed DICTSIZE from 20000 to 25000 and STACKSIZ from 4000 to 8000, to deal +with large scripts and tasks with zillions of parameters now used at STScI +which have been causing some overflows. The VMS CL's executable size is no +larger, since uninitialized arrays are allocated at run-time. + +Also changed NFGPROC from 4 to 3. Originally changed in an effort to improve +performance, it's causing more problems with page-file quotas because of the +very large SDAS executables, so back it goes. + +-------------------------------- +Friday 17-JAN-1986 09:25:22.96 + +Subject: Loading packages from within procedure scripts [[ resolved below ]] + +It is a known "feature" in the CL that packages cannot be loaded from within a +procedure script or from within braces. An old-style script, like the current +IRAF package scripts, can contain statements which load packages (e.g. onedspec +loads the list and plot packages). + +Loading packages from within procedure scripts should be supported at some +point (if possible). SDAS uses procedure scripts almost exclusively now, even +their package scripts are procedures. + +Checking into it a little bit, it appears that putting a `keep' statement in +the package script fixes this problem. But this is not a good solution for +general interactive use. A possible solution is to add an implicit `keep' when +a cl() call is made from a script called by a script (as in most package +scripts). This may be the easiest solution and will require no changes to +existing package scripts. + +-------------------------------- +Monday 20-JAN-1986 11:17:09.92 + +Subject: pkg/language/doc [[ used Feb release instead ]] + +A few minor changes to the help text; typos, corrections, added examples, etc. + +-------------------------------- +Monday 20-JAN-1986 16:42:18.87 + +Subject: pkg/cl/Makelib [[ use mkpkg instead ]] + +Corrected Makelib file to contain correct include files for CL source. + +-------------------------------- +Tuesday 21-JAN-1986 12:25:29.74 + +Subject: pkg/system/gripes.cl [[ now in vms/hlib/ ]] + +Changed to mail entire gripe text to IRAF development account, as in KPNO +version, and not just a message that a gripe has been made. Also changed +to use `userid' for the From field instead of `home'. + +-------------------------------- +Tuesday 21-JAN-1986 15:37:48.27 + +Subject: pkg/cl/grammar.y + +Added initialization code for the label list structure used for goto statements +in CL scripts. Simply added "label1 = NULL;" statements to the three places in +the grammar where things are initialized. The absence of this would eventually +cause access violations and other fatal side effects when goto's were used +again and again. + +-------------------------------- +Wednesday 22-JAN-1986 09:12:46.73 + +Subject: pkg/cl/builtin.c [[ fixed at noao too ]] + +Two instances of + flags != LT_PFILE; +changed to + flags &= ~LT_PFILE; + +-------------------------------- +Friday 24-JAN-1986 08:11:29.20 + +Subject: pkg/cl/pfiles.c + +Added line to reset parse state in certain circumstances within a script. + +-------------------------------- +Tuesday 28-JAN-1986 09:16:18.48 + +Subject: sys/fmtio/lexnum.x [[ fixed at noao too ]] + +A previous fix to lexdata.xi caused a bug in lexnum.x to show up, although the +relation between the two is unknown. The stk_ip[] array in lexnum() was +declared as short; this would sometimes overflow since it was storing pointers +which could be quite large. This showed up when a user tried to add a field in +an image header with 'hedit', resulting in an arithmetic trap. The fix is to +declare stk_ip[] as int instead of short. + +-------------------------------- +Tuesday 28-JAN-1986 11:06:27.14 + +Subject: GIO and graphcap [[ fixed in Feb release ]] + +Setting stdgraph to tek4014 results in an "openws: illegal graphics window" +error message when running the graph task. Using showcap to see what is +really in the graphcap entry shows that although it points back to tek4012, +all of the upper case values (X1,X2,Y1,Y2,etc) do not get set properly. + +-------------------------------- +Tuesday 28-JAN-1986 11:44:54.72 + +Subject: pkg/cl/exec.c [[ #ifdef st stuff removed 3/11 ]] + +Quick patch to allow packages to be loaded from within any type of script. This +fix has been #ifdef ST'd for now (ST is #define'd in config.h). Basically, when +a "cl" or "clbye" statement is encountered within a script, the package is kept +for the duration of the script task that called it. + +-------------------------------- +Tuesday 28-JAN-1986 16:29:25.83 + +Subject: pkg/twodspec/longslit/apdefine.x [[ fixed at noao too ]] + +Was getting a lot of "adjustable array dimension errors" when running apdefine. +The following changes fixed them: + + real apdata[3, naps] --> real apdata[3, NAPS] + real imdata[npts] --> real imdata[ARB] + +In the original code, if 'naps' or 'npts' were invalid (e.g., zero or negative) +when the arrays were declared, this error occurred. + +-------------------------------- +Monday 3-FEB-1986 10:25:45.69 + +Subject: iraf$vms/loc.c [[ ST tool, moved to local/ ]] + +Threw together a quick and dirty Lines-of-Code counter to handle C, SPP, +Fortran, MACRO and Ratfor source files for IRAF. It only counts non-blank and +non-comment lines, considering them "executable". (NASA folks like this +software metric to see how much we're supporting.) + +-------------------------------- +Monday 3-FEB-1986 13:00:23.77 + +Subject: pkg/twodspec/longslit/apextract.x [[ fixed in Feb release ]] + +Changed + int fopen(), ... +to + int open(), ... + +Would result in a "bad file descriptor" error message in IRAF/VMS since open() +function was assumed to be real instead of int. + +-------------------------------- +Tuesday 4-FEB-1986 13:40:44.07 + +Subject: sys/os/zopcpr.c [VMS Kernel] + +Added the following initialization code before the call to ZOPNPR to prevent +error recovery problems which occurred occasionally. + + *inchan = *outchan = XERR; + +-------------------------------- +Tuesday 4-FEB-1986 15:43:51.21 + +Subject: sys/tty/ttyputl.x [[ see below... ]] + +The parameter 'map_cc' in this routine is declared as 'int', but everything +that calls it (e.g. lprint, type, page, help), passes in a 'bool'. This is +probably a bug and most certainly a possible portability problem. I did not +change anything, but 'map_cc' should probably be treated as a 'bool' in this +routine. + +-------------------------------- +Wednesday 5-FEB-1986 13:47:01.28 + +Subject: pkg/cl/exec.c + +In mk_startupmsg(), added redirection support for STDERR, so the iraf main will +know about it as well as STDIN and STDOUT (for STDERR, the string sent down is +" 5> $"). A low-level SPP routine used by SDAS for error logging depends on +knowing the redirection status of STDERR. + +-------------------------------- +Wednesday 5-FEB-1986 16:30:12.55 + +Subject: sys/os/zfiopr.c [VMS] [[ in Feb release ]] + +Made changes in the memory allocation strategy. Instead of using _zmaloc and +then mapping to it, let the $crmpsc and $mgblsc system services create and map +the global memory sections. This is a simpler and more standard way of doing +things, according to the examples in the VMS documentation. The system service +$deltva is used to delete the sections. + +These changes were prompted by spurious errors when creating connected +subprocesses, with the following VMS error from $crmpsc: + + SECTBLFUL, section table (process/global) is full + +There is a system paramater (GBLPAGFIL) that controls this and may be too low. +However, the initial implementation of zfiopr with _zmaloc may have been +causing some troubles as well. Memory sections may not have been fully +unmapped/deleted because of problems with memory (de)allocation in the context +of global pagefile sections. The solution mentioned attacks this concern, +and it is better than changing system parameters in the long run. + +Inter-process communication still works fine with this new implementation of +zfiopr and I haven't been able to recreate the error above, so I'm hoping it's +fixed and behaves better as far as deallocation of global pagefile sections. + +Warning: DEC recommends that programs which allocate memory not mix allocation +techniques (lib$get_vm vs. $cretva/$expreg), so there still may be some strange +problems. The full warning is in the VMS System Services manual and some notes +on it are in sys/os/zvaloc.c. + +-------------------------------- +Wednesday 12-FEB-1986 09:07:16.44 + +Subject: sys/os/zmain.c [VMS] + +For interactive HOST and non-batch DETACHED processes, the error channel is now +set to the output channel explicitly. It used to be opened as a separate +channel to the VMS SYS$ERROR. This makes no difference within IRAF, as FIO +(and the CL) keeps track of them as separate entities. It does, however, give +us more control over the VMS SYS$ERROR stream, for example, to redirect +SYS$ERROR to a file to get SDAS tracebacks, etc. + +Also modified to translate SYS$ERROR for the logical assignments made when a +connected subprocess (rather than assigning in/out/tt/command to "SYS$ERROR"). + +-------------------------------- +Wednesday 12-FEB-1986 09:22:34.24 + +Subject: pkg/cl/eparam.c + +A number of changes have been made: + + - bug fixes for arrays and multiline prompts, and movement in + multiple pages when these things are around. + - bug fixes for old patches - the "real" bugs have been found + and fixed. + - enhancement for hidden parameters; now, Eparam output of hidden + params (when showall set in epinit) is similar to Lparam, i.e., + `(name = value) prompt' and for arrays, `(name) prompt \n values' + - updated and added comments where appropriate (and necessary) + - made all debugging/diagnostic code (within eparam) print at the + bottom of the screen, to prevent screen rolling while in eparam. + cldebug messages elsewhere still cause screen craziness, however. + - a bit of code reorganizing and cleaning up + +Eparam continues to get harder to debug. Some of the changes here will +hopefully make future debugging easier. At some point, much of this code +should probably be redesigned/rewritten (as mentioned before). + +-------------------------------- +Wednesday 12-FEB-1986 13:01:46.18 + +Subject: pkg/language/language.hd [[ use Feb release instead ]] + +Added entry for 'stridx', pointing at "string.hlp" + +-------------------------------- +Thursday 13-FEB-1986 13:08:00.00 + +Subject: pkg/cl/gquery.c + +This is used by EPARAM for checking ranges and enumerated values. Fixed some +bugs in the range message generation. Old messages would stay around in a +static array and show up on different parameters in Eparam; modified to null +out string when no range specified. Also did a little bit of cleanup on the +source file. + +-------------------------------- +Thursday 13-FEB-1986 13:13:01.10 + +Subject: sys/os/zxwhen.c [VMS] + +Changed TRACEBACK code (conditionally compiled to show VMS tracebacks rather +than recovering) to force traceback to a file as well as the terminal. This +also gets rid of the double traceback seen when subprocesses abort. The output +file is called ".ERROR", and will be written in the user's current directory +(if writable). + +-------------------------------- +Thursday 13-FEB-1986 17:12:52.80 + +Subject: pkg/cl/decl.c + +Changes to deal with parameters declared in the procedure statement that are +later defined as hidden. We print out a warning message and override the mode, +from hidden to auto. If the user really wants a parameter hidden, it should +not be in the procedure statement, as this can screw up positional arguments. + +-------------------------------- +Thursday 13-FEB-1986 17:54:59.57 + +Subject: abbreviations in the CL + +This "feature" continually comes up here at ST. A lot of people are writing +scripts here and always having problems with abbreviations. The comments +in the abbrev() function in pkg/cl/modes.c says that only interactive (or +batch) tasks can be abbreviated, meaning tasks called from within scripts +must always be fully spelled out. + +I imagine the original reason for this was to insure "good" script programming +practices at the expense of convenience. However, when writing front ends that +use tasknames as parameters and then call lparam, eparam, etc. (e.g., +system.mkscript), it forces the user to type the taskname in full, which makes +it inconsistent with normal interactive usage. + +-------------------------------- +Friday 14-FEB-1986 08:27:57.42 + +Subject: pkg/clpackage/clpackage.men [[ fixed ]] + +typo: 'utilties' --> 'utilities' for System package + +-------------------------------- +Friday 14-FEB-1986 09:35:58.21 + +Subject: package rearrangement for ST [[ to be further resolved ]] + +Put most of the KPNO-specific and general IRAF packages into a new package +called NOAO. This is to avoid name conflicts and confusion with the ST +software, especially SDAS and CDBS. The files affected are: + + lib/clpackage.cl + + lib/noao.cl + pkg/clpackage/clpackage.hd + pkg/clpackage/clpackage.men + + pkg/clpackage/noao.hd + + pkg/clpackage/noao.men + +CLPACKAGE now consists of: sdas noao language lists softools system. + +-------------------------------- +Friday 21-FEB-1986 14:34:26.46 + +Subject: lib/clpackage.cl login.cl [[ now vms/hlib/ ]] + +Changed startup file and template login.cl so filewait="no" is the default. +Too many "Waiting for access to file" messages, especially on the logfiles, +which are in heavy use around here for lots of things besides what the CL +puts in them. + +-------------------------------- +Tuesday 25-FEB-1986 13:48:30.21 + +Subject: pkg/cl/builtin.c + +clhidetask(): Removed check for tasks without parameter files. This should +not matter when hiding a task. The inability to hide foreign tasks prompted +this change. + +-------------------------------- +Monday 3-MAR-1986 13:25:02.14 + +Subject: pkg/cl/eparam.c + +Minor change in eparam to clear the bottom line before returning to the CL. +This clears the " for Help" message from the command line, to avoid +confusion. + +-------------------------------- +Thursday 6-MAR-1986 09:24:31.20 + +Subject: system package, copy and rename + +Copy does not allow wildcard files as output, but rename does. Thus, copy +seems to be modelled after the Unix cp whereas rename acts like the VMS task of +the same name. This seems inconsistent and is sometimes annoying to users +here. + +Also, if the copy command cannot read the input file for some reason, the +resulting error message says that it can't create the output file (because the +call to zfmkcp fails). This is misleading, and is due to the logic in +fio$fcopy and fmkcopy, which check only for the existence of the input file and +not whether it can be read. + + +---------------------------------------------------------- +Merge Notes -- NOAO Feb release +Starting March 6, 1986 Jay Travisano + +Mostly ST-specific notes, but some notes on VMS/IRAF... +---------------------------------------------------------- + +Read backup tape to [iraf.new...]. Will merge IRAFX changes into that and then + backup whole thing; NOAO has made a lot more changes than we have. + +doc/vmsnotes.* --> doc/ports/* + save old vmsnotes files, may be useful + +vms/hlib/irafuser.com + site-dependent changes; also added MYDISK job logical to deal with + dollar signs in disk names. Will change mkiraf.com to use MYDISK + if can't get rid of dollar sign in home disk. Also, reinstate + IMDIRDISK for the IRAFTMP directory... +*** + We don't have system logical names without '$' in them and even the + physical names have them too (VAX cluster). Having another system + logical name without the '$' is not the answer here, since we have + over 30 cluster disks. Forcing IRAF sites to change system logicals + is an unreasonable method to avoid the '$' (as the installation doc + recommends). It may be easy at NOAO but our experience here and + at other VMS-only sites shows otherwise; system managers around here + are even reluctant sometimes to raise users' paging file quotas, as + it requires more pagefile space on the system disks. + + One solution to this is to have a fully supported (consistent) escape + mechanism. The "disk\\$newton:[irafx]" works in most cases + and is used currently at ST. The MYDISK job logical for the home + directory in the login.cl also helps out. + + A better solution perhaps is to change vfnmap/vfntrans so that + during logical dir translation, a check is added to see if we have + an OS path. If so, don't bother rescanning the string for more + logical directories. This would allow + + set junk = "disk$newton:[iraf.local.jay]" + type junk$file + + and after the first translation of "junk$", it would realize that + we've got an OS path and continue on with the "file" portion. +*** + +vms/hlib/libc/iraf.h + site changes for ST; not crazy about site disk and dir names in this + file which must be moved to sys$library. assuming vms logicals + will be set correctly so won't need to read this file at run-time. + +vms/hlib/gripes.cl + added subject to mail message + use USERID instead of HOME for From field + +vms/hlib/install*.com + changed for ST; only install CL and SYSTEM package here + +vms/hlib/irafemacs.com + newer version of emacs command file, plus a few minor changes for IRAF + +vms/hlib/zzsetenv.def +vms/hlib/login.cl +vms/hlib/mkpkg.inc + setups for ST + +vms/hlib/mkiraf.com + use MYDISK job logical instead of SYS$DISK; avoids '$' garbage. + +vms/os/net/zfioks.c + turned on DECnet instead of TCP; never worked all that well, but we'll + try it again + +vms/os/zmain.c + merged in our changes and updated comments + +vms/os/zopcpr.c + merged in old change missing from noao distribution + +vms/os/zxwhen.c + merged in new traceback handling stuff + *NOTE*: this is currently turned ON for ST, for debugging of access + violations and arithmetic faults. To turn it off, #define NOTRACEBACK. + +vms/os/rms.c + (debug) references to EP2 changed to _EP2 + +vms/boot/spp/xc.c + added /EXTEND qualifier for Fortran; allow statements in cols 1-132 + +dev/devices + magtape entries for ST cluster + +pkg/cl/tests/* + Note in Unix notes file says this was deleted because it wasn't used + anymore. In fact, it has been used here at ST for (crude) regression + testing when making CL changes. Have moved these into my (Jay) + private directory in case they're needed in the future. + +vms/boot/spp/rpp/mkpkg.com + DCL syntax errors in "if f$search()" line: + () screwed up + "then" missing + (I booted the tools from scratch, to test everything out) + +pkg/cl/* + used ST version as a base; merged in NOAO changes where necessary + +pkg/cl/mkpkg + added lines to lex and yacc the grammar, if stsci and vms, since we + muck around with the grammar too. + also, typo in install comment (move to bin$, not lib$) + +vms/hlib/notes.com rcscom.com --> local/ + these are ST-specific tools; notes file (notes.st) will also be here + +doc/ports/ <-- old vms/ctio.hlp vmsprog.hlp (from old distribution) + +backup current ST develop/experimental version (IRAFX) to tape +backup new merged version to IRAFX +remake... +testing... +everything looks good... + +Networking w/ DECnet seems to work fine; tried remote file access, remote +subprocesses (will be useful for IDM access). Tried very simple remote tape +access and didn't work; seemed to abort quickly though as if it failed on +local host. The noao notes file says it won't work on VMS because of the +process structure; not sure what this means exactly -- looks like it should +work with the allocation built into the kernel server as it is now. Will +look into it more later... + +dev/hosts + set up ST nodes +*** + took out the single quotes on the vms executable name (from noao). + can't access "node!iraf$file" with them in, i.e., the "iraf$" + logical doesn't get set up correctly. appears that the quotes are + left over from some previous syntax. don't think noao has vms + servers (for tcp) yet (?). +*** + +vms/hlib/irafuser.com + changed most job logicals to process ones, since they aren't needed + at the job level, and job table space is limited around here. + (Process logicals are automatically copied when spawning DCL commands + or background jobs.) So, now (at least for ST), + job logicals: IRAFDISK (IMDIRDISK) IRAFTMP IRAFIRAF IRAFHOST + IRAFHLIB + process logicals: IRAFLIB IRAFBIN IRAFLIBC IRAFVMS batch-logicals + +vms/hlib/mkiraf.com + bypass sections that delete login.cl and uparm files; + let a new version of the login.cl be made in case user must go + back. for uparm files, the 'out of date' message will be enough + to tell the user to do an unlearn. besides, the sdas par files + don't change that much (or do they?) In any event, I'd get lots of + complaints if everyone's par files disappear when running mkiraf. + +vms/gdev/ + made library as is, to resolve link references w/ irafks, display and + cv. For deanza at ST, probably won't use this interface; easier to + use old deanza code until new display code and image interfaces are + in place. + +pkg/language/doc/edit.hlp + typo: edcapf --> edcap + +pkg/system/doc/directory.hlp + typo: \fb --> \fB + +pkg/* + many packages list a 'revisions' task in the help menu but don't + have one in the package; I imagine this is a future enhancement. + +pkg/images/tv/display/mkpkg + /deanza/* + Added temporary deanza code (vms and stsci dependent). Changed mkpkg + in display/ to make the deanza/ subdir instead. + +dev/graphcap + added entry for `deanza'; no more .imh files...Yeah! + added entries for Selanar-enhanced vt100 (vt100s), and Pericom. + +dev/termcap + added/updated ST entries. + +vms/hlib/clpackage.cl + changed 'page' to 'type'. if a long motd, user may inadvertantly + type ahead and get all screwed up, so just type the message out. + +pkg/cl/grammar.l + modified to accept double precision real numbers on input, e.g. + + cl> task.param=12d20 + + used to give a syntax error. Simple change in lex input, namely: + [eE] --> [eEdD] for real numbers. + +vms/as/README +vms/as/cstr.mar + + Added assembler versions of LIBC string routines; added to list in + README file. These are much faster than the LIBC string routines + written in C, and although they may not make a significant increase + in performance of the CL, we have them, so why not use them. + +sys/libc/mkpkg + Modified to use as$cstr.s if available, otherwise use the portable + routines written in C. + +vms/boot/mkpkg/mkpkg.help + typo: \fmkpkg --> \fBmkpkg + +math/mkpkg + added "$purge lib$" at end of 'mathgen' + +----------------------- +CL Logging Enhancements +Feb/Mar 1986 +----------------------- + +The following enhancements to the CL logging facilities were made: + + 1) a 'putlog' builtin was added, so a user's script or program + can log important messages and errors + 2) added logging from the CL itself, when script and executable + tasks are started/stopped (i.e., a task trace) + 3) errors are logged, from the CL, when from a script or executable + 4) background logging supported (a result of above changes) + +These functions are parameter controlled, by the CL parameter `logmode', e.g., + + cl> logmode = "commands background error trace" + (nocommands nobackground noerror notrace) + +The old `keeplog' parameter has the same function, turning the whole thing +on or off. + +Note: To avoid file access conflicts (e.g. bkg logging), the environment + variable 'filewait' must be set to "no". (This is now the default + at ST.) As a result, some log messages, especially those from the + background, may still not get to the (single) logfile. The use of + multiple logfiles is encouraged because of this, but SDAS developers + and testers prefer a single logfile with everything in it. Not much + we can do to change their minds. + + +Source changes in pkg/cl/: + +builtin.c + Added clputlog() function for the 'putlog' builtin. + Added code so that the clerror() function calls putlog with + the error message, when logging is on. + +history.c + Fixed the code for shared logfile access. Modified so login/logout + messages are not printed for background jobs. + Added putlog() function, which formats the log messages from the + user and/or the CL and writes to logfile. + Added reset_logfile() function to reopen logfile if name is changed. + This is only for share_logfile=no and has not been tested here, + but it's just a close and reopen. + +exec.c + Added code to log a message when starting/stopping a script or + executable task. This is the "trace" feature. + +bkg.c + Added code to log a message when a background job is started or + completes. + +errs.c + Added code to log the error messsage if a script or executable task + (and it hasn't already been logged by clerror()). + +param.h + Added P_CL value for p_flags field of the param structure. This + is used to test (quickly) whether a parameter is a CL parameter. + +param.c + Added check in paramset() for a CL parameter (p_flags & P_CL); + if so, call parse_clmodes() (below). + +modes.c + Added parse_clmodes(), to parse logging control parameter and + epinit/ehinit parameters and to call reset_logfile() if logfile + name is changed. + +clmodes.h + Added extern declarations for logging/epinit/ehinit variables + +eparam.c +history.c +cl.par + "epinit" and "ehinit" changed from environment variables to CL params + as per mail discussion with Doug. Removed all setoption() stuff as + this is now taken care of in parse_clmodes() (in modes.c). + +hlib/clpackage.cl + Removed epinit and ehinit env vars. + +hlib/login.cl + Added commented out default values for logging and epinit/ehinit + parameters to the template login.cl file. + +pkg/language/doc/cl.hlp + ehistory.hlp + eparam.hlp + Modified due to move of epinit/ehinit vars to CL parameters and + addition of new logging parameter. + +pkg/language/language.hd + language.men +pkg/language/doc/logging.hlp + + putlog.hlp + + Added help for the "logging" discussion and the "putlog" builtin. + The "logging" man page talks about the CL logging as a whole, + discussing the parameters involved in a little more detail than the + help on the cl. + +------------------- + +pkg/cl/* + Cleaned up some of the CL source code; mostly just removed some + old, useless cldebug statements, etc. Also cleaned up grammar.y + a lot, at least to make the style consistent and more readable. + Gram.c and decl.c also got a bit of this as well. + +pkg/cl/README + Updated text; still referred to Unix "make" and VMS DCL/Makelib + generation techniques. + +-------------------------------- +Monday 24-MAR-1986 12:01:48.70 + +Subject: VMS/IRAF Plotting + +dev/graphcap + Added entries for QMS, EQMS, and NULL (testing) for STScI. + +vms/os/ vms.h + zfipol.c + mcsub.c + + mkpkg + +Implemented ZFIOPL for VMS to use NCAR Metacode translator (MCVAX). A +spoolfile is written in the necessary VMS file format by ZFIOPL. On close, +MCVAX is started up as a subprocess and commands are sent to it to set the +device (from graphcap DD string), read the spoolfile, and plot until finished. + +This code may depend on peculiarities of the ST version of MCVAX which I don't +know about. + +-------------------------------- +Tuesday 25-MAR-1986 11:53:12.75 + +Subject: vms/boot/bootlib/vfn2osfn.c + +Changed to return a null string if an error occurs mapping the file; it used to +return the last result of a filename mapping operation. This would to lead to +problems in mkpkg, e.g., + + $delete dir$sub/file.c + +If this file did not exist, the previous filename returned by vfn2osfn() would +be deleted. + +-------------------------------- +Wednesday 26-MAR-1986 12:04:53.81 + +Subject: mkpkg + +vms/boot/mkpkg/tok.c + $ifdef/$ifndef was not working -- bug when setting boolean variable; + fixed. + + changed os_cmd() to host_xc() for do_omake(), do_link(), do_xc(), so + the VMS DOCVCL routine can be used (to eliminate some spawning). + +vms/boot/mkpkg/host.c + docvcl() -- don't check return status and change to XYES/XNO; + leave as is (OK or ...) + + added host_xc() routine to call docvcl(). + +vms/boot/spp/xc.c + bug fix -- `firstobj' variable was not being reinited to NULL; caused + problems with above host_xc() changes. Added reinit in do_cleanup(). + +vms/boot/mkpkg/mkpkg + added ../spp/xc.c dependency for xcsub.c + +-------------------------------- +Friday 28-MAR-1986 09:37:16.83 + +Subject: ttyputline and map_cc + +pkg/system/lprint.x + page.x + type.x + ./help/houtput.x + + Changed map_cc from bool to int to work correctly with ttyputline(), + which expects an int and checks for YES/NO. In VMS Fortran, .true. is + encoded as a -1, not a 1 (YES). To change ttyputline() would mean + changing the LIBC interface c_ttyputline() so that it knew about this + feature of the host Fortran, so let's use the int YES/NO method. + +-------------------------------- +Friday 28-MAR-1986 10:12:49.38 + +Subject: graphcap entry for selanar hirez 100xl + +Not sure if this is a graphcap entry problem or a limitation on the selanar +itself: When in cursor mode in a task (e.g. onedspec.splot), typing 'c' to +print the cursor position will print "x,y: ... ..." in the lower left hand +corner, but then immediately erase it. Help via '?' does the same thing, i.e., +gets printed and erased immediately. + +-------------------------------- +Wednesday 2-APR-1986 13:22:46.16 + +Subject: pkg/cl/edcap.c + +Added the editor name to the eparam help page. + +-------------------------------- +Wednesday 2-APR-1986 15:24:20.96 + +Subject: vms/boot/bootlib/dcl.c + +Added interrupt support. When ^C typed, return status of dcl() (and os_cmd) +will be SYS_XINT, so MKPKG can deal with the error as on Unix. + +-------------------------------- +Wednesday 2-APR-1986 16:51:37.03 + +Subject: vms/boot/spp/... + +xc.c fixed inconsistencies in error/status checking, removed + old code, rearranged some functions (main to front, etc)., + and general cleanup. +xc.com command file to make xc (only) +mkpkg.com call xc.com + +-------------------------------- +Thursday 3-APR-1986 08:06:49.57 + +Subject: editor + +Just realized that "editor" is still an environment variable, used by +eparam/ehistory and the edit builtin. Epinit/ehinit have been changed to CL +parameters during the logging changes, but I forgot about this one. + +Should we change "editor" to a CL parameter, too? If so, it would require +changes in pkg/cl/edcap.c,builtin.c,cl.par and the help files for +eparam,ehistory,edit,cl. 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 + cr=100 + ds=54640 + +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 + (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. diff --git a/doc/ports/sun2_032786.doc b/doc/ports/sun2_032786.doc new file mode 100644 index 00000000..298139db --- /dev/null +++ b/doc/ports/sun2_032786.doc @@ -0,0 +1,152 @@ +SUN/IRAF V2.2 Installation, 6 March 1986 Sun-2, software floating point +------------------------------------------------------------------------------ + +/usr/iraf/***** +/usr/iraf + Located IRAF root directory at /usr/iraf, created iraf/local + for personal file storage. Unpacked tar archive of v2.2, 6 Mar + version, from master VAX/UNIX system "lyra". (3/6) + +/usr/iraf/local/ + Unpacked earlier Sun archive of /usr/iraf/local; this contains + development stuff for Sun graphics kernels, plus the .login file + for the IRAF account. It is important that this file sources + $iraf/unix/hlib/irafuser.csh to pick up environment definitions + and aliases. Make sure iraf root and home directories match + the real thing. (3/6) + +unix/as +unix/as/ishift.s +unix/as/zsvjmp.s + Moved the VAX as/ to unix/vaxas. Created an empty unix/as and + copied the two SUN .s files into it from unix/mc68000. (3/6) + +unix/hlib/mach.h +unix/hlib/libc/spp.h + Set EPSILONR and EPSILOND for the SUN as in unix/mc68000/README. + Set BYTE_SWAP2 and BYTE_SWAP4 to NO in mach.h. (3/6) + +unix/hlib/mkmlist.csh + Changed bgrep to grep, since bgrep not available in standard + UNIX. (Not important, doesn't have to work, so the efficiency + of bgrep on the development machine is worth the mach. dependence.) + (3/6) + +home$.login +unix/hlib/mkiraf.csh +unix/hlib/libc/iraf.h + Changed all occurrences of iraf root directory pathname. (3/6) + +unix/hlib/mkpkg.inc + Set USE_CALCOMP to no. (3/6) + +/usr/include/iraf.h -> $hlib/libc/iraf.h + Establish this symbolic link as superuser (i.e. %su; cd /usr/include; + ln -s $hlib/libc/iraf.h iraf.h). This is necessary for compiling + IRAF programs. (3/6) + +TODO: unix/hlib/[dif]mach.f + These files were NOT set up for the Sun, since we did not have the + values, but this should be done later. Once modified, a mkpkg at the + root will recompile all affected programs. + +TODO: unix/as/*.x + It would be nice to have some additional assembler modules for + efficiency reasons. See unix/vaxas. Coding of these can be left + for later. + + +/usr/iraf/hlib/libc/kernel.h + Commented out DEBUGMEM in order to use the standard UNIX malloc rather + than IRAF's version. This is necessary for some reason on the Sun for + SunCGI programs to be callable from SPP programs. (3/6) + +------------------------------------------------------------------------------ +That completes the initial setup. Now we bootstrap the system. + + % cd $iraf/unix + % sh -x mkpkg.csh >& spool & + +This builds all the bootstrap utilities, then as a final step compiles the +portion of LIBSYS in host/gdev, which exercises MKPKG, XC, etc. If all that +works things are in excellent shape. (3/6) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e + Establish these symbolic links as superuser (e.g. cd /usr/include; + ln -s $hlib/mkiraf.csh mkiraf). These are required for regular + users who do not have a .cshrc or .login which sources + $iraf/unix/hlib/irafuser.csh, for running the cl or mkiraf. + Ordinarily we only link xc, mkiraf, and mkpkg here, but since we're + doing development on the Sun outside IRAF, the rest are useful. (3/6) + +unix/hlib/alloc.e + This file must belong to root, since it needs root permissions at + runtime to allocate devices. Do the following: + + % cd $hlib + % su + % /etc/chown 0 alloc.e (3/6) + +------------------------------------------- +The bootstrap is now complete. The next step is to do a full system compile. + +There are 5 files that need to be hand-compiled without optimization (from +previous experience on the SUN) to avoid getting in an infinite loop in pass +c2 of the compiler. "xc -c" each file to create an object file in its +directory; mkpkg will then avoid recompiling it. Note: see local/bugs +README for description of "-P" for partial optimization instead. + + sys/fio/fstati.x + math/bevington/matinv.f + sys/gio/nspp/portlib/gridal.f + sys/ki/irafks.x + pkg/twodspec/longslit/transform/igsfit/igsfit.f + +(The last file wasn't included in the initial hand-compile, but stalled +the later sysgen in an infinite loop; placed here for completeness next time.) +Now perform the full system compile (sysgen). + + % cd $iraf + % mkpkg >& spool & (3/6) + + The sysgen was started at 17:02 on March 6, 1986. It stalled at 9:47 + Friday March 7, in an infinite loop in: + pkg$twodspec/longslit/transform/igsfit/igsfit.f + I hand-compiled it and restarted the sysgen at 13:30, renaming the first + spool file spool1. (3/7) + + The sysgen finished at 15:53 with no further errors (the "Termination + code 9" in $iraf/spool is due to another stall in igsfit -- I had + hand-compiled the wrong file, so mkpkg stalled again; this time I just + killed the lowest-level process and ran mkpkg from longslit/transform + by hand during the main sysgen, and later checked that there weren't + any collision problems). + + Clock time was thus 19:08 hours, but at least 5 of these hours saw two + interactive users (mostly editing, but some compiling) competing for + resources. (3/7) + +/usr/bin/xc -> $hlib/xc.e + Established this symbolic link as superuser, now what we have a + CL in $iraf/bin. This completes the software-building part of the + installation. (3/7) + +unix/as/ishift.s + Would not do a right shift, since the 68010 uses two different + instructions to do left and right shifts, unlike the vax, which + allows the shift argument to be negative. Changed to use the ROL + and ROR instructions. (3/14) + +sys/gio/stdgraph/stgdrawch.x + When stdgraph kernel attempted to draw high-quality text, it + began drawing lines and garbage text all over the screen until it + hit a segmentation violation. Traced to module sgch_flush(), + "call stg_polyline (pl, op / 2)", (SHORT op), where stg_polyline + wanted an INT for the 2nd argument. Changed to "int (op / 2)". (3/27) diff --git a/doc/ports/sun2_042386.doc b/doc/ports/sun2_042386.doc new file mode 100644 index 00000000..c2807994 --- /dev/null +++ b/doc/ports/sun2_042386.doc @@ -0,0 +1,141 @@ +SUN/IRAF V2.3 Installation, 17 April 1986 Sun-2, software floating point +------------------------------------------------------------------------------ + +/usr/iraf/***** +/usr/iraf + Located IRAF root directory at /usr/iraf, created iraf/local + for personal file storage. Unpacked tar archive of v2.3, 17 Apr + version, from master VAX/UNIX system "lyra". (4/17) + +unix/as +unix/as/ishift.s +unix/as/zsvjmp.s + Moved the VAX as/ to unix/vaxas. Created an empty unix/as and + copied the two SUN .s files into it from unix/mc68000. (4/17) + +unix/hlib/mach.h +unix/hlib/libc/spp.h + Set EPSILONR and EPSILOND for the SUN as in unix/mc68000/README. + Set BYTE_SWAP2 and BYTE_SWAP4 to NO in mach.h. (4/17) + +unix/hlib/mkmlist.csh + Changed bgrep to grep, since bgrep not available in standard + UNIX. (Not important, doesn't have to work, so the efficiency + of bgrep on the development machine is worth the mach. dependence.) + (4/17) + +home$.login +unix/hlib/mkiraf.csh +unix/hlib/libc/iraf.h + Changed all occurrences of iraf root directory pathname. (4/17) + +unix/hlib/mkpkg.inc + Set USE_CALCOMP to no. (4/17) + +/usr/include/iraf.h -> $hlib/libc/iraf.h + Establish this symbolic link as superuser (i.e. %su; cd /usr/include; + ln -s $hlib/libc/iraf.h iraf.h). This is necessary for compiling + IRAF programs. (4/17) + +unix/hlib/[dir]1mach.f + Commented out the VAX data statements, and uncommented the IEEE/ + 68000 data statements. (4/17) + +TODO: unix/as/*.x + It would be nice to have some additional assembler modules for + efficiency reasons. See unix/vaxas. Coding of these can be left + for later. + +/usr/iraf/hlib/libc/kernel.h + Commented out DEBUGMEM in order to use the standard UNIX malloc rather + than IRAF's version. This is necessary for some reason on the Sun for + SunCGI programs to be callable from SPP programs. (4/17) + +------------------------------------------------------------------------------ +That completes the initial setup. Now we bootstrap the system. + + % cd $iraf/unix + % sh -x mkpkg.csh >& spool & + +This builds all the bootstrap utilities, then as a final step compiles the +portion of LIBSYS in host/gdev, which exercises MKPKG, XC, etc. If all that +works things are in excellent shape. (4/17) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + Establish these symbolic links as superuser (e.g. cd /usr/include; + ln -s $hlib/mkiraf.csh mkiraf). These are required for regular + users who do not have a .cshrc or .login which sources + $iraf/unix/hlib/irafuser.csh, for running the cl or mkiraf. + Ordinarily we only link xc, mkiraf, and mkpkg here, but since we're + doing development on the Sun outside IRAF, the rest are useful. (4/17) + +unix/hlib/alloc.e + This file must belong to root, since it needs root permissions at + runtime to allocate devices. Do the following: + + % cd $hlib + % su + % /etc/chown 0 alloc.e (4/17) + +------------------------------------------- +The bootstrap is now complete. The next step is to do a full system compile. + +There are 5 files that need to be hand-compiled without optimization (from +previous experience on the SUN) to avoid getting in an infinite loop in pass +c2 of the compiler. "xc -c" each file to create an object file in its +directory; mkpkg will then avoid recompiling it. Note: see local/bugs +README for description of "-P" for partial optimization instead. + + sys/fio/fstati.x + math/bevington/matinv.f + sys/gio/nspp/portlib/gridal.f + sys/ki/irafks.x + pkg/twodspec/longslit/transform/igsfit/igsfit.f + + (The following two entries are from the previous NOTES file on tucana; + I'm not sure if this ishift is the correct one: Doug indicated that + the fixed ishift on tucana hadn't made it back to lyra, but DIFF showed + only half of a comment line difference between the lyra version and the + version unpacked from the $iraf/unix directory in the tucana archive. + The stgdrawch.x fix also hadn't made it back to lyra prior to cutting + the tape for this installation.) + + unix/as/ishift.s + Would not do a right shift, since the 68010 uses two different + instructions to do left and right shifts, unlike the vax, which + allows the shift argument to be negative. Changed to use the ROL + and ROR instructions. + + sys/gio/stdgraph/stgdrawch.x + When stdgraph kernel attempted to draw high-quality text, it + began drawing lines and garbage text all over the screen until it + hit a segmentation violation. Traced to module sgch_flush(), + "call stg_polyline (pl, op / 2)", (SHORT op), where stg_polyline + wanted an INT for the 2nd argument. Changed to "int (op / 2)". + +Now perform the full system compile (sysgen). + + % cd $iraf + % mkpkg >& spool & (4/17) + + Begun at Thu Apr 17 13:13:22 MST 1986; ended at Fri Apr 18 06:35:16 + MST 1986, for a sysgen time of 17h22m. The only suspicious thing in + the spoolfile was in XTOOLS, where mkpkg could not find module or + label "generic". (4/20) + +$iraf/bin/x_cv.e +$iraf/bin/x_display.e +$iraf/vms/ + Removed these files and directories to free up disk space. (4/20) + +(help database) + Ran MKHELPDB from the CL, having neglected to do so immediately + after the sysgen. (4/23) diff --git a/doc/ports/sun2_062486.doc b/doc/ports/sun2_062486.doc new file mode 100644 index 00000000..d483e475 --- /dev/null +++ b/doc/ports/sun2_062486.doc @@ -0,0 +1,134 @@ +SUN/IRAF V2.3 Installation, 13 June 1986. Sun-2, software floating point +-------------------------------------------------------------------------------- + +/usr/iraf/ + Ran rmbin on bin, sys, pkg, math, lib, local, unix. Unpacked + source-only archive from master VAX/UNIX system "lyra" of + 12-June-86 17:00. (6/13) + +unix/as/ +unix/as/ishift.s +unix/as/zsvjmp.s + Deleted VAX contents of as/, copied mc68000/ishift.SUN and + zsvjmp.SUN to as/*.s. (6/13) + +unix/hlib/[dir]1mach.f + Commented out pdp (vax) data statements and uncommented IEEE + statements. (6/13) + +unix/hlib/mach.h +unix/hlib/libc/spp.h + Replaced EPSILONR and EPSILOND with values from unix/mc68000/README. + Set both BYTE_SWAPs to NO in mach.h. (6/13) + +unix/hlib/mkiraf.csh + Edited iraf root to new pathname. (6/13) + +unix/hlib/mkpkg.inc + Set USE_CALCOMP to "no". (6/13) + +unix/hlib/libc/iraf.h + Changed iraf root pathname. (6/13) + +unix/hlib/libc/kernel.h + Commented out DEBUGMEM (i.e. use standard UNIX malloc()) + in order that spp programs can call SunCGI. (6/13) + +unix/ + Bootstrap (sh -x mkpkg.csh); no problems. (6/13) + +unix/hlib/alloc.e + As su, "/etc/chown 0 alloc.e" so it can allocate devices. (6/13) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + Made sure these symbolic links existed. (6/13) + +-------------------------------------------------------------------------------- +Bootstrap is complete. Hand-compile the Sun f77 optimizer-bug routines before +performing the full recompile sysgen. + +sys/fio/fstati.x F77 runtime +math/bevington/matinv.f F77 runtime +sys/gio/nspp/portlib/gridal.f F77 runtime +sys/ki/irafks.x F77 runtime +noao/twodspec/longslit/transform/igsfit/igsfit.f F77 runtime + All these files have to be hand-compiled without optimization + from previous experience with the Sun V2.0 f77 compiler; none + of these files nor their .x parents have changed since last + built on a Sun-2. (6/13) + +iraf/ + Began full compile & link sysgen at 16:33. (6/13) + +fio/fioclean.x + Fixed null pointer bug. (6/14) + +bin/x_display.e +bin/x_cv.e +images/tv/cv/libpkg.a +images/tv/display/libpkg.a + Removed to free up disk space. (6/14) + +$iraf + Unpacked an incremental archive from lyra! to bring us current + to 09:15 June 20, 1986. Performed an incremental sysgen from + the root. (6/20) + +noao/twodspec/apextract/* + The preceding sysgen failed to find all files in icfit/* except + for 3 source files. To be safe, I (sr) made a complete archive + of apextract from lyra at 10:20, unpacked it, and did a "mkpkg + update" from here. (6/20) + +pkg/images/geometry/t_imtranspose.x F77 runtime + f77 optimizer bug was causing "Pixel subscript out of bounds" + in imtranspose. Compiled without optimization from cl with + "cl> !mkpkg xflags=-c; cd ..; mkpkg update". (6/20) + +noao/twodspec/apexold/* + Because of old file dates and because this directory on lyra + was created only by renaming the directory itself, it didn't + get copied in the incremental tar earlier this week. Made + a fresh archive on lyra and a "mkpkg update". (6/20) + +$iraf + Unpacked a lyra! incremental archive taken at 14:40 June 21; + performed a root incremental sysgen. (6/21) + +$iraf + Unpacked a lyra! incremental archive taken at 08:10 June 23; + performed a root incremental sysgen. (6/23) + +noao/lib/scr/* +noao/twodspec/apexold/* +noao/twodspec/apextract/* + Replaced with full archives from lyra! to attempt to clear up bugs + possibly related to renaming, rather than copying, files on lyra! + since the June 12 full archive -- these could be missed by the + incremental archives (find . -mtime -N). MKPKG updates in both + apextract directories. (6/23) + +pkg/cl/unop.c + Changed call to sscanf (sval, "%f", &rresult) in case OP_REAL to + sscanf (sval, "%lf", &rresult) because on SUNs, only the first + four bytes starting at rresult were being written into (rresult + is declared "double"). Should be changed on master system as well. + (6/23) + +-------------------------------------------------------------------------------- +June 24, 1986: Extensive testing for several days has revealed no further +bugs particular to the SUN-2 in its implementation at NOAO (SUN V2.0, no +fpa, no array processor). Although we do not have a 1/2" tape drive on the +SUN-2, the SUN-3's have a known bug which appears to be SUN's problem -- +I/O error when trying to backspace-record when the drive is positioned between +the two EOF marks written at close time. It is probable we will have a +workaround for this bug in early July. +-------------------------------------------------------------------------------- diff --git a/doc/ports/sun2_102885.doc b/doc/ports/sun2_102885.doc new file mode 100644 index 00000000..adf5055c --- /dev/null +++ b/doc/ports/sun2_102885.doc @@ -0,0 +1,190 @@ +SUN/IRAF V2.0 Installation, 28 October 1985 Sun-2, software floating point +------------------------------------------------------------------------------ + +find . \! -type d -print > _files # get list of nondirectory files +grep '\.[aoe]$' _files > _bin # find binaries +grep '\.s$' _files > _mach # find assembler files +ls _bin | grep '[2-9] iraf' > _links # find binary files with links +rm _bin # delete binary files + +deleted all .[aoe] files (22 Mb) +not necessary to edit Makefiles + +/usr/include/iraf.h + Made symbolic link in pointing to /iraf/lib/libc/iraf.h; necessary + before compiling any C programs. + +built mklib.e +built preprocessor: xc.e, xpp.e, rpp.e +built generic.e (had to do this manually; no Makefile) + lex generic.l; cc lex.yy.c -lln -o generic.e + +/usr/bin + Made symbolic links for unix tasks cl, xc, mklib, mkiraf + +lib/*.e + Made symbolic links for xc.e, xpp.e, rpp.e, mklib.e generic.e + +lib/libc/spp.h +lib/mach.h + Changed defn of machine epsilon (use Fort program in osb). + Set byte swap flags to NO. + +sys/os/zsvjmp.s + Replaced VAX version with MC68000 version. + +sys/osb/bitpak.s +sys/osb/bitupk.s +sys/osb/bytmov.s + Edited Makelib to replace bitpak.s and bitupk.s with the portable + version in bitfields.c. Likewise replaced bytmov.s with bytmov.c. + +sys/vops/ak/Makelib +sys/vops/lz/Makelib + Commented out the VAX .s optimized files in the Makelib, and + uncommented the portable .x versions. + +cd sys; make >& spool & # start sysgen of system libraries + (pass c2 of f77 hung in infinite loop on fio$fstati.f; optimizer bug) + +cd libc; mklib -O >& spool & # make libc.a (C runtime library) + + +(peruse output from sysgen and fix compile time bugs) +---------------------------------- + +sys/gio/gki/gkigetwcs.x + Array 'ret' no longer used, deleted. + +sys/vops/achtXY + When datatype X is the same as Y, the loop variable I is not used + (no action taken). + +pkg/softools/boot/spp/xpp/decl.c + The XPP declarations code which output the argument list for a + procedure could sometimes generate an output line too long for RPP to + handle. The code was breaking the argument list after 8 arguments + had been output, a simplistic technique which would fail when the + identifiers were too large. Changed to keep track of the output + column and break lines that are close to 80 cols in length. + +sys/libc/ckimapc.c + Local variable maxch redefines argument; argument maxch not used to + control length of output string. + +pkg/system/x_systest.x +pkg/system/system.cl + Procedure mtdevlist was still being referenced in this package. + +(system package, cl came up with no problems) + + +cd math; make >& spool & +------------------------------------- + +math/Makefile +math/Makelib + Added a Makelib to the math directory, with an entry for each math + package. Set up Makefile to make all the libraries. Must still + be linked to lib when done, if not already. + +math/bevington/matinv.f + Apparent optimizer failure in matinv.f. Recompiled successfully + without optimization. + +(all other math libraries compiled successfully; linked em all into /iraf/lib) + + +cd /iraf; csh -x Mkpkg.sh >& spool & +----------------------------------------------- + +pkg/*/Mkpkg.sh + The "rm -f *.e" causes the script to abort without doing anything if + there is no .o or .e file to delete. Got around this with a temporary + fix, i.e, making a junk.e in each directory before doing the rm. + +As expected, the links failed due to the following libraries not being present +in lib$ yet: + + all math libraries math/ + xtools pkg/xtools + nspp sys/gio/nspp + ncar sys/gio/ncarutil + gks sys/gio/gks + calcomp local UNIX (not IRAF) library + +sys/gio/ncarutil/ishift.s +sys/gio/nspp/ishift.s + Wrote SUN/MC68000 version. + +sys/gio/nspp/* + The usual complaints about questionable or nonportable constructs + in the NCAR fortran. + +sys/gio/nspp/nspp/gridal.f + Optimizer failure. + +sys/gio/nspp/utilities/conrec.f + Invalid hollerith specification on line 387; count is incorrect due + to continuation. Changed to quoted string. + +pkg/Mkpkg.sh + Reordered packages to make the lower level packages first. + In particular, imred cannot be made until after onedspec. + +pkg/softools/boot/spp/xc.c +pkg/softools/boot/spp/xpp/xppmain.c + Added a fflush(stderr) after each write to stderr. On the SUN stderr + appears not to be flushed automatically when i/o is redirected to an + ordinary file. + +pkg/dataio/lib/cyboow.s + Wrote a stubbed out SPP version of these procedures so that the DATAIO + package can be linked. + +pkg/images/tv/display/t_mkdisplay.x + Changed the obsolete IM_PIXELS to IM_PIXOFF. + +pkg/twodspec/longslit/Makefile + Would not make the library before linking, causing a rebuild to fail. + x_aperture.e was made first, but mklib was called only for x_longslit.e. + +ADB usage note: + Breakpoints should be set at procedure+4 to get a correct stack trace + showing the arguments to the procedure (vs. +2 on the VAX). + +pkg/twodspec/longslit/Makefile (etc. in subdirs) + Turned off the -F -g; this is for debugging and should NOT be turned + on in an installed package (the images are larger and there is no + optimization). Also, the f77 compiler aborted with a DBX error + related to a call to an external procedure passed as an argument to + a procedure (file igsfit.f). I did not investigate further; hand + compilation of the procedure worked. + +sys/libc/cfpath.c + The third (maxch) argument was being passed to FPATHNAME by value + rather than by reference. + +dev/uhosts +dev/hosts +dev/hostlogin + Added more machines to the network tables. + +pkg/images/Mkpkg.sh + Added entry for subpackage imdebug. + +pkg/images/imdebug/Mkpkg.sh + New file. + +dev/helpdb + Recompiled the help database (in the CL using the mkhelp task in the + softools package). + +sys/libc/cfmapfn.c + The third (maxch) argument was being passed to FPATHNAME by value + rather than by reference. + +pkg/system/allocate.cl + As a temporary fix, commented out the call to UNIX to allocate a + device. Removed the enumerated device names from the parameter file + since device names are not constant strings (this was never correct). diff --git a/doc/ports/sun2_skyfpa.unc b/doc/ports/sun2_skyfpa.unc new file mode 100644 index 00000000..fcc97f48 --- /dev/null +++ b/doc/ports/sun2_skyfpa.unc @@ -0,0 +1,168 @@ +SUN/IRAF installation U. North Carolina, Sun-3 UNIX on Sun-2 hardware. +Beginning 24 September 1986, dct. +---------------------------------------------------- + +unix/... + Deleted all binary files (should have been done before distribution). + (9/24) + +local/.login +unix/hlib/mkiraf.csh +unix/hlib/mkpkg.inc + Changed the -f68881 flags to -fsky. (9/24) + +cd unix; sh -x mkpkg.csh >& spool & + Started up the first bootstrap. (9/24) + +------------------------- +(Resume 27 Sept) +Bootstrap succeeded without any apparent problems, except that there were +still binaries in lib, so the mkpkg in gdev did not recompile the IIS +interface into libsys.a. + + - Ran RMBIN on the non-HSI directories to get rid of the binaries. + Worked fine, except that it also deleted the .login file which + contained some control codes which fooled RMBIN into thinking it + was a binary file. + +Next, tried mkpkg again in GDEV. This failed immediately with RPP generating +an error message something like `unknown x$type directive'. Traced this to +a Fortran optimizer bug in rpp/ratlibf/enter.f. Compiled that module and +tried again. Failed again: this time it ran, but some of the symbols came +out with all the characters set to the | character. Traced this one to yet +another (very similar) optimizer bug in spp/rppfor/ludef.f. Fixed that one +and relinked, and this time was able to compile GDEV, although by this time +I have little confidence in the quality of the compiled objects!! + +local/bugs/unc/enter.[fs] +local/bugs/unc/ludef.[fs] + Generated the assembler for these bugs and captured it with tip so + that we can send it to the place where bugs go at SUN. (9/27) + +unix/hlib/SUN_kludge/precomp.csh + Changed the -f68881 switches to -fsky. (9/27) + +----------------------------------------------- +Started the first full sysgen. + cd $hlib/SUN_kludge; precomp.csh + cd $iraf + mkpkg >& spool & (9/27) + +unix/hlib/mkiraf.csh + Set root imdir to /usr/tmp. (9/28) + +Sysgen Progress: (9/28) + There were a couple of problems with the sysgen, but mostly it seems to + be running ok. This machine is very slow, the Sun-3 is MUCH faster. + + [1] When I rebuilt gdev manually (due to the problems with the SPP), + I was in a subdirectory hence did not make everything. This caused + some of the links in the main sysgen to come up short. This is + not unusual; probably a mkpkg gdev should be included in the + main sysgen, just in case it was missed in the bootstrap, or in + case libsys.a was deleted. + + [2] There were some f77 failures in VOPS, despite the reduction in the + command line lenth to 400. This is almost certainly a bug in the + f77 program itself. The error message is + + Compiler error on line 0 of (null): invalid flag c + + Where c is some character. This always happens to a file at or + near the end of the file list (maybe 384 would be a good length?). + The workaround until Sun gets this fixed is simply to mkpkg + again, that will recompile the remaining files. + + NOTE - NOTE - NOTE - I just discovered some Sun docs noting bugs + in the V3.1 f77. One is "f77 cannot handle more than about forty + source files in a single command". This is the problem we have + here. + + (fixed these items and restarted sysgen, keeping libraries thus far + (compiled intact.) + +unix/boot/mkpkg/host.c + Decreased the size of the host command line to 320 characters to + avoid the above mentioned f77 40-file bug. (9/28) + +--------------------------------------- +Begin testing, x_system.e, cl.e,... + We have very serious problems here. x_system.e runs, but most of + the tasks misbehave in one way or another. The cl just hangs up + during startup. + +unix/os/zmain.c +unix/os/zopdpr.c +unix/os/zfiopr.c +unix/os/zoscmd.c + The runtime problem mentioned above turned out to be due to the Sky + floating point board ignoring all floating point instructions; the + last operand sent would be the one read back, with no operation + being performed. Took a while to figure this one out: everything + was being compiled and linked correctly with the -fsky option, + and indeed the skyboard startup code was being called during process + startup. + + What it finally turned out to be was the series of close() cy{alls in + the IRAF main. These were used to close the unwanted file + descriptors inherited from the parent process via the usual UNIX + convention of passing all open files on to the child. Unfortunately, + the sky board is opened as a file during process startup, before the + IRAF main is entered, hence the IRAF main would immediately close + it down and all floating point would thereafter fail miserably. + + The solution was to use the new 4.2BSD `fcntl' to set the close-on-exec + flag on the unwanted file descriptors (3 on) before calling execl(). + It is conceivable there might be problems with using this in + conjunction with vfork (don't want to affect parents file descriptors, + e.g., if execl fails), but I think it will probably work; more + testing is warranted later. (^R +{9/28) + +-------------------------------------------- +With this fix and a relink, CL runs, spawning system process, etc. +Sysgen resumed at its incredibly slow pace; will check back later for further +tests. (9/28) + +Sysgen completed normally (Monday 29 September) +Begin testing. + +sys/gio/gascale.x + IMPLOT failed immediately on the first attempt. The problem was traced + to a Fortran optimizer bug in this routine - very straightforward code, + too. My confidence in this compiler is pretty low this point. + A few more of these, and we should recompile the entire system without + optimization; it is probably already justified. (9/28) + + Moved sample bug file into in local/bugs/unc. It is a register + allocation bug in a case statement; the code is testing the value of + a register that was never loaded with the value it is supposed to + be testing. + +image templates + The image template code is returning garbage image names; imheader, + imstat, etc., fail on dev$pix. + +---------------------------------------- +That does it, we recompile everything without optimization. The bootstrap +appears to be ok, so we will not redo that. Probably VOPS can be compiled +with optimization, that would gain back much of the speed for image operators. +I will leave the executables in case anyone wants to use them; they will be +replaced automatically when the sysgen reaches the link stage. (9/29) + +unix/hlib/mkpkg.inc + Remove -O flag. (9/29) + +cd $hlib/SUN_kludge; precomp.csh + This step not necessary since we are not using the optimizer, + nor the -f68881 switch, which gave problems with complex. (9/29) + +cd $iraf; rmbin lib pkg noao (except keep the optimized VOPS) +cd gdev; mkpkg +cd $iraf; mkpkg >& spool & (and renice it) + +--------------------------------- +Sysgen completed; ran a few tests and things?`[5'4llright. (9/30) + + TODO: as root, `chown 0 $hlib$alloc.e' + backup system, strip it to save space (probably) diff --git a/doc/ports/sun3_042586.doc b/doc/ports/sun3_042586.doc new file mode 100644 index 00000000..03f26c72 --- /dev/null +++ b/doc/ports/sun3_042586.doc @@ -0,0 +1,250 @@ +SUN/IRAF V2.3 Installation, 14 April 1986 Sun-3, software floating point +------------------------------------------------------------------------------ + +/usr/iraf/ + Unpacked a source-only TAR archive made on lyra this afternoon; + didn't first delete anything. Made sure we had a .login with + $iraf defined as the local IRAF root (/usr/iraf/). (4/14) + +/usr/include/iraf.h + As Superuser, "ln -s unix/hlib/libc/iraf.h ." (4/14) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + As Superuser, performed these symbolic links. (4/14) + +unix/hlib/mkiraf.csh +unix/hlib/libc/iraf.h + Modified IRAF root pathname, HOST definition; irafuser.csh not + modified, as $iraf is defined in the IRAF account .login. (4/14) + +unix/hlib/mkmlist.csh + Changed bgrep to grep, since bgrep not available in standard + UNIX. (Not important, doesn't have to work, so the efficiency + of bgrep on the development machine is worth the mach. dependence.) + (4/14) + +as/ +vaxas/ +mc68000/ + Moved as/ to $iraf/vaxas/; moved $iraf/mc68000/ishift.SUN, + zsvjmp.SUN to as/ishift.s, zsvjmp.s. (Now that we have a + SUN-3 with 68020, the BYTPAK etc. assembler sources should also be + implemented). (4/14) + +unix/hlib/mach.h +unix/hlib/libc/spp.h (EPSILON) + Compiled osb$zzeps.f with "f77 -O -f68881 -o zzeps.e zzeps.f"; + ran it to check hardware floating point epsilon; turned out to + be same as software floating point to 4 places. Modified machine + epsilon and byte-swapping definitions (see unix/mc68000/README). + (4/14) + +unix/hlib/[dir]1mach.f + Commented out the VAX lines and uncommented the IEEE floating + point lines for the 68000. (4/15) + +unix/hlib/mkpkg.inc + Modified XFLAGS to "-c -O -f68881" for our hardware floating point + option. To verify that this works, I examined zzeps.e, compiled with + the same flags, with adb and found that, indeed, only single arguments + were being passed and actual floating point instructions were being + generated. Set USE_CALCOMP to NO. (4/15) + +unix/hlib/libc/kernel.h + Commented out DEBUGMEM in order to use the standard UNIX malloc rather + than IRAF's version. This is necessary for some reason on the Sun for + SunCGI routines to be callable from SPP programs. (4/15) + +unix/hlib/libc/iraf.h + Added definition for SUN3; the Sun IRAF kernel is still mostly + identical with the VAX kernel, but zxwhen.c needs to know if it + is being compiled on a Sun-3. (4/15) + +unix/ + Attempted a bootstrap; had to make the following modification to + get it to work: (4/15) + +unix/os/zxwhen.c + Renamed structure vax_exception to hwx_exception; added ifdef branch + for SUN3 FPE traps-to-strings structure. (The version that compiled + under the Sun-2 failed to compile under the Sun-3.) (4/15) + +unix/ + Performed a bootstrap with "sh -x mkpkg.csh >& spool &". + The only error showing was in bootlib/mkpkg.csh, "syntax error + at line 13: `end of file' unexpected", presumably due to the + conditional construct, and possibly a CSHELL bug (libboot.a + built correctly and ended up in $hlib as it should anyway). (4/15) + +unix/hlib/alloc.e + This file must belong to root, since it needs root permissions at + runtime to allocate devices. Do the following: + + % cd $hlib + % su + % /etc/chown 0 alloc.e (4/15) + +------------------------------------------- +The bootstrap is now complete. The next step is to do a full system compile. + + + Attempted a "mkpkg >& spool &" from the root directory. Got compiler + failure in fio$; "Compiler error line 0 of (null): invalid flag + s...y...s...t...e...m...=" when trying to compile fowner.f. Also + got similar errors in fmtio$gstrcat.f and other places. No further + files from the original XC command line were compiled. Common + denominator was the length of the command line to the f77 compiler. + Made the following change: (4/15) + +unix/boot/mkpkg/host.c + Changed SZ_CMD from 512 to 400; this shortens the command line + that MKPKG constructs for XC. Rebuilt MKPKG with "sh -x mkpkg.csh". + (4/15) + + + Started another sysgen. Noticed compiler errors on the following + files; let the sysgen continue while fixing them. + + sys/fmtio/gctod.f + sys/fmtio/xtoc.f + These routines had to be hand-compiled without switch "-f68881". + Made copies of the fortran in local/bugs, and hand-compiled + each routine in its own directory. Something to do with complex + numbers? Since it didn't look like they affected anything else, + just did a "mkpkg" to load them back into libsys and let the + sysgen continue. (4/15) + + sys/vops/ak/abeqkx.f + sys/vops/ak/abeqx.f + sys/vops/ak/abgekx.f + sys/vops/ak/abgtkx.f + sys/vops/ak/ablekx.f + sys/vops/ak/abltkx.f + sys/vops/ak/abnekx.f + sys/vops/ak/abnex.f + sys/vops/ak/advzx.f + sys/vops/lz/allnx.f + sys/vops/lz/alogx.f + sys/vops/lz/arcpx.f + sys/vops/lz/arczx.f + Same with these routines; again, all contained complex datatypes. + Hand-compiled, then a "mkpkg" from vops. (4/16) + +unix/hlib/mkpkg.inc + Changed LFLAGS from "" to "-f68881" to get pick up the references + generated by the same switch during default compilation. This may + cause a problem with those files hand-compiled without this switch + due to compiler errors. (4/16) + +pkg/dataio/reblock/t_reblock.x line 56 +pkg/dataio/cardimage/t_wcardimage.x 39 +pkg/images/imutil/imdelete.x 43 +pkg/onedspec/t_widstape.x 65 +pkg/plot/gkiextract.x 99 +pkg/utilities/t_translit.x 41, 68 +pkg/imred/vtel/dicoplot.x 324 +pkg/imred/vtel/tcopy.x 59 +pkg/imred/vtel/vtfix.x 60 +pkg/imred/vtel/writevt.x 42 + All these lines tested a boolean conditional against "true" or "false". + The Sun-3 f77 compiler refused to compile these; all were changed to + just the name of the boolean or !boolean as appropriate. + This was only done on the Sun, since this is an experimental version; + mail will be sent on lyra. (4/16) + +pkg/images/tv/display/iisers.x + No change made, since there is no need for this code on the Sun, + and it looked like there were non-obvious consequences in other + routines for changing either the values or changing shorts to ints. + However, note should be taken on lyra that "erase" is a short integer, + and it is being assigned to ERASE (in one of the local include + files), which has the value "32768" -- too high by one, apparently. + +pkg/images/tv/cv/iism70/iiscursor.x +pkg/images/tv/cv/iism70/zclear.x + Also no change made, but similar problem: the include file + definitions IREAD (100000B) and ERASE (32768) are being used + in assignments to short integers, in one case "32768+256". (4/16) + +unix/boot/spp/xc.c + Added references for the standard Fortran libraries -lI77 and -lU77, + plus a reference to the temporary library $hlib/libk.a, which contains + several routines referenced by the Fortran compiler, but not provided + in any SUN library. See below. (4/25) + +unix/hlib/SUN_kludge/ + This a temporary directory added to build the kludge library libk.a + so that IRAF programs can be linked on the SUN-3. Source for the + following routines were added: + + Fc_eq compare complex numbers for equality + Fc_conv_h convert complex to short + Fh_conv_c convert short to complex + + The conversion routines appear to have been overlooked by SUN, and + should be added to /usr/lib/libF77.a. (4/25) + +unix/mkpkg.csh + Added a line to compile the kludge library during the bootstrap. (4/25) + +unix/hlib/mkpkg.inc + Added the flag "-f68881" to LFLAGS (the linker flags). This is + necessary to get the linker to reference /lib/Mcrt1.o rather than + /lib/Fcrt1.o. If this is not done and one attempts to link code + compiled with the -f68881 switch, an unresolved reference to + the external "f68881_used" will result. (4/25) + +sys/osb/miiupk16.x +sys/osb/miiupk32.x + Replaced by the new versions from lyra, which fix the BYTE_SWAP + bug. (4/25) + +sys/gio/nspp/portlib/flush.f +sys/gio/nspp/portlib/flash[13].f +sys/gio/nsppkern/gktcancel.f +sys/gio/nsppkern/gktclear.f +sys/gio/nsppkern/gktclose.f +sys/gio/ncarutil/sysint/spps.f + Changed the name of the NSPP routine "flush" to "mcflsh" to avoid + a library conflict with the Fortran FLUSH. (4/25) + +pkg/images/tv/display/iisers.x +pkg/images/tv/cv/iism70/iiscursor.x +pkg/images/tv/cv/iism70/zclear.x + All these files produced a compiler bug due to a compile time + assignment of an unsigned short integer number 1XXXXX into a + short variable. Had to change these to run time assignments to + get the desired truncation assignment. (4/25) + +local/.login +local/login.cl + Aliased XC to 'xc -f68881' since all floating point is handled that + way on this machine. (4/25) + +unix/hlib/libc/finfo.h + The fi_owner field of the finfo structure was not dimensioned + properly, causing the storage allocated for the structure to be + overrun. This was found in a call to pfileopen/filetime in the + CL; the finfo structure is allocated space on the stack, hence the + stack was being corrupted. This was a fairly serious bug which has + been in the system for a long time. (4/25) + +[[ The system is now up (4/25) ]] + +dev/pix +dev/pix.pix + Moved the test image over from lyra: + + wfits dev$pix /u2/tody/pix.fits (on VAX lyra) + rfits lyra!/u2/tody/pix.fits (on SUN) + + We ought to add a dev$pix.fits file so that the test image is + available on source only archives. (4/25) diff --git a/doc/ports/sun3_062486.doc b/doc/ports/sun3_062486.doc new file mode 100644 index 00000000..16a1107e --- /dev/null +++ b/doc/ports/sun3_062486.doc @@ -0,0 +1,202 @@ +SUN/IRAF V2.3 Installation, 12 June 1986 Sun-3, MC68881 floating point +------------------------------------------------------------------------------ + +/usr/iraf/local/notes + Began this new notes file. All subsequent pathnames assume + "/usr/iraf/" preceding them. (6/12) + +unix/ + Made a tar backup in /tmp2/iraf/tuc_unix.arc. (6/12) + +local/ + Made a tar backup in /tmp2/iraf/tuc_local.arc. (6/12) + +bin/ +lib/ +pkg/ +sys/ +unix/ + Ran rmbin to remove all binary files. (6/12) + +/usr/iraf/ + Unpacked new "wtar -o" source-only archive from lyra. (6/12) + +unix/as/ +unix/mc68000 + Replaced VAX contents of as/ with those from mc68000; renamed + .SUN's to .s's. (6/12) + +unix/mkpkg.csh + Replaced with the one from the archive; contains SUN_kludge + mkpkg.csh command. (6/12) + +unix/hlib/[dir]1mach.f + Replaced with those from archive for 68000; using MC68000 + versions of machine-independent stuff for nspp software. (6/12) + +unix/hlib/mach.h + Compared with archive and replaced with archive version to pick + up BYTE_SWAP[24] = NO, and to use the 68000 fp epsilons. (6/12) + +unix/hlib/motd + Short message about SUN/IRAF system testing. (6/12) + +unix/hlib/mkpkg.inc + Ran diff; replaced from archive to pick up 68000 compiler + and linker switches for this SUN-3, which has MC 68881 floating + point (XFLAGS -c -O -f68881; LFLAGS -f68881). Set USE_CALCOMP + to NO. (6/12) + +unix/hlib/mkiraf.csh + Replaced iraf root definition. (6/12) + +unix/hlib/libc/iraf.h + Changed root directory to /usr/iraf/, added "#define SUN3". (6/12) + +unix/hlib/libc/kernel.h + Commented out DEBUGMEM so that the normal UNIX malloc() is + used. This was and probably still is necessary in order to + link with SUNCGI. (6/12) + +unix/hlib/libc/spp.h + Ran diff; replaced with archive version to pick up MC68000 + fp epsilons. (6/12) + +unix/boot/mkpkg/host.c + Changed SZ_CMD from 512 to 400 to get around SUN-3 f77 command- + line bug. (6/12) + +unix/boot/spp/xc.c + Ran diff; replaced with archive version to pick up all the + extra Fortran library definitions and command-line args. (6/12) + +unix/os/zxwhen.c + Ran diff; replaced with archive version to pick up Sun floating + point exception definitions. (6/12) + +local/notes + Renamed to notes.vax. (6/12) + +local/login.cl + Renamed root directory in "home"; aliased "xc" to "xc -f68881". (6/12) + +/usr/include/iraf.h -> $hlib/libc/iraf.h + Made sure this symbolic link existed. (6/12) + +unix/ [BOOTSTRAP] + Attempted bootstrap ("sh -x mkpkg.csh"). (6/12) + +unix/boot/bootlib/mkpkg.csh + This time the bootstrap failed because of the "unexpected end of + file" error and did NOT create libboot.a. Resolved by inserting + "#! /bin/csh -f" as the first line. (6/13) + +unix/ [BOOTSTRAP] + Successful bootstrap this time. (6/13) + +unix/hlib/alloc.e + Changed ownership to root in order to allocate devices at runtime. + (6/13) + +/usr/bin/alloc -> $hlib/alloc.e +/usr/bin/generic -> $hlib/generic.e +/usr/bin/mkpkg -> $hlib/mkpkg.e +/usr/bin/rmbin -> $hlib/rmbin.e +/usr/bin/rmfiles -> $hlib/rmfiles.e +/usr/bin/rtar -> $hlib/rtar.e +/usr/bin/wtar -> $hlib/wtar.e +/usr/bin/xc -> $hlib/xc.e +/usr/bin/cl -> $hlib/cl.e + Made sure these symbolic links existed. (6/13) + +sys/fmtio/gctod.f F77 compile-time +sys/fmtio/xtoc.f F77 compile-time +sys/vops/ak/abeqkx.f F77 compile-time +sys/vops/ak/abeqx.f F77 compile-time +sys/vops/ak/abgekx.f F77 compile-time +sys/vops/ak/abgtkx.f F77 compile-time +sys/vops/ak/ablekx.f F77 compile-time +sys/vops/ak/abltkx.f F77 compile-time +sys/vops/ak/abnekx.f F77 compile-time +sys/vops/ak/abnex.f F77 compile-time +sys/vops/ak/advzx.f F77 compile-time +sys/vops/lz/allnx.f F77 compile-time +sys/vops/lz/alogx.f F77 compile-time +sys/vops/lz/arcpx.f F77 compile-time +sys/vops/lz/arczx.f F77 compile-time + Hand-compiled without "-f68881" switch (but with optimization); + otherwise the compiler fails due to complex datatype expressions. + This will be the case until the next Sun f77 release. (6/13) + +sys/fmtio/fprfmt.x F77 run-time + Hand-compiled without optimization (but with "-f68881"). Have not + yet determined source of problem (symptom was garbage appearing + in text files) -- pursue shortly. (6/13) + +$iraf + Started sysgen at 10:22. (6/13) + +dev/devices + Replaced with version from suntest!, since we now have a 1/2 inch + tape drive on tucana. Added mtb entry for the 1/4 inch drive. (6/13) + +noao$onedspec/getnimage.x F77 run-time + There is a bug in the optimizer which seems to be caused by a + logical comparison to MAX_INT. To get around the problem do the + following after a full sysgen. (6/19) + + touch getnimage.x; mkpkg xflags=-c fluxcal; mkpkg install + +$iraf + Unpacked an incremental archive from lyra to bring tucana up + to current as of 09:15 June 20, 1986. Performed an incremental + sysgen. (6/20) + +noao/twodspec/apextract/* + The preceding MKPKG found the entire contents of icfit/* missing + except for 3 source files. To be safe, I (sr) made a complete + archive of lyra!/...apextract/* and unpacked it here, followed + by another root sysgen. (6/20) + +noao/twodspec/apexold/* + Because this directory was created by renaming the directory + apextract after the full archive of June 12, it had old file + dates and the incremental archives this week didn't pick it + up. Unpacked a full archive and MKPKG'd. (6/20) + +sys/gio/cursor/grcwcs.x F77 run-time + Apparent f77 optimizer bug; hand-compiling w/o optimization + and relinking the CL clears up the problem of IMPLOT's "l" + and "c" commands returning bad pixel rows/columns. Before, + clgcur was sometimes returning the y coordinate in pixel, + rather than data, units -- i.e. in WCS 1 rather than 2. Haven't + had time to try to isolate the source of the optimizer bug. (6/21) + +$iraf + Unpacked an incremental archive from lyra! current to 14:40 June + 21; performed an incremental sysgen. (6/21) + +noao/mtlocal/r2df/r2df.com + The preceding sysgen died because this file was missing; it had + a date earlier than the incremental archive, so was missed. + Added it and rebuilt mtlocal. (6/21) + +$iraf + Unpacked an incremental archive from lyra! current to 08:15 June + 23; performed an incremental sysgen. (6/23) + +noao/lib/scr/* +noao/twodspec/apextract/* +noao/twodspec/apexold/* + Unpacked full, not incremental, archives from lyra! to pick up any + files missed during the incremental archives as a result of renaming + rather than copying files since the June 12 full archive. mkpkg + updates in both apextract directories. (6/23) + +pkg/cl/unop.c + Changed call to sscanf (sval, "%f", &rresult) in case OP_REAL to + sscanf (sval, "%lf", &rresult) because "rresult" is declared type + "double", and on the SUNs, sscanf was only writing into the first + four bytes of rresult, giving erroneous answers to REAL coercion, + as in "cl> =real(imgets.value)". Should be changed on master system + as well. (6/23) diff --git a/doc/ports/sun3_f77Obugs.doc b/doc/ports/sun3_f77Obugs.doc new file mode 100644 index 00000000..1f06a3e5 --- /dev/null +++ b/doc/ports/sun3_f77Obugs.doc @@ -0,0 +1,1666 @@ +# f77 source programs and corresponding assembler code generated with +# "f77 -S -O -f68881" that cause run-time failure, where the corresponding +# unoptimized code does not. +#=============================================================================== +# fprfmt.f: + integer function fprfmt (ival) + integer ival + logical ivalad + integer ctoi + integer stridx + integer*2 ch + integer*2 chrlwr + integer fd + integer ip + integer width + integer decpl + integer col + integer leftjy + integer radix + integer fmtste + integer ofilee + integer formar + integer*2 fillcr + integer*2 format(161 +1) + integer*2 obuf(1024+1) + integer sw0001 + common /fmtcom/ fd,ip,width,decpl,col,leftjy,radix,fmtste, ofilee, + *formar,fillcr,format,obuf + integer*2 st0001(17) + integer*2 st0002(35) + integer*2 st0003(1) + save + integer iyy + data (st0001(iyy),iyy= 1, 8) / 98, 99,100,101,102,103,104,109/ + data (st0001(iyy),iyy= 9,16) /111,114,115,116,117,119,120,122/ + data (st0001(iyy),iyy=17,17) / 0/ + data (st0002(iyy),iyy= 1, 8) / 87, 97,114,110,105,110,103, 58/ + data (st0002(iyy),iyy= 9,16) / 32, 85,110,107,110,111,119,110/ + data (st0002(iyy),iyy=17,24) / 32,102,111,114,109, 97,116, 32/ + data (st0002(iyy),iyy=25,32) /116,121,112,101, 32, 99,104, 97/ + data (st0002(iyy),iyy=33,35) /114, 10, 0/ + data st0003 / 0/ + sw0001=(fmtste) + goto 110 +120 continue + ivalad = .false. + goto 111 +130 continue + goto 2 +140 continue + goto 3 +150 continue + goto 4 +160 continue + goto 5 +170 continue + goto 6 +180 continue + goto 7 +110 continue + if (sw0001.lt.1.or.sw0001.gt.7) goto 111 + goto (120,130,140,150,160,170,180),sw0001 +111 continue + if (.not.(format(ip) .eq. 0 .or. format(ip) .ne. 37 )) goto 190 + width = (-999) + decpl = (-999) + formar = (-999) + fillcr = 32 + leftjy = 0 + fmtste = 1 + fprfmt = (1) + goto 100 +190 continue + ip = ip + 1 +191 continue + if (.not.(format(ip) .eq. 42 )) goto 200 + ip = ip + 1 + if (.not.(ivalad)) goto 210 + fmtste = 2 + fprfmt = (0 ) + goto 100 +210 continue +2 ivalad = .true. + if (.not.(ival .lt. 0)) goto 220 + leftjy = 1 + goto 221 +220 continue + leftjy = 0 +221 continue + fillcr = 32 + width = abs (ival) + goto 201 +200 continue + if (.not.(format(ip) .eq. 45)) goto 230 + leftjy = 1 + ip = ip + 1 + goto 231 +230 continue + leftjy = 0 +231 continue + fillcr = 32 + if (.not.(format(ip) .eq. 48)) goto 240 + if (.not.((format(ip+1).ge.48.and.format(ip+1).le.57) .or + * . format(ip+1) .eq. 42 )) goto 250 + fillcr = 48 + ip = ip + 1 + goto 251 +250 continue + fillcr = 32 +251 continue +240 continue + if (.not.(format(ip) .eq. 42 )) goto 260 + ip = ip + 1 + if (.not.(ivalad)) goto 270 + fmtste = 3 + fprfmt = (0 ) + goto 100 +270 continue +3 ivalad = .true. + if (.not.(ival .lt. 0)) goto 280 + leftjy = 1 + goto 281 +280 continue + leftjy = 0 +281 continue + width = abs (ival) + goto 261 +260 continue + if (.not.(ctoi (format, ip, width) .le. 0)) goto 290 + width = (-999) +290 continue +261 continue +201 continue + if (.not.(width .eq. 0)) goto 300 + width = (-999) +300 continue + if (.not.(format(ip) .eq. 46)) goto 310 + ip = ip + 1 + if (.not.(format(ip) .eq. 42 )) goto 320 + ip = ip + 1 + if (.not.(ivalad)) goto 330 + fmtste = 4 + fprfmt = (0 ) + goto 100 +330 continue +4 ivalad = .true. + decpl = ival + goto 321 +320 continue + if (.not.(ctoi (format, ip, decpl) .le. 0)) goto 340 + decpl = (-999) +340 continue +321 continue + goto 311 +310 continue + decpl = (-999) +311 continue + if (.not.(format(ip) .eq. 42 )) goto 350 + ip = ip + 1 + if (.not.(ivalad)) goto 360 + fmtste = 5 + fprfmt = (0 ) + goto 100 +360 continue +5 ivalad = .true. + formar = ival + goto 351 +350 continue + formar = format(ip) + ip = ip + 1 +351 continue + if (.not.((formar.ge.65.and.formar.le.90))) goto 370 + formar = (formar+97-65) +370 continue + ch = formar + if (.not.(stridx (ch, st0001) .le. 0)) goto 380 + call putlie (5, st0002) + call fmterr (st0003, format, ip-1) + formar = (-999) + goto 381 +380 continue + if (.not.(formar .eq. 114 )) goto 390 + ch = chrlwr (format(ip)) + ip = ip + 1 + if (.not.(ch .eq. 42 )) goto 400 + if (.not.(ivalad)) goto 410 + fmtste = 6 + fprfmt = (0 ) + goto 100 +410 continue +6 ivalad = .true. + radix = ival + goto 401 +400 continue + if (.not.((ch.ge.48.and.ch.le.57))) goto 420 + radix = (ch-48) + goto 421 +420 continue + if (.not.((ch.ge.97.and.ch.le.122))) goto 430 + radix = ch - 97 + 10 + goto 431 +430 continue + radix = 10 + ip = ip - 1 +431 continue +421 continue +401 continue + goto 391 +390 continue + if (.not.(formar .eq. 119 .or. formar .eq. 116 )) goto 440 + ivalad = .false. +440 continue +391 continue +381 continue + if (.not.(ivalad)) goto 450 + fmtste = 7 + fprfmt = (0 ) + goto 100 +450 continue +7 ivalad = .true. + fmtste = 1 + fprfmt = (1) + goto 100 +100 return + end +c leftjy left_justify +c fmterr fmt_err +c fmtste fmt_state +c ivalad ival_already_used +c fillcr fill_char +c putlie putline +c ofilee ofile_type +c formar format_char +#------------------------------------------------------------------------------- +# fprfmt.s: + .data + .data1 + .bss + .data + .globl _fprfmt_ + .comm _fmtcom_,2416 + .globl _ctoi_ + .globl _stridx_ + .globl _putlie_ + .globl _fmterr_ + .globl _chrlwr_ + .align 4 + .text +|#PROC# 07 + + .bss + .align 4 +VAR_SEG1: + .skip 10 + .data1 + .align 2 +L1D186: + .long 5 + LF1 = 228 + LS1 = 8432 + LFF1 = 208 + LSS1 = 0 + LP1 = 20 + .text + .globl _fprfmt_ +_fprfmt_: + link a6,#-228 + moveml #8432,sp@ + movl a6@(8),a5 + movl _fmtcom_+4,d4 + movl VAR_SEG1+4,d5 + cmpl #1,_fmtcom_+28 + jge L77020 + jra L77005 +L77007: + moveq #1,d5 + movl a5@,d7 + jge L77043 + movl d5,_fmtcom_+20 + jra L77044 +L77009: + moveq #1,d5 + movl a5@,d7 + jge L77078 + movl d5,_fmtcom_+20 + jra L77079 +L77011: + moveq #1,d5 + movl a5@,_fmtcom_+12 + jra L77109 +L77013: + moveq #1,d5 + movl a5@,d7 + jra L77118 +L77015: + moveq #1,d5 + movl a5@,_fmtcom_+24 + jra LY00019 +L77017: + moveq #1,d5 + jra LY00006 +L77018: + movl _fmtcom_+28,d0 + moveq #8,d7 + cmpl d7,d0 + bcc L77005 + addw d0,d0 + movw pc@(6,d0:w),d0 + jmp pc@(2,d0:w) +L1I1: + .word L77023-L1I1 + .word L77004-L1I1 + .word L77007-L1I1 + .word L77009-L1I1 + .word L77011-L1I1 + .word L77013-L1I1 + .word L77015-L1I1 + .word L77017-L1I1 + jra L77005 +L77020: + cmpl #7,_fmtcom_+28 + jle L77018 + jra L77005 +L77023: + jra L77005 +L77030: + addql #1,d4 + movl d4,d7 + lea _fmtcom_+40,a0 + movw a0@(0,d7:l:2),d0 + extl d0 + moveq #42,d6 + cmpl d6,d0 + jne L77035 + addql #1,d7 + movl d7,d4 + tstl d5 + jeq L77007 + moveq #2,d6 + jra LY00016 +L77024: + movl #-999,_fmtcom_+8 + movl #-999,_fmtcom_+12 + movl #-999,_fmtcom_+36 + movw #32,_fmtcom_+40 + clrl _fmtcom_+20 +LY00006: + moveq #1,d6 + moveq #1,d7 + jra LY00010 +L77129: + movl d4,_fmtcom_+4 + asll #1,d4 + addl #_fmtcom_+40,d4 + movl d4,sp@- + jbsr _chrlwr_ + addqw #4,sp + movl _fmtcom_+4,d4 + addql #1,d4 + extl d0 + movl d0,d7 + moveq #42,d6 + cmpl d6,d7 + jne L77136 + tstl d5 + jeq L77015 + moveq #6,d6 + jra LY00016 +L77136: + moveq #48,d6 + cmpl d6,d7 + jlt L77146 + moveq #57,d6 + cmpl d6,d7 + jgt L77146 + moveq #-48,d6 + addl d6,d7 + movl d7,_fmtcom_+24 + jra LY00019 +L77146: + moveq #97,d6 + cmpl d6,d7 + jlt L77152 + moveq #122,d6 + cmpl d6,d7 + jgt L77152 + moveq #-87,d6 + addl d6,d7 + movl d7,_fmtcom_+24 + jra LY00019 +L77152: + moveq #10,d7 + movl d7,_fmtcom_+24 + moveq #-1,d7 + addl d7,d4 + jra LY00019 +LY00020: + movl d4,_fmtcom_+4 + pea v.17 + pea L1D186 + jbsr _putlie_ + addqw #8,sp + movl _fmtcom_+4,d0 + moveq #-1,d7 + addl d7,d0 + movl d0,a6@(-20) + pea a6@(-20) + pea _fmtcom_+42 + pea v.18 + jbsr _fmterr_ + lea sp@(12),sp + movl _fmtcom_+4,d4 + movl #-999,_fmtcom_+36 +LY00019: + tstl d5 + jeq L77017 + moveq #7,d6 + jra LY00016 +L77110: + addql #1,d4 + tstl d5 + jeq L77013 + moveq #5,d6 + jra LY00016 +L77096: + addql #1,d7 + movl d7,d4 + tstl d5 + jeq L77011 + moveq #4,d6 +LY00016: + moveq #0,d7 +LY00010: + movl d7,d0 + movl d6,_fmtcom_+28 + movl d4,_fmtcom_+4 + movl d5,VAR_SEG1+4 + moveml a6@(-228),#8432 + unlk a6 + rts +L77004: + moveq #0,d5 +L77005: + lea _fmtcom_+40,a0 + movw a0@(0,d4:l:2),d0 + extl d0 + movl d0,d7 + jeq L77024 + moveq #37,d6 + cmpl d6,d7 + jeq L77030 + jra L77024 +L77035: + moveq #45,d4 + cmpl d4,d6 + jne L77052 + moveq #1,d6 + movl d6,_fmtcom_+20 + addql #1,d7 + jra L77053 +L77043: + clrl _fmtcom_+20 +L77044: + movw #32,_fmtcom_+40 + tstl d7 + jlt L77046 + jra LY00023 +L77088: + movl #-999,_fmtcom_+8 + jra L77091 +L77052: + clrl _fmtcom_+20 +L77053: + movw #32,_fmtcom_+40 + movl d7,d6 + asll #1,d6 + lea _fmtcom_+40,a0 + movw a0@(0,d6:l),d0 + extl d0 + moveq #48,d4 + cmpl d4,d0 + jne L77057 + lea _fmtcom_+42,a0 + movw a0@(0,d6:l),d0 + extl d0 + movl d0,d4 + moveq #48,d6 + cmpl d6,d4 + jlt L77061 + moveq #57,d6 + cmpl d6,d4 + jgt L77061 + jra L77058 +L77057: + lea _fmtcom_+40,a0 + movw a0@(0,d7:l:2),d0 + extl d0 + moveq #42,d6 + cmpl d6,d0 + jne L77070 + addql #1,d7 + movl d7,d4 + tstl d5 + jeq L77009 + moveq #3,d6 + jra LY00016 +L77065: + movw #32,_fmtcom_+40 + jra L77057 +L77058: + movw #48,_fmtcom_+40 + addql #1,d7 + jra L77057 +L77061: + moveq #42,d6 + cmpl d6,d4 + jne L77065 + jra L77058 +L77070: + movl d7,_fmtcom_+4 + movl d7,_fmtcom_+4 + pea _fmtcom_+8 + pea _fmtcom_+4 + pea _fmtcom_+42 + jbsr _ctoi_ + lea sp@(12),sp + moveq #0,d1 + tstl d0 + sle d1 + negb d1 + movl d1,a6@(-52) + movl _fmtcom_+4,d4 + tstl d1 + jeq LY00002 + movl #-999,_fmtcom_+8 + jra LY00002 +L77078: + clrl _fmtcom_+20 +L77079: + tstl d7 + jge LY00023 +L77046: + negl d7 +LY00023: + movl d7,_fmtcom_+8 +LY00002: + tstl _fmtcom_+8 + jeq L77088 +L77091: + lea _fmtcom_+40,a0 + movw a0@(0,d4:l:2),d0 + extl d0 + moveq #46,d7 + cmpl d7,d0 + jne L77105 + addql #1,d4 + movl d4,d7 + lea _fmtcom_+40,a0 + movw a0@(0,d7:l:2),d0 + extl d0 + moveq #42,d6 + cmpl d6,d0 + jeq L77096 + movl d7,_fmtcom_+4 + movl d7,_fmtcom_+4 + pea _fmtcom_+12 + pea _fmtcom_+4 + pea _fmtcom_+42 + jbsr _ctoi_ + lea sp@(12),sp + moveq #0,d1 + tstl d0 + sle d1 + negb d1 + movl d1,a6@(-48) + movl _fmtcom_+4,d4 + tstl d1 + jeq L77109 +L77105: + movl #-999,_fmtcom_+12 +L77109: + lea _fmtcom_+40,a0 + movw a0@(0,d4:l:2),d0 + extl d0 + movl d0,d6 + moveq #42,d7 + cmpl d7,d6 + jeq L77110 + movl d6,d7 + addql #1,d4 +L77118: + moveq #65,d6 + cmpl d6,d7 + jlt L77123 + moveq #90,d6 + cmpl d6,d7 + jgt L77123 + moveq #32,d6 + addl d6,d7 +L77123: + movw d7,VAR_SEG1+8 + movl d7,_fmtcom_+36 + movl d4,_fmtcom_+4 + pea v.16 + pea VAR_SEG1+8 + jbsr _stridx_ + addqw #8,sp + moveq #0,d1 + tstl d0 + sle d1 + negb d1 + movl d1,a6@(-44) + movl _fmtcom_+4,d4 + tstl d1 + jne LY00020 + cmpl #114,_fmtcom_+36 + jeq L77129 + cmpl #119,_fmtcom_+36 + jeq L77017 + cmpl #116,_fmtcom_+36 + jne LY00019 + jra L77017 + .globl f68881_used + .data1 + .align 4 +v.16: + .long 0x620063,0x640065 + .long 0x660067,0x68006d + .long 0x6f0072,0x730074 + .long 0x750077,0x78007a + .word 0x0 + .align 4 +v.17: + .long 0x570061,0x72006e + .long 0x69006e,0x67003a + .long 0x200055,0x6e006b + .long 0x6e006f,0x77006e + .long 0x200066,0x6f0072 + .long 0x6d0061,0x740020 + .long 0x740079,0x700065 + .long 0x200063,0x680061 + .long 0x72000a + .word 0x0 + .align 4 +v.18: + .skip 2 +#=============================================================================== +# ========================== +# FORTRAN for get_next_image +# ========================== + integer function getnee (infile, recors, nrecs, image, szname) + integer infile + integer nrecs + integer szname + integer recors(3,100) + integer*2 image(szname+1) + integer nextnm + integer stat + logical flag1 + logical flag2 + logical flag3 + integer*2 image0(63 +1) + integer clgfil + integer getney + integer xstrln + common /gnicom/ flag1, flag2 + integer*2 st0001(6) + save + data st0001 / 46, 37, 48, 52,100, 0/ + data flag3/.true./ + if (.not.(flag1 .or. flag3)) goto 110 + nextnm = -1 + call rstgey () +110 continue + if (.not.(nrecs .eq. 2147483647)) goto 120 + stat = clgfil (infile, image, szname) #<--- Never executed + goto 121 +120 continue + if (.not.(flag1)) goto 130 + stat = clgfil (infile, image0, szname) + if (.not.(stat .eq. -2)) goto 140 + getnee = (stat) + goto 100 +140 continue +130 continue + stat = getney (recors, nextnm) + if (.not.(stat .ne. -2)) goto 150 + call xstrcy(image0, image, szname) + call sprinf (image(xstrln(image)+1), szname, st0001) + call pargi (nextnm) +150 continue +121 continue + flag1 = .false. + flag3 = .false. + getnee = (stat) + goto 100 +100 return + end + +#==================================================================== +#Optimized assembly +#==================================================================== + +_getnee_+4: moveml d4/d5/d6/d7,sp@ + tstl _gnicom_ + beqs _getnee_+0x30 + bras _getnee_+0x20 +_getnee_+0x12: movl d7,d0 + moveml a6@(-0x50),d4/d5/d6/d7 + unlk a6 + rts + bras _getnee_+0x38 + moveq #-1,d6 + movl d6,ARR_SEG5+0x294 + jsr _rstgey_ + bras _getnee_+0x38 + tstl v.150+0x90 + bnes _getnee_+0x20 + movl a6@(8),d4 + movl a6@(0x18),d5 + movl a6@(0x14),d6 + movl a6@(0x10),a0 + cmpl #0x7fffffff,a0@ <-------- + beq _getnee_+0xd4 <-------- Causes return + tstl _gnicom_ + beqs _getnee_+0x76 + movl d5,sp@- + pea ARR_SEG5+0x298 + movl d4,sp@- + bsrl _clgfil_ + lea sp@(0xc),a7 + movl d0,d7 + moveq #-2,d4 + cmpl d4,d7 + beqs _getnee_+0x12 + pea ARR_SEG5+0x294 + movl a6@(0xc),sp@- + jsr _getney_ + addqw #8,sp + movl d0,d7 + moveq #-2,d4 + cmpl d4,d7 + beqs _getnee_+0xd4 + movl d5,sp@- + movl d6,sp@- + pea ARR_SEG5+0x298 + bsrl _xstrcy_ + lea sp@(0xc),a7 + pea v.150+0x84 + movl d5,sp@- + movl d6,sp@- + bsrl _xstrln_ + addqw #4,sp + asll #1,d0 + addl d6,d0 + movl d0,sp@- + bsrl _sprinf_ + lea sp@(0xc),a7 + pea ARR_SEG5+0x294 + bsrl _pargi_ + addqw #4,sp +_getnee_+0xd4: clrl _gnicom_ + clrl v.150+0x90 + bra _getnee_+0x12 + +_resete_: linkw a6,#0 + movl #1,_gnicom_ + unlk a6 + rts + +_addspc_: linkw a6,#-0xec + moveml d3/d4/d5/d6/d7/a3/a4/a5,sp@ + fmovex fp7,a6@(-0xcc) + moveq #0,d6 + movl a6@(0x14),a0 + movl a0@,a5 + tstl a5 + bnes _addspc_+0x8e + moveq #-1,d6 + bras _addspc_+0x8e + moveq #1,d4 + movl a4@,d7 + subl d4,d7 + tstl d7 + blt _addspc_+0xb4 + + +#=============================================================================== +# grcwcs.f: + subroutine grcscs (stream, sx, sy, wx, wy, wcs) + integer stream + real sx + real sy + real wx + real wy + integer wcs + logical Memb(1) + integer*2 Memc(1) + integer*2 Mems(1) + integer Memi(1) + integer*4 Meml(1) + real Memr(1) + double precision Memd(1) + complex Memx(1) + equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx) + common /Mem/ Memd + integer w + integer tr + real mx + real my + real ct(2,4) + integer grcses + integer gtrint + save + tr = gtrint (stream) + call grcscc (sx, sy, mx, my) + if (.not.(memi(tr+16) .eq. 0)) goto 110 + wcs = grcses (tr, mx, my) + goto 111 +110 continue + wcs = memi(tr+16) +111 continue + w = ((tr)+154+(wcs)*11) + call grcsen (w, ct) + call grcnds (ct, mx, my, wx, wy) +100 return + end + subroutine grcsen (w, ct) + logical Memb(1) + integer*2 Memc(1) + integer*2 Mems(1) + integer Memi(1) + integer*4 Meml(1) + real Memr(1) + double precision Memd(1) + complex Memx(1) + equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx) + common /Mem/ Memd + integer w + real ct(2,4) + real worign + real scale + real m1 + real m2 + real w1 + real w2 + integer transn + integer ax + real elogr + save + do 110 ax = 1, 2 + if (.not.(ax .eq. 1)) goto 120 + transn = memi(w+8) + w1 = memr(w) + w2 = memr(w+1) + m1 = memr(w+4) + m2 = memr(w+5) + goto 121 +120 continue + transn = memi(w+9) + w1 = memr(w+2) + w2 = memr(w+3) + m1 = memr(w+6) + m2 = memr(w+7) +121 continue + if (.not.(transn .eq. 0 )) goto 130 + worign = w1 + scale = (m2 - m1) / (w2 - w1) + goto 131 +130 continue + if (.not.(transn .eq. 1 .and. w1 .gt. 0 .and. w2 .gt. 0)) + * goto 140 + worign = log10 (w1) + scale = (m2 - m1) / (log10(w2) - worign) + goto 141 +140 continue + worign = elogr (w1) + scale = (m2 - m1) / (elogr(w2) - worign) +141 continue +131 continue + ct(ax,1) = transn + ct(ax,2) = scale + ct(ax,3) = worign + ct(ax,4) = m1 +110 continue +111 continue +100 return + end + subroutine grcwcc (ct, wx, wy, mx, my) + real wx + real wy + real mx + real my + real ct(2,4) + real v + integer transn + integer ax + real elogr + save + do 110 ax = 1, 2 + transn = nint (ct(ax,1)) + if (.not.(ax .eq. 1)) goto 120 + v = wx + goto 121 +120 continue + v = wy +121 continue + if (.not.(transn .eq. 0 )) goto 130 + goto 131 +130 continue + if (.not.(transn .eq. 1)) goto 140 + v = log10 (v) + goto 141 +140 continue + v = elogr (v) +141 continue +131 continue + v = ((v - ct(ax,3)) * ct(ax,2)) + ct(ax,4) + if (.not.(ax .eq. 1)) goto 150 + mx = v + goto 151 +150 continue + my = v +151 continue +110 continue +111 continue +100 return + end + subroutine grcnds (ct, mx, my, wx, wy) + real mx + real my + real wx + real wy + real ct(2,4) + real v + integer transn + integer ax + real aelogr + save + do 110 ax = 1, 2 + transn = nint (ct(ax,1)) + if (.not.(ax .eq. 1)) goto 120 + v = mx + goto 121 +120 continue + v = my +121 continue + v = ((v - ct(ax,4)) / ct(ax,2)) + ct(ax,3) + if (.not.(transn .eq. 0 )) goto 130 + goto 131 +130 continue + if (.not.(transn .eq. 1)) goto 140 + v = 10.0 ** v + goto 141 +140 continue + v = aelogr (v) +141 continue +131 continue + if (.not.(ax .eq. 1)) goto 150 + wx = v + goto 151 +150 continue + wy = v +151 continue +110 continue +111 continue +100 return + end + integer function grcses (tr, mx, my) + logical Memb(1) + integer*2 Memc(1) + integer*2 Mems(1) + integer Memi(1) + integer*4 Meml(1) + real Memr(1) + double precision Memd(1) + complex Memx(1) + equivalence (Memb, Memc, Mems, Memi, Meml, Memr, Memd, Memx) + common /Mem/ Memd + integer tr + real mx + real my + integer w + integer wcs + integer closes + real tol + real sx1 + real sx2 + real sy1 + real sy2 + real distae + real olddie + real xcen + real ycen + integer nin + integer in(16 ) + save + nin = 0 + closes = 1 + olddie = 1.0 + tol = (1.192e-7) * 10.0 + do 110 wcs = 1, 16 + w = ((tr)+154+(wcs)*11) + sx1 = memr(w+4) + sx2 = memr(w+5) + sy1 = memr(w+6) + sy2 = memr(w+7) + xcen = (sx1 + sx2) / 2.0 + ycen = (sy1 + sy2) / 2.0 + if (.not.(abs ((sx2-sx1) - 1.0) .lt. tol .and. abs ((sy2-sy1 + * ) - 1.0) .lt. tol)) goto 120 + goto 110 +120 continue + distae = ((mx - xcen) ** 2) + ((my - ycen) ** 2) + if (.not.(distae .le. olddie)) goto 130 + closes = wcs + olddie = distae +130 continue + if (.not.(mx .ge. sx1 .and. mx .le. sx2 .and. my .ge. sy1 . + * and. my .le. sy2)) goto 140 + nin = nin + 1 + in(nin) = wcs +140 continue +110 continue +111 continue + if (.not.(nin .eq. 1)) goto 150 + grcses = (in(1)) + goto 100 +150 continue + grcses = (closes) + goto 100 +100 return + end +c gtrint gtr_init +c grcses grc_selectwcs +c grcscs grc_scrtowcs +c olddie old_distance +c grcsen grc_settran +c transn transformation +c distae distance +c grcscc grc_scrtondc +c closes closest_wcs +c grcnds grc_ndctowcs +c grcwcc grc_wcstondc +c worign worigin +#------------------------------------------------------------------------------- +# grcwcs.s: + .data + .data1 + .bss + .data + .data1 + .bss + .data + .data1 + .bss + .data + .data1 + .bss + .data + .data1 + .bss + .data + .globl _grcscs_ + .comm _mem_,8 + .globl _gtrint_ + .globl _grcscc_ + .globl _grcses_ + .globl _grcsen_ + .globl _grcnds_ + .globl _elogr_ + .globl _grcwcc_ + .globl _i_nint + .globl _aelogr_ + .align 4 + .text +|#PROC# 07 + + .bss + .align 4 +VAR_SEG1: + .skip 16 + .bss + .align 4 +ARR_SEG1: + .skip 32 + LF1 = 20 + LS1 = 128 + LFF1 = 16 + LSS1 = 0 + LP1 = 28 + .text + .globl _grcscs_ +_grcscs_: + link a6,#-20 + movl d7,sp@ + movl a6@(8),sp@- + jbsr _gtrint_ + addqw #4,sp + movl d0,VAR_SEG1+4 + pea VAR_SEG1+12 + pea VAR_SEG1+8 + movl a6@(16),sp@- + movl a6@(12),sp@- + jbsr _grcscc_ + lea sp@(16),sp + movl VAR_SEG1+4,d0 + lea _mem_+60,a0 + movl a0@(0,d0:l:4),d7 + jne L77006 + pea VAR_SEG1+12 + pea VAR_SEG1+8 + pea VAR_SEG1+4 + jbsr _grcses_ + lea sp@(12),sp + movl a6@(28),a0 + movl d0,a0@ + jra L77007 +L77006: + movl a6@(28),a0 + movl d7,a0@ +L77007: + movl a6@(28),a0 + movl a0@,d0 + movl d0,d1 + addl d1,d1 + addl d1,d0 + asll #2,d1 + addl d1,d0 + movl VAR_SEG1+4,d1 + addl #154,d1 + addl d1,d0 + movl d0,VAR_SEG1 + pea ARR_SEG1 + pea VAR_SEG1 + jbsr _grcsen_ + addqw #8,sp + movl a6@(24),sp@- + movl a6@(20),sp@- + pea VAR_SEG1+12 + pea VAR_SEG1+8 + pea ARR_SEG1 + jbsr _grcnds_ + lea sp@(20),sp + movl a6@(-20),d7 + unlk a6 + rts +|#PROC# 07 + + .bss + .align 4 +VAR_SEG2: + .skip 32 + .data1 + .align 2 +L2D24: + .long 0 + .data1 + .align 2 +L2D22: + .long 0 + LF2 = 432 + LS2 = 15612 + LFF2 = 392 + LSS2 = 63 + LP2 = 12 + .text + .globl _grcsen_ +_grcsen_: + link a6,#-432 + moveml #15612,sp@ + fmovem #63,a6@(-392) + moveq #1,d7 + movl d7,VAR_SEG2+20 + movl a6@(12),d0 + moveq #20,d7 + addl d7,d0 + movl d0,a6@(-4) + movl a6@(12),d0 + moveq #12,d7 + addl d7,d0 + movl d0,a6@(-8) + movl a6@(12),d0 + addql #4,d0 + movl d0,a6@(-12) + movl a6@(12),d0 + moveq #-4,d7 + addl d7,d0 + movl d0,a6@(-16) + movl a6@(8),a0 + movl a0@,d7 + asll #2,d7 + movl #_mem_+16,d0 + addl d7,d0 + movl d0,a6@(-20) + movl #_mem_+12,d0 + addl d7,d0 + movl d0,a6@(-24) + movl #_mem_,d0 + addl d7,d0 + movl d0,a6@(-28) + movl #_mem_+-4,d0 + addl d7,d0 + movl d0,a6@(-32) + movl #_mem_+28,d0 + addl d7,d0 + movl d0,a6@(-36) + movl #_mem_+24,d0 + addl d7,d0 + movl d0,a6@(-40) + movl #_mem_+20,d2 + addl d7,d2 + movl #_mem_+8,d3 + addl d7,d3 + movl #_mem_+4,d4 + addl d7,d4 + movl #_mem_+32,d5 + addl d7,d5 + movl VAR_SEG2+20,d6 + asll #2,d6 + movl d6,a2 + addl a6@(-4),a2 + movl d6,a3 + addl a6@(-16),a3 + movl d6,a4 + addl a6@(-12),a4 + movl d6,d0 + addl a6@(-8),d0 + movl d0,a5 +L77011: + moveq #4,d7 + cmpl d7,d6 + jne L77015 + movl a6@(-36),a0 + movl a0@,d7 + movl a6@(-32),a0 + fmoves a0@,fp3 + movl a6@(-28),a0 + fmoves a0@,fp2 + movl a6@(-24),a0 + fmoves a0@,fp7 + movl a6@(-20),a0 + jra LY00000 +L77015: + movl d5,a0 + movl a0@,d7 + movl d4,a0 + fmoves a0@,fp3 + movl d3,a0 + fmoves a0@,fp2 + movl d2,a0 + fmoves a0@,fp7 + movl a6@(-40),a0 +LY00000: + fmoves a0@,fp5 + tstl d7 + jne L77020 + fmovex fp3,fp6 + fmovex fp5,fp0 + fsubx fp7,fp0 + fmovex fp2,fp1 + fsubx fp3,fp1 + jra LY00001 +L77020: + cmpl #1,d7 + jne L77027 + fcmps L2D24,fp3 + fjngt L77027 + fcmps L2D22,fp2 + fjngt L77027 + flog10x fp3,fp0 + fmovex fp0,fp6 + fmovex fp5,fp0 + fsubx fp7,fp0 + flog10x fp2,fp1 + fsubx fp6,fp1 +LY00001: + fdivx fp1,fp0 + fmovex fp0,fp4 +L77021: + fmovel d7,fp0 + fmoves fp0,a3@+ + fmoves fp4,a4@+ + fmoves fp6,a5@+ + fmoves fp7,a2@+ + addql #4,d6 + moveq #8,d7 + cmpl d7,d6 + jle L77011 + fmovem a6@(-392),#63 + moveml a6@(-432),#15612 + unlk a6 + rts +L77027: + fmoves fp3,VAR_SEG2+12 + pea VAR_SEG2+12 + jbsr _elogr_ + addqw #4,sp + fmoves d0,fp6 + fmoves fp2,VAR_SEG2+16 + pea VAR_SEG2+16 + jbsr _elogr_ + addqw #4,sp + fmoves d0,fp0 + fsubx fp6,fp0 + fsubx fp7,fp5 + fdivx fp0,fp5 + fmovex fp5,fp4 + jra L77021 +|#PROC# 07 + + .bss + .align 4 +VAR_SEG3: + .skip 12 + LF3 = 264 + LS3 = 15608 + LFF3 = 228 + LSS3 = 7 + LP3 = 12 + .text + .globl _grcwcc_ +_grcwcc_: + link a6,#-264 + moveml #15608,sp@ + fmovem #7,a6@(-228) + moveq #1,d7 + movl a6@(20),a2 + movl a6@(24),d3 + movl a6@(8),d6 + movl d6,d0 + moveq #20,d5 + addl d5,d0 + movl d0,a6@(-4) + movl d6,d0 + addql #4,d0 + movl d0,a6@(-8) + movl d6,d0 + moveq #12,d5 + addl d5,d0 + movl d0,a6@(-12) + movl a6@(12),a0 + fmoves a0@,fp5 + movl a6@(16),a0 + fmoves a0@,fp6 + moveq #-4,d5 + addl d5,d6 + movl d6,a6@(-24) + asll #2,d7 + movl d7,a3 + addl a6@(-4),a3 + movl d7,d4 + addl d6,d4 + movl d7,a4 + addl d0,a4 + movl d7,a5 + addl a6@(-8),a5 +L77034: + movl d4,sp@- + jbsr _i_nint + addqw #4,sp + movl d0,d6 + moveq #0,d0 + moveq #4,d5 + cmpl d5,d7 + seq d0 + negb d0 + movl d0,d5 + jeq L77038 + fmovex fp5,fp7 + jra L77039 +L77038: + fmovex fp6,fp7 +L77039: + tstl d6 + jeq LY00002 + cmpl #1,d6 + jne L77048 + flog10x fp7,fp0 + fmovex fp0,fp7 + jra LY00002 +L77050: + fmoves fp7,a2@ + jra L85 +L77048: + fmoves fp7,VAR_SEG3 + pea VAR_SEG3 + jbsr _elogr_ + addqw #4,sp + fmoves d0,fp7 +LY00002: + fsubs a4@,fp7 + fmuls a5@,fp7 + fadds a3@,fp7 + tstl d5 + jne L77050 + movl d3,a0 + fmoves fp7,a0@ +L85: + addql #4,d7 + addqw #4,a5 + addqw #4,a4 + addql #4,d4 + addqw #4,a3 + moveq #8,d6 + cmpl d6,d7 + jle L77034 + fmovem a6@(-228),#7 + moveml a6@(-264),#15608 + unlk a6 + rts +|#PROC# 07 + + .bss + .align 4 +VAR_SEG4: + .skip 12 + LF4 = 264 + LS4 = 15608 + LFF4 = 228 + LSS4 = 7 + LP4 = 12 + .text + .globl _grcnds_ +_grcnds_: + link a6,#-264 + moveml #15608,sp@ + fmovem #7,a6@(-228) + moveq #1,d7 + movl a6@(20),a2 + movl a6@(24),d3 + movl a6@(8),d6 + movl d6,d0 + moveq #12,d5 + addl d5,d0 + movl d0,a6@(-4) + movl d6,d0 + addql #4,d0 + movl d0,a6@(-8) + movl d6,d0 + moveq #20,d5 + addl d5,d0 + movl d0,a6@(-12) + movl a6@(12),a0 + fmoves a0@,fp5 + movl a6@(16),a0 + fmoves a0@,fp6 + moveq #-4,d5 + addl d5,d6 + movl d6,a6@(-24) + asll #2,d7 + movl d7,a3 + addl a6@(-4),a3 + movl d7,d4 + addl d6,d4 + movl d7,a4 + addl d0,a4 + movl d7,a5 + addl a6@(-8),a5 +L77060: + movl d4,sp@- + jbsr _i_nint + addqw #4,sp + movl d0,d6 + moveq #0,d0 + moveq #4,d5 + cmpl d5,d7 + seq d0 + negb d0 + movl d0,d5 + jeq L77064 + fmovex fp5,fp7 + jra L77065 +L77064: + fmovex fp6,fp7 +L77065: + fsubs a4@,fp7 + fdivs a5@,fp7 + fadds a3@,fp7 + tstl d6 + jeq LY00004 + cmpl #1,d6 + jne L77074 + ftentoxx fp7,fp0 + fmovex fp0,fp7 + jra LY00004 +L77076: + fmoves fp7,a2@ + jra L121 +L77074: + fmoves fp7,VAR_SEG4 + pea VAR_SEG4 + jbsr _aelogr_ + addqw #4,sp + fmoves d0,fp7 +LY00004: + tstl d5 + jne L77076 + movl d3,a0 + fmoves fp7,a0@ +L121: + addql #4,d7 + addqw #4,a5 + addqw #4,a4 + addql #4,d4 + addqw #4,a3 + moveq #8,d6 + cmpl d6,d7 + jle L77060 + fmovem a6@(-228),#7 + moveml a6@(-264),#15608 + unlk a6 + rts +|#PROC# 07 + + .bss + .align 4 +VAR_SEG5: + .skip 52 + .bss + .align 4 +ARR_SEG5: + .skip 64 + .data1 + .align 2 +L5D70: + .single 0r1.00000000000000000e+00 + .data1 + .align 2 +L5D68: + .single 0r1.00000000000000000e+01 + .data1 + .align 2 +L5D67: + .single 0r1.19200000000000000e-07 + .data1 + .align 2 +L5D49: + .single 0r2.00000000000000000e+00 + .data1 + .align 2 +L5D41: + .single 0r-1.00000000000000000e+00 + LF5 = 356 + LS5 = 8444 + LFF5 = 328 + LSS5 = 63 + LP5 = 8 + .text + .globl _grcses_ +_grcses_: + link a6,#-356 + moveml #8444,sp@ + fmovem #63,a6@(-328) + moveq #0,d3 + moveq #1,d2 + movl L5D70,VAR_SEG5+4 + fmoves L5D68,fp0 + fmuls L5D67,fp0 + fmoves fp0,VAR_SEG5+40 + moveq #1,d6 + movl a6@(16),a0 + movl a0@,a6@(-60) + movl a6@(12),a0 + fmoves a0@,fp2 + movl a6@(8),a0 + movl a0@,d0 + addl #154,d0 + movl d0,a6@(-36) + movl d3,d0 + asll #2,d0 + movl d6,d5 + movl d5,d1 + addl d1,d1 + addl d1,d5 + asll #2,d1 + addl d1,d5 + addl #ARR_SEG5+-4,d0 + movl d0,a5 + movl d5,d4 + addl a6@(-36),d4 + jra L77087 +LY00009: + moveq #1,d7 + cmpl d7,d3 + jne L77108 + movl ARR_SEG5,d7 +LY00008: + movl d7,d0 + fmovem a6@(-328),#63 + moveml a6@(-356),#8444 + unlk a6 + rts +LY00006: + addql #1,d6 + moveq #11,d7 + addl d7,d5 + addl d7,d4 + cmpl #176,d5 + jgt LY00009 +L77087: + movl d4,d7 + asll #2,d7 + lea _mem_+12,a0 + fmoves a0@(0,d7:l),fp6 + lea _mem_+16,a0 + fmoves a0@(0,d7:l),fp4 + lea _mem_+20,a0 + fmoves a0@(0,d7:l),fp5 + lea _mem_+24,a0 + fmoves a0@(0,d7:l),fp3 + fmovex fp6,fp0 + faddx fp4,fp0 + fdivs L5D49,fp0 + fmoves fp0,VAR_SEG5+28 + fmovex fp5,fp0 + faddx fp3,fp0 + fdivs L5D49,fp0 + fmoves fp0,VAR_SEG5+32 + fmovex fp4,fp7 + fsubx fp6,fp7 + fadds L5D41,fp7 + fabsx fp7,fp0 + fcmps VAR_SEG5+40,fp0 + fjnlt L77092 + fmovex fp3,fp7 + fsubx fp5,fp7 + fadds L5D41,fp7 + fabsx fp7,fp0 + fcmps VAR_SEG5+40,fp0 + fjlt LY00006 +L77092: + fmovex fp2,fp7 + fsubs VAR_SEG5+28,fp7 + fmoves fp7,a6@(-20) + fmoves a6@(-60),fp7 + fsubs VAR_SEG5+32,fp7 + fmoves fp7,a6@(-24) + fmoves a6@(-20),fp7 + fmulx fp7,fp7 + fmoves a6@(-24),fp1 + fmulx fp1,fp1 + faddx fp1,fp7 + fcmps VAR_SEG5+4,fp7 + fjnle L77096 + movl d6,d2 + fmoves fp7,VAR_SEG5+4 +L77096: + fcmpx fp6,fp2 + fjnge LY00006 + fcmpx fp4,fp2 + fjnle LY00006 + fcmps a6@(-60),fp5 + fjnle LY00006 + fcmps a6@(-60),fp3 + fjnge LY00006 + addql #1,d3 + addqw #4,a5 + movl d6,a5@ + jra LY00006 +L77108: + movl d2,d7 + jra LY00008 + .globl f68881_used + .data1 +#=============================================================================== diff --git a/doc/ports/sun4_sep87.doc b/doc/ports/sun4_sep87.doc new file mode 100644 index 00000000..e10f5232 --- /dev/null +++ b/doc/ports/sun4_sep87.doc @@ -0,0 +1,296 @@ +Begin port of Sun/IRAF to the Sun-4 (RISC/sparc cpu). +Beginning Saturday, 26 Sep 1987 (dct). +========================================= + +V2.5 release was installed on the disk at /usr/iraf and stripped of all m68x +binaries, by Skip before I started. + +/etc/termcap +/usr/local/* + +/local -> /usr/local + + The first step was to add some local utilities to the standard Sun + release. Added entries for terminals sun{24,34,40,54},unixpc to the + termcap (unixpc is so I can work from home). Added a bunch of stuff + in local, e.g., less, egrep, top, sps, mon, a modified 'man' which + uses less, etc. (9/26) + +cd $iraf/unix +sh -x mkpkg.sh >& spool & + Did a trial bootstrap just to see what would fail. The only files + giving problems were, as expected, as$zsvjmp.s and os$zxwhen.c. (9/26) + +unix/os/zxwhen.c + Replaced the entire hardware exception initialization list by a + version which will work on any sun (680XX or sparc) or a Vax. (9/26) + +unix/hlib/libc/iraf.h + Deleted the BSD42 and BSD43 entries, which were never used. Replaced + with BSDUNIX (which has still not been used but will be, along with + a SYSVUNIX or some such). In zxwhen.c, the #ifdefs use the system + type names defined by the C compiler, e.g., vax, sparc, m68k, etc. + (9/26) + +bin +bin.sparc + +bin.ffpa - +bin.f68881 - + Deleted the .ffpa and .f68881 binaries for this host, and added a + bin.sparc directory for the sparc binaries. Set bin to point to this. + (9/26) + +unix/mkpkg.sh +unix/as -> unix/as.`mach` +unix/as.vax +unix/as.sparc + +unix/as.mc68020 + + The different assemblers are quite incompatible, even on a Sun. + To make it possible to maintain sources for all Suns in one Sun/IRAF + source, I set up as.XX directories for the assembler sources for + each main hardware type, and made as a symbolic link to the particular + version in use. The value of as is set automatically by mkpkg.sh + during a bootstrap. Note that this does not necessarily work when + using a single source to maintain multiple versions of the system; + I will wait and resolve that later. (9/26) + +unix/as.sparc/zsvjmp.s + Wrote a zsvjmp/zdojmp for the sparc architecture. This was not + difficult, except for the time required to figure out the machine + architecture and assembler, which is not very well documented in the + gamma release of the SunOS for the Sun-4. (9/26-27) + +cd $iraf/unix +sh -x mkpkg.sh >& spool & + Did a real bootstrap, this time it completed with no errors. (9/27) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf + In mkpkg.inc, set the FPU option to 'sparc'. Added some $ifeq code + to set the XFLAGS,LFLAGS,XVFLAGS different for sparc than anything + else, since no -/fparc is tolerated on the commands to the compiler + programs. In the mkpkg.sf, deleted all the old special file entries + having to do with compiler bugs, since we have a completely new set + of compilers to deal with on this machine (they really are very + different, especially in the optimization and code generation). (9/27) + +local/.login + Commented out the code which sets FLOAT_OPTION, since the compilers + give errors if this is set to 'sparc', even on a sparc cpu (this is + inconsistent). (9/27) + +unix/hlib/cl.csh + Added support for machine type 'sparc'. (9/27) + +cd $iraf +mkpkg >& spool & + Tried to do a sysgen of the full system. This died on the very first + file, with rpp.e going into an infinite loop. This was traced to an + optimizer bug in rpp.e, see below. (9/27) + +unix/boot/spp/rpp/mkpkg.sh + Added some code to compile rpp/rppfor/outch.f without optimization, + to work around an optimizer bug which would cause an infinite loop. + (9/27) + +cd $iraf +mkpkg >& spool & + Successfully started up a sysgen of the full system and went home + for the day. (9/27) + +unix/hlib/mkpkg.sf + When I checked the next day, the sysgen was hung in an infinite loop + in the optimizer (iropt), trying to compile pkg$lists/unique.x. + Added an entry with flags "-cq -P" to the special file list, allowing + the file to be compiled. Checking back over the spooled output, + I found that the only other file giving problems was pkg$cl/ytab.c, + which produced the following error message when compiled: + + Routine _yyparse too big: + use a lower level of optimization or + increase stack limit and / or + size of swap space + + compiler(iropt) error: alloca: out of memory + + This was due to the static control flow analysis perfomed by the + fancy new 3 level C code optimizer that comes with the Sun-4. + The yyparse routine (the parser) in the CL is a very large function, + and it is not surprising that it overflows something. In this case + the runtime data structures required for the static flow analysis + exceeded something like 10 Mb (!), causing the compiler to run out + of memory. Added the file to the special file list with the flags + "-cq -/O2" (the default -O gives -O3 or third level optimization). + (9/28) + +------------------- +With these changes, the sysgen completed normally. Some brief testing showed +that x_system.e would run stand alone, but the CL would die on a bus error. +Some interesting comparisons of object and executable sizes: + + BSD(11/750) Sun-3 Sun-4 + du -s bin 17345 16801 20593 + du -s lib 3234 2932 3787 + + Hence, it turns out that the binaries for the Sun-4 with its RISC cpu + are not that much larger than for the CISC machines, after all. + The slighly larger disk file size of the BSD VAX compared to the Sun-3 + was due to the symbol table in the (unstripped) executables being + larger for BSD than for the Sun. (9/28) + +sys/etc/envreset.x + The bus error in the CL turned out to be due to a short being passed + as an int in a procedure call in the above routine. It took me a + while to figure this out, due to the time required to learn to use + ADB on a RISC machine. Most of this was just becoming familiar with + the machine architecture, but it is a bit harder to match the + assembler up with the high level code on a RISC machine, due to the + many similar looking simple little instructions, and the heavy + optimization performed by the compiler. A lot of little ADB things + are different - the register set in the sparc architecture is like + nothing you have ever seen before, the pipelining is visible (the + instruction after a branch or function call is always executed + even if the branch is taken, and is shown AFTER the branch!), + the arguments to a procedure seem to be always passed in registers + (haven't tried any procedures with very long argument lists yet), + so on. One interesting discovery was that there are no MUL and DIV + instructions in the RISC cpu!. These are implemented as subroutines, + but seem to be pretty fast nonetheless (but about 6 times slower than + an add). (9/28) + + [With this change the CL now comes up fine, and all the little system + [things I tried work. zdojmp/zsvjmp are not working correctly in + [the CL, although they worked fine in a C test program I wrote, and + [they work fine in x_system.e run stand alone.] + +unix/hlib/libc/setjmp.h + Added a "#pragma unknown_control_flow", #ifdef-ed for the sparc. + This is necessary to tell the C optimizer that any routine which calls + setjmp (zsvjmp_) may trash the registers or do other strange things. + This was the cause of the zsvjmp failure in the CL (C) code. (9/29) + +dev/help.db + Rebuilt the help datbase - all is well. (9/29) + +---------------------------- +A little further testing immediately shows further problems, although a lot +of stuff is working correctly now. We still have a very buggy system here. +Did not get much time to work on this today. (9/29) + +pkg/cl/unop.c +pkg/cl/binop.c +pkg/cl/opcodes.c + The problem with the CL getting confused about whether certain files + existed or not turned out to be due to another IRAF bug, rather than + a Sun bug. The problem was the macro VALU(o) in the CL. This checks + the operand type and conditionally accesses and returns either the + integer or real value. This was being used to fetch the value of a + boolean operand, and it was natural for the code to assume that VALU + would return an integer value for a boolean operand. Not so, however. + The datatype of the conditional expression used in this macro is + evaluated at compile time, hence is double rather than int, and the + CL was doing boolean operations on double floating quantities. + + This has gone undetected up until now, but for some reason zero values + were testing not zero-floating on the sparc cpu. Integer 0 was being + loaded into a floating register, and the floating result after a + convert integer to double instruction was a very small floating point + number (exponent -212), with value exactly 0 when printing the binary + floating number in hex. Evidently binary zero is not the same as + floating zero on this cpu. (9/30) + +---------------------------- +Did a new sysgen to relink all executables to pick up bug fixes. +Things seem to be working pretty well now. Known problems: + + Contour dies on a segmentation violation every time, + and ERROR RECOVER IS NOT WORKING (the latter is true + on all systems I think, and must be due to a bug in + this program) + +local/sun +local/sun/Makefile + Deleted this code and replaced by the new (3.4) version from tucana. + Rebuilt suntools.e. This died on the first attempt due to a symbol + CPUTYPE=-mc68010 in the Makefile that came with the suntools code + from Sun, on the Sun-4! Modified the Makefile in local/sun to call + the suntool Makefile with CPUTYPE="", and suntools.e was built + successfully. (9/30) + +cd $hlib +install + Installed the custom suntools software. This has not yet been tested, + since I am working remotely. (9/30) + + +Begin IRAF Installation on ORION (NOAO/Tucson Sun-4) +SunOS Release Sys4BETA1 (ORION) #1: Fri Oct 23 13:09:29 PDT 1987 +---------------------------------------------------------------- + +Did a little UNIX level configuring, as orion only just came up: + Replaced termcap by tucana version. + Replaced /etc/group by tucana version. + Created /usr/local; someone else installed sources; I compiled and + installed sps, man, less, etc. + NOTE: the f77 compiler is back-ordered, so we nabbed the GAMMA + release compiler from hercules, until ours comes in. + +Created directory on /usr, read in V2.6 export version from lyra (same as + prepared for the Convex Port). + +Configured Sun-3 kernel from tucana for the Sun-4: + Made as a link to as.sparc. + Replaced mkpkg.inc and mkpkg.sf by the Sun-4 versions. + Uncommented #pragma in hlib/libc/setjmp.h. + Fixed a bug in boot/spp/rpp/mkpkg.sh (mach -> `mach`). + +Booted the system successfully. +Started a full sysgen and went home. (10/23) + +Examine spooled output from Sysgen (10/24): +-------------------------------------------- + +sys/fmtio/evexpr.x + Failed with the message: + f77: Fatal error in iropt: Segmentation fault (core dumped) + But it compiled just fine when I ran mkpkg on the directory. (??) + +noao/onedspec/sensfunc/mkpkg +noao/onedspec/sensfunc/sfgraphs.x + Deleted the junk file (zero length) sfgraphs.x, and its entry in + the mkpkg file list. (10/24) + +local/tasks + There was a problem here caused by my forgetting to delete the binaries + when I moved the Sun/IRAF version of local over from tucana. (10/24) + +local/sun/mksuntools.csh + Contained the statement "rm -rf *", used to delete the old 'suntool' + subdirectory before building a new one. If the directory already + happended to be empty, this would cause rm to return an error exit + status, causing the script to terminate prematurely. The suntools + executable would appear to be built correctly, but gterm and imtool + would not run. (10/24) + +unix/hlib/mkpkg.sf +unix/hlib/libc/setjmp.h + Had problems with register allocation again in the CL main, where + setjmp (ZSVJMP) is used. Unlike the case with the gamma release, + the #pragmas in did not fix things this time, so I + had to add the affected files to the special file list to be + compiled with no optimization. (10/24) + +unix/hlib/mkpkg.inc +unix/hlib/mkpkg.sf.SUN3 +unix/hlib/mkpkg.sf.SUN4 + Replaced mkpkg.sf by two versions, one each for the Sun-3 and Sun-4. + The one to be used is conditionally loaded via a $ifeq statement in + the mkpkg.inc file. (10/24) + +local/sun/imtool.c + There is a bug in the C library SCANF routines: scanning a perfectly + legal input string with a format such as "%f%f%f..." results in the + scan terminating after processing only the first floating point number. + I had to rewrite a section of code in IMTOOL to use the lower level + ATOF conversion routine to read the wcs file. (10/25) + + [The above was due to us getting a BETA release of the OS, and went + [away when we got the GAMMA release.] diff --git a/doc/ports/sun_f77bugs.doc b/doc/ports/sun_f77bugs.doc new file mode 100644 index 00000000..e4a39469 --- /dev/null +++ b/doc/ports/sun_f77bugs.doc @@ -0,0 +1,15 @@ +Different problems were encountered in both Sun-2's and Sun-3's +with the f77 compiler. On the Sun-2, the problems were in the +optimizer. See the "sun2*.doc" files for documentation on which +IRAF source files generated compile-time and run-time problems. + +On the Sun-3, the worst problem was that Sun forgot about complex +datatypes after Sun V2.0. See the notes in the "sun3*.doc" files. +Sun still (June 24) has not solved the problem, but Doug Tody came +up with workarounds; look for the string "kludge" in "sun3_042586.doc" +and in the directory $iraf/unix/hlib/SUN_kludge/. + +There were also three IRAF source files that generated run-time +errors on the Sun-3 due to bugs in the "-f68881" version of the f77 +optimizer; these files are documented in "sun3_f77Obugs.doc". + diff --git a/doc/ports/unix.isi b/doc/ports/unix.isi new file mode 100644 index 00000000..a45b8c9c --- /dev/null +++ b/doc/ports/unix.isi @@ -0,0 +1,87 @@ +From rooke Thu Feb 27 11:35:41 1986 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA06429; Thu, 27 Feb 86 11:35:35 mst +Date: Thu, 27 Feb 86 11:35:35 mst +From: rooke (Steve Rooke) +Message-Id: <8602271835.AA06429@lyra.noao.UUCP> +To: tody +Subject: Ebert's mail +Status: R + +>From ipac3!rick Wed Feb 26 19:35:54 1986 +Received: from noao.UUCP (carina) by lyra.noao.UUCP (4.12/4.7) + id AA03007; Wed, 26 Feb 86 19:35:50 mst +Received: by noao.UUCP (4.12/4.7) + id AA27537; Wed, 26 Feb 86 19:36:52 mst +Received: by ipac3.ARPA (4.12/4.7) + id AA10161; Wed, 26 Feb 86 18:32:49 pst +Date: Wed, 26 Feb 86 18:32:49 pst +From: ipac3!rick (Rick Ebert) +Message-Id: <8602270232.AA10161@ipac3.ARPA> +To: rooke@noao +Subject: IRAF @ IPAC [up] +Cc: noao\!tody +Status: RO + +Steve, + +The news is mostly good: IRAF is up at IPAC! The blessed event +occurred at 11:44:46 PST on 26 Feb. The new addition weighed in at +a little over 46Mb. + +All of our trouble seems to have been related to an obstinate fortran +optimizer. Once I figured out how to turn off that -O flag everywhere +in IRAF's mkpkg, it all fell into place. (As promised, a list of +files that gave our optimizer indigestion follows, but I'm convinced +the problem is with some northern California compiler writers and not +with IRAF.) + +I did run into a problem quite quickly though. I managed to make the +help data base by doing this: + +cl> softools +so> mkhelpdb + +IRAF proceeded to produce lots of stuff. +With many of the "help" requests that I tried the formatted manual +page printed on the screen as expected, followed by a listing of +what appeared to an unformatted copy of the same help file (there +were lots of .xx commands at the beginning of lines). Once this +starts to print out, a response of "n" to "More?" causes the whole +of iraf to crash. If I coax it with an interupt I receive the message, + +ERROR: subprocess is hung: process should be killed + +wait several seconds and interupt again, then I'm back in the csh +(this is probably our unix doing houskeeping). + +Not a very well documented bug, but I wanted to get it to you +right away. The "help" is all I have to learn IRAF! (Sob, poor me). + +Rick Ebert, Infrared Processing and Analysis Center (IPAC) +Cal Tech MS 100/22, Pasadena, CA 91125 + +Ma Bell: 818-584-2963 (MWF) +UUCP: ipac3!rick + +"Problem" files: + +./sys/fio/fwtacc.x +./pkg/system/help/helpdb.x +./pkg/system/help/prfile.x +./pkg/system/directory.x +./pkg/system/isdir.x +./pkg/onedspec/identify/isdir.x +./pkg/system/lprint.x +./pkg/system/page.x +./pkg/xtools/isdirectory.x +./pkg/dataio/imtext/rt_rwpix.x +./pkg/dataio/cyber/rrcopy/rc_rheader.x +./pkg/dataio/cyber/rrcopy/read_rcopy.x +./pkg/dataio/cyber/t_ridsfile.x +./pkg/dataio/cyber/read_dumpf.x +./pkg/dataio/cyber/read_pft.x +./pkg/images/geometry/geogmap.x +------that-is-all--------------------- + + diff --git a/doc/ports/vms_jan85.st b/doc/ports/vms_jan85.st new file mode 100644 index 00000000..3ad46793 --- /dev/null +++ b/doc/ports/vms_jan85.st @@ -0,0 +1,994 @@ +Notes file for VMS/IRAF V2.2 Installation +Beginning 16 January 1985 (code prepared on UNIX) +------------------------------------------------ + +vms/* + Moved unix/* to vms/*. (1/16) + +vms/os/* + Moved the current VMS kernel into host$os. (1/16) + +vms/os/mkpkg + Wrote mkpkg file for OS. (1/16) + +vms/as/*.s + Replaced all these assembler files by their VMS equivalents. Deleted + all the arithmetic VOPS machine files, as they are not worth it on + VMS (probably not worth it any more on UNIX, either). Wrote the new + routine ACLR.S for VMS. (1/17) + +vms/os/zsvjmp.s + Moved to AS. (1/17) + +vms/os/str.s + Added _strupk, _strpak, since the VMS kernel references these + internally, they need to be in LIBOS. Added the underscore to avoid + conflict with the OSB (C) versions used by the VOS. I know it seems + wasteful to duplicate essentially the same routine in different parts + of the system, but the subsystem interfaces must be respected. The + alternative is to add the routines to the kernel, but this involves + an expensive interface modification, and I don't think its worth it + for such trivial little routines. (1/17) + +vms/os/zfiotx.c +vms/os/zfioty.c +vms/os/zfrnam.c + Changed references to strpak, strupk to _strpak, _strupk. (1/17) + +vms/hlib/* + Set up the HLIB directory. This involved minor edits to config.h, + clpackage.cl, etc., and most of the .cl scripts therein. Moved in + all the .com files from the original "vms" directory from V2.0 of + VMS/IRAF. Added logical names for TMP and HOST to irafuser.com, + also logical names for MKPKG, RMBIN, etc. (1/18) + +vms/hlib/libc/iraf.h + Modified for VMS. The remaining files are now the same for both + UNIX/IRAF and VMS/IRAF. (1/18) + +vms/boot/bootlib/* + Minor changes for VMS. (1/19-20) + +vms/boot/generic/* + Minor changes for VMS. (1/20) + +vms/boot/mkpkg/* + Fairly extensive changes for VMS. Picked up the SCANLIB code from + the old VMS mkpkg; for the rest (mkpkg/host.c) I just modified the + new UNIX code as necessary for VMS. Still using the docvcl() stuff + to call XC, which is a kludge, but presumably it helps cut down on + process spawns. (1/20-21) + +vms/boot/mkpkg/scanlib.c,rec.c + Had second thoughts about this code. A full but null sysgen must be + incredibly slow on anything less than an 8600, since the old vms mklib + would physically open and read each file to map an object file name + into an object module name to get a date. Even on the 8600 it is + probably an order of magnitude slower than the new MKPKG on the UNIX + 750. Opening the source files with the C i/o can also change the file + modify dates, and the modify date is valuable information which I hate + to lose. + + To avoid this dreadful situation, I have decided to not use the VMS + librarian at all to track object module dates. Instead, for each + library there is an associated module date database file, e.g., + libsys.mlb for libsys.olb. This is updated by MKPKG when + objects are inserted into the library. If modules are replaced in + the library at the VMS level, MKPKG will simply recompile those + modules when eventually it is run (unless a utility program is run + to update the .mlb dates). But since the new MKPKG is such a screamer + anyhow, there is no need to use REPLACE.COM, or whatever, to update + modules in libraries - and the thing is dangerous anyhow (it is easy + to put the module in the wrong library, for example). + + This approach has the further advantage that the technique and the + code are both portable and can be reused on other systems that, like + VMS, do not manage libraries the way we would like. (1/21) + +vms/boot/rmbin +vms/boot/rtar +vms/boot/wtar + No changes for VMS, other than to replace the mkpkg.csh by a mkpkg.com. + (1/22) + +vms/boot/xyacc + Not supported on VMS. (1/22) + +vms/boot/spp/[...] + Some work was required here for VMS. The VMS version of RATLIBC was + picked up wholesale, but the UNIX versions of RATLIB[RF], RPPRAT, and + RPPFOR were used without change (these contain recent revisions which + were documented elsewhere). The VMS version of SPP.C was used (it + does more), but the UNIX versions XPPMAIN.C, XPPCODE.C, and DECL.c + were used, since they should be portable, now address all of the + issues dealt with in the VMS versions, and have recent revisions. + The VMS version of XC.C was used with very minor revisions. DCL.C + (the special ZOSCMD) was moved to BOOTLIB and hooked into os_cmd(). + + To summarize, the VMS versions of XC.C, RPP.C, and RATLIBC were used + with minor changes since they have been extensively modified for VMS. + The UNIX versions of the remaining files were used since they should + work for VMS, and it is desirable to minimize the differences between + the two versions to ease future merges. + + A DCL mkpkg.com was written for each directory under SPP. These are + for bootstrap purposes and will always recompile everything. It is + assumed that some version of LIBSYS and LIBVOPS is available for + filename mapping purposes. (1/22) + +vms/os/zfiomt.c + Removed the device table stuff, since the drive argument to ZZOPMT + is now the VMS device name. Density checking is performed at allocate + time by the VOS. It appears that the density is not being set + anywhere. (1/22) + +vms/os/zalloc.c + +vms/os/cltape.c - +vms/os/devtable.c - + Added the two new kernel routines ZDVALL and ZDVOWN, in the file + zalloc.c. They were easy to generate as the original cltape.c code + was quite well structured. Deleted the files cltape.c and devtable.c + since they are no longer used. (1/22) + +------------------------------------------- +That completes the coding modifications for VMS/IRAF, done on UNIX. +System moved to VMS for compile test beginning the 23rd. (1/22) + +(edited the mkpkg.coms, fixed compile time bugs, not worth recording here) + +vms/boot/generic/lexyy.c + Made the same changes for VMS as were made for the Lex/C output of + xpp.l. Should add editor script in UNIX version to make these + changes whenever lexyy.c is generated. (1/23) + +vms/os/zfnbrk.x +vms/os/zfxdir.x +vms/os/zfpath.x +vms/os/zfsubd.x + Replaced these SPP source files by equivalent C versions, to simplify + bootstrapping the system. It is just as easy to work on XCHAR arrays + in a C program as char arrays, hence there is no advantage to using + SPP for these routines. (1/23) + +TODO + Note - ZFNBRK differs from the UNIX version in that it ignores \ in + filenames (rather than interpreting them as directory delimiters). + Should merge back into UNIX version, too. (1/23) + +vms/boot/bootlib/osfn2vfn.c +vms/boot/bootlib/vfn2osfn.c + Added #undefs for fprintf, strcpy to cancel out the defines in libc.h. + (1/23) + +vms/hlib/libc/xnames.h +vms/hlib/libc/xnames.no_ + Added a define for VFNUNMAP. (1/23) + +vms/os/zzstrt.c +vms/hlib/libc/knames.h +vms/hlib/libc/knames.no_ + Discovered that the VMS kernel does not have the entry points _zstartup + and _zshutdown. These are used in programs that do not have a ZMAIN. + They are currently no-ops in both UNIX and VMS, but in general it sure + seems that they might be needed; the bootstrap utilities would not + link because the routines were missing. If we are going to have them + they should be Fortran callable too, so I changed the names to ZZSTRT + and ZZSTOP and added them to the VMS kernel (as no-ops). (1/23) + +vms/boot/* + Replaced all references to _zstartup and _zshutdown by references to + ZZSTRT and ZZSTOP. (1/23) + +vms/boot/rtar/rtar.c + Declared getblock() at the head of the file and deleted the local + definitions in each procedure. (1/23) + +vms/hlib/libc/xnames.h +vms/hlib/libc/xnames.no_ +vms/boot/bootlib/vfn2osfn.c +vms/boot/bootlib/envinit.c + Use of the VOS for filename mapping requires initialization of the + iraf environment table. VFN2OSFN will now initialize the env. table + the first time it is called, taking SET declarations from the + zzsetenv.def file in hlib. Added a define for ENVINIT to xnames.h + to initialize the env data structures; ENVPUTS is called to make + entries in the table. The bootlib init procedure is _envinit(). (1/23) + +vms/boot/bootlib/osfpathname.c + Added call to vfn2osfn() before call to ZFPATH. (1/23) + +vms/boot/bootlib/oschdir.c + Replaced call to os_fpathname() by call to ZFSUBD, since the former + produces an OS filename rather than an OS directory name, and VMS + insists on the latter. (1/23) + +vms/boot/hlib/libc/spp.h + Added a definition OSOK to spp.h. This is the value a foreign task + should return for normal successful completion, i.e., 0 for UNIX, + and 1 for VMS. (1/23) + +vms/boot/mkpkg/host.c +vms/boot/mkpkg/modlist.c +vms/boot/bootlib/*.c + Lots of changes to the system interface code to get MKPKG to work + properly on VMS. (1/23-24) + +vms/boot/bootlib/osdir.c + This code was rewritten to vfnopen the directory at diropen time + for efficiency reasons. Debugged the VOS filename mapping interface. + RMBIN was used to test the OSDIR code. (1/24) + +vms/boot/hlib/libc/libc.h + Added a #ifdef to turn off LIBC name redefinitions, for programs like + the bootstrap utilities which need to import_libc, but which want to + use the host system strcpy, printf, etc. (1/24) + +vms/boot/rtar.c +vms/os/zfiotx.c + I had a binary file on a supposedly text only tar tape. The file would + pass the ZFACSS test and appear to be a text file. RTAR would try to + use ZFIOTX to write the output file; the result was an access violation + in ZPUTTX, presumably because of the binary data. (1/24) + + [not yet resolved] + +vms/boot/rmbin [!!! NASTY BUG !!!] +vms/os/zfdele.c + Ran into an interesting problem with RMBIN. This task reads through + a directory, deleting any binary files found. The problem is that on + VMS, while the directory is open for reading, one cannot delete any + files in the directory because the directory file is locked. Not only + does this make RMBIN fail, it will also make a regular file delete, + create, rename, etc., fail, if the request is issued while another + process is reading from the directory!!! This means that bkg jobs + will mysteriously bomb out at random intervals on a file error. (1/24) + + [not yet resolved] + +sys/mkpkg + Added a $purge lib$ to the end of the sysgen section (after updating + all the system libraries). This will purge all the old versions of + the libraries after a sysgen. In the first attempt at a full sysgen + on the 24th, MKPKG went into a loop and filled up a disk, creating + 43 versions of each system library! (1/25) + +sys/mkpkg/pkg.c + The MKPKG loop mentioned earlier turned out to be due to a bug in the + VMS C stdio. FTELL returns the offset of the current record, rather + than the offset of the next record as the documentation states (and as + is necessary for UNIX compatibility). MKPKG would therefore repeat + the last command after pushing (ftell) and restoring (fseek) its state + to call a lower level module. This explains the problem, but does not + explain how it ever worked as well as it did in the first trial; we + may not know the whole story yet. + + No choice but to add an #ifdef vms to pop_context() in pkg.c to skip + forward one line after an FSEEK. (1/25) + +vms/os/net/kutil.c + Eliminated the reference to the macro define IRAFDIR, which has been + deleted. (1/25) + +vms/mkpkg + Added a call at the end to MKPKG to update LIBOS, since the bootstrap + does not get the networking stuff. (1/25) + +sys/libc/cfnames.c - + Deleted this file, which was apparently forgotten about after the + contents were unpacked into separate files. (1/25) + +vms/boot/mkpkg/pkg.c + As expected, the FTELL/FSEEK problem has not yet been resolved. After + running tests for several hours, most of which worked, I was unable to + isolate the problem. Simple little test programs always work correctly + (i.e., they always seek to the wrong line). I was able to determine + that when it fails it is because FTELL returns the wrong offset. It is + conceivable that MKPKG could be corrupting a stdio data structure, but + I doubt it. More likely there is a bug in the VMS FTELL. + + The next attempt at a workaround is to avoid the use of FTELL entirely + for VMS. Instead, I wrote a little package k_getc, k_fgets, k_ftell, + k_fseek. The getc counts characters, the ftell returns the char + offset, and the fseek rewinds the bloody file and reads so many + characters to get to the seek position. With this change, "mkpkg -n" + was able to traverse the system successfully. This code could be + useful on any system, so I will leave it in with a switch; there is + little effect on speed. (1/25) + +vms/os/zfiotx.c + It appears that the RTAR crash when writing binary data into a text + file was due to the lack of overflow checking in ZPUTTX. Added + overflow checking. (1/25) + +------------ +Started a full sysgen on 25 January. This ran to completion, uncovering the +usual assortment of compile time bugs not found on UNIX/IRAF. + +NOTE TO VMS/IRAF PROGRAMMERS + To relink a package executable for debugging on VMS, enter the + following command to relink with the "-x" flag: + + mkpkg lflags=-x + + For most packages, this will produce a debug version of x_test.e in + the local directory. The user package in the IRAF login.cl file + defines a foreign task "mkdebug" to make this easier: + + task $mkdebug = "$mkpkg lflags=-x" + + After debugging is complete, the following command will relink and + install a new executable: + + mkpkg update + + Alternatively, you can always type in a long "xc -x ..." command. + DCL .com files should not be used in the SYS or PKG directories. + +sys/mkpkg + Made compilation of libmain.o optional, under control of a switch in + hlib$mkpkg.inc. The VMS XC does not need a separate object module, + hence it is turned off for VMS. LIBMAIN is a prelinked object module + on UNIX, and will eventually be the sharable library on VMS, once we + figure out how to have MKPKG udpated during a sysgen. (1/26) + +vms/hlib/libcalcomp.a [SITE DEPENDENT] + Copied the VMS version of this library into HLIB. The source for the + library is local and is not part of IRAF. To link with this library, + one must reference the C runtime library CRTLIB.OLB in their login.com + file. Other sites may have a different version of the calcomp library, + or the Versaplot library, any of which will probably do as well for + the GIO calcomp kernel. (1/26) + +math/llsq/sva.for + On lines 179, 181, the comma at the end of the line was in column 73, + hence VMS/FORTRAN would ignore it. Moved to column 7 of the first + continuation line. (1/26) + +pkg/dataio/idsmtn/bswap6.c + Changed the [include "iraf.h"] to [include ]. (1/26) + +pkg/images/geometry/geotran.x + On line 531, changed a couple of '0's to '0.'s in calls to the intrinsic + function MAX (argument type mismatch). (1/26) + +pkg/local/mkpkg + Disabled the PERITEK code on VMS. This is a local, UNIX dependent pkg + (written by a staff astronomer) not intended for use outside of NOAO. + Will compile now only if site=noao and hostid=unix. (1/26) + +pkg/local/intrp.f + Near the end of file, contained a line that extended way beyond col 72. + Detabbed the file and made extra continuation for the long line. Has + already been updated on UNIX/IRAF (where I did the detab). (1/26) + +pkg/onedspec/identify/idpeak.x + Argument type mismatch in call to max(). (1/26) + +pkg/twodspec/longslit/transform/trtransform.x + Several array arguments were dimensioned using variables NX,NY defined + in COMMON. Changed to ARB to get it to compile (the original is not + legal Fortran), but passing the array dimensions via common is a more + serious problem. (1/26) + +pkg/utilities/t_polyfit.x +pkg/utilities/pfregres.f + + The polyfit task called the Bevington procedure REGRES which implicitly + called a function with the explicit external name FCTN. The source + for FCTN was provided with that for the polyfit task, but the VMS + librarian would store it in a separate library object module. Hence, + at link time REGRES causes a backwards reference to FCTN in the package + library, but since that library had already been searched the module + would not be found and the link would fail. + + This could be solved by moving FCTN into a separate object file not + in the package library, and linking it explicitly by name. Instead, + I copied the source for REGRES into the local file pfregres.f, and + added a reference to FCTN (renamed pf_fctn) in the pf_regres argument + list as an external. The real problem here is the Bevington library, + a simple instructional tool which was never intended to be used in an + application such as ours. Coupling to the outside world via a reserved + external name (FCTN) is as bad as common coupling. In both cases the + information should come into the procedure in an obvious way via the + argument list. (1/26) + + The new code should be tested. + +pkg/imred/vtel/readvt.x + Assignment to DO variable `subswath' within loop. Recoded to use a + FOR loop. (1/26) + +pkg/mkpkg + Added a "purge [...]" at the end, to be executed only on a vms host. + (1/26) + +------------- +(End of compile time bug fixes) +(All of the above files where also updated in UNIX/IRAF, so that the PKG +(sources are still identical in both systems). + + +pkg/cl/opcodes.c [+ globaldef] +pkg/cl/globals.c [+ globaldef] +pkg/cl/main.c [+2 globalref] + I was forced to add #ifdef vms globaldef, globalref nonsense to these + files to enable a standard XC call to link the CL. I suspect that + linking C data-only modules will be a problem on other systems as well; + in the future, we may want to outlaw data only modules in portable C + code. (1/26) + +(With this last fix, the new system is fully up and seems to be running +(fine, performing all basic functions normally). + +dev/devices + Edited for VMS. Decided to use the third field ("aliases" for UNIX) + to pass the density at device allocation time. For VMS it appears + the density must be set at ALLOCATE (mount) time. (1/26) + +vms/hlib/devstatus.cl + Edited for VMS. After printing the IRAF status (which is obtained + by a direct inquiry to VMS, not by just looking for a lock file), + devstatus will scan the device table dev$devices and do a + "!show devices/full device" to print the VMS info. (1/26) + +pkg/cl/scan.c + Would only skip blanks between the tokens; will now skip both spaces + and tabs. (1/26) + +vms/boot/spp/xc.c + Modified to actually create a shareable image with no traceback when + the -n flag is specified (it was a no-op before). Doesn't seem very + useful yet (the resultant image cannot be executed or installed), + but it will be useful for testing purposes. (1/26) + +vms/hlib/devstatus.cl + Added a boolean param verbose, default no, controlling whether the + SHOW DEV info is printed. Since the IRAF device status now comes + from VMS, we no longer need the VMS output, and it is a lot faster + without it. (1/26) + +vms/hlib/login.cl + Added a default NOAO USER package to the default login.cl. This serves + as a starter package for each user to modify as they wish. Each site + will wish to set up their own default package. (1/27) + +vms/os/open.c + Modified to provide shared access to files opened for reading, to + avoid the locked directory problem mentioned earlier. (1/27) + +sys/etc/syserr.x + In syserrs, added a check for overflow on the error message string. + These messages do not necessarily come from , and can be + quite long. (1/27) + +sys/ki/kiconnect.x + Added a call to ki_gethosts() if the node table has not yet been + read. There are circumstances (although unusual) in which ki_connect + can be called before the node table has been read, causing the system + to try to open the resource on the local node. (1/27) + +(All these bugs I am fixing have been in the system for some time, they +(are not new with this release...) + +vms/os/zmain.c +vms/os/zfiopr.c + Added support for monitoring IPC messages a run time, a useful tool + for debugging connected subprocesses. To enable logging of IPC + communications for a process, the programmer runs the VMS PATCH + facility to set the value of the global variable debug_ipc to 1. + The process must first be linked -x (or -M) to get the address of + the variable debug_ipc. + + cl> mkdebug + cl> adb x_test + DBG> ev debug_ipc + 1D58 + DBG> exit + cl> !patch x_pkg + PATCH> deposit 1d58=1 + PATCH> update + PATCH> exit + + This is similar to the way one does this on UNIX. (1/29) + +sys/fmtio/lexnum.x + Changed stk_ip[] from short to int. (1/29) + +pkg/cl/builtin.c + Changed two instances of + + flags != LT_PFILE; + to + flags &= ~LT_PFILE; (1/29) + +sys/clio/zfiocl.x + There was some confusion between bytes and chars here, causing the + numstr[..] = EOS to overwrite the static "xfer" string, resulting in + the command "x(3,2044)" being sent to the CL. This would cause + tasks which read from the standard input to fail. (1/29) + +pkg/system/help/t_help.x + Added , to the stridxs search for pattern metacharacters, so that + commands like "help taska,taskb" do not stop after printing only the + first task. (1/29) + +pkg/images/tv/display/imdopen.x +pkg/images/tv/cv/iism70/imdopen.x + Added an include . (1/29) + +vms/os/net/zfioks.c + Modified to not return a channel value of zero, which makes the KI + think the server has not been connected, even though it has. (1/29) + +Proposed Changes based on recent Installation Experiences +---------------------- +The following observations followed a trip to the Univ. of Wash. to install +IRAF and interface the display software to the model 75 IIS. This served +as a test case to refine our installation procedures before the release. + + - The quota requirements need to be better defined. In this case + the paging file quota was too small, and we had problems spawing + connected subprocesses. + - Make the [iraf.local] directory a standard thing, to hold all + local and VMS junk, e.g., login.com, test login.cl and uparm, + notes file, sysbull.dat, etc. etc. + - Replace IMAGEDISK by a definition of the default image storage + directory, which need not be a disk device. + - The symbol IRAF (used to load the logical names) collides with + the iraf system login IRAF. Mail cannot be sent to IRAF, it + has to be sent to _IRAF, which is confusing to the user. + Solution: use "IRAF" for the system login, [IRAF] for the + root directory, and IRAFDEFS for the symbol which used to be + called IRAF. + - Add a new subdirectory off the root called BIN, and install all + the executables there. Modify the CL to read the parameter + files from the source directories for the package, rather than + constraining the .par files to be in the same directory as the + executable. + - Add a utility to strip the system of all sources, objects, and + libraries not needed at runtime or for simple user software + development applications. All machines do not need to have + a full copy of the system with all sources. + - We need to include NSPP/MCVAX in the distribution, so that people + can get hardcopy on a Versatec or Printronix. + +(end of observations) +----------------------- + +vms/gdev/zfiogd.x + Broke iism70, iism75 into two separate cases, calling two separate + sets of interface procedures for each device. (2/5) + +vms/gdev/iism75/* + Added a new subdirectory IISM75 containing the interface procedures + for the Model 75 IIS. This device was interfaced without any changes + at all to the existing high level code, which was written for the + Model 70. Instead, the IISM75 procedures perform transformations on + the data stream to and from the physical device. M70 output + instructions are converted to M75 format, and M75 responses are + converted to M70 format. In effect, we have added software to convert + the model 75 back into a 70. This makes it possible for us to modify + the complex high level software and test in on the model 70, with a + reasonable expectation that it will still work on the 75 as well. (2/5) + +vms/gdev/iism70/m70io.f + The .for QIO interface procedures in gdev/iism70 are used for both + the model 70 and 75 (probably they should be moved into a separate + directory). The M70IO procedure would fail with the max transfer + size set to 32768 bytes. This was traced to the following expression + in a QIO call: + + %val(2*count) + + Here, `count' is a short integer variable. The result of the + expression is a long integer. The Fortran compiler would do the + multiplication with short integer arithmetic and then convert the + result to long integer, causing the unsigned integer result to overflow + into the sign bit, causing sign extension and an invalid QIO request + resulting in a cryptic insufficient working set message from VMS. + + The solution was to store count into a long integer temporary before + evaluating the expression. Applying the INT intrinsic function to + COUNT had no effect. Note also that one might assume that 2 is of + type "integer" and that the multiplication would be evaluated using + integer arithmetic, but that is not how this compiler does it. + + After this modification, the interface still failed, no doubt due + to the same problem elsewhere in the interface; I did not persue the + matter any further. I am documenting this carefully here because it + illustrates the danger of short integer arithmetic with the VMS + Fortran compiler, and anyone using such arithmetic must understand + in detail how such expressions are evaluated. Short integer arithmetic + was used in this particular application only because I cribbed the + QIO level interface routines from somewhere else, and they were + written to be compiled /I2. (2/5) + +pkg/images/tv/display/iisrcr.x + Added a 30 millisecond delay, so that cursor loop applications (e.g., + to window the display) do not hog the cpu polling the system in an + infinite loop. (2/5) + +dev/graphcap + Added an entry for the CIT-414a graphics terminal. (2/5) + +sys/tty/mkpkg +sys/tty/ttyclear.x +sys/tty/ttyclln.x +sys/tty/ttyctrl.x +sys/tty/ttydelay.x +sys/tty/ttygoto.x +sys/tty/ttyputs.x +sys/tty/ttywrite.x + In the process of developing a graphcap for the CIT-414a, I found + a problem with the TTY interface. The interface was set up to + operate upon EOS delimited control strings. This would prevent + inclusion of NULs in the control string (used to generate delays), + since the NUL would be interpreted as the EOS. A new routine TTYWRITE + was added, and TTYPUTS was modified to call STRLEN and then TTYWRITE. + The remaining routines were modified to call TTYWRITE rather than + TTYPUTS. I considered adding a notation to be used in control strings + to represent delays, but did not do so since the resultant TERMCAP + entries would no longer be compatible with UNIX TERMCAP. Instead, + one must explicitly include the nulls as \0\0\0 in the control strings. + (2/5) + +sys/gio/stdgraph/stdgraph.h +sys/gio/stdgraph/stgencode.x + Added a new operator !! to the stdgraph encoder, used to generate + millisecond delays by inserting NUL characters into the output text. + The delay in milliseconds is popped from the stack. For example, + (#20!!) is a 20 millisecond delay. (2/5) + +sys/gio/stdgraph/t_showcap.x + Modified to use the count returned by the encoder to find the end + of the output string, rather than assuming that the control string + is EOS delimited. This is necessary because the string may contain + embedded NUL characters. SHOWCAP will represent these as \0 in + diagnostic output. (2/5) + +dev/graphcap + Made a pass through this and made minor revisions to bring the comments + up to date. Deleted all the "old graphcap" stuff at the end of the + file, as the code which used it has all been deleted. (2/6) + +vms/boot/mkpkg/host.c + Modified h_outcheck() ($checkout) to always check out the latest + version of a file, even if a local file already exists with the + same name as the file to be checked out (the old version is deleted + and a new version is checked out). (2/6) + +vms/boot/mkpkg/tok.c + Added verbose messages to do_copyfile() and do_movefile(). (2/6) + +vms/os/zgtenv.c +vms/hlib/libc/iraf.h +sys$library:iraf.h + After having what appeared to be problems with the passing of logical + names to subprocesses spawned by batch queue jobs, I added the logical + name table lookup code from UNIX/IRAF to the VMS version of ZGTENV. + This code will fetch the values of the three essential logical names + IRAF, HOST, or TMP from the file at runtime, if not found in + the VMS environment. These logical names are currently defined as VMS + logical names in hlib$irafuser.com as well, but these values can be + deleted should it prove desirable, and the system will automatically + pick up the default values from . This is the way this works + on UNIX/IRAF too. (2/6) + +vms/boot/boot/* [UNRESOLVED] + This is a problem with the bootstrap utilities. At present, these + work great when run interactively from either DCL or the CL. + Even background execution works, provided the subprocess type of + bkg job is used. When run in a batch queue, however, my test case + (MKPKG) apparently completes successfully (an executable is linked), + but the spool file contains a DCL dump claiming that the MKPKG died + during startup because it could not find a file (it looks like the + hlib$zzsetenv.def file, but the RMS error message does not give the + file name). No other output is produced. I looked for a while but + could not figure out where the real output is going, or why this + apparently ficticious error output is being generated. Since the + MKPKG job apparently completes normally, it must be something during + job termination, but I don't have time to look into this further + now. (2/6) + +vms/os/net/zfioks.c +vms/os/net/inet.h + Reduced the max transfer size to 32256. A transfer size of 32768 or + larger causes the Wollongong network driver to crash VMS (this was + reported before, but the value checked for was still too large). (2/9) + +pkg/images/tv/display/iisopn.x + Added a strupk to unpack devinfo before calling ki_gnode. (2/9) + +pkg/images/tv/display/zsttim.x + Added code to multiply the max buffer size by 2 if "packit" is set, + allowing twice as many pixels to be stored in the same space. (2/9) + +vms/os/zgtenv.c + We don't want to use VMS logical names like "IRAF" and "TMP" because + problems are likely due to name collisions. On the other hand, we + don't want to change the IRAF names. The solution adopted was to + have ZGTENV, when asked to lookup NAME, look for IRAFNAME first. + This allows all logical names to be defined in irafuser.com with the + IRAF prefix. + + The exact sequence of events followed by ZGTENV when a request for NAME + is received is the following: + + [1] Look in VMS land for IRAFNAME. + [2] If NAME is one of "IRAF", "HOST", or "TMP", the three host level + logical names required by the IRAF VOS, and the VMS lookup for + "IRAFIRAF", "IRAFHOST", or "IRAFTMP" failed, fetch the default + value from . + [3] Lastly, simply look in the VMS tables for NAME. + +vms/hlib/irafuser.com +vms/hlib/mkiraf.com + Now defines the following machine dependent logical names: + + IRAFDISK locates IRAF root at IRAFDISK:[IRAF] + IRAFTMP default TMP directory (public) + + fast,batch,slow aliases for batch queues + (SYS$NODE) not needed for 4.X VMS. + + The remaining definitions in irafuser.com are site independent. + The old logical IMDIRDISK has been replaced by IRAFTMP. The latter + is needed in any case to define the IRAF "tmp$", and it was desirable + for the default image storage location to be a directory rather than a + disk. MKIRAF was modified to create the default user IMDIR as a + subdirectory of the directory IRAFTMP. The temporary logical names + IRAF, HOST, and TMP were replaced by IRAFIRAF, IRAFHOST, and IRAFTMP. + The logical names EDT and VI were replaced by IRAFEDT and IRAFVI, + under the assumption that code will be added to EDCAP to define what + name to pass to the host to run the editor. It was annoying to have + an important symbol like VI used by IRAF, and always calling the + editor via the very slow @irafvi.com script. (2/11) + + TODO: add "host command" string to EDCAP, modify CL to use it. + +VMS Environment + This is a summary of the VMS environment configuration recommended + for IRAF. + + IRAF Symbol, loads irafuser.com + IRAFDISK Logical name, disk iraf sources are on + IRAFTMP Default public scratch directory + + IRAFDISK:[IRAF] Root directory of iraf on IRAFDISK + IRAFDISK:[IRAF.LOCAL] Login directory for vms user "IRAF". + + If no IMDIR is defined, the CL uses IRAFTMP. The default IMDIR + created by MKIRAF is the subdirectory .USER] of IRAFTMP. The system + should be installed under the login name IRAF. IRAF related VMS + mail should be sent to user IRAF (no need to use _iraf). (2/11) + +pkg/cl/builtin.c +pkg/cl/edcap.c +pkg/cl/globals.c +pkg/cl/eparam.h + Added a new field EDITOR_CMD to the EDCAP database. The "escape" + field contains the command to be sent to the host system to run the + editor. The function HOST_EDITOR() accesses edcap and returns the + command string for the named editor. (2/11) + +dev/edt.ed +dev/emacs.ed +dev/vi.ed + Added an EDITOR_CMD entry to each table file. (2/11) + +vms/hlib/clpackage.cl +vms/hlib/zzsetenv.def + Since the CL is an IRAF task run from the host, it reads the default + zzsetenv.def file during startup. Since this file already defines + all the logical directories, I moved the remaining non CL specific + SET definitions from clpackage.cl to zzsetenv.def. The clpackage.cl + file is now machine and site independent, and is one less file to + have to worry about during an installation. Since the system package + is loaded during startup now, I also replaced the fscan stuff, used + to type the message of the day, by a call to PAGE. (2/12) + +sys/ki/kishownet.x +pkg/system/netstatus.x +pkg/system/system.cl,x_system.x + Added function ki_shownet (outfd), used to print the network status. + Added a task NETSTATUS to the system package which simply calls the new + function and prints the network status as seen by x_system.e. (2/12) + +dev/hosts +dev/uhosts + Updated these tables. (2/12) + +vms/os/zopdpr.c + This interface routine was modified to give the user more control over + the priority of "interactive" background jobs (bkg jobs run as + subprocesses, rather than in a batch queue). The syntax is as follows: + + & [+|-]N + + where +(-) causes the bkg job to run at a higher(lower) priority than + the parent, and N is a decimal number. If neither + or - appears N is + the absolute priority of the process. + + For example, + + &15 run job at priority level 15 + &-1 run job at a priority one level down + + The default if nothing is specified is to run the job at a priority + level one less that that of the parent. (2/12) + +vms/os/zgtenv.c + This procedure was returning ERR if it could not find the name or the + output string overflowed. Changed to return 0, as is the standard for + operators that return string values. (2/12) + +iraf$mkpkg + Added an "update" entry point to the root mkpkg, so that I don't + have to run update twice in sys and pkg when relinking the system. + (2/12) + +dev/edt.ed +dev/emacs.ed + Added the NEXT_PAGE and PREV_PAGE operators as indicated in the ST + notesfile, received last month in the mail (the VI edcap file was + updated some time ago). There was a conflict for EDT; there was a + duplicate entry for MOVE_START which used the same code as one of + the new commands (keypad-7). I solved the problem by deleting the + duplicate entry. (2/12) + +pkg/cl/builtin.c + Everywhere there was a reference to the _pname (physical task name) + for an executable file, added a call to findexe() to get the name + of the executable which is actually used. If this is not done, + things like testing to see if a process is in the cache (prc, flpr) + fail. (2/12) + +sys/sys.hd +host/os/doc/os.hd + Changed sys$ references to host$ references to reflect the relocation + of OS to the HOST directories. (2/12) + +pkg/images/tv/cv/ids/idsfont.x +pkg/images/tv/cv/iism70/idsoptn.x - + There was a name collision with the routines IDS_OPEN and IDS_OPTN. + The latter was a no-op in any case, so I deleted it and commented + out the only reference to it in IDS_FONT. (2/13) + +sys/gio/cursor/grcwaitp.x + Modified to display the "wait" message again after the user responds + to the previous "wait" with a space bar, causing the system help + to be printed. (2/13) + +dev/termcap +dev/graphcap + Added a few new entries to each file, contributed from our early + test sites. Updated the cached entries. (2/13) + +pkg/language/* + Extensively revised, edited, corrected, extended, brought up to + date, added new examples, etc. the manual pages for the CL. + Most of the changes were minor, but some important new material + was added. Manual pages were added for those tasks added since + the docs were originally written. A manual page CURSORS was + added for cursor mode. The BEGIN and END manual pages were + deleted since these keywords are merely components of the PROCEDURE + declaration, not entities in themselves. (2/12-13) + +softools/*.hlp + Added manual pages for all the softools utilities, including all + bootstrap utilities (generic, mkpkg, rtar, wtar, rmbin, mkhelpdb, + hdbexamine, mkmanpage, etc.). (2/13) + +pkg/cl/builtin.c + Deleted a couple of task placeholder entries for the language package + and added a couple others, so that "? lan" will prompt with a certain + set of tasks or functions. The keywords and common intrinsic fcns + are excluded. (2/15) + +dev/termcap + Added a new device entry VMSPRINT, used to queue print jobs to the + standard VMS print queue SYS$PRINT. (2/15) + +sys/imio/imfort/ + +vms/os/zgcmdl.c + + Added a new interface IMFORT, the Fortran programmer's interface to + IRAF images. This is implemented as the library lib$libfort.a. + Linking requires also libsys.a, libvops.a, and libos.a. Documentation + is in the README file, and a manual is on the way. The interface is + minimal at present. + + A new routine, ZGCMDL, was added to the kernel to support IMFORT + (I also have plans for it for the LIBC interface, to be able to + emulate main(argc,argv)). This in available in IMFORT as the + Fortran callable procedure GCMDLN. The idea is that the user + interfaces their Fortran (or C) program to the CL as a foreign task, + then calls it with arguments like any other task. The Fortran program + gets the command line and parses it in memory to get the arguments. + (1/17) + +vms/os/zfiopr.c + We have been having problems connecting subprocesses, so I added a + call to _zerror if the create and/or map global section fails when + setting up IPC, so that hopefully we can determine why. (2/18) + +sys/etc/propcpr.x + A very minor change, while looking over this code. Added an errchk + for the syserr SYS_PROVFL, to prevent a memory overrun in the event + that there are no more process slots. (2/18) + +vms/hlib/gripes.cl + Modified the gripes script to send the entire text of the gripe to + IRAF (as in UNIX/IRAF), rather than just a line stating that a gripe + has been posted. On our system, mail to IRAF on any node is + forwarded to a central node, with the mail file for IRAF on that + node serving as the central gripes database. A copy of the gripe + is still appended to the gripesfile on the local node. The temporary + file was moved from TMP to UPARM and the extension ".txt" was added + to keep VMS mail happy. The second temporary file for the mail + message is no longer created, since the osfn() function now allows + us to pass the host name of the first tempfile to the host mail + program. (2/19) + +vms/os/zfiopr.c + Installed a new version of this driver from ST, which should fix + the IPC connect failure problem we have been experiencing lately. + ST went though the same thing several weeks ago. The problem was + traced to a SECTBLFUL (section table full) problem in VMS. This is + fixable by rebuilding VMS with a larger table (param GBLPAGFIL), + but the new driver will hopefully avoid the problem altogether, + avoiding the need for sites istalling IRAF to change a system + parameter. The recent debug_ipc mods were merged into the new + driver. (2/19) + +exception handling [UNRESOLVED] + After relinking the system with the new IPC driver from ST, we had + problems when interrupting subprocesses. Relinking with the old + IPC driver helped, but while testing I continued to have problems + with exception handling. Nothing I have done in recent history + should have anything to do with these problems, so I ran the same + tests on an executable in the old system (untouched for some months). + Exactly the same thing happened there, so evidently the problem has + been with us for some time. + + The test is this: I run the x_system.e process standalone, entering + the command "count files=*.x", and then interrupt the + task while it is running. Five times out of six, or thereabouts, + it will work, going through error recovery successfully. When it + fails VMS prints the message "improperly handled condition" along + with a dump of the stack and registers, and does a panic shutdown of + the process. This is preceeded by an access violation message. + +-------------------------------------------------------------------------- +VMS/IRAF V2.2 frozen on 21 Feb. + + +vms/hlib/mkpkg.e + Relinked; old executable was using an obsolete version of zgetenv + that had a bug. (3/4) + +pkg/cl/config.h + Doubled the size of the stack and increased the dictionary from 20K + to 30K. (3/6) + +dev/termcap + Added an entry for device "imagend", the new imagen on node draco, + plus an alias "imagena" for the original imagen on node aquila. (3/13) + +sys/ki/kireceive.x + Will now echo "out of band" error messages to STDERR, prefixed by + the node name, before returning ERR on the kernel server channel. + (3/14) + +sys/osb/miiupk16.x +sys/osb/miiupk32.x + These procedures were modifying their input arguments. (3/14) + +mkpkg, zgtenv.c [OBSERVATION] + We are running with two different versions of the system, IRAF and + IRAFX. When I linked a process with mkpkg from the IRAFX CL I found + that the old IRAF libraries were being used. The pathnames in the + global , read by ZGTENV when it cannot find IRAF etc. in + the VMS tables, were still set for the old system. After editing + and repeating the mkpkg, the IRAFX libraries were accessed. + This proves that indeed the logical names are NOT always getting passed + down through all the process spawns, and the new ZGTENV facility is + doing its job. (3/14) diff --git a/doc/ports/vms_oct85.st b/doc/ports/vms_oct85.st new file mode 100644 index 00000000..d4e23104 --- /dev/null +++ b/doc/ports/vms_oct85.st @@ -0,0 +1,786 @@ +Space Telescope Science Institute IRAF Notes (File: iraf$vms/notes) + + +-------------------------------- +Wednesday 23-OCT-1985 14:20:08.71 + +Subject: I/O redirection support for IRAF/VMS + +Added the ability to do I/O redirection on the command line (Unix-style). + + interactive $ cl + i/o to files $ cl outfile (or >>outfile) + +This allows people to run the CL in a VMS batch job or as a "background" +subprocess, specifying the CL commands in a text file. + + +sys$os/zmain.c + Added code to support I/O redirection (parsing, file setup, etc.) + +sys$os/zfiotx.c, zfiofi.c + Fixed ZSEKTX to work correctly (had troubles with redirected i/o for + some reason). + + Changed append mode access so it has RMS Update access (for seeking). + +pkg$cl/exec.c + Added a global variable 'logout_on_eof' (default=0), which is set + by the VMS ZMAIN when I/O is redirected to files. If the user forgets + to put the 'logout' command in the infile, then EOF will get him out. + Otherwise, it's very easy to fill up a disk with "ERROR: use 'logout'.." + messages in a file, something we definitely want to avoid. + + This is only a TEMPORARY fix. The same thing happens under Unix, so + maybe their should be some way of handling this in a general, + system-independent way. Will users use the CL with input from a file + instead of the terminal? They are here (for now) and the capability + should probably be supported, since it is automatically supported + under Unix. + + This fix does not affect normal operation of the CL in interactive mode; + the user still has to say 'logout' to get out of the CL. + + Note: If a user has a parameter which has a range specified, and the + value is out-of-range, while running the CL in this "OS-background" + mode, it will probably just loop until death saying "parameter out of + range", and fill up a disk with these error messages. This is also + a problem, but not sure how (or if) to fix it; the user should make + sure that the parameters are indeed correct when running the CL this + way to avoid this problem (?). + +-------------------------------- +Friday 25-OCT-1985 17:16:02.53 + +Subject: pkg$cl/eparam.c + +Hacked EPARAM to fix a number of problems with multi-line prompts, arrays, +and other things. There are still a few known "features", but they are so +obscure and such special cases that I'm not going to worry about them now +(there are easy ways to "reset" eparam to fix these offset problems). + +Also, changes so that value field is not overwritten by prompt string. + +-------------------------------- +Wednesday 30-OCT-1985 09:40:22.45 + +Subject: Parameter cacheing (pkg$cl/exec.c) + +Parameter cacheing mechanism (pkg$cl/exec.c mk_startupmsg, sys$etc/main.x, +clio$clcache.x, etc.) does not handle array parameters. Eventually, it should, +but this will mean some non-trivial changes in all of these places. There +are a few places in SDAS that do indeed have array parameters, so the course +of action for now is to not pass them in the startup message (as is done with +list-structured parameters). This fix is a simple "if" statement in exec.c/ +mk_startupmsg(). + +-------------------------------- +Monday 4-NOV-1985 12:33:48.79 + +Subject: pkg$cl/grammar.y (ytab.c) decl.c + +Bug fixes for 'real' declarations with negative values for min and max. + +-------------------------------- +Monday 4-NOV-1985 14:34:10.38 + +Subject: pkg$cl/lex.sed lex.com (for lexyy.c) + +Added editor functions to change (YYLMAX 200) --> (YYLMAX 2048), so lexical +analyzer can handle long prompts given in procedure scripts. + +-------------------------------- +Monday 4-NOV-1985 15:35:36.85 + +Subject: pkg$cl/linkcl.com [VMS] + +Changed to generate the CLDATE file in MACRO rather than C (i.e. cldate.mar). +This is so IRAF/VMS sites don't need a C compiler to relink IRAF (one site had +this problem already). + +-------------------------------- +Tuesday 5-NOV-1985 16:22:14.70 + +Subject: pkg$cl/task.c + +Additional check added before strncmp() call in ltasksrch() to check first +character first. Some profiling on Unix showed this to cut down the calls to +strncmp() significantly. + +-------------------------------- +Wednesday 20-NOV-1985 08:59:41.61 + +Subject: sys$os/ [VMS Kernel] + +The VMS Kernel routines have been overhauled. The large number of changes +consisted of: deleting obsolete code, consolidating common code segments, +some name changing, improving readability and consistency, and some tweaks +for efficiency. Most of the changes were indeed cosmetic, in an effort to +bring the code into conformance with the IRAF coding standards (though perhaps +not 100% there). To list all the changes would be impossible, so here are +some of the major ones... + +A number of files have been renamed, as well as support routine names, to be +more descriptive (and to remove the "z" on many of the support routine names). + +File name changes: + zconvtim.c --> convtime.c + zexit.c --> exit.c + zget*.c --> get*.c + zprocname.c --> procname.c + ztrnlg.c --> tranlog.c + zfiofi.c --> rms.c + ast.c deleted (no longer needed) + +Function name changes: + _zopnfi, _zclsfi --> _rms_open, _rms_close + _ztrnlg, _zcrelg --> _tranlog, _createlog + _zrequestio --> _zqio + _zsttfi deleted + others... + +New files: + dirname.c + queue.c + eprintf.c (from Kitt Peak, VMS net stuff) + +The file status functions (formerly in _zsttfi) have all been moved into each +of the ZFIO* drivers, with appropriate buffer size values in the include file +"vms.h". Some of these values have been modified, where appropriate, or as a +result of recommendations from Kitt Peak. + +No effort was made to completely redesign anything, though some files and +routines were restructured quite a bit. The effect on executable sizes of +these changes is negligible. + +-------------------------------- +Friday 22-NOV-1985 10:43:50.93 + +Subject: pkg$softools/boot/... + +All of the VMS source code for the boot utilities (MKLIB, XC, support ...) +have been overhauled to look like the rest of IRAF (at least partially), just +as the VMS Z routines. Besides a few name changes because of Z-routine +name changes, there was only 1 functional modification: + + pkg$softools/boot/spp/xc.c [VMS] + /dcl.c + + Changed to use the function DCL instead of ZOSCMD. DCL does + everything ZOSCMD does without all the weird features to + support interactive commands. The output is much more + consistent here as well, no longer generating ".;" and ".LOG;" + files all over the place when running XC and MKLIB in batch + or background. (DCL is essentially an earlier, stripped-down + version of what eventually became ZOSCMD). + +-------------------------------- +Monday 25-NOV-1985 15:41:56.73 + +Subject: Support for VMS batch jobs + +The VMS kernel has been modified to support VMS batch jobs as well as +parallel subprocesses for IRAF background jobs. Changes in the higher level +IRAF code is necessary to selectively use these two options. Since the +calling sequence for ZOPDPR has been changed, the new one is currently +commented out until these higher level changes are finished (at Kitt Peak). + +[received CL and system lib changes, 9-DEC] + +The changes include: + + ZOPDPR -- extra parameter 'batch_queue', null or "" for subprocesses, + a batch queue name for a VMS batch job. A few new routines + in this module were added and everything was reorganized a + bit. + + ZMAIN -- some extra checks were added to deal with the batch case. + + ZFIOTX -- In ZSEKTX, added a check for STDIN/STDOUT when a VMS batch + job. This is necessary to avoid seek errors on NLA0: and + the batch log file. (VMS really makes it hard to deal with + I/O in a consistent manner.) + + queue.c - Contains VMS batch and print queue support functions. Used + by ZOPDPR and ZFIOLP. + +-------------------------------- +Monday 2-DEC-1985 09:40:50.23 + +Subject: pkg$cl/builtin.c + +Changed SZ_FNAME to SZ_PATHNAME in cledit() to handle longer VMS filenames +resulting from filename mapping. + +-------------------------------- +Monday 9-DEC-1985 08:27:39.00 + +Subject: pkg$cl/prcache.c + +Interrupts were not being enabled if connected subprocess create failed. +Added call to intr_enable() in before returning NULL. + +-------------------------------- +Tuesday 10-DEC-1985 12:39:20.67 + +Subject: New version of IRAF/VMS from Kitt Peak. Merge notes: + +sys/os/* + Remerged the VMS kernel. No major problems, even though we both had + made a number of changes. Will test it all out soon. + +sys/os/net/decnet.c + + zfioks.c + Makelib + eprintf.c --> ../ + + Added support for DECnet, though this is not fully tested yet. This + is a compile time option (DECnet or TCP) in ZFIOKS and will not affect + the TCP implementation. The eprintf.c file was moved to the sys/os/ + directory, since some debugging code there uses it now as well. + +sys/gio/gks/gtx.f + Did NOT use KPNO version of file since it was calling f77upk with + the wrong number of arguments. There is no min-length arg to f77upk + in either version of IRAF. + +sys/osb/f77pak.f + Changed DO loop to pop out when done, rather than going around until + it reaches 9999. + +sys/gio/ncarutil/sysint/uliber.f + Following change need to compile on VMS. + integer*2(80) sppmsg --> integer*2 sppmsg(80) + +pkg/images/imarith/imadiv.x + imamax.x + imamin.x + (>>> imarith.x) + POINTER --> PIXEL + +pkg/imred/generic/Makelib, x_generic.x, generic.cl + Removed references to 'cmdstr' in these files. Assumed 'cmdstr' was + moved to the system pkg, since no cmdstr.* files on the tape. (?) + +sys/fio/vfnmap.x + Reference to ztslee changed to zwmsec. + +pkg/system/x_systest.x + Removed reference to mtdevlist. + +pkg/images/tv/display/t_mkdisplay.x + Moved call to open_display_header to AFTER getting name of stdimage + and frame number. Was before it, resulting in dev$_0.imh, instead + of dev$deanza_1.imh. + +pkg/language/doc/*.hlp + Some of these files were updated recently to correct errors, typos, + misspellings, etc. Forgot to note these changes before. + +Testing re-merged system + Tested out a number of the usual things: CL, test scripts, SYSTEM and + LISTS pkgs, some graphics and image tasks, etc. Everything seems to + be working okay. There are still a number of known bugs, especially + in eparam and procedure scripts (history gets a 'begin' in the history + for procedure scripts). I'll be looking into these again soon. + +VMS Batch Jobs + Tested out the CL with both types of background jobs, subprocesses and + batch. Both work fine. A logfile for the batch job case is kept + in the user's sys/login directory with a name like "12345678_D_1.LOG", + (i.e., like detached subprocess names). This logfile is largely + login garbage, but if the user does not redirect output, it will go + here as well. When things settle down and everything is working okay, + we may want to have the logfile deleted, or add an option for keeping + it or not. + + Logical names for batch queues work as expected. For example, the + following can be done: + + $ define b sys$batch + $ define f localfastbatch + $ define s localslowbatch + ... + + cl> task >&task.out &f # IRAF bkg job to 'localfastbatch' + + This means that zopdpr.c can remain system-independent, with system + dependent batch queues set up in logical names or spelled out fully + when in the CL. + +Magtapes + Tested the tape stuff with all the new changes from Kitt Peak merged + in. Used mtexamine and rfits and was able to read in about 20 small + FITS images and run some tasks from the images and plot pkgs on them + with no problems. + + +======> Sent tape of changes above to KPNO (16-Dec-1985) <===== + + +-------------------------------- +Tuesday 17-DEC-1985 16:07:42.04 + +Subject: sys/os/zpanic.c + +Bugs in formatting the error message fixed. + +-------------------------------- +Tuesday 17-DEC-1985 16:29:52.99 + +Subject: sys/os/zmain.c + +Changed code in _get_prtype() to figure out whether we're a batch job +by examining the PCB status bits, instead of the process name. If the user +sets his process name in the login.com file, then the background CL starts +up thinking it's a regular host process. + + +===> Sent above fixes to KPNO 17-Dec <=== + + +-------------------------------- +Wednesday 18-DEC-1985 12:36:34.43 + +Subject: dev/*.ed + +Added NEXT_PAGE and PREV_PAGE sequences to edcap files for EDT, EMACS and VI. + +edt -- + NEXT_PAGE \033Ow keypad-7 + PREV_PAGE \033OP\033Ow gold-7 + + (In edt, prev_page is really keypad-5,keypad-7, but this would + set direction backwards; gold-7 in edt is "command", which is not + used in eparam anyway.) + +emacs -- + NEXT_PAGE ^V ^V + PREV_PAGE \eV ESC-V + PREV_PAGE \ev ESC-v + +vi -- + NEXT_PAGE ^F ^F + (Nothing added for PREV_PAGE; not sure what to use, since ^B and ^U + are already being used.) + +-------------------------------- +Wednesday 18-DEC-1985 16:43:41.78 + +Subject: pkg/cl/builtin.c + +Fixed a bug in clflprcache() so that everything is not flushed if the named +task is not found in the process cache. Previously, if a user said + + cl> flprcache notask + Warning: 'notask' not in cache + +Then everything would go anyway, including locked tasks. The fix is simply +to do a 'continue' in the while loop when we print out this warning message. + +-------------------------------- +Wednesday 18-DEC-1985 18:44:37.98 + +Subject: sys/fmtio/lexdata.xi + +Changed action table for +/- in state QRX from Rvt to QRX. This is to fix +a bug when getting numbers like 1.0e-10 which returned nchars=3 instead of +nchars=7. This code is (eventually) used to check the type of command line +arguments in the CL when lexmodes=yes, which is where the problem was first +noticed. + +The code in lexnum.x along with the action table are somewhat difficult to +follow and there may be other implications here which are not apparent, but +based on other entries in the table, this looked like it was indeed a bug. +Ran the debug code in sys/debug/nop.x (lex task) and things worked correctly +in all cases tested. + +-------------------------------- +Friday 20-DEC-1985 11:42:48.72 + +Subject: VMS batch jobs and DCL commands + +When running a DCL command as an IRAF/VMS batch job (e.g. a foreign task), if +the output just goes into the logfile, it ends up being written into files with +names like .;1 and .;2, etc. This goes back to all the old crazies with the +funny ZOSCMD to defeat slow spawning and still provide interactive +capabilities. The user should redirect output in this case somewhere else and +not let it go to the VMS logfile. Tried a few changes in zoscmd.c and open.c +to no avail, so I'm just going to let this slide for now. + +-------------------------------- +Monday 23-DEC-1985 08:50:37.80 + +Subject: pkg/system/help/Help.hlp + +Formatting change to fix indentation: + + .ls + helpdb = "helpdb" +to + .ls helpdb = "helpdb" + +-------------------------------- +Monday 23-DEC-1985 10:35:15.82 + +Subject: Help task (discussion) + +Some SDAS users have voiced a "concern" over the help task. When saying "help +abc", everything that matches "abc" is given, even if something has already +matched it in the current package. This is confusing to novice users, even +though it is documented in the help that it will perform this way. A more +concrete example: + + cl> system + sy> help co + ... concatenate + ... copy + ... count + ... imred.coude + ... language.command + ... + +Would it be possible (and/or desireable) to stop the searching if help is found +somewhere in the current package for a named task or abbreviation? + +Another problem is getting help on something in a different package than what +was intended because of a common abbreviation (and no help file for the task in +the current package). The fix for this might be to limit the help search to +the current loaded packages, unless an explicit pkg-template.module-template +were given by the user. + +To go one step further, a suggestion by some SDAS people was to have an extra +parameter that controlled the search. For example, if matchall=yes, then help +would act as it does currently, otherwise, it would only search the current +package. + +-------------------------------- +Monday 23-DEC-1985 17:32:26.42 + +Subject: CL Changes Nov-Dec 1985 + (T.McGlynn, J.Travisano) + +grammar.y + - delete opnl's in procedure declarations to eliminate s/r conflicts. + - create LP and RP for parentheses to eliminate some expressions. + - repositioned initialization processing. + - modified var_decls slightly. + - if/else fixes, so don't need { if ... }. + - better syntax error reporting in scripts: gives (correct) line number, + points to offending position, and continues parsing script for errors. + +history.c gram.c + - changes to support above grammar changes + +history.c exec.c pfiles.c decl.c + - changes to deal with script line numbers correctly, i.e. + task->t_scriptln, which is used in syntax error messages; also, + a fix in the skip_to() function in decl.c. + +history.c + - problem of getting a "begin" in the history when running (or parsing) + a procedure script was fixed. The original command is now recorded + in the history (and logfile) correctly. Unfortunately, there is + one case where this does not work -- when get an error parsing the + parameter declarations in a procedure script. + +eparam.c + - format changes for real arrays (so exponent shows up) + - tried to fix MOVE_END problem when going across page boundaries; + can't seem to find the bug, so for now just print out a message that + says to use NEXT_PAGE a few times instead of MOVE_END. + +pfiles.c param.c gram.c + - added support for '\r' and '\f', so can be used in prompt strings + for better formatting control (\f not fully supported in EPAR yet) + +modes.c decl.c pfiles.c + - whitespace-only filename parameters are turned into null strings; + so users can check null filenames easily in a script (fn != "") + without having to deal with whitespace. Filenames with whitespace + only are not really legal anyway (?). + +modes.c + - bug fix to prevent trashing of enumerated parameters in certain + instances. + +param.h + - minor typo 'ai' --> 'ar' + +-------------------------------- +Friday 27-DEC-1985 14:47:48.01 + +Subject: CL history editor + +The following is another lexmodes=yes problem: + + pl> contour img1[*:16,*:16] + ... + pl> surface ^^ + surface img1[*:16 + Warning: ... + +The get-arguments code in pkg/cl/history.c checks for comma-delimited strings. +Putting the whole argument in quotes, i.e. "img1[*:16,*:16]", and then using +^^ works fine. (No fix/change was made.) + +-------------------------------- +Friday 3-JAN-1986 14:59:06.87 + +Subject: Local vars in CL procedure scripts + +It is generally assumed that local variables in CL procedure scripts, i.e. +those after the "begin" statement, will be initialized by the user with +simple assignment statements. There is one (possibly more) case where this +assumption can cause problems. For example, + + ... + begin + string buf + + if (fscan (plist, buf) != EOF) ... + ... + +Here, "buf" is used before being initialized, and the result is an error +saying "Attempt to use uninitialized local variable 'buf'". Perhaps local, +uninitialized variables should be initialized automatically by the CL, but +have done nothing to fix/change this yet; just making a note of it. + +-------------------------------- +Tuesday 7-JAN-1986 15:37:59.59 + +Subject: Miscellaneous + +These are various notes and suggestions by IRAF users at STScI and elsewhere. +I decided to finally add them all here since they were beginning to pile up +on various scraps of paper on my desk. Some of them are minor bugs, but most +are suggestions of some kind. Nothing has been done with any of them in terms +of IRAF changes. Most of the text is from mail messages or typed in verbatim +from paper copies. Any notes by me (JayT) are indicated in brackets []. + + +From ST users: + +CL + Would it be possible to put a feature into iraf whereby you say +'task=xxx', which would then set a default so that you could just +type lpar, or an input, without having to specify which task? +Ie, instead of having to type 'xxx.infile=etc', you could specify +the task and then just type 'infile=etc', with iraf filling in +the task name. This would not interfere with those who like the +system as it is, but could streamline things for those of us who +like the way AIPS does things. + +Integer parameters + We have encountered another peculiar feature of IRAF. Suppose you have a +parameter that is declared as integer in a .par file, and the user attempts +to put in a value for that integer that exceeds the range of INT*4. The cl +fills in that parameter with the value 'indef', a character string. When +SDAS goes to read the parameter, we get a crash because the parameter is not +in integer form. Now, it seems that a parameter declared as an integer ought +to be an integer no matter what, not a character string. Wouldn't it be better +to leave the parameter value unchanged from its current or default value rather +than put in this string? + + +From RAL users: + +CL Parser + li> ?? | words | match ':' stop+| sort | table + + does NOT work correctly, but separating the "+|" to "+ |" works okay. + +Help on parameter prompt + It is very complicated to provide additional help at the prompt for + parameter stage especially for non-string parameters. This facility + is almost essential to provide a user-friendly interface. + For example: + A string specified in the parameter file is output if ? is + typed in response to a prompt or possibly even enter the help + system. + + [NOTE: One can make the prompt quite verbose, up to something + like 2K characters; e.g., many SDAS prompts are long and multiline.] + +Range check and default display in sexagesimal + There needs to be an option in the parameter file to cause the range + check and default information to be output in sexagesimal. For example, + it is ugly to type in 12:34:56.7 and have it reappear as 12.582417. + +Date type + I think there ought to be special facilities for handling dates. At + present you can't enter a date all in one line (except using a + grotty fudge involving sexagesimal, which precludes proper range + checking), and if you enter the Y,M,D separately you can get things + like 1985 2 30 past the range checks. + + +From U. of Cal/San Diego (Doug Tudhope): + +lists.gcursor [and imcursor] + Get syntax error line 2. [known "feature" since CL2 grammar] + + [NOTE: doing an "lpar gcursor" activates the graphics cursor, + but then get an error of "EOF encountered in list parameter..."] + +plot.graph task + If only 2 points are given, only the axes are drawn, e.g. + + pl> graph STDIN + 10 10 + 20 20 + + axes, but no line! + pl> + +images.imtranspose + Made a transposed output file of a real 190*800 image -> 800*190 + but neither onedspec.splot nor images.implot would work on it. + they stopped with "reserved operand fault". + When imcopy run on transposed image, got "pixel storage file truncated". + +-------------------------------- +Tuesday 7-JAN-1986 15:51:02.98 + +Subject: pkg/softools/boot/spp/xc.c [VMS] + +Added EXTEND_SOURCE option for calling Fortran compiler from XC. This lets +source statements go up to column 132 (instead of 72). One line added to +source: + +fcompile() { + ... + sp = strcpy (outbuf, F77); ++ sp = strcpy (sp, "/EXTEND"); /* Allow statement in cols 1-132 */ + if (portable) + ... +} + +-------------------------------- +Tuesday 7-JAN-1986 16:11:20.85 + +Subject: pkg/images/tv/display/deanza/* + +Deanza now works with tv/display under VMS! All of the source files and Deanza +libraries are here. See the README file for more detailed information. + +Also changed "pkg/image/tv/display/mkpkg.com" to make the Deanza code instead +of the IIS-dependent code. + +-------------------------------- +Wednesday 8-JAN-1986 12:21:09.73 + +Subject: pkg/imred/.../*.e + +The ONEDSPEC executables are copied all over the place into IMRED. Comments in +the mkpkg.com files say this is to use different par files for different +directories. There's GOT to be a better way, as this eats up a lot of +diskspace (and tape as well at distribution time), which we always seem to be +running up against here. + +-------------------------------- +Friday 10-JAN-1986 15:29:37.13 + +Subject: More SDAS concerns/suggestions + +Environment variables + When a script task ends or a user bye's from a package, all "set" + declarations made in the task or since the package started are + "popped" during task restoration. Comments in pkg/cl/exec.c indicate + that this is for keeping the environment the same across processes. + + However, this can lead to confusion. If a user does a "set stdgraph=" + and later bye's out of a package, stdgraph reverts back to the + previous value, just as any other environment variable. The same + thing occurs in script tasks during the restore, making it difficult + to have global environment variables. Putting a "keep" in scripts at + various places can get around this to some degree, but it's sometimes + awkward. + +Process cache + SDAS has been set up under IRAF such that the user can choose which + version of SDAS he wants (baseline|standard|develop). This choice + can be made when starting the sdas package or any of its packages. + There is a problem, however, when running a package from 'standard' + and then running the 'develop' version when the executable is already + out there. When a task is invoked, it will simply use the subprocess + already in the cache, even though it's a different executable (with + the same IRAF logical name). + + The suggestion that came up was to do an implicit "flprcache" whenever + there is a "bye" to a package, i.e. when all the tasks associated with + the executable are gone. I've looked at this a little bit and don't + see an easy way of determining when we're bye'ing from a package which + has tasks that are in an executable. I imagine there's a decent amount + of overhead associated with checking all the tasks associated with + an executable as well. In general, getting rid of old executables + does make sense if they're not longer referenced, since it frees up + system and user resources (especially important on VMS given the + large process and executable sizes). + +Table parameters + SDAS and CDBS now have a new type of input file, a table, which may or + may not have a header as well. They have asked if it would be easy + to add a new parameter (or two) to IRAF, i.e. a table parameter and + possibly a table-with-header parameter. + + I don't think this is a good idea, as it is something which only + benefits SDAS and CDBS, and does very little if anything for IRAF. + I have encouraged the SDAS people to find an SDAS-only solution to + this problem using existing IRAF facilities. One simple way is to + have tasks which use tables to have a 'type' parameter which tells + if the input file is a table or something else. + +-------------------------------- +Tuesday 14-JAN-1986 08:48:36.11 + +Subject: doc/clintro* + +Copied the TeX source for the CL User's Intro doc from Peter's directory +to the general IRAF DOC directory. + +-------------------------------- +Tuesday 14-JAN-1986 10:49:06.01 + +Subject: Size of IRAF... + +A concern has risen, once again, on the size of IRAF. Garrett Jernigan +(Berkeley Space Sciences Lab) has mentioned problems finding diskspace to +handle all of IRAF. The suggestion he made to Peter was "to split the source, +obj and executables into separate libraries for the distribution, or at least +put them into different sub-directories. If either a tape could be generated +that only had executables, or that had the whole works, but allowed only the +required files for execution to be loaded it would be a real boon." I guess +this means having something analagous to the bin/, src/ scheme in Unix. + +I think a better solution to this is to add something to the installation docs +to describe how to load only parts of IRAF, i.e. everything, or no source, +etc., so the IRAF installer can load only the parts needed/desired. Both Tar +and Backup can handle selective copying in some manner. + +-------------------------------- +Tuesday 14-JAN-1986 11:37:46.40 + +Subject: CL strings + +It is currently impossible to get the length of a string in the CL. This +should be quite trivial to implement, but it is not. The documentation on +"paramaters" states that p_length contains the maximum length of the string, +though in reality, saying =param.p_length simply prints the string, just as +=param does. + +There should be some way of getting the current length of a string, since it +could be used as the 'last' parameter in stridx, for getting the rest of a +string starting at column n. ST users have continually asked me about ways to +get the current length of a string parameter (e.g., from within a CL script). + +One solution is to change the meaning of some of the parameter attributes for +string parameters to something which makes more sense: + + p_length -- contains the current string length, updated whenever + the parameter is changed. + p_max -- contains the maximum string length + +These would require changes primarily in param.c and gram.c. + +Also, currently trying an =param.p_min or p_max on a string parameter results +in an access violation. diff --git a/doc/ports/vmsbugs.doc b/doc/ports/vmsbugs.doc new file mode 100644 index 00000000..e67d62e1 --- /dev/null +++ b/doc/ports/vmsbugs.doc @@ -0,0 +1,328 @@ +From stsci Thu Jan 17 08:30:15 1985 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA10600; Thu, 17 Jan 85 08:30:03 mst +Date: Thu, 17 Jan 85 08:30:03 mst +From: stsci (Space Telescope ) +Message-Id: <8501171530.AA10600@lyra.noao.UUCP> +To: tody +Status: R + +Doug, + + Here is a list of bugs, changes, suggestions, etc. compiled during +the port of IRAF to VMS. + + Some of the bugs have the bug fixes listed here; others were too +elusive and/or time-consuming to try to figure out at this time. When you +get the latest, greatest VMS version of IRAF, what changes we made will +certainly be there; we'll probably send along RCS files as well so you could +easily update some of your files. However, most of the changes are +just a few lines here and there. + + We await any comments or any bug fixes you have there... + + Jay and Fred + +P.S. + We were discussing using mapped sections such as sdas +uses for static files. There is one major difference in the way that +iraf and sdas handle static (image) files. In the sdas routine +a pointer is passed back to where the image resides in memory. This +is due to the way the mapped sections work in VMS. In Iraf the zroutine +is given a pointer to where the data is to reside, so we have to do +a memory copy for each image reference, and may not be more efficient +than just writing to or reading from disk. Can you see any easy +way around this problem, or maybe an additional flag to zopnsf which +indicates that a pointer is to be passed back from zardsf or zawrsf +for the data rather than a passing in a pointer to where the data is to +be read to or written from? (fred) + + +---------------------------------------------------------------------------- + + + ------------------------ + NOTES file for IRAF (VMS) + ------------------------ + + +Contents: + 1. Bugs + + 2. Portability Considerations + + 3. Source file name changes + + +------------------------------------------------------------------------------- + + +1. Bugs + + /pkg/cl/bkg.c + In rbkgfile(), following fix: + ... fgets (set, fp) ... TO + ... fgets (set, SZ_LINE, fp) ... + + /sys/libc/qsort.c -- qcmp() --> (*qcmp)() + /sys/libc/cfilbuf.c -- filbuf() --> (*filbuf)() + + /sys/vops/advz.x -- '$t' missing for generic function + /sys/vops/advz*.x -- procedure advz[idx...] + + (extra files ?) + /sys/vops/ak/aif*.x -- aiftrrr.x + /sys/vops/ak/aff*.x -- afftrxx.x, afftxrr.x, afftxxx.x + /sys/vops/ak/acjgx.x -- acjgxx.x + + /sys/fio/fdebug.x -- "int and()" statement missing + /sys/fio/fputtx.x -- "int and()" statement missing + /sys/fio/fgetfd.x -- "int or()" statement missing + + /pkg/cl/pfiles.c -- pfcopyback() + 'pt' was going NULL before 'pf' in a for loop check; + was changed to check for 'pt' being NULL instead of 'pf' + + /pkg/cl/builtin.c, binop.c, bkg.c, history.c, lexicon.c, + debug.c, errs.c, exec.c, pfiles.c + + problem getting to next task by doing 'tp++'; due to VMS + alignment of structures. Fixed with a macro definition in + /pkg/cl/task.h for "next_task()", namely: + + #define next_task(tp) \ + ((struct task *)((unsigned)tp + (TASKSIZ * BPI))) + #define prevtask next_task(currentask) + + + /pkg/help/lroff/output.x -- references constant MAX_INT + "include " statement missing + + /pkg/lists/tokens.x -- last_nscan() --> last_nscan + + SPP/RPP compiler bug -- + + define and jiand (e.g. in ) + + if (x == FIVE && y == SIX) ... (SPP) + if (x == FIVE & y == SIX) ... (RPP) + if (x .eq. 5 .jiand. y .eq. 6) ... (FORTRAN) + + only occurs when a macro is replaced before the '&&', + in this case FIVE. + + /sys/fio/vfnmap.x + vfnunmap() -- when an OS extension was (un)mapped to a null + IRAF extension, the character count returned + was not right: + (e.g.) doc.dir --> doc but nchars = 7 + This caused problems later on in the directory + task of the system package. + The fix: + ... { + vfn[extn_offset-1] = EOS + op = extn_offset - 1 <-- was missing + } ... + + /sys/fio/vfntrans.x + filename mapping for directories sometimes doesn't work; + sys$ --> drb4:[irafx.sys]sys instead of + drb4:[irafx.sys] + made a quick fix in zopdir() and zfchdr() to deal with this + for now; can't seem to locate the exact problem in vfntrans.x + + /sys/fio/vfnmap.x + When deleting a file and the parameter subfiles=yes, and + no mapping file is currently in directory, a null mapping + file is (sometimes) created. Then doing a system.directory + fails when trying to read this null mapping file. + + E.g. cl> delete aaabbb.ccc + subfiles=yes (default .par file) + + delete() is called with 'aaabbb.ccc' and then + 'aaabbb.ccc.zsf', which is degenerate; + therefore, if a mapping file doesn't + exist, it is created. + + Haven't fixed this yet; not sure about the best way to go. + Some simple suggestions: + + -- Could somehow figure out whether the file is being + added or deleted (i.e. was vfnmap() called from + vfnadd() or vfndel()?). + + -- Or, whenever a mapping file is created, it has the + appropriate header info in it rather than being null? + + -- Or, some special case of reading null mapping files? + + + /sys/etc/environ.x + env_hash() + return (sum**2 / CONSTANT) + + causes integer overflow on VMS; changed to: (for now) + return ( int( float(sum) / CONSTANT * float(sum) ) ) + + arithmetic overflows: + /sys/etc/urand.x and others... + + These seem to occur in a few places, sometimes purposely. + An easy VMS fix is to use "FORTRAN/NOCHECK file", but it's + a pain to have to remember which files need this special + treatment. + + /sys/fio/ + Seems to be a bug in the file i/o related to writing + asynchronously to binary files. In VMS, this is REALLY + asynchronous, and it caused problems when trying to write + the help database; making VMS do it synchronously (like + UNIX) fixed the problem, for now anyway. + + It may be that a single buffer is being played with between + the write and the wait; at least that's what it looks like + in some of the binary files that were written -- there were + missing blocks and misaligned data, which were there when + displayed on the terminal. + + I don't think it's a problem with RMS, since double buffering + was used to test the binary file driver, with success. + + + /pkg/system/directory.x + - call strcat ("$", Memc[template]) --> + call strcat ("$", Memc[template], SZ_FNAME) + + - should sort and output the file name list ONLY + if (nfiles > 0) + otherwise, an "adjustable array error" occurs in qsort() + (i.e. an array with dimension of 0 is passed to qsort, + causing VMS to complain) + + +------------------------------------------------------------------------------- + + +2. Portability Considerations + + + (life would be easier if most source files and include files did + not need to be mapped ... especially C source files) + + -- no underscores + -- only alphanumeric + -- case insensitive (i.e. lower case) + -- (9 chars).(3 chars) + + (Notes: Some source file names and references to include files + had to be changed to create the filename mapping in the + first place, see list below. + + This is not so crucial now, since XC and XPP have been + written/modified to handle filename mapping. But, it + still does cause problems when making bug fixes to source + files with degenerate names and trying to keep track of + them with RCS. Of course, 99% of the mapping problems will + disappear with VMS V4.0.) + + also, directories should be case insensitive: + /sys/vops/AK --> ak + /sys/vops/LZ --> lz + + + sys/libc/cfilbuf.c -- filbuf --> vfilbuf (VMS) + since 'FILBUF' gets translated to + 'filbuf' on VMS, not 'filbuf_', + which causes a conflict: + FILBUF and (*filbuf)() + + + SPP coding conventions that cause problems for VMS FORTRAN compiler: + + a) multiple declarations, e.g. + + int ip + ... + int ip, this, that + + files: /sys/fmtio/ctoi.x + /sys/fmtio/sscan.x + /sys/fmtio/chdeposit.x + /pkg/system/sort.x + + b) 'real' function, e.g. + + real (dval, 0) --> real (dval, 0.0) + /sys/fmtio/gctod.x + + c) array declarations in procedures, e.g. + + procedure proc1 (array, count) + type array (count) + int count # should be BEFORE array declaration + # (tries to use 'count' as a REAL) + /sys/fmtio/patmatch.x + /pkg/utilities/t_translit.x + makeset(), filset() + + + and(), or(), not() --> andi(), ori(), noti() ??? + lots of references in /sys/fio/ to these procedures + (added them for VMS, using andi(),...) + xor() referenced in /sys/vops/...axorki.x + (added xor() for VMS, using xori()) + + FIO + file mode "APPEND" -- create the file if non-existent?? + UNIX (and now VMS) do this automatically, but system + reference document isn't clear about this. Without this + feature, /pkg/system/bugmail.cl and revisions.cl don't work. + + I/O drivers + ZMAIN passes the EPA of the read driver to IRAF_MAIN() ... + + This is OK in UNIX (and VMS, for now), but may have cases + where I/O is to different devices and the drivers are NOT + compatible. (I don't know enough of the internals of + other operating systems to say for sure that this is a + problem, but it seems like it could be.) + + Eg. STDIN from a file and STDOUT to terminal + + If the file and terminal drivers are incompatible, then + things won't work. We may eventually have some problems + in this area with VMS, especially if we start to support + some network I/O access. Eventually, we may store the + actual read/write function in the channel structure and + check it whenever a read/write function is called; that is, + override the higher level IRAF I/O at the kernel level. + + zardlp() function referenced in /sys/etc/lpopen.x ?? + (added dummy function for VMS) + + + modf() function used in /pkg/cl/unop.c + was missing from /sys/libc/ + (added modf.mar to /sys/os/ for VMS) + + +------------------------------------------------------------------------------- + + +3. Source file name changes + + + /pkg/softools/boot/spp/xpp/xpp_main.c --> xppmain.c + + Necessary for file name mapping: + + /sys/memio/ty_size.dat --> tysize.dat + + /sys/memio/coerce.x, salloc.x, sizeof.x + include "ty_size.dat" --> include "tysize.dat" + + +------------------------------------------------------------------------------- + + diff --git a/doc/ports/vmsport.doc b/doc/ports/vmsport.doc new file mode 100644 index 00000000..63e09193 --- /dev/null +++ b/doc/ports/vmsport.doc @@ -0,0 +1,1271 @@ +> From stsci Mon Dec 17 06:37:53 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA15814; Mon, 17 Dec 84 06:37:48 mst +> Date: Mon, 17 Dec 84 06:37:48 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412171337.AA15814@lyra.noao.UUCP> +> To: tody +> Subject: VMS .dir files +> Status: R +> +> Doug, +> +> Had some questions on how you handle directory files, especially in VMS. +> The filename mapping stuff takes a ".DIR" file on VMS and strips it off +> for IRAF. Is there a need to go the other way, and if so, how do you do +> it ? Do you keep a flag that says that a particular file is a DIRECTORY_FILE? +> The reason I ask, is that ZFINFO is supposed to tell whether a file is +> a directory file. Before, for VMS, zfinfo just looked for the ".DIR" +> extension. I have since modified it to do an additional check on files +> with null extensions, if it doesn't find the file in the 1st place. +> (since testing the single directory bit in the file header on VMS takes +> about 100 lines of code!!) I guess my overall question here is do you map +> the names back, somehow, for the case of zfinfo, or should I just keep my +> extra little check in there in case a file with a null extension comes in? + +The directory files are unique in the filename mapping scheme because they +have no extension in IRAF form, as when listing a directory (this is controlled +by the extension mapping string in config.h). This is necessary for +compatibility with UNIX and to ease pathname generation, e.g., "a/b/c" is +easy to generate if directory filenames are returned as "a", "b", etc., +but no so easy if they are "a.d", "b.d", and so on. If we used the second +form with the ".d" extension, and tried to add the ability to generate the +extension on UNIX via an FSTAT call on each file, listing a directory on UNIX +would be prohibitively expensive. If we put the ".d" extension explicitly +in the directory name on UNIX, then it would have to appear explicitly in +all UNIX pathnames and other directory file references. + +For these and other reasons, it seemed that the simplest solution was to +omit the extension for directory references. Directory files are almost always +referenced in a context where it is known that the file is a directory, +hence the kernel can add the extension if it needs to. Normally the kernel +will receive a directory filename with a null extension. ZFINFO should +definitely make an explicit check to see if a file is a directory, rather +than merely looking at the filename. As far as I can remember, all other +kernel primitives know if they are dealing with a directory file. Note that +ZFACSS was recently modified to add the DIRECTORY_FILE file type, used when +checking for the existence of a directory file (the new filetype tells the +kernel to add the ".dir" extension). + +The high level code does not maintain any flags telling which files are +directory files. In no case is a directory extension appended, except in +a machine dependent name entered by the user. + +> Also, re filename mapping, it seems that filenames without extensions +> (including +> directory files once they've been mapped on VMS) don't get listed correctly +> by the directory task in /pkg/system/. It seems to be a problem with +> /sys/clio/fntgfn.x, but I'm not sure - I'll see if I can locate it and fix it. +> It does the following: +> +> Files --> File +> Makefile --> Makefi +> README --> READM + +The function of FNTGFN is to expand filename templates, i.e., read VFN's from +a directory or directories using DIROPEN, select all filenames which match a +pattern, returning a list of filenames as output. It is unlikely that this +code could perturb a filename in the manner described. I recommend writing +an SPP test program which calls DIROPEN to verify that VFN's are being read +from the directory correctly, before doing anything to FNTGFN. The latter +package should be machine independent. + +By the way, the DIRECTORY task has bugs (machine independent) which are +annoying, but should not affect the basic operation of the routine. +These will be fixed eventually with a new version of DIRECTORY, but this +is not a high priority item at present. + +> Other than that, things are coming along; the system and help packages are up +> and running standalone, and the CL is coming along -- we had to backtrack a +> little and redo the old fixes for VMS... +> +> Jay. + + +> From stsci Mon Dec 17 13:58:50 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA22347; Mon, 17 Dec 84 13:58:44 mst +> Date: Mon, 17 Dec 84 13:58:44 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412172058.AA22347@lyra.noao.UUCP> +> To: tody +> Subject: iraf +> Status: R +> +> Doug, +> I hope you didn't get that last letter. I got hugh up on. Any way, I have a +> couple of iraf questions. I will start with the simple one first. +> How long should +> EOF last in the terminal driver?? Currently I return EOF once for each time it +> is typed. THis could be changed to only happening at beginning of line, or so +> that EOF is given for every call to zgetty after the first EOF is typed. + +Treat EOF like a character, except that EOF is not returned if there is any +data left to return. An input line, delimited by EOF but not newline, is +returned as a line of text not delimited by newline, followed by EOF in the +next read. The next read after that will return the next line of text from +the terminal, i.e., EOF does not "stick". + +> Also I got my problem fixed with task definitions. I had a tp = tp + TASKSIZ +> instead of tp = tp + TASKSIZ * BPI. We had to changed to this format since +> TASKSIZ * BPI is different from the actual size of the task structure in +> VMS. I changed all of the tp++ and tp + 1 to this format. Also I decided to +> use a macro instead to get to the next task structure so I didn't run into +> the problem again. + +Right, I recognize that as one of the more subtle bugs that Jim discovered +working with the prototype version of the system. Sorry that the bugfix did +not get into the version of the CL that you received. + +> Now for a couple of problems. The cl currently gets up on its own, but will +> not talk to any subprocesses. What happens is that it sends the one piece +> of data to the subprocess, and then the subprocess kind of takes off and reads +> millions of bytes of data instead of just 4 (internal length of data package). +> It apears from the debugs that I get that zardpr is not being used to get +> the data??? I don't know if you have seen this before. + +You might have a look at the UNIX version of ZFIOPR. This driver contains +support for debugging IPC. Debugging IPC with the OS debugger is difficult +or impossible. I instead put a debugging switch in the driver (an external +variable named debug_ipc, settable with the debugger before or during +execution), which causes debugging information to be printed during task +execution. There is also a "-C" flag on the UNIX IRAF Main which causes +the task to run standalone in CONNECTED mode, using the IPC driver, but packs +and unpacks char data so that I can run in IPC mode from a terminal. +Installing something similar in the VMS IPC driver would make it easier to +debug problems involving IPC. + +If ZARDPR is not being called to read from CLIN it may be because the integer +entry point address of ZARDPR, as returned by ZLOCPR, is not being passed +correctly to the IRAF Main by the ZMAIN. + +I am not sure what the 4 byte quantity referred to is. The 4 byte record +header used in the UNIX IPC driver is peculiar to UNIX and is not necessary +on a system which supports record level IPC i/o. UNIX pipes are byte streams, +causing record boundaries to be lost, and I had to use the 4 byte header to keep +records intact across the pipe. All knowledge of the 4 byte record header +is concentrated into the UNIX IPC driver. The high level code merely +calls ZARDPR, ZAWRPR, and ZAWTPR to read and write headerless records. + +> Opps got hung up on again... +> Another problem I had was with the -c flag. It seems that irafmain redirects +> i/o to the null device on task startup and shutdown. After redirecting +> STDOUT and STDERR, it sets them with fseti so that they are no longerT +> +> Hung up again... +> redirected, but does not swap the fd's back again. Then on task shutdown, it +> does through and closes the users files that weren't kept and manages to +> close the redirected stdout and stderr because they were copeid into a file +> descriptor greater than last_fd. Have you seen this before??. This also +> may be my problem with subprocess also. +> fred. +> + +The STDOUT and STDERR streams are redirected to the null file during +process startup when in CONNECTED mode (when process is spawned by CL). +Redirection is effected with FREDIR and cancelled with CLOSE, not FSETI. +FSETI is used to set the redirect flag in FIO if the stream has been +redirected remotely by the CL. + +The redirection to dev$null during startup and shutdown is a new wrinkle +added to the IPC protocol since the Sys.Int.Ref.Man was written. What +happens is: + + cl spawns subprocess + subprocess runs IRAF Main + Main redirs STDOUT,STDERR -> dev$null + cl sends envlist (sequence of + SET statements) + cl sends chdir curdir + cl sends "_go_" + Main cancels redirection + +The CL (actually, etc$propen.x) must send the "_go_" command to the subproc +to tell it that process startup is complete. Output is discarded during +startup to avoid deadlock due to two processes writing to the IPC at the +same time. + +Redirection is cancelled when the "_go_" is received by closing the affected +files. The FD's are swapped back at CLOSE time. If the redirection during +startup is not being cancelled it is probably because the Main is not seeing +the "_go_" command. +> From stsci Thu Dec 20 09:05:22 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA05472; Thu, 20 Dec 84 09:05:17 mst +> Date: Thu, 20 Dec 84 09:05:17 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412201605.AA05472@lyra.noao.UUCP> +> To: tody +> Subject: help db +> Status: R +> +> Doug, +> +> Jay here; having a bit of trouble with the help database. Running help +> standalone, I can do a mkhelpdb on lib$root.hd and it gets all the way to +> the end before dying. It seems to die when it tries to make the root/index +> entry, though I'm a little shaky on what's actually going on there. +> +> Does it read back the entire help db and then try to make a full index ? +> If so, then the problem is probably in our binary file driver. That's what +> it looks like to me, anyway. Any ideas, suggestions on where to look?... + +I could help more if I knew more about how it is dying. On UNIX one usually +gets a fault which can be caught by the debugger, after which one does a +stack trace to find out where the crash occurred. The most common cause of +faults are memory violations of various flavors. Unfortunately any bugs +having to do with memory violations are usually hard to track down, because +the fault is often not remotely related to the bug which caused memory to be +overwritten. In the event of a memory violation of unknown origin I usually +take the brute force debugging approach, i.e., I first find out what region +of memory is getting clobbered and then repeatedly rerun the program, doing +a binary search for the code which is causing memory to be clobbered by +setting breakpoints in time sequence. This always works but requires intimate +knowledge of the code and a good debugger. Probably you should try to avoid +this and check the low level routines first. + +From what you are saying it sounds like the problem is most likely in +hdb_make_rhd() in helpdb.x. I agree that the most likely cause of the problem +is the binary file driver. During compilation compiled help directories are +appended to the help database. This is done as follows: + + NOTE is called to note the one-indexed XCHAR offset at which + the next segment will be written. FIO keeps track of this + itself (not the kernel) hence this should not be the problem. + WRITE is called twice to append the two parts of a compiled help + directory to the output file. Since output is buffered there + may or may not be a corresponding call to ZAWRBF. + +This sequence is repeated for each help directory in the system. When the +tree has been exhausted the file position is NOTEd and used to compute the +length of the data area. HDB_MAKE_RHD is then called to make the root +help directory, taking the following FIO operations: + + SEEK to the beginning of the data area. This will lead to a file + fault to the file buffer containing the seek offset, i.e., + ZARDBF will be called to read in a file buffer somewhere back + toward the beginning of the file. This is something to check + since it is a random access and most or all file accesses thus + far tested have been sequential. + + READ is called to read in the entire data area. The resulting kernel + level operations are likely to be the following: + + - ZAWRBF to flush the buffer at the end of the file + - a sequence of ZARDBF calls to read the file buffers + containing the data segment (which is large, about 70KB). + - for each ZARDBF there will be one or more calls to AMOVC, + which is optimized in assembler calling the VAX MOVC3 + instruction (check that). + +The memory allocation routines are absolutely crucial to all of this (and to +the whole system), and are another possible source of trouble. In particular, +you might check ZRALOC, which is rarely used but is definitely used here. +The things to check are the pointer (if the buffer moves, is the returned +pointer a pointer to XCHAR) and the data alignment (if the buffer moves, the +buffer contents should be simply copied as a byte array with no byte shifts; +the high level code will shift the data to correct any alignment problems). + +> Also, the help tasks like lroff, mkhelpdb, and hdbexamine - can they be +> run from under the CL ? I can't seem to get them to work there , so I'm +> just running them standalone... +> +> Jay +> + +These tasks are available in the package SOFTOOLS and are nothing special. +They should run just like any other task. It is misleading because the +source is in pkg$help and the task declarations are in pkg$softools. +I will put a comment in the README. + +--Doug +> From stsci Thu Dec 20 11:32:09 1984 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA06285; Thu, 20 Dec 84 11:32:02 mst +> Date: Thu, 20 Dec 84 11:32:02 mst +> From: stsci (Space Telescope ) +> Message-Id: <8412201832.AA06285@lyra.noao.UUCP> +> To: tody +> Subject: file name mapping +> Status: R +> +> Doug, +> I am running into a couple of small problems. I am trying to use VFNDEL +> from xc. I have a file name t_rcardimage.x. I generate t_rcardimage.r and +> then t_rcardimage.f. At this point t_rcardimage.f maps to tj8rcarde.for +> which I would guess is correct. I then delete the entry for t_rcardimage.r +> the mapping for t_rcardimage.f then changes to t_widsout.r. Have you +> seen this before? Also from the cl if i delete a file in a directory and +> then try to do a directory listing of that directory I get: +> "Cannot open file drb4:[...]zzfnmap.zvf". May question is does the +> filename mapping still have the mapping file open for write or read_write +> access?? VMS has a tendancy to lock files against read if someone else is +> writing it. +> fred. + +Fred-- + + This one is a bug in the high level code. The filename mapping code could +not delete files with long filenames properly. There were two independent +bugs, for which I have included fixes below. I have tested this on UNIX +after compilation with the VMS file parameters in config.h (that's the best +I can do without going to a lot of trouble). + +The bug was such that file deletion of a file with a long filenames will have +corrupted your zzfnmap.zvf mapping file (the first long filename will have +been overwritten). After the bug fix, however, the mapping file will again +be readable and can probably be patched up with a rename or something. + +FIO knows whether or not the OS locks files opened for writing, as is the case +for VMS. If the file is locked by another process FIO will wait for it to +become available. FIO is careful to open the mapping file for as brief a time +as possible to minimize contention problems. Care is taken to avoid deadlock +between concurrent processes in cases such as a rename where it may be +necessary to open two different mapping files (what a pain that was...). +This sort of thing should not be a source of problems unless there is a bug. +See fio$doc/vfn.hlp if you want to know the nasty details. + +By the way, if a file such as "t_rcardimage.x" should appear as "t_rcarde.x" +in a directory listing, that is a sign that FIO could not find an entry for +the file in the mapping file. You reported something like this a while back. +Let me know if the problem should recur. + + --Doug. + + +[1] VFNMAP.X line 115, old ......................................: + + define FN_VFN Memc[M_FNMAP($1)+($2*2-2)*LEN_FN] + define FN_OSFN Memc[M_FNMAP($1)+($2*2-1)*LEN_FN] + +[1] VFNMAP.X line 115, new + + define FN_VFN Memc[M_FNMAP($1)+(($2)*2-2)*LEN_FN] + define FN_OSFN Memc[M_FNMAP($1)+(($2)*2-1)*LEN_FN] + + +[2] VFNMAP.X line 729, old ......................................: + + # entire MFD is written to the mapping file. + + checksum = vvfn_checksum (Memi[mfd+1], (len_file - 1) * SZ_INT) + ntrys = ntrys + 1 + +[2] VFNMAP.X line 729, new + + # entire MFD is written to the mapping file. Note that the + # file will contain garbage at the end following a file + # deletion (the file list gets shorter but the file does not). + # Compute checksum using only the valid file data, since that + # is how it is computed when the file is updated. + + len_file = LEN_MFD - (MAX_LONGFNAMES - M_NFILES(mfd)) * + (SZ_FNPAIR / SZ_STRUCT) + checksum = vvfn_checksum (Memi[mfd+1], (len_file-1) * SZ_INT) + + ntrys = ntrys + 1 +Re: file not closed when filename mapping -- + + I fixed the same bug in the version here, so you won't see it next time +around. + +> From stsci Wed Jan 2 06:42:10 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA26294; Wed, 2 Jan 85 06:42:05 mst +> Date: Wed, 2 Jan 85 06:42:05 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501021342.AA26294@lyra.noao.UUCP> +> To: tody +> Subject: file i/o +> Status: R +> +> Doug, +> We had a problem with the interaction between iraf file i/o and the +> zroutines. The problem seems to be with the asynchronousity. If we do the +> same thing as unix everything flys, but if we make it asychronous, it falls +> apart. The file name mapping works just fine, and so have our tests with it +> running asychronously [[synchronously?]]. Is it possible that the iraf fio +> plays with the buffer before the operation has completed?? + +The FIO code was written to call ZAWTBF after every i/o request, before using +the buffer, but this mode of operation has never been tested since UNIX is not +asynchronous. My feeling is that it is not worthwhile to test this mode of +operation until FIO supports more than one buffer per file. The current +interface still supports only one buffer internally, so you have to wait on +every i/o operation in any case, and having asynchronous primitives does not +make much difference (I just use very large buffers when I want it to go fast). +Unless you can find the bug in FIO without spending a lot of time, it might +be best to leave this until I modifiy FIO to support multiple buffers, +at which time the bug will certainly disappear. For the moment it is +sufficient to test the asynchronous features of the zroutines outside FIO. + +> Has anything happened with the new process caching. We do the impression +> (oops got) that there would be more changes in the cl. Something about having +> a bunch of processes loaded but not having the nesting and always being at +> the cl prompt? You had mentioned something about this before, and we were +> wondering if it might have got lost somewhere in getting the tape. + +All of the process caching code is brand new, written to use the new process +control code accessed via LIBC. The CL process cache code is a package +contained wholly within the file "prcache.c". This version supports nesting +of calls from one process to another (although deadlock will occur if the +cache fills up). The newest parts of the CL are the files "prcache.c", +"main.c", and "bkg.c". + +> Also with the text i/o the file size may not represent the actual size +> (in characters) of the file, due to VMS standard record files. Will this +> be a problem. Any Iraf created files will have the correct size since +> they are stream_lf. +> Fred & Jay + +This is ok, the file size need be known accurately only for binary files. +For text files the file size is not used for anything serious (see the +description of FSTT_FILSIZE in the manual page for ZFIOTX). + +Glad to hear that the filename mapping code is working well. It is crucial +to the port, and I was concerned about bugs since it is such a complex +package. + Doug +Fred and Jay: + + Answers to recent questions follow. Is the system ready yet for me to +look at over the modem? When you get it to a state where you feel it is +working fairly well, I would like to fire it up and try a few things. + + Doug. + +> From stsci Thu Jan 17 08:30:15 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA10600; Thu, 17 Jan 85 08:30:03 mst +> Date: Thu, 17 Jan 85 08:30:03 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501171530.AA10600@lyra.noao.UUCP> +> To: tody +> Status: R +> +> Doug, +> +> Here is a list of bugs, changes, suggestions, etc. compiled during +> the port of IRAF to VMS. +> +> Some of the bugs have the bug fixes listed here; others were too +> elusive and/or time-consuming to try to figure out at this time. When you +> get the latest, greatest VMS version of IRAF, what changes we made will +> certainly be there; we'll probably send along RCS files as well so you could +> easily update some of your files. However, most of the changes are +> just a few lines here and there. +> +> We await any comments or any bug fixes you have there... +> +> Jay and Fred + +Thanks a lot for the bug reports. I will wait and install these bug fixes +during the upcoming system integration period when I get the new VMS version +of the system back from you guys. + +I have been working on some of the more subtle bugs here and will send you +a bug list and/or code updates at some point. I have a few hard to catch +bugs to track down yet before this will be worthwhile. + +> P.S. +> We were discussing using mapped sections such as sdas +> uses for static files. There is one major difference in the way that +> iraf and sdas handle static (image) files. In the sdas routine +> a pointer is passed back to where the image resides in memory. This +> is due to the way the mapped sections work in VMS. In Iraf the zroutine +> is given a pointer to where the data is to reside, so we have to do +> a memory copy for each image reference, and may not be more efficient +> than just writing to or reading from disk. Can you see any easy +> way around this problem, or maybe an additional flag to zopnsf which +> indicates that a pointer is to be passed back from zardsf or zawrsf +> for the data rather than a passing in a pointer to where the data is to +> be read to or written from? (fred) + +My impression from a glance at the VMS system services was that the create +and map section function could be broken into smaller functions. The idea +was that ZARDSF, when requested to read/map file segment A onto memory +segment M, could unmap M (from the paging file) and remap it onto A. +A subsequent ZARDSF on the same M would unmap from file segment A and +remap onto file segment B. ZCLSSF would unmap file segment B (etc.) +and remap onto the paging file. When using the static file driver, the +high level system code will see to it that M is always aligned on a virtual +memory page boundary and is an integral number of pages. + +Will that work? If not something can be done, but at least conceptually +it makes sense to me, and it would eliminate artifical distinctions between +the two types of i/o. + +> From stsci Tue Jan 22 12:44:59 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA22373; Tue, 22 Jan 85 12:44:51 mst +> Date: Tue, 22 Jan 85 12:44:51 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501221944.AA22373@lyra.noao.UUCP> +> To: tody +> Subject: vfn mapping +> Status: RO +> +> Doug, +> We are having a problem with degenerate directory names. It appears that the +> filename mapping handles degenerate filenames, but no directory names +> contained within the path to that file. Is this correct? I would guess that +> the translation should be done in vfn_translate some where. +> fred. + +The mapping file is not used for directory names for performance reasons. +First, OS filenames are not mapped at all. An OS filename is any filename +for which ZFXDIR returns an OS directory prefix (the test is necessarily +machine dependent). Pathnames containing directory names are parsed by +VFN_TRANSLATE, extracting successive directory names. Each directory name +is processed through VFN_ENCODE to map illegal characters, then through +VFN_SQUEEZE to make it fit in an OS filename. It is possible that multiple +directory names will map to the same internal name. + +It is possible to modify the mapping code to use the mapfile for long +directory names, but I would prefer to make everyone use short names. +Is the problem with names in the system you got from us? We will change +the directory names if so. Long directory names will also lead to problems +with truncation of pathnames, hence should be avoided in any case. +> From stsci Wed Jan 23 10:40:52 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA05645; Wed, 23 Jan 85 10:06:56 mst +> Date: Wed, 23 Jan 85 10:06:56 mst +> From: stsci (Space Telescope ) +> Message-Id: <8501231706.AA05645@lyra.noao.UUCP> +> To: tody +> Status: RO +> +> DIFFERENCES /MERGED=1/OUTPUT=DISK$USER1:[IRAF.FRED]DOUG.TXT;1- +> DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;5- +> DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;4 +> +> Also, back to the static file driver. There are a number of hitches with +> mapping the file into the user's buffer. One problem with mapped sections +> is that we may run into the working set limit or paging file limit when +> mapping a file. Another is that the buffer pointer must point to a virtual +> address which has not been "created", so the pages in the user's buffer +> must be freed. The users buffer must be on a virtual page boundry. +> Also remote files cannot be used in a mapped section due +> to DECNET and RMS restrictions. Also in writting an image out to disk, the +> create mapped section cannot be into the users buffer, since the data would +> be lost, So a memory copy would be necessary. Also should a mapping be +> undone after a wait, so that the buffer can be reused, and what should +> be done about requests which overlap in some of the pages? Do you see any +> easy ways around these? In sdas a pointer to where the data is to be read +> or written is returned. This removes the problems of page overlap, memory +> copies, and page allignment. +> fred. + +I think I need to go into more detail on the scheme I had in mind for the +static file driver, including more information on how FIO works. The file +i/o zroutines are designed to be called only by FIO under carefully controlled +circumstances. + +FIO works internally by "paging" file segments the size of a FIO buffer into +the FIO buffer. A file is a series of logical pages, each the size of the +FIO buffer, which is in turn an integral number of disk blocks in size. +FIO guarantees that these logical pages will not overlap; if this were not +the case, ordinary i/o would not work properly, let alone static file i/o. + +A "file fault" occurs when i/o is done to a file segment not currently +mapped into a FIO buffer. If the file is open for RW access the file segment +will be read into the FIO buffer. This is true for both reads and writes. +A write causes the file segment to be faulted into the buffer, followed by +modification of the buffer contents. Nothing is actually written to the +file until another file fault occurs, causing the modified buffer to be updated +on disk. There is one exception to this scheme: when a write occurs which +would write the entire file segment, the read is skipped to save i/o. + +All of the above discussion concerns only FIO, and is independent of whether +the file is a static file, an ordinary disk file, a DECNET file, or whatever. +A static file is by definition a file which does not change in size while +i/o is in progress. At open time file space has already been allocated and +the system knows exactly where the file blocks are, making optimization +possible. A static file is never created by ZOPNST. It either already +exists or is preallocated by ZFALOC. + +FIO buffer space for a static file is allocated before i/o occurs (before +any sections are mapped) by the MEMIO procedure VMALLOC, which ensures that +the buffer is allocated on a virtual memory page boundary. VMALLOC calls +ZMALOC to allocate a conventional buffer larger than necessary, computes +the offset of the first page boundary, and returns a pointer to that page +to the caller. On VMS, VMALLOC would therefore allocate a potentially +large segment of storage in the paging file. The paging file space would +probably be freed very shortly therafter, but it is possible to run out +of space in the paging file if very large buffers are to be allocated. +The virtual page count limit of the process must be large enough to +accommodate the buffer, but since no i/o will be incurred the working set +size should not matter. If I understand VMS correctly, the principal +expense in allocating a large, say 1 MB buffer will be the expense of +initializing the associated 16 pages of process page table space. This will +likely incur several page faults (to fault in the pages of the page table), +plus .1 second or so to initialize the page table entries. + +The initial operations required to map an entire section into memory for FIO +are thus the following: + + open calls ZOPNST to assign a channel for the section file + VMALLOC calls ZMALOC to allocate a buffer the size of the section + (i.e., the size of the pixel storage file). Pages are + initially allocated from the system paging file. + +The next operation will almost certainly be a ZARDST to "fault" the file +into the FIO buffer, which is probably the size of the entire image. ZAWTST +would be called next to get the status of the read. No further FIO faults +would be incurred while accessing the image, since all of the data is +effectively accessible in memory. Eventually ZCLSST or possibly ZAWRST, +ZAWTST, ZCLSST would be called when the file is closed. + +I see the functions of the static file i/o routines in terms of VMS system +service calls as follows: + + ZOPNST Assign file to a channel. + + ZARDST Unmap buffer pages with $DELTVA. Map buffer pages onto + new section with $CRMPSC. + + ZAWRST Call $UPDSEC to update the section on disk. Do non unmap + pages as they may be reused. If the pages are not mapped + (very unlikely) perform a map and copy operation or just + return ERR. + + ZAWTST Static file i/o is not really asynchronous. Just return + status. + + ZSTTST Easy. + + ZCLSST Unmap all sections associated with the file. It may be + necessary to remap sections back onto the paging file to + keep the VMS memory allocator happy, but it is not necessary + for IRAF reasons since file buffer space is freed when the + file is closed. + + +Response to specific questions: + +> The users buffer must be on a virtual page boundry. + +Alignment on virtual page boundaries is not a serious problem; the +current VMALLOC procedure already does so. + +> Also remote files cannot be used in a mapped section due to DECNET and +> RMS restrictions. + +The static file driver scheme works well here because it makes it possible +to access files via DECNET if we wish to do so, by copying the data rather +than mapping it. This would be slow if the entire image were being mapped, +but might be worthwhile in some cases, since the software would at least +function. + +> In writting an image out to disk, the create mapped section cannot be into +> the users buffer, since the data would be lost, So a memory copy would +> be necessary. + +The buffer is mapped by a ZARDST call onto the section file, hence no +copy operation is necessary. ZAWRST merely updates any modified pages. + +> Also should a mapping be undone after a wait, so that the buffer can +> be reused.. + +I/o to mapped sections would not be asyncronous. The wait primitive would +only return a status value. Pages would be unmapped only at close time +and when the buffer is faulted (in a FIO sense) onto another section. + +> what should be done about requests which overlap in some of the pages? + +FIO does not permit such overlaps. FIO divides a file into a series of +logical pages the size of a FIO buffer. All i/o is initiated on logical +page boundaries. The FIO buffer is an integral number of disk blocks in +size. + +If there are serious problems with the scheme I have described (e.g., +because it does not fit the real VMS) then let me know and there are probably +things we can do. For example, VMALLOC could have a special kernel routine +instead of calling ZMALOC, and might only allocate virtual space without +mapping it, not using the VMS memory allocator at all to avoid conflicts. + + +> From stsci@aquila.noao Wed Jan 30 11:21:12 1985 +> Received: from aquila.noao.UUCP by lyra.noao.UUCP (4.12/4.7) +> id AA00912; Wed, 30 Jan 85 11:21:09 mst +> Received: by aquila.noao.UUCP (4.12/4.7) +> id AA21711; Wed, 30 Jan 85 07:28:33 mst +> Date: Wed, 30 Jan 85 07:28:33 mst +> From: stsci@aquila.noao (Space Telescope ) +> Message-Id: <8501301428.AA21711@aquila.noao.UUCP> +> To: tody@lyra.noao +> Subject: fortran hex values +> Status: RO +> +> Doug, +> We have just run into a non-protable problem. In VMS fortran hex values look +> like '111111'x and in unix fortran they look like x'111111'. Neither compiler +> will accept the other. (oops portable above). Do you know which is supposed to +> be standard??. The other way around it would be to run all fortran files +> through the cpp on our end, so that we can use ifdefs as you can under unix. +> fred. + + +The Fortran standard permits only decimal integer constants. The octal and +hex forms noted are both nonstandard exceptions and cannot be used in portable +Fortran code. There are many other things just like this, e.g., ! comments, +byte, integer*N, logical*N, etc. datatypes, nonstandard intrinsic functions, +do while, identifiers which are nonalphanumeric or which are longer than +six characters, continuation longer than a few lines, inclusion of character +in common blocks, use of normal data statement to initialize data in common +blocks, passing an integer*2 to a function which expects an integer +or vice versa, use of ichar for byte operations, and so on. A simple +preprocessor like cpp is a big help but will not solve problems like the ! +comments and identifiers longer than six chars, and I don't think it does +anything about octal, hex, character, etc. constants. + + +> ZGTENV (new kernel procedure) + + I changed the specifications trivially to make it consistent with the +other kernel procedures. See the code in the new version of IRAF I recently +sent you on tape. I also modifed TTY to permit device unit specs etc in +device names. The ZMKDIR primitive has not been specified because it is not +yet proven that we need it (I started to add it for making subdirectories +off UPARM in the CL). + + +From stsci Fri Feb 15 06:37:12 1985 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA15277; Fri, 15 Feb 85 06:37:06 mst +Date: Fri, 15 Feb 85 06:37:06 mst +From: stsci (Space Telescope ) +Message-Id: <8502151337.AA15277@lyra.noao.UUCP> +To: tody +Subject: IRAF things... +Status: RO + +Doug, + +Got the tape read on to VMS with rtar; had to make some small mods to read +from tape. Seems the C lib read() function can't handle it. We found all +the different files and new files, and are remaking the entire system. + +Some thoughts and questions: + +> 1. Fred was wondering whether there exists some documentation on XC and Mklib +> other than what's in the source files. + +There is no additional documentation at present. XC is however much +like the UNIX cc and f77 commands. + +> 2. In much of the GIO, FIO, IMIO source files, you have 2 conventions for +> include files, namely include "gio.h" and include . This works +> fine in UNIX because you have linked files to iraf$lib/, but on VMS this +> means we have to have 2 copies of the .h files. We are taking it upon +> ourselves to change all the "fio.h", "gio.h" etc. to , ,... +> It makes more sense to us, and to IRAF in general, it seems. Is this +> okay with you? + +I agree that it is best to avoid links for portability reasons, but sometimes +they make things much easier. Regarding the "file" and problem, I agree +that it is desirable to have only one copy of an include file (and of course +the link provides this on UNIX). To eliminate the possibility of error on VMS +we will have to get rid of the "file" references, but only in cases where the +named file is global, i.e., referenced in more than one directory. Whenever +possible I use local include files rather than global ones to reduce the +coupling between different parts of the system, and this should not be changed. + +This problem with eliminating the local copy of a global include file is +that the package source is no longer self contained. When a package is +listed or moved the included file may be omitted. + +Include files are not the only linked files. There are also linked libraries +and executables. In all cases I have tried to restrict the number of links +to 2 to make it obvious where the second entry is. The use of links for +libraries and executables can be eliminated by use of file moves or copies, +e.g., with a "make install" in the package Makefile (see pkg$cl/). This +solution works fine for executables, but there are problems with libraries. +Probably the best solution is to modify Mklib to permit library names like +"lib$libsys.a". + +> 3. Some of the VOPS routines have .s versions as well as .x ones. The +> Makelib files don't always use the .s files, but they're there. We've +> been converting your .s files to VMS .mar files (added to the filename +> mapping pairs), and using them instead of the .x files, updating the +> Makelib files appropriately. Some of the .s files (e.g. /vops/AK/aadd*.x) +> are simply output from the fortran compiler, possibly w/ a few things +> taken out. + +Sounds good. It seems to me that we can have both the unix and vms assembler +sources in the same directory with the filename mapping selecting the file to +be used when the extension is mapped (on VMS, the UNIX files should appear +as "file\.s" in directory listings). Assembler sources which appear in +directories but which are not referenced in the Makelib are garbage and +should probably be deleted. In some cases, e.g., AADD, there may be no +advantage in having a VMS assembler version since the VMS Fortran compiler +is better than the UNIX one. + +> By the way, we changed the IPC routines on VMS to use shared memory regions +> instead of mailboxes. This was due to lots of problems we had with ^C +> interrupts and the mailbox I/O. Shared memory regions helped a lot, +> but are still prone to the problems occasionally. Your latest changes +> dealing with interrupts look they will help us a lot too. In any event, +> the shared memory IPC is much faster and seems a lot more reliable than +> mailboxes. +> +> Jay and Fred + +The bug fixes I made should help a lot but do not yet fully solve the problem. +Also, in the UNIX IPC driver I had to disable interrupts while writing a record +to ensure that the data structures would not be corrupted. You might need to +do something similar. + +What is your schedule for converting to VMS version 4.0? We are still +running 3.7, and should coordinate the conversion to 4.0 between the +observatories. The 8600 will run 4.0, and should arrive sometime in May. +We should convert to 4.0 sometime before then. + +Do not waste time trying to get the new GIO stuff working yet. We are still +actively working on the many pieces of the graphics subsystem and it is not +yet completely installed nor user tested. The GIO/NSPP kernel should be +completed later this week or next and then we will complete the installation. +I can send you a tape containing only the affected files at that time if you +wish. + Doug +> From stsci Wed Mar 6 14:00:12 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA29984; Wed, 6 Mar 85 13:59:45 mst +> Date: Wed, 6 Mar 85 13:59:45 mst +> From: stsci (Space Telescope ) +> Message-Id: <8503062059.AA29984@lyra.noao.UUCP> +> To: tody +> Subject: IRAF +> Status: RO +> +> Doug, +> +> Jay here... IRAF VMS is coming along. Having some difficulties dealing with +> 4.0 though, asI'm sure Peter has told you about. The filename mapping +> stuff in particlular - we're keeping it as 3.x filenames even though +> it would be possible to convert to the nice longer ones in 4.0. +> But then it's not possible to go back very easily. W Something we have +> to think about some more and which Peter may talk with you about. + +At some point we should reconfigure the system to use the long filenames. +This requires reloading the system with RTAR, editing the filename parameters +in the file, and recompiling the system. Any system dependent +makefiles or VMS .com files you guys have added would also have to be changed. +I am considering renaming some files in the directories for the core system +to minimize these sorts of problems, allowing us to get the basic system up +and running and then use the system to handle the filename mapping required +for the applications directories. This does not solve the Make problem unless +we add an IRAF Make to the SOFTOOLS package, which is probably the thing to do. + +> Your ideas on using mapped sections for the VMS static file driver look +> okay, thou and should work, with some slight mods, +> but we haven't gotten around +> to it yet (may be lots of line noise here...). +> Also some other enhandcements +> are in the queue for VMS, time allowallowing... +> +> Had a question re Help and Help dtaatabases. +> In SDAS, we have 2 choices for +> Help under IRAF - 1) use 1 big Help db with IRAF and SDAS help combined, or +> 2) have a separate SDAS help db. I've done some simple tests with 2 +> separate dbs and it doesn't look to good. If you've run help in IRAF and +> then turn around and specify a new db, does the new database get read +> in entirely? One can envision an SDASHELP script that does: +> set helpdb=sdas$sdas.db +> help ... +> set helpdb=dev$help.db +> But this method can be terribly slow if you go back and forth between IRAF +> and SDAS help and requires a separater task , SDASHELP, to invoke it. +> +> Maybe I'm not  don't fully understand the details of the +> helpdb stuff...would it be +> possible to have a couple of helpdb's loaded in memory at the same time, or +> a list of helpdb's to search in the event of a 'help'.? Or, should we +> just use one huge helpdb for IRAF and SDAS and avoid all these problems?? + + Jay + +I think the best solution is for each system to have one big help database +for all packages. I see no problem with this, but the current help database +facilities are probably not up to the task and will have to be replaced +eventually possibly with a DBIO based version. + + +> From stsci Sat Apr 6 07:52:33 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA07328; Sat, 6 Apr 85 07:52:27 mst +> Date: Sat, 6 Apr 85 07:52:27 mst +> From: stsci (Space Telescope ) +> Message-Id: <8504061452.AA07328@lyra.noao.UUCP> +> To: tody +> Subject: Mapped sections on VMS +> Status: RO +> +> Doug, +> +> Finally got around to implementing a static file driver for VMS using mapped +> sections. Your ideas were partially used here, as well as the stuff I threw +> together for the IPC driver using shared global sections. However, there +> are 2 problems which don't want to be solved very easily. +> +> 1. When closing a static file (mapped section file), the pages must +> be unmapped. Since they are mapped within the IMIO via VMALLOC, +> I can't unmap them at the Z-routine level because of the way ZMALOC +> works (puts the count in the longword ahead of the returned buffer +> address). So the pages must be unmapped before the call to ZCLSSF. +> +> However, I have not been able to get this to work. That is, even +> unmapping the pages and then closing the file doesn't work very well +> This may be due to some incompatabilities between the $CRMSPC +> ssystem +> service and the LIB$GET_VM() routine used by ZMALOC to get virtual +> memory. Seems that using the $CREVTA (create virt address space) +> doesn't work too well with the LIB$GET_VM - in fact, DEC warns about +> using them together, since they don't communicate with each other. +> +> The effect of this is that the image file remains open until your +> executable image exits - the close doesn't really close... +> +> The only way I see around this is to rewrite ZMALOC/ZRALOC/ZMFREE +> to use $CREVTA/$DELVTA and then hope for the best, or possibly +> use another idea you had, of having a special Z-routine for a +> allocating virtual memory on page boundaries w/out mapping it... +> maybe that would work, as long as the pixel-file buffers were +> unmapped before the call to ZCLSSF. + +I thought the memory allocation might be a problem, in which case the best +solution is probably to add two new kernel procedures (sigh) to be used to +allocate and free pages of virtual memory independently of the ZMALOC allocation +facilities. The pages would initially be unmapped and would not get mapped +until a ZARDSF call was made. Since we would then be able to package the +virtual memory allocator and static file driver together in a self contained +unit, we should be able to do whatever needs to be done to make it all work. +If this looks reasonable I will have to generate some specifications for the +kernel procedures and work out the details of the high level code (not a big +task). + +> 2. If you open an image file w/ READ_WRITE access, any changes made +> to the buffer will be made in the file, whether or not a call to +> ZAWRSF is made. This is the way mapped sections work on VMS and +> I haven't found a way around it yet. This could be a potentially +> major obstacle... + +I don't see any problem here. If FIO writes into a buffer opened on a file +with read write access, the file is expected to be modified. The only +difference between this and normal i/o is that the write may occur sooner +and cannot be cancelled, but there is no software in the system which depends +upon such subtle semantics. + +> Peter probably talked to you a few times about device specifications within +> IRAF, possibly of the form set stdimage=(iis,image_unit_2) or something of +> the sort. Support for this is definitely needed at some higher level than +> the kernel. For the line printer driver, I had to play all kinds of games to +> map the printer names without having to recompile the ZFIOLP source and relink +> the system package. Basically, I used some VMS means to find out where +> iraf$dev/ was and then read a file called "lprtable.vms" which had things like +> +> qms LCA0 +> printronix SYS$PRINT +> +> By setting printer=qms for example, 'qms' would be looked up in termcap and +> satisfy all that stuff, then at the ZFIOLP level, qms would be mapped to +> the VMS queue LCA0. +> +> For things like this, it would be nice to have some system-dependent device +> mapping table that is read at a level higher than the kernel, that would +> map a device-type (for termcap/graphcap/printcap/...) +> into an OS/system-dependent +> name or queue_name. For example: +> +> qms LCA0 +> deanza ABC0: (i.e. some VMS device name) +> ... +> +> I know it's easy in UNIX to have these tables built into the kernel, so all +> you do is a 'make' and IRAF is remade. In VMS, this is not so easy, and we +> would like to be able to distribute executables. Also, our RCSMake hasn't +> worked since VMS V4.0 came along -- we're using Mklib and DCL command +> procedures everywhere. +> +> I think this kind of device mapping would not be hard and would make it easy +> to add devices without remaking part of the system. + +I agree that a runtime table lookup would be nicer in some cases than a +compiled table. I suspect however that the structure and contents of the table +may be too machine dependent to be worth trying to standardize. The easiest +solution may be to have the kernel read the table, rather than IRAF. In that +case it may be more appropriate to put the table in the OS directory, rather +than in DEV. It would not be difficult to call to the ZFIOTX primitives +directly to read such a table. + +Some information can now be included in the device specification in the +CL environment. Peter mentioned a syntax such as + + deanza!unit=2 + +or some such. Anything can follow the ! and is assumed to be system +dependent. The high level code will ignore the ! and all that follows +in the termcap and graphcap access, but will pass the full string on to +the kernel to parse as it wishes. + + +> From stsci Thu May 9 05:41:11 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA17243; Thu, 9 May 85 05:41:06 mst +> Date: Thu, 9 May 85 05:41:06 mst +> From: stsci (Space Telescope) +> Message-Id: <8505091241.AA17243@lyra.noao.UUCP> +> To: tody +> Subject: IRAF +> Status: RO +> +> Doug, +> +> Jay here; have had a hell of a time trying to login to your system, though I +> think it's a problem with our phone system - which means you're probably +> having trouble getting in to ours as you did before. + +I have been having lots of trouble getting modem access, but have not tried +it for a week or so. The next test will be trying to send this mail. + +> In any event, a few items/questions... +> +> Peter talked to you about the filename mapping and using actual VMS names in +> the CL. We initially thought it was a filename mapping problem, but you were +> right in that it is already handled quite well. The problem, as we quickly +> discovered, is that most of the tasks which open files, handle lists of files +> and templates. The template matching code is the problem with respect to +> VMS names, since things like "[a-zA-Z0-9]*" can be used as a filename, and +> using a VMS name like [iraf.jay.cl]file.dat is processed as a template. +> I don't see a real easy way around it - Peter's suggestion about quoting all +> OS-dependent entities with !'s may be the answer, meaning VMS names would +> be ![iraf.jay.cl]file.dat! on the command line... Sorry if you went about +> the filename mapping code looking for this non-existent bug... If !'s are +> used, some higher-level decoding must be done, but I'm not sure exactly where, +> probably in the template stuff and the filename mapping... + +I see the problem now and of course you are right, the template expansion code +is at fault. It is not out of the question to consider changing the logical +directory metacharacter to something less troublesome, e.g., one of "!@%^". +It should be a character which satisifes the following criteria: + + not routinely used in filenames on any of our target systems + not an operator character when "lexmodes=yes" + +Unfortunately the $ fails criteria number one. Let me know what you think of +such a change and I will discuss it with my group in a meeting on Wednesday. +It is not too late to make such a change if it will make life significantly +easier on VMS. + +> Sometimes (a lot less now than before) we have a situation where a connected +> subprocess gets astray and is running while we are back at the CL, i.e. doing +> a 'prcache' shows a state of 'R' for the process. 'Flprcache' can't kill it, +> and on logout, the CL will hang forever for what is seemingly a running +> process. Is there a way we can just kill these guys off, especially on +> logout? Seems to +> me that connected subprocesses should never be asynchronous anyway, so being +> in this state is really an error, though maybe there are future ideas I'm not +> aware of. In any event, sometimes an interrupt at a certain time can put a +> subprocess in this sort of state and making logging out hang the process, and +> the user will need to type ^Y to get out on VMS. Have you seen this type of +> occurence on Unix, and if so, have you any ideas on how we might combat this +> portably? If you don't see it there, we can just do some "#if vms" sections +> in the CL to make sure subprocesses die on logout, but I'm hoping for a more +> portable method. + +We also sometimes get hung processes with state R (apparently running). This +happens rarely but is evidently a bug in the system independent code, which +I will fix eventually. I may not be able to prevent processes from getting +into such a state, but I should be able to make the system detect such a state +and recover automatically. + + - Doug + 13 April 85 +> From stsci Thu May 23 06:16:18 1985 +> Received: by lyra.noao.UUCP (4.12/4.7) +> id AA11890; Thu, 23 May 85 06:16:14 mst +> Date: Thu, 23 May 85 06:16:14 mst +> From: stsci (Space Telescope) +> Message-Id: <8505231316.AA11890@lyra.noao.UUCP> +> To: tody +> Subject: major portability problem in fortran +> Status: R +> +> Doug, +> We have run into a snag up here. The problem is with fortran integer +> constants. We currently have iraf moved over to the Sun and I was working +> at getting it up and running. It seems that all integer constants are +> passed as I*4. This causes problems for functions that expect I*2 values +> (xpp character constants). Due to the byte ordering the value which +> gets to the other end is the high bytes rather than the low bytes of the +> I*4. This problem would also exist going from I*2 to I*4. Do you know +> of any easy (portable) way to type cast constants in fortran. The other +> method I considered was putting he character constants into the string +> array that gets created by either rpp or xpp (I can't remember which). This +> would solve the problem for xpp characters, but would not solve any +> problems for xpp routines expecting short parameters and getting an I*4 +> constant. +> fred. +> + +1. Discussion + + I knew this would be a problem but could see no easy way to address the +problem until we had access to a non-DEC machine with the bytes in an integer +reversed. It is considered an error in SPP if the programmer declares an +argument as I*2 and passes an I*2, or vice versa. Similar problems occur if +the mismatched types are int and long or int and bool, or if a procedure is +passed the wrong number of arguments. Such bugs will go unnoticed on a DEC +machine because of the architecture (or Fortran implementation). The first +port of IRAF to a non-DEC machine will require finding all such bugs. + +I had always planned that my group would do this kind of debugging, but have +no objection if you wish to push ahead and find the bugs for us. The rule is +that an integer constant appearing in an argument list must be declared as +an integer argument in the called procedure. If a short, char, or long is +required than an explicit type coercion must be used, e.g., "(a,long(1),b)". +A character constant, e.g., 'a', is defined as an operand of type char. + +It is up to the programmer to use explicit type coercion where necessary to +match the datatypes of actual and dummy arguments. In the case of the +character constant I expected that we would have to add a switch to the +preprocessor to automatically add a call to a I*2 coercion function when +a character constant is used as an argument to a procedure. Of course +Fortran does not define such a function since I*2 is itself non standard +Fortran. The VAX/UNIX Fortran compiler does not provide such a function, +but then none is required since I*2 and I*4 are interchangeable as arguments +on the VAX. Compilers for machines where this is not the case would hopefully +provide such functions. The AOS compiler does, but I never checked the +UNIX implementation on non-Dec machines. It does not surprise me if the +SUN/UNIX Fortran compiler omits the INT2 and INT4 (or whatever) intrinsic +functions. + +My plan if the host compiler did not provide INT2 and INT4 intrinsic functions +was for the compiler to generate a Fortran temporary variable of the necessary +type. This will always work but requires care to implement in the current +preprocessor due to the complications of statement labels, error checking, etc. +If the time has come then I can do this or perhaps you would like to have a +go. An easier, but less attractive solution might be to add the intrinsic +functions to the Fortran compiler itself and report the extension to SUN. +If this were done the Fortran generated for 'a' would be 'int2(97)' when the +paren level is greater than zero, skip the INT2 otherwise. + +In retrospect I think it would have been better to define character constants +as integer rather than char values. It is not too late to make such a change +to the language definition but doing so will introduce bugs into existing code. +Since we have not already debugged such code, this is not a great problem. +Rather than find such bugs at run time, I would do a pattern search of the +entire system looking for occurrences of ' within parens, then examine each +such occurence interactively. We should really do this ourselves for our +own code, rather than having you guys do it. + + +2. Conclusions + + Having thought all this through, I think the best course of action is the +following: + + [1] Change the SPP language definition to define a character constant as an + integer, rather than char value, e.g., 'a' would be exactly equivalent + to 97 in all contexts. + + [2] Modify XPP to declare and initialize hidden Fortran I*2 and I*4 + intermediate variables whenever the coercion functions "short", "char", + or "long" appear in SPP code within the body of a procedure. + +It would be best for NOAO to do this since we are responsible for the code +which is causing the problem. There is a big merge coming up with the +installation of VMS IRAF at NOAO, and that would be an appropriate time to +address the problem. If you cannot wait and wish to forge ahead, feel free +to do so, but please keep notes on the changes required (I would expect there +will be only a few dozen such occurrences). + + +3. Other + + We are in the process of submitting a request to NSF to purchase a SUN +system for delivery this fall to Tucson. I plan to port IRAF to the SUN, +including special performance enhacements for disk access and an interface +for the Sky Warrior array processor. Anything you guys (or JPL) do in the +interim will of course help make this easier. + +The JPL port to the JUPITER running the ISI version of 4.2BSD UNIX has run +into serious problems with the ISI Fortran compiler, which turns out to be +untested and quite buggy. An AOS port has also begun, with Steward doing +most of the work. I would like to eliminate this type of bugs from the system +before these sites really attempt to bring the system up. + +By the way, in the process of trying to compile IRAF on the JPL system we +found two bugs in the SPP compiler, both caused by the wrong number of +arguments to a procedure. One was in XPP (xppcode.c) and can be found with +LINT. The other was in RPP in the file "rpprat/errchk.r", in the call to the +procedure GNBTOK. Presumably you have already found both of these problems +since you have already succeeded in compiling the system. + +Other bugs were found in OSB in the same port. Some of the ACHT procedures +had bugs, the Makelib file had a bug. In OS in the ZCALL file, "pointer to +function" was being used where "function" was required; the UNIX/C compiler +does not complain about such usage. If you have not already found these +I can supply notes (they will be fixed on the next tape you receive in any +case). +> From stsci Thu Jul 11 05:33:23 1985 +> +> Doug, a few short notes... +> +> 1. XPP +> +> The 'lexyy.c' file for the new XPP (output of 'xpp.l') causes the VMS C V1.5 +> compiler to bomb of a symbol table overflow, so we're still using the old +> XPP. I tried the C V2.0 compiler (on our 8600) and it fixes this problem, +> but spouts out other warnings; I'll have to check them out when it gets +> installed on our machine. This is just a warning; I don't know which +> version you're running. + +I have had the V2.0 C compiler installed on the 8600 and that is what I will +be using when I recompile the CL etc., hope it does not give serious problems. + +> 2. RPP +> +> The file '...imdis/cv/load.x' causes RPP to stop somewhere and say it's +> got a storage overflow. I split the file into 2 files (load1.x and load2.x) +> and things work okay. Don't know if you have this problem, too. + +Just want to make sure you know (I already told Peter) that the CV code is +preliminary and will be changed significantly. I am not happy with it yet +and it will be reworked considerably before being installed (ideally the +display interface subroutines Starlink is working on would come along in time +to prevent a third major revision). On the other hand, either the old display +using the IMIO interface or the new CVL (to eventually replace "display" and +inherit the same name) are both infinitely faster than the infamous SDAS image +load code I have been hearing about. PLEASE SPEED THAT THING UP!! I have +been overhearing comments from the astronomical community about how slow "IRAF" +is, following the recent SDAS/IRAF demo. People do not understand that IRAF +and SDAS are quite different things, or that SDAS is not using IRAF yet for +anything having to do with image display or vector graphics. + +The IRAF image load software runs 12 clock seconds on an unloaded 750, and +should run twice as fast as that on a 780 with its faster cpu and faster, +asynchronous i/o system (512 square by 16 bit image). Note that only standard +hight level IRAF interface software is being used and the DISPLAY program is +a sophisticated program with lots of fancy options. This proves that is it +possible to have features and speed, too. + +> 3. VMS Kernel +> +> I wrote an assembler version of the str*() routines for VMS last year to +> remove dependencies on the VMS C libraries (str.mar). There are 2 +> "phantoms" in there that have been known to cause access violations at +> randomly spaced intervals and disappear when you try to throw in extra +> code to debug them. The two lines containing the 'DECB' instruction should +> be changed to 'DECL' instead; subtracting 1 from an address can have strange +> effects when only the low-order byte is changed! This is an old phantom +> which has finally been killed, but as we all know, phantoms have brothers... +> +> Jay + +Unless it can be demonstrated that the assembler versions of the string +routines are a good deal faster than the C versions in LIBC, I do not plan +to use them. I will look at the /mach output for the C versions before +deciding. If the assembler versions used (already use?) the VMS string +instructions that would be different. + diff --git a/doc/pset.ms b/doc/pset.ms new file mode 100644 index 00000000..b7193a08 --- /dev/null +++ b/doc/pset.ms @@ -0,0 +1,433 @@ +.LP +.ps +1 +.ce +\fBNamed External Parameter Sets in the CL\fR +.ps +.ce +\fIand related revisions\fR +.ce +Doug Tody +.ce +October 1986 +.sp 2 + +.NH +Introduction +.PP +The CL has recently been modified or extended in a number of areas to support +named, shareable parameter sets. The purpose of this memo is to document the +changes and the new facilities. All revisions are upwards compatible with +previous versions of the CL. + +.NH +Parameter Set Extensions +.PP +The major modification to the CL was the addition of support for named external +parameter sets, breaking the one-to-one relationship between tasks and what +were formerly called parameter files. This was done to make it possible to +better structure the parameter sets of tasks with very large numbers of +parameters, and to make it possible for tasks which use the same piece of +code to share a common parameter set. +.PP +It should be emphasized that most tasks are not expected to need the new pset +facilities, and the use of a single main task parameter set should prove the +simplest and best approach for most tasks. Tasks which would otherwise have +very large parameter sets, subsets of which would appear in the parameter sets +of other tasks in the same package, are most likely to benefit from the use of +the new pset facilities. + +.NH 2 +Conceptual Model +.NH 3 +Pset Tasks +.PP +A \fIpset-task\fR is an object whose function is to maintain a global set of +parameters for access by other tasks or by the user. Pset tasks may be either +visible or hidden, but normally they serve an important role in describing +some data object or controlling some algorithm, hence they should be a visible +and well documented part of the user interface to a package. One of the main +reasons for implementing a named pset as a type of task is this desire to have +them be a visible part of the user interface. They appear in the package menu, +have on-line manual pages, can be run as tasks (\fIeparam\fR is called up to +edit the pset), and their contents (the pset parameters) can be accessed using +the facilities already provided for accessing the parameters of an ordinary +executable task or package. +.PP +A named pset is very similar to a global (external) data structure in C. +Psets and tasks are two different but equally viable classes of objects from +which packages are constructed. In a sense it is not correct to think of +a pset as a type of task, rather, psets and tasks are instances of some more +abstract type of object, and a package is a collection of objects of various +types which operate upon a particular kind of data. +.PP +Examples of psets are the control parameters for a sky fitting or centering +algorithm, the control parameters for a graphics plotting utility (e.g., an +axis drawing and labelling routine), or a set of parameters describing the +characteristics of a particular type of data. The conceptual basis of a pset +should be obvious to the user, else the use of a pset is probably not justified. +.PP +By concentrating the information pertaining to a particular object in one place, +a pset can significantly reduce the complexity of a large package without loss +of flexibility or control. The information hiding capability of a pset can +reduce the coupling between the modules of a large package or task, much as +the use of an opaque external data structure (descriptor or handle) can reduce +the coupling between the procedures in a large program. +.NH 3 +Pset Parameters +.PP +A pset parameter serves as a pointer to an external parameter set. A pset +parameter is a string valued parameter of datatype \fIpset\fR. The string +value of the parameter is the filename or taskname of the pset to be used +when the task is run. If the value of the pset parameter is the null string, +the parameter set of a pset-task with the same name as the pset parameter +will be used. All pset parameters in a package that refer to the same type +of pset should have the same name, and a pset-task of the same name should +be defined in the package to define the contents of the parameter set and +to supply default values (if appropriate) for the parameters. +.PP +Whereas a pset-task is a named, statically allocated instance of some data +structure, much like a C external data structure, a pset parameter is like +a C structure pointer. Imagine a C function which takes a pointer to an +external structure as an argument. If the value of the pointer is null +the function references a particular default global structure, otherwise the +referenced structure is used. Within the program the external structure is +always referred to via the pointer, regardless of the name or storage class +of the particular external data structure being referenced. This is very +similar to the way psets are used in CL programs. +.NH 3 +Relationship to other Data Structuring Facilities +.PP +The main parameter set of a CL task is very similar to the arguments and local +variables of a conventional compiled procedure. The pset construct adds a +basic data structuring capability to the CL. It is not surprising that, +just as data structuring becomes increasingly important as the size of a +compiled program or package increases, we should start to experience the +need for it in our large CL tasks and packages. Part of the need can and +should be met by non-CL data structures, e.g., image structures and various +kinds of database facilities, but the CL pset mechanism offers unique +facilities for queries and command line parameter assignments which are not +provided by these other, more lower level facilities. In general, the pset +mechanism should be used for high level interactive control, and the lower +level data structures should be used to access and store large quantities +of data. + +.NH 2 +Implementation of Psets +.PP +A pset-task is declared with the \fItask\fR or \fIredefine\fR statements +in much the same way that a CL script task is declared, except that the +filename extension of the referenced file is \fL.par\fR rather than \fL.cl\fR. +For example, +.DS +\fLtask skypars = "mypkg$skypars.par"\fR +.DE +adds the new pset-task \fIskypars\fR to the current package. The parameter +set of a pset-task is initially read from the named file in the package +directory and is updated in the the users \fLUPARM\fR directory, just as +for a conventional task. For those who prefer to have their parameter +declarations parsed, the actual declarations file may be a \fL.cl\fR file, +e.g., \fLskypars.cl\fR, but the extension \fI.par\fR must still be used in +the \fItask\fR statement. A pset-task may be called like any other task, +with or without arguments on the command line; the function of a pset-task +is to call up \fIeparam\fR to edit and update the parameter set. +.PP +A pset parameter is declared like any other parameter except that the +datatype is specified as \fIpset\fR. For example, either +.sp +.nf +\fL skypars,pset,h,,,,"sky fitting parameters"\fR +or +\fL pset skypars { prompt = "sky fitting parameters" }\fR +.fi +.sp +would suffice to declare the pset parameter \fIskypars\fR in the parameter +set for some task. +.PP +Binding of a pset parameter to a particular instance of the referenced +parameter set occurs when a task is \fIexecuted\fR. This means that the +pset parameter must be set to point to the pset to be used either before +the task is called, or on the command line when the task is called. +The pset parameter should not be changed to point to a different pset while +a task is executing. +.PP +When a task is invoked the main task parameter set and all external psets are +loaded into memory and the names and values of all the non-query parameters +therein are passed via IPC to the CLIO cache in the subprocess. The query +mechanism works exactly the same for pset parameters as for the main task +parameters. For example, if a parameter does not have a valid value or the +effective mode is something other than hidden, the parameter is not cached +in the subprocess during task startup, and a query will result if the parameter +is referenced at runtime. The values of pset parameters may be set with +\fIclput\fR calls and the parameter set will be updated if the task exits +normally, just as for the main task parameter set. +.PP +The runtime context of a task which has a parameter set has always included +three different psets, the main task pset, the pset of the package in which +the task is defined, and the global CL pset; runtime parameter references +are resolved by searching the three psets in the order \fItask-pkg-cl\fR. +This mechanism has been extended to include any psets referenced in the +main task pset. For example, if the task references the two psets A and B, +the search path for a parameter is \fItask-A-B-pkg-cl\fR. If the package +itself references psets they will be loaded when the package is loaded, +since a package is a type of task, however the use of psets in the parameter +set of a package is not recommended (cacheing frequently used psets at package +load time may be desirable, however). +.PP +Since the psets are included in the search path for a runtime parameter +reference, the pset name is optional when specifying a parameter. +This has two major implications: first, the parameters to a task may be +organized into psets without the applications code having to know about +the existence of the psets, and second, the user may override the values +of pset parameters on the command line when a task is invoked, without +having to specify the pset name., i.e., \fIparam=value\fR rather than +\fIpset.param=value\fR. The full syntax is however supported for both +command line and runtime parameter references, and should be used in +applications code to eliminate the possibility of name collisions, +to improve error detection, and to speed searches. +.PP +In the current implementation of the CL, psets may not reference other psets. +There is nothing in the conceptual model of a pset which excludes this, +but it would complicate the implementation considerably and the use of such +a feature would probably be undesirable in any case. +.NH 3 +Example +.PP +A brief example may help to clarify the discussion presented in the last +section. Assume we have a task \fIcenter\fR with the following parameters +(a real task would have lots more): +.DS +\fLimage,s,a,,,,"image name" +objlist,*imcur,a,,,,"list of initial object centers" +cenpars,pset,h,,,,"centering algorithm parameters" +skypars,pset,h,,,,"sky fitting algorithm parameters"\fR +.DE +Assume further that the \fIskypars\fR parameter set contains a parameter +\fIksigma\fR defining the k-sigma cutoff level for some iterative rejection +feature of the sky-fitting algorithm. +.LP +The task would normally be called as follows when working interactively: +.DS +\fLcl> center pix\fR +.DE +This would run the task, taking cursor input interactively from the image +display, using the default centering and sky fitting parameter sets. +To use a different set of centering algorithm parameters, stored in the +file \fLcen1.par\fR in the current directory: +.DS +\fLcl> center pix cen=cen1.par\fR +.DE +To use the default parameter sets, but override the value of the \fIksigma\fR +parameter in the \fIskypars\fR parameter set: +.DS +\fLcl> center pix sky.ksigma=3.5\fR +.DE +Assuming that the \fIcenpars\fR parameter set does not also contain a +\fIksigma\fR parameter, this could be shortened to: +.DS +\fLcl> center pix ksigma=3.5\fR +.DE +The default \fIcenpars\fR and \fIskypars\fR parameter sets would be stored +in the files \fLcenpars.par\fR and \fLskypars.par\fR (or in equivalent \fL.cl\fR +files) in the package source directory. + +.NH 2 +CLIO Pset Extensions +.PP +The CLIO package has been modified to support the new CL pset facilities. +The major modification was the addition of a subpackage of get/put routines +to be used to access parameters in named psets. These are very simple +routines, provided to avoid having programs explicitly reference the pset +name in every \fIclget\fR or \fIclput\fR call, and to eliminate the need +for string concatenation to construct the \fIpset.param\fR parameter name +if the pset name is parameterized. The new routines are summarized below. +.sp +.TS +center; +n l. +pp = \fLclopset\fR (\&psetname) open pset +\fLclcpset\fR (\&pp) close pset +pval = \fLclgpset\fR[\fLbcsilrdx\fR] (\&pp, param) get parameter +\fLclppset\fR[\fLbcsilrdx\fR] (\&pp, param, pval) put parameter +\fLclgpset\fR (\&pp, param, sval, maxch) get string parameter +\fLclppset\fR (\&pp, param, sval) put string parameter +.TE +.LP +The CLIO pset routines are functionally equivalent to the corresponding +\fIclget\fR and \fIclput\fR routines except that ``\fIpsetname.\fR'' is +prefixed to the given parameter name to form the full parameter name +before the parameter value is retrieved or updated. The string \fIpsetname\fR +is the name of the pset parameter (pset pointer) in the main parameter set +of the calling task. +.PP +Continuing with the example presented in \(sc2.2.1, we would open the pset +and fetch the \fIksigma\fR parameter as follows: +.DS +\fLpp = clopset ("skypars") +ksigma = clgpsetr (pp, "ksigma")\fR +.DE +.LP +A conventional \fLksigma = clgetr ("ksigma")\fR statement could also have +been used, in which case the CL would search for the named parameter using +the search path described in \(sc2.2, referencing the first parameter found. +Use of the CLIO pset routines will be preferable in most applications since +they eliminate the possibility of the wrong parameter being referenced. + +.NH +Eparam and Lparam Extensions +.PP +The \fIeparam\fR and \fIlparam\fR tasks have been modified to work upon either +the main parameter sets of tasks (as before), or upon named parameter files. +The presence or absence of a \fL.par\fR filename extension is used to +determine whether an operand is a taskname or a filename. For example, +.DS +\fLcl> eparam skypars.par\fR +.DE +will edit the parameter \fIfile\fR \fLskypars.par\fR in the current directory, +whereas +.DS +\fLcl> eparam skypars\fR +.DE +will edit the parameter set for the pset-task \fIskypars\fR. +Lastly, since \fIspypars\fR is a pset-task, we could just type +.DS +\fLcl> skypars\fR +.DE +to edit or review the contents of the pset. +.PP +The parameter file \fLskypars.par\fR in the above example would probably be +created using the new colon-command extensions to eparam. The original +eparam supported only single keystroke editing commands. The new colon +commands are used to enter command lines of arbitrary length to be processed +by eparam. +.PP +A colon command is entered by typing the colon character (`\fL:\fR') while +the cursor is positioned to the starting column of any value field of the +parameter set being edited. The colon character is not recognized as a +special character beyond column one, e.g., when entering the string value +of a parameter. When colon command mode is entered, the colon character +will be echoed at the start of the bottom line on the screen, and the cursor +will move to the character following the colon, waiting for the command to +be entered. The command is read in raw mode, but the usual delete, +, , etc. sequences are recognized. +.PP +The following eparam colon commands are currently supported. All commands +are carefully error checked before being executed to avoid having eparam +abort with a stack trace. An illegal operation causes colon command entry +mode to be exited, leaving an error message on the command entry line. +All commands which cause editing of the current pset to terminate may include +the \fL!\fR character to avoid updating the current pset before reading in +the new one or exiting eparam. The default is to update the current pset. +In all cases, \fIpset\fR may be either the name of a task or the name of a +parameter file. Parameter files are always indicated by a \fL.par\fR +extension, even though the actual file may be a \fL.cl\fR file: +only \fL.par\fR files will be written, although either type of file may be read. +.sp +.RS +.IP \fB:e\fR[\fL!\fR]\ [\fIpset\fR] +.br +Edit a new pset. If \fIpset\fR is omitted and the cursor was positioned to +a pset parameter when the colon command was entered then eparam descends into +the referenced pset; when editing of the sub-pset is complete eparam returns +to editing the higher level pset at the point at which the ``\fL:e\fR'' +command was entered. If a pset is named the editor context is switched to +the new pset, updating the current pset first unless the ``\fL:e!\fR'' command +was given. +.sp +.IP \fB:q\fR[\fL!\fR] +.br +Exit eparam for the current pset; equivalent to a . The variant +``\fL:q!\fR'' causes eparam to be exited without updating the current pset. +Entering this command when editing a sub-pset causes an exit to the higher +level pset. To abort eparam entirely without updating anything, +should be used. +.sp +.IP \fB:r\fR[\fL!\fR]\ [\fIpset\fR] +.br +Read in a new pset. If the command is ``\fL:r\fR'', an error message is +printed. If the command is ``\fL:r!\fR'' the pset currently being edited +is reread, cancelling any modifications made since the last update. +If a pset is specified the contents of the named pset are merged into the +current pset, i.e., the named pset is loaded into the current pset, +overwriting the contents of the current pset. +The command ``\fL:r pfile.par\fR'' is commonly used to load a pset formerly +saved in a user file with ``\fL:w pfile.par\fR'' into the UPARM version of +the parameter set for a task. +.sp +.IP \fB:w\fR[\fL!\fR]\ [\fIpset\fR] +.br +Write or update a pset. If \fIpset\fR is omitted the pset currently being +edited is updated on disk. If \fIpset\fR is given it should normally be the +name of a parameter file to be written. If the file exists an error message +will be printed unless the command ``\fL:w! pfile.par\fR'' is given to force +the file to be overwritten. +.sp +.IP \fB:g\fR[\fBo\fR][\fL!\fR] +.br +Run the task. Eparam exits, updating the pset and running the task whose pset +was being edited. This is implemented by pushing a command back into the input +stream of the task which called eparam, hence if eparam was called in a script +or with other commands on the same line, execution may be delayed until these +other commands have been edited. The feature works as expected when used +interactively. Since the run command is pushed back into the command input +stream it will appear in the history record and in any log files. +.RE + +.LP +To get out of colon command mode without doing anything, simply type delete +until the colon prompt is deleted and the cursor returns to the parameter +it was positioned to when colon command entry mode was entered. + +.NH 2 +New Task Dparam +.PP +A new builtin task \fIdparam\fR (dump-parmeters) has been added to the +\fIlanguage\fR package. This task is similar to \fIlparam\fR except that the +output is formatted in a way which is more convenient for use in scripts +or as input a program, whereas \fIlparam\fR output is intended more for the +user. The \fIdparam\fR task dumps the parameters for the named psets, +one parameter per line, in the format \fItask.param\ =\ value\fR. Nothing +is abbreviated or truncated. The value string will be absent if the value +of the parameter is undefined. Array valued parameters are not supported. + +.NH +Pfile Access Semantics +.PP +The code which reads and writes parameter files had to be almost completely +rewritten to accomodate the above features. In the process several other +improvements were made. +.IP \(bu +The old "Warning: pfile X is out of date" message will no longer be seen. +If the package pfile is newer than the user copy of the pfile, the package +pfile will be read and the parameter values from the old user pfile will +be merged into the new pfile. This preserves the learned parameter values +but allows the master pfile to change, e.g., new fields can be added, old +fields deleted, or the names of parameters may be changed. If an old parameter +cannot be found in the new pfile the old value is simply discarded. +.IP \(bu +Zero length \fLUPARM\fR pfiles are now detected, causing the package pfile +to silently be read. +.IP \(bu +A bug was fixed which would sometimes cause \fIunlearn\fR to fail. +.IP \(bu +The low level CL procedure which reads a pfile will look for a \fL.par\fR +file followed by a \fL.cl\fR file with the same root name, allowing either +type of pfile to be used virtually anywhere. + +.NH +Showtype Option in Package Menus +.PP +A new boolean parameter \fLshowtype\fR has been added to the set of global +CL parameters. If this option is enabled the special tasks will be flagged +in package menus by appending a character to the end of the taskname. +Currently, two types of special tasks are recognized thusly: package script +tasks are marked with a trailing `\fL.\fR', and pset-tasks are marked with +a trailing `\fL@\fR'. The default value of this switch is currently \fLno\fR +for compatibility with previous versions of the CL. +.PP +In order for the \fIshowtype\fR option to work properly for package script +tasks, the CL must be informed that the script will define a new package +when executed. This was done by extending the syntax recognized by the +\fItask\fR statement to permit a \fL.pkg\fR extension on the taskname. +For example, \fLtask plot.pkg = "plot$plot.cl"\fR defines the new +package-task \fIplot\fR. The \fL.pkg\fR is optional and it is harmless if +it is omitted, but the \fIshowtype\fR option will not work properly without it. diff --git a/doc/rev1.ms b/doc/rev1.ms new file mode 100644 index 00000000..3a50c276 --- /dev/null +++ b/doc/rev1.ms @@ -0,0 +1,305 @@ +.TL +Summary of Revisions in Version 1.2 of IRAF +.AU +Doug Tody +IRAF Group +. + +1. Scope of Revisions + +2. CL Modifications + 2.1. Process Cache + 2.2. Background Jobs + 2.3. I/O Redirection + 2.4. OS Escapes + 2.5. Timing Tasks + 2.6. Package Loading and Logout + 2.7. The Null File, Standard Streams + 2.8. CL Main + +3. C Runtime Library + 3.1. Purpose + 3.2. Procedure Naming Convention + 3.3. Include Files + 3.4. UNIX Emulation + 3.5. System Calls + +4. Program Interface + 4.1. Process Control Facilities + 4.2. Environment Facilities + 4.3. Error Recovery + 4.4. File I/O Modifications + 4.5. Formatted I/O Modifications + 4.6. Bit and Byte Primitives + 4.7. Vector Operators + +5. Kernel Modifications + +6. Math Library + 6.1. Curve fitting package + 6.2. Surface fitting package + 6.3. Image interpolation package + 6.4. Slatec + 6.5. ACM Algorithms + +7. Applications Packages + 7.1 Dataio + 7.1.1. rdumpf + 7.2.2. rrcopy + 7.2.3. ridsfile + 7.2.4. ridsout + 7.2.5. ridsmtn + 7.1. Images + 7.2. Imred + 7.2.1. Echelle + 7.2.2. Cryomap + 7.2.3. Generic + 7.3. Onedspec + 7.4. Twodspec + 7.4.1. Multispec + 7.4.2. Longslit + + + + + +1. CL Modifications + + A new version of the system has been released on all three 4.2 BSD UNIX +vaxes at NOAO. The system has undergone major revisions, primarily to +remove UNIX dependencies in preparation for the port to VMS. A number +of enhancements have also been made in the process. Those modifications +or extensions of most interest to the user are summarized below. + +1.1 Process Cache: + + The process cache is the key to good interactive response. While the +operation of the process cache is completely automated and need not be +understood, the sophisticated user can obtain improved interactive response +by tuning the cache. + + prcache show what is in the cache + prcache task [,task] lock a task in the cache + flprcache flush cache (except locked tasks) + flprcache task [,task] unlock a task and remove from cache + +Where "task" is the name of a logical task, e.g. "directory". +When task A is present (locked) in the cache all tasks present in +the same physical process as task A are also cached (locked). +If one locks too many processes in the cache deadlock will occur. +Flushing a task from the cache initializes the process and may +fix certain classes of bugs. + +The process cache is no longer flushed when the current directory +is changed, when the environment changes (except when a +redefinition is uncovered by a bye), or when a task aborts. + + +1.2 Background Jobs: + + Background jobs are submitted by appending & to the command line, +as has always been the case. There is a limit on the number of +bkg jobs that can be running at any one time (currently 4). + + cmd & run command "cmd" in the background + jobs show status of background jobs + service service a query from the last bkg job + submitted + service N service a query from job N + kill N [,M,...] kill job number N + +A bkg job needing service (waiting for parameter input) will +timeout and abort after a set period of time (currently 3 hours). + + +1.3 I/O Redirection: + + Is now compatible with the cshell, e.g., >& to redirect both the +standard output and the standard error output, ditto |& and >>&. +The standard error output of an OS escape issued from a script +task or subprocess is now redirected properly, hence output from +XC and MAKE may be spooled. + + +1.4 OS Escapes: + + !command Now sends "command" to the shell defined by the UNIX + environment variable SHELL or to /bin/sh if SHELL is + not found. The cshell user can therefore now issue + + ! cmd >& spool & + + from within the CL. + + !!command Always sends the command to the Bourne shell (/bin/sh). + + +1.5 Timing Tasks + + The cpu and clock time consumed by a compiled task may now be +measured by prefixing the task name with a $, e.g.: + + set | $sort | $match tty | $count + +The times given are measured by the IRAF Main and hence do not +include the overhead of process initiation if it occurs. This +feature is currently only available for external compiled tasks. +It is not currently available for script tasks, intrinsic +functions, or builtin tasks. + + +1.6 Package Loading and Logout + + The original package loading protocol has returned without the +drawbacks of the original. When you type the name of a package +the package will become the "current package" (first package +searched when looking for a task), the prompt will change to +reflect the new current package, and a "bye" will be necessary +to return to the package. It is no longer necessary to issue +a whole series of "bye" commands to log out of the CL, just +type "logout". + + packages name the packages currently loaded + ?? print menus for all loaded packages + ?sys print menu for (e.g.) package 'sys' + +A package is "loaded" by typing its name, making the tasks +therein known to the CL. Any number of packages may be +simultaneously loaded and referenced without continually +changing the "current package". + +Programmers: use the new "clbye" in package script tasks in +place of "cl" if the "cl" is the last command in the file, +i.e., if there is no epilogue. This saves a file descriptor. +The function of "clbye" is otherwise completely identical to +that of "cl". + + +1.7 The Null File, Standard Streams + + IRAF now has a null file, known as "dev$null". This is useful +for discarding the output of commands. The null file may be +referenced anywhere an IRAF filename may be used. The special +files "STDIN", "STDOUT", and "STDERR" are also quite useful. +These reference the standard i/o streams of the task in which +they are found but may be used wherever an ordinary filename +would be used, including in compiled programs. + + + +System Software +.PP +A great deal of work was done on the core system software of IRAF (the virtual +operating system) to make concurrent operation of a single IRAF system on +UNIX, VMS, and other operating systems a reality. It is not possible to +report on this in any detail without getting technical, hence a detailed +summary of the work is given as an appendix. +.PP +The highest level system software modifications involved changes in the +\fBsystem\fR package to reflect minor changes in file i/o caused by +implementation of the new kernel, and major changes to the command language (CL) +to remove UNIX dependencies. The latter conversion involved the design and +implementation of a runtime C language library which includes a complete +emulation of the UNIX/C standard i/o package in terms of IRAF i/o, as well +as a C language callable interface to the IRAF virtual operating system. +.PP +Major modifications and extensions to the file i/o interface (FIO) were +required to make use of the new kernel and to support new software which +will be developed this fall. Most notably a machine independent, table driven +filename mapping capability was implemented to provide a consistent file naming +syntax on both UNIX and VMS. +.PP +Process control facilities were added to the virtual operating system and +included in the C library for use by the CL. A portable environment table +facility was implemented which is fully integrated with the file i/o and +process control faciltities, as well as interfaced to the C library. +Some real progress was made on interfacing the NCAR GKS graphics software +to IRAF, leading to production of sample plots on the graphics terminal +(via an intermediate metacode file) by the end of the quarter. Most of the +research and preliminary design required for the IRAF database facilities +was carried out during the quarter. +.PP +Additional system software projects not required for the VMS port but desirable +for the fall pre-release of IRAF included modification of the \fBhelp\fR +facilities to permit precompilation of the help database, greatly improving the +interactive response, modifications to the TTY interface to permit +precompilation of terminal device tables, also as an efficiency enhancement, +and miscellaneous modifications and extensions to the programmer level +interfaces since we will soon have more people using the system and it will +therefore be that much harder to modify. + +Virtual Operating System +.PP +Much work was done on the IRAF virtual operating system (kernel and i/o +packages) during this quarter to make routine concurrent operation of +a single IRAF system on UNIX, VMS, and other operating systems a reality. +Achieving this required not only implementation of equivalent kernels for +UNIX and VMS but also removal of the remaining UNIX dependencies from +the UNIX based IRAF development system. +.NH 4 +UNIX and VMS Kernels +.PP +The 4.1BSD UNIX IRAF kernel was completed during the last quarter. The VMS +kernel, built according to the same specifications as the (revised) UNIX +kernel, was received from STScI in mid-September. +.NH 4 +File I/O (FIO) +.PP +A general machine independent, table driven filename mapping capability was +added to FIO to permit use of IRAF virtual filenames on a range of systems. +Achieving this was essential because filenames and directory references +are used extensively in source files in the system (and if they are machine +dependent the code is not portable). Filename mapping will also help give +us a consistent user interface on all systems. Implementation of filename +mapping was complicated by the lack of file locking on some of our target +systems. +.PP +In addition to modifying FIO to use the new kernel, the following capabilities +were added to FIO for the October release of the system: +.RS +.IP \(bu +Raw i/o to terminals. Required for highly interactive programs (e.g. the +simple editor) and for cursor readback from the graphics terminal. +.IP \(bu +Recursive pushback. Required for macro expansion in CL2 and the new SPP +compiler, and by the C runtime library LIBC (the C runtime library is +discussed below). +.IP \(bu +Temporary redirection of a open stream to a disk file. Required to implement +i/o redirection in the IRAF Main, providing more efficient pipes between tasks. +.IP \(bu +Automatic deletion of subfiles when the main file is deleted. This permits +use of the standard file delete command to delete imagefiles and database +files as well as ordinary files. +.IP \(bu +Limited support for multiple file versions as in VMS. +.IP \(bu +Addition of a driver for the "null file" device. +.RE +.NH 4 +Process Control +.PP +Formerly, since only the command language (CL) required process control, all +process control was provided by accessing the UNIX system calls directly. +This saved us some time early in the project, but the VMS port required that +the virtual OS be expanded to include process control facilities. +The high level IRAF process control facilities for both connected and +detached processes have been defined, implemented, and tested. +Included are mechanisms for passing the environment list and current working +directory to a subprocess when it is spawned, record oriented binary +interprocess communication facilities, automatic subprocess shutdown +during error recovery, and multiplexing of the i/o streams of both parent +and child processes (i.e., access by the child to a terminal opened by the +parent process). +.NH 4 +Environment Facilities +.PP +The UNIX environment (logical name) facilities have been replaced in IRAF +by a similar capability implemented entirely above the system interface +(i.e., it is portable). In addition to being portable, the new facilities +are superior to those provided by UNIX since the environment name table is +hashed (access is more efficient), entries may be deleted, the table is +automatically passed to a child process at process creation time, and updating +of the table in a child process is supported without respawning the process. +.NH 4 + diff --git a/doc/rev2.txt b/doc/rev2.txt new file mode 100644 index 00000000..1feda120 --- /dev/null +++ b/doc/rev2.txt @@ -0,0 +1,7524 @@ + +------------ +From: /usr/tody/ Thu 18:35:41 29-Dec-83 +Package: system +Title: software release notices (revisions) + +Task 'revisions' added to the system package. Please use to record all +revisions and modifications to a released package. It is not necessary +to record revisions to a package which is still under development and has +not yet been released. + +Usage is very similar to 'bugmail'. Type 'rev' to read all revision notices +added since your last 'rev'. Type 'rev package_name' to add a revision notice +for the named package. Note that '~e' can be typed while entering a revision +notice to edit the text that has been entered, just as '~v' is used in the UNIX +mail utility. + +------------ +From: /usr/tody/ Thu 18:41:47 29-Dec-83 +Package: cl +Title: config change + +Stack size increased from 1000 to 4000. Note that scripts are compiled onto +the stack, hence lots of stack space is needed to run large, nested scripts. +If you see a message something like "pc exceeds topcs", that means that the +control stack has overflowed; report it with bugmail system. + +------------ +From: /usr/tody/ Thu 19:14:32 29-Dec-83 +Package: system +Title: tail + +The task 'tail' has been modified to permit negative 'nlines'. If nlines is +positive (default), the last nlines lines of the file are printed. If nlines +is negative, the first nlines lines are skipped, then the remainder of the +file is printed. + +------------ +From: /usr/tody/ Mon 16:33:01 02-Jan-84 +Package: softools +Title: syntax bug in spp fixed + +The SPP would not recognize BEGIN and END statements unless they were +all alone on a line, i.e., comments were not permitted on the same line. +Edited lexical definition of XPP (xpp.l) and remade XPP. + +------------ +From: /usr/tody/ Mon 19:06:20 02-Jan-84 +Package: system +Title: full sysgen + +I did a full sysgen of the system today; the system libraries, the CL, +the SPP compiler, and the SYSTEM package were all recompiled. The value +of SZ_FNAME has been increased from 33 to 63, the value of SZ_PATHNAME +from 81 to 127. Several minor bugs were discovered in the process +(some of this stuff has not been recompiled for months and months). + +------------ +From: /usr/tody/ Mon 19:09:48 02-Jan-84 +Package: system +Title: system errors + +The system error handling code has been extensively revised. The error code +is now stored in the system error message file (lib$syserrmsg) on the same +line as the message. For example, + + 572 Out of memory + +whereas before we had + + Out of memory + +and where the error code is defined in as + + define SYS_MFULL 572 + +This increases the reliability of message fetch significantly, and makes +it easy to leave lots of space for new messages, and to add new messages. + +A companion routine to "SYSERR (errcode)" was also added. The new routine +"SYSERRS (errcode, string)" looks up the error message string in the +system error message file and concatenates the user supplied string, +producing an error message of the form "errmsg (string)". The FILERR +routine is similar but I have never felt that it should be used outside +the FIO package, and I have replaced all non file i/o references to FILERR +with calls to SYSERRS. Additional routines, i.e., SYSERRI, may be added +in the future if needed. + +Any changes to the error codes in require a full sysgen, which +is why I waited until now to make this revision. + +------------ +From: /usr/valdes/iraf/ Thu 10:17:56 05-Jan-84 +Package: xtools +Title: Bug fix in ranges + +The routine decode_ranges in ranges.x had a bug which did not allow proper +decoding. This bug has been fixed. If any further problems are noted +please check with me. The old version of ranges has been (temporarily) +saved as ranges.old.x. + +------------ +From: /usr/valdes/iraf/ Fri 11:06:02 06-Jan-84 +Package: xtools +Title: Bug fix in ranges + +decode_ranges +Additional info about bug fix in procedure decode_ranges in file ranges.x. + +The old version had incorrect braces. It turned everything into +a range. Thus, "1, 4, 7" became "1 - 4, 7 - MAXINT" +It also did not skip arbitrary delimiters after a '-'. Thus, "1 -, 8" +would be wrong. + +Old version: + # Get last limit of current range. + # Skip delimiters + while (IS_WHITE(str[ip]) || str[ip] == ',') + ip = ip + 1 + if (str[ip] == '-') { + ip = ip + 1 + if (ctoi (str, ip, last) == 0) + last = MAX_INT +---> } else if (IS_DIGIT(str[ip])) { # ,-n, + if (ctoi (str, ip, last) == 0) # can't happen + return (ERR) + } else + last = first + +The new version recognizes all the following cases: +"1, 3 5" = 1, 3, and 5 +"- 6" = 1 through 6 +"-" = 1 through MAX_INT +"1 ,, -, 7 , 9 -" = 1 through 7 and 9 through MAX_INT. +"1 - END" = 1 through MAX_INT + +The most useful form is "-" to denote all values. + +New version: + + # Get last limit of current range. + # Skip delimiters + while (IS_WHITE(str[ip]) || str[ip] == ',') + ip = ip + 1 + if (str[ip] == '-') { +---> while (IS_WHITE(str[ip]) || str[ip] == ',' || str[ip] == '-') + ip = ip + 1 + if (str[ip] == EOS) + last = MAX_INT +---> else if (IS_DIGIT(str[ip])) { + if (ctoi (str, ip, last) == 0) +---> last = MAX_INT +---> } else +---> return (ERR) + } else + last = first + +------------ +From: /usr/tody/ Fri 17:43:07 06-Jan-84 +Package: cl +Title: logout procedure + +The system logout script no longer attempts to delete the graphics +descriptor files if they do not exist, avoiding the warning message issued +by delete in verify mode. + +------------ +From: /usr/tody/ Fri 18:37:48 06-Jan-84 +Package: system +Title: new software development tools + +The softools package is now available. Currently, the package contains only +two programs, MAKE and XCOMPILE. Make talks directly to the UNIX make, +sending zero, one, or two arguments on to the UNIX make without modification. +This version of make will someday be replaced by a completely IRAF version. + +XCOMPILE is more sophisticated, attempting to provide a machine independent +compiler function at the CL level. Usage is as follows: + + xcompile (files) + +The following hidden parameters are provided: + + files = file1,file2 list of files to be compiled or linked + (xcompiler = xxc) name of OS compiler program + (output_file = first) name of executable output file + (optimize = yes) run the object code optimizer +(compile_only = no) produce only object modules + (fortran = no) keep fortran source + (libraries = none) list of user libraries to be referenced + (osflags = none) OS compiler flags + (debug = no) print but do not execute OS command + (verbose = no) print OS command for verification + (fname = ) + (syscmd = xxc -F -O file1 file2 -ldeboor -lxtools) + (file_list = /usr/irafx/tmp/xcr027809) + (mode = ql) + +Usage is straightforward and should be obvious to the experienced CL user, +given the above param declarations. There is one restriction; if a file +template is used, it should reference only files in the current directory. +Files in other directories should be referenced only by an OS pathname. +Libraries are referenced as a simple quoted list, i.e., + + xc file.x, lib='deboor,xtools' + +Special OS compiler flags may be passed via the osflags parameter, as in + + xc "file1,file2", os = '-S' + +If no output file is named and linking is to occur, the name of the process +file is taken from the name of the first file referenced by the files template. + +------------ +From: /usr/tody/ Sat 12:45:03 07-Jan-84 +Package: system +Title: 'bad mode spec' bug fixed + +I finally tracked down the bug that was causing the 'bad mode spec' +warning message on exit from a package. After a lengthy and abstruse +examination of the CL code, guess what it turned out to be -- the mode +parameter in the parameter file was actually bad!! The moral of the story +is, try not to overlook the obvious when tracking down a bug. Mode params +are treated a bit differently than other params by the CL, and I was assuming +that there was a bug having to do with that difference. + +------------ +From: /usr/tody/ Wed 09:19:51 11-Jan-84 +Package: system +Title: stdimage modified + +The device "iis70" has been renamed "iism70" throughout the system. +In particular, the environment definition stdimage has been changed to iism70. + +------------ +From: /usr/tody/ Wed 09:38:22 11-Jan-84 +Package: system +Title: magtape deallocation at logout time + +Bug fix; the device was being deallocated within IRAF but not within +UNIX, when automatically deallocated at logout time. Replaced task +"_mtdeallocate" by "deallocate" in lib$cllogout.cl. + +------------ +From: /usr/tody/ Wed 22:00:17 11-Jan-84 +Package: imio +Title: imdelete added + +The "imdelete(imagefile)" procedure has been added to the IMIO interface. +Use this to delete imagefiles, rather than "delete(imagefile)", which +currently leaves headerless pixel storage files lying about. + +------------ +From: /usr/valdes/iraf/ Fri 10:49:39 20-Jan-84 +Package: xtools +Title: New ranges + +The range parsing procedures have been rewritten, improved, and documented. +The main change is that the syntax allows both ranges and steps. Thus, +to select every third number in the range 1 to 15 the range string is +1-15x3 or -15x3. The documentation is in the source text and also +in the subdirectory doc. In addition to the original procedures-- +decode_range and get_next_number -- a new procedure -- is_in_range -- +returns a boolean value for whether the specified number is in the +range array. + +------------ +From: /usr/tody/ Wed 18:13:02 25-Jan-84 +Package: system +Title: llsq library + +Lawson's and Hanson's linear least squares routines have been compiled and +installed in the system library as the library "llsq". Reference the library +on the xcompile command line as "lib=llsq". See me for documentation. +Minor modifications to the software were necessary to remove i/o, and the +only record of the modifications is in the book describing the routines. + +------------ +From: /usr/tody/ Thu 13:53:38 26-Jan-84 +Package: system +Title: exception handlers + +The call given for a user exception handler in the crib sheet was in error +and has been fixed. A handler should return the entry point address of the +next handler to be executed, or the magic value X_IGNORE, as the second +argument rather than as the function value. The correct call is thus + + procedure user_exception_handler (exception, next_handler) + + begin + (handle exception) + next_handler = (old_handler or X_IGNORE) + end + +This is posted with a call of the form shown below. The value of +"old_handler" must be passed to the user handler to be returned as shown +above when the exception is handled. + + call xwhen (exception, user_exception_handler, old_handler) + +In general, handlers should be chained by saving the old_handler address +and passing it back to the system in each handler. This is the only way +that all handlers can be called when an exception occurs. + + In addition to the error in the crib sheet, there was a bug in ZXWHEN +which prevented chaining; this has been fixed and a new sysgen performed. + +------------ +From: /usr/tody/ Thu 14:24:08 26-Jan-84 +Package: imio +Title: bug in immap fixed + +The variable "mode" (the file access mode) was being used in place of +"acmode" (the image access mode) in several places, preventing special +image access mode NEW_COPY from being recognized. Sections of the code +for new copy images were therefore unreachable. Mode was changed to acmode +in several places, but the code has not yet been tested in NEW_COPY mode. + +------------ +From: /usr/tody/ Sun 12:58:32 29-Jan-84 +Package: fio,system +Title: file deletion + +It is now an error to attempt to delete a nonexistent file (previously, +such an attempt was silently ignored). + +------------ +From: /usr/tody/ Mon 11:14:00 30-Jan-84 +Package: system +Title: bug in errcode() + +The old errcode() procedure would return status OK if an error condition +was not actually in effect, making it unusable in error handlers. +Errcode now returns the integer error code of the last error posted. +Whenever an IFERR block is entered, the error code is cleared, i.e., +set to OK. The system error codes are defined in . + +------------ +From: /usr/tody/ Mon 20:58:46 30-Jan-84 +Package: system,clio,softools +Title: bug in "xcompile" + +Several mods were made to fix a bug in xcompile. The bug was caused by +"files", called by xcompile to expand the list of files to be compiled or +linked. Files would always sort the file list; this was improper since +the first file has a special significance (it provides the default root +name of the output executable file). Revs: + + (1) FILES and PATHNAMES were modified by the addition of the hidden + parameter "sort", type boolean, default value "yes". + + (2) CLIO was modified by the addition of the procedure CLPOPNU (open + list unsorted) to the usual CLPOPN[IS]. + + (3) XCOMPILE no longer sorts either the files list or the libraries + list. + +------------ +From: /usr/tody/ Tue 22:19:50 31-Jan-84 +Package: system +Title: error recovery: file cleanup + +The file cleanup routine, called during error recovery, did not know the +difference between a "string" (sprintf or stropen) file and a normal file. +When error recovery occurred while a string was opened as a file, the +message "No write permission on file (StringFile)" would be given, misleading +one as to the the cause of the error. Fio$fio_cleanup.x was modified so +that it merely closes a string file, rather than trying to flush the output, +close, and sometimes delete the file. + +------------ +From: /usr/tody/ Fri 19:42:28 03-Feb-84 +Package: fio +Title: byte-oriented i/o + +The following procedures have been added to the FIO interface: + + areadb (fd, buffer, maxbytes, byte_offset) + awriteb (fd, buffer, nbytes, byte_offset) + nbytes = awaitb (fd) + +The old AREAD, AWRITE, and AWAIT are still available, are unchanged, and should +continue to be used for programs which can work in units of chars. The new +routines are identical except that they are byte-oriented, like the device +z-routines. Using these routines, byte-oriented asynchronous block i/o can +now be done in a device independent manner (i.e., as opposed to calling the +z-routines directly), with full error checking. + +------------ +From: /usr/tody/ Sun 12:06:41 05-Feb-84 +Package: system, tty +Title: New TTY package installed + +A completely new version of the TTY package has been installed, supplanting +the old interface. The new version interfaces directly to the UNIX termcap +file, which will be exported with IRAF. The termcap file concisely describes +the characteristics of many terminals, and is in wide use. This interface +change is not upward compatible; all programs which used the old TTY +interface must be modified. + +The system is configured for a system defined default terminal when you log +onto the CL (i.e., the VT100 on our systems). Default values are provided for +the following variables in the CL environment: + + terminal termcap name of terminal in use (i.e., vt100) + ttybaud baud rate for the terminal (9600) + ttynlines number of lines on the screen (24) + ttyncols number of chars per line (80) + termcap filename of termcap file (dev$termcap) + printer termcap name of default printer (i.e., imagen) + +PAGE, CLEAR, LPRINT, DELETE, etc. all use the new device independent TTY +interface. All programs which print tabular data on the terminal, i.e., ?, +lparam, etc. in the CL, use the environment variable ttyncols to format +the table. The line printer facilities are described in a separate revision +notice. + +If you are using a terminal other than the system default, system.stty +should be used to select the terminal. The command + + stty tek4012 + +for example, would change the values of the TTY environment variables +as required for the Tektronix 4012 series terminals. The command +"stty baud=1200" would tell the system that the baud rate is 1200, +for example when working over a modem (the system must know the baud +rate to be able to generate delays). STTY without any arguments prints +the terminal status. + +The TTY interface is described in tty$TTY.hlp, where tty="sys$tty/". + +------------ +From: /usr/tody/ Sun 12:36:20 05-Feb-84 +Package: system +Title: line printer interface + +The LPRINT task is now installed. LPRINT provides a device independent +line-printer interface. + +usage: + lprint (files) + +params: + files = *.x list of files to be printed + (device = printer) name of output device + (map_cc = yes) make unknown control chars printable + (header = yes) enable printing of header on each page + (mode = ql) + +examples: + program | lprint # direct output of program to printer + lprint "*.x,*.cl" # make package source listing + +If called with a file list, Lprint by default prints each file starting +on a new page and breaks pages, putting a one-line header at the top of +each page (like the UNIX pr). If used in a pipe, Lprint copies lines +of text to the printer, but does not break pages or print headers. Escape +sequences are still mapped, however. Page breaks and headers may be +disabled with the hidden parameter lprint.header. + +The following control characters have a special significance in text input +to Lprint (also to TYPE): + + FF=formfeed advance to new page + SO= begin standout mode + SI= end standout mode + +The TTY interface is used to translate such directives as required for the +device. Programs like HELP, MANPAGE, and LROFF insert these three directives +into output text to break pages and embolden text in a device independent +fashion. TTY is also used to determine whether tabs must be expanded, to +define the number of lines per printer page, the number of chars per line +(long lines are broken), and so on. + +The parameter lprint.device determines the printer device to be used. If +the value is the string "printer", the system defined default printer device +is used (defined in the environment). Some other printer may be explicitly +named if desired. For a printer to be accessible, there must be a termcap entry +for the device, and the device must be installed in the ZOPNLP printer device +table. The devices currently installed are "imagen" and "versatec". Output +for both devices is currently spooled and printed asynchronously. + +Low level interface routines installed in this release include the line +printer z-routines (os$zfiolp.c), and the device FIO open procedure LPOPEN, +source in "sys$system/lpopen.x". + +------------ +From: /usr/tody/ Sun 13:02:54 05-Feb-84 +Package: fio +Title: bug fixes + +The following bugs|restrictions were found and fixed in the process of +installing and testing the new TTY interface and LPRINT program: + + (1) If a binary file is opened in APPEND mode, and the file does + not exist, one will be created and opened for WRITE_ONLY access. + Previously, the file had to exist be be opened for appending. + This bug did not pertain to text files, which have a different + interface. + + (2) AREADB/AWRITEB: if file is a streaming (sequential only) file, + the offset parameter passed to the z-routine is now guaranteed + to be zero. The old routines were passing the offset argument + from FIO (which is nonzero) on the z-routine unchanged, and the + z-routine would perform an illegal seek (ignored on a streaming + device, but would cause a write error for the printer). + +------------ +From: /usr/tody/ Thu 19:35:24 09-Feb-84 +Package: os +Title: debug routine added to memory allocator + +A routine ZMEMCK has been added to the OS package to aid in debugging +programs which use dynamic memory. The operation of ZMEMCK is highly +system dependent. In the current implementation, the UNIX memory allocator +keeps a list of memory regions (malloc'ed buffers and other areas). +ZMEMCK traverses the list and prints the address and size in bytes (both +in octal) of each region, and tells whether or not the region is "busy" +(in use) or not. Only regions which have been released with "mfree" +will show up as not busy. If memory is corrupted, the list will be +trashed near the area of memory where the buffer overflow or underflow +occurred. SALLOC stack segments show up in the list as regions with +a length of 4004 (octal) bytes. + +------------ +From: /usr/tody/ Sun 20:33:43 12-Feb-84 +Package: system,memio,os +Title: bug fixes: malloc,realloc + +The MALLOC and REALLOC routines were checking for an ERR return, +while the OS routine ZMALOC and ZRALOC were returning the NULL pointer in +the event of an error. I added a third argument "status" to each z-routine, +returning OK or ERR, and changed malloc and realloc to properly check +the status parameter. + +------------ +From: /usr/tody/ Mon 13:17:56 13-Feb-84 +Package: fio +Title: asynchronous i/o + +Awrite/await bug: file size was being incremented by await when called after +a write. Ok, but the FIO buffer offset was being used by await to determine +the final offset as boffset+nbytes_written. This meant that FIO could not +keep track of the file size when writing a file using only awrite/await. + +I moved the updating of the file size into awrite, deleting it from await. +This is ok since it is an error if fewer bytes are written than requested. +A couple new test programs can be found in debug$afio.x. + +------------ +From: /usr/tody/ Tue 09:52:36 14-Feb-84 +Package: cl +Title: radix intrinsic function + +RADIX has been changed to format the operand as an unsigned integer for +non decimal output bases. Thus, "radix(-1,10)" produces "-1" as output, +whereas "radix(-1,8)" produces something like "37777777777". + +------------ +From: /usr/tody/ Wed 15:48:27 15-Feb-84 +Package: fio +Title: stropen bug fix + +Stropen had a bug when opening a string with read access. There was a loop +in the routine which searched for the EOS; the loop was infinite because +the input pointer was not being bumped. Fixed and did a new sysgen. + +------------ +From: /usr/tody/ Thu 16:28:44 16-Feb-84 +Package: softools +Title: lroff utility installed + +A preliminary version of the lroff utility has been installed +in the Softools package. This version does not break pages and +print page headers, but it is useful nonetheless. This is the +new version of Lroff, including support for standout mode, and +numbered section headers. + +The Troff font change escapes \fB, \fI, and \fR are recognized in help text. +The .nh or .NH directive is used for numbered sections. Output must be +passed through type, page, or lprint to make the font changes +"visible". The control chars SO (control-N) and SI (control-O) may be +inserted in text to be processed by one of the above output programs to turn +standout mode on and off. Processing of control directives is under +control of the new TTY interface and is quite device independent. + +------------ +From: /usr/tody/ Fri 00:05:03 17-Feb-84 +Package: system +Title: lprint modified + +Several hidden params were added to lprint. By default, pages are broken +only if the standard input is not redirected, i.e., if one or named files +are to be printed. It is now possible to explicitly specify that pages +are to be broken or not broken. If reading from the standard input, +a file name label string may be given, else the file name will appear as +"STDIN". + +------------ +From: /usr/tody/ Tue 19:55:57 21-Feb-84 +Package: fmtio +Title: gctol, lexnum mods + +The following modifications were made to the FMTIO routines gctol and +lexnum: + + (1) GCTOL would only recognize the B and X suffixes (for octal and + hex numbers) if the suffix chars were in lower case. The procedure + now recognizes the suffixes in either case. + + (2) LEXNUM is a lexical analysis routine which figures out whether a + string is an IRAF number, and if so, what kind (octal, decimal, real, + etc). The calling sequence is "lexnum (numstr, ip, nchars)". + Formerly, the IP arg was input only. Lexnum was changed to always + advance IP over any leading whitespace, so that the routine can + be used to find the start of a token as well as decide whether or + not it is a number. + +------------ +From: /usr/tody/ Tue 20:03:01 21-Feb-84 +Package: softools +Title: YACC compiler compiler now available for SPP + +The Yacc compiler has been modified to produce parsers in the SPP language, +and is now installed in softools (this was done because the prototype image +calculator needs a parser, as will the database tools, etc.) This is a full +implementation, and an SPP parser can be every bit as sophisticated as a C +parser, with a parser token value stack of arbitrary structures, the usual +error recovery tools, and so on. In combination with the Lexnum lexical +analysis routine (used to build lexical analysers), it is straightforward +to build compilers for sophisticated applications programs. + +The standard Yacc documentation remains valid; a list of differences in the +SPP version are given in "softools$yacc/README". A complete working example +of an SPP/Yacc algebraic desk calculator is given in "yacc/debug/dc.y". +This example resembles that given in the Yacc reference manual. + +------------ +From: /usr/davis/ Wed 13:15:40 22-Feb-84 +Package: dataio +Title: mtexamine + +The task mtexamine has been installed in the dataio package. Documentation +can be found in mtexamine.hlp. + +------------ +From: /usr/davis/ Wed 13:24:33 22-Feb-84 +Package: dataio +Title: rfits, pdsread, rcamera + +A bug was found and fixed in the error handling code of rfits, pdsread +and rcamera. When an error occurred in reading a tape file the +routines returned control to the main program without closing the file +in which the error was encountered. Any attempt to process the next +tape file in the list resulted in a "doubly_opened magtape" error +and an abort. + +------------ +From: /usr/tody/ Sun 13:12:12 26-Feb-84 +Package: system +Title: hidden param added to type, page + +The hidden parameter "device", default value "terminal", has been added to +the parameter files for the TYPE and PAGE utilities. This parameter may be +used to specify that output be processed according to a termcap entry other +than that for the terminal. I also added a termcap entry for the pseudodevice +"text", which is a device with no capabilities at all (i.e., the capabilities +of the final device are unknown). This is useful for removing standout mode +escapes from Lroff output, producing a pure text file as output. When +producing output for a device which cannot overstrike, embolden, etc., TTY +renders standout mode as upper case. Thus, to remove the standout mode +escapes from Lroff output, saving the result in a text file which can be +printed on any device or system: + + lroff file | type device=text, > textfile + +------------ +From: /usr/tody/ Wed 22:26:43 29-Feb-84 +Package: system +Title: name of LOC function changed to ZLOC + +The names of the LOC and LOCC functions (OS pkg) have been changed to +ZLOC and ZLOCC, to eliminate a library conflict with the NCAR function LOC. +Hopefully all references in the sys and pkg directory systems have been +found and modified. As far as I know, these functions have only been used +in system code thus far, so I doubt if anyone's code will be affected. + +------------ +From: /usr/tody/ Fri 22:14:43 02-Mar-84 +Package: softools +Title: xcompile modification + +The XCOMPILE utility has been modified to permit compilation of Fortran +source files without checking for undeclared variables and functions. +The old version would complain about undeclared variables, and stop the +compilation, whether the source file was SPP or F77. Now the checking +is only done for SPP sources. + +------------ +From: /usr/tody/ Mon 17:41:11 05-Mar-84 +Package: memio +Title: bug discovered and fixed + +Woops.. I missed a few occurrences of the function LOC in MEMIO (recall the +recent name change to ZLOC). Did not cause any problems because the old +object module for LOC was still in the system library, and would get +linked in in any case. Fixed memio routines; will leave old loc in library +until I am sure all occurences of the old function have been changed. + +------------ +From: /usr/tody/ Mon 18:44:02 05-Mar-84 +Package: softools +Title: bug fix in XCOMPILE + +XCOMPILE had the following bug: if asked to compile a nonexistent file "file.x" +when there was a file "file.f" in the directory, it would proceed to add the +file "file.f" to its list of intermediate Fortran files to be deleted, and +then delete the user's Fortran source! The program has been modified to check +for the existence of files. If a file does not exist, a warning is issued, +and the file name is not added to any of the internal lists. + +------------ +From: /usr/tody/ Wed 18:58:58 07-Mar-84 +Package: system +Title: magtape allocation bug fix + +The allocate task has been smartened up to determine when the drive has +been allocated outside of IRAF. If the OS error message "mt? already +allocated to..." appears, the IRAF system will no longer think that it +has successfully allocated the drive. Related mods: rewinding has been +made an option under control of a hidden param to deallocate. The argument +"rewind_tape" has been added to the argument list of the "mtdeallocate" +procedure in MTIO, and a sysgen performed. + +------------ +From: /usr/tody/ Wed 21:16:28 07-Mar-84 +Package: system +Title: match speeded up + +The pattern matching utility 'match' was noticeably slow when searching large +files or lists of files. I have speeded it up some by treating searching for +an alphanumeric string as a special case. A new pattern matching utility, +STRSEARCH, calling sequence identical to STRMATCH and PATMATCH, has been +added to FMTIO for searching for substrings that do not use metacharacters. +MATCH examines the pattern you give it and automatically determines the +most efficient searching procedure to use. A new hidden param 'metacharacters', +default =yes, was added to permit disabling pattern matching metacharacters +entirely. + +Comparative timings of the three procedures, searching for a simple string +in a list of 5000 full length lines: + + strsearch 9.4 sec, cpu + strmatch 43.5 sec + patmatch 66.1 sec + +Real timings, searching for a simple string in a 3711 line Fortran program: + + old 'match' 20.5 sec, cpu + new 'match' 7.8 sec + unix 'grep' 4.3 sec + unix 'egrep' 2.8 sec + +Hmm... Looks like we still have a ways to go, but a significant improvement +nonetheless. + +------------ +From: /usr/tody/ Sun 17:28:25 11-Mar-84 +Package: system +Title: LPRINT no longer spools versatec output + +LPRINT has been modified to write directly to the versatec (like the UNIX +VPR), rather than writing a spool file and disposing of it to the printer +when closed. This is desirable for making listings, in which case it is +inefficient to spool the output. If spooling of versatec output is desired, +run LPRINT with device=lpr; this is the versatec with spooling. Note that +in IRAF, pipes are a spooling mechanism (because they are temp files), +so spooling with device lpr is generally not necessary. + +------------ +From: /usr/tody/ Tue 15:22:34 13-Mar-84 +Package: fio +Title: 'access' modified + +The behavior of 'access' for the null string and for the standard files +has been modified slightly. The behavior for ordinary files is unchanged. +The new behavior is as follows: + + yes/no = access (fname, mode, type) + +If fname is the null string or a string containing only whitespace, access +returns NO (the file is not accessible). If fname is one of STDIN, STDOUT, +etc., and the mode and type are given as zero, the function returns YES. +If the mode and type arguments are given and a standard stream is named, +the mode and type must agree with those given by FSTATI or the function will +return NO. Thus, "STDIN" always exists, is accessible with mode READ_ONLY, +is of type BINARY_FILE when a task is run from the CL, and TEXT_FILE when +run in debug mode. + +------------ +From: /usr/tody/ Wed 19:58:26 14-Mar-84 +Package: fio +Title: tempfiles + +Previously if a tempfile were opened with mode TEMP_FILE and deleted +explicitly before task termination, the system would print a warning +message when it found (during the file cleanup which occurs at task +termination time) that it could not delete the file. File "fio$fsvtfn.x" +was modified to silently ignore files in the tempfile list which do +not exist at fio cleanup time. + +------------ +From: /usr/tody/ Wed 20:44:30 14-Mar-84 +Package: clio +Title: clcmd now flushes STDOUT + +The clcmd procedure, used by system utilities to send commands to the +CL, was modified to flush the standard output before sending the command. + + +------------ +From: /usr/davis/ Thu 14:51:22 15-Mar-84 +Package: dataio +Title: rcardimage, wcardimage mods + +Rcardimage and wcardimage can now read and write EBCDIC cardimage tapes +as well as ASCII tapes. + +------------ +From: /usr/tody/ Thu 22:55:09 15-Mar-84 +Package: vops +Title: bug fix in acht_b.c, efficiency enhancement in achtb_.c. + +Fixed a bug in the ".. to unsigned byte" type conversion vector primitives. +The npix argument, used as a loop counter, is a pointer variable and the +pointer was being used as the loop counter rather than the array length, +causing the output array to be overrun. While I was at it, I also modified +achtb_ to put the loop counter in a register for greater efficiency. + +------------ +From: /usr/davis/ Fri 15:32:29 16-Mar-84 +Package: dataio +Title: task reblock + +The task reblock has been added to the dataio package. Reblock can be +used to copy tape or disk files, optionally changing the blocking factor, +padding blocks and/or records or changing the density in the case of a +tape file. See directory /usr/irafx/pkg/dataio/reblock for documentation. + +------------ +From: /usr/tody/ Fri 17:46:57 16-Mar-84 +Package: imio +Title: imunmap bug fix + +When unmapping a new image which had never been written into, IMUNMAP +would attempt to close the pixel storage file even though it had never +been written into. The close is no longer attempted unless the pixel +storage file is open. + +------------ +From: /usr/davis/ Mon 14:56:31 19-Mar-84 +Package: dataio +Title: rfits bugfix + +A bug in reading FITS files with long headers has been fixed. FITS +header parameters with unknown keywords were being added to the user +area of the IRAF image header. However insufficient space was being +allocated to accomodate the EOS on the character string and the +buffer would occasionally overflow. + +------------ +From: /usr/davis/ Mon 15:07:44 19-Mar-84 +Package: dataio +Title: rfits mods + +Rfits now applies bscale and bzero to the integers on tape. If no output +data type is specified rfits selects one based on the bits per pixel on +tape and bscale and bzero. Rfits now initializes the coordinate trans- +formation parameters. + +------------ +From: /usr/tody/ Tue 19:40:19 20-Mar-84 +Package: system +Title: eprintf now flushes the standard output + +A call to flush STDOUT has been added to EPRINTF, so that warning messages +will be synchronized with interactive output. Note that writing to STDERR, +however (i.e. with putline), does not flush STDOUT. + +------------ +From: /usr/tody/ Sat 11:14:54 24-Mar-84 +Package: fmtio +Title: lexnum did not recognize indefs + +The LEXNUM procedure, used to lexically analyse a string to determine +if it is a number, did not recognize the special number "INDEF". +It now returns the token LEX_REAL when given INDEF as input. This bug +was discovered when trying to read a list containing indefinites using +SCANR or SCAND. The scan routines (and GCTOD) will now interpret INDEF +as a legal number with the value INDEFR, INDEFD, etc. depending on the +datatype requested. + +------------ +From: /usr/tody/ Sat 21:08:47 24-Mar-84 +Package: fmtio +Title: printf was not autoscaling properly + +The printf routines, when presented with a number which will not fit within +the given field width, are supposed to automatically decrease the precision +until the number fits, and if that fails, print out the number anyway in a +larger field (as opposed to printing "******" which is silly in a language +with free format i/o). This was not working when printing reals, i.e., +"%10g" would result in ********** when printing a very large or very small +number, because a real in E format would not fit in a field width of 10 +using the default precision (7 digits). The bug has been fixed and a format +of %Ng should work without overflowing the field for any N >= 7. + +------------ +From: /usr/tody/ Sun 22:55:37 25-Mar-84 +Package: system +Title: package reorganization + +The ultimate decomposition of the IMAGES package into subpackages has not +yet been defined. As a first step, the following changes have been made: + + [1] The graphics utilities have been moved out of images into a new + system package called PLOT. + + [2] A new images subpackage called TV has been created to hold all + programs having to do with the image display. The package name + TV is reasonably descriptive and has an unambiguous abbreviation. + +The utilities in the TV package have been reworked somewhat to more closely +resemble their expected final form. Type "help tv" for a brief description +of the contents of the package. + +------------ +From: /usr/tody/ Sun 23:06:25 25-Mar-84 +Package: plot +Title: new package PLOT + +Testing of the new plotting utilities introduced last week has now been +completed, and the three utilities are fully up. Note that new parameters +have been added to CONTOUR and SURFACE to give more control over the plot +(floor and ceiling levels can be specified, the number of contours can be +specified, and so on). + +GRAPH can now overplot several curves (lists or image sections), compute +projections, draw dashed lines, log scale the axes, annotate plots, and lots +more. Manual pages for all these utilities will be available soon. + +------------ +From: /usr/tody/ Mon 00:08:33 26-Mar-84 +Package: plot +Title: handy-dandy routines for plotting lines and columns of images + +Versions of the ever popular Forth/Camera routines PROW, PROWS, PCOL, +and PCOLS have been added to the PLOT package. These are implemented +as scripts calling GRAPH. GRAPH itself should be called if you want +to do anything fancy. + +------------ +From: /usr/tody/ Mon 10:08:34 26-Mar-84 +Package: utilities +Title: utilities package online + +The UTILITIES package has been brought online. UCASE and LCASE were moved +from the LISTS package into utilities. We are in the process of adding +TRANSLIT, DETAB, ENTAB, PRECESS, and AIRMASS. + +------------ +From: /usr/davis/ Mon 17:10:45 26-Mar-84 +Package: dataio +Title: tasks txtbin, bintxt + +The tasks txtbin and bintxt have been added to the dataio package. +Bintxt converts binary files containing only text to text files +and txtbin does the inverse. + +------------ +From: /usr/tody/ Mon 23:20:16 26-Mar-84 +Package: softools +Title: new task MKMANPAGE + +A new utility MKMANPAGE is available in softools. Use as follows: + + mkman taskname + +This copies the manual page template into the new file "taskname.hlp", +leaving you in the editor ready to fill in the blanks. + +------------ +From: /usr/davis/ Tue 13:15:17 27-Mar-84 +Package: utilities +Title: task translit + +The task translit has been added to the utilities package. Translit can +be used to delete or replace characters in text file(s). Documentation +in translit.hlp in the utilities directory. + +------------ +From: /usr/davis/ Tue 16:31:16 27-Mar-84 +Package: utilities +Title: tasks detab, entab + +Tasks detab and entab have been added to the utilities package. See +detab.hlp and entab.hlp for documentation. + +------------ +From: /usr/tody/ Wed 19:25:49 28-Mar-84 +Package: system +Title: HELP moved to system; package LOCAL added to root + +The HELP program has been moved into the system package, with the new +package LOCAL taking its place. LOCAL provides a place for users or +remote sites to add their own software, without having to modify the +system itself. It also provides a way to get software into the system +so that people can use it, without having to meet the strict standards +required for mainline software. + +------------ +From: /usr/tody/ Wed 19:29:25 28-Mar-84 +Package: local +Title: new utility URAND + +A new utility program URAND (uniform random number generator) has been +added to the UTILITIES package. URAND is particularly useful for generating +lists to test software. Try the example given in the manual page. + +------------ +From: /usr/tody/ Thu 01:27:13 29-Mar-84 +Package: os +Title: zfpath modified + +The calling sequence for the ZFPATH primitive has been changed from + + call zfpath (fname, pathname, maxch, status) +to + call zfpath (fname, pathname, maxch, isdir, status) + +If the "isdir" argument is XYES, the pathname returned by the primitive +will be a directory name, suitable for prepending to a file name to +generate a pathame for the file (i.e., on UNIX, the directory pathname +will have a '/' as the last character). + +------------ +From: /usr/tody/ Thu 01:30:38 29-Mar-84 +Package: system +Title: copy, rename modified; movefiles added + +The COPY and RENAME tasks in the system package have long been tricky +to use, because it was hard to predict when there had to be a $ in a +directory name. These programs have been smartened up so that they +will always know when a file is a directory. For example, + + copy files, '.' + +will suffice to copy the named files to the current directory on our +UNIX systems. + + copy file, lib + +would make a copy "lib" of the file "file", while + + copy files, lib + +would copy the named files to the lib$ directory (provided there is more +than one file matching the template). + +RENAME can no longer be used to move a list of files to another directory; +use MOVEFILES for that function instead. If RENAME is called with a list +of files, the default action is to change the root name of each file: + + rename 'task.*', newtask + +might be used to change 'task.cl' to 'newtask.cl', and 'task.par' to +'newtask.par', all in the same command. A hidden param makes it possible +to change the extension instead. If a single file is named, it is +simply renamed. + +MOVEFILES moves the named files to the destination directory. The destination +must be a directory or it will abort. A command like + + move '*.x', name + +will move the file the subdirectory 'name' if there is one; otherwise the +program looks for a logical directory 'name$' and if it finds one, moves +the files there (but not across file systems at present). + +------------ +From: /usr/davis/ Thu 15:33:40 29-Mar-84 +Package: xtools +Title: gstrsettab bugfix + +Gstrsettab has been fixed so that it will accept an arbitrary first tabstop +and tab size. + +------------ +From: /usr/tody/ Thu 22:26:21 29-Mar-84 +Package: cl +Title: fix to avoid deadlock when killing a nonexistent process + +The CL would sometimes get into a strange state where, in response to +a ctrl/c interrupt, it would try to kill a process which had already +been killed. Deadlock would occur waiting for the nonexistent process +to die; additional interrupts would only result in more attempts to kill +the nonexistent process. To be honest, I do not understand why this +happens in the first place, but nonetheless the OSKILL primitive has +been modified to detect and avoid this kind of deadlock. + +------------ +From: /usr/tody/ Wed 10:03:36 04-Apr-84 +Package: fmtio +Title: LEXNUM did not recognize INDEF at the end of a line + +LEXNUM was using streq to compare its input with "INDEF", thus the test +would return false if the input string was longer than 5 characters. +Replaced the call to streq with one to strncmp. Indefinites should now +be properly recognized in formatted input. + +------------ +From: /usr/tody/ Fri 11:25:31 06-Apr-84 +Package: plot +Title: bug in graphics output to batch devices + +We have been experiencing intermittent failures of the graphics programs +when writing to the batch devices (versatec, imagen). The problem has +been traced to the system metacode translators (Jan's Fortran programs), +which evidently create temporary files in the current directory. I modified +the IRAF interface to these routines to call them from /tmp, so that +the graphics software will not abort when used in someone else's directory. + +------------ +From: /usr/tody/ Thu 16:15:00 12-Apr-84 +Package: fio +Title: bug fix: stderr was being directed to stdgraph output + +The recent addition of the pseudofile STDGRAPH introduced a bug into +file i/o causing the standard error output to be directed to STDGRAPH +instead of STDERR. The current CL does not differentiate between STDOUT +and STDGRAPH for output, so the ultimate effect was to direct STDERR to +the same destination as STDOUT. The file clio.clstdio.x was edited to +fix the bug (a missing goto after the entry point for the pseudofile +stderr was causing control to pass to the entry point for stdgraph). + +------------ +From: /usr/tody/ Tue 16:39:09 17-Apr-84 +Package: imio +Title: readwrite access to an image trashes the user area + +When opening an existing image for read write access, specifying the +size of the user area as zero (because it does not need to be used by +the calling program) IMIO would read only the standard header, but +would then write out the full header at imunmap time. The user area +would thus be overwritten with uninitialized data. Immap was modified +to record the amount of header data actually read if opening an existing +image, and imunmap was modified to write only that amount out when updating +the header. + +------------ +From: /usr/tody/ Tue 16:43:55 17-Apr-84 +Package: mii +Title: bug fix in miipak + +The wrong array was being byte swapped in the call to bswaps. A simple +error, fixed by replacing the name of the unpacked data array (spp) by +the name of the packed array (mii). + +------------ +From: /usr/tody/ Thu 20:05:06 26-Apr-84 +Package: vops +Title: bug in ARAV, the rejection average procedure + +A bug in ARAV caused all pixels to be rejected in the first iteration +(it was never tested and never worked). + +------------ +From: /usr/tody/ Fri 13:41:26 27-Apr-84 +Package: system +Title: "sleep" task added to system package + +The new task system.sleep provides a means for generating delays. The +single integer argument specifies the number of seconds of delay desired. + +------------ +From: /usr/tody/ Tue 22:03:33 01-May-84 +Package: imio +Title: bug fixes + +Problems were reported accessing images of more than 2 dimensions: the data +was not being written into the image properly. The problem turned out to be +the routine which calculates the char offset into the image given the coords +of a line. The routine would use the size of axis 3 in the calculation when +it was supposed to be using 2. It would also use 2 when it was supposed to +be using 1, but we have not seen it up until now because the test images have +all been square. All programs which access images of 2 or more dimensions +should be relinked. + +A second problem, reported some time ago, was also fixed. Imdelete would +crash when trying to delete an image with a zero length header. Problem was +lack of a return statement or error checking in immap after call to imerr; +added return statement and it works fine now when there is a header read +error. + +------------ +From: /usr/davis/ Mon 13:12:38 07-May-84 +Package: dataio +Title: pdsread mods + +For the sake of uniformity the pdsread task in dataio has been renamed +rpds. Rpds now calculates the minimum and maximum data values in the +pds image and enters them in the header. + +------------ +From: /usr/davis/ Mon 13:41:38 07-May-84 +Package: dataio +Title: rcamera mods + +Rcamera now calculates the maximum and minimum data values in the camera +image and inserts these values in the IRAF image header. + +------------ +From: /usr/davis/ Mon 16:21:05 07-May-84 +Package: dataio +Title: rfits mods + +Rfits in the dataio package now calculates the data minimum and maximum +values and puts these in the IRAF image header. + +------------ +From: /usr/valdes/iraf/ Tue 10:52:31 08-May-84 +Package: system +Title: interpolator routine + +The image interpolator library /usr/irafx/math/interp has a clget routine +to select one of the interpolator types. The routine is called +clginterp. + + interpolator_type = clginterp (param) + + char param[ARB] + +The CL request the parameter param, which is a string type parameter. +The string is interpreted into one of the interpolator types in interpdef.h. +The possible strings including abbreviations are: + + nearest + linear + 3rd order poly + 5th order poly + cubic spline + +This routine is implemented using clgwrd and will set an error condition +if the input string does not match any of the allowed strings. + +------------ +From: /usr/davis/ Thu 17:58:52 10-May-84 +Package: dataio +Title: FITS writer + +Task wfits has been added to the dataio package. + +------------ +From: /usr/tody/ Fri 09:07:24 11-May-84 +Package: system +Title: count would not read from STDIN + +Count would no longer read from the standard input because of a recent change +to ACCESS. Deleted all the file type checking from COUNT; now it counts each +file in the list whether or not it is a text file, just like any other utility +which operates on a list of files. + +------------ +From: /usr/tody/ Fri 10:06:11 11-May-84 +Package: images +Title: imdelete now works in verify mode + +The IMDELETE utility has been modified to fix a bug in verify mode. +The code was using the old TTY routines and had to be modified to +open and close the termcap database. While I was at it, I modified the +SYSTEM.DELETE program to only access the termcap database in verify +mode, making noninteractive deletes more efficient. + +------------ +From: /usr/davis/ Wed 09:58:49 16-May-84 +Package: dataio +Title: rcamera bugfix + +A bug in rcamera resulting in picture that were shifted left one column +has been fixed. The problem was that rcamera was reading the first data +value as the last header value causing all the pixels to be offset by one. + +------------ +From: /usr/tody/ Fri 11:41:18 18-May-84 +Package: fio +Title: file fault bug fix + +FIO divides a binary file up into a sequence of segments the size of the file +buffer. When seeking to the very last char in a segment, FFAULT would fault +in the next segment, and then write the first char of data into the char +preceeding the first char of the buffer, overwriting the MEMIO header word. +When the buffer was subsequently deallocated MEMIO would detect the overwrite +and a fatal error would result. There was no problem when seeking (faulting) +to any other char in a segment. + +------------ +From: /usr/tody/ Mon 10:21:25 21-May-84 +Package: math +Title: bevington library installed + +The Bevington library has been installed in lib$ for our scientific users. +The limit on the number of datapoints the REGRES procedure can handle has +been increased from 100 to 1000 points. These routines should not be used +in serious software. + +------------ +From: /usr/tody/ Thu 13:15:47 24-May-84 +Package: softools +Title: bug fix in SPP compiler + +When called with the -F flag followed by one or more filenames and then +some libraries, i.e., + + xcompile file.x, fort+, lib=library + +which is translated to + + xc -F file.x -llibrary + +the compiler would not set the -o file because by the time it saw "file.x" +it thought it should only make the fortran. Fixed so that it always sets +the -o file if it sees a filename. + +------------ +From: /usr/tody/ Sat 12:47:10 26-May-84 +Package: system +Title: handy type coercion functions for booleans + +We often need to convert the return value from procedures like clgetb +into one of the integer values YES or NO, and vice versa. To make this +easier I have added the following functions to the system: + + bool = itob (integer_value) + int = btoi (boolean_value) + +------------ +From: /usr/tody/ Sat 12:58:24 26-May-84 +Package: system +Title: database package renamed + +The DATABASE package has been renamed DBMS (for database management system, +as in all the trade journals). This yields a package prefix of "db>" for +the package, and makes it possible to abbreviate DATAIO. + +------------ +From: /usr/tody/ Sat 16:55:06 26-May-84 +Package: system +Title: enhancements to HELP + +The HELP utility now handles paging of multiple help blocks or source files +(option op=source) properly. The original program would pause at the end +of every screen of text but not at the end of every help block or file. +The program also discriminates now between the "more" prompt at the end of +a screen of text and that at the end of a block or file. If one answers +no to the "more" prompt at the end of a screen, the rest of the block or file +in question is skipped, i.e., the program advances to the next block or file. +If no is given in response to the prompt at the end of a block or file, +HELP quits. + +Help blocks with multiple keywords are now handled a bit differently too. +A single help block may be referenced by several keywords in the help +directory; the same block will be printed regardless of which keyword the +user enters. Previously HELP would always use the first keyword as the +title name, producing an identical manual page regardless of the keyword +requested. Now the program prints a manual page named for the keyword +requested; and it just so happens that several keywords are linked to the +same manual page. An entry is made in the printed manual for each keyword +so that the user does not have to know what keyword to look under to find +the documentation. + +------------ +From: /usr/tody/ Tue 20:28:04 29-May-84 +Package: system +Title: more enhancements to HELP + +The following enhancements have been made to the HELP utility: + + [1] Help now generates "manual page" style output, if the standard + output is redirected and pagination is enabled. Just pipe the + Help output to Page or Lprint and Help will generate manpage + output by default. A command such as + + help 'package.*' | lprint + + will print all of the manual pages for the named package. + + [2] Help can now be run on a file or files not installed in the help + database. This is useful for developmental packages, for + specifications documents, and so on. The "file_template" switch, + if enabled, causes the template to be interpreted as a filename + template rather than as a module name template. For example, + + help doc$crib.hlp, f+ | lprint + + will print the current version of the crib sheet on the line printer. + +------------ +From: /usr/davis/ Mon 08:35:51 18-Jun-84 +Package: dataio +Title: reblock bugfix + +Reblock was not appending the tape file number to the input file correctly when +the parameter file list contained only a single entry. + +------------ +From: /usr/tody/ Tue 11:38:41 19-Jun-84 +Package: vops +Title: call to error removed from the ACHT routines + +The call to "error" has been removed from the ACHT routines so that they can +be called from Fortran programs (they are used in the new Fortran simple +interface to IRAF images). If an ACHT routine is called to convert to an +unknown datatype it does nothing. This is in keeping with the convention +that the string operators, vector operators, formatted i/o operators, and +math library routines be purely numerical procedures. + +------------ +From: /usr/tody/ Sat 16:33:03 23-Jun-84 +Package: vops +Title: interface modification + +The calling sequence of the ABAV (block average) vector operator has been +changed and the code has been internally modified. The new calling sequence +is + abav[silrdx] (a, b, nblocks, npix_per_block) + +and partial blocks are not permitted. Computation of the block sum is +carried out in enough precision internally to guarantee that there will be +no problems with overflow for the integer types. + +------------ +From: /usr/tody/ Sat 21:46:08 23-Jun-84 +Package: imio +Title: bug fix in IMIO + +When opening a new or new copy image the image dimensions were not getting +copied into the internal array IM_SVLEN, used in the IMIO code where the +full (non-section) image dimensions are required. IMIOFF was modified to +set this array when the dimensions of a new image are processed. + +------------ +From: /usr/tody/ Sun 18:41:04 24-Jun-84 +Package: memio +Title: error checking added to SALLOC + +The SALLOC procedure will now detect a bad datatype code (arg 3), producing +a fatal error. + +------------ +From: /usr/tody/ Tue 10:41:20 26-Jun-84 +Package: system +Title: minor mod to RENAME + +RENAME has been modified so that it queries for the old filename(s) before +the new name(s). The order of the queries now agrees with the order of the +positional parameters. + +------------ +From: /usr/hammond/iraf/ Tue 16:53:24 26-Jun-84 +Package: dataio +Title: new task installed: rrcopy + +Task "rrcopy" has been installed in the dataio package. This task will +read IPPS rasters stored on rcopy tapes and convert the rasters to IRAF +images. A rcopy format disk file can also be converted. + +------------ +From: /usr/hammond/iraf/ Tue 16:56:37 26-Jun-84 +Package: local +Title: new task installed: fields + +Task "fields" has been installed in the local package. This task is a +list processing tool used to extract whitespace separated fields from +the specified files. + +------------ + +------------ +From: /usr/davis/ Wed 08:31:28 27-Jun-84 +Package: dataio +Title: new parameter in dataio readers + +It is now possible to specify a tape file number offset in the dataio +tasks rpds, rfits, rcamera and rcardimage. The readers will begin begin +numbering the output files at "offset + tape file number" instead of +"tape file number as before". The offset parameter is useful in cases +where one wishes to maintain the same root output file name but read +from a different tape. + +------------ +From: /usr/tody/ Thu 17:49:07 28-Jun-84 +Package: fio +Title: file fault now zero-fills on a write-only file + +The file fault procedure was modified to zero the file buffer when +faulting "in" a block on a write only file. Previously the contents +of the file buffer were uninitialized and if the buffer was not completely +written into, garbage would be written out to the file. + +------------ +From: /usr/tody/ Mon 14:49:47 02-Jul-84 +Package: help +Title: bug fixes in HELP + +The following two bug fixes were made to the HELP utility: + + [1] File mode will now find unnamed help blocks, i.e., blocks + beginning with a ".help" not followed by a keyword. + + [2] Help block name keywords may now contain underscore as well + as alphanumeric characters. + +------------ +From: /usr/tody/ Mon 14:52:40 02-Jul-84 +Package: fio, imio +Title: optimization + +A number of small mods were made to FIO and IMIO to enchance efficiency. +No interface changes were involved. + +------------ +From: /usr/tody/ Tue 14:20:23 03-Jul-84 +Package: fio +Title: whitespace in filenames, numbered files + +The filename mapping procedure now deletes trailing whitespace from a +filename. It no longer maps numbered files, hence numbered files may +now be referenced just like any other file. + +------------ +From: /usr/tody/ Wed 16:44:53 04-Jul-84 +Package: images +Title: improvements to IMHEADER utility + +The IMHEADER utility program now accepts filename templates, and hence can be +used to print the headers of a list of images. There is both a long and a +short form. The name of the pixel storage file is printed, along with a note +telling whether or not the file exists. + +------------ +From: /usr/tody/ Thu 19:27:24 12-Jul-84 +Package: spp +Title: buffer space in compiler increased + +The size of the dynamic memory area in the RPP phase of the SPP compiler +has been increased to avoid the "in dsget: out of memory" compiler errors +we have been getting occasionally. + +------------ +From: /usr/tody/ Thu 19:38:04 12-Jul-84 +Package: plot +Title: GRAPH can now put image title on a plot + +If the parameter graph.title is set to "@imtitle" and the first operand in +the list of operands to be graphed is an image, GRAPH will now use the title +of the first image as the plot title. This has been changed to be the default +action. + +------------ +From: /usr/tody/ Thu 22:12:43 12-Jul-84 +Package: plot +Title: variable line widths + +The plotting interface to the versatec has been changed to permit variable +line widths. The appearance of plots on the versatec is much improved, +particularly the contour plots. Try it! + +------------ +From: /usr/tody/ Fri 21:21:38 13-Jul-84 +Package: plot +Title: new parameter for CONTOUR + +A new hidden parameter has been added to CONTOUR permitting a zero point +shift to be applied to the data before plotting. This makes it easy to +adjust the percentage of dashed (negative) contour lines in the plot. + +------------ +From: /usr/tody/ Thu 16:51:39 19-Jul-84 +Package: plot +Title: minor mods and bug fixes + +CONTOUR and SURFACE will now print a warning message if used to operate +on a very large subraster; possibly the user did not know about image +sections or forgot to use one. The warning message can be disabled with +the hidden parameter "verbose". GRAPH had a bug (now fixed) introduced by +the recent mod to use the image title as the default plot title. If called +to graph a list from the standard input, GRAPH would try to immap the input +operand (STDIN) and would discover that it was not an image, which is fine, +but then there would be no data left to plot since STDIN is sequential. + +------------ +From: /usr/tody/ Fri 10:41:45 20-Jul-84 +Package: cl +Title: new _curpack builtin + +A new builtin task "_curpack" has been added to the language package in the CL. +The function of this task is to print the name of the current package. Used by +HELP to order searches of the help database. + +------------ +From: /usr/tody/ Sun 22:41:02 22-Jul-84 +Package: mkmanpage +Title: now supports both CL format and SPP (procedure) formats + +The MKMANPAGE utility can now be used to generate manual page templates +for both CL programs and library procedures. Do an lparam for additional +details. + +------------ +From: /usr/tody/ Sun 22:43:44 22-Jul-84 +Package: xtools +Title: cleanup + +The XTOOLS package has been reorganized and the code cleaned up somewhat. +The package is now online in HELP too. The CLGINTERP routine has been +moved from math$interp into XTOOLS. + +------------ +From: /usr/tody/ Sun 22:46:07 22-Jul-84 +Package: help +Title: new relase of the HELP program + +The HELP program has undergone a major revision. Highlights include +pre-compilation of the help database, improved error diagnostics, +a much larger help database, and speedy response (but it still takes +forever to spawn the process the first time). Details will follow soon. +Try "help '*.', op=dir" or softools.hdbexamine for a peek at the database. + +------------ +From: /usr/tody/ Mon 19:28:52 23-Jul-84 +Package: cl +Title: dictionary size increased, process cache more efficient + +We had a dictionary overrun recently so I doubled the size of the CL +dictionary (which is currently fixed in size at startup time) from 7500 ints +to 15000 ints (60 Kb). This will permit more complex CL scripts to be run. +The stack area is also fixed in size but judging from the report I heard +it was the dictionary which was being overrun. + +While I was at it I made a mod to improve the efficiency of the process +cache. The process cache is no longer flushed when a command is sent to +the OS with a "!" escape. The improvement in response should be significant. +The process cache is still flushed by CHDIR or when the environment list +is modified. Both of these cases will be fixed in the future as well. + +The builtin command FLPRCACHE has been added to flush the process cache. +An explicit command to flush the process cache has been added to XCOMPILE +and MAKE to avoid a UNIX abort while trying to rebuild a process which is +sitting in the cache. There may be other times when this is a problem, +however; beware that the executable file is protected while the process is +running, and that an occasional "flpr" may be necessary to explicitly flush +the cache. The inconvience should be minor compared to the significant +improvement in response we should see for commonly used commands like dir, +clear, etc. + +In particular, the following will not work when a process is running: + + - The file cannot be written into, e.g., by COPY or even by + the UNIX "cp". + + - The process can be run under the debugger, but you cannot set + a breakpoint (cannot write into the executable file which + is mapped into memory). + +Beware of these sorts of problems, it can be hard to figure out what is +going on! + +Finally, a new intrinsic function STRIDX was added. Function is similar +to the program interface version. The EDIT script was recoded to use this +function, eliminating the use of a temporary file and speeding up EDIT a bit +(we still have a ways to go, though). +math/bevington/*.f + Changed illegal unix style continuation in several Fortran files to + Fortran continuation. + +math/llsq/sva.f + Fixed hollerith fields of format statements at end of procedure. + +sys/clio/zfiocl.x + Variable 'nchars' was multiply declared. + +sys/clio/clgfil.x + This file (and the FNTGFN code) was completely rewritten as noted + elsewhere in the revs notices. + +sys/fio/filopn.x + The VFN (mapping file) was being opened with read write access even + when the file was to be opened read only. This would cause an + unnecessary delay when multiple users would try to read from the + same file at the same time. + +sys/fio/vfnmap.x + Variable file_exists was never used in vfnmap due to the commenting + out of the .zmd file code. The declaration was commented out as well. + +sys/fio/fcopy.x + The call to fmkcopy would fail when the input file was a standard + stream. Changed to use fstdfile() to test for a standard file, + calling fmkcopy only if not a standard file. + +sys/fio/vfntrans.x + Escape character processing was mapping \X into X for all X, causing + file.\X extensions to in effect not be escaped (a later routine would + map the extension). Changed to allow escaping of the $ metacharacter + but no other, i.e., \$ maps to $ without logical directory expansion, + but \X maps to \X for all X != $. + +sys/fmtio/fmtstr.x +sys/fmtio/strtbl.x + Did away with the experimental ; in argument lists, using ',' instead. + This feature turned out not be useful and has been deleted from the + SPP language. + +sys/fmtio/strtbl.x + Modified to use STRSRT to sort the field list. + +sys/fmtio/fmt_setcol.x +sys/fmtio/fprfmt.x + Deleted declaration for unused variable 'i'. + +sys/gio/glabax/glbverify.x + Deleted commented out code used to test if log scaling made sense. + The associated function gt_linearity() was declared but never used, + causing a warning message. + +sys/gio/gtickr.x + Similar problem with variable 'nticks'. + +sys/gio/nspp/mcscale.x + min/max type mismatch fixed. + +sys/gio/cursor/grccommand.x + The unreachable code should have disappeard with the completion + of all the grccommand options, hence this routine was not changed. + +sys/gio/nsppkern/pwry.for + This routine was deleted when the new character generator was + intalled recently, hence the illegal \\ in fortran problem is gone. + +sys/mtio/mtupdlock.x + Could cause no write perm problem on tmp$ as temporary file name + "tmp$mtlok1234ll" was too long for VMS and would cause a mapping + file reference. Changed the "mtlock" to "mt" to eliminate the + mapping file reference. This is supposed to be a low level routine + (it is called by a FIO device driver) hence full filename mapping + is not desired here. + +sys/mtio/rewind.x + This was changed in the VMS version of IRAF because the SIRM + specified a channel number for the argument to ZZRWMT, rather than + the unit number used in the code. No changes were made as it + is the SIRM which is in error. REWIND takes as argument a drive + name such as "mta", rather than the file descriptor of an open file. + + call rewind ("mta") + + This permits rewinding of a drive which is not open, and + forbids rewinding of a drive which IS open. This consistent with + the philosophy of MTIO in which MTOPEN can only be used to access + a single file at a time. It is not safe to assume that a tape + drive can be rewound while opened to a particular file on the tape; + this does not work on some systems (e.g., AOS, at least as of 2 + years ago). + +sys/libc/mathc.c +lib/libc/libc.h,math.h + Found a way to eliminate the extra procedure call without adding + VMS dependence. The LIBC stuff is nearly machine independent and + we should strive to keep it so. The (&(x),&(y)) construct used + here (where x and y may be constants) is nonstandard C and should + be avoided. + +sys/libc/cfchdr.c + In the VMS version XOK was always returned since FCHDIR does not + return a function value. This is not right because FCHDIR takes + an error action if it cannot change the directory. I modified + c_fchdir() to error check FCHDIR and return ERR if an error occurs. + CHDIR in builtin.c checks for this function value. + +sys/libc/free.c + Reference to 'ptr' changed to 'buf'. + +sys/tty/ttyctrl.x + Remove declaration for unused variable 'i'. There were other + modifications to the TTY files as a result of the recent effort + to eliminate unix like filenames from the system directories. + +pkg/softools/boot/spp + Many changes here. The missing argument in errchk.f was fixed + a long time ago. There was also a missing argument in xppcode.c. + The 'elusive rpp bug' (jiand problem) was fixed some time ago. + Other changes for reordering declarations were reported in the + revs notices recently. + +pkg/softools/boot/spp/rpp/rpprat/lndict.r +pkg/softools/boot/spp/rpp/rpprat/outstr.r + The declarations for 'cupper' were deleted in the VMS version to + avoid a 'declareed but never used' warning message from the + compiler. This was an error because the integer function cupper() + is conditionally used in the body of the procedure if a switch + definition is defined in the rpp include file. I replaced the + declaration but put a conditional compilation around it to that + it would be declared only if used. + +pkg/cl/exec.c + There was a typo: operator '*' used where '&' was intended. + This was fixed some time ago but not recorded. + +pkg/cl/builtin.c + The error checking of the return value from c_fchdir was removed + in the VMS version due to a related change to c_fchdir(). I left + the error checking in for the reasons noted above. + +pkg/cl/pfiles.c + The operator '&&' was used where '&' was intended, resulting in a + nasty bug in pfcopyback(). The weak typing in C strikes again. + +sys/fmtio/parg.x + Changed the default precision of a %f from 1 decimal places to + full precision. The former default was causing numbers such as + "0.01" to be printed as "0.0". + +dev/graphcap + Added entries for vt100s,vt240,vt240o,vt100so from the VMS graphcap. + +dev/termcap + Added entries for printronix,qms from the VMS graphcap. + +dev/ + Added files edt.ed, emacs.ed. + +lib/cl.par + Made cosmetic changes as in the VMS version. + +lib/cllogout.cl + Commented out automatic magtape deallocation as in VMS. This has + caused problems for users multiply logged in, and greatly slows + down logout as well. + +lib/clpackage.cl + Added SET defs for "language", "showall", and "editor". Added + a "lexmodes = yes" to make command mode the default. + +lib/login.cl + Did NOT add the statement + + set logfile = uparm$logfile" + + because the logfile name is controlled by a CL parameter rather than + by an environment name. I do not understand why this set stmt was + present in the default VMS login.cl file. + +lig/make.h + Added a CFLAGS macro and a .c.o entry which uses it. + +lib/libc/ctype.h + Added #ifdef vms condtional to define "vms_ctype_defs" as a globalvalue. + Presumably this is necessary for the VMS C compiler to be able to link + in the initialization module ctype.o from the library. + +lib/libc/iraf.h + Added a def "UNIX42BSD" to specify the exact version of UNIX used on + the host system. Not yet used anywhere. + +lib/libc/kernel.h + Modifed plotter table entries for the NSPP devices to submit the + rasterization tasks as a reduced priority (UNIX only). + +lib/libc/[kx]names.h + Not modified - VMS needs a different version of these files. + +lib/libc/spp.h + Changed define of INDEFL for VMS, added VFN definitions. + +lib/libc/stdio.h + Modified getchar(), putchar() macros to use fgetc() and fputc(). + Don't know why this is necessary on VMS, but it cannot hurt and + these routines are used too infrequently for it to be worth worrying + about efficiency. + +pkg/help/ +pkg/help/lroff/ + There were a number of changes recently to make structure definitions + more portable, to eliminate ENTRY statements, and to avoid type + mismatches in argument lists. + +pkg/help/lroff/lroff.hlp + The documentation for ".in" incorrectly specifed the action as move + to col "n+1". Changed to move to "current+n". + +pkg/language/ + Moved in the entire VMS version of this directory to capture the + new manual pages therein. Deleted the junk file "words" from the + root directory. + +pkg/lists/ + Added the SDAS task "columns" to the package. Some source changes + were required, in particular the task was installed int the x_lists.e + executable to save disk space. Not tested. + +pkg/lists/words.x + The variable last_nscan was incorrectly declared to be a function. + +sys/gio/stdgraph/stg[gr]cur.x +sys/gio/stdgraph/stginit.x +sys/gio/cursor/grccmd.x + A new cursor mode option ":.cursor N" was added to allow the user + to select the logical device cursor to be used for cursor mode input. + The cursor may also be selected under program control by using GSETI + to set the desired cursor number and then calling GSCUR to set both + the cursor number and position. The kernel will continue to use the + indicated cursor so long as cursor reads request cursor number 0; + this is always the case for cursor mode cursor reads. For cursor + selection to work for STDGRAPH devices, the graphcap entry for RC + should be implemented as a case statement, with logical cursor numbers + of 1, 2, etc (see the entry for the device "vt640" for an example). + +sys/dev/graphcap.vt640 +sys/gio/stdgraph +sys/gio/cursor + More changes were required to support setting of logical cursors in + cursor mode. Setting a logical cursor with :.cursor now locks the + logical cursor until unlocked by a subsequent ":.cur 0" or ":.init", + i.e., the locked cursor N will always be referenced regardless of + the cursor number specified in a GIO call. + + In the process of debugging this feature a bug was discovered in + the stdgraph encoder. The encoder case statement ($1..$2..$$) was + not being processed correctly. + +sys/pkg/plot + A new task SHOWCAP was added to the PLOT package. SHOWCAP is used + to interactively inspect and check out graphcap entries. Complex + graphcap entries can be encoded and the output dumped in ASCII + (rather than graphically) to verify that the correct codes will be + are are being sent to the terminal. The task is implemented as an + interactive interpreter and is self documenting. + + SHOWCAP accesses the graphcap database like any graphics task, hence + any errors in the links to the database should be detectable by running + SHOWCAP. It may be necessary to relink both SHOWCAP and the CL to + make sure that both are using the same version of tty$cacheg.dat. + Graphcap entries may be cached in object form in libsys.a by running + the task MKTTYDATA in package softools, then rebuilding libsys.a. + +sys/osb/bytmov.s +sys/vops/lz/amov.s + The VAX memory copy instruction AMOVC3 cannot move more than 65K bytes + in a single call. All routines which use this instruction were + modified to check for very large blocks and to call AMOVC3 repeatedly + to copy such blocks in 65K or smaller segments. + +sys/etc/symtab/* ***** NEW PACKAGE!! ***** + A new system package SYMTAB was added to the system library libsys. + SYMTAB is a very general and efficient symbol table package for use + in IRAF system utilities, applications, and other places (possibly in + HELP for faster help database searches, or a future version of the CL + which implements macro expansion). + +sys/etc/environ.x + The hash function used in the environment package was replaced by the + function used in the new SYMTAB package, which is simpler and better. + +pkg/softools/* + This entire package has diverged so far from the UNIX version that I + have decided (for the present) to support two completely different + implementations of the SOFTOOLS tasks, one for VMS and one for + other systems. At some point this package will have to be cleaned + up and the existing (gawdawful) code thrown away. + +sys/fio/fmkdir.x +pkg/system/mkdir.x +sys/libc/cfmkdir.c + A new library procedure FMKDIR was added to the FIO package for + creating new directories. A new task MKDIR was added to the system + package to provide the same facility at the CL level. The FMKDIR + procedure was added to xnames.h and a new procedure c_fmkdir() + was added to the C runtime library. + +pkg/system/edit.* + The edit script was changed to pick up the name of the editor from + the environment, rather than from a parameter. This permits use of + a single global variable to select the editor everywhere. + +pkg/system/lprint.x + For reasons I don't understand (despite the comments in the code) + the VMS version of this task insists on a separate LPOPEN call + for each INPUT file to be printed. This does not make any sense - + it should not matter to the LP driver where the input is coming + from, or how many files input is coming from. Furthermore, printing + each file as a separate VMS print job (presumably with a separate + job header etc.) is a drastic change to the LPRINT utility which would + render it unusable for making listings of packages (a directory full + of files). The typical command to print a full listing of a package + is "lprint *.x,*.h,*.com": these files must be submitted to the system + as a single print job. + + I will check into this further when testing the merged system. + +pkg/system/stty.cl + Modified to permit setting the baud rate, screen size, etc. on the + same command line when the terminal type is set. STTY with no + arguments shows the status; STTY with any combination of arguments + sets the arguments. The VMS version of this mod was not quite + right, by the way, because hidden parameters are not counted in + $nargs. Hence a "stty baud=1200" has $nargs=0 (no positional args), + and "stty baud=1200" was being treated the same as "stty". + + Note: STTY should not be used in the login.cl file because it is + slow (it has to spawn the system process to access termcap). Use + explicit SET statements in the login.cl file instead, leaving STTY + for the interactive user. + +sys/Makelib +sys/gio/Makelib + Added entries for the system libraries libcur.a (cursor mode) and + libstg.a (the stdgraph kernel). These libraries are required to + link the CL hence are installed in the system library. I did not + add the library libgkt.a (NSPP kernel) because it is really just + a "pkg.a" type library, and is not used outside of the package. + Updating of this package shoud done by some sort of make facility, + since MKLIB cannot link and install the process. + +sys/fmtio/cto[il].x + I agree that CTOI and CTOL should have the same semantics and that + neither should call GCTOL, which is different. Rather than + implement CTOI as a call to CTOL I have simply duplicated the same + code in both CTOI and CTOL. One does not really save any memory + by having CTOI call CTOL because mostly likely a process will only + link in one or the other, and it will almost always be CTOI which + gets used. If CTOI calls CTOL then the result is something which + not only runs slower but which requires MORE core memory. CTOI, by + the way, was originally implemented as a call to GCTOL (like CTOL). + I wanted something simple and fast (formatted i/o is the slowest + thing around), hence I don't like the extra procedure call in this + context, even though I admit it is better software engineering (more + structured). + + I noticed in the VMS CTOL that the "if (str[ip] == 'I')" was + commented out, presumably because the code works the same whether + it is there or not. The reason it is there is for efficiency - + it is much faster to compare two integers and branch than to + call an external procedure like STRNCMP. The test for 'I' eliminates + the call to STRNCMP in virtually all calls to CTOL, since indefinite + numbers are rare. + + By the way, I noticed that the new version of CTOI did use the new + IS_INDEF macros, which indicates that somebody out there in VMS land + reads the revs notices pretty carefully. Good show. + +sys/fmtio/* + All occurrences of (NNN == INDEF_) were replaced by equivalent + IS_INDEF constructs. Probably still a lot of the old constructs + left in the other parts of the system. + +sys/libc/ato[il].c + These LIBC procedures were NOT converted to calls to CTOI and CTOL. + Formatted i/o is a major consumer of cpu cycles and the original + C versions of ATOI and ATOL are optimal C code. The VMS version + of ATOI has to pack the numeric string, call CTOI which calls CTOL + which makes an unnecessary call to STRNCMP - 5 procedure calls where + formerly there was only one. The amount of memory saved is not + enough to be worth modifying an existing, functional library procedure, + even if it did not make things slower. + +sys/libc/calloc.c + The type coercion (char *)NULL added here and elsewhere is strange - + UNIX lint accepts just a NULL which is a legal pointer value in C + (see K&R pg. 192 and the example on pg. 97). The type coercion + added is probably harmless but should not be necessary - does the + VMS C compiler issue a warning message or something? If not and + the message is only from VMS lint, then we should leave the NULL + as is. I suspect that the VMS C does not realize that 0 is a special + number in C and is complaining about an integer to pointer assignment. + If that is the case, the problem is with the VMS C compiler and the + code should not be changed (unless we are forced to do something + because the compiler treats the "error" as fatal). + +sys/libc/cclose.c + Added error checking and function value. + +sys/libc/cnvtime.c + Move c_cnvdate out into a separate file. + +sys/libc/cenvget.c (and elsewhere) + It is common in C sources at many sites to declare C functions as + follows + + typespec + function_name (arglist) + + rather than as + + typespec function_name (arglist) + + This is done because [1] there are software tools, e.g., a cross + reference utility, which can only recognize a function declaration + of the first form, and [2] when editing the file, a "beginning of line" + pattern match will find the function declaration (rather than every + call to the function plus the declaration for the procedure itself). + The C syntax is so subtle that without this convention it is difficult + to find things in C source files containing many functions. + + If C had a PROCEDURE keyword like SPP then I would use the second + form, but since it does not and the ^func style is common in UNIX + land, I would like to keep things as in the first example. + +sys/libc/cenvget.c (and elsewhere) + I did not change the + + if (...) + return (a); + else + return (b); + + constructs to the form + + if (...) + return (a); + return (b); + + The first form is more readable and does not bother UNIX lint. Modern + compilers are smart enough to compile the same code in either case, + hence there is no efficiency gain in the second form. If the VMS C + compiler or lint complains it is in error and should be fixed (rather + than IRAF). + +sys/libc/cerror.c + Moved each procedure into a separate file. Added NCHARS as in VMS + version. Went one step further and changed all the "return(strlen())" + to "return (nchars)" since we now have the NCHARS. + +sys/libc/cread.c,cwrite.c + Did not replace the calls to c_erract and c_error by direct calls + to the SPP ERRACT and ERROR procedures. Since errors rarely occur + doing so does nothing to make the code go faster; no memory is + saved since c_erract is very small (5 longwords) and its size is + offset by the extra code needed to call the Fortran procedures by + reference. Also the code is prettier if the C binding is used. + +pkg/dataio/imtext/* + This task was found to be extremely inefficient and the output code + (ascii encoding) was rewritten, speeding the task up by more than a + factor of 10. + +sys/fio/putline.x + In the process of profiling the optimized version of WTEXTIMAGE it + was discovered that text file i/o is now dominating the timings (the + output text file is enormous). Examination of PUTLINE revealed that + it could be optimized substantially, hence the procedure was largely + rewritten. This is a major output procedure hence is worth careful + coding. I rewrote PUTLINE, speeding it up by more than a factor of 2. + +sys/os/zfiotx.c + Examination of the UNIX version of ZPUTTX revealed some considerable + inefficiencies. Every character was being compared to newline even + when it was known in advance that this was not necessary. Characters + were being output one at a time with PUTC. I moved the test for + newline outside the loop, making a loop where newline is checked for + and another where it is not. In the latter case data is now output + in a block without using PUTC. + +sys/libc/cxwhen.c + Moved c_xgmes() out into a separate file. + +sys/libc/fclose.c,fflush.c,fopen.c,etc. + Modified to make direct calls to the SPP procedures (as in the VMS + version) to eliminate the slight overhead involved in the extra call + to the procedures of the C binding. + +sys/libc/* + Did not modify these routines to use FGETC,FPUTC rather than GETC,PUTC, + since the inline macros are more efficient. Why was this changed for + VMS? If it was to save a little memory I think that is a bad tradeoff, + the amount of memory saved is insignificant and cpu cycles are usually + in shorter supply. + +sys/libc/system.c + Eliminated the call to c_oscmd to avoid an unnecessary and redundant + string unpack/pack operation. + +sys/osb/*.c + A number of procedures were changed in the VMS version of the system, + converting register variable declarations to register argument + declarations. I did not keep these mods as the resultant code is the + same in either case and I prefer the former style. + +sys/etc/main.x + A variable was placed in a fake common to defeat optimizations by + the VMS fortran compiler that would cause failure in a future magic + return from ZSVJMP during error recovery (a very subtle bug found + by Jay T. at STScI, after a great effort). + +sys/etc/qsort.x + The array argument x[nelem] where X and NELEM are both arguments would + cause a VMS Fortran runtime error when QSORT was called with NELEM=0 + (I am surprised that the compiler makes such a check at runtime). X is + now dimensioned ARB hence this error should no longer occur, even if + QSORT is called to sort an array of length 0. I did not add the test + for NELEM==0 since the routine as written will work for this limiting + case (the array X will never be referenced). + +sys/fio/rename.x + A change was made to this routine to force the host system dependent + mapped filename to come out a certain way. I did not keep the rev + because FIO does not guarantee that a filename will be mapped in a + certain way, and the external world should not depend upon names always + being mapped in a certain way. A change which would slow down rename + by a factor of two is not justified. + +sys/fio/vfnmap.x + A number of changes were made here to fix bugs which were independently + fixed on our UNIX system. In particular there was a bug where a null + length mapping file would be created when a VFN was opened for updating + but no update ever occurred. I fixed that independently some time ago + (apparently with fewer changes) and will wait and test my version of + the routine on VMS. + +sys/fio/vfntrans.x + It was not correct to remove the handling of \ escapes completely in + the routine which expands logical directory names. The problem was + fixed by having \$ map to $ as before (allowing $ in filenames), but + having all \C map to \C rather than C, preserving escaped filename + extensions. + +sys/fio/isdir.x + I did not add this routine to FIO, but may do so at some time in the + future if it proves useful enough (the name would have to be changed). + It was improper for the Makefile in IMAGES to refer to the routine + directly in the SYSTEM package, since SYSTEM is a package and not a + library (I was not aware of the reference to ISDIR in the IMAGES + makefile). The solution for the present is to duplicate the code in + both packages. There are an infinite number of routines that could + be added to the system libraries; the libraries must be kept small to + be comprehensible by programmers, hence I never add a procedure to a + library until it becomes clear that it is best to do so. + +sys/fio/fseti.x +sys/fio/fset.h +sys/os/zfiomt.c [UNIX] + A new fset option F_VALIDATE was added. This is used to validate the + contents of the active FIO buffer after a read error, in order to + try to recover at least part of the record. The caller must tell + FIO how many chars to validate. The next read will return the contents + of the buffer. The UNIX magtape driver routine ZZRDMT was also modified + to backspace a record and retry the read if a read error occurs. The + output buffer (usually the FIO buffer) is zeroed prior to the retry + to avoid garbage data in the buffer if error recovery is attempted. + My thinking is that the magtape drive will get partially through a + dma transfer, detect a parity error, and then abort the rest of the + dma transfer, in which case at least part of the buffer should be + valid. + + # If a read error occurs validate whatever is in the buffer + # and repeat the read, returning data from the validated + # buffer w/o any more io. + + iferr (status = read (magtape, outbuf, maxchars)) { + call fseti (magtape, F_VALIDATE, record_length_in_chars) + status = read (magtape, outbuf, maxchars) + } + + The caller must know the expected record length for this type of + error recovery to be successful. + +--------------------------- +CL2 integration +Phase 1: quick onceover of code and first compile. +--------------------------- + +Moved in new CL wholesale. +Deleted all junk files. +Inspected Makefile; looked up to date. + +Tried to compile the CL. Died on first file, "cl.x" (would not compile on +UNIX for some reason - I did not investigate). Looked therein and horror of +horrors, a hacked version of the IRAF Main. I do not want to support two +versions of this very important procedure, so I deleted the hacked version +so that The Real One will be pulled in from libsys. + +It looks like the hacked version of the iraf main was used to avoid the +reference to the library routine "cmain" in LIBC (a funny library reference +was required to link this module which perhaps caused problems on VMS). +I guess a better solution is needed, but it must not involve a second copy +of the iraf main. Doing so violates the LIBC interface, resulting in possible +failure of the CL whenever changes are made to the iraf VOS. + +Second try. + +Lots of error messages, shown below. Actions taken to fix each bug are shown +in parenthesis. + + *.c: CLDEBUG redefined everywhere +(-DCLDEBUG compiler flag removed in UNIX Makefile) + + grammar.y: 120: RETURN redefined + ./lexyy.c: 3: BEGIN redefined + ./ytab.h: 22: RETURN redefined + (etc) +(RETURN is also defined as an opcode in opcodes.h. BEGIN is an internal +(definition produced by YACC. Solution was to use Y_ consistently for all +(tokens in the parser. Incidentally, RETURN is also defined in eparam.h. +(Should have been called CR there, since CR is the standard ASCII name for +(that key). + + linker unsatisfied external: _AMOVI +(The CL used to have a C function called "amovi" in main.c. This was removed +(in the VMS version and a direct call to the VOS procedure AMOVI substituted +(instead, presumably in reponse to a library conflict on VMS caused by VMS +(not distinguishing between C and Fortran externals in libraries. This is a +(violation of the LIBC interface; I solved the problem by changing the name +(of the C function to "cl_amovi".) +( +(NOTE: the fact that we are doing this at all (playing with the ZSVJMP vector) +(is a subtle violation of the LIBC interface, more serious than the use of +(amovi, and should be changed (this one is my fault)). + + "gram.c", line 1116: + warning: struct/union or struct/union pointer required +(typo: misplaced parenthesis in statement 'curr = coderef(curr->c_args);' +(should have been 'curr = coderef(curr)->c_args;') + + "eparam.c", line 311: + warning: illegal combination of pointer and integer, op = + +It was not obvious what was causing this error, but I decided to postpone that +for the moment to clean up the EPARAM code. This code stands out in the CL +like a sore thumb, as it is written in a style completely different than the +rest of the CL (and at odds with the iraf standard). Even worse, the style +is not consistent as if several people with different coding styles had worked +on the code. Now that the code is written and people other than the original +author(s) have to maintain it, it must conform to the rest of the CL. + +(busy reworking eparam) + Added call to c_ttycdes to ttyexit() to close tty descriptor. + Old code was allocating a new tty descriptor on every call, + never returning old ones. + Replaced environment variables "standout" and "showall" by + the single variable "epinit". A name such as "standout" + has no obvious association with EPARAM and could easily + conflict with other names. For example, use SET declaration + "set epinit = nostandout showall" to disable standout and + enable showall. Additional parameters can easily be added + without cluttering the environment list. Usage is consistent + with "cminit", used to init cursor mode. + Simplified the code a bit in various spots; some pretty messy + stuff in there (admittedly the rest of the CL is messy too). + Obviously will have to check this when I get it running again + against the original version to see if it operates mostly the + same. + Added "ehinit" to give user control over EHIST. Current parameters + [no]standout, bol, eol. + +(now for edcap.c) + Warning message is now printed if editor is named for which an + edcap file cannot be found. + Input EDCAP format for keystrokes generalized. Now supports the more + readable ^X, \[befnrt] formats as well as octal escapes. + + GRIPE: The string editing facility is really tied into its use in + EPARAM and EHIST, with all sorts of changes occurring internally + to the values of global variables used by the calling program. + The string editor should have been coded as a self-contained, + general purpose subroutine that modifies a string using the EDCAP + screen editor interface. + +(edcap.c and eparam.c now cleaned up and compile with no errors. I am familiar +(with them now and ready to tune them when the CL runs (from looking at the +(code I am sure that some tuning will be necessary). The rest of the new +(code looks pretty good, with the exception of numerous ELSE clauses which +(are not connected to the preceding ifs. Try again to make the CL...) + + CL runs! Sill getting compile time warning messages, however. + The warning messages are as follows (numerous occurrences in several + files): + + "globals.c", lines 45-97 + warning: illegal combination of pointer and integer, op = + + The problem is statements like + + char array[] = "string"; + + which get converted by XSTR into + + char array[] = (&xstr[N]); + + This causes our compiler to issue a warning message and seems like + rather a dangerous construct (I am not even sure it is even legal). + The following is however ok: + + char *array = (&xstr[N]); + + I converted a few of the array[] to *array to avoid this class of + problem. The EDCAP initialization remained a problem; the question + is, is XSTR worth all this? It makes the compile go MUCH slower, + but how much memory does it really save? + + no xstr text data bss dec hex + 267264 56320 115556 439140 6b364 + xstr text data bss dec hex + 267264 55296 114832 437392 6ac90 + ----- ------ ------ + 1024 724 1748 + + For less than 2K I don't think its worth it. Bye bye xstr, at least + for now. For comparison, here is CL1.x (current version, no eparm): + + text data bss dec hex + cl1.x 237568 49152 109744 396464 60cb0 + + There was a time once when the CL fit in a 64K partition. Now the + CL grows by almost 64K every time we add a new feature! + +-------------------------- +Phase 2: Test and tune CL2 + +history.c + Removed the "#ifdef ST" dealing with the logfile. Put a compile time + switch called SHARELOG in config.h. Define this when history.c is + compiled if logfile sharing amongst processes is desired. + +BUG - system package is not getting defined at cl startup time + parser never sees the 'package' statement in system.cl + + Found it - in decl.c, the procedure procscript() tries to seek to the + beginning of the current line with the statement + + fseek (fp, ftell(fp), 0L); + + This is illegal in UNIX and in IRAF too, since LIBC emulates UNIX + with very few exceptions. What this does is seek to the current + position in the file; the file pointer is not moved. I think the VMS + kernel has a bug. The original SIRM specified that ZNOTTX returns + the offset of the current line, rather than of the next line; + I changed that long ago to be consistent with UNIX and other systems + and sent you all some mail noting the change. + + How many occurrences of this bug are there? + + decl.c: fseek(fp, ftell(fp), 0L); + decl.c: fseek (fp, posit, 0L); + + Only two in CL. Fixed; will fix VMS kernel later. + +BUG - in eparam. Eparam is not catching interrupts. When an interrupt occurs + eparam is simply interrupted, leaving the terminal with echoing turned + off in raw mode, reverse video, etc. Evidently the VMS text file + driver is turning off interrupts in raw mode, i.e., returning + to the program as a character rather than generating an interrupt. + Eparam 'knows' this and hence does not post an interrupt handler. + + The easiest fix is to change the UNIX text file driver to behave the + same way in raw mode. The problem is that editors generally work in + raw mode but do need to be able to catch interrupts. There are some + subtle problems to be solved to provide a nice interface that does + all this. I will make the following changes to the kernels to fix + the problem. + +********************************************************************* +Kernel change + + [1] The terminal is placed in raw mode when ZGETTX receives a request + to read 1 character (rather than, e.g., SZ_LINE characters). + In raw mode echoing is turned off, control codes are not mapped + by the OS driver (e.g. CR to newline on UNIX systems), *interrupt + is disabled and the interrupt code or codes are returned like + any other control characters*, and each character is returned as + it is typed, one at a time. + + [2] Raw mode is terminated when any of the following events occur: + + - When a ZGETTX call is issued to read more than a single + character. + + - When a special escape sequence is "output" with ZPUTTX. + The sequence is arbitrary and should be chosen such that + it does not conflict with the sequences used by the terminal. + The sequence is only recognized when passed as a record, + i.e., ZPUTTX checks for the sequence only if called to write + exactly the number of characters in the sequence. The sequence + is recognized and filtered out whether or not raw mode is in + effect. The actual escape sequence selected is "\e-rAw" + (5 characters) where \e signifies ESC (escape). + + Output of a newline no longer disables raw mode. This eliminates the + need to scan the output for occurrences of newline when raw mode is + in effect. + + +Raw mode is turned on and off by the character count, rather than by a +control function, so that the terminal interface may be totally data driven. +The result of a data driven mode switch is that a process may easily command +raw mode in a remote process or on a remote node in a network, without +complex special control codes. +********************************************************************* + + +os/zfiotx.c (UNIX) + Changed to disable interrupts during raw mode. + +sys/fio/fseti.x + If the operand FD is STDIN fseti(fd,F_RAW,NO) will now send the + sequence \e-rAw to STDOUT followed by a flush to immediately turn + raw mode off. If FD != STDIN but has write permission than the + sequence is sent to FD. + +lib/chars.h + Added a new define called INTCHAR to define the interrupt character + for SPP programs. + +sys/gio/stdgraph/stgrcur.x + Will now terminate the cursor read when INTCHAR is received. The old + interrupt handler was left in for the time being. Also added a + putline call to write two null to the terminal after turning raw mode + off with FSETI, to physically turn raw mode off in case the CL is + interrupted before normal iraf i/o to the terminal occurs. + +pkg/cl/builtin.c + Removed the ifdef vms around the beep, clear, etc. tasks. For the + moment the ifdef remains for the magtape allocation code but I will + get rid of that soon too. + +pkg/system/ + Removed the beep, clear, sleep, and time tasks from this package since + they have been moved into the CL language task. + +pkg/cl/edcap.c + Changed show_edithelp to sort the command list and print it in two + column format using STRTBL (like the package menus). This makes it + easier to find commands in the list, and duplicate entries (e.g., + several different ways of moving down) appear in the same place in + the table. + +pkg/cl/eparam.c + Displaying a large parameter set seemed slow, particularly when + toggling back and forth between the help screen and the parameters. + I tried to speed it up by optimizing the e_display_key routine to + output fewer characters; helped only a little. The name of + E_DISPLAY_KEY was changed to E_DRAWKEY to avoid a name conflict with + E_DISPLAY on systems that only keep 7 or 8 characters of a C identifier. + +pkg/cl/eparam.c + The action EPARAM takes when incorrect input is entered is as follows + (integer value entered for a boolean parameter): + + [1] message is printed at bottom of screen, says respond with + yes or no. + [2] I type anything. + [3] Screen is repainted, then immediately repainted again, + leaving the cursor positioned to the first parameter even + though I was several parameters into the set. + + I tried this on both the (unchanged) VMS system and on the UNIX version + of CL2, with the same results. Certainly this must not be the way + errors are supposed to be handled. + + I changed the error handling code to print the error message at the + bottom of the screen and ring the bell (IRAF uses the bell to bring + errors to the attention of the user), leaving the cursor at the + former keyline so that a different value can be entered. The error + message is limited to one line of text. + +(EPARAM seems to work pretty well now, although I have yet to test the rarely +(used features - multiline prompts, arrays, etc. Now lets have a look at +(EHIST). + + +History Editor +------------------------------------ + + I added an environment variable EHINIT to initialize the history editor, +with "standout", "nostandout", "bol", and "eol" forming the set of currently +recognized switches. If EHINIT is not defined at all then history editing +is turned off and the old CSH style history mechanism is in effect. +The history editor is quite useful for its most common function - editing one +line command blocks - but has some serious limitations, as noted below. +Please note that despite all the criticism recorded here, I feel that the +current history editor fulfills its primary function admirably and am quite +happy with it. + +The current history editor has two major problems: [1] it cannot emulate VI, +and [2], it is not useful for editing multiline command blocks. The editor +as coded knows that is an "insert mode" editor, rather than a "command mode" +editor or an editor which supports both modes. Hence I can prepare an EDCAP +file for part of VI but the commands never get executed, since they are not +escape sequences. There is no mechanism for switching between command and +insert mode, which VI requires. In VI one types "i", "a", "A", "o", "O", +"cw", "r", "s", etc. to insert, add, or change characters. Escape is used +to terminate insert mode and return to command mode. The current string +editor is always in insert mode (it doesn't know about modes). In VI there +is no undelete char, word, line, etc. Instead there is the much more powerful +"undo", which undoes the last modify command, no matter what kind of operation +it was. + +Despite the fact that ehist cannot emulate VI, I was able to prepare an insert +mode, control code type EDCAP file called "dev$vi.ed" which is easy for VI +users to learn to use but which does not emulate VI. This is acceptable for +editing single line history records. + +Editing of multiline command blocks does not work well enough to be useful. +True VI emulation is a must for this type of application. The help feature +does not work for history editing. Upon returning from help the current +line is drawn in the middle of the help text; if editing a command block, +only that one line is drawn and the rest of the block is editable but not +displayed. Tabs are common in command blocks but are not handled correctly +by the editor (they are treated as spaces - I added a klude fix to map them +into spaces so that at least the cursor will be positioned correctly). + +It would be nice if the command block to be edited could be printed at the +current position rather than at the bottom of the screen, although I realize +there are technical problems in doing this. Relative rather than absolute +cursor motions should solve the problem and are more efficient than absolute +cursor addressing. + +My impression from using the history editor and studying the code is that it +may have been a mistake to try to use the same editor for both EPARAM and +EHISTORY. The parameter editor is really quite a different beast, more of +a forms editor than a text editor. All that is really needed for EPARAM are +cursor motions and field replacement (and the help facility). + +I would like eventually to have a history editor which emulates VI and and be +used to edit multiline command blocks. We should strip the current EPARAM +code down, producing a compact package which is used only to edit CL parameter +sets. A general screen editing facility should be generated from scratch +which has no ties whatsoever to EPARAM (it could be called by EPARAM to edit +withing a single field - parameter value- if desired, but not to navigate +about a parameter set). The screen editor subroutine, e.g., SCREDIT, would +take as input a sequence of chars and produce a sequence of chars as output, +using a self contained screen editing capability to perform the transformation. + + scredit (in, out, start, editor) + + int in, out # input and output file descriptors + char start[] # defines initial cursor position + char editor[] # editor language to be used + +Here, IN and OUT are FIO file descriptors which in the case of the CL would +be associated with memory resident strings with STROPEN. START is a string +symbolically defining the position within the file (line, column) to which +the cursor is initially to be positioned. Without further study I cannot say +whether the same code should be used to support both command mode and insert +mode editor languages, or whether two separate codes should be used internally. + +The SCREDIT facility should be coded in SPP and placed in a system library +since it would be self contained and usable in any program, e.g., in a portable +IRAF text editor, or in a DBIO table editor. + +I suggest we leave EPARAM and EHIST much as they are now, for the moment. +I will add the string editor subroutine to the program interface as part +of the DBIO implementation. When this becomes available, the EPARAM and EHIST +code will be restructured to use the new facilities, and we will also be able +to start providing screen editing in the user interfaces to various IRAF +programs. In particular, we will then have a simple but useful text editor +as part of IRAF, usable on all IRAF systems (probably limited to small files, +e.g., < 100K) and usable to edit files resident on remote nodes accessed by +the kernel server (this is a problem we currently face with our network here). +--------------------------------------------------- + +Now we proceed on to the language features. + +1. Packages, Tasks, Parameters + + The CL handling of these checks out ok as far as I could determine. +I tried package loading and unloading, verified that package list was as it +should be, storage is being freed as it should be. The naming syntax +package.task.param.p_field works as it used to. Parameters may be used in +expressions and set in assigment statements as they used to. Have not yet +retested parameter indirection, but we have packages that use it so will +find out soon. + + +2. Expressions + + Simple expressions worked fine, however I did find some problems with +the more subtle forms; these are discussed below in the context of bug fixes. + + +3. Control Flow + + A goto with an undeclared label causes an access violation. Trying to +declare the label (with syntax "label:") caused a syntax error. FOR, BREAK, +NEXT check out. Haven't checked SWITCH CASE yet. + + +4. Procedures + + I could not get procedures to work at all, at least when entered +interactively from the terminal. Perhaps I will try again later, but this +feature is not needed at this point and I have little time. I always get +the message "illegal variable defn's". Typing in a procedure with null +arglist and no declarations caused "illegal parser state" after the "begin". +The declaration "int procedure junk()" was a syntax error. + + By the way, there are two reduce/reduce warnings in the grammar. In case +I don't have time to look into these, I should point out that these usually +indicate a serious problem in the grammar. Shift/reduce conflicts on the +other hand are normal and are no problem provided the precedences have been +defined properly. +------------------------------------- + +pkg/cl/gram.c + The following statements would fail with a syntax error: + + = gcur # cl parameter - global graphics cursor + + I can see that the recent introduction of declarations forces us to + reserve the type specifiers as keywords, else a declaration would + look like a task statement. I could not bring myself to change the + name of either the datatype "gcur" or the global cursor parameter + of the same name, so I built the damn things into the grammar. + I hate to do that but we would have a poorer user interface if we + used different names in the two contexts. Having to reference + "cl.gcur" is not acceptable. The keywords "gcur" and "imcur" are + now recognized in expressions, permitting both "= gcur" and statements + like "print (gcur // 'abc')". The form "gcur=" is however not + permitted. + +sys/clio/clreqpar.x + Changed the form of a runtime parameter request from "param=" to + "=param". Perhaps we can do away with the former type of statement + at some point, as it is no longer used anywhere. This was changed + at this time so that the CL will receive "=gcur" requests rather + than "gcur=" requests; the latter form will now cause a syntax error + since gcur is a keyword marking the start of a variable declaration. + +pkg/cl/grammar.y + The declarations syntax looks more complex than it ought to be. + The parser now has twice as many states as it used to. This is not + necessarily a problem but could indicate a "syntax error" prone + grammar and/or a slow grammar. The last time I profiled the CL the + parser turned out to be the biggest consumer of cpu cycles. + Just turn on yydebug and see how many states it visits to parse a + trivial statement and you will see why. + + NOTES on the grammar: + + [1] The form of an initializer should be "var = const" or + "var = { key=value [, key=value] }", i.e., there should + always be an '=' following the variable or array specifier + if there are any initializations, whether or not these + are compound. + + Always using '=' for initializations should simplify the + grammar, in addition to making the CL consistent with C + and SPP+. + + ------------------------------------------------------------ + [Added Later] On second thought I am not sure about this + one. I can see why the current syntax was chosen - it is + because the initializer is a list of assignments rather than + values as in C. The syntax is that of a structure with + initializers for the individual elements, although it does + not look like it when entered all on one line, e.g.: + + int param { + default = 0, (alias ??) + min = 0, + max = 1, + prompt = "prompt" + } + + I missed that earlier - I guess the syntax chosen is the best + after all. + ------------------------------------------------------------ + + [2] I note that "char" is being used to declare string variables. + This seems wrong; char is an integer datatype in SPP, as in C. + There should be an explicit "string" typespec corresponding + to type "s" in the parameter files. Note that SPP also has + a string type. Syntax, e.g., + + string alpha = "text" (1) + string beta[5] = { "a", "b", "c" } (2) + char zeta[100] = "text" (3) + + In case (1) the length of the alpha string variable is the + default, e.g., 64 chars. In case (2) BETA is an array of + strings, each of the default length. In case (3) ZETA is + a conventional character array as in SPP or C + (****** but the actual amount of storage allocated should + (****** be 101 chars, as in SPP). + + [3] It looked like the grammar included some support for array + constants, e.g., + + int array[n]; + + array = (1,2,3,4) (1) + + or + userproc (a, b, (1,2,3,4), c, de) (2) + + Case (1) assigns an array constant expression to an array + variable. Case (2) passes such a constant in an argument + list. If you folks are already doing that, congratulations, + it is a great idea. By the way, can the N in "[n]" be a + runtime variable or an argument, if "array" is a local variable? + + If we are going to support arrays and expressions involving + arrays in the language (and we already do), then clearly we + need to support array valued constants as well. + +-------------------------------------- +Run time testing +-------------------------------------- + +pkg/cl/builtin.c + Put checking for error status return back in chdir. + Deleted all the _static in the procedure declarations. Why bother? + Static procedures have caused portability problems, and as long as the + iraf procedure naming convention is followed (using a package prefix), + there should be no problem with name collisions with other externals. + Using static procedure names has one very real disadvantage, namely + you cannot debug these procedures normally with the debugger since + the symbol table info aint there no mo. + +pkg/cl/opcodes.c + Deleted all the "_static" and the #ifdef vms. Add an "o_" prefix + to all the opcode function names to avoid name collisions with other + externals. + +pkg/cl/config.h + Deleted the #ifdef vms definition for _static. + +lib/libc/libc.h + No change, just some comments while checking up on LIBC due to a bug. + There were a couple of things in the VMS libc which I did not keep: + defines for u_upkstr,u_upksize (not used anywhere, defined locally + in c_sppstr), and an #ifdef vms to define import_xnames. I suspect + the latter was just because someone got lazy - in any event, iraf + standard does not permit nested includes since I feel include file + dependencies are potentially very dangerous and should be evident + from looking at a file. Also, by avoiding nested includes, it is + easy to prepare the list of dependency files for the Makelib files. + +sys/fio/fstati.x + Was erroneously using "fp" rather than "ffp" when returning the value + of F_MAXBUFSIZE. + +sys/mtio/* +sys/os/zfiomt.c [UNIX] + The datatype of the "drive" argument to the MTIO zz-routines ZZOPMT + and ZZRWMT was changed from integer to character string. This is + consistent with all of the other ZOPEN procedures, and provides more + flexibility in how the drive is named. The magtape naming convention + was also changed slightly to reflect this change, e.g., if the magtape + is named as + + mta.1600[3] + + then file three of magtape unit A will be opened at 1600 bpi. The + former syntax was "mta1600[3]". The significance of the new syntax + is that everything between the "mt" and the "." (or EOS) comprises + the DRIVE string sent to the kernel to access a drive. The contents + of the DRIVE string are therefore no longer constrained to be "a", + "b", "c", etc. and the string may be used to convey additional + information. + + In particular (and this is the primary reason for the change), the + drive string may now contain a node name prefix, permitting use of + a drive on a remote node. For example, to reference logical unix A + on node "draco" (drive "draco@a") either of the following will work: + + mtdraco@a.1600[3] + mt.draco@a.1600[3] + + The syntax "draco@mta.1600[3]" would have been more pleasing and + more consistent with node names in filenames, but the original MTIO + specifications guaranteed that magtape names passed to MTOPEN must + begin with the prefix "mt", hence the former syntax was chosen. + Note that the usual magtape references "mta", "mtb", etc. are still + recognized (the "." delimiter after the "mt" is optional). + +-------------------------------------------------------------------------- +KERNEL CHANGES + +sys/os/zfiomt.c + Change the "drive" argument of procedures ZZOPMT and ZZRWMT from an + integer to a string. Change device table accordingly to permit + table lookup via string match. Use of "a", "b", etc. for logical + drives on a node is still recommended for consistency, although + additional flexibility is now possible. +-------------------------------------------------------------------------- + + +sys/osb/mii.x + Moved each procedure in this file into its own file to avoid loading + the whole thing in each image. Modified the low level routines + MIIPAK16, etc. to be self contained so that they can be called by + the user rather than load the entire package. This involved moving + the byte swapping code into these lower level procedures. + +sys/osb/bytmov.c + This routine had a bug which was never discovered since we use an + assembler version instead on the VAX. Rewritten to eliminate the bug. + +sys/gio/gopen.c +dev/graphcap + Added device "stdvdm" (alias "vdm") to the graphcap. VDM is the virtual + device metafile, used to spool graphics output in a file. GOPEN was + modified to accept "vdm" as an abbreviation for "stdvdm" and to use + a default file ("uparm$vdm") if stdvdm is not defined in the + environment. + +sys/gio/stdgraph/* + Replaced all calls to TTYCTRL with calls to STG_CTRL, to permit use + of graphcap encode/decode instructions in all graphcap entries. + +sys/etc/onentry.x + Bkg filename was not being packed before call to ZOPNTX. Noticed this + in passing; the standard onentry has never been tested as a means for + running iraf tasks in the background. + +------------------------------------------------------------------------------- +Commencing installation of networking software (package KI) +The KI is a sysgen option, not required for operation of iraf. +------------------------------------------------------------------------------- + +sys/ki/ + Added package KI (the kernel interface). + +sys/os/zfioks.c + Added a new device driver ZFIOKS, the kernel server device driver. + This driver is the iraf interface to the networking facilities + provided by the host system. + +sys/cl/prcache.c + Changed the names of the CONNECT and DISCONNECT procedures to PR_CONNECT + and PR_DISCONNECT. The unix networking system library includes a + connect procedure, causing a library conflict. + +lib/knet.h +lib/libc/knames.h +sys/*/*.x + Added to LIB and added includes of this file to all VOS + procedures which do kernel i/o. Added a KNET section to the C include + file . These two include files determine whether or + not a system is to be configured with networking capabilities. + A system can be configured without networking simply by defined + "NOKNET" before knames.h is loaded in a C file and by commenting out + the defines in . + +sys/etc/main.x + The inchan, outchan, device, etc. arguments passed to the IRAF Main + by ZMAIN refer to the real kernel; if networking is used these must + refer to the kernel interface instead. A subroutine call was added + to map these values is networking is in use. This was done in such + a way that the kernel itself did not have to be modified. One of the + goals of the kernel interface design was that the KI shall require no + modifications to the kernel beyond the addition of the ZFIOKS driver. + +sys/etc/envnext.x,environ.x,Makelib + Two new procedures env_first and env_next were added to the environ + package to permit traversal of the environment list by external + programs. + +sys/etc/envscan.x + Changed to use stropen to open the input string as a file, so that + a string buffer containing many set statements may be processed in + a single call. + +sys/fio/getline.x + Getline was assuming that ZGETTX returns an EOS delimited string; + this just happened to be the case with the unix kernel, but is not + required by the si specs. Changed to EOS delimit the string using + the count returned by zgettx. + +sys/libc/ckimapc.c + Added ki_mapchan to LIBC to permit recovery of the host system channel + code or pid and node name in the CL, e.g., for "prcache" output. + Note that when the KI is in use KI channel numbers are returned to + the VOS rather than OS channel numbers. + +pkg/cl/prcache.c + Modified the prcache output display to print both the OS pid in both + decimal and hex and the node name. The display formatting was + improved to eliminate the blank area associated with the hex number. + This code will work the same whether or not the system is configured + with networking enabled. + + The information now printed for each process in the cache is the + following: + + [v] node@pid(pidX) bits processname + + where V is the VOS pid (a small integer, typically one digit), NODE is + the name of the node on which the process is running, PID is the host + pid in decimal, PIDx is the host pid in hex, BITS are the process + status bits (hibernating, running, etc.), and PROCESSNAME is the + name of the process. A process may be flushed or locked by referencing + either the number V or the name of a task in the process. + +dev/graphcap,termcap + Added a new kernel string type parameter DD to the entry for each + plotter or printer. This string is passed to the device driver at + device open time and replaces the device tables formerly given in + kernel.h (and should replace the table used in VMS as well). + + The scenario is as follows: the device open procedure GOPEN, LPOPEN, + etc. (or a graphics kernel such as the NSPP kernel) calls TTY to fetch + the graphcap or termcap entry for the device. The value of the + parameter DD is obtained and passed as the "osfn" argument to the + device open Z-routine, e.g, ZOPNPL or ZOPNLP. + + The syntax of the DD entry is determined by the device driver. For the + existing drivers I have adopted the following syntax: + + :DD=node@device,string,string,...: + + where the comma delimiter may be any character, the value being set by + the first alphanumeric character following the device name. The colon + character : may not be used in the entry, of course, because it is a + termcap metacharacter. The node name and delimiter are optional and + are removed from the string by the kernel interface; the z-routine sees + only the characters following the node delimter character @. + + The two logical nodes names "plot" and "print" are reserved for use to + identify the node to be used to process graphics output or print text. + The graphcap entries, for example, usually reference the "plot" node, + e.g., ":DD=plot@versatec,...". The plot node is identified in the host + name table dev$host (see KI documentation). If no node has the alias + "plot", the default node will be used instead, e.g., the local node. + +sys/tty + Given the above revision, it is no longer necessary to place any system + level information in the environment entries for devices - nobody made + use of that capability in any case. The name parsing code in TTY is + however harmless and will be left in for the time being (in fact I + extended the syntax for some reason before adopting the graphcap type + solution). + +sys/gio/nsppkern + Added support for the DD parameter. The value of this parameter is + now passed to ZOPNPL at device open time; formerly only the device + name string was passed. + +pkg/system/lprint.x + Ditto; added support for DD parameter. + +pkg/images/display/tv/iisopen.x +pkg/images/display/new/iism70/iisopen.x + (throwaway or prototype interfaces). Added explicit node reference + for the IIS so that the affected programs will work on all NOAO nodes. + This is good enough for these interfaces since they are due to be + replaced later this year. The only change required was to replace + the (explicit UNIX) pathname "/dev/iis" with "lyra@/dev/iis". + +lib/libc/kernel.h [UNIX] + The device tables for the plotter and printer devices were deleted + since this information has been moved to graphcap and termcap. + + [Probably there should be printcap, rather than putting the printers] + [in termcap, but that can wait... ] + + +----------------------------------------------------------------------------- +KERNEL CHANGE + +sys/os/zfiopl.c [UNIX] +sys/os/zfiolp.c [UNIX] + Kernel drivers rewritten to obtain plotter information from the ZOPN + argument rather than from the kernel.h table. +----------------------------------------------------------------------------- + +sys/tty/ttyopen.x + In the process of revising graphcap and termcap I found and removed + several unnecessary restrictions on the termcap format. Blank lines + are now permitted, a capability entry may now extend over several lines + and each line need no longer begin with a colon (leading whitespace on + each line is omitted), and the colon character may be included in an + entry via a conventional backslash escape \:. For some reason the + original UNIX termcap format was more restrictive but I see no reason + to preserve these restrictions. + +sys/gio/cursor + If the system failed to open a plotter subkernel during a :.snap the + graphics system would be left in a bad state. This would usually + happen when the user entered an invalid device name for the snap output. + Cursor mode will now recover properly from such an error. + +pkg/cl/builtin.c + Reinstalled builtin task "gflush"; this was lost when the new CL was + installed. + +pkg/cl/errs.c + Reinstalled call to XER_RESET in errs.c to initialize the error stack + when error recovery takes place (necessary since the iraf main is not + being allowed to do error recovery). There should be a LIBC mechanism + for doing this. + +pkg/cl/edcap.c + Had to turn off raw mode to print the editor keystrokes because UNIX + disables output processing of the newlines when in raw mode. IRAF + kernel drivers which have to do such output processing themselves + should also disable such processing when in raw mode, like UNIX. + +pkg/cl/main.c + Added a call to gflush to the shutdown procedure to flush graphics + output and terminate any graphics subkernels when the user logs out. + +pkg/cl/lexicon.c + Added some context mode logic to recognize [] as command mode + metacharacters only when they occur on the left hand side of an + assignment statement. Hence an array reference such as + + v[4] = 123 + + is legal in command mode, as is + + contour m74[*:8,*:8] + + A reference to an array element on the right hand side of an assignment + is legal since the rhs is interpreted in compute mode. An array + reference in an argument list or expression must be parenthesized to + be recognized as such, like *, /, etc. + +sys/gio/cursor/grcpage.x + The help cursor mode feature used to display a "[hit return to + continue]" message at the end of the help screen. This has been + changed to a more informative message which includes prompts for + the hidden keystrokes - in particular it is now easy to get cursor + mode help. + +sys/etc/main.x +sys/clio/clcache.x +sys/fmtio/clscan.x + Added parameter caching to CLIO. The iraf main now permits parameters + to be set on the command line when a task in invoked. If a parameter + is set on the command line when the task is invoked then CLIO will + automatically satisfy all CLGET requests with the cached value of the + parameter without generating a query. + + This is useful for tasks that have many (dozens of) parameters, since + all of the parameters with values set at task invocation time (e.g., + hidden params or params set on the command line) can be cached, + greatly reducing the number of runtime queries to the CL and speeding + task execution. This might save several seconds of clock time when + executing a task with a couple of dozen parameters, since handshaking + over the IPC is expensive. + + Parameter cacheing is implemented in CLIO using the new SYMTAB package, + providing efficient hash table lookup. This was probably not necessary + but I computed the object size overhead associated with using SYMTAB + and it probably only adds 1K or so (SYMTAB is compact). + + The iraf main command line syntax now permits both i/o redirection and + parameter set arguments of the form param=value and param[+-]. + Whitespace delimits arguments. Newline may be escaped for multiline + command blocks. + + For example: + + taskname 3 < $ 6 > mc\ + param1=value\ + param2+ + + This executes task "taskname" indicating that the stdin (pseudofile 3) + has been redirected in the parent (dummy $ filename), stdgraph (6) + is to be redirected by the iraf main to the file "mc", the value + of the parameter param1 is to be set to "value" (may be quoted) and + the value of param2 is to be set to "yes". In the case of a task with + many static parameters the CL will pass a command consisting of many + lines, but it takes only one IPC packet for the entire command block + hence all the parameters are set with no additional expense. + + ----------------------------------------------------------------------- + *** N O T E *** + None of this changes the semantics of CLIO in the slightest and the + changes are all internal. Note however that as soon as the revisions + are made in the CL all executables will have to be relinked before + they can be used with the new CL, or a syntax error will occur due to + the multiline command blocks. + ----------------------------------------------------------------------- + +pkg/cl/exec.c + Modified task execution via pr_connect() to support parameter cacheing. + The startup command is now a multiline command, hence all old + executables must be relinked. I expect that runtime parameter cacheing + will be a significant optimization, noticeable even for tasks with + only a half dozen or so arguments. + +pkg/cl/cl.x +pkg/cl/main.c + Modified to eliminate the reference to the LIBC procedure "c_main", + used to provide the ONENTRY procedure to gain control during process + startup. I moved the ONENTRY into cl.x instead, elimating the funny + backwards linking used formerly. The new configuration is straight- + forward and should be portable. + + At some point I would like to replace this construct by an emulation + of the K&R C main, i.e., with argc,argv. This would not be difficult + and would make it much easier to port C programs to the IRAF + environment. XC and MKLIB, for example, could be nice UNIX/C programs + (actually iraf programs internally) callable from either the host system + or the CL. This has been attempted in the VMS version of softools but + we do not have a good interface yet. + +pkg/cl/main.c + There has been a bug in the system for some time now that goes like + this: [1] interrupt, nothing happens; [2] interrupt again, CL complains + about unknown task `xmit', goes through error recovery; [3] IPC + protocol is trashed and syntax error occurs at next attempt to run + a task in the affected subprocess, [4] flpr and get write to IPC error + from child. I suspect this is due to the way PRPSIO (pseudofile i/o) + handles the input buffer; the buffer pointers are not updated until + sometime after the "xmit" command was first read, and an interrupt in + between states causes the XMIT directive to be read as data by the CL. + The fix was however not to modify PRPSIO, but to call F_CANCEL on the + t_in and t_out to the subprocess in ONINT when X_INT is sent to the + subprocess. + +pkg/cl/prcache.c + In pr_connect, the call to fprintf to format and output the startup + command to the subprocess was replaced by calls to fputc and fputs. + Fprintf has a builtin limit on the size of a %s string which could be + a problem in this application (due to the long list of parameter + assignments). Also, the flexibility of fprintf is not needed and + fputs is more efficient. + +pkg/cl/eparam.c + Recall that in raw mode, no output processing is performed hence + newlines are not converted into crlf. Modified the repaint code + to output \r\n instead of \n (switch to raw mode could also have + been used). + +pkg/cl/history.c + This code was assuming "ehistory" whenever a command beginning with + "ehi" was entered, regardless of the characters following the "ehi". + Hence a command such as "ehinit" would cause ehistory to be run + instead. Changed to do a rigorous match. Any abbreviation is + permitted, including "e", hence ehistory is a very privledged command + indeed (I guess that is what was intended, else the normal minimum + match would have been used instead). + +sys/ki/* +lib/chars.h + The network node delimiter was changed from @ to !, in response to a + request from STScI. Either metacharacter will do just as well, but + ! is a bit easier for a touch typist to type, is used for similar + purposes in other networking software, but is not used in filenames + on any of our major host systems. + +sys/fio/fntgfn.x + Removed the code for the !...! escape notation. The decision has been + made to not implement filename escapes using this notation. + Conventional backslash escapes will be used instead; the code for this + is already largely in place and all we really need to do is test it. + +pkg/system/edit.cl + Tried to write a version of the editor script which uses the new array + stuff to manipulate filename strings. I entered the declaration + + char fname[80] + + to define a character array for holding filename. Turns out the CL + understood an array of 80 strings, each of some default length. + This is supposed to be compatible with SPP? (see notes on string + variables earlier). + + Dropped out into the CL to try some things interactively, since it was + clear I do not understand the new features. Typed a "cl" to push a + new context on the stack; made some declarations; when I typed "bye" + I expected the variables to go away but they did not. Should have. + Tried it again with integer decls and those went away at the bye. + Cannot redeclare a variable within a block; I understand why but should + be able to. + + First decl or so worked but then I got a segmentation violation in + strcmp from paramfind. Did not look into it, perhaps it is a bug I + introduced into the CL. Repeated the experiment somewhat differently + and it worked fine. + + Logged out and back in to initialize things (ugh). Typed "char ss" + to get a char array. Tried "ss = 'abcdef'; =ss" which worked as + expected. Tried "=ss[3]" and it printed the entire string, rather + than just one char. Also, if the [3] is a string rather than char + index, it should have given an out of bounds error. + + Perhaps it was my own undoing (although I don't think I changed much + that could cause such problems), but even without the bugs I think + we have a serious problem here. We need to resolve the syntax and + semantics of these new features before they are released for people + to use. + + Here it is: + + char fname[80] + int i1, i2 + + while (fscan (file_list, fname) != EOF) { + # Determine starting and ending indices of filename. + i1 = 1 + for (i2=1; fname[i2] != 0; i2=i2+1) + if (fname[i2] == '!') + i1 = i2 + 1 + fname = substr (fname, i1, i2) + + # Call host system editor. (wanted to use fname[i1] + # in arglist but didn't dare). + + print ("!!", editor, " ", osflags, " ", fname) | cl + } + + (and I still haven't figured out how to strip node prefixes from + pathnames in the editor). + +---------------------------------------------------------------------------- +Snapshot of system sent to STScI +---------------------------------------------------------------------------- + +dev/graphcap + Set the multifile count parameter MF to one for the dicomed. + The default MF count (16) was causing overflow of the scratch area + since the dicomed frames can be very large. + +pkg/cl/main.c +pkg/cl/history.c + A bus error would occur during CL logout when attempting to close the + logfile. Removed the "ifdef ST" stuff in main.c (when !ST close_logfile + was being closed without the logfile name argument, causing the crash). + Also added error checking and a warning message to the open logfile + code in history.c, in case the logfile cannot be opened. + +sys/os/zfioks.c [UNIX] + The kernel server device driver was modified to post a handler for + X_IPC and X_INT during a read or write on a KS channel. If one of these + signals occurs while reading or writing a KS channel the signal is + caught and converted into an i/o error (status ERR) on the channel. + +sys/os/zfioks.c [UNIX] + The KS driver was further modified to use the user login to authenticate + on a remote node (formerly a fixed public login was used). The login + name and password are taken from a file ".irafhosts" in the user's home + directory on the local node. If this file is not found a similar file + in dev$ is read to obtain the name of a public login. The user may + instruct the system to query for the password rather than risk placing + their password in their .irafhosts file, even though the .irafhosts file + would normally be read protected. + + The format of the .irafhosts file is as follows: + + alias1 alias2 ... aliasN : loginname password + (etc.) + + If the host alias "*" is encountered the login name and password given + in that record are used. If the password "?" is encountered the actual + password is obtained by querying the user terminal (this will fail for + a batch job). Comments lines and blank lines are permitted. + + Since this mechanism is implemented at the OS device driver level it + is considered to be machine dependent, although it expected that a + similar mechanism will be used on non-UNIX IRAF hosts. + +sys/fio/fwatio.x + Modified to mark the file buffer empty if an error occurs on a file + write. If this is not done then close() will try again to flush the + buffer during error recovery, possibly causing error recursion. + +sys/ki/kbzard.x + Fixed a typo, ks_awrite was being called where ks_await was intended. + +sys/fio/awaitb.x + The fill code, used to pad reads out to an integral number of chars, + was being executed even if zawait returned ERR. + +sys/ki/kbzcls.x +sys/ki/ktzcls.x + Modified to not return a close status of ERR if the error bit is set on + the kernel server channel. Close is called during error recovery, and + close would post a second error before the error message associated with + the original read or write error was output. + +sys/ki/ksawait.x + In the event of an i/o error on the kernel server channel, was setting + the error bit on the channel when it should have been calling ki_error() + instead. Because of this the error recovery designed into the KI was + not being exercised. + +sys/ki/kghost.x + The syntax of the host name table was changed to a better form which + is also closer to the form of the irafhosts file. Formerly the format + of a line was + + node@server_startup : alias1 alias2 ... aliasN + + This was changed to + + alias1 alias2 ... aliasN : node@server_startup + + This is more logical since the server startup string is logically a + function of the node names. It is also simpler because the startup + string is delimited by EOL rather than colon, hence it is no longer + necessary to escape colons to include them in the startup string. + +(Rebuilt the image display task and tried it over the ethernet - worked as ) +(advertised. Speed is only slightly slower than a direct connection. ) + + + ******************************************* + *** EDIT *** + *** decent editor interface surfaces !! *** + ******************************************* + +pkg/cl/builtin.c +pkg/system/system.cl + Since the old edit.cl script converts vfn's into pathnames, and + pathnames now include nodenames, it is no longer possible with the + current script to edit files not in the current directory. The edit + script is glacially slow in any case, and offers a poor interface + to the host editor. EDIT has been changed to a builtin task with no + parameter file. The editor name is taken from the environment. + + The argument list is a list of strings. Each argument string is + filtered through FMAPFN to convert VFN's into OSFN's, and then + appended to the OSCMD string with a leading space. Most non-filename + strings are unaffected by the filename mapping, hence system dependent + arguments can be passed through to the host editor. Most importantly, + this interface allows the editor to be called up about as fast as an + OS escape or even a host command language call. + + To edit a list of files (note each file is a separate argument, unlike + most iraf commands): + + cl> ed file1 file2 file3 + + To edit via a template: + + cl> ed *.x + + Note that this template is merely a string to the editor interface, + i.e., it is expanded by the host editor rather than by IRAF. Filename + mapping is passing the character * on through unchanged - it is not + a VFN metachararacter. This is fast and (at least on UNIX) is a much + better interface to the host editor, since the host editor will retain + its context when called once to edit a set of files, but will lose its + context when called N times to edit N files. + +pkg/cl/builtin.c + A new task BACK has been added to the language package. BACK is used + in conjunction with CHDIR (aka cd) to return to the previous default + directory. BACK;BACK toggles between two directories. + +sys/libc/cfpath.c + Added C_FPATHNAME to the LIBC interface (req'd by BACK). + + NOTE -- It would be useful to be able to define "cd" as "chdir", + "pd" as "back", "pwd" as "cd;back", etc., etc., in one's login.cl + file. Given that we now have string pushback in FIO (ungetline) + and general hashed symbol table facilities (SYMTAB), little work + remains to implement DEFINE in the CL. Note that SYMTAB maintains + its database in a position independent form suitable for passing + to bkg CLs. + + BUT -- The semantics of the CL define facility, in particular the + scoping rules, have yet to be worked out. + +pkg/system/system.cl +pkg/system/help/* +pkg/help (defunct) + Moved the HELP directories from pkg$ to pkg$system. Merged x_help.e + into x_system.e. Hence, one executable now contains all of the + system tasks required by the typical user. The intention is that + the x_system.e process be locked in the process cache upon login. + HELP, DIRECTORY, TYPE, PAGE, etc. will then be perpetually available + without having to do a process spawn (although on a busy system + considerable pagein may be required if the process has been idle for + a while). + + TODO -- Rework HELP to use the new SYMTAB package to maintain the + help database. This will greatly speed up the database search, + the main efficiency bottleneck remaining in HELP. + + TODO -- All VMS IRAF process should have a large page fault cluster + (and large working set size) to decrease pagein time, due to the large + text segments involved. Shared libraries would be even better... + +lib/login.cl + Added commands to the default login.cl file to spawn the system proc + and lock it into the process cache (leaving 3 open slots). Also + cached pfiles for directory, help, type, and page. In combination + with runtime parameter cacheing and the fast edit this should produce + a noticeably faster system. + + NOTE -- The MKIRAF host system task should use (does use on UNIX) this + default login.cl file as input. When the new version of the system is + released we should request that all users run MKIRAF to insure that + all the new goodies are functional and that the user's old parameter + files do not cause problems. When installing a new version of the + system it is possible for a user's obsolete parameter file to test + as newer than the package parameter file, since the user's pfile is + updated continually. This can cause a task to abort myseriously with + no obvious connection to the pfile. + +pkg/system/doc/*.hlp + Changed all manual pages to reflect the recent change to command + mode as the default input mode of the CL. The SYNTAX of the command + in the USAGE section is given formally using parens, commas, and + square brackets (for optional args). This is arguable; perhaps the + parenthesis and commas should be dropped from the syntax. Only the + positional arguments are shown in the command syntax. The EXAMPLES + are given in command mode and typical abbreviations are permitted. + + (The System seemed noticeably more responsive when editing all these + (help files.) + + NOTE -- The new manual pages in the language package are written + in style inconsistent with that of the rest of IRAF (not SDAS). + They should either be brought into conformance with the rest of the + system, the standard manual page format should be amended, or some + combination of the above. + + NOTE -- All manual pages for the IRAF applications packages will be + updated within the next couple of weeks. + +BUG IN CL PARSER + While not strictly speaking a bug, this is a serious problem. The + CL recognizes "for", "next", etc. as keywords regardless of their + position in the input text. Use of these strings as parameter or + task name abbreviations or as data strings causes an EXTREMELY subtle + syntax error, which most users will be unable to cope with. Perhaps + some additional context sensitivity in the lexical input is required. + +pkg/cl/history.c + Using the existence of the "ehinit" environment variable to trigger + automatic editing of the recalled command is incorrect. If the user + does not wish to verify and/or edit when using the normal history + mechanism, they should still be able to define EHINIT to set the + parameters for EHISTORY. The solution was to change the history + code to autoedit recalled history records only if "ehinit" is defined + and the switch "verify" is included in its value string, e.g., + + set ehinit = "nostandout eol verify" + + If autoedit is not desired the verify keyword may be omitted, or + alternatively "noverify" may be substituted. + +pkg/cl/history.c + A long standing bug in the history mechanism was fixed. The bug would + cause a history record to be trashed every now and then; the record + would print as garbage and would be unrecoverable. The cause of the + bug was the fetch_history() function, which was unaware that it was + reading from a circular buffer. + +sys/gio/cursor/prpsio.x + Fixed a horrendous bug in PRPSIO that I am sure has been there for + months (the bug is still present in the old system; I have been working + at the system level for ages so was not aware of it). The bug would + cause the CL to hang up during error recovery following an interrupt + of a subprocess. It would be necessary to interrupt twice and then + flush the process from the cache, because the IPC protocol would be + trashed. + +BUG (unresolved) + Twice now the CL has gotten into a funny state where it can no longer + map any filename. This bug is NOT present in the old system. I have + not been able to trace the bug down yet (it does not happen very often), + but it is quite serious as the user must log out when it occurs. + The symptoms are misleading; it appears to be a bug with FILEWAIT but + in fact it is more serious. + +pkg/softools/make.cl + Changed to set IRAFDIR rather than IRAFLIB, since the makefiles now + build all pathnames using IRAFDIR. + +BUG (unresolved) + Once again, when a subprocess died, the CL (which was reading from the + process) was fed garbage input in the form of a single letter duplicated + many times. The lexical analyzer, given this input, tries to build a + very long identifier token and overflows its token buffer, corrupting + memory. This is awkward to fix since the standard LEX lexical analyser + does not do bounds checking. The best solution is probably to not use + LEX, but use a hand crafted lexical analyzer for compute mode (we are + already using one for command mode). YACC is useful, but LEX is + generally not worthwhile for production software. + + NOTE: Infinite error recursion occurs when a parser error occurs + causing error restart. The ERRLEV variable in main.c, used to detect + error recursion, is cleared just before the parser is called under + the assumption that error restart has completed. I have yet to find + any surefire way to detect and prevent error recursion. + +sys/os/zfmkdr.c [UNIX] + The MODEBITS are improper for a directory file. Replaced with a + mode value suitable for a directory file on UNIX. + +---------------------------------------------------------------------------- +Snapshot of system sent to ST. +Identical snapshot (minus binaries) saved in lyra!/tmp2/tody (for diffs). +---------------------------------------------------------------------------- + +sys/mtio/mtgetpos.x + The pointer "drive" was not being dereferenced as "Memc[drive]" in + two procedure calls. + +sys/ki/kopdpr.x + The node name of the second filename argument "bkgfile" was not + being stripped before the call to zopdpr to spawn a detached process + (e.g., bkg cl) on the local node. + +sys/mtio/*.x,Makelib +sys/os/zfiomt.c +sys/ki/(kiextnode.x,kzopmt.x,kignode.x) + The revised MTIO was tested and a number of bugs were found and fixed. + Since I already had to do that I went ahead and changed the drive name + syntax to + + node ! mt... + + The explicit test for a "mt" prefix to determine if a file is a MTIO + file or not (as is currently done in many of the DATAIO programs) is + now considered a violation of the MTIO interface. A new integer + function MTFILE has been added to the interface to perform this test + without need to build explicit knowledge of the filename syntax into an + applications program. + + YES|NO = mtfile (filename) + +-------------- +26 Aug 85 + +sys/gio/cursor/prpsio.x + When reading 0 chars from a stream, would return 0 as function value. + Changed to return EOF when 0 chars are read, since that is what the + caller expects. + +sys/mtio/mtalloc.x,mtdealloc.x + These routines were not dereferencing the pointer "drive". + +-------------- +27 Aug 85 + +sys/ki/kzwrmt.x + Was calling zawrbf when it should have been calling kzwrmt. + +sys/etc/(sysid.x,gethost.x,Makelib) + Added GETHOST; high level interface to zghost. + Added SYSID, used to format labels for various type of output, + e.g., plots. Returns a string which identifies the version of IRAF, + the user, the host machine, and the time and date. + SYSID should be used routinely to label science plots and other output. + +sys/etc/envscan.x + Envscan would truncate the value string at the first whitespace + encountered, even if the value string was quoted. This bug has been + lying there undiscovered since the code was first written. + +sys/fio/fmapfn.x +sys/fio/vfnmap.x + Modified FMAPFN to return a legal host system filename if the file + resides on the local node, i.e., the node name is stripped from the + osfn if the file is local. FPATHNAME should be called if an absolute + pathname, including node prefix, is desired. The packing action of + vfnmap was a nuisance here. Vfnmap was split into two procedures, + vfnmap (unchanged) and vfnmapu (vfnmap w/o packing of the osfn). + Fmapfn now calls vfnmapu to get an unpacked OS filename. (this packing + and unpacking is of course a mess - everything should be unpacked until + the kernel is called). + + [This bug was discovered when trying to edit with "ed lib$*.h" - the ] + [resultant unix command was "vi lyra!/tmp3/unix/lib/*.h" which would ] + [have worked were it not for the node prefix. ] + +--------------------- +28 Aug 85 + +sys/mtio/mtfilspec.x + The generalized magtape name syntax turns out not to be quite upward + compatible with the orignal syntax. An old name such as "mta1600" + must be given as "mta.1600". There is no good reason to subject the + users to such a forced change in the syntax, hence mtfilspec.x was + changed to be compatible with the old syntax while still permitting + general drive name strings. The new rule is: [1] if the first character + following the "mt" is a letter, the drive name is a sequence of letters + delimited by the first nonalpha; [2] if the first character following + the mt is not a letter, it is taken to be the drive name delimiter + character and characters are accumulated until the delimiter is + reached. + + The result is the obvious syntax, e.g.: + + mta, mta1600, mta1600[1], (etc.) # local node + or + node!mta, node!mta1600 # remote node + +sys/os/doc/os.hd + An error in the pathname for the logical directory doc was preventing + access to the OS manual pages via help. + + USAGE NOTE - When you recompile the help database you must flush the + system task (containing HELP) from the process cache before the + changes take effect (the old database may still be in a buffer in + the process memory). + +sys/fio/fwtacc.x + The file wait code was not correctly testing (via FINFO) for a file's + permanent access permissions before entering the wait loop to wait + for access to the file. + +lib/finfo.h + Added defines for the file permission bits. + +sys/clio/clcache.x + If a task has no pfile the CL will send its command line arguments + on in the command line passed to the IRAF main using the parameter + names "$1", "$2", etc. Modified parameter cacheing to support this + type of parameter to avoid unnecessary CL queries. + +------------------- +29 Aug 85 + +sys/imio/imrdpx.x +sys/imio/imwrpx.x + The computation of the max physical pixel index, used to check for + an out of bounds reference, was in error. + +-------------------- +30 Aug 85 + +sys/imio/db/idbpstr.x + A ficticious image header parameter "IM_NAXIS" was being set when + IM_NDIM was clearly intended. + +sys/tty/ttyputs.x + AND was being called with an argument of type CHAR. + +----------------- +3 Sep 85 + +------------------------------------------------------------------------------- +TODO * TODO * TODO * TODO * TODO * TODO * TODO * TODO * TODO * TODO * TODO +------------------------------------------------------------------------------- + This is a continuation of a bug report given earlier. I plan to fix + this sometime in Sep-Oct before releasing the new system (on UNIX) + for general use. + + The bug is the syntax error caused by use of reserved keywords in + expressions and argument lists. This happens with "gcur", "for", + "next", "min", "max", etc., etc. The solution is to add context + sensitivity to crackident(), the function used to turn idents into + keywords. When the parser recognizes a statement it will push a + new context and the lexical analyzer (crackident in this case) will + change its actions accordingly. + + +BUG (cl) + =gcur aborts with an `EOF while evaluating expression' when EOF is + returned in a cursor read. Should just return "EOF". I fixed this + already in the old system and will transfer the fix to the new CL. + + +---------------- +08 Sep 85 + +sys/fio/awaitb.x +sys/fio/await.x + This is not really a bug, but a logical inconsistency. AWAIT, when + called after an AREAD has completed, is supposed to zero fill the + last char of data if the number of bytes read was not enough to fill + a char. The filling operation was being performed in AWAITB instead + of AWAIT, but it does not make any sense for the byte oriented routine + to be zero filling chars. The zero fill code was moved from AWAITB + to AWAIT. + +----------------------- +17 Sep 85 + +lib/fio.h +fseti.x +prpsio.x + Raw mode to the terminal from a subprocess via the CL was not working, + it was never being turned on in PRPSIO. Added code to turn raw mode + on and off to PRPSIO. Moved define for RAWOFF from fseti.x to fio.h + so that it could be used both in fseti.x and prpsio.x. (tested) + +sys/gio/gki/gkigetwcs.x +sys/gio/cursor/gtrctrl.x + Discovered that APPEND mode (gopen) was never tested. In append mode + the subprocess reads the world coord information back from the CL via + the PSIOCTRL pseudofile. gki_getwcs had a bug; I also changed the + operation to return the WCS data without a header on the process CLIN, + which is easier than trying to return a SETWCS instruction via the + pseudofile, as the GIO specs state. Only system code uses the GETWCS + instruction so this mod should not affect any existing software. + +----------------------- +20 Sep 85 + +sys/etc/main.x + The main was calling clc_mark once and then calling clc_free after + each task call to free storage, without doing another mark. This + is illegal because clc_mark calls STMARK which creates a marker + in the symbol table. STFREE frees this marker; calling STFREE + again without another STMARK causes whatever was at the marker + position to be used as if it were a marker, causing the symbol + table pointers to be corrupted. The solution was to add a call + to mark after the call to free in the main, e.g., + + call clc_free (clc_marker) + call clc_mark (clc_marker) + + +------------------------ +27 Sep 85 + +pkg/softools/mktags.x + A new task MKTAGS was added to the softools package. This task will + find all procedures declared in a set of files, printing either + [1] a sorted listing giving for each procedure the name, source + file, line in the file, and the declaration, or [2] a "tags" database + file, used by VI to edit procedures rather than files. + + +------------------------ +8 Oct 85 + +sys/clio/gexfls.x + This file was moved from GIO to CLIO to avoid a library conflict. + The object module is referenced by code in libsys but formerly it + was archived in libex, which is searched before libsys at link time. + +sys/tty/ttyputs.x + PUTC was being called to write the value returned by the integer + function AND, causing an integer argument to be passed to a procedure + expecting a short integer argument. Changed the PUTC to PUTCI. + +------------------------ +9 Oct 85 + +sys/vops/absu.x +sys/vops/Makefile +sys/vops/vops.men +sys/vops/vops.syn +sys/vops/ak/Makelib + Added a new vector operator ABSU for block-summing a vector (like a + block average but not normalized). + +pkg/cl/config.h + The size of the CL dictionary was increased from 15000 to 20000 due + to dictionary overflow in a large script. + +pkg/cl/exec.c + The parameter cacheing code would pass the ")param" literal value of + an indirect parameter, rather than the value of the referenced + parameter. Changed to not cache parameters which are indirect. + +pkg/cl/opcodes.c + When testing the previous bug fix the CL crashed in debug mode due + to an invalid OT_STRING test inside an if(cldebug) block in procedure + o_inspect. Changed to ((p_type&OT_BASIC)==OT_STRING) which should + fix the problem. + +----------------------- +13 Oct 85 + +sys/ki/irafks.x + The kernel server would die on a segmentation violation when it + received a garbage datagram, due to lack of error checking on the + p_sbuflen parameter used to unpack the text buffer. Added a min(SZ_SBUF + to prevent this. + +sys/fio/fredir.x + Added a subprocedure FREDIRO which is like FREDIR, but redirects a + stream onto an already opened stream. (10/23) + +sys/os/zoscmd.c [UNIX] + Minor changes. Will print error message if stream cannot be + redirected. Uses fork instead of vfork when possible for a + little more speed. Moved some code to before the fork in the + hopes of making the apparent ZOSCMD related bug go away; I cannot + find anything wrong with the code nor make it fail in tests. + +sys/os/zpanic.c [UNIX] + Panic shutdown messages from bkg jobs are now echoed on the console + to provide a permanent record. + +sys/os/zmain.c [UNIX] + SIGTSTP is now ignored in bkg processes. Hopefully this will prevent + bkg jobs from being suspended when the CL is suspended. + +sys/os/zmain.c [UNIX] + Bkg processes are now spawned at a reduced priority. + +sys/os/zoscmd.c [UNIX] + The local files of the parent were being inherited by the child (SH), + causing OS commands to fail unpredictably due to no more file + descriptors. Added FCNTL calls to close files >=3 if exec succeeds. + (10/31) + +sys/osb/f77pak.f + OP was not getting set if the loop terminated without seeing the EOS. + (11/4) +---------- +Thu Nov 1 21:23:16 MST 1984 + +1. CL Modifications + + A new version of the system has been released on all three 4.2 BSD UNIX +vaxes at NOAO. The system has undergone major revisions, primarily to +remove UNIX dependencies in preparation for the port to VMS. A number +of enhancements have also been made in the process. Those modifications +or extensions of most interest to the user are summarized below. + +1.1 Process Cache: + + The process cache is the key to good interactive response. While the +operation of the process cache is completely automated and need not be +understood, the sophisticated user can obtain improved interactive response +by tuning the cache. + + prcache show what is in the cache + prcache task [,task] lock a task in the cache + flprcache flush cache (except locked tasks) + flprcache task [,task] unlock a task and remove from cache + +Where "task" is the name of a logical task, e.g. "directory". +When task A is present (locked) in the cache all tasks present in +the same physical process as task A are also cached (locked). +If one locks too many processes in the cache deadlock will occur. +Flushing a task from the cache initializes the process and may +fix certain classes of bugs. + +The process cache is no longer flushed when the current directory +is changed, when the environment changes (except when a +redefinition is uncovered by a bye), or when a task aborts. + + +1.2 Background Jobs: + + Background jobs are submitted by appending & to the command line, +as has always been the case. There is a limit on the number of +bkg jobs that can be running at any one time (currently 4). + + cmd & run command "cmd" in the background + jobs show status of background jobs + service service a query from the last bkg job + submitted + service N service a query from job N + kill N [,M,...] kill job number N + +A bkg job needing service (waiting for parameter input) will +timeout and abort after a set period of time (currently 3 hours). + + +1.3 I/O Redirection: + + Is now compatible with the cshell, e.g., >& to redirect both the +standard output and the standard error output, ditto |& and >>&. +The standard error output of an OS escape issued from a script +task or subprocess is now redirected properly, hence output from +XC and MAKE may be spooled. + + +1.4 OS Escapes: + + !command Now sends "command" to the shell defined by the UNIX + environment variable SHELL or to /bin/sh if SHELL is + not found. The cshell user can therefore now issue + + ! cmd >& spool & + + from within the CL. + + !!command Always sends the command to the Bourne shell (/bin/sh). + + +1.5 Timing Tasks + + The cpu and clock time consumed by a compiled task may now be +measured by prefixing the task name with a $, e.g.: + + set | $sort | $match tty | $count + +The times given are measured by the IRAF Main and hence do not +include the overhead of process initiation if it occurs. This +feature is currently only available for external compiled tasks. +It is not currently available for script tasks, intrinsic +functions, or builtin tasks. + + +1.6 Package Loading and Logout + + The original package loading protocol has returned without the +drawbacks of the original. When you type the name of a package +the package will become the "current package" (first package +searched when looking for a task), the prompt will change to +reflect the new current package, and a "bye" will be necessary +to return to the package. It is no longer necessary to issue +a whole series of "bye" commands to log out of the CL, just +type "logout". + + packages name the packages currently loaded + ?? print menus for all loaded packages + ?sys print menu for (e.g.) package 'sys' + +A package is "loaded" by typing its name, making the tasks +therein known to the CL. Any number of packages may be +simultaneously loaded and referenced without continually +changing the "current package". + +Programmers: use the new "clbye" in package script tasks in +place of "cl" if the "cl" is the last command in the file, +i.e., if there is no epilogue. This saves a file descriptor. +The function of "clbye" is otherwise completely identical to +that of "cl". + + +1.7 The Null File, Standard Streams + + IRAF now has a null file, known as "dev$null". This is useful +for discarding the output of commands. The null file may be +referenced anywhere an IRAF filename may be used. The special +files "STDIN", "STDOUT", and "STDERR" are also quite useful. +These reference the standard i/o streams of the task in which +they are found but may be used wherever an ordinary filename +would be used, including in compiled programs. + + +2. C Runtime Library + +3. New Process Control Facilities + +4. Environment Facilities + +5. Error Recovery + +6. File I/O Modifications + +7. Formatted I/O Modifications + +8. Bit and Byte Primitives + +9. Vector Operators + +10. Kernel Modifications + +11. Configuration Control Procedures + + +### Revision 1.1 Wed Oct 31 23:29:14 MST 1984 + +------------ +From: /u2/valdes/iraf/ Fri 13:49:39 02-Nov-84 +Package: system +Title: WIDSOUT: dataio and multispec packages + +The task 'toiids' in the multispec package has been moved to the +dataio package and renamed 'widsout'. It converts IRAF images to +IDSOUT text format. It is complementary to 'ridsout'. + +------------ +From: /u2/valdes/iraf/ Fri 13:54:22 02-Nov-84 +Package: plot +Title: _imaxes + +The task _imaxes, used in scripts dealing with the sizes and number of +dimensions in images, has been moved from the plot package to the images +package. The plot package automatically loads the images package now. +The reason for this change is that there are possible uses for _imaxes +in scripts, particularly in the imred package, which also use many of +the images tasks but rarely need any of the plot tasks. + +------------ +From: /u2/valdes/iraf/ Fri 13:58:48 02-Nov-84 +Package: images +Title: imcopy and imtransform + +The tasks imcopy and imtransform have been generalized to allow +multiple input and output image templates. The parameter names +are input and output respectively. Each image in the input list +is matched, in order, with each image name in the output list. If +the input image and output image are the same then the operation +is performed to a temporary file in tmp$ and, when the operation is complete, +the temporary file replaces the input image. Image sections are allowed +in the input list and are ignored in the output list. For simple +uses these tasks work just as they did before (except for the change +in the parameter names). This system is also used in imlinefit. + +A help entry is now available for imcopy. + +------------ +From: /u2/valdes/iraf/ Fri 14:05:18 02-Nov-84 +Package: generic +Title: new tasks colbckgrnd and chimages + +The new tasks colbckgrnd and chimages have been added. Colbckgrnd is +a companion to linebckgrnd. They apply imlinefit to determine and +subtract a line by line or column by column background for the specified +images. They supply a generalized form of a function available on the +CYBER. The task chimages is a script application of imcopy and imtransform +suitable for in place modifications of images. This task can trim, flip, +rotate, transpose, and subsample a list of images. The default function +can be set by the user to always perform the same function on the images +(such as a standard trim and rotation). Help entries are available for +these and other generic tasks. + +------------ +From: /u2/valdes/iraf/ Tue 13:13:00 06-Nov-84 +Package: images +Title: shiftlines + +A new task, shiftlines, is available in the images package. It shifts +image lines by a specified amount. There are five choices for the +image interpolation and two choices for boundary extension. See +the help page for further information. + +------------ +From: /u2/davis/ Thu 16:30:26 08-Nov-84 +Package: curfit +Title: curfit mods + +A piecewise linear (SPLINE1) polynomial fitting function has been added +to the CURFIT package. A new routine CVSET can take coefficients derived +external to the CURFIT package and store them in the curve descriptor +for use by the CVEVAL and CVVECTOR routines. + +------------ +From: /u2/davis/ Thu 16:35:58 08-Nov-84 +Package: local +Title: Imsurfit installed in local + +A new task, IMSURFIT, which fits surfaces to IRAF images has been +added to the local package. See manual pages for more documentation. + +------------ +From: /u2/valdes/iraf/ Fri 10:12:52 09-Nov-84 +Package: multispec +Title: New parameter in findpeaks + +A new parameter, edge, was added to the task findpeaks. This parameter +specifies a minimum distance to the edge of the image for peaks found. + +------------ +From: /u2/tody/ Sun 21:29:59 11-Nov-84 +Package: cl +Title: parameter indirection, enumerated values + +Two new features affecting parameter access have been added to the CL, +parameter indirection and enumeration of the legal types of a string valued +parameter. + +1. Parameter Indirection + + Parameter indirection allows a parameter to take any combination of its +value, minimum, or maximum fields from another parameter. Indirection is +signalled by an '@' prefixed field in the parameter file, e.g., + + order,i,h,@param + +specifies that the value of parameter "order" is the value of the parameter +"param", which is located by the usual search path (task, package, cl). +More general forms include + + order,i,h,@task.param +and + order,i,h,@pack.task.param.field + +The taskname of the current package my be specified by the shorthand name "_", +e.g.: + + order,i,h,@_.order + +states that the default value of the task parameter "order" defaults to the +same value as the package parameter of the same name. + +Minimum and maximum fields may be specified in the same fashion, e.g.: + + alpha,i,h,5 + beta,i,h,10,@alpha + +Indirection may be overridden permanently via an assignment statement or +temporarily on the command line. + + +1.1 Caveats + + Indirection requires string storage for the p_value, p_minimum, and +p_maximum fields of a parameter. String storage for these fields is +allocated only if indirection is specified in the parameter file (except +for the value field of a string parameter which is always allocated string +storage of SZ_FNAME chars). In general a parameter may not be made indirect +after loading the parameter file. + +Multiple indirection is permitted. Infinite recursion will occur if a +field of a parameter indirectly references itself. A field of a parameter +may indirectly reference another field of the same parameter. + +Implementing parameter indirection was surprisingly difficult and involved +substantial modifications to the CL. The most common cases have been +tested but further bugs caused by these modifications can be expected to +turn up. + + +2. Enumerating the Values of a Parameter + + The legal values of a string type parameter may now be enumerated in +the parameter file. For example, + + device,s,a,"mta","mta|mtb|tty" +or + order,s,a,"5","3|5|7" + +The CL will accept only values enumerated in the list found in the p_minimum +field. Minimum match abbreviations are permitted, with the CL always +returning the full value of the matched substring. While enumeration of +values is currently supported only for string valued parameters, integer +values may be stored as strings (with restrictions on the use of such a +parameter in CL expressions) as shown in the example above. + +------------ +From: /u2/tody/ Sun 22:23:42 11-Nov-84 +Package: cl +Title: parameter file names in UPARM + +The underscore has been omitted from the parameter file names stored in +the UPARM directory. Old parameter files can no longer be referenced and +the contents of the UPARM should therefore be deleted. + +------------ +From: /u2/tody/ Sun 22:26:34 11-Nov-84 +Package: cl +Title: command mode versus compute mode in the CL + +A new lexical analyzer has been added to the CL to permit a more terse +mode for entering simple commands. The CL now distinguishes between two +distinct modes of command input, known as "command mode" and "compute mode". + + +1. Command Mode + + Command mode is useful when interactively entering commands because it is +the most terse mode of input. There are few special characters, most strings +do not have to be quoted, and command arguments are delimited by whitespace +rather than commas. Command mode is permitted only when working interactively, +i.e., it is turned off when running a script task or an external compiled +task. The features of command mode are summarized below: + + o Unquoted strings may contain any nonwhite character except "'\(|><{};=#. + The characters !^&+- may be embedded in strings but are recognized as + the OS escape, history metacharacter, etc. when the occur in the + obvious context. + + o Whitespace delimits arguments, not comma. Commas may be embedded + within argument strings. For example, + + delete file1,file2,file.* v+ + + would delete all files matching the template given as the first + argument with verification enabled. + + o The sequence \c is replaced by the character c. A lone \ at the end + of a line causes continuation on the next line. Quotes may also be + used to escape characters but a quoted string is a distinct token + (e.g. argument or value). + + o The OS escape need no longer appear at the beginning of an input line + of text, e.g., sequences such as "time;!w" are now permitted. Newline + may be escaped when building up long OS escape commands. When not used + to escape newline the escape character is left alone, i.e., \c equates + to \c. An unescaped newline marks the end of the command. + + o A string constant appearing on the righthand side of an assignment + statement need not be quoted. Only the simple assignment statement + is recognized in command mode (i.e., += etc are not recognized). + +The command mode syntax is consistent with the that of many command languages, +including the UNIX shell and cshell, and VMS DCL. + + +2. Compute Mode + + The original command form of the CL is now known as "compute mode". +In compute mode arguments must be delimited by commas and general expressions +are recognized. Compute mode is automatically entered in any of the following +circumstances: + + o Within parentheses. Compute mode expressions may be embedded within + command mode commands. + + o Within braces. Command mode is turned off in a compound statement, + e.g. within the body of a while loop. + + o Within scripts or when executing an external compiled task. Command + mode may not be used within a script; the old compute mode scripts + need not be changed. + + o When the CL parameter "lexmodes" is set to NO. This is currently the + default since command mode is not fully tested and the documentation + all pertains to compute mode. + + +3. CL Syntax + + The grammar (syntax) of the CL is the same for both command and compute +mode. Mode switching is implemented by two separate lexical analysis filters. +The lexical filter to be used depends on the runtime context and is selected +upon entry to a command block. + +The only change to the grammar of the CL made to implement command mode was +the elimination of the need to quote a string constant appearing on the right +side of an assignment statement. String constants appearing in assignment +statements within braces ({}) must be quoted regardless of the lexical mode +of the CL. Conversely, a parameter name appearing on the righthand side +of an assignment statement outside of a block must be enclosed in parenthesis +to be interpreted as a parameter name rather than as a string constant. + +This change affects any existing CL scripts which assign a parameter to a +parameter outside of a brace delimited block. Within a block the syntax +and lexical form of the CL is that of a conventional programming language. + + +### Revision 1.1 Mon Nov 12 04:42:52 MST 1984 + + +### Revision 1.2 Tue Nov 13 04:10:28 MST 1984 + +------------ +From: /u2/tody/ Wed 10:42:07 14-Nov-84 +Package: system +Title: help for the system package + +Thanks to Richard Wolff, manual pages have been installed for the tasks +in the system package. + +------------ +From: /u2/tody/ Wed 20:46:43 14-Nov-84 +Package: plot +Title: graph mods + +The x-clipping feature lost during the switch to the new system has been +restored. If xautoscale is turned off and ux1,ux2 are set to points within +the plot, no data is plotted to the left or right of the window. + +The default value of the parameter "title" has been changed from "@imtitle" +to simply "imtitle". The @ was causing parameter indirection with the +result that graph could not find the parameter "imtitle". + +This points out a serious weakness of the parameter indirection scheme; the +value of a parameter may no longer begin with an @ as a normal character. +On the other hand it is nice to be able to respond to a query with @param. +This will have to be resolved at some point, hence the current scheme for +implementing parameter indirection must be regarded as experimental. We are +committed to having the capability, but how it is implemented may change. + +------------ +From: /u2/tody/ Wed 20:54:07 14-Nov-84 +Package: cl +Title: bug fixes + +The bug involving INDEF's in parameter files has been fixed. The new MAGNIFY +task and others like now work properly again. Beware that if you ran any of +these tasks while the bug was active, the parameter file may have to be +unlearned. + +------------ +From: /u2/tody/ Wed 20:56:30 14-Nov-84 +Package: system +Title: allocate, deallocate bug fixes + +The system tasks allocate and deallocate had two bugs related to the system +modifications made last weekend. They should be working properly now. + +------------ +From: /u2/tody/ Wed 22:57:26 14-Nov-84 +Package: cl +Title: cl bug fixes + +The following CL bug fixes have been made. Examples of statements that +formerly did not work are shown. + + +Bugs in the new lexical analyzer (lexmodes=yes): + + [1] spawning background tasks (& at end of line), e.g., + + make >& spool & + + [2] what is a number, e.g., + + x = .5 + + [3] the ? and ?? tasks work again. ? anywhere but at the beginning + of a statement is not special, i.e., ? can be embedded in strings. + + +Assignment statement bugs: + + [1] both of the following would formerly fail: + + s1 = [*:16,-*] + and + s1 = identifier + +Other: + + [1] An invalid CD or CHDIR is no longer passed to a child process. + This turned out to be a kernel bug rather than a CL bug, but + should not affect processes other than the CL. + +------------ +From: /u2/tody/ Tue 22:02:07 20-Nov-84 +Package: fio +Title: freadp, fwritep added + +The two i/o procedures FREADP and FWRITEP have been added to FIO to support +direct access by IMIO of pixel data in the FIO buffers. These new procedures +are useful in operations where performance is critical, but usage is a bit +tricky hence their use in applications code is not recommended. + + charp = freadp (fd, offset, nchars) + charp = fwritep (fd, offset, nchars) + +Both routines cause the FIO buffer to be filled with the file buffer sized +file block containing the portion of the file starting at "offset" and +extending for "nchars" chars. The referenced segment must fall entirely +within a file buffer. An error action is taken if offset+nchars falls +at a point outside the file buffer, or if the segment referenced is beyond +BOF or EOF. A char pointer to the first char of data is returned as the +function value. The referenced data must be used before FIO reuses the +file buffer for a different region of the file. + +Successive calls to data segments lying within a single large buffer, i.e., +which do not result in a file fault, cost about 180 microseconds per call +for FREADP and 240 microseconds per call for FWRITEP on the VAX 11/750. +No seek is required since the file offset is included in the call. + +------------ +From: /u2/tody/ Tue 22:19:22 20-Nov-84 +Package: plot +Title: plot expansion in GRAPH + +The modifications to GRAPH made to permit proper autoscaling in Y when +specifiying an X subrange of data to be plotted were lost in the disk +crash over the weekend. This mod has been repeated and plots should be +properly scaled when GRAPH is used to expand a portion of a plot. + +------------ +From: /u2/valdes/iraf/ Thu 17:37:39 06-Dec-84 +Package: images +Title: Enhancements to imarith + +Imarith has been greatly enhanced. The enhancements are in performance, +flexibility, and use of lists for operands and resultant images. +Performance has been enhanced by providing type specific operators +to perform the operation in any desired datatype. If the calculation +datatype matches the operand and result pixel datatypes then no +datatype conversions are performed and the operation is particularly +efficient. The flexibility enhancement allows the user to select the +pixel datatype of the resultant image(s) and the calculation datatype(s). +Specially recognized datatypes allow defaulting to the datatype of +highest precedence from the operand images or to the datatype of +either operand. The list enhancement allows either operand to be +a list of images and constants (they can even be mixed). The +result parameter can also be a list of images. The number of +operand elements can be either one (in which case it is used repeatedly) +or match the number of elements in the result list (in which case +the elements are match one-to-one). + +It is also possible to have the result image match one of the operand +images (apart from sections). In this case the operation is performed +to a temporary image and, when completed successfully, the temporary image +replaces the operand image being overwritten. + +There are options to print the operations being performed as diagnositics +and to print the operations without performing the operation for debugging. + +------------ +From: /u2/valdes/iraf/ Thu 17:47:55 06-Dec-84 +Package: images +Title: Enhancements to imcopy + +Imcopy has been enhanced to use general image template lists. The +number of input images can be either one (in which case the input +image is repeatedly copied to each element of the output list) or +or match the number of output images (in which case the image lists +are matched one-to-one). If the input image and output images are the +same (except for sections) then the copy is performed to a temporary +image and, when completed successfully, the temporary image replaces +the original input image. + +------------ +From: /u2/tody/ Fri 18:09:13 07-Dec-84 +Package: imio +Title: optimized version of IMIO installed + +Testing of the optimized version of IMIO has been completed and the new +interface installed. The optimizations improve the efficiency of line by +line i/o, the most common type if i/o to images. In short, the overhead +required to access the pixels will be minimal provided no image section is +given, datatype conversion is not necessary, there is only one input line +buffer, boundary extension is not in use, bad pixels are not being set to +INDEF, etc. If all these conditions are true IMIO can skip a lot of code +and the pointer returned by a get/put line or section call will point +directly into the FIO buffer, eliminating a memory to memory copy. If any +of the fancy IMIO options are used additional expense will of course be +incurred. There is little difference in the timings for the integer and real +datatypes. + +All modifications to IMIO were internal to the interface, hence only relinking +is necessary to take advantage of the increased efficiency provided by the new +interface. The IMAGES and TV packages have been relinked. Loading a 512**2 +type short image into the image display now takes only 2-3 cpu seconds in +the simplest case (ztran=none). Clock time for this image load operation is +still a minimum of 10-12 seconds due to the limitations imposed by the UNIX +file system. Image arithmetic operations typically require several cpu seconds +per operation. The inefficiencies of the UNIX file system will be overcome when +a low level IRAF static file driver is implemented for 4.2BSD UNIX in coming +months. + +------------ +From: /u2/tody/ Fri 19:04:42 07-Dec-84 +Package: imio +Title: image sections + +Minor changes have been made to the image section code in IMIO to make the +section notation more deterministic and to remove unecessary restrictions on +the use of sections. A section of the form [5] no longer refers to the +highest physical dimension of the image; this was nondeterministic and +required advance knowledge of the dimensionality of the image. In the new +release of IMIO the number of dimensions referenced in an image section need +not match the number of physical dimensions in the image. If too few +dimensions are specified in the section then the higher dimensions will be +set to 1. If too many dimensions are specified then the higher dimensions +must be set 1 explicitly or it is an error. + +For example, if A is a 2-dim image, A[10:20] is equivalent to A[10:20,1], +i.e., the section is 1-dim. If B is 1-dim B[*,1] is a legal section but +B[*,2] is not. + +------------ +From: /u2/tody/ Fri 19:12:41 07-Dec-84 +Package: libsys +Title: error recursion + +A bug has been fixed in etc$xerfmt.x which would cause error recursion when +error recovery occurred under certain circumstances. The error recovery +code was calling ENVGETS, which takes an error action under certain +cirumstances, causing error recursion. The call to ENVGETS was replaced +by a call to ENVFIND which is functionally identical but does not query or +abort if it cannot find an environment variable. + +------------ +From: /u2/tody/ Sat 14:41:37 08-Dec-84 +Package: lprint +Title: bug fix + +The bug which caused LPRINT to output garbage following the normal text has +been fixed for the second time. Evidently this bug fix was lost in the disk +crash in November. + +------------ +From: /u2/tody/ Sat 14:44:32 08-Dec-84 +Package: libsys +Title: process control bug fix + +Error checking was missing in PROPEN, used to open a connected subprocess. +This would cause a segmentation violation in the CL when trying to open +a nonexistent executable process file. + +------------ +From: /u2/hammond/iraf/ Mon 10:58:21 10-Dec-84 +Package: dataio +Title: wtextimage installed + +Task wtextimage has been installed in the dataio package for converting +IRAF images to text files. The text file written consists of an optional +FITS header followed by the pixel values. + +------------ +From: /u2/tody/ Mon 17:16:57 10-Dec-84 +Package: cl +Title: flprcache bug fix + +The flprcache (flush process cache) task had a bug that caused it to flush +only the top process from the cache. The corrected function is to flush +all processes not locked in the cache (locked processes can be flushed if +a flag is set to break the locks). + +This bug may have been responsible for background jobs leaving dreg processes +running after termination of the bkg CL. + +------------ +From: /u2/tody/ Wed 10:33:48 12-Dec-84 +Package: images +Title: new package IMDEBUG + +A new subpackage IMDEBUG has been added to IMAGES. This is a slightly +cleanup version of the image i/o debugging tasks formerly stored with the +IMIO source. Tasks MKTEST and CUBE are particularly useful for testing +image operators. No param files or manual pages are presently available +for these routines. + +------------ +From: /u2/tody/ Wed 17:45:55 12-Dec-84 +Package: IMIO +Title: bug fix + +The new (optimized) version of IMIO had a bug which was not discovered and +fixed until today. The bug would cause image sections to be ignored (in +effect). + + +------------ +From: /u2/tody/ Wed 17:48:47 12-Dec-84 +Package: images +Title: IMCOPY can now mosaic images + +IMCOPY has been modified to permit use of an image section on the output +image, which must be an existing image if a section is used. The input +image or image section will be copied into the output section. Both +sections must be the same size. This facility is particularly useful for +mosaicing images, i.e., placing several small images into a larger image +to form a single large image. + +------------ +From: /u2/tody/ Tue 15:35:41 18-Dec-84 +Package: libbev +Title: bug fix in regres.f + +The Bevington library procedure REGRES had an error in the Fortran source +(a * that should have been a **) causing the coefficient errors to be +computed incorrectly. The bug has been fixed and the task POLYFIT in +local relinked to use the new version of the library. + +------------ +From: /u2/tody/ Thu 21:09:02 20-Dec-84 +Package: fio +Title: filename mapping bug fix + +The FIO filename mapping code had a bug which caused the mapping file (used +for long filenames) to be corrupted when deleting a file with a name too +long for the host OS. The mapping file would be unreadable with a checksum +error following the deletion. The file vfnmap.x was modified in two places +to fix this bug. This bug was discovered by the guys at STScI in the +process of testing the new VMS version of IRAF. + +------------ +From: /u2/tody/ Thu 21:12:16 20-Dec-84 +Package: system +Title: obscure bug in the IRAF Main + +The IRAF Main, when passed a command using i/o redirection on the command +line, would include the newline in the filename used for redirection. +The code which extracts the filename was modified to recognize newline as +a filename delimiter. + +------------ +From: /u2/tody/ Mon 13:42:05 24-Dec-84 +Package: fio +Title: bug fix in the filename mapping code + +The filename mapping package had a bug causing the mapping file to be left +open when opened for writing but never modified. Procedure vfnclose in +file fio$vfnmap.x was modified to close and unlock the mapping file in +this case, as well as when it is modified and has to be rewritten. + +------------ +From: /u2/tody/ Mon 15:20:45 24-Dec-84 +Package: spp +Title: portability problems with INDEF + +Equality comparisions of the form + + if (pixval == INDEF) + ... + +involve a comparison of two floating point numbers for equality and hence may +not be portable to some machines or to some compilers. The following macro +has been added to the SPP language definitions to make such constructs more +portable: + + bool = IS_INDEFt (value) + +where the "t" stands for one of the standard type suffixes. One such macro +is provided for each data type, e.g., IS_INDEFS, IS_INDEFR, and so on. The +macro IS_INDEF with no type suffix is equivalent to IS_INDEFR. All programs +which make equality comparisons involving indefinites should eventually be +converted to use these new constructs. + + +### Revision 1.3 Mon Dec 24 22:13:31 MST 1984 + +------------ +From: /u2/valdes/iraf/ Thu 10:58:27 27-Dec-84 +Package: local +Title: imreplace + +Imreplace has been changed in several ways: + +1. There is no output file. The replacement operation is done in place. +2. The input images may have sections to select the part of the image to + be operated upon. This eliminates the need for the column parameters. +3. The lower and upper limits are hidden parameters. +4. The operation is more efficient. + +------------ +From: /u2/tody/ Wed 19:30:38 02-Jan-85 +Package: fmtio +Title: procedure CTOR added + +A new procedure CTOR has been added to FMTIO. This procedure merely calls +CTOD and is provided for the sake of convenience, to avoid having to deal +with double precision numbers in simple conversions. + +------------ +From: /u2/tody/ Thu 18:54:36 03-Jan-85 +Package: images +Title: magnify parameter file replaced + +The parameter file for the task MAGNIFY somehow got filled with zeros. +I copied the version of the file from /u2/valdes/iraf/images into +pkg$images. + +------------ +From: valdes$iraf/ Fri 17:42:46 04-Jan-85 +Package: images +Title: magnify + +Magnify has been fixed. The bug dealt with changing + +delta = (x2 - x1 ) / (npix - 1) + +to + +delta = (x2 - x1 + 1) / npix + +------------ +From: /u2/tody/ Fri 21:06:39 04-Jan-85 +Package: system +Title: new system functions + +Two new system functions, LOCPR and LOCVA, have been added to the ETC package. +These integer functions are more convenient to use than the subroutines ZLOCPR +and ZLOCVA, and they eliminate the need to call the kernel routines directly +in the higher level packages. Use of these new functions should probably be +restricted primarily to system code. + +------------ +From: valdes$iraf/ Thu 15:25:53 10-Jan-85 +Package: images +Title: imstatistics + +When using a large number of pixels the accumulation of the sum of the +pixel values and the sum of the squares of the pixel values may suffer +from roundoff error. This causes the standard deviation to be zero when +the true standard deviation is less than a percent of the mean. This +has been improved by changing to accumulation in double precision. + +------------ +From: /u2/tody/ Fri 12:38:59 11-Jan-85 +Package: system +Title: removal of filename restriction in IRAF Main + +The IRAF Main formerly restricted filenames in the context + + task > filename + +to only those filename beginning with a letter. This prevented the use +of pathnames such as ../filename. The restriction has been removed and +now the filename may contain any characters except whitespace, newline, +or the redirection characters. + +------------ +From: /u2/tody/ Mon 10:43:09 14-Jan-85 +Package: system +Title: GIO installed + +The new GIO (graphics i/o) interface has been installed in a system library. +Up to date documentation is available in gio$Gio.hlp. GIO is functional in +the sense that the library is complete and programs written to use GIO can +be compiled and run. The CL has not yet been modified to interactively +interpret GIO metacode, however, so GIO can only be used at present to spool +metacode into a file. Metacode produced in this fashion can be decoded with +the GKIDECODE task in "gio$stdgraph/x_kernel.e" for debugging purposes. +The task STDGRAPH in the same process is a mockup of the stdgraph kernel, +and may be used (noninteractively) to make crude plots on the terminal from +GIO metacode. + + +### Revision 1.4 Tue Jan 15 04:57:57 MST 1985 + +------------ +From: valdes$iraf/ Wed 17:45:04 16-Jan-85 +Package: images +Title: new output type for imlinefit + +A new output type for imlinefit has been added. The output type is called +normfit. It outputs the fitted line normalized to have a unit mean. This +is used to generate calibration corrections; for slit profiles in longslit +spectroscopy in particular. Also the output pixel type is now always real. + +------------ +From: /u2/tody/ Wed 18:15:15 16-Jan-85 +Package: cl +Title: bug affecting list structured parameters + +A bug fix has been made to 'paramset' to permit setting the filename of a +non-string datatype list structured parameter. This bug was the source +of the problems experienced earlier this week with NORMALIZE and NORMFLAT +(generic package). + +------------ +From: /u2/tody/ Mon 23:09:30 21-Jan-85 +Package: system +Title: error recovery bug fixes + +I spent several hours tracking down several of the "bugs" that have been +annoying us when interrupting subprocesses. Specifically, a task will now +stop spewing out output immediately when interrupted, and interrupt should +no longer get stuck off. + +Software modifications: + + [1] etc$main.x + Added an fseti call to cancel STDOUT during error recovery. + + [2] cl$pfiles.c + Failure to write pfile was a fatal error for some reason; changed it + to an internal error. + + [3] cl$main.c + Calls added to the ONINT interrupt handler for the case interrupt + of a subprocess: + + c_fseti to cancel stdout + c_prredir to redirect stdin, stdout, stdgraph to 0. This causes + etc$prfilbuf to ignore pseudofile directives buffered in + IPC at the time the interrupt occurs. + + [4] fio$fseti.x + The F_CANCEL code in fseti formerly did an LNOTE, LSEEK before + and after clearing the buffer, to preserve the file offset. + Removed these to force iop to point to beginning of buffer if + i/o cancelled. + + [5] cl$prcache.c + If a process was interrupted during startup IPC would be trashed, + causing endless "IRAF Main: unknown task name" errors from the + subprocess. Make the call to c_propen in cl$prcache.c a critical + section to prevent interrupt of the child process until startup + is completed (a critical section is a section of code which is + uninterruptable). The effect of this is noticeable: a ctrl/c typed + immediately after entering a command which causes a process to be + spawned will be ignored. + + In the process of fixing this one I discovered a flaw in the + exception handling code, which is patterned after the UNIX "signal" + facilities. The idea was that one could call + + xwhen (signal, newhandler, oldhandler) + .... + xwhen (signal, oldhandler, junk) + + with some code in between, and the oldhander would be restored by + the second call. This does not work if the code in between calls + XWHEN for the same signal. + + [6] os$zxwhen.c + A bkg process is spawned with SIGINT disabled. ZXWHEN would check + to see if the signal was disabled when posting a new one. If the + signal was disabled it would ignore the posting and leave the signal + disabled. The bug occurred when ZXWHEN was called to disable the + signal temporarily to protect a critical section; once turned off + a handler could never be posted. Added a "first_time" flag to make + the test only in the first call to SIGNAL for SIGINT. + + +Zombie processes are still occuring. I found and fixed a bug some time ago +which may have solved this problem, but many tasks have yet to be relinked +and hence the fix has not been propagated. I will relink the whole system +when the visitors currently using the system finish their reductions. + +------------ +From: valdes$iraf/ Tue 09:04:28 22-Jan-85 +Package: images +Title: New task blkaverage + +A new task specifically for block averaging two dimensional images has +been added. + +------------ +From: valdes$iraf/ Tue 09:07:32 22-Jan-85 +Package: images +Title: Bug fix in sigl2 + +A bug in the sigl2 package for image block averaging and linear interpolation +has been fixed. The partial blocks at the ends of the image were not +being truncated so that the code was trying to read outside the image. +This package is used in magnify and display. + +------------ +From: valdes$iraf/ Thu 17:33:02 24-Jan-85 +Package: local +Title: fixpix + +A new task called fixpix has been added to the local package. It +replaces pixels in a set of bad pixel regions by linear interpolation +from nearby pixels. The bad pixel regions are specified via a file +(which may be STDIN) by lines of four coordinates consisting of the +first and last columns and the first and last lines of the bad region. +The direction of interpolation is determined by the shape of the region; +i.e. it interpolates across the narrower dimension of the bad region. +This task should be very useful in imred type applications for detectors +with consistent bad full and partial columns and lines. + +------------ +From: /u2/tody/ Thu 20:25:18 24-Jan-85 +Package: system +Title: more bug fixes + +Many bug fixes have been made in the past two days to make the system more +reliable, particularly where error recovery is concerned. A summary of +the software revisions follows. + + [1] fio$xerputc.x + Would overrun buffer if called repeatedly without a newline terminator. + Modified to flush buffer when it fills, even if newline not seen. + Buffer overrun was supposed to be impossible, but it turned out it + could happen during error recursion. + + [2] etc$erract.x + More logic was added to improve the heuristic for detecting error + recursion. + + [3] cl$builtin.c + The CLERROR procedure was modified to pop the last task off the + control stack. Both BYE and ERROR signal task termination. It is + necessary to pop the task to keep KILLTASK from sending X_INT to + interrupt a task which has already terminated, if the task is an + external executable. + + [4] os$zxwhen.c (UNIX kernel) + The SIGTERM signal was getting blocked after the first exception, + causing the process to become uninterruptable. For some reason + UNIX identifies the signal as SIGINT in the argument list of the + exception handler, even though it is the SIGTERM signal which + was caught. The handler would unblock SIGINT rather than SIGTERM, + leaving SIGTERM blocked. + + [5] cl$errs.c + The ONINT cl interrupt handler is now reposted whenever CL_ERROR is + called. This is necessary as CL_ERROR might be called while interrupts + are disabled in a critical section. Additional logic was added to + detect error recursion. The tests for an error occurring during + process startup or shutdown were moved to the beginning of the + procedure. + + [6] etc$main.x + Modified to block interrupts during process startup, to prevent + loss of sync of the IPC protocol. Added F_CANCEL calls for the + standard streams during error recovery. Added a call to repost + the standard exception handlers during error recovery (this will + reenable interrupts if error recovery takes place while interrupts + are blocked). + + [7] cl$exec.c + The test to prevent "bye" from logging out of the CL was not working + due to a precedence error in the test for a bkg CL. The CL will once + again print the "use 'logout' ..." message if one accidentally types + "bye" in the CL menu. + + [8] cl$main.c + The ZDOJMP jump buffer of the IRAF Main is now restored when the CL + main exits, in case an error occurs during process shutdown. + A bug was fixed which would cause the LOGGINGOUT flag to be cleared + when EXECUTE was called to process the logout.cl file. + New routines INTR_DISABLE, INTR_ENABLE were added to make it + convenient to protect critical sections of CL code. + + [9] cl$prcache.c + The STDGRAPH stream of a task is now initialized to STDOUT by + default when an external task is connected. + + [10] cl$pfiles.c + Writing a parameter file is now a critical section to prevent + learning of truncated parameter files. + + [11] cl$bkg.c + The command to be executed in the background is now saved in the + bkg file header to permit spying on what the task is doing with + the octal dump program. Use PS to get the pathname of the bkgfile + and then "od -c" to print the first few bytes of the file. + + [12] cl$bkg.c + Various critical sections were identified and protected. + The filenames of the bkg query files are now generated and deleted + at bkg job spawn time, just in case there are any dreg files left + over in uparm from a previous bkg job. If this were to happen + JOBS might print a misleading status for the job. + + [13] fio$ delete.x, falloc.x, fmkcopy.x, frename.x, filopn.x + All code segments that have the VFN database opened for writing + are now critical sections, and all error checking in these sections + is done explicitly. This is necessary to prevent an interrupt from + corrupting the mapping file, to ensure that the lock on the mapping + file is removed, and to ensure that the mapping file is closed by + the process so that the same or another process does not block waiting + for access to the file. + + [14] fio$rename.x + RENAME will now copy the file and delete the original if the ZFRNAM + (move) operation fails, allowing files to be renamed to different + filesystems. + + [15] os$zoscmd.c (UNIX kernel) + Will now trap interrupts and kill the OS command and then the parent + process. + +------------ +From: /u2/tody/ Sat 19:27:06 26-Jan-85 +Package: os +Title: zfsubd smartened up + +The ZFSUBD kernel procedure, used to add a subdirectory to a pathname to +produce the pathname of the subdirectory, has been smartened up to back up +a pathname when the subdirectory is given as "..". Thus, if the current +directory is "/iraf/sys/fio/" and the subdirectory is "..", the output +pathname will be "/iraf/sys/" rather than "/iraf/sys/fio/../". The second +form is a legal UNIX pathname equivalent to the first, but it is less +efficient to evaluate and would lead to long pathnames and eventual overflow +of a filename buffer. + +------------ +From: /u2/tody/ Sat 20:31:59 26-Jan-85 +Package: fio +Title: filename mapping bug discovered + +A filename mapping bug (file fio$vfntrans.x, procedure vfn_translate) has +been discovered and fixed. The bug would cause sometimes cause a subdirectory +name to appear twice in the mapped filename. I discovered it when the +filename ".." was mapped to "../..", but the same bug could be expected for +ordinary subdirectory names as well, provided they were recognizable as +subdirectory names and appeared as the last field in a filename. + +------------ +From: /u2/tody/ Sat 20:41:08 26-Jan-85 +Package: imio +Title: modification date was not getting initialized + +A bug causing the image modification date to not be initialized at image +create time has been discovered and fixed. The symptom was that the +modify date would show up as zero (=1970). Tests for invalid minimum and +maximum pixel values would consequently fail since an invalid limits time +would also be set to zero, which would not test as older than the modify +date. + +------------ +From: /u2/tody/ Sat 20:44:07 26-Jan-85 +Package: images +Title: new task MINMAX installed + +A new task named MINMAX has been added to the IMAGES package. The new task +is used to compute or recompute the mininum and maximum pixel values in an +image or set of images. The computed values may be printed, used to update +the image header, or accessed from a CL script. + +------------ +From: /u2/tody/ Mon 21:26:43 28-Jan-85 +Package: imio +Title: error recovery bugfix in IMMAP + +The IMMAP procedure would not always close the header file when taking an error +action, e.g., when the file opened turned out to not be an image header. + +------------ +From: /u2/tody/ Mon 21:30:26 28-Jan-85 +Package: images +Title: prettyprinting of title strings in IMHEADER + +The IMHEADER task will now strip trailing newlines and whitespace from +title strings, printing the final string with a single newline. This +results in a consistent looking title regardless of the DATAIO reader +used to create the image (some readers blank fill to 80 columns, others +add an unneeded newline). + +------------ +From: valdes$iraf/ Wed 14:52:04 30-Jan-85 +Package: images +Title: imsum replaces imaverage + +The task imaverage has been replaced by the task imsum. This new task provides +several improvements. + +1. The sum of the input images is provided. +2. The average of the input images is provided. +3. The median of the input images is provided. +4. The output pixel datatype is selectable and defaults to the appropriate + highest precedence datatype of the input images. +5. The calculation type is selectable and defaults to the appropriate + highest precedence datatype of the input images. +6. When all images are of the same datatype and the calculation is done + in the same type then this operation is particularly efficient. + +------------ +From: /u2/tody/ Thu 19:13:33 31-Jan-85 +Package: images +Title: new task IMGETS added + +The new task IMGETS has been added to the IMAGES package. The new task is +used to get parameters by name from the image header. The function of the +task is not expected to be greatly affected by the upcoming DBIO mods. +IMGETS returns the value of the parameter as a string in the parameter +"imgets.value". + +To coerce this string into some other datatype, e.g., int or real, reference +it in an expression with the either the "int" or "real" type coercion function +(as in F77), e.g.: + + cl> imgets image HA + cl> = real (imgets.value) + 5.67544 + cl> + +Note that the DATAIO readers tend to write the instrument parameters in the +header with upper case names, and you must get the case right. Use IMHEADER +to list the image parameters if there is a problem. The following standard +image header parameters may also be accessed with IMGETS: + + name datatype + + pixtype string + ndim int + len[1], len[2], etc. int + min real + max real + title string + pixfile string + +------------ +From: /u2/tody/ Thu 19:21:34 31-Jan-85 +Package: images +Title: task IMHEADER modified + +The IMHEADER task has been modified to print the "user area" of an image +header, if nonempty. The user area should be formatted as a string buffer +containing newline delimited entries of the form "keyword = value" for this +to work properly. + +------------ +From: /u2/tody/ Thu 19:58:17 31-Jan-85 +Package: imio +Title: changes to IMMAP + +The IMMAP procedure in IMIO has undergone the following modifications to +support IMGETS, etc: + + [1] When opening an existing image or a new image, space is always + allocated for a minimum size user area of 2880 struct units, + regardless of the value given in the argument list (a larger space + is allocated if the argument is larger than 2880). The purpose for + allocating the extra space is to permit automatic reading of the + user area regardless of the size given in the argument list, in case + the image is subsequently referenced in a NEW_COPY mode call to + IMMAP. + + [2] IMMAP will no longer abort if the size of the user area is different + than that specified in the argument list. + +The choice of 2880 struct units is arbitrary but since this code is expected +to be replaced shortly, I did the easy thing. The changes should not affect +any existing code. + +------------ +From: /u2/davis/ Fri 09:03:49 01-Feb-85 +Package: dataio +Title: rcamera mods + +RCAMERA has been modified to read old 9-track camera format where tape files +contained multiple images. A new parameter image_list has been added so the +user can specify which images to extract from a file. The camera header +parameters are now stored in the user area. + +------------ +From: /u2/tody/ Fri 18:22:40 01-Feb-85 +Package: vops +Title: modifications and additions to the VOPS package + + +The following VOPS procedures have been modified: + + [1] ASOK - selection of Kth smallest element in a vector. + Calling sequence changed to eliminate the internal vector copy, + modifying the single vector argument in place. The procedure was + tested and a bug found and fixed. + + [2] AMED - median of a vector + Calling sequence changed to eliminate the internal vector copy, + modifying the single vector argument in place. Calls ASOK. The cases + npix=1,2,3 were optimized. + + [3] ALTR - general linear transformation of a vector + Calling sequence modified to add a new constant making the + transformation completely general, i.e., + + call altri (a, b, npix, k1, k2, k3) + b[i] = (a[i] + k1) * k2 + k3 + + Examination of the optimized assembler source for the routines actually + installed in the library showed that the installed routines named ALTRS + and ALTRR were actually performing the function of AMAPS and AMAPR. + The names of the assembler versions were changed to AMAP. A search of + all IRAF source files showed that the modified vector operators were + used only in the DISPLAY program, which was also modified. + + +The following new vector operators were added: + + [1] ALTA - linear transformation via add and multiply + A variant of ALTR: b[i] = (a[i] + k1) * k2 + + [2] ALTM - linear transformation via multiply and add + A variant of ALTR: b[i] = (a[i] * k1) + k2 + + [3] AMED3 - vector median of three vectors + Calculates the vector median of three input vectors, i.e., each + point in the output vector is the median of the corresponding three + points in the input vectors. + + [4] AMED4 - vector median of four vectors + Calculates the vector median of four input vectors. + + [5] AMED5 - vector median of five vectors + Calculates the vector median of five input vectors. + +------------ +From: valdes$iraf/ Fri 18:36:01 01-Feb-85 +Package: images +Title: Task linefit replace imlinefit + +The task imlinefit has been replaced by an improved version call linefit. +The improvements are: + +1. Ability to specify the output columns. +2. Pixels rejected from the fit may or may not be replaced when computing + the output image lines. +3. The fitted points may be subsampled by binning them and taking the average + of the column positions as the ordinates and the median as the abscissas + for each bin. +4. The task efficiency has been somewhat enhanced. Greater efficiency + enhancements are expected shortly. + +The tasks linebckgrnd, colbckgrnd, lineflat, and colflat in the generic +package have been changed to use the new task. + +------------ +From: /u2/tody/ Sat 14:18:03 02-Feb-85 +Package: cl +Title: recent minor modifications + +The following modifications were recently made to the CL: + + [1] It was discovered that SCAN and FSCAN would recognize comma as a + field delimiter in addition to whitespace. While this might + occasionally be useful, it prevents the scanning of lists wherein + the fields contain embedded commas, e.g., image sections. + The scanner has been modified to recognize only whitespace as the + field delimiter. + + Todo: recognize quoted string fields. Add formatted scan capability + to permit more complex scans. + + [2] The iofinish procedure (exec.c), called when a task finishes, would + take an error action if an attempt was made to close one of the + standard streams. This interferred with the use of the special "files" + "STDIN", "STDOUT", and "STDERR". The checking has been removed. + The checking was put in back when the CL was interfaced to UNIX, which + will physically close a standard stream if you tell it to. The IRAF + i/o system works differently and the checking is no longer necessary. + +------------ +From: /u2/tody/ Sun 15:58:00 03-Feb-85 +Package: os +Title: interrupting a command sent to the OS + +The ZOSCMD kernel procedure has been modified in an attempt to fix the +bug that occurs sometimes when "edit" is interrupted. Interrupting a +command like "edit" at just the right point would sometimes leave both +the foreground CL and the forked child CL reading from the terminal at +the same time. The theory is that this occurs when the FORK system call +is interrupted, a definite possibility since a fork can take a while +for a process as large as the CL. Interrupts are now disabled before +the fork and reset in the child process before the execl. The parent CL +is now uninterruptable upon entry to the fork and until the child exits. + +I have given up on the attempt to kill a tree of child subprocesses when +an interrupt occurs as there does not seem to be any way to do this in +UNIX (e.g., a kill of a "make" command entered from the CL). It is easy +to kill the process at the root of the tree, but the children of that +process continue to run. Using process groups it is possible to kill all +processes in the tree but unfortunately the CL and all processes except +the CSH are killed too. Perhaps examination of the CSH source will uncover +a way to do this properly. + +------------ +From: /u2/tody/ Sun 16:11:45 03-Feb-85 +Package: softools +Title: mklib buffers changed + +The MKLIB buffers have been increased by a factor of two to accommodate +larger libraries. The recent additions to VOPS overflowed the old buffers +(which were set to hold 1000 object modules). + +------------ +From: /u2/tody/ Sun 19:10:34 03-Feb-85 +Package: tty +Title: logical device names + +The TTY package has been modified to permit logical device names containing +optional subunit, frame, etc. information in addition to the root TERMCAP or +GRAPHCAP name for the device. This feature is most useful when any of several +units of a device may be accessed, all of which have the same termcap or +graphcap entry. Thus, for example, we might have devices "versatec.1" and +"versatec.2". + +The format and contents of any subfields are device or installation dependent +(the extra fields are passed on to and interpreted by a kernel). All we +require is that the fields be set off from the root device name by a special +character. To make such distinctions possible the root device name may contain +only characters chosen from the set [a-zA-Z0-9_+_]. + +------------ +From: /u2/tody/ Mon 22:25:48 18-Feb-85 +Package: libc +Title: bug fix to FILBUF in the C runtime library + +I discovered that a section of code originally put into the FILBUF procedure +in the C runtime library for debugging purposes was never removed. Two lines +of code were deleted and the library updated. +rev + +------------ +From: /u2/tody/ Thu 02:33:09 21-Feb-85 +Package: os +Title: new devices added + +Two new logical printer devices were added to kernel.h, "vup" and "vdown", +used to select either the upstairs or downstairs versatec printers. The +names are the same as used in the UNIX commands vpr, lpr, etc. A new +plotter device named "dicomed" was added to the system to facilitate debugging +the NSPP kernel, although the host system metacode translator is not yet +installed. + +------------ +From: /u2/davis/ Fri 15:22:12 01-Mar-85 +Package: curfit +Title: curfit mods + +The CURFIT package has been revised. The routines should now run faster. +A new routine cvacpts has been added (see help facilities). + +------------ +From: /u2/tody/ Tue 20:14:02 05-Mar-85 +Package: system +Title: new task GRIPE installed; BUGMAIL deleted. + +Following a suggestion from STScI (no doubt under the influence of AIPS) +I have replaced the old, little used BUGMAIL task by a new task named +GRIPE. GRIPE writes into the file "doc$gripesfile", which anyone can +read, and in addition sends each gripe directly to a designated IRAF +person, currently me, to insure that the GRIPE is read promptly. Please +feel free to post gripes using the new task to ensure that they get +recorded properly. + +------------ +From: valdes$iraf/ Thu 11:47:13 14-Mar-85 +Package: images +Title: Changes to imcopy + +Imcopy has been changed as follows: + +1. The output name may be a directory in which case the input images are +copied to the directory. + +2. A verbose option has been added to print each copy operation as it +occurs. + +3. The choice of copying one file to several output files never really +worked and is now not allowed. Thus, the input is a list of images and +the output must be a list of matching images (the number of input and output +images must be the same) or a single directory. + +This task now is similar to the file copy except that the file copy does +not allow matching lists of input and output files. The help page has +been updated. + +------------ +From: valdes$iraf/ Tue 18:11:20 19-Mar-85 +Package: xtools$imt.x +Title: image template enhancement + +Tasks which accept image templates (most of those in images and longslit) +may now concatenate strings and templates to form new image names. This +is particularly useful for forming new output image names based on the +image names in the input image template. The concatenation operator is +the double slash (//). Some examples are: + + image -> image + image* -> image1, image2, etc. + image*[1,*] -> image1[1,*], image2[1,*], etc. + image*//.1 -> image1.1, image2.1, etc. + new//image*//.bck -> newimage1.bck, newimage2.bck, etc. + image01\[0-5] -> image010, image011, ..., image015 + +To test the image template expansion use the task "sections". +This change is effected in the imt.x procedures in the xtools package. + +------------ +From: /u2/tody/ Tue 21:35:46 19-Mar-85 +Package: osb +Title: string conversion between fortran and spp + +Two subroutines have been added to the OSB package (the bit and byte primitives) +for converting to and from SPP and Fortran strings. The new routines are named +F77PAK and F77UPK. Usage is very similar to the existing STRPAK and STRUPK, +used to convert to and from SPP and C strings. Unfortunately there is no +standard specifying the representation of strings in different languages, and +all three of the IRAF languages do in fact represent strings differently. + + f77pak (sppstr, f77str, maxch) + f77upk (f77str, sppstr, maxch) + +Note that these routines are only callable from a Fortran subprogram since +there is no (machine independent) way in SPP or C to declare a Fortran string +type argument (the only exception is the use of *" for Fortran character +constant arguments in SPP). + +------------ +From: /u2/tody/ Sat 14:47:18 23-Mar-85 +Package: vops +Title: histogram vector operator added to the VOPS package + +A new vector operator ahgm[csilrd] has been added to the VOPS package. +The function of this new operator is to accumulate the histogram of a +series of input vectors in the integer histogram output array. + + ahgm_ (data, npix, hgm, nbins, z1, z2) + +The range of the histogram is from greyscale values Z1 to Z2. Pixels with +values outside the range Z1 to Z2 are excluded from the histogram. + +------------ +From: /u2/tody/ Sat 17:24:55 23-Mar-85 +Package: images +Title: graphics added to the imhistogram task + +The imhistogram task in the images package has been rewritten to use GIO. +The default action is now to compute and plot the histogram of an image +on the standard graphics output. The histogram may optionally be output +as a list. + +------------ +From: /u2/tody/ Sun 18:28:56 31-Mar-85 +Package: cl, etc. +Title: recent mods + +A bug in the ABS function was fixed. In recent weeks many changes have +occurred in that portion of the graphics system resident in the CL, i.e., +the cursor read code, workstation transformation, pseudofile i/o, subkernel +control, and the stdgraph kernel. Virtually all of the revisions have been +isolated to the graphics subsystem. These revisions were not documented +since the graphics subsystem was actively being installed and tested. Now +that the graphics subsystem is stable I will begin to record revisions to +the subsystem. + +Nearly all of the GIO modifications/additions were in the following new +directories: + + sys$gio GIO library + sys$gio/glabax axis labelling and drawing + sys$gio/gki graphics kernel interface + sys$gio/cursor cursor mode, pseudofile i/o, subkernels + sys$gio/stdgraph the stdgraph kernel + sys$gio/nspp the nspp kernel + pkg$plot task implot added + +soon to be added: + + sys$gio/gkslib gks emulation + sys$gio/ncarutil ncar/gks utilities + sys$gio/display generic image display kernel + +The CL must now be linked with the libraries libcur.a (cursor) and libstg.a +(the stdgraph kernel). Changes to the CL itself were minor; the QUERY +procedure in modes.c was modified to read the cursor for gcur and imcur +type parameters. Minor modifications were required wherever the word STDGRAPH +appeared in the old CL. CL_ERROR was modified to call C_XONERR during +error recovery to give the i/o system a chance to clean things up (e.g., +turn off graphics mode). + +In addition to the graphics directories, minor changes were required in the +FIO, CLIO, and ETC directories. A new (internal) file type SPOOL_FILE was +added to FIO to support the wierd i/o required by the graphics system. +A new fset parameter was added to find out how man chars remain to be read +in the file buffer. CLOPEN and ZARDPS in CLIO were completely rewritten to +permit bidirectional i/o on the graphics streams and to add support for all +three graphics streams. A new stream PSIOCTRL was added; this is used by GIO +to send control instructions to connect subkernels to graphics streams, save +and restore WCS, and so on. CLOPEN will now direct graphics output to the +null file if a task is run standalone, thus preventing garbage from being +written to the terminal in debug mode. + +------------ +From: /u2/davis/ Mon 16:26:44 01-Apr-85 +Package: images +Title: imsurfit + +The task imsurfit have been moved from the local to the images +directory. New parameters to permit pixel rejection and region +growing have been addded. The user has the option of fitting selected +columns, rows, subsections or a border around the image. + +------------ +From: /u2/tody/ Wed 15:56:57 03-Apr-85 +Package: cl +Title: parameter indirection + +The metacharacter used to indicate parameter indirection has been changed +from @ to ) to eliminate confusion with list file indirection in a filename +template. For example, try setting the CL parameter "s1" to ")version", +i.e., and the command "=s1" will cause the value of "version" to be printed. + +------------ +From: /u2/tody/ Wed 15:59:39 03-Apr-85 +Package: vops +Title: additions to VOPS + +Two new vector operators have been added to the VOPS package. The ACNV +operator convolves a data vector with a kernel of the same datatype. +The ACNVR operator is similar but the kernel is always of type real. + + acnv[silrd] (a, b, npix, kernel, kpix) + acnvr[silrd] (a, b, npix, kernel, kpix) + +where + a[] pixel array of length npix+kpix-1 + b[] pixel array of length npix (output, accumulated) + kernel[] convolution kernel, type pixel or real + +For kpix=5, b[1] would be set to b[1] plus the dot product of the 5 point +kernel and the 5 points a[1:5]. The one dimensional convolution operators +may easily be used to implement higher dimensional convolutions. + + +### Revision 1.5 Wed Apr 3 23:59:56 MST 1985 + +------------ +From: /u2/tody/ Sun 17:30:28 07-Apr-85 +Package: system +Title: miscellaneous bug fixes + +A number of bug fixes were made to the system following written bug reports +from STScI (for the VMS port) and CTIO (for the AOS port). All bugs reported +by STScI were fixed with the exception of the asynchronous file i/o bug, +which will be easier to track down later when we have a system with asynch. +i/o. In particular the SPP bug which caused '&&' to be replaced by 'jiand' +has been fixed, hence it will no longer be necessary to use the typed functions +andi(), etc. in the VMS version of the system. The same bug would have cropped +up in AOS. + +The bugs reported by STScI are summarized in their report, which is reproduced +below. I have added comments enclosed in brackets, i.e., [[ ... ]]. + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +From stsci Thu Jan 17 08:30:15 1985 +Received: by lyra.noao.UUCP (4.12/4.7) + id AA10600; Thu, 17 Jan 85 08:30:03 mst +Date: Thu, 17 Jan 85 08:30:03 mst +From: stsci (Space Telescope ) +Message-Id: <8501171530.AA10600@lyra.noao.UUCP> +To: tody +Status: R + + ------------------------ + NOTES file for IRAF (VMS) + ------------------------ + + +Contents: + 1. Bugs + + 2. Portability Considerations + + 3. Source file name changes + + +------------------------------------------------------------------------------- + + +1. Bugs + + /pkg/cl/bkg.c + In rbkgfile(), following fix: + ... fgets (set, fp) ... TO + ... fgets (set, SZ_LINE, fp) ... + + /sys/libc/qsort.c -- qcmp() --> (*qcmp)() + /sys/libc/cfilbuf.c -- filbuf() --> (*filbuf)() + + /sys/vops/advz.x -- '$t' missing for generic function + /sys/vops/advz*.x -- procedure advz[idx...] + + (extra files ?) + /sys/vops/ak/aif*.x -- aiftrrr.x + /sys/vops/ak/aff*.x -- afftrxx.x, afftxrr.x, afftxxx.x + /sys/vops/ak/acjgx.x -- acjgxx.x + + /sys/fio/fdebug.x -- "int and()" statement missing + /sys/fio/fputtx.x -- "int and()" statement missing + /sys/fio/fgetfd.x -- "int or()" statement missing + + /pkg/cl/pfiles.c -- pfcopyback() + 'pt' was going NULL before 'pf' in a for loop check; + was changed to check for 'pt' being NULL instead of 'pf' + + /pkg/cl/builtin.c, binop.c, bkg.c, history.c, lexicon.c, + debug.c, errs.c, exec.c, pfiles.c + + problem getting to next task by doing 'tp++'; due to VMS + alignment of structures. Fixed with a macro definition in + /pkg/cl/task.h for "next_task()", namely: + + #define next_task(tp) \ + ((struct task *)((unsigned)tp + (TASKSIZ * BPI))) + #define prevtask next_task(currentask) + +[[ not fixed; will be fixed when CL2 is merged (dct) ]] + + + /pkg/help/lroff/output.x -- references constant MAX_INT + "include " statement missing + + /pkg/lists/tokens.x -- last_nscan() --> last_nscan + + SPP/RPP compiler bug -- + + define and jiand (e.g. in ) + + if (x == FIVE && y == SIX) ... (SPP) + if (x == FIVE & y == SIX) ... (RPP) + if (x .eq. 5 .jiand. y .eq. 6) ... (FORTRAN) + + only occurs when a macro is replaced before the '&&', + in this case FIVE. + +[[ see spp/rpp/rpprat/pbstr.r for fix ]] + + /sys/fio/vfnmap.x + vfnunmap() -- when an OS extension was (un)mapped to a null + IRAF extension, the character count returned + was not right: + (e.g.) doc.dir --> doc but nchars = 7 + This caused problems later on in the directory + task of the system package. + The fix: + ... { + vfn[extn_offset-1] = EOS + op = extn_offset - 1 <-- was missing + } ... + + /sys/fio/vfntrans.x + filename mapping for directories sometimes doesn't work; + sys$ --> drb4:[irafx.sys]sys instead of + drb4:[irafx.sys] + made a quick fix in zopdir() and zfchdr() to deal with this + for now; can't seem to locate the exact problem in vfntrans.x + +[[ this was fixed sometime ago ]] + + /sys/fio/vfnmap.x + When deleting a file and the parameter subfiles=yes, and + no mapping file is currently in directory, a null mapping + file is (sometimes) created. Then doing a system.directory + fails when trying to read this null mapping file. + + E.g. cl> delete aaabbb.ccc + subfiles=yes (default .par file) + + delete() is called with 'aaabbb.ccc' and then + 'aaabbb.ccc.zsf', which is degenerate; + therefore, if a mapping file doesn't + exist, it is created. + + Haven't fixed this yet; not sure about the best way to go. + Some simple suggestions: + + -- Could somehow figure out whether the file is being + added or deleted (i.e. was vfnmap() called from + vfnadd() or vfndel()?). + + -- Or, whenever a mapping file is created, it has the + appropriate header info in it rather than being null? + + -- Or, some special case of reading null mapping files? + +[[ the mapping file is now deleted if it contains no filenames ]] + + /sys/etc/environ.x + env_hash() + return (sum**2 / CONSTANT) + + causes integer overflow on VMS; changed to: (for now) + return ( int( float(sum) / CONSTANT * float(sum) ) ) + +[[ changed to sum / constant * sum ]] + + arithmetic overflows: + /sys/etc/urand.x and others... + + These seem to occur in a few places, sometimes purposely. + An easy VMS fix is to use "FORTRAN/NOCHECK file", but it's + a pain to have to remember which files need this special + treatment. + +[[ no action; overflow in URAND is not supposed to happen ]] + + /sys/fio/ + Seems to be a bug in the file i/o related to writing + asynchronously to binary files. In VMS, this is REALLY + asynchronous, and it caused problems when trying to write + the help database; making VMS do it synchronously (like + UNIX) fixed the problem, for now anyway. + + It may be that a single buffer is being played with between + the write and the wait; at least that's what it looks like + in some of the binary files that were written -- there were + missing blocks and misaligned data, which were there when + displayed on the terminal. + + I don't think it's a problem with RMS, since double buffering + was used to test the binary file driver, with success. + +[[ no action ]] + + /pkg/system/directory.x + - call strcat ("$", Memc[template]) --> + call strcat ("$", Memc[template], SZ_FNAME) + + - should sort and output the file name list ONLY + if (nfiles > 0) + otherwise, an "adjustable array error" occurs in qsort() + (i.e. an array with dimension of 0 is passed to qsort, + causing VMS to complain) + + +------------------------------------------------------------------------------- + + +2. Portability Considerations + + + (life would be easier if most source files and include files did + not need to be mapped ... especially C source files) + + -- no underscores + -- only alphanumeric + -- case insensitive (i.e. lower case) + -- (9 chars).(3 chars) + + (Notes: Some source file names and references to include files + had to be changed to create the filename mapping in the + first place, see list below. + + This is not so crucial now, since XC and XPP have been + written/modified to handle filename mapping. But, it + still does cause problems when making bug fixes to source + files with degenerate names and trying to keep track of + them with RCS. Of course, 99% of the mapping problems will + disappear with VMS V4.0.) + +[[ I am considering eliminating all nonportable filenames in the system ]] +[[ directories, though not in the applications directories. This would ]] +[[ make it easier to move the system software, and once the system is up ]] +[[ the system itself would map the filenames in the applications programs. ]] + + also, directories should be case insensitive: + /sys/vops/AK --> ak + /sys/vops/LZ --> lz + +[[ subdirectory names in VOPS, IMIO changed to lower case ]] + + sys/libc/cfilbuf.c -- filbuf --> vfilbuf (VMS) + since 'FILBUF' gets translated to + 'filbuf' on VMS, not 'filbuf_', + which causes a conflict: + FILBUF and (*filbuf)() + + + SPP coding conventions that cause problems for VMS FORTRAN compiler: + +[[ the following are all bugs, not SPP features; all have been fixed ]] + + a) multiple declarations, e.g. + + int ip + ... + int ip, this, that + + files: /sys/fmtio/ctoi.x + /sys/fmtio/sscan.x + /sys/fmtio/chdeposit.x + /pkg/system/sort.x + + b) 'real' function, e.g. + + real (dval, 0) --> real (dval, 0.0) + /sys/fmtio/gctod.x + + c) array declarations in procedures, e.g. + + procedure proc1 (array, count) + type array (count) + int count # should be BEFORE array declaration + # (tries to use 'count' as a REAL) + /sys/fmtio/patmatch.x + /pkg/utilities/t_translit.x + makeset(), filset() + +[[ all such arrays that I could find are now dimensioned ARB ]] + + and(), or(), not() --> andi(), ori(), noti() ??? + lots of references in /sys/fio/ to these procedures + (added them for VMS, using andi(),...) + xor() referenced in /sys/vops/...axorki.x + (added xor() for VMS, using xori()) + + FIO + file mode "APPEND" -- create the file if non-existent?? + UNIX (and now VMS) do this automatically, but system + reference document isn't clear about this. Without this + feature, /pkg/system/bugmail.cl and revisions.cl don't work. + +[[ kernel should create nonexistent file opened in APPEND mode ]] + + I/O drivers + ZMAIN passes the EPA of the read driver to IRAF_MAIN() ... + + This is OK in UNIX (and VMS, for now), but may have cases + where I/O is to different devices and the drivers are NOT + compatible. (I don't know enough of the internals of + other operating systems to say for sure that this is a + problem, but it seems like it could be.) + + Eg. STDIN from a file and STDOUT to terminal + + If the file and terminal drivers are incompatible, then + things won't work. We may eventually have some problems + in this area with VMS, especially if we start to support + some network I/O access. Eventually, we may store the + actual read/write function in the channel structure and + check it whenever a read/write function is called; that is, + override the higher level IRAF I/O at the kernel level. + +[[ this is unlikely to be a problem and can be fixed at kernel level if nec ]] + + zardlp() function referenced in /sys/etc/lpopen.x ?? + (added dummy function for VMS) + +[[ no action ]] + + modf() function used in /pkg/cl/unop.c + was missing from /sys/libc/ + (added modf.mar to /sys/os/ for VMS) + +[[ call to modf deleted; modf.mar should be removed from kernel ]] + +------------------------------------------------------------------------------- + + +3. Source file name changes + + + /pkg/softools/boot/spp/xpp/xpp_main.c --> xppmain.c + +[[ removed underscore in C file name ]] + + Necessary for file name mapping: + + /sys/memio/ty_size.dat --> tysize.dat + + /sys/memio/coerce.x, salloc.x, sizeof.x + include "ty_size.dat" --> include "tysize.dat" + + +[[ used "include " ]] +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + +In addition, Nelson Zarate at CTIO reported the following minor bugs which +I have fixed. The AOS port is only just beginning. Once again a lot of +code compiled with only a few errors. + + [1] libc$cfredir.c + redundant "int fd" declaration. + + [2] libc$cfilbuf.c, libc$qsort.c + pointer to function returning pointer to int problem + + [3] softools$boot/spp/rpp/rppfor/indent.f77 + local variable LOGICO redefining common variable of the same name. + + [4] softools$boot/spp/rpp/ratlibf/catsub.f + array argument declaration out of order, as reported by ST in + other parts of the system. + + [5] softools$boot/spp/rpp/ratlibc/ create.c,open.c + reference to UNIX stdio hidden structure field _file. Replaced + by use of "fileno(fp)". + + +### Revision 1.6 Mon Apr 8 22:27:58 MST 1985 + +------------ +From: /u2/tody/ Wed 10:15:40 10-Apr-85 +Package: softools +Title: bug in the SPP compiler + +A bug was fixed in the first pass of the SPP compiler as a result of the +effort to get IRAF running on the Jupiter supermicro system at JPL. The +bug would cause a spurious "too many strings" error to occur during the +processing of a large number of include files. + +------------ +From: /u2/tody/ Mon 21:44:33 15-Apr-85 +Package: sys +Title: use of ENTRY statement considered harmful + +In trying to port IRAF to the Jupiter / 4.2BSD system I found that the +F77 compiler on that system could not compile ENTRY statements. This is +not the first time I have had trouble with compilers and entry statements, +hence I was forced to conclude that use of such statements compromises the +portability of our software, despite the fact that entry statements are +part of the Fortran 77 standard. I have removed all the entry statements +from the files in the sys$ directories (the system libraries), and am in +the process of removing them from HELP and XTOOLS (the latter so that I can +compile the images package). Hereafter the use of ENTRY statements in +SPP or Fortran code in IRAF is discouraged. + +------------ +From: /u2/tody/ Thu 00:21:31 25-Apr-85 +Package: gio +Title: new version of NSPP kernel installed + +The latest version of the NSPP/GIO kernel has been installed. This version +differs from the previous one primarily in the way it handles put cell array. + +------------ +From: /u2/tody/ Thu 00:22:52 25-Apr-85 +Package: clio,gio +Title: nasty bug found and fixed + +The nasty bug that was keeping cursor mode SNAP from working has finally +been found and fixed. The recent removal of ENTRY statements caused this +bug (a memory overwrite bug) to resurface as a cascade of "Warning: cannot +delete file" messages when writing to STDPLOT or PSIOCTRL (bug reported by +both Dyer and Suzanne). In this form it was straightforward to find and fix. +The bug dates back to the addition of the pseudofiles STDIMAGE, STDPLOT, and +PSIOCTRL to the pseudofile i/o code in CLIO. The parameter defining the +number of pseudofiles was not increased to allow for these new files, +causing a write off the end of an array. + +All graphics applications programs should be relinked to capture the bug +fix. All such programs are currently overwriting either part of the FIO or +environment list data structures, depending on how they are being used. + +------------ +From: /u2/tody/ Thu 11:11:36 25-Apr-85 +Package: softools +Title: XCOMPILE enhancement + +The XC task will now produce, by default, an output executable file with +extension ".e", unless the output file name is explicitly set on the command +line with the "-o" switch. + +------------ +From: /u2/tody/ Thu 22:22:50 25-Apr-85 +Package: graphcap +Title: dicomed device entry + +The graphcap entry for the dicomed device has been modifed to use the NSPP +kernel, allowing it to drive the physical dicomed device. Formerly the +output was directed to the gkidecode kernel since the low level code was +not then working. + +------------ +From: /u2/tody/ Thu 22:24:51 25-Apr-85 +Package: gio +Title: cursor mode enhancements + +1. Snap + + The SNAP function in cursor mode is now fully functional. The cursor mode +snap makes a hardcopy of the graphics on your screen on a batch plotter, e.g., +the imagen or versatec. This gives a much higher resolution plot then is +achievable with a video hardcopy device, and of course snap works from any +graphics terminal. The snap will work at any magnification and will capture +key A style axes, T or D text and lines, etc. Syntax is + + :.snap [device] + +where [device], if absent, defaults to stdplot or to the device currently +connected to the STDPLOT graphics stream, if any (type :.sh to check the +status of the streams). For example, + + :.sn imagen + +makes a snap on the imagen, and + + :.sn + +is the shortest form of the command. It takes only a fraction of a second +to make a snap, but it may take several minutes for it to appear on the +plotter. Versatec snaps are much more expensive to generate than imagen +ones due to the need to digitize the plots (but the versatec makes prettier +plots). Avoid generating a lot of snaps to the versatec all at once, or you +will swamp the VAX with "vplot" rasterization tasks. SNAP does a frame +advance after each snap, hence there is no buffering of the last snap in +the kernel, as is the case for ordinary output to STDPLOT. + + +With the implementation of SNAP cursor mode is now fully functional. I do +plan, however, to add a DISPOSE function to flush the last plot out of +STDPLOT. There are also still some bugs in the cursor mode code waiting +to be fixed, e.g., =gcur before any graphics does not currently work, +nor does it work after a :.init. The backup and undo commands, used to +discard graphics instructions, do not always erase the graphics at present +(a full screen redraw will however show that the line or text string is +gone). + + +2. Waitpage + + The [hit return to continue] wait is now implemented as a text mode +getline rather than as a cursor read. The cursor read would cause a switch +to graphics mode, blanking the text memory on some terminals (giving the +user no chance to read the text). + + +------------ +From: /u2/tody/ Thu 22:42:47 25-Apr-85 +Package: gio +Title: nspp kernel + +The NSPP kernel will now generate lines of different widths. More precisely, +linewidths less than 1.5 are drawn in "low" intensity, and everything else +is drawn in "high" intensity. By default, the axes and tick labels of a plot +are drawn in high intensity and the data in low intensity. Variable lien +widths are not currently supported for the imagen and dicomed. + +------------ +From: /u2/tody/ Fri 17:38:19 26-Apr-85 +Package: gio +Title: more bug fixes + +The "write to IPC with no reader" bug, which would formerly appear at logout +after a write to a plotter device, has been fixed. The bug was in the IRAF +Main, i.e., file etc$main.x. GIO calls ONEXIT to post a procedure which +is supposed to shutdown the graphics system at process exit. The procedure +posted by ONEXIT was not getting called, however, until the main called +the FIO cleanup procedure, which would close down the graphics kernel +rudely, causing the error messages. The main has been modifed to call the +ONEXIT procedures before cleaning up FIO. + +Typing "=gcur" at login, before generating any graphics, now works. The +graphics kernel was being opened but the open workstation command was not +being sent to the kernel, hence an attempt to read the cursor would cause +EOF to be returned. + +A new builtin task called GFLUSH has been added to the CL package language. +This may be called to flush any graphics buffered in STDPLOT to the plotter. + +------------ +From: /u2/tody/ Sat 15:12:41 27-Apr-85 +Package: gio +Title: new command .gflush + +A new : escape ":.gflush" has been added to the cursor mode escapes. This is +the cursor mode equivalent of the "gflush" command in the CL, permitting +disposal of plotter output from within cursor mode w/o having to exit to the +CL. + +------------ +From: /u2/tody/ Mon 09:40:45 29-Apr-85 +Package: fmtio/str +Title: string sorting utility + +A new procedure has been added to the STR subpackage of FMTIO for sorting +arrays of strings. + + strsrt (strp, sbuf, nstr) + + int strp[ARB] # array of indices of strings + pointer sbuf # pointer to string buffer + int nstr # number of strings + +Sorting is carried out by permutation of the indices of the strings in STRP. +String storage is in SBUF. + +------------ +From: /u2/davis/ Mon 11:05:43 29-Apr-85 +Package: dataio +Title: rfits,wfits mods + +WFITS will now store the IRAF image name in the FITS parameter IRAFNAME. +RFITS will optionally restore image files to disk with the old IRAF name +if the parameter oldirafname is set. A new parameter scale has been added +to RFITS. If the scale switch is set to no RFITS will dump the FITS integers +directly to tape regardless of the value of bscale and bzero. Otherwise +RFITS will check the bscale and bzero factors before deciding whether or +not to scale the data. + +------------ +From: /u2/tody/ Mon 22:48:03 29-Apr-85 +Package: fmtio +Title: bug fix in patmatch + +PATMATCH was found to be grossly inefficient for a match at the beginning +of a line, and was optimized accordingly. + +------------ +From: /u2/davis/ Tue 14:31:06 30-Apr-85 +Package: images +Title: new 2-D shift operator + +A new task IMSHIFT has been added to the images package. IMSHIFT will shift +an image by fractional pixel shifts in both x and y using a set of 2-D +interpolation routines. See the help file for more info. + +------------ +From: /u2/tody/ Mon 22:36:38 06-May-85 +Package: cl +Title: bug fix affecting i/o redirection + +A bug was discovered that would cause commands of the form + + task < file + +to fail. In such a case, the CL would open "file" as a binary file rather +than as a text file, causing every other character to be discarded on our +machine. The bug was due to a typo in exec.c with the operator "*" typed +when "&" was meant (see the code which sets the STDINB flag). + +------------ +From: valdes$iraf/ Wed 16:13:37 08-May-85 +Package: imred +Title: bias package + +There has been a great deal of confusion about removing bias from CCD +images. This has led to use of several different IRAF operators for +this purpose. In particular a contant bias subtraction and a line-by-line +bias subtraction have been used. Neither of these is correct. The bias +does vary (at least for some detectors) so a constant is not appropriate. +However, line-by-line subtraction introduces noise because the bias +variations are expected to be low frequency. After discussion with George +Jacoby and Roger Davies the following approach seems to be the correct one. +For this discussion assume that the bias region occupies a set of columns. +Average the bias columns to produce an average bias column. Fit a function +of the line number to the average bias column. Subtract this average function +from each column of the image. Note that this method encompasses the constant +bias and high frequency line-by-line subtraction with a suitable choice +of the fitting function (i.e. a polynomial of order 1 or a very high +order function respectively). + +I have implemented this algorithm using the general curve fit package with +interactive extensions. In the imred package there is a package called +bias. In the bias package are two tasks colbias and linebias. Help +information is available for these tasks. Because trimming of the bias +region and unwanted portions of the image is very commonly desired +and can result in considerable savings in execution time these tasks +provide for specifying a "trim" region to be bias subtracted and output. +The tasks can be run non-interactively, interactively, or partially +interactive and partially non-interactive. + +I would like to remove the following tasks from the imred.generic package: + +dcbias, btt, chimages, biassub + +If there are no objections I will do this in a week or so. + +------------ +From: /u2/tody/ Wed 23:50:51 08-May-85 +Package: plot +Title: additions to IMPLOT task + +The IMPLOT task has been modified to generate a two line plot title, the first +line of which tells whether the plot is a line or column plot, gives the line +or column number (or numbers in the case of an average), and gives the image +name. The image title appears on the second line. + +The :l and :c commands now permit a second numeric argument. If two numeric +arguments are given, the indicated range of lines or columns will be averaged. + +------------ +From: valdes$iraf/ Thu 14:27:51 09-May-85 +Package: curfit +Title: New stat procedures + +Two procedure have been added to the curfit package. These are +CVSTATI and CVSTATR. They are used to get parameters from the +curfit package. The parameter macro values are defined in curfit.h. +The parameters currently defined are: + +define CVTYPE 1 # curve type +define CVORDER 2 # order +define CVNSAVE 3 # Length of save buffer +define CVXMIN 4 # minimum ordinate +define CVXMAX 5 # maximum ordinate + +Primary usages are to get the length of the buffer needed for a CVSAVE +and to determine the properties of a curve which has been restored +by a CVRESTORE. + +------------ +From: /u2/tody/ Thu 18:07:47 09-May-85 +Package: images +Title: minor mod to HEDIT + +The interactive verification feature of HEDIT has been slightly modified +since some users turned out to be confused by the original way things were +done. One can now respond to the field update query with either "yes" or +"no", in addition to explicitly entering a new value string. Either "yes", +"y", or carriage return serves to accept the prompted value. + +A editing sequence involving many images can now be terminated prematurely +by typing "q" in response to the "update header" query given after all +fields in a particular image have been edited. The task will exit +immediately without editing the remaining images. + +------------ +From: /u2/tody/ Thu 22:12:31 09-May-85 +Package: imio +Title: new release of IMIO installed + +A new release of IMIO was installed in the system on 29 April. The major +changes in the new version of IMIO are summarized below. + + [1] IMIO now has the ability to perform (optionally) automatic boundary + extension to satisfy out of bounds pixel references. + + [2] A preliminary database interface has been added to IMIO. Image headers + are now variable length and use only the amount of disk space required + to store the header (excluding byte packing). + + [3] Two new database utility tasks HEDIT and HSELECT have been added to + the IMAGES package. Both use the new library subroutine EVEXPR, + now installed in the FMTIO package. + +The new release of IMIO is upward compatible with previous versions and should +require no changes to or even recompilation of existing code. The basic image +header structure is unchanged hence existing images and image headers are still +accessible. Copying of old images still on disk with IMCOPY may however be +desirable to reduce disk consumption (the old headers were wasteful of storage). + +This release of IMIO introduces some database tools and concepts which +should help us understand the role the DBIO interface and DBMS package will +play in image processing applications in the near future. The current database +interface has serious functional limitations and is inefficient for operations +which operate upon entire databases (e.g., the select operation), but does +provide a basic and much needed image database capability. + + +1. Modifications to the Current Interface + +1.1 Boundary extension + + Automatic boundary extension is useful in applications such as filtering +via convolution, since the convolution kernel will extend beyond the boundary +of the image when near the boundary, and in applications which operate upon +subrasters, for the same reason. When reading from an image with boundary +extension in effect, IMIO will generate artificial values for the out of bounds +pixels using one of the techniques listed below. When writing to an image +with boundary extension in effect, the out of bounds pixels are discarded. + +By default, an out of bounds pixel reference will result in an error message +from IMIO. Consider an image line of length 5 pixels. The statement + + buf = imgs1r (im, -1, 7) + +references out of bounds by 2 pixels on either end of the image line, +referencing a total of 5+2+2=9 pixels. If boundary extension is enabled +and the get section completes successfully then Memr[buf] will reference +the pixel at X = -1, and Memr[buf+2] will reference the first inbounds +pixel. + +When an image is first opened zero pixels of boundary extension are +selected, and any out of bounds references will result in an error. +To enable boundary extension imseti must be called on the open +image to specify the number of pixels of boundary extension permitted +before an out of bounds error occurs. + + include + call imseti (im, IM_NBNDRYPIX, 2) + +If boundary extension is enabled the type of boundary extension desired +should also be set. The possibilities are defined in and +are summarized below. + + + BT_CONSTANT return constant if out of bounds + BT_NEAREST return nearest boundary pixel + BT_REFLECT reflect back into image + BT_WRAP wrap around to other side + BT_PROJECT project about boundary + + Types of Boundary Extension + + +The type of boundary extension is set with the imset parameter IM_TYBNDRY. +If the BT_CONSTANT option is selected the constant value should be set with +an imseti or imsetr call to set the parameter IM_BNDRYPIXVAL. +Boundary extension works for images of any dimension up to 7 (the current +IMIO limit). A single IM_NBNDRYPIX value is used for all dimensions. +This value is used only for bounds checking, hence the value should be set +to the maximum out of bounds reference expected for any dimension. +Larger values do not "cost more" than small ones. An actual out of bounds +reference is however more expensive than an inbounds reference. + + +1.2 Image Database Interface + + The image database interface is the IMIO interface to the database +containing the image headers. In this implementation the image header is +a variable length binary structure. The first, fixed format, part of the +image header contains the standard fields in binary and is fixed in size. +This is followed by the so called "user area", a string buffer containing +a sequence of variable length, newline delimited FITS format keyword=value +header cards. When an image is opened a large user area is allocated to permit +the addition of new parameters without filling up the buffer. When the +header is subsequently updated on disk only as much disk space is used as +is needed to store the actual header. + +The new header format is upwards compatible with the old image header format, +hence old images and programs do not have to be modified to use the latest +release of IMIO. In the future image headers will be maintained under DBIO, +but the routines in the image header database interface described in this +section are not exected to change. The actual disk format of images will of +course change when we switch over to the DBIO headers. While the physical +storage format of header will change completely under DBIO, the logical schema +will change very little, i.e., our mental picture of an image header will be +much as it is now. The main difference will be the consolidation of many +images into a few files, and real support in the image header for bad pixels, +history, and coordinate transformations. In addition a number of restrictions +on the "user fields" will be lifted, the remaining distinctions between the +standard and user fields will disappear, and database operations will be much +more efficient than they are now. + + +1.2.1 Library Procedures + + The IMIO library procedures comprising the current image database interface +are summarized in the table below. + + + value = imget[bcsilrd_] (im, field) + imgstr (im, field, outstr, maxch) + imput[bcsilrd_] (im, field, value) + impstr (im, field, value) + imadd[bcsilrd_] (im, field, def_value) + imastr (im, field, def_value) + imaddf (im, field, datatype) + imdelf (im, field) + y/n = imaccf (im, field) + + list = imofnl[su] (im, template) + nchars/EOF = imgnfn (list, fieldname, maxch) + imcfnl (list) + +where + pointer im, list + char[] field, outstr, datatype, template, fieldname + + + Image Database Interface Procedures + + +New parameters will typically be added to the image header with either +one of the typed imadd procedures or with the lower level imaddf +procedure. + +The former procedures permit the parameter to be created and the value +initialized all in one call, while the latter only creates the parameter. +In addition, the typed imadd procedures may be used to update the values +of existing parameters, i.e., it is not considered an error if the parameter +already exists. The principal limitation of the typed procedures is that +they may only be used to add or set parameters of a standard datatype. +The imaddf procedure will permit creation of parameters with more +descriptive datatypes (abstract datatypes or domains) when the interface is +recut upon DBIO. There is no support in the current interface for domains. + +The value of any parameter may be fetched with one of the imget functions. +Be careful not to confuse imgets with imgstr (or imputs with impstr ) +when fetching or storing the string value of a field . Full automatic type +conversion is provided. Any field may be read or written as a string, +and the usual type conversions are permitted for the numeric datatypes. + +The imaccf function may be used (like the FIO access procedure) +to determine whether a field exists. Fields are deleted with imdelf ; +it is an error to attempt to delete a nonexistent field. + +The field name list procedures imofnl[su] , imgnfn , and imcfnl procedures +are similar to the familiar file template facilities, except that the @file +notation is not supported. The template is expanded upon an image header +rather than a directory. Unsorted lists are the most useful for image header +fields. If sorting is enabled each comma delimited pattern in the template +is sorted separately, rather than globally sorting the entire template after +expansion. Minimum match is permitted when expanding the template, another +difference from file templates. Only actual, full length field names are +placed in the output list. + + +1.2.2 Standard Fields + + The database interface may be used to access any field of the image header, +including the following standard fields. Note that the nomenclature has been +changed slightly to make it more consistent with FITS. Additional standard +fields will be defined in the future. These names and their usage may change +in the next release of IMIO. + + + keyword type description + + i_ctime l time of image creation + i_history s history string buffer + i_limtime l time when limits (minmax) were last updated + i_maxpixval r maximum pixel value + i_minpixval r minimum pixel value + i_mtime l time of last modify + i_naxis i number of axes (dimensionality) + i_naxis[1-7] l length of an axis ("i_naxis1", etc.) + i_pixfile s pixel storage file + i_pixtype i pixel datatype (SPP integer code) + i_title s title string + + + +The names of the standard fields share an "i_" prefix to reduce the possibility +of collisions with user field names, to identify the standard fields in +sorted listings, to allow use of pattern matching to discriminate between the +standard fields and user fields, and so on. For the convenience of the user, +the "i_" prefix may be omitted provided the resultant name does not match the +name of a user parameter. It is however recommended that the full name be +used in all applications software. + + +1.2.3 Restrictions + + The use of FITS format as the internal format for storing fields in this +version of the interface places restrictions on the size of field names and +of the string value of string valued parameters. Field names are currently +limited to eight characters or less and case is ignored (since FITS requires +upper case). The eight character limit does not apply to the standard fields. +String values are limited to at most 68 characters. If put string is passed +a longer string it will be silently truncated. Trailing whitespace and +newlines are chopped when a string value is read. + + +2. Database Utility Tasks + + Two image database utility tasks have been implemented, hedit and +hselect. Hedit is the so called header editor, used to modify, add, or +delete selected fields of selected images. The hselect task is used to +select images that satisfy a selection criteria given as a boolean +expression, printing a subset of the fields of these images on the +standard output in list form. + +Both of these tasks gain most of their power from use of the evexpr +utility procedure, now available in FMTIO. The evexpr procedure takes +as input an algebraic expression (character string), parses and evaluates +the expression, and returns as output the value of the expression. + + + include + pointer evexpr() + + o = evexpr (expr, getop, ufcn) + +where + o Is a pointer to an operand structure + expr Is a character string + getop Is either NULL or the locpr address + of a user supplied procedure called during + expression evaluation to get the value of + an external operand. + ufcn Is either NULL or the locpr address + of a user supplied procedure called during + expression evaluation to satisfy a call to + an external function. + + +The operand structure is defined in . The best documentation +currently available for the operators and functions provided by evexpr +will be found in the manual page(s) for hedit . Additional documentation +will be found with the sources. The expression evaluation procedure is +probably the single largest procedure in the system (in terms of kilobytes +added to an executable) and should not be used unless it is needed, but it can +greatly increase the power of a task in the right application. + +------------ +From: /u2/tody/ Fri 20:32:55 10-May-85 +Package: gio +Title: spooling of plotter output + +Plotter output is now spooled many plots to a metafile rather than being +processed to the plotter a plot at a time. You will no longer get a plot +out immediately after a cursor mode snap. Spooling many plots into a single +metafile is much more efficient, reduces the load on the system, and produces +more pleasing output since the plots will come out on successive pages of +paper as a single print job (with no wasted paper). All plotter output is +spooled, e.g., cursor mode snaps, plots written to devices such as "stdplot", +"vup", "imagen", etc., and plots written to the dicomed (e.g., by crtpict). +Versatec plots are also now more closely centered on a page (formerly part +of the plot would be in the perforations between pages of paper). + +The spooled plotter output will be disposed of to the plotter device when +any of the following events occur: + + [1] When you type the command "gflush" in the CL, or enter colon escape + ":.gflush" while in cursor mode. A ":.init" will also do it. + + [2] When you log off. + + [3] When the graphics device assigned to the stream STDPLOT changes. + This happens when a new device name is assigned to the "device" + parameter of a graphics task which writes to STDPLOT, or when + you make a "snap" on a different device. + + [4] When the "maximum frame count" for a device is exceeded. This can + be specified individually for the different plotter devices, with + the default value currently being 16 frames per metafile. This is + enough frames to make things efficient, but not so many that we + run out of disk space or lose everything in a system crash. + +If the system should crash before plotter output is disposed of to the system, +the metafile should still be intact in the /tmp directory (e.g., "/tmp/gvp...") +and may be disposed of manually with a command such as the following (this +would plot on the upstairs versatec): + + plotX -Tver -W=3 /tmp/gvp* | plot -Tver -M75 -Pvup + +These comments apply only to the plotter devices. The plotter (NSPP) devices +currently supported are the following: + + calcomp + dicomed + imagen + versatec + vdown + vup + +------------ +From: /u2/tody/ Sat 00:23:44 11-May-85 +Package: gio +Title: bug fix, log scaling, etc. + +A serious bug in pseudofile i/o to STDPLOT (gio$cursor/prpsio.x) was preventing +plots written to STDPLOT by a task from being sent properly to the NSPP kernel. +This was fixed and in addition, the following enhancements were made: + + [1] Log ticks are now labelled as powers of 10 rather than in linear units, + i.e., as a 10 followed by the exponent one half character higher. + + [2] The EPSILON tolerance test in FP_EQUAL[DR] and FP_NORM[DR] was relaxed + to 10*EPSILON to make these routines useful in real life situations + where there is typically a small accumulation of error to be allowed + for. + +------------ +From: /u2/tody/ Sun 20:19:38 12-May-85 +Package: plot +Title: graphics kernels added to PLOT package + +The three existing graphics kernels have been added to the PLOT package as +the following tasks: + + gkidecode + stdgraph + stdplot + +These tasks are used to process metacode, either from a file or from the +standard input (e.g., from a pipe). At present, however, there is no way +to redirect a graphics stream on the command line. + +In the process of installing these tasks the name of the old NSPP task was +changed to STDPLOT. These tasks will already be useful for metacode +translation. In the future the CL i/o redirection syntax will be extended +to permit redirection of graphics output, e.g., + + plottask arg arg | stdplot dev=vup cell+ + +------------ +From: /u2/tody/ Thu 10:08:43 16-May-85 +Package: gio +Title: degenerate windows + +If a window (world coordinate system) is degenerate in either axis GIO will +now increase the upper limit of the window in steps of EPSILON until there +is enough separation between the edges of the window to define the coordinate +system. Formerly GIO would take an error action ("no range in [XY]") when +given a degenerate coordinate system. + +------------ +From: valdes$iraf/ Fri 13:37:34 17-May-85 +Package: lib +Title: Subdirectory for include files of xtools + +To keep the lib directory managable we plan to make subdirectories of +lib available as standard search places for include files and libraries. +As a start include files for the xtools procedures have been placed in +the subdirectory xtools. Currently these include files must be +reference with an OS path name. This will change later to be OS +independent. The usage (in UNIX) is: + + include + +------------ +From: valdes$iraf/ Fri 13:42:33 17-May-85 +Package: xtools +Title: New xtools + +Three packages of xtools have been added to xtools. These packages are +in subdirectories of xtools. The new xtools are as follows. + +ranges (rg_ prefix procedures): + + A ranges package using : as the range delimiter (like image sections) +and without steps. It contains tools for parsing ranges, merging ranges, +ordering ranges, packing and unpacking arrays, and doing median and averaging +of sets of points within ranges. It is used in the icfit tools and in +some of the longslit tasks. Indirectly through icfit it is used in a number +of other tasks. + +gtools (gt_ prefix procedures): + + Graphics tools. These tools provide for printing help files in response +to : cursor commands, paging (clearing the terminal) text, and tools to use +a structure containing window and axis transformation parameters. These +tools are used in icfit and indirectly through icfit in a number of tasks. + +icfit (ic_ and icg_ prefix procedures): + + Interactive curve fitting. These tools provide a somewhat higher level +interface to the curfit math package. It has been designed to be efficient +and to use a set of standard parameters (sample points, median and subsample +averaging, functions, orders, deviant point rejection, and rejection growing. +A subset of the package provides an interactive GIO interface. These tools +are used in linefit, lineclean, identify, response, illumination, background, +linebias, colbias, lineflat, colflat, linebckgrnd, and colbckgrnd in the +images, longslit, bias, and generic packages. A good example of usage is +t_linefit.x in the images package. + + The source code is moderately well commented but there is little other +documentation as yet. Include files for the various set and get calls are +in lib$xtools. If you have any interest in using them see Frank Valdes. + +------------ +From: valdes$iraf/ Fri 13:44:31 17-May-85 +Package: images +Title: Linefit and lineclean + +The linefit task has been changed again. It now has interactive graphics +options and is greatly simplified. The previous version tried to do too +many things and was difficult to understand. The new task fits image +lines and creates output images with the fit, the difference or residuals, +or the ratio of the image values to the fit values. Cleaning of deviant +pixels has been moved to the task lineclean (though elimination of bad +points from the fits is still available). There is no minimum +division threshold and no output column selection. It uses the icfit +tools for interactively setting the fitting parameters. + +A new task lineclean has been added to use curve fitting to detect and +replace deviant pixels. It is similar to linefit and uses the same icfit +tools and interactive fitting parameter approach. + +These tasks are also used in the generic scripts lineflat, colflat, +Linebckgrnd, and colbckgrnd. + +------------ +From: valdes$iraf/ Fri 13:45:48 17-May-85 +Package: generic +Title: Changes + +The generic package has been revised. The tasks dcbias, chimages, btt, +and biassub have been removed. Note that bias strip corrections are +available in the imred.bias package. The tasks lineflat, colflat, +linebckgrnd, and colbckgrnd have been changed to use the new linefit +task in the images package. + +------------ +From: valdes$iraf/ Fri 16:20:06 17-May-85 +Package: icfit +Title: Help for interactive graphics in icfit package + +Help for the cursor mode keys and colon commands in the interactive +graphics of the icfit package is available as ichelp. This package +is used in numerous tasks and this help page is relevent to all these +tasks: linefit, lineclean, colbias, linebias, colflat, lineflat, linebckgrnd, +colbckgrnd, identify, response, illumination, background. + +------------ +From: /u2/tody/ Wed 17:48:07 29-May-85 +Package: clpackage +Title: revision of the root package (clpackage) + +The DTOI package has been moved from the root to IMRED, where it more +properly belongs. The SDAS package has been added to the root and will +eventually contain the applications software from our friends at the +Space Telescope. + +------------ +From: /u2/tody/ Thu 00:57:22 30-May-85 +Package: plot +Title: IMPLOT enhancements + +A new keystroke 'e' has been added to IMPLOT to permit plot expansion with a +completely redrawn box (makes a prettier plot than the 'E' and 'A' keystrokes +in cursor mode). Two new colon escapes ":x x1 x2" and ":y y1 y2" have been +added to permit fixing of the plot scale in X or Y, disabling autoscaling. +A bug was fixed which was preventing log scaling from working. The ? help +text was moved out into the file "plot$implot.keys". The manual page was +updated. + +------------ +From: /u2/tody/ Thu 17:45:52 30-May-85 +Package: clio,fio +Title: filename templates + +The filename template expansion code has been rewritten with the results +outlined below. The external specifications of the packages involved have +not changed. + + [1] Sorting, if enabled, is now done only when expanding a pattern rather + than globally over the entire template. Thus a template such as + + *.h,*.x + + will be expanded with all the .h files first in alphabetical order, + followed by all the .x files in alphabetical order. File lists are + no longer sorted, e.g., forms "a,b,c", and "@filelist". + + [2] Template expansion is now substantially more efficient. One result + of this is that directory listings are now somewhat faster. + + [3] The new routine CLPREW has been added to the CLGFIL package. The + new entry point may be used to rewind the file list. + + [4] An OS escape syntax has been added to permit "quoting" if OS filenames + containing template metacharacters, e.g., $ and []. Anything enclosed + by OS escape characters, e.g., '!', is treated as a filename string. + Hence, templates such as + + !vmsdir$file!,!drb0:[dir]file! + or + !vmsfile + + are now permitted. The only effect of the ! are to turn metacharacters + off and back on; beyond that the ! are just stripped out. + + [5] A new "buffered" FNT package has been added, to permit convenient + filename template expansion for templates not necessarily bound to + CL string parameters. + + Procedures: + + fntopnb - Expand template, open a buffered filename list + fntclsb - Close buffered list + fntgfnb - Get next filename from buffered list + fntlenb - Get number of filenames in a buffered list + fntrewb - Rewind the list + + Calling sequences: + + list = fntopnb (template, sortflag) + fntclsb (list) + nchars|EOF = fntgfnb (list, outstr, maxch) + nfiles = fntlenb (list) + fntrewb (list) + + These entry points are provided only for extra flexibility. The old + CLPOPN[ISU] should continue to be used for the common case when the + template is a CL parameter, or when the list is associated with the + standard input, which might be redirected. + + +In other changes, the CLGFIL sources in CLIO have become somewhat smaller and +simpler. A couple include files were removed from CLIO. The FNT package was +moved from CLIO to FIO. + +------------ +From: /u2/tody/ Thu 18:19:17 30-May-85 +Package: gio +Title: bug fix to polymarker in NSPP kernel + +The polymarker function in the NSPP kernel turned out to be the same as +polyline; was changed to draw points rather than vectors. + +------------ +From: /u2/tody/ Fri 20:12:34 31-May-85 +Package: gio +Title: gio bug fix + +The GINIT procedure was using an invalid struct pointer to initialize the +current text attribute structure. + +------------ +From: /u2/tody/ Fri 20:14:09 31-May-85 +Package: hedit,imio +Title: bug fix involving addition of parameters to image headers + +The image database interface routines in IMIO were not properly adding +new parameters to image headers. There were a couple of bugs, i.e., +the newline of the new record was being overwritten with a blank, and +the datatypes of string and numeric fields were not being set properly. +A bug was also fixed in HEDIT that would cause a cryptic "parameter not found" +message when attempting to "add" (edit) an existing image header parameter. +HEDIT will now invoke the edit function when an attempt is made to add +a parameter to an image that already contains such a parameter. + +------------ +From: /u2/tody/ Sat 20:07:58 01-Jun-85 +Package: gio +Title: new font installed in NSPP kernel + +The original character font of the NSPP kernel has been replaced by a new +font from NCAR/GKS. The new font is generally better than the old one, +particularly the lower case letters and certain digits, although there +appear to be certain characters in the new font which could stand some +tweaking (i.e., the characters ";:#"). Roman, bold, and italic versions +of the new font are available via gseti-G_TXFONT and \f[RIB] escape sequences +in text strings. + +------------ +From: /u2/tody/ Sun 18:37:36 02-Jun-85 +Package: gio +Title: postprocessing of metacode files + +The graphics kernels have been modified to permit processing of metacode +files which do not contain the open workstation instruction. Such metafiles +are commonly produced by the ":.write" command in cursor mode. + +------------ +From: /u2/tody/ Sun 18:39:53 02-Jun-85 +Package: gio +Title: new NSPP device "tek" added + +A new graphics device using the NSPP kernel has been added. The new device, +named "tek", is useful for interactively inspecting fully vectorized plots +such as would they would appear on the imagen, versatec, dicomed, or other +NSPP devices. In particular, character generation is done by the NSPP +kernel rather than by the graphics terminal. + +------------ +From: /u2/tody/ Mon 15:49:33 03-Jun-85 +Package: gio +Title: text generation in the STDGRAPH kernel + +The text generator developed for the NSPP kernel has been installed also in +the STDGRAPH kernel. The "normal" text quality for the stdgraph kernel is +whatever is provided by the hardware character generator on the graphics +terminal. Hardware character generation will be used if the text quality +(G_TXQUALITY) is normal or low; the software character generator is selected +if the quality is set to medium or high. Software character generation +permits arbitrarily sized characters with arbitrary up vectors, making it +possible to prepare plots just as they will appear on when drawn on a plotter +device which does not have hardware character generation. The new character +generator also fixes errors in string justification present in the old +kernel. Strings will now be justified correctly regardless of the text +quality. + +The text quality may be selected by setting the G_TXQUALITY parameter before +calling GTEXT. When working interactively, however, it will be easier to +override the runtime quality attribute by setting the text quality in +cursor mode. A new cursor mode command ".txquality" has been added for +this purpose. For example, after drawing a plot with hardware character +generation and while in cursor mode, type ":.txq h" followed by a 0 to +redraw the plot using software character generation. The "T" keystroke +may be used to interactively draw characters and inspect the font, etc. + +------------ +From: /u2/tody/ Mon 15:59:27 03-Jun-85 +Package: cl +Title: error handling bug fix + +A bug has been fixed in the CL affecting error handling. When error recovery +takes place while within an IFERR in SPP, e.g., after a when the +CL has called a system service which uses error handling, it is necessary +to reinitialize the error handling system. In normal programs this is done +by the error restart code in the IRAF Main, but since the CL has its own +error recovery code it must perform the reinitialization itself during +error recovery. + +------------ +From: /u2/tody/ Mon 16:35:51 03-Jun-85 +Package: gio +Title: character size adjusted + +Ideally the size 1.0 character should be the same size in NDC units on all +graphics devices, otherwise text which is scaled relative to the size 1 +character will come out a different size on the different devices. The NSPP +devices turned out to have character sizes some 20% bigger than the normal +character size for the VT640, our reference graphics device. The hardware +character size of the VT640 could of course not be changed, so I adjusted +the character size in the graphcap entry of each NSPP device to make it agree +with the VT640/4012. + +As as result of this change default size characters on plots will now appear +both taller and narrower than before (note that the aspect ratio of a plotter +device is different than that of the terminal). An entirely reasonable plot +still results. If precise control over the character size is desired, the +character size may in NDC units may be set explicitly, rather than scaling +relative to the device size-1 character. There is currently no way to change +the aspect ratio of a character, since only one size parameter is used for +both axes (this is consistent with GKS). + +------------ +From: /u2/tody/ Mon 18:51:33 03-Jun-85 +Package: gio +Title: error checking of ":.snap" + +The cursor mode command ":.snap" now checks for an error when trying to open +the snap device, printing a warning message if there is a problem rather than +going through error recovery. + +------------ +From: /u2/tody/ Tue 22:51:26 04-Jun-85 +Package: gio +Title: bug fix affecting log scaling + +A case turned up in which glabax would fail to log scale correctly. The +step size between minor ticks was so small that the next major tick +would never be reached, resulting in an infinite loop. This bug has been +fixed and the log scaling code has been extensively tested. + +------------ +From: /u2/tody/ Wed 15:51:50 05-Jun-85 +Package: cl +Title: bug fix in CL + +The internal CL function "breakout" breaks a long form parameter name into +fields, returning a pointer to each field (a long form parameter name is +"task.param" or "package.task.param"). In order to return a pointer to an +EOS delimited string the routine overwrites the periods in the input string +with EOS, returning a pointer to each substring (needless to say, not a good +practice). A bug was found and fixed involving the use of the breakout +procedure in the run time opcode procedures. When such a procedure is +passed an operand which is compiled into the dictionary, the first call to +breakout was modifying the input operand but functioning successfully. +In the second call the same input operand was passed (but modified in the +first call), hence the bug. I added a new procedure called "breakcopy" +which calls breakout on a local copy of the input operand. All calls to +the breakout function in the CL were examined and parcelled into three +cases: [1] breakout called on a local copy, no changes; [2] reentrant call +to breakcopy possible, routine changed to make local copy of operand and +call breakout directly; and [3] simple reference to a nonlocal operand, +call to breakout replaced by equivalent call to breakcopy. Most changes +were of the latter type and occurred in the file opcodes.c. + +------------ +From: /u2/tody/ Wed 16:06:37 05-Jun-85 +Package: fio +Title: bug fix in binary file i/o + +The procedure FWATIO was modified to mark the FIO buffer inactive regardless +of the status returned by an i/o transfer to the buffer. Formerly the +routine would not mark the buffer inactive following an i/o transfer +which returned an error. This would cause the error to "stick" when trying +to read the file (and probably when trying to write it too). + +------------ +From: /u2/tody/ Wed 19:03:06 05-Jun-85 +Package: library +Title: mathematical constants + +A new file has been installed in the system library. This file +contains definitions of various constants and macros useful in numerical +applications. + +------------ +From: /u2/tody/ Thu 20:27:16 06-Jun-85 +Package: fmtio +Title: bug fix in CTOWRD (hence also CTOTOK, GARGTOK) + +The CTOWRD procedure was recognizing newline as a word delimiter even when +the "word" in question was a quoted string or character constant. Since +newlines are permitted in strings and character constants this was an error. +CTOWRD is called by both CTOTOK and GARGTOK, hence the bug affected both +of these routines as well. + +------------ +From: /u2/tody/ Fri 11:44:20 07-Jun-85 +Package: spp +Title: pointer conversions in structures + +Several macros have been added to to facilitate pointer conversions +within structure definitions. These macros convert a struct pointer into a +pointer to some other datatype, e.g., to reference a field of a structure. + + P2C(p) *(struct) -> *char + P2S(p) *(struct) -> *short + P2L(p) *(struct) -> *long + P2D(p) *(struct) -> *double + P2X(p) *(struct) -> *complex + +By definition pointer to struct is equivalent to a pointer to int hence there +is no conversion for integer fields. Also by definition int and real occupy +the same amount of storage, hence pointer conversions are not necessary to +reference fields of type real. Since an SPP pointer is implemented as an +integer it may be stored in an integer field within a structure (we are taking +liberties within struct declarations that should not be taken in regular code). + +Sufficient storage should be allocated for each CHAR or SHORT field of a +structure to permit variations in the actual size of a char or short on the +host machine. Allocate one full struct unit for each storage element of +type char, short, int, long, or real. Allocate two struct units per double +or complex element. When storing character strings in a structure, dimension +the string odd and allow one extra char for the EOS. Double and complex fields +must have double alignment with the pointer to the start of the structure, +i.e., a double or complex field must be placed at an offset of 0, 2, 4, etc. +struct units from the start of the structure. + +Example: + + define LEN_ASTRUCT (10+40+40) + define SZ_NAME 39 + + define A_FD Memi[$1] + define A_STATUS Memi[$1+1] + define A_SCALE Memd[P2D($1+2)] + define A_OFFSET Memd[P2D($1+4)] + # (extra space) + define A_NAME1 Memc[P2C($1+10)] + define A_NAME2 Memc[P2C($1+50)] + + +Note that the offset into the structure is always given in struct units. +It is good practice to allow extra space for expansion. Likewise it is +advisable to place char storage at the end of the structure to allow for +expansion without having to recompute the offsets of the scalar fields. + +If these rules are followed the resulting structure definitions should be +portable to most or all IRAF host machines without change. + +------------ +From: /u2/tody/ Sun 22:31:53 09-Jun-85 +Package: fmtio +Title: new procedures added to the strings package + +Two new procedures have been added to the strings subpackage of FMTIO. The +new procedures, more general versions of the old routines STRIDX and STRLDX, +are called STRIDXS and STRLDXS and differ from the original routines in that +the first argument is a string defining a set of characters to be searched +for, rather than a single character. + + index = stridx (ch, str) # first occurrence of CH in STR + index = stridxs (set, str) # first occurrence of SET[i] in STR + index = strldx (ch, str) # last occurrence of CH in STR + index = stridxs (set, str) # last occurrence of SET[i] in STR + +I have been thinking of adding these procedures for some time since there +have been numerous occasions on which they would have been useful. The addition +of the new routines at this particular time was prompted by the redefinition +of a character constant as an integer value. The following statement is now +illegal since the first argument is an integer rather than char scalar: + + ip = stridx ('a', str) # BAD!! + +Rather than define a char variable to convert this into a legal statement, +the following form may be used instead: + + ip = stridxs ("a", str) + +------------ +From: /u2/tody/ Sun 22:42:40 09-Jun-85 +Package: spp +Title: revision to the SPP language standard + +The original standard for the SPP language, which has remained unchanged since +its first definition several years ago, defined a character constant (e.g., 'a') +as a numeric constant of type CHAR. It has recently become apparent that +the SPP language can be simplified by redefining the character constant as an +integer constant. With this new definition the following are all legal +integer constants, equating to 32 decimal: + + 32 + 40B + 20X + ' ' + +Likewise, the following are all equivalent to the decimal integer 49 (SPP +specifies that characters are represented internally in ASCII): + + 49 + 61B + 31X + '0' + 1 + TO_DIGIT(1) + +This change requires that all existing code which uses character constants +in argument lists be changed, since it is illegal to pass an integer argument +to a procedure expecting an argument of type char. A complete list of all +such (newly) illegal statements has been prepared by automatic means and +the affected code is in the process of being revised. + +------------ +From: /u2/tody/ Mon 19:23:58 10-Jun-85 +Package: fio +Title: new routines added to FIO + +Two new procedures PUTCI and GETCI have been added to the FIO interface. +These are integer versions of the old procedures PUTC and GETC. + + ch/EOF = getci (fd, ch) # int fd, ch, getci() + putci (fd, ch) + + ch/EOF = getc (fd, ch) # int fd; char ch, getc() + putc (fd, ch) + +The new routines are functionally identical to the old ones but eliminate +the char scalar argument and function value (which can cause portability +problems). PUTCI is particularly useful for the output of character +constants, e.g.: + + call putci (fd, '\n') + +This is certainly a kludge, but both types of procedures are useful depending +on the application, and the revision is upwards compatible. In the ideal +world a better solution would be for SPP to accept either char or integer +scalar arguments but always pass an integer in the argument list, like C. +This is beyond the capabilities of the current preprocessor because it does +not parse expressions and keep track of their datatypes. + +------------ +From: /u2/tody/ Tue 09:53:06 11-Jun-85 +Package: fmtio +Title: argument datatype changed in DTOC, XTOC + +The datatype of the "format" argument to DTOC and XTOC has been changed from +CHAR to INT, since the actual argument in typical calls is usually an explicit +character constant, e.g., 'f', 'e', or 'g'. + +------------ +From: /u2/tody/ Tue 13:19:28 11-Jun-85 +Package: system +Title: minor revisions to match argument types + +Approximately 75 lines of code were modified to match argument datatypes +(char to char, int to int) as a result of the recent change in the SPP +language standard. The count of number of lines of code modified does not +include numerous related modifications made in declarations, etc. Some of +the affected routines were quite old and were cleaned up and made more +efficient in the process. Most of the changes were procedure name changes, +e.g.: + + putc -> putci + stridx -> stridxs + +The following files were affected. + + +PKG: + utilities + decod_tablst.x t_translit.x + help/lroff + breakline.x center.x justify.x lroff.x section.x + do_ls.x output.x skiplines.x + help + prblkhdr.x hbgetblk.x hbgetblk.x hinput.x + manout.x manout.x manout.x modtemp.x + images + imheader.x hedit.x + imdebug/dump.x + tv/display zopnim.x + softools/yacc/debug + ytab.x(dc.y) + system + page.x directory.x match.x beep.x + plot + graph.x + +SYS: + clio + clcmd.x zfiocl.x + fmtio + ctocc.x dtoc.x xtoc.x strtbl.x fmtstr.x parg.x + gio + nspp/encode.x stdgraph/stgencode.x glabax/glbtitle.x + cursor/(rcursor.x,grcstatus.x,grccommand.x) + debug + realio.x nop.x clio.x strings.x fio.x fio2.x words.x plot.x + mtio + mtgetpos.x + tty + ttyputline.x ttyinit.x debug.x + etc + erract.x sys_ptime.x x_debug.x envlist.x propen.x main.x + xerstmt.x + fio + x_debug.x, fchdir.x vfntrans.x + imio + immap.x db/imgetb.x db/imaddf.x db/imdelf.x + fmtio + chrupr.x chrlwr.x dtoc.x fpradv.x patmatch.x pargx.x + mtio + mtposition.x mtdevlist.x + tty + ttyputline.x + + +For the most part the modifications were trivial and should not cause any +problems. Routines where were more heavily modifed include the pattern +matching code in FMTIO and the character output code in LROFF (HELP). + +------------ +From: valdes$iraf/ Thu 10:29:36 13-Jun-85 +Package: xtools +Title: Simple text database tools + +Some simple text database tools have been added to the xtools library. +Some help text under the name dttext is available through the help task. +The source code is in dttext.x in the xtools directory. These tools are +useful for keeping multiple database text entries in one file. These tools +are in use in the longslit package. + +------------ +From: /u2/tody/ Fri 13:26:57 14-Jun-85 +Package: spp +Title: SPP compiler revisions + +The first pass of the SPP compiler, i.e., the C program XPP, has been +modified as follows: + + [1] A new file "decl.c" was added containing a package of routines for + parsing argument lists and declaration statements. As arguments and + declarations are parsed each argument or local variable is added to + an internal symbol table. When a procedure has been fully processed + a code generation routine is called to output the RPP declarations + required by the second pass. + + Declarations are output in the following order: (1) scalar arguments, + (2) array arguments, (3) local variables, (4) miscellaneous + declarations (commons, errchk, etc.), (5) switch variables and string + array names, (6) data statements. This ordering is independent of + the order in which these items occur in the source. The output + ordering is as required by Fortran. + + This revision was made to permit correct generation of Fortran code + for the following type of case, which is quite common in IRAF: + + procedure alpha (fd, x, xlen) + + pointer im + real x[xlen] + int xlen + + begin + + + Previously the Fortran generated for this procedure would have + declared the OUTSTR array and then the MAXCH scalar. This is illegal + Fortran because the length argument XLEN would be used to dimension + X before being declared as an integer argument; some compilers would + accept such a construct and compile it correctly, while others would + conclude that XLEN was a real by applying the autotyping convention of + Fortran. This is no longer a problem because SPP will reorder the + argument list to suit Fortran. + + [2] In addition to reordering argument lists, the new code will also + detect multiple declarations of the same identifier, printing a + warning message for each such case found. + + [3] XPP (the first pass of the preprocessor) now prints the name of each + procedure as it is processed, in addition to the name of each file + processed. This gives the user more feedback on the progress of the + compile, particularly when a large file is being compiled on a slow + machine. Typically the filename will appear, then there will be a + delay while all the header includes are read in, then the individual + procedures in the file will be processed, then there will be a delay + while RPP is called to generate the Fortran output file. + +Related changes were required in the lexical analyzer (file xpp.l) and in the +file xppcode.c. In particular the way in which context sensitivity is handled +was completely changed, removing all of the old context variables and replacing +them with a single multistate variable named "context". Additional buffering +was added (the symbol table and another buffer for miscellaneous declarations), +hence now an entire procedure is buffered internally before any output is +generated. Comments are no longer passed to RPP. By stripping comments and +optimizing character output the performance of XPP was improved by 25%. + +------------ +From: tody$ Fri 21:48:40 14-Jun-85 +Package: vops +Title: precision of VOPS projection functions increased + +The VOPS function procedures ASSQ, ASUM, and ADOT have been changed to +accumulate the sum of squares, sum, or dot product as a variable of type +real, double, or complex depending upon the datatype of the procedure. +The function value was also changed to return a floating point value of +the correct precision. Formerly both the sum and the function value +were of type PIXEL, making the procedures of little value for integer +vectors. + +------------ +From: tody$ Sun 21:13:22 16-Jun-85 +Package: system +Title: filename changes + +All files in the lib$ and sys$ directories (excluding lib$xtools) with names +longer than 9 characters or which contained underscore characters were renamed. +This eliminates the need to mess with filename mapping (except for filename +extensions) when bootstraping the system on a foreign host. There is no need +to do the same thing for the applications packages since the IRAF VOS will +handle the filename mapping once the core system is up. + +------------ +From: tody$ Sun 21:17:32 16-Jun-85 +Package: math +Title: nonportable constructs fixed in math packages + +The bevington fortran sources had nonstandard UNIX continuation (& in col 1). +This was changed to Fortran standard continuation (char in col 6). +The file llsq/sva.f was found to have errors in the hollerith format +statements at the end of the file. The version of the file from VMS IRAF +was substituted for the UNIX version, after verifying that the only +differences were in the format statements. Neither library has been +recompiled as yet. + +------------ +From: /u2/tody/ Thu 19:34:06 20-Jun-85 +Package: cl +Title: logout change, bug fix + +The CL will no longer automatically deallocate magtape drives when logging +out. This greatly speeds up logout and permits the same user to logout +of a second CL while the first still has a tape drive allocated (formerly +the drive would be deallocated). + +Since deallocation is no longer automatic, people will inevitably forget +to deallocate the tape drive. The next user to attempt to allocate the +drive will get a "drive already allocated" error message, even if the user +has deallocated the drive at the host system level. When this occurs +delete the file "dev$mta.lok" or "dev$mtb.lok", making certain by first +typing the file that it is not in use. If this file does not exist IRAF +assumes that the drive can be allocated to someone else. The file MUST +exist while a drive is being accessed. + +A recent bug fix has been made which will probably cure the bug which has +been causing parameter values to be overwritten with garbage when a task +exits. + +------------ +From: tody$ Thu 19:42:41 20-Jun-85 +Package: gio +Title: graphics kernels + +Recently all filenames in the iraf VOS were changed which were longer than +9 characters or which contained underscores. Some runtime files were affected, +in particular the graphics kernels, "lib$x_stdplot.e" and "lib$x_stdgraph.e". +These are now named "lib$xstdplot.e" and "lib$xstdgraph.e". + +The system tasks spawned by the graphics kernels when "gflush" is typed +are now submitted with a reduced priority of 4. + +------------ +From: tody$ Thu 19:42:41 20-Jun-85 +Package: system +Title: merge + +A merge of the VMS and UNIX versions of IRAF is in progress. A number of +changes have been made which have not yet been recorded by revisions notices. +These will be summarized when the merge is complete. + + +------------ +From: valdes$iraf/ Mon 14:11:37 01-Jul-85 +Package: generic +Title: Changes to lineflat and colflat + +The task lineflat for creating flat fields by ratioing the image lines +by function fits to the image lines has been changed. It used to be +a simple script calling the task linefit in the images package. Now it +it is a complied task which is similar to linefit. This allowed the +addition of a new parameter specific to the flat field problem. The +new parameter is call minflat. If the fitted value is less than the +value of this parameter the flat field value is set to unity. + +The task colflat used to be a script calling linefit. Now it calls lineflat +and, hence, has the minflat parameter. + +------------ +From: valdes$iraf/ Tue 16:49:50 02-Jul-85 +Package: gtools +Title: Expanded gtools structure + +The gtools structure has been expanded to include a title, xlabel, and +ylabel. The call gtlabax in place of glabax will call glabax with the +appropriate strings. If the gtools pointer is null then glabax will +be called with no strings. The initialization is null strings. +Calls to gt_sets and gt_gets are used to set and get the strings +with the parameters GTTITLE, GTXLABEL, and GTYLABEL from gtools.h. +gt_colon has also been modified to respond to :title, :xlabel, and +:ylabel. These changes do not affect any code except those which +use the colon parameters title, xlabel, and ylabel. + +------------ +From: valdes$iraf/ Mon 15:28:57 08-Jul-85 +Package: images +Title: New magnify + +The magnify task has been rewritten using the new two dimensional interpolation +and boundary extension packages. Thus, magnify will now do true two +dimensional interpolation. The block averaging aspect of the old magnify +has been eliminated (use blkaverage first if desired). + +------------ +From: valdes$iraf/ Tue 14:18:36 09-Jul-85 +Package: local +Title: New task imfunction + +A new task called imfunction has been added to the local package. It +applies a function to the input pixel values to produce an output image. +Currently only the log (base 10) function is available but other functions +can easily be added. This task differs from imarith in that imarith is +a binary operator and imfunction is a unary operator. + +------------ +From: /u2/davis/ Fri 15:25:04 12-Jul-85 +Package: dataio +Title: rcamera mod + +RCAMERA now writes the total time since last readout, and the total shutter +open time in the IRAF image header as well as the integration time. + +------------ +From: /u2/davis/ Wed 11:51:13 17-Jul-85 +Package: images +Title: shiftlines bug + +Shiftlines was not calculating the fractional pixel shifts correctly in +the case of boundary extension. Instead it was shifting by the nearest +integer, i.e 1 if shift=1.5. + +------------ +From: /u2/davis/ Mon 09:32:44 22-Jul-85 +Package: dataio +Title: rfits mod + +The parameters blank has been added to the RFITS task. Blank values in the +FITS image will be replaced in the IRAF image by the user defined quantity +blank. Appropriate type conversion will be performed on blank. For example +if blank = -1.5 and the output image type is real, blank pixels will have +the value -1.5; if the output image type is integer, blank pixel values will +have the value -1. + +------------ +From: valdes$iraf/ Mon 14:15:47 29-Jul-85 +Package: images +Title: Changes + +1. The task revisions has been added to page revisions to the images +package. The intent is that each package will have a revisions task. +Note that this means there may be multiple tasks named revisions loaded +at one time. Typing revisions alone will give the revisions for the +current package. To get the system revisions type system.revisions. + +2. A new task called fit1d replaces linefit. It is essentially the same +as linefit except for an extra parameter "axis" which selects the axis along +which the functions are to be fit. Axis 1 is lines and axis 2 is columns. +The advantages of this change are: + + a. Column fitting can now be done without transposing the image. + This allows linefit to be used with image sections along + both axes. + b. For 1D images there is no prompt for the line number. + +------------ +From: valdes$iraf/ Mon 14:17:40 29-Jul-85 +Package: generic +Title: Changes + +July 26, 1985: + +1. Help page available for flat1d. + +2. Background has been modified to use new fit1d task. It now does +column backgrounds without transposes and allows image sections. +------ +July 25, 1985: + +1. A new task called flat1d replaces lineflat and colflat. It is +essentially the same as lineflat except for an extra parameter "axis" +which selects the axis along which the 1D functions are to be fit. +Axis 1 is lines and axis 2 is columns. The advantages of this change are: + + a. Column fitting is done without transposing the image. + b. The colflat script using image transpositions would not + work the same as lineflat when used with sections. Now + it is possible to mosaic several flat fields as need with + multiple slits or apertures. + c. Because no transpose is needed and it is not a script + flat1d should work faster than colflat. + d. The prompts for interactive fitting are now correct when + doing column fits. +------ +July 23, 1985: + +1. The task revisions has been added to page revisions to the generic +package. The intent is that each package will have a revisions task. +Note that this means there may be multiple tasks named revisions loaded +at one time. Typing revisions alone will give the revisions for the +current package. To get the system revisions type system.revisions. + +2. The tasks linebckgrnd and colbckgrnd have been combined into one +task with the extra hidden parameter "axis". With axis=1 the task +is the same as linebckgrnd and with axis=2 the task is the same as +colbckgrnd. + diff --git a/doc/revsfile b/doc/revsfile new file mode 100644 index 00000000..2b7dd76a --- /dev/null +++ b/doc/revsfile @@ -0,0 +1,251 @@ +------------ +From: /u2/davis/ Thu 16:47:49 01-Aug-85 +Package: images +Title: new images tasks + +The tasks ROTATE, IMLINTRAN and GEODISTRAN have been added to the images +package. ROTATE rotates and shifts an image. IMLINTRAN will rotate, rescale +and shift an an image. GEODISTRAN corrects an image for geometric distortion. + +------------ +From: /u2/davis/ Fri 18:14:12 02-Aug-85 +Package: images +Title: new images task + +A new task GEOMAP has been added to the images package. GEOMAP calculates +the spatial transformation required to map one image onto another. + +------------ +From: /u2/davis/ Tue 08:27:09 06-Aug-85 +Package: images +Title: imshift bug + +Imshift was shifting incorrectly when an integral pixel shift in x and +a fractional pixel shift in y was requested. The actual x shift was +xshift + 1. The bug has been fixed and imshift will now work correctly for +any combination of fractional and integral pixel shifts + +------------ +From: /u2/davis/ Fri 10:53:18 09-Aug-85 +Package: dataio +Title: reblock mod + +The task REBLOCK has been modified so that it will trim as well as pad +logical records. + +------------ +From: /u2/davis/ Fri 15:05:31 09-Aug-85 +Package: math +Title: math documentation + +The documentation for the 2D interpolation routines has been added +to the math package. + +------------ +From: /u2/davis/ Mon 15:55:45 12-Aug-85 +Package: math +Title: gsurfit package + +A set of routine for fitting surfaces and accompanying documentation +have been installed in the math package. + +------------ +From: /u2/davis/ Tue 08:26:19 01-Oct-85 +Package: images +Title: fmedian, median + +Two median filtering tasks have been added to the images package. Fmedain +is a fast median processing routine which utilises the image histogram to +calculate the median at each window position. Fmedian is best suited to +integer data. Median is a more general routine which uses a sorting technique +but takes longer to execute. + +------------ +From: /u2/davis/ Thu 17:06:15 03-Oct-85 +Package: images +Title: minmax bug + +Minmax was not calculating the minimum correctly for integer images. + +------------ +From: /u2/davis/ Mon 10:51:05 21-Oct-85 +Package: images +Title: imsurfit bug + +An error in pixel rejections cycle of IMSURFIT corrected. The routine +make_ranges was not successfully converting a sorted list of rejected pixels +into a list of ranges in all cases. + +------------ +From: /u2/hammond/iraf/ Tue 16:45:33 29-Oct-85 +Package: dataio +Title: New task installed + +Task rtextimage, which converts text files to IRAF images, has been installed +in the dataio package. + +------------ +From: tody Thu Nov 7 22:25:20 MST 1985 +Package: cl +Title: foreign tasks in the CL + + A new type of task called a "foreign task" has been added to the CL. This +facility was added primarily to provide an improved interface for the bootstrap +utilities XC and MKLIB, but may be used to access any host system utility to +enhance one's personal IRAF environment. The foreign task facility is a type +of OS escape, hence should not be used in mainline software. + +One ore more foreign tasks may be defined with the TASK statement by setting +the "physical task name" to the special value "$foreign", e.g., + + task $xc, $mklib, $make = "$foreign" + +A foreign task, once defined, may be called by name like any other IRAF task, +without the overhead of processing a script task containing an OS escape. +The argument list of a foreign task is parsed exactly like that of any other +task, allowing the string value of a parameter to be generated by any CL +expression. Full i/o redirection is supported. + +A foreign task is run by passing a string command to the host system with +ZOSCMD. The command is built up by concatenating the task name with the +values of the argument strings in the order in which they appear on the command +line, inserting a blank between each string argument. Foreign tasks may have +parameter files, but normally there will be no parameter file and the arguments +will be given in the same syntax one would use when operating outside the CL. +This provides a more direct interface and eliminates needless restrictions and +the need to learn a second syntax for the same command (e.g., xc and xcompile). + +An additional advantage of the foreign task interface is that i/o redirection +is implemented without the temporary files used for !cmd type OS escapes. +In other words, given a command such as + + xc -cO file1.x file2.x >& spool & + +output will be written directly into the spool file during task execution, +rather than copied to the spool file after task execution. This prevents +stdout and stderr from being separated and permits use of TAIL during execution +to see how things are going (at least on UNIX). + +Since flags beginning with - are so common in UNIX, "lexmodes" has been +enhanced to treat arguments beginning with a minus (or plus) sign as string +constants. + +The softools tasks XC, MKLIB, and MAKE have been redefined as foreign tasks +and the new version of the CL which supports foreign tasks has been installed. +MAKE will probably be deleted from softools in the near future. +------------------------------------------------------------------------------ + +sys/clio/zfiocl.x + In zardps(), in the first call to zardpr, changed the third argument + to SZ_NUMSTR * SZB_CHAR; would cause XFER failure on AOS. (11/8 dct) + +pkg/cl/unop.c +pkg/cl/gram.c +pkg/cl/operand.h + Added a new CL intrinsic function osfn(). This function takes a + virtual filename as input and returns a host system filename as output. + (11/9 dct) + +sys/os/zfiotx.c [UNIX] + Modified terminal (text file) driver to mask parity bit when reading + from the terminal in raw mode. (11/10 dct) + +pkg/cl/* + Merged revisions from the VMS version of the cl into the unix sources. + These consisted mostly of VMS/C compiler workarounds, some allocate + stuff (deactivated in unix/iraf currently), and other minor changes. + (11/11 dct) + +sys/fio/ffault.x + When faulting in the FIO buffer on a write-only file, not at EOF, + the ITOP pointer would be set to the start of the buffer rather than + to the end, as it is if the buffer is actually filled from the file. + When the buffer is later flushed the amount of data written would be + less than a full buffer if the full buffer had not been written into. + Modified to set ITOP to BP+BUFSIZE when filling the buffer on a write + only random access file, not at EOF. (11/13) + +sys/gio/stdgraph/stgencode.x + Changed the code for \ch in compile mode to push the escaped character + rather than output it. Reversed the arguments to ; (goto) to match + the order described in the documentation. (11/14) + +sys/gio/stdgraph/tshowcap.x + Installed a new version which supports boolean capabilities, scan + cursor, etc. (11/14) + +sys/libc/cmain.c + Deleted this file from the library, since it causes linker problems and + it no longer used (cl.x defined ONENTRY and calls c_main directly). + (11/15) + +pkg/cl/task.h +pkg/cl/builtin.c + Added user definable OSCMD prefix strings to the foreign task interface. + This removes the restriction that the host task name be equivalent to + the logical task name, e.g., permitting calling the host task with a + full pathname, with a different name, with switches, etc. (11/15) + +pkg/cl/builtin.c +pkg/cl/task.h + Generalized the foreign task interface to permit user specification + of the foreign command prefix string. In the case + + task $ltname = $foreign + + the foreign command prefix string defaults to "ltname", and multiple + foreign tasks may be declared in a single statement. In the case + + task $ltname = $prefix + + the command sent to the host system will begin with the given prefix + string, which may be different from the ltask name and which may + contain whitespace. For example, + + task $who = "$show users" + + will perform the UNIX "who" function on a VMS system. On a UNIX + system, + + task $renice = "$/etc/renice" + + would make the renice task available as a CL task, even though the + /etc directory is not normally in one's search path. (11/16) + +sys/os/zwmsec.c +sys/os/Makelib +lib/libc/knames.h KERNEL CHANGE +------------------------------------------------------------------------------- + New module ZWMSEC added to package OS. The new kernel operator + suspends process execution for the indicated number of milliseconds. + (11/18) +------------------------------------------------------------------------------- + +sys/fmtio/printf.h + Changed the size of the internal printf buffer from SZ_LINE to 1024 + to reduce the possibility of truncation when printing strings. (11/27) + +sys/fmtio/Makelib + Several files which included printf.h did not list it as a dependency + in the Makelib file. (11/27) + +sys/etc/main.x + Did not permit parameters with upper case names. (11/27) + +pkg/cl/exec.c + Simplified the mk_startupmsg procedure slightly, while looking for + a problem that turned out to be elsewhere. (11/27) + +pkg/cl/task.h + Two of the T_XXX task bit flags had the same value. (11/27) + +pkg/cl/bkg.c + When a new CL is installed while someone is using the old one, + the core image bkgfile produced when a bkg job is submitted by + the old CL may not be usable by the new CL. The CL checks for + this when reading the bkgfile, but error recursion was occurring + due to the call to EPRINTF to report the error. This was replaced + by a call to fprintf(stderr since EPRINTF is higher level (it + requires a stacked task descriptor which is not there until the + bkg file has been read) and cannot be used during process startup. + (11/27) diff --git a/doc/sgi.ms b/doc/sgi.ms new file mode 100644 index 00000000..da75b28c --- /dev/null +++ b/doc/sgi.ms @@ -0,0 +1,570 @@ +.RP +.TL +The IRAF Simple Graphics Interface (SGI) +.AU +Doug Tody +.AI +.K2 "" "" "*" +August 1986 + +.AB +.ti 0.75i +The IRAF Simple Graphics Interface (SGI) provides a straightforward way of +interfacing batch plotter devices such as laser printers and raster or pen +plotters to the IRAF graphics i/o subsystem (GIO) to provide high quality +graphics hardcopy. To minimize the knowledge of the IRAF system internals +required to interface a new device, the device interface is implemented as +a user written host Fortran or C program taking as input an SGI format +metacode or raster plot file written by the IRAF graphics subsystem. +To simplify the task of the host system program (and hence of the programmer +who writes it), as well as to minimize the size and complexity of the +interface, as much work as possible is done in the high level, device +independent SGI kernel. The result is a surprisingly clean and efficient +interface to which new devices can typically be added in a matter of hours, +starting from the code for an existing SGI device interface. +.AE + +.NH +Introduction +.PP +The IRAF graphics subsystem defines three classes of graphics devices: +interactive vector graphics devices, e.g., graphics terminals or bit-mapped +graphics workstations (class \fLSTDGRAPH\fR), semi-interactive image display +devices (class \fLSTDIMAGE\fR), and noninteractive or batch plotter devices +(class \fLSTDPLOT\fR). Our concern here is with the \fLSTDPLOT\fR class of +graphics devices, the output only, medium to hiqh quality plotter devices. +The typical \fLSTDPLOT\fR device is a laser printer, raster plotter, +or pen plotter. +.PP +The SGI interface is not the only plotter interface provided by IRAF. Other +plotter interfaces currently provided by IRAF are the \fIcalcomp kernel\fR, +useful when a Calcomp compatible plotter library is available, and the +\fInspp kernel\fR, useful when the NCAR graphics software is available on +the host machine. Additional interfaces (GIO kernels) are planned for the +\fICGI\fR, \fIGKS\fR, and \fIPostscript\fR graphics standards. +The principal advantage of the SGI interface is that it is vastly simpler +than these alternative interfaces as well as highly efficient. +In cases where the plotter device +in question is not already supported on the local host by one of the standard +graphics libraries, it will probably be much easier to build an SGI dispose +task than to add a new device driver to the standard graphics library. + +.NH +Overview +.PP +The Simple Graphics Interface (SGI) allows any plotter device to be interfaced +to IRAF with a minimum amount of work, and with minimum knowledge of the IRAF +system internals. This is achieved by having the IRAF graphics system do +virtually all the work, producing as output a simple format \fIplot file\fR +containing the information required to produce one or more graphics frames. +A user supplied host system \fIdispose task\fR is then called to dispose of +the output to a specific host system plotter device. +.PP +The architecture and dataflow of the SGI interface in the normal runtime +multiprocess configuration is shown in Figure 1. +Graphics output destined for an SGI device interface starts out as +\fIGKI metacode\fR produced by an IRAF applications program running as a +subprocess of the CL. The GKI metacode may be spooled in a metafile as is +shown in the figure, but normally it is sent by the applications subprocess +directly to the SGI kernel by writing to one of the IPC pseudofile streams +(usually \fLSTDPLOT\fR for a plotter device), with the IPC data being routed +through the CL. +.PP +When \fLSTDPLOT\fR becomes active the CL will fetch the graphcap entry for the +plotter device specified by the user, e.g., the value of the environment +variable \fIstdplot\fR. The graphcap entry for a plotter device contains +an entry (\fIkf\fR) specifying the filename of executable containing the +graphics kernel to be run. In our case the graphics kernel is the +SGI kernel (\fLbin$x_sgikern.e\fR), a conventional portable and device +independent GIO graphics kernel. +.PP +The SGI kernel takes as input GKI metacode, translating all high level graphics +and text drawing instructions into simple pen-up pen-down moves, writing the +SGI plot file as output. When the maximum frame count has been reached, +when the user logs out of the CL, or when the command \fIgflush\fR is entered, +the SGI kernel issues a command to the host system to dispose of the plot file +to the plotter. The host command interpreter executes the dispose command, +calling the user supplied \fBdispose task\fR to dispose of the plot file to +the plotter. The plot file is then deleted, either by the SGI kernel or by +the dispose task itself. + +.DS +.PS 5 +.ps -1 +CL: box wid 0.9i "CL" + line -> right 2.0i at CL.e "dispose" "command" +CI: box wid 0.9i "Host" "CL" + line <-> down 0.8i at CL.s +SGI: box wid 0.9i "SGI" "kernel" + line -> down 0.8i at CI.s +HT: box wid 0.9i "dispose" "task" + +PF: ellipse wid 0.9i "plot" "file" at SGI.e + (1.0i,-0.8i) + line -> from SGI.s + (.2,0) then to PF.w + line -> from PF.e then to HT.s - (.2,0) +PQ: ellipse wid 0.9i "plotter" "queue" at HT.e + (1.0i,-0.8i) + line -> from HT.s + (.2,0) then to PQ.w +GKI: ellipse wid 0.9i "GKI" "metacode" at SGI.w + (-1.0i,-0.8i) + line -> from GKI.e then to SGI.s + (-.2,0) + +GCAP: ellipse wid 0.9i "graphcap" at CL.s + (-1.5i,-0.4i) + line -> from GCAP.e + (0, 0.1) then to CL.w + line -> from GCAP.e + (0,-0.1) then to SGI.w +.PE +.ps +.sp +.ce +Figure 1. SGI Architecture and Dataflow +.DE + +.PP +The SGI kernel can produce two types of plot files: +\fBmetacode files\fR, wherein all text and vector drawing instructions have +been reduced to simple pen up and pen down drawing commands, +and \fBraster files\fR, simple two dimensional boolean arrays (bitmaps). +Metacode files are used to drive intelligent devices such as laser printers, +non-raster devices such as pen plotters, and to interface to host graphics +libraries such as the Calcomp and PLOT10 libraries. Raster files are used +to drive raster devices, such as the Printronix, Trilog, Versatec, and so on. +.PP +Fortunately, one does not have to understand all this in any detail to +implement an SGI interface for a new device. +To interface a new graphics device via SGI one must [1] add an entry for the +new SGI device to the IRAF \fIgraphcap\fR (graphics device capability) file, +and [2] write and test the host level SGI dispose program. The dispose task, +a conventional host dependent Fortran or C program, is typically only several +hundred lines of code and can usually be written by adapting the code for an +existing SGI device. The graphcap entry defines the physical and control +parameters for the device, and is typically only half a dozen lines of text. +.PP +The SGI interface is not called simple because the IRAF graphics subsystem is +simple (it isn't), but because the interface defined by the SGI plot file is so +small and well defined. Once the dispose task functions correctly when run +manually on a test SGI plot file, it can be expected to run correctly in the +multi-process configuration described above as well. + +.NH +The SGI Graphcap Entry +.PP +All graphics devices supported by IRAF must have an entry in the graphics +device capability file, \fLdev$graphcap\fR. Often a \fBphysical device\fR will +have more than one entry, e.g., when the device is supported by more than one +GIO graphics kernel. The \fBlogical device name\fR specified by the user +determines which graphcap entry, and therefore which GIO graphics kernel, +will be used to process the GKI metacode output by the applications program. +The graphcap file format and usage is discussed in more detail in the paper +\fIGraphics I/O Design\fR, but for completeness we will present the essential +concepts here as well. +.PP +The graphcap entry for a device contains two distinct classes of device +parameters. The parameters with lower case names, e.g., `kf', `xr', and so on, +are the \fBgeneric device parameters\fR. The generic parameters are defined +for all graphics devices, with default values if omitted from the graphcap +entry for a device. The generic parameters are used to control the device +independent part of the graphics system. +The parameters with upper case names, e.g., `DD', `PX', and so on, are the +\fBkernel control parameters\fR. These are defined only for one particular +type of graphics kernel, and are used to control the device dependent operation +of that kernel. Often the same kernel parameter will be used by two different +kernels in a slightly different way, creating a possible source of confusion. +.PP +Of the generic parameters, only two are absolutely required for a kernel to +function (\fLkf\fR and \fLtn\fR). A couple more generic parameters are +required for text to come out the right size. Several more are usually added +to define the physical characteristics of the plotter. The recommended +minimum set of generic parameters for an SGI device are shown in Figure 2. + +.DS +.TS +center; +ci ci ci +c c l. +parameter recommended default description + +ch 0.0294 character height in NDC units +cw 0.0125 character width in NDC units +kf bin$x_sgikern.e executable containing kernel task +tn sgikern name of the kernel task to be run +xr,yr - device resolution in X and Y (pixels) +xs,ys - device scale in X and Y (meters) +zr 1 device resolution in Z (greylevels) +.TE +.sp +.ce +Figure 2. Generic graphcap parameters for an SGI device +.DE + +.PP +The SGI kernel parameters fall into two subclasses, those parameters which +pertain to both metacode and raster output, and those used only for raster +output. There are currently no special parameters for controlling the format +of metacode output (since there is only one format). The parameters common +to both metacode and bitmap devices are defined in Figure 3. +.PP +The function of most of the SGI control parameters should be self explanatory. +Since the graphcap entry is read at runtime, new values for any of these +parameters take effect immediately (unless the graphcap entry is cached +somewhere), making it easy to tune the graphcap entry for a device. +.PP +The most critical parameter in an SGI graphcap entry is the DD parameter, +the device-dispose control string. The DD entry has the following three fields: +.DS +\fIdevice, plotfile, dispose_command\fR +.DE +The \fIdevice\fR field should be the logical device name; it is required as a +placeholder but is not actually used at present. The \fIplotfile\fR field +is the root name for the temporary plot file; the SGI kernel will use this +to construct a unique temporary file name. This is normally set to +\fLtmp$sgk\fR, causing the plot files to be placed in the IRAF logical +directory \fLTMP\fR. Lastly, the \fIdispose_command\fR field is the command +to be sent to the host system command interpreter to dispose of the plot file +to the plotter queue. The dispose command can be almost anything; some +examples will be given later. The sequence \fB$F\fR appearing anywhere in +the dispose command string is replaced by the host equivalent of the computer +generated plot file name before the dispose command is executed. + +.DS +.TS +center; +l l. +DB have the kernel print debug messages during execution +DD host command to dispose of metacode file ($F) +FE output a frame instruction at end of plotfile +FS output a frame instruction at start of plotfile +MF multiframe count (max frames per job) +NF store each frame in a new file (rather than all in one file) +RM boolean; if present, SGK will delete plot files +RO rotate plot (swap x and y) +YF y-flip plot (flip y axis) (done after rotate) +.TE +.sp +.ce +Figure 3. SGI kernel control parameters +.DE + +.PP +The integer parameter MF sets a limit on the maximum number of graphics frames +to be buffered by the kernel before the output is disposed of. Typical values +are 1, 8, or 16. If the boolean parameter NF is present in the graphcap entry +for the device each frame will be stored in a separate file, otherwise all +frames are concatenated together in the same file. If multi-file output is +enabled, i.e., if MF is greater than 1 and NF is asserted, then the individual +plot file names will have the root name \fL$F\fR, e.g., \fLtmp$sgk1234a\fR, +and a numeric extension, e.g., ".1", ".2", and so on. For example, on a UNIX +host, the DD string might contain a file template such as \fL$F.[1-8]\fR to +match up to eight frame files in multi-file output mode. + +.DS +\fLsgiver|uver|UNIX/SGI versatec interface:\\\\ + :kf=bin$x_sgikern.e:tn=sgikern:xs#.200:ys#.200:\\\\ + :xr#1536:yr#1536:zr#1:cw#.0125:ch#.0294:\\\\ + :BI:YF:BF:LO#1:LS#2:PX#2112:PY#1576:\\\\ + :XO#300:YO#40:XW#1536:YW#1536:MF#8:NF:\\\\ + :DD=uver,tmp$sgk,!{ lpr -Pvup -s -r -v $F.[1-8]; }:\fR +.sp +.ce +Figure 4. Sample SGI graphcap entry +.DE + +.PP +A complete example of an actual SGI graphcap entry is given in Figure 4. +Since this is a runtime file the syntax (which is patterned after the UNIX +\fItermcap\fR) is concise and unforgiving, but it matters little since it +is so simple. Note that the entire entry is actually a single logical line +of text, using the backslash convention to continue the entry on multiple +physical lines. The entry consists of a list of logical device name aliases, +followed by a list of device parameters delimited by colons, with the whole +delimited by the first unescaped newline encountered. Whitespace immediately +following an escaped newline is ignored, elsewhere it is data. Numeric +constants must be preceded by the character \fL#\fR to be interpreted as such. +.PP +The remaining SGI kernel parameters are those used to control the generation +of raster output. Discussion of these parameters is deferred to the +description of the SGI raster file format. + +.NH +Plot File Formats +.PP +The SGI kernel can generate either metacode output, wherein the plot file +contains a series of simple vector drawing commands, or raster output, wherein +the plot file is a two dimensional raster (bitmap) with all the vector drawing +commands already processed and the corresponding bits set in the bitmap. +The two plot file formats are described in detail in the next two sections. +.NH 2 +SGI Metacode Format +.PP +The SGI metacode file format is a sequence of 16 bit integer words containing +binary opcodes and data. The metacode is extremely simple, consisting of only +two drawing instructions (pen up move and pen down draw), a frame instruction, +and an optional set line width instruction. All text is rendered into vectors +by the SGI kernel hence there are no text drawing instructions (some other GIO +kernel should be used if fancy hardware character generation, etc., is desired). +The SGK metacode instruction formats are summarized in Figure 5. + +.DS +.TS +center; +ci ci ci +c c l. +opcode data words instruction + +1 0, 0 frame instruction +2 x, y move to (x,y) +3 x, y draw to (x,y) +4 w, 0 set line width (>= 1, 1=normal, 2=bold) +.TE +.sp +.ce +Figure 5. SGI Metacode instruction formats +.DE + +.PP +All opcodes and data words are 16 bit positive integers encoded in the machine +independent MII format, i.e., most significant byte first. Only 15 bits of +each 16 bit word are actually used. Coordinates are specified in the range 0 +to 32767. All instructions are zero padded to 3 words to simplify metacode +translation programs. Note that whether the frame instruction precedes or +follows each graphics frame is a device option controlled by the FS and FE +kernel parameters. Note also that the \fIsgidecode\fR task in the \fIplot\fR +package may be used to examine the contents of SGI metacode files. + +.NH 2 +SGI Raster File Format +.PP +The raster file format written by the SGK consists of a binary raster file +containing one or more bitmaps (rasters) with no embedded header information. +All bitmaps in a raster file are of the same size. +The size is specified in the graphcap entry for the device and may be +passed to the host dispose task on the foreign task command line if desired. +Page offsets may also be passed on the command line, e.g., to position the +plot on the plotter page. The SGI kernel control parameters defined for +bitmap devices are summarized in Figure 6. + +.DS +.TS +center; +l l. +BI boolean; presence indicates a bitmapped or raster device +LO width in device pixels of a line of size 1.0 +LS difference in device pixels between line sizes +PX physical x size (linelen) of bitmap as stored in memory, bits +PY physical y size of bitmap, i.e., number of lines in bitmap +XO,YO origin of plotting window in device pixels +XW,YW width of plotting window in device pixels +NB number of bits to be set in each 8 bit output byte +BF bit-flip each byte in bitmap (incredible but true) +BS byte swap the bitmap when output (swap every two bytes) +WS word swap the bitmap when output (swap every four bytes) +.TE +.sp +.ce +Figure 6. SGI graphcap control parameters for bitmap devices +.DE + +.PP +The output raster will consist of PY lines each of length PX bits. +If PX is chosen to be a multiple of 8, the \fIphysical\fR length of each +line of the output raster will be PX/8 bytes. +Note that the values of PX and PY are arbitrary and should be chosen +to simplify the code of the translator and maximize efficiency. In particular, +PX and PY do not in general define the maximum physical resolution of the +device, although if NB=8 the value of PX will typically approximate the +physical resolution in X. If the byte packing factor is less than 8 then +PX must be increased to allow space for the unused bits in each output byte. +If there are multiple bitmap frames per file, each frame will occupy an +integral number of SPP char units of storage in the output file, with the +values of any extra bits at the end of the bitmap being undefined +(an SPP char is 16 bits on most IRAF host machines). +.PP +The plot will be rasterized in a logical window XW one-bit pixels wide and YW +pixels high. The first YO lines of the output raster will be zero, with the +plotting window beginning at line YO+1. The first XO bits of each output line +will be zeroed, with the plotting window beginning at bit XO+1. The bytes in +each output line may be bit-flipped if desired, and all of the bits in each +output byte need not be used for pixel data. If the bit packing factor NB is +set to 8 the plotting window will map into XW bits of storage of each output +line. If fewer than 8 bits are used in each output byte more than XW physical +bits of storage will be used, e.g., if NB=4, XW*2 bits of storage are required +to store a line of the plotting window. The unused bits are set to zero. +.PP +While the SGI kernel may not always produce a plotter ready output raster, +it will likely come pretty close. The translator can later \fIor\fR a mask +into the zeroed bits, flip the data bits, complement the data bits, or perform +any other bytewise operation using a simple and highly efficient table lookup +vector operator (i.e., use the \fIvalue\fR of the raster byte as the \fIindex\fR +into a 256 element lookup table, passing the value of the indexed element to +the plotter; prepare the lookup table once when the program first fires up). +.PP +Contrary to normal IRAF practice, storage for the raster buffer is statically +allocated in the SGI kernel. This was done for efficiency reasons, since +rasterization is an unusually expensive operation (the Fortran compiler can +generate tighter code for a static buffer). The only disadvantage is +that since the dimensions of the raster buffer are fixed at compile time, +\fIthere is a builtin upper limit on the size of a raster\fR. The SGI kernel +comes configured ready to rasterize the output for any device with a resolution +of up to 2112 by 2048 pixels. If this is too small, change the values of +the \fIdefine\fR-ed parameters \fLLEN_FBUF\fR and \fLLEN_OBUF\fR in the file +\fLgio$sgikern/sgk.x\fR, and do a \fLmkpkg; mkpkg install\fR on the package +to recompile and install a new SGI kernel (obviously, you must have the source +on line). Note also that efficient rasterization requires sufficient working +set to avoid excessive page faulting (thrashing) on the raster buffer when +drawing vertical vectors. Typical \fIglabax\fR vector plots require about 5 +seconds to rasterize on our UNIX 11/750. + +.NH +Implementing a New SGI Device Interface +.PP +As noted earlier, to implement a new SGI device interface you must [1] add an +SGI graphcap entry for the device to \fLdev$graphcap\fR, and [2] write a +translator program to dispose of the SGI plot file to the device. +.PP +If the device in question requires a metacode type plot file, there should +be no problem \fBsetting up the graphcap entry\fR, except for the DD string, +which we can deal with later when the dispose task is better defined. +If the device requires raster input, some investigation will +be required to determine how best to format the output raster, e.g., how +many bits per byte (NB), how many bits per physical output line (PX), and +how many output lines (PY). The values of the various flip, swap, rotate, +etc., parameters are most easily set by trial and error once the dispose +task is installed and running. The \fIshowcap\fR task is useful for debugging +graphcap entries. The new graphcap entry can either be added directly to the +installed graphcap file (\fLdev$graphcap\fR), or it can be developed in a test +graphcap file and installed later, changing the value of the \fIgraphcap\fR +environment variable to point to the private version of the file. +.PP +Once a graphcap entry for the new device is available, it may be used in +conjunction with the SGI kernel to \fBgenerate an SGI plot file\fR to be used +to test the translation (dispose) task. +To do this, get into the CL and make a GKI metacode file, e.g., using the +command `\fL:.write mc\fR' while in cursor mode with any old plot displayed +on the graphics terminal. Next, run the SGI kernel (task \fIsgikern\fR in +the \fIplot\fR package) to turn the GKI metacode file into an SGI metacode +or raster file. Note that the plot file is normally deleted automatically, +so to generate the test plot file you must set the graphcap entry up with +a null dispose command of some sort, also making sure that the \fIRM\fR +switch is omitted from the graphcap entry. +.PP +Given the test plot file, we are ready to \fBcode and test the translation +program\fR, normally implemented as a host Fortran or C program (note that it +may not be necessary to write such a program at all - the host system may +already provide something which can be used directly, such as the UNIX \fIlpr\fR +task in the sample graphcap entry for the versatec, shown in Figure 4). +The IRAF system comes with a number of such programs ready made for the more +common plotter devices; you will find these in the directory +\fLhost$gdev/sgidev\fR. Each device interface is contained in a single file. +Pick the one for the device most closely resembling the device you are +interfacing, make a copy of it with a new name, and modify the code as +necessary for the new device. Test the program on the test plot file, +go back and change the graphcap if necessary and generate a new test plot +file, and iterate until the process converges. +.PP +The final products of this exercise are the graphcap entry and the dispose task. +It is probably simplest if the graphcap entry is installed directly in +\fLdev$graphcap\fR. The dispose task may either be installed directly in +the system, like the SGI device interfaces that come with IRAF, or it may be +installed in the \fLLOCAL\fR directory or some place outside of IRAF, changing +the graphcap entry to point to the task wherever it has been installed. +If you choose to install the dispose task and its source directly in the +system, remember to save it and merge it back in when future versions of +IRAF are installed. +.LP +The procedure for adding a new dispose task to the standard system is as +follows: + +.RS +.IP [1] +Install the source file in \fLhost$gdev/sgidev\fR. +.IP [2] +Make an entry for the device in all \fImkpkg\fR files in the same directory, +e.g., \fLmkpkg\fR, \fLmkpkg.com\fR, \fLmkpkg.csh\fR, and so on, depending +upon the host system. +.IP [3] +Type \fLmkpkg update\fR to compile, link, and install the new executable +in the \fLHLIB\fR directory (where host dependent runtime files go). +.IP [4] +On a VMS host, add an entry for the device to \fLhlib$sgiqueue.com\fR, +and set up the graphcap entry to submit this file to run in a batch queue, +like the other VMS/SGI devices. On a UNIX host, \fIlpr\fR provides queueing +as a builtin feature, and can easily be used to set up new queues. +Alternatively, appending an `\fL&\fR' to the DD dispose command will at +least allow the translation to be carried out in the background, and prefixing +the command with \fInice\fR will cause it to be run at a reduced priority. +.RE + +.LP +Note that while IRAF does not (currently) provide a builtin network capability +for SGI devices, the UNIX \fIlpr\fR provides full network access on UNIX hosts, +and on a VMS host something can usually be cobbled together using DCL command +files and DECNET. The principal advantage of using the IRAF network +capabilities with SGI will be the ability to easily access devices on a remote +node running a different operating system than that on the local node. + +.NH +Site Dependencies in the SGI Graphcap Entry +.PP +As the number of plotter devices supported by SGI translators in the standard +IRAF system grows, many sites will find that support for their local plotter +device is already provided by the standard IRAF system. In most cases the only +changes required to interface to the local device will be modifications to the +graphcap entry for the device, and possibly modifications to any associated +script files in \fLHLIB\fR. The parameters the user is most likely to need +to change in the graphcap entry are the logical device name and the dispose +command (DD parameter), e.g., to change the name of the plotter queue, if +passed as a command line argument in the dispose command. If multiple copies +of the same device exist on the local network, a separate graphcap entry must +be provided for each. + +.NH +Some Examples +.PP +We have already seen one example, i.e., an SGI interface for a versatec +raster plotter on a UNIX node (Figure 4). This example is unusual because +no special SGI translation task is required; the raster file format required +by the UNIX \fIlpr\fR is sufficiently device and system independent that +the SGI kernel can produce it directly. As a bonus, \fIlpr\fR provides +full network access and queued execution, without any extra work on our part. +.PP +Life is never quite so simple on VMS, but the VMS SGI interface for the +versatec plotter is not very difficult either. To dispose of a raster to +the versatec on a VMS host, one must reformat the raster file produced by +the SGI kernel to produce an RMS fixed format record structured file, +blocked 132 bytes per record (130 data bytes plus a 2 byte record type code, +used to signal formfeeds and such). +.PP +The primary function of the VMS/SGI dispose task for the versatec, therefore, +is to copy the SGI raster plot file, reformatting it into the peculiar record +structure required by the VMS print queue. Once the record structured file +has been generated, the file is disposed of to the print queue and the SGI +plot file is deleted. When plotting is complete, the VMS print queue deletes +the queued file. The graphcap entry for all this is shown in Figure 7. +Note the use of the VMS batch queue facility in the DD string; this makes +\fIgflush\fR appear considerably faster that it would otherwise be. +The \fIFAST\fR queue is used since the reformatting operation is expected +to take only a few tens of cpu seconds. + +.DS +\fLsgiver|Basic SGI/SGK interface to the versatec:\\\\ + :kf=bin$x_sgikern.e:tn=sgikern:xs#.200:ys#.200:\\\\ + :xr#1536:yr#1536:zr#1:cw#.0125:ch#.0294:\\\\ + :BI:YF:BF:LO#1:LS#2:PX#2112:PY#1576:XO#300:YO#40:XW#1536:YW#1536: +vver|SGI/SGK interface to the versatec on the local VMS node:\\\\ + :DD=vver,tmp$sgk,sub/que=fast/noprint/nolog \\\\ + /para=\\\\050"vver","$F","2112","1576","versatec","$F.ras"\\\\051 \\\\ + irafhlib\\\\072sgiqueue.com:\\\\ + :MF#8:tc=sgiver:\fR +.sp +.ce +Figure 7. VMS/SGI graphcap entry for the versatec raster plotter +.DE + +.PP +We have concentrated on raster plotters in our examples because the raster +plotter interface is more complex than the metacode file interface, and because +at the time this was written, there was not yet a working example of a laser +printer SGI interface (SGI interfaces for the \fIimagen\fR and \fIQMS\fR were +under development). The SGI interface for a metacode device is very similar, +the principal difference being the omission of the \fL:BI...\fR etc. line +in the graphcap entry. The dispose task for a laser printer simple reads +successive 3 word SGI instructions from the SGI metacode file until EOF is +reached, translating each instruction into the plotting instructions required +by the laser plotter, with rasterization being performed by the plotter itself. diff --git a/doc/spp_title.ms b/doc/spp_title.ms new file mode 100644 index 00000000..5076b8a2 --- /dev/null +++ b/doc/spp_title.ms @@ -0,0 +1,20 @@ +.RP +.TL +A Reference Manual +for the +IRAF Subset Preprocessor Language +.AU +Douglas Tody +.AI +.K2 "" "" "*" +January 1983 +(revised September 1983) +.AB +The IRAF subset preprocessor language (SPP) implements a subset of the +proposed full IRAF scientific programming language. This paper defines +the language and gives several examples of procedures written in the language. +The differences between the subset language and the full language are +summarized. IRAF tasks or programs are discussed, and a working example +of an IRAF program is shown. The XC compiler for the SPP language on the +UNIX software development system is introduced. +.AE diff --git a/doc/spp_toc.hlp b/doc/spp_toc.hlp new file mode 100644 index 00000000..0494f96e --- /dev/null +++ b/doc/spp_toc.hlp @@ -0,0 +1,119 @@ +.help spp Jan83 "IRAF Subset Preprocessor Language" +.ce +Contents + +.rj 1 +1. Introduction + +.rj 1 +2. Getting Started + +.rj 2 +3. Fundamentals of the Language +.in 5 +.rj 2 +3.1 Lexical Form +.in 5 +.rj 2 +3.1.1 comments +.rj 2 +3.1.2 continuation +.rj 2 +3.1.3 integer constants +.rj 3 +3.1.4 floating point constants +.rj 3 +3.1.5 character constants +.rj 4 +3.1.6 string constants +.rj 4 +3.1.7 identifiers +.in -5 +.rj 4 +3.2 Data Types +.rj 5 +3.3 Declarations +.in 5 +.rj 5 +3.3.1 variable, array, and procedure declarations +.rj 6 +3.3.2 array declarations +.rj 6 +3.3.3 string declarations +.rj 7 +3.3.4 global common declarations +.rj 7 +3.3.5 procedure declarations +.in 5 +.rj 8 +example 1: the sinc function +.in -5 +.rj 8 +3.3.6 multiple entry points +.in 5 +.rj 9 +example 2: multiple entry points +.in -5 +.in -5 +.rj 9 +3.4 Initialization +.rj 9 +3.5 Control Flow Constructs +.in 5 +.rj 10 +3.5.1 conditional execution +.rj 11 +3.5.2 error handling +.rj 13 +3.5.3 repetitive execution +.in -5 +.rj 15 +3.6 Expressions +.in 5 +.rj 16 +3.6.1 mixed mode expressions +.rj 16 +3.6.2 type coercion +.in -5 +.rj 16 +3.7 The Assignment Statement +.rj 16 +3.8 Some Examples +.in 5 +.rj 17 +example 3: length of a string +.rj 17 +example 4: min and max of a real array +.in -5 +.rj 18 +3.9 Program Structure +.in 5 +.rj 19 +3.9.1 include files +.rj 19 +3.9.2 macro definitions +.rj 20 +3.9.3 the task statement, and tasks +.rj 22 +3.9.4 help text + +.in -5 +.in -5 +.rj 22 +4. Anachronisms + +.rj 23 +5. Notes on Topics not Discussed + +.rj 24 +APPENDIX A: Predefined Constants +.rj 25 +APPENDIX B: Detailed Examples +.in 5 +.rj 25 +Example 5: Matrix Inversion +.rj 28 +Example 6: Pattern Matching +.rj 31 +Example 7: Error Handling +.endhelp diff --git a/doc/std.ms b/doc/std.ms new file mode 100644 index 00000000..e26a1ded --- /dev/null +++ b/doc/std.ms @@ -0,0 +1,2200 @@ +.RP +.TL +IRAF Standards and Conventions +.AU +Elwood Downey +George Jacoby +Vesa Junkkarinen +Steve Ridgway +Paul Schmidtke +Charles Slaughter +Douglas Tody +Francisco Valdes +.AI +.K2 "" "" "*" +August 1983 +.AB +Clearly defined and consistently applied standards and conventions are +essential in reducing the "number of degrees of freedom" which a user +or programmer must deal with when using a large system. +The IRAF system and applications software is being built in accord with +the standards and conventions described in this document. These include +system wide standards for data structures and files, standard coding +practices, coding standards, and standards for documentation. +Wherever possible, the IRAF project has adopted or adapted existing +standards and conventions that are in widespread use in other systems. +.AE +.NH +Introduction +.PP +Clearly defined and consistently applied standards and conventions are +essential in reducing the "number of degrees of freedom" which a user +or programmer must deal with when using a large system. The user benefits +from consistently applied naming conventions for packages and tasks, +and from a logical and consistently applied scheme for ordering the +parameters to a task. The programmer who must read code written by +other programmers benefits from the application of good programming +practices and a uniform style. +.PP +The IRAF system and applications software is being built in accord with +the standards and conventions described in this document. These include +system wide standards for data structures and files, coding standards, +standards for numerical libraries, and standards for documentation. +.PP +Whenever possible, the IRAF project has adopted or adapted existing +standards and conventions that are in widespread use in other systems. +Examples are the standard filename extensions, which are adopted from +UNIX (the IRAF software development system), and the coding standard +for the SPP language, which is consistent with the coding standard +for the C language, on which the design of the SPP language was based. + +.NH 2 +Official Acceptance Procedure +.PP +Software developed by programmers outside of the IRAF group +must conform to the standards presented in this document to be accepted +as a supported product, or to be included in the IRAF distribution. +.PP +Software developed by programmers within the IRAF group will be +inspected periodically by another member of the IRAF group to check +for adherence to the standards, for constructs that could cause +transportability problems, and to ensure that the code is upwards +compatible with future versions of the SPP language compiler and program +libraries. IRAF group members will gladly provide this service to +anyone outside the group who would like to have their code checked. + + +.NH +System Standards +.PP +This section defines those standards and conventions which pervade the +system. An example of such a fundamental convention is one-indexing. +Others include the standard for generating and using virtual file names, +and the procedure naming convention for the system libraries. + +.NH 2 +Standard Data Structures +.PP +This section describes the fundamental data structures used by the +IRAF system and applications tasks. An IRAF applications package +should not access data structures other than those described here. +Applications may build their own high level structures upon text or +binary files if necessary, but the standard high level structures +(particularly the imagefile and the datafile) should be used when +applicable. +.NH 3 +Text and Binary Files +.PP +The most primitive data structure in the IRAF system is the file. +At the most basic level there are two types of files, \fItext files\fR +and \fIbinary files\fR. +.PP +\fBText files\fR may contain only character data. The fundamental unit of +storage is the line of text. Character data in text files is maintained +in a form which is OS (operating system) dependent, and text files may +be edited, printed, and so on with the utilities provided by the host OS. +Character data is stored in text files in the character set of the host +OS, which is not necessarily ASCII. Text files are normally accessed +sequentially, and writing is permitted only at EOF (end of file). +.PP +Examples of text files include program source files, CL parameter +files, list files, ASCII card image files, CL script files, and the +session logfile. Text files are often used for descriptor files which +are read at run time by table driven software. +.PP +\fBBinary files\fR are read and written only by IRAF tasks. The fundamental +unit of storage is the \fIchar\fR. Data is stored in binary files in +the form in which it appears internally in IRAF tasks, without any form +of type conversion. Binary files are generally not transportable between +different machines. Binary files may (normally) be read and written at +random. +.PP +Any device which supports reads and writes in some form may be made to +appear to be a binary file, subject to possible restrictions on seeks +and writing at EOF. FIO (the IRAF file i/o package) supports devices +of arbitrary blocksize, and i/o to binary files is very efficient +and may be optimized according to the type of access expected. +.PP +Examples of binary files include imagefiles, datafiles, a graphics stream, +a FITS file, and memory. +.PP +Although a binary file may be used to store any kind of data, including +text, files which contain only text should be maintained as text files. +.NH 3 +Parameter Files +.PP +The \fBparameter file\fR, a text file, is used to store the parameters +and associated information (type, mode, prompt, default value, etc.) +for a task. Parameter files are read and written by the CL, and are +normally invisible both to the user and to the applications task. +.PP +The \fIdefault\fR parameter file for a task must reside in the same directory +as the executable file or script file associated with the task. The +root name of the parameter file is the name of the task. Parameter files +have the extension ".par". +.PP +The logical directory \fBuparm\fR should be defined by the user to provide +a place to store \fIupdated\fR versions of parameter files. When updating +a parameter file, the CL will prepend the first two characters of the +package name to the parameter file name (to avoid redefinitions), and save +the resultant file in \fBuparm\fR. This package prefix should be omitted +from the names of default parameter files in the package directory. + +.RS +.TS +il l. +task.par default parameter file +pk\(ultask.par updated parameter file (package \fIpk...\fR) +.TE +.RE + +.NH 3 +Imagefiles +.PP +The \fBimagefile\fR is used to store bulk data arrays of arbitrary +dimension, size, and datatype. Images of up to seven dimensions are +currently supported. The length of a dimension is limited by the +size of a long integer on the host machine. A full range of datatypes, +from unsigned char through complex, are supported. +.PP +The fundamental unit of storage for an imagefile is the \fIpixel\fR. +All the pixels in an image must be of the same datatype. The dimensions, +size, and datatype of an image are fixed when the image is created. +.NH 4 +standard nomenclature for images +.PP +The axes of a two dimensional image divide the image into \fIlines\fR +and \fIcolumns\fR. A three dimensional image consists of one or more +\fIbands\fR, each of which is a two dimensional image, all of which +are the same size and datatype. +.PP +The names of procedures, variables, and so on in software which accesses +images should be derived from the standard names \fBline\fR, \fBcolumn\fR, +\fBband\fR, and \fBpixel\fR. The use of the term \fIrow\fR in place of +\fIline\fR is discouraged, despite the historical use of \fIrow\fR at KNPO. +The \fIline\fR, \fIcolumn\fR, \fIband\fR nomenclature is a defacto +international standard, not only in the image processing literature, +but at most astronomical data reduction centers as well. +.PP +Examples of standard identifiers include \fInlines\fR, \fIncols\fR, +\fInpix\fR, and \fIndim\fR, referring respectively to the number of lines, +columns, pixels, or dimensions to be operated upon. +.NH 4 +definition of a pixel +.PP +Given an image of dimension N, a \fIpixel\fR is defined as the datum +whose coordinates within the image are given by the subscript [x1,x2,...,xN], +where the first index in each dimension has the value one, and where +\fBi\fR is the \fIcolumn\fR index, \fBj\fR the \fIline\fR index, \fBk\fR +the band index, and so on. The dimensionality of the image is given by +the number of subscripts. The value of a pixel is \fInot\fR a dimension. +.PP +If an array of pixels is to be interpolated, the question of the extent +or size of a pixel arises. In the IRAF system a pixel is defined as +a mathematical point, and has no extent. This is in contrast to some +other systems, which have adopted the "physical" definition of a pixel, +i.e., pixel \fIi\fR is assumed to extend from [i\(mi0.5] to [i+0.5]. +.PP +Thus, given an array of N pixels, an IRAF interpolant will return an +indefinite value at the points [1\(mieps] and [N+eps], where \fIeps\fR +is a very small number. An array of N pixels contains N\(mi1 subintervals. +If an array of N pixels is expanded by interpolating every 0.5 pixels, +an array of 2N\(mi1 pixels will result. Mapping an array of N pixels into +an array of 2N pixels requires a stepsize of (N\(mi1)/(2N\(mi1) pixel units. +.NH 3 +Datafiles +.PP +The \fBdatafile\fR provides a \fIdatabase management\fR capability for +the IRAF system. The datafile is used to store \fBrecords\fR. A record +consists of an ordered set of \fBfields\fR, each of which has a name, +a datatype, and a value. The structure of a datafile is defined by the +applications program, and a description of that structure is saved in +the datafile itself. It is this self describing nature of datafiles +which makes database management possible. +.PP +The datafile has many advantages over the old technique of writing an +array of binary records in a headerless file, via FIO \fBwrite\fR calls. +Datafiles are self documenting, can be manipulated by the standard +database management tools, and the structure of the records in a datafile +can be modified as a program evolves, without losing the capability to +access old datafiles. +.NH 3 +List Files +.PP +The \fBlist file\fR is a text file, each line of which comprises one +element of the list. Lists are used to drive tasks in batch or semibatch +mode. A typical list defines a set of files, images, records, coordinates of +objects, etc. to be processed by a task. +.PP +Lists should be maintained as text files to take advantage of the ability +of the CL to process text files. Lists maintained in text form can +be created by i/o redirection, and are easily edited, sorted, filtered, +inspected, and so on. Lists can be input to tasks using list structured +parameters, redirection of the standard input, and templates. +.NH 3 +FITS +.PP +The FITS standard of the AAS and IAU [1] is the standard format for +image data entering and leaving the IRAF system. The FITS format will be +used both for image data transmitted by magnetic tape between machines, and for +image data transmitted between machines by other means (i.e., via a network). +.PP +Proposed extensions to the FITS standard may provide a means for transmitting +tabular data (such as a list), as well as an efficient means for transporting +text files. These extensions will be implemented in the IRAF system when a +draft standard is received from the FITS standards committee of the AAS. + +.NH 2 +Virtual File Names +.PP +A file name may be specified in a machine independent fashion, or as +an OS dependent pathname. A machine independent filename is called a +\fBvirtual file name\fR (VFN). The ability of the system to deal with +OS dependent filenames is intended primarily as a convenience feature +for the user. Applications programs and CL script tasks should be +written in terms of virtual file names for maximum transportability. +.PP +A virtual file name has the following form: + +.nf +.RS +\fIldir$root.extn\fR +.RE + +where +.RS +.TS +ci ci +lw(1.0i) l. +field usage + +ldir logical directory or device name +root root or base file name +extn extension denoting the type of file +.TE +.RE +.fi + +.PP +The \fIldir\fR and \fIextn\fR fields are optional. The logical directory +field, if present, must be delimited by the character $. The backslash +character can be used to escape characters such as $, if required in +OS dependent filenames. +.PP +The root and extension fields may contain up to 20 characters selected +from the set [a-zA-Z0-9\(ul+\(mi#.]. +A file name may not contain any whitespace. +The extension field should not exceed three characters. +The extension field is separated from the root field by the character "." (dot). +If the root field contains one or more occurrences of the dot character, +the final dot delimited field is understood to be the extension, and the +remaining fields are considered to be part of the root. +.PP +Purely numeric filenames are legal virtual file names. If the first +character of a file name is a digit, the character "I" will be prepended +to generate the OS pathname. Thus, the filenames "I23" and "23" refer to +the same file. Numeric filenames are reserved for use by the user as a +convenient way to name imagefiles, and should not be used in programs +or script tasks. + +.NH 2 +Standard Filename Extensions +.PP +A number of standard filename extensions are defined to identify those +types of files which are most commonly used in IRAF programs and by +users of the IRAF system. +These extensions reflect the selection of UNIX +as the IRAF software development system, but transportability is not +compromised since the extension field is part of a VFN (and is therefore +mapped in a machine dependent way). + +.RS +.TS +center box; +cb s +c | c +l | l. +Standard Filename Extensions += +Extension Usage +_ +\\.a archive or library file +\\.c C language source +\\.cl Command Language script file +\\.com global common declaration +\\.df IRAF datafile +\\.f Fortran 77 source +\\.h SPP header file (contains global \fIdefines\fR) +\\.hlp \fILroff\fR format help text +\\.ms \fITroff\fR format text +\\.o object module +\\.par CL parameter file +\\.pix pixel storage file (part of an imagefile) +\\.s assembler language source +\\.x SPP language source +.TE +.RE + +.PP +Note that no extension is assigned for executable files (executable files +are not directly accessed by IRAF programs or utilities). +Certain of these extensions may have to be mapped into a different form +in the process of converting a VFN to an OSFN (i.e., on most operating +systems, ".a", ".f", ".o", and ".s" will be mapped into some other +extension at file access time by the system interface routine \fIzmapfn\fR). + +.NH 2 +One Indexing +.PP +The IRAF system is one-indexed. This convention is applied without +exception in the system software, and should be applied equally rigorously +in applications code. Past systems (i.e., the KPNO IPPS system and +the original KPNO Forth Camera system) have shown that mixing zero and +one indexing in the same system is confusing, and is the source of many +errors. +.PP +Note that the one-indexing convention applies to both numbering systems +and offsets. Thus, the coordinates of the first pixel in a two dimensional +image are [1,1], and the offset of the first character in a file is also +one. Scaling an offset involves subtracting the constant one, a multiply +or divide to perform the actual scaling, followed by the addition of the +constant one. +.PP +The awkwardness of one-indexing for calculating offsets (in comparison +with zero-indexing) is balanced by the logical simplicity of one-indexed +numbering schemes. The one-indexing convention was selected for IRAF +because numbering schemes are more visible to the user than is offset +arithmetic, and because IRAF is a Fortran based system. + +.NH 2 +The Procedure Naming Convention for the System Libraries +.PP +With the exception of certain "language" level identifiers (\fBopen\fR, +\fBclose\fR, \fBread\fR, \fBwrite\fR, \fBmap\fR, \fBerror\fR, etc.), +all procedures in the packages comprising the IRAF program and system +interfaces are named according to a simple convention. +.PP +The purpose of the procedure naming convention is to make procedure name +selection logical and predictable, and to minimize collisions with the +names of the procedures (and other external identifiers) used in applications +programs. This latter problem is a serious matter in a large system which +is Fortran based, due to the global nature of all procedure and global common +names, and the restriction to six character identifiers. +.PP +The procedure naming convention should \fInot\fR be used to generate +names for procedures in applications code. The procedure naming +convention purposely results in rather obscure identifiers. This is +necessary for system library routines, to minimize the possibility of +collisions, but at the highest level (in applications code and in CL +packages), readability is the most important consideration. +.PP +The names of system library procedures are generated by concatenating +the following fields: + +.nf + \fIpackage\(ulprefix\fR \(sl\(sl \fIopcode\fR \(sl\(sl \fItype\(ulsuffix\fR +.fi + +.PP +The package prefix identifies the package to which the procedure belongs, +and is one to three characters in length. The opcode is a concise +representation of the function performed by the procedure. The type suffix +identifies the datatype of the function value or primary operand. +.PP +An example of the use of the procedure naming convention is the generic +function \fBclgpar\fR, in the CLIO package. In this case, the package prefix +is "cl", the opcode is "g" (get), and the (abstract) type suffix is "par". +The generic function \fBclgpar\fR is implemented with the following set of +typed procedures: + +.nf + \fBclgpar\fR \(-> clgetb, clgetc, clgets, clgeti, clgetl, clgetr, clgetd, clgetx + +or, more concisely, + + \fBclgpar\fR \(-> clget[bcsilrdx] +.fi +.NH 3 +Orthogonality +.PP +The procedure naming convention is an example of a three dimensional +"orthogonal" naming convention. The VAX instruction set and associated +mnemonics are another example. As we have seen, often two dimensions are +sufficient (no type suffix) to encode the names of the procedures in a +package. Occasionally it is necessary to have more than three dimensions, +as in the following example from the image i/o package: + +.nf + \fBgetpix\fR, \fBputpix\fR \(-> im[gp][pls][123][silrdx] + +where the fields have the following significance: + + im[get/put][pixel/line/section][dimension][datatype] +.fi + +.PP +The five dimensional expression on the right side represents a total of 108 +possible procedure names (\fIimgp1s\fR, etc.). +A \fBgetpix\fR or \fBputpix\fR statement is easily converted into a call +to the appropriate low level Fortran subprogram by analyzing the subscript +and applying the above generating function. +.NH 3 +Standard package prefixes +.PP +A table of the package prefixes for the packages comprising the IRAF +system libraries is shown below. + +.TS +center box; +cb s s +ci | ci +l | l l. +Standard Package Prefixes += +package prefix +_ +CLIO cl command language i/o +FIO f file i/o +MEMIO m (or mem) memory i/o +VSIO v virtual structure i/o +IMIO im image i/o +MTIO mt magtape i/o +GIO g graphics i/o +VOPS (1-dim) a vector operators +VOPS (2-dim) m matrix operators + +byte primitives byt +char utilities chr +error handling err (or xer) +pattern matching pat +string utilities str +process control t +exception handling x +OS interface z +.TE + +.NH 3 +Standard type suffixes +.PP +The type suffix is optional, and is used when the operator is implemented +for several different types of data. The type suffix is a single character +for the primary data types, but may be up to three characters for the +abstract data types ("file", "string", etc.). The standard type suffixes +are as follows: + +.TS +center box; +cb s s +c | c s +l | l l. +Standard Type Suffixes += +datatype suffix +_ +\fBbool\fR b (primary types) +\fBchar\fR c +\fBshort\fR s +\fBint\fR i +\fBlong\fR l +\fBreal\fR r +\fBdouble\fR d +\fBcomplex\fR x +_ +file fil (abstract types) +string str +cursor cur +CL parameter par +character constant cc +.TE + +.NH 2 +Mapping of External Identifiers +.PP +The SPP language maps identifiers longer than the six characters permitted +by the Fortran standard into identifiers of six or fewer characters. +Both local and external identifiers are mapped. The mapping convention +applies to all procedures in the system libraries. +.PP +A simple, fixed mapping is used to facilitate the use of symbolic debuggers +without having to resort to a compiler listing. A simple mapping convention +also makes it easier for the programmer to foresee possible redefinitions. +.PP +The mapping function used is known as the "5+1" rule. The six character +Fortran identifier is formed by concatenating the first five characters +and the last character of the long identifier from the SPP source code. +Underscore characters are ignored. +.PP +Identifiers in SPP source code should be chosen to maximize readability, +without concern for the length of an identifier. The compiler will +flag spelling errors and identifiers which map to the same six character +Fortran identifier (if both identifiers are referenced in the same file). + +.KS +Examples: +.TS +center; +ci ci s +l c l. +XPP identifier Fortran identifier + +strmatch STRMAH (library procedure) +read\(ultemplate READTE (procedure) +get\(ulkeyword GETKED (procedure) +ival\(ulalready\(ulused IVALAD (boolean variable) +days\(ulper\(ulyear DAYSPR (integer variable) +.TE +.KE + +.NH 2 +Conventions for Ordering Argument Lists +.PP +The convention for ordering argument lists applies to both CL tasks +and compiled procedures. This convention should serve only as a +guideline: in practice, other considerations (such as symmetry) may +produce a more natural ordering. +.PP +Argument lists may contain operands and their dimensions, objects +used for working storage, control parameters, and status return +values (organized in that order). +The types of operands may be further broken down into those which +are input and those which are output, ordered with the input parameters +at the left and the output parameters at the right. +.PP +More precisely, the ordering of operands and parameters in the argument +lists of procedures and tasks is as follows: + +.RS +.IP (1) +The principal operand or operands (data objects) dealt with by the +procedure, ordered with input at the left and output at the right. +Examples of primary operands include file names, file descriptors, +image header pointers, vectors, and so on. +.IP (2) +Dimension parameters, offsets, position vectors, or other objects which +can be considered part of the specification of an operand. If the operands +in (1) are individually dimensioned, the dimension argument(s) should +immediately follow the associated operand. If several operands share +the same dimension arguments, these arguments should follow the last +operand in the group. +.IP (3) +Objects used for working storage, and their dimensions. +.IP (4) +Any control parameters, flags, options, etc., used to direct the operation +of the procedure. Unless there is another ordering which is clearly more +logical, these should be arranged in alphabetical order. +.IP (5) +Status return parameter or parameters, if any. +.RE + +.PP +Argument lists should be kept as short as possible if they are to be +easily remembered by the programmer (ideally, no more than three arguments). +Short argument lists decrease the coupling between modules, increasing +modularity and making programs easier to modify. Any procedure which +requires more than five arguments should be carefully examined to see +if it should be broken into several smaller procedures. + + +.NH +Coding Standards +.PP +Programs are read far more often than they are written. The readability +of a program is a function of the \fBstyle\fR in which it is written. +The effectiveness of a particular style in enhancing the readability of +a program is increased when that style is applied consistently throughout +the entire program. The readability of the code within a \fIsystem\fR +is maximized when a single, well designed style is applied consistently +throughout the system. Since large systems are written by many people +(though often read by a single person), it is necessary to document the +standard programming style for the system, as clearly as can be done. +.PP +The standard programming style for a system is a major part of the +\fBcoding standard\fR for that system (though not the whole story). +The benefits and difficulties of coding standards are well summarized by +the following excerpt from a paper describing the evolution of the +\fIIngres\fR data base management system [2]: + +.QP +\fI"The initial reaction was exceedingly negative. Programmers used to +having an address space of their own felt an encroachment on their personal +freedom. In spite of this reaction, we enforced standards that in the +end became surprisingly popular. Basically, our programmers had to recognize +the importance of making code easier to transfer to new people, and that +coding standards were a low price to pay for this advantage..."\fR +.QP +\fI"Coding standards should be drawn up by a single person to ensure +unity of design; however, input should be solicited from all programmers. +Once legislated, the standards should be rigidly adhered to."\fR + +.PP +The standard language for IRAF system and applications code is the Subset +Preprocessor Language (SPP), which was patterned after the C language of +Kernighan and Ritchie [3]. Much of the text in the following pages was +taken almost verbatim from reference [4], which defines the coding standard +adopted at Bell Labs for the C language. Since such a well defined (and +widely used) standard already exists, we have adopted the C coding +standard as the core of the standard for the SPP language. + +.NH 2 +General Guidelines +.PP +In this section we discuss the philosophy governing the decomposition of +the IRAF system into packages and tasks. The same principles are seen to +apply to the decomposition of tasks or programs into separately compiled +procedures. +.PP +Our intent here is to summarize the structural characteristics expected +of a finished applications package. Once a package has been coded and +tested, however, it is too late to change its structure. The functional +decomposition of a package or program into a set of modules, the selection +of names for the modules, and the definition of the parameters of each +module, is the purpose of the detailed design process. A discussion of +the techniques and tools used to perform a detailed design is beyond the +scope of this document. +.NH 3 +Packages and Tasks +.PP +The IRAF system and applications code is organized into \fBpackages\fR, +each of which operates upon a particular kind of data. These packages are +independent, or are loosely coupled by the datafiles, imagefiles, or lists +on which they operate. +.PP +Close coupling between packages (for example, by means of specialized +data structures) should be avoided. Leave the coupling of modules from +different packages to the user, or write high level script tasks ("canned" +procedures) to streamline commonly performed operations, \fIafter\fR the +packages involved have been designed and coded. +.PP +A package consists of a set of \fBtasks\fR, each of which should perform +a \fIsingle function\fR, and all of which operate on the package data +structures. The name of each task should be carefully chosen to identify +the function performed by the task (a novice user should be able to guess +what function the task performs without having to read the documentation). +Command names should not be abbreviated to the point where they have +meaning only to the package designer. +.PP +The tasks in a package should be \fIdata coupled\fR, meaning that +their operation is defined entirely in terms of the package data +structures. Avoid \fIcontrol coupling\fR, which occurs when one task +controls the functioning of another by passing a control parameter or +switch. A task should not modify another tasks parameters, nor should +it modify its own input parameters. +.PP +A CL callable task may reference its own local parameters, plus two +levels of \fBglobal parameters\fR (the package parameters and the CL +parameters). Global parameters should be used with care to avoid tasks +which are highly coupled. For example, if a task were to use the the CL +"scratch" parameters \fBi\fR and \fBj\fR for loop control variables, +that task would be strongly coupled to any other task in the system, +now and in the future, which also references the global parameters +\fBi\fR and \fBj\fR (with disastrous results). The CL scratch parameters +are provided for the convenience of the user: they should not be used +by tasks. +.PP +Global parameters can actually reduce the coupling between tasks when +the alternative would be to add a parameter to the set of local parameters +for each task in the package. Such parameters are normally set only by +the user (or by a user script task), and are \fIread only\fR to all tasks +in the package. Examples of such parameters might be the names of the +package datafiles, or parameters which describe the general characteristics +of the data to be operated upon. If in doubt, use a local parameter +instead of a global parameter. +.PP +A task may be implemented as a \fBscript task\fR, written in the CL, or as +a compiled procedure or \fBprogram\fR, written in the SPP language. +Any number of related or unrelated programs may be linked together to form +a single executable \fBprocess\fR. The decision to implement a task +in the CL or in the SPP language is irrelevant to the package designer, +as is the grouping of programs to form physical processes. +.NH 3 +Procedures +.PP +The guidelines for implementing a program as a set of separately +compiled \fBprocedures\fR are similar to those for decomposing a package +into a set of tasks. \fIEach procedure should perform a single function, +should be well named, should be data coupled, and should have as few +parameters as possible\fR. +.PP +Procedures which perform a single function are less complex than multiple +function procedures, tend to be less strongly coupled to their callers, +and are more likely to be useful elsewhere in the program, and in future +programs. A program structured as a hierarchy of single function, +minimally coupled procedures is highly modular, and generally much easier +to modify, than a program consisting of multiple function (monolithic), +strongly coupled procedures. Reducing the coupling between procedures +makes it less likely that a change to one procedure will affect the +functioning of another procedure somewhere else in the system. +.PP +It has long been argued that a monolithic procedure is more efficient +than one which calls external procedures to perform subfunctions. +While there is some truth to this claim, efficiency is only one of the +measures of the quality of software. Other factors such as reliability, +robustness, flexibility, transportability, simplicity, and modifiability +are often more important. Furthermore, it is almost always true that +five or ten percent of the code accounts for ninety percent of the +execution time, and it will prove easier to optimize that five or ten +percent of the code if it is in the form of isolated, single function +procedures (a small, simple procedure is easily replaced by an equivalent +routine written in assembler, for example). +.PP +A section of code which is common to two or more modules, which is +\fBfunctional\fR (performs a single, well defined function), and which is +not strongly coupled to the rest of the code in the parent module, +should be extracted to form a separate module. Not only does this +reduce the amount of code which must be tested and debugged, it also +makes the program easier to modify, since only a single section of code +must be changed to modify the function in question. +.PP +Less obviously, a section of code should be extracted to form a new module +even if the new module is only called from one other module, if the new +module is functional, and is likely to be useful in future programs. +A new module should also be created if doing so removes a sizable +section of code from the parent module, significantly reducing the complexity +of the parent module (provided the new module is functional and not +strongly coupled). If the control flow of a procedure is so deeply nested +that statements will no longer fit on a line, that is an indication that +code should be extracted to form a new module. +.PP +The name of a procedure, like that of a task, should be carefully +selected to identify the function performed by the procedure. +\fIThe function of each subprocedure referenced by a procedure should +be evident to the reader, without having to go look up the source for +the individual subprocedures\fR. For similar reasons, the function of +each of the \fBarguments\fR of a subprocedure should be evident without +having to look up the source or documentation for the procedure. +The \fBdefine\fR feature of the SPP language is particularly useful +for parameterizing argument lists. +.PP +Reducing the number of arguments to a procedure reduces the coupling +of the procedure to its callers, making the procedure easier to modify +and use, reducing the possibility of a calling error, and usually +increasing the functionality (usefulness) of the procedure. Most +procedures should have no more than three arguments: procedures with +more than five arguments should be examined to see if they should be +decomposed into several smaller procedures. +.PP +Psychologists have shown that one 8\(12 by 11 inch sheet of paper +(i.e., one page of a computer listing) contains about the amount of +information that most people can comfortably handle at one time. +Procedures larger than one or two pages should be examined to see +if they should be broken down further. Conversely, procedures which +contain fewer than five lines of code should be examined to see if +they should be merged into their callers. If a procedure contains +more than ten declarations for local variables or arrays, that is +another indication that the procedure probably needs to be decomposed +into smaller functional units. +.PP +A program is more resistant to changes in the external environment +(and therefore more transportable) if that part of the program which +interfaces to the outside world is isolated from the part which processes +the data. This tends to happen automatically if the "single function" +guideline is followed, but nonetheless one should be consciously aware +of the need to \fIisolate those portions of a program which get parameters, +access external data structures, and format the output results\fR. +.PP +Numerical routines, transformations, and so on should almost always +be implemented as separate procedures. These are precisely those parts +of a program which are most likely to be useful in future programs, +and they are also among the most likely to be modified, or replaced +by functionally equivalent modules, as the program evolves. + +.NH 2 +Languages +.PP +The standard language for IRAF systems and applications code is the SPP +language [5], which is mechanically translated into Fortran during compilation. +Fortran itself may be used for purely numerical routines (no i/o) which +are called from programs written in the SPP language. +.PP +IRAF programs must be written in the SPP language, rather than Fortran, +because the routines in the IRAF i/o libraries are callable only from the +SPP language. The IRAF i/o libraries are interfaced to the SPP language +because they are \fIwritten\fR in the SPP language. +.NH 3 +The SPP Language +.PP +The IRAF Subset Preprocessor language (SPP) implements a subset of the +full language scheduled for development in 1984. The SPP language is +defined by the SPP Reference Manual [5]. Be warned that present compilers +for the SPP language accept constructs that are not permitted by the +language standard. As better compilers become available, programs using +such constructs (i.e., parenthesis instead of brackets for array subscripts), +will no longer compile. If you are not sure what the language standard +permits, have your code checked periodically by someone who is familiar +with the standard. +.NH 3 +The Fortran Language +.PP +The Fortran language is defined by the ANSI standards document ANSI X3.9-1978 +[6]. Be warned that most Fortran compilers accept constructs that are +not permitted by the language standard. When a Fortran module developed +on one machine is ported to another, programs using such constructs +(i.e., the DO WHILE and TYPE constructs provided by the DEC Fortran +compilers), will no longer compile, or will run incorrectly. +.PP +Fortran is used in IRAF applications only for numerical subroutines and +functions, such as mathematical library routines. The following Fortran +statements should not be used in Fortran subprograms that are to be called +from an IRAF program (use of one of these statements would probably +result in a loader error): + +.DS +all statements which involve i/o +CHARACTER +BLOCK DATA +(blank) COMMON +PAUSE +PROGRAM +STOP +.DE + +.PP +The SPP datatypes \fBint\fR, \fBreal\fR, \fBdouble\fR, and \fBcomplex\fR +are equivalent to the Fortran datatypes INTEGER, REAL, DOUBLE PRECISION, +and COMPLEX. These are the only datatypes which should be used in IRAF +callable Fortran modules. +.PP +There is no single widely accepted coding standard for the Fortran language. +Fortran code being ported into the IRAF system should remain in the +form in which it was originally written, except for the removal of +the statements listed above. If extensive modifications are required, +the modules should be recoded in the SPP language. All new software +should be written in the SPP language. + +.NH 2 +Standard Interfaces +.PP +The programmer should be familiar with the routines in the packages +comprising the IRAF program interface, and should use these routines where +applicable. This practice reduces the amount of code which must be +written and debugged, and simplifies the task of the newcomer who must +read and understand the code for the package. Furthermore, optimizations +are often possible in system library routines which would be inappropriate +or difficult to perform in applications modules. +.PP +Only procedures which appear in the documentation for a package (the +\fBexternal specifications\fR of the package) should be called from +programs external to the package. The external specifications +of a package define the \fBinterface\fR to the package. The major +interfaces of a large system are normally documented and frozen early +in the lifetime of the system. Freezing an interface means that its +external specifications stop changing; \fIthe internal specifications of the +code beneath the interface can and will continue to change as the system +evolves\fR. +.PP +Calling one of the internal, undocumented procedures in a package, +or directly accessing the internal package data structures, is known +as \fBbypassing\fR or \fBviolating the interface\fR. Violating an +interface is a serious matter because it results in code which works +when it is coded and tested, but which mysteriously fails some months +later when the programmer responsible for maintaining the called package +releases a new version which has been modified internally, even though +its external specifications have not changed. +.PP +Interfaces are often violated, albeit unintentionally, when a programmer +copies the source for one of the documented procedures in a package, +changes the name, and modifies it to do his bidding. This may result in +the programmer getting his or her job done a bit faster, but must be +avoided at all costs because sooner or later the resultant software system +is going to fail. +.PP +Worse yet, there is no guarantee that when the failure occurs, it will +occur in that part of the system written by the programmer who violated +the interface. Activation of the offending module may corrupt the +internals of the called package, resulting at some indefinite point later +in an apparently unrelated error, which may be difficult to trace back +to the module which originally violated the interface. Typically, +the error will appear only infrequently, when the system is exercised +in a certain way. +.PP +Violating interfaces results in an \fIunreliable system\fR. If such a +problem as that described above happens very often, the systems +programmer charged with maintaining the system will become afraid to +change systems code, and the result will be a system which is hard to +modify, and which will eventually have to be frozen internally as well +as externally. At that point the system will no longer be able to evolve +and grow, and eventually it will die. +.PP +Other common ways in which interfaces are violated include communicating +directly with the host operating system (bypassing the system interface), +communicating directly with the CL, or sending explicit escape sequences +to a terminal. If one were to access an external image format by calling +C routines interfaced directly to UNIX, for example, one would be bypassing +the system interface, and the transportability of the applications program +which did so would be seriously compromised. +.PP +The CL interface may be violated by sending an explicit command to the CL, +by reading from CLIN or writing to CLOUT, or by directly accessing the +contents of a parameter file. Sending a command to the CL violates the +CL interface because a task must know quite a bit about the syntax of +an acceptable CL command, as well as the capabilities of the CL, to send +such a command. +.PP +From the point of view of a task, the CL is simply a data structure, +the fields of which (parameters) are accessed via \fBclget\fR and +\fBclput\fR procedures. Programs which do not expect the CL to be +anything more than a data structure will be immune to changes in the CL +as it evolves. In the future we might well have several different +command languages, each with a different syntax and capabilities. +An IRAF task which does not attempt to bypass the CL interface will +be executable from any of these command languages, without modification +or even recompilation. + +.NH 2 +Package Organization +.PP +Each package should be maintained in its own directory or set of directories. +The name of the \fBpackage directory\fR should be the name of the package, +or a suitable abbreviation. +.PP +A package consists of source files (".x", ".f", ".cl", ".h", ".com"), +documentation (".hlp" and ".ms" files), parameter files (".par"), +and executable modules. If the package is small it will be most convenient +to maintain the package in a single directory. The package directory should +contain a file named "Readme" or "README", describing the function of the +package, and refering the reader to more detailed package documentation. +.PP +If a package is too large to be maintained in a single directory, two +subdirectories named \fBbin\fR and \fBdoc\fR should be created. The +package directory should contain the sources, the Readme file, and +a file named "Makefile" if \fIMake\fR is used to maintain the package. +The \fBbin\fR directory should contain the executable files and the +default parameter files (the CL requires that these be placed in the +same directory). The \fBdoc\fR directory should contain the design +documentation, reference manuals, user's guides, and manual pages. +.PP +The programmer should develop and maintain a package in directories +located within the programmer's own directory system. When the package +is released, an identical set of directories will be created within the +IRAF directory system. Subsequent releases of new versions of the package +will be a simple matter of copying the files comprising the new package +into the IRAF directories, and documenting the differences between the +old and new versions of the package. +.PP +This procedure makes a clear distinction between the current release of +the package and the experimental version, buffering the user from constant +changes in the software, yet giving the programmer freedom to experiment +and develop the software at will. + +.NH 2 +Tasks and Processes +.PP +The \fBtask\fR statement of the SPP language is used to group one or +more compiled tasks (programs) together to form an executable process. +As noted earlier (\(sc3.1.1), the grouping together of programs to +form a physical process is a detail which is irrelevant to the structure +of the package. +.PP +The grouping of several programs together to form a single process can, +however, result in significant savings in disk space by replacing a +number of executable files by a single (slightly larger) file. +The same technique can also have a significant impact on the efficiency of +a CL script, by eliminating the overhead of process initiation required when +each task called by the CL resides in a different executable file. +In the case of a simple task which executes in a few tens of milliseconds, +the overhead of process initiation could easily exceed the time required +to actually execute the task by one or two orders of magnitude. +.PP +The user of a package may well wish to change the way in which programs +are grouped together to form processes, in order to minimize the overhead +of process initiation when the programs are executed in a sequence peculiar +to the user's application. To make it easier to modify the grouping of +tasks to form processes, the \fBtask\fR statement should be placed in +a file by itself, rather than including it in the file containing the +source for a program. +.PP +In other words, \fIthe task statement should be decoupled from the source +for the programs which it references\fR. If this is done, then regrouping +is a simple matter of editing the file containing the task statement, +editing the package script task (which associates tasks with executable +files), and compiling the new task statement. + +.NH 2 +File Organization +.PP +Each program or task in a package should be placed in a separate file. +The name of the file should be the same as the name of the top level module +in the file. This practice makes it easy to locate the source for a module, +and speeds compilations. The \fIMake\fR and \fIMklib\fR utilities are +particularly useful for automatically maintaining programs and libraries +consisting of many small files. +.PP +A file consists of various sections that should be separated by several +blank lines. The sections should be organized as follows: + +.RS +.IP (1) +Any header file includes should be the first thing in the file. +.IP (2) +A prologue describing the contents of the file should immediately follow +the includes. If the prologue exceeds four lines of text, it should be +enclosed in \fB.help\fR ... \fB.endhelp\fR delimiters, rather than making +each line of text a comment line. Large blocks of texts are easier to +edit if maintained as help blocks, and placing such program documentation +in a help block makes it accessible to the online \fBhelp\fR utilities. +.IP (3) +Any parameter or macro definitions that apply to the file as a whole +are next. +.IP (4) +The procedures come last. They should be in a meaningful order. +Top-down is generally better than bottom up, and a "breadth-first" +approach (functions on a similar level of abstraction together) is +preferred over depth-first (functions defined as soon as possible after +their calls). Considerable judgment is called for here. If defining +large numbers of essentially independent utility procedures, consider +alphabetical order. +.RE + +.NH 2 +Header Files +.PP +Header files are files that are included in other files prior to +compilation of the main file. A header file contains a number of +\fBdefine\fR statements, defining symbolically the constants, +structures, and macros used by a subsystem. +Some header files are defined at the system level, +like \fI\fR which must be included in any file which accesses +the image header structure. Other header files are defined and used +within a single package. +.PP +Absolute pathnames should not be used to reference header files. +Use the \fI\fR construction to reference system header files. +Non-system header files should be in the same directory as the source +files which reference them. Header files should be functionally +organized, i.e., declarations for separate subsystems should be in +separate header files. The name of the header file should be the same +as the name of the associated subsystem, and the extension should be ".h". +For example, if the name of a package were "imio", the package header +file would be named "imio.h". +.PP +Header files should not be nested. Nesting header files can cause the +contents of a header file to be seen by the compiler more than once. +Furthermore, the dependence of a source file on a header file should +be made clear and explicit. The pattern matching utilities (\fBmatch\fR +or \fBgrep\fR) are often used to search for the name of a particular +header file, to determine which source files are dependent upon it. + +.NH 2 +Comments +.PP +Well structured code with self explanatory procedure and variable names +does not need to be extensively commented. At a minimum, the contents +of the file should be described in the file prologue, and each procedure +in the file should be preceded by a comment block giving the name of the +procedure and describing what the procedure does. +.PP +Comments within the body of a procedure should not obscure the code. +Large procedures should be broken up into logical sections (groups +of statements which perform some function that can be understood in +the abstract), with one or more blank lines and (optionally) a comment +preceding each section. The comment should be indented to the same +level as the code to which it refers. +.PP +The amount of commenting required depends on the complexity of the code. +Generally speaking, if a comment appears every five lines or less, +the code is either overcommented or too complex. If a one page procedure +contains no comments, it is probably undercommented. +.PP +Short comments may appear on the same line as the code they describe, +but they should be tabbed over far enough to separate them from the +statements. If more than one short comment appears in a block of code, +they should all be tabbed to the same column. + + +\fIExample 1: Compute the mean and standard deviation of a sample.\fR +.DS +.cs 1 22 +# Accumulate the sum and sum of squares of those pixels +# whose value is within range and not indefinite. +do i = 1, npix + if (sample[i] != INDEF) { + value = sample[i] + if (value >= lcutoff && value <= hcutoff) { + ngpix = ngpix + 1 + sum = sum + value + sumsq = sumsq + value \(**\(** 2 + } + } + +# Compute the mean and standard deviation (sigma). +switch (ngpix) { +case 0: # no good pixels + mean = INDEF + sigma = INDEF +case 1: # exactly one good pixel + mean = sum + sigma = INDEF +default: + mean = sum \(sl ngpix + temp = sumsq \(sl (ngpix\(mi1) \(mi sum\(**\(**2 \(sl (ngpix \(** (ngpix\(mi1)) + if (temp < 0) # possible with roundoff error + sigma = 0.0 + else + sigma = sqrt (temp) +} +.DE +.cs 1 + +.NH 2 +Procedure Declarations +.PP +Each procedure should be preceded by several blank lines and a block +comment that gives the name of the procedure and a short description +of what the procedure does. If extensive comments about the arguments +or algorithm employed are required, they should be placed in the +prologue rather than in the procedure itself. +.PP +The prologue should be followed by one or two blank lines, then the +\fBprocedure\fR statement, which should be left justified in column one. +A blank line should follow, followed by the declarations section, +then another blank line, and lastly the body of the procedure, +enclosed in left justified \fBbegin\fR ... \fBend\fR statements. +The declarations should start in column one, and the list of objects +in each declaration should begin at the first tab stop. The body of +the procedure should be indented one full tab stop. +.PP +If the function of an argument, variable, or external function is +not obvious or is not documented in the prologue, it should be +declared alone on a line with an explanatory comment on the same line. +In general, well chosen identifiers are preferable to explanatory +comments, which tend to produce clutter, and which are more likely to +be misleading or wrong. Arguments should be declared first, +followed by local variables and arrays, followed by function declarations, +with the \fBerrchk\fR declaration, common block includes, +string declarations, and \fBdata\fR initialization statements last. + + +\fIExample 2\fR +.DS +.cs 1 22 +# ADVANCE\(ulTO\(ulHELP\(ulBLOCK -- Search a file for a help block +# (block of text preceded by ".help" left justified on a +# line). Upon exit, the line buffer will contain the text +# for the help statement, if one is found. EOF is returned +# for an unsuccessful search. + +int procedure advance\(ulto\(ulhelp\(ulblock (fd, line\(ulbuffer) + +int fd # file to be searched +char line\(ulbuffer[SZ\(ulLINE] +int getline(), strmatch() +errchk getline + +begin + while (getline (fd, line\(ulbuffer) != EOF) + if (strmatch (line\(ulbuffer, "^.help") > 0) + return (OK) + + return (EOF) +end +.DE +.cs 1 + + +.NH 2 +Statements +.PP +The format of both simple and compound statements is the same, +except that the body of a compound statement is enclosed in braces. +The body or executable part of a statement should begin on the second +line of the statement, and should be indented one more level than the +first line. Each successive level should be indented four spaces more +than the preceding level (every other level is aligned on a tab stop). +The opening left brace should be at the end of the first line, +and the closing right brace should be alone on a line +(except in the case of \fBelse\fR and \fBuntil\fR), +indented to the same level as the initial keyword. +.NH 3 +Statement Templates +.PP +Templates are shown only for the compound form of each statement. +To get the template for the non-compound form, omit the braces and +truncate the statement list to a single statement. The \fBiferr\fR +statement is syntactically equivalent to the \fBif\fR statement, and +may be used wherever an \fBif\fR could be used. +.PP +If a compound statement extends for many lines, the readability of the +construct is often enhanced by inserting one or more blank lines into +the body of the compound statement. In the case of a large \fBif else\fR, +for example, a blank line (and possibly a comment) might be added before +the \fBelse\fR clause. Similarly, blank lines could be inserted before +an \fBelse if\fR, a \fBthen\fR, or a \fBcase\fR. + +.cs 1 22 +.DS +\fBif\fR (expr) { + + +} +.DE +.DS +\fBiferr\fR (statement) { + + +} +.DE +.DS +\fBiferr\fR { + + +} \fBthen\fR { + + +} +.DE +.DS +\fBif\fR (expr) { + + +} \fBelse\fR { + + +} +.DE +.cs 1 + +.PP +The \fBelse if\fR construct should be used for general multiway branching, +when the logical conditions for selecting a particular branch are too +complex to permit use of the \fBswitch case\fR construct. + +.DS +.cs 1 22 +\fBif\fR (expr) { + +} \fBelse if\fR (expr) { + +} \fBelse if\fR (expr) { + +} +.DE +.cs 1 + +.PP +The \fBfor\fR statement is the most general looping construct. The \fBdo\fR +construct should be used only to index arrays (i.e., for vector operations). +The value of the index of the \fBdo\fR loop is undefined outside the body +of the loop. The \fBfor\fR statement should be used instead of the +\fBdo\fR if the loop index is needed after termination of the loop. +The \fBrepeat\fR construct, without the optional \fBuntil\fR, should be +used for "infinite" loops (terminated by \fBbreak\fR, \fBreturn\fR, etc.). + +.DS +.cs 1 22 +\fBfor\fR (i=1; i <= MAX; i=i+1) { + + +} +.DE +.DS +\fBdo\fR i = 1, npix { + + +} +.DE +.DS +\fBwhile\fR (expr) { + + +} +.DE +.DS +\fBrepeat\fR { + + +} \fBuntil\fR (expr) +.DE +.cs 1 + +.PP +The \fBswitch case\fR construct is preferred to \fBelse if\fR for a multiway +branch, but the cases must be integer constants. The cases should not be +explicit or "magic" integer values; use symbolically defined constants. +Explicit character constants are permissible, but often it is best to define +character constants symbolically too. A number of common character constants +are defined in the system include file \fI\fR. + +.DS +.cs 1 22 +\fBswitch\fR (expr) { +\fBcase\fR ABC: + +\fBcase\fR DEF, GHI, JKL: + +\fBdefault\fR: + +} +.DE +.cs 1 + +.PP +The \fBprintf\fR statement is a compound statement, since the \fIparg\fR +calls are logically bound to the \fBprintf\fR. Although braces are +not used, the body of the statement should be indented one level to make the +connection clear. Printf statements must not be nested. + +.DS +.cs 1 22 +call \fBprintf\fR (format\(ulstring) + + +.DE +.cs 1 + +.PP +The \fBnull statement\fR should be used whenever a statement is required +by the syntax of the language, but the problem does not require that a +statement be executed. Null cases are often added to switch statements +to reserve cases, even though the code to be executed for the case has +not yet been implemented. + +\fIExample 3\fR +.DS +.cs 1 22 +# Skip leading whitespace. +for (ip=1; IS\(ulWHITE(str[ip]); ip=ip+1) + ; +.DE +.cs 1 + +.NH 2 +Expressions +.PP +Whitespace should be distributed within an expression in a way +which emphasizes the major logical components of the expression. +For simple expressions, this means that all binary operators should +be separated from their operands by blanks. In an argument list, +a blank should follow each comma. Keywords and important structural +punctuation like the brace should be separated from the neighboring +left or right parenthesis by a blank. Complex expressions are generally +clearer if whitespace is omitted from the "inner" expressions. + +.KS +\fIExample 4:\fR + +.RS +.nf +.cs 1 22 +alpha = beta + zeta +a = (a + b) \(sl (c \(** d) +p = ((p\(mi1) \(** SZ\(ulDOUBLE) \(sl SZ\(ulINT + 1 +IM\(ulPIXFILE(im) = open (filename, READ\(ulONLY, BINARY\(ulFILE) +a[i,j] = max(minval, min(maxval, a[i\(mi1,j])) +.fi +.RE +.KE +.cs 1 + +.PP +By convention, whitespace is omitted from all but the most complex +array subscript expressions, and the left square bracket is not +separated from the array name by a blank. A unary operator should +not be separated from its operand by a blank. +.PP +The system include file \fI\fR defines a set of macros which +should be used in expressions involving characters. For example, +IS\(ulWHITE tests whether a character is a whitespace character +(see Example 3), IS\(ulDIGIT tests whether a character is a digit, +and IS\(ulALNUM tests whether a character is alphanumeric. + +.NH 2 +Constants +.PP +Numerical constants should not be coded directly. The \fBdefine\fR +feature of the SPP language should be used to assign a meaningful name. +This practice does much to enhance the readability of code, and +also makes large programs considerably easier to modify, since one +need only change the \fIdefine\fR. Defined constants which are referenced +by more than one file should be placed in an ".h" include file. +.PP +A number of numerical constants are predefined in the SPP language. +A full list is given in reference [5]. Some of the more commonly used +of these global constants are shown below. To save space, those constants +pertaining to i/o (READ\(ulONLY, TEXT\(ulFILE, STDIN, STDOUT, etc.) are omitted, +as are the type codes (TY\(ulINT, TY\(ulREAL, etc.), and the type sizes +(SZ\(ulINT, SZ\(ulREAL, etc.). + +.TS +box center; +cb s s +ci | ci | ci +l | c | l. +Selected Predefined Constants += +constant datatype meaning +_ +ARB i arbitrary dimension, i.e., "char lbuf[ARB]" +BOF, BOFL i,l beginning of file (use BOFL for seeks) +EOF, EOFL i,l end of file (use EOFL for seeks) +EOS i end of string +EPSILON r single precision machine epsilon +EPSILOND d double precision machine epsilon +ERR i error return code +INDEF r indefinite valued pixel +MAX\(ulEXPONENT i largest exponent +MAX\(ulINT i largest positive integer +MAX\(ulREAL r largest real number +NO i opposite of YES +NULL i invalid pointer, etc. +OK i opposite of ERR +SZB\(ulCHAR i size of a char, in machine bytes +SZ\(ulFNAME i maximum size of a file name string +SZ\(ulLINE i maximum size of a line of text +SZ\(ulPATHNAME i maximum size of an OS pathname +YES i opposite of NO +.TE + +.NH 2 +Naming Conventions +.PP +Keywords, variable names, and procedure and function names should be +in lower case. The names of macros and defined parameters should be +in upper case. The prefix SZ, meaning \fBsizeof\fR, should be used +only to name objects which measure the \fIsize of an object in chars\fR. +Other prefixes like LEN, N, or MAX should be used to name objects which +describe the number of elements in an array or set. +.PP +For example, the system wide predefined constant SZ\(ulLINE defines the +maximum size of a line of text, in units of chars, while SZ\(ulFNAME +defines the maximum size of a file name string, also in chars. Since +space in structures is allocated in struct units rather than chars, +the constant defining the size of the FIO file descriptor structure is +named LEN\(ulFIODES, \fInot\fR SZ\(ulFIODES. + +.NH 1 +Portability Considerations +.PP +IRAF programs tend to be highly transportable, due to the machine +and device independent nature of the SPP language and the program +interface libraries. +Nonetheless, it is possible (unintentionally or otherwise) +to produce machine or device dependent programs. +A detailed discussion of the most probable trouble areas follows. +The programmer should be aware of these pitfalls, +but highly transportable programs can be produced merely by +applying the following simple guidelines: \fI +(1) choose the simplest, not the cleverest solution, +(2) write modular, well structured programs, and +(3) use the standard interfaces.\fR +.NH 2 +keep it simple +.PP +Simple, modular programs, structured according to the guidelines in \(sc3.1, +are easy to understand and modify. Even the best programs are unlikely +to be completely portable, because they will only have been tested and +debugged on one or two systems by their author. +Therefore the transportability of a program is significantly increased +if it easy for someone who is unfamiliar with the code to quickly find +and fix any machine dependencies. A package of \fBverification routines\fR +are extremely useful when testing software on a new system, and ideally +should be supplied with each package, along with sample output. +.NH 2 +use the standard interfaces +.PP +Much care has gone into making the standard interfaces as machine and +device independent as possible. By using the standard interfaces in +a straightforward, conventional fashion, one can concentrate on solving +the immediate problem with confidence that a highly transportable +and device independent program will automatically result. +.PP +The surest way to produce a machine or device dependent program is +to bypass an interface. This fact is fairly obvious, but it is not +always easy to tell when an interface is being bypassed (see \(sc3.3 +for examples). Furthermore, by bypassing an interface, one may be able to +provide some feature that would be difficult or impossible to provide +using the standard interfaces. In some cases this may be justified +(provided transportability is not a requirement), +but often the feature is cosmetic, and does not significantly increase +the functionality of the program. The correct procedure is to +request that the interface causing the problem be extended or refined. +.NH 2 +avoid machine dependent filenames +.PP +Machine dependent filenames should not appear in source files. +Files which are referenced at compile time, such as include files, +should be placed either in the package directory or in the system +library directory, to eliminate the need to use a pathname. +Program files accessed at runtime must be referenced with a pathname, +since the runtime current working directory is unpredictable. +In this case a VFN should be used. The logical directory for the VFN +should be defined in the package script task. +.NH 2 +isolate those portions of a program which perform i/o +.PP +This fundamental principle is especially important when one attempts +to transport an applications program from one reduction and analysis +system to another, since the interfaces will almost certainly be quite +different in the two systems. +Encapsulating that part of the program which does i/o +reduces the amount of code which must be understood and changed +to bring up the package on the new system. +.NH 2 +keep memory requirements to a reasonable level +.PP +Not all machines have large address spaces, nor do all machines have +virtual memory. Virtual memory seems simple, but it is not; to use it +effectively one must know quite a bit about how virtual memory is +implemented by the local OS, and implementations of virtual memory by +different operating systems differ considerably in their characteristics +and capabilities. +Using virtual memory effectively is not just a matter of accessing +large arrays in storage order. If one can do that, then there is little +justification for writing a program which is dependent on virtual +memory. +.PP +It is possible to write down a set of guidelines for using virtual +memory effectively and in a reasonably transportable manner, +if one considers only large virtual memory machines. +These guidelines are complex, however, and such a discussion is beyond the +scope of this document. +It must be recognized that any dependence on virtual memory seriously +restricts the transportability of a program, and the use of virtual memory +should only be considered if the problem warrants it. +.PP +The best approach for most applications is to restrict the memory +requirements of a program to the amount of per-process \fIphysical\fR +memory which one can reasonably expect to be available on a modern supermini +or supermicro. An upper limit of one quarter of a megabyte is recommended +for most programs. Programs which need all the memory they can get, +but which can dynamically adjust their buffer space to use whatever is +available, should use the \fBbegmem\fR system call to determine how +much memory is available in a system independent way. +.NH 2 +make sure argument and function datatypes match +.PP +Compilers for the SPP and Fortran languages do not verify that a function +is declared correctly, or that a procedure or function is called with +the correct number and type of arguments. This seriously compromises +the transportability of programs, because \fIwhether or not a type mismatch +causes a program to fail depends on the machine architecture\fR. +Thus, a program may work perfectly well on the software development +machine, but that does not indicate that the program is correct. +.PP +The most dangerous example of this is a procedure which expects an +argument of type short or char. If passed an actual argument +of type integer, as happens when the actual argument is an integer +constant (i.e., NULL, 1, ('a'+10), etc.), we have a type mismatch since +the corresponding Fortran dummy argument is (usually) declared as +INTEGER\(**2, while the actual argument is of type INTEGER. +Whether or not the program will work on a particular machine depends +on how the machine arranges the bytes in an integer. Thus, the +mismatch will go undetected on a VAX but the program will fail on +an IBM machine. +.PP +A similar problem occurs when a boolean dummy argument or function +is declared as an integer in the calling program, and vice versa. +In this case, whether or not the program works depends on what integer +values the compiler uses to represent the boolean constants \fBtrue\fR +and \fBfalse\fR. The danger is particularly great if the compiler +happens to use the constants one and zero for true and false, since the +integer constants YES and NO are equivalent in value and similar in function. +.PP +The technique used by the Fortran compiler to implement subroutine and +function calls determines whether or not +\fBcalling a function as a subroutine\fR, +or calling a subprogram with the \fBwrong number of arguments\fR +will cause a program to fail. +For example, if the arguments to a subroutine are +placed on the hardware stack during a subroutine call, as is done by compilers +which permit recursive calls, then most likely the stack will not be +popped correctly upon exit from the subroutine, and the program will fail. +On a machine which statically allocates storage for argument lists, +the problem may go undetected. +.NH 2 +do not use output arguments as local variables +.PP +This section is not directly relevant to the issue of portability, +but is included nonetheless because the topic presented here +is logically related to that discussed in the previous section. +.PP +The output or status arguments of a procedure should be regarded as +\fIwrite-only\fR. Output arguments should not be used as local +variables, i.e., should not appear in expressions. +Likewise, the function value of a typed procedure should not be +used as a local variable. +.PP +To see why this is important, consider a procedure \fIalpha\fR +with input arguments A and B, and output arguments C and D: +.DS +procedure alpha (a, b, c, d) +.DE +The calling program may not be interested in the return values C and D, +and may therefore call \fIalpha\fR as follows: +.DS +call alpha (a, b, junk, junk) +.DE +Since the SPP language passes arguments by reference, this call maps the +two dummy arguments C and D to the same physical storage location. +If C and D are used as distinct local variables within \fIalpha\fR +(presumably in an effort to save storage), +a subtle computation error will almost certainly result, +which may be quite difficult to diagnose. +.NH 2 +avoid assumptions about the machine precision +.PP +The variation of numeric precision amongst machines by different manufacturers +is a well known problem affecting the portability of software. +This problem is especially important in numeric software, where +the accumulation of errors may be critically important. +The SPP language addresses the problem of machine precision by providing +both single and double precision integer and floating point data types, +and by defining a minimum precision for each. +.PP +To produce a transportable program, one must select datatypes based on +the minimum precisions given in the table below. +The actual precision provided by the software development machine +may greatly exceed these values, but a program must not take advantage +of such excess precision if it is to be transportable. +In particular, a long integer should be used whenever a high precision +integer is required, and care should be taken to avoid large floating +point exponents. + +.TS +center box; +cb s +c | c +lb | l. +Minimum Precision of Selected SPP Datatypes += +datatype precision +_ +char +/- 127 (8 bit signed) +short +/- 32767 (16 bit signed) +int +/- 32767 (16 bit signed) +long +/- 2147483647 (32 bit signed) +real 6 decimal digits, exponent +/- 38 +double 14 decimal digits, exponent +/- 38 +.TE + +.NH 2 +do not compare floating point numbers for equality +.PP +In general, it is very difficult to reliably compare floating point +numbers for equality. The result of such a comparison is not only +machine dependent, it is context dependent as well. +The only possible exception is when numbers are compared which have +only been copied in an assignment statement, without any form of type +coercion or other transformations. + +.DS +.cs 1 22 +real x + +begin + x = 1.0D10 + if (x == 1.0D10) + ... +end +.DE +.cs 1 + +.PP +The code fragment shown above, simple though it is, is machine dependent +because the double precision constant has been coerced to type real and +back to double by the time the comparison takes place. +Comparisons of just this sort are possible in IRAF programs which flag +bad pixels with the magic value \fBINDEF\fR. +Avoid type coercion of indefinites; use INDEF or INDEFR only for +type real pixels, INDEFD for type double pixels, and so on. +.PP +Occasionally it is necessary to determine if two floating point numbers are +equivalent to within the machine precision. +The predefined machine dependent constants \fBEPSILON\fR and +\fBEPSILOND\fR are provided in the SPP language to facilitate such comparisons. +The two single precision floating point numbers \fIx\fR and \fIy\fR are +said to be equivalent to within the machine precision, +\fIprovided the quantities \fRx\fI and \fRy\fI are normalized +to the range one to ten prior to comparison\fR, +if the following relation holds: +.DS +abs (x \(mi y) < EPSILON +.DE +.NH 2 +use the standard predefined machine constants +.PP +A number of obviously machine dependent constants are predefined in the +SPP language. These include such commonly used values as EPSILON, INDEF, +SZB\(ulCHAR, and so on. Other less commonly used machine constants, +such as the maximum number of open files (LAST\(ulFD), are defined in +the system include file \fI\fR. Device dependent parameters such as +the block or sector size for a disk device are not necessarily unique +within a system, and are therefore not predefined constants. A run time +call is required to obtain the value of such device dependent parameters. +.PP +A complete list of the standard predefined machine dependent constants +is shown below. Some of these are difficult to use in a transportable fashion. +The transportability of a program is greatest when no machine dependent +parameters are used, be they formally parameterized or not. + +.TS +center box; +cb s s +ci | ci | ci +l | c | l. +Machine Dependent Constants += +name datatype meaning +_ +BYTE\(ulSWAP i swap magtape bytes? +EPSILON r single precision machine epsilon +EPSILOND d double precision machine epsilon +INDEF r indefinite pixel of type real +INDEF\fIt\fR \fIt\fR indefinite valued pixels +MAX\(ulDIGITS i max digits in a number +MAX\(ulEXPONENT i largest floating point exponent +MAX\(ulINT i largest positive integer +MAX\(ulLONG l largest positive long integer +MAX\(ulREAL r largest floating point number +MAX\(ulSHORT i largest short integer +NBITS\(ulINT i number of bits in an integer +NBITS\(ulSHORT i number of bits in a short integer +NDIGITS\(ulDP i number of digits of precision (double) +NDIGITS\(ulRP i number of digits of real precision +SZB\(ulADDR i machine bytes per address increment +SZB\(ulCHAR i machine bytes per char +SZ\(ulFNAME i max chars in a file name +SZ\(ulLINE i max chars in a line +SZ\(ulPATHNAME i max chars in OS dependent file names +SZ\(ulVMPAGE i page size, chars (1 if no virtual mem.) +SZ\(ul\fItype\fR i sizes of the primitive types +WORD\(ulSWAP i swap magtape words? +.TE + +.NH 2 +explicitly initialize variables +.PP +Storage is statically allocated for all local and global variables +in the SPP language. Unless explicitly initialized, the initial value +of a variable is \fIundefined\fR. Although many compilers implicitly +initialize variables with the value zero, this fact is quite machine +dependent and should not be depended upon. Local variables should be +explicitly initialized in an assignment or \fBdata\fR statement before +use. +.PP +Global variables (in common blocks) cannot be initialized with +the \fBdata\fR statement. Some compilers permit such initialization, +but this feature is again quite machine dependent, and should not +be depended upon. Global variables must be initialized by a run +time initialization procedure. +.NH 2 +beware of functions with side effects +.PP +The order of evaluation of an expression is not defined. In particular, +the compiler may evaluate the components of a boolean expression in +any order, and parts of a boolean expression may not be evaluated at +all if the value of the expression can be determined by what has already +been evaluated. +This fact can cause subtle, potentially machine dependent problems +when a boolean expression calls a function with side effects. +To see why this is a problem, consider the following example: +.DS +.cs 1 22 +if (flag || getc (fd, ch) == EOF) + ... +.DE +.cs 1 +.PP +The function \fIgetc\fR used in the example above has two side effects: +it sets the value of the external variable \fIch\fR, and it advances the +i/o pointer for file \fIfd\fR by one character. +If the value of \fIflag\fR in the \fBif\fR statement is true, +the value of the boolean expression is necessarily true, and the compiler +is permitted to generate code which would skip the call to \fIgetc\fR. +Whether or not \fIgetc\fR gets called during the evaluation of this expression +depends on how clever the compiler is (which cannot be predicted), +and on the run-time value of the variable \fIflag\fR. +.NH 2 +use of intrinsic functions +.PP +The intrinsic functions are generic functions, meaning that the same +function name may be used regardless of the datatype of the arguments. +Unlike ordinary external functions and local variables, +\fIintrinsic functions should not be declared\fR. Not all compilers +ignore intrinsic function declarations. +.PP +Only the intrinsic functions shown in the table below should be used in SPP +programs. Although current compilers for the SPP language will accept +many Fortran intrinsic functions other than those shown, the use of such +functions is nonstandard, and will not be supported by future compilers. + +.TS +center box; +cb s s s s s s +l l l l l l l. +Standard SPP Intrinsic Functions += +abs atan conjg exp long nint sinh +acos atan2 cos int max real sqrt +aimag char cosh log min short tan +asin complex double log10 mod sin tanh +.TE + +.PP +Note that the names of the type coercion functions (\fBchar\fR, \fBshort\fR, +\fBint\fR, \fBreal\fR, etc.) are the same as the names of the datatypes in +declarations. The functions \fBlog10\fR, \fBtan\fR, and the hyperbolic +functions, may not be called with complex arguments. +.NH 2 +explicitly align objects in global common +.PP +Care should be taken to align objects in common blocks on word boundaries. +Since the size of a word is machine dependent, this is not always easy +to do. Common blocks which contain only objects of type integer and +real are the most portable. Avoid booleans in common blocks; +use integer variables with the values YES and NO instead. +Objects of type char and short should be grouped together, +preferably at the end of the common block, with the total size of the +group being an even number. Remember that the SPP compiler allocates +one extra character of storage for character arrays; character arrays +should therefore be odd-dimensioned. + +.NH 1 +Software Documentation +.PP +Even the best software system is of no value unless people use it. +Given several software packages of roughly similar capabilities, +people are most likely to use the package which is easiest to understand, +i.e., which has the simplest interface, and which is best documented. +Documentation is perhaps the single most important part of the user interface +to a system, and to a large extent the quality of the documentation for +a system will determine what judgment people make of the quality of the +system itself. +.PP +The documentation associated with a large software system (or applications +package) can be classed as either user documentation or system documentation. +User documentation describes the function of the modules making up the +system, without reference to the details of how the modules are implemented. +System documentation includes design documentation, +documentation describing the details of how the software is implemented, +and documentation describing how to install and test the system. +.NH 2 +User Documentation +.PP +The first contact a user has with a system is usually provided by the +user documentation for the system. Good user documentation should provide +an accurate and concise introduction to the system; it should not emphasize +the glamorous system features or otherwise try to "sell" the system. +It should not be necessary for the user to read all the documentation to +be able to make simple use of the system. The documentation should be +structured in such a way that the user may read it to the level of detail +appropriate to his or her needs. Good user documentation is characterized by +its conciseness and clarity, not by the sheer volume of documentation provided. +.PP +In what follows, we use the terms "system", "subsystem", and "package" +interchangeably. The term "function" refers both to CL callable tasks +and to library procedures. The term "user" refers both to end users and +to programmers, depending on the nature of the system or package to be +documented. The term "document" need not refer to separately bound +documents; whether separate documents or multiple sections within a +single document are produced depends upon the size of the system and +upon the number of authors. +.PP +The user documentation for a large system or package should consist of at +least the following documents: +.RS +.IP (1) +The \fBUser's Guide\fR, which introduces the user to the system, +and provides a good overall summary of the facilities provided by the system. +This document should provide just enough information to tell the +first time user how to exercise the most commonly used functions. +Great care should be taken to produce a highly readable document, +minimizing technical jargon without sacrificing clarity and conciseness. +Plenty of figures, tables, and examples should be included to enhance +readability. +.IP (2) +The \fBReference Manual\fR, which describes in detail the facilities +available to the user, and how to use these facilities. The reference +manual is the definitive document for the system. It should be complete +and accurate; technical terms and formal notations may be used for +maximum precision and clarity. The reference manual defines the \fIuser +interface\fR to the system; implementation details do not belong here. +.RE +.PP +The minimum reference manual consists of a set of so-called \fBmanual +pages\fR, each of which describes in detail one of the functions provided +by the system. The manual pages should be available both on-line and +in printed form. The printed reference manual should contain any +additional information which pertains to more than one function, and +which therefore does not belong in a manual page, but which is too +technical or detailed for the user's guide. +.PP +Other user documentation might include a report of the results of any +tests of the system, as when an a scientific analysis package is tested +with artificial data. An objective evaluation of strengths and shortcomings +of the algorithms used by the package might be useful. +It is important that both the user and the implementor understand the +limitations of the software, and its intended range of application. +.NH 2 +System Documentation +.PP +System documentation is required to produce, maintain, test, and install +software systems. The main requirement for system documentation is +that it be accurate; it need not be especially well written, is usually +quite technical, and need not be carefully typeset nor printed. +The system documentation for a package should be maintained in files in +the source directories for the package which it describes. +.PP +The system documentation for a large system or package should include +the following documents: +.RS +.IP (1) +The requirements for the system. +.IP (2) +The detailed technical specifications for the system. +.IP (3) +For each program in the system, a description of how that program is +decomposed into modules (i.e., a structure chart), and the function +of each module. +.IP (4) +Implementation details, including descriptions of the major data structures +and details of their usage, descriptions of complicated algorithms, +important strategies and design decisions, and notes on any code +that might be hard for another programmer to understand. This need not +extend to describing program actions which are already documented +using comments in the code. +.IP (5) +A test plan, describing what verification software is available, +how to use it, and how to interpret the results. The amount of +documentation required should be minimized by automating the verification +software as much as possible. +.IP (6) +Instructions on how to install the system when it is ported to a new +computer. List any include files which may need to be edited, +directories required by the system which may have to be created, +libraries or other program modules external to the package which +are required, and any file or device names which may have to be changed. +A description of how to compile each program should be included; +a UNIX \fIMakefile\fR for the package would be ideal. +.IP (7) +A revision history for the software, giving the names of the original +authors, the dates of the first release and of all subsequent revisions, +and a summary of the changes made in each release of the system. +Any bugs, restrictions, or planned improvements should be noted. +.RE +.PP +These documents are listed more or less in the order in which they would +be produced. The requirements and specifications of a system are written +during the preliminary design phase. +Documentation describing the decomposition of programs into modules, +and detailing the data structures and algorithms used by the package +is written during the detailed design stage. +After the code has been written and tested, +additional notes on the details of the implementation should be made, +and the original design documentation should be brought up to date. +The remaining documentation should be produced after implementation, +before the package is first released. +.NH 2 +Documentation Standards +.PP +All documentation should be maintained in computer readable form on the +software development machine. The standard text processing software +for IRAF user documentation is the UNIX \fITroff\fR text formatter, used +with the \fIms\fR macros, the \fITbl\fR table preprocessor, the \fIEqn\fR +preprocessor for mathematical graphics, and so on. Associated utilities +such as \fISpell\fR and \fIDiction\fR are useful for detecting spelling +errors and bad grammatical constructs. User documentation will be +typeset and reproduced in quantity by the KPNO print shop. +.PP +The standard text processing software for all on-line manual pages and +system documentation is the \fILroff\fR text formatter, a portable +IRAF system utility. The UNIX utilities cannot be used for on-line +documentation, and should not be used for system documentation because +it is difficult to justify the expense of typesetting system documentation, +and because system documentation is not maintained in printed form, +and many users will not have access to the UNIX text processing tools. +The Lroff text processor is more than adequate for most system +documentation. +.PP +The format of user documentation should be similar to that used in this +document, i.e.: +.RS +.IP (1) +The title page should come first, consisting of the title, +the names of the authors and of their home institutions, an abstract +summarizing the contents of the document, and the date of the first +release of the document, and of the current revision. +.IP (2) +A table of contents for the document should be given next, +except possibly in the case of very small documents. +.IP (3) +Next should come the introduction, followed by the body of the document, +organized into sections numbered as in this document. +.IP (4) +Any references, appendices, large examples, or the index or glossary +if any, should be given last. +.RE +.PP +Lroff and Troff format source files should have the extensions ".hlp" +and ".ms", respectively. \fIAll documentation for a package should +be maintained in the source directories for the package\fR, +to ensure that the documentation gets distributed with the package, +does not get lost, can easily be found, and to make it easier for the +programmer to keep the documentation up to date. +.NH 2 +Technical Writing +.PP +Technical writing is a craft comparable in difficulty to computer programming. +Writing good documentation is not easy, nor is it a single stage process. +Documents must be designed, written, read, criticized, and then rewritten +until a satisfactory document is produced. The process has much in common +with programming; first one should establish the requirements or scope of the +document, then one should prepare an initial outline (design), which is +successively refined until it is detailed enough to fully define the contents +of the final document. Writing should not begin until one has structured +the document into a hierarchy of sections, each of which is well named, +and each of which documents a single topic. +.PP +English is not a formal language, like a computer language, and it is +accordingly very difficult to define a standard style for technical prose. +A discussion of writing style in general is given in the excellent little +book by Strunk and White [14]. Technical writing differs from other writing +in that the material should be clearly and logically organized into sections, +and graphics, i.e., lists, tables, figures, examples, etc., should be +liberally used to present the material. Large, monolithic paragraphs, +or entire pages containing only paragraphs of text, appear forbidding to +the reader and should be avoided. +.PP +The following guidelines for writing style in technical documents are +reproduced from reference [8], \fISoftware Engineering\fR by I. Sommerville: +.RS +.IP (1) +Use active rather than passive tenses when writing instruction manuals. +.IP (2) +Do not use long sentences which present a number of different facts. +It is much better to use a number of shorter sentences. +.IP (3) +Do not refer to previously presented information by some reference +number on its own. Instead, give the reference number and remind the +reader what the reference covered. +.IP (4) +Itemize facts wherever possible rather than present them in the form +of a sentence. +.IP (5) +If a description is complex, repeat yourself, presenting two or more +differently phrased descriptions of the same thing. If the reader +fails to completely understand one description, he may benefit from having +the same thing said in a different way. +.IP (6) +Don't be verbose. If you can say something in 5 words do so, rather than +use ten words so that the description might seem more profound. There is +no merit in quantity of documentation \(em quality is much more important. +.IP (7) +Be precise and, if necessary, define the terms which you use. +Computing terminology is very fluid and many terms have more than one +meaning. Therefore, if such terms (such as module or process) are used, +make sure that your definition is clear. +.IP (8) +Keep paragraphs short. As a general rule, no paragraph should be made +up of more than seven sentences. This is because of short term memory +limitations. [Another general rule is that few paragraphs should be +longer than seven or eight \fIlines\fR on an 8\(12 by 11 inch page.] +.IP (9) +Make use of headings and subheadings. Always ensure that a consistent +numbering convention is used for these. +.IP (10) +Use grammatically correct constructs and spell words correctly. +Avoid constructs such as split infinitives. +.RE +.PP +Technical writing should not be regarded as a chore. The process is difficult +and challenging, and can be quite rewarding. Often the act of writing +results in new insight for the writer. Writing is a form of judgment; +if an idea or design cannot be explained clearly, there is probably something +wrong with it. Writing forces one to consider an issue in detail, and often +is the source of new ideas. A software system cannot be widely used until +it is documented, and the quality of the documentation will do much to +ensure the success of the system itself. + +.sp 2 +.ps -1 +.vs -1p +.pg +.ftB +References +.sp.4 +.pg +.ta .3i +.in .3i +.ftR +.ti0 +1. D. C. Wells and E. W. Greisen, +.ul +FITS \(em A Flexible Image Transport System, +Proceedings of the International Workshop on Image Processing in +Astronomy, Ed. G.Sedmak, M.Capaccioli, R.J.Allen, Osservatorio +Astronomico di Trieste, 1979. +.sp.4 +.ti0 +2. E. Allman and M. Stonebreaker, +"Observations on the Evolution of a Software System", +\fIComputer\fR, June 1982. +.sp.4 +.ti0 +3. B. W. Kernighan and D. M. Ritchie, +.ul +The C Programming Language, +Prentice - Hall, Inc., Englewood Cliffs, New Jersey, 1978. +.sp.4 +.ti0 +4. H. Spencer et al., +.ul +Indian Hill C Style and Coding Standards as amended for U of T Zoology UNIX. +An annotated version of the original Indian Hill (Bell Labs) style manual for +the C language. +.sp.4 +.ti0 +5. D. Tody, +.ul +A Reference Manual for the IRAF Subset Preprocessor Language, +KNPO, January 1983. +.sp.4 +.ti0 +6. American National Standards Institute, Inc., +.ul +American National Standard Programming Language Fortran, +document number ANSI X3.9-1978, April 1978. +.sp.4 +.ti0 +7. J. Larmouth, +.ul +Fortran 77 Portability, +Software \(em Practice and Experience, Vol. 11, 1071-1117 (1981). +.sp.4 +.ti0 +8. I. Sommerville, +.ul +Software Engineering, +Addison-Wesley, 1982. +.sp.4 +.ti0 +9. W. P. Stevens, +.ul +Using Structured Design, +John Wiley & Sons, Inc., 1981. +.sp.4 +.ti0 +10. J. D. Aron, +.ul +The Program Development Process; Part II, The Programming Team, +Addison-Wesley, 1983. +.sp.4 +.ti0 +11. W. S. Davis, +.ul +Tools and Techniques for Structured Systems Analysis and Design, +Addison-Wesley, 1983. +.sp.4 +.ti0 +12. B. Meyer, +"Principles of Package Design", +\fICommunications of the ACM\fR, July 1982, Vol. 25, No. 7. +.sp.4 +.ti0 +13. G. D. Bergland, +"A Guided Tour of Program Design Methodologies," +\fIComputer\fR, October 1981. +.ti0 +14. W. Strunk Jr. and E. B. White, +.ul +The Elements of Style, +Mcmillan Publishing Co., Inc., 1979 (third edition). diff --git a/doc/std_gl.ms b/doc/std_gl.ms new file mode 100644 index 00000000..dfd70ad0 --- /dev/null +++ b/doc/std_gl.ms @@ -0,0 +1,571 @@ +.TL +Standard Nomenclature + +.SH +AAS +.IP +The American Astronomical Society. +.SH +C +.IP +C is a powerful modern language for both systems and general programming. +C provides data structuring, recursion, automatic storage, a fairly +standard set of control constructs, a rich set of operators, +and considerable conciseness of expression. Developed by Ken Thompson +and Dennis Ritchie at Bell Labs in the early 1970's, C is the language +used to implement the kernel of the UNIX operating system, as well as +the standard UNIX utilities. +.SH +CL +.IP +The IRAF Command Language. The CL is an interpreted language designed +to execute external \fBtasks\fR, and to manage their \fBparameters\fR. +The CL organizes tasks into a hierarchical structure of independent +\fBpackages\fR. Tasks may be either \fBscript tasks\fR, written in +the CL, or compiled \fBprograms\fR, written in the SPP language, and +linked together to form \fBprocesses\fR. A single process may contain +an arbitrary number of tasks. +.IP +The CL is itself both a task and a process. The CL process runs +concurrently with the subtasks which it executes. The CL process and +the process containing the subtask being executed communicate dynamically +via interprocess communication, providing both a highly interactive mode +of execution, as well as a batch mode. +.IP +The CL provides \fBredirection\fR of all i/o streams, including graphics output +and cursor readback. +Other facilities include \fBmenus\fR, \fBcommand logging\fR, +parameter \fBprompting\fR, an online \fBhelp facility\fR, a "programmable desk +calculator" capability, and a \fBlearn mode\fR. +New packages and tasks are easily added by the user, +and the CL environment is maintained in the user's own directories, +providing continuity from session to session. +.SH +CLIO +.IP +CL I/O. +A package of SPP callable library routines, used to communicate with the CL. +.SH +FIO +.IP +File I/O. +A package of SPP callable library routines, used to access files. +.SH +FITS +.IP +A "Flexible Image Transport System". FITS is +a standard data format used to transport images (pictures) between computers +and institutions. Developed in the late 1970s by Donald Wells (KPNO) and +Eric Greisen (NRAO), the FITS standard is now widely used for the +interchange of image data between astronomical centers, and is officially +sanctioned by both the AAS and the IAU. +.SH +FMTIO +.IP +Formatted I/O. +A package of SPP callable library routines, used to perform formatted +i/o (decoding and encoding of character strings). +.SH +Fortran +.IP +As the most widely used language for scientific computing for the past +twenty years, Fortran needs no introduction. Fortran is used in the +IRAF system as a sort of "super assembler" language. Programs and procedures +written in the IRAF SPP language are mechanically translated into a highly +portable subset of Fortran, and the Fortran modules are in turn translated +into object modules by the host resident Fortran compiler. Existing numerical +and other modules, already coded in the Fortran language, are easily linked +with modules written in the SPP language to produce executable programs. +The IRAF system and applications software does not use any Fortran i/o; +all i/o facilities are provided by the IRAF \fBprogram interface\fR and +\fBvirtual operating system\fR. +.SH +GIO +.IP +Graphics I/O. +A package of SPP callable library routines, used to interface to +graphics and grayscale devices. +.SH +IAU +.IP +The International Astronomical Union. +.SH +IMIO +.IP +Image I/O. +A package of SPP callable library routines, used to access imagefiles +(bulk data arrays). +.SH +IRAF +.IP +The IRAF or "Image Reduction and Analysis Facility", consists of a +virtual operating system, a command language, a general purpose +programming language (which was developed especially for IRAF), +a large i/o library, a numerical library, and numerous support utilities +and scientific applications programs. The system is designed to be +transportable to any modern superminicomputer. When completed, the +system will provide extensive facilities for general image processing, +astronomical data reduction and analysis, scientific programming, +and general software development. +.SH +Lroff +.IP +The Lroff text formatter is part of the portable IRAF system. +The online \fBhelp\fR facilities use Lroff, and hence manual pages +and other online documentation must be maintained in Lroff form. +The Lroff text formatter is patterned after the UNIX \fITroff\fR +text formatter. +.SH +MTIO +.IP +Magnetic Tape I/O. +A package of SPP callable library routines, used to read and write +magnetic tapes. +.SH +Make +.IP +Make is a UNIX utility program, used to compile and link +(make) programs. +Make takes as input a human readable \fIMakefile\fR which +describes the interdependencies of the modules in the package, +as well as giving exact instructions for making each module. +When making a target module, Make recompiles only those +modules which have been changed since the target was last made. +A simple command like "make all" usually suffices to make all of +the modules in a package. +.IP +Make is most useful on UNIX systems. Even on non-UNIX +systems, however, the makefile for the package is useful documentation, +for it describes precisely how to make each module in the package. +.SH +Mklib +.IP +Mklib is a UNIX dependent utility developed for IRAF. +Mklib is analogous to Make, except that Mklib is used to maintain libraries. +Mklib checks each module in a library to see if it is up to date, +and if not, recompiles the module and installs the new object module +in the library. +Mklib is used by the IRAF Sysgen utility to automatically update +the IRAF system (consisting of four libraries containing several +hundred modules). +.SH +OS +.IP +(1) An acronym for the term "operating system". +(2) The OS interface package, which contains the machine dependent +routines required to interface the portable IRAF i/o packages to the +local operating system. +.SH +OSFN +.IP +An acronym for the term "OS dependent file name". +.SH +SPP +.IP +The IRAF Subset Preprocessor Language (SPP), implements a subset of the +full language scheduled for development in 1984. The SPP language is +a general purpose language, patterned after Ratfor and C. +The language provides advanced capabilities, modern control constructs, +enhanced portability, +and support for the IRAF runtime library (CL interface, etc.). +.SH +Troff +.IP +Troff is the UNIX text formatter. In IRAF documentation, +\fITroff\fR is always used in conjunction with the "ms" macro package. +.SH +UNIX +.IP +An operating system developed at Bell Labs in the early 1970s by +Ken Thompson and Dennis ritchie. Though originally developed for +the PDP11, UNIX is now available on a wide range of machines, +ranging from micros to superminis and mainframes. UNIX is the +software development system for the IRAF project. +.SH +VFN +.IP +An acronym for the term "virtual file name". A virtual file name is +a machine independent filename of the form "ldir$root.extn". +.SH +VMS +.IP +The native operating system for Digital Equipment Corporation's VAX +series of supermini computers. +.SH +VOPS +.IP +The "vector operators" package, a package of SPP callable library +routines providing a wide class of vector pseudo-instructions. +The VOPS routines are written in the SPP language, but may be +optimized in assembler or interfaced directly to an array processor, +depending upon the implementation. +.SH +band +.IP +The Nth band of a three dimensional array or image is denoted +by the subscript [\(**,\(**,N], +where \(** refers to all the pixels in that dimension. +A band is a two dimensional array. +.SH +binary file +.IP +A binary file is an array or sequence of \fBchars\fR, where +the term char defines a unit of storage, and implies nothing +about the contents of the file. +Data is transferred between a binary file and a buffer in the +calling program by a simple copy operation, without any form of conversion. +Binary files are created, deleted, and accessed via the +routines in the FIO interface. Barring device restrictions, +binary files may be accessed at random, and extended indefinitely. +Almost any device may be accessed as a binary file via FIO. +.SH +binary operator +.IP +An operator which combines two operands to produce a single result +(i.e., the addition operator in "x + y"). +.SH +brace +.IP +The left and right braces are the characters "{" and "}". Braces +are used in the CL and in the SPP language to group statements to form +a compound statement. +.SH +bracket +.IP +The left and right square brackets are the characters "[" and "]". +Brackets are used in the SPP language to form array subscripts. +.SH +byte +.IP +The \fBbyte\fR is the smallest unit of storage on the host machine. +The IRAF system assumes that there are an integral number of bytes +in a \fBchar\fR and in an address increment (and therefore that the +byte is not larger than either). +On most modern computers, a byte is 8 bits, and a char is 16 bits +(INTEGER\(**2). If the address increment is one byte, the machine +is said to be \fBbyte addressable\fR. Other machines are \fBword +addressable\fR, where one word of memory contains two or more bytes. +In the SPP language, SZB\(ulCHAR gives the number of bytes per char, +and SZB\(ulADDR gives the number of bytes per address increment. +.SH +char +.IP +The \fBchar\fR is the smallest signed integer which can be +directly addressed by programs written in the SPP language. The char +is also the unit of storage in IRAF programs: the sizes of objects are +given in units of chars, and binary files and memory are addressed in +units of chars. Since the SPP language interfaces to the machine via the +local Fortran compiler, the Fortran compiler determines the size of a char. +On most systems, the datatype \fBchar\fR is equivalent to the (nonstandard) +Fortran datatype INTEGER\(**2. +.SH +column +.IP +The Nth column vector of a two dimensional array or image is denoted +by the subscript [N,\(**], +where \(** refers to all the pixels in that dimension. +The Nth column of the Mth band of a three dimensional array or image +is denoted by [N,\(**,M]. +.SH +compiler +.IP +A compiler for a language X is a program which translates a \fBsource +module\fR written in the language X into an \fBobject module\fR. +A \fBlinker\fR subsequently combines a number of object modules to +produce an executable \fBprocess\fR. +.SH +coupling +.IP +Coupling measures the strength of relationships between modules. +The independence of modules is maximized when coupling in minimized. +A change in one module is least likely to require a change in another +module when the two modules are minimally coupled. +.SH +data structure +.IP +A data structure is an aggregate of two or more data elements. +Examples include arrays, descriptors, files, records, linked lists, +trees, graphs, and so on. +.SH +database management +.IP +Database management is a branch of computing science concerned with +techniques for implementing, maintaining, and accessing databases. +Databases may be used to store arbitrarily complex data objects. +A database is self describing and self contained. Access to a database +typically occurs only through well defined interfaces, which ideally +provide a high degree of \fBdata independence\fR (the external world +knows no more than needed about the contents of the database, or how +data is stored in the database). +.IP +Applications programs communicate with one another via records passed +through the database, as well as save final results in the database. +A general purpose query language can be used to inspect and manipulate +the contents of a database. +.SH +datafile +.IP +A datafile is a database storage file. Datafiles are used to store +program generated \fBrecords\fR or descriptors, containing the results +of the analysis performed by a program. Datafile records may be the +final output of a program, or may be used as input to a program. +.SH +field +.IP +A field is an element of a structure or record. Each field has +a name, a datatype, and a value. +.SH +function +.IP +A function is a procedure which returns a value. Functions must be +declared before they can be used, and functions must only be used in +expressions. It is illegal to \fBcall\fR a function. +.SH +header file +.IP +A header file is a file (extension ".h") containing only defined +constants, structure definitions, macro definitions, or comments. +Header files are included in other files by referencing them in +\fBinclude\fR statements, and are not directly compiled. +.SH +identifier +.IP +An identifier is a sequence of characters used to name a procedure, +variable, etc. in a compiled language. In the SPP language, an identifier +is an upper or lower case letter, followed by any number (including zero) +of upper or lower case letters, digits, or instances of the underscore +character. +.SH +image +.IP +An array of arbitrary dimension and datatype, used for bulk data storage. +An image is an array of \fBpixels\fR. +.SH +imagefile +.IP +The form in which images are implemented in the IRAF system. The IRAF +currently supports images of up to seven dimensions, in any of eight +different datatypes. Only \fBline storage mode\fR is currently available. +The "imagefile" structure is actually implemented as two separate files, +the \fBimage header file\fR and the \fBpixel storage file\fR. +.SH +include file +.IP +An "\fBinclude\fR \fI\fR" +statement in the SPP language is replaced during compilation by the +contents of the named include file (the contents of the include +file are inserted into the input stream). +.SH +interface +.IP +The interface to a module is \fIdefined\fR by the \fBexternal specifications\fR +of the module. The \fIactual\fR interface to a module is everything that +is known about the module by other modules in the system. The interface to +a subroutine library, for example, is defined by the manual pages, reference +manuals, and other formal documentation for the library. +.SH +line +.IP +The Nth line of a two dimensional array or image is denoted +by the subscript [\(**,N], +where \(** refers to all the pixels in that dimension. +The Nth line of the Mth band of a three dimensional array or image +is denoted by [\(**,N,M]. +.SH +list file +.IP +A list file is a text file, each line of which is a record containing +one or more fields. Each record in the list has the same format, +though not all fields need be present (fields can only be omitted +from right to left). +.SH +macro +.IP +A macro, or \fBinline function\fR, is a function with zero or more arguments, +which is expanded by text substitution during the preprocessing phase +of compilation. +.SH +newline +.IP +The newline character ('\\n') delimits each line of text +read by the FIO input procedures. If a text file is read character +by character, a single newline character marks the end of each line, +and the special character EOF marks the end of the file. Newline is +logically equivalent to a carriage return followed by a line feed. +.SH +operand +.IP +An operand is a data object which is operated upon by an operator, +procedure, or task. Operands may be either input or output, or both. +.SH +package +.IP +A package is a set of modules which operate on a specific \fBabstract +datatype\fR. The modules in a package may be either procedures or +tasks. Examples of abstract datatypes include the CL, the file, +the imagefile, and so on. +Some packages are merely collections of modules which +are logically related (i.e., the class of system utilities). +.SH +parameter +.IP +An externaly supplied argument to a module which directly controls +the functioning of the module. +.SH +pathname +.IP +An absolute OS dependent filename specification, i.e, a filename which +is not an offset from the current directory. +.SH +pixel +.IP +The fundamental unit of storage in an image; a picture element. An image +is an array of pixels. +.SH +pointer +.IP +A pointer is a datum which defines the coordinates of an object in +some logical coordinate system. To use a pointer, one must know what +type of object the pointer points to, and what coordinate system the +pointer references. +.SH +portable +.IP +A program is said to be \fBportable\fR from computer A to computer B +if it can be moved from A to B without change. A program is said +to be \fBtransportable\fR from computer A to computer B if the effort +required to move the program from A to B is much less than the effort +required to write an equivalent program on machine B from scratch. +.SH +preprocessor +.IP +A preprocessor is a program which transforms the text of a source file +prior to compilation. A preprocessor, unlike a compiler, does not fully +define a language. A preprocessor transforms only those constructs which +it understands; all other text is passed on to the compiler without change. +.SH +procedure +.IP +A separately compiled program unit. The procedure is the main construct +provided by languages for the \fIabstraction of function\fR. +The external characteristics of a procedure are its name, argument list, +and optional return value. +.SH +process +.IP +An executable partition of memory in the host computer. +The host OS initiates a process by copying or mapping an executable file +into main memory. +In a multitasking, multiuser system, a number of processes +will in general be simultaneously resident in main memory, +and the processor will execute each in turn, +performing many \fBcontext switches\fR each second with the result that +all processes appear to be executing simultaneously. +.SH +program +.IP +A program is a compiled procedure which is called by the CL, +via the CL interface. +The procedure must be referenced in a \fBtask\fR statement before it +can be accessed by the CL, and must not have any formal arguments. +A program communicates with the CL via CLIO. +An arbitrary number of programs may be linked to form a single \fBprocess\fR. +.SH +program interface +.IP +The interface between an applications program and the outside world. +The program interface is subdivided into a number of \fBpackages\fR, +each of which has a well defined interface of its own. +The specifications of the program interface are summarized in the +program interface \fBcrib sheet\fR. +.SH +record +.IP +A record is data structure consisting of an arbitrary set of fields, +used to pass information between program modules, +or to permanently record the results of an analysis program +in a \fBdatabase\fR. +Often, records are organized into arrays, where each record +contains the results of the analysis of a particular object. +.SH +script task +.IP +An interpreted program written in the command language. A script task, +like a compiled program, may have formal parameters and local variables. +A script task may call another task, including another script task, +but may not call itself. +To the caller, script tasks and compiled programs are equivalent. +.SH +specifications +.IP +A detailed description of a software system or subsystem, +concentrating on the external attributes of the software rather than +the on the implementation. \fBRequirements\fR are similar to specifications, +but are usually more formal and less detailed. The specifications for +a subsystem define the interface to the subsystem, +and when written in an informal style may resemble a reference manual. +.SH +system interface +.IP +The interface between the portable IRAF software and the host operating +system. The system interface is a \fBvirtual operating system\fR. +The system interface routines, maintained in the "OS" package, +are in principle the only part of a system that needs to be changed +when porting the system to a new computer. +.SH +task +.IP +A CL callable program unit. CL tasks may be script tasks, external programs, +or compiled procedures which are built in to the CL. +.SH +task statement +.IP +(1) The \fBtask\fR statement in the SPP language defines a list of programs +to be linked together to form a single process. +(2) The CL \fBtask\fR statement enters the name of a task in the dictionary, +defines the type of task, and in the case of a compiled task, the name of +the process in which it resides. +.SH +text file +.IP +A file which contains only text (character data), and which is maintained +in the form expected by the text processing tools of the host OS. +.SH +unary operator +.IP +An operator which operates on a single operand, i.e., the minus sign in +the expression "\(mix", or the boolean complement operator in the +expression "!x". +.SH +virtual memory +.IP +If the address space of a process exceeds the amount of physical memory +which the process can directly address, the process is using virtual memory. +The virtual address space is organized into a series of fixed size \fBpages\fR. +The amount of physical memory available to a process is known as the +\fBworking set\fR of a process. Pages which are not \fBmemory resident\fR, +i.e., not in the working set, reside on some form of backing store, usually +a disk file. When a page is referenced which is not in the working set, +a \fBpage fault\fR occurs, causing the page to be read into the working set. +If the pattern of memory accesses is such that a page fault occurs on nearly +every access, the process is said to be \fBthrashing\fR, and will run +exceedingly slowly. +.SH +virtual operating system +.IP +A package of system calls, providing a set of primitive functions comparable +to those provided by an actual operating system, which can be interfaced +to a number of actual operating systems. +The IRAF virtual operating system provides routines (the so-called +\fBz-routines\fR) for file access, process initiation and control, +interprocess communication, memory management, +magtape i/o, exception handling, logical names, and time and date. +.SH +whitespace +.IP +A sequence of one or more occurrences of the characters blank or tab. +.SH +z-routines +.IP +Machine dependent routines, used to interface to the host operating +system. The IRAF z-routines are maintained in the package "OS". diff --git a/doc/std_toc.ms b/doc/std_toc.ms new file mode 100644 index 00000000..34b386bd --- /dev/null +++ b/doc/std_toc.ms @@ -0,0 +1,134 @@ +.RP +.ND +.TL +Contents +.PP +Hi there. +.bp +.ce +\fBContents\fR +.sp +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'1.1.\h'|0.9i'Official Acceptance Procedure\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBSystem Standards\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Standard Data Structures\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'Text and Binary Files\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'Parameter Files\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.3.\h'|1.5i'Imagefiles\l'|5.6i.'\0\03 +.br +\h'|1.5i'2.1.3.1.\h'|2.2i'standard nomenclature for images\l'|5.6i.'\0\03 +.br +\h'|1.5i'2.1.3.2.\h'|2.2i'definition of a pixel\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.1.4.\h'|1.5i'Datafiles\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.1.5.\h'|1.5i'List Files\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.1.6.\h'|1.5i'FITS\l'|5.6i.'\0\04 +.br +\h'|0.4i'2.2.\h'|0.9i'Virtual File Names\l'|5.6i.'\0\04 +.br +\h'|0.4i'2.3.\h'|0.9i'Standard Filename Extensions\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.4.\h'|0.9i'One Indexing\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.5.\h'|0.9i'The Procedure Naming Convention for the System Libraries\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.5.1.\h'|1.5i'Orthogonality\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.5.2.\h'|1.5i'Standard package prefixes\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.5.3.\h'|1.5i'Standard type suffixes\l'|5.6i.'\0\08 +.br +\h'|0.4i'2.6.\h'|0.9i'Mapping of External Identifiers\l'|5.6i.'\0\08 +.br +\h'|0.4i'2.7.\h'|0.9i'Conventions for Ordering Argument Lists\l'|5.6i.'\0\09 +.sp +3.\h'|0.4i'\fBCoding Standards\fP\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.1.\h'|0.9i'General Guidelines\l'|5.6i.'\0\010 +.br +\h'|0.9i'3.1.1.\h'|1.5i'Packages and Tasks\l'|5.6i.'\0\010 +.br +\h'|0.9i'3.1.2.\h'|1.5i'Procedures\l'|5.6i.'\0\011 +.br +\h'|0.4i'3.2.\h'|0.9i'Languages\l'|5.6i.'\0\013 +.br +\h'|0.9i'3.2.1.\h'|1.5i'The SPP Language\l'|5.6i.'\0\013 +.br +\h'|0.9i'3.2.2.\h'|1.5i'The Fortran Language\l'|5.6i.'\0\013 +.br +\h'|0.4i'3.3.\h'|0.9i'Standard Interfaces\l'|5.6i.'\0\014 +.br +\h'|0.4i'3.4.\h'|0.9i'Package Organization\l'|5.6i.'\0\015 +.br +\h'|0.4i'3.5.\h'|0.9i'Tasks and Processes\l'|5.6i.'\0\015 +.br +\h'|0.4i'3.6.\h'|0.9i'File Organization\l'|5.6i.'\0\016 +.br +\h'|0.4i'3.7.\h'|0.9i'Header Files\l'|5.6i.'\0\016 +.br +\h'|0.4i'3.8.\h'|0.9i'Comments\l'|5.6i.'\0\017 +.br +\h'|0.4i'3.9.\h'|0.9i'Procedure Declarations\l'|5.6i.'\0\018 +.br +\h'|0.4i'3.10.\h'|0.9i'Statements\l'|5.6i.'\0\019 +.br +\h'|0.9i'3.10.1.\h'|1.5i'Statement Templates\l'|5.6i.'\0\019 +.br +\h'|0.4i'3.11.\h'|0.9i'Expressions\l'|5.6i.'\0\021 +.br +\h'|0.4i'3.12.\h'|0.9i'Constants\l'|5.6i.'\0\022 +.br +\h'|0.4i'3.13.\h'|0.9i'Naming Conventions\l'|5.6i.'\0\022 +.sp +4.\h'|0.4i'\fBPortability Considerations\fP\l'|5.6i.'\0\023 +.br +\h'|0.4i'4.1.\h'|0.9i'keep it simple\l'|5.6i.'\0\023 +.br +\h'|0.4i'4.2.\h'|0.9i'use the standard interfaces\l'|5.6i.'\0\023 +.br +\h'|0.4i'4.3.\h'|0.9i'avoid machine dependent filenames\l'|5.6i.'\0\023 +.br +\h'|0.4i'4.4.\h'|0.9i'isolate those portions of a program which perform i/o\l'|5.6i.'\0\024 +.br +\h'|0.4i'4.5.\h'|0.9i'keep memory requirements to a reasonable level\l'|5.6i.'\0\024 +.br +\h'|0.4i'4.6.\h'|0.9i'make sure argument and function datatypes match\l'|5.6i.'\0\024 +.br +\h'|0.4i'4.7.\h'|0.9i'do not use output arguments as local variables\l'|5.6i.'\0\025 +.br +\h'|0.4i'4.8.\h'|0.9i'avoid assumptions about the machine precision\l'|5.6i.'\0\025 +.br +\h'|0.4i'4.9.\h'|0.9i'do not compare floating point numbers for equality\l'|5.6i.'\0\026 +.br +\h'|0.4i'4.10.\h'|0.9i'use the standard predefined machine constants\l'|5.6i.'\0\026 +.br +\h'|0.4i'4.11.\h'|0.9i'explicitly initialize variables\l'|5.6i.'\0\027 +.br +\h'|0.4i'4.12.\h'|0.9i'beware of functions with side effects\l'|5.6i.'\0\027 +.br +\h'|0.4i'4.13.\h'|0.9i'use of intrinsic functions\l'|5.6i.'\0\028 +.br +\h'|0.4i'4.14.\h'|0.9i'explicitly align objects in global common\l'|5.6i.'\0\028 +.sp +5.\h'|0.4i'\fBSoftware Documentation\fP\l'|5.6i.'\0\028 +.br +\h'|0.4i'5.1.\h'|0.9i'User Documentation\l'|5.6i.'\0\029 +.br +\h'|0.4i'5.2.\h'|0.9i'System Documentation\l'|5.6i.'\0\030 +.br +\h'|0.4i'5.3.\h'|0.9i'Documentation Standards\l'|5.6i.'\0\031 +.br +\h'|0.4i'5.4.\h'|0.9i'Technical Writing\l'|5.6i.'\0\031 +.sp +\fBReferences\fR +.sp +\fBStandard Nomenclature\fR diff --git a/doc/suniraf.hlp b/doc/suniraf.hlp new file mode 100644 index 00000000..821e3d33 --- /dev/null +++ b/doc/suniraf.hlp @@ -0,0 +1,199 @@ +.help install Aug86 "SUN/IRAF Installation Notes" +.sp 3 +.ce +\fBSUN/IRAF Addition to UNIX/IRAF Installation Guide\fR +.ce +(draft) + +.ce +Steve Rooke +.ce +August 19, 1986 + +.nh +Introduction + + This document should be used in conjunction with the \fBUNIX/IRAF +Installation Guide\fR (Doug Tody, March 13, 1986) to install IRAF +on SUN-2 and SUN-3 systems. Since the VAX/UNIX and SUN/UNIX systems are +currently so similar, a separate guide does +not seem warranted. As of June 1986, there are sufficient hardware options +and operating system versions available on SUNs that many SUN installations +will have to recompile the entire system unless they have an identical +machine to one of ours. See Section 2.1 of the \fBInstallation Guide\fR. + +Our normal procedure in our own SUN installations is to unpack an archive of +our master VAX/UNIX system, and then to edit certain files, perform a +bootstrap, inspect the spooled output, and proceed to a full compile and +link sysgen. All files we modify in the IRAF directory system, plus any +external file links, are logged +into a file called \fBnotes\fR in $iraf/local/. +These \fBnotes\fR files are archived in $iraf/doc/ports/ as +"sun[23]_(date).doc". The installer may wish to do the same (keep a +\fBnotes\fR file of modifications to files in the IRAF directory system +in $iraf/local/) for their own information. One reason for doing this +might be to assist the installer in the next upgrade, as a reminder of +which files needed to be modified in $iraf/dev/ and $iraf/unix/hlib/, for +example. + +The SUN distribution tapes were archived from either a SUN/UNIX V2.x or V3.0 +system that already has all the modifications from the VAX/UNIX master +system as documented in "$iraf/doc/ports/sun[23]_062486.doc". Consequently, +the installation consists of the usual steps described in the Guide, with +minor differences relating to SUN f77 compiler bugs. + +In the rest of this addition, we will follow the \fBInstallation Guide\fR +instructions beginning in its section 2.1.1, noting any special steps required +for the SUN. + +.nh +Installing the System + + Since this is our first SUN release, it is quite possible that we will +want to log on to your system at some point to investigate problems. +Consequently, it helps if you retain the IRAF account after the installation, +so that we can use it and have write permission in the IRAF directories. +Note that the full system as of June 1986 requires about 48 Mb on a SUN +rather than the 45 mentioned in the Guide. If the whole system is built +with software floating point, it will take about 50 Mb. + +Note that after unpacking the archive (section 2.1.2), there will be a file +"$iraf/local/notes" from our most recent NOAO SUN/IRAF installation. If +you desire to keep a record of your installation, delete or rename this file +so that you may create your own. If, due to hardware or operating system +version differences, you have to do anything special during the installation, +we would then know exactly where to look later on. + +Follow the instructions in the Guide in sections 2.1.1 through 2.1.4. There +should be no differences for a SUN installation up to section 2.2 of the Guide. + +.nh 2 +Compiling and Linking + + Note the first paragraph in section 2.2 of the Guide. If it is +necessary to bootstrap the system, go to the Guide's section 2.4. Since there +is almost no floating point in the bootstrap utilities, both the SUN-2 and +SUN-3 distributions should bootstrap exactly as in the Guide. Be sure +to inspect the spool file before proceeding. + +Now that you have the bootstrap utilities, you are ready to relink and/or +compile the full IRAF system. Before doing so, it is necessary to inspect +the file $iraf/unix/hlib/mkpkg.inc. This is where you edit in the appropriate +floating point switches for the SUN compiler and linker. If you received +a "you-relink" distribution and you have the identical hardware options as +on the system from which we made the tape (just look at the XFLAGS and +LFLAGS switches in mkpkg.inc), you should be able to relink directly. +Otherwise, you will have to recompile the full system as well with the +different floating-point switches. + +If you are able simply to relink, just follow the instructions in Guide +section 2.2. If you have to recompile, in addition to editing mkpkg.inc, +you will need to pre-compile certain routines to defeat either optimizer +bugs or complex datatype bugs. The routines that need to be +hand-compiled differ depending on whether you are operating SUN/UNIX V2.x or +V3.0. A shell script is provided for pre-compiling these routines. + +Read section 2.3 of the \fBInstallation Guide\fR. If you need to strip +the binary files do so now ("% rmbin ..."). Then follow the instructions +below before completing the steps in Guide section 2.3. + +.nh 3 +SUN/UNIX Fortran Compiler Bugs + + There are two kinds of bugs in the SUN/UNIX V3.0 f77 compiler -- +optimization and complex datatype-compare expressions. The latter problem +has apparently existed in all versions of the f77 compiler since SUN/UNIX V2.0. +SUN/UNIX V2.x systems have their own fortran optimizer bugs. +To work around these bugs, we pre-compile the necessary routines with the +appropriate compiler switches (which are not the ones used during a sysgen). +The object modules so compiled will then be loaded automatically into their +libraries during the sysgen. + +Before carrying out an IRAF sysgen, first execute the shell script +$iraf/unix/hlib/SUN_kludge/precomp.csh. Note that if you +need to strip the binary files, that must be done first, otherwise the +pre-compiled object files will be lost before the sysgen. In the shell +script, the "-f68881" floating point hardware switch is assumed, but replace +it with the correct one for your own system if it is different. + +If you plan on compiling SPP programs outside of the IRAF CL, directly +with the XC compiler rather than through MKPKG, you may wish to define +an alias in your account .login file to pick up the correct floating-point +hardware switch. This can keep you from accidentally forgetting to use +the same switch with which the rest of the IRAF routines were compiled. +(You may subsequently re-execute precomp.csh safely, because it un-aliases +xc). If you use MKPKG, either from the CL or from UNIX, it +will use by default the XFLAGS and LFLAGS switches in +$iraf/unix/hlib/mkpkg.inc. + +.nf + alias xc '$hlib/xc.e -f68881' + +.fi + +You are now ready to perform the sysgen, i.e. continue on in section +2.3 of the Guide with the "% mkpkg >& spool &" step. + +.nh +Interactive Graphics on the SUN + + Our SunCGI vector graphics kernel is not yet ready for the SUN, +due to problems integrating IRAF into the window system. That leaves +two ways to use IRAF graphics utilities until we distribute a graphics +upgrade, hopefully later in the summer. + +.nh 2 +Separate Graphics Terminal + + The most effective way to use IRAF graphics at present is not to +use the SUN monitor at all, but rather to use one of the many supported +graphics terminals attached to a SUN, either hardwired or through a +local network. In this case the relevant sections of the \fBInstallation +Guide\fR apply directly. + +.nh 2 +Tektool Window + + If it is not possible to attach a graphics terminal to your SUN, you +will have to resort to a Tektool Window. This Suntools Tektronix 4014 +terminal emulator will allow you to do limited graphics applications work, +but it has several problems. The most obvious is that nothing can be +erased without redrawing the whole window -- which, however, is quite fast on a +SUN-3. However, testing shows that it has some bugs -- data points are +sometimes +drawn outside of the axis borders and occasional vectors go astray. +We note that simply dumping a binary file with correct Tek 4014 instructions +in it reproduces the same bugs, so we believe the problem is in the Tektool +emulator. We do not recommend using a Tektool +Window at present, and if you must do so, be aware that there are known +bugs. + +Tektool must be invoked with the command-line switch "-s gc" or else you +will not be able to read the cursor. Once in the CL, you must tell the +IRAF graphics system you are using a Tek 4014 terminal. The following +steps will suffice: + +.nf + % suntools + % tektool -s gc + % cl + cl> set terminal = 4014 + cl> set stdgraph = 4014 + +.fi + +The "set" commands, of course, may be edited into your "login.cl" file +if you expect to use the SUN monitor as your default terminal. + +.nh +Conclusion + + Our SUN experience is only with SUN-2's running SUN/UNIX V2.0 with +software floating point and SUN-3's running V3.0 with the MC68881 floating +point board. In each case we experienced minor problems with the Fortran +optimizer or complex-compare operations, some of which were compile-time +and some run-time problems. If you compile with different floating-point +switches you may encounter new bugs at compile-time (easy to detect) or +run-time (harder). Feel free to contact us for advice if you have any +difficulties. Contacts are listed in the IRAF Newsletter. +.endhelp diff --git a/doc/suniraf.ms b/doc/suniraf.ms new file mode 100644 index 00000000..c7cf2462 --- /dev/null +++ b/doc/suniraf.ms @@ -0,0 +1,692 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +Sun/IRAF Installation Guide +.AU +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +June 1989 +.br +Revised July 1992 + +.AB +This document describes how to install IRAF on a Sun workstation or server, +or update an existing installation. Both standalone and networked, multiple +architecture configurations are described. Only those issues which one must +understand to install Sun/IRAF are discussed here; a companion document, +\fISun/IRAF Site Manager's Guide\fR, deals with other issues such as +interfacing new devices, configuring the IRAF networking system, Sun/IRAF +shared libraries, adding layered software, and so on. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling Sun/IRAF\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Install the files\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Installing from a network distribution\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing from tape\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Configuring the BIN directories\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.2.4.\h'|1.5i'Deleting unused HSI binaries\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.3.\h'|0.9i'Merge local revisions back into the new system\l'|5.6i.'\0\07 +.br +\h'|0.4i'2.4.\h'|0.9i'Run the INSTALL Script\l'|5.6i.'\0\07 +.sp +3.\h'|0.4i'\fBSystem Checkout\fP\l'|5.6i.'\0\08 +.sp +\fBAppendix A.\0A Complete Example\fP\l'|5.6i.'\0\10 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Before installing Sun/IRAF, one must 1) obtain an appropriate Sun/IRAF +distribution, e.g., from the IRAF network archive on \f(CWiraf.noao.edu\fR +(or by ordering a tape distribution from NOAO), 2) select the server or node +on which the system is to be installed and arrange for sufficient disk space +to hold the system, and 3) set aside sufficient time to do the +installation. If these directions are followed carefully and mistakes are +avoided the basic installation should only take a half hour or so. +Additional time may be required to customize the system to configure the +local tape drives and other devices, set up IRAF networking, and so on. +.PP +At the present time there are two distributions of Sun/IRAF, +representing the range of systems currently marketed by Sun, all of which +are supported by the IRAF project. These are the following: +.RS +.IP \(bu +All Sun-3 and Sun-4 workstations running SunOS-4 +.IP \(bu +The 386i (Roadrunner), running SunOS-4 +.RE +.PP +V2.10 Sun/IRAF supports SunOS versions 4.0.3 through 4.1.2 (the current +release as of July 1992). Solaris 2.0, due out in 1993, is not currently +supported. V2.10 will be the last IRAF release supporting the 386i since +this machine is obsolete and is no longer being supported by Sun. Sun +is also dropping support for the Sun-3 machines, however IRAF will continue +to support these as long as their use remains widespread (we encourage +everyone to upgrade these machines to sparcstations). +.PP +The amount of disk space required to install IRAF depends upon the system +configuration, primarily the number of architectures one needs to support +(sparc, 386i, f68881 and ffpa (Sun-3), and so on. The main system, +including both the core system and NOAO package sources, requires about 47 +Mb, less if stripped after installation. Each core system binary requires +about 15-17 Mb and each NOAO package binary requires about 12 Mb (assuming +OS-4 and shared libraries). The actual numbers will vary slightly depending +upon the architecture. + +.NH +Installing Sun/IRAF +.PP +Although the details of how Sun/IRAF is installed or updated depend upon the +type of distribution and the desired local system configuration, the basic +procedure is always the same. First one obtains the distribution files, +then one follows the procedure outlined below to install the system. Most +of these steps should be performed while logged in as IRAF; superuser +permission is required in the final stages of the installation, to run the +\fIinstall\fP script. +.PP +System managers familiar with the installation of typical UNIX programs +should beware that IRAF, being a large system in its own right and not a +UNIX program, does not always follow to the usual conventions. It is wise +to read and adhere to the installation instructions to avoid problems. +.XS +\fR# Prepare the root IRAF directory.\fP +if new installation + create iraf account +else if updating an old installation + save locally modified files; delete old system + +\fR# Install the files.\fP +login as iraf +unpack the core system distribution +configure the BIN directories + +\fR# Merge local revisions into new system.\fP +if updating an old installation + merge locally modified files back into new system + +run the iraf install script to complete the installation +checkout the new system +.XE +.PP +If problems should arise during the installation help is available via the +IRAF HOTLINE (602-323-4160), or by sending email to \f(CWiraf@noao.edu\fP. + +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation then you will be replacing +IRAF by the new version, and IRAF should already have an account and root +directory on the desired host system. You should save any locally modified +files and delete the old system, e.g., login as IRAF and enter something +like the following. +.XS +% cd $iraf\(dg +% tar -cf /scr0/oiraf.tar local dev unix/hlib +% /bin/rm -rf * +.XE +.FS +\(dg\0\(CW$iraf\fP symbolizes the UNIX pathname of the root IRAF directory. +If no "iraf" environment variable is defined just supply the actual pathname. +.FE +.PP +There are many possible variations on this, e.g., you could use \fImv\fR to +move the above directories to someplace outside the main IRAF directory +tree. Although it is probably simplest and safest to save entire +directories as in the example, in practice only a few files are likely to +have been modified. These are the following. +.XS +dev/graphcap +dev/hosts +dev/tapecap +dev/termcap +hlib/extern.pkg +hlib/login.cl +hlib/zzsetenv.def +local/.login +.XE +.PP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. It is important to delete the old system first to +avoid creating junk files or directories when the new system is installed +(due to file or directory name changes or deletions). Once the new system +has been restored to disk, do \fInot\fR merely restore the files saved above, +as you will need to carefully merge local changes into the versions of the +files supplied with the new IRAF release (more on this later). +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set +up a new account for the user `\f(CWiraf\fP'. This is necessary for IRAF +system management, which should always be done from the IRAF account. The +IRAF account has special login files which set up a custom UNIX environment +for IRAF system management. Having an IRAF account provides a convenient +place (the IRAF system manager's login directory) to keep scratch files +created during system configuration. +.PP +The location of the IRAF root directory is arbitrary. Our practice here is +to locate the software in a system file storage area separate from the SunOS +files (to simplify SunOS upgrades), and then use a symbolic link such as +/iraf or /usr/iraf to point to the actual root directory. This makes life +simpler if IRAF is NFS mounted on several machines and it is later necessary +to move the IRAF files. Try to keep the path to the physical IRAF root +directory short to avoid filename truncation problems when IRAF is run. +.PP +The login directory for the iraf account should be $iraf/local (e.g., +/iraf/iraf/local), rather than the IRAF root directory $iraf as one might +expect. This is done to provide a work area for local files separate from +the main IRAF directory tree, to simplify updates and make it easier to keep +track of what has been locally added and what is standard IRAF. In any +case, make sure that when the IRAF account is set up the login directory is +set correctly, or the IRAF environment will not be set up properly, and +later problems are sure to result. +.PP +A typical IRAF installation consists of the main IRAF release, a number of +BIN directories (the IRAF binaries), and additional directories for layered +software such as STSDAS, PROS, and so on. If sufficient disk space is +available to keep everything in one area the following directory structure +is recommended. +.XS +/iraf/iraf \fR# iraf root directory ($iraf)\fP +/iraf/iraf/local \fR# iraf login directory (~iraf)\fP +/iraf/irafbin \fR# iraf BIN directories\fP +/iraf/irafbin/bin.sparc \fR# sparc binaries iraf core system\fP +/iraf/irafbin/bin.f68881 \fR# f68881 binaries iraf core system\fP +/iraf/stsdas \fR# layered package\fP +/iraf/xray \fR# layered package\fP + \fI(etc.)\fP +.XE +.PP +For the purpose of this example we assume that the IRAF files are stored in +/iraf; as we say this might be a link and the actual directory is +arbitrary. Given this directory the IRAF root $iraf would be "/iraf/iraf/" +and the login directory for the IRAF account would be /iraf/iraf/local. The +sparc binaries for the core IRAF system would be in /iraf/irafbin/bin.sparc, +with a link $iraf/bin.sparc pointing to this directory (more on this +later). +.PP +Given the above directory structure the \f(CWpasswd\fR file entry for the +IRAF account would be something like the following. +.XS +iraf:##iraf:312:12:IRAF system login:/iraf/iraf/local:/bin/csh +.XE +.PP +On 386i systems Sun recommends placing exportable layered products such as +IRAF in the 386i-specific directory /files/vol. Hence the recommended +root directory for IRAF on the 386i is /files/vol/iraf. Due to the +mandatory yellow pages feature of the 386i, the easiest and most reliable +way to create a new user account is with SNAP. If SNAP is used to create +the IRAF account the home directory will be set to /home/iraf. +.PP +To create the iraf root and login directories on a 386i (and only on a 386i) +and make them the default for the iraf account, do the following as root: +.XS +# rm -rf /home/iraf +# mkdir /files/vol/iraf /files/vol/iraf/local +# /etc/chown -R iraf /files/vol/iraf +# ln -s /files/vol/iraf/local /home/iraf +.XE +.PP +Do not worry about configuring the environment files for the new account as +these will be created when the iraf system is later restored to disk. + +.NH 2 +Install the files +.PP +If you are installing from tape skip forward to \(sc2.2.2. If you are +installing from a network distribution (i.e., from disk) continue with the +next section. +.NH 3 +Installing from a network distribution +.PP +Sun/IRAF is available over the network via anonymous ftp from the node +\f(CWiraf.noao.edu\fR, in the subdirectory \f(CWiraf/v\fInnn\fP/SOS4\fR, +where "\f(CWv\fInnn\fR" is the IRAF version number, e.g., subdirectory +\f(CWiraf/v210/SOS4\fR for V2.10 Sun/IRAF. +.PP +If IRAF is being installed from a network distribution all the architecture +independent IRAF files for both the core IRAF system and the NOAO packages +will be in the distribution file \f(CWas.sos4.gen\fR. This "file" is stored +in the network archive as a directory wherein the large distribution file +has been split into a number of smaller pieces, e.g., +.XS +% ls as.sos4.gen +CHECKSUMS as.sos4.gen.Z.12 as.sos4.gen.Z.26 +FILES.Z as.sos4.gen.Z.13 as.sos4.gen.Z.27 +as.sos4.gen.Z.00 as.sos4.gen.Z.14 as.sos4.gen.Z.28 +as.sos4.gen.Z.01 as.sos4.gen.Z.15 as.sos4.gen.Z.29 +as.sos4.gen.Z.02 as.sos4.gen.Z.16 as.sos4.gen.Z.30 +as.sos4.gen.Z.03 as.sos4.gen.Z.17 as.sos4.gen.Z.31 + \fI(etc.)\fP +.XE +.LP +Assume that the directory \f(CWas.sos4.gen\fR as shown above has been +recreated somewhere on the machine on which IRAF is to be installed. +We can restore the main IRAF source tree as follows. +.XS +% whoami +iraf +% cd $iraf +% cat /\fIpath\fP/as.sos4.gen/as.* | uncompress | tar -xpf - +.XE +After the above finishes the root IRAF directory should appears as follows +(this is for V2.10). +.XS +HS.SOS4.GEN bin.ffpa doc mkpkg tags +IS.PORT.GEN bin.generic lib noao unix +bin bin.sparc local pkg +bin.f68881 dev math sys +.XE +The files \f(CWbin.f68881, bin.sparc,\fR etc. are links to the IRAF BIN +directories (for binary executables), which probably do not exist yet. +Configuring the BIN directories is discussed in section \(sc2.2.3. +.NH 3 +Installing from tape +.PP +If you have not already done so, log into the IRAF account so that the files +when restored will belong to IRAF. Mount the distribution tape, which may +be a cartridge tape, a 6250 bpi 9 track tape, a DAT tape, an Exabyte, or +whatever. +.PP +IRAF distribution tapes consist of multiple files separated by tape marks, +with a TOC (table of contents) file as the first file on the tape. To find +out what is on the tape, rewind it and read out the TOC file as follows (the +actual device name will likely be different than that shown in the examples). +.XS +% mt -f /dev/nrst0 rew; cat /dev/nrst0 +.XE +This should cause a TOC file to be listed similar to the following, except +for the file names which will vary depending upon what type of distribution +you have (also the file sizes are now somewhat larger than what is shown). +The example below is for a distribution of Sun/IRAF for SunOS-4, with the +f68881, ffpa, and sparc binaries. +.XS +0 Table of Contents + +1 AS.SOS4.GEN 36.2Mb IRAF, NOAO packages and Sun/OS sources +2 IB.SOS4.F68 8.5Mb f68881 binaries for IRAF system +3 IB.SOS4.FPA 9.1Mb ffpa binaries for IRAF system +4 IB.SOS4.SPC 11.3Mb sparc binaries for IRAF system +5 NB.SOS4.F68 6.9Mb f68881 binaries for NOAO packages +6 NB.SOS4.FPA 7.4Mb ffpa binaries for NOAO packages +7 NB.SOS4.SPC 8.7Mb sparc binaries for NOAO packages +.XE +.PP +Here, the first column is the file number on the tape, the TOC file being +file zero (the first distribution file is numer one), the second column is +the name of the tape file, the third column is the file size in megabytes +(this tells you how much space will be needed to unpack the file on disk), +and the last column is a description of the file contents. +.PP +There are three types of tape files in the example shown: the \f(CWAS\fR +file, which is all the IRAF sources (the core IRAF system, NOAO packages, +and the SunOS host system interface), the \f(CWIB\fR files, or IRAF core +system binaries, one for each architecture, and the \f(CWNB\fR files, or +NOAO package binaries. The NOAO package sources are included in the +\f(CWAS\fR file since most people requesting IRAF are expected to want the +astronomical reduction software, although IRAF can be configured without +this if desired. All of the file objects are UNIX \fItar\fR format files, +with the exception of the TOC file which is a simple text file. The +distribution files may be compressed if this was necessary to fit all the +files on a tape. +.PP +In the above example, the \f(CWSOS4\fR in the file names indicates that +these files are for SunOS version 4. A SunOS version 3 distribution is +indicated by a \f(CWSOS3\fR in the file names, and a 386i distribution is +indicated by a \f(CWS386\fP. In principle a given distribution tape may +contain any combination of these files. +.PP +The following commands would suffice to restore the main IRAF system to +disk, given the distribution tape described by the TOC file in our example +above. Once again, the tape device file and block size shown in the example +will very likely have to be changed to whatever is needed for the tape +device being used (the example is for a cartridge drive). +.XS +% whoami +iraf +% cd $iraf +% mt -f /dev/nrst0 rew; mt -f /dev/nrst0 fsf 1 +% tar -xpbf 126 /dev/nrst0 +.XE +.PP +After the above tar file read operation, the tape is left positioned to +\fIjust before the EOF of the file just read\fR, since \fItar\fP stops +reading the file data before reading the physical EOF. Hence, an +\fImt\0fsf\fR will be required to position to the next file on the tape. +Any combination of \fIfsf\fP (forward skip file) or \fIbsf\fR (backward skip +file) operations may be used to position to a file on a 9 track tape. On a +cartridge tape, it is best to plan things so that only forward file skips +are used, using a rewind and forward skip if it is necessary to position to +an earlier file on the tape. +.PP +Once the main system, containing only sources, is installed it is possible to +create one or more empty BIN directories for the executables, then compile +and link the full system. More commonly one will merely read the precompiled +executables off the distribution tape, as we discuss in the next section. +.NH 3 +Configuring the BIN directories +.PP +In IRAF all the files specific to any particular architecture, e.g., sparc +(Sun-4 or sparcstation) or f68881 (Sun-3, mc68020 based) are contained in +a single directory called the BIN, or "binary", directory. To run IRAF +you must install not only the \f(CWAS\fR (all-sources) directory tree, but +the BIN directory for each architecture. The IRAF core system and the +NOAO packages have separate BIN directories. +.PP +The BIN directories for the IRAF core system or a layered package (such as +NOAO) are located, logically or physically, in the root directory of the +IRAF core system or layered package. Every layered package has its own set +of BIN directories. In the distributed V2.10 system you will find the +following BIN files (directories or symbolic links) at the IRAF root. +.XS +link bin -> bin.generic +directory bin.generic +link bin.sparc -> ../irafbin/bin.sparc +link bin.f68881 -> ../irafbin/bin.f68881 +link bin.ffpa -> ../irafbin/bin.ffpa +.XE +.PP +If the IRAF directory structure is set up as described in \(sc2.1.2, with +$iraf located at iraf/iraf and the BIN directories stored in iraf/irafbin, +then these links will not have to be modified. If a different directory +structure is used you will have to modify the links accordingly. +.PP +The \fIbin\fR link and the \fIbin.generic\fR directory are required for the +correct operation of the IRAF system software (\fImkpkg\fR) and are +maintained automatically by the IRAF software management utilities. +\fIUnder no circumstances should "bin" or "bin.generic" be modified or +deleted\fR. It is a very common error to manually delete the bin link and +manually set it to bin.sparc or some other architecture. The links +bin.sparc, bin.ffpa, and bin.f68881 can be modified as desired but bin and +bin.generic should be left alone. +.PP +Assume that the bin.sparc directory has been created somewhere (e.g. in the +iraf/irafbin directory) and that the \f(CWib.sos4.spc\fR distribution files +for the core IRAF system sparc binaries have been downloaded from the +network archive. We can restore the sparc binaries with the following +commands. +.XS +% cd $iraf/bin.sparc +% cat /\fIpath\fP/ib.sos4.spc/ib.* | uncompress | tar -xpf - +.XE +Similarly, to restore the NOAO package sparc binaries: +.XS +% cd $iraf/noao/bin.sparc +% cat /\fIpath\fP/nb.sos4.spc/nb.* | uncompress | tar -xpf - +.XE +This process is repeated for each architecture. For example, a central +IRAF distribution installed on a server machine with both Sun-3 and Sun-4 +clients might well require the sparc, f68881, and ffpa architectures, or +six BIN directories in all. +.PP +The procedure for restoring a BIN directory from a tape distribution is +similar to that described in \(sc2.2.2 for the core system. For example, +.XS +% cd $iraf/bin.sparc +% mt -f /dev/nrst0 rew; mt -f /dev/nrst0 fsf 4 +% tar -xpbf 126 /dev/nrst0 +.XE +would restore the core system bin.sparc directory from a cartridge tape +containing an uncompressed \f(CWib.sos4.spc\fR as file 4 on the tape. +.NH 3 +Deleting unused HSI binaries +.PP +Unlike the main IRAF system and external packages like NOAO, the host system +interface (HSI) comes with its binaries pre-installed. The \f(CWS386\fP +(Sun 386i) HSI comes with only a single set of HSI binaries which you will +surely need if you are installing on a 386i. The \f(CWSOS4\fP (SunOS-4) +HSI, on the other hand, comes with pre-installed sparc and mc68020 (Sun-3) +HSI binaries. These binaries are stored in the bin.sparc and bin.mc68020 +subdirectories in $iraf/unix. +.PP +If you will not be needing either of these HSI BINs (because you don't have +both Sun-3 and Sun-4 clients) you may wish to delete the contents of one or +the other of these directories to save disk space. For example, if IRAF is +installed on a standalone Sun-4 system only the binaries in bin.sparc will +be needed, and the contents of $iraf/unix/bin.mc68020 can be deleted. + +.NH 2 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure to not replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF.\(dg +.FS +\(dgThe UNIX utility \fIdiff\fP is useful for comparing files to see +what has changed. +.FE +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each +site to maintain their own custom LOCAL package external to the core IRAF +system. The core system LOCAL is now only a \fItemplate-local\fR to be +copied and used as the starting point for a custom LOCAL layered package. +The layered software enhancements, and the procedure for building a custom +LOCAL, are discussed further in the \fISun/IRAF Site Manager's Guide\fR. + +.NH 2 +Run the INSTALL Script +.PP +Once all of the IRAF files have been restored to disk the Sun/IRAF installation +script must be run to complete the system installation. The install script +modifies the system as necessary to reflect the new root directory and new +default image storage and local bin directories, checks the mode and ownership +of a number of files, installs a small set of IRAF commands in UNIX, and so on. +.LP +To make a trial run of the install script, enter the following commands: +.XS +% setenv iraf /\fIpath\fP/iraf/ +% cd $iraf/unix/hlib +% source irafuser.csh +% ./install -n +.XE +and answer the questions (don't forget the trailing `/' in the "setenv +iraf"). The "-n" argument tells install to go through the motions without +actually doing anything, so that one can see what will be done before +committing to it. +.PP +Installing IRAF requires a few changes to be made to system directories +outside the IRAF directory tree. Two fifo device entries are made in /dev. +A symbolic link "iraf.h" is created in /usr/include. A number of links (cl, +mkiraf, etc.) are made in /usr/local/bin or some similar directory which +most users can be expected to have in their search path. The tape +allocation task alloc.e is made suid root (there are no known security +loopholes, although we cannot make any guarantees). A symbolic link +imtoolrc is created in /usr/local/lib. If installing the SunView support, +the gterm and imtool executables are copied into /usr/bin. +.PP +Following one or more trial "no execute" ("-n") runs to see what the install +script will do, the install script should be run without the "-n" to +complete the installation. This must be done by the superuser as superuser +permission is required to carry out the necessary additions to UNIX. +.PP +It is necessary to run the install script separately on each node from which +IRAF will be used. If a single version of IRAF is installed on a server and +NFS mounted on one or more clients, the install script must be run first on +the server and then on \fIeach\fR client (when installing on a client there +will be warnings about insufficient permission to make changes to files on +the NFS mounted partitions, which can be ignored). To install IRAF on a +diskless client it may be necessary to run the install script \fIon the +server\fR to do the install for the client, since the client's /usr/include +and /dev directories may only be writable by root on the server. On some +systems /usr is mounted read-only, and must be unmounted and remounted +read-write before doing the installation to allow an entry to be made in +/usr/include. Once the installation is complete the default mount access +mode may be restored. +.PP +The exchange with the install script will be along the lines of the +following (this example is for a sparc server): +.XS +% ./install -n +new iraf root directory (/iraf/iraf): +default root image storage directory (/d0/iraf): +local unix commands directory (/usr/local/bin): +install iraf for machine type sparc +old iraf root = /usr/iraf, old imdir = /d0/iraf +installing iraf at /iraf/iraf, imdir=/d0/iraf, lbindir=/usr/local/bin +proceed with installation? (yes): +.XE +.LP +The "iraf root directory" is the value of $iraf (minus the trailing `/'in +this case). The "root image storage directory" is the default place to put +image data for users; the program may prompt with /tmp if it cannot find any +likely looking data storage areas on your system, but /tmp is not a good +place to put image data as the contents are deleted whenever the system +reboots. The value entered should be the path to a public iraf subdirectory +of a designated data or scratch disk on your system. Lastly, the "local +unix command directory" is where the UNIX callable IRAF startup commands +will be defined. This should be a UNIX directory which is in the default +path of anyone who might want to use IRAF; /usr/local/bin is the most common +value. +.PP +After answering with "yes" or hitting return in response to the "proceed with +installation" query, the script will issue a series of messages as it checks +the system and performs the installation, possibly answering additional +questions in the process. + +.NH +System Checkout +.PP +The basic IRAF system should be usable once the files have been restored to +disk, the binaries have been configured or generated, and the install script +has been run. To verify that the basic system comes up and runs +successfully, login as iraf and startup the CL (IRAF command language) from +the iraf account. You should be able to login as IRAF and type "cl" to +start IRAF, using the login files which come with the distributed system. +.XS +% login iraf +% cl +.XE +.LP +To more thoroughly test the installation it is a good idea to test IRAF from +a user account. To do this you login to a user account and run the +\fImkiraf\fR task to set up the IRAF login files. This will create or +initialize the user's \f(CWuparm\fP (user parameter) directory, and create a +new \f(CWlogin.cl\fP file. It may also be desirable to edit the +user's \f(CW.login\fP file to modify the way the environment variable +\f(CWIRAFARCH\fP is defined. This variable, required for software +development but optional for merely using IRAF, must be set to the name of +the desired machine architecture, e.g., sparc, f68881, etc. +.XS +% mkiraf +Initialize uparm? (y|n): y +Terminal types: xterm,gterm,vt640,vt100,etc." +Enter terminal type: gterm +A new LOGIN.CL file has been created in the current directory. +You may wish to review and edit this file to change the defaults. +.XE +The \fIcl\fR command should now start up the CL, which will clear the screen +and print out a startup message. The standard test procedure included in +Volume 1A of the \fIIRAF User Handbook\fP should be run to verify the +installation. + +.bp +.SH +Appendix A. A Complete Example +.PP +Assume we are installing IRAF for the first time on a sparcstation. The +IRAF directories will be located at /u3/iraf using a symbolic link /iraf to +point to this location. We will configure only the sparc binaries, locating +the BIN directories in the directory /iraf/irafbin. The local user commands +will be placed in /usr/local/bin. We will be installing from a network +distribution with the distribution files located in /scr0. +.PP +The first step is for the superuser to create an account for the fictitious +user `\f(CWiraf\fP', with home directory /iraf/iraf/local and shell +/bin/csh. The /u3/iraf directory is created owned by IRAF, and pointed to +by the link /iraf. We then login as IRAF (a warning message will be printed +since there is no login directory) and proceed as follows. +.XS +% whoami +iraf +% +% setenv iraf /iraf/iraf/ \fR# set root directory\fP +% mkdir /iraf/iraf +% +% cd $iraf \fR# unpack main IRAF distribution\fP +% cat /scr0/as.sos4.gen/as.* | uncompress | tar -xpf - +% +% cd /iraf \fR# create BIN directories\fP +% mkdir irafbin +% mkdir irafbin/bin.sparc +% mkdir irafbin/noao.bin.sparc +% +% cd $iraf/bin.sparc \fR# unpack core bin.sparc\fP +% cat /scr0/ib.sos4.spc/ib.* | uncompress | tar -xpf - +% +% cd $iraf/noao/bin.sparc \fR# unpack NOAO bin.sparc\fP +% cat /scr0/nb.sos4.spc/nb.* | uncompress | tar -xpf - +% +% cd $iraf/unix/hlib \fR# run the INSTALL script\fP +% source irafuser.csh +% ./install -n +% su +# ./install +# exit +% +% cd +% source .login \fR# read new .login\fP +% rehash \fR# pick up new iraf commands\fP +% cl \fR# verify that the CL runs\fP +.XE +.LP +This will fully install IRAF on a server or a standalone system. If this +version of IRAF will be accessed via NFS by client nodes then the IRAF +install script must be run on each client node as well. Installing IRAF +does not allow one to access local tape drives, printers, and so on. +Refer to the \fISun/IRAF Site Manager's Guide\fR for information on how +to configure IRAF for the local site. diff --git a/doc/sunsmg.ms b/doc/sunsmg.ms new file mode 100644 index 00000000..13d0a119 --- /dev/null +++ b/doc/sunsmg.ms @@ -0,0 +1,1606 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +Sun/IRAF Site Manager's Guide +.AU +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +June 1989 +.br +Revised July 1992 + +.AB +An IRAF \fIsite manager\fR is anyone who is responsible for installing and +maintaining IRAF at a site. This document describes a variety of site +management activities, including configuring the device and environment +tables to provide reasonable defaults for the local site, adding interfaces +for new devices, configuring and using IRAF networking, the installation +and maintenance of layered software products (external packages), +and configuring a custom site LOCAL package so that local software may be +added to the system. Background information on multiple architecture +support, shared library support, and the software management tools provided +with the system is presented. The procedures for rebooting IRAF and +performing a sysgen are described. An introduction to graphics and image +display on the Sun workstation is provided. The host system resources +required to run IRAF are discussed. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBSystem Setup\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Installing the System\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'Configuring the Device and Environment Tables\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Environment definitions\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.2.2.\h'|1.5i'The template LOGIN.CL\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.3.\h'|1.5i'The TAPECAP file\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.4.\h'|1.5i'The DEVICES.HLP file\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.5.\h'|1.5i'The TERMCAP file\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.6.\h'|1.5i'The GRAPHCAP file\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.7.\h'|1.5i'Configuring IRAF networking\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.8.\h'|1.5i'Configuring the IRAF account\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.2.9.\h'|1.5i'Configuring user accounts for IRAF\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.3.\h'|0.9i'Tuning Considerations\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.3.2.\h'|1.5i'Stripping the system to reduce disk usage\l'|5.6i.'\0\06 +.sp +3.\h'|0.4i'\fBSoftware Management\fP\l'|5.6i.'\0\07 +.br +\h'|0.4i'3.1.\h'|0.9i'Multiple architecture support\l'|5.6i.'\0\07 +.br +\h'|0.4i'3.2.\h'|0.9i'Shared libraries\l'|5.6i.'\0\08 +.br +\h'|0.4i'3.3.\h'|0.9i'Layered software support\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.4.\h'|0.9i'Software management tools\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.5.\h'|0.9i'Modifying and updating a package\l'|5.6i.'\0\10 +.br +\h'|0.4i'3.6.\h'|0.9i'Installing and maintaining layered software\l'|5.6i.'\0\12 +.br +\h'|0.4i'3.7.\h'|0.9i'Configuring a custom LOCAL package\l'|5.6i.'\0\13 +.br +\h'|0.4i'3.8.\h'|0.9i'Updating the full IRAF system\l'|5.6i.'\0\13 +.br +\h'|0.9i'3.8.1.\h'|1.5i'The BOOTSTRAP\l'|5.6i.'\0\13 +.br +\h'|0.9i'3.8.2.\h'|1.5i'The SYSGEN\l'|5.6i.'\0\14 +.br +\h'|0.9i'3.8.3.\h'|1.5i'Localized software changes\l'|5.6i.'\0\15 +.sp +4.\h'|0.4i'\fBGraphics and Image Display under SunView\fP\l'|5.6i.'\0\16 +.br +\h'|0.4i'4.1.\h'|0.9i'The SunView environment\l'|5.6i.'\0\16 +.br +\h'|0.4i'4.2.\h'|0.9i'Vector graphics capabilities\l'|5.6i.'\0\17 +.br +\h'|0.4i'4.3.\h'|0.9i'Image Display capabilities\l'|5.6i.'\0\17 +.br +\h'|0.4i'4.4.\h'|0.9i'Using the workstation with a remote compute server\l'|5.6i.'\0\18 +.sp +5.\h'|0.4i'\fBInterfacing New Graphics Devices\fP\l'|5.6i.'\0\19 +.br +\h'|0.4i'5.1.\h'|0.9i'Graphics terminals\l'|5.6i.'\0\19 +.br +\h'|0.4i'5.2.\h'|0.9i'Graphics plotters\l'|5.6i.'\0\19 +.br +\h'|0.4i'5.3.\h'|0.9i'Image display devices\l'|5.6i.'\0\20 +.sp +6.\h'|0.4i'\fBHost System Requirements\fP\l'|5.6i.'\0\20 +.br +\h'|0.4i'6.1.\h'|0.9i'Memory requirements\l'|5.6i.'\0\20 +.br +\h'|0.4i'6.2.\h'|0.9i'Disk requirements\l'|5.6i.'\0\20 +.br +\h'|0.4i'6.3.\h'|0.9i'Diskless nodes\l'|5.6i.'\0\20 +.sp +\fBAppendix A.\0The IRAF Directory Structure\fP\l'|5.6i.'\0\21 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Once the IRAF system has been installed it will run, but there remain many +things one might want to do to tailor the system to the local site. +Examples of the kinds of customizations one might want to make are the +following. +.RS +.IP \(bu +Edit the default IRAF environment definitions to provide reasonable +defaults for your site. +.IP \(bu +Make entries in the device descriptor tables for the devices in use at +your site. +.IP \(bu +Code and install new device interfaces. +.IP \(bu +Enable and configure IRAF networking, e.g., to permit remote image +display, tape drive, or file access. +.IP \(bu +Perform various optimizations, e.g., stripping the system to reduce disk +usage. +.IP \(bu +Extend the system by installing layered software products. +.IP \(bu +Configure a custom LOCAL package so that locally developed software +may be installed in the system. +.RE +.PP +This document provides sufficient background information and instructions to +guide the IRAF site manager in performing such customizations. Additional +help is available via the IRAF HOTLINE (602 323-4160), or by sending mail to +\f(CWiraf@noao.edu\fR (internet) or \f(CW5355::iraf\fP (SPAN). +Contributions of interfaces developed for new devices, or any other software +of general interest, are always welcome. +.PP +The IRAF software is organized in a way which attempts to isolate, so far as +possible, the files or directories which must be modified to tailor the +system for the local site. Most or all changes should affect only files in +the local, dev, and hlib (unix/hlib) directories. Layered software +products, including locally added software, reside outside of the IRAF core +system directory tree and are maintained independently of the core system. +.PP +A summary of all modifications made to the IRAF system for a given IRAF +release is given in the \fIRevisions Summary\fR distributed with the +system. Additional information will be found in the system notes files +(notes.v29, notes.v210, etc.) in the iraf/local and iraf/doc directories. +This is the primary source of technical documentation for each release and +should be consulted if questions arise regarding any of the system level +features added in a new release of the core system. + +.bp +.NH +System Setup +.NH 2 +Installing the System +.PP +The procedure for installing or updating Sun/IRAF is documented in the +\fISun/IRAF Installation Guide\fR. In short, an IRAF tape or network +distribution is obtained and installed according to the instructions. +The result is a full IRAF system, including both sources and executable +binaries for the architectures to be supported. The system will +have been modified to reflect the new IRAF root directory and should run, +but will otherwise be a generic IRAF distribution. To get the most out +of an IRAF installation it will be necessary to perform some of the +additional steps outlined in the remainder of this document. + +.NH 2 +Configuring the Device and Environment Tables +.PP +Teaching IRAF about the devices, network nodes, external programs, +and other special resources available at a site is largely a matter of +editing a standard set of device descriptor and environment setup files, +all of which are simple text files. +The versions of these files provided with the distribution are simply +those in use on the NOAO system from which the tapes were made, +at the time the tapes were generated. +Hence while these files may be useful as examples of properly +configured descriptor files, the defaults, and many specific device entries, +will in many cases be meaningless for a different site. This is harmless +but it may be confusing to the user if, for example, the default printer +doesn't exist at your site. +.PP +The device and environment files also contain much material which any site +will need, however, so care must be taken when editing the files. Important +changes may be made to the global portions of these files as part of any +IRAF release. To facilitate future updates, it is wise where possible to +isolate any local changes or additions so that they may be copied into the +new (distributed) version of the file in a future update. +.NH 3 +Environment definitions +.PP +Since IRAF is a machine and operating system independent, distributed system +it has its own environment facility apart from that of the host system. +Host system environment variables may be accessed as if they are part of the +IRAF environment (which is sometimes useful but which can also be +dangerous), but if the same variable is defined in the IRAF environment it +is the IRAF variable which will be used. The IRAF environment definitions, +as defined at CL startup time, are defined in a number of files in the +unix/hlib directory. Chief among these is the \fBzzsetenv.def\fR file. +Additional user modifiable definitions may be given in the template +\fBlogin.cl\fR file (see \(sc2.2.2). +.PP +The zzsetenv.def file contains a number of environment definitions. +Many of these define IRAF logical directories and should be left alone. +Only those definitions in the header area of the file should need to be +edited to customize the file for a site. It is the default editor, +default device, etc. definitions in this file which are most likely to +require modification for a site. +.PP +If the name of a default device is modified, the named device must also have +an entry in the \fBtermcap\fR file (terminals and printers) or the +\fBgraphcap\fR file (graphics terminals and image displays) in iraf/dev. +There must also be an \fIeditor\f(CW.ed\fR file in dev for the +default editor; \fIedt\fR, \fIemacs\fR, and \fIvi\fR are examples of +currently supported editors. +.PP +Sample values of those variables most likely to require modification for +a site are shown below. +.XS +set editor = "vi" +set printer = "lpr" +set stdplot = "lpr" +set stdimage = "imt512" +.XE +.PP +For example, you may wish to change the default editor to "emacs", the +default printer to "lw5", or the default image display to "imt800". Note +that the values of terminal and stdgraph, which also appear in the +zzsetenv.def file, have little meaning except for debugging processes run +standalone, as the values of the environment variables are reset +automatically by \fIstty\fR at login time. The issues of interfacing new +graphics and image display devices are discussed further in \(sc5. +.NH 3 +The template LOGIN.CL +.PP +The template login.cl file hlib$login.cl, is the file used by \fImkiraf\fR +to produce the user login.cl file. The user login.cl file, after having +possibly been edited by the user, is read by the CL every time a new CL is +started, with the CL processing all environment and task definitions, +package loads, etc., in the login file. Hence this file plays an important +role in establishing the IRAF environment seen by the user. +.PP +Examples of things one might want to change in the template login.cl +are the commented out environment definitions, the commented out CL +parameter assignments, the foreign task definitions making up the default +\f(CWuser\fR package, and the list of packages to be loaded at startup +time. For example, if there are host tasks or local packages which +should be part of the default IRAF operating environment at your site, +the template login.cl is the place to make the necessary changes. +.NH 3 +The TAPECAP file +.PP +Beginning with V2.10 IRAF magtape devices are described by the tapecap file, +dev$tapecap. This replaces the "devices" file used in earlier versions of +IRAF. The tapecap file describes each local magtape device and controls all +i/o to the device, as well as device allocation. +.PP +The tapecap file included in the distributed system includes some generic +device entries such as "mtxb1" (Exabyte unit 1, Sun ST driver), "mthp2" +(HP7880 9 track drive, unit 2), and so on which you may be able to use as-is +to access your local magtape devices. Most likely you will want to add some +device aliases, and you may need to prepare custom device entries for local +devices. There must be an entry in the tapecap file for a magtape device in +order to be able to access the device from within IRAF. +.PP +Instructions for adding devices to the tapecap file are given in the +document \fIIRAF Version 2.10 Revisions Summary\fR, in the discussion of +the new magtape system. +.NH 3 +The DEVICES.HLP file +.PP +All physical devices that the user might need to access by name should be +documented in the file dev$devices.hlp. Typing +.XS +cl> help devices +.XE +or just +.XS +cl> devices +.XE +in the CL will format and output the contents of this file. It is the IRAF +name of the device, as given in files such as termcap, graphcap, and +tapecap, which should appear in this help file. +.NH 3 +The TERMCAP file +.PP +There must be entries in this file for all local terminal and printer +devices you wish to access from IRAF (there is currently no "printcap" file +in IRAF). The entry for a printer contains one special device-specific +entry, called \f(CWDD\fR. This consists of three fields: the device name, +e.g. "node!device", the template for the temporary spoolfile, and the UNIX +command to be used to dispose of the file to the printer. On most UNIX +systems it is not necessary to make use of the node name and IRAF networking +to access a remote device since UNIX \fIlpr\fR already provides this +capability, however it might still be useful if the desired device does not +have a local \fIlpr\fR entry for some reason. +.PP +If you have a local terminal which has no entry in the IRAF termcap file, +you probably already have an entry in the UNIX termcap file. Simply copy it +into the IRAF file; both systems use the same termcap database format and +terminal device capabilities. However, if the terminal in question is a +graphics terminal with a device entry in the graphcap file, you should +add a `\f(CW:gd\fR' capability to the termcap entry. If the graphcap entry +has a different name from the termcap entry, make it `\f(CW:gd=\fIgname\fR'. +.NH 3 +The GRAPHCAP file +.PP +There must be entries in the graphcap file for all graphics terminals, batch +plotters, and image displays accessed by IRAF programs. New graphics +terminals will need a new entry. The IRAF file gio$doc/gio.hlp +contains documentation describing how to prepare graphcap device entries. A +printed copy of this document is available from the iraf/docs directory in +the IRAF network archive. However, once IRAF is up you may find it easier +to generate your own copy using \fIhelp\fR, as follows: +.XS +cl> help gio$doc/gio.hlp fi+ | lprint +.XE +which will print the document on the default IRAF printer device (use the +"device=" hidden parameter to specify a different device). Alternatively, +to view the file on the terminal, +.XS +cl> phelp gio$doc/gio.hlp fi+ +.XE +.PP +The help pages for the IRAF tasks \fIshowcap\fR and \fIstty\fR should also +be reviewed as these utilities are useful for generating new graphcap +entries. The i/o logging feature of \fIstty\fR is useful for determining +exactly what characters your graphcap device entry is generating. The +\fIgdevices\fR task is useful for printing summary information about the +available graphics devices. +.PP +Help preparing new graphcap device entries is available if needed. We ask +that new graphcap entries be sent back to us so that we may include them in +the master graphcap file for all to benefit. +.NH 3 +Configuring IRAF networking +.PP +The dev directory contains several files (\f(CWhosts\fR, +\f(CWirafhosts\fR, and \f(CWuhosts\fR) used by the IRAF network interface. +IRAF networking is used to access remote image displays, printers, magtape +devices, files, images, etc. via the network. Nodes do not necessarily have +to have the same architecture, or even run the same operating system, so +long as they can run IRAF. +.PP +To enable IRAF networking for a Sun/IRAF system, all that is necessary is to +edit the "hosts" file. Make an entry for each logical node, in the format +.XS +\fInodename\fR [ \fIaliases\fR ] ":" \fIirafks.e-pathname\fR +.XE +following the examples given in the hosts file supplied with the +distribution (which is the NOAO/Tucson hosts file). Note that there may be +multiple logical entries for a single physical node. +.PP +The "uhosts" file is not used by UNIX/IRAF systems hence does not need to +be modified (it used by VMS/IRAF). The "irafhosts" file is the template +file used to create user .irafhosts files. It does not have to be modified, +although you can do so if you wish to change the default parameter values +given in the file. +.PP +To enable IRAF networking on a particular IRAF host, the SunOS +\fBhostname\fR must appear as a primary name or alias somewhere in the IRAF +hosts table. During process startup, the IRAF VOS looks for the system name +for the current host and automatically disables networking if this name is +not found. Hence IRAF networking is automatically disabled when the +distributed system is first installed - unless you are unlucky enough to +have installed the system on a host with the same name as one of the nodes +in the NOAO host table. +.PP +Once IRAF networking is configured, the following command may be typed in +the CL to verify that all is well: +.XS +cl> netstatus +.XE +This will print the host table and state the name of the local host. +Read the output carefully to see if any problems are reported. +.PP +For IRAF networking to be of any use, it is necessary that IRAF be installed +on at least two systems. In that case either system can serve as the server +for an IRAF client (IRAF program) running on the other node. It is not +necessary to have a separate copy of IRAF on each node, i.e., a single copy +of IRAF may be NFS mounted on all nodes (you will need to run the IRAF +\fIinstall\fR script on each client node). If it is not possible to install +IRAF on a node for some reason (either directly or using NFS) it is possible +to manage by installing only enough of IRAF to run the IRAF kernel server. +Contact IRAF site support if you need to configure things in this manner. +.PP +Sun/IRAF currently supports only TCP/IP based networking. Networking +between any heterogeneous collection of systems is possible provided they +support TCP/IP based networking (virtually all UNIX-based systems do). The +situation with networking between UNIX and VMS systems is more complex. +V2.9 and earlier versions of VMS/IRAF support client-side only TCP/IP using +the third party Wollongong software. For V2.10 we plan to drop support for +the Wollongong software and switch to the more fully-featured Multinet +instead (another third party product). We have long had an experimental +DECNET networking interface for SunOS which is based on Sun's DECNET +implementation, however at this time it does not appear worthwhile to +release this as a supported product. Contact the IRAF project for further +information on networking between UNIX and VMS systems. +.PP +Once IRAF networking is enabled, objects resident on the server node may be +accessed from within IRAF merely by specifying the node name in the object +name, with a "\fInode!\fR" prefix. For example, if \fIfoo\fR is a network +node, +.XS +cl> page foo!hlib$motd +cl> allocate foo!mta +cl> devstatus foo!mta +.XE +.PP +In a network of "trusted hosts" the network connection will be made +automatically, without a password prompt. A password prompt will be +generated if the user does not have permission to access the remote node +with UNIX commands such as \fIrsh\fR. Each user has a .irafhosts file in +their UNIX login directory which can be used to exercise more control over +how the system connect to remote hosts. See the discussion of IRAF +networking in the \fIIRAF Version 2.10 Revisions Summary\fR, or in the V2.10 +system notes file, for a more in-depth discussion of how IRAF networking +works. +.PP +To keep track of where files are in a distributed file system, IRAF uses +\fBnetwork pathnames\fR. A network pathname is a name such as +"foo!/tmp3/images/m51.pix", i.e., a host or IRAF filename with the node name +prepended. The network pathname allows an IRAF process running on any node +to access an object regardless of where it is located on the network. +.PP +Inefficiencies can result when image pixel files are stored on disks which +are cross-mounted using NFS. The typical problem arises when imdir (the +pixel file storage directory) is set to a path such as "/data/iraf/user/", +where /data is a NFS mounted directory. Since NFS is transparent to +applications like IRAF, IRAF thinks that /data is a local disk and the +network pathame for a pixel file will be something like "foo!/data/iraf" +where "foo" is the hostname of the machine on which the file is written. If +the image is then accessed from a different network node the image data will +be accessed via an IRAF networking connection to node "foo", followed by an +NFS connection to the node on which the disk is physically mounted, causing +the data to traverse the network twice, slowing access and unnecessarily +loading the network. +.LP +A simple way to avoid this sort of problem is to include the server name +in the imdir, e.g., +.XS +cl> set imdir = "server!/data/iraf/user/" +.XE +This also has the advantage of avoiding NFS for pixel file access - NFS is +fine for small files but can load the server excessively when used to access +bulk image data. +.PP +Alternatively, one can set imdir to a value such as "HDR$pixels/", or +disable IRAF networking for disk file access. In both cases NFS will be +used for image file access. +.NH 3 +Configuring the IRAF account +.PP +The IRAF account, i.e., what one gets when one logs into SunOS as "iraf", +is the account used by the IRAF site manager to work on the IRAF system. +Anyone who uses this account is in effect a site manager, since they have +permission to modify, delete, or rebuild any part of IRAF. For these and +other reasons (e.g., concurrency problems) it is recommended that all routine +use of IRAF be performed from other accounts (user accounts). +.PP +If the system has been installed according to the instructions given in the +installation guide the login directory for the IRAF account will be +iraf/local. This directory contains both a \f(CW.login\fR file +defining the environment for the IRAF account, and a number of other "dot" +files used to setup a sample SunView screen of the type that an IRAF user +will want, i.e., with the IRAF graphics and image display windows. +.PP +Most site managers will probably want to customize these files according to +their personal preferences. In doing this please use caution to avoid losing +environment definitions, etc., which are essential to the correct operation +of IRAF, including IRAF software development. +.PP +The default login.cl file supplied in the IRAF login directory uses machine +independent pathnames and should work as-is (no need to do a \fImkiraf\fR - +in fact \fImkiraf\fR has safeguards against inadvertent use within the IRAF +directories and may not work in iraf/local). It may be necessary to edit +the .login file to modify the way the environment variable +\f(CWIRAFARCH\fR is defined. This variable, required for software +development but optional for merely using IRAF, must be set to the name of +the desired machine architecture, e.g., sparc, f68881, etc. If it is set to +the name of an architecture for which there are no binaries, e.g., generic, +the CL may not run, so be careful. The alias \fIsetarch\fR, defined in the +iraf account .login, is convenient for setting the desired architecture for +IRAF execution and software development. +.NH 3 +Configuring user accounts for IRAF +.PP +User accounts should be loosely modeled after the IRAF account. All that is +required for a user to run IRAF is that they run \fImkiraf\fR in their +desired IRAF login directory before starting up the CL. In many cases it +may be desirable for the user, if using SunView, to copy the default SunView +startup files from iraf/local as well (see \(sc4.1). Defining +\f(CWIRAFARCH\fR in the user environment is not required unless the user +will be doing any IRAF based software development (including IMFORT). + +.NH 2 +Tuning Considerations +.NH 3 +Stripping the system to reduce disk usage +.PP +If the system is to be installed on multiple CPUs, or if a production +version is to be installed on a workstation, it may be necessary or +desirable to strip the system of all non-runtime files to save disk space. +This equates to deleting all the sources and all the reference manuals and +other documentation, excluding the online manual pages. A special utility +called \fIrmfiles\fR (in the SOFTOOLS package) is provided for this +purpose. It is not necessary to run \fIrmfiles\fR directly to strip the +system. The preferred technique is to use "mkpkg strip" as in the following +example (this may be executed from either the host system or from within +IRAF). +.XS +% cd $iraf +% mkpkg strip +.XE +.PP +This will preserve all runtime files, permitting use of the standard system +as well as user software development. Note that only the IRAF core system +is stripped, i.e., if you want to strip any external layered software +products, such as the NOAO package, a \fImkpkg strip\fR must be executed +separately for each - \fIcd\fR to the root directory of the external package +first. A tape backup of a system should always be made before the system is +stripped; keep the backup indefinitely as it may be necessary to restore the +sources in order to, e.g., install a bug fix or add-on software product. + +.NH +Software Management +.NH 2 +Multiple architecture support +.PP +Often the computing facilities at a site consist of a heterogeneous network +of workstations and servers. These machines will often have quite different +architectures. Considering only a single vendor like Sun, as of 1992 one +sees the three major architectures SPARC, Motorola 68020, and Intel 80386, +and several minor variations on these architectures, i.e., the floating +point options for the Sun-3, namely the Motorola 68881 coprocessor, the Sun +floating point accelerator (FPA), and software floating point (Sun is trying +to phase some of these out but the need for multiple architecture support is +not likely to go away). +.PP +Since IRAF is a large system it is undesirable to have to maintain a separate +copy of IRAF for each machine architecture on a network. For this reason +IRAF provides support for multiple architectures within a single copy of IRAF. +To be accessible by multiple network clients, this central IRAF system will +typically be NFS mounted on each client. +.PP +Multiple architecture support is implemented by separating the IRAF sources +and binaries into different directory trees. The sources are architecture +independent and hence sharable by machines of any architecture. All of the +architecture dependence is concentrated into the binaries, which are collected +together into the so-called BIN directories, one for each architecture. +The BIN directory contains all the object files, object libraries, executables, +and shared library images for an architecture, supporting both IRAF execution +and software development for that architecture. A given system can support +any number of BIN directories, and therefore any number of architectures. +.PP +In IRAF terminology, when we refer to an "architecture" what we really +mean is a type of BIN. The correspondence between BINs and hardware +architectures is not necessarily one-to-one, i.e., multiple BINs can exist +for a single compiler architecture by compiling the system with different +compilation flags, as different versions of the software, and so on. +Examples of some currently supported software architectures are shown below. +.DS +.TS +center; +ci ci ci +l l l. +Architecture System Description +.sp +f68881 Sun-3 mc68020, 68881 floating point coprocessor +ffpa Sun-3 mc68020, Sun floating point accelerator board +generic any no binaries +i386 386i Intel 80386, 80387 floating point coprocessor +pg any compiled with -pg option for profiling +sparc Sun-4 Sun SPARC (RISC) architecture, integral fpu +.TE +.DE +.PP +Most of these correspond to hardware architectures or floating point hardware +options. The exceptions are the generic architecture, which is what +the distributed system is configured to by default (to avoid having any +architecture dependent binary files mingled with the sources), and the +"pg" architecture, which is not normally distributed to user sites, +but is a good example of a custom software architecture used for software +development. +.PP +When running IRAF on a system configured for multiple architectures, +selection of the BIN (architecture) to be used is controlled by the UNIX +environment variable \f(CWIRAFARCH\fR, e.g., +.XS +% setenv IRAFARCH f68881 +.XE +would cause IRAF to run using the f68881 architecture, corresponding to the +BIN directory bin.f68881. Once inside the CL one can check the current +architecture by entering one of the following commands (the output in each +case is shown as well). +.XS +cl> show IRAFARCH +f68881 +.XE +or +.XS +.cc # +cl> show arch +.f68881 +#cc +.XE +.LP +If IRAFARCH is undefined at CL startup time a default architecture will be +selected based on the current machine architecture, the available floating +point hardware, and the available BINs. The IRAFARCH variable controls not +only the architecture of the executables used to run IRAF, but the libraries +used to link IRAF programs, when doing software development from within the +IRAF or host environment. +.PP +Additional information on multiple architecture support is provided in the +system notes file for V2.8, file doc$notes.v28. + +.NH 2 +Shared libraries +.PP +Sun/IRAF provides a shared library facility for SunOS 4.0 and later versions +of SunOS (but not for SunOS-3). All architectures are supported. +So long as everything is working properly, the existence and use of the shared +library should be transparent to the user and to the site manager. +This section gives an overview of the shared library facility to point +the reader in the right direction in case questions should arise. +.PP +What the shared library facility does is take most of the IRAF system +software (currently the contents of the \f(CWex\fR, \f(CWsys\fR, +\f(CWvops\fR, and \f(CWos\fR libraries) and link it together into a special +sharable image, the file \f(CWS\fIn\fP.e\fR in each core system BIN +directory (\fIn\fR is the shared image version number, e.g. "S6.e"). This +file is mapped into the virtual memory of each IRAF process at process +startup time. Since the shared image is shared by all IRAF processes, each +process uses less physical memory, and the process pagein time is reduced, +speeding process execution. Likewise, since the subroutines forming the +shared image are no longer linked into each individual process executable, +substantial disk space is saved for the BIN directories. Link time is +correspondingly reduced, speeding software development. +.PP +The shared library facility consists of the \fBshared image\fR itself, +which is an actual executable image (though not runnable on all systems), +and the \fBshared library\fR, contained in the library lib$libshare.a, +which defines each VOS symbol (subroutine), and which is what is linked +into each IRAF program. The shared library object module does not consume +any space in the applications program, rather it consists entirely of symbols +pointing to \fBtransfer vector\fR slots in the header area of the shared +image. The transfer vector slots point to the actual subroutines. +.PP +When an IRAF program is linked with \fIxc\fR, one has the option of linking +with either the shared library or the individual system libraries. Linking +with the shared library is the default; the \f(CW-z\fR flag disables linking +with the shared library. In the final stages of linking \fIxc\fR runs the +HSI utility \fIedsym\fR to edit the symbol table of the output executable, +modifying the shared library (VOS) symbols to point directly into the shared +image (to facilitate symbolic debugging), optionally deleting all shared +library symbols, or performing some other operation upon the shared library +symbols, depending upon the \fIxc\fR link flags given. +.PP +At process startup time, upon entry to the process main (a C main for +Sun/IRAF) the shared image will not yet have been mapped into the address +space of the process, hence any attempted references to VOS symbols would +result in a segmentation violation. The \fIzzstrt\fR procedure, called by +the process main during process startup, opens the shared image file and +maps it into the virtual space of the IRAF program. Once the IRAF main +prompt appears (when running an IRAF process standalone), all initialization +will have completed. +.PP +Each BIN, if linked with the shared library, will have its own shared image +file \f(CWS\fIn\fP.e\fR. If the shared image is relinked this file will be +moved to \f(CWS\fIn\fP.e.1\fR and the new shared image will take its place; +any old shared image files should eventually be deleted to save disk space, +once any IRAF processes using them have terminated. Normally when the +shared image is rebuilt it is not necessary to relink applications programs, +since the transfer vector causes the linked application to be unaffected +by relocation of the shared image functions. +.PP +If the shared image is rebuilt and its version number (the \fIn\fR in +\f(CWS\fIn\fP.e\fR) is incremented, the transfer vector is rebuilt the new +shared image cannot be used with previously linked applications. These +old applications will still continue to run, however, so long as the older +shared image is still available. It is common practice to have at least +two shared image versions installed in a BIN directory. +.PP +Further information on the Sun/IRAF shared library facility in given in the +IRAF V2.8 system notes file. In particular, anyone doing extensive IRAF +based software development should review this material, e.g., to learn how +to debug processes that are linked with the shared image. + +.NH 2 +Layered software support +.PP +An IRAF installation consists of the core IRAF system and any number of +external packages, or "layered software products". As the name suggests, +layered software products are layered upon the core IRAF system. Layered +software requires the facilities of the core system to run, and is portable +to any computer which already runs IRAF. Any number of layered products can +be installed in IRAF to produce the IRAF system seen by the user at a +given site. +.PP +The support provided by IRAF for layered software is essentially the same as +that provided for maintaining the core IRAF system itself (the core system +is a special case of a layered package). Each layered package (usually this +refers to a suite of subpackages) is a system in itself, similar in +structure to the core IRAF system. Hence, there is a LIB, one or more BINs, +a help database, and all the sources and runtime files. A good example of +an external package is the NOAO package. Except for the fact that NOAO is +rooted in the IRAF directories, NOAO is equivalent to any other layered +product, e.g., STSDAS, TABLES, XRAY, CTIO, NLOCAL, ICE, and so on. In +general, layered products should be rooted somewhere outside the IRAF +directory tree to simplify updates. + +.NH 2 +Software management tools +.PP +IRAF software management is performed with a standard set of tools, +consisting of the tasks in the SOFTOOLS package, plus the host system +editors and debuggers. Some of the most important and often used tools for +IRAF software development and software maintenance are the following. +.sp +.RS +.IP \f(CWmkhelpdb\fP 20 +Updates the HELP database of the core IRAF system or an external package. +The core system, and each external package, has its own help database. +The help database is the machine independent file \f(CWhelpdb.mip\fR in the +package library (LIB directory). The help database file is generated with +\fImkhelpdb\fR by compiling the \f(CWroot.hd\fR file in the same directory. +.IP \f(CWmkpkg\fP 20 +The "make-package" utility. Used to make or update package trees. +Will update the contents of the current directory tree. When run at +the root iraf directory, updates the full IRAF system; when run at the +root directory of an external package, updates the external package. +Note that updating the core IRAF system does not update any external +packages (including NOAO). When updating an external package, the +package name must be specified, e.g., "\fImkpkg -p noao\fR". +.IP \f(CWrmbin\fP 20 +Descends a directory tree or trees, finding and optionally listing or +deleting all binary files therein. This is used, for example, to strip +the binaries from a directory tree to leave only sources, to force +\fImkpkg\fR to do a full recompile of a package, or to locate all the +binaries files for some reason. IRAF has its own notion of what a binary +file is. By default, files with the "known" file extensions +(.[aoe], .[xfh] etc.) are classified as binary or text +(machine independent) files immediately, +while a heuristic involving examination of the file data +is used to classify other files. Alternatively, a list of file extensions +to be searched for may optionally be given. +.IP \f(CWrtar,wtar\fP 20 +These are the portable IRAF tarfile writer (\fIwtar\fR) and reader +(\fIrtar\fR). About the only reasons to use these with Sun/IRAF +are if one wants to move only the machine independent or source files +(\fIwtar\fR, like \fIrmbin\fR, can discriminate between machine +generated and machine independent files), or if one is importing files +written to a tarfile on a VMS/IRAF system, where the files are blank +padded and the trailing blanks need to be stripped with \fIrtar\fR. +.IP \f(CWxc\fP 20 +The X (SPP) compiler. This is analogous to the UNIX \fIcc\fR except +that it can compile ".x" or SPP source files, knows how to link with the +IRAF system libraries and the shared library, knows how to read the +environment of external packages, and so on. +.RE +.sp +.PP +The SOFTOOLS package contains other tasks of interest, e.g., a program +\fImktags\fR for making a tags file for the \fIvi\fR editor, a help +database examine tool, and other tasks. Further information on these +tasks is available in the online help pages. + +.NH 2 +Modifying and updating a package +.PP +IRAF applications development is most conveniently performed from within the +IRAF environment, since testing must be done from within the environment. +The usual edit-compile-test development cycle is illustrated below. This +takes place within the \fIpackage directory\fR containing all the files +specific to a given package. +.RS +.IP \(bu +Edit one or more source files. +.IP \(bu +Use \fImkpkg\fR to compile any modified files, or files which include a +modified file, and relink the package executable. +.IP \(bu +Test the new executable. +.RE +.PP +The mkpkg file for a package can be written to do anything, +but by convention the following commands are usually provided. +.sp +.RS +.IP "\f(CWmkpkg\fP" 20 +The \fImkpkg\fR command with no arguments does the default mkpkg operation; +for a subpackage this is usually the same as \fImkpkg relink\fR below. For +the root mkpkg in a layered package it udpates the entire layered package. +.IP "\f(CWmkpkg libpkg.a\fP" 20 +Updates the package library, compiling any files which have been modified or +which reference include files which have been modified. Private package +libraries are intentionally given the generic name libpkg.a to symbolize +that they are private to the package. +.IP "\f(CWmkpkg relink\fP" 20 +Rebuilds the package executable, i.e., updates the package library and +relinks the package executable. By convention, this is the file +xx_\fIpkgname\fR.e\fR in the package directory, where \fIpkgname\fR is the +package name. +.IP "\f(CWmkpkg install\fP" 20 +Installs the package executable, i.e., renames the xx_foo.e file to x_foo.e +in the global BIN directory for the layered package to which the subpackage +\fIfoo\fR belongs. +.IP "\f(CWmkpkg update\fP" 20 +Does everything, i.e., a \fIrelink\fR followed by an \fIinstall\fR. +.RE +.sp +.PP +If one wishes to test the new program before installing it one should do a +\fIrelink\fR (i.e., merely type "mkpkg" since that defaults to relink), then +run the host system debugger on the resultant executable. The process is +debugged standalone, running the task by giving its name to the standalone +process interpreter. The CL task \fIdparam\fR is useful for dumping a +task's parameters to a text file to avoid having to answer parameter queries +during process execution. The LOGIPC debugging facility introduced in V2.10 +is also useful for debugging subprocesses. If the new program is to be +tested under the CL before installation, a \fItask\fR statement can be +interactively typed into the CL to cause the CL to run the "xx_" version of +the package executable, rather than old installed version. +.PP +When updating a package other than in the core IRAF system, the \f(CW-p\fR +flag, or the equivalent \f(CWPKGENV\fR environment variable, must be used to +indicate the system or layered product being updated. For example, "mkpkg +-p noao update" would be used to update one of the subpackages of the NOAO +layered package. If the package being updated references any libraries or +include files in \fIother\fR layered packages, those packages must be +indicated with a "-p pkgname" flag as well, to cause the external package to +be searched. +.PP +The CL process cache can complicate debugging and testing if one forgets +that it is there. When a task is run under the CL, the executing process +remains idle in the CL process cache following task termination. If a new +executable is installed while the old one is still in the process cache, the +CL will automatically run the new executable (the CL checks the modify date +on the executable file every time a task is run). If however an executable is +currently running, either in the process cache or because some other user is +using the program, it may not be possible to set debugger breakpoints. +.PP +The IRAF shared image can also complicate debugging, although for most +applications-level debugging the shared library is transparent. By default +the shared image symbols are included in the symbol table of an output +executable following a link, so in a debug session the shared image will +appear to be part of the applications program. When debugging a program +linked with the shared library, the process must be run with the \f(CW-w\fR +flag to cause the shared image to be mapped with write permission, allowing +breakpoints to be set in the shared image (that is, you type something like +":r -w" when running the process under the debugger). Linking with the +\f(CW-z\fR flag will prevent use of the shared image entirely. +.PP +A full description of these techniques is beyond the scope of this manual, +but one need not be an expert at IRAF software development techniques to +perform simple updates. Most simple revisions, e.g., bug fixes or updates, +can be made by merely editing or replacing the affected files and typing +.XS +cl> mkpkg +.XE +or +.XS +cl> mkpkg update +.XE +to update the package. + +.NH 2 +Installing and maintaining layered software +.PP +The procedures for installing layered software products are similar to those +used to install the core IRAF system, or update a package. +Layered software may be distributed in source only form, or with binaries; +it may be configured for a single architecture, or may be preconfigured +to support multiple architectures. The exact procedures to be followed +to install a layered product will in general be product dependent, and should +be documented in the installation guide for the product. +.LP +In brief, the procedure to be followed should resemble the following: +.RS +.IP \(bu +Create the root directory for the new software, somewhere outside the +IRAF directories. +.IP \(bu +Restore the files to disk from a tape or network archive distribution file. +.IP \(bu +Edit the core system file hlib$extern.pkg to "install" the new package in +IRAF. This file is the sole link between the IRAF core system and the +external package. +.IP \(bu +Configure the package BIN directory or directories, either by restoring +the BIN to disk from an archive file, or by recompiling and relinking the +package with \fImkpkg\fR. +.RE +.LP +As always, there are some little things to watch out for. +When using \fImkpkg\fR on a layered product, you must give the name +of the system being operated upon, e.g., +.XS +cl> mkpkg -p foo update +.XE +where \fIfoo\fR is the system or package name, e.g., "noao", "local", etc. +The \f(CW-p\fR flag can be omitted by defining \f(CWPKGENV\fR in your +UNIX environment, but this only works for updates to a single package. +.PP +An external system of packages may be configured for multiple architecture +support by repeating what was done for the core system. One sets up several +BIN directories, one for each architecture, named \f(CWbin.\fIarch\fR, where +\fIarch\fR is "f68881", "ffpa", "sparc", etc. These directories, or +symbolic links to the actual directories, go into the root directory of the +external system. A symbolic link \f(CWbin\fR pointing to an empty directory +bin.generic, and the directory itself, are added to the system's root +directory. The system is then stripped of its binaries with \fIrmbin\fR, if +it is not already a source only system. Examine the file zzsetenv.def in +the layered package LIB directory to verify that the definition for the +system BIN (which may be called anything) includes the string "(arch)", +e.g., +.XS +set noaobin = "noao$bin(arch)/" +.XE +.LP +The binaries for each architecture may then be generated by configuring the +system for the desired architecture and running \fImkpkg\fR to update the +binaries, for example, +.XS +cl> cd foo +cl> mkpkg sparc +cl> mkpkg -p foo update >& spool & +.XE +where \fIfoo\fR is the name of the system being updated. If any questions +arise, examination of a working example of a system configured for multiple +architecture support (e.g., the NOAO packages) may reveal the answers. +.PP +Once installed and configured, a layered product may be deinstalled merely +by archiving the package directory tree, deleting the files, and commenting +out the affected lines of hlib$extern.pkg. With the BINs already configured +reinstallation is a simple matter of restoring the files to disk and editing +the extern.pkg file. + +.NH 2 +Configuring a custom LOCAL package +.PP +Anyone who uses IRAF enough will eventually want to add their own software +to the system, by copying and modifying the distributed versions of +programs, by obtaining and installing isolated programs written elsewhere, +or by writing new programs of their own. A single user can do this by +developing software for their own personal use, defining the necessary +\fItask\fR statements etc. to run the software in their personal login.cl +or loginuser.cl file. To go one step further and install the new software +in IRAF so that it can be used by everyone at a site, one must configure a +custom local package. +.PP +The procedures for configuring and maintaining a custom LOCAL package are +similar to those outlined in \(sc3.5 for installing and maintaining +layered software, since a custom LOCAL will in fact be a layered software +product, possibly even something one might want to export to another site +(although custom LOCALs may contain non-portable or site specific software). +.PP +To make a custom local you make a copy of the "template local" package +(iraf$local) somewhere outside the IRAF directory tree, change the name +to whatever you wish to call the new layered package, and install it as +outlined in \(sc3.5. The purpose of the template local is to provide the +framework necessary for a external package; a couple of simple tasks are +provided in the template local to serve as examples. Once you have +configured a local copy of the template local and gotten it to compile and +link, it should be a simple matter to add new tasks to the existing +framework. + +.NH 2 +Updating the full IRAF system +.PP +This section will describe how to recompile or relink IRAF. Before we get +into this however, it should be emphasized that \fImost users will never +need to recompile or relink IRAF\fR. In fact, this is not something that +one should attempt lightly - don't do it unless you have some special +circumstance which requires a custom build of the system (such as a port). +Even then you might want to set up a second copy of IRAF to be used for the +experiment, keeping the production system around as the standard system. If +you change the system it is a good idea to make sure that you can undo the +change. +.PP +While the procedure for building IRAF is straightforward, it is easy to make +a mistake and without considerable knowledge of IRAF it may be difficult to +recover from such a a mistake (for example, running out of disk space during +a build, or an architecture mismatch resulting in a corrupted library or +shared image build failure). More seriously, the software - SunOS, the Sun +Fortran compiler, the local system configuration, and IRAF - is changing +constantly. A build of IRAF brings all these things together at one time, +and every build needs to be independently and carefully tested. An OS +upgrade or a new version of the Fortran compiler may not yet be supported by +the version of IRAF you have locally. Any problems with the SunOS +configuration can cause a build to fail, or introduce bugs (for example, Sun +Fortran problems have been common since the compiler was unbundled). +.PP +The precompiled binaries we ship with IRAF have been carefully prepared and +tested, usually over a period of months. They are the same as are used at +NOAO and at most IRAF sites, so even if there are bugs they will likely have +already been seen elsewhere and a workaround determined. If the bugs are +new then since we have the exact same IRAF system we are more likely to be +able to reproduce and fix the bug. Often the bug is not in the IRAF +software at all but in the host system or IRAF configuration. As soon as an +executable is rebuilt (even something as simple as a relink) you have new, +untested, software. +.NH 3 +The BOOTSTRAP +.PP +To fully build IRAF from the sources is a three step process. First the +system is "bootstrapped", which builds the host system interface (HSI) +executables. A "sysgen" of the core system is then performed; this compiles +all the system libraries and builds the core system applications. Finally, +the bootstrap is then repeated, to make use of some of the functions from +the IRAF libraries compiled in step two. +.PP +To bootstrap Sun/IRAF, login as IRAF and enter the commands shown below. +This takes a while and generates a lot of output, so the output should be +spooled in a file. +.LP +For a Sun-4 (sparc) system: +.XS +% cd $iraf +% mkpkg sparc +% cd $iraf/unix +% reboot >& spool & +.XE +For a Sun-3 system: +.XS +% cd $iraf +% mkpkg f68881 +% cd $iraf/unix +% reboot >& spool & +.XE +.PP +There are two types of bootstrap, the initial bootstrap starting from a +source only system, called the NOVOS bootstrap, and the final or VOS +bootstrap, performed once the IRAF system libraries \f(CWlibsys.a\fR and +\f(CWlibvops.a\fR exist. The bootstrap script \fIreboot\fR will +automatically determine whether or not the VOS libraries are available and +will perform a NOVOS bootstrap if the libraries cannot be found. It is +important to restore the sparc or f68881 architecture before attempting a +bootstrap, as otherwise a NOVOS bootstrap will be performed. +.NH 3 +The SYSGEN +.PP +By sysgen we refer to an update of the core IRAF system - all of the files +comprising the runtime system, excluding the HSI which is generated by the +bootstrap. On a source only system, the sysgen will fully recompile the +core system, build all libraries and applications, and link and install the +shared image and executables. On an already built system, the sysgen +scans the full IRAF directory tree to see if anything is out of date, +recompiles any files that need it, then relinks and installs new executables. +.PP +To do a full sysgen of IRAF one merely runs \fImkpkg\fR at the IRAF root. +If the system is configured for multiple architecture support one must +repeat the sysgen for each architecture. Each sysgen builds or updates a +single BIN directory. Since a full sysgen takes a long time and generates a +lot of output which later has to be reviewed, it is best to run the job in +batch mode with the output redirected. For example to update the sparc +binaries: +.XS +% cd $iraf +% mkpkg sparc +% mkpkg >& spool & +.XE +To watch what is going on after this command has been submitted and while +it is running, try +.XS +% tail -f spool +.XE +Sysgens are restartable, so if the sysgen aborts for any reason, simply fix +the problem and start it up again. Modules that have already been compiled +should not need to be recompiled. How long the sysgen takes depends upon +how much work it has to do. The worst case is if the system and +applications libraries have to be fully recompiled. If the system libraries +already exist they will merely be updated. Once the system libraries are up +to date the sysgen will rebuild the shared library if any of the system +libraries involved were modified, then the core system executables will be +relinked. +.PP +A full sysgen generates a lot of output, too much to be safely reviewed for +errors by simply paging the spool file. Enter the following command to +review the output (this assumes that the output has been saved in a file +named "spool"). +.XS +% mkpkg summary +.XE +It is normal for a number of compiler messages warning about assigning +character data to an integer variable to appear in the spooled output +if the full system has been compiled. There should be no serious error +messages if a supported and tested system is being recompiled. +.PP +The above procedure only updates the core IRAF system. To update a layered +product one must repeat the sysgen process for the layered system. For +example, to update the sparc binaries for the NOAO package: +.XS +% cd $iraf/noao +% mkpkg sparc +% mkpkg -p noao >& spool & +.XE +This must be repeated for each supported architecture. Layered systems are +independent of one another and hence must be updated separately. +.PP +To force a full recompile of the core system or a layered package, one can +use \fIrmbin\fR to delete the objects, libraries, etc. scattered throughout +the system, or do a "mkpkg generic" and then delete the \f(CWOBJS.arc.Z\fR +file in the BIN one wishes to regenerate (the latter approach is probably +safest). +.PP +A full IRAF core system sysgen currently takes anywhere from 3 to 30 hours, +depending upon the system (e.g. from 30 hours on a VAX 11/750, to 3 hours on +a big modern server). On most systems a full sysgen is a good job to run +overnight. +.PP +.NH 3 +Localized software changes +.PP +The bootstrap and the sysgen are unusual in that they update the entire +HSI, core IRAF system, or layered package. Many software changes are more +localized. If only a few files are changed a sysgen will pick up the changes +and update whatever needs to be updated, but for localized changes a sysgen +really does more than it needs to (if the changes are scattered all over +the system an incremental sysgen-relink will still be best). +.PP +To make a localized change to a core system VOS library and update the +linked applications to reflect the change all one really needs to do is +change the desired source files, run \fImkpkg\fR in the library source +directory to compile the modules and update the affected libraries, and then +build a new IRAF shared image (this assumes that the changes affect only the +libraries used to make the shared image, i.e., libsys, libex, libvops, and +libos). Updating only the shared image, without relinking all the +applications, has the advantage that you can put the runtime system back the +way it was by just swapping the old shared image back in - a single file. +.PP +For example, assume we want to make a minor change to some files in the VOS +interface IMIO, compiling for the sparc architecture. We could do this as +follows (this assumes that one is logged in as IRAF and that the usual IRAF +environment is defined). +.XS +% whoami +iraf +% cd $iraf +% mkpkg sparc +% cd imio + \fR(edit the files)\fP +% mkpkg \fR# update IMIO libraries (libex)\fP +% +% cd $iraf/bin.sparc \fR# save copy of old shared image\fP +% cp S6.e S6.e.V210 +% +% cd shlib +% tar -cf ~/shlib.tar . \fR# backup shlib just in case\fP +% mkpkg update \fR# make and install new shared image\fP +.XE +.PP +Changing applications is even easier. Ensure that the system architecture +is set correctly (i.e. "mkpkg sparc" at the iraf or layered package root), +edit the affected files in the package source directory, and type "mkpkg -p + update" in the root directory of the package being edited. This +will compile any modified files, and link and install a new executable. +You can do this from within the CL and immediately run the revised program. +.PP +We should emphasize again that, although we document the procedures for +making changes to the software here, to avoid introducing bugs we do not +recommend changing any of the IRAF software except in unusual (or at least +carefully controlled) circumstances. To make custom changes to an +application, it is best to make a local copy of the full package somewhere +outside the standard IRAF system. If changes are made to the IRAF system +software it is best to set up an entire new copy of IRAF on a machine +separate from the normal production installation, so that one can experiment +at will without affecting the standard system. An alternative which does +not require duplicating the full system is to use the \f(CWIRAFULIB\fR +environment variable. This can be used to safely experiment with custom +changes to the IRAF system software outside the main system; IRAFULIB lets +you define a private directory to be searched for IRAF global include files, +libraries, executables, etc., allowing you to have your own private versions +of any of these. See the system notes files for further information on how +to use IRAFULIB. + +.NH +Graphics and Image Display under SunView +.PP +Sun/IRAF may be used from any ordinary video or graphics terminal, or from a +Sun workstation run either as a terminal or under the SunView windowing +system (IRAF can also be run from X, but full support for X on Suns is not +yet available at the time this is being written). Our concern here is with +the use of IRAF on a Sun workstation running SunView. [Jul92 note - this +section, discussing SunView support dates from the original Jun89 document +and is being left as is. The X11 support package will be system independent +and is being distributed separately from Sun/IRAF. If you wish, you can +already run Sun/IRAF under X11, using \fIxterm\fR and \fIsaoimage\fR for +graphics and image display]. +.PP +The standard SunView system provides standard window tools which can be used +to run IRAF, e.g., \fIshelltool\fR and \fItektool\fR. \fIshelltool\fR is ok +as a terminal but cannot do graphics. \fItektool\fR can do graphics but is +much too inflexible, and is not much good as a terminal since it cannot scroll +or erase text. To provide a reasonable combination of video terminal and +vector graphics capabilities, we have extended SunView by adding a general +purpose virtual graphics terminal window tool called \fIgterm\fR, and an +image display server window tool called \fIimtool\fR. Both programs are +implemented at the SunView level as general purpose window tools, and are +useful independently of IRAF. Detailed documentation on the basic operation +and use of these programs is given in the \fIgterm\fR(l) and \fIimtool\fR(1) +manual pages. Our concern in this document is with the use of these programs +with IRAF. +.NH 2 +The SunView environment +.PP +The graphics and image display tools provided with IRAF operate within the +SunView windowing environment much like the standard tools provided with +SunView. To help illustrate the use of these tools, Sun/IRAF is distributed +with a sample SunView environment already configured for the IRAF account. +This consists of the following files in the IRAF account login directory, +iraf$local. +.RS +.IP \f(CW.defaults\fP 20 +Sets up the defaults for how the window system looks, e.g., enables the +custom rootmenu file. +.IP \f(CW.rootmenu\fP 20 +An example of a sophisticated, multilevel custom rootmenu, including +entries for gterm and imtool. +.IP \f(CW.suntools\fP 20 +Defines a screen layout that includes gterm and imtool windows, including +sizing and positioning the graphics window. +.IP \f(CW.sunview\fP 20 +Same as the \f(CW.suntools\fP file, which Sun plans to rename +to \f(CW.sunview\fP in a future version of SunOS. +.IP \f(CW.ttyswrc\fP 20 +Defines some function keys for \fItty\fP subwindows (gterm). +.RE +.PP +No one screen layout will suit all users or all applications. +Everyone will wish to customize the workstation screen to suit their +preferences and the type of work they are doing, but it is recommended +that users copy these files to serve as a starting point. + +.NH 2 +Vector graphics capabilities +.PP +The standard graphics terminal emulator for Sun/IRAF under SunView is +\fIgterm\fR, which emulates a conventional dual plane text/graphics terminal. +This software terminal is driven via an ASCII datastream like a conventional +hard terminal (except that the effective baud rate is much higher). +The text window behaves like the Sun console and the graphics window +behaves like a Tektronix 4012, plus some IRAF oriented extensions. +Since gterm emulates standard text and graphics devices non-IRAF programs +can easily be run as well as IRAF programs. +.PP +Configuring IRAF to use gterm is very simple. The following command does +the job. This is normally executed by the login.cl or loginuser.cl file at +login time. +.XS +cl> stty gterm +.XE +.PP +A number of function keys are recognized by gterm which one should be aware +of. Some of these are built into gterm itself, others are defined in the +default \f(CW.ttyswrc\fR file. +.RS +.IP F7 +Toggle between fullscreen graphics window and normal graphics window. +.IP F8 +Clear (if in graphics mode) or enable (if in text mode) output to the +graphics plane. Used to manually put the terminal into 4012 emulation mode. +.IP F9 +Clear (if in text mode) or enable (if in graphics mode) the text plane. +Closing the graphics plane will also enable the text plane. +.IP R1 +Set text window size to 24 lines by 80 columns. +.IP R2 +Set text window size to 34 lines by 80 columns. +.IP R3 +Set text window size to 40 lines by 80 columns. +.IP R5 +Set text window size to 54 lines by 80 columns. +Tallest possible text window using standard font. +.RE +.PP +The text window may also be manually resized using the mouse but the +function keys are most convenient for rapid changes to the window height. +The IRAF software will automatically sense that the window size has +changed whenever a screen oriented program is run. The current window size +can be printed with \f(CWstty show\fR, or updated with \f(CWstty resize\fR. +.PP +There is a \fBframe menu\fR which may be used to access a number of +useful functions, e.g., logging of all output to the terminal, or bitmap +hardcopies of the text or graphics windows or the full screen. Control +over the terminal setup is provided by a \fBsetup panel\fR. +.PP +Note that the \fIgraphics\fR window may also be resized and moved about on the +screen. A number of predefined standard window sizes are provided via the +gterm setup panel, ranging from pretty small to the full screen. +The graphics window may also be interactively adjusted with the mouse +to some arbitrary size, but the advantage of the predefined window sizes +is that they all have the same standard aspect ratio and size in characters +(35x80). Multiple IRAF sessions running in multiple gterm windows are +possible; using different colors makes it easier to remember which window +is which. +.PP +Aside from the dynamic nature of windows in the SunView environment, +operation of IRAF from a gterm window is straightforward and should present +no problems for someone already familiar with the use of IRAF on a conventional +graphics terminal. Further information is given in the gterm manual page, +\fIgterm\fR(l) (a UNIX level manpage). +.NH 2 +Image Display capabilities +.PP +Image display for IRAF running in the SunView environment is provided +by the \fIimtool\fR display server prototype. The current \fIimtool\fR +program provides a basic display capability, including programmed access +from the IRAF environment to load images, interactive windowing of the +display, pseudocolor, dithered (Postscript) or Sun rasterfile image hardcopy, +an interactive image cursor readback capability, zoom and pan, a variety +of frame buffer sizes, independent frame buffer and display window sizing, +up to four frames, each with its own state, and programmable frame blink. +\fIimtool\fR runs as a display server, meaning that it sits idle most of +the time, waiting for some client, e.g., IRAF, to send it an image to be +displayed via some form of interprocess communication. +.PP +To use imtool from within IRAF one must define the logical device and +enable image cursor input. For example, +.XS +cl> reset stdimage = imt512 +.XE +would configure IRAF and imtool for use with a 512 pixel square frame buffer +(image display image memory). A variety of frame buffer sizes are +predefined; see the \f(CWimtoolrc\fR file (normally in /usr/local/lib) for a +complete list of possible configurations. +.LP +The image cursor is enabled by +.XS +cl> reset stdimcur = stdimage +.XE +.LP +This is the default for Sun/IRAF. Setting \f(CWstdimcur\fR to "text" +disables the image cursor, allowing cursor values to be typed in interactively +in the terminal window. This is useful, for example, when running image +oriented programs from a simple terminal. +.PP +The standard IRAF interface to the display server is the \fIdisplay\fR program +in the TV package. Automatic determination of the optimum intensity mapping +to the 200 imtool greylevels is provided. Entire frames can be displayed, +or one can write to subregions of the display. Other programs useful with +the image display include \fIimexamine\fR, used to interactively examine +images under image cursor control, \fIimedit\fR, used to edit images using +the display, and \fItvmark\fR, used to write color graphics into a display +frame. +.PP +The display server has the capability of displaying the cursor (mouse) +position and pixel value in image pixel units as the mouse is moved about +in the window. In addition, text file cursor lists can be generated and +displayed, or the image cursor can be read interactively from within IRAF. +The image cursor may be called up at any time by typing +.XS +cl> =imcur +.XE +into the CL. Applications programs which read the interactive image cursor +will do this automatically during program execution. +.PP +Imtool supports a number of special function keys and other keyboard +accelerators, a \fBframe menu\fR, a \fBsetup panel\fR and so on. +Further information on the operation of imtool is given in the online manual +page, \fIimtool\fR(l) (a UNIX level manpage). Further information on the +use of the image cursor is given in the online help page \f(CWcursors\fR. +.NH 2 +Using the workstation with a remote compute server +.PP +A common mode of operation with a workstation is to run Sun/IRAF under +SunView directly on the workstation which runs IRAF, accessing files either +on a local disk, or on a remote disk via a network interface (NFS, IRAFKS, +etc.). It is also possible, however, to run SunView with gterm and imtool +on the workstation, but run IRAF on a remote node, e.g., some powerful +compute server such as a large Sun server, a large VAX, or a vector +minisupercomputer or supercomputer, possibly quite some distance away. +This is done by logging onto the workstation, starting up SunView and a +\fIgterm\fR window, logging onto the remote machine with \fIrlogin\fR, +\fItelnet\fR, or whatever, and starting up IRAF on the remote node. +.LP +After IRAF comes up one need only type +.XS +cl> stty gterm +cl> reset node = \fIhostname\fP +.XE +to tell the remote IRAF that it is talking to a gterm window and that +the image display is on the network node \fIhostname\fR. +.PP +In this mode one is effectively using the workstation as a sort of super +terminal with powerful graphics and image display capabilities. One gets +the best of both worlds, i.e., a state of the art user interface, and the +compute power of a large machine. It matters little what operating system +is used on the remote machine, so long as it also runs IRAF. +Except for the details of the login sequence, operation is completely +transparent; gterm does not care whether the process it is talking to is +on a local or remote node. Performance, e.g,. for image loads, is often +\fIbetter\fR than when everything is run directly on the local node, +due to the more powerful server. + +.NH +Interfacing New Graphics Devices +.PP +There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +.NH 2 +Graphics terminals +.PP +The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal or terminal emulator, using the \fIstdgraph\fR +graphics kernel supplied with the system. All one need do to interface to a +new graphics terminal is add new graphcap and termcap entries for the device. +This can take anywhere from a few hours to a few days, depending on one's +level of expertise, and the characteristics of the device. Be sure to check +the contents of the dev$graphcap file to see if the terminal is already +supported, before trying to write a new entry. Useful documentation for +writing graphcap entries is the GIO reference manual and the HELP pages for +the \fIshowcap\fR and \fIstty\fR tasks (see \(sc2.2.6). Assistance with +interfacing new graphics terminals is available via the IRAF Hotline. +.NH 2 +Graphics plotters +.PP +The current IRAF system comes with several graphics kernels used to drive +graphics plotters. The standard plotter interface the SGI graphics kernel, +which is interfaced as the tasks \fIsgikern\fR and \fIstdplot\fR in the +PLOT package. Further information on the SGI plotter interface is given in +the paper \fIThe IRAF Simple Graphics Interface\fR, a copy of which is +included with the IRAF installation kit. +.PP +SGI device interfaces for most plotter devices already exist, and adding +support for new devices is straightforward. Sources for the SGI device +translators supplied with the distributed system are maintained in the +directory iraf/unix/gdev/sgidev. NOAO serves as a clearinghouse for new SGI +plotter device interfaces; contact us if you do not find support for a local +plotter device in the distributed system, and if you plan to implement a new +device interface let us know so that we may help other sites with the same +device. +.PP +The older NCAR kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +plots on devices supported by host-level NCAR metacode translators. The +host level NCAR metacode translators are not included in the standard IRAF +distribution, but public domain versions of the NCAR implementation for UNIX +systems are widely available. A site which already has the NCAR software +may wish to go this route, but the SGI interface will provide a more +efficient and simpler solution in most cases. +.PP +The remaining possibility with the current system is the \fIcalcomp\fR kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. To make use of such a library to get +plotter output on any devices supported by the interface, one may copy +the library to the hlib directory and relink the Calcomp graphics +kernel. +.PP +A graphcap entry for each new device will also be required. Information on +preparing graphcap entries for graphics devices is given in the GIO design +document, and many actual working examples will be found in the graphcap +file. The best approach is usually to copy one of these and modify it. +.NH 2 +Image display devices +.PP +The standard image display facility for a Sun workstation running the +SunView window system is \fIimtool\fR (\(sc4.3). Image display under the +MIT X window system is also available using the \fIsaoimage\fR display +server. This was developed for IRAF by SAO; distribution kits are available +from the IRAF network archive. +.PP +Some interfaces for hardware image display devices are also available, +although a general display interface is not yet included in the system. +Only the IIS model 70 and 75 are current supported by NOAO. Interfaces for +other devices are possible using the current datastream interface, which is +based on the IIS model 70 datastream protocol with extensions for passing +the WCS, image cursor readback, etc. (see the ZFIOGD driver in unix/gdev). +This is how all the current displays, e.g., imtool and ximage, and the IIS +devices, are interfaced, and there is no reason why other devices could not +be interfaced to IRAF via the same interface. Eventually this prototype +interface will be obsoleted and replaced by a more general interface. + +.NH +Host System Requirements +.PP +IRAF is currently supported on all Sun models, i.e., the Sun-3, Sun-4, +Sun-386i, and SPARCstation (as well as many systems other than Sun of course). +Any of these system will make excellent IRAF hosts. Be aware that the +386i is architecturally incompatible with the other Suns, which will cause +problems in client/server configurations. +.PP +In a typical installation +there will be a large central compute server, usually a fast Sun-4 with +several Gb of fast SMD or IPI disk and 32-64 Mb of memory, serving a number +of SPARCstation or Sun-3 or 4 nodes. For scientific use, a color screen +(16 inch is fine) and several hundred Mb of local disk is desirable. +The local SCSI disk is comparatively slow and is no substitute for the large, +fast disks on the server, but is cheap and is worthwhile for server +independence alone. The GX graphics accelerator option available on the +newer systems is attractive and is recommended, finances permitting. +.NH 2 +Memory requirements +.PP +The windowing systems used in these workstations tend to be very memory +intensive; the typical screen with ten or so windows uses a lot of memory. +With the introduction of the virtual files system in SunOS 4.0, the memory +requirements of SunOS have increased ever further. Interactive performance +will suffer greatly if the system pages a lot. Fortunately, memory is +becoming relatively cheap. No Sun system, including personal diskless +nodes, should be configured with less than 8 Mb of main memory; 20 Mb or +more is recommended if you plan to do a lot of image processing. On +servers, 32, 64, or even 128 Mb is not an unreasonable amount of memory to +try to configure the system with. +.NH 2 +Disk requirements +.PP +The amount of disk required by a user depends greatly on the application, +so it is hard to recommend a minimum disk size. For a system with access +to a central server, no disk or 200-300 Mb of local SCSI disk is fine. +For a standalone system with no access to large server, 500-600 Mb is +about the minimum. A server should have several Gb of fast disk. +.NH 2 +Diskless nodes +.PP +For an application such as programming or word processing, a diskless node +connected to a large file server is a cost effective approach delivering +good performance. Some local disk for boot, swap, and local file storage +is desirable but not essential. For most IRAF applications however, where +serious image processing is planned, one is inevitably going to want to +run large batch image processing jobs directly on the server, implying that +a \fIcompute\fR rather than \fIfile\fR server is what is needed (i.e., one +will want to avoid heavy NFS loading on the server). A diskless node is +still viable, but one will want to run jobs which involve heavy disk i/o +directly on the server, reserving the workstation for the interactive +things, e.g., graphics and image display, and compute bound image analysis +tasks. Small SCSI disks are getting cheap enough that almost any color +workstation equipped with say, 12-16 Mb of memory, probably warrants several +Mb of local disk for server independence, swap, and local file storage. + +.SH +Appendix A. The IRAF Directory Structure +.PP +A graph of the current full Sun/IRAF directory structure is given at the +end of this document. The main branches of the tree are summarized below. +Beneath the directories shown are some 300 subdirectories, the largest +directory trees being \f(CWsys\fR, \f(CWpkg\fR, and \f(CWnoao\fR. +The entire contents of all directories other than \f(CWunix\fR, \f(CWlocal\fR, +and \f(CWdev\fR are fully portable, and are identical in all installations +of IRAF sharing the same version number. +.XS +bin \fR- the IRAF BIN directories\fP +dev \fR- device tables (termcap, graphcap, etc.)\fP +doc \fR- assorted IRAF manuals\fP +lib \fR- the system library; global files\fP +local \fR- iraf login directory; locally added software\fP +math \fR- sources for the mathematical libraries\fP +noao \fR- packages for NOAO data reduction\fP +pkg \fR- the IRAF applications packages\fP +sys \fR- the virtual operating system (VOS)\fP +unix \fR- the UNIX host system interface (HSI = kernel + bootstrap utilities)\fP +.XE +.LP +The contents of the \f(CWunix\fR directory (host system interface) are +as follows: +.XS +as \fR- assembler sources\fP +bin \fR- the HSI BIN directories\fP +boot \fR- bootstrap utilities (mkpkg, rtar, wtar, etc.)\fP +gdev \fR- graphics device interfaces (SGI device translators)\fP +hlib \fR- host dependent library; global files\fP +os \fR- OS interface routines (UNIX/IRAF kernel)\fP +reboot \fR- executable script run to reboot the HSI\fP +shlib \fR- shared library facility sources\fP +sun \fR- gterm and imtool sources\fP +.XE +.PP +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. diff --git a/doc/template.ms b/doc/template.ms new file mode 100644 index 00000000..aae0842c --- /dev/null +++ b/doc/template.ms @@ -0,0 +1,16 @@ +.RP +.TL +(title) +.AU +(name) +.AI +.K2 "" "" "*" +(date) + +.AB +(abstract) +.AE + +.NH +Introduction +.PP diff --git a/doc/unixiraf.hlp b/doc/unixiraf.hlp new file mode 100644 index 00000000..448013e9 --- /dev/null +++ b/doc/unixiraf.hlp @@ -0,0 +1,833 @@ +.help install Mar86 "UNIX/IRAF Installation Guide" +.sp 3 +.ce +\fBUNIX/IRAF Installation and Maintenance Guide\fR +.ce +(draft) + +.ce +Doug Tody +.ce +March 13, 1986 + +.nh +Introduction + + The procedure for installing IRAF on a UNIX host is complicated by the +great variety of computers which run UNIX, by the many small differences in +the operating system software on these machines, and by the hardware +differences between the machines. In general, the IRAF system can be ported +with a modest effort to any UNIX host which has a reliable and reasonably bug +free Fortran compiler (this cannot be taken for granted). From the standpoint +of ease of installation and reliability, the ideal case is a VAX running 4.2BSD +Berkeley UNIX (or ULTRIX, which is the same thing), since that is the +configuration we run on the IRAF software development machine. +NOAO has also recently ported the system to a SUN workstation running the +SUN version of 4.2BSD UNIX. This is a new system which has not yet seen +heavy use within NOAO and which cannot therefore be said to be as well +tested as the VAX version, but it is already clear that it will be a good +host (the initial port took only a few hours). + +Other ports, e.g., to other workstations or to System V UNIX, have been +talked about and are certainly feasible, but NOAO cannot presently support +such systems since we do not use them internally. This should not discourage +others from developing such systems, as other advantages may outweigh the +expense of having to port and support IRAF locally. To the extent that we +are able, we will be glad to assist with such ports. In the remainder of +this document, we shall assume that the host operating system is some variant +of 4.2BSD Berkeley UNIX. + +The ideal case of installing a "load and go" distribution tape containing +a precompiled and prelinked system is easy, except possibly for the graphics +interfaces. There are various levels of installations beyond this, becoming +progressively more involved, with a port of the system to a new version of +UNIX being the most ambitious. The possible levels of installations are +summarized below. +.ih +Load and Go +The system is read onto disk, several links are made in the UNIX system +directories providing hooks into the system, and the device and network tables +are tailored for the local system. +.ih +Load and Relink +This is like load and go, except that the system was shipped without the +executables to save space. Relinking is necessary but the relinking procedure +is fully automated and does not significantly increase the difficulty of the +installation. +.ih +Full Sysgen +In this case the system tables have already been configured for the host +machine, but neither the executables nor object libraries can be used for +some reason, e.g., because we are starting with a source only distribution. +The sysgen procedure is fully automated and in principle should pose no more +problems than a relink, but in practice it is unusual to get through a full +sysgen on a new machine without encountering compilation errors, usually +due to obscure errors in the Fortran optimizer. This sounds bad, but one can +usually hand compile the affected files with the optimizer turned off, and +then restart the sysgen, which will automatically pick up where it left off. + +On the VAX we routinely perform full system sysgens without any problems +whatsoever. A full sysgen on a VAX 750 class machine requires about 45 +minutes for the bootstrap (building the host interface), plus another 20 +hours to compile and link the machine independent part of the system. +.ih +Port to a New System +To port IRAF to a new version of UNIX requires some modifications to the +files in the host interface directories, followed by a full sysgen and lots +of testing. Typically most of the code in the host interface can be used +without change, with only minor changes to the remaining code, since the +different versions of UNIX are quite similar (as compared to, for example, +a port to a completely different operating system like VMS or AOS/VS). + +Note that even when the target system is a "fully compatible" 4.2BSD UNIX +system, some changes are likely to be necessary since all of these systems +are slightly different. For example, the SUN and ISI implementations of +4.2BSD UNIX employ different assemblers, and the Fortran compilers on the +two systems have diverged considerably. A port to Bell System V or one of +the UNIX look alikes would certainly require some changes to the IRAF kernel, +particularly in the exception handling, process control, and network interface +facilities. + +The changes required are likely to be minor for someone sufficiently familiar +with both IRAF and UNIX, but should not be underestimated. Every new port +produces its share of compile time errors (due to differences in the Fortran +compilers) and finds a few new bugs, both in the IRAF software and often in +the host Fortran compiler as well. A thorough understanding of both IRAF and +the host system is required to rapidly isolate such bugs. +.in -4 + +Fortunately, a port only has to be done once and most of the sites receiving +UNIX/IRAF will not need to do more than a relink or a sysgen, both of which +are straightforward. Many sites will not even need to relink, in which case +the installation is trivial. + +Once the basic system is functioning, it is still necessary to edit the device +and network tables to interface IRAF to the local terminals, printers, magtape +devices, describe the nodes in the local network, and so on. +Once that is done only the graphics device interfaces are left. +Conventional graphics terminals, i.e., Tektronix +compatibles with a serial interface, are not difficult. The worst case is +a new bit mapped display or image (greyscale) display device, which may +require the implementation of a new IRAF GIO graphics kernel for the device. + +The IRAF system is organized in such a way that the machine and device +dependent software is stored separately from the bulk of the software, +which is machine and device independent. This should make it relatively +easy to install new revisions of the system, provided the host and device +interfaces do not have to be modified. The procedure for installing a +minor revision is simply to read the revision tape into the system (containing +the BIN, DOC, LIB, SYS, PKG, and MATH directories), and then possibly do a +partial or full sysgen, depending upon whether the distribution included +executables and objects. The local device and network tables will not be +affected since they are stored in different directories (HOST and DEV) than +those on the tape. Note that a "minor" revision actually updates virtually +the entire system, since the host system interface is small compared to the +rest of the system. + +When a major revision is received it will be necessary to reinstall the +full system, but it is likely that the old device tables can be kept and +used in the new system, in which case even a full installation should only +take a couple of hours, excluding the time for a full sysgen if such is needed. +Once the initial version of IRAF has been installed, the procedure for +installing a minor revision is identical for all systems, including such +systems as VMS and AOS/VS as well as UNIX. + +Sites which are actively using IRAF will probably want to keep their systems +up to date, as the system is continually evolving and improving, and new +software is continually being added. To ensure that it will be easy to +install future updates, it is wise to store locally added software outside +the standard system, and to keep a log of all revisions, if any, made to +the standard system. The subdirectory LOCAL (off the IRAF root directory) +is provided for this purpose. NOAO should be informed of any local revisions +or bug fixes so that we have the opportunity to incorporate them in the +standard system. + +.nh +Installing the System +.nh 2 +Initial System Installation + + This section documents the procedure for installing a binary distribution +tape prepared on a compatible (VAX or SUN) system at NOAO. The procedure +outlined in this section is also used to install a source distribution, the +difference being that when one is done it is still necessary to do a sysgen +to compile and link the system. + +Few problems are expected when installing binary distributions for the VAX, +since all VAX hardware and (UNIX) software is pretty much the same. +For a system like the SUN this is not necessarily the case, e.g., a SUN-3 +distribution will have to be recompiled to run on a SUN-2, and a SUN-2 +distribution compiled with inline floating point instructions for the SKY +floating point board will have to be recompiled if the SKY board is not present. +Conversely, a system compiled with the SUN-2 portable floating point interface +will run whether or not the SKY board is present, but it might be desirable +to recompile the system with the inline code generation option, just for the +added speed. If you have received a binary SUN distribution, be sure to +check the system (SUN-2/3), operating system version, and floating point +compiler option used for compatibility with your system. + +.nh 3 +Create an IRAF Account + + The first step is to set up an account for IRAF. The pathname to the +root directory does not matter, but it is wise to keep it short to speed up +pathname resolution and to minimize the possibility of filename truncation. +The account should be set up to use \fBcsh\fR as the shell. The disk +partition containing IRAF should have about 45 Mb of space available for +the system; if necessary, the system can be stripped later to save space, +but the full 45 Mb is required for the installation. + +In what follows, we shall refer to the IRAF root directory as "$iraf", +as if it were a cshell \fBsetenv\fR variable. It is not however necessary to +define such a variable at this point, provided you do not try to type it +in as shown in the examples (type in the full pathname instead). + +.nh 3 +Read the Distribution Tape + + The system is distributed on one or more TAR format tapes or cassettes. +Login as IRAF, go to the IRAF root directory, and enter the \fBtar\fR command +shown for each tape in the distribution kit. The order in which the tapes +are read is not important. + +.ks +.nf + % cd $iraf + % tar -xpf /dev/XXXX +.fi +.ke + +The full system contains approximately 6000 files in over 200 directories; +the \fBtar\fR flags -tv are not recommended, as printing the filename can +slow things down considerably. It typically takes a half hour or so to read +the tapes. + +.nh 3 +Set up the Host System Environment + + Login as root (type \fIsu\fR) and modify the IRAF account to make +$iraf/local the login directory for user IRAF (this is done by editing the +/etc/passwd file - use \fIvipw\fR). Enter the following commands to enable +device allocation within IRAF. This only works if you have a binary +distribution; if not, it must be done later after the system has been +bootstrapped. + +.ks +.nf + % cd $iraf/unix/hlib + % /etc/chown 0 alloc.e # (zero, not "oh") +.fi +.ke + +While still logged in as root, make the following symbolic links in the +standard UNIX directories. We assume here that local utility programs are +installed in /usr/bin, but a different directory may be used for this +purpose on your system (any public directory which is in the default \fIpath\fR +for the average user will do). Since these are symbolic links, this +step may be performed even if a source distribution is being installed. + +Symbolic links are preferred to file copies because IRAF is a self contained +system and is not set up to install executables, etc. in external host system +directories. Symbolic links also eliminate the possibility of the installed +version of the file being obsolete. Although we use links here, no links are +used within the IRAF system itself. + +.ks +.nf + % cd /usr/include + % ln -s $iraf/unix/hlib/libc/iraf.h . + % cd /usr/bin + % ln -s $iraf/bin/cl.e cl + % ln -s $iraf/unix/hlib/mkiraf.csh mkiraf + % ln -s $iraf/unix/hlib/mkpkg.e mkpkg +.fi +.ke + +The following additional links are optional but are desirable if any IRAF +programming is anticipated. An alternative is to "source" the file +"$iraf/unix/hlib/irafuser.csh" in one's .login file (this only works for cshell +users). + +.ks +.nf + % ln -s $iraf/unix/hlib/generic.e generic + % ln -s $iraf/unix/hlib/rmbin.e rmbin + % ln -s $iraf/unix/hlib/rmfiles.e rmfiles + % ln -s $iraf/unix/hlib/rtar.e rtar + % ln -s $iraf/unix/hlib/wtar.e wtar + % ln -s $iraf/unix/hlib/xc.e xc +.fi +.ke + +Logout of root. If this is done by exiting "su", type "rehash" to make the +cshell aware of the new programs. + +.nh 3 +Configure the IRAF Environment + + While once again logged in as IRAF, edit the .login file in the IRAF +login directory $iraf/local. The \fBsetenv iraf\fR definition must be +changed to reflect the new IRAF root directory; everything else is optional +and may be personalized if desired. Note that IRAF assumes that all host +directory pathnames may be concatenated with a filename to produce the +pathname of the file, hence the directory pathname MUST end with a slash, +contrary to normal UNIX convention. + +.ks +.nf + % cd + % vi .login + % source .login +.fi +.ke + +After editing the .login file, "source" it to pick up the new environment +definitions. Hereafter we shall assume that the directories $iraf, $hlib, +etc. have been defined in the cshell environment by the .login file. At this +point you may want to read the file $hlib/irafuser.csh to see what has been +defined. + +There are several files in $hlib (the host system interface library) which +must now be edited to reflect the host system. Edit the following definitions +in the file $hlib/mkiraf.csh (the trailing slashes are omitted in this case +because this script is pure UNIX). The \fBmkiraf\fR script is run by the user +to autoconfigure the IRAF environment; see the CL User's Guide for additional +information on the use of this task. + +.ks +.nf + set iraf = "/iraf" + set imdir = "/tmp2/iraf" + set ttymsg = "Terminal types: vt100=basic terminal, ..." +.fi +.ke + +Set the value of \fBimdir\fR to the pathname of a public scratch directory +to be used for the storage of bulk image data. The \fBmkiraf\fR script +will create the default user image storage directories as subdirectories of +this directory. A scratch rather than user (login directory) file system is +normally used for this purpose to avoid storing bulk data on a backed up +user file system, and to facilitate the use of file deletion daemons to +automatically delete old files. Note that the user may override the default +\fBimdir\fR pathname defined in the LOGIN.CL file created by \fBmkiraf\fR. + +The \fBttymsg\fR prompt string is printed by the script to help the user +set the default terminal type for IRAF. Each terminal must have an entry +in the IRAF (not UNIX) \fBtermcap\fR file. + +Now descend to the subdirectory LIBC and edit the file "iraf.h", for which +we earlier made a symbolic link. This global C header file is required to +compile any IRAF C sources, and is also used by the system at runtime to +determine the IRAF root directory, as well as the pathnames of the HOST +and TMP logical directories. The definition of TMP defaults to the standard +UNIX /tmp and should not have to be changed. Make the obvious change to +the definitions of HOST and IRAF; HOST is the unix pathname of $iraf/unix. +This has to be defined at the system level because HOST might be, for example, +$iraf/vms instead of $iraf/unix. HOST is the root directory of the IRAF +host system interface. The remainder of the file contains many occurrences +of the pathname to the IRAF root. Use global replacement to change all +these definitions to the new IRAF root. + + +Assuming a full binary distribution, it should now be possible to return to +the IRAF login directory, type \fBmkiraf\fR to configure the IRAF environment, +and then \fBcl\fR to log into IRAF. Indeed, any user should be able to do +the same at this point. + +.ks +.nf + % cd + % mkiraf + % cl +.fi +.ke + +.nh 2 +Relinking the System + + Relinking the system is necessary if the system was shipped without +the executables in the BIN directory. In order to relink the system must +first have been \fIbootstrapped\fR. When the system is shipped without +executables (to save space) it will already have been bootstrapped. +If it is necessary to bootstrap the system, e.g., given a source only +distribution, go read section 2.4 before trying to relink the system. + +The system is relinked by the bootstrap utility program \fBmkpkg\fR. +The \fBmkpkg\fR program is driven by the MKPKG files found in all IRAF +source directories. Running \fBmkpkg\fR in a directory causes the +contents of that directory, normally an applications package or library, +to be updated, along with the contents of all subdirectories referenced +by the root MKPKG file. + +Running \fBmkpkg\fR in the root IRAF directory causes the entire system to +be updated. If the system libraries are all up to date, the effect is to +relink the system. If the system has been modified and some library modules +have to be recompiled and inserted into the system libraries, then the +operation is a partial sysgen. If there are no libraries or object libraries +then we have a full sysgen, which is the topic of the next section. +The \fBmkpkg\fR utility is documented in detail in the IRAF User's Guide, +in the manual pages for the \fBsoftools\fR package. + +To relink all of IRAF, go to the root and run \fBmkpkg\fR, i.e., + +.ks +.nf + % cd $iraf + % mkpkg +.fi +.ke + +The program will inspect all source modules and verify that the system +libraries are up to date, then relink the system executables, followed by +all the applications executables, installing the executable files in the +BIN directory. + +.nh 3 +Relinking Individual Packages + + It is just as easy to relink the individual IRAF packages, e.g., after +a bug has been fixed, or if an update of a package is received by electronic +mail. This would normally be done from within IRAF since the next step +is to test the new package, so we will use the "cl>" prompt in the examples, +but since \fBmkpkg\fR is a bootstrap utility (IRAF foreign task), usage is +the same both in IRAF and in UNIX. + +To relink a package and install the new executable in BIN: + + cl> mkpkg update + +To relink a package, leaving the executable in the package directory for +testing or debugging prior to installation: + + cl> mkpkg + +To install an already linked executable after testing: + + cl> mkpkg install + +To update only the package library without relinking (this assumes that the +name of the library is LIBPKG.A): + + cl> mkpkg libpkg.a + +The "update", "install", and "libpkg.a" identifiers are entry points in the +MKPKG file, which may be read to see what is going on. + +As an actual example of a package relink, suppose we wanted to increase the +size of the stack area in the CL to 8000 elements, e.g., because the CL was +running out of space at runtime. We would go to the CL directory, edit +the file CONFIG.H, change the value of STACKSIZ to 8000, and then run +\fBmkpkg\fR: + +.ks +.nf + cl> cd cl + cl> ed config.h + cl> mkpkg update +.fi +.ke + +Since CONFIG.H is included by nearly all the CL source files, the entire +package would be recompiled unnecessarily, but it is safer that way. + +.nh 2 +Autogeneration of the System (SYSGEN) + + A full system sysgen is necessary when installing a source only version +of the system. The system must first have been bootstrapped; see section +2.4 if this has not yet been done. A full sysgen may also be necessary if +a binary distribution has been received but it is later discovered that it is +necessary or desirable to recompile the system. In this case the existing +libraries and objects must be deleted before the sysgen, else the sysgen +will be nothing more than a relink. The \fBrmbin\fR utility is used to +descend a directory tree, deleting all binary files therein. Note that +the ONLY case in which it is necessary to use \fBrmbin\fR is when we wish +to force the entire system to be recompiled. The \fBrmbin\fR task is yet +another bootstrap utility, and is documented in the manual pages for the +\fBsoftools\fR package. + +.ks +.nf + % cd $iraf + % rmbin -vi bin lib pkg sys +.fi +.ke + +This will delete all binaries in the portable part of the system, excluding +the HOST or UNIX directories (if you run \fBrmbin\fR on UNIX, you will have +to bootstrap the system as well). + +Before starting the full system sysgen it may be desirable to review the +switches in the file MKPKG.INC in the HLIB directory. +This is the global include file for the \fBmkpkg\fR utility, +and contains various switches controlling \fBmkpkg\fR, e.g., which packages +will be compiled, and the default compiler and linker flags. + +Since a full sysgen takes a long time and generates a lot of output which +later has to be reviewed, they are always run in batch with the output +redirected, e.g.: + +.ks +.nf + % cd $iraf + % mkpkg >& spool & +.fi +.ke + +To watch what is going on after this command has been submitted and while +it is running, try + + % tail -f spool + +Sysgens are restartable, so if the sysgen aborts for any reason, simply +fix the problem and start it up again. + +A full sysgen generates a lot of output, too much to be safely reviewed for +errors by simply paging the spool file. Enter the following command to review +the output (this assumes that the output has been saved in a file named +SPOOL). + + % mkpkg summary + +It is normal for a number of compiler messages warning about assigning +character data to an integer variable to appear in the spooled output. +These are harmless on most (but not all) machines, and are due to questionable +coding practices in the old (pre-F77) NCAR graphics utilities. Hopefully the +problem will be fixed in an upcoming release by NCAR. + +The discussion up to now has centered on the full system sysgen. +Partial sysgens are actually much more common. For example, if an important +bug is fixed in the VOS or in the IRAF kernel, a (partial) sysgen should be +conducted to recompile the affected modules and relink the system. +An example of this occurs when the \fBtermcap\fR or \fBgraphcap\fR entries +for important local devices are cached by running the \fBttycompile\fR +task (another \fBsoftools\fR utility). A sysgen is required after regenerating +the cache tables, since these must be compiled and linked into the affected +programs to have any effect. + +.nh 2 +Bootstrapping the System + + A bootstrap is like a full system sysgen, except that it is the host +system interface (kernel and bootstrap utilities) which are compiled and +linked, rather than IRAF itself. The system must be bootstrapped before +a sysgen is possible, since the bootstrap utilities are required to do a +sysgen. The two operations are distinct because only the bootstrap is +machine dependent; everything else works the same on all IRAF systems. + +The bootstrap operation is necessary when installing the system from a +source only distribution tape. We assume that the files in the host system +interface have already been configured for the host system. If this is +not the case, then we are doing a port, which is a lot more ambitious than +a simple bootstrap. + +To bootstrap UNIX/IRAF, go to the UNIX directory and interpret the shell +script MKPKG.CSH. This takes about 45 minutes, so the output should be +spooled in a file. Note that (for no good reason) the files have a .CSH +extension even though we have chosen to use the Bourne shell to execute +the commands therein. + +.ks +.nf + % cd $iraf/unix + % sh -x mkpkg.csh >& spool & +.fi +.ke + +A bootstrap recompiles everything whether it needs to or not, so it is +usually not necessary to delete the binaries before doing a full bootstrap. + +.nh 2 +Configuring the IRAF Device Tables + + The following files should now be edited to define the default terminal, +printer, editor, and so on for your system. Any part of this can be left +until later if desired. + +.ls 4 \fB$hlib/zzsetenv.def\fR +This file contains the name of the default editor, the default names of all +the standard devices, and a number of other definitions which are not site +dependent and which can therefore be ignored. To be accessible by the IRAF +system, each local device named must also have an entry in the TERMCAP file +(terminals and printers) or GRAPHCAP file (graphics terminals and image +displays) in DEV. There must also be an "editor.ED" file in DEV +for the named editor; EDT, EMACS, and VI are currently supported. +Edit the string to the right of the equals sign for the following entries. +Sample values are shown. + +.ks +.nf + set editor = "vi" + set printer = "imagen" + set stdgraph = "vt640" + set stdimage = "iism70l" + set stdplot = "versatec" + set terminal = "vt640" +.fi +.ke + +For example, you may wish to change the default editor to "emacs" (heaven +forbid), the default printer to "versatec", the default image display to +"iism75", and the default terminal to "vt100". Note that only the IIS model +70 and 75 image displays are directly supported by the current system. +Display code is also available for the DeAnza displays from STScI for VMS +hosts, but nothing is currently available for UNIX hosts (NOAO will directly +support the DeAnza sometime in 1986). The complex issues of the graphics +and display interfaces are discussed more fully in a later section. +.le + +.ls 4 \fB$iraf/dev/devices\fR +This file contains a list of the allocatable devices (primarily tape drives) +for the local system. It should be obvious how to change it by reading the +comments in the file and studying the current values, which are for our system. +.le + +.ls 4 \fB$iraf/dev/termcap\fR +There must be entries in this file for all local terminal and printer +devices you wish to access from IRAF (there is no \fBprintcap\fR file in IRAF). +The entry for a printer contains one special (non-\fBtermcap\fR) entry, +called DD. This consists of three fields: node!device, the template for the +temporary spoolfile, and the UNIX command to be used to dispose of the file to +the printer. On Berkeley UNIX it is rarely necessary to make use of the node +name capability, since the UNIX \fBlpr\fR already provides this capability. + +If you have a new terminal which has no entry in the termcap file provided, +you probably already have an entry in the UNIX termcap file. Simply copy it +into the IRAF file; both systems use the same termcap database format. +.le + +.ls 4 \fB$iraf/dev/graphcap\fR +There must be entries in this file for all graphics terminals, batch plotters, +and image displays accessed by IRAF programs. Weird graphics terminals will +need a new entry. The IRAF file "sys$gio/doc/gio.hlp" contains docs for +graphcap. A printed copy of this document is available upon request, however +once IRAF is up you may find it easier to generate your own copy using HELP, +as follows: + +.nf + cl> cd sys$gio/doc + cl> help gio.hlp fi+ | lprint +.fi + +The manual page for the \fBshowcap\fR task should also be printed since this +utility is useful for generating new graphcap entries. More focused +documentation will be available eventually. Telephone consultation is +available for those who need it. We ask that new graphcap entries be sent +back to us so that we may include them in the master graphcap file for other +sites to use. +.le + +.ls +The DEV directory also contains a number of files (HOSTS, HOSTLOGIN, and UHOSTS) +used by the IRAF network software. We depend upon the networking capabilities +of IRAF heavily at NOAO to access image displays, printers, files, etc. resident +upon remote nodes (the IRAF network interface is also capable of spawning +subprocess and background jobs on remote nodes, and works even when the nodes +run different host operating systems, e.g., both UNIX and VMS). + +We expect that most sites will not need this capability initially, hence +documentation of the networking software will be left for later. For sites +that want to try it out, all that is necessary to enable networking is to +edit the three networking files in the DEV directory, and install IRAF on +the other nodes. It does not matter what native operating system runs on the +remote nodes, so long as it runs IRAF as well. The source for the network +interface is in the sys$ki directory, and a discussion of the conceptual +design of the interface is given in the README file in that directory. +.le + +.nh 2 +Login to IRAF and Run the Test Procedure + + Congratulations! You should now have a fully functional IRAF system. +At this point it would probably be wise to read the CL User's Guide, +if you have not already done so. Once the IRAF environment is configured +with \fBmkiraf\fR (discussed earlier) one need only enter the CL command +to start up the CL. After a bit IRAF should print the message of the day +and the root menu, and issue the "cl> " prompt. + + % cl + +Once in the CL, you will probably have magtape and printer access, are likely +to have graphics terminal access, and very possibly will not have either +image display access or graphics plotter access. If the graphics terminal +capability is ready the next step is to run the IRAF test procedure to +verify that all is working well, as well as try out a few of the many tasks +in the system. If the graphics terminal is not up yet, there is probably +no point in running the test procedure. To run the test procedure, read +the documentation in volume 1A of the IRAF User's Guide and follow the +instructions therein. + +.nh +Tuning Considerations + + There are two things that are commonly done to tune UNIX/IRAF for a +particular host system: + +.nf + o Precompile selected TERMCAP and GRAPHCAP entries + o Strip the system to reduce disk consumption +.fi + +.nh 2 +Precompiling TERMCAP and GRAPHCAP Entries + + Precompilation of a termcap or graphcap entry is a technique used to +speed runtime access of the entry for that device. If the entry is not +precompiled the termcap or graphcap file must be physically opened and +scanned at runtime to read the desired entry. This causes a noticeable +delay of as much as a second when clearing the terminal screen or plotting +a graph, hence it is usually worthwhile to cache the entries for commonly +used video and graphics terminals. It is not worthwhile for printers, +plotters, and image displays. + +The system comes with selected termcap and graphcap entries already +precompiled. To see which devices are precompiled, page the cache data +files, dev$cachet.dat (for termcap) and dev$cacheg.dat (for graphcap). +To cache a different set of entries one must regenerate these files with the +\fBmkttydata\fR task in the \fBsoftools\fR package, and then do a full +sysgen with the \fBmkpkg\fR utility. Detailed instructions are given in +the manual page for \fBmkttydata\fR. + +.nh 2 +Stripping the System to Reduce Disk Consumption + + If the system is to be installed on multiple cpus, or if a production +version is to be installed on a workstation, it may be necessary or desirable +to strip the system of all non-runtime files to save disk space. +This equates to deleting all the sources and all the reference manuals and +other documentation, excluding the online manual pages. A special utility +called \fBrmfiles\fR (in the \fBsoftools\fR package, of course) is provided +for this purpose. It is not necessary to run \fBrmfiles\fR directly to strip +the system. The preferred technique is to enter the commands given below. +The example is for the cshell for consistency with the rest of this document, +but this could be done from within the CL as well. + +.nf + % cd $iraf + % mkpkg strip +.fi + +This will preserve all runtime files, permitting use of the standard system +as well as user software development. The size of the system is reduced +from about 41 Mb (megabytes) to around 19 Mb. One can optionally enter the +command "mkpkg stripall" to delete the system libraries as well, but this +saves only another couple of Mb and a full sysgen or a tape reload will be +required to regain the capability to link user programs with the IRAF +libraries, or relink the IRAF executables. + +.nh +Interfacing to New Graphics Devices + + There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +The topic of interfacing to these devices has already been discussed in +the letter which was sent out with the IRAF questionnaire, hence the +discussion given here will be brief. + +.nh 2 +Graphics Terminals + + The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal, using the \fBstdgraph\fR graphics kernel +supplied with the system. All one need do to interface to a new graphics +terminal is add a new graphcap entry for the device. This can take anywhere +from a few hours to a few days, depending on one's level of expertise, and the +perversity of the device in question. + +The fancy bit mapped, high resolution graphics displays common on "workstations" +like the MicroVax and the SUN cannot be driven (very well) by the existing +\fBstdgraph\fR graphics kernel. We are actively developing new graphics kernels +for these devices, and they should be available later this year. These systems +often come with some graphics software, e.g., CORE, GKS, or CGI, but a good +interface requires interaction with the window management software as well, +hence each workstation will probably require a customized graphics kernel. + +.nh 2 +Graphics Plotters + + The current IRAF system comes with three graphics kernels usable to drive +graphics plotters. Additional kernels are under development to interface the +IRAF graphics subsystem to GKS, CGI, and CORE. + +The \fBstdgraph\fR kernel can in principle be used to make +plots on many devices by using a Tek graphcap entry, redirecting the Tek +drawing instructions into a file, and using the Tek emulation software that +comes with most plotters to generate the plot. A more streamlined interface +is possible but is not yet available. + +The supplied \fBstdplot\fR kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +excellent plots on the Versatec, Imagen, and other similar devices if NCAR +metacode translators are available. This is the kernel we currently depend +upon most heavily at NOAO for plotter output. + +Unfortunately, the host level NCAR metacode translators are not included in +the standard IRAF distribution but are required for a plot. The necessary +software is however in the public domain and is in use at NOAO, hence is +available upon special request. + +The remaining possibility with the current system is the \fBcalcomp\fR kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. It should be possible to edit the name +of the library in the hlib$mkpkg.inc file and relink the Calcomp graphics +kernel to get output on any devices supported by the library. +The following commands should suffice to relink and install the Calcomp +graphics kernel, assuming a Calcomp library is available locally: + +.nf + % cd $iraf/sys/gio/calcomp + % mkpkg update +.fi + +A graphcap entry may also be required. + +.nh 2 +Image Displays + + The IRAF system as currently supported directly supports only the +IIS model 70 and 75 image displays (a Peritek interface of sorts is +also available for VAX/UNIX hosts). The 8 bit color display for the SUN-3 +is on order and we expect to use it for image display. We are expecting +to take delivery of a MicroVax with bit mapped graphics display and DeAnza +image display later this year. + +We cannot do much to help sites with other image displays until the new +IRAF display interface (which will be based on the IDI standard) is completed. +Work is scheduled to begin on this in the spring, hence the software should +become available this summer or fall. The new interface and associated TV +package software will be a great improvement over what is currently available; +the current interface is a prototype and is quite minimal, e.g., it does +not support image cursor readback, although it is fine for image display. + +In the meantime, the simplest approach is to use the new IMFORT interface +and whatever non-IRAF display software you currently have to construct +an interim display program. The IMFORT library provides host system Fortran +or C programs with access to IRAF images. The only documentation +currently available for IMFORT is the README file in the directory +$iraf/sys/imio/imfort. Sample Fortran programs and a UNIX make script +showing how to link are given in the same directory. + +.nh +The IRAF Directory Structure + + The current IRAF directory structure (new directories are constantly +being added) is documented in the Appendix. The main branches of the tree +are the following. + +.nf + bin - installed executables + dev - device tables (termcap, graphcap, etc.) + doc - assorted IRAF manuals + lib - the system library; object libraries, global files + local - your login directory + math - sources for the mathematical libraries + pkg - the IRAF applications packages + sys - the virtual operating system (VOS) + unix - the UNIX system interface (kernel + bootstrap utilities) + vms - the VMS system interface (kernel + bootstrap utilities) +.fi + +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. +.endhelp diff --git a/doc/unixiraf.ms b/doc/unixiraf.ms new file mode 100644 index 00000000..1f8ea7bd --- /dev/null +++ b/doc/unixiraf.ms @@ -0,0 +1,1004 @@ +.RP +.TL +UNIX/IRAF Installation and Maintenance Guide +.AU +Doug Tody +.br +Steve Rooke +.AI +.K2 "" "" "*" +.br +August 1987 + +.AB +The procedure for installing IRAF on a UNIX host is described. +Procedures are given both for the initial system installation, +and for updating an existing installation with a new version of IRAF. +The interfaces for site specific devices such as video terminals, +graphics terminals, printers, plotters, image displays, and so on are +discussed, and the steps to be taken to interface a new device are +described. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling the System\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Initial System Installation\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'Create the `iraf' account\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'Read the distribution tape\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.1.3.\h'|1.5i'Run the INSTALL script\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.1.4.\h'|1.5i'Relink the system if necessary\l'|5.6i.'\0\04 +.br +\h'|0.4i'2.2.\h'|0.9i'Updating an Existing IRAF Installation\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Save Locally Modified Files\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Read the Distribution Tape or Tapes\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Restore Site-Dependent Files\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.2.4.\h'|1.5i'Run the INSTALL Script\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.3.\h'|0.9i'Configuring the IRAF Device Tables\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.3.1.\h'|1.5i'$hlib/zzsetenv.def\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.3.2.\h'|1.5i'$iraf/dev/devices\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.3.3.\h'|1.5i'$iraf/dev/termcap\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.3.4.\h'|1.5i'$iraf/dev/graphcap\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.3.5.\h'|1.5i'Network Tables\l'|5.6i.'\0\08 +.sp +3.\h'|0.4i'\fBTesting the System\fP\l'|5.6i.'\0\08 +.sp +4.\h'|0.4i'\fBReconfiguring the System\fP\l'|5.6i.'\0\09 +.br +\h'|0.4i'4.1.\h'|0.9i'Bootstrapping the System\l'|5.6i.'\0\09 +.br +\h'|0.4i'4.2.\h'|0.9i'Relinking the System\l'|5.6i.'\0\09 +.br +\h'|0.9i'4.2.1.\h'|1.5i'Relinking individual packages\l'|5.6i.'\0\010 +.br +\h'|0.4i'4.3.\h'|0.9i'Autogeneration of the System (SYSGEN)\l'|5.6i.'\0\010 +.br +\h'|0.4i'4.4.\h'|0.9i'New Ports\l'|5.6i.'\0\011 +.sp +5.\h'|0.4i'\fBTuning Considerations\fP\l'|5.6i.'\0\012 +.br +\h'|0.4i'5.1.\h'|0.9i'Precompiling TERMCAP and GRAPHCAP Entries\l'|5.6i.'\0\012 +.br +\h'|0.4i'5.2.\h'|0.9i'Stripping the System to Reduce Disk Consumption\l'|5.6i.'\0\012 +.sp +6.\h'|0.4i'\fBInterfacing New Graphics Devices\fP\l'|5.6i.'\0\013 +.br +\h'|0.4i'6.1.\h'|0.9i'Graphics Terminals\l'|5.6i.'\0\013 +.br +\h'|0.4i'6.2.\h'|0.9i'Graphics Plotters\l'|5.6i.'\0\013 +.br +\h'|0.4i'6.3.\h'|0.9i'Image Displays\l'|5.6i.'\0\014 +.sp +7.\h'|0.4i'\fBThe IRAF Directory Structure\fP\l'|5.6i.'\0\014 + +.nr PN 0 +.bp +.NH +Introduction +.PP +The procedure for installing IRAF on a UNIX host is complicated by the great +variety of computers which run UNIX, by the many small differences in the +operating system software on these machines, and by the differences in the +hardware configurations of the various machines. Fortunately, however, +most sites installing UNIX/IRAF will be installing IRAF on a system which +is already directly supported by NOAO, in which case the installation should +be straightforward. +.PP +This system installation and maintenance guide describes those operations and +procedures which are the same regardless of the peculiarities of each vendor's +UNIX implementation. To install or update IRAF on a specific machine you +will need both this manual and the installation notes for your particular +host system. For example, to install IRAF on a Sun workstation you will +follow the instructions given in this manual, plus those given in the +\fISun/IRAF Installation Notes\fR. +.PP +The distribution tape is a snapshot of one of our local (NOAO/Tucson) UNIX/IRAF +systems. The device and system configuration tables come configured for our +system, and will have to be modified as part of the installation process. +These modifications are discussed in detail in this document. +To simplify the installation process as well as future upgrades, we have tried +to isolate the site dependent files to the minimum number of directories, i.e., +\fLdev\fR, \fLhlib\fR (a subdirectory of \fL$iraf/unix\fR), and \fLlocal\fR and its +subdirectories. The remainder of the system should not require any +modifications. +.sp +.TS +center; +cb s s +l l l. +IRAF HOTLINE +.sp +telephone \fL(602) 323-4160\fP +internet iraf@noao.arizona.edu +BITnet iraf@noao.arizona.edu + (via Wisconsin gateway until 1 Dec 87) +SPAN/HEPnet (DECnet) draco::iraf or 5356::iraf +UUCP/Usenet seismo!noao!iraf, ihnp4!noao!iraf, + uunet!noao.arizona.edu!iraf (after 1 Sept 87) +.TE +.PP +An installation typically takes about an hour, somewhat longer if relinking is +necessary. Interfacing new graphics terminals, plotters, or image displays +can take considerably longer, of course, and we will only touch upon such +matters in the installation guide. Feel free to contact the IRAF hotline for +assistance if any problems should arise during the installation, or for help +in interfacing new devices. + +.NH +Installing the System +.PP +The procedures to be followed to install the system depend upon whether you +are installing IRAF for the first time, or merely updating an existing IRAF +installation. If you updating an existing installation to the latest IRAF +release you have less work to do, as you will have already modified the +site-dependent files as part of the previous installation. +Proceed to \(sc2.2 if that is the case. + +.NH 2 +Initial System Installation +.PP +This section documents the procedure for installing a binary distribution +tape prepared on a compatible (VAX, Sun, or Microvax) system at NOAO. +The procedure outlined in this section is also used to install a source +distribution, the difference being that when one is done it is still +necessary to do a sysgen to compile and link the system. +If you have already installed IRAF and are merely installing a new release +of the system, proceed to \(sc2.2 instead of following the procedure +outlined here. +.LP +The basic system installation procedure is as follows: +.RS +.IP \(bu +create the `iraf' account +.IP \(bu +read the distribution tape or tapes (UNIX \fItar\fR format) +.IP \(bu +run the \fLinstall\fR script +.IP \(bu +configure the device tables +.RE +.PP +This should suffice for the basic installation of a full binary distribution. +If executables were not included with the distribution (a "you relink" type +distribution) then relinking will also be necessary, but this is easy. +In some cases it may be desirable to delete all binaries and recompile the +entire system, e.g., to reconfigure the system for different floating point +hardware. Once the basic system is up and running it will still be necessary +to provide interfaces for the terminals, printers, plotters, and so on in +use at your site, in order to have a fully functional system. + +.NH 3 +Create the `iraf' account +.PP +The first step is to set up an account for user `iraf'. +IRAF is a big system and we do not recommend trying to install it as a +subdirectory of someone's personal account. IRAF system maintenance +should be performed by the IRAF system manager while logged into the `iraf' +account, to ensure that the environment is properly configured to run the +system management tools. Ordinary users should not have write permissions +on the IRAF directories to avoid accidental deletion of critical files. +.PP +The pathname to the root directory does not matter, but it is wise to keep +it short to speed up pathname resolution and to minimize the possibility +of filename truncation. A typical IRAF root directory is "\fL/usr/iraf\fR" +or "\fL/u/iraf\fR". The account should be set up to use \fL/bin/csh\fR as the +standard shell. The disk partition containing IRAF should have about 60 Mb +of space available for the system; if necessary, the system can be stripped +later to save space, but the full 60 Mb is required during system installation. +.PP +In what follows, we refer to the IRAF root directory as "\fL$iraf\fR", as if it +were a cshell \fIsetenv\fR environment variable. Note that during the +initial stages of the installation this variable may not yet be defined, +hence you should be prepared to manually substitute the actual pathname +when entering the commands shown. +.PP +Contrary to common practice, +the login directory for `iraf' is not \fL$iraf\fR as one would expect, +but \fL$iraf/local\fR. This is done so that all local files may be kept +in one place, apart from the standard system. This simplifies system +updates and makes it easier to keep track of locally added or modified files. +When creating the iraf account be sure to set up the root directory in this +way, else when you later login as `iraf' you will not access the +standard \fL.login\fR etc. files in the \fL$iraf/local\fR directory. + +.NH 3 +Read the distribution tape +.PP +The system is distributed on one or more UNIX \fItar\fR format tapes or +cassettes. Login as IRAF, go to the IRAF root directory, and enter the +\fLtar\fR command shown for each tape in the distribution kit. +The order in which the tapes are read is not important. +Note that the \fL$iraf/local\fR directory, \fL.login\fR file, +etc., will not be created +until the tape is read, so the login will not be completely successful, +but this is harmless. Note also that the environment variable \fIiraf\fR +has probably not yet been defined, so you must substitute the actual +pathname to the iraf root directory when entering the commands shown below. +.DS +\fL% cd $iraf +% tar -xpf /dev/\fIdevice\fR +.DE +The full system contains something like 7000 files in over 250 directories; +printing the filenames (e.g., with \fLtar -tv\fR) as the tape is read is not +recommended, as this can slow things down considerably. +It typically takes a half hour or so to restore the tape or tapes to disk. +.NH 3 +Run the INSTALL script +.PP +Once the system has been restored onto disk, most of the remaining work +required for the basic installation is done by the semi-automated \fIinstall\fR +script supplied with the system. The install script edits various IRAF system +configuration files to reflect the pathname to IRAF on the local system, +and installs a few links in standard UNIX directories to define the UNIX +level tasks necessary for the user to start up IRAF. +.PP +The install script may be run in "do-nothing" mode by specifying the -n +option on the command line, as in the example below. This is recommended +the first time the script is run so that you can see what questions will be +asked and what the script will do, without actually doing anything. +.DS +\fL% cd $iraf/unix/hlib +% install -n\fR +.DE +The script will make educated guesses regarding the pathname to the iraf +root directory, the pathname to the UNIX directory where locally added +commands are normally put, and the pathname to the public scratch directory +(\fLimdir\fR) where bulk image data is to be stored, +and then ask for you to enter +the pathnames to these directories, prompting with the values it has guessed. +If the prompted value is acceptable hit return to accept it, otherwise +you should enter a new value. +.PP +As mentioned earlier, typical values for the IRAF root directory are +\fL/usr/iraf\fR or \fL/u/iraf\fR. +If the actual directory is more obscure the script +will fail to find it and you must enter the actual path. Locally added UNIX +level tasks are most commonly put in a directory like \fL/usr/local/bin\fR, +but any directory in the normal user's search path will do, even \fL/usr/bin\fR +if you have not defined a \fLlocal/bin\fR directory on your system. +.PP +Most likely the script will not find any good place for \fLimdir\fR, +and will prompt +with \fL/tmp\fR for lack of anything better. This will work during the initial +system testing, but is not recommended as a permanent solution as your image +files will be deleted every time the system is rebooted. On the other hand, +we do not recommend storing bulk image data directly in the user directories +as the disk management policies for large but short-lived data files tend to +be different than those for small but long-lived user files. The best solution +is to set aside a large area (on our system it is \fL/tmp2\fR, +\fL/tmp3\fR, etc.) which +is not backed up daily or weekly, and in which files which have not been +modified for two weeks or so are automatically deleted. Another advantage of +a separate area for large data files on BSD derived systems is that when you +make the files system you can specify a larger than normal file system block +size to increase the i/o bandwidth to disk. +.LP +Once you are happy with the installation procedure, become super user and +run the install script for real, without leaving the \fLhlib\fR directory: +.DS +\fL% su +% install\fR +.DE +You should now log out entirely and log back in as `iraf'. +Type "\fLecho $iraf\fR" +to verify that the system knows what the root directory is. If you have +installed a full binary distribution on a compatible machine you should be +able to run IRAF by entering the commands \fBmkiraf\fR to configure the IRAF +environment for user `iraf' (while still in the \fL$iraf/local\fR login +directory) and \fBcl\fR to start up the IRAF Command Language (CL). +If the CL does not run you must relink or recompile and relink the system, +as described in the next section. + +.NH 3 +Relink the system if necessary +.PP +Relinking the IRAF system is necessary if the distribution was shipped +without the executables in the \fLbin\fR directory (e.g. a `you-relink' +system). In order to relink, the system must first have been +\fIbootstrapped\fR; see \(sc4.1 if in doubt or if it is necessary +to perform a bootstrap. `You-relink' and of course `load-and-go' +distributions are already bootstrapped; source only distributions are not. +.PP +Relinking is covered in greater detail in \(sc4.2. Briefly, to relink the +entire system while spooling the output, run \fLmkpkg\fR from the IRAF root +directory: +.DS +\fL% cd $iraf +% mkpkg >& spool &\fR +.DE +See \(sc4.3 for information on inspecting a spoolfile for errors. +A relink-only sysgen might take a half hour or so depending on the +hardware configuration and system loading. +.PP +If IRAF is being installed on a host machine which is binary incompatible +with the distributed system (e.g., because the local host uses floating point +hardware not available at NOAO) then it may be necessary to strip the binaries +and recompile the system from scratch. Recompiling the full system can easily +take an entire day (of computer time, not person time). + +.NH 2 +Updating an Existing IRAF Installation +.PP +Skip to \(sc2.3 if you are installing IRAF for the first time. This section +is for sites upgrading to a new version of IRAF. +.PP +Updating a UNIX/IRAF installation is similar to the initial installation +procedure. The main difference is that local modifications made to the +site dependent files should be saved and then merged back into the generic +system from the distribution tape. The typical update process consists of +the following steps: +.RS +.IP \(bu +Save any locally modified files. +.IP \(bu +Delete the old system. +.IP \(bu +Read the distribution tape. +.IP \(bu +Restore site-dependent files. +.IP \(bu +Run the \fLinstall\fR script. +.IP \(bu +Relink the system if necessary. +.RE +.NH 3 +Save Locally Modified Files +.PP +Login as IRAF. Ordinarily the only directories containing files you may wish +to save are \fLdev\fR, \fLhlib\fR (\fL$iraf/unix/hlib\fR), and \fLlocal\fR. +The safest and easiest way to do this is to save the entire contents of +those directories. For example: +.DS +\fL% cd $iraf +% mkdir O +% mv dev local unix/hlib O\fR +.DE +Many variations on this are of course possible. The basic idea is to move +the old directories to a nonstandard place so that they are not deleted or +overwritten when we install the new system. +.NH 3 +Read the Distribution Tape or Tapes +.PP +Having temporarily preserved all directories containing the locally modified +files, it is now time to delete the old system and read in the new one. If +you are the cautious type you may wish first to preserve the entire +existing IRAF system on an archive tape (e.g. if something were to have +happened to the distribution tape en route). The old system may be deleted +as follows (assuming IRAF owns all the files in \fL$iraf/*\fR): +.DS +\fL% cd $iraf +% rm -rf [a-z]*\fR +.DE +This will preserve the old site local files in subdirectory "O". +Now read the distribution tape or tapes: +.DS +\fL% tar -xpf /dev/\fIdevice\fR +.DE +.LP +Repeat this for each tape in the distribution set. The order in which the +tapes are restored is not important. +.NH 3 +Restore Site-Dependent Files +.PP +You can either merge the contents of locally modified files saved from +the previous installation into their counterparts in the new system, or edit +the new ones from scratch. Whichever is easier depends on how much editing +you had to do in the first place, which probably depends upon the complexity +of your local computer network and the number of peripheral devices. +Any of the site configuration files might have been modified in the new +release of IRAF, so in general one cannot simply replace such a file with +the one that was saved. +.PP +Merging means inspecting the two files (newly distributed vs. its +saved counterpart) for differences, and deciding how to update the new +file with local device names, directory pathnames, etc. +The UNIX "\fLdiff\fR" utility may be useful for this, +depending on how much a file has changed, and how extensively it +was modified locally. One thing that is a big help is to keep track of +all local changes made to the standard system in a local "notes" file; +when the next system update occurs or when the installation is repeated on +another cpu at the local site, one can then go down the list and make all +the same changes to the newly installed system. +.KS +.TS +center; +ci ci ci +l l l. +directory files [and possibly] +.sp +\fLdev\fR devices, graphcap, termcap [, hosts, hostlogin, uhosts] +\fLhlib\fR zzsetenv.def [, mkpkg.inc, mkpkg.sf] +\fLlocal\fR (any local additions) [, all . (hidden) files] +.TE +.KE +.PP +The files which should be edited, via a diff/merge operation on the saved +files or otherwise, are summarized in the table above. +It is likely that only some of these files will have been modified at a +given site; the ones in brackets are used at IRAF networking sites, for +nonstandard compilation, and possibly window-system startup files for +workstations. In principle the entire contents of the \fLlocal\fR +directories are site-dependent and may be preserved in toto during an +update, but this is not true for all versions of IRAF, and sometimes +we add things to these directories which user sites may be useful to user +sites as well. +.PP +The \fLinstall\fR script, new in IRAF V2.5, takes care of the editing +that previously was done manually on such files as \fLhlib$mkiraf.csh\fR +and \fLhlib$libc/iraf.h\fR, so it is not necessary to diff/merge these files. +.NH 3 +Run the INSTALL Script +.PP +Use of the \fLinstall\fR script is described in detail in \(sc2.1.3, and is +summarized only briefly here. To preview its effects (still logged in as +`iraf'): +.DS +\fL% cd $iraf/unix/hlib +% install -n\fR +.DE +If you are satisfied, login as superuser and execute it for real, still +in the \fLhlib\fR directory: +.DS +\fL% su +% install\fR +.DE +Then log out entirely and back in as `iraf'. Verify that the system +knows where the root directory is, using "\fLecho $iraf\fR". At this +point you can test the system as described in the last paragraph of +\(sc2.1.3. If everything works, the installation is complete, and the +remainder of this manual will serve for system maintenance or when +device configurations change. If the CL does not run, you must relink +or recompile and relink the system as described in \(sc2.1.4. + +.NH 2 +Configuring the IRAF Device Tables +.PP +The following files should now be edited to define the default terminal, +printer, editor, and so on for your system. Any part of this can be left +until later if desired. +.NH 3 +$hlib/zzsetenv.def +.PP +This file contains the name of the default editor, the default names of all +the standard devices, and a number of other definitions which are not site +dependent and which can therefore be ignored. To be accessible by the IRAF +system, each local device named must also have an entry in the \fLtermcap\fR +file (terminals and printers) or \fLgraphcap\fR file (graphics terminals and +image displays) in \fLdev\fR. There must also be an \fIeditor\fL.ed\fR +file in \fLdev\fR +for the named editor; EDT, EMACS, and VI are currently supported. +Edit the string to the right of the equals sign for the following entries. +Sample values are shown. +.DS +\fLset editor = "vi" +set printer = "imagen" +set stdgraph = "vt640" +set stdimage = "iism70l" +set stdplot = "versatec" +set terminal = "vt640"\fR +.DE +For example, you may wish to change the default editor to "\fLemacs\fR", +the default printer to "\fLversatec\fR", the default image display to +"\fLiism75\fR", and the default terminal to "\fLvt100\fR". Note that the set of +devices for which interfaces are already available is steadily growing +but always finite. The issues of interfacing new graphics and image +display devices are discussed further in \(sc6. +.NH 3 +$iraf/dev/devices +.PP +This file contains a list of the allocatable devices (primarily tape drives) +for the local system. It should be obvious how to change it by reading the +comments in the file and studying the current values, which are for our system. +.NH 3 +$iraf/dev/termcap +.PP +There must be entries in this file for all local terminal and printer +devices you wish to access from IRAF (there is no \fLprintcap\fR file in IRAF). +The entry for a printer contains one special (nonstandard termcap) entry, +called DD. This consists of three fields: node!device, the template for the +temporary spoolfile, and the UNIX command to be used to dispose of the file to +the printer. On Berkeley UNIX it is rarely necessary to make use of the node +name capability, since the UNIX \fLlpr\fR already provides this capability. +.PP +If you have a new terminal which has no entry in the termcap file provided, +you probably already have an entry in the UNIX termcap file. Simply copy it +into the IRAF file; both systems use the same termcap database format. +However, if this is also a graphics terminal with a device entry in +\fLdev$graphcap\fR, you should add a `\fL:gd\fR' capability to the termcap +entry. If the graphcap entry has a different name from the termcap entry, +make it `\fL:gd=\fIgname\fR'. +.NH 3 +$iraf/dev/graphcap +.PP +There must be entries in this file for all graphics terminals, batch plotters, +and image displays accessed by IRAF programs. Weird graphics terminals will +need a new entry. The IRAF file \fLsys$gio/doc/gio.hlp\fR contains docs for +graphcap. A printed copy of this document is available upon request, however +once IRAF is up you may find it easier to generate your own copy using +\fLhelp\fR, as follows: +.DS +\fLcl> cd sys$gio/doc +cl> help gio.hlp fi+ | lprint\fR +.DE +The manual page for the \fBshowcap\fR task should also be printed since this +utility is useful for generating new graphcap entries. More focused +documentation will be available eventually. Help is available for those who +need it via the IRAF Hotline. We ask that new graphcap entries be sent +back to us so that we may include them in the master graphcap file for other +sites to use. +.NH 3 +Network Tables +.PP +The \fLdev\fR directory also contains a number of files (\fLhosts\fR, +\fLhostlogin\fR, and \fLuhosts\fR) +used by the IRAF network software. We depend upon the networking capabilities +of IRAF heavily at NOAO to access image displays, printers, files, etc. resident +upon remote nodes (the IRAF network interface is also capable of spawning +subprocess and background jobs on remote nodes, and works even when the nodes +run different host operating systems, e.g., both UNIX and VMS). +.PP +We expect that most sites will not need this capability initially, hence +documentation of the networking software will be left for later. For sites +that want to try it out, all that is necessary to enable networking is to +edit the three networking files in the \fLdev\fR directory, and install IRAF on +the other nodes. It does not matter what native operating system runs on the +remote nodes, so long as it runs IRAF as well. The source for the network +interface is in the \fLsys$ki\fR directory, and a discussion of the conceptual +design of the interface is given in the \fLREADME\fR file in that directory. + +.NH +Testing the System +.PP +Once the system has been installed or updated and the principal device tables +configured, it is time to perform a few simple tests to make sure the system +is working properly. At this point it would probably be wise to read the +CL User's Guide, if you have not already done so. Once the IRAF environment +is configured with \fLmkiraf\fR (discussed earlier) one need only enter the +"cl" command to start up the CL. +.DS +\fL% cl\fR +.DE +After a bit IRAF should print the message of the day and the root IRAF menu, +and issue the \fLcl> \fR prompt. +Once in the CL, you will probably have magtape and printer access, are likely +to have graphics terminal access, and very possibly will not have either +image display access or graphics plotter access. If the graphics terminal +capability is ready, the next step is to run the IRAF test procedure to +verify that all is working well, as well as try out a few of the many tasks +in the system. If the graphics terminal is not up yet, there is probably +no point in running the test procedure. To run the test procedure, +familiarize yourself with the documentation in Volume 1A of the +\fIIRAF User Handbook\fR and follow the instructions therein. + +.NH +Reconfiguring the System +.NH 2 +Bootstrapping the System +.PP +All current normal IRAF distributions come with the system already bootstrapped. +A bootstrap should not be necessary unless one is doing something unusual, +e.g., attempting a new port. +.PP +A bootstrap is like a full system sysgen, except that it is the host +system interface (kernel and bootstrap utilities) which are compiled and +linked, rather than IRAF itself. The system must be bootstrapped before +a sysgen is possible, since the bootstrap utilities are required to do a +sysgen. The two operations are distinct because only the bootstrap is +machine dependent; everything else works the same on all IRAF systems. +.PP +The bootstrap operation is necessary when installing the system from a +source only distribution tape. We assume that the files in the host system +interface have already been configured for the host system. If this is +not the case, then we are doing a port, which is a lot more ambitious than +a simple bootstrap. +.PP +To bootstrap UNIX/IRAF, go to the \fLunix\fR directory and interpret the shell +script \fLmkpkg.csh\fR. This takes about 45 minutes, so the output should be +spooled in a file. Note that (for no good reason) the files have a \fL.csh\fR +extension even though we have chosen to use the Bourne shell to execute +the commands therein. +.DS +\fL% cd $iraf/unix +% sh -x mkpkg.csh >& spool &\fR +.DE +A bootstrap recompiles everything whether it needs to or not, so it is +usually not necessary to delete the binaries before doing a full bootstrap. + +.NH 2 +Relinking the System +.PP +Relinking the system is necessary if the system was shipped without +the executables in the \fLbin\fR directory. In order to relink the system must +first have been bootstrapped. When the system is shipped without +executables (to save space) it will already have been bootstrapped. +If it is necessary to bootstrap the system, e.g., given a source only +distribution, go read \(sc4.1 before trying to relink the system. +.PP +The system is relinked by the bootstrap utility program \fBmkpkg\fR. +The \fLmkpkg\fR program is driven by the \fLmkpkg\fR files found in all IRAF +source directories. Running \fLmkpkg\fR in a directory causes the +contents of that directory, normally an applications package or library, +to be updated, along with the contents of all subdirectories referenced +by the root \fLmkpkg\fR file. +.PP +Running \fLmkpkg\fR in the root IRAF directory causes the entire system to +be updated. If the system libraries are all up to date, the effect is to +relink the system. If the system has been modified and some library modules +have to be recompiled and inserted into the system libraries, then the +operation is a partial sysgen. If there are no libraries or object libraries +then we have a full sysgen, which is the topic of the next section. +The \fLmkpkg\fR utility is documented in detail in Volume 1B of the +IRAF User Handbook, in the manual pages for the \fLsoftools\fR package. +.LP +To relink all of IRAF, go to the root and run \fLmkpkg\fR, i.e., +.DS +\fL% cd $iraf +% mkpkg\fR +.DE +The program will inspect all source modules and verify that the system +libraries are up to date, then relink the system executables, followed by +all the applications executables, installing the executable files in the +\fLbin\fR directory. +.NH 3 +Relinking individual packages +.PP +It is just as easy to relink the individual IRAF packages, e.g., after +a bug has been fixed, or if an update of a package is received by electronic +mail. This would normally be done from within IRAF since the next step +is to test the new package. We will use the \fLcl> \fR prompt in the +examples, but since \fLmkpkg\fR is a bootstrap utility (IRAF foreign task), +usage is the same both in IRAF and in UNIX. +.LP +To relink a package and install the new executable in \fLbin\fR: +.DS +\fLcl> mkpkg update\fR +.DE +To relink a package, leaving the executable in the package directory for +testing or debugging prior to installation: +.DS +\fLcl> mkpkg\fR +.DE +To install an already linked executable after testing: +.DS +\fLcl> mkpkg install\fR +.DE +To update only the package library without relinking (this assumes that the +name of the library is \fLlibpkg.a\fR): +.DS +\fLcl> mkpkg libpkg.a\fR +.DE +The "update", "install", and "libpkg.a" identifiers are entry points in the +\fLmkpkg\fR file, which may be read to see what is going on. +.PP +As an actual example of a package relink, suppose we wanted to increase the +size of the stack area in the CL to 8000 elements, e.g., because the CL was +running out of space at runtime. We would go to the CL directory, edit +the file \fLconfig.h\fR, change the value of \fLSTACKSIZ\fR to \fL8000\fR, +and then run \fLmkpkg\fR: +.DS +\fLcl> cd cl +cl> ed config.h +cl> mkpkg update\fR +.DE +Since \fLconfig.h\fR is included by nearly all the CL source files, the entire +package would be recompiled unnecessarily, but it is safer that way. + +.NH 2 +Autogeneration of the System (SYSGEN) +.PP +A full system sysgen is necessary when installing a source only version +of the system. The system must first have been bootstrapped; see \(sc4.1 +if this has not yet been done. A full sysgen may also be necessary if +a binary distribution has been received but it is later discovered that it is +necessary or desirable to recompile the system. In this case the existing +libraries and objects \fImust be deleted\fR before the sysgen, else the sysgen +will be nothing more than a relink. The \fBrmbin\fR utility is used to +descend a directory tree, deleting all binary files therein. Note that +the ONLY case in which it is necessary to use \fLrmbin\fR is when we wish +to force the entire system to be recompiled. The \fLrmbin\fR task is yet +another bootstrap utility, and is documented in the manual pages for the +\fLsoftools\fR package. +.DS +\fL% cd $iraf +% rmbin -vi bin lib pkg sys\fR +.DE +This will delete all binaries in the portable part of the system, excluding +the \fLhost\fR or \fL$iraf/unix\fR directories (if you run \fLrmbin\fR on the +\fL$iraf/unix\fR directories, you will have to bootstrap the system as well). +.PP +Before starting the full system sysgen it may be desirable to review the +switches in the file \fLmkpkg.inc\fR in the \fLhlib\fR directory. +This is the global include file for the \fLmkpkg\fR utility, +and contains various switches controlling \fLmkpkg\fR, e.g., which packages +will be compiled, and the default compiler and linker flags. +.PP +Since a full sysgen takes a long time and generates a lot of output which +later has to be reviewed, they are always run in batch with the output +redirected, e.g.: +.DS +\fL% cd $iraf +% mkpkg >& spool &\fR +.DE +To watch what is going on after this command has been submitted and while +it is running, try +.DS +\fL% tail -f spool\fR +.DE +Sysgens are restartable, so if the sysgen aborts for any reason, simply +fix the problem and start it up again. +.PP +A full sysgen generates a lot of output, too much to be safely reviewed for +errors by simply paging the spool file. Enter the following command to review +the output (this assumes that the output has been saved in a file named +\fLspool\fR). +.DS +\fL% mkpkg summary\fR +.DE +It is normal for a number of compiler messages warning about assigning +character data to an integer variable to appear in the spooled output. +These are harmless on most (but not all) machines, and are due to questionable +coding practices in the old NCAR graphics utilities and some of the math +library routines, all of which are coded in Fortran (SPP code never causes +such problems!). +.PP +The discussion up to now has centered on the full system sysgen. +Partial sysgens are actually much more common. For example, if an important +bug is fixed in the VOS or in the IRAF kernel, a (partial) sysgen should be +conducted to recompile the affected modules and relink the system. +An example of this occurs when the \fLtermcap\fR or \fLgraphcap\fR entries +for important local devices are cached by running the \fBttycompile\fR +task (another \fLsoftools\fR utility). A sysgen is required after regenerating +the cache tables, since these must be compiled and linked into the affected +programs to have any effect. + +.NH 2 +New Ports +.PP +We recommend that you contact the IRAF group for assistance if you are +contemplating porting IRAF to a new host machine. +To port IRAF to a new version of UNIX requires some modifications to the +files in the host interface directories (\fL$iraf/unix/\fR...), +followed by a full +sysgen and lots of testing. Typically most of the code in the host interface +can be used without change, with only minor changes to the remaining code, +since the different versions of UNIX are quite similar (as compared to, +for example, a port to a completely different operating system like VMS or +AOS/VS). +.PP +Note that even when the target system is a "fully compatible" 4.X BSD UNIX +system, some changes are likely to be necessary since all of these systems +are slightly different. For example, the SUN and ISI implementations of +BSD UNIX employ different assemblers, and the Fortran compilers on the +two systems have diverged considerably. A port to Bell System V or one of +the UNIX look alikes would certainly require some changes to the IRAF kernel, +particularly in the exception handling, process control, and network interface +facilities. +.PP +The changes required are likely to be minor for someone sufficiently familiar +with both IRAF and UNIX, but should not be underestimated. Every new port +produces its share of compile time errors (due to differences in the Fortran +compilers) and finds a few new bugs, sometimes in the IRAF software but more +often in the host Fortran compiler, now that IRAF has been ported to so many +systems. A thorough understanding of both IRAF and the host system is required +to rapidly isolate such bugs. + +.NH +Tuning Considerations +.PP +There are two things that are commonly done to tune UNIX/IRAF for a +particular host system: +.RS +.IP \(bu +Precompile selected \fLtermcap\fR and \fLgraphcap\fR entries +.IP \(bu +Strip the system to reduce disk consumption +.RE +.LP +The most important optimization is precompilation of the termcap and graphcap +entries of the devices most commonly used at the local site, particular when +running IRAF on a slow machine. Stripping the system is inadvisable if the +system is to be used for software development, but is normally desirable when +installing a production version of IRAF on a small system with limited disk +space, e.g., a workstation. + +.NH 2 +Precompiling TERMCAP and GRAPHCAP Entries +.PP +Precompilation of a termcap or graphcap entry is a technique used to +speed runtime access of the entry for that device. If the entry is not +precompiled the termcap or graphcap file must be physically opened and +scanned at runtime to read the desired entry. This causes a noticeable +delay of as much as a second when clearing the terminal screen or plotting +a graph, hence it is usually worthwhile to cache the entries for commonly +used video and graphics terminals. It is not worthwhile for printers, +plotters, and image displays. +.PP +The system comes with selected termcap and graphcap entries already +precompiled. To see which devices are precompiled, page the cache data +files, \fLdev$cachet.dat\fR (for termcap) and \fLdev$cacheg.dat\fR +(for graphcap). +To cache a different set of entries one must regenerate these files with the +\fBmkttydata\fR task in the \fLsoftools\fR package, and then do a full +sysgen with the \fLmkpkg\fR utility. Detailed instructions are given in +the manual page for \fLmkttydata\fR. +.PP +Note that if you wish to precompile and relink the system to cache selected +termcap or graphcap device entries and plan to strip the system as well to +save disk space, \fIyou must cache the termcap and graphcap entries before +stripping the system\fR, because once the system is stripped you cannot +relink. + +.NH 2 +Stripping the System to Reduce Disk Consumption +.PP +If the system is to be installed on multiple cpus, or if a production +version is to be installed on a workstation, it may be necessary or desirable +to strip the system of all non-runtime files to save disk space. +This equates to deleting all the sources and all the reference manuals and +other documentation, excluding the online manual pages. A special utility +called \fBrmfiles\fR (in the \fLsoftools\fR package, of course) is provided +for this purpose. It is not necessary to run \fLrmfiles\fR directly to strip +the system. The preferred technique is to enter the commands given below. +The example is for the cshell for consistency with the rest of this document, +but this could be done from within the CL as well. +.DS +\fL% cd $iraf +% mkpkg strip\fR +.DE +This will preserve all runtime files, permitting use of the standard system +as well as user software development. The size of the system is reduced +from about 50 Mb (megabytes) to around 26 Mb. One can optionally enter the +command \fLmkpkg stripall\fR to delete the system libraries as well, but this +saves only another couple of Mb and a full sysgen or a tape reload will be +required to regain the capability to link user programs with the IRAF +libraries (including IMFORT), or relink the IRAF executables. +.PP +Note: if the \fLvms\fR directory is present at the \fL$iraf\fR root, +it may be removed entirely. On a full system it takes up over 3Mb, and +may be present on some distribution tapes for UNIX/IRAF cut on our master +development system. + +.NH +Interfacing New Graphics Devices +.PP +There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. + +.NH 2 +Graphics Terminals +.PP +The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal and most workstations' terminal emulators, +using the \fLstdgraph\fR +graphics kernel supplied with the system. All one need do to interface to a +new graphics terminal is add a new graphcap entry for the device. This can +take anywhere from a few hours to a few days, depending on one's level of +expertise, and the perversity of the device in question. Be sure to check +the contents of the \fLdev$graphcap\fR file to see if the terminal is already +supported, before trying to write a new entry. Assistance in interfacing new +graphics terminals is available via the IRAF Hotline. + +.NH 2 +Graphics Plotters +.PP +The current IRAF system comes with several graphics kernels used to drive +graphics plotters. The standard plotter interface is via the SGI graphics +kernel, which has largely replaced the older \fLNCAR\fR kernel used in earlier +versions of IRAF (in those earlier versions the \fLNCAR\fR kernel was called +the \fLstdplot\fR kernel). Further information on the SGI plotter interface +is given in the paper \fIThe IRAF Simple Graphics Interface\fR, a copy of which +is included with the installation kit. +.PP +SGI device interfaces for most +plotter devices already exist, and adding support for new devices is +straightforward. Sources for the SGI device translators supplied with the +distributed system are maintained in the directory \fL$iraf/unix/gdev/sgidev\fR. +NOAO serves as a clearinghouse for new SGI plotter device interfaces; +contact us if you do not find support for a local plotter device in the +distributed system, and if you plan to implement a new device interface let +us know so that we may help other sites with the same device. +.PP +The older \fLNCAR\fR kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +plots on devices supported by host-level NCAR metacode translators. +The host level NCAR metacode translators are not included in the standard +IRAF distribution, but public domain versions of the NCAR implementation for +UNIX systems are widely available. A site which already has the +NCAR software may wish to go this route, but the SGI interface will provide +a more efficient and simpler solution in most cases. +.PP +The remaining possibility with the current system is the \fLcalcomp\fR kernel. +Many sites will have a Calcomp or Versaplot libary (or Calcomp compatible +library) already available locally. To make use of such a library to get +plotter output on any devices supported by the interface, one may copy +the library to the \fLhlib\fR directory and relink the Calcomp graphics +kernel. +.PP +A graphcap entry for each new device will also be required. Information on +preparing graphcap entries for graphics devices is given in the GIO design +document, and many actual working examples will be found in the graphcap +file. The best approach is usually to copy one of these and modify it. + +.NH 2 +Image Displays +.PP +The current IRAF system does not yet have a well defined and well isolated +device independent image display interface. Work on such an interface is +currently underway; contact the IRAF group at NOAO for further information +on the status of the new display interfaces. Further information on the +image display interfaces currently available may be found in the +\fIIRAF Newsletter\fR. +.PP +If there is no IRAF interface for your device, the best approach at present is +to use the IMFORT interface and whatever non-IRAF display software you +currently have to construct a host level Fortran or C display program +(a number of people have also managed to construct an interface by hacking +the IRAF display software in \fLpkg$images/tv/display\fR). +The IMFORT library provides host system Fortran or C programs with access +to IRAF images on disk. Documentation on the IMFORT interface is available in +\fIA User's Guide to Fortran Programming in IRAF -- The IMFORT Interface\fR, +Doug Tody, September 1986, a copy of which is included in the IRAF User +Handbook, Volume 1A. + +.NH +The IRAF Directory Structure +.PP +The current full UNIX/IRAF directory structure is documented graphically in +the appendix. The main branches of the tree are the following; beneath the +directories shown are some 250 subdirectories, the largest directory trees +being \fLsys\fR, \fLpkg\fR, and \fLnoao\fR. The entire contents of all +directories other than \fLunix\fR, \fLlocal\fR, and a few configuration files +in \fLdev\fR are fully portable, and are identical in all installations +of IRAF sharing the same version number. +.DS +\fLbin \fR- installed executables +\fLdev \fR- device tables (\fLtermcap\fR, \fLgraphcap\fR, etc.) +\fLdoc \fR- assorted IRAF manuals +\fLlib \fR- the system library; object libraries, global files +\fLlocal \fR- iraf login directory; locally added software +\fLmath \fR- sources for the mathematical libraries +\fLnoao \fR- packages for NOAO data reduction +\fLpkg \fR- the IRAF applications packages +\fLsys \fR- the virtual operating system (VOS) +\fLunix \fR- the UNIX host system interface (HSI = kernel + bootstrap utilities) +.DE +.LP +The contents of the \fLunix\fR directory (host system interface) are +as follows: +.DS +\fLas \fR- assembler sources for UNIX/IRAF +\fLboot \fR- bootstrap utilities (mkpkg, rtar, wtar, etc.) +\fLgdev \fR- graphics device interfaces (SGI device translators) +\fLhlib \fR- host dependent runtime files +\fLmc68000 \fR- Motorola 68xxx assembler sources +\fLmkpkg.sh \fR- executed to bootstrap the UNIX/IRAF HSI +\fLos \fR- OS interface routines (UNIX/IRAF kernel) +\fLrmbin.sh \fR- executed to delete binary files in subdirectories +.DE +.PP +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. diff --git a/doc/unixsmg.ms b/doc/unixsmg.ms new file mode 100644 index 00000000..7473d5e6 --- /dev/null +++ b/doc/unixsmg.ms @@ -0,0 +1,1432 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +UNIX/IRAF Site Manager's Guide +.AU +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +June 1989 +.br +Revised September 1992 + +.AB +An IRAF \fIsite manager\fR is anyone who is responsible for installing and +maintaining IRAF at a site. This document describes a variety of site +management activities, including configuring the device and environment +tables to provide reasonable defaults for the local site, adding interfaces +for new devices, configuring and using IRAF networking, the installation +and maintenance of layered software products (external packages), +and configuring a custom site LOCAL package so that local software may be +added to the system. Background information on multiple architecture +support, shared library support, and the software management tools provided +with the system is presented. The procedures for rebooting IRAF and +performing a sysgen are described. The host system resources +required to run IRAF are discussed. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBSystem Setup\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Installing the System\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'Configuring the Device and Environment Tables\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Environment definitions\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.2.2.\h'|1.5i'The template LOGIN.CL\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.3.\h'|1.5i'The TAPECAP file\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.4.\h'|1.5i'The DEVICES.HLP file\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.5.\h'|1.5i'The TERMCAP file\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.6.\h'|1.5i'The GRAPHCAP file\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.7.\h'|1.5i'Configuring IRAF networking\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.8.\h'|1.5i'Configuring the IRAF account\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.2.9.\h'|1.5i'Configuring user accounts for IRAF\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.3.\h'|0.9i'Tuning Considerations\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.3.2.\h'|1.5i'Stripping the system to reduce disk usage\l'|5.6i.'\0\06 +.sp +3.\h'|0.4i'\fBSoftware Management\fP\l'|5.6i.'\0\07 +.br +\h'|0.4i'3.1.\h'|0.9i'Multiple architecture support\l'|5.6i.'\0\07 +.br +\h'|0.4i'3.2.\h'|0.9i'Shared libraries\l'|5.6i.'\0\08 +.br +\h'|0.4i'3.3.\h'|0.9i'Layered software support\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.4.\h'|0.9i'Software management tools\l'|5.6i.'\0\10 +.br +\h'|0.4i'3.5.\h'|0.9i'Modifying and updating a package\l'|5.6i.'\0\11 +.br +\h'|0.4i'3.6.\h'|0.9i'Installing and maintaining layered software\l'|5.6i.'\0\12 +.br +\h'|0.4i'3.7.\h'|0.9i'Configuring a custom LOCAL package\l'|5.6i.'\0\13 +.br +\h'|0.4i'3.8.\h'|0.9i'Updating the full IRAF system\l'|5.6i.'\0\13 +.br +\h'|0.9i'3.8.1.\h'|1.5i'The BOOTSTRAP\l'|5.6i.'\0\14 +.br +\h'|0.9i'3.8.2.\h'|1.5i'The SYSGEN\l'|5.6i.'\0\14 +.br +\h'|0.9i'3.8.3.\h'|1.5i'Localized software changes\l'|5.6i.'\0\15 +.sp +4.\h'|0.4i'\fBGraphics and Image Display\fP\l'|5.6i.'\0\17 +.br +\h'|0.4i'4.1.\h'|0.9i'Using the workstation with a remote compute server\l'|5.6i.'\0\17 +.sp +5.\h'|0.4i'\fBInterfacing New Graphics Devices\fP\l'|5.6i.'\0\17 +.br +\h'|0.4i'5.1.\h'|0.9i'Graphics terminals\l'|5.6i.'\0\17 +.br +\h'|0.4i'5.2.\h'|0.9i'Graphics plotters\l'|5.6i.'\0\17 +.br +\h'|0.4i'5.3.\h'|0.9i'Image display devices\l'|5.6i.'\0\18 +.sp +6.\h'|0.4i'\fBHost System Requirements\fP\l'|5.6i.'\0\18 +.br +\h'|0.4i'6.1.\h'|0.9i'Memory requirements\l'|5.6i.'\0\19 +.br +\h'|0.4i'6.2.\h'|0.9i'Disk requirements\l'|5.6i.'\0\19 +.sp +\fBAppendix A.\0The IRAF Directory Structure\fP\l'|5.6i.'\0\19 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Once the IRAF system has been installed it will run, but there remain many +things one might want to do to tailor the system to the local site. +Examples of the kinds of customizations one might want to make are the +following. +.RS +.IP \(bu +Edit the default IRAF environment definitions to provide reasonable +defaults for your site. +.IP \(bu +Make entries in the device descriptor tables for the devices in use at +your site. +.IP \(bu +Code and install new device interfaces. +.IP \(bu +Enable and configure IRAF networking, e.g., to permit remote image +display, tape drive, or file access. +.IP \(bu +Perform various optimizations, e.g., stripping the system to reduce disk +usage. +.IP \(bu +Extend the system by installing layered software products. +.IP \(bu +Configure a custom LOCAL package so that locally developed software +may be installed in the system. +.RE +.PP +This document provides sufficient background information and instructions to +guide the IRAF site manager in performing such customizations. Additional +help is available via the IRAF HOTLINE (602 323-4160), or by sending mail to +\f(CWiraf@noao.edu\fR (internet) or \f(CW5355::iraf\fP (SPAN). +Contributions of interfaces developed for new devices, or any other software +of general interest, are always welcome. +.PP +The IRAF software is organized in a way which attempts to isolate, so far as +possible, the files or directories which must be modified to tailor the +system for the local site. Most or all changes should affect only files in +the local, dev, and hlib (unix/hlib) directories. Layered software +products, including locally added software, reside outside of the IRAF core +system directory tree and are maintained independently of the core system. +.PP +A summary of all modifications made to the IRAF system for a given IRAF +release is given in the \fIRevisions Summary\fR distributed with the +system. Additional information will be found in the system notes files +(notes.v29, notes.v210, etc.) in the iraf/local and iraf/doc directories. +This is the primary source of technical documentation for each release and +should be consulted if questions arise regarding any of the system level +features added in a new release of the core system. + +.bp +.NH +System Setup +.NH 2 +Installing the System +.PP +The procedure for installing or updating a UNIX/IRAF system is documented in +the \fIIRAF Installation Guide\fR distributed with the system. A custom +installation guide is provided for each platform on which IRAF is supported. +.PP +In short, an IRAF tape or network distribution is obtained and installed +according to the instructions. The result is a full IRAF system, including +both sources and executable binaries for the architectures to be supported. +The system will have been modified to reflect the new IRAF root directory +and should run, but will otherwise be a generic IRAF distribution. To get +the most out of an IRAF installation it will be necessary to perform some of +the additional steps outlined in the remainder of this document. + +.NH 2 +Configuring the Device and Environment Tables +.PP +Teaching IRAF about the devices, network nodes, external programs, and other +special resources available at a site is largely a matter of editing a +standard set of device descriptor and environment setup files, all of which +are simple text files. The versions of these files provided with the +distribution are simply those in use on the NOAO system from which the tapes +were made, at the time the tapes were generated. Hence while these files +may be useful as examples of properly configured descriptor files, the +defaults, and many specific device entries, will in many cases be +meaningless for a different site. This is harmless but it may be confusing +to the user if, for example, the default printer doesn't exist at your +site. +.PP +The device and environment files also contain much material which any site +will need, so care must be taken when editing the files. Important changes +may be made to the global portions of these files as part of any IRAF +release. To facilitate future updates, it is wise where possible to isolate +any local changes or additions so that they may simply be extracted and +copied into the new (distributed) version of the file in a future update. +.NH 3 +Environment definitions +.PP +Since IRAF is a machine and operating system independent, distributed system +it has its own environment facility apart from that of the host system. +Host system environment variables may be accessed as if they are part of the +IRAF environment (which is sometimes useful but which can also be +dangerous), but if the same variable is defined in the IRAF environment it +is the IRAF variable which will be used. The IRAF environment definitions, +as defined at CL startup time, are defined in a number of files in the +unix/hlib directory. Chief among these is the \fBzzsetenv.def\fR file. +Additional user modifiable definitions may be given in the template +\fBlogin.cl\fR file (see \(sc2.2.2). +.PP +The zzsetenv.def file contains a number of environment definitions. +Many of these define IRAF logical directories and should be left alone. +Only those definitions in the header area of the file should need to be +edited to customize the file for a site. It is the default editor, +default device, etc. definitions in this file which are most likely to +require modification for a site. +.PP +If the name of a default device is modified, the named device must also have +an entry in the \fBtermcap\fR file (terminals and printers) or the +\fBgraphcap\fR file (graphics terminals and image displays) in iraf/dev. +There must also be an \fIeditor\f(CW.ed\fR file in dev for the +default editor; \fIedt\fR, \fIemacs\fR, and \fIvi\fR are examples of +currently supported editors. +.PP +Sample values of those variables most likely to require modification for +a site are shown below. +.XS +set editor = "vi" +set printer = "lpr" +set stdplot = "lpr" +set stdimage = "imt512" +.XE +.PP +For example, you may wish to change the default editor to "emacs", the +default printer to "lw5", or the default image display to "imt800". Note +that the values of terminal and stdgraph, which also appear in the +zzsetenv.def file, have little meaning except for debugging processes run +standalone, as the values of the environment variables are reset +automatically by \fIstty\fR at login time. The issues of interfacing new +graphics and image display devices are discussed further in \(sc5. +.NH 3 +The template LOGIN.CL +.PP +The template login.cl file hlib$login.cl, is the file used by \fImkiraf\fR +to produce the user login.cl file. The user login.cl file, after having +possibly been edited by the user, is read by the CL every time a new CL is +started, with the CL processing all environment and task definitions, +package loads, etc., in the login file. Hence this file plays an important +role in establishing the IRAF environment seen by the user. +.PP +Examples of things one might want to change in the template login.cl +are the commented out environment definitions, the commented out CL +parameter assignments, the foreign task definitions making up the default +\f(CWuser\fR package, and the list of packages to be loaded at startup +time. For example, if there are host tasks or local packages which +should be part of the default IRAF operating environment at your site, +the template login.cl is the place to make the necessary changes. +.NH 3 +The TAPECAP file +.PP +Beginning with V2.10 IRAF magtape devices are described by the tapecap file, +dev$tapecap. This replaces the "devices" file used in earlier versions of +IRAF. The tapecap file describes each local magtape device and controls all +i/o to the device, as well as device allocation. +.PP +The tapecap file included in the distributed system includes some generic +device entries such as "mtxb1" (Exabyte unit 1), "mtwd0" (WangDAT unit 0), +and so on which you may be able to use as-is to access your local magtape +devices. The actual list of generic device entries provided is system +dependent, so consult the tapecap file in your installed system for a list +of the currently interfaced devices. Most likely you will want to add some +device aliases, and you may need to prepare custom device entries for local +devices. There must be an entry in the tapecap file for a magtape device in +order to be able to access the device from within IRAF. +.PP +Instructions for adding devices to the tapecap file are given in the +document \fIIRAF Version 2.10 Revisions Summary\fR, in the discussion of +the new magtape system. +.NH 3 +The DEVICES.HLP file +.PP +All physical devices that the user might need to access by name should be +documented in the file dev$devices.hlp. Typing +.XS +cl> help devices +.XE +or just +.XS +cl> devices +.XE +in the CL will format and output the contents of this file. It is the IRAF +name of the device, as given in files such as termcap, graphcap, and +tapecap, which should appear in this help file. +.NH 3 +The TERMCAP file +.PP +There must be entries in this file for all local terminal and printer +devices you wish to access from IRAF (there is currently no "printcap" file +in IRAF). The entry for a printer contains one special device-specific +entry, called \f(CWDD\fR. This consists of three fields: the device name, +e.g. "node!device", the template for the temporary spoolfile, and the UNIX +command to be used to dispose of the file to the printer. On most UNIX +systems it is not necessary to make use of the node name and IRAF networking +to access a remote device since UNIX \fIlpr\fR already provides this +capability, however it might still be useful if the desired device does not +have a local \fIlpr\fR entry for some reason. +.PP +If you have a local terminal which has no entry in the IRAF termcap file, +you probably already have an entry in the UNIX termcap file. Simply copy it +into the IRAF file; both systems use the same termcap database format and +terminal device capabilities. However, if the terminal in question is a +graphics terminal with a device entry in the graphcap file, you should +add a `\f(CW:gd\fR' capability to the termcap entry. If the graphcap entry +has a different name from the termcap entry, make it `\f(CW:gd=\fIgname\fR'. +.NH 3 +The GRAPHCAP file +.PP +There must be entries in the graphcap file for all graphics terminals, batch +plotters, and image displays accessed by IRAF programs. New graphics +terminals will need a new entry. The IRAF file gio$doc/gio.hlp +contains documentation describing how to prepare graphcap device entries. A +printed copy of this document is available from the iraf/docs directory in +the IRAF network archive. However, once IRAF is up you may find it easier +to generate your own copy using \fIhelp\fR, as follows: +.XS +cl> help gio$doc/gio.hlp fi+ | lprint +.XE +which will print the document on the default IRAF printer device (use the +"device=" hidden parameter to specify a different device). Alternatively, +to view the file on the terminal, +.XS +cl> phelp gio$doc/gio.hlp fi+ +.XE +.PP +The help pages for the IRAF tasks \fIshowcap\fR and \fIstty\fR should also +be reviewed as these utilities are useful for generating new graphcap +entries. The i/o logging feature of \fIstty\fR is useful for determining +exactly what characters your graphcap device entry is generating. The +\fIgdevices\fR task is useful for printing summary information about the +available graphics devices. +.PP +Help preparing new graphcap device entries is available if needed. We ask +that new graphcap entries be sent back to us so that we may include them in +the master graphcap file for all to benefit. +.NH 3 +Configuring IRAF networking +.PP +The dev directory contains several files (\f(CWhosts\fR, +\f(CWirafhosts\fR, and \f(CWuhosts\fR) used by the IRAF network interface. +IRAF networking is used to access remote image displays, printers, magtape +devices, files, images, etc. via the network. Nodes do not necessarily have +to have the same architecture, or even run the same operating system, so +long as they can run IRAF. +.PP +To enable IRAF networking for a UNIX/IRAF system, all that is necessary is to +edit the "hosts" file. Make an entry for each logical node, in the format +.XS +\fInodename\fR [ \fIaliases\fR ] ":" \fIirafks.e-pathname\fR +.XE +following the examples given in the hosts file supplied with the +distribution (which is the NOAO/Tucson hosts file). Note that there may be +multiple logical entries for a single physical node. +.PP +The "uhosts" file is not used by UNIX/IRAF systems hence does not need to +be modified (it used by VMS/IRAF). The "irafhosts" file is the template +file used to create user .irafhosts files. It does not have to be modified, +although you can do so if you wish to change the default parameter values +given in the file. +.PP +To enable IRAF networking on a particular IRAF host, the \fBhostname\fR for +the host machine must appear as a primary name or alias somewhere in the +IRAF hosts table. During process startup, the IRAF VOS looks for the system +name for the current host and automatically disables networking if this name +is not found. Hence IRAF networking is automatically disabled when the +distributed system is first installed - unless you are unlucky enough to +have installed the system on a host with the same name as one of the nodes +in the NOAO host table. +.PP +Once IRAF networking is configured, the following command may be typed in +the CL to verify that all is well: +.XS +cl> netstatus +.XE +This will print the host table and state the name of the local host. +Read the output carefully to see if any problems are reported. +.PP +For IRAF networking to be of any use, it is necessary that IRAF be installed +on at least two systems. In that case either system can serve as the server +for an IRAF client (IRAF program) running on the other node. It is not +necessary to have a separate copy of IRAF on each node, i.e., a single copy +of IRAF may be NFS mounted on all nodes (you will need to run the IRAF +\fIinstall\fR script on each client node). If it is not possible to install +IRAF on a node for some reason (either directly or using NFS) it is possible +to manage by installing only enough of IRAF to run the IRAF kernel server. +Contact IRAF site support if you need to configure things in this manner. +.PP +UNIX IRAF systems currently support only TCP/IP based networking. +Networking between any heterogeneous collection of systems is possible +provided they support TCP/IP based networking (virtually all UNIX-based +systems do). The situation with networking between UNIX and VMS systems is +more complex. V2.9 and earlier versions of VMS/IRAF support client-side +only TCP/IP using the third party Wollongong software. For V2.10 we plan to +drop support for the Wollongong software and switch to the more +fully-featured Multinet instead (another third party product). Contact the +IRAF project for further information on networking between UNIX and VMS +systems. +.PP +Once IRAF networking is enabled, objects resident on the server node may be +accessed from within IRAF merely by specifying the node name in the object +name, with a "\fInode!\fR" prefix. For example, if \fIfoo\fR is a network +node, +.XS +cl> page foo!hlib$motd +cl> allocate foo!mta +cl> devstatus foo!mta +.XE +.PP +In a network of "trusted hosts" the network connection will be made +automatically, without a password prompt. A password prompt will be +generated if the user does not have permission to access the remote node +with UNIX commands such as \fIrsh\fR. Each user has a .irafhosts file in +their UNIX login directory which can be used to exercise more control over +how the system connect to remote hosts. See the discussion of IRAF +networking in the \fIIRAF Version 2.10 Revisions Summary\fR, or in the V2.10 +system notes file, for a more in-depth discussion of how IRAF networking +works. +.PP +To keep track of where files are in a distributed file system, IRAF uses +\fBnetwork pathnames\fR. A network pathname is a name such as +"foo!/tmp3/images/m51.pix", i.e., a host or IRAF filename with the node name +prepended. The network pathname allows an IRAF process running on any node +to access an object regardless of where it is located on the network. +.PP +Inefficiencies can result when image pixel files are stored on disks which +are cross-mounted using NFS. The typical problem arises when imdir (the +pixel file storage directory) is set to a path such as "/data/iraf/user/", +where /data is a NFS mounted directory. Since NFS is transparent to +applications like IRAF, IRAF thinks that /data is a local disk and the +network pathame for a pixel file will be something like "foo!/data/iraf" +where "foo" is the hostname of the machine on which the file is written. If +the image is then accessed from a different network node the image data will +be accessed via an IRAF networking connection to node "foo", followed by an +NFS connection to the node on which the disk is physically mounted, causing +the data to traverse the network twice, slowing access and unnecessarily +loading the network. +.LP +A simple way to avoid this sort of problem is to include the server name +in the imdir, e.g., +.XS +cl> set imdir = "server!/data/iraf/user/" +.XE +This also has the advantage of avoiding NFS for pixel file access - NFS is +fine for small files but can load the server excessively when used to access +bulk image data. +.PP +Alternatively, one can set imdir to a value such as "HDR$pixels/", or +disable IRAF networking for disk file access. In both cases NFS will be +used for image file access. +.NH 3 +Configuring the IRAF account +.PP +The IRAF account, i.e., what one gets when one logs into UNIX as "iraf", +is the account used by the IRAF site manager to work on the IRAF system. +Anyone who uses this account is in effect a site manager, since they have +permission to modify, delete, or rebuild any part of IRAF. For these and +other reasons (e.g., concurrency problems) it is recommended that all routine +use of IRAF be performed from other accounts (user accounts). +.PP +If the system has been installed according to the instructions given in the +installation guide the login directory for the IRAF account will be +iraf/local. This directory contains both a \f(CW.login\fR file +defining the environment for the IRAF account, and a number of other "dot" +files used to setup the IRAF system manager's working environment. +.PP +Most site managers will probably want to customize these files according to +their personal preferences. In doing this please use caution to avoid losing +environment definitions, etc., which are essential to the correct operation +of IRAF, including IRAF software development. +.PP +The default login.cl file supplied in the IRAF login directory uses machine +independent pathnames and should work as-is (no need to do a \fImkiraf\fR - +in fact \fImkiraf\fR has safeguards against inadvertent use within the IRAF +directories and may not work in iraf/local). It may be necessary to edit +the .login file to modify the way the environment variable \f(CWIRAFARCH\fR +is defined. This variable, required for software development but optional +for merely using IRAF, must be set to the name of the desired machine +architecture, e.g., sparc, vax, rs6000, ddec, etc. If it is set to the name +of an architecture for which there are no binaries, e.g., generic, the CL +may not run, so be careful. The alias \fIsetarch\fR, defined in the iraf +account .login, is convenient for setting the desired architecture for IRAF +execution and software development. +.NH 3 +Configuring user accounts for IRAF +.PP +User accounts should be loosely modeled after the IRAF account. All that is +required for a user to run IRAF is that they run \fImkiraf\fR in their +desired IRAF login directory before starting up the CL. Defining +\f(CWIRAFARCH\fR in the user environment is not required unless the user +will be doing any IRAF based software development (including IMFORT). +Programmers doing IRAF software development may wish to source +hlib$irafuser.csh in their .login file as well. + +.NH 2 +Tuning Considerations +.NH 3 +Stripping the system to reduce disk usage +.PP +If the system is to be installed on multiple CPUs, or if a production +version is to be installed on a workstation, it may be necessary or +desirable to strip the system of all non-runtime files to save disk space. +This equates to deleting all the sources and all the reference manuals and +other documentation, excluding the online manual pages. A special utility +called \fIrmfiles\fR (in the SOFTOOLS package) is provided for this +purpose. It is not necessary to run \fIrmfiles\fR directly to strip the +system. The preferred technique is to use "mkpkg strip" as in the following +example (this may be executed from either the host system or from within +IRAF). +.XS +% cd $iraf +% mkpkg strip +.XE +.PP +This will preserve all runtime files, permitting use of the standard system +as well as user software development. Note that only the IRAF core system +is stripped, i.e., if you want to strip any external layered software +products, such as the NOAO package, a \fImkpkg strip\fR must be executed +separately for each - \fIcd\fR to the root directory of the external package +first. A tape backup of a system should always be made before the system is +stripped; keep the backup indefinitely as it may be necessary to restore the +sources in order to, e.g., install a bug fix or add-on software product. + +.NH +Software Management +.NH 2 +Multiple architecture support +.PP +Often the computing facilities at a site consist of a heterogeneous network +of workstations and servers. These machines will often have quite different +architectures. Considering only a single vendor like Sun, as of 1992 one +sees the three major architectures SPARC, Motorola 68020, and Intel 80386, +and several minor variations on these architectures, i.e., the floating +point options for the Sun-3, namely the Motorola 68881 coprocessor, the Sun +floating point accelerator (FPA), and software floating point (Sun is trying +to phase some of these out but the need for multiple architecture support is +not likely to go away). On the Decstation we currently support two +architectures, one (ddec) using the DEC Fortran compiler, and the other +(dmip) using the MIPS Risc Fortran compiler. Other systems such as SGI/IRAF +or the VAXstation support only a single architecture. +.PP +Since IRAF is a large system it is undesirable to have to maintain a separate +copy of IRAF for each machine architecture on a network. For this reason +IRAF provides support for multiple architectures within a single copy of IRAF. +To be accessible by multiple network clients, this central IRAF system will +typically be NFS mounted on each client. +.PP +Multiple architecture support is implemented by separating the IRAF sources +and binaries into different directory trees. The sources are architecture +independent and hence sharable by machines of any architecture. All of the +architecture dependence is concentrated into the binaries, which are collected +together into the so-called BIN directories, one for each architecture. +The BIN directory contains all the object files, object libraries, executables, +and shared library images for an architecture, supporting both IRAF execution +and software development for that architecture. A given system can support +any number of BIN directories, and therefore any number of architectures. +.PP +In IRAF terminology, when we refer to an "architecture" what we really +mean is a type of BIN. The correspondence between BINs and hardware +architectures is not necessarily one-to-one, i.e., multiple BINs can exist +for a single compiler architecture by compiling the system with different +compilation flags, as different versions of the software, and so on. +Examples of some currently supported software architectures are shown below. +.DS +.TS +center; +ci ci ci +l l l. +Architecture System Description +.sp +generic any no binaries (default IRAF configuration) +sparc Sun-4 Sun SPARC (RISC) architecture, integral fpu +f68881 Sun-3 mc68020, 68881 floating point coprocessor +pg Sun-4 Sun/IRAF compiled for profiling +ddec Decstation DEC Fortran version of DSUX/IRAF +dmip Decstation MIPS Risc Fortran version of DSUX/IRAF +rs6000 IBM IBM RS/6000 running AIX +irix SGI SGI IRIX, MIPS cpu +f2c Macintosh A/UX, using Fortran-to-C translation and GCC +.TE +.DE +.PP +Most of these correspond to hardware architectures or floating point hardware +options. The exceptions are the generic architecture, which is what +the distributed system is configured to by default (to avoid having any +architecture dependent binary files mingled with the sources), and the +"pg" architecture, which is not normally distributed to user sites, +but is a good example of a custom software architecture used for software +development. +.PP +When running IRAF on a system configured for multiple architectures, +selection of the BIN (architecture) to be used is controlled by the UNIX +environment variable \f(CWIRAFARCH\fR, e.g., +.XS +% setenv IRAFARCH ddec +.XE +would cause IRAF to run using the ddec architecture, corresponding to the +BIN directory bin.ddec. Once inside the CL one can check the current +architecture by entering one of the following commands (the output in each +case is shown as well). +.XS +cl> show IRAFARCH +ddec +.XE +or +.XS +.cc # +cl> show arch +.ddec +#cc +.XE +.LP +If IRAFARCH is undefined at CL startup time a default architecture will be +selected based on the current machine architecture, the available floating +point hardware, and the available BINs. The IRAFARCH variable controls not +only the architecture of the executables used to run IRAF, but the libraries +used to link IRAF programs, when doing software development from within the +IRAF or host environment. +.PP +Additional information on multiple architecture support is provided in the +system notes file for V2.8, file doc$notes.v28. + +.NH 2 +Shared libraries +.PP +Among the UNIX based versions of IRAF, currently only Sun/IRAF supports +shared libraries, although we are looking into adding shared library support +to the other, mostly SysV based versions of IRAF. SunOS has an unusually +powerful virtual file system architecture, and several years ago was one of +the few UNIX systems supporting shared, mapped access to files. This is no +longer the case however, and nowadays most versions of UNIX provide some +sort of shared library facility. Shared libraries result in a considerable +savings in disk space, so eventually we will probably implement the facility +for additional platforms. In the meanwhile, if you are running IRAF on a +system other than a Sun this section can be skipped. +.PP +Sun/IRAF provides a shared library facility for SunOS 4.0 and later versions +of SunOS (but not for SunOS-3). All architectures are supported. +So long as everything is working properly, the existence and use of the shared +library should be transparent to the user and to the site manager. +This section gives an overview of the shared library facility to point +the reader in the right direction in case questions should arise. +.PP +What the shared library facility does is take most of the IRAF system +software (currently the contents of the \f(CWex\fR, \f(CWsys\fR, +\f(CWvops\fR, and \f(CWos\fR libraries) and link it together into a special +sharable image, the file \f(CWS\fIn\fP.e\fR in each core system BIN +directory (\fIn\fR is the shared image version number, e.g. "S6.e"). This +file is mapped into the virtual memory of each IRAF process at process +startup time. Since the shared image is shared by all IRAF processes, each +process uses less physical memory, and the process pagein time is reduced, +speeding process execution. Likewise, since the subroutines forming the +shared image are no longer linked into each individual process executable, +substantial disk space is saved for the BIN directories. Link time is +correspondingly reduced, speeding software development. +.PP +The shared library facility consists of the \fBshared image\fR itself, +which is an actual executable image (though not runnable on all systems), +and the \fBshared library\fR, contained in the library lib$libshare.a, +which defines each VOS symbol (subroutine), and which is what is linked +into each IRAF program. The shared library object module does not consume +any space in the applications program, rather it consists entirely of symbols +pointing to \fBtransfer vector\fR slots in the header area of the shared +image. The transfer vector slots point to the actual subroutines. +.PP +When an IRAF program is linked with \fIxc\fR, one has the option of linking +with either the shared library or the individual system libraries. Linking +with the shared library is the default; the \f(CW-z\fR flag disables linking +with the shared library. In the final stages of linking \fIxc\fR runs the +HSI utility \fIedsym\fR to edit the symbol table of the output executable, +modifying the shared library (VOS) symbols to point directly into the shared +image (to facilitate symbolic debugging), optionally deleting all shared +library symbols, or performing some other operation upon the shared library +symbols, depending upon the \fIxc\fR link flags given. +.PP +At process startup time, upon entry to the process main (a C main for +Sun/IRAF) the shared image will not yet have been mapped into the address +space of the process, hence any attempted references to VOS symbols would +result in a segmentation violation. The \fIzzstrt\fR procedure, called by +the process main during process startup, opens the shared image file and +maps it into the virtual space of the IRAF program. Once the IRAF main +prompt appears (when running an IRAF process standalone), all initialization +will have completed. +.PP +Each BIN, if linked with the shared library, will have its own shared image +file \f(CWS\fIn\fP.e\fR. If the shared image is relinked this file will be +moved to \f(CWS\fIn\fP.e.1\fR and the new shared image will take its place; +any old shared image files should eventually be deleted to save disk space, +once any IRAF processes using them have terminated. Normally when the +shared image is rebuilt it is not necessary to relink applications programs, +since the transfer vector causes the linked application to be unaffected +by relocation of the shared image functions. +.PP +If the shared image is rebuilt and its version number (the \fIn\fR in +\f(CWS\fIn\fP.e\fR) is incremented, the transfer vector is rebuilt the new +shared image cannot be used with previously linked applications. These +old applications will still continue to run, however, so long as the older +shared image is still available. It is common practice to have at least +two shared image versions installed in a BIN directory. +.PP +Further information on the Sun/IRAF shared library facility in given in the +IRAF V2.8 system notes file. In particular, anyone doing extensive IRAF +based software development should review this material, e.g., to learn how +to debug processes that are linked with the shared image. + +.NH 2 +Layered software support +.PP +An IRAF installation consists of the core IRAF system and any number of +external packages, or "layered software products". As the name suggests, +layered software products are layered upon the core IRAF system. Layered +software requires the facilities of the core system to run, and is portable +to any computer which already runs IRAF. Any number of layered products can +be installed in IRAF to produce the IRAF system seen by the user at a +given site. +.PP +The support provided by IRAF for layered software is essentially the same as +that provided for maintaining the core IRAF system itself (the core system +is a special case of a layered package). Each layered package (usually this +refers to a suite of subpackages) is a system in itself, similar in +structure to the core IRAF system. Hence, there is a LIB, one or more BINs, +a help database, and all the sources and runtime files. A good example of +an external package is the NOAO package. Except for the fact that NOAO is +rooted in the IRAF directories, NOAO is equivalent to any other layered +product, e.g., STSDAS, TABLES, XRAY, CTIO, NSO, ICE, GRASP, NLOCAL, STEWARD, +and so on. In general, layered products should be rooted somewhere outside +the IRAF directory tree to simplify updates. + +.NH 2 +Software management tools +.PP +IRAF software management is performed with a standard set of tools, +consisting of the tasks in the SOFTOOLS package, plus the host system +editors and debuggers. Some of the most important and often used tools for +IRAF software development and software maintenance are the following. +.sp +.RS +.IP \f(CWmkhelpdb\fP 20 +Updates the HELP database of the core IRAF system or an external package. +The core system, and each external package, has its own help database. +The help database is the machine independent file \f(CWhelpdb.mip\fR in the +package library (LIB directory). The help database file is generated with +\fImkhelpdb\fR by compiling the \f(CWroot.hd\fR file in the same directory. +.IP \f(CWmkpkg\fP 20 +The "make-package" utility. Used to make or update package trees. +Will update the contents of the current directory tree. When run at +the root iraf directory, updates the full IRAF system; when run at the +root directory of an external package, updates the external package. +Note that updating the core IRAF system does not update any external +packages (including NOAO). When updating an external package, the +package name must be specified, e.g., "\fImkpkg -p noao\fR". +.IP \f(CWrmbin\fP 20 +Descends a directory tree or trees, finding and optionally listing or +deleting all binary files therein. This is used, for example, to strip +the binaries from a directory tree to leave only sources, to force +\fImkpkg\fR to do a full recompile of a package, or to locate all the +binaries files for some reason. IRAF has its own notion of what a binary +file is. By default, files with the "known" file extensions +(.[aoe], .[xfh] etc.) are classified as binary or text +(machine independent) files immediately, +while a heuristic involving examination of the file data +is used to classify other files. Alternatively, a list of file extensions +to be searched for may optionally be given. +.IP \f(CWrtar,wtar\fP 20 +These are the portable IRAF tarfile writer (\fIwtar\fR) and reader +(\fIrtar\fR). About the only reasons to use these with the UNIX versions of +IRAF are if one wants to move only the machine independent or source files +(\fIwtar\fR, like \fIrmbin\fR, can discriminate between machine generated +and machine independent files), or if one is importing files written to a +tarfile on a VMS/IRAF system, where the files are blank padded and the +trailing blanks need to be stripped with \fIrtar\fR. +.IP \f(CWxc\fP 20 +The X (SPP) compiler. This is analogous to the UNIX \fIcc\fR except +that it can compile ".x" or SPP source files, knows how to link with the +IRAF system libraries and the shared library, knows how to read the +environment of external packages, and so on. +.RE +.sp +.PP +The SOFTOOLS package contains other tasks of interest, e.g., a program +\fImktags\fR for making a tags file for the \fIvi\fR editor, a help +database examine tool, and other tasks. Further information on these +tasks is available in the online help pages. + +.NH 2 +Modifying and updating a package +.PP +IRAF applications development is most conveniently performed from within the +IRAF environment, since testing must be done from within the environment. +The usual edit-compile-test development cycle is illustrated below. This +takes place within the \fIpackage directory\fR containing all the files +specific to a given package. +.RS +.IP \(bu +Edit one or more source files. +.IP \(bu +Use \fImkpkg\fR to compile any modified files, or files which include a +modified file, and relink the package executable. +.IP \(bu +Test the new executable. +.RE +.PP +The mkpkg file for a package can be written to do anything, +but by convention the following commands are usually provided. +.sp +.RS +.IP "\f(CWmkpkg\fP" 20 +The \fImkpkg\fR command with no arguments does the default mkpkg operation; +for a subpackage this is usually the same as \fImkpkg relink\fR below. For +the root mkpkg in a layered package it udpates the entire layered package. +.IP "\f(CWmkpkg libpkg.a\fP" 20 +Updates the package library, compiling any files which have been modified or +which reference include files which have been modified. Private package +libraries are intentionally given the generic name libpkg.a to symbolize +that they are private to the package. +.IP "\f(CWmkpkg relink\fP" 20 +Rebuilds the package executable, i.e., updates the package library and +relinks the package executable. By convention, this is the file +xx_\fIpkgname\fR.e\fR in the package directory, where \fIpkgname\fR is the +package name. +.IP "\f(CWmkpkg install\fP" 20 +Installs the package executable, i.e., renames the xx_foo.e file to x_foo.e +in the global BIN directory for the layered package to which the subpackage +\fIfoo\fR belongs. +.IP "\f(CWmkpkg update\fP" 20 +Does everything, i.e., a \fIrelink\fR followed by an \fIinstall\fR. +.RE +.sp +.PP +If one wishes to test the new program before installing it one should do a +\fIrelink\fR (i.e., merely type "mkpkg" since that defaults to relink), then +run the host system debugger on the resultant executable. The process is +debugged standalone, running the task by giving its name to the standalone +process interpreter. The CL task \fIdparam\fR is useful for dumping a +task's parameters to a text file to avoid having to answer parameter queries +during process execution. The LOGIPC debugging facility introduced in V2.10 +is also useful for debugging subprocesses. If the new program is to be +tested under the CL before installation, a \fItask\fR statement can be +interactively typed into the CL to cause the CL to run the "xx_" version of +the package executable, rather than old installed version. +.PP +When updating a package other than in the core IRAF system, the \f(CW-p\fR +flag, or the equivalent \f(CWPKGENV\fR environment variable, must be used to +indicate the system or layered product being updated. For example, "mkpkg +-p noao update" would be used to update one of the subpackages of the NOAO +layered package. If the package being updated references any libraries or +include files in \fIother\fR layered packages, those packages must be +indicated with a "-p pkgname" flag as well, to cause the external package to +be searched. +.PP +The CL process cache can complicate debugging and testing if one forgets +that it is there. When a task is run under the CL, the executing process +remains idle in the CL process cache following task termination. If a new +executable is installed while the old one is still in the process cache, the +CL will automatically run the new executable (the CL checks the modify date +on the executable file every time a task is run). If however an executable is +currently running, either in the process cache or because some other user is +using the program, it may not be possible to set debugger breakpoints. +.PP +The IRAF shared image can also complicate debugging, although for most +applications-level debugging the shared library is transparent. By default +the shared image symbols are included in the symbol table of an output +executable following a link, so in a debug session the shared image will +appear to be part of the applications program. When debugging a program +linked with the shared library, the process must be run with the \f(CW-w\fR +flag to cause the shared image to be mapped with write permission, allowing +breakpoints to be set in the shared image (that is, you type something like +":r -w" when running the process under the debugger). Linking with the +\f(CW-z\fR flag will prevent use of the shared image entirely. +.PP +A full description of these techniques is beyond the scope of this manual, +but one need not be an expert at IRAF software development techniques to +perform simple updates. Most simple revisions, e.g., bug fixes or updates, +can be made by merely editing or replacing the affected files and typing +.XS +cl> mkpkg +.XE +or +.XS +cl> mkpkg update +.XE +to update the package. + +.NH 2 +Installing and maintaining layered software +.PP +The procedures for installing layered software products are similar to those +used to install the core IRAF system, or update a package. +Layered software may be distributed in source only form, or with binaries; +it may be configured for a single architecture, or may be preconfigured +to support multiple architectures. The exact procedures to be followed +to install a layered product will in general be product dependent, and should +be documented in the installation guide for the product. +.LP +In brief, the procedure to be followed should resemble the following: +.RS +.IP \(bu +Create the root directory for the new software, somewhere outside the +IRAF directories. +.IP \(bu +Restore the files to disk from a tape or network archive distribution file. +.IP \(bu +Edit the core system file hlib$extern.pkg to "install" the new package in +IRAF. This file is the sole link between the IRAF core system and the +external package. +.IP \(bu +Configure the package BIN directory or directories, either by restoring +the BIN to disk from an archive file, or by recompiling and relinking the +package with \fImkpkg\fR. +.RE +.LP +As always, there are some little things to watch out for. +When using \fImkpkg\fR on a layered product, you must give the name +of the system being operated upon, e.g., +.XS +cl> mkpkg -p foo update +.XE +where \fIfoo\fR is the system or package name, e.g., "noao", "local", etc. +The \f(CW-p\fR flag can be omitted by defining \f(CWPKGENV\fR in your +UNIX environment, but this only works for updates to a single package. +.PP +An external system of packages may be configured for multiple architecture +support by repeating what was done for the core system. One sets up several +BIN directories, one for each architecture, named \f(CWbin.\fIarch\fR, where +\fIarch\fR is "sparc", "ddec", "rs6000", etc. These directories, or +symbolic links to the actual directories, go into the root directory of the +external system. A symbolic link \f(CWbin\fR pointing to an empty directory +bin.generic, and the directory itself, are added to the system's root +directory. The system is then stripped of its binaries with \fIrmbin\fR, if +it is not already a source only system. Examine the file zzsetenv.def in +the layered package LIB directory to verify that the definition for the +system BIN (which may be called anything) includes the string "(arch)", +e.g., +.XS +set noaobin = "noao$bin(arch)/" +.XE +.LP +The binaries for each architecture may then be generated by configuring the +system for the desired architecture and running \fImkpkg\fR to update the +binaries, for example, +.XS +cl> cd foo +cl> mkpkg sparc +cl> mkpkg -p foo update >& spool & +.XE +where \fIfoo\fR is the name of the system being updated. If any questions +arise, examination of a working example of a system configured for multiple +architecture support (e.g., the NOAO packages) may reveal the answers. +.PP +Once installed and configured, a layered product may be deinstalled merely +by archiving the package directory tree, deleting the files, and commenting +out the affected lines of hlib$extern.pkg. With the BINs already configured +reinstallation is a simple matter of restoring the files to disk and editing +the extern.pkg file. + +.NH 2 +Configuring a custom LOCAL package +.PP +Anyone who uses IRAF enough will eventually want to add their own software +to the system, by copying and modifying the distributed versions of +programs, by obtaining and installing isolated programs written elsewhere, +or by writing new programs of their own. A single user can do this by +developing software for their own personal use, defining the necessary +\fItask\fR statements etc. to run the software in their personal login.cl +or loginuser.cl file. To go one step further and install the new software +in IRAF so that it can be used by everyone at a site, one must configure a +custom local package. +.PP +The procedures for configuring and maintaining a custom LOCAL package are +similar to those outlined in \(sc3.5 for installing and maintaining +layered software, since a custom LOCAL will in fact be a layered software +product, possibly even something one might want to export to another site +(although custom LOCALs may contain non-portable or site specific software). +.PP +To make a custom local you make a copy of the "template local" package +(iraf$local) somewhere outside the IRAF directory tree, change the name +to whatever you wish to call the new layered package, and install it as +outlined in \(sc3.5. The purpose of the template local is to provide the +framework necessary for a external package; a couple of simple tasks are +provided in the template local to serve as examples. Once you have +configured a local copy of the template local and gotten it to compile and +link, it should be a simple matter to add new tasks to the existing +framework. + +.NH 2 +Updating the full IRAF system +.PP +This section will describe how to recompile or relink IRAF. Before we get +into this however, it should be emphasized that \fImost users will never +need to recompile or relink IRAF\fR. In fact, this is not something that +one should attempt lightly - don't do it unless you have some special +circumstance which requires a custom build of the system (such as a port). +Even then you might want to set up a second copy of IRAF to be used for the +experiment, keeping the production system around as the standard system. If +you change the system it is a good idea to make sure that you can undo the +change. +.PP +While the procedure for building IRAF is straightforward, it is easy to make +a mistake and without considerable knowledge of IRAF it may be difficult to +recover from such a a mistake (for example, running out of disk space during +a build, or an architecture mismatch resulting in a corrupted library or +shared image build failure). More seriously, the software - the host +operating system, the host Fortran compiler, the local system configuration, +and IRAF - is changing constantly. A build of IRAF brings all these things +together at one time, and every build needs to be independently and +carefully tested. An OS upgrade or a new version of the Fortran compiler +may not yet be supported by the version of IRAF you have locally. Any +problems with the host system configuration can cause a build to fail, or +introduce bugs. For example, systems which support multiple Fortran +compilers or which require the user to install and configure the compiler +are a common source of problems. +.PP +The precompiled binaries we ship with IRAF have been carefully prepared and +tested, usually over a period of months prior to a major release. They are +the same as are used at NOAO and at most IRAF sites, so even if there are +bugs they will likely have already been seen elsewhere and a workaround +determined. If the bugs are new then since we have the exact same IRAF +system we are more likely to be able to reproduce and fix the bug. Often +the bug is not in the IRAF software at all but in the host system or IRAF +configuration. As soon as an executable is rebuilt (even something as +simple as a relink) you have new, untested, software. +.NH 3 +The BOOTSTRAP +.PP +To fully build IRAF from the sources is a three step process. First the +system is "bootstrapped", which builds the host system interface (HSI) +executables. A "sysgen" of the core system is then performed; this compiles +all the system libraries and builds the core system applications. Finally, +the bootstrap is then repeated, to make use of some of the functions from +the IRAF libraries compiled in step two. +.PP +To bootstrap IRAF, login as IRAF and enter the commands shown below. +This takes a while and generates a lot of output, so the output should be +spooled in a file. Here, \fIarch\fR refers to the IRAF architecture you +wish to build for. +.XS +% cd $iraf +% mkpkg \fIarch\fP +% cd $iraf/unix +% reboot >& spool & +.XE +.PP +There are two types of bootstrap, the initial bootstrap starting from a +source only system, called the NOVOS bootstrap, and the final or VOS +bootstrap, performed once the IRAF system libraries \f(CWlibsys.a\fR and +\f(CWlibvops.a\fR exist. The bootstrap script \fIreboot\fR will +automatically determine whether or not the VOS libraries are available and +will perform a NOVOS bootstrap if the libraries cannot be found. It is +important to restore the desired architecture before attempting a +bootstrap, as otherwise a NOVOS bootstrap will be performed. +.NH 3 +The SYSGEN +.PP +By sysgen we refer to an update of the core IRAF system - all of the files +comprising the runtime system, excluding the HSI which is generated by the +bootstrap. On a source only system, the sysgen will fully recompile the +core system, build all libraries and applications, and link and install the +shared image and executables. On an already built system, the sysgen +scans the full IRAF directory tree to see if anything is out of date, +recompiles any files that need it, then relinks and installs new executables. +.PP +To do a full sysgen of IRAF one merely runs \fImkpkg\fR at the IRAF root. +If the system is configured for multiple architecture support one must +repeat the sysgen for each architecture. Each sysgen builds or updates a +single BIN directory. Since a full sysgen takes a long time and generates a +lot of output which later has to be reviewed, it is best to run the job in +batch mode with the output redirected. For example to update the ddec +binaries on a Decstation: +.XS +% cd $iraf +% mkpkg ddec +% mkpkg >& spool & +.XE +To watch what is going on after this command has been submitted and while +it is running, try +.XS +% tail -f spool +.XE +Sysgens are restartable, so if the sysgen aborts for any reason, simply fix +the problem and start it up again. Modules that have already been compiled +should not need to be recompiled. How long the sysgen takes depends upon +how much work it has to do. The worst case is if the system and +applications libraries have to be fully recompiled. If the system libraries +already exist they will merely be updated. Once the system libraries are up +to date the sysgen will rebuild the shared library if any of the system +libraries involved were modified, then the core system executables will be +relinked. +.PP +A full sysgen generates a lot of output, too much to be safely reviewed for +errors by simply paging the spool file. Enter the following command to +review the output (this assumes that the output has been saved in a file +named "spool"). +.XS +% mkpkg summary +.XE +It is normal for a number of compiler messages warning about assigning +character data to an integer variable to appear in the spooled output +if the full system has been compiled. There should be no serious error +messages if a supported and tested system is being recompiled. +.PP +The above procedure only updates the core IRAF system. To update a layered +product one must repeat the sysgen process for the layered system. For +example, to update the sparc binaries for the NOAO package: +.XS +% cd $iraf/noao +% mkpkg ddec +% mkpkg -p noao >& spool & +.XE +This must be repeated for each supported architecture. Layered systems are +independent of one another and hence must be updated separately. +.PP +To force a full recompile of the core system or a layered package, one can +use \fIrmbin\fR to delete the objects, libraries, etc. scattered throughout +the system, or do a "mkpkg generic" and then delete the \f(CWOBJS.arc.Z\fR +file in the BIN one wishes to regenerate (the latter approach is probably +safest). +.PP +A full IRAF core system sysgen currently takes anywhere from 3 to 30 hours, +depending upon the system (e.g. from 30 hours on a VAX 11/750, to 3 hours on +a big modern server). On most systems a full sysgen is a good job to run +overnight. +.PP +.NH 3 +Localized software changes +.PP +The bootstrap and the sysgen are unusual in that they update the entire +HSI, core IRAF system, or layered package. Many software changes are more +localized. If only a few files are changed a sysgen will pick up the changes +and update whatever needs to be updated, but for localized changes a sysgen +really does more than it needs to (if the changes are scattered all over +the system an incremental sysgen-relink will still be best). +.PP +To make a localized change to a core system VOS library and update the +linked applications to reflect the change all one really needs to do is +change the desired source files, run \fImkpkg\fR in the library source +directory to compile the modules and update the affected libraries, and then +build a new IRAF shared image (this assumes that the changes affect only the +libraries used to make the shared image, i.e., libsys, libex, libvops, and +libos). Updating only the shared image, without relinking all the +applications, has the advantage that you can put the runtime system back the +way it was by just swapping the old shared image back in - a single file. +.PP +For example, assume we want to make a minor change to some files in the VOS +interface IMIO, compiling for the sparc architecture on SunOS, which uses a +shared library. We could do this as follows (this assumes that one is +logged in as IRAF and that the usual IRAF environment is defined). +.XS +% whoami +iraf +% cd $iraf +% mkpkg sparc +% cd imio + \fR(edit the files)\fP +% mkpkg \fR# update IMIO libraries (libex)\fP +% +% cd $iraf/bin.sparc \fR# save copy of old shared image\fP +% cp S6.e S6.e.V210 +% +% cd shlib +% tar -cf ~/shlib.tar . \fR# backup shlib just in case\fP +% mkpkg update \fR# make and install new shared image\fP +.XE +.PP +If IRAF is not configured with shared libraries, one must relink the full +IRAF system and all layered packages for the change to take effect. This +is done by running \fImkpkg\fR at the root of the core system and each layered +package. For example, on an IBM RS/6000, +.XS +% whoami +iraf +% cd $iraf +% mkpkg rs6000 +% cd imio + \fR(edit the files)\fP +% cd iraf +% mkpkg \fR# update the core system\fP +% +% cd noao +% mkpkg rs6000 +% mkpkg -p noao \fR# update the NOAO packages\fP +.XE +.LP +and so on, for each layered package. +.PP +Changing applications is even easier. Ensure that the system architecture +is set correctly (i.e. "mkpkg \fIarch\fR" at the iraf or layered package root), +edit the affected files in the package source directory, and type "mkpkg -p + update" in the root directory of the package being edited. This +will compile any modified files, and link and install a new executable. +You can do this from within the CL and immediately run the revised program. +.PP +We should emphasize again that, although we document the procedures for +making changes to the software here, to avoid introducing bugs we do not +recommend changing any of the IRAF software except in unusual (or at least +carefully controlled) circumstances. To make custom changes to an +application, it is best to make a local copy of the full package somewhere +outside the standard IRAF system. If changes are made to the IRAF system +software it is best to set up an entire new copy of IRAF on a machine +separate from the normal production installation, so that one can experiment +at will without affecting the standard system. An alternative which does +not require duplicating the full system is to use the \f(CWIRAFULIB\fR +environment variable. This can be used to safely experiment with custom +changes to the IRAF system software outside the main system; IRAFULIB lets +you define a private directory to be searched for IRAF global include files, +libraries, executables, etc., allowing you to have your own private versions +of any of these. See the system notes files for further information on how +to use IRAFULIB. + +.NH +Graphics and Image Display +.PP +IRAF itself is device and window system independent, hence it can be used +with any windowing system such as X11 or SunView, or with hardware graphics +and display devices. Nowadays most people will be running IRAF on a UNIX +workstation under X11. At the time that this is being written, IRAF is most +commonly run under X11 using \fIxterm\fR for graphics and \fIsaoimage\fR for +image display. Binaries for these applications are included in the IRAF +distribution if not already provided with the window system software on the +host system. New graphics and image display clients are being developed for +use with IRAF running under X11; contact the IRAF group for further +information on the availability of these products. +.NH 2 +Using the workstation with a remote compute server +.PP +A common mode of operation with a workstation is to run IRAF under a window +system directly on the workstation which runs IRAF, accessing files either +on a local disk, or on a remote disk via a network interface (NFS, IRAFKS, +etc.). It is also possible, however, to run the window system on the +workstation, but run IRAF on a remote node, e.g., some powerful compute +server such as a large UNIX server, a large VAX, vector minisupercomputer, +supercomputer, etc., possibly quite some distance away. This is done by +logging onto the workstation, starting up the window system, logging onto +the remote machine with \fIrlogin\fR, \fItelnet\fR, or whatever, and +starting up IRAF on the remote node. +.PP +If X11 is running on the local workstation as well as on the remote system, +and one's favorite X11 client it installed on the remote system, then the +networking support built into X11 can be used to display and plot remotely. +This is not always possible however. If the necessary X11 clients are not +available on the remote system or the networking connection does not support +X11, it is still possible to work remotely using the networking capabilities +built into IRAF, provided one is already running IRAF on the remote node. +.LP +After IRAF comes up one need only type +.XS +cl> stty xterm +cl> reset node = \fIhostname\fP +.XE +to tell the remote IRAF that it is talking to an xterm window (for example) +and that the image display is on the network node \fIhostname\fR. + +.NH +Interfacing New Graphics Devices +.PP +There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +.NH 2 +Graphics terminals +.PP +The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal or terminal emulator, using the \fIstdgraph\fR +graphics kernel supplied with the system. All one need do to interface to a +new graphics terminal is add new graphcap and termcap entries for the device. +This can take anywhere from a few hours to a few days, depending on one's +level of expertise, and the characteristics of the device. Be sure to check +the contents of the dev$graphcap file to see if the terminal is already +supported, before trying to write a new entry. Useful documentation for +writing graphcap entries is the GIO reference manual and the HELP pages for +the \fIshowcap\fR and \fIstty\fR tasks (see \(sc2.2.6). Assistance with +interfacing new graphics terminals is available via the IRAF Hotline. +.NH 2 +Graphics plotters +.PP +The current IRAF system comes with several graphics kernels used to drive +graphics plotters. The standard plotter interface the SGI graphics kernel, +which is interfaced as the tasks \fIsgikern\fR and \fIstdplot\fR in the +PLOT package. Further information on the SGI plotter interface is given in +the paper \fIThe IRAF Simple Graphics Interface\fR, a copy of which is +included with the IRAF installation kit. +.PP +SGI device interfaces for most plotter devices already exist, and adding +support for new devices is straightforward. Sources for the SGI device +translators supplied with the distributed system are maintained in the +directory iraf/unix/gdev/sgidev. NOAO serves as a clearinghouse for new SGI +plotter device interfaces; contact us if you do not find support for a local +plotter device in the distributed system, and if you plan to implement a new +device interface let us know so that we may help other sites with the same +device. +.PP +The older NCAR kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +plots on devices supported by host-level NCAR metacode translators. The +host level NCAR metacode translators are not included in the standard IRAF +distribution, but public domain versions of the NCAR implementation for UNIX +systems are widely available. A site which already has the NCAR software +may wish to go this route, but the SGI interface will provide a more +efficient and simpler solution in most cases. +.PP +The remaining possibility with the current system is the \fIcalcomp\fR kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. To make use of such a library to get +plotter output on any devices supported by the interface, one may copy +the library to the hlib directory and relink the Calcomp graphics +kernel. +.PP +A graphcap entry for each new device will also be required. Information on +preparing graphcap entries for graphics devices is given in the GIO design +document, and many actual working examples will be found in the graphcap +file. The best approach is usually to copy one of these and modify it. +.NH 2 +Image display devices +.PP +The standard image display facility for a Sun workstation running the +SunView window system is \fIimtool\fR. Image display under the +MIT X window system is also available using the \fIsaoimage\fR display +server. This was developed for IRAF by SAO; distribution kits are available +from the IRAF network archive. At the time that this was written new +X11 based image display clients were being developed for or interfaced to +IRAF by several sites. Eventually, there will be a range of image display +clients to choose from and people will use the tool best suited to the +type of data analysis they are doing. +.PP +Some interfaces for hardware image display devices are also available, +although a general display interface is not yet included in the system. +Only the IIS model 70 and 75 are current supported by NOAO. Interfaces for +other devices are possible using the current datastream interface, which is +based on the IIS model 70 datastream protocol with extensions for passing +the WCS, image cursor readback, etc. (see the ZFIOGD driver in unix/gdev). +This is how all the current displays, e.g., imtool and ximage, and the IIS +devices, are interfaced, and there is no reason why other devices could not +be interfaced to IRAF via the same interface. Eventually this prototype +interface will be obsoleted and replaced by a more general interface. + +.NH +Host System Requirements +.PP +Any modern host system capable of running UNIX should be capable of running +IRAF as well. IRAF is supported on all the more popular UNIX platforms, +as well as on other operating systems such as VMS. +.PP +A typical small system is a single workstation with a local disk. In a +typical large installation there will be one or more large central compute +servers, each with several Gb of disk and many Mb of RAM, networked to a +number of personal or public workstations. For scientific use, a megapixel +color screen is desirable. +.NH 2 +Memory requirements +.PP +The windowing systems used in these workstations tend to be very memory +intensive; the typical screen with ten or so windows uses a lot of memory. +Interactive performance will suffer greatly if the system pages a lot. +Fortunately, memory is becoming relatively cheap. Typical workstation +memory sizes in 1992 range from 16 to 32 Mb. Servers will have several +times that. +.NH 2 +Disk requirements +.PP +IRAF itself requires anywhere from 60 to 150 Mb of memory depending upon +whether the system is stripped, on the size of the binaries, and on how many +architectures are supported. Since IRAF is an image processing system, +usually the disk requirements of the data will vastly outstrip those of IRAF +itself. The amount of space needed for the data to be processed varies +greatly and will depend upon the type of data being processed. A useful +system requires from several hundred Mb to 1 Gb of disk space. + +.SH +Appendix A. The IRAF Directory Structure +.PP +The main branches of the IRAF directory tree are summarized below. +Beneath the directories shown are some 400 subdirectories, the largest +directory trees being \f(CWsys\fR, \f(CWpkg\fR, and \f(CWnoao\fR. +The entire contents of all directories other than \f(CWunix\fR, \f(CWlocal\fR, +and \f(CWdev\fR are fully portable, and are identical in all installations +of IRAF sharing the same version number. +.XS +bin \fR- the IRAF BIN directories\fP +dev \fR- device tables (termcap, graphcap, etc.)\fP +doc \fR- assorted IRAF manuals\fP +lib \fR- the system library; global files\fP +local \fR- iraf login directory; locally added software\fP +math \fR- sources for the mathematical libraries\fP +noao \fR- packages for NOAO data reduction\fP +pkg \fR- the IRAF applications packages\fP +sys \fR- the virtual operating system (VOS)\fP +unix \fR- the UNIX host system interface (HSI = kernel + bootstrap utilities)\fP +.XE +.LP +The contents of the \f(CWunix\fR directory (host system interface) are +as follows: +.XS +as \fR- assembler sources\fP +bin \fR- the HSI BIN directories\fP +boot \fR- bootstrap utilities (mkpkg, rtar, wtar, etc.)\fP +gdev \fR- graphics device interfaces (SGI device translators)\fP +hlib \fR- host dependent library; global files\fP +os \fR- OS interface routines (UNIX/IRAF kernel)\fP +reboot \fR- executable script run to reboot the HSI\fP +shlib \fR- shared library facility sources\fP +sun \fR- gterm and imtool sources (SunView)\fP +x11 \fR- saoimage and other X11 sources\fP +.XE +.PP +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. diff --git a/doc/v210revs.ms b/doc/v210revs.ms new file mode 100644 index 00000000..9739d32b --- /dev/null +++ b/doc/v210revs.ms @@ -0,0 +1,3460 @@ +.RP +.TL +IRAF Version 2.10 Revisions Summary +.AU +IRAF Group +.br +.K2 "" "" "\(dg" +.br +July 1992 + +.AB +A summary of the revisions made to the IRAF for the version 2.10 release are +presented. V2.10 is a major IRAF release, meaning that there were +significant additions to both the system and applications software, and the +release will eventually be made available on all supported systems. This +document deals with only the changes to the IRAF core system and NOAO +packages. The many layered packages available for IRAF follow independent +release schedules and are documented separately. This revisions summary is +divided into three main sections: system revisions, IRAF and NOAO +applications revisions, and revisions to the IRAF programming environment. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBIRAF System Revisions\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'2.1.\h'|0.9i'Starting up V2.10 IRAF\l'|5.6i.'\0\01 +.br +\h'|0.9i'2.1.1.\h'|1.5i'LOGIN.CL changes\l'|5.6i.'\0\01 +.br +\h'|0.9i'2.1.2.\h'|1.5i'Compatibility Issues\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'CL Enhancements\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Formatted scans and prints, scan from a pipe\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Unlearning package parameters\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Loading packages at login time\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.4.\h'|1.5i'Environment variables\l'|5.6i.'\0\04 +.br +\h'|0.4i'2.3.\h'|0.9i'System Management Related Changes\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.1.\h'|1.5i'Install script\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.2.\h'|1.5i'Caching of termcap entries\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.3.\h'|1.5i'Sorting of UNIX directories\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.4.\h'|1.5i'UMASK support\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.4.\h'|0.9i'Networking Enhancements\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.4.1.\h'|1.5i'New networking driver\l'|5.6i.'\0\05 +.br +\h'|1.5i'2.4.1.1.\h'|2.2i'How it works\l'|5.6i.'\0\06 +.br +\h'|1.5i'2.4.1.2.\h'|2.2i'The .irafhosts file\l'|5.6i.'\0\06 +.br +\h'|1.5i'2.4.1.3.\h'|2.2i'Compatibility\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.4.2.\h'|1.5i'The hosts file\l'|5.6i.'\0\07 +.br +\h'|0.4i'2.5.\h'|0.9i'Magtape System Enhancements\l'|5.6i.'\0\08 +.br +\h'|0.9i'2.5.1.\h'|1.5i'Basic usage\l'|5.6i.'\0\08 +.br +\h'|1.5i'2.5.1.1.\h'|2.2i'Logical device names\l'|5.6i.'\0\08 +.br +\h'|1.5i'2.5.1.2.\h'|2.2i'Device allocation\l'|5.6i.'\0\09 +.br +\h'|1.5i'2.5.1.3.\h'|2.2i'Device status\l'|5.6i.'\0\09 +.br +\h'|1.5i'2.5.1.4.\h'|2.2i'File positioning\l'|5.6i.'\0\10 +.br +\h'|1.5i'2.5.1.5.\h'|2.2i'Rewind\l'|5.6i.'\0\11 +.br +\h'|0.9i'2.5.2.\h'|1.5i'New magtape driver\l'|5.6i.'\0\11 +.br +\h'|1.5i'2.5.2.1.\h'|2.2i'Software structure\l'|5.6i.'\0\11 +.br +\h'|1.5i'2.5.2.2.\h'|2.2i'Driver features\l'|5.6i.'\0\12 +.br +\h'|0.9i'2.5.3.\h'|1.5i'Tapecap\l'|5.6i.'\0\12 +.br +\h'|1.5i'2.5.3.1.\h'|2.2i'Using tapecap\l'|5.6i.'\0\13 +.br +\h'|1.5i'2.5.3.2.\h'|2.2i'Configuring tapecap\l'|5.6i.'\0\13 +.br +\h'|1.5i'2.5.3.3.\h'|2.2i'Supported devices\l'|5.6i.'\0\14 +.br +\h'|0.9i'2.5.4.\h'|1.5i'Status output\l'|5.6i.'\0\15 +.br +\h'|0.9i'2.5.5.\h'|1.5i'Error recovery\l'|5.6i.'\0\16 +.br +\h'|0.9i'2.5.6.\h'|1.5i'Device optimization\l'|5.6i.'\0\16 +.br +\h'|0.9i'2.5.7.\h'|1.5i'MTIO interface changes\l'|5.6i.'\0\17 +.br +\h'|0.4i'2.6.\h'|0.9i'Graphics and Imaging Subsystem Enhancements\l'|5.6i.'\0\17 +.br +\h'|0.9i'2.6.1.\h'|1.5i'New graphics applications\l'|5.6i.'\0\17 +.br +\h'|0.9i'2.6.2.\h'|1.5i'Graphics system changes\l'|5.6i.'\0\17 +.br +\h'|1.5i'2.6.2.1.\h'|2.2i'Encapsulated postscript SGI kernel\l'|5.6i.'\0\17 +.br +\h'|1.5i'2.6.2.2.\h'|2.2i'Graphics output to the default printer\l'|5.6i.'\0\17 +.br +\h'|1.5i'2.6.2.3.\h'|2.2i'Tick spacing algorithm improved\l'|5.6i.'\0\17 +.br +\h'|1.5i'2.6.2.4.\h'|2.2i'Graphics metacode buffer\l'|5.6i.'\0\17 +.br +\h'|1.5i'2.6.2.5.\h'|2.2i'IMTOOL changes\l'|5.6i.'\0\17 +.br +\h'|1.5i'2.6.2.6.\h'|2.2i'IMTOOLRC changes\l'|5.6i.'\0\18 +.br +\h'|1.5i'2.6.2.7.\h'|2.2i'X11 support\l'|5.6i.'\0\18 +.br +\h'|0.4i'2.7.\h'|0.9i'Image Structures\l'|5.6i.'\0\18 +.br +\h'|0.9i'2.7.1.\h'|1.5i'Image I/O (IMIO)\l'|5.6i.'\0\18 +.br +\h'|1.5i'2.7.1.1.\h'|2.2i'Null images\l'|5.6i.'\0\18 +.br +\h'|1.5i'2.7.1.2.\h'|2.2i'Preallocating pixel file storage\l'|5.6i.'\0\18 +.br +\h'|1.5i'2.7.1.3.\h'|2.2i'Image templates now sorted\l'|5.6i.'\0\19 +.br +\h'|1.5i'2.7.1.4.\h'|2.2i'The dev$pix test image\l'|5.6i.'\0\19 +.br +\h'|0.9i'2.7.2.\h'|1.5i'Image kernels (IKI)\l'|5.6i.'\0\19 +.br +\h'|1.5i'2.7.2.1.\h'|2.2i'New PLF image kernel\l'|5.6i.'\0\19 +.br +\h'|1.5i'2.7.2.2.\h'|2.2i'OIF image kernel changes\l'|5.6i.'\0\20 +.br +\h'|1.5i'2.7.2.3.\h'|2.2i'STF image kernel changes\l'|5.6i.'\0\20 +.br +\h'|1.5i'2.7.2.4.\h'|2.2i'QPF image kernel changes\l'|5.6i.'\0\21 +.br +\h'|0.9i'2.7.3.\h'|1.5i'World coordinate system support (MWCS)\l'|5.6i.'\0\22 +.br +\h'|1.5i'2.7.3.1.\h'|2.2i'Applications support\l'|5.6i.'\0\22 +.br +\h'|1.5i'2.7.3.2.\h'|2.2i'New function drivers\l'|5.6i.'\0\22 +.br +\h'|1.5i'2.7.3.3.\h'|2.2i'WCS attributes\l'|5.6i.'\0\22 +.br +\h'|1.5i'2.7.3.4.\h'|2.2i'Axis mapping\l'|5.6i.'\0\22 +.br +\h'|1.5i'2.7.3.5.\h'|2.2i'MWCS save format\l'|5.6i.'\0\22 +.br +\h'|1.5i'2.7.3.6.\h'|2.2i'Bug fixes\l'|5.6i.'\0\22 +.br +\h'|0.9i'2.7.4.\h'|1.5i'Event files (QPOE)\l'|5.6i.'\0\23 +.br +\h'|1.5i'2.7.4.1.\h'|2.2i'Blocking factors\l'|5.6i.'\0\23 +.br +\h'|1.5i'2.7.4.2.\h'|2.2i'Parameter defaults\l'|5.6i.'\0\23 +.br +\h'|1.5i'2.7.4.3.\h'|2.2i'Referencing the current datafile in macros\l'|5.6i.'\0\23 +.br +\h'|1.5i'2.7.4.4.\h'|2.2i'Bitmask expressions\l'|5.6i.'\0\23 +.br +\h'|1.5i'2.7.4.5.\h'|2.2i'Large time filters\l'|5.6i.'\0\23 +.br +\h'|1.5i'2.7.4.6.\h'|2.2i'Default filters\l'|5.6i.'\0\24 +.br +\h'|1.5i'2.7.4.7.\h'|2.2i'Alternate coordinate systems\l'|5.6i.'\0\24 +.br +\h'|0.4i'2.8.\h'|0.9i'System Specific Changes\l'|5.6i.'\0\25 +.br +\h'|0.9i'2.8.1.\h'|1.5i'Sun/IRAF\l'|5.6i.'\0\25 +.sp +3.\h'|0.4i'\fBIRAF and NOAO package revisions\fP\l'|5.6i.'\0\26 +.br +\h'|0.4i'3.1.\h'|0.9i'Changes to the IRAF system packages\l'|5.6i.'\0\26 +.br +\h'|0.9i'3.1.1.\h'|1.5i'DATAIO package modifications\l'|5.6i.'\0\26 +.br +\h'|0.9i'3.1.2.\h'|1.5i'IMAGES package modifications\l'|5.6i.'\0\27 +.br +\h'|0.9i'3.1.3.\h'|1.5i'IMAGES.TV package reorganization and modifications\l'|5.6i.'\0\27 +.br +\h'|0.9i'3.1.4.\h'|1.5i'LISTS package modifications\l'|5.6i.'\0\27 +.br +\h'|0.9i'3.1.5.\h'|1.5i'OBSOLETE package added\l'|5.6i.'\0\27 +.br +\h'|0.9i'3.1.6.\h'|1.5i'PLOT package modifications\l'|5.6i.'\0\28 +.br +\h'|0.9i'3.1.7.\h'|1.5i'PROTO Package reorganization and modifications\l'|5.6i.'\0\28 +.br +\h'|0.9i'3.1.8.\h'|1.5i'Additions to XTOOLS and MATH\l'|5.6i.'\0\29 +.br +\h'|0.9i'3.1.9.\h'|1.5i'Glossary of new tasks in the IRAF core system\l'|5.6i.'\0\29 +.br +\h'|0.4i'3.2.\h'|0.9i'Changes to the NOAO Packages\l'|5.6i.'\0\29 +.br +\h'|0.9i'3.2.1.\h'|1.5i'ARTDATA package modifications\l'|5.6i.'\0\29 +.br +\h'|0.9i'3.2.2.\h'|1.5i'ASTUTIL package modifications\l'|5.6i.'\0\30 +.br +\h'|0.9i'3.2.3.\h'|1.5i'DIGIPHOT package modifications\l'|5.6i.'\0\30 +.br +\h'|0.9i'3.2.4.\h'|1.5i'DIGIPHOT.APPHOT package modifications\l'|5.6i.'\0\30 +.br +\h'|0.9i'3.2.5.\h'|1.5i'DIGIPHOT.DAOPHOT (TESTPHOT) package modifications\l'|5.6i.'\0\30 +.br +\h'|0.9i'3.2.6.\h'|1.5i'IMRED package modifications\l'|5.6i.'\0\31 +.br +\h'|0.9i'3.2.7.\h'|1.5i'IMRED.CCDRED package modifications\l'|5.6i.'\0\32 +.br +\h'|0.9i'3.2.8.\h'|1.5i'NOBSOLETE package added\l'|5.6i.'\0\32 +.br +\h'|0.9i'3.2.9.\h'|1.5i'NPROTO package modifications\l'|5.6i.'\0\32 +.br +\h'|0.9i'3.2.10.\h'|1.5i'ONEDSPEC package reductions\l'|5.6i.'\0\32 +.br +\h'|0.9i'3.2.11.\h'|1.5i'RV package added\l'|5.6i.'\0\34 +.br +\h'|0.9i'3.2.12.\h'|1.5i'TWODSPEC package modifications\l'|5.6i.'\0\34 +.br +\h'|0.9i'3.2.13.\h'|1.5i'TWODSPEC.APEXTRACT package modifications\l'|5.6i.'\0\35 +.br +\h'|0.9i'3.2.14.\h'|1.5i'TWODSPEC.LONGSLIT package modifications\l'|5.6i.'\0\36 +.br +\h'|0.9i'3.2.15.\h'|1.5i'Glossary of new tasks in the NOAO packages\l'|5.6i.'\0\36 +.sp +4.\h'|0.4i'\fBProgramming Environment Revisions\fP\l'|5.6i.'\0\39 +.br +\h'|0.4i'4.1.\h'|0.9i'Compatibility Issues\l'|5.6i.'\0\39 +.br +\h'|0.4i'4.2.\h'|0.9i'Portability Issues\l'|5.6i.'\0\39 +.br +\h'|0.4i'4.3.\h'|0.9i'Software Tools\l'|5.6i.'\0\39 +.br +\h'|0.9i'4.3.1.\h'|1.5i'LOGIPC feature\l'|5.6i.'\0\39 +.br +\h'|0.9i'4.3.2.\h'|1.5i'XC changes\l'|5.6i.'\0\40 +.br +\h'|0.9i'4.3.3.\h'|1.5i'SPPLINT code checker\l'|5.6i.'\0\41 +.br +\h'|0.9i'4.3.4.\h'|1.5i'Multiple architecture support\l'|5.6i.'\0\41 +.br +\h'|0.9i'4.3.5.\h'|1.5i'Package environments\l'|5.6i.'\0\41 +.br +\h'|0.9i'4.3.6.\h'|1.5i'Finding module sources\l'|5.6i.'\0\41 +.br +\h'|0.4i'4.4.\h'|0.9i'Programming Interface Changes\l'|5.6i.'\0\42 +.br +\h'|0.9i'4.4.1.\h'|1.5i'IEEE floating support\l'|5.6i.'\0\42 +.br +\h'|0.9i'4.4.2.\h'|1.5i'MATH libraries\l'|5.6i.'\0\42 +.br +\h'|0.9i'4.4.3.\h'|1.5i'CLIO interface\l'|5.6i.'\0\42 +.br +\h'|0.9i'4.4.4.\h'|1.5i'ETC interface\l'|5.6i.'\0\43 +.br +\h'|1.5i'4.4.4.1.\h'|2.2i'Calling sequence for onentry changed\l'|5.6i.'\0\43 +.br +\h'|1.5i'4.4.4.2.\h'|2.2i'New onerror and onexit procedures\l'|5.6i.'\0\43 +.br +\h'|1.5i'4.4.4.3.\h'|2.2i'New gqsort routine\l'|5.6i.'\0\43 +.br +\h'|0.9i'4.4.5.\h'|1.5i'FIO interface\l'|5.6i.'\0\44 +.br +\h'|1.5i'4.4.5.1.\h'|2.2i'Nonblocking terminal i/o\l'|5.6i.'\0\44 +.br +\h'|0.9i'4.4.6.\h'|1.5i'FMTIO interface\l'|5.6i.'\0\44 +.br +\h'|0.9i'4.4.7.\h'|1.5i'GTY interface\l'|5.6i.'\0\45 +.br +\h'|0.9i'4.4.8.\h'|1.5i'MTIO interface\l'|5.6i.'\0\45 +.br +\h'|1.5i'4.4.8.1.\h'|2.2i'MTIO applications programming interface\l'|5.6i.'\0\45 +.br +\h'|1.5i'4.4.8.2.\h'|2.2i'MTIO system procedures\l'|5.6i.'\0\46 +.br +\h'|1.5i'4.4.8.3.\h'|2.2i'Magtape driver procedures\l'|5.6i.'\0\46 +.br +\h'|0.9i'4.4.9.\h'|1.5i'MWCS interface\l'|5.6i.'\0\46 +.sp +5.\h'|0.4i'\fBGetting Copies of this Revisions Summary\fP\l'|5.6i.'\0\47 +.nr PN 0 +.bp + +.de XS +.DS +.ps -1 +.vs -1p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.de i0 \" usage: .i0 spacing +.fl \" Save the current +.nr xl \\n(nl \" line number and +.nr xp \\n% \" page number. +.KS +\\& \" Make space for the +.sp \\$2 \" plot, ejecting +\\& \" a new page if +.KE \" necessary. +.fl +.if \\n%>\\n(xp .nr xl 720 \" New page, 1" margin. +\\!! /irafsave save def \" "Encapsulate" the Post- +\\!! 0 72 \\n(xl 10 div sub translate \" Script plot, position +\\!! /erasepage {} def \" the plot on the page, +\\!! /initgraphics {} def \" disable irreversible +\\!! /showpage {} def \" PostScript operations. +.fl \" Cure a bug with ".sy". +.sy sed 's/^/!/' \\$1 \" Escape plot for devps. +\\!! irafsave restore \" Restore the P.S. context +.rr xl +.rr xp +.. + +.NH +Introduction +.PP +This document summarizes the changes made to IRAF in version 2.10. V2.10 +is a major release of IRAF, meaning that there were significant changes to +both the system and applications software, and the release will eventually +be made available on all supported platforms. +.PP +By IRAF version 2.10 we refer only to the core IRAF system and NOAO +packages. Numerous external or "layered" packages are also available for +IRAF, for example the NSO package (solar astronomy), the ICE package (data +acquisition), the STSDAS package from STScI (HST data reduction and +analysis), the TABLES package from STScI (tabular data), the XRAY package +from SAO (X-ray data analysis), and so on. These packages are layered upon +the IRAF core system, and once installed, are indistinguishable from the +rest of IRAF. Layered packages are developed and maintained separately +from the core IRAF release and follow independent release schedules, hence +we will not discuss them further here. Contact the IRAF project or any +of the outside groups supporting IRAF layered packages for additional +information on what is available. +.PP +This document is intended only as an overview of what is new in version 2.10 +IRAF. More detailed documentation will be found in the systems and +applications notes files (files \f(CWsysnotes.v210.Z\fR and +\f(CWpkgnotes.v210.Z\fR in the network archive), in the online help pages, +and in any reference papers or user's manuals distributed with the software. +The IRAF Newsletter is a good source of information for new IRAF software. +.PP +The reader is assumed to already be familiar with the basic concepts and +operation of the IRAF system. In particular, familiarity with V2.9 IRAF is +assumed. + +.NH +IRAF System Revisions +.NH 2 +Starting up V2.10 IRAF +.PP +Before attempting to start V2.10 IRAF each user should run the \fImkiraf\fR +command in their IRAF login directory. This will create a new \f(CWlogin.cl\fR +file and \f(CWuparm\fR (user parameter) directory. \fImkiraf\fR should be +allowed to delete any existing parameter files, as there have been many +changes to task parameter sets in the new version of IRAF. +.NH 3 +LOGIN.CL changes +.PP +The \f(CWlogin.cl\fR file is read by the CL during startup to perform some +runtime initialization and to customize IRAF for each user. A standard +\f(CWlogin.cl\fR file is created and initialized by the \fImkiraf\fR command +when the user's IRAF login directory is configured. For V2.10 IRAF the +\f(CWlogin.cl\fR file has undergone the following changes. +.RS +.IP \(bu +The IRAF version number is now checked automatically whenever you login, +and a warning message will be printed if your \f(CWlogin.cl\fR file is +out of date. If you see this message it means that important changes have +been made to the \f(CWlogin.cl\fR file and you need to rerun \fImkiraf\fR +to update this file. +.IP \(bu +Most of core IRAF system packages are now loaded automatically at login time +by the \f(CWlogin.cl\fR file. If you use a personal \f(CWloginuser.cl\fR +file and you previously loaded any core system packages in this file, you +should edit the file and remove those entries. +.IP \(bu +A "quiet" login option is now provided. If a file named \f(CW.hushiraf\fR +exists in the login directory when you start up the CL, printing of the +usual login messages will be disabled (the only output seen will be the "cl>" +prompt). +.IP \(bu +On UNIX/IRAF systems the login script now looks at the host system +environment variable \f(CWTERM\fR and checks for the common terminal types +"sun" and "xterm", configuring the IRAF \fIstty\fR accordingly if either +terminal type is seen (note that the default number of lines set for an +xterm terminal window may need to be modified). The logic used to do this +is not foolproof however, and is provided only as an example illustrating +how to make use of the host system terminal definitions. You may need to +customize this portion of the script, or override it in your +\f(CWloginuser.cl\fR file. +.IP \(bu +The CL hidden parameter \f(CWshowtype\fR is now set to "yes" by default. +This will cause a character to be printed after the name of each package or +named pset in CL package menus to allow these objects to be easily +distinguished from ordinary tasks. Packages are marked with a trailing +period (".") and psets with an ampersand ("@"). This feature can be +disabled with a "showtype=no" statement. +.IP \(bu +The V2.10 login script contains a call to a new internal (non-user) IRAF +task \fImtclean\fR. Be sure to leave this alone, it is required for the +correct operation of the new magtape i/o system. +.RE +.LP +The USER package defined in the template \f(CWlogin.cl\fR has been +extensively revised, adding many new tasks. These are mainly used to +make common UNIX commands available from within the IRAF environment. +Type "?user" in the CL to see what is available, e.g.: +.XS +cl> ?user + adb cp fc lpq mv rlogin spell top + bc csh find ls nbugs rsh sps touch + buglog date finger mail nm rtar strings vi + cal df ftp make od ruptime su w + cat diff generic man ps rusers sync wc + cls du grep mkpkg pwd rwho telnet wtar + comm emacs less mon rcp sh tip xc +.XE +.LP +Note that since the USER package is defined in the user's login file it is +easily customized to add new tasks. Refer to the existing package for +examples illustrating how to do this. +.RE +.NH 3 +Compatibility Issues +.PP +Version 2.10 IRAF requires the new \f(CWlogin.cl\fR file; if the CL does not +start up correctly, it may be because the user has not done a \fImkiraf\fR, +or because they have some construct in their \f(CWloginuser.cl\fR file which +is incompatible with V2.10 IRAF. The V2.10 login file is usable with V2.9 +IRAF, however this is not recommended. +.PP +There have been many task \fBparameter changes\fR between V2.9 and V2.10. +If "parameter not found" messages are seen, most likely the user has an old +\f(CWuparm\fR directory, or has been switching back and forth between IRAF +versions. An \fIunlearn\fR or \fImkiraf\fR should fix the problem. +.PP +The V2.10 IRAF \fBnetworking system\fR is not fully compatible with earlier +versions of IRAF. This can cause problems when, e.g., a newly installed +V2.10 system is used to communicate with an older version of IRAF on another +system. The best solution is to update to V2.10 on all systems, but if this +is not convenient it is possible to configure the networking system to avoid +the problems. See the discussion of the new networking system given below. +.PP +Accessing a \fBremote magtape device\fR via IRAF networking will not work +between V2.10 and older versions of IRAF (the remote procedure calls have +changed). To remotely access magtape devices you will need to install V2.10 +IRAF on both the client and server nodes. +.PP +In most respects installing V2.10 IRAF will be very similar to installing +earlier versions of IRAF. The main difference is the \fBtapecap file\fR +required to use the new magtape system. The old \f(CWdev$devices\fR file +is no longer used. See the discussion of the new magtape system given below +for more details. +.PP +Due to name changes in certain low level system routines (made to avoid name +clashes when linking with host level libraries) the V2.10 libraries are +incompatible with older versions of IRAF. Any IRAF programs or external +packages \fBrelinked\fR under V2.10 will have to be fully recompiled or the +linker will complain about unresolved externals. Note that so long as the +old program is not relinked there should be no problem, even if the program +uses the IRAF shared image, since the V2.9 shared image is included in V2.10 +(this applies to Sun/IRAF systems only). +.PP +Starting with V2.10, many IRAF applications now fully support generalized +\fBworld coordinates\fR (WCS). While in principle this should not pose any +compatibility problems, the image headers do contain more information in +V2.10 than previously, and there can be problems if, for example, an input +image contains an illegal WCS. Previous versions of IRAF would ignore this +but in V2.10 such an image could result in an error or warning message. +If WCS related problems are encountered it is probably best to contact the +IRAF group for help. + +.NH 2 +CL Enhancements +.NH 3 +Formatted scans and prints, scan from a pipe +.PP +New in the V2.10 CL (command language) are formatted scan and print routines, +and the ability to scan from a pipe or other form of redirected input. These +new facilities will prove most useful in CL scripts. +.PP +The old unformatted scan and print routines are the following. These are +still available and are the simplest routines to use where they are adequate. +.XS + scan (arglist) # scan standard input + fscan (list, arglist) # scan a list + print (expr, exprlist) # print to standard output +fprint (param, exprlist) # print to a string buffer +.XE +.LP +For example, +.XS +list = "\fIfilename\fP" +while (fscan (list, x, y) != EOF) + print ("x=", x, "y=", y) +.XE +.LP +In the above, \fIarglist\fR is a comma delimited list of output arguments +(parameter or parameter field names) and \fIexprlist\fR is a comma delimited +list of expressions to be printed. \fIlist\fR is the name of a +list-structured parameter to be scanned, and \fIparam\fR is the name of a +parameter, the value field of which is to receive the output string. The +unformatted scan routines will automatically convert output data values to +match the types of the output arguments. +.PP +The new formatted routines are as follows. These take an extra +\fIformat\fR argument which tells how to parse the input string in the case +of the \fIscanf\fR routines, or how to format the output in the case of the +\fIprintf\fR routines. +.XS + scanf (format, arglist) # formatted scan from stdin +fscanf (list, format, arglist) # formatted scan from a list +printf (format, exprlist) # formatted print to standard output +.XE +.PP +Currently there is no \fIfprintf\fR routine. For the \fIprintf\fR routine +the \fIformat\fR argument is similar to that for the SPP/VOS \fIprintf\fR +(which is similar to the C \fIprintf\fR). The \fIformat\fR argument for the +\fIscanf\fR routines is the same as the VOS LIBC \fIscanf\fR, which is +patterned after the C \fIscanf\fR (in fact the UNIX manual page for +\fIscanf\fR can be used as a guide to the CL \fIscanf\fR with only minor +deviations). +.LP +The following examples illustrate the new routines. +.XS +cl> printf ("%d foo %7.3f\\\\n", 5, 12.123) | scanf ("%d foo %g", i, x) +cl> printf ("new values are i=%d, x=%g\\\\n", i, x) +new values are i=5, x=12.123 +.XE +or, +.XS +while (fscanf (list, " %*d size=%d name=%s", i, s1) != EOF) + printf ("size=%05o, name=`%s'\\\\n", i, s1) +.XE +.LP +Note in the first example the use of \fIscanf\fR to scan from a pipe. There +are actually two different versions of \fIscan\fR and \fIscanf\fR in V2.10 +IRAF, an intrinsic function version and a procedure version. When called as +an intrinsic function, a \fIscan\fR routine returns as its function value +the number of operands successfully scanned, or EOF. When called as a +procedure, the function value of a \fIscan\fR routine is discarded. +.PP +Here is another example illustrating scan from a pipe, in this case using +an unformatted scan since the \fIhselect\fR output is in a simple tabular +format (\fIhselect\fR prints selected fields of the image header). +.XS +cl> hselect dev$pix naxis,naxis1,naxis2 yes | scan (i, j, k) +cl> printf ("naxis=%d, axlen=[%d,%d]\\\\n", i, j, k) +naxis=2, axlen=[512,512] +.XE +.LP +When using the formatted scan routines, care must be taken to ensure that +the data types implied by the \fIformat\fR argument match the actual data +types of the output parameters. The \fIscanf\fR routines are implemented +using an internal call to the C (LIBC) \fIscanf\fR, with the output +parameter value fields referenced directly via a pointer. If the data type +is incorrect the output value may be meaningless. +.NH 3 +Unlearning package parameters +.PP +The \fIunlearn\fR task now works for package parameters as well as task +parameters. In a command such as "unlearn pkgname" the package parameters +for the named package will be unlearned, as well as the parameters for +all the tasks in the package. This works whether or not the package is +loaded. +.NH 3 +Loading packages at login time +.PP +A bug has been fixed which affected packages with package parameters loaded +at login time. It is now permissible to load any package at login time +regardless of whether it has package parameters (V2.9 users will recognize +this bug as one which prevented loading CCDRED in the login script). +.NH 3 +Environment variables +.PP +The environment variables \f(CWimtype\fP, \f(CWcmbuflen\fP, +and \f(CWmin_lenuserarea\fP are now defined at login time. Previously, +explicit values for these variables were not defined, and the system +would use the builtin internal defaults. Explicit definitions were +added so that the user can query the current value, e.g. +.XS +cl> show cmbuflen +128000 +.XE +A \fIshow\fR or \fIset\fR with no arguments will print the full environment +list. New values for these and other common environment variables may be +set in the user \f(CWlogin.cl\fP file. + +.NH 2 +System Management Related Changes +.NH 3 +Install script +.PP +The UNIX/IRAF install script underwent minor changes to make it more +robust. Problems are still possible if the IRAF root pathname is set to +different values in the various system dependent files modified by the +script. The system as shipped from NOAO has the same initial root pathname +set in all such files, but problems can occur if the files are manually +edited during or after installation. To avoid problems always use the +install script to make system changes such as installing at a different root +directory. +.NH 3 +Caching of termcap entries +.PP +User caching of termcap or graphcap entries with the old \f(CWmkttydata\fR +task is no longer recommended. The most common entries (e.g. sun, xterm, +vt100) are already cached. Modern workstations are so fast that there is no +longer much point in caching termcap entries; it is sufficient to merely +place local additions near the top of the file. Most programs that +repeatedly access the terminal cache the entries internally during +execution. Custom caching of termcap or graphcap device entries requires +that the system be relinked, and the risk inherent in relinking the system +(hence giving up the prebuilt, pretested binaries) is not worth the small +performance gain achieved. +.NH 3 +Sorting of UNIX directories +.PP +The UNIX-based versions of IRAF now sort UNIX directories whenever a +directory is accessed to expand a file or image template. This will fix the +problem sometimes seen in earlier versions of IRAF, in which an image +template could appear to be expanded in a seemingly random fashion. +.NH 3 +UMASK support +.PP +The UNIX-based versions of IRAF now support the host level \fIumask\fR file +creation mask correctly. If files or directories created by V2.10 IRAF do +not have the desired permissions, it is because you do not have umask set +correctly at the UNIX level (most people set umask to 022). + +.NH 2 +Networking Enhancements +.NH 3 +New networking driver +.PP +The UNIX/IRAF networking driver has been completely rewritten for version +2.10 IRAF, with the goals of eliminating redundant password prompts, +improving efficiency, and enhancing system security. For the most part the +changes will be transparent to the user. Once the IRAF system manager has +configured the \f(CWdev$hosts\fR file for the local site the networking +system should function automatically; in the default configuration a password +prompt should be seen only when connecting to a server for which \fIrhosts\fR +("trusted" hosts) permission is not granted. +.PP +The following information is provided mainly for IRAF system managers. +In normal use the user does not need to understand how the networking +system functions. +.NH 4 +How it works +.PP +The IRAF networking system is an RPC (remote procedure call) mechanism for +the IRAF kernel; all kernel procedures may execute either locally or +remotely, and the client and server nodes do not even need to run the same +operating system. IRAF applications may be distributed, and may access +resources which reside anywhere on the network. IRAF networking is layered +upon standard low level networking protocols such as TCP/IP and DECNET. +.PP +The IRAF networking system defines one or more \fIconnection protocols\fR +which are used by a client to connect to the IRAF kernel server on a remote +machine. The old networking driver supported only one connection protocol, +the \fIrexec\fR protocol, which requires a login name and password. The new +driver adds support for an \fIrsh\fR based protocol. This is the default +connection protocol for V2.10 IRAF; automatic fallback to the rexec protocol +is provided in the event that the rsh connect fails. The rsh connection +protocol bootstraps off the suid-root \fIrsh\fR command found in most BSD +derived UNIX systems (most System V systems provide the equivalent command +\fIremsh\fR). +.PP +The connection protocol is used to start the \fIin.irafksd\fR IRAF +networking daemon on the remote server node. This daemon executes with the +same uid and permissions as the account which initiated the connection, and +there is one such daemon per user per server node. Once the daemon has been +started via the rsh or rexec connection protocol, new client connections are +made very quickly, by merely forking the daemon to create the IRAF kernel +server process, and setting up a direct socket connection between the IRAF +client process and the server. The daemon process runs indefinitely, +shutting down if idle for longer than a certain interval (the current +default is one hour). When connecting to the daemon a client must supply an +authentication key to gain access to the daemon. If authentication fails +the daemon shuts down and it is necessary to reestablish the connection. +.NH 4 +The .irafhosts file +.PP +The new networking driver retains the old \fIirafhosts\fR file, used to +store information telling how to connect to various IRAF hosts (the +irafhosts file is the file \f(CW.irafhosts\fR in the user's login +directory). The networking system will automatically create this file for +the user if the file is not found; if an old-style file is found, it will be +edited by the system to make it compatible with the new networking system. +While it is no longer necessary for the irafhosts file to contain password +information to avoid password prompts, the file is used to store the user +authentication key, hence the file should be read protected. The networking +system will automatically read protect the file if it is not already +protected. +.PP +To avoid authentication failures when clients on different nodes attempt to +connect to the same server, the same authentication code should be used on +all server nodes. Unfortunately there is no way that the networking system +can do this automatically (without going to some much more complicated +authentication scheme, such as a key server), so users who make heavy use of +the networking system should install a copy of their irafhosts file +in their login directory on all server nodes. If this is not done the +networking system will still work, but will be less efficient than it could +be, when simultaneously accessing the same server from IRAF sessions running +on multiple client nodes. +.PP +The truly paranoid may not be happy with even the unique user +authentication code used in the current networking system. If this is the +case the \fIport\fR parameter (see below) may be set to zero to force rsh to +be used for every connection (in effect the in.irafksd daemon has to be +restarted for every connection). This imposes an overhead of as much as +several seconds on every server connect. Alternatively, \f(CWKSAUTH\fR can +be defined in the user environment at login time, setting the value string +to some random integer value selected at login time. If defined in the user +environment, \f(CWKSAUTH\fR will override the value of \fIauth\fR given in +the irafhosts file. This approach would at least allow efficient connects +for a single login process tree. +.PP +The irafhosts file consists of two sections. The first section +defines several networking parameters: \f(CWport\fP, \f(CWauth\fP, +\f(CWhiport\fP, and \f(CWtimeout\fP. The second section is a list of +server nodes, with login and password information describing how to connect +to each node. +.XS +port = default +auth = 1234567890 +hiport = default +timeout = default + +ursa : ? +* : +.XE +.LP +The example above illustrates a typical irafhosts file. Typically a unique +authentication code is allocated automatically by the system when the file +is first created, and the other parameters retain their default values as +shown (i.e., the string "default"). In the example the host list consists +of an entry for the node "ursa", and an entry for everything else. The +format of a host entry is "\fIhost-name : login-name password\fP". If +\fIlogin-name\fR is the reserved string "" the user name on the client +node is used for login authentication on the remote node. Setting the +password to "" as well causes the rsh connect protocol to be used; +anything else causes the rexec protocol to be used. If the rexec protocol +is used the password field may be set to the actual password or to the +string "?", in which case the system will prompt for the password whenever a +connection attempt is made. The "*" entry should always be the last entry +in the list, since it matches all nodes. The default host list contains +only the "*" entry. +.PP +Additional information on the irafhosts file is provided in the +comments in the file \f(CWdev$irafhosts\fR, and in the system notes file. +.NH 4 +Compatibility +.PP +By default the new networking system will try to use the rsh protocol to +connect to the server node. If the server is running an older version of +IRAF the connection attempt will hang and eventually time out. If this +occurs the networking system will fall back on the rexec protocol and issue +a password prompt, but by then the user will probably have interrupted the +connect. The best way to avoid this problem is to update the server node +to V2.10, but if this is not possible, an explicit entry for the node can +be made in the irafhosts file, setting the password field so that +the rexec protocol will be used. +.PP +An older, e.g. V2.9 client connecting to a V2.10 server should not be a +problem. In this case the V2.10 server will see an attempt to connect with +the rexec protocol, which should be processed as in the past. +.PP +Aside from the problem of making a connection the pre-V2.10 and V2.10 +networking systems are compatible, \fIexcept\fR for the magtape i/o calls. +Since the magtape driver calling sequences were changed in V2.10, remote +magtape access between V2.10 and older systems is not supported. +.NH 3 +The hosts file +.PP +The file \f(CWdev$hosts\fR is used to interface new host machines to the +IRAF networking system. This file defines, for each host, the primary +host name, any aliases, and the command to be executed remotely to start +up the IRAF kernel server on a remote node. +.PP +The format and role of the hosts file is unchanged in V2.10. Two changes +were made which affect the use of this file. +.RS +.IP \(bu +A user can now have a private copy of the hosts file. To enable this feature, +the variable \f(CWirafhnt\fR (IRAF host name table) should be defined in +the user's IRAF or host level environment, with the string value giving the +file pathname of the user's private host name table file. +.IP \(bu +The maximum number of entries in the host name table has been increased from +64 to 128. In the current implementation these entries are statically +buffered, so it is necessary to keep the maximum number of entries to a +reasonable value. +.RE +.LP +The hosts file must be configured to enable IRAF networking. IRAF networking +is disabled if there is no entry for the local host in this file. The +\fInetstatus\fR command may be used to examine the state of the host name +table after it has been loaded by the networking system. +.PP +There is another file \f(CWdev$uhosts\fR which often confuses people. This +file is not used by UNIX/IRAF and can be ignored; it is there for VMS/IRAF +and other IRAF implementations which do not provide the equivalent of the +UNIX system routine \fIgethostbyname\fR. On host machines which implement +name server facilities IRAF will use the name server, allowing any machine +on the internet to be accessed via IRAF networking, so long as there is an +entry in the system wide or user IRAF hosts file. + +.NH 2 +Magtape System Enhancements +.PP +The magtape subsystem underwent a major revision in V2.10. The VOS level +MTIO interface was extensively revised, and the host-level IRAF magtape +driver ZFIOMT is completely new. A new device configuration facility +called \fItapecap\fR was introduced. Together with the new "programmable" +magtape driver, this makes it possible to interface almost any removable +media mass storage device to the magtape subsystem. The DATAIO +applications, in particular the FITS programs, underwent minor, but +important revisions. +.PP +A full specification of the new magtape subsystem, particularly the tapecap +facility, is beyond the scope of this document. Our intention here is +merely to introduce the new facilities. A reference paper is planned, time +permitting, which will fully document the new magtape system and tapecap. +.NH 3 +Basic usage +.PP +In most respects basic usage of the magtape system is unchanged from +previous releases. Many new capabilities have been added, but these are +upwards compatible with earlier releases. +.NH 4 +Logical device names +.PP +Magtape devices are still referred to in IRAF applications much as they +have been in the past. Whether or not the logical device names are the +same before and after the V2.10 upgrade depends upon how the IRAF system +manager configures the tapecap file. The new magtape system is much more +flexible than previously regarding device names, but to avoid user confusion +it is recommended that the old names be supported as aliases regardless of +whatever the full device name may be. +.LP +As in earlier versions of IRAF, a simple magtape reference might be +.XS +cl> mtexamine mta +.XE +where "mta" is the device name. To examine only file 3 on the tape one +might enter +.XS +cl> mtex mta[3] +.XE +If the device is on the remote node "ursa" the command would be +.XS +cl> mtex ursa!mta[3] +.XE +If the device is a 9 track tape supporting multiple densities we might +specify the density explicitly, e.g. +.XS +cl> mtex mta1600[3] +.XE +Device names can be more complex. For example, +.XS +cl> mtex mtwd +.XE +might refer to a WangDAT drive, and +.XS +cl> mtex mtwdc +.XE +to the same drive, but with data compression enabled. +.PP +Devices can have multiple names, possibly with slightly different behavior +or characteristics. Device names such as "mta" are usually only host +specific aliases for the lower level, host independent device names. +The names "mta" and "mtb" might be aliases for the actual device +names "mthp0" and "mtxt1". This can be useful in networked systems +where IRAF and the tapecap file reside on a server node, but the user +is running IRAF on their workstation with a local tape drive attached. +In this case there may be no entry for the local drive in the installed +tapecap file, but the user can still access the local drive using the lower +level, host independent device entry (it is also possible to have a +private tapecap file as we shall see later). +.PP +To see what logical devices are known to the magtape system you can +enter the following command (the task \fIgdevices\fR was intended for +graphics devices but can be pressed into service to list a tapecap +file as well). Just because a device is listed does not mean that the +physical device actually exists on a particular host system. +.XS +cl> gdev devices='^mt' graphcap=dev$tapecap +.XE +In IRAF V2.10 it is possible to include tapecap parameters in the device +specification to do clever things, as in the following example. +.XS +cl> mtex "mta[:so=lepus:se:nb]" +.XE +This is discussed further below in the section describing the tapecap +facility. +.NH 4 +Device allocation +.PP +Device allocation operates much the same in V2.10 as in earlier versions +of IRAF. The main change is that it is no longer necessary to allocate a +device in order to be able to access it. It is strongly recommended however +that you always allocate a device before accessing it in IRAF. If the +device is not allocated anyone can access the drive, e.g., changing the +tape position, and this can cause data to be lost or improperly read back. +The only reason to access the drive without allocating it is if there is +some problem with device allocation on your system. +.LP +A device is allocated with the \fIallocate\fR command, e.g. +.XS +cl> alloc mta +.XE +A device is deallocated with \fIdeallocate\fR. If the tape has already +been unmounted use the \fIrewind=no\fR option to avoid accessing the drive. +By default the tape will be rewound when it is deallocated. Deallocating +and reallocating a drive initializes the magtape system, i.e., all cached +knowledge of the status of the drive is discarded. +.NH 4 +Device status +.PP +The device status can be examined at any time that the magtape device is +idle (not being actively accessed by an IRAF task) using the \fIdevstatus\fR +task. +.XS +cl> devs mtc +# Magtape unit mtc status Thu 12:54:02 04-Jun-92 user v14 +file = 4 +record = 1 +nfiles = 0 +tapeused = 405 +pflags = 0 +.XE +.LP +Of particular interest are the \fItapeused\fR and \fInfiles\fR fields. +\fInfiles\fR refers to the total number of files on the tape (if a file is +appended to the tape it will be file \fInfiles\fR+1). If \fInfiles\fR +is given as zero that means that the magtape system does not yet know how +many files are on the tape (it has not seen the end of tape). +.PP +\fItapeused\fR reports the amount of tape used in units of kilobytes. This +is intended to refer to the amount of tape used up to and including the end +of tape (EOT). However, the magtape system only knows about data that it +has seen, i.e. physically read or written, so whether or not \fItapeused\fR +is accurate depends upon how you have accessed the tape. +.PP +For example, if you started out with a fresh tape and appended a number of +files the number should be accurate. If you just completed a full scan of +the tape with \fImtexamine\fR the number should be accurate, since all the +data was read. If you just put on a new tape and did a scan of the FITS +headers with "rfits make-", the number may or may not be accurate, depending +upon the device and how file skipping forward was done. In most cases only +the header area of each file will have been read and \fItapeused\fR will not +reflect the full contents of the tape. If however, "rfits make-" is done +immediately after writing to a new tape, the number will be accurate, since +all the data was written before the tape was rescanned to print the FITS +headers. +.PP +Be advised that by default an explicit \fIrewind\fR will clear the \fInfiles\fR +and \fItapeused\fR fields, since by default \fIrewind\fR initializes the +magtape system. See the discussion of \fIrewind\fR below. +.PP +In summary \fItapeused\fR can be useful for monitoring how much space is +left on a tape, but you have to know what you are doing. When writing to a +new tape the number will be accurate so long as you avoid doing an explicit +\fIrewind\fR. A simple procedure which will always work when mounting a +non-empty tape and appending files to it, is to do an \fImtexamine\fR of the +tape and then append the new files. This can be time consuming for large +tapes but does provide a safe and device-independent method for getting the +maximum amount of data on a tape. +.NH 4 +File positioning +.PP +File positioning when accessing magtape files in IRAF is straightforward in +the sense that you can simply specify the file number to read an existing +file, or "append" (as in wfits new-) to append a file to an existing tape. +Most tasks accept range lists to access existing files, e.g. +.XS +cl> mtexamine mta file="3,5,9-11" +.XE +It is even possible to position a tape to a specific record within a file. +Opening a tape with file zero (as in "mta[0]") disables file positioning, +allowing the tape to be positioned with host level utilities to workaround +media problems. +.PP +There can be problems with this simple scheme however, with modern tape +devices such as DAT and Exabyte which have capacities in the gigabyte +range and which may be used to store thousands of files. It is beyond the +scope of a revisions summary to go into this in detail here, but a simple +example will help illustrate the problem. +.PP +Assume we have a tape mounted on device "mtwd" containing 900 files. We +want to append image "pix" as a FITS file. The obvious thing to do is enter +the following command. +.XS +cl> wfits pix mtwd new- +.XE +This will certainly work. The only problem is that if the tape is freshly +mounted the magtape system will not know how many files there are on the +tape, and it will have to skip forward one file at a time to count the files +and determine where EOT is. In the worst case of a tape containing several +thousand files this could literally take hours. +.PP +If we know apriori the number of files on the tape, e.g., 900 in our example, +the following command would be much faster (something like 10-40 seconds on +most DAT drives, assuming a decent host level driver). +.XS +cl> wfits pix mtwd[901] +.XE +Of course, if there were actually 930 files on the tape, the last 30 files +would be overwritten. +.PP +There is a useful trick which works in some cases if we don't care exactly +how many files are on the tape (whether this works depends upon the specific +device and the host driver). Assume that we know there are several hundred +files on the tape, but less than 1000. We enter the following command to +append a file to the tape. +.XS +cl> wfits pix mtwd[1000] +.XE +If this works, after the operation the magtape system will think there are +1000 files on the tape. A subsequent "wfits new-" would be very fast +regardless of the tape position, since so long as the magtape system knows +where the end of tape is relative to the current position, it can get there +very fast. +.PP +If the trick doesn't work for your particular device or driver you will +probably get a positioning error when attempting to position to a +nonexistent file beyond the EOT. +.PP +More automated techniques for rapid positioning with very high capacity +tapes are still a matter for study. One promising technique would be to +formalize the above approach by supporting EOT-relative positioning. A tape +catalog based approach is also possible. The best approach may simply be to +not write so many small files on large tapes, by grouping images or other +data system files into a single large tape file (as with UNIX \fItar\fR). +None of these approaches are implemented in V2.10. +.NH 4 +Rewind +.PP +In IRAF a magtape device is rewound with the \fIrewind\fR command, as in the +following example. +.XS +cl> rewind mta +.XE +By default this will not only rewind the tape but also initialize the +magtape system, in the sense that all cached information regarding the named +device is erased (e.g., \fInfiles\fR and \fItapeused\fR in the cached device +status). This is necessary when changing tapes without deallocating the +drive; always do an explicit rewind (or deallocate) of the device before +removing a tape or mounting a new one. Having \fIrewind\fR initialize +things is also useful if error recovery should fail following an interrupt +or program abort. +.PP +In some cases it may be useful to be able to do a rewind without erasing the +cached device status. This is done by specifying the \fIinit-\fR option on +the command line. +.NH 3 +New magtape driver +.PP +The IRAF magtape driver is new for V2.10. The chief feature of the new +driver is that it is programmable, via the tapecap device entry, making it +possible to interface new devices or host drivers without having to make +any binary code changes to IRAF. All one has to do is add a device entry +in the tapecap file. +.NH 4 +Software structure +.PP +The IRAF magtape system has enough layers that it may be confusing exactly +what the magtape driver is and what role it plays. A brief review of the +software structure may help clarify things. +.PP +Starting at the top we have applications, such as the DATAIO and MTLOCAL +tasks, which can access magtape files. These use the IRAF/VOS interfaces +FIO (file i/o) and MTIO (magtape i/o) to do i/o to tape devices. For the +most part i/o is done with FIO and is device independent, but a call to the +magtape system is required to open a magtape device. The tapecap file is +read by the GTY interface, which is called by MTIO. MTIO passes the tapecap +device entry as a string to ZFIOMT, the IRAF magtape device driver, when a +tape file is opened. All magtape positioning and i/o is done by ZFIOMT +driver under the control of the MTIO interface. Device allocation is done +prior to accessing the device by the CL and is handled by the allocation +routines in the ETC interface, with kernel support (this is largely +independent of the magtape system). +.PP +All of the code listed above is part of the portable IRAF system (i.e., is +OS independent and shared by all host versions of IRAF) until we get to the +ZFIOMT driver. This is in the IRAF kernel and is host system dependent. At +present the only version of ZFIOMT is the UNIX version; other versions, +e.g., for VMS will follow as IRAF is updated to V2.10 on these systems. The +UNIX version of ZFIOMT uses only generic UNIX ioctls and should compile on +most UNIX systems without change. All of the system and device dependence +has been concentrated in the tapecap file. The ioctls used to communicate +with a UNIX tape device are fairly standard, but the semantics are often +poorly defined and are certainly not standardized. +.PP +Beneath the IRAF driver are the host level magtape device drivers. A given +host system may have more than one of these, typically one for each class of +magtape device. Some systems, notably Sun with their ST (SCSI tape) driver, +try to control more than one type of device with a single host driver. The +host driver may come with the OS or may be supplied by a third party vendor. +.PP +Beneath the host driver is the actual tape device. Often these days this is +a SCSI tape device such as a DAT or Exabyte. These devices are intelligent +peripherals; control of the physical tape hardware resides in the tape +unit. There is a small computer in each tape drive which communicates with +the host computer via the SCSI interface, passing commands and data back and +forth. The drive will buffer 256K to 512K of data passed in bursts over the +SCSI bus, and then copied to or from the physical media at a much slower +rate. These drives emulate variable size records by blocking and deblocking +within the drive unit, and writing fixed size blocks to the media. Features +such as error correction and data compression are also handled within the +drive. +.PP +Although we usually speak of tape devices, the "magtape" device does not +have to be a tape device at all. The IRAF magtape system can also make use +of, e.g., a floppy disk, or anything that looks like a raw disk partition. +The problem with the latter devices is that they usually don't support +files and file positioning, hence can only be used to store one "file". +.NH 4 +Driver features +.PP +A detailed description of the magtape driver is beyond the scope of this +document. Briefly, the driver supports two main classes of devices, variable +record size devices and fixed block devices. All file positioning is handled +by the driver, and while the driver has the device open it is responsible for +keeping track of the device position (the saved device position is passed +in at open time and saved by the high level code at close time). A couple of +dozen tapecap parameters are defined which describe the characteristics of +each device, such as whether it supports variable records, the maximum record +size, whether it can backspace, and so on. A socket or file based status +logging feature is provided which allows detailed monitoring of the tape +status during execution (see below). +.PP +In the simplest case the new magtape system, coupled with the UNIX version +of the magtape driver, will emulate simple UNIX commands such as \fItar\fR +and \fImt\fR insofar as the requests made to the host system and magtape +device are concerned. That is, if one writes a series of files the only +system requests made for each file will be open, write, and close. When +reading a series of files in sequence the only requests made will be open, +read, and close. Providing no file positioning is attempted it is possible +to get by with no file positioning requests other than rewind. The driver +provides extensive facilities for file positioning, using tapecap parameters +to work around any shortcomings of the host system or device, but in case +of trouble it is possible to operate with only open, close, read, and write +requests, which should work for any device (unless it is truly broken). +.NH 3 +Tapecap +.PP +The tapecap file, or magtape device capabilities file, defines the magtape +devices known to the system and how to access these devices. While large +portions of this file depend only upon the host operating system and device +type and hence are fairly site independent, it will typically be necessary +to customize the tapecap file to configure the IRAF magtape system for a +site. In normal use the tapecap file is invisible to the user, but users +with special problems may wish to learn more about tapecap to gain more +control over the behavior of the magtape system. +.NH 4 +Using tapecap +.PP +The standard tapecap file is the file \f(CWdev$tapecap\fR. A system +environment variable \f(CWtapecap\fR is defined which by default points to +this file. +.PP +Users can customize or manipulate tapecap entries in either of two ways. +The user can have their own private copy of the tapecap file (much as is +currently done with the termcap and graphcap files), by resetting the +value of the \f(CWtapecap\fR environment variable to point to their local +copy of the file. For example, +.XS +cl> reset tapecap = home$tapecap +.XE +This may be necessary to customize a device entry, or add support for a +local device not supported by the system wide tapecap file. +.PP +It is also possible to modify a tapecap device entry "on the fly", by +overriding the values of specific tapecap parameters on the command line +when the device is accessed. For example, +.XS +cl> mtex "mta[:so=/dev/tty]" +.XE +would override the default value of the tapecap parameter "so" for device +mta (in this case enabling status output logging and directing this output +to the user terminal). +.PP +Specifying tapecap parameters on the command line is useful for +experimentation but rapidly becomes tiresome if many commands are entered. +In this case it becomes simpler to redefine \f(CWtapecap\fR to include +the desired tapecap parameter overrides. +.XS +cl> reset tapecap = ":so=/dev/tty" +.XE +As we see, the \f(CWtapecap\fR environment variable can be used to either +specify the tapecap file name, or globally override specific tapecap +parameters (all device entries are affected). The full form of the value +string for \f(CWtapecap\fR is +.XS +cl> reset tapecap = \fR[\fP\fItapecap-file\fP\fR] [\fP`:' \fIcapabilities-list\fP\fR]\fP +.XE +Any number of colon-delimited tapecap capabilities or parameters may be +given. +.PP +It is beyond the scope of this document to detail all the tapecap parameters +here. A reference paper for the magtape system is planned. For the +present, there is a summary of the tapecap parameters in the ZFIOMT driver +source file, \f(CWos$zfiomt.c\fR. For examples of actual usage refer to the +tapecap file in the distributed system. +.NH 4 +Configuring tapecap +.PP +The tapecap file uses the standard "termcap" file format, originally developed +for BSD UNIX and adopted long ago for IRAF. Any UNIX system will probably +have a manual page defining the termcap file format, if not this can be +obtained from the IRAF group. +.PP +The distributed tapecap file is divided into three sections: the host machine +specific device aliases (names like "mta" etc.), the site logical devices, +and the generic device entries. To customize the tapecap file for a site +you modify the first and second sections. To configure the tapecap file for +a particular host machine you uncomment the entries for that host in the +first section of the file. Sites which don't have a large network of hosts +may prefer to combine the first two sections to simplify things. Site +specific changes should never be made to the bottom, or generic, part of +the tapecap file, as you will want to update this portion of the file when +new versions of IRAF are released. +.PP +Don't be intimidated by the apparent complexity of some of the tapecap device +entries. In most cases the generic device entry will already exist for the +device you need to interface, and all you need to do is add a site entry +which references the generic entry. In some cases the generic entry itself +may be sufficient (for example, in the distributed SunOS version of tapecap, +logical device "mtxb0" would provide access to Exabyte unit 0 interfaced +with the Sun ST driver, "mtxb1" would be the same but unit 1, "mthp0" the +HP 9 track tape on unit 0, and so on). +.PP +For example to interface Exabyte unit 2, using the Sun ST driver, as local +device "mta", the following entry would suffice. +.XS +mta| :tc=mtst2-exb: +.XE +If the generic device entry provided doesn't quite work and minor +modifications are needed, these should be made to the \fIlocal\fR entry and +not the standard generic entry. This is easily done with termcap parameter +redefinitions. For example, in SunOS 4.1.2 (but not earlier versions of +SunOS) there is a bug in the Sun ST driver which necessitates rewinding the +tape after a tape scan is made to position to EOT (!). The capabilities +":se:nb" can be added to the tapecap entry for the device to workaround this +bug, as in the following example. +.XS +mta| :se:nb:tc=mtst2-exb: +.XE +The parameters mean that the device spaces past EOT in a read (se) and +cannot backspace (nb). Neither of these things is actually true, but the +effect is that the tape is rewound and spaced forward to get back to the +desired file, working around the host level driver bug. Access will be +less efficient than it should be, but the interface will work properly and +the user does not have to be concerned with the problem. +.PP +As a final example, suppose we need to write a new tapecap entry from +scratch because there is no generic entry for the device in the distributed +tapecap file. To simplify things we assume that no special tapecap +parameters are needed, i.e., that the standard UNIX defaults builtin to +the driver will work for the device. We are upgrading from an old version +of IRAF so we already have an old \f(CWdev$devices\fR file to work with. +For the purposes of our example we use an old HP 88780 1/2 tape drive entry, +but pretend that the device is something which is not already supported. +.LP +The old devices file entry was as follows. +.XS +mta nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 +mta.6250 nrst20 nrst4 nrst12 nrst28 rst4 rst12 rst20 rst28 +.XE +The minimal tapecap entry required to duplicate this is the following. +.XS +mta|mta6250|HP 88780 1/2 inch tape drive:\\\\ + :al=nrst4 nrst12 nrst20 nrst28 rst4 rst12 rst20 rst28:\\\\ + :dv=nrst20:lk=st4:tc=9tk-6250: +.XE +Here, the "al" parameter lists the device files to be allocated, the "dv" +parameter is the device file to be used for i/o at the desired density +(6250bpi in this case), and "lk" is the root file name to be used for the +".lok", or device status file. The "tc=" picks up the standard parameters +for a 9 track 1/2 inch tape drive operating at 6250 bpi. Two device +aliases are defined, "mta" and "mta6250". +.NH 4 +Supported devices +.PP +The IRAF magtape system itself should support almost any magtape device if +properly configured. What devices are actually supported at a site depends +upon the tapecap file, and in particular upon the host system (different +host systems have different tapecap files). +.TS +center; +ci ci +l l. +Device Driver + +QIC-11 cartridge tape Sun st +QIC-24 cartridge tape Sun st +QIC-150 cartridge tape Sun st +Pertec compatible 1/2 inch drives Xylogics +HP 88780 1/2 inch drive Sun st +WangDAT 1300, 2000 ApUNIX +HP DAT ApUNIX +Exabyte 8200, 8500 ApUNIX, Sun st, Ciprico +DC2000 cartridge tape A/UX tc +FDHD floppy disk A/UX fd +.TE +.PP +As an example, the tapecap file distributed in the V2.10.0 release of Sun/IRAF +supported the devices listed in the table above. New devices are constantly +being added. As V2.10 IRAF propagates to the various platforms on which IRAF +is supported, similar tapecap files will be configured for those systems. +.NH 3 +Status output +.PP +The new magtape driver has a facility known as status output logging which +can be used to monitor interactively lengthy tape jobs while i/o is in +progress. The status output facility can also be useful for debugging +magtape problems. +.PP +In its simplest form, the status output may be directed to a file, e.g., an +actual text file, or a terminal device. Status output is enabled by setting +the "so" option in tapecap. For example, +.XS +cl> mtex "mta[:so=/tmp/mta.out]" +.XE +would enable status output logging and direct the output text to the file +/tmp/mta.out. Likewise, +.XS +cl> mtex "mta[:so=/dev/ttyp7]" +.XE +would enable status output and direct the output to a pseudoterminal, e.g., +an xterm window. When this form of status output logging is used one +sees the raw, driver level status messages, as in the following example. +.XS +cl> mtex "mta[:so=/dev/tty]" +open device tc2n\\\\n +devtype = Apple Tape 40SC +tapetype = DC2000 +tapesize = 38500 +density = na +blksize = 8192 +acmode = read +file = -1 +record = -1 +nfiles = 0 +tapeused = 0 +device tc2n opened on descriptor 4\n +rewinding... +done\\\\n +position to file 1\\\\n +file = 1 +record = 1 +reading...\\\\n +recsize = 65536 +record = 9 +tapeused = 64 + \fI(etc.)\fP +.XE +.LP +The UNIX version of the new magtape driver also has an option to direct +status output to a TCP/IP socket, which can be anywhere on the network. +For this option to be useful one must have a program which will listen +on the designated socket, accept the connection when the magtape driver +tries to open a connection, and then read and process the status messages +(which are still text, exactly as in the example above). +.PP +Status output to a socket is enabled by giving a host name instead of a +file name in the "so" directive: +.XS +cl> mtex "mta[3:so=lepus]" +.XE +to examine file 3, directing status messages to a socket on node "lepus". +.PP +An X11 client application called \fIxtapemon\fR has been developed to listen +on a socket, read messages from the tape driver, and provide a real-time +display of the status of the tape device. While not included in the V2.10 +IRAF distribution, this utility will be available later in 1992 as part of +the X11 support package currently under development. +.NH 3 +Error recovery +.PP +Considerable effort went into "bullet proofing" the new magtape system to +make it recover gracefully from ctrl/c interrupts or other program aborts. +In practice it can be very difficult to reliably catch and recover from +interrupts in a multiprocess, distributed system such as IRAF. No doubt +there are still conditions under which an interrupt will leave the magtape +system in a bad state, but in most circumstances the system should now be +able to successfully recover gracefully from an interrupt. +.PP +If it is necessary to interrupt a tape operation, it is important to +understand that the host system will not deliver the interrupt signal to the +IRAF process until any pending i/o operation or other driver request +completes. For example, in a read operation the interrupt will not be acted +upon until the read operation completes, or in a tape positioning operation +such as a rewind or file skip forward, the interrupt will not be acted upon +until the tape gets to the requested position. For a device such as a disk +you rarely notice the delay to complete a driver request, but for a magtape +device these operations will take anywhere from a few seconds to a few tens +of seconds to complete. Type ctrl/c once, and wait until the operation +completes and the system responds. +.PP +If a magtape operation is interrupted, the IRAF error recovery code will +mark the tape position as undefined (\fIdevstatus\fR will report a file +number of -1). This will automatically cause a rewind and space forward +the next time the tape is accessed. The rewind is necessary to return the +tape to a known position. +.NH 3 +Device optimization +.PP +In addition to making it possible to characterize the behavior of a magtape +device to permit the device to be accessed reliably, the tapecap facility is +used to optimize i/o to the device. The parameter "fb" may be specified for +a device to define the "optimum" FITS blocking factor for the device. +Unless the user explicitly specifies the blocking factor, this is the value +that the V2.10 \fIwfits\fR task will use when writing FITS files to a tape. +Note that for cartridge devices a FITS blocking factor of 22 is used for +some devices; at first this may seem non-standard FITS, but it is perfectly +legal, since for a fixed block size device the FITS blocking factor serves +only to determine how the program buffers the data (for a fixed block device +you get exactly the same tape regardless of the logical blocking factor). +For non-FITS device access the magtape system defines an optimum record size +which is used to do things like buffer data for cartridge tape devices to +allow streaming. +.PP +Some devices, i.e., some DAT and Exabyte devices, are slow to switch between +read and skip mode, and for files smaller than a certain size, when skipping +forward to the next file, it will be faster to read the remainder of the +file than to close the file and do a file skip forward. The "fe" parameter +is provided for such devices, to define the "file equivalent" in kilobytes +of file data, which can be read in the time that it takes to complete a +short file positioning operation and resume reading. Use of this device +parameter in a tape scanning application such as \fIrfits\fR can make a +factor of 5-10 difference in the time required to execute a tape scan of +a tape containing many small files. +.PP +On most cartridge tape devices backspacing, if permitted at all, is very +slow. On such devices it may be best to set the "nf" parameter to tell +the driver to rewind and space forward when backspacing to a file. +.NH 3 +MTIO interface changes +.PP +A number of new routines were added to the MTIO (magtape i/o) programming +interface. These are documented in the summary of programming environment +revisions given below. Existing magtape applications may benefit from +being modified to make use of these new routines. + +.NH 2 +Graphics and Imaging Subsystem Enhancements +.NH 3 +New graphics applications +.PP +New tasks for histogram plotting, radial profile plotting, and producing +lists of the available graphics devices have been added to the PLOT +package. All of the tasks in this package were revised to add support for +world coordinates. A related task for drawing world coordinate grid +overlays on images or plots was added to the IMAGES.TV package. See the +appropriate sections of \fIIRAF and NOAO package revisions\fP below for +further information on these changes. +.NH 3 +Graphics system changes +.NH 4 +Encapsulated postscript SGI kernel +.PP +A new encapsulated postscript SGI kernel has been added. Graphics output +may be directed to any of the logical graphics devices \fIeps\fR, \fIepsl\fR, +\fIepshalf\fR, etc. to render a plot in encapsulated postscript, e.g., for +inclusion as a figure in a document. For example, +.XS +cl> prow dev$pix 101 dev=eps; gflush +.XE +will leave a ".eps" file containing the plot in the current directory. +The command "gdev dev=eps" will produce a list of the available EPS +logical graphics devices. +.NH 4 +Graphics output to the default printer +.PP +Graphics output (SGI postscript) can now be directed to the UNIX default +printer device by directing output to any of the logical devices "lpr", +"lp", or "lw". +.XS +cl> prow dev$pix 101 dev=lpr +.XE +.PP +Output will be sent to the default device for the UNIX +\fIlpr\fR command (set by defining "PRINTER" in your UNIX environment). +This makes it possible to make immediate use the distributed IRAF graphcap +without having to add entries for specific local devices (although you +may still wish to do so). +.NH 4 +Tick spacing algorithm improved +.PP +The algorithm used to draw the minor ticks on IRAF plots was replaced by an +improved algorithm contributed by the STScI STSDAS group (Jonathan +Eisenhamer in particular). This was derived from similar code in Mongo. +.NH 4 +Graphics metacode buffer +.PP +The default maximum size of the graphics metacode buffer in the CL, used to +buffer graphics output for cursor mode interaction, was increased from 64K +to 128K graphics metacode words (256Kb). The \f(CWcmbuflen\fR environment +variable may be used to change this value. +.NH 4 +IMTOOL changes +.PP +The \fIimtool\fR display server (SunView) was enhanced to add additional +builtin color tables, support for user color tables, and setup panel control +over the screen capture facilities. A version supporting encapsulated +postscript output is in testing. This will be the final version of the +SunView based version of imtool (the new display servers are all X +window system based). +.NH 4 +IMTOOLRC changes +.PP +The \f(CWimtoolrc\fR file, used by display servers such as \fIimtool\fR and +\fIsaoimage\fR to define the available image frame buffer configurations, +has been relocated to the DEV directory to make it easier for local site +managers to customize. The IRAF install script now uses a link to point to +this file, rather than copying it to /usr/local/lib. The maximum number of +frame buffer configurations was increased from 64 to 128. +.NH 4 +X11 support +.PP +The released version of V2.10 does not contain any changes insofar as X11 +support is concerned. Since our X11 support code is host level stuff, with +minimal ties to IRAF per se, it is being developed independently of the V2.10 +release and will be distributed and installed as a separate product. + +.NH 2 +Image Structures +.NH 3 +Image I/O (IMIO) +.PP +The image i/o interface (IMIO) is that part of the IRAF system responsible +for imagefile access and management. The changes to IMIO for V2.10 included +the following. +.NH 4 +Null images +.PP +Null images are now supported for image output, much like the null files +long supported by the file i/o system. For example, +.XS +cl> imcopy pix dev$null +.XE +would copy the image "pix" to the null image. This exercises the software +but produces no actual output image. Unlike null files, null images do not +work for input since images have some minimal required structure, whereas +files can be zero length. +.NH 4 +Preallocating pixel file storage +.PP +In the UNIX versions of IRAF, when a new image is created storage is not +physically allocated for the output image until the data is written. This +is because most UNIX systems do not provide any means to preallocate file +system storage. The UNIX/IRAF file creation primitive \fIzfaloc\fR, used by +IMIO to create pixel files, now provides an option which can be used to +force storage to be physically allocated at file creation time. This feature +is enabled by defining the environment variable \f(CWZFALOC\fR in the UNIX +environment. For example, +.XS +% setenv ZFALOC +.XE +can be entered before starting IRAF to cause space for all pixel files to +be preallocated as images are created. If it is not desired to preallocate +all image storage (there is a significant runtime overhead associated with +preallocating large images) then a value string can be given to specify +which types of images to preallocate storage for. For example, +.XS +% setenv ZFALOC /scr5 +.XE +would preallocate only those pixel files stored on the /scr5 disk, and +.XS +% setenv ZFALOC "/scr5,zero" +.XE +would preallocate only images on /scr5, or images containing the substring +"zero" in the image name. In general, the string value of \f(CWZFALOC\fR +may be the null string, which matches all images, or a list of simple +pattern substrings identifying the images to be matched. +.PP +In most cases the default behavior of the system, which is to not physically +allocate storage until the data is written, is preferable since it is more +efficient. The preallocation option is provided for users who, for example +might have an application which spends a lot of time computing an image, +and they want to ensure that the disk space will be available to finish +writing out the image. +.NH 4 +Image templates now sorted +.PP +As mentioned earlier in the \fISystem Management\fR section, UNIX/IRAF now +sorts UNIX directories. One result of this is that the sections of image +templates which are expanded via pattern matching against a directory will +now be sorted, or at least logically ordered (the final output list will not +necessarily be fully sorted if string substitution is being performed - this +is the reason the output list itself is not sorted). +.NH 4 +The dev$pix test image +.PP +Minor changes were made to clean up the image header of the standard test +image \f(CWdev$pix\fR. A second test image \f(CWdev$wpix\fR has been +added. This is the same image, but with a different header containing a +test world coordinate system (actually the image is just a second image +header pointing to the \f(CWdev$pix\fR pixel file, now shared by both +images). +.NH 3 +Image kernels (IKI) +.PP +The IMIO image kernels are the data format specific part of the IRAF image +i/o subsystem. Each kernel supports a different image format. Existing +disk image formats range from the conventional image raster formats (OIF +and STF) to the photon image format (QPF and QPOE) and the pixel mask +image format (PLF and PMIO/PLIO). There also exist special image kernels +which allow IMIO to be used to access non-disk storage devices such as +image display frame buffers. +.NH 4 +New PLF image kernel +.PP +A new image kernel, the PLF image kernel, has been added which allows IRAF +PMIO/PLIO pixel masks to be stored as images. This kernel first appeared +as a patch to version 2.9 IRAF but was actually developed within V2.10. +.PP +Pixel mask images may be created, deleted, read, written, etc. like other +IRAF images, but the image is stored in a special compressed format designed +specially for image masks. An image mask is an N-dimensional raster-like +object wherein typically there are regions of constant value but arbitrary +shape. Masks are used by applications involving image decomposition. The +image is decomposed into regions of different types, the type of region +being very dependent upon the type of image analysis being performed. A +special type of mask image is the bad pixel mask, used to flag the bad +pixels in an image. Other applications use masks for data quality, to +identify the region or regions to be used for analysis, and so on. +.PP +A PMIO image mask is a special case of a PLIO pixel list. Masks can exist +and be accessed independently of the image i/o system, but the PLF image +kernel allows a mask to be stored and accessed as an IRAF image. Any IRAF +application which operates upon images can operated upon a mask image. +For example, the \fIimcalc\fR (image calculator) program in the SAO XRAY +package can be used to combine images and masks, or compute new masks +by evaluating an algebraic expression over an image. +.PP +Mask images have the reserved image extension ".pl". Some of the features +of mask images are illustrated by the following example. +.XS +cl> imcopy dev$pix pix.pl +dev$pix -> pix.pl +cl> imstat dev$pix,pix.pl +# IMAGE NPIX MEAN STDDEV MIN MAX + dev$pix 262144 108.3 131.3 -1. 19936. + pix.pl 262144 108.3 131.3 6. 19936. +.XE +This is a sort of worst case test of the mask encoding algorithm, since +our test image is not a mask but a noisy image (and hence not very +compressible). Note that masks must be positive valued, hence the MIN +value is different for the two images. Storing \f(CWdev$pix\fR as a +mask does not result in any significant compression, but for a real +mask very high compression factors are possible. The compression algorithm +used in PLIO is simple and fast, combining 2D run length encoding and a +differencing technique in a data structure allowing random access of +multidimensional masks (masks are not limited to one or two dimensions). +.PP +For further information on pixel lists and pixel masks, see the document +\f(CWplio$PLIO.hlp\fR in the online system. This is also available as +\f(CWplio.txt.Z\fR in the IRAF network archive. +.NH 4 +OIF image kernel changes +.PP +The OIF image kernel is the kernel for the old IRAF image format - this is +still the default IRAF image format. Revisions to the OIF kernel for V2.10 +included the following items. +.RS +.IP \(bu +A valid image header is now written even if an application which writes to +a new image is aborted. Previously, the pixel file would be written but +the image header would be zero length until the image was closed. If an +image creation task aborts the image will likely be incomplete in some way, +e.g., part of the pixels may not have been written to, or the header may +be missing application specific keywords. By valid image header we mean +that the header will be valid to IMIO, allowing the image to be accessed +to try to recover the data, or to delete the image. +.IP \(bu +The image header file of a new image is now written to and closed at image +create time, then reopened at image close time to update the header. This +frees one file descriptor, an important consideration for applications +which for some reason need to write to dozens of output images +simultaneously. +.IP \(bu +The OIF image kernel uses file protection to prevent inadvertent deletion of +the image header file. In UNIX/IRAF systems file delete protection is +simulated by creating a ".." prefixed hard link to the file. This could +cause problems with images if the user deleted the image header file outside +of IRAF, leaving the ".." prefixed link to the file behind. A subsequent +image create operation with the same image name would fail due to the +existence of the hidden ".." prefixed file. It is unlikely that such a +file (with a ".." prefix and a ".imh" extension) could ever be anything but +an old IRAF image header file, so the system will now silently replace such +files when creating a new image. +.RE +.PP +A couple of related system changes were made which, while not implemented in +the OIF kernel, do involve the OIF or ".imh" image format. The default +template \f(CWlogin.cl\fR now defines the environment variable +\f(CWimtype\fR and sets it to "imh". The environment variable +\f(CWmin_lenuserarea\fR is also defined now at login time, with a default +value of 20000, allowing image headers with up to about 250 header +parameters. +.NH 4 +STF image kernel changes +.PP +The STF image kernel is the kernel for the online HST (Hubble Space Telescope) +image format. This format allows multiple images to be grouped together in +a single "group format" image. There is a common image header stored in a +FITS-like format, as well as a small fixed format binary header associated +with each image in the group. +.RS +.IP \(bu +A check was added for a group index out of range. This yields a more +meaningful error message about no such group, rather than having IMIO +complain about a reference out of bounds on the pixel file. +.IP \(bu +Support was added for non-group STF images (GROUPS=F in the header). +At first glance a non-group group format image might seem a little silly, +but it turns out that a non-group STF image with a zero length group +parameter block is very close to "FITS on disk", since the header is +FITS-like and the image matrix is simple. It is still not true FITS +since the header and pixels are stored in separate files and the pixels +are not encoded in a machine independent form, but on UNIX hosts which +are IEEE standard and not byte swapped, it comes close enough to be useful +for communicating with external applications in some cases. +.RE +.PP +A true FITS image kernel is planned for IRAF. This will probably appear +in one of the V2.10 patches, sometime during 1992. +.NH 4 +QPF image kernel changes +.PP +The QPF image kernel is the interface between the QPOE (position ordered +event file) interface and IMIO, allowing QPOE event files to be accessed as +images by general IRAF applications. Photon "images" are unique in that the +image raster is generated at runtime as the image is accessed, optionally +passing the photon list through event attribute and spatial filters, and +sampling the photons to produce a raster image. For example, +.XS +cl> imcopy "snr[time=@snr.tf,bl=4]" snr.imh +.XE +would filter the event list stored in the file "snr.qp" by the time filter +stored in file "snr.tf", sample the image space blocking by a factor of 4, +and store the resultant image raster in the OIF image file "snr.imh". +.XS +cl> display "snr[time=@snr.tf,bl=4]" 1 +.XE +would display the same image raster without creating an intermediate disk +image. +.LP +The changes to the QPF interface for V2.10 included the following. +.RS +.IP \(bu +A bug was fixed which would prevent very long filter expressions from being +correctly recorded in the IMIO image header. The current version of IMIO +stores applications header parameters in FITS format, hence multiple FITS +cards are required to store long filter expressions. The bug would cause +only one such card to be output. +.IP \(bu +A new facility was added which allows general expressions to be computed for +the input event list and stored as keywords in the output image header. The +header of the input QPOE file can contain one or more parameters named +\fIdefattr1\fR, \fIdefattr2\fR, and so on. If present, the string value of +each such parameter should be a statement such as +.XS +exptime = integral time:d +.XE +which will cause a keyword named "exptime" to be added to the output image +header, the scalar value of the keyword being the value of the expression on +the right. Currently, only the integral function is provided. This +computes the included area of a range list field of the event attribute +expression, such as a time filter. In the example, "time" is the name of +the event attribute to be integrated, and the ":d" means use a range list of +type double for the computation. The data types currently supported are +integer, real and double. +.RE +.PP +Other minor changes to QPF included improvements to the error recovery, +and other changes to support very large filters. +.NH 3 +World coordinate system support (MWCS) +.PP +MWCS is the IRAF world coordinate system package, one of the major new +system interfaces developed for the new image structures project. +A full description of the MWCS interface is given in the file +\f(CWmwcs$MWCS.hlp\fR in the online system, and in the file \f(CWmwcs.txt.Z\fR +in the IRAF network archive. +.NH 4 +Applications support +.PP +MWCS was first released in V2.9 IRAF and at the time the interface was new +and few applications were yet using it. In V2.10 IRAF most (but not all) +applications which deal with coordinates now use MWCS. These include all of +the system plotting tasks, and the spectral reduction packages. Details of +the MWCS support added to the system and science applications in V2.10 are +given in the \fIIRAF and NOAO package revisions\fR section of this revisions +summary. +.NH 4 +New function drivers +.PP +Function drivers for the \fIarc\fR, \fIsin\fR, and \fIgls\fR nonlinear sky +projections were added, as well as a special function driver for the +\fImultispec\fR image format. The latter allows general programs which +don't know anything about spectra to access and display spectra in world +coordinates, e.g., for plotting. +.NH 4 +WCS attributes +.PP +The maximum number of "attributes" per WCS was increased from 64 to 256, +mainly to support the multispec function driver, which makes heavy use of +attributes. A limit on the size of a single attribute value string was +removed, allowing arbitrarily large attribute values to be stored. +.NH 4 +Axis mapping +.PP +Axis mapping is now fully implemented. Axis mapping is used when, for +example, you extract a 2 dimensional section from a 3 dimensional image +and write the result to a new image. Axis mapping allows the 2 dimensions +of the new image to be mapped backed into the original 3 dimensional WCS, +making it possible to get the full physical coordinates (which are 3 +dimensional) for any point in the extracted image. A new header keyword +\f(CWWAXMAP\fInn\fR was added to store the axis map in image headers. +.NH 4 +MWCS save format +.PP +The newer IRAF image formats such as QPOE are capable of storing arbitrarily +complex objects such as a MWCS in an image header keyword. In the case of a +stored MWCS object, the MWCS interface is responsible for encoding the +object in its external storage format, and restoring it to a MWCS descriptor +when the MWCS is accessed. The code which does this was revised to add a +new version number for the stored V2.10 MWCS, to make it possible to +differentiate between the MWCS save formats used in V2.9 and V2.10 and allow +recovery of MWCS objects from data files written under V2.9. +.NH 4 +Bug fixes +.PP +Since MWCS is a new interface and V2.10 saw its first real use in +applications, a number of interface bugs were discovered and fixed. Most of +the bugs turned out to be in the part of MWCS which converts between the +internal MWCS WCS representation, and the FITS WCS representation, used for +those image formats that still use FITS-like headers. Bug fixes included a +problem with the treatment of CROTA2, a problem with the FITS CD matrix, an +axis mapping problem that caused "dimension mismatch" errors, and a problem +with support for the old-style CDELT/CROTA which could result in a singular +matrix during WCS inversion when compiling a transformation. +.NH 3 +Event files (QPOE) +.PP +The QPOE interface is the interface responsible for creating and accessing +\fIevent files\fR, the main data format produced by event counting +detectors. We summarize here the main enhancements to QPOE made during the +preparation of V2.10. Some of these features appeared earlier in the +patches made to V2.9 IRAF but these revisions have never been formally +documented so we summarize both the old and new revisions here. See also +the discussion of the QPF image kernel given earlier. +.NH 4 +Blocking factors +.PP +The builtin default blocking factor, when sampling the event list to make +an image raster, is one. This may be changed on a per-datafile basis by +defining the parameter \fIdefblock\fR in the QPOE file header. +.NH 4 +Parameter defaults +.PP +Since parameters such as the blocking factor can be set at a number of levels, +a parameter defaulting scheme was defined to determine the precedence of +parameter overrides. The lowest level of precedence is the builtin default. +Next is any datafile specific value such as \fIdefblock\fR. A value such +as \fIblockfactor\fR set in the QPDEFS file will override the datafile +default value if any. Specifying the parameter value in a runtime filter +expression or \fIqpseti\fR call is the highest order of precedence and will +override any other setting. +.PP +Another way to think of this is the more recently the parameter was set, the +higher the precedence. The oldest value is the default builtin to the +code. Next is the datafile value, usually set when the datafile was +created. Next is the QPDEFS macro file, usually set by the user or for a +site. Last (highest precedence) is the value set by the user when the data +is accessed. +.NH 4 +Referencing the current datafile in macros +.PP +A special symbol \f(CW$DFN\fR is now recognized during macro expansion and +if present is replaced by the filename of the current QPOE file. This allows +macros to be written which automatically perform some operation involving +the datafile to which they applied, e.g., computing an attribute list from +aspect or data quality information stored in the datafile header. +.NH 4 +Bitmask expressions +.PP +Bitmask expressions may now be negated, e.g., "%3B" is the mask 03 octal, +"!%3B" or "!(%3B)" is the complement of 03 octal. +.NH 4 +Large time filters +.PP +A number of changes and bug fixes were made to QPOE for V2.10 to support +large time filters. These are lists of "good time" intervals used to filter +the event list. These large time filters may contain several hundred +double precision time intervals spanning the exposure period. Often a +large time filter is combined with a complex spatial filter (PLIO mask) to +filter an event list consisting of from several hundred thousand to several +million events. QPOE can handle this efficiently regardless of whether +the data is temporarily or spatially sorted and regardless of the complexity +of the temporal or spatial filters. +.PP +A number of minor bugs were fixed caused by the large filter expressions +overflowing various buffers. The default sizes of the program and data +buffers used to compile filter expressions were increased to allow all but +very large filters to be compiled without having to change the defaults. +If the buffers overflow more space can be allocated by setting the +\f(CWprogbuflen\fR and \f(CWdatabuflen\fR parameters in QPDEFS (these +buffers are not dynamically resized at runtime for efficiency reasons). +During testing with large time filters it was discovered that a routine +used to test floating point equality was being used inefficiently, and +compilation of large time filters was taking a surprisingly long time. +A change was made which reduced the time to compile large filters by a +factor of 10 to 15. +.NH 4 +Default filters +.PP +QPOE now fully supports default event attribute and spatial filtering of +data at runtime. The idea is that the full data set (all events) is stored +in the QPOE file, along with default event attribute and spatial filters. +When the data is accessed these filters are, by default, automatically +applied. Any user specified event attribute or spatial filters are "added" +to the builtin default filters to produce the combined filter used when the +event list is accessed. The point of all this is to make it easy for the +user to modify or replace the default filters and "reprocess" the raw event +list. In effect the raw and processed event list are available in the same +file. +.PP +The default filter and mask, if any, are stored in the datafile header +parameters \f(CWdeffilt\fR and \f(CWdefmask\fR. If the datafile contains +multiple event lists a default filter or mask may be associated with +each list by adding a period and the name of the event list parameter, +e.g., "deffilt.foo" would be the default filter for the event list "foo". +.PP +By default, if a default filter or mask exists for an event list it is +automatically applied when the event list is accessed. +Use of the default filter or mask can be disabled in QPDEFS with either +of the following statements: +.XS +set nodeffilt +set nodefmask +.XE +The default filter and mask can also be disabled in a filter expression +by adding a "!" before the expression, as in the following example. +.XS +display "snr[!time=@times.lst,pha=(3,8:11)]" +.XE +There are actually several variants on the "=" assignment operator used +in filter expressions such as that above. The operator "=" is equivalent +to "+=", meaning the expression term on the right adds to any existing +filter specified for the event attribute on the left. The operator ":=" +on the other hand, means \fIreplace\fR any existing filter by the new +filter expression. +.NH 4 +Alternate coordinate systems +.PP +The event structure used to represent each event in an event list may +contain multiple coordinate systems if desired, for example, detector and +sky coordinates. One coordinate system should be defined as the default +when the event list is created, and if the event list is to be indexed +it must be sorted using the coordinate system specified as the default. +Any coordinate system may be used when the data is accessed however; +this can result in quite different views of the same data set. For example, +.XS +cl> display snr.qp 1 +.XE +would display the QPOE file "snr.qp" in display frame 1, using all defaults +for the event list, blocking factor, filter, mask, and so on. The default +event coordinate system would probably be sky coordinates. To display the +same event list in detector coordinates, one could enter the following +command. +.XS +cl> display "snr.qp[key=(dx,dy)]" 1 +.XE +This assumes that the event structure fields "dx" and "dy" are defined +somewhere, either in the datafile header or in QPDEFS (otherwise the actual +field datatype-offset codes must be given). +.PP +Currently if the QPOE datafile has a WCS associated with it this WCS can +only refer to one coordinate system, normally the default event coordinate +system. Additional WCS can be stored in the QPOE file, either in the stored +MWCS object or as separate MWCS objects, but at present there is no +mechanism for selecting which will be used (if the parameter \f(CWqpwcs\fR +exists in the QPOE file header, this is assumed to be a stored MWCS object +and this is the WCS which will be used). + +.NH 2 +System Specific Changes +.NH 3 +Sun/IRAF +.PP +Since V2.10 has only just been completed and at this stage has only been +released on Sun platforms, there are few system specific revisions to report. +For SunOS there were several system specific revisions worth noting here. +.RS +.IP \(bu +The HSI binaries for the sparc architecture are now statically linked. +This makes them considerably larger, but avoids problems with SunOS +complaining about shared library version mismatches (note that we refer +here to to Sun shared libraries - this is not a problem with the IRAF +shared library facility since we control the version numbers). +.IP \(bu +The HSI binaries for the Motorola architectures (f68881 and ffpa) are +\fInot\fR statically linked since they cannot be without running into +linker problems warning about f68881_used etc. To avoid or at least +minimize warnings about SunOS shared library versions the system was +linked on 4.1.1 instead of 4.1.2. SunOS 4.0.3 versions of the Motorola +HSI binaries are also available upon request. +.IP \(bu +The system as distributed was linked with the name server library, +\f(CW-lresolv\fR. This means that if the local host is configured to +use the name server, IRAF will be able to access almost any host on the +Internet without an entry in the \f(CW/etc/hosts\fR file on the local host. +.RE +.PP +Additional system specific changes will be reported in the documentation +distributed with each release, as V2.10 is moved to the various platforms +for which IRAF is supported. + +.bp +.NH +IRAF and NOAO package revisions +.PP +The revisions for the various packages in the IRAF core system and in the +NOAO packages are summarized below. There have been many changes with this +release. Users are encouraged to refer to the help pages, user's guides +provided with some packages, revisions notes, and more recent issues of IRAF +Newsletters for more details. Comprehensive notes on systems and +applications modifications are in the files \f(CWpkgnotes.v210.Z\fP and +\f(CWsysnotes.v210.Z\fP in the directory \f(CWiraf/v210\fP in the network +archive. This summary can be read online by typing \fInews\fP. Revisions +notes for the various packages can also be accessed online as in the +following example. +.XS +cl> phelp dataio.revisions opt=sys +.XE +.PP +One of the system changes that affects many tasks in the IMAGES, PLOT, and +LISTS packages as well as most tasks in the spectroscopic packages in NOAO +is the full implementation of the world coordinate system (WCS), introduced +in V2.9 but not fully integrated into the IRAF and NOAO tasks at that time. +There are currently three classes of coordinate systems: the logical system +is in pixel units of the current image section; the physical system is in +pixel units of the parent image (for a WCS associated with a raster image); +the world system can be any system defined by the application, e.g. RA and +DEC or wavelength. In general, this should be transparent to the user since +most defaults have been chosen carefully so that tasks perform the same as +in V2.9. The NOAO spectroscopic tasks also use the WCS extensively, but +again, this should be transparent to the user, although it can cause some +problems with backward compatibility. Users will notice the biggest +difference in the image headers with additional keywords added by the +interface. Two tasks in the PROTO package may help the interested user +understand more about the WCS - see \fIwcsedit\fP and \fIwcsreset\fP. +Technical notes on the WCS are available in a paper in the +\f(CWiraf$sys/mwcs\fP directory. Type the following to read more about the +MWCS interface. +.XS +cl> phelp mwcs$MWCS.hlp fi+ +.XE +.NH 2 +Changes to the IRAF system packages +.NH 3 +DATAIO package modifications +.IP \(bu +The output defaults for \fIwfits\fP have been modified. If the pixel type on +disk is real or double precision the output will be IEEE format (FITS +bitpix = -32 or -64, respectively). If the pixel type on disk is short +integer then the output will be integer format (bitpix = 16) as before. +These defaults can of course be changed by modifying the parameters for +\fIwfits\fP. +.IP \(bu +The \fIwfits\fP "blocking_factor" parameter can accept values up to and +including 10 for variable blocked devices, i.e. 1/2" tape drives, Exabytes, +and DATs. If the "blocking_factor" parameter is set to "0", as in the +default, the value is read from the "fb" parameter in the tapecap file +(usually 10 for variable blocked devices). For fixed blocked devices such +as cartridge tape drives the default value for the "fb" parameter in the +tapecap file is 22 (used to determine a buffer size) and the block size +of the device is given by the "bs" parameter. +.IP \(bu +All tasks were modified to accept tapecap parameters as part of the magtape +file name syntax. Tapecap +parameters can now be appended to the magtape file name to add to or +override values in the tapecap file. For example, +\f(CW"mta6250[:se]"\fP is a valid magtape file name (the "" are important +when tapecap parameters are specified at execution time). See the file +\f(CWos$zfiomt.c\fP for more details about the tapecap parameters. +.IP \(bu +The \fIrfits\fP task has been modified to permit a short last record, i.e. a last +record that has not been padded out to 2880 bytes. No warning messages +are issued. +.IP \(bu +\fIrfits\fP was modified to map ASCII control characters in the header to blanks. +.IP \(bu +The sequence number appended to disk file names by \fIrfits\fP and \fIwfits\fP was +modified to 4 digits, i.e. 0001 - 9999. +.NH 3 +IMAGES package modifications +.IP \(bu +WCS (world coordinate system) support was added to all tasks in the IMAGES +package that could introduce a coordinate transformation. Some tasks had +already been modified for the V2.9 release. These tasks +(\fIblkavg\fP, \fIblkrep\fP, \fIgeotran\fP, \fIimcopy\fP, \fIimlintran\fP, \fIimshift\fP, \fIimslice\fP, \fIimstack\fP, +\fIimtranspose\fP, \fImagnify\fP, \fIregister\fP, \fIrotate\fP, and \fIshiftlines\fP), upon execution, +will update the image header to reflect any transformation. +.IP \(bu +The \fIlistpixels\fP task was modified to list the pixel coordinates in either +logical, physical, or world coordinates. A format parameter was added to +the task for formatting the output pixel coordinates taking precedence over +the WCS in the image header, if used. +.IP \(bu +A new \fIimcombine\fP task was added to the package. This new task supports +image masks and offsets, and has an assortment of new combining algorithms. +See the help pages for complete details on this powerful new task. +.IP \(bu +The \fIimhistogram\fP task has a new "binwidth" parameter for setting histogram +resolution in intensity units. +.IP \(bu +The default values for the parameters "xscale" and "yscale" in the +\fIregister\fP and \fIgeotran\fP tasks were changed from INDEF to 1.0, to preserve the +scale of the reference image. +.NH 3 +IMAGES.TV package reorganization and modifications +.IP \(bu +The TV package has been reorganized. The IIS dependent tasks have been moved +into a subpackage, TV.IIS. The \fIimedit\fP, \fIimexamine\fP, and \fItvmark\fP tasks that were +previously in PROTO have been moved to TV. +.IP \(bu +A new task \fIwcslab\fP developed at STScI by Jonathan Eisenhamer was added +to the package. \fIwcslab\fP overlays a labeled world coordinate grid on an +image using WCS information stored in the header of the image or in +parameters of the task. +.IP \(bu +\fIimexamine\fP was modified to use WCS information in axis labels and +coordinate readback, if selected by the user. Two new parameters, "xformat" +and "yformat", were added to specify the format of the WCS if it is not +present in the header of the image. +.IP \(bu +A new option was added to \fIimexamine\fP to allow for fitting 1D gaussians to +lines or columns. +.IP \(bu +\fItvmark\fP had two cursor key changes. The "d" keystroke command that marked +an object with a dot was changed to "."; the "u" keystroke command that +deleted a point was changed to "d". +.NH 3 +LISTS package modifications +.IP \(bu +Two new parameters were added to the \fIrimcursor\fP task, "wxformat" and +"wyformat". These parameters allow the user to specify the coordinate +formats for the output of the task and override any values stored in the +WCS in the image header. +.NH 3 +OBSOLETE package added +.IP \(bu +An new package called OBSOLETE was added. Tasks will be moved to this +package as they are replaced by newer tasks in the system. OBSOLETE tasks +will then be removed at the time of the next release. +.IP \(bu +\fImkhistogram\fP, \fIimtitle\fP, \fIradplt\fP, and the old \fIimcombine\fP task have been moved to the +OBSOLETE package. Users should become familiar with \fIphistogram\fP, \fIhedit\fP, +\fIpradprof\fP, and the new \fIimcombine\fP and use +them instead since \fImkhistogram\fP, \fIimtitle\fP, \fIradplt\fP, and \fIoimcombine\fP will be +retired with the next release. +.NH 3 +PLOT package modifications +.IP \(bu +A new task called \fIphistogram\fP was added to the PLOT package. This task +takes input from an image or from a list and allows full control +over the plotting parameters. This task replaces the \fIobsolete.mkhistogram\fP +task. +.IP \(bu +A new task \fIpradprof\fP was added to the PLOT package. This task plots or lists +the radial profile of a stellar object. This task replaces the +\fIobsolete.radplt\fP task. +.IP \(bu +A new task called \fIgdevices\fP was added to the package. \fIgdevices\fP prints +available information known about a particular class of device. The +default parameters are set up to print a list of the available stdimage +devices in the standard graphcap file. +.IP \(bu +WCS support was added to the tasks \fIgraph\fP, \fIpcol(s)\fP, and \fIprow(s)\fP. A new +parameter called "wcs" was added to define the coordinate system to be +used on the axis, either logical, physical or world. Two additional +parameters, "xformat" and "yformat", were also added to allow the user to set +the format for axis labels overriding any values in the image header. +The "xlabel" parameter values were extended to include the special word +"wcslabel" to select the WCS label for the x axis from the image header. +.IP \(bu +WCS support was added to the task \fIimplot\fP. A new parameter called +"wcs" was added to define the coordinate system for plotting, either logical, +physical, or world. Two new ":" commands were also added: ":w" allows +the user to set a new WCS type interactively; ":f" allows the user +to change the axis format, for instance, ":f %H" would change the axis +to read h:m:s, if the world coordinate RA had been defined in the image +header. The "space" key now prints out the coordinate and pixel value +information. +.IP \(bu +\fIgraph\fP has a another new parameter "overplot" that allows the user to overplot +multiple plots with different axes. +.IP \(bu +The default parameters for "floor" and "ceiling" in \fIcontour\fP and \fIsurface\fP were +changed to INDEF. +.NH 3 +PROTO package reorganization and modifications +.PP +This package has been reorganized. The PROTO package now resides in the +core system. Tasks in the old PROTO package that were general image +processing tools were kept in this new PROTO package. Tasks that were more +data reduction specific were moved to the new NPROTO package in the NOAO +package. The current PROTO package now contains the tasks \fIbinfil\fP, +\fIbscale\fP, \fIepix\fP, \fIfields\fP, \fIfixpix\fP, \fIhfix\fP, +\fIimalign\fP, \fIimcentroid\fP, \fIincntr\fP, \fIimfunction\fP, +\fIimreplace\fP, \fIimscale\fP, \fIinterp\fP, \fIirafil\fP, \fIjoinlines\fP, +\fIsuntoiraf\fP, \fIwcsedit\fP, and \fIwcsreset\fP. +.IP \(bu +The new task \fIhfix\fP was added to the package. This task allows the user to +extract the image headers into a text file, view or modify this file with a +specified command, and then update the image header with the modified file. +.IP \(bu +A new task called \fIsuntoiraf\fP was added to this package. This is a host +dependent task that will most likely be useful only on Sun's. This task +converts a Sun raster file into an IRAF image. +.IP \(bu +Two new tasks dealing with the WCS were added to this package, +\fIwcsreset\fP and \fIwcsedit\fP. \fIwcsreset\fP resets the coordinate +systems in the image header to the logical coordinate system. \fIwcsedit\fP +allows the user to modify the existing WCS or to create a new WCS and then +update the image header. +.IP \(bu +A new version of \fIbscale\fP was added to the package. The task now takes a +list of input images and output images. +.IP \(bu +A new version of \fIimfunction\fP was added to the package. The task supports +many more functions, for example log10, alog10, ln, aln, sqrt, square, cbrt, +cube, abs, neg, cos, sin, tan, acos, asin, atan, hcos, hsin, htan, and +reciprocal. +.IP \(bu +\fIimreplace\fP was modified to support the "ushort" pixel type. +.IP \(bu +The task \fIjoin\fP has been renamed \fIjoinlines\fP. +.NH 3 +Additions to XTOOLS and MATH +.PP +Programmers may be interested in the following new additions to the XTOOLS +and MATH libraries. +.IP \(bu +The interactive non-linear least squares fitting package INLFIT, developed by +Pedro Gigoux at CTIO, was added to XTOOLS. +.IP \(bu +The 1D image interpolation routines in the MATH library were modified +to support sinc interpolation. +.NH 3 +Glossary of new tasks in the IRAF core system +.sp 0.5 +\fR +.TS +center; +c c c c c +l c l c lw(4i). +Task Package Description +_ + +gdevices - plot - List available imaging or other graphics devices +hfix - proto - Fix image headers with a user specified command +imcombine - images - Combine images pixel-by-pixel using various algorithms +phistogram - plot - Plot or print the histogram of an image or list +pradprof - plot - Plot or list the radial profile of a stellar object +suntoiraf - proto - Convert Sun rasters into IRAF images +wcsedit - proto - Edit the image coordinate system +wcslab - tv - Overlay a displayed image with a world coordinate grid +wcsreset - proto - Reset the image coordinate system +.TE +.NH 2 +Changes to the NOAO Packages +.PP +An updated version of the \fIobservatory\fP task has been installed at the +NOAO level. The task sets observatory parameters from a +database of observatories or from the parameters in the task itself. +Many packages and tasks within the NOAO packages that need information +about where the data was observed use information supplied by +the \fIobservatory\fP task. +.NH 3 +ARTDATA package modifications +.PP +A new version of the ARTDATA package was released with IRAF version 2.9.1. +A summary of those changes plus modifications since that update are listed +below. A more comprehensive list of the changes included in V2.9.1 are +discussed in IRAF Newsletter Number 10. +.IP \(bu +A new task \fImkechelle\fP has been added that creates artificial 2D echelle +images. +.IP \(bu +A new task \fImkexamples\fP has been added. The task is intended to generate a +variety of artificial images to be used in testing or demonstrations. +.IP \(bu +A new task \fImkheader\fP adds or modifies +image headers using a header keyword data file. +.IP \(bu +The \fImk1dspec\fP task was modified to create multispec and echelle format +images, line by line. +.IP \(bu +A parameter "header" was added to \fImkobjects\fP, \fImknoise\fP, \fImk1dspec\fP, and +\fImk2dspec\fP so that a header data file could be added to the output image. +Other header parameters are also added to the image header such as +gain, rdnoise, and exptime. +.IP \(bu +A "comments" parameter was added to various tasks to include/exclude comments +in the header of the output image that describe the data parameters. +.NH 3 +ASTUTIL package modifications +.IP \(bu +A new task \fIgratings\fP has been added to the package. This task computes +grating parameters; five of the seven parameters must be specified at +one time. +.IP \(bu +A new task \fIsetjd\fP has been added to the package. \fIsetjd\fP computes the geocentric, +heliocentric, and integer local Julian dates from information given in the +headers of the input list of images. This information is then listed or +added to the image headers. +.IP \(bu +A few changes were made to \fIsetairmass\fP. The default value for "update" +was changed to "yes"; an update field was added to the "show" messages; +a warning is printed if both "show" and "update" are set to "no" +indicating that nothing was done. +.NH 3 +DIGIPHOT package modifications +.PP +A new version of the DIGIPHOT package was installed. Some changes were +made to the existing APPHOT package used for aperture photometry, and those +are mentioned below. But three new packages have also been installed, DAOPHOT, +PHOTCAL, and PTOOLS. +.PP +DAOPHOT has been available for the past two years as an add-on package known +as TESTPHOT. It is now part of the distributed system. The IRAF version of +DAOPHOT, used to do photometry in crowded fields, has been a collaborative +effort with Peter Stetson and Dennis Crabtree of the DAO. For the +convenience of the many TESTPHOT users, changes to the package since the +last release of TESTPHOT are summarized below. +.PP +PHOTCAL is the photometric calibration package for computing the transformations +of the instrumental magnitudes output from APPHOT and DAOPHOT +to the standard photometric system. This +package has been a collaborative effort with Pedro Gigoux at CTIO. +.PP +PTOOLS is a package containing an assortment of tools for manipulating +the data files produced from APPHOT and DAOPHOT. If users are using +STSDAS TABLES format data files then they must first install the +TABLES layered package. This package can be obtained from either STScI or +NOAO (see \f(CWiraf/contrib\fR in the IRAF network archive). +.NH 3 +DIGIPHOT.APPHOT package modifications +.IP \(bu +The \fIapselect\fP task was replaced with the functionally equivalent \fItxdump\fP task. +\fItxdump\fP allows +the user to select fields of data from the output data files produced +from APPHOT tasks and either simply list the extracted data or save it +in another file. +.IP \(bu +A new task called \fIpexamine\fP has been added to the package. \fIpexamine\fP is a +general purpose tool for interactively examining and editing the data +files produced from tasks in either APPHOT or DAOPHOT. This task is +intended to complement the batch oriented task \fItxdump\fP. +.IP \(bu +All of the APPHOT tasks will now query to verify the "datamin" and "datamax" +values, if these values are used by the tasks. +.IP \(bu +The time of the observation, i.e. UT, can now be carried over into the output +data files, if a keyword in the image header contains this information. +.IP \(bu +If there is bad data within the photometry aperture a value of INDEF will +be stored in the data file for that magnitude. +.NH 3 +DIGIPHOT.DAOPHOT (TESTPHOT) package modifications +.PP +This is a new package but for the convenience of the many users of the +TESTPHOT add-on package, +the changes to TESTPHOT between its last release and its installation into +the DIGIPHOT package as DAOPHOT are summarized below. +.IP \(bu +The \fIappend\fP, \fIconvert\fP, \fIdump\fP, \fIrenumber\fP, \fIselect\fP, and \fIsort\fP tasks were renamed +to \fIpappend\fP, \fIpconvert\fP, \fIpdump\fP, \fIprenumber\fP, \fIpselect\fP, and \fIpsort\fP. +.IP \(bu +The "text" parameter was moved from \fIdaopars\fP to the DAOPHOT package parameters. +.IP \(bu +All the DAOPHOT routines were modified so that "psfrad", "fitrad", and +"matchrad" are defined in terms of scale. +.IP \(bu +The tasks \fIallstar\fP, \fIgroup\fP, \fInstar\fP, \fIpeak\fP, \fIpsf\fP, and \fIsubstar\fP were all modified +to include "datamin" and "datamax" in their verify routines. +.IP \(bu +Support was added for a time of observation parameter to all the +appropriate DAOPHOT tasks. If present, this time will be carried over +into the output data files. +.IP \(bu +All the DAOPHOT tasks except \fIpsf\fP have been modified to accept lists of input +and output files. +.IP \(bu +The new \fIpexamine\fP task was added to this package. \fIpexamine\fP is a +general purpose tool for interactively examining and editing the data +files produced from tasks in either APPHOT or DAOPHOT. This task is +intended to complement the batch oriented task \fItxdump\fP. +.IP \(bu +Several changes were made to \fIpsf\fP: the default PSF image header will now +hold up to 66 stars (but it is still dependent on the environment +variable \f(CWmin_lenuserarea\fP); a check was added so that the same star can +not be added to the PSF twice; potential PSF stars are now rejected if +their sky or magnitude values are INDEF; a check was added so that stars +with INDEF valued positions are treated as stars that were not found. +.IP \(bu +\fIgroup\fP was modified so that the groups are output in y order instead of in +order of the size of the group. +.IP \(bu +Both \fIgroup\fP and \fIpeak\fP were modified so that stars with INDEF centers are not +written to the output file. +.NH 3 +IMRED package modifications +.PP +The spectroscopic packages within the IMRED package have undergone quite a bit +of work and reorganization. The spectroscopic packages are now ARGUS, +CTIOSLIT, ECHELLE, HYDRA, IIDS, IRS, KPNOCOUDE, KPNOSLIT, and SPECRED. +These packages are a collection of tasks from APEXTRACT and ONEDSPEC that are +appropriate for the specific applications. +All these packages use the new versions of the APEXTRACT and ONEDSPEC packages; +the changes for APEXTRACT and ONEDSPEC are summarized below. +Earlier versions of all these packages were released as the NEWIMRED add-on +package. The NEWIMRED package is now defunct and the distributed system +contains the latest versions of these packages. +.PP +The spectroscopic packages now contain "DO" tasks that are scripts that +streamline the reduction process for the user. The "DO" tasks have been +modified for each particular application. +.PP +The ARGUS package is for the reduction of data taken with the CTIO \fIargus\fP +instrument. Its corresponding script task is \fIdoargus\fP. +.PP +The CTIOSLIT package is similar to the ARGUS package except that is a +collection of spectroscopic tasks used for general CTIO slit reductions. The +\fIdoslit\fP task allows for streamlined reductions. +.PP +The ECHELLE package has the addition of the \fIdoecslit\fP task for +simplied echelle reductions. The \fIdofoe\fP task has been added for the reduction +of Fiber Optic Echelle (FOE) spectra. +.PP +The HYDRA package is used for the reduction of multifiber data taken at +KPNO. The \fIdohydra\fP task has been customized for streamlining \fInessie\fP +and \fIhydra\fP reductions. +.PP +The KPNOCOUDE package has been customized for the KPNO Coude. The \fIdoslit\fP +task allows the user to go through the reduction process with as few +keystrokes as possible. The \fIdo3fiber\fP task is specialized for the 3 fiber +(two arc and one object) instrument. +.PP +The KPNOSLIT package can be used for general slit reductions at KPNO. The +\fIdoslit\fP task in this package is similar to that in the other packages. +.PP +The SPECRED package is the old MSRED package, used for general multispectral +reductions. This is a generic package that can be used for slit and multifiber/ +aperture data. General \fIdoslit\fP and \fIdofibers\fP tasks are available. +.PP +Several of the spectroscopic packages has a special task called \fImsresp1d\fP +for creating 1d aperture response corrections from flat and +throughput data. This task is specialized for multiaperture or +multifiber data. +.PP +All of the "DO" tasks have reference manuals that are available in the +network archive in the \f(CWiraf/docs\fP directory. +.NH 3 +IMRED.CCDRED package modifications +.IP \(bu +A new task \fIccdinstrument\fP was added to the package. The purpose of this +task is to help users create new CCD instrument translation files to use +with the package. +.IP \(bu +The \fIcombine\fP task (as well as \fIdarkcombine\fP, \fIflatcombine\fP, and \fIzerocombine\fP) is +the same task as the new \fIimcombine\fP task in IMAGES. A few parameters were +added for compatibility with the CCDRED tasks. +.IP \(bu +A new parameter was added to \fIccdproc\fP called "minreplace". Pixel values +in flat fields below the value for "minreplace" are replaced by the same +value (after overscan, zero, and dark corrections). This avoids dividing +by zero problems. +.IP \(bu +The default computation and output "pixeltype" in the package parameter +for CCDRED are both real. Note that both can now be specified separately. +.IP \(bu +The default parameters for \fIdarkcombine\fP and \fIflatcombine\fP have been changed. +.NH 3 +NOBSOLETE package added +.PP +This new package has been defined but currently no tasks reside in it. This +package will be used as a repository for tasks that have been replaced by +newer tasks in the NOAO packages. The NOBSOLETE tasks will then be removed +at the time of the next release. +.NH 3 +NPROTO package modifications +.PP +The old PROTO package was divided into two separate packages, one called +PROTO that now resides in the IRAF core system and the other called +NPROTO that resides in the NOAO package. The current NPROTO tasks +are \fIbinpairs\fP, \fIfindgain\fP, \fIfindthresh\fP, \fIiralign\fP, \fIirmatch1d\fP, \fIirmatch2d\fP, \fIirmosaic\fP, +\fIlinpol\fP, and \fIslitpic\fP. The \fIimedit\fP, \fIimexamine\fP, and \fItvmark\fP tasks were moved to +the IMAGES.TV package. The \fIndprep\fP task was moved to ONEDSPEC. All other tasks +were moved to the PROTO package at the core level. +.IP \(bu +Two new tasks called \fIfindgain\fP and \fIfindthresh\fP were added to this package. +\fIfindgain\fP determines the gain and read noise of a CCD from a pair of dome +flats and from a pair of bias/zero frames using the Janesick method. +\fIfindthresh\fP estimates the background noise level of the CCD using a sky +frame and the gain and readnoise of the CCD. +.IP \(bu +A new task called \fIlinpol\fP has been added to the PROTO package. This task +calculates the pixel-by-pixel fractional linear polarization +and polarization angle for three or four images. The polarizer must be +set at even multiples of a 45 degree position angle. +.IP \(bu +The task \fIndprep\fP used for CTIO 2DFRUTTI reductions was moved to the +ONEDSPEC package. +.IP \(bu +The task \fItoonedspec\fP was removed since its function can now be performed +by the \fIonedspec.scopy\fP task. +.NH 3 +ONEDSPEC package reductions +.PP +There have been significant changes to the ONEDSPEC package. +A more detailed revisions summary is available +in the IRAF network archive as file \f(CWonedv210.ps.Z\fP in the +subdirectory \f(CWiraf/docs\fP. +.PP +The new package supports a variety of spectral image formats. The older +formats can still be read. In particular the one +dimensional "onedspec" and the two dimensional "multispec" format will +still be acceptable as input. Note that the image naming syntax for the +"onedspec" format using record number extensions is a separate issue and is +still provided but only in the IMRED.IIDS and IMRED.IRS packages. Any new +spectra created are either a one dimensional format using relatively simple +keywords and a two or three dimensional format which treats each line of +the image as a separate spectrum and uses a more complex world coordinate +system and keywords. For the sake of discussion the two formats are still +called "onedspec" and "multispec" though they are not equivalent to the +earlier formats. +.PP +In addition, the one dimensional spectral tasks may also operate on two +dimensional images. This is done by using the "dispaxis" keyword in the +image header or a package dispaxis parameter if the keyword is missing to +define the dispersion axis. In addition there is a summing parameter in +the package to allow summing a number of lines or columns. If the spectra +are wavelength calibrated long slit spectra, the product of the +\fIlongslit.transform\fP task, the wavelength information will also be properly +handled. Thus, one may use \fIsplot\fP or \fIspecplot\fP for plotting such data +without having to extract them to another format. If one wants to extract +one dimensional spectra by summing columns or lines, as opposed to using +the more complex APEXTRACT package, then one can simply use \fIscopy\fP (this +effectively replaces \fIproto.toonedspec\fP) +.PP +Another major change to the package is that spectra no +longer need to be interpolated to a uniform sampling in wavelength. The +dispersion functions determined by \fIidentify\fP/\fIreidentify\fP can now be carried along +with the spectra in the image headers and recognized throughout the package and +the IRAF core system. Thus the WCS has been fully implemented in the ONEDSPEC +tasks and although much is to be gained by this it can cause problems with +earlier IRAF systems as well as making it difficult to import data into +non-IRAF software. But it is now possible to use \fIimcopy\fP with an image section +on a spectrum, for instance, and have the wavelength information retained +correctly. +.PP +A sinc interpolator is now available +for those tasks doing geometric corrections or interpolations. This option +can be selected by setting the "interp" parameter in the ONEDSPEC package +parameters. +.PP +Other changes are summarized: +.IP \(bu +The new task \fIderedden\fP corrects input spectra for interstellar extinction, or +reddening. +.IP \(bu +The new task \fIdopcor\fP corrects input spectra by removing a specified doppler +velocity. The opposite sign can be used to add a doppler shift to a spectrum. +.IP \(bu +The new task \fIfitprofs\fP fits 1D gaussian profiles to spectral lines or +features in an image line or column. This is done noninteractively and +driven by an input list of feature positions. +.IP \(bu +The task \fIndprep\fP was moved to this package from the PROTO package. \fIndprep\fP +is used for CTIO \fI2DFRUTTI\fP reductions. +.IP \(bu +The new task \fIsapertures\fP adds or modifies beam numbers and +aperture titles for selected apertures based on an aperture +identification file. +.IP \(bu +The new task \fIsarith\fP does spectral arithmetic and includes unary operators. +The arithmetic can be performed on separate input spectra or on apertures +within a multispec format image. +.IP \(bu +The task \fIscombine\fP has been added to the package. This new task is similar +to the new \fIimcombine\fP task in the IMAGES package but is specialized for +spectral data. +.IP \(bu +The new task \fIscopy\fP copies subsets of apertures and does format +conversions between the different spectrum formats. +.IP \(bu +The new task \fIsfit\fP fits spectra and outputs the fits in various ways. +This includes a new feature to replace deviant points by the fit. +Apertures in multispec and echelle format are fit independently. +.IP \(bu +The tasks \fIaddsets\fP, \fIbatchred\fP, \fIbswitch\fP, \fIcoincor\fP, \fIflatdiv\fP, \fIflatfit\fP, \fIsubsets\fP +and \fIsums\fP were moved to the IIDS and IRS packages. +.IP \(bu +The task \fIcombine\fP was removed with the all new \fIscombine\fP suggested in its place. +.IP \(bu +The tasks \fIrebin\fP, \fIsflip\fP and \fIshedit\fP were removed from the package. +Rebinning of spectra can now be done with \fIscopy\fP or \fIdispcor\fP. \fIscopy\fP and \fIimcopy\fP +can now be used in place of \fIsflip\fP. And \fIhedit\fP is an alternative for \fIshedit\fP. +.IP \(bu +\fIbplot\fP and \fIslist\fP have been modified to support the multispec format. +.IP \(bu +The task \fIcontinuum\fP now does independent fits for multispec and +echelle format spectra. +.IP \(bu +There is now only one \fIdispcor\fP task doing the work of the three previous +tasks \fIdispcor\fP, \fImsdispcor\fP and \fIecdispcor\fP. Several of the parameters for this +task have been changed. The old "recformat" and "records" parameters for +supporting the old onedspec format have been removed except in the IIDS/IRS +packages. A "linearize" parameter has been added for setting the interpolation +to yes or no on output. The "interpolation" parameter was removed since this +information is now read from the package parameter "interp". The "ignoreaps" +parameter has been changed to "samedisp". +.IP \(bu +\fIidentify\fP and \fIreidentify\fP now treat multispec format spectra +and two dimensional images as a unit allowing easy movement between +different image lines or columns. The database is only updated upon +exiting the image. The "j", "k", and "o" keys have been added to the +interactive sessions to allow for scrolling through the different lines +in a two dimensional image. The database format now uses aperture numbers +rather than image sections for multispec format spectra. +.IP \(bu +The task \fIspecplot\fP has new parameters "apertures" and "bands" to select +spectra for plotting in the multispec format. +.IP \(bu +\fIsplot\fP now allows deblending of any number of components and +allows simultaneous fitting of a linear background. Several cursor keys +have been redefined and colon commands have been added to fully support +the new multispec format and to add even more flexibility to the task than +before! Please see the help pages for details. +.IP \(bu +The \fIreidentify\fP task is essentially a new task. The important changes +are an interactive review option, the ability to add features from +a line list, using the same reference spectrum for all other spectra in +a 2D reference image rather than "tracing" (using the results of the +last reidentification as the initial guess for the next one) across the +image, and matching image lines/columns/apertures from a 2D reference +image to other 2D images rather than "tracing" again. +.NH 3 +RV package added +.PP +This is a new package installed with IRAF version 2.10. A version of this +package, RV0, has been available as an add-on for the past year or so. The +package contains one main task \fIfxcor\fP that performs a Fourier +cross-correlation on the input list of spectra. The package supports the +multispec format. +.NH 3 +TWODSPEC package modifications +.PP +The old MULTISPEC package that has resided in the TWODSPEC package for +years has been disabled. The code is still there for browsing, however, and +the package can be resurrected easily if needed. +.PP +The \fIobservatory\fP task was moved to the NOAO package itself. The \fIsetairmass\fP +task was moved to LONGSLIT. And the \fIsetdisp\fP task is no longer needed; +task or package parameters are used in its place. +.PP +Changes to the APEXTRACT and LONGSLIT packages are summarized below. +.NH 3 +TWODSPEC.APEXTRACT package modifications +.PP +A new version, version 3, of the IRAF APEXTRACT package has been +completed. A detailed revisions summary is available in the IRAF +network archive (file \f(CWapexv210.ps.Z\fP in \f(CWiraf/docs\fP). +.PP +There were three goals for the new package: new and improved cleaning +and variance weighting (optimal extraction) algorithms, the addition of +recommended or desirable new tasks and algorithms (particularly to +support large numbers of spectra from fiber and aperture mask +instruments), and special support for the new image reduction scripts in +the various IMRED packages. +.PP +The multispec format, the default image format for all spectroscopic packages +except IIDS and IRS, is either 2D or 3D (the 3D format is new with this +release). +The 3D format is produced when the parameter "extras" is set to yes in the +extraction tasks. The basic 2D format, which applies to +the first plane of the 3D format, has each 1D aperture spectra extracted +in a line. Thus, the first coordinate is the pixel coordinate along the +spectra. The second coordinate refers to the separate apertures. The +third coordinate contains extra information associated with the spectrum +in the first plane. The extra planes are: +.DS L + 1: Primary spectra which are variance and/or cosmic ray cleaned + 2: Spectra which are not weighted or cleaned + 3: Sky spectra when using background subtraction + 4: Estimated sigma of the extracted spectra +.DE +If background subtraction is not done then 4 moves down to plane 3. +Thus: +.DS L + output.ms[*,*,1] = all primary spectra + output.ms[*,5,1] = 5th aperture spectrum which is cleaned + output.ms[*,5,2] = raw/uncleaned 5th aperture spectrum + output.ms[*,5,3] = sky for 5th spectrum + output.ms[*,5,4] = sigma of 5th spectrum +.DE +.LP +The following summarizes the major new features and changes. +.IP \(bu +New techniques for cleaning and variance weighting extracted spectra have +been implemented. +.IP \(bu +Special features for automatically numbering and identifying large +numbers of apertures have been added. +.IP \(bu +There is no longer a limit to the number of apertures that can be extracted. +.IP \(bu +The new task \fIapall\fP integrates all the parameters used for +one dimensional extraction of spectra. +.IP \(bu +The new task \fIapfit\fP provides various types of fitting for two dimensional +multiobject spectra. +.IP \(bu +The new task \fIapflatten\fP creates flat fields from fiber and slitlet +spectra. +.IP \(bu +The new task \fIapmask\fP creates mask images from aperture definitions using the +new pixel list image format. No tasks +have yet been written, however, to use this new mask image format. +.IP \(bu +The new tasks and algorithms, \fIaprecenter\fP and \fIapresize\fP, will +automatically recenter and resize aperture definitions. +.IP \(bu +The task \fIapio\fP is defunct. Its functionality has been replaced by the +APEXTRACT package parameters. +.IP \(bu +The task \fIapstrip\fP has been removed. +.IP \(bu +Minor changes have been made to the old "AP" tasks to accommodate these +new changes in the package; in some cases new parameters have been added to +the task and in other cases new cursor options have been implemented. See the +help pages for details. +.NH 3 +TWODSPEC.LONGSLIT package modifications +.IP \(bu +The "dispaxis" parameter was added to the package parameters. This value +is used unless DISPAXIS is in the image header. +.NH 3 +Glossary of new tasks in the NOAO packages +.sp 0.5 +\fR +.TS +center; +c c c c c +l c l c lw(4i). +Task Package Description +_ + +addstar - daophot - Add artificial stars to an image using the computed psf +allstar - daophot - Group and fit psf to multiple stars simultaneously +apall - apextract - Extract 1D spectra (all parameters in one task) +apfit - apextract - Fit 2D spectra and output the fit, difference, or ratio +apflatten - apextract - Remove overall spectral and profile shapes from flat fields +apmask - apextract - Create and IRAF pixel list mask of the apertures +aprecenter - apextract - Recenter apertures +apresize - apextract - Resize apertures +ccdinstrument - ccdred - Review and edit instrument translation files +centerpars - daophot - Edit the centering algorithm parameters +chkconfig - photcal - Check the configuration file for grammar and syntax errors +continpars - rv - Edit continuum subtraction parameters +daofind - daophot - Find stars in an image using the DAO algorithm +daopars - daophot - Edit the daophot algorithms parameter set +datapars - daophot - Edit the data dependent parameters +deredden - onedspec - Apply interstellar extinction correction +do3fiber - kpnocoude - Process KPNO coude three fiber spectra +doargus - argus - Process ARGUS spectra +doecslit - echelle - Process Echelle slit spectra +dofibers - specred - Process fiber spectra +dofoe - echelle - Process Fiber Optic Echelle (FOE) spectra +dohydra - hydra - Process HYDRA spectra +dopcor - onedspec - Apply doppler corrections +doslit - ctioslit - Process CTIO slit spectra +doslit - kpnocoude - Process KPNO coude slit spectra +doslit - kpnoslit - Process slit spectra +doslit - specred - Process slit spectra +evalfit - photcal - Compute the standard indices by evaluating the fit +filtpars - rv - Edit the filter function parameters +findgain - nproto - Estimate the gain and readnoise of a CCD +findthresh - nproto - Estimate a CCD's sky noise from the gain and readnoise +fitparams - photcal - Compute the parameters of the transformation equations +fitprofs - onedspec - Fit gaussian profiles +fitskypars - daophot - Edit the sky fitting algorithm parameters +fxcor - rv - Radial velocities via Fourier cross correlation +gratings - astutil - Compute and print grating parameters +group - daophot - Group stars based on positional overlap and signal/noise +grpselect - daophot - Select groups of a specified size from a daophot database +invertfit - photcal - Compute the standard indices by inverting the fit +istable - ptools - Is a file a table or text database file ? +linpol - nproto - Calculate polarization frames and Stoke's parameters +keywpars - rv - Translate the image header keywords used in RV package +mkcatalog - photcal - Type in a standard star catalog or observations file +mkconfig - photcal - Prepare a configuration file +mkechelle - artdata - Make artificial 1D and 2D echelle spectra +mkexamples - artdata - Make artificial data examples +mkheader - artdata - Append/replace header parameters +mkimsets - photcal - Prepare an image set file for input to (mk)(n)obsfile +mk(n)obsfile - photcal - T{ +Prepare a single (multi)-starfield observations file from apphot/daophot output +T} +mkphotcors - photcal - T{ +Type in/check any photometric corrections files required by mk(n)obsfile +T} +msresp1d - argus - Create 1D response spectra from flat field and sky spectra +msresp1d - hydra - Create 1D response spectra from flat field and sky spectra +msresp1d - kpnocoude - Create fiber response spectra from flat field and sky spectra +msresp1d - specred - Create 1D response spectra from flat field and sky spectra +nstar - daophot - Fit the psf to groups of stars simultaneously +obsfile - photcal - T{ +Prepare a single (multi)-starfield observations file from a user-created text file +T} +pappend - daophot - Concatenate a list of daophot databases +pappend - ptools - Concatenate a list of apphot/daophot databases +pconvert - daophot - Convert a text database to a tables database +pconvert - ptools - Convert from an apphot/daophot text to tables database +pdump - daophot - Print selected fields from a list of daophot databases +pdump - ptools - Print selected columns of a list of daophot/apphot databases +peak - daophot - Fit the psf to single stars +pexamine - apphot - Interactively examine or edit an apphot output file +pexamine - daophot - Interactively examine and edit a daophot database +pexamine - ptools - Interactively examine and edit an apphot/daophot database +phot - daophot - Compute sky values and initial magnitudes for a list of stars +photpars - daophot - Edit the photometry parameters +prenumber - daophot - Renumber stars in a daophot database +prenumber - ptools - Renumber a list of apphot/daophot databases +pselect - daophot - Select records from a daophot database +pselect - ptools - Select records from a list of apphot/daophot databases +psf - daophot - Fit the point spread function +psort - daophot - Sort a daophot database +psort - ptools - Sort a list of apphot/daophot databases +sapertures - onedspec - Set or change aperture header information +sarith - onedspec - Spectrum arithmetic +scombine - onedspec - Combine spectra having different wavelength ranges +scopy - onedspec - Select and copy apertures in different spectral formats +seepsf - daophot - Compute an image of the point spread function +setjd - astutil - Compute and set Julian dates in images +sfit - onedspec - Fit spectra and output fit, ratio, or difference +substar - daophot - Subtract the fitted stars from the original image +tbappend - ptools - Concatenate a list of apphot/daophot tables databases +tbdump - ptools - Print selected columns of a list of tables databases +tbrenumber - ptools - Renumber a list of apphot/daophot tables databases +tbselect - ptools - Select records from a list of apphot/daophot tables databases +tbsort - ptools - Sort a list of apphot/daophot tables databases +txappend - ptools - Concatenate a list of apphot/daophot text databases +txdump - apphot - Dump selected fields from an apphot output file +txdump - ptools - Print selected columns of a list of apphot/daophot text databases +txrenumber - ptools - Renumber a list of apphot/daophot text databases +txselect - ptools - Select records from a list of apphot/daophot text databases +txsort - ptools - Sort a list of apphot/daophot text databases +.TE + +.bp +.NH +Programming Environment Revisions + +.NH 2 +Compatibility Issues +.PP +V2.10 IRAF requires that any local IRAF programs external to the V2.10 +system (such as layered packages or locally written tasks) be \fIfully +recompiled\fR if they are relinked against V2.10. The problem arises only +if the programs are relinked; external programs will continue to run after +V2.10 is installed, but linker errors will be seen if the programs are +relinked without being fully recompiled. This is because the internal names +of some important system routines were changed in V2.10 to avoid name +clashes with host system routines. For example, the SPP procedure "rename" +is now translated to "xfrnam" when the SPP code it appears in is compiled. +.PP +As always, actual interface changes affecting existing source code were very +few. The macro "E" in \f(CW\fR was renamed to "BASE_E" to minimize +the chance of an accidental name collision. The calling sequence for the +\fIonentry\fR procedure (ETC) was changed, but since this is a little used +system procedure very few tasks should be affected. A number of new +procedures were added to MTIO and the syntax of a magtape device has +changed; old applications should be modified to use the MTIO procedures to +operate upon magtape device names. +.PP +These and other revisions affecting the programming environment +are discussed in more detail below. + +.NH 2 +Portability Issues +.PP +The V2.10 UNIX/IRAF kernel now includes "#ifdef SYSV" support for System V +UNIX, making it easier to port IRAF to SysV based systems. The UNIX/IRAF +HSI (host system interface) is still not as portable to UNIX variants as it +could be, but at this point it is easier for us to make the minor revisions +required for a new port than to further refine the HSI. The disadvantage is +that it is harder than it should be for people in the community to do their +own IRAF ports, due to the level of IRAF expertise required to tune the +code. Someday we plan to generate a generic-UNIX HSI. Note that these +comments pertain only to the few thousand lines of code in the HSI - the +bulk of the IRAF code is 100% portable (identical on all IRAF systems) as it +has always been. +.PP +The recent port of IRAF to A/UX (the Apple Macintosh UNIX) is interesting +from a portability standpoint because we used the publically available +Fortran to C translator \fIf2c\fR plus the GNU C compiler \fIgcc\fR to +compile all the SPP and Fortran code in IRAF. This was remarkably +successful and means that the IRAF code is now portable to any system with a +C compiler. In the process of performing these compilations a few dozen +minor bugs were found by the static compile time checking performed by +\fIf2c\fR and \fIgcc\fR. The IRAF C code was run through \fIgcc\fR with +ANSI mode enabled, and hence should now be ANSI-C compatible. The GNU +debugger \fIgdb\fR proved to be an effective tool for debugging of IRAF code +compiled with \fIgcc\fR. + +.NH 2 +Software Tools +.NH 3 +LOGIPC feature +.PP +A new facility has been added to UNIX/IRAF (all systems) for debugging +interprocess communication (IPC). This feature will also be useful for +debugging tasks standalone, particularly in cases where a bug seen when +running a task from the CL is difficult to reproduce when the task is run +standalone. The new facility allows one to carry out a normal IRAF session +while transparently logging all interprocess communications. Each process +can then be rerun individually using the logged IPC to exactly duplicate +the functioning of the process to, e.g., examine the program operation in +detail under a debugger. +.PP +The facility is this: if LOGIPC is defined in the host environment when an +iraf process is started, the process will create two files \fIpid\f(CW.in\fR +and \fIpid\f(CW.out\fR, where \fIpid\fR is the process id. Everything read +from the IPC input file is copied to the \f(CW.in\fR file, and everything +written to the IPC output (i.e., sent back to the CL) is copied to +the \f(CW.out\fR file. This is done only for connected subprocesses. +It will work for any connected subprocess, e.g., normal cached processes and +graphics subkernels in both foreground and background CLs, but not the i/o +of the CL itself since the CL is not driven by IPC. +.PP +The IPC streams saved are an exact binary copy of whatever was sent via IPC, +including the binary IPC packet headers, and binary graphics data, and so +on. All the IPC communications used to start up the process, run zero or +more tasks, and close the process down will be logged. Most IPC traffic is +textual in nature so it will usually be possible to examine the IPC files +with a file pager, although the results may be less than satisfactory if +binary data such as a graphics metacode stream is logged. It is not +necessary to examine the IPC files to use them for process execution or +debugging. +.PP +A particularly interesting use of this feature is to allow a process to be +run under the CL in the normal fashion, then rerun under a host level +debugger using the saved IPC input to duplicate the input and actions of the +process when run under the CL. For example, +.XS +% setenv LOGIPC +% cl +cl> dir +cl> logout +% unsetenv LOGIPC +.XE +will run the CL, saving the IPC of all subprocesses, e.g. \f(CWx_system.e\fR. +We can then run the system process manually, using the saved IPC input: +.XS +% $iraf/bin/x_system.e -c < \fIpid\fR.in +.XE +To run the process under \fIadb\fR or \fIdbx\fR, using the saved input: +.XS +% adb $iraf/bin/x_system.e +:r <\fIpid\fR.in -c +.XE +or +.XS +% dbx $iraf/bin/x_system.e +dbx> r -c < \fIpid\fR.in +.XE +Note that the redirection has to be given first for \fIadb\fR, and last for +\fIdbx\fR. This also works for \fIgdb\fR using the \fIrun\fR command. Some +implementations of \fIadb\fR are picky about syntax and will not allow a +space between the "<" and the process id in the :r command. +.PP +Running a task in this way is not identical to running the task standalone, +e.g. using a \fIdparam\fR file for parameter input, because the full +runtime context of the process as run under the CL is reproduced by LOGIPC +but not when the task is run standalone. The differences are subtle but can +be important when trying to reproduce a bug seen when the process is run +under the CL. It is often the case that a bug seen when a task is run +from the CL will disappear when the task is run standalone, but in most +cases LOGIPC will duplicate the bug. +.NH 3 +XC changes +.PP +The \fIxc\fR program (IRAF compiler-linker) underwent the following changes for +V2.10, in addition to the usual host-system specific changes required to +support new host compiler versions. +.PP +Multiple "-p pkgname" arguments are now supported. These are used when +compiling a module which uses multiple package environments, e.g., +.XS +cl> xc -p noao -p tables foo.x +.XE +Each package environment may define package environment variables, +directories to be searched for include files and libraries, and so on. +Package environments are used by the IRAF layered packages. +.PP +Host libraries named on the command line using the -l switch (e.g., +"-lresolv") are now searched after the IRAF system libraries, rather than +before as in previous versions of \fIxc\fR. If the host library is +referenced by absolute pathname it is still searched before the IRAF +libraries, since the command line order determines the search order. +.NH 3 +SPPLINT code checker +.PP +A static code checker utility \fIspplint\fR has been developed for checking +SPP programs. This uses the SPP translation utilities in IRAF to convert +SPP to Fortran, \fIf2c\fR to generate C code, and \fIlint\fR to check the C +code. The code is checked in various ways at all phases of translation. +Some of the most useful checking are performed by \fIf2c\fR, which checks +the number and type of arguments in all calls to IRAF VOS library +procedures. In other words, \fIspplint\fR will determine if an IRAF library +procedure is called incorrectly, as well as perform a variety of other +checks. +.PP +The \fIspplint\fR utility is not included in the main IRAF release, but is +available separately. Contact the IRAF project for information on the +availability of this and other optional code development utilities. +.NH 3 +Multiple architecture support +.PP +Multiple architecture support is a way of using multiple sets of compiled +program binaries within a single copy of IRAF. Multiple sets of binaries +are used to support different machine architectures (e.g. sparc and Motorola), +different compiler options (floating point options, vectorization options, +profiling options), different compilers, and so on. +.PP +The command for checking the architecture of the IRAF core system or a +layered package has been changed from \fIshowfloat\fR to \fIarch\fR to +reflect the fact that multiple architecture support is no longer used merely +to select the floating point option. +.XS +cl> mkpkg arch +sparc +.XE +The default architecture of the distributed system is "generic", meaning +no specific architecture has been set (the source tree is generic, not +configured for any particular architecture). +.PP +It is suggested that developers of layered software for IRAF adopt this +same convention in their root \fImkpkg\fR files. +.NH 3 +Package environments +.PP +All the HSI software utilities now permit multiple "-p pkgname" package +environment references. The host \f(CWPKGENV\fR environment variable now +also permits multiple package environments to be referenced, e.g. +.XS +% setenv PKGENV "noao tables xray" +.XE +The package names should be whitespace delimited (\f(CWPKGENV\fR is used to +avoid having to give the "-p" flags on the \fImkpkg\fR or \fIxc\fR command +line). To successfully load a package enironment, the package root +directory must be defined in \f(CWhlib$extern.pkg\fR or in the user's host +environment. A host environment definition will override the value given in +extern.pkg. +.NH 3 +Finding module sources +.PP +IRAF V2.10 includes a "tags" file in the IRAF root directory to aid software +development. This file contains an index to all procedures in the IRAF VOS +and HSI and can be used with host editors such as \fIvi\fR to rapidly find +and display the source for IRAF system procedures. Note that the names of +the kernel procedures are given in upper case, e.g., "ZOPNBF", whereas the +names of the VOS procedures are given in lower case. To use the tags file +with \fIvi\fR, start the editor at the IRAF root directory and while in the +editor, type a command such as ":ta foo" to view the source for procedure +\fIfoo\fR. + +.NH 2 +Programming Interface Changes +.NH 3 +IEEE floating support +.PP +Modifications were made to the IEEE floating conversion routines in the OSB +package to support NaN mapping. This is a low level package used by, e.g., +the MII package in ETC. The interface as it currently stands is summarized +below. +.XS + ieepak[rd] (datum) # pack scalar value + ieeupk[rd] (datum) # unpack scalar value + ieevpak[rd] (native, ieee, nelem) # pack vector + ieevupk[rd] (ieee, native, nelem) # unpack vector + iee[sg]nan[rd] (NaN) # set/get NaN value + ieemap[rd] (mapin, mapout) # enable/disable NaN mapping + ieestat[rd] (nin, nout) # get count of NaN values + ieezstat[rd] () # zero NaN counters +.XE +.PP +The new or modified routines are \fIieesnan\fR, \fIieegnan\fR, \fIieemap\fR, +\fIieestat\fR, and \fIieezstat\fR. By NaN (not-a-number) we refer +collectively to all IEEE non-arithmetic values, not just IEEE NaN. The +routines \fIieesnan\fR and \fIieegnan\fR set or get the native floating +value used to replace NaNs or overflows occurring when converting IEEE to the +native floating format (any floating value will do, e.g., zero or INDEF). +If NaN mapping is enabled, the \fIieestat\fR routines may be used to +determine the number of input or output NaN conversions occurring since the +last call to \fIieezstat\fR. Both real and double versions of all routines +are provided. +.PP +The NaN mapping enable switch and statistics counters are undefined at +process startup; programs which use the IEEE conversion package should call +\fIieemap\fR to enable or disable NaN mapping, and \fIieezstat\fR to +initialize the statistics counters. +.NH 3 +MATH libraries +.PP +The following changes were made to the MATH libraries in the IRAF core +system. Refer to the online help pages of the affected routines for +detailed information. +.RS +.IP \(bu +The one-dimensional image interpolation library \fBiminterp\fR was modified +to add support for sinc interpolation. +.IP \(bu +A new library \fBnlfit\fR was added for non-linear function fitting. +An interactive graphics front end to this was also added in XTOOLS. +.IP \(bu +The name of the symbol \f(CWE\fR in \f(CW\fR was changed to +\f(CWBASE_E\fR to minimize the chance of name clashes. +.RE +.NH 3 +CLIO interface +.PP +The CLIO (command language i/o) interface underwent the following changes +for version 2.10 IRAF. +.RS +.IP \(bu +A README file was added to the source directory containing an up to date +interface summary. +.IP \(bu +The routines \fIclgpset\fR and \fIclppset\fR (get/put string valued +parameter) were renamed \fIclgpseta\fR and \fIclppseta\fR. The old +procedures were retained for compatibility but are now obsolete and may at +some point in the future disappear or be reused for some other function. +.IP \(bu +Two new routines \fIcllpset\fR and \fIclepset\fR were added for listing +and editing psets (parameter sets). +.RE +.LP +The calling sequences for the new pset routines are as follows. +.XS +cllpset (pp, fd, format) # list pset +clepset (pp) # edit pset +.XE +These new routines are still considered experimental and should be avoided +or used with caution (they could change). +.PP +Internal to the CLIO code, the CLIO parameter caching package underwent +minor changes to add a new \fIclc_compress\fR routine and improve pset +handling, as part of the minilanguage support effort. +.RE +.NH 3 +ETC interface +.PP +The ETC interface contains miscellaneous system interface routines. +The ETC interface underwent the following changes for V2.10 IRAF. +.NH 4 +Calling sequence for onentry changed +.PP +The calling sequence for the \fIonentry\fR routine was changed. The new +calling sequence is as follows. +.XS + action = onentry (prtype, bkgfile, cmd) +.XE +The \fIonentry\fR procedure is an optional procedure which is called when an +IRAF process starts up. Normally the onentry procedure is a no-op, passing +control to the IRAF main in-task interpreter. Custom IRAF applications, +e.g., the CL, have a special \fIonentry\fR procedure which replaces the +default in-task interpreter. +.PP +The change made to the \fIonentry\fR calling sequence was the addition of +the additional argument \fIcmd\fR. This argument receives the command line +used to invoke the IRAF process at the host level. The application can +parse this command line to extract arguments, allowing the IRAF process to +operate as a host program (it is already possible to call any IRAF task from +the host level, but use of an \fIonentry\fR procedure allows the in-task +interpreter to be bypassed and gives the application control over parsing +the command line). +.PP +See \f(CWetc$onentry.x\fR for additional information on how to use this +procedure. +.NH 4 +New onerror and onexit procedures +.PP +Two new procedures \fIonerror_remove\fR and \fIonexit_remove\fR were added. +These have the following calling sequences. +.XS + onerror_remove (proc) # remove posted onerror procedure + onexit_remove (proc) # remove posted onexit procedure +.XE +The new routines are used to remove \fIonerror\fR or \fIonexit\fR procedures +posted by a task during task execution. Such user procedures are called +if the task aborts (\fIonerror\fR procedures) or during normal task exit +(\fIonexit\fR procedures). Formerly there was no way to "unpost" the +procedures other than by the normal cleanup occurring during task termination. +.NH 4 +New gqsort routine +.PP +A new quick-sort routine \fIgqsort\fR (generalized quick sort) was added. +This has the following calling sequence. +.XS + gqsort (x, nelem, compare, client_data) +.XE +\fIgqsort\fR is identical to the old \fIqsort\fR routine except for the +addition of the fourth argument \fIclient_data\fR. This is an integer value +which is passed on to the \fIcompare\fR procedure during sorting to compare +two data values. The \fIcompare\fR routine is called as follows. +.XS + result = compare (client_data, x1, x2) +.XE +The new routine eliminates the need to use a common area to pass information +to the compare routine, as was often necessary with \fIqsort\fR. +.NH 3 +FIO interface +.PP +The FIO interface (file i/o) underwent minor changes to fix some bugs +affecting pushed back data. The \f(CWF_UNREAD\fR file status parameter +will now correctly report pushed back data as well as any buffered +input file data. The \f(CWF_CANCEL\fR file set option will now cancel +any pushed back data. +.NH 4 +Nonblocking terminal i/o +.PP +A new nonblocking form of raw mode terminal input has been added. This +permits polling the terminal for input without blocking (suspending process +execution) if no input is available. In a character read, EOF is returned +if no input is available otherwise the character value is returned. +An example illustrating the use of nonblocking terminal i/o follows. +.XS +include + +task foo + +procedure foo() +.sp 0.5v +int fd, ch +int getci() +.sp 0.5v +begin + fd = STDIN + call fseti (fd, F_IOMODE, IO_RAW+IO_NDELAY) +.sp 0.5v + repeat { + if (getci(fd,ch) == EOF) + call printf ("no pending input\\\\r\\\\n") + else { + call printf ("ch = %03o\\\\r\\\\n") + call pargi (ch) + } + call sleep (1) + } until (ch == '\\\\004' || ch == 'q') +.sp 0.5v + call fseti (fd, F_IOMODE, IO_NORMAL) +end +.XE +.PP +This sample program sets the terminal i/o mode to nonblocking raw mode and +polls the terminal once per second, printing the character value in octal if +a character is typed on the terminal, exiting when ctrl/d or 'q' is typed. +Note that in raw mode characters such as ctrl/d or ctrl/c are passed through +as data and do not get mapped to EOF, generate an interrupt, and so on. +Raw mode i/o such as this will work both when running a task under the CL +and standalone, and in combination with IRAF networking (e.g. to access a +remote device). +.PP +Nonblocking terminal input is used in applications which run continuously +but which we wish to be able to control interactively. +.NH 3 +FMTIO interface +.PP +The FMTIO interface (formatted i/o) is used to format output text or decode +input text. The V2.10 release adds two new \fIprintf\fR output formats, +\f(CW%H\fR and \f(CW%M\fR. These are used to print numbers in +hours-minutes-seconds or minutes-seconds format and are equivalent to the +older output formats \f(CW%h\fR and \f(CW%m\fR except that the number is +first divided by 15. This converts degrees to hours allowing values given +in units of degrees to be printed as hours with just a change of the output +format. In other words, given a number N in units of degrees, \f(CW%H\fR +would print the number in hours-minutes-seconds, i.e., "hh:mm:ss.ss", +whereas \f(CW%h\fR would print the same number as degrees-minutes-seconds, +"dd:mm:ss.ss". The \f(CW%m\fR formats are similar except that only two of +the three fields are printed. +.NH 3 +GTY interface +.PP +The GTY interface is a generalized version of that portion of the older TTY +interface dealing with termcap format files. The TTY code which accesses +termcap format files has been extracted to form the new GTY interface, +allowing arbitrary termcap format files to be accessed by filename, unlike +TTY which returns TTY descriptors given the termcap or graphcap device +name. GTY was contributed by Skip Schaller of Steward Observatory. +.XS + gty = gtyopen (termcap_file, device, ufields) + gtyclose (gty) + cp = gtycaps (gty) + pval = gtyget[bir] (gty, cap) + nchars = gtygets (gty, cap, outstr, maxch) +.XE +.PP +The \fIgtyopen\fR call returns the GTY descriptor for the named \fIdevice\fR +from the file \fItermcap_file\fR. The \fIufields\fR string may be either +NULL or a list of colon-delimited device capabilities, which will override +the corresponding capabilities in the device entry given in the termcap +file. If \fItermcap_file\fR is the null string \fIufields\fR is taken to be +the device entry for the named device. The \fIgtycaps\fR routine may be +used to get the entire device entry as a string, whereas the \fIgtyget\fR +and \fIgtygets\fR routines are used to get the values of individual +capabilities or parameters. +.NH 3 +MTIO interface +.PP +MTIO is the magtape i/o interface. The magtape i/o subsystem was +extensively revised for V2.10 IRAF, as documented earlier in this revisions +summary. The VOS level MTIO interface itself was not changed other than to +add a few new routines. The \fItapecap\fR facility is new in V2.10. The +revisions to the host level magtape driver ZFIOMT required that the +calling sequences of some of the interface routines be changed. +.NH 4 +MTIO applications programming interface +.PP +The current MTIO applications programming interface is summarized below. +Most of these routines are new: the old routines are \fImtfile\fR, +\fImtopen\fR, \fImtrewind\fR and \fImtposition\fR. +.XS + yes|no = mtfile (fname) +yes|no = mtneedfileno (mtname) + gty = mtcap (mtname) + mtfname (mtname, file, outstr, maxch) +.sp 0.5v + mtparse (mtname, device, fileno, recno, attrl, maxch) + mtencode (mtname, maxch, device, fileno, recno, attrl) +.sp 0.5v + fd = mtopen (mtname, acmode, bufsize) + mtrewind (mtname, initcache) + mtposition (mtname, file, record) +.XE +.PP +The \fImtfile\fR routine is used to test whether the given filename is a +magtape file or something else, i.e., a disk file. \fImtneedfileno\fR +tests whether a file number has been specified in \fImtname\fR (e.g., +to determine whether or not to query for a file number parameter). +\fImtfname\fR takes \fImtname\fR and a file number and constructs a new +magtape device name in the output string. \fImtparse\fR parses a magtape +device name into its component parts, and \fImtencode\fR does the reverse. +\fImtcap\fR returns the GTY descriptor of the tapecap entry for the device. +\fIgtyclose\fR should be used to free this descriptor when it is no longer +needed. +.PP +Some older magtape applications programs parse the magtape device name +directly, looking for characters like `['. These old programs are making +assumptions about the form of a magtape device name which are probably +no longer true. Such old applications should be rewritten to use the +new MTIO procedures for all magtape device name operations. +.NH 4 +MTIO system procedures +.PP +The MTIO interface also includes a number of procedures intended for use +in systems code. These are summarized in the table below. +.XS + mtallocate (mtname) + mtdeallocate (mtname, rewind_tape) + mtstatus (out, mtname) + mtclean (level, stale, out) +.XE +.PP +The only new routine here is \fImtclean\fR. This is called by the +\fImtclean\fR task in the V2.10 SYSTEM package and is used to scan the +magtape status file storage area to delete old magtape position status +files. Prior to V2.10 these files were stored in the user's UPARM +directory, but in V2.10 the files are stored in \f(CW/tmp\fR so that +multiple IRAF sessions will share the same tape position information. A +special task is needed to delete old position files in order to protect +against, e.g., one user deleting another user's device position file while +the device is actively in use. +.NH 4 +Magtape driver procedures +.PP +All access to the physical magtape device is via the host level IRAF magtape +device driver ZFIOMT. The driver procedures had to be revised for +V2.10 to add support for the tapecap facility and to accommodate changes in +the way the device position is maintained. The new driver procedures are +summarized below. +.XS + zzopmt (device, acmode, devcap, devpos, newfile, chan) + zzrdmt (chan, buf, maxbytes, offset) + zzwrmt (chan, buf, nbytes, offset) + zzwtmt (chan, devpos, status) + zzstmt (chan, param, value) + zzclmt (chan, devpos, status) + zzrwmt (device, devcap, status) +.XE +.PP +The corresponding KI (kernel interface) routines were also modified to +reflect the new calling sequences. A result of this is that IRAF networking +for magtape devices is incompatible between V2.10 and earlier versions of +IRAF. +.PP +The host level device driver procedures are not normally called directly +in applications code (applications use \fImtopen\fR). Refer to the comments +in the source file \f(CWos$zfiomt.c\fR for additional details. +.NH 3 +MWCS interface +.PP +The MWCS interface provides world coordinate system support for the IRAF +system and applications. The main changes in the MWCS interface for V2.10 +were bug fixes and semantic changes, e.g. various restrictions having to do +with WCS attributes were removed, new function drivers were added, and so +on. These changes are documented elsewhere in this revisions summary. +.PP +The only interface change affecting MWCS was the addition of the new MWCS +procedure \fImw_show\fR. +.XS + mw_show (mw, fd, what) +.XE +.PP +This is used to dump a MWCS descriptor to the given output file, and is +useful for examining MWCS descriptors while debugging applications. + +.NH +Getting Copies of this Revisions Summary +.PP +Additional copies of this revisions summary are available via anonymous ftp +from node \f(CWiraf.noao.edu\fR in the directory \f(CWiraf/v210\fR, or via +email from \f(CWiraf@noao.edu\fR. diff --git a/doc/v211revs.hlp b/doc/v211revs.hlp new file mode 100644 index 00000000..1407df06 --- /dev/null +++ b/doc/v211revs.hlp @@ -0,0 +1,1199 @@ +.help IRAF Aug97 "V2.11EXPORT Release Notes" +.sp 1 +.ce +IRAF V2.11EXPORT Release Notes +.ce +August 27, 1997 + + +Modifications and additions to IRAF V2.11EXPORT, compiled since the last +documented release of IRAF, V2.10.3, are summarized below. V2.11EXPORT is +a major release of IRAF and will be available for all supported platforms. +These release notes provide a summary of the major changes in V2.11. More +detailed technical documentation of all system changes will be found in the +notes.v210 and notes.v211 files in the iraf$doc and iraf$local directories. + +.nf + 1. \fBThings to be aware of or watch out for\fR + 1.1. Parameter file changes + 1.2. Networking change + 1.3. Image format change + 1.4. FITS kernel + 1.5. RFITS/\fIwfits\fR changes + 1.6. Merged SunOS and Solaris IRAF systems + 1.7. Tape access + 1.8. Default magnitude zero changed + + 2. \fBIMAGES package changes\fR + + 3. \fBMajor system changes\fR + 3.1. New FITS image kernel (FXF) + 3.2. Changes to the IRAF native image format (OIF) + 3.3. IMFORT changes + 3.4. Environment variables + 3.5. New intrinsic functions + 3.6. System default modifications + 3.7. Libraries added + 3.8. Graphics changes + 3.9. FITS-related core-level task changes + 3.10. General changes + + 4. \fBNew tasks, or old tasks moved to new packages\fR + + 5. \fBTask and package deletions\fR + + 6. \fBModifications to old tasks\fR + + 7. \fBParameter file changes\fR +.fi +.nh +Things to be aware of or watch out for +.nh 2 +Parameter file changes + +Since this is a major release we recommend that you do a \fImkiraf\fR and +delete all your old parameter files. You may choose not to do this if you +are in the midst of a project and have setups that may be difficult to +reproduce. Old IMAGES package parameter files will no longer be recognized, +however, because of the package reorganization mentioned below. Generally, +old parameter files are merged automatically with any new parameter files +if there have been any changes, but if you do have problems you will need +to \fIunlearn\fR the task before you can proceed. A list of the parameter +file changes appears below and you may wish to check this list to see how +this will affect your setups. + +The automatic parameter file update/merge mechanism, which is used if you +do not initialize your parameters with \fImkiraf\fR, is based on file date +comparisons. If you run IRAF V2.10 after V2.11 has been installed, the +file dates on your uparm parameter files will be more recent than the +V2.11 installation date. If you then try to run V2.11, the automatic +parameter file merge/update will fail due to the file dates. The system +only updates personal parameter files which are older than the update date +of the system. A \fImkiraf\fR avoids the problem if you delete your +parameter files, causing them to be updated from the system default +versions. +.nh 2 +Networking change + +The "set node = foo" syntax, used to enable remote image display under +IRAF networking, has changed. The new syntax requires that an exclamation +be appended to the node name as in the example below (this dates back to +V2.10.4 so many users will already be familiar with the feature). +.nf + + cl> set node = "orion!" +.fi +.nh 2 +Image format change + +The internal IRAF image format (.imh images) has changed. V2.11EXPORT +can read the old image format but the new image format is not readable by +V2.10.4 or earlier versions. This means that you can not easily go from +the new IRAF system (V2.11) to an old one (V2.10.4 or earlier) unless you +first convert the V2.11 IRAF images to FITS files. All your old V2.10.4 +or earlier images are readable by V2.11EXPORT. The benefit is that the +new image format is machine independent, slightly more storage efficient, +and supports long file pathnames. If it is necessary to be able to read +images written by V2.11 with older software, V2.11 can be made to write +the old IRAF image format by setting the \fIoifversion\fR environment +variable, e.g., "set oifversion = 1" (the default is version 2). See +below for details. +.nh 2 +FITS kernel + +A FITS image kernel is available in V2.11, allowing runtime read and write +access to FITS files on disk. There are many related changes to IRAF +image i/o and FITS support. More information on the new image kernel, +and on the expanded FITS support available in V2.11, is given below. +.nh 2 +RFITS/WFITS changes + +\fIrfits\fR and \fIwfits\fR have been modified to support multi-extension +FITS files. The extension numbering convention used is the same as in +the FITS image kernel. As a result, users who read simple FITS files on +disk with a command such as "rfits diskfilename 1 foo" will find that +this no longer works - instead use "rfits diskfilename 0 foo". See below +for details. +.nh 2 +Merged SunOS and Solaris IRAF systems + +A single installation of Sun/IRAF will now simultaneously support both +SunOS and Solaris (previously separate IRAF distributions were required +for each). +.nh 2 +Tape access + +The "tapecap" mechanism has changed. The system now looks for the filename +"tapecap." followed by the default "tapecap". : should be +the hostname (as used by IRAF networking) of the server hosting the tape +drives described by the tapecap file. For example if host "gemini" serves +up some tape drives it's tapecap file is named "tapecap.gemini". If a +server-specific tapecap file is not found the default "tapecap" (on the +possibly remote server node) is used. This feature allows a single IRAF +installation to be shared by multiple servers. +.nh 2 +Default magnitude zero changed + +The default APPHOT magnitude zero point has been changed from 26.0 to 25.0 +to bring it into agreement with the DAOPHOT package default value and +thereby avoid confusion for users who switch back and forth between +packages. The affected APPHOT tasks are \fIphot\fR, \fIphotpars\fR, +\fIpolypars\fR, \fIpolyphot\fR, \fIqphot\fR, \fIradprof\fR, and \fIwphot\fR. +The APPHOTX package in the addon DIGIPHOTX package will retain the old +zero point values until IRAF 2.11 is released after which they will be +updated. + +The default value of the magzero parameter in \fIimexamine\fR was changed +from 30.0 to 25.0 for consistency with the DIGIPHOT package. +.nh +IMAGES package changes + +The IMAGES package has been reorganized by function into the 7 subpackages +listed below. +.nf + + imcoords - Image coordinates package + imfilter - Image filtering package + imfit - Image fitting package + imgeom - Image geometric transformation package + immatch - Image matching and combining package + imutil - Image utilities package + tv - Image display utilities package + +.fi +The new IMAGES package contains a total of 82 tasks, including 26 new tasks +from the IMMATCH and VOL external addon packages, 6 existing PROTO package +tasks, and 1 existing NOAO.PROTO package task. The undocumented IMAGES +package IMDEBUG and its 6 tasks have been deleted from the IMAGES package. +User should use the tasks in the ARTDATA package instead. + +This reorganization of the IMAGES package should be mostly transparent to +the user and not affect any existing scripts, unless you were using any of +the 6 deleted tasks. By default, the IMAGES subpackages are automatically +loaded when you log in to the CL. Old parameter files will not be recognized +since the package names have changed. +.nh +Major system changes +.nh 2 +New FITS image kernel (FXF) + +V2.11 introduces a new image kernel providing runtime access to FITS +multi-extension image datafiles. What this means is that IRAF tasks +can now read and write FITS images directly at runtime. The native IRAF +image format (used by images with the .imh extension), remains the +default as it is the most efficient and well-tested format. IMH, FITS, +and the other types of images supported by IRAF can be used +interchangeably in most IRAF tasks. Although we have extensively tested +the new FITS image kernel, it is still evolving, is complex, and still +has some bugs. Users should use it with caution. Please let us know of +any problems. + +Besides support for classical FITS images, the new FITS kernel also +supports multi-extension FITS files: several FITS files packed into one +large file with a PHU (Primary Header Unit) that contains global header +information shared by the other files. Multi-extension FITS files are +0-indexed, with the PHU being 0 and the first image extension (or other +data extension) at index 1. If there is no PHU then the first FITS +image is 0 and there is no global header. + +For further details about the FITS kernel please see the new FITS Kernel +User's Guide by Nelson Zarate. +.nh 2 +Changes to the IRAF native image format (OIF) + +.nf + o It was necessary to change the IRAF image format to increase the + maximum path length for header and pixel files. This made it necessary + to change the disk image format, since the old format only allowed 80 + characters for the pixel file pathname. The path lengths can now be up + to 255 characters. + + Support for two versions of the image and pixel file headers was added. + V2.11 will read both the old image format (V1) and the new image format + (V2). But the new image format is not readable by older versions of IRAF. + + o Native format IRAF images (OIF type or extension ".imh") are now machine + independent, for example, a PC and a Sun can now access the same images. + + o Support was added for byte swapping pixels. With the machine independent + image header, this allows .imh images to be read on any node (integer) + or any IEEE-compatible node (floating). + + o Some pointers: "strings foo.imh" (or other tools like the "less" file + viewer) can be used at the Unix level to look at the text contained in + the new V2 OIF image headers. +.fi +.nh 2 +IMFORT changes + +.nf + o IMFORT was brought up to date to read and write the new V2 ".imh" images. + The old V1 format is still supported but new images are written using + the new machine independent V2 format by default. + + o Image headers can now be any size (the old IMFORT had a fixed, relatively + low, limit on the image header size). + + o The "min_lenuserarea" variable is now supported by IMFORT (since IMFORT + is host level the variable must be defined in the host environment). + The builtin default header buffer is 64000 chars, which is about 800 + card images. +.fi +.nh 2 +Environment variables + +Several new environment variable have been added to the system. + +.nf + o The new environment variable \fIimextn\fR determines the image kernels + (image file formats) recognized by IRAF and defines the mapping of + imagefile extensions to these image formats. A file that does not have + an extension listed in imextn may not be recognized as an image by all + IRAF tasks. The default value of imextn is as follows: + + imextn = "oif:imh fxf:fits,fit plf:pl qpf:qp stf:hhh,??h" + + IRAF tasks will not recognize a file as an image unless it has an + extension (except \fIrfits\fR which will read FITS files on disk that + have no extensions). The \fIrename\fR task can be used to add + extensions to image files if needed. "imextn" can be redefined (use + reset imextn = "new-value") to modify the mapping of extensions to + image types. + + The meaning of the fields of the default "imextn" are as follows. Each + substring corresponds to a single kernel. The "xxx:" is the internal + name of the image kernel, i.e. "oif", "fxf", "plf", etc. A comma + delimited list of the extensions, or extension patterns, associated with + that image format follows the colon. For example, for the FITS image + kernel, the internal kernel name is "fxf" and the system default file + extensions are ".fits" and ".fit". + + - oif:imh - The original (native) IRAF image format. + + - fxf:fits,fit - The FITS image extension format, which supports + classical FITS images as well as multi-extension FITS files. + + - plf:pl - The pixel list format used for compressed pixel masks. + + - qpf:qp - The QPOE image format for event list data (typically + X-ray or other high energy data). + + - stf:hhh,??h - The Space Telescope runtime GEIS image format. + + Users can define extensions for the fxf and stf kernels. For example, + if you have FITS files on disk that have a .ft extension then you can + reset imextn so that IRAF will recognize these image extensions: + + cl> reset imextn="fxf:ft" + + The new .ft extension for the FITS kernel images will now override the + default values - the other kernels remain unchanged. ".fits" will no + longer be recognized as a FITS file unless you include it in the list + of extensions for the "fxf" kernel. + + The first extension given for a kernel defines the default file + extension for new images of that type (rather than e.g. the value of + imtype, or a builtin default). + + The value of "imextn" is only read once when a process starts up. Hence + it is advisable to do a "flpr" (flush process cache) after changing + this variable, to force all processes to re-read it. + + o The environment variable \fIimtype\fR defines the default image type for + new images created by IRAF. If a file extension is given explicitly + when creating a new image then this file extension, in combination with + the "imextn" mappings, determines the type of the new image. Otherwise + the type is determined by the value of "imtype". Typical values are + "imh" for native IRAF images, or "fits" for FITS images. The internal + kernel name documented above for "imextn" can be used instead of a file + extension to ensure that the desired image format is used regardless of + what extensions are assigned to that type by imextn. + + The default value of imtype is "oif,noinherit" which means that the + IRAF native format is the default for all new images, regardless of the + type of the input image (i.e. do not "inherit" the input image type). + "inherit" was the default in V2.10 and earlier versions of IRAF. + + For example, if you wish to use FITS as the default for new images you + can set imtype=fits as follows: + + cl> reset imtype="fits" + cl> flpr % needed before the next task execution + + Assuming "imextn" defines ".fits" as a valid file extension for FITS + imagefiles (kernel "fxf"), all new images produced by IRAF will be FITS + files with the extension .fits unless some other extension is given + explicitly when creating a new image. + + cl> reset imtype = "imh,inherit" + + This example sets the default type for new images to ".imh" for native + format images, but enables image type inheritance. By default new + images will be of the same type as the input image. For example if a + FITS image is being read another FITS image will be output, or if a + pixel mask is being read a pixel mask will be created. + + You can override the default output image type specified by imtype by + giving an image extension (as defined by imextn) explicitly in the image + name, e.g. "pix.imh", "pix.fits", "pix.pl" and so on. + + o A new environment variable called \fIimclobber\fR has been added. + The default value is set to no. If imclobber is set to yes, images + can and will be overwritten, without warning, when you create new + images. + + o The original IRAF image format (OIF) kernel now supports an environment + variable \fIoifversion\fR which, if defined, specifies the file + version for new OIF images (for example, oifversion=2 produces the + new format, or version 2 images). By default the variable is undefined, + the builtin OIF default will be in effect, and new-format images will + be generated. This variable is provided only for backwards + compatibility, e.g., when using V2.11 IRAF with old software which + cannot easily be updated. +.fi +.nh 2 +New intrinsic functions + +Two new intrinsic functions were added to the CL, \fIimaccess\fR and +\fIdefvar\fR. \fIimaccess\fR tests whether an image exists, e.g., +(imaccess("dev$pix")) or (imaccess(foo.fits[3])). \fIdefvar\fR tests +whether an environment variable exists, e.g. (defvar("imextn")). +.nh 2 +System default modifications +.nf + + o The default size of the user area (\fImin_lenuserarea\fR) was increased + to 64000 (about 800 80 character cards). There was some ambiguity about + units for min_lenuserarea; it should be consistently characters now. + + o The maximum number of open IRAF logical files was increased from 128 to + 256. This is good news for \fIimcombine\fR users. + + o Various buffer limits were increased: + + - The IRAF line length was increased from 161 to 1023 characters. + One often ran into this lower limit when entering a long list of + input image names, for example. + + - CL commands can now be 2047 characters long (the old limit was + 1024) - this is particularly useful for scripts. + + - IRAF file names can now be up to 255 characters long. + + - Expanded file names (pathnames) can be up to 511 characters long. +.fi +.nh 2 +Libraries added + +The Starlink positional astronomy library SLALIB was added to the math +package. +.nh 2 +Graphics changes +.nf + + o SGI Translator change: Modified the header ID string produced by + sgi2uapl to be "%!PS", this is required by certain models of printers. + + o Installed graphcap support for the STSDAS PostScript graphics kernel. + + o The SGI graphics kernel was upgraded with a better roman font, and a + new greek font was added. To use the new high-quality greek fonts use + the "\fG" escape sequence when you use the "T" keystroke to mark text + in a plot, e.g., \fGa \fRHydra would produce " Hydra". The greek font + may also be used in label parameters for tasks like GRAPH, for example + + cl> graph dev$pix xlabel="Wavelength\\fG(A)" + + would produce an Angstrom symbol in parenthesis. The double backslash + is necessary to pass the escape string thru the CL. A file containing + the mappings for the greek fonts and other special characters can be + found at http://iraf.noao.edu/greek.ps. +.fi +.nh 2 +FITS-related core-level task changes +.nh 3 +IMHEADER + +The behavior of \fIimheader\fR has changed a bit - typed with no arguments +it will list all the images in the current directory, as in the following +example: + +.nf + cl> imhead + pix4.imh[512,512][short]: m51 B 600s + boc.fits: FXF: must specify which FITS extension (boc.fits) + fits.fits[512,512][short]: m51 B 600s + pix.fits[512,512][short]: m51 B 600s + pix3.fits[512,512][short]: m51 B 600s + pix5.fits: FXF: must specify which FITS extension (pix5.fits) + zero.fits: FXF: must specify which FITS extension (zero.fits) + mask.pl[512,512][int]: m51 B 600s + foo.qp[1024,811][int]: +.fi + +The multi-extensions FITS files show up in the list with the message +"FXF: must specify which FITS extension", since these files contain +multiple images and the task does not know which image to open to get +header information. + +At present imheader does not use "imextn" to determine what is and is +not an image. The parameter "imlist" defines the valid imagefile +extensions. If imextn is modified "imlist" may need to be modified as +well. +.nh 3 +RENAME + +The \fIrename\fR task was modified to allow a destination directory to be +specified without changing the filename. A new "field" parameter option +"all" was added and made the default so the entire filename is changed +(or moved in the case of a destination directory). When field is set +to "extn" filenames without an extension will not have the new extension +appended so a filename isn't generated which can get overwritten. +.nh 3 +\fIrfits\fR/\fIwfits\fR + +Some changes were also implemented in \fIrfits\fR and \fIwfits\fR to add support +for multi-extension FITS files. + +.nf + o The default action of \fIwfits\fR when writing to tape is unchanged for + single image files. + + \fIwfits\fR now has a new parameter called "fextn" and it is set to + "fits". This parameter only affects FITS files written by \fIwfits\fR + to disk - the extension .fits will automatically be added to the + filenames, so that the files will be automatically recognized by + the FITS image kernel. + + \fIwfits\fR also has two additional parameters called "extensions" and + "global_hdr" that deal with writing multi-extension FITS files. + + o The default action of \fIrfits\fR from tape to disk remains unchanged. + + If \fIrfits\fR is used to read FITS files on disk then users need to + be aware of a change to the behavior of the "file-list" parameter. + File-list is now used to define the list of files on the tape as + well as the list of extensions in a multi-extension FITS image. + To read single FITS images on disk use "" as the value for + "file-list". Some users have been using "1" for this value but now + that value will try to read the first extension which doesn't + exist - use "0" if you wish to put something there. + + \fIrfits\fR will unpack multi-extension FITS files upon a read. If you + wish to retain the multi-extension FITS format then use T2D and + RENAME. +.fi + +The help pages have been updated to reflect these changes. + +\fIwfits\fR now writes ushort (16 bit unsigned short) images to FITS images +with bitpix=16, bscale=1.0, and bzero=32768.0 by default. \fIrfits\fR will +read these images back as type ushort. +.nh 2 +General changes + +.nf + o The GSURFIT package has been updated to include support for the "half" + cross terms option useful in computing plate solutions. Tasks that can + make use of this feature have been updated although their default + behaviors have not changed. + + o The code which computes the CD matrix from CDELT/CROTA was modified. + The old code computed the diagonal (scale) terms correctly but the + rotation terms were evidently incorrect. The old code was based on + the 1988 Hanisch and Wells WCS paper and the new code is based on a + more recent paper by Mark Calabretta et al, which supersedes the + 1988 representation. The affect of this change should be limited + as it only affects rotated images for which CDELT is given but no + CD matrix is defined. (V2.10.4p2) + + o Several new celestial coordinate projection functions have been added. + Users with IPAC data that use the CAR projection function should now be + able to read the image coordinates directly with LISTPIXELS, etc. +.fi +.nh +New tasks, or old tasks moved to new packages + +.nf + \fBTask Name Package Function\fR + + CCXYMATCH IMCOORDS Four new tasks for computing and evaluating + CCMAP simple astrometric plate solutions and storing + CCSETWC them in the image headers in fits-compatible + CCTRAN format. + + CCFIND IMCOORDS CCFIND locate objects in an image given a + celestial coordinate list and the image wcs. + + IMCCTRAN IMCOORDS Two new tasks for transforming celestial + SKYCTRAN coordinate lists and image celestial + coordinate systems from one celestial + coordinate system to another. + + STARFIND IMCOORDS STARFIND automatically detects stellar objects + in a list of images. + + WCSCTRAN IMCOORDS A new task for transforming between IRAF image + coordinate systems. + + WCSEDIT IMCOORDS Two unaltered former PROTO package tasks for + WCSRESET editing IRAF image coordinate systems. + + FRMEDIAN IMFILTER Four new tasks for doing circular/elliptical/ + FRMODE ring image median filtering. + RMEDIAN + RMODE + + IM3DTRAN IMGEOM The former addon VOL package task IM3DTRAN for + doing 3D image transposes. + + GEOXYTRAN IMMATCH A new task for transforming coordinate lists + using the results of the GEOMAP task. + + IMCENTROID IMMATCH Four new tasks for computing matched pixel + SKYXYMATCH lists. IMCENTROID is a modified version of the + WCSXYMATCH PROTO package task of the same name. + XYXYMATCH + + SKYMAP IMMATCH Two new tasks for computing geometric + WCSMAP transforms using the image coordinate system + information. + + IMALIGN IMMATCH Three new tasks for doing automated image + SREGISTER registration. IMALIGN is a modified version + WREGISTER of the PROTO package task of the same name. + + WCSCOPY IMMATCH A new task for copying the coordinate system + of a reference image to a set of input images. + + PSFMATCH IMMATCH A new task for matching the PSFs of a set of + input images to the PSF of a reference image + using Fourier techniques. + + LINMATCH IMMATCH A new task for matching the linear intensity a + scale of a set of input images to the + intensity scale of a reference image. + + IMFUNCTION IMUTIL The former PROTO package task for applying a + single argument function to an image. + + IMJOIN IMUTIL The former addon VOL package task for joining + same-dimensioned images along a specified + dimension. + + IMREPLACE IMUTIL The former PROTO package task IMREPLACE for + replacing bad pixels based on their value. + + IMTILE IMUTIL A modified version of the NOAO.PROTO IRMOSAIC + task for tiling same sized 2D images into a + single mosaiced image. + + EXPORT DATAIO Two new tasks from the external IMCNV package + IMPORT for exporting IRAF images to binary formats + and for importing binary files into IRAF + images. + + TEXT2MASK PROTO This new task appears in conjunction with a + new pixel mask based version of FIXPIX. + + IMEXTENSIONS PROTO This task selects and lists image extensions + in files. Image extensions currently occur + in multi-extension FITS files and multi-group + Geiss (STF format) files. + + CCDMASK CCDRED This new task creates a pixel mask from a + CCD image. + + AIDPAR ONEDSPEC New parameter set for automatic line + identification for the tasks AUTOIDENTIFY, + IDENTIFY and REIDENTIFY. + + AUTOIDENTIFY ONEDSPEC A new task to automatically identify lines + and fit the dispersion function. + + SKYTWEAK ONEDSPEC Sky spectra are shifted and scaled to best + subtract sky features from data spectra. + + TELLURIC ONEDSPEC Telluric calibration spectra are shifted and + scaled to best divide out telluric features + from data spectra. + + ASTCALC ASTUTIL An astronomical calculator. + + ASTRADIUS ASTUTIL Finds images within a circle on the sky. +.fi +.nh +Task and package deletions + +CUBE, DUMP, GSUBRAS, MAXMIN, MKIMAGE, MKTEST: These tasks have been +superseded by the equivalent tasks in the IMAGES or ARTDATA packages. +The functionality of these tasks still exists in the +iraf$pkg/images/lib/zzdebug.x file. + +REGISTER: This task has been renamed to GREGISTER. + +IMALIGN, IMCENTROID, IMFUNCTION, IMREPLACE, WCSEDIT, WCSRESET: Moved to the +IMAGES package. +.nh +Modifications to old tasks + +Grouped by package, a list of modifications to old tasks in IRAF are +summarized below. We have included modifications since the V2.10.3 +release. +.nf + +\fBIMFILTER:\fR + FMEDIAN, FMODE, MEDIAN, MODE + Minimum and maximum good data value parameters zloreject and zhireject + and a verbose option parameter were added. + MEDIAN, MODE + The 64 x 64 maximum kernel size limit was removed from these tasks. + +\fBIMMATCH:\fR + GEOMAP + Renamed the output parameter to database for the sake of consistency + with other new images tasks. + + Changed the default value of the reject parameter from 0.0 to INDEF. + + Added the transforms parameter. Transforms permits the user to specify + the names of the output database records explicitly. + + Added the parameter results. Results permits the user to save a summary + of the results including a description of the transform geometry, and a + listing of the input coordinates, the fitted coordinates, and the fit + residuals. + + Added the fitgeometry parameter. Fitgeometry permits the user to + constrain the linear part of the fit to: 1) x and y shifts only, 2) x + and y shifts and rotation only, 3) x and y shifts and x and y scale + changes only, 4) x and y shifts, rotation, and a scale change only, 5) + x and y shifts, rotation, x and y scale changes only, and 5) x and + shifts, rotation, skew, and x and y scale changes. + GREGISTER + Renamed the register task gregister to emphasize that it is paired with + the geomap task and to avoid confusion with the new registration tasks. + GEOTRAN, GREGISTER + Renamed the transform parameter to transforms. + + Added the verbose parameter. + GEOTRAN + Added the ability to write to a section of an existing image. + IMCOMBINE + The limit of the number of images that may be combined has been + removed. If the number of images exceeds the maximum number of + open images permitted then the images are stacked in a single + temporary image and then combined with the project option. + Note that this will double the amount of diskspace + temporarily. There is also a limitation in this case that the + bad pixel mask from the first image in the list will be applied + to all the images. + + Integer offsets may be determined from the image world + coordinate system. + + A combination of ushort and short images now defaults to + integer. + + Added support for type ushort images. + + Added a new options for computing offsets using the image wcs. + + Removed the limit on the maximum number of images that can be combined. + IMALIGN, IMCENTROID + Renamed the images parameter to input, changed the reference parameter + mode from hidden to automatic, and reversed the order of the reference + and coords parameters. + +\fBIMUTILS:\fR + IMEXPR + Modified the task so that it will accept an image name that looks like + a number in the first few characters, but which is really an image + name. For example, "123.imh" or "../foo.imh". The previous version + of imexpr was treating any string which looked like a number in the + first few characters as a numeric constant. (V2.10.4p2) + IMREPLACE + The lower value is now rounded up for integer images so that a + range like 5.1-9.9 affects pixels 6-9 instead of 5-9. + IMSUM + Now allows "ushort" data types. + +\fBTV:\fR + DISPLAY + The bad pixel mask, overlay mask, sample mask, and overlay + colors parameters and functionality have been added. The + "nsample_lines" parameter is now an "nsample" parameter. + + Bugs in the coordinate system sent to the image display for + cursor readback were fixed. + IMEDIT + If xorder or yorder are zero then a median background is + computed for the 'a' and 'b' keys. + IMEXAMINE + ('a' and 'r'): The fit to the radial profile points now + includes both a Gaussian and a Moffat profile. The Moffat + profile exponent parameter, beta, may be fixed or left free to + be fit. + + ('a' and 'r'): New estimates fo the FWHM were added to the 'a' + and 'r' keys. These include the Moffat profile fit noted + above, a direct measurement of the FWHM from the radially + binned profile, and a Gaussian or Moffat fit to the radial + enclosed flux profile. The output from these keys was modified + to include the new information. + + ('a' and 'r'): The direct FWHM may be used to iteratively + adjust the fitting radius to lessen the dependence on the + initial fitting radius value. + + ('k'): Added a kimexam parameter set. + + The default value of rimexam.magzero parameter was changed from + 30.0 to 25.0 for consistency with the digiphot package. + +\fBPROTO:\fR + FIELDS + The default value for the lines parameter was changed to an open + upper limit. + + Changed the default value of the lines parameter from "1-999" to + "1-" so that the upper bound would be open ended. + FIXPIX + This task replaces the old task (now obsolete.ofixpix) and + works with the more general pixel mask facilities. It also + provides greater flexibility in choosing the interpolation + direction. + +\fBICFIT\fR used in various tasks: + ICFIT + The :xyshow output was modified to 1) not include colon labels, + 2) print (X, Y, Y fit, Weight) instead of (X, Y fit, Y), and 3) + the printed values are those actually used in the fit when using + composite points (naverage not 1). + +\fBARTDATA:\fR + MK1DSPEC + Lorentzian and Voigt profiles were added and the parameters and + input line list format were changed. The widths are now FWHM + instead of gaussian sigmas. + MKOBJECTS, MKNOISE + The default value of "ranbuf" was changed to zero. + GALLIST + The default value for the minimum elliptical galaxy axial ratio + was changed to 0.3 to cover the range E0-E7 uniformly. + MKPATTERN + Now allows ndim=0 to make an dataless header. + Now allows ushort pixel type. + +\fBASTUTIL:\fR + SETJD + The checking of the epoch keyword value was improved. + Previously if there was a problem with the keyword value + (missing or malformed) the task would use the epoch of the + observation. Now it is an error if an epoch keyword is + specified but the epoch value can't be determined. Also a + leading 'B' or 'J' is allowed and a warning will be given if + the epoch value is unlikely. + ASTHEDIT + There are new astronomical functions and input/output functions. + The command syntax may now use "=" as a delimiter as well as + the whitespace. + + A new parameter "update" allows protecting images and accessing + read-only images for the purpose of calculating and printing + quantities. + + The special variable name "$I" has the value of the image name, + $D the current date, and $T the current time. + + The case of no image name creates and deletes a temporary image + so the task can be used purely as a calculator (but see + astcalc). + +\fBCCDRED:\fR + CCDPROC + The bad pixel fixing was modified to allow use of pixel masks, + images, or the text file description. Bad pixel masks are the + desired description and use of text files is only supported for + backward compatibility. Note that support for the trimmed or + untrimmed conversion from text files has been eliminated. + + Line-by-line overscan/prescan subtraction is now provided with + three simple algorithms. + COMBINE + The limit of the number of images that may be combined has been + removed. If the number of images exceeds the maximum number of + open images permitted then the images are stacked in a single + temporary image and then combined with the project option. + Note that this will double the amount of diskspace + temporarily. There is also a limitation in this case that the + bad pixel mask from the first image in the list will be applied + to all the images. + + Integer offsets may be determined from the image world + coordinate system. + + Fixed a bug where a variable was improperly used for two different + purposes causing the algorithm to fail. This also affected IMCOMBINE + and SCOMBINE. See bug 316 for details. (V2.10.4p2) + COSMICRAYS + The output bad pixel data accidentally included some extra fields + making it incorrect to use the file directly with BADPIXIMAGE. + The extra diagnostic fields were removed. For details, see bug 311 + in the buglog. (V2.10.4p2) + +\fBECHELLE:\fR + ECIDENTIFY + The dispersion units are now determined from a user parameter, + the coordinate list, or the database entry. + +\fBIMRED\fR Spectral Packages: + DOARGUS, DOFIBERS, DOHYDRA + A sky alignment option was added. + + The aperture identification can new be taken from image header + keywords. + + The initial arc line identifications is done with the automatic + line identification algorithm. + DOSLIT, DO3FIBER + The initial arc line identifications is done with the automatic + line identification algorithm. + +\fBONEDSPEC:\fR + Support for the Sloan Sky Survey was added by allowing multifiber + reductions with up to 500 fibers with non-linear dispersions. (V2.10.4p2) + + BPLOT + Fixed a general problem in BPLOT and SLIST that caused a segmentation + violation error. See buglog 312 for details. (V2.10.4p2) + FITPROFS + Modified to include lorentzian and voigt profiles. The + parameters and positions file format have changed in this + version. A new parameter controls the number of Monte-Carlo + samples used in the error estimates. + IDENTIFY + The dispersion units are now determined from a user parameter, + the coordinate list, or the database entry. + A new key, 'e', has been added to add features from a line list + without doing any fits. This is like the 'l' but without the + automatic fitting before and after adding new features. + + A new key, 'b', has been added to apply an automatic line + identification algorithm. + + The 'x' key has been changed to use the automatic line + identification algorithm. The allows finding much larger + shifts. + + The match parameter may now be specified either in user + coordinates or in pixels. The default is now 3 pixels. + + The default threshold value has been changed to 0. + REIDENTIFY + A new parameter, "search", was added to specify a search radius + for the automatic line identification algorithm. + + The "nlost" parameter now also applies when not tracing; i.e. it + will issue a warning and not record a solution if the specified + number of features is lost when reidentifying against a specific + reference spectrum as is done with multispec data. + + The task will now work with only a warning if the reference + image is absent; i.e. it is possible to reidentify given only + the database. + + The addfeatures function will now add features before a fit if + there are no reference database features. Previously features + could only be added after an initial fit using the reference + features and, so, required the reference database to contain + features for reidentification. This new feature is useful if + one wants to uses a dispersion function from one type of + calibration but wants to add features for a different kind of + calibration. + SAPERTURES + This task has been modified to allow use of image header + keywords as done in the APEXTRACT package. + SARITH + Previously both w1 and w2 had to be specified to select a range + to be used. Now if only one is specified the second endpoint + defaults to the first or last pixel. + + The noise band in multispec data is only copied from the primary + spectrum and not modified. This is a kludge until the noise is + handled properly. + + Fixed a problem in SARITH and SCOPY where a segmentation error + occurred when a wavelength range was specified in the reverse sense + of the data and without rebinning. See buglog 323 for details. + (V2.10.4p2) + SBANDS + Fixed a problem in SBANDS that caused a segmentation violation when + the number of input bandpasses was greater than 10. See buglog 298 + for details. (V2.10.4p2) + SCOPY + Previously both w1 and w2 had to be specified to select a range + to copy. Now if only one is specified the second endpoint + defaults to the first or last pixel. + SPECPLOT + The scale and offset parameters may now be a value, a filename, + or and image header keyword. + + The 'f' key was added to toggle between world and logical pixel + coordinates. + SPLOT + The profile fitting and deblending was expanded to include + lorentzian and voigt profiles. A new parameter controls the + number of Monte-Carlo samples used in the error estimates. + RSPECTEXT + The task now automatically senses the presence of a header. + +\fBAPEXTRACT:\fR + APALL, APSUM, APNOISE, APNORMALIZE, APSCATTER, APTRACE, + APRECENTER, APRESIZE, APMASK, APFIND, APFLATTEN + The "apertures" parameter can be used to select apertures for + resizing, recentering, tracing, and extraction. This parameter + name was previously used for selecting apertures in the + recentering algorithm. The new parameter name for this is now + "aprecenter". + APALL, APSUM + The "nsubaps" parameter now allows onedspec and echelle output + formats. The echelle format is appropriate for treating each + subaperture as a full echelle extraction. + APALL + The aperture ID table information may now be contained in the + image header under the keywords SLFIBnnn. + APSUM + The dispersion axis parameter was moved to purely a package + parameter. + + As a final step when computing a weighted/cleaned spectrum the + total fluxes from the weighted spectrum and the simple + unweighted spectrum (excluding any deviant and saturated + pixels) are computed and a "bias" factor of the ratio of the + two fluxes is multiplied into the weighted spectrum and the + sigma estimate. This makes the total fluxes the same. In this + version the bias factor is recorded in the logfile if one is + kept. Also a check is made for unusual bias factors. If the + two fluxes disagree by more than a factor of two a warning is + given on the standard output and the logfile with the individual + total fluxes as well as the bias factor. If the bias factor is + negative a warning is also given and no bias factor is applied. + In the previous version a negative (inverted) spectrum would + result. + +\fBRV:\fR + RVIDLINES, RVREIDLINES + These tasks now work in the units of the input spectra. + FXCOR + The input spectra are converted to Angstroms for the + crosscorrelation and analysis. Thus the velocities will + be correctly computed regardless of the units of the + input spectra. + +\fBDAOPHOT:\fR + DAOFIND + A major bug in the DAOFIND task centering code that affects the + computed x and y positions was fixed. Users should refer to bug + log entry number 332 for details. (V2.10.4p2) + + A new roundness statistic was added to the DAOFIND output to + bring the task into conformance with standalone DAOPHOT II. The new + statistic is sensitive to and tries to eliminate detected objects + which are significantly elongated in directions other than 0, 90, + 180, and 270 degrees. The original roundness statistic is stored in + the ground column, the new one in the sround column. The same + default roundness limits apply to both statistics. (V2.10.4p2) + + DAOPARS + Added a new parameter "mergerad" to the DAOPARS parameter set. + Mergerad permits the user to control the merging process. If + mergerad is INDEF (the default setting) the default merging radius + is used. If mergerad is 0 object merging is turned off altogether. + Otherwise the user can set the merging radius to a specific value. + Mergerad is used by the nstar and allstar tasks, but their default + behavior is unchanged. (V2.10.4p2) + + Changed the name of the "critovlap" parameter to "critsnratio" to + avoid confusion with the meaning of the parameter especially + with regard the mergerad parameter. The behavior of the parameter is + unchanged. (V2.10.4p2) +.fi +.nh +Parameter file changes + +The parameter file changes below are for modifications between V2.10.4 +and V2.11. For a list of parameter file changes between V2.10.3 and +V2.10.4 see the file iraf/v210/params.v2104.Z in the IRAF FTP archives. + +In the tables below each parameter change is identified with one of the +following codes followed by task_name.parameter_name and the description of +the change. + +.nf + n = new parameter + c = changed/modified parameter + d = deleted parameter + +\fBTV:\fR + n display.nsample: replaces nsample_lines + d display.nsample_lines: replaced by nsample + n display.bpmask: specify a bad pixel mask + n display.bpdisplay: specify display mode for bad pixel mask + n display.bpcolors: specify overlay colors for bad pixel mask + n display.overlay: specify an overlay mask + n display.ocolors: specify overlay colors for overlay mask + n display.zmask: specify a sample mask for the zscale calculation + c imedit.xorder: now allows a value of zero for median background + c imedit.yorder: now allows a value of zero for median background + n rimexam.fittype: specify a profile type to fit - default is now moffat + n rimexam.iterations: specify number of iterations to adjust fitting radius + n rimexam.beta: specify beta value for moffat fitting + c rimexam.buffer: default value changed from 1 to 5 + c rimexam.width: default value changed from 2 to 5 + c rimexam.magzero: default value changed from 30 to 25 + n wcslab.overplot: specify overplotting + +\fBDATAIO:\fR + n wfits.fextn: extension to append to output disk FITS filename - default is + fits + n wfits.extensions: write all images to a single FITS file ? - default is no + n wfits.global_hdr: prepend a global header to the FITS extensions - default + is yes + +\fBIMAGES:\fR + n fmedian.zloreject: good data minimum + n fmedian.zhireject: good data maximum + n fmedian.verbose: verbose option + n fmode.zloreject: good data minimum + n fmode.zhireject: good data maximum + n fmode.verbose: verbose option + n median.zloreject: good data minimum + n median.zhireject: good data maximum + n median.verbose: verbose option + n mode.zloreject: good data minimum + n mode.zhireject: good data maximum + n mode.verbose: verbose option + n geomap.transforms: list of record names + n geomap.results: results summary file + n geomap.fitgeometry: fitting geometry + d geomap.output: renamed to database + c geomap.reject: changed from 0.0 to INDEF + n [g]register.verbose: verbose option + d [g]register.transform: renamed to transfo + n geotran.verbose: verbose option + d geotran.transform: renamed to transforms + c imcombine.offsets: now allows specifying "wcs" to compute offsets from WCS + d imalign.images: renamed to input + c imalign.reference: went from hidden to auto + c imalign.coords: reversed places with reference + d imcentroid.images: renamed to input + c imcentroid.reference: went from hidden to auto + c imcentroid.coords: reversed places with reference + n imheader.imlist: default image names + +\fBPLOT:\fR + n graph.ltypes: specify the line types + n graph.colors: specify the colors + +\fBPROTO:\fR + n fixpix.masks: new version specifies bad pixel masks + n fixpix.linterp: specify mask values for line interpolation + n fixpix.cinterp: specify mask values for column interpolation + n fixpix.pixels: list pixels that are modified + d fixpix.badpixels: new version does not use bad pixel region description + c fields.lines: default value changed from "1-9999" to "1-" + +\fBARTDATA:\fR + n mk1dspec.profile: define the profile type + n mk1dspec.gfwhm: replaces sigma for gaussian profile width + n mk1dspec.lfwhm: width for lorentzian profile + c artdata.randbuf: default value changed from 1000 to 0. + c mkpattern.ndim: allows a value of 0 for a dataless header. + c mkpattern.pixtype: allows ushort. + c gallist.ar: default value changed to 0.3. + d mk1dspec.sigma: replaced by gfwhm + +\fBASTUTIL:\fR + n rvcorrect.keywpars: added to define keywords used + n asthedit.prompt: used for new calculator option + n asthedit.update: update the header + n asthedit.oldstyle: to allow backward compatibility + +\fBAPEXTRACT, IMRED\fR spectral packages: + n apnoise.apertures: select apertures to be used + n apfit.apertures: select apertures to be used + n apedit.apertures: select apertures to be used + n apfind.apertures: select apertures to be used + n apnormalize.apertures: select apertures to be used + n apscatter.apertures: select apertures to be used + n apsum.apertures: select apertures to be used + n aptrace.apertures: select apertures to be used + n apresize.apertures: select apertures to be used + n apmask.apertures: select apertures to be used + n apflatten.apertures: select apertures to be used + n aprecenter.apertures: select apertures to be used + n aprecenter.aprecenter: was what was previously the apertures parameter + n apall.apertures: select apertures to be used + n apall.aprecenter: was what was previously the apertures parameter + +\fBARGUS, HYDRA, SPECRED:\fR + n doargus.crval: for automatic line identifications + n doargus.crdelt: for automatic line identifications + n doargus.skyalign: night sky alignment option + n dohydra.crval: for automatic line identifications + n dohydra.crdelt: for automatic line identifications + n dohydra.skyalign: night sky alignment option + n dofibers.crval: for automatic line identifications + n dofibers.crdelt: for automatic line identifications + n dofibers.skyalign: night sky alignment option + n do3fiber.crval: for automatic line identifications + n do3fiber.crdelt: for automatic line identifications + +\fBARGUS, HYDRA, KPNOCOUDE, KPNOSLIT, SPECRED:\fR + c params.match: default value changed to -3 (3 pixels instead of Angstroms) + c sparams.match: default value changed to -3 (3 pixels instead of Angs) + +\fBONEDSPEC, IMRED\fR spectral packages: + d fitprofs.sigma: replaced by gfwhm + d fitprofs.function: replaced by profile + d fitprofs.fitsigmas: replaced by fitgfwhm + d rspectext.header: removed since the task now senses the header information + +\fBONEDSPEC, LONGSLIT, IMRED\fR spectral packages: + n identify.units: specify the desired units for the dispersion function + n identify.crval: for automatic line identifications + n identify.crdelt: for automatic line identifications + n identify.aidpars: parameter set for automatic line identifications + c identify.match: default value changed to -3 (3 pixels instead of Angstroms) + c identify.threshold: default value changed from 10 to 0. + c reidentify.match: default value changed to -3 (3 pixels instead of Angs) + c reidentify.threshold: default value changed from 10 to 0. + n reidentify.crval: for automatic line identifications + n reidentify.crdelt: for automatic line identifications + n reidentify.aidpars: parameter set for automatic line identifications + n reidentify.search: specify a search radius for the automatic line + identification algorithm + n ecidentify.units: specify the desired units for the dispersion function + n fitprofs.profile: define the profile type + n fitprofs.gfwhm: replaces sigma for gaussian profile width + n fitprofs.lfwhm: width for lorentzian profile + n fitprofs.fitgfwhm: replaces fitsigmas + n fitprofs.fitlfwhm: select whether to fit lorentzian profile widths + n fitprofs.nerrsample: allows control of the error calculation accuracy + n splot.nerrsample: allows control of the error calculation accuracy + +\fBCCDRED:\fR + c ccdproc.fixfile: this now specifies a bad pixel mask + c combine.offsets: now allows specifying "wcs" to compute from WCS + +\fBRV:\fR + n rvcorrect.par: Added the KEYWPARS pset declaration + +\fBDAOPHOT:\fR + c daopars.critsnratio: critical S/N ratio for group membership - changed + the name only from critovlap (V2.10.4p2) + n daopars.mergerad: critical object merging radius in scale units + (V2.10.4p2) +.fi +.endhelp diff --git a/doc/v212revs.hlp b/doc/v212revs.hlp new file mode 100644 index 00000000..17f0db89 --- /dev/null +++ b/doc/v212revs.hlp @@ -0,0 +1,1152 @@ +.help IRAF Mar02 "V2.12EXPORT Release Notes" +.sp 1 +.ce +IRAF V2.12EXPORT Release Notes +.ce +January 25, 2002 +.ce +Updated: March 25, 2002 + + +These release notes provide a summary of the major changes in V2.12. This +is a major release of IRAF and will be available for all supported platforms. +More detailed technical documentation of all system changes will be found +in the 'notes.v211' and 'notes.v212' files in the iraf$doc and iraf$local +directories. Detailed revisions notes for each application package are in +the package directories in a file called Revisions, e.g. apphot$Revisions. + +.nf + 1. \fBHighlights of This Release\fR + 2. \fBIRAF System Revisions Summary\fR + 3. \fBCore IRAF Revisions Summary\fR + 3.1 New Tasks + 3.2 Existing tasks with new parameters/defaults + 3.3 Existing tasks with new capabilities + 4. \fBNOAO Package Revisions Summary\fR + 4.1 New NOAO Packages + 4.2 New NOAO Package Tasks + 4.3 Existing tasks with new parameters/defaults + 4.4 Existing tasks with new capabilities + 5. \fBGeneral Package Changes\fR + 6. \fBGeneral Task Changes\fR + 7. \fBParameter File Changes\fR + 8. \fBDetails of Major System Changes\fR + 8.1 FITS Kernel Changes + 8.2 Large Image Support + 8.3 Virtual Memory Cache + 8.4 New Developer libraries + 9. \fBSystem Changes Which May Affect You\fR + 9.1 Shared Library Version Incremented + 9.2 External Package Recompilation + 9.3 Parameter File Changes + 9.4 Installation Script Changes + 9.5 Help System Changes + 9.6 Image Display Changes + 9.7 PLIO Changes + 9.8 New Environment Variables Changes +.fi + + +.nh +Highlights of This Release + +.nf + o \fBPixel Mask Support Added to FITS Kernel\fR + The FITS kernel was modified to add support for storing images in + extensions as compressed pixel masks using the binary table extension. + These masks may be accessed like any other image and allow for tasks + to more easily store bad-pixel masks, regions masks, or error arrays + in the same image file as the science data. + + o \fBNew Pixel Mask Tasks\fR + Several new tasks have been added to the system PROTO package for + manipulating pixel masks: + + o MIMSTATISTICS allows image statistics to be computed while + rejecting pixels specified by an input mask. + o MSKEXPR task is a general-purpose mask expression evaluator + similar to IMEXPR for images, but has builtin boolean region + functions which can be used to set values inside or outside + of certain geometric shapes. + o MSKREGIONS creates an output mask based on an input text de- + scription. Region descriptions can be composed of geometric + shapes and logical operation on mask regions. + + o OBJMASKS in the NPROTO package is a new task for detecting objects + in an image and creating an output catalog or pixel mask of + found objects. + + o \fBShared Memory Limitations Eased\fR + The IMAGES and DAOPHOT packages executables are now linked statically + to remove per-process memory limitations imposed by the IRAF shared + library on Sun and Dec Alpha systems. Previously tasks such as + DAOFIND and IMCOMBINE were limited to 268Mb on Sun systems, these + tasks can now use up to the machine memory limits. + + o \fBImage I/O Buffer Sizes Increased\fR + Support for large image I/O was improved by changes to the internal + buffer sizes. These buffers may automatically adjust to optimal + values for the image being accessed, however new environment variables + may be set to further tune the buffers at the user level. Where + needed applications tasks were modified to take advantage of these + buffer size changes to force the imio buffer to be the size of the + input image. + + o \fBSimplified Installation Script\fR + The install script was rewritten to clarify the output and provide + some basic checking of the IRAF system setup prior to installation, + and to do some of the most common post-install configuration. The + script will print an explanation of any errors it finds and suggest + corrective action, the hope is this will lead the user past some of + the most common installation errors. + + In addition, the SYSINFO diagnostic script which does more extensive + checking of the system is also now part of the distribution. This + script can be used to verify the system once the install is complete, + or to generate a report of the system configuration if needed by + site support. An UNINSTALL script to remove iraf command links and + files created by the INSTALL script is also available to remove IRAF + from a machine. All scripts are now installed in the hlib$ directory. + + o \fBNew HELP GUI and Output Options\fR + The HELP task was enhanced to have a new GUI option for XGterm + users. This is essentially the XHELP task which has been available + in the GUIAPPS external package for some time, however the task is + fully backwards compatible and the text-mode output is still the + default. As part of this work, help pages may also now be formatted + as either HTML or Postscript for web presentation or pretty-printing + to a hardcopy device. The LROFF task was similarly modified to + provide direct conversion of lroff text sources. + + o \fBDISPLAY Task Changes\fR + As part of the recent X11IRAF enhancements, the DISPLAY task and + others such as IMEXAMINE which interact with the display server were + modified to take advantage of the new features in XImtool V1.3. + These include support for 16 frame buffers (increased from 4 in + previous versions), and enhanced WCS readout capabilities. The + changes are fully backwards compatible for use with older XImtool + versions or display servers such as SAOimage, SAOtng, or DS9 which + have not yet been updated. + + X11IRAF V1.3 is being released simultaneously (but still separately) + with IRAF V2.12. While V2.12 is fully compatible with older versions + of X11IRAF, however users will need to upgrade both systems to take + full advantage of all the new features. Users should consult the + X11IRAF Release Notes for details on what has changed there. + + o \fBNew Packages\fR + Several new packages are available in this release (see the NOAO + package change notes below for details): + + - A new ASTCAT package for extracting astrometric and photometric + calibration data from remote or local catalogs was added to NOAO. + + - A new CRUTIL package for doing cosmic ray detection and removal + package was installed in the IMRED package. + + - A new QUADRED reduction package for QUAD format data was installed + in the IMRED package. This is a generalized replacement for the + ARED.QUAD and XCCDRED external packages for processing CTIO and + ESO FORS1 multi-amplifier data. + + - A new OBSUTIL package was installed in NOAO. This is a collection + of tasks from various external packages which are useful to plan or + carry out observations. + + o \fBNew Developer Libraries.\fR + Several new libraries are available for SPP developers: + + - PSIO is a new Postscript text generation library installed in + sys$psio. + + - CATQUERY is a remote astrometric/photometric catalog access lib + installed in the XTOOLS utility library. + + - SKYWCS is a sky coordinate transformation library installed in + the XTOOLS utility library. +.fi + + +.nh +IRAF System Revisions Summary + +.nf + o The IRAF shared library version number was incremented for SunOS + and Solaris systems. See below for details on how this change + will affect external packages and locally-compiled software. + + o The maximum number of nodes in a local iraf network was increased + from 320 to 512. + + o The max number of open files in FIO, FIO_MAXFD, was increased from + 256 to 4096. This is the "hard limit" on the maximum number of + open files in an IRAF process. + + o The maximum number of host level open files, MAXOFILES, was increased + from 64 to 256. This is the maximum number of files that can be + simultaneously open at the host level. It determines the maximum + number of files that can be simultaneously open by an IRAF process + in the usual case. + + o The number of keywords in a group header block for STF images (i.e. + the MAX_PCOUNT) was increased from 50 to 99 in the STF image kernel. + + o Added support for the bitwise boolean operators: '&' (and), '|' (or), + '^' (xor), and '~' (not/complement), to vectory expression evaluator + fmtio$evvexpr.gy. The IMEXPR task was modified to allow these new + bitwise operations. + + o Added new vector operators to VOPS library: alan, alank (logical AND) + and alor, alork (logical OR). These take any integer data as input + (short, int, long) and return a logical (expressed as int) result. + + o The 'imextn' environment variable will now accept upper-case extensions + to specify image types. + + o Host Command Execution: The way command line arguments are parsed + was modified to make it easier to set the value of a string parameter + to the null string. Whitespace is still skipped in @par files + as before, however null strings are valid parameter values and will + no longer cause a parameter prompt. + + o The MKPKG special file list link support was enhanced to allow replacing + LFLAGS (the link flags variable) as well as the entire link line. + This makes is possible to write special-file list entries for packages + which need e.g. to be compiled nonshared on certain platforms without + creating a platform specific mkpkg file for the package itself. + + o The HSI zawset.c routine which controls a process working set size was + modified to automatically detect the physical size of system memory + (with a maximum return value of 2Gb). The hard upper limit on memory + utilization defined by the unix kernel can be limited either by the + value return by the IRAF kernel (up to 90% of physical memory), or by + the value set in the user environment variable MAXWORKSET (given in + units of Mb). + + o New stdimage display devices were added to support the display of Gemini + GMOS CCD data. These devices are named 'imt45' thru 'imt49' and + correspond to the following frame buffer sizes: + + imt45 2080 x 4644 # imt45|imtgmosccd + imt46 6400 x 4644 # imt46|imtgmos + imt47 3200 x 2322 # imt47|imtgmos2 + imt48 1600 x 1161 # imt48|imtgmos4 + imt49 800 x 581 # imt49|imtgmos8 +.fi + +.nh +CORE IRAF REVISIONS SUMMARY + +.nh 2 +New Tasks +.nf + imcoords.ccget - extract objects from a test file catalog + imcoords.ccstd - transform to and from standard astrometric coordinates +proto.mimstatistics - do image statistics through a mask + proto.rskysub - sky subtract images using running mean or median + proto.mskexpr - general mask expression evaluator + proto.mskregions - create a mask from a list of region specifications +.fi + +.nh 2 +Existing Tasks with New Parameters or New Parameter Defaults +.nf + immatch.imcentroid - new parameter maxshift + immatch.imalign - new parameter maxshift + immatch.geomap - new parameter maxiter, default reject = 3.0 not INDEF + imcoords.ccmap - new parameter maxiter, default reject = 3.0 not INDEF + imcoords.imcctran - new parameter longpole + imutil.hedit - new parameter addonly +imutil.imstatistics - new parameters nclip, lsigma, usigma, cache +.fi + +.nh 2 +Existing Tasks with New Capabilities +.nf + immatch.imcentroid - optionally rejects objects whose centers wander too much + immatch.imalign - optionally rejects objects whose centers wander too much + immatch.geomap - iterative rejection capability added + imcoords.ccmap - iterative rejection capability added + imcoords.imcctran - support for non-zenithal projections added + imutil.hedit - support for add keyword only if new option +imutil.imstatistics - support for iterative rejection and memory caching added + imutil.imexpr - support for bitwise operators or, and, xor, and not added +.fi + + +.nh +NOAO PACKAGE REVISIONS SUMMARY + +.nh 2 +New NOAO Packages +.nf + astcat - Astronomical catalog and surveys access package + crutil - Cosmic ray detection and removal package + obsutil - Observing utilities package +.fi + +.nh 2 +New NOAO Package Tasks +.nf + apphot.pcalc - Do arithmetic operations on a list of apphot databases + apphot.pconvert - Convert a text database to a tables database + apphot.pdump - Print selected fields from a list of apphot databases + apphot.pexamine - Interactively examine and edit an apphot database + apphot.prenumber - Renumber stars in an apphot database + apphot.pselect - Select records from an apphot database + apphot.psort - Sort an apphot database + + astcat.aclist - List the supported astrometric catalogs + astcat.agetcat - Extract astrometry files from astrometric catalogs + astcat.afiltcat - Filter astrometry files derived from astrometric catalogs + astcat.adumpcat - Catalog access debugging task + astcat.aslist - List the supported image surveys + astcat.agetim - Extract FITS images from image surveys + astcat.ahedit - Initialize the image wcs and set standard keywords + astcat.aimfind - Select images containing catalog objects + astcat.adumpim - Image survey access debugging task + astcat.aregpars - Default region parameter set + astcat.acatpars - Default astrometry file format parameter set + astcat.afiltpars - Default astrometry file filtering parameters + astcat.aimpars - Default image data parameters + astcat.awcspars - Default image wcs parameters + + crutil.cosmicrays - Remove cosmic rays using flux ratio algorithm + crutil.craverage - Detect CRs against average and avoid objects + crutil.crcombine - Combine multiple exposures to eliminate cosmic rays + crutil.credit - Interactively edit cosmic rays using an image display + crutil.crfix - Fix cosmic rays in images using cosmic ray masks + crutil.crgrow - Grow cosmic rays in cosmic ray masks + crutil.crmedian - Detect and replace cosmic rays with median filter + crutil.crnebula - Detect and replace cosmic rays in nebular data + +obsutil.psfmeasure - Measure PSF sizes from stellar images + obsutil.specfocus - Determine spectral focus and alignment variations + obsutil.starfocus - Determine direct focus variations from stellar images + obsutil.ccdtime - CCD photometry exposure time calculator + obsutil.pairmass - Plot airmass vs time for a given coordinate + obsutil.sptime - Spectroscopic exposure time calculator + obsutil.specpars - Spectrograph instrument parameters for sptime + obsutil.bitcount - Accumulate the bit statistics for a list of images + obsutil.findgain - Estimate the gain and readnoise of a CCD + obsutil.shutcor - Shutter correction from images of varying exposure times + + nproto.objmasks - detect and catalog objects in image +.fi + +.nh 2 +Existing Packages and Tasks with New Parameters or New Parameter Defaults +.nf + apphot - new package parameters wcsin, wcsout, and cache + apphot.center - new parameters wcsin, wcsout, cache + apphot.daofind - new parameters wcsout, cache + apphot.fitpsf - new parameters wcsin, wcsout, cache + apphot.fitsky - new parameters wcsin, wcsout, cache + apphot.phot - new parameters wcsin, wcsout, cache + apphot.polymark - new parameters wcsin, wcsout, cache + apphot.polyphot - new parameters wcsin, wcsout, cache + apphot.qphot - new parameters wcsin, wcsout, cache + apphot.radprof - new parameters wcsin, wcsout, cache + apphot.wphot - new parameters wcsin, wcsout, cache + apphot.txdump - replaced by pdump, available as a hidden task + +astutil.setairmass - new parameters ra, dec, equinox, st, ut, scale + + daophot - new package parameters wcsin, wcsout, wcspsf, and cache + daophot.addstar - new parameters wcsin, wcsout, wcspsf, and cache + daophot.allstar - new parameters wcsin, wcsout, and wcspsf + daophot.daoedit - new parameters cache + daophot.daofind - new parameters wcsout, and cache + daophot.group - new parameters wcsin, wcsout, wcspsf, and cache + daophot.nstar - new parameters wcsin, wcsout, wcspsf, and cache + daophot.peak - new parameters wcsin, wcsout, wcspsf, and cache + daophot.phot - new parameters wcsin, wcsout, and cache + daophot.psf - new parameters wcsin, wcsout, and cache + daophot.substar - new parameters wcsin, wcsout, and cache +.fi + +.nh 2 +Existing Tasks with New Capabilities +.nf + apphot.center - coordinate system support, optional image cacheing + apphot.daofind - coordinate system support, optional image cacheing + apphot.fitpsf - coordinate system support, optional image cacheing + apphot.fitsky - coordinate system support, optional image cacheing + apphot.phot - coordinate system support, optional image cacheing + apphot.polymark - coordinate system support, optional image cacheing + apphot.polyphot - coordinate system support, optional image cacheing + apphot.qphot - coordinate system support, optional image cacheing + apphot.radprof - coordinate system support, optional image cacheing + apphot.wphot - coordinate system support, optional image cacheing + +astutil.setairmass - ra, dec, equinox, st, ut, scale are no longer hardwired + astutil.rvcorrect - more flexibility in setting ut + + daophot.addstar - coordinate system support, optional image cacheing + daophot.allstar - coordinate system support + daophot.daoedit - optional image cacheing + daophot.daofind - coordinate system support, optional image cacheing + daophot.group - coordinate system support, optional image cacheing + daophot.nstar - coordinate system support, optional image cacheing + daophot.peak - coordinate system support, optional image cacheing + daophot.phot - coordinate system support, optional image cacheing + daophot.psf - coordinate system support, optional image cacheing + daophot.substar - coordinate system support, optional image cacheing +.fi + + +.nh +General Package Changes + +.nf +\fBNOAO\fR + + \fBONEDSPEC\fR + More than 999 apertures are now allowed. + + \fBAPPHOT\fR + Coordinate Support: + All the apphot tasks have been modified to accept input coordinates + in the logical, tv, physical, or world systems, and to write output + coordinates in the logical, tv, or physical coordinate systems. One + consequence of this is that the apphot tasks will now work correctly + on image sections in interactive mode. Another is that users can now + work directly on image sections while preserving the coordinate + system of the parent image. + + Image Cacheing Support: + All the apphot tasks which accept image pixel input have been mod- + ified to optional cache the entire input image in memory. Cacheing + may significantly improve the performance of tasks where many random + access operations are performed. + + File and image name directory information removed from output files + All the apphot tasks have been modified to strip directory infor- + mation from the image and coordinate file names written to the output + files, to the terminal, and to the plot headers. The colon commands + will still read and write full image and coordinate file path names. + + New PTOOLS Tasks Added + The ptools package tasks pcalc, pconvert, pdump, prenumber, pselect + and psort were added to the apphot package. The functionality of the + old txdump task as been replaced by the pdump. TXDUMP is still avail- + able as a hidden task. + + \fBASTCAT\fR + The astcat package is a set of tasks for extracting astrometric and + photometric calibration data from remote or local catalogs, filtering + the data, extracting FITS images from remote or local surveys, and adding + standard keywords to the extracted images. There is also a task for + selecting images which contain catalog objects and locating the catalog + objects in the image. + + \fBIMRED.CRUTIL\fR + Cosmic ray detection and removal package. This package includes new + tasks and links to tasks from other package. It replaces the CRUTIL + external package. + + \fBIMRED.QUADRED\fR + Reduction package for QUAD format data. This replaces the ARED.QUAD + and XCCDRED external packages for processing CTIO and ESO FORS1 multi- + amplifier data. + + \fBDAOPHOT\fR + Coordinate Support + All the daophot tasks have been modified to accept input coordinates + in the logical, tv, physical, or world systems, and to write the output + coordinates in the logical, tv, or physical coordinate systems. One + consequence of this is that the daophot tasks will now work correctly + on image sections in interactive mode. Another is that users can now + work directly on image sections while preserving the coordinate + system of the parent image. + + Image Cacheing Support + All the daophot tasks which accept image pixel input have been modified + to optionally cache the entire input image in memory. Cacheing signif- + icantly improves the performance of the tasks when many random access + operations are performed. The cacheing already performed by the + ALLSTAR task is unchanged. + + File and image name directory information removed from output files + All the daophot tasks have been modified to strip directory information + from the image and coordinate file names written to the output files, + to the terminal, and to the plot headers. The colon commands will still + read and write full image and coordinate file path names. + + \fBOBSUTIL\fR + New observing utilities package. This collects tasks from the NMISC, + SPECTIME, PROTO, and NLOCAL external package which are useful to + plan or carry out observations. The new tasks are: + + PSFMEASURE STARFOCUS SPECFOCUS CCDTIME + PAIRMASS SPTIME BITCOUNT FINDGAIN + SHUTCOR + + \fBOBSOLETE\fR + o Added tasks OIMCOMBINE and OIMSTATISTICS which are the previous + versions from V2.113b system + o Deleted the ODISPLAY task +.fi + + +.nh +General Task Changes + +.nf +\fBNOAO\fR + \fBONEDSPEC.SPLOT\fR + Rather than refusing to evaluate errors when there is negative data, + negative data is treated as zero. + + \fBASTUTIL.SETAIRMASS\fR + Modified to have greater flexibility in selecting the keyword defining + the universal time. New parameters define the keywords for RA, dec, + equinox, siderial time, universal time, and astrospheric scale height. + + \fBASTUTIL.RVCORRECT\fR + Modified to have greater flexibility in selecting the keyword defining + the universal time. + + \fBIMRED.ECHELLE.ECIDENTIFY\fR + Help page describes how to externally evaluate the dispersion fcns. + + \fBIMRED.CCREDRED.COSMISRAYS\fR + Task was removed (see CRUTIL) + + \fBNPROTO.FINDGAIN\fR + Task was removed (see OBSUTIL) + + \fBNPROTO.OBJMASKS\fR + This is a new task for detecting objects in an image and creating + an output catalog or pixel mask of found objects. + + \fBTWODSPEC.LONGSLIT.FITCOORDS\fR + - Help page describes the contents of the database and how to ext- + ernally evaluate the fits. + - The RMS is shown in the graph title and in the :show output. + + \fBTWODSPEC.APEXTRACT.APEDIT\fR + When there is just one aperture the background regions are shown + on the graph without needing to enter the 'b' background mode. + + +\fBIMAGES\fR + + \fBTV.DISPLAY\fR + - The mask overlay feature when the displayed image is a reduction of + mask (e.g. a block average) now uses the maximum of all mask pixels + within the display pixel. + - The task will now allow up to 16 frame buffers to be used for the + display if allowed by the server. (Currently requires XIMtool V1.3). + + \fBTV.IMEXAMINE\fR + - A new key 't' allows output of a region centered on the cursor as an + image for further analysis by other programs. + - The task will now allow up to 16 frame buffers to be used for the + display if allowed by the server. (Currently requires XIMtool V1.3). + - Cursor readback will now properly detect the correct image when more + than one image is displayed per frame, e.g. in a mosaic. (Currently + requires XIMtool V1.3). + + \fBIMMATCH.IMCOMBINE\fR + - New parameters "headers", "bpmasks", "rejmasks", "nrejmasks", and + "expmasks" provide additional types of output. The old parameters + "rejmask" and "plfile" were removed. The new "nrejmasks" parameter + corresponds to the old "plfile" and the new "rejmasks" parameter + corresponds to the old "rejmask". + - There is a new "combine" type "sum" for summing instead of averaging + the final set of offset, scaled, and weighted pixels. + - There is a new parameter "outlimits" to allow output of a subregion + of the full output. This is useful for raster surveys with large + numbers of images. + - Additional keywords may appear in the output headers. + - Scaling is now done relative to the first image rather than an average + over the images. This is done so that flux related keywords such as + exposure time and airmass remain representative. + - A median calculation was made faster. + - The previous version is available in the OBSOLETE package. + + \fBIMMATCH.IMCENTROID\fR + \fBIMMATCH.IMALIGN\fR + A new parameter maxshift has been added to the imcentroid and imalign + tasks. Maxshift defines the maximum permitted difference between the + predicted and computed shifts. It is used to reject objects whose + positions have wandered too far from the predicted positions. + + \fBIMMATCH.GEOMAP\fR + \fBIMCOORDS.CCMAP\fR + An iterative rejection capability has been added to the geomap and + ccmap tasks. The new parameter maxiter in combination with the existing + parameter reject define the rejection parameter. The default value of + the reject parameter has been changed from INDEF to 3.0. + + The colon command ":order " has been added to the geomap and ccmap + tasks. The new command enables the user to change all the order parameters + simultaneously when experimenting with different fitting functions. + + \fBIMCOORDS.STARFIND\fR + The starfind task background estimation algorithm has been modified so + that it no longer depends on the value and density of the central pixel. + + \fBIMCOORDS.IMCCTRAN\fR + Support for non-zenithal projections has been added to the imcctran task. + The previous technique of rotating the cd matrix does not work properly + for these functions. The new parameter longpole was added to imcctran. + Longpole enables the user to select either the cd matrix or longpole / + latpole method for transforming zenithal projections. + + \fBIMCOORDS.CCGET\fR + The new task ccget was added to the imcoords package. Ccget extracts + objects in a user specified region from a simple text file catalog. + + \fBIMCOORDS.CCSTD\fR + The task ccstd was added to the imcoords package. Ccstd transforms pixel + and celestial coordinates to standard coordinates and vice versa. + + \fBIMUTIL.HEDIT\fR + The new parameter addonly was added to hedit task. The addonly switch + is used to add a parameter to the image header only if it does not + already exist. The addonly switch has a precedence intermediate between + the add and delete switches. + + \fBIMUTIL.IMSTATISTICS\fR + An interactive rejection capability has been added to the imstatistics + task. The new parameters nclip, lsigma, and usigma define the rejection + parameters. A memory cacheing option was also added to imstatistics in + order to optionally speed up performance if iterative rejection is en- + abled or the midpt/mode is computed. + + \fBIMUTIL.IMEXPR\fR + Support for the bitwise operators or (|), and (&), exclusive or (^), and + not (~) has been added to the imexpr task. The logical operators or (||) + and and (&&) have been made truly logical i.e. they return 0's or 1's, + rather than results of a bitwise or and and. + + +\fBPROTO\fR + \fBMIMSTATISTICS\fR + The new task mimstatistics has been added to the proto package. + Mimstatistics does image statistics through a mask. + + \fBRSKYSUB\fR + The new task rskysub was added to the proto package. Rskysub does a + running mean or median sky subtraction on an ordered list of images + using optional background scaling and object masking. + + \fBMSKEXPR\fR + The new task mskexpr has been added to the proto package. Mskexpr + creates a new mask from a user supplied expression, an optional + reference image, and an optional reference mask. + + \fBMSKREGIONS\fR + The new task mskregions has been added to the proto package. Mskregions + creates a new mask or modifies an existing mask using a list of region + definitions or region expressions. + + +\fBXTOOLS\fR + \fBSKYWCS\fR + A new library skywcs has been added to the xtools package. The skywcs + library is a set of routines for managing image and catalog celestial + coordinate systems and for transforming from one celestial coordinate + system to another. Skywcs is layered on the Starlink Positional + Astronomy library slalib which is installed in the iraf math package. + + \fBCATQUERY\fR + A new library catquery was added to the xtools package. The catquery + library is a set of routines for doing local and remote catalog and + image survey access. + +\fBSYSTEM\fR + \fBHELP\fR + Task was modified to call the XHELP code to run the GUI version of + the task if requested. Task output is the same if the device + remains the default 'terminal' value, however resetting the 'device' + parameter to one of 'gui', 'html', or 'ps' will either spawn the GUI + task under xgterm or print the converted help page to the stdout. + + \fBLROFF\fR + The task was enhanced with a new 'format' parameter that allows the + text to be formatted as one of: plain-text, HTML, or Postscript. +.fi + + +.nh +Parameter File Changes + +In the tables below each parameter change is identified with one of the +following codes followed by task name and the description of the change. +.nf + * n = new parameter + * c = changed/modified parameter + * d = deleted parameter + + +\fBCL\fR + n cl Added the new CL parameter "release". This + is a string valued parameter with values such + as "2.11.3a", "2.12", "3.0" etc. This differs + from "version" which is a descriptive string + such as "NOAO/IRAF V2.11.3 EXPORT". There can + be multiple releases of one version of the + software, and "release" specifies exactly what + build the software is. The release strings are + composed in such a way that they can be used + in expressions, e.g. (release >= 2.11.3) would + be true for IRAF V2.11.3 and all subsequent + releases. + +\fBDATAIO\fR + c dataio.export Made the 'format' parameter automatic mode + c dataio.import Made the 'format' parameter automatic mode + +\fBIMAGES\fR + n imcoords.imcctran Added a new parameter longpole to the imcctran + task. If longpole=yes then coordinate transfor- + mations with zenithal projections will be rot- + ated using longpole rather than the CD matrix. + + c immatch.wregister Fixed boundary option typo, "refect" to "reflect". + c immatch.sregister Fixed boundary option typo, "refect" to "reflect". + + n immatch.imcentroid Added a new parameter maxshift to the imcentroid + immatch.imalign and imalign tasks. Maxshift is the maximum perm- + itted difference between the computed and predicted + shifts. Maxshift can be used to reject objects whose + centers have wandered too far from the expected + center. By default maxshift is undefined. + + n immatch.geomap Added a new parameter maxiter to the geomap and + immatch.ccmap ccmap tasks. Maxiter defines the maximum number of + rejection iterations and has a default value of 0 + for no rejection. + + c immatch.geomap Changed the default value of the ccmap and geomap + c immatch.ccmap parameter reject from INDEF to 3.0. + + c immatch.imcombine Numerous changes, see details above + + c imgeom.imlintran Changed the nrows argument names to nlines + + + n imutil.hedit Added a new addonly parameter to the hedit task. If + addonly is set a new field will only be added to + the image header if it does not already exist. + + n tv.imexamine Added new parameters 'output', 'ncoutput', and + 'nloutput' used by the new 't' keystroke when + outputting an image section centered on the cursor. + +\fBSYSTEM\fR + n help New parameters required for GUI options, output + formats for HTML/PS, printer, etc. + n lroff Added new 'format' parameter for HTML/PS output + +\fBUTILITIES\fR + + c utilities.surfit Added support for the half cross-terms option to + the surfit task. This involved changing the type + of the xterms parameter from boolean (yes/no) to + string (none,half,full). + +\fBNOAO\fR + + \fBASTUTIL\fR + n astutil.setairmass new parameters ra, dec, equinox, st, ut, scale + + \fBDIGIPHOT\fR + n apphot new package parameters wcsin, wcsout, and cache + n apphot.center new parameters wcsin, wcsout, cache + n apphot.daofind new parameters wcsout, cache + n apphot.fitpsf new parameters wcsin, wcsout, cache + n apphot.fitsky new parameters wcsin, wcsout, cache + n apphot.phot new parameters wcsin, wcsout, cache + n apphot.polymark new parameters wcsin, wcsout, cache + n apphot.polyphot new parameters wcsin, wcsout, cache + n apphot.qphot new parameters wcsin, wcsout, cache + n apphot.radprof new parameters wcsin, wcsout, cache + n apphot.wphot new parameters wcsin, wcsout, cache + + n daophot new package params wcsin, wcsout, wcspsf, and cache + n daophot.addstar new parameters wcsin, wcsout, wcspsf, and cache + n daophot.allstar new parameters wcsin, wcsout, and wcspsf + n daophot.daoedit new parameters cache + n daophot.daofind new parameters wcsout, and cache + n daophot.group new parameters wcsin, wcsout, wcspsf, and cache + n daophot.nstar new parameters wcsin, wcsout, wcspsf, and cache + n daophot.peak new parameters wcsin, wcsout, wcspsf, and cache + n daophot.phot new parameters wcsin, wcsout, and cache + n daophot.psf new parameters wcsin, wcsout, and cache + n daophot.substar new parameters wcsin, wcsout, and cache + + + \fBONEDSPEC\fR + n standard new parameter mag, magband, and teff. These + n splot params can be use to specify calibration files + n lcalib as blackbody curves scale to a specified magnitude + + \fBTWODSPEC\fR + c apextract.apall1 Reduced the 'polysep' parameter. + c apextract.apdebug Reduced the 'polysep' parameter. + c apextract.apfit1 Reduced the 'polysep' parameter. + c apextract.apnoise1 Reduced the 'polysep' parameter. + c apextract.apnorm1 Reduced the 'polysep' parameter. + c apextract.apparams Reduced the 'polysep' parameter. +.fi + + + +.nh +Details of Major System Changes + +.nh 2 +FITS kernel changes +.nf + The FITS kernel was modified to add support for storing images in + extensions as compressed pixel masks. The mask is stored as a binary + table using the "ZIMAGE" (compressed image) convention proposed by White, + Greenfield, Pence, and Tody in 1999: + + http://heasarc.gsfc.nasa.gov + /docs/software/fitsio/compression/compress_image.html + + In the current implementation only the "PLIO_1" compression + algorithm is implemented. Mask extensions may be read or written directly + by the kernel. When writing a new extension it will be appended to the + MEF file. To append an image to a MEF file as a mask, include "type=mask" + in the image kernel section when the output image is opened. + + Masks are interfaced to the system as images and may be read and + written like any other image via IMIO. They have a normal image header + and can be manipulated with any program that deals with images. The pixel + type is INT. + + It is also possible to access a mask image as a PLIO mask. An + IMSTATI query for IM_PLDES parameter will return the PLIO mask descriptor. + While a mask extension is opened under IMIO it is represented as a PLIO + mask and may be accessed in this form like any other mask. + + The mask image is stored in the FITS binary table (BINTABLE) + extension when the image is closed, and is loaded from the extension when + the image is opened. The compression representation used to store the + mask in the binary table is the same as is used within PLIO. The new + (V2.12) encoding is used, allowing very large masks to be stored. + Currently masks up to 3D are supported. Data on each 2D mask plane + will be compressed in both X and Y as with PLIO. The depth of the mask + is preserved. + + Although a mask is stored as a binary table the format of the + table is not completely general. In the current implementation there + can be only one column in the table (COMPRESSED_DATA). This is an + integer-valued variable length array column containing, for each line of + the N-dimensional image, the PLIO compressed version of that image line. + The actual compressed data is stored in the heap area of the table. + Multiple image lines may point to the same compressed line list, e.g., + to store the empty line or to compression in Y. +.fi + + +.nh 2 +Large Image Support + + The following changes were made to enable IMIO to use larger buffer +sizes to optimize i/o for large images: + +.nf + The default file buffer size set by IMIO is unchanged: it is still + about 512 MB, the value set for V2.11.2. However, a new parameter + IM_BUFFRAC was added. Both IM_BUFSIZE and IM_BUFFRAC are used to help + determine the FIO buffer size set when an image is opened. The logic + for this is implemented in imsetbuf.x. + + Backwards compatibility. If you do nothing about IMIO/FIO buffers + in your program, the system may transparently use a larger buffer for + larger images. If you set BUFSIZE in your program, the system will + by default use the value you give, or possibly a larger value, if the + image you are accessing is very large. If you set BUFSIZE and you want + to guarantee that the value you set is used (even for very large images) + then you should also set BUFFRAC=0 to ensure that only BUFSIZE is used. + + How it works. BUFFRAC specifies the default FIO buffer size used to + access an image, expressed as a percentage of the size of the image. + For example, the builtin default value of BUFFRAC=10 will try to make a + FIO buffer 10% of the size of the image. The actual value used will be + given by BUFFRAC, but will be at least BUFSIZE, and no more than a builtin + default maximum value, currently 32 MB. Given the builtin defaults, + the buffer size will range from 0.5 to 32 MB depending upon the size of + the image being accessed. As noted above, BUFSIZE and BUFFRAC can be + set to force the buffer size to a specific value if desired. + + Environment variables for both parameters are provided. The names + are "IMIO_BUFSIZE" (specified as bytes) and "IMIO_BUFFRAC" (specified + as a decimal fraction). If defined, these override (at image open time) + the builtin default values for both parameters. An IMSET call by the + application will override all such defaults. + + The FIO buffer allocated will not be larger than the size of the + image. The FIO buffer will also not exceed the maximum size set by + the file driver being accessed. For example, for PLIO images the file + buffer will not exceed about 2KB, even for a very large mask. This is + because the "pixel file" for a PLIO image is dev$null, the driver for + which specifies a maximum i/o buffer size of 2K (the real file to load + or save the mask will use a different descriptor). + + The intent here is to provide an adaptive mechanism for setting the + FIO buffer size used to access an image, which automatically adapts to + the size of the image being accessed. If you access a lot of small + images you will get smaller buffers - everything will be as before. + If you access very large images, you may get large buffers up to the + builtin maximum value of (currently) 32 MB. + + Using large buffers could cause a machine to run out of memory. + However, it is likely that if someone is working on 300 MB images + that they are using a machine which has a memory at least that large + - probably larger. If there are problems, the environment variable + overrides can be used to tune IMIO. + + The reason for large file buffers is to limit the number of disk + data transfers, and hence the number of disk seeks. Using buffers larger + than a certain amount (32 MB is generous) is probably counterproductive. + If the i/o system provides 20 MB/sec i/o transfers, 32 MB will take + 1.6 seconds. This should be more than a large enough granularity to + provide efficient i/o, hence is a reasonable limit (at this point paging + effects are likely to dominate). +.fi + +.nh 2 +Virtual Memory Cache + + The VMcache client interface and daemon provide a method by which +data-intensive IRAF tasks (or non-IRAF tasks for that matter) can manage +how files/images are maintained in virtual memory to avoid excessive system +paging. In essence it's a way to "lock" a specific image in memory to +improve performance. As of this release no tasks in the system have been +modified to make use of the VMcache daemon, however installing it in the +system at this point provides a framework for future applications and +systems development. + + The following notes summarize the changes made for this feature +and describe it's function in more detail. A more complete description of +the interface, environment variables which control it, etc can be found in +the main systems revisions file iraf$local/notes.v211. + +.nf + The source for the developmental version of the VMcache library + and the VMcache daemon (vmcached) have been installed in the + unix$boot tree and the HSI binary file driver was modified to add VMcache + client support. This adds two new capabilities to the driver: 1) + built-in support for direct i/o (on systems that support it), and 2) + a client interface to the VMcache daemon to permit the daemon to + optimally manage binary file i/o if a VMcache daemon is present. + + The vmcached code is complete but only enough debug/testing was done to + support development of the VMcache client interface for IRAF (the vmcached + code is debugged but the new version of the vmcache library code has + not been tested). Since the daemon can be utilized outside the normal + IRAF release we do not have to fully develop it for the release. + + It should be stressed that VMcache is only useful or warranted for + systems that are very data intensive. The standard host operating + system file access heuristics are best for "normal" processing where + either the system is not really busy, or the datafiles are not + excessively large. On systems with very large physical memories + where massive amounts of data are being processed, VMcache can make + a significant difference in overall system performance. + + VMcache is too complex to document here. Without going into the + details, its function is to manage a cache of files in system + virtual memory. Files can be explicitly cached or uncached, or they + can be "accessed", and VMcache will decide whether or not to cache + the file in virtual memory. This is what the VMcache client + interface does: every time it accesses (opens or extends) a file + larger then the VM threshold it sends an "access" directive to the + VMcache daemon. The daemon sends back a response of 0 (file not + cached; use direct i/o to access the file), or 1 (file cached in VM; + use normal VM-buffered i/o to access the file). Even if a file is + not cached the daemon keeps track of all accesses. Files which are + frequently accessed will have a higher priority and are more likely + to be cached in memory. + + The VMcache daemon is a separate system-level program outside of + IRAF. This is necessary to provide a central system-wide cache + controller. It also provides flexibility, allowing multiple + versions of the daemon to exist, e.g., to allow experimentation with + different types of caching algorithms. It also allows easy + customization of the daemon independently of the IRAF applications + using the VMcache client interface. +.fi + + +.nh 2 +New Developer Libraries + +.nf + o Several new libraries are now available for developers: + + \fBPSIO\fR New Postscript text generation library installed in the + sys$psio. The PSIO interface is used to format a block of + text as Postscript output on a page of a given size (Letter, + Legal, A4 or B5). See the psio$README file for details. + + \fBCATQUERY\fR Remote astrometric/photometric catalog access lib installed + in the XTOOLS utility library. + The catquery package provides a set of routines for local + and remote catalog and image survey server access. The sup- + ported catalogs and image surveys are described in records + stored in a catalog and image survey configuration file + respectively. The catalog and image survey records specify + the network address, the query format, and the output format + for each supported catalog or image display server. See + "help catalogs" and "help surveys" for details. + + \fBSKYWCS\fR Sky coordinate transformation library installed in the XTOOLS + utility library. + The skywcs package contains a simple set of routines for + managing sky coordinate information and for transforming from + one sky coordinate system to another. The sky coordinate + system is defined either by a system name, e.g. "J2000", + "galactic", etc., or by an image system name, e.g. "dev$ypix" + or "dev$ypix world". +.fi + + +.nh +System Changes Which May Affect You + +.nf + * \fBSHARED LIBRARY VERSION INCREMENTED\fR (Sun/IRAF only) + The IRAF shared library for SunOS and Solaris platforms has been + incremented with this release due to the nature of various system + changes. Existing IRAF binaries (e.g. locally written software + or external packages) will continue to run using the old shared + image, however they will need to be recompiled against V2.12 in order + to pick up the numerous system bug fixes and features in this release. + In particular, pixel masks produced by V2.12 IRAF tasks may be + incompatible with external packages which have not been recompiled. + + * \fBEXTERNAL PACKAGE RECOMPILATION\fR + The V2.12 release contains changes to the FIO and PLIO/PMIO interface + header files used by numerous applications. Relinking of an external + package may fail to pick up these changes and not recompile a source + file which uses one of these header files if the mkpkg file doesn't + correctly list all of the dependencies (nearly all packages have one + or more mkpkg files which have this problem). In the worst cases + this could lead to a runtime error due to the incompatibilities. + + For this reason we recommend that all packages and local tasks be + recompiled (completely from source* (rather than simply relinked + against the new version) to assure that all changes and new features + will be included. Recompilation also guarantees that packages can + take advantage of some of the larger buffer sizes and optimizations + in this release. Site support can supply a list of missing mkpkg + dependencies for most external packages being developed outside NOAO + that wish to fix these files for a future release. + + * \fBPARAMETER FILE CHANGES\fR + As with all major releases, we recommend that you do a MKIRAF and + delete all your old parameter files after the IRAF upgrade. You may + choose not to do this if you are in the midst of a project and have + setups that may be difficult to reproduce. + + The automatic parameter file update/merge mechanism, which is used + if you do not initialize your parameters with MKIRAF, is based on + file date comparisons. If you run IRAF V2.11 after V2.12 has been + installed, the file dates on your uparm parameter files will be + more recent than the V2.12 installation date. If you then try to + run V2.12, the automatic parameter file merge/update will fail due + to the file dates. The system only updates personal parameter + files which are older than the update date of the system. A + MKIRAF avoids the problem if you delete your parameter files, + causing them to be updated from the system default versions. + + * \fBINSTALLATION SCRIPT CHANGES\fR + As the first step of an ongoing effort to simplify the installation + and system configuration, the IRAF install script was rewritten to + do some error-checking of the iraf setup, present a simplified and + easier to read output, and do some common post-install configuration + of the system. Additionally, the SYSINFO diagnostic script for + finding system errors and reporting on the configuration, and a new + UNINSTALL script for removing IRAF files/links from the system have + also been installed. The old install script is still available as + a fallback in case problems with the new script are found. + + * \fBHELP SYSTEM CHANGES\fR + The HELP task was modified with several new parameters controlling + the display and formatting of the help pages. Help may now be + presented as formatted text (as before), HTML, or fully formatted + Postscript. Additionally, users running under an XGterm window can + use the task in a new GUI mode. The help GUI allows users to browse + the help system and easily search for tasks/topics using a familiar + web-like interface. The GUI mode is not the default, but can be + enabled easily using the 'device' parameter. + + * \fBIMAGE DISPLAY CHANGES\fR + Tasks which display images or interact with the image display were + modified to take advantage of new features added to XImtool V1.3 + (e.g. the multiple WCS and pixel-value readouts and 16 display frame + buffers). These changes were done in a backwards compatible way so + interaction with display servers such as SAOimage, SAOtng, DS9, or + older XImtool versions should be unaffected. If problems are dis- + covered a CL environment variable 'disable_wcs_maps' can be defined + to force all of the old behaviors. These changes do not add any new + functionality to the tasks themselves, only the underlying display + protocols. + + * \fBPLIO Changes\fR + The LEN and BLEN fields of the encoded line list (LL) descriptor + would limit the length of a pixel area (and hence the size of a + pixel mask) to the max size of a signed short, 32768. This was due + to the use of a simple array of type short to encode the line list + (which simplifies handling considerably). Nonetheless the limit to + 32K was unacceptable. The fix adopted was to increase the LL header + from 3 to 7 words. Two 16 bit words are now used to encode each of + LEN and BLEN. A "version" word was added to allow the old, new, and + future encodings to be distinguished. A "hdrlen" word was added to + parameterize the length of the LL header, rather than fix it at + compile time as in the initial version. With this change, the + maximum length of an image line under PLIO is increased from 32768 + to 1073741824 (32768*32768). All the higher level PLIO code is + integer, so should already support larger masks. + + This was done in such a way that old line lists can still be read, + although PLIO will always write out new format line lists (pixel + mask files and images, QPOE, and MWCS all store encoded line lists + in external storage, so backwards compatibility is important; also + existing complied programs will continue to generate the old + format). The cost is 8 bytes per encoded line list. For most masks + this should only increase the size of the mask by a few percent at + most. + + * \fBNEW ENVIRONMENT VARIABLES\fR + The following new environment variables may be defined to tune the + size of the system file i/o buffers used by the image i/o system. + The system will automatically adjust to use larger buffers when + accessing larger images, these variables may be set to further + optimize the buffers + + \fBIMIO_BUFSIZE\fR Size of the FIO buffer size in bytes. + + \fBIMIO_BUFFRAC\fR FIO buffer size expressed as a percentage of + the image size. Actual value will be at least + BUFSIZE and no more than BUFMAX. + + \fBIMIO_BUFMAX\fR Max size of FIO buffer which will override the + 32Mb default. + + + Other miscellaneous environment variables: + + \fBdisable_wcs_maps\fR If defined or set to 'yes', this variable will + force any tasks which interact with the image + display to use the old protocols. + + \fBpspage\fR Variable which is used by the PSIO interface to + set the default page size. Acceptable values + include "letter" (the default) for US Letter, + "legal" for US Legal, and "a4" and "b5" for the + most common European sizes. Pspage can be used + by the new HELP and LROFF tasks to automatically + set the desired Postscript page size. +.fi + +.endhelp diff --git a/doc/v29revs.ms b/doc/v29revs.ms new file mode 100644 index 00000000..0182f263 --- /dev/null +++ b/doc/v29revs.ms @@ -0,0 +1,826 @@ +.PP +.ce +.LG +\fBIRAF Version 2.9 Revisions Summary\fP +.SM +.ce +April 10, 1990 +.sp 2 +.NH +Introduction +.PP +This document summarizes the changes in IRAF version 2.9. This was primarily +a development release intended to support applications software development, +hence the major changes were in the programming environment, although there +are important new features of interest to general users too. Since IRAF V2.9 +is primarily a development release, it is not being released on all platforms, +and it is expected that many sites will not need to upgrade until IRAF V2.10 +is available. Sites interested in obtaining IRAF V2.9 should contact the +IRAF project to determine if the release is available for a particular host +system. At the present time, the release is being made available for all +Sun systems, for VAX/VMS, and for the DECstation running Ultrix. +.PP +What follows is a brief description of some of the new features available +in IRAF Version 2.9. This is not intended to be an exhaustive list, but +rather a brief summary of the major changes since the last +release of IRAF, Version 2.8, released in July 1989. +More detailed revisions notes are available in the system notes file, +\f(CWiraf$local/notes.v29\fR, as well as in the online revisions notes for +the various packages. +.PP +Users looking for information on a particular new package should note that +if the package is not mentioned in these release notes and therefore is not +included in IRAF V2.9, that does not necessarily mean that it is not +available. Most major reduction and analysis packages are now made available +for testing as user installable layered packages before they are included in +the standard distribution. For information on the available add-on packages, +contact the IRAF group, or check the latest \fIIRAF Newsletter\fR. + +.LP +This revisions summary is organized as follows: +.DS +.sp +1.\h'|0.4i'\fBIntroduction\fP\l +.sp +2.\h'|0.4i'\fBIRAF System Revisions\fP\l +.sp +3.\h'|0.4i'\fBIRAF Package Revisions\fP\l +.br +\h'|0.4i'3.1.\h'|0.9i'Changes to the System Packages\l +.br +\h'|0.4i'3.2.\h'|0.9i'Glossary of New Tasks in the IRAF System Packages\l +.br +\h'|0.4i'3.3.\h'|0.9i'Changes to the NOAO Packages\l +.br +\h'|0.4i'3.4.\h'|0.9i'Modifications and Additions to Calibration Data\l +.br +\h'|0.4i'3.5.\h'|0.9i'Glossary of New Tasks in the NOAO Packages\l +.sp +4.\h'|0.4i'\fBProgramming Environment Revisions\fP\l +.br +\h'|0.4i'4.1.\h'|0.9i'Changes to the Programming Utilities\l +.br +\h'|0.4i'4.2.\h'|0.9i'Programming Interface Changes\l +.DE + +.NH +IRAF System Revisions +.NH 2 +IEEE to native floating point conversions +.PP +Support has been added to the programming interfaces (\(sc4.2.3) for +converting between the IEEE floating point and native floating point data +formats, including both single and double precision. The FITS programs +in DATAIO (\(sc3.1.1) make use of this, allowing floating point data to +be exchanged in FITS format without having to convert to type integer. +.NH 2 +World coordinate system support +.PP +A major new VOS interface MWCS has been added to support general world +coordinate systems (WCS) and transformations thereon (\(sc4.2.1). +This includes support for linear, piecewise linear or sampled WCS, +and general nonlinear WCS such as the tangent plane or gnomonic projection. +.PP +If a FITS image is read into the system which has WCS information in the +header, the WCS will be retained in the IRAF image header and can be used +in coordinate transformations. The IMAGES tasks which move pixels around +have been modified to edit the WCS to reflect the transformation (\(sc3.1.2). +The image i/o system will automatically propagate the WCS of an image to a +new copy of the image, and will edit the WCS as necessary if an image +section is copied (this applies to all IRAF tasks which operate upon images). +The task RIMCURSOR in the LISTS package has been rewritten to add support +for coordinate transformations (\(sc3.1.3), and can be used, e.g., to read +out the RA and DEC of objects on the image display using the image cursor, +if the image has the necessary WCS information in the image header. +.PP +Full integration of the new world coordinate facilities into all the IRAF +applications, e.g., the graphics tasks and the spectral reduction packages, +will take a year or longer due to the amount of software involved. In V2.9 +the IRAF spectral packages have not yet been converted to use MWCS, and if +MWCS is enabled it could alter the normal behavior of these packages. +\fIIRAF V2.9 is therefore shipped with MWCS disabled\fR. What "disabled" +means is that WCS information in the image headers is not edited to +reflect operations involving image sections, or geometric transformations +of images. Tasks such as RIMCURSOR which use an already existing WCS will +still work whether or not header editing is disabled. If the spectral tasks +will not be used and it is desired that world coordinates be propagated +correctly in image transformations, MWCS header editing can be enabled in +either of the following ways. +.PP +The MWCS transformations are disabled by defining the variable "\f(CWnomwcs\fR" +in the IRAF environment. To globally enable MWCS by default for everyone +using the system, edit the file "\f(CWhlib$zzsetenv.def\fR" and comment out the +following line as shown (you want to add the leading \f(CW#\fR, which will +be missing in the distributed version): +.DS +\f(CW#set nomwcs = yes\fR +.DE +To enable MWCS header editing temporarily, for the current IRAF run: +.DS +\f(CWcl> reset nomwcs = no\fR +.DE +.LP +Detailed information on the coordinate systems defined by MWCS can be +obtained in the online system with the command +.DS +\f(CWcl> phelp mwcs$MWCS.hlp fi+\fR +.DE +Additional information is also given in the help page for RIMCURSOR. +.NH 2 +IMFORT changes +.PP +The IMFORT interface (host level Fortran or C interface to the IRAF image +format) has undergone the following bug fixes and enhancements: +.RS +.IP \(bu +A couple of bugs associated with the IMDIR (image pixel-file directory) +feature introduced in IRAF V2.8 have been fixed. +.IP \(bu +Image clobber checking has been added. By default, if you create a new +image and another image with the same name already exists, the image create +will now return an error code leaving the existing image unchanged. +To override clobber checking in IMFORT programs, restoring the previous +behavior of the interface, define "\f(CWclobber\fR" in your host environment. +.IP \(bu +IMFORT will now perform a limited filename translation service using the +IRAF VOS filename translation code. This should allow most IRAF filenames +to be used as input to host level IMFORT programs. Full VOS filename mapping +is not provided, but filenames containing upper case characters and +multiple "." delimited fields should be translated as in IRAF programs. +.IP \(bu +On systems with multiple architecture support (e.g., Sun, Convex) the FC +task, used to compile and link IMFORT programs from within the IRAF +environment, is now a script rather than a simple foreign task front end +to XC. The purpose of the script is to see that all the necessary IRAF +and host level command line switches and environment definitions +(\f(CWIRAFARCH\fR, \f(CWFLOAT_OPTION\fR, etc.) are used. +Previously, users had to make these environment definitions manually, +and if they forgot the IMFORT program could fail to link or execute. +.IP \(bu +On most UNIX/IRAF systems, the host library \f(CW-lU77\fR is now searched +automatically by FC when an IMFORT program is linked. This library is +not used by any of the IRAF code, but is required to link some Fortran +programs that might want to use IMFORT. +.RE +.LP +Users are encouraged to use FC to link their IMFORT programs. It is possible +to manually link against the IRAF libraries if you know what you are doing, +but the location of the libraries and the required host level command line +switches vary for different systems and for different architectures of a +single system, and it is easy to make mistakes. +.NH 2 +MKIRAF now copies login.cl to login.cl.OLD +.PP +On UNIX/IRAF systems, the MKIRAF command will now copy any existing +\f(CWlogin.cl\fR file to \f(CWlogin.cl.OLD\fR, so that, for example, you +can more easily merge any custom changes back in after running MKIRAF. +On VMS/IRAF systems a new file version is created, as before. +.NH 2 +Local additions to termcap/graphcap +.PP +The termcap and graphcap device capability files have been reorganized with +a section at the top for local additions. It is recommended that any locally +added entries be made in this area, to simplify future system updates. +The local additions can then be simply transferred to the new version of +the file when a new version of IRAF is installed (any entries which are +modified versions of standard entries should always be checked to see if +anything has changed in the distributed version). +.NH 2 +BIN directories now smaller +.PP +On systems with multiple architecture support, the architecture save file +\f(CWOBJS.arc\fR stored in the BIN directory for each architecture is now +maintained as a compressed file. In a typical case this reduces the size +of the file by about a factor of two, saving 1-2 Mb of disk space in each +BIN directory. +.NH 2 +Various system buffers increased in size +.PP +The layered software support in IRAF V2.8 (\f(CWextern.pkg\fR and all that) +had a problem with very long \f(CWhelpdb\fR environment strings, limiting the +number of external packages which could be defined. To fix this problem, +various buffers were increased in size all over the system. The +maximum length of an environment variable such as \f(CWhelpdb\fR is now 960 +characters (12 80 character lines of text). String parameters to tasks can +also be larger, and the system is more resistant to problems when size limits +are exceeded. Foreign task commands, OS escapes, etc., can all be larger now. +The current limit on such strings is about 1024 characters, and is defined +at sysgen time by the new system parameter \f(CWSZ_COMMAND\fR in +\f(CWhlib$iraf.h\fR. +.NH 2 +Shared library versions +.PP +The Sun/IRAF shared library mechanism was modified to add support for shared +library versions. The result is that when you install IRAF V2.9, which has a +different shared library than V2.8, any local programs or other layered +software linked under V2.8 will continue to run, because both the old V2.8 +shared library and the new V2.9 shared library are included in V2.9 (with +different version numbers). Although old programs will continue to run with +V2.9, it is recommended that they be relinked eventually to take advantage +of the many features and bug fixes provided by V2.9. In the case of very +large packages, e.g., STSDAS 1.0, it may be wise to wait until the latest +release can be obtained and installed before relinking, as the old version +will not have been tested under IRAF V2.9 (which of course, didn't exist +back then). +.NH 2 +File pager enhancements +.PP +The system file pager, used in the PAGE task, the new PHELP task, +and other places, has undergone the following enhancements. +.RS +.IP \(bu +The N and P keys, used to move to the next or previous file when paging a list +of files, now have a dual meaning: when paging a \fIsingle\fR file containing +multiple formfeed delimited pages, the keys will move to the next or previous +\fIpage\fR in the file. This feature is used in the new PHELP task to page +a large file containing, e.g., all the HELP pages for a package. +.IP \(bu +A limited upscrolling capability is now supported, e.g., if you hit the 'k' +key while in the pager, the screen will be scrolled up one line in the file +being paged. This feature may not be supported for some terminals, in which +case the entire screen is redrawn at the new file location. +.RE +.NH 2 +STF image kernel enhancements +.PP +Extensive work has been done on the STF image kernel in this release (the +STF kernel allows IRAF to access the Space Telescope image format directly). +The changes included the following. +.RS +.IP \(bu +Header file caching. STF images often have quite large FITS headers which +can be time consuming to read. A header file caching scheme is now used to +optimize the kernel in cases where the same imagefile is repeatedly accessed, +e.g., when successively reading each element of a large group format image. +By default up to 3 header files will be cached; this default should be +fine for most applications. If necessary the number of cache slots can be +changed by defining the integer variable "\f(CWstfcache\fR" in the IRAF +environment (the builtin maximum is 5 cached headers per process). +.IP \(bu +\fIThe semantics of the kernel regarding header updates have changed\fR. +STF images differ from other IRAF images in that they may consist of a +group of images all in the same file, with each individual image having +its own header (the group header), plus a single global FITS header shared +by all images in the group. This is no problem in a read operation, +but in a write or update operation there can be problems since parameters +cannot be added to or deleted from the individual group headers. +The new semantics regarding STF image header updates are as follows: +1) when updating the header of a multigroup image (not recommended) only +the group header is updated, and attempts to add new parameters are +ignored; 2) when updating the header of an image containing a single group, +both the group header and the FITS header are updated. +.sp +As a result of these changes, the behavior of a single group STF image is +now identical to that of a regular IRAF image. It is recommended that +multigroup STF images be treated as read only if possible, creating only +single group images during interactive processing (except when running a +program that is explicitly designed to create multigroup images). +.IP \(bu +The kernel was modified to work with the new MWCS (world coordinate system) +interface. The image section transformation is now performed by MWCS rather +than by the STF kernel. +.IP \(bu +A number of minor changes were made to the way the group parameter block (GPB) +cards are maintained in the IRAF image descriptor. The comments on GPB +definition cards are now preserved. Restrictions on the grouping of GPB +cards in the header have been removed. +.IP \(bu +A number of bugs were fixed and restrictions removed, e.g., the size of a +header is no longer limited to 32767 characters (404 lines). +.RE +.LP +The IRAF core system and NOAO science applications were extensively tested +with both single and multigroup STF images using the new kernel, and we now +feel that it is safe to use the STF image format with these tasks, +although the regular format is preferred if there is no special reason to +use the STF format (the regular format is more efficient). +.NH 2 +QPOE (event list image format) enhancements +.PP +The QPOE image kernel, used for event list data (photon counting detectors, +e.g., X-ray satellites such as ROSAT) underwent the following changes. +.RS +.IP \(bu +MWCS (world coordinate system) support has been added (\(sc4.2.2). This +provides a consistent coordinate system despite, e.g., the blocking factor, +rect, or image section used to construct an image matrix from an event list. +.IP \(bu +When opening a QPOE file as an IRAF image, the runtime filter expression +used to create the image matrix is now saved in the parameter \f(CWQPFILT\fIn\fR +in the image header (multiple cards are used for long expressions). +.IP \(bu +Region masks of arbitrary complexity and size can now be used to mask the +event list when reading time-ordered or unordered (unindexed) event lists. +This is done using the new PLRIO package (\(sc4.2.5) which provides the +capability to efficiently random access large image masks of arbitrary +complexity. +.IP \(bu +Unmatched brackets, braces, or parentheses are now reported as an error by +the filter expression parser (this can occur even with a valid expression, +e.g., due to truncation of the expression string). A reference to an +undefined keyword, e.g., due to a spelling error, is now detected and reported +as an error. Any errors occurring during expression parsing will now result +in termination of the calling task, unless caught in an error handler. +.IP \(bu +A number of bugs were fixed. +.RE +.NH 2 +Changes affecting image display in VMS/IRAF +.PP +A new version of Nigel Sharp's UISDISPLAY program, for image display on +VMS systems running UIS, has been installed in "\f(CWiraf$vms/uis\fR". +An executable for an early version of the SAOIMAGE display program for the +X window system, written by Mike VanHilst (SAO), and ported to VMS by Jay +Travisano (STScI) has been placed in the directory "\f(CWiraf$vms/x11\fR". +An executable for a VMS version of XTERM (the X window terminal emulator, +ported to VMS by Stephan Jansen), is also in this directory. We wanted our +VMS users to have access to these programs, although more development work +and testing is needed before we can offer good support for X window based +image display and graphics on VMS. A more comprehensive package providing +enhanced capabilities should be available as an add-on later this year. + +.NH +IRAF Package Revisions +.PP +The most notable changes to the tasks in the IRAF packages are summarized +below. Further information may be obtained by reading the help page for each +task, or by paging the revisions file for a particular package. +For example, to page the revisions for the DATAIO package: +.DS +\f(CWcl> phelp dataio.revisions op=sys\fP +.DE +.NH 2 +Changes to the System Packages +.NH 3 +Modifications to tasks in the DATAIO package +.IP \(bu +The RFITS and WFITS tasks have been modified to add support for the IEEE +floating point format. The "bitpix" parameter in WFITS can be set to -32 +or -64 to specify real or double precision IEEE floating numbers on output. +RFITS recognizes these same values in the bitpix keyword in the FITS header +on input and converts the data accordingly. Note that this option must be +selected by the user as the defaults for writing a FITS tape have not changed. +The user is cautioned that support for the IEEE floating formats is a new +feature of FITS and may not be supported by all FITS readers. +.IP \(bu +RFITS was modified so that the "iraf_file" parameter can be a list of +output images or a image root name. +.NH 3 +Modifications to tasks in the IMAGES package +.IP \(bu +MWCS (world coordinate system) support was added to those tasks in the +IMAGES package which change the geometry of an image, i.e., +IMSHIFT, SHIFTLINES, MAGNIFY, IMTRANSPOSE, IMCOPY, BLKREP, BLKAVG, ROTATE, +IMLINTRAN, REGISTER, and GEOTRAN (REGISTER and GEOTRAN only support simple +linear transformations). If one of these tasks is used to linearly transform +an image, the world coordinate system (WCS) in the image header will be +updated to reflect the transformation. Note that MWCS is disabled by default +in IRAF V2.9, and must be explicitly enabled to allow these tasks to edit +the image header to update the WCS (see \(sc2.2). +.IP \(bu +The IMSTATISTICS task was modified. The "verbose" parameter was renamed +"format" with the default being set to "yes" (fixed format with column labels). +Otherwise the fields are printed in free format with 2 blanks separating +the fields. The name of the median field has been changed to "midpt". +.IP \(bu +The IMHISTOGRAM task has a new parameter called "hist_type" that gives +the user the option of plotting the integral, first derivative, or +second derivative of the histogram instead of the normal histogram. +.NH 3 +Modifications to tasks in the LISTS package +.IP \(bu +The RIMCURSOR task in the LISTS package was completely rewritten to add +MWCS support, so that coordinates may be output in any user specified +coordinate system defined by the WCS information in the image header of +the reference image. For example, if an image with a TAN projection WCS +is loaded into the image display, RIMCURSOR may be used to print the right +ascension and declination at the location defined by the image cursor. +Refer to the help page for details. +.NH 3 +Modifications to tasks in the PLOT package +.IP \(bu +A new graphics kernel task IMDKERN (written by Zolt Levay at STScI) has been +added to the PLOT package. The new graphics kernel allows the graphics +output of any task to be plotted as a graphics overlay on the image display. +As with the other graphics kernels, this may be done by calling the IMDKERN +task directly, but is more often done by specifying the image display +(e.g., device "\f(CWimd\fR") as the output device when running a graphics task. +Refer to the help page for details. +.IP \(bu +The CONTOUR task was modified so that it could be used with IMDKERN to +overlay contour plots on the image display. +If the parameters \f(CWfill=yes\fP and \f(CWperimeter=no\fP are set +the contour plot is scaled to fill the entire device viewport and all +axis and plot labeling is disabled. If the image being displayed also +fills the entire device viewport (display frame) then the contour plot +will be drawn to the same scale as the displayed image. +Refer to the help page for details. +.IP \(bu +Several tasks in the PLOT package were modified to allow use with image +specifications containing brackets, e.g., group format images, QPOE +filter expressions, and image sections. The tasks modified were PROW, +PROWS, PCOL, PCOLS, SURFACE, and CONTOUR. +.IP \(bu +An option was added to the PVECTOR task to output the vector (cut through +the image at an arbitrary angle and center) as a text file or image, +rather than plotting the vector. +.NH 3 +Modifications to tasks in the SYSTEM package +.IP \(bu +A new task PHELP (paged help) was added to the SYSTEM package. +PHELP is a script task front end to HELP which collects the output of HELP +in a scratch file and pages it with the system pager, allowing one to +randomly skip around to read the help text. Note that paging of all the +help pages in a package is supported, e.g., +.DS +\f(CWcl> phelp images.*\fR +.DE +would page all the help files for the IMAGES package. +.IP \(bu +The NEWS task was completely rewritten, and is now used to page the +revisions summary for the current and previous releases. In other words, +one can now type NEWS to find out what is new in the current release. +.IP \(bu +The GRIPES task was modified to send mail to +\f(CWiraf@noao.edu\fP or \f(CW5355::iraf\fP. +The IRAF site administrator may want to check this script for compatibility +with the local mail system. +.RE +.NH 2 +Glossary of New Tasks in the IRAF System Packages +\fR +.TS +center; +c c c c c +l c l c lw(4i). +Task Package Description +_ + +imdkern - plot - Image display device (IMD) graphics kernel +news - system - Summarize what is new in the current release +phelp - system - Paged HELP: collects and pages the output of HELP +rimcursor - lists - Read image cursor position in world coordinates +.TE + +.NH 2 +Changes to the NOAO Packages +.NH 3 +New NOAO Packages +.PP +A new package ARTDATA, used to generate artificial data, has been added +to the NOAO packages. ARTDATA includes tasks for the generation of star +fields, optionally containing galaxies, and one and two dimensional spectra +as well as simple test pattern images. +The tasks GALLIST and STARLIST provide many options for producing lists +of galaxies or stars that can then be used by the task MKOBJECTS to produce +output images. The tasks MK1DSPEC and MK2DSPEC provide tools for making +artificial spectral data. The task MKNOISE allows the user to add readout +noise, poisson noise and/or cosmic ray events to new or already +existing images. The task MKPATTERN allows the user to make images +from a choice of patterns. +.NH 3 +Modifications to Existing NOAO Packages +.NH 4 +The ASTUTIL package +.IP \(bu +The task SETAIRMASS in the ASTUTIL package was modified so that it now +precesses the coordinates to the epoch of the observation. +.NH 4 +The DIGIPHOT.APPHOT package +.IP \(bu +A new task APTEST was added to the DIGIPHOT.APPHOT package that +tests the execution of the package. Output files are generated that +the user can review. +.IP \(bu +Two new parameters were added to DATAPARS, "datamin" and "datamax". +Pixels outside this range are rejected from the sky fitting algorithms +and from the non-linear least square fits in FITPSF and RADPROF. +.IP \(bu +An "update" parameter was added to all of the APPHOT tasks. If the +"verify" parameter is set to "yes" and the task is run in noninteractive +mode \f(CWupdate=yes\fP will update the critical parameters in their +respective parameter sets. +.IP \(bu +Four new parameters, "airmass", "xairmass", "filter", and "ifilter", +were added to the DATAPARS task. These parameters provide the user the +option of having the filter and airmass quantities from the image +headers to be carried over into the APPHOT database files for later +transmission to calibration programs. +.IP \(bu +A new algorithm "mean" was added to the sky fitting options. +.IP \(bu +A setup menu mode was added to all the APPHOT tasks. When the user types +"i" in interactive mode a setup menu is presented rather than a fixed +set of predefined commands. +.NH 4 +The IMRED.IRRED package +.IP \(bu +The APSELECT +task (from the APPHOT package) has been made visible. +.IP \(bu +The image i/o +for IRMOSAIC, IRALIGN, IRMATCH1D, and IRMATCH2D has been optimized +so things should run much faster. There is now an option to trim +each section before insertion into the output image. The actions of +these tasks can now optionally be output to the terminal. +.NH 4 +The IMRED.MSRED package +.IP \(bu +A task called MSBPLOT was added to the IMRED.MSRED package. +This task allows the user to plot a range of lines in multispec images in batch +mode. +.NH 4 +The ONEDSPEC package +.IP \(bu +Several modifications were made to the ONEDSPEC package. These changes +affect all of the IMRED packages that include these tasks as well. +.IP \(bu +The equivalent width measurement using the "e" keystroke in SPLOT +is now computed using the ratio of the spectrum to the continuum. The +previous approximation is included in the logfile for comparison. +.IP \(bu +The DISPERSION task will now add CD\fIi\fR_\fIj\fR (CD matrix) keywords to +the image header as an alternative way of expressing the dispersion function. +If the keywords W0 and WPC or CRVALn and CDELTn +are not in the image header the tasks reading this information for +setting the wavelength (IDENTIFY, SENSFUNC, SPLOT, and SPECPLOT) will +look for the CD\fIi\fR_\fIj\fR keywords. This change should have no affect +on the NOAO applications but provides compatibility with STSDAS applications +using the new MWCS interface provided with IRAF version 2.9. +.IP \(bu +The call to the CALIBRATE task in the script task BATCHRED was modified so that +the "extinct" parameter is always set to "yes". Since CALIBRATE checks to +be sure the data has not been previously extinction corrected this simple +change provides more flexibility. +.NH 4 +The PROTO package +.IP \(bu +Two new tasks, IMALIGN and IMCENTROID, were added to the package. IMCENTROID +computes a set of relative shifts required to register a set of images. +The task IMALIGN both computes the shifts and aligns the images. +.IP \(bu +The JOIN task (previously a simple script) has been replaced by a compiled +version which removes many of the restrictions of the previous version. +.IP \(bu +The IR tasks have been modified as mentioned above under the IMRED.IRRED +section (\(sc3.3.2.3). +.IP \(bu +The TVMARK task was modified to permit deletion (the "u" key) +as well as addition of +objects to the coordinate file. Another cursor keystroke, the "f" key, +was added allowing the user to draw a filled rectangle. +.NH 4 +The TWODSPEC.LONGSLIT package +.IP \(bu +Tasks in the TWODSPEC.LONGSLIT package that are used for setting +wavelength information (EXTINCTION, FLUXCALIB, and TRANSFORM) +were modified for the CD\fIi_j\fR keywords as outlined above for ONEDSPEC. +.NH 2 +Modifications and Additions to Calibration Data +.PP +The calibration data used by some of the tasks in the TWODSPEC, +ONEDSPEC, and many of the IMRED packages are kept in a directory +called ONEDSTDS in \f(CWnoao$lib\fR. The current contents of this directory +are best summarized by paging through its README file, e.g., +.DS +\f(CWcl> page noao$lib/onedstds/README\fP +.DE +.PP +A new directory \(CWspec50redcal\fR in "\(CWnoao$lib/onedstds\fR" +has been added containing flux information for standard stars. +The data in this list are from Massey and Gronwall, Ap. J., July 20, 1990. +.NH 2 +Glossary of New Tasks in the NOAO Packages +\fR +.TS +center; +c c c c c c +l c l c lw(3.5i). +Task Package Description +_ + +aptest - apphot - Run basic tests on the apphot package tasks +gallist - artdata - Make an artificial galaxies list +imalign - proto - Register and shift a list of images +imcentroid - proto - Compute relative shifts for a list of images +mk1dspec - artdata - Make/add artificial 1D spectra +mk2dspec - artdata - Make/add artificial 2D spectra using 1D spectra templates +mknoise - artdata - Make/add noise and cosmic rays to 1D/2D images +mkobjects - artdata - Make/add artificial stars and galaxies to 2D images +mkpattern - artdata - Make/add patterns to images +msbplot - msred - Batch plots of multispec spectra using SPLOT +starlist - artdata - Make an artificial star list +.TE + +.NH +Programming Environment Revisions +.NH 2 +Changes to the Programming Utilities +.NH 3 +MKPKG changes +.PP +The MKPKG utility can now substitute the contents of a file back into the +input stream, as a special case of the macro replacement syntax. +For example, the sequence +.DS +\f(CWabc$(@file)def\fR +.DE +would be translated as +.DS +\f(CWabc10def\fR +.DE +if the file "\fIfile\fR" contained the string "10". The replacement is +performed by inserting the contents of the file back into the input stream, +replacing sequences of newlines, spaces, or tabs by a single space, and +omitting any trailing whitespace. +.PP +The "-p " argument to MKPKG, XC, and so on loads the environment of the +named package \fIpkg\fR, to define the package environment variables, load +the mkpkg special file list, define the directories to be searched for global +include files and libraries, and so on. Multiple "-p" arguments may be given +to load multiple package environments. What is new is that if \f(CWpkglibs\fR +is defined in the environment of a package to list the package library +directories to be searched (the usual case), and multiple package environments +are loaded, successive redefinitions of \f(CWpkglibs\fR will \fIadd\fR to +the list of directories to be searched, rather than redefining the old list +as each new package environment is loaded. For example, if two package +environments are loaded, and each defines its own library, both libraries +will be searched. +.NH 3 +Generic preprocessor +.PP +A minor change was made to the generic preprocessor which affects how strings +such as "FOO_PIXEL" are translated. In the usual case, the preprocessor +replaces all occurrences of "PIXEL" by "int", "real", or whatever the actual +datatype is. The translation is now context sensitive. Rather than +translating "FOO_PIXEL" as "FOO_int" (e.g., "MII_PIXEL" -> "MII_int"), the +type name will now be output in upper case if the rest of the name in which +it occurs is upper case. Hence, a string such as "MII_PIXEL" will now be +translated as "MII_INT". This allows the use of generic constructs to +symbolize SPP macros. +.NH 3 +SPP changes +.PP +The language constant ARB, formerly defined as 32767, is now treated +differently depending upon how it is used. In a declaration of an array +argument, ARB is replaced in the output Fortran by a "*", e.g., +"\f(CWint data[ARB]\fR" becomes "\f(CWINTEGER DATA(*)\fR". In an executable +statement, ARB is replaced by a very large ("arbitrarily" large) integer +value, e.g., to define a DO-loop which is to loop an arbitrary number of +times. If ARB is mistakenly used to dimension an array which is a local +variable rather than an argument, the SPP translator will now detect and +report the error. +.NH 3 +Interactive development and the process cache +.PP +Whenever a CL task is run and the process containing the task is already +idling in the CL process cache, the CL will now check to see if the modify +date on the process executable has changed, and restart the process if the +executable has been modified. For example, when doing software development +from within the CL and a process is alternately relinked and tested, the +CL will now automatically detect that the process has been relinked and will +run the new process, without any need to manually flush the process cache. +.NH 2 +Programming Interface Changes +.NH 3 +New MWCS interface (world coordinate system support) +.PP +A major new VOS interface MWCS, providing general facilities for +linear and nonlinear world coordinate systems, has been added to +the programming environment and is used in IRAF V2.9 in IMIO, IMAGES, and +other parts of the system. MWCS is intended for use in scientific +applications as well as in system code such as IMIO, hence is of potential +interest to anyone developing software within the IRAF environment. +The source directory is "\f(CWmwcs\fR" and the interface is documented in the +file "\f(CWmwcs$MWCS.hlp\fR". Users should be aware that, although the new +interface addresses the general WCS problem and has been carefully designed, +a second version of the interface is planned and the current interface is +not yet a "frozen" interface. +.NH 3 +QPOE interface changes +.PP +The QPOE (event list image) interface has been extended to add routines to +store MWCS objects in the QPOE header. By default, there is one MWCS per +QPOE file, stored encoded in a machine independent binary format in a +variable length array \fIqpwcs\fR of type \fIopaque\fR. The new routines +are as follows: +.DS +.TS +n. +mw = qp_loadwcs \&(qp) +qp_savewcs \&(qp, mw) +mw = qpio_loadwcs \&(io) +.TE +.DE +.LP +The routines \fIqp_savewcs\fR and \fIqp_loadwcs\fR merely save a MWCS in the +QPOE header, or load a previously saved one. The QPIO (event i/o) routine +\fIqpio_loadwcs\fR is like \fIqp_loadwcs\fR, except that it will also modify +the Lterm of the MWCS to reflect any blocking factor or "rect" specified in +the filtering expression when the event list was opened. The new routine is +called automatically by QPF and IMIO whenever a QPOE event list is opened +under image i/o, making the physical coordinate system of the image matrix +the same as physical event coordinates. +.PP +The calling sequences of the \fIqp_add\fR and \fIqp_astr\fR routines, used +to conditionally add or update header parameters, have been changed (so far +as we could determine very few programs exist yet which use these routines, +so we decided to risk an interface change). The change made was to add a +\fIcomment\fR argument. This change was motivated by the observation that +people would not use the routines but would instead use lower level routines, +in order to be able to set the comment field if the parameter has to be added +to the header. +.NH 3 +IEEE support routines added +.PP +Routines for IEEE floating to native floating conversions have been added to +the MII and OSB interfaces. The new MII routines are as follows: +.DS +.TS +n. +nelem = miiread[rd] \&(fd, spp, maxelem) +miiwrite[rd] \&(fd, spp, nelem) +miipak[rd] \&(spp, mii, nelems, spp_datatype) +miiupk[rd] \&(mii, spp, nelems, spp_datatype) +.TE +.DE +.LP +The \fImiiread\fR and \fRmiiwrite\fR routines are like their FIO +counterparts, except that they are used only with data of the indicated +type, and perform the IEEE to native floating conversion (or vice versa) +as part of the i/o operation. The \fImiipak\fR and \fImiiupk\fR routines +pack (native\(->IEEE) and unpack (IEEE\(->native) arrays of the indicated +type. +.PP +The lowest level conversion routines are the OSB routines, which are what +the MII routines use to perform the lowest level translation. +.DS +.TS +n. +ieepak[rd] \&(datum) +ieeupk[rd] \&(datum) +ieevpak[rd] \&(native, ieee, nelem) +ieevupk[rd] \&(ieee, native, nelem) +iee[sg]nan[rd] \&(NaN) +.TE +.DE +.LP +The \fIieepak\fR and \fIieeupk\fR routines transform a single scalar value +in place, while the \fIieevpak\fR and \fIieevupk\fR routines transform +vectors (note that the package prefix is "iee", not "ieee"). In-place +vector conversions are permitted. Since IRAF does not support the IEEE +not-a-number formats, \fINaN\fR, \fIInf\fR etc. values are converted to a +legal native floating value on input. The native floating value to which +\fINaN\fRs are mapped (default zero) may be globally set with \fIieesnan\fR. +.PP +On some systems, e.g., the VAX, the low level conversion routines may be +written in assembler or machine dependent C. If so, the source file actually +used by the system will be found in the "\f(CWhost$as\fR" directory. +.NH 3 +New routine GETLLINE added to FIO +.PP +A new routine \fIgetlline\fR (get long line) has been added to FIO. This +is similar to \fIgetline\fR, except that it will reconstruct arbitrarily +long newline delimited lines of text, whereas \fIgetline\fR returns at most +SZ_LINE characters. +.DS +nchars = getlline (fd, outstr, maxch) +.DE +.LP +The new routine should not be confused with the old routine \fIgetlongline\fR, +a higher level routine which performs a similar function, but which also +ignores comment lines and help blocks, and maintains a line counter. +.NH 3 +Modifications to PLIO/PMIO +.PP +A new routine \fIp[lm]_sectnotconst\fR has been added to PLIO and PMIO +(the pixel list and image mask interfaces). As the name suggests, the +routine tests whether a given rectangular section of the mask is all at +the same value, and if so returns the mask value as an output argument. +.DS +bool = pl_sectnotconst (pl_src, v1, v2, ndim, mval) +.DE +.LP +A new subpackage PLRIO has been added. This is used to efficiently random +access any 2D plane of an existing pixel list or image mask. +.DS +.TS +n. +plr = plr_open \&(pl, plane, buflimit) +plr_setrect \&(plr, x1,y1, x2,y2) +mval = plr_getpix \&(plr, x, y) +plr_getlut \&(plr, bufp, xsize,ysize, xblock,yblock) +plr_close \&(plr) +.TE +.DE +.LP +The mask is opened for random access on a special descriptor which incorporates +a scaled, active 2D lookup table. Most subsequent \fIplr_getpix\fR calls +will return the given mask value directly from the table with +very little overhead; only if the referenced pixel occurs in a region +too complex to be described by a single table entry is the value +computed by direct evaluation of the mask. A special 2D binary +recursive algorithm (using \fIpl_sectnotconst\fR above) with log2(N) +performance is used to calculate the scaled lookup table. These +algorithms provide efficient table generation and random mask pixel +access even for very large masks. diff --git a/doc/vmsiraf.hlp b/doc/vmsiraf.hlp new file mode 100644 index 00000000..91530ee5 --- /dev/null +++ b/doc/vmsiraf.hlp @@ -0,0 +1,681 @@ +.help install Aug86 "VMS/IRAF Installation Guide" +.sp 3 +.ce +\fBVMS/IRAF Installation and Maintenance Guide\fR +.ce +(draft) + +.ce +Doug Tody +.ce +February 22, 1986 +.ce +(revised August 17, 1986 for VMS/IRAF V2.3) + +.nh +Introduction + + The initial port of IRAF to VMS was carried out primarily by Fred +Rommelfanger and Jay Travisano at STScI beginning in the fall of 1984. +Fred and Jay implemented the VMS/IRAF kernel and are the real experts on the +functioning of that part of the system, although VMS/IRAF is now supported +solely by NOAO. The VMS version of IRAF was installed on the NOAO VAX-8600, +which runs VAX/VMS, in the fall of 1985. Much work has been done on both +the UNIX and VMS versions of the system since that time, and the VAX 8600 +running VMS/IRAF is now the primary data processing facility at NOAO/Tucson. +All IRAF software development continues to be done on UNIX/IRAF, with new +software continually moving from UNIX/IRAF to VMS/IRAF at weekly or even +daily intervals. + +The distribution tape is a snapshot of our local VMS/IRAF system. +The device and system configuration tables come configured for our system, +hence will have to be modified as part of the installation process. +These modifications are discussed in detail in this document. To simplify +the installation process as well as future upgrades, we have tried to isolate +the site dependent files to the minimum number of directories, i.e., +DEV, HLIB, and LOCAL. + +.nh +System Installation + + Version 2.3 of VMS/IRAF has already been installed at a number of early +test sites with little trouble. An installation typically takes about an hour, +perhaps longer if relinking is necessary. Interfacing new graphics terminals +or image displays can take much longer, of course, and we will only touch +upon such matters in this draft version of the installation guide. + +.ls [1] \fBSystem Configuration\fR + +Login as SYSTEM and run the AUTHORIZE utility to create an account for +a user named IRAF. Select a disk device with sufficient free space for the +system (see [2] below). If necessary, the system can be stripped after +installation to save space, but the full amount of space will be needed +during installation. Set the IRAF login directory to [IRAF] for now (we will +need to change it later). Do not worry about VMS quotas and +privileges yet; this is not a concern during installation and is discussed +in a later section. In this and all the following examples, names like +DISK:, TAPE:, etc. denote site dependent device names which you must supply +values for. + +.ks +.nf + $ run sys$system:authorize + UAF> (etc) +.fi +.ke + +Add the following statement to the system SYLOGIN.COM file, making the +appropriate substitution for DISK. + + $ IRAF :== "@DISK:[IRAF.VMS.HLIB]IRAFUSER.COM" + +In pre-V2.3 versions of VMS/IRAF it was necessary to define a system or +job logical name for each disk an IRAF user might need to access which +did not contain the $ character, since $ is the logical directory +meta-character in IRAF virtual filenames. This step is no longer necessary +as the $ can be escaped with backslash in IRAF virtual filenames, e.g., +"usr\$0:[iraf...]". The MKIRAF script will automatically insert the escape +characters when building the LOGIN.CL file; do not escape the $ characters +in logical name definitions in IRAFUSER.COM. +.le + +.ls [2] \fBRead the BACKUP Tape\fR + +Login as IRAF (you will get a LOGIN.COM not found message which you should +ignore) and run the VMS BACKUP utility to read the BACKUP tape provided. +The tape contains approximately 6600 files in 240 directories, for a total +of 41 Mb or 81,200 blocks (including binaries). + +.ks +.nf + $ mount/foreign TAPE: + $ set default DISK:[iraf] + $ backup/rew TAPE:iraf.bck/select=[iraf...] [...] +.fi +.ke + +It typically takes half an hour or so to read the tape on a lightly loaded +system. +.le + +.ls [3] \fBEdit the Files that Describe the Host System\fR + +As far as possible, we have tried to condense knowledge of the host system +into a few text files which are read at run time by IRAF. The following +files must be edited before the system can be run. + +.ls 4 [IRAF.VMS.HLIB]IRAFUSER.COM +This file defines the VMS logical names and symbols needed to run IRAF. +The site dependent ones are grouped at the beginning of the file. +.ls 10 IRAFDISK +Set to the name of the disk the [IRAF] directory is on. +.le +.ls 10 IMDIRDISK +Set to the name of a public scratch device. The MKIRAF script will try to +create the default user image storage directories on this disk, e.g., +IMDIRDISK:[USER]. All potential IRAF users should have write permission +and quota on this device. If this is not possible on your system, comment +out the definition and add one instead to the LOGIN.COM file of each IRAF +user, so that each user can have a private IMDIRDISK, or simply edit the +entry for IMDIR in the LOGIN.CL file created when MKIRAF is run. + +A public scratch device is used because this is where bulk image data +will be stored by default. It is often +desirable for this to be on a different disk than that used for user +logins, to minimize the amount of disk that has to be backed up on tape, +and to permit a different quota and file expiration date policy to be used +for large datafiles than is used for the small, relatively long lived files +normally kept on the user disk. +.le +.ls 10 TEMPDISK +Set to the name of a public scratch device and create a public directory +[IRAFTMP] on this device. +The device may be the same as is used for IMDIRDISK if desired. +The IRAF logical directory "tmp$" (known as IRAFTMP in the IRAFUSER.COM file) +is defined as TEMPDISK:[IRAFTMP]. +The IRAF system will create temporary files in this directory at runtime. +These files are always deleted immediately after use (unless a task aborts), +hence any files in "tmp$" older than a day or so are garbage and should be +deleted. It is best if "tmp$" points to a public directory which is cleaned +periodically, e.g., whenever the system is booted, so that junk temporary +files do not accumulate. +.le +.ls 10 FAST,BATCH,SLOW +These are the logical names of the standard IRAF logical batch queues. +They should be redefined to reference the queues used on your machine, +e.g., the standard VMS batch queue SYS$BATCH. +.le +.le + +.ls 4 [IRAF.VMS.HLIB.LIBC]IRAF.H +This file (often referred to as ) is required to compile any of the +C source files used in IRAF. Most sites will not need to recompile the C +sources and indeed may not even have the DEC C compiler, but the file is +also used by the runtime system in some cases to resolve logical names, +hence must be edited and installed. Change the following directory names +as required for your system, referencing only system wide logical names in +the new directory pathnames. +.ls 10 HOST +Set to the fully resolved pathname of the directory IRAFDISK:[IRAF.VMS]. +.le +.ls 10 IRAF +Set to the fully resolved pathname of the directory IRAFDISK:[IRAF]. +.le +.ls 10 TMP +Set to the fully resolved pathname of the directory TEMPDISK:[IRAFTMP]. +.le + +These directory definitions are referenced only if logical name translation +fails for some reason, as often happens on VMS systems for various reasons. +It is therefore essential that only system wide logical names be used in +these directory pathnames. Do not use job or process logicals. Do not +change the order in which the entries appear, or otherwise alter the syntax - +the kernel code which scans is very strict about the syntax. +.le + +.ls 4 [IRAF.LOCAL]LOGIN.COM +We recommend that the login directory for the IRAF account be [IRAF.LOCAL], +rather than the usual [IRAF], to provide a place to keep all the miscellaneous +files required locally to maintain the system, without cluttering up the +standard system. This will simplify the installation of future updates since +it makes it obvious what is part of the standard system and what has been +added locally, and having all the local stuff in a separate directory will +make it easier to ensure that it is not lost when the next version of the +system is installed. + +The default LOGIN.COM will therefore be found in [IRAF.LOCAL]. The LOGIN.COM +file should contain a call to the newly defined IRAF command to define the +IRAF logicals at login time (or when a batch job is submitted). Depending +on when the distribution tape was made, the LOGIN.COM that comes with the +system may reference either IRAF or IRAFX. If the latter is the case, change +the reference to IRAF. The remainder of the file mostly consists of site +dependent stuff used here, and can be changed if desired (it should be +harmless to leave it in). +.le + + +The following files should now be edited to define the default terminal, +printer, editor, and so on for your system. Any part of this can be left +until later if desired. + +.ls 4 [IRAF.VMS.HLIB]ZZSETENV.DEF +This file contains the name of the default editor, the default names of all +the standard devices, and a number of other definitions which are not site +dependent and which can therefore be ignored. To be accessible by the IRAF +system, each local device named must also have an entry in the TERMCAP file +(terminals and printers) or GRAPHCAP file (graphics terminals and image +displays) in [IRAF.DEV]. There must also be an "editor.ED" file in +[IRAF.DEV] for the named editor; EDT, EMACS, and VI are currently supported. +Edit the string to the right of the equals sign for the following entries. +Sample values are shown. + +.ks +.nf + set editor = "vi" + set printer = "imagen" + set stdgraph = "vt640" + set stdimage = "iism70l" + set stdplot = "versatec" + set terminal = "vt640" +.fi +.ke + +For example, you may wish to change the default editor to "edt", the default +printer to "vmsprint", the default image display to "iism75", and the default +terminal to "vt100". Note that only the IIS model 70 and 75 image displays +are directly supported by the current system. Display code is also available +for the DeAnza displays from STScI (NOAO will also support the device in the +near future). The complex issues of the graphics and display interfaces are +discussed more fully in a later section. +.le + +.ls 4 [IRAF.DEV]DEVICES +This file contains a list of the allocatable devices (primarily tape drives) +for the local system. It should be obvious how to change it by reading the +comments in the file and studying the current values, which are for our system. +.le + +.ls 4 [IRAF.DEV]TERMCAP +There must be entries in this file for all host local terminal and printer +devices you wish to access from IRAF. The printer is easy, since the +"vmsprint" entry provided should work on any VMS system. To prepare entries +for other devices, simply copy the "vmsprint" entry and change the queue name +from SYS$PRINT to the name of the queue for the new printer. Any number of +these entries may be placed in the termcap file. If you have a new terminal +which has no entry in the termcap file provided, a new entry will have to be +added (termcap is widely used, so it is highly likely that someone somewhere +will already have written it). A copy of the UNIX manual page documenting +the termcap database is appended in case you need it. +.le + +.ls 4 [IRAF.DEV]GRAPHCAP +There must be entries in this file for all graphics terminals, batch plotters, +and image displays accessed by IRAF programs. Weird graphics terminals will +need a new entry. The IRAF file "sys$gio/doc/gio.hlp" contains docs for +graphcap. A printed copy of this document is available upon request, however +once IRAF is up you may find it easier to generate your own copy using HELP, +as follows: + +.nf + cl> cd sys$gio/doc + cl> help gio.hlp fi+ | lprint +.fi + +The manual page for the SHOWCAP task should also be printed since this utility +is useful for generating new graphcap entries. More focused documentation +will be available eventually. Telephone consultation is available for those +who need it. We ask that new graphcap entries be sent back to us so that we +may include them in the master graphcap file for other sites to use. +.le + +The DEV directory also contains a number of files (HOSTS, HOSTLOGIN, and UHOSTS) +used by the IRAF network software. We depend upon the networking capabilities +of IRAF heavily at NOAO to access image displays, printers, files, etc. resident +upon remote nodes. We expect that most sites will not need this capability +initially, hence documentation of the networking software will be left for +later. For sites which do have a local TCP/IP based network (we do not yet +support DECNET) all that is necessary to enable networking is to edit the +three networking files in the DEV directory, and install IRAF on the other +nodes. It does not matter what native operating system runs on the remote +nodes, so long as it runs IRAF as well. +.le + +.ls 4 [4] \fBComplete the System Configuration\fR + +Login again as SYSTEM, run AUTHORIZE, and change the login directory for +the IRAF account to [IRAF.LOCAL]. Next, copy the IRAF.H file to the system +library, ensuring that the file has read permission for the world. + +.ks +.nf + $ set default sys$library + $ copy DISK:[iraf.vms.hlib.libc]iraf.h [] + $ set prot=(w:r) iraf.h +.fi +.ke + +This is the last part of the system installation procedure requiring +SYSTEM privilege, excepting the adjustment of the authorized quotas for +the IRAF account and any other accounts which will be using IRAF. +.le + +.ls 4 [5] \fBRelink the System (if necessary)\fR + +The prelinked executables supplied on the distribution tape should +execute on most systems without need to relink. If you run a different +version of IRAF than we do, however, it may be necessary to relink all +or part of the system. If you requested a "you relink" version of the system, +read on, otherwise you can probably skip to the next section. + +There are two different sets of executables in the system, the so-called +"bootstrap utilities", and the regular system executables. The bootstrap +utilities are required to relink the system and hence must be linked first. +If you received a "you relink" distribution you can skip this step, since the +bootstrap utilities are included on these tapes as well. Even if you did +not receive a you-relink distribution you should be able to skip this step, +as we were told by DEC that if we linked the bootstrap executables in such +and such a way (/NOSYSSHR link option), they would run on older versions of +VMS. Hopefully this is true, otherwise you must either rebootstrap the +system yourself, or upgrade to a more recent version of VMS. + +The bootstrap utilities are written in C, and the DEC C compiler is required +to compile or link these utilities. The C compiler is NOT required to run +the prelinked binaries. To recompile and link the bootstrap utilities, i.e., +to "bootstrap" IRAF, enter the following commands. + +.nf + $ set default [iraf.vms] + $ set verify + $ @rmbin + $ @mkpkg +.fi + +The bootstrap should take 30 to 45 minutes on an unloaded 11/780. Once the +bootstrap utilities have been relinked and installed in HLIB, the main system +may be relinked. We assume that there is nothing wrong with the system +object libraries and that we only need to relink. If this assumption is false +the system (excluding the [IRAF.VMS...] directories) can be stripped of all +.OLB, .MLB, .OBJ, and .EXE files and the procedure outlined below will +automatically recompile the libraries as well, but of course this will take +much longer than a relink. + +Once the system has been bootstrapped all system maintenance is done with +the MKPKG utility. Documentation for this and the other SOFTOOLS utilities +may be found in the IRAF User's Guide, and is also available in the online +system via HELP. The bootstrap utilities differ from most IRAF software in +that they can be run either from DCL or from the IRAF CL. The following DCL +commands may be entered to relink (or recompile and relink) the main IRAF +system. Note that in this case MKPKG is a DCL foreign task, not a .COM file, +hence there is no @. + +.nf + $ set default [iraf] + $ mkpkg +.fi + +A full system relink will take around 30 minutes. A full system compile and +relink takes about 20 hours on our UNIX 11/750 (single user), and probably +almost as long on a VMS 11/780. The file [IRAF.VMS.HLIB]MKPKG.INC may be +edited to disable compilation of any parts of the system that will not be +used at your site. +.le + +.nh +Login to IRAF and Run the Test Procedure + + Congratulations! You should now have a functional IRAF system. +At this point it would probably be wise to read the CL User's Guide, +if you have not already done so. Before starting the CL you should +probably do what a regular user would do, i.e., run MKIRAF to initialize +the IRAF environment, and then edit the LOGIN.CL file created by MKIRAF +as desired. + +.nf + $ set default [iraf.local] + $ mkiraf +.fi + +Once the IRAF environment is configured one need only enter the CL command +to start up the CL. After a bit IRAF should print the message of the day +and the root menu, and issue the "cl> " prompt. This assumes that the IRAF +command is referenced in the LOGIN.COM file; if this is not the case, IRAF +must be entered first to define CL and the other VMS logical names and +symbols used by IRAF. + + $ cl + +Once in the CL, you will probably have magtape and printer access, are likely +to have graphics terminal access, and very possibly will not have either +image display access or graphics plotter access. If the graphics terminal +capability is ready the next step is to run the IRAF test procedure to +verify that all is working well, as well as try out a few of the many tasks +in the system. If the graphics terminal is not up yet, there is probably +not point in running the test procedure. To run the test procedure, read +the documentation in volume 1A of the IRAF User's Guide and follow the +instructions therein. You may also wish to run some of the benchmarks +described in the benchmarks paper distributed with V2.3, to make sure that +your VMS system (or user quotas and working set) is/are configured properly +for efficient execution of IRAF programs. + +.nh +VMS Quotas and Privileges Required to Run IRAF + + The only special privilege required by IRAF is TMPMBX, which is probably +already standard on your system. Systems with DECNET capabilities should +also give their users NETMBX privilege, although it is not required to run +IRAF. No other privileges are required or useful for normal activities. + +Although privileges are no problem for VMS/IRAF, it is absolutely essential +that the IRAF user have sufficient VMS quota, and that the system tuning +parameters be set correctly, otherwise IRAF will not be able to function +correctly. If a quota is exceedd, or if the system runs out of some +limited resource, the affected VMS system service will return an error code +to IRAF and the operation will fail (this usually happens when trying to +spawn a connected subprocess). + +We are still trying to determine the best minimum recommended quota values. +The current recommendations are summarized below. + +.nf + BYTLM 30000 + PGFLQUOTA 15000 + PRCLM 10 + WSEXTENT 2048 +.fi + +Please note that these are MINIMUM values. Larger values for PGFLQUOTA and +WSEXTENT may be desirable, depending upon expected usage and system resources. + +In addition to sufficient per user authorized quota, the system tuning +parameters must be set to provide enough dynamically allocatable global +pages and global sections to handle the expected load. If these parameters +are set too small, process connects will fail intermittently, usually when +the system load is high. Each subprocess needs about 10 global pages when +activated. With IRAF in heavy use (i.e., a dozen simultaneous users) this +can easily reach a requirement for several hundred additional global pages. +Each installed image and subprocess also needs at least one, usually two, +global sections. The system parameters on our 8600 (which is probably a +worst case example) are currently set to GBLPAGES = 14000 and GBLSECTIONS += 220. Don't despair, though; our little UNIX 11/750 can handle up to ten +IRAF users with only 5 Mb of memory, provided they aren't all doing heavy +image processing. + +.nh +Tuning Considerations + + There are three things that are commonly done to tune VMS/IRAF for a +particular host system: + +.nf + o Install the executables to permit shared memory + o Precompile selected TERMCAP and GRAPHCAP entries + o Strip the system to reduce disk consumption +.fi + +.nh 2 +Installing Executable Images + + VMS/IRAF does not yet implement shared libraries. The system manager must +"install" executable images if the pages comprising the read only PSECT's of +these images are to be shared amongst all processes currently executing the +same image. This is not necessary if only one person will be using IRAF at +a time, but becomes increasingly important as the number of user increases, +or if even a single user begins submitting a lot of batch jobs to run +concurrently. This problem is, of course, not unique to IRAF (except that +the images are rather large, e.g., often several hundred Kb). + +The procedure for installing images is quite simple, however it will fail +if there are insufficient global pages available in the system. The number +of global pages required to install an image is typically about 60 percent +of the size of the image in disk blocks. + +Only the VMS system manager can install images. Images installed interactively +must be reinstalled whenever the system is booted; to permanently install +images, the system startup file must be edited. The procedure followed to +install an image is quite simple, e.g., login as SYSTEM and enter the following +commands to install the CL.EXE and X_SYSTEM.EXE images, and any others +expected to be used enough to be worth installing. + +.nf + $ run sys$system:install + INSTALL> DISK:[iraf.bin]cl /open/header/shared + INSTALL> DISK:[iraf.bin]x_system /open/header/shared + (etc.) +.fi + +Alternatively, one can run the INSTALL.COM DCL script in the HLIB directory. +The main IRAF executables all reside in the [IRAF.BIN] directory. + +.nh 2 +Precompiling TERMCAP and GRAPHCAP Entries + + Precompilation of a termcap or graphcap entry is a technique used to +speed runtime access of the entry for that device. If the entry is not +precompiled the termcap or graphcap file must be physically opened and +scanned at runtime to read the desired entry. This causes a noticeable +delay of as much as a second when clearing the terminal screen or plotting +a graph, hence it is usually worthwhile to cache the entries for commonly +used video and graphics terminals. It is not worthwhile for printers, +plotters, and image displays. + +The system comes with selected termcap and graphcap entries already +precompiled. To see which devices are precompiled, page the cache data +files, DEV$CACHET.DAT (for termcap) and DEV$CACHEG.DAT (for graphcap). +To cache a different set of entries one must regenerate these files with the +MKTTYDATA task in the SOFTOOLS package, and then do a full sysgen with the +MKPKG utility. Detailed instructions are given in the manual page for +MKTTYDATA. + +.nh 2 +Stripping the System to Reduce Disk Consumption + + If the system is to be installed on multiple cpus, or on a particularly +small host like a MicroVax, it may be necessary or desirable to strip the +system of all non-runtime files to save disk space. This equates to deleting +all the sources and all the reference manuals and other documentation, +excluding the online manual pages. A special utility called RMFILES (in the +SOFTOOLS package, of course) is provided for this purpose. It is not +necessary to run RMFILES directly to strip the system. The preferred +technique is to enter the commands given below. The example is for DCL for +consistency with the rest of this document, but this could be done from +within the CL as well. + +.nf + $ set default [iraf] + $ mkpkg strip +.fi + +This will preserve all runtime files, permitting use of the standard runtime +system as well as user software development. The size of the system is reduced +from about 41 Mb (megabytes) to around 19 Mb. One can optionally enter the +command "mkpkg stripall" to delete the system libraries as well, but this +saves only another couple of Mb and a full sysgen (20 cpu hours) or a tape +reload will be required to regain the capability to link user programs with +the IRAF libraries, or relink the IRAF executables. + +.nh +Interfacing to New Graphics Devices + + There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +The topic of interfacing to these devices has already been discussed in +the letter which was sent out with the IRAF questionnaire, hence the +discussion given here will be brief. + +.nh 2 +Graphics Terminals + + The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal, using the STDGRAPH graphics kernel supplied +with the system. All one need do to interface to a new graphics terminal +is add a new graphcap entry for the device. This can take anywhere from +a few hours to a few days, depending on one's level of expertise, and the +perversity of the device in question. We are willing to help out if +necessary, as noted in the letter mentioned earlier. + +The fancy bit mapped, high resolution graphics displays common on "workstations" +like the MicroVax and the Sun cannot be driven (acceptably) by the existing +STDGRAPH graphics kernel. We are actively developing new graphics kernels +for these devices, and they should be available later this year. + +.nh 2 +Graphics Plotters + + The current IRAF system comes with three graphics kernels usable to drive +graphics plotters. The STDGRAPH kernel can in principle be used to make +plots on many devices by using a Tek graphcap entry, redirecting the Tek +drawing instructions into a file, and using the Tek emulation software that +comes with most plotters to generate the plot. A more streamlined interface +is possible but is not yet available [V2.3 - see the discussion of the new +SGI interface in the paper "The IRAF Simple Graphics Interface"]. + +The supplied STDPLOT kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +excellent plots on the Versatec, Printronix, Trilog, and other similar +devices if NCAR metacode translators are available. This is the kernel +we currently depend upon most heavily at NOAO for plotter output. +Unfortunately, the host level NCAR metacode translators are not included in +the standard IRAF distribution but are required for a plot. The necessary +software is however in the public domain, and will be available at a later +date. Sites which already have the Ray Bovet "McVax" package are already +very close to having plotter output using this kernel. A little software +twiddling remains to be done to make the connection for VAX/VMS (we do all +our plotting on UNIX here), but this is a matter of a few hours and the +software should be available shortly. Contact us for more information. + +The remaining possibility with the current system is the CALCOMP kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. It should be possible to copy this +library to the HLIB directory and relink the Calcomp graphics kernel to +get output using on any devices supported by the library. The following +commands should suffice to install the calcomp library, and relink and +install the Calcomp graphics kernel: + +.nf + $ set default [iraf.vms.hlib] + $ copy mycalcomplibrary.olb libcalcomp.olb + $ set default [iraf.sys.gio.calcomp] + $ mkpkg update +.fi + +A graphcap entry may also be required. + +[NOTE, August 1986]: A new graphics kernel called the SGI kernel is now +available. In many cases this will greatly simply the process of interfacing +to a new plotter device. Documentation should have been included with the +V2.3 distribution kit. See also [VMS.GDEV.SGIDEV]README). + +.nh 2 +Image Displays + + The IRAF system as currently supported directly supports only the +IIS model 70 and 75 image displays. Comparable software is available from +STScI for the DeAnza displays; requests for this software should be +directed to Sammy Kijilner or Jay Travisano at STScI. We are expecting +to take delivery of a MicroVax with bit mapped graphics display and +DeAnza IP5000 image display any day now, hence these devices will soon +be supported by NOAO, too. + +We cannot do much to help sites with other image displays until the new +IRAF display interface is completed. This is scheduled to be worked on +this spring, and should be available this summer. The new interface and +associated TV package software will be a great improvement over what is +currently available; the current interface is very minimal, and does not +even support cursor readback, although it is fine for image display. + +In the meantime, the best approach is to use the new IMFORT interface +and whatever non-IRAF display software you currently have to construct +an interim display program. The IMFORT library provides host system Fortran +or C programs with access to IRAF images. The only documentation +currently available for IMFORT is the README file in the directory +[IRAF.SYS.IMIO.IMFORT]. Sample Fortran programs and a VMS .COM file +showing how to link are given in the same directory. + +.nh +The IRAF Directory Structure + + The current IRAF directory structure (new directories are constantly +being added) is documented in the Appendix. The main branches of the tree +are the following. + +.nf + bin - installed executables + dev - device tables (termcap, graphcap, etc.) + doc - assorted IRAF manuals + lib - the system library; object libraries, global files + local - your login directory + math - sources for the mathematical libraries + pkg - the IRAF applications packages + sys - the virtual operating system (VOS) + vms - the VMS system interface (kernel + bootstrap utilities) +.fi + +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. + +.nh +Relinking or Updating IRAF Packages + + Should it be necessary to fix a bug in one of the applications packages, +it is very easy to recompile and relink the package and install the new +executable. After editing the affected files, enter any of the following +commands (this is normally done from within the CL): + +.nf + mkpkg Makes an executable in the package directory + mkdebug Same, but with the debugger linked in + mkpkg install Used after "mkpkg" (but not mkdebug!) to + install the new executable in BIN. + mkpkg udpate Relinks the new executable and installs it in + BIN all in one shot. +.fi + +If extensive revisions are contemplated, a copy of the entire package should +be made and moved out of the system, and that version of the package modified, +rather than modifying the standard package, which will only make updating the +system more difficult. It will be necessary to delete or replace the installed +executables in BIN before the revised ones can be used. The directory name +in the TASK declaration for the package in HLIB$CLPACKAGE.CL is all one must +modify to use the local version of the package rather than the standard one. +.endhelp diff --git a/doc/vmsiraf.ms b/doc/vmsiraf.ms new file mode 100644 index 00000000..f0156a93 --- /dev/null +++ b/doc/vmsiraf.ms @@ -0,0 +1,2375 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +VMS/IRAF Installation and Site Manager's Guide +.AU +Doug Tody, Suzanne Jacoby +.br +IRAF Group +.br +.sp +Nigel Sharp +.br +CCS +.AI +.# National Optical Astronomy Observatories +.br +.K2 "" "" "\(dg" +June, 1993 + +.AB +.ti 0.75i +This document describes how to install or update the VMS version of the +portable IRAF system (Image Reduction and Analysis Facility). Installation +instructions as well as procedures for improving performance, minimizing +disk and memory usage, configuring the system for the local site, and +interfacing local devices are given. +.AE + +.bp +.ce +\fBContents\fR +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling VMS/IRAF\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Read in the distribution files\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Installing from a network distribution\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing from tape\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Merge local revisions back into the new system\l'|5.6i.'\0\04 +.br +\h'|0.4i'2.3.\h'|0.9i'Edit the system configuration files\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.1.\h'|1.5i'[IRAF.VMS.HLIB]IRAFUSER.COM\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.2.\h'|1.5i'[IRAF.VMS.HLIB]INSTALL.COM\l'|5.6i.'\0\06 +.br +\h'|0.9i'2.3.3.\h'|1.5i'[IRAF.VMS.HLIB.LIBC]IRAF.H\l'|5.6i.'\0\07 +.br +\h'|0.4i'2.4.\h'|0.9i'Complete the initial system configuration\l'|5.6i.'\0\07 +.sp +3.\h'|0.4i'\fBTesting a Newly Installed or Updated System\fP\l'|5.6i.'\0\08 +.br +\h'|0.4i'3.1.\h'|0.9i'Configuring the IRAF account\l'|5.6i.'\0\08 +.sp +4.\h'|0.4i'\fBConfiguring the IRAF Environment\fP\l'|5.6i.'\0\09 +.br +\h'|0.4i'4.1.\h'|0.9i'[IRAF.VMS.HLIB]ZZSETENV.DEF\l'|5.6i.'\0\09 +.br +\h'|0.4i'4.2.\h'|0.9i'The template LOGIN.CL\l'|5.6i.'\0\10 +.sp +5.\h'|0.4i'\fBConfiguring the Device and Networking Files\fP\l'|5.6i.'\0\10 +.br +\h'|0.4i'5.1.\h'|0.9i'[IRAF.DEV]TAPECAP\l'|5.6i.'\0\10 +.br +\h'|0.4i'5.2.\h'|0.9i'[IRAF.DEV]DEVICES\l'|5.6i.'\0\11 +.br +\h'|0.4i'5.3.\h'|0.9i'The DEVICES.HLP file\l'|5.6i.'\0\11 +.br +\h'|0.4i'5.4.\h'|0.9i'[IRAF.DEV]TERMCAP\l'|5.6i.'\0\11 +.br +\h'|0.4i'5.5.\h'|0.9i'[IRAF.DEV]GRAPHCAP\l'|5.6i.'\0\11 +.br +\h'|0.4i'5.6.\h'|0.9i'[IRAF.DEV]HOSTS, UHOSTS, and IRAFHOSTS\l'|5.6i.'\0\12 +.sp +6.\h'|0.4i'\fBVector Graphics and Image Display using X Windows\fP\l'|5.6i.'\0\14 +.br +\h'|0.4i'6.1.\h'|0.9i'Xterm\l'|5.6i.'\0\14 +.br +\h'|0.4i'6.2.\h'|0.9i'SAOimage\l'|5.6i.'\0\14 +.sp +7.\h'|0.4i'\fBAdditional System Configuration Issues\fP\l'|5.6i.'\0\15 +.br +\h'|0.4i'7.1.\h'|0.9i'New networking driver\l'|5.6i.'\0\15 +.br +\h'|0.9i'7.1.1.\h'|1.5i'DECNET networking\l'|5.6i.'\0\15 +.br +\h'|0.9i'7.1.2.\h'|1.5i'Proxy logins\l'|5.6i.'\0\16 +.br +\h'|0.9i'7.1.3.\h'|1.5i'Configuring a VMS host as a TCP/IP server\l'|5.6i.'\0\17 +.br +\h'|0.9i'7.1.4.\h'|1.5i'Network security alarms\l'|5.6i.'\0\17 +.br +\h'|0.4i'7.2.\h'|0.9i'New magtape driver\l'|5.6i.'\0\18 +.br +\h'|0.9i'7.2.1.\h'|1.5i'Allocation\l'|5.6i.'\0\18 +.br +\h'|0.9i'7.2.2.\h'|1.5i'Density\l'|5.6i.'\0\18 +.br +\h'|0.9i'7.2.3.\h'|1.5i'Status output logging\l'|5.6i.'\0\18 +.br +\h'|0.9i'7.2.4.\h'|1.5i'Using tape drives over the network\l'|5.6i.'\0\19 +.br +\h'|0.4i'7.3.\h'|0.9i'Configuring user accounts for IRAF\l'|5.6i.'\0\19 +.br +\h'|0.4i'7.4.\h'|0.9i'VMS quotas and privileges required to run IRAF\l'|5.6i.'\0\20 +.br +\h'|0.4i'7.5.\h'|0.9i'Interfacing new graphics devices\l'|5.6i.'\0\21 +.br +\h'|0.9i'7.5.1.\h'|1.5i'Graphics terminals\l'|5.6i.'\0\21 +.br +\h'|0.9i'7.5.2.\h'|1.5i'Graphics plotters\l'|5.6i.'\0\21 +.br +\h'|0.9i'7.5.3.\h'|1.5i'Image display devices\l'|5.6i.'\0\22 +.sp +8.\h'|0.4i'\fBTuning Considerations\fP\l'|5.6i.'\0\22 +.br +\h'|0.4i'8.1.\h'|0.9i'Stripping the system to reduce disk consumption\l'|5.6i.'\0\22 +.br +\h'|0.4i'8.2.\h'|0.9i'Installing executable images\l'|5.6i.'\0\23 +.br +\h'|0.4i'8.3.\h'|0.9i'Rendering large runtime files contiguous\l'|5.6i.'\0\23 +.br +\h'|0.4i'8.4.\h'|0.9i'Precompiling TERMCAP and GRAPHCAP entries\l'|5.6i.'\0\24 +.sp +9.\h'|0.4i'\fBSoftware Management\fP\l'|5.6i.'\0\24 +.br +\h'|0.4i'9.1.\h'|0.9i'Shared libraries\l'|5.6i.'\0\24 +.br +\h'|0.4i'9.2.\h'|0.9i'Layered software support\l'|5.6i.'\0\24 +.br +\h'|0.4i'9.3.\h'|0.9i'Software management tools\l'|5.6i.'\0\25 +.br +\h'|0.4i'9.4.\h'|0.9i'Modifying and updating a package\l'|5.6i.'\0\26 +.br +\h'|0.4i'9.5.\h'|0.9i'Installing and maintaining layered software\l'|5.6i.'\0\27 +.br +\h'|0.4i'9.6.\h'|0.9i'Configuring a custom LOCAL package\l'|5.6i.'\0\27 +.br +\h'|0.4i'9.7.\h'|0.9i'Updating the full IRAF system\l'|5.6i.'\0\28 +.br +\h'|0.9i'9.7.1.\h'|1.5i'The BOOTSTRAP\l'|5.6i.'\0\28 +.br +\h'|0.9i'9.7.2.\h'|1.5i'Updating the system libraries\l'|5.6i.'\0\28 +.br +\h'|0.9i'9.7.3.\h'|1.5i'Relinking the IRAF shared library\l'|5.6i.'\0\29 +.br +\h'|0.9i'9.7.4.\h'|1.5i'Relinking the main IRAF system\l'|5.6i.'\0\30 +.sp +10.\h'|0.4i'\fBMiscellaneous Notes\fP\l'|5.6i.'\0\30 +.sp +Appendix A.\h'|0.9i'\fBPrivate TMP and IMDIR Directories\fP\l'|5.6i.'\0\31 + + +.nr PN 0 +.bp +.NH +Introduction +.PP +Before installing VMS/IRAF, one must 1) obtain the VMS/IRAF +distribution, e.g., from the IRAF network archive on \f(CWiraf.noao.edu\fR +(or by ordering a tape distribution from NOAO), 2) select the server or node +on which the system is to be installed and arrange for sufficient disk space +to hold the system, and 3) set aside sufficient time to do the +installation. If these directions are followed carefully and mistakes are +avoided the basic installation should only take an hour or so. +Additional time may be required to customize the system to configure the +local tape drives and other devices, set up IRAF networking, and so on. +.PP +V2.10 VMS/IRAF supports VMS versions 5.2 through 5.5. The amount of disk +space required to install IRAF, including both the core system and NOAO +package sources and all binaries, is about 78 Mb. If desired about half +of this space can be reclaimed after installation by stripping the system +of all but the runtime files. +.XS +$ dir/size=all \fIirafdisk\fP:[iraf...] +Grand total of 401 directories, 10507 files, 144566/157008 blocks. +.XE +.LP +The distributed system is a snapshot of our local (NOAO/Tucson) VMS/IRAF +installation. The device and system configuration tables come edited for +our system, and will have to be modified as part of the installation +process. These modifications are discussed in detail in this document. To +simplify the installation process as well as future upgrades, we have tried +to isolate the site dependent files to the minimum number of directories, +i.e., \f(CWdev\fP, \f(CWhlib\fP, and \f(CWlocal\fP and its subdirectories +(the equivalent VMS pathnames are [IRAF.DEV], [IRAF.VMS.HLIB], and +[IRAF.LOCAL]). The remainder of the system should not require any +modifications. +.PP +Feel free to contact the IRAF Hotline for assistance if any problems should +arise during the installation, or for help in interfacing new devices. +.TS +center; +c s +l l. +.sp 1 +\fBIRAF SUPPORT SERVICES\fP +.sp +Internet: iraf@noao.edu +NSI-DECNET: noao::iraf or 5355::iraf +.sp 0.5 +IRAF Hotline: (602) 323-4160 +FAX: (602) 325-9360 +.sp 0.5 +Network Archive: ftp iraf.noao.edu +(anonymous ftp) ftp 140.252.1.1 +.sp +.TE + +.NH +Installing VMS/IRAF +.PP +The steps required to install VMS/IRAF are summarized below. This summary +is provided only to introduce the installation procedure: it is important to +read the detailed installation instructions for additional information, to +avoid certain errors or omissions which are otherwise likely (IRAF does not +always follow VMS conventions!). +.XS +\fR# Prepare the root IRAF directory.\fP +if new installation + create iraf account +else if updating an old installation + save locally modified files; delete old system + +\fR# Read in the distribution files.\fP +login as iraf +unpack the distribution files from a network distribution or tape + +\fR# Modify IRAF system and device configuration files.\fP +edit site dependent files in hlib, hlib/libc and dev directories +if updating an old installation + merge locally modified files back into new system + +\fR# Complete the Initial Installation as SYSTEM.\fP +add global symbol "iraf" to SYLOGIN.COM +copy edited hlib$libc/iraf.h file to SYS$LIBRARY +install in system memory IRAF shared library and other executables + +\fR# Checkout the new system.\fP +run test procedure from iraf account +.XE +.PP +If problems should arise during the installation, help is available from the +IRAF Hotline (602-323-4160), or by sending email to \f(CWiraf@noao.edu.\fP +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation, you will be replacing +IRAF by the new version and IRAF should already have an account and root +directory on the desired host system. You should first log in as IRAF and +save any locally modified files before deleting the old system. Ordinarily +the only directories containing files you may wish to save are \f(CWdev\fP, +\f(CWhlib\fP, and \f(CWlocal\fP. The safest and easiest way to do this is +to save the entire contents of those directories. For example: +.XS +$ set default [iraf] +$ rename dev.dir,local.dir,[.vms]hlib.dir [\fIdirectory\fP] +.XE +.LP +This would physically move (not copy) the \f(CWdev\fP, \f(CWlocal\fP, and +\f(CWhlib\fP directories to the named directory, which must be on the same +disk device as [IRAF]. Many variations on this are possible. The +destination directory should be somewhere \fIoutside\fP the [IRAF...] +directory tree, else it may get deleted when you delete the old system. +.PP +Although it is probably simplest and safest to save entire directories as in +the example, in practice only a few files are likely to have been modified. +These are the following: +.XS +[iraf.dev]tapecap. +[iraf.dev]graphcap. +[iraf.dev]termcap. +[iraf.dev]hosts. +[iraf.dev]uhosts. +[iraf.dev]irafhosts. +[iraf.dev]devices. +[iraf.dev]devices.hlp +.XE +.XS +[iraf.vms.hlib]motd. +[iraf.vms.hlib]login.cl +[iraf.vms.hlib]extern.pkg +[iraf.vms.hlib]install.lst +[iraf.vms.hlib]irafuser.com +[iraf.vms.hlib]zzsetenv.def +[iraf.vms.hlib.libc]iraf.h +[iraf.local]login.com +.XE +.LP +Having temporarily preserved all the locally modified files, it is now +time to delete the old system and read in the new one. If you are +the cautious (prudent?) type you may wish to first preserve the entire +existing IRAF system on a backup tape. Using only the standard +VMS utilities, the old system may be deleted as follows (assuming IRAF +owns all the files in [IRAF...]). +.XS +$ set default [iraf] +$ delete [...]*.*;* /nolog/noconfirm +$ set protection=(owner:wd) [...]*.*;* +$ delete [...]*.*;* /nolog/noconfirm + \fR(repeat delete command with until done)\fP +.XE +.LP +It is normal for the \fIdelete\fP command shown to generate lots of messages +during execution warning that it cannot delete directories because they are +not yet empty. When the command finally executes without any warning messages +this means the directory tree has been fully deleted. +.PP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. It is important to delete the old system first to +avoid creating junk files or directories when the new system is installed +(due to file or directory name changes or deletions). Once the new system +has been restored to disk, do \fInot\fR merely restore the files saved above, +as you will need to carefully merge local changes into the versions of the +files supplied with the new IRAF release. +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set +up a new account for the user `iraf'. This is necessary for IRAF system +management, which should always be done from the IRAF account. Having an +IRAF account provides a convenient place (the IRAF system manager's login +directory) to keep scratch files created during system configuration. +.PP +System management policies vary from site to site, so we do not give +specific instructions for \fIhow\fP to create the account (e.g., +\f(CW$ run sys$system:authorize\fP), +but the account itself should be structured as follows: +.RS +.IP \(bu +Select a disk device with sufficient free space for the system (about 75 +Mb for V2.10). If necessary, the system can be stripped after installation +to save space (\(sc8.1), but the full amount of space will be needed during +installation. The disk should not be a "rooted logical" \(dg. +.FS +\(dgA rooted logical might be something like \f(CWlocal_disk = +dub4:[local.]\fR, with the IRAF disk set to \f(CWlocal_disk\fR. +This will not work. +.FE +.IP \(bu +The root directory for the IRAF account should be set to [IRAF], as +this name is explicitly assumed in various places in the configuration +files. A "rooted logical" directory will not work. +.IP \(bu +The \fIlogin\fR directory for the IRAF account should be set to +[IRAF.LOCAL] rather than [IRAF] as one would expect, as we +want to keep all the locally modified files in subdirectories off the iraf +root directory, to simplify site management and future updates. If this +point is missed the iraf environment will not be set up properly, and later +problems are sure to result. +.IP \(bu +Do not create a LOGIN.COM for IRAF; one will be read from the +distribution tape, as will the [IRAF.LOCAL] directory. (If for some +local management reason the directory [IRAF.LOCAL] is created at +this time, make sure it has the proper protections [e.g., +"\f(CWset protection = (s:rwd,o:rwd,g:r,w:r)\fR"].) +.IP \(bu +There is no need to worry about VMS quotas and privileges yet; this is not +a concern during installation and is discussed in a later section (\(sc7.4). +.RE +.NH 2 +Read in the distribution files +.PP +If you are installing from tape skip forward to \(sc2.2.2. If you are +installing from a network distribution (i.e., from disk) continue with the +next section. +.NH 3 +Installing from a network distribution +.PP +VMS/IRAF is available over the network via anonymous ftp from the node +\f(CWiraf.noao.edu\fR, in the subdirectory \f(CWiraf/v\fInnn\fP/VMS5\fR, +where "\f(CWv\fInnn\fR" is the IRAF version number, e.g., subdirectory +iraf/v210/VMS5 for V2.10 VMS/IRAF. Complete instructions for +retrieving IRAF from the network archive are given in the +README file in this directory. The retrieval can be accomplished with +UNIX FTP, VMS FTP or VMS DECNET. +.PP +The subdirectory ia.vms5.vax 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. To reconstruct the original backup save +file, the segments must be transferred, uncompressed and concatenated. This +can be done in several ways, as described in the README file. Once the disk +save set has been reconstructed on your local disk, you can proceed with the +installation. +.PP +Login as IRAF (ignore any LOGIN.COM not found error message) and +run the VMS \fIbackup\fP utility to read the backup save set, named v210.bck +in this example: +.XS +$ set default \fIdisk\fP:[iraf] +$ backup v210.bck/select=[iraf...] [...]/own=iraf/prot=w:r +.XE +.LP +In this and all the following examples, names like \fIdisk:\fP, +etc., denote site dependent device names for which you must supply values. +.NH 3 +Installing from tape +.PP +Login as IRAF (ignore any LOGIN.COM not found error message) and +run the VMS \fIbackup\fP utility to read the backup tape or tapes provided. +.XS +$ mount/foreign \fItape-device\fP: +$ set default \fIdisk\fP:[iraf] +$ backup/rew \fItape\fP:v210.bck/select=[iraf...] [...]/own=iraf/prot=w:r +.XE +.LP +The tape may be restored while logged in as SYSTEM if desired, but the switch +/OWNER=IRAF should be appended to give the IRAF system manager +(anyone who logs in as IRAF) write permission on the files. +.PP +It typically takes twenty minutes to half an hour to read the tape on a +lightly loaded system. +.NH 3 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure to not replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF. +.PP +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each +site to maintain their own custom LOCAL package external to the core IRAF +system. The core system LOCAL is now only a \fItemplate-local\fR to be +copied and used as the starting point for a custom LOCAL layered package. +The layered software enhancements, and the procedure for building a custom +LOCAL, are discussed in \(sc9 of this manual. +.NH 2 +Edit the system configuration files +.PP +The files listed below must be edited before the system can be run. +The principal change required is to change the pathnames of the major IRAF +logical directories for the local machine. If any of these files are edited +while logged in as SYSTEM, be sure to do a \f(CWset file/owner=iraf\fP to +restore ownership of the edited file to IRAF. +.NH 3 +[IRAF.VMS.HLIB]IRAFUSER.COM +.PP +This file defines the VMS logical names and symbols needed to run IRAF. +The site dependent ones are grouped at the beginning of the file. The +top of the distributed file looks like this: +.XS +$! IRAFUSER.COM -- VMS symbols and logicals for using IRAF. +$! +$! The following logical names are system-dependent. IMDIRDISK and +$! TEMPDISK should be public devices and may be the same device. +$! +$ define/job IRAFDISK USR$3: ! Disk IRAF resides on +$ define/job IMDIRDISK SCR$4: ! User image subdirectories go here +$ define/job TEMPDISK SCR$2: ! Runtime (scratch) files go here +$ define/job IRAFGMTOFF -7 ! Offset from GMT in hours +$! define/job IRAFUHNT (file) ! Use (file) instead of dev$uhosts +$! +.XE +.IP \f(CWIRAFDISK\fP +.br +Set to the name of the disk the [IRAF] directory is on; this may +be another logical name but not a "rooted logical". + +.IP \f(CWIMDIRDISK\fP +.br +Set to the name of a public scratch device, if available. The \fImkiraf\fP +script will try to create the default user image storage directories on this +disk, e.g., IMDIRDISK:[\fIusername\fP]. All potential IRAF users should +have write permission and quota on this device. +.sp 0.4 +A public scratch device is desirable because this is where bulk image data +will be stored by default. It is often best for this to be on a different +disk than that used for user logins, to minimize the amount of disk that has +to be backed up on tape, and to permit a different quota and file expiration +date policy to be used for large datafiles than is used for the small, +relatively long lived files normally kept on the user disk. +.sp 0.4 +Note for sites that use "rooted logicals": the VMS/IRAF kernel does not +support rooted logicals. If you use one, e.g., for IMDIRDISK, +batch jobs that need to access it will fail. To avoid problems, you must +either choose IMDIRDISK to be truly just a disk specification, or inform all +users to edit their IRAF login.cl files after a \fImkiraf\fR. +.sp 0.4 +For example, if you define IMDIRDISK to be "DATA_DISK:", where DATA_DISK is +a logical name for dub4:[data.], user ICHABOD's login.cl would have "set +imdir = DATA_DISK:[ICHABOD]", but this would not work for batch jobs. The +user should edit login.cl after a \fImkiraf\fR to use an expanded directory +specification, in this case "set imdir = dub4:[data.ichabod]". + +.IP \f(CWTEMPDISK\fR +.br +Set to the name of a public scratch device on which you have created a +public directory named [IRAFTMP]. The device may be the same as is used for +IMDIRDISK if desired. The IRAF logical directory "tmp" (known as IRAFTMP in +the IRAFUSER.COM file) is defined as TEMPDISK:[IRAFTMP].\(dg +.FS +\(dgIf local system management or accounting policies require that private +tmp and imdir directories be defined for each user, rather than the public +ones we recommend, see Appendix A. +.FE +The IRAF system will create temporary files in this directory at runtime. +These files are always deleted immediately after use (unless a task aborts), +hence any files in IRAFTMP older than a day or so are garbage and +should be deleted. It is best if IRAFTMP points to a public directory +which is cleaned periodically by the system, e.g., whenever the system is +booted, so that junk temporary files do not accumulate. This is a good +reason for using a single public directory for this purpose rather than +per-user private directories. The files created in IRAFTMP are rarely +very large. +.sp 0.4 +See note under IMDIRDISK concerning rooted logicals, if you plan to +locate TEMPDISK at a rooted logical. + +.IP \f(CWIRAFGMTOFF\fP +.br +The value of IRAFGMTOFF is the offset in hours to convert Greenwich mean +time (GMT) to local standard time. It is used by the VMS/IRAF versions of +\fIrtar\fR and \fIwtar\fR to restore file dates properly when moving files +between UNIX and VMS systems. For example, Tucson is 7 hours west of +Greenwich so IRAFGMTOFF is defined as -7. + +.IP \f(CWIRAFUHNT\fP +.br +Define IRAFUHNT to be the name of the internet host table for the local +system, if this exists and is in the correct format for use by IRAF (i.e., +the same format as the file dev$uhosts). On VMS systems there is no +standard internet host table comparable to the /etc/hosts file used on unix +systems. The VMS/IRAF implementation of TCP/IP networking therefore uses +its own host table, dev$uhosts, which is what is used if IRAFUHNT is not +defined. Some VMS networking implementations (e.g., Multinet) have their +own host tables. If this is the case then IRAF can make use of the system +host table by uncommenting and defining the logical name IRAFUHNT to point +to the file. + +.IP \f(CWFAST,BATCH,SLOW\fP +.br +These are the logical names of the standard IRAF logical batch queues. +They should be redefined to reference the queues used on your machine, +e.g., the standard VMS batch queue SYS$BATCH (all three names +may point to the same batch queue if desired). The fast queue is intended +for small jobs to be executed at interactive priorities, the batch queue +is for medium sized jobs, and the slow queue is for large jobs that need +a lot of system resources and are expected to run a long time. +.NH 3 +[IRAF.VMS.HLIB]INSTALL.COM +.PP +This command procedure is run by the system manager, or by the system at +boot time, to install the IRAF shared library and selected executable +images.\(dg\(dg +.FS +\(dg\(dg\fRIn VMS terminology, \fIimage\fR, as in "executable image" refers +to the executable program, and has nothing to do with IRAF image data. +.FE +Installing images in system memory is necessary to permit memory sharing in +VMS, and can greatly reduce physical memory usage and paging on a busy +system, while speeding process startup. Installing images also consumes +system global pages, however, of which there is a limited supply. Hence, +one should only install those images which will be used enough to make it +worthwhile. See \(sc8.2 for more information. +.PP +The \f(CWinstall.com\fP procedure both installs the IRAF executables and +replaces them after any have been changed. It works from a separate list of +files, so you should not edit install.com itself. Instead, edit install.lst +to select files by commenting out only those which are \fInot\fP to be +installed (the comment character is a "!" at the beginning of the line). +.PP +The IRAF shared library \f(CWs_iraf.exe\fP should always be installed if +IRAF is going to be used at all, or the system will execute very +inefficiently (the IRAF shared library is used by all executing IRAF +processes). Normally the executables cl.exe and x_system.exe should also be +installed, since these are used by anyone using IRAF, as well as by all +batch IRAF jobs. If IRAF is heavily used and sufficient global pages are +available it is also desirable to install x_images.exe and x_plot.exe, since +virtually everyone uses these executable images frequently when using IRAF. +It is probably not worthwhile to install any other executables, unless usage +at the local site involves heavy use of specific additional executable +images. +.NH 3 +[IRAF.VMS.HLIB.LIBC]IRAF.H +.PP +This file (often referred to as "") is required to compile any of +the C source files used in IRAF. Most sites will not need to recompile the +C sources and indeed may not even have the DEC C compiler, but the file is +also used by the runtime system in some cases to resolve logical names, +hence must be edited and installed in the VMS system library. Change the +following disk names as required for your system, referencing only system +wide logical names in the new directory pathnames (e.g. usr1:[IRAF.VMS], +where usr1 is a system logical name; do not leave the IRAF logicals like +irafdisk in the definition). +.DS +.TS +ci ci +n l. +IRAF Logical Directory VMS directory + +\&HOST \fIirafdisk\fP:[IRAF.VMS] +\&IRAF \fIirafdisk\fP:[IRAF] +\&TMP \fItempdisk\fP:[IRAFTMP] (may vary\(dg\(dg) +.TE +.DE +.FS +\(dg\(dg\fRIf local system restrictions forbid a public IRAFTMP directory, +set this entry to the pathname of a suitable directory in IRAF, e.g., +[IRAF.LOCAL.UPARM]. This should work in most circumstances, since it is +most likely to be the IRAF system manager who runs a program that accesses +these pathnames. This is separate from the user-level private IRAFTMP +irectory discussed in Appendix A. +.sp +.FE +.LP +These directory definitions are referenced only if logical name translation +fails, as sometimes happens on VMS systems for various reasons. +It is therefore essential that only system wide logical names be used in +these directory pathnames. Do not use job or process logicals. Do not +change the order in which the entries appear, or otherwise alter the syntax; +the kernel code which scans is very strict about the syntax. +.NH 2 +Complete the initial system configuration +.PP +Login again as SYSTEM and copy the recently edited file +irafdisk:[iraf.vms.hlib.libc]iraf.h to the system library, ensuring that the +file has world read permission (be sure not to copy [iraf.vms.hlib]iraf.h by +mistake):\(dg +.FS +\(dg\fROn a VMS cluster, make sure the IRAF.H file is added to +SYS$COMMON:[SYSLIB] rather than SYS$SYSROOT:[SYSLIB], so that all nodes in +the cluster may transparently access the file. The same precaution is +needed when editing the system-wide login procedure file (e.g., +SYLOGIN.COM), which will probably want to go into SYS$COMMON:[SYSMGR]. The +SYSTARTUP_V5.COM file, on the other hand, should go into +SYS$SYSROOT:[SYSMGR] if the bootstrap procedure is different for each node. +.FE +.XS +$ set default sys$library +$ copy \fIdisk\fP:[iraf.vms.hlib.libc]iraf.h []/protection=w:r +.XE +.LP +Add the following statement to the system SYLOGIN.COM file, making the +appropriate substitution for \fIdisk\fP. +.XS +$ iraf :== "@\fIdisk\fP:[iraf.vms.hlib]irafuser.com" +.XE +.LP +Add the following statement to the SYSTARTUP_V5.COM file, read by the system +at startup time. This is necessary to cause the IRAF executables to be +reinstalled in system memory when the system is rebooted. +.XS +$ @\fIdisk\fP:[iraf.vms.hlib]install.com +.XE +.LP +While still logged in as SYSTEM, type in the above command interactively to +perform the initial executable image installation. It may be necessary to +increase the number of system global pages for the command to execute +successfully. If you do not want to install the set of IRAF executables +normally installed at NOAO, edit [iraf.vms.hlib]install.lst before +executing install.com (see \(sc8.2). +.PP +Lastly, log out of SYSTEM, and back in as IRAF. Update the date stamp +of a file that is used to ensure that newly updated parameter sets are +used rather than any old versions a user might have around: +.XS +$ set default irafhlib +$ copy utime. utime. +$ purge utime. +.XE + +.NH +Testing a Newly Installed or Updated System +.PP +At this point it should be possible for any user to run IRAF. First however, +you should verify this by using the IRAF account itself. +Before testing a newly installed or upgraded system it is wise to read the +\fICL User's Guide\fP, the revisions notes, and the list of known bugs, +if one has not already done so. +.NH 2 +Configuring the IRAF account +.PP +The default LOGIN.COM in the IRAF login directory [IRAF.LOCAL] will +automatically execute the globally defined system command `iraf', which +defines the IRAF logicals. Login as IRAF so IRAFUSER.COM is executed and +the IRAF logicals are defined. +.PP +Before starting the IRAF CL (command language) you should do what a regular +user would do, i.e., run \fImkiraf\fR to initialize the IRAF uparm directory +and create a new LOGIN.CL (answer yes to the purge query, as it is advisable +to delete the contents of the old uparm). You may edit the LOGIN.CL created +by \fImkiraf\fR as desired. +.XS +$ set default [iraf.local] +$ mkiraf +.XE +.LP +Any modifications you wish to preserve across another \fImkiraf\fP may be +placed into an optional "loginuser.cl" file to avoid having to edit the +login.cl file. The loginuser.cl file can have the same kinds of commands in +it as login.cl, but \fImust\fR have the statement \f(CWkeep\fR as the last +line. +.PP +Once the IRAF environment is configured one need only enter the +command \fIcl\fP to start up the CL. From an X windows workstation, you +should always start the CL from an \fIxterm\fR window (or \fIxgterm\fR if +available). See \(sc6.1. +.XS +$ cl +.XE +.LP +If the CL runs successfully, the screen will be cleared (if the terminal +type is set correctly) and the message of the day printed. You can then +type \fIlogout\fR to stop the CL and return to DCL, or stay in the CL to +edit and test the device files described in the next section. When logging +back into the CL (as `IRAF'), always return to the [IRAF.LOCAL] directory +before logging in. A little command \fIh\fR (for `home') is defined in the +default IRAF LOGIN.COM file for this purpose. +.PP +If the CL does not run successfully, it is probably because the \fIiraf\fR +command was not executed in the LOGIN.COM file at login time. The \fIiraf\fR +command must be executed to define \fIcl\fP and the other VMS logical names +and symbols used by IRAF, before trying to run the IRAF system. +.LP +Important Note: any users wishing to execute IRAF tasks in VMS batch +queues \fImust\fP issue the `iraf' command inside their LOGIN.COM, prior +to any +.XS +if f$mode().nes."INTERACTIVE" then exit +.XE +.LP +command, otherwise critical IRAF logical names will be undefined when +executing tasks remotely using IRAF networking. +.PP +Once in the CL, you should be able to draw vector graphics on the +workstation screen (\fIxterm\fR) or graphics terminal and have printer +access (device \fIvmsprint\fR). If working from a workstation on which +you've started \fIsaoimage\fR (see \(sc6.2), you should be able to display +images. In addition, you may have magtape access with minimum modifications +to dev$tapecap and may or may not have graphics plotter access. If the +graphics terminal capability is ready the next step is to run the IRAF test +procedure to verify that all is working well, as well as try out a few of +the many tasks in the system. If the graphics terminal is not up yet, there +is probably no point in running the test procedure. To run the test +procedure, read the documentation in the \fIIRAF User Handbook\fP, Volumn +1A, and follow the instructions therein. The test procedure is also +available separately from the anonftp archive on iraf.noao.edu. + +.NH +Configuring the IRAF Environment +.PP +Since IRAF is a machine and operating system independent, distributed system +capable of executing on a heterogeneous network, it has its own environment +facility separate from that of the host system. Host system environment +variables may be accessed as if they are part of the IRAF environment (which +is sometimes useful but which can also be dangerous), but if the same +variable is defined in the IRAF environment it is the IRAF variable which +will be used. The IRAF environment definitions, as defined at CL startup +time, are defined in a number of files in the [IRAF.VMS.HLIB] directory. +Chief among these is the system wide \f(CWzzsetenv.def\fR file. Additional +user modifiable definitions may be given in the user's login.cl file. +.NH 2 +[IRAF.VMS.HLIB]ZZSETENV.DEF +.PP +The zzsetenv.def file contains a number of environment definitions. +Many of these define IRAF logical directories and should be left alone. +Only those definitions in the header area of the file should need to be +edited to customize the file for a site. It is the default editor, +default device, etc., definitions in this file which are most likely to +require modification for a site. +.PP +If the name of a default device is modified, the named device must also have +an entry in the dev$termcap file (terminals and printers) or the +dev$graphcap file (graphics terminals and image displays). There must also +be an \fIeditor\fP.ed file in dev for each supported editor; \fIedt\fR, +\fIemacs\fR, and \fIvi\fR are examples of currently supported editors. +.LP +Sample values of those variables most likely to require modification for +a site are shown below. +.XS +set editor = "vi" +set printer = "versatec" +set stdplot = "lw5" +set stdimage = "imt512" +.XE +.LP +For example, you may wish to change the default editor to "emacs", the +default printer to "vmsprint", or the default image display to "imt800". +Note that the values of terminal and stdgraph, which also appear in the +zzsetenv.def file, have little meaning except for debugging processes run +standalone, as the values of the environment variables are reset +automatically by the IRAF \fIstty\fR task at login time. The default stty +setting in VMS/IRAF V2.10 is "xterm". This is consistent with the default +values of terminal and stdgraph defined in zzsetenv.def to be "xterm" and +would be appropriate for users with workstations running X based +DECwindows/VMS or Motif/VMS. The issues of interfacing new graphics and +image display devices are discussed further in \(sc7.5. +.NH 2 +The template LOGIN.CL +.PP +The template login.cl file, hlib$login.cl, is the file used by \fImkiraf\fR +to produce the user login.cl file. The user login.cl file, after having +possibly been edited by the user, is read and executed by the CL every time +a new CL is started to define the initial configuration of the CL. Hence +this file plays an important role in establishing the IRAF environment seen +by the user. +.PP +Examples of things one might want to change in the template login.cl +are the commented out environment definitions, the commented out CL +parameter assignments, the foreign task definitions making up the default +USER package, and the list of packages to be loaded at startup +time. For example, if there are host tasks or local packages which +should be part of the default IRAF operating environment at your site, +the template login.cl is the place to make the necessary changes. +.NH +Configuring the Device and Networking Files +.PP +The files listed below must be edited before IRAF can be used with the +video terminals, graphics terminals, plotters, printers, magtape devices, +and so on in use at the local site. +.NH 2 +[IRAF.DEV]TAPECAP +.PP +Beginning with V2.10, IRAF magtape devices are described by the \fBtapecap\fR +file, dev$tapecap. This replaces the old "devices" file for all runtime +access to tape devices (the "devices" file is still used however in a lesser +role; see below). The tapecap file describes each local magtape device and +controls all i/o to the device, as well as device allocation. +.PP +The tapecap file included in the distributed system includes some generic +device entries such as "9t-6250" (9track 1/2 inch tape drive at 6250 bpi), +"vms-exabyte" (exabyte EXB-8200 8mm tape drive on VMS), and so on which you +may be able to use as-is to access your local magtape devices. For +example, by default, the device known to the CL as "mta" is a TA78 9tk +drive known as device TU0:, which is locally defined at the system level as +a specific tape drive (actually, in our cluster, $1$MUA0:). Notice how +related entries are chained together in the tapecap file with the tc= field: +.XS +mta|mtahi|mta6250|TA78 9tk tape drive| :tc=mttu0-6250: + +mttu0-6250|mttu0|TA78 half inch reel tape drive (VMS):\e + :al=tu0:dv=tu0:lk=tu0:mr#64512:or#64512:se:tc=9tk-6250: + +9tk-6250|9track 1/2 inch tape drive at 6250 bpi:\e + :dt=9 track at 6250 bpi:tt=2400 foot:ts#140000:\e + :dn#6250:bs#0:mr#65535:or#65535:fb#10: +.XE +.LP +Most likely you will want to add some device aliases, and you may need to +prepare custom device entries for local devices. There must be an entry in +the tapecap file for a magtape device in order to be able to access the device +from within IRAF. +.PP +Instructions for adding devices to the tapecap file are given in +the \fIIRAF V2.10 Revisions Summary\fP. Notes on the VMS specific +implementation of the new magtape facilities are found in \(sc7.2 +of this document. +.NH 2 +[IRAF.DEV]DEVICES +.PP +This file is used to associate IRAF logical device names with VMS device +names. This file is no longer used by the IRAF magtape i/o system which is +now all tapecap based, but is used by host level utilities like +\fIdevstatus\fR which need a simple way to translate IRAF device names to +host device names. The file is optional and need not be configured to run +IRAF. +.NH 2 +The DEVICES.HLP file +.PP +All physical devices that the user might need to access by name should be +documented in the file dev$devices.hlp. Typing +.XS +cl> help devices +.XE +.LP +or just +.XS +cl> devices +.XE +.LP +in the CL will format and output the contents of this file. It is the IRAF +name of the device, as given in files such as termcap, graphcap, and +tapecap, which should appear in this help file. +.NH 2 +[IRAF.DEV]TERMCAP +.PP +There must be entries in this file for all video terminal, graphics +terminal, and printer devices you wish to access from IRAF. The printer is +easy, since the "vmsprint" entry provided should work on any VMS system. To +prepare entries for other devices, simply copy the vmsprint entry and change +the queue name from SYS$PRINT to the name of the queue for the new +printer.\(dg +.FS +\(dgIf the printer or plotter device is on a remote node which is not +clustered with the local node but which is accessible remotely, IRAF +networking must be used to access the remote device. IRAF networking is +also frequently used to access devices on non-VMS (e.g., UNIX) nodes. +.FE +Any number of these entries may be placed in the termcap file, and there can +be multiple entries or aliases for each device. If you have a new terminal +which has no entry in the termcap file provided, a new entry will have to be +added. Termcap is widely used, so it is highly likely that someone +somewhere will already have written a termcap entry for your terminal. If +the terminal in question is a graphics terminal with a device entry in the +graphcap file, you should add a `:gd' capability to the termcap entry. If +the graphcap entry has a different name from the termcap entry, make it +`:gd=\fIgname\fR'. Local additions should be placed at the top of the file +to make it easier to merge the changes into a future IRAF release. +.NH 2 +[IRAF.DEV]GRAPHCAP +.PP +There must be entries in the graphcap file for all graphics terminals, batch +plotters, and image displays accessed by IRAF programs. New graphics +terminals will need a new entry. The IRAF file gio$doc/gio.hlp contains +documentation describing how to prepare graphcap device entries. A printed +copy of this [60 page] document is available from the iraf/docs directory in +the IRAF network archive. However, once IRAF is up you may find it easier +to generate your own copy using \fIhelp\fR, as follows: +.XS +cl> help gio$doc/gio.hlp fi+ | lprint +.XE +.LP +which will print the document on the default IRAF printer device (use the +"device=" hidden parameter to specify a different device). Alternatively, +to view the file on the terminal, +.XS +cl> phelp gio$doc/gio.hlp fi+ +.XE +.LP +The help pages for the IRAF tasks \fIshowcap\fR and \fIstty\fR should also +be reviewed as these utilities are useful for generating new graphcap +entries. The i/o logging feature of \fIstty\fR is useful for determining +exactly what characters your graphcap device entry is generating. The +\fIgdevices\fR task is useful for printing summary information about the +available graphics devices. +.PP +Help preparing new graphcap device entries is available if needed. We ask +that new graphcap entries be sent back to us so that we may include them in +the master graphcap file for all to benefit. +.NH 2 +[IRAF.DEV]HOSTS, UHOSTS, and IRAFHOSTS +.PP +The dev directory contains several files (\f(CWhosts\fR, \f(CWirafhosts\fR, +and \f(CWuhosts\fR) used by the IRAF network interface. IRAF networking is +used to access remote image displays, printers, magtape devices, files, +images, etc., via the network. IRAF network nodes do not have to have the +same architecture, or even run the same operating system, i.e., one can +access a UNIX/IRAF node from VMS/IRAF and vice versa. V2.10 IRAF contains +extensive changes to the networking code to permit remote client access to a +VMS node via TCP/IP, and runtime selection of either TCP/IP or DECNET for +the transport method. Editing changes to the networking related files in +[IRAF.DEV] are illustrated here. Further documentation on the networking +interface can be found in the \fIIRAF Version 2.10 Revisions Notes\fP and +\(sc7.1 of this manual. +.PP +The \f(CWdev$hosts\fR file is used to configure IRAF networking on the local +system. This file tells IRAF what network nodes are defined and how to +connect to them, including the protocol to be used. Initially IRAF +networking is disabled. To enable networking there must be an entry in +the hosts file for the host IRAF is running on. To do anything useful +with networking there must also be entries for the nodes you wish to +connect to. Often a single VMS/IRAF installation and a single copy of +dev$hosts are shared by several nodes in a VMS cluster. +.LP +To connect to a local VMS node via DECNET requires an entry in the hosts +file like the following (these and the following examples are taken from +the NOAO VMS/IRAF hosts file). +.XS +robur r : robur::0=irafks +draco : draco::0=irafks +.XE +.LP +Here, nodes "robur" and "draco" are defined as DECNET-connected nodes with +the IRAF kernel server (IRAFKS) installed as a "zero numbered" object in +DECNET. IRAFKS can also be installed as a numbered DECNET service, in which +case the hosts file entry should appears as follows. +.XS +robur r : robur::242 +draco : draco::242 +.XE +.LP +In this example the IRAFKS service is installed locally as object number +242 in DECNET. +.LP +To connect to a node on a remote UNIX host via TCP/IP requires an entry +using "!" to indicate the TCP/IP protocol, followed by the UNIX command +to be executed to start up the IRAF kernel server, as in the following +examples (note the different machine types). +.XS +cephus : cephus!/usr/iraf/bin.ddec/irafks.e +columba : columba!/usr1/iraf/iraf/bin.mips/irafks.e +felis : felis!/u1/iraf/iraf/bin.rs6000/irafks.e +lepus : lepus!/usr/iraf/bin.f2c/irafks.e +noctua : noctua!/usr/iraf/iraf/bin.irix/irafks.e +ursa u : ursa!/local/iraf/bin.sparc/irafks.e +vega : vega!/iraf/iraf/bin.hp700/irafks.e +.XE +.LP +Finally, the hosts file may contain logical node entries. These are not +real network nodes, but hosts file entries which point to some other entry +in the same host table. These are most commonly used to designate logical +nodes for disposing of output to different classes of devices such as +printers and plotters, hosted by some node elsewhere on the network, but +can be used for other purposes such as gateways. +.XS +# Logical nodes (lpnode = line printer output, plnode = plotter output). +lpnode : @ursa +plnode : @ursa +.XE +.LP +In the example above node ursa is a Sun server; the hosts file entry for this +node is given in an earlier example above. +.PP +The other files required to configure IRAF networking are the \f(CWuhosts\fR +and \f(CWirafhosts\fR files. The \f(CWuhosts\fR file is a standard internet +host table containing hostnames and internet numbers. It is used for TCP/IP +networking unless the logical name IRAFUHNT is defined to point to an +alternate file (e.g., Multinet uses a hosts file which IRAF networking can +access directly). The uhosts file, if used, should be replaced by a host +listing for your local site. One way to do this is to copy the /etc/hosts +file from a local UNIX host. Note that V2.10 VMS/IRAF TCP/IP networking +does not support runtime lookup of hostnames via a name service, hence an +internet host must have an entry in the uhosts or IRAFUHNT file for VMS/IRAF +to be able to connect to the host. +.PP +The \f(CWirafhosts\fP file supplies login information used by IRAF +networking when a connection is made. When a network login is attempted the +networking system will use the user's .irafhosts file if there is one, +otherwise it defaults to the irafhosts file in dev. The system version of +irafhosts should not need to be modified unless proxy logins are enabled on +the local host. Proxy logins are used to eliminate password prompts when +making network connections between cooperating machines in the local VMS +cluster. This is a desirable but optional feature in all but one case, +network gateways. When IRAF network connections are routed through a local +VMS machine serving as a gateway machine password prompts are not possible, +and one must either enable proxy logins or supply each user with a .irafhosts +file containing their password. Proxy logins are probably the least +objectionable of these two options. +.PP +Thus far we have discussed the IRAF networking configuration only as it +appears from the VMS side of the network, i.e., what one sees when +configuring the dev$hosts and other files on a VMS host. This is sufficient +to allow one VMS/IRAF host to network to another, or to allow a VMS/IRAF +host to connect to an external host machine running UNIX. The remaining +case occurs when IRAF running on a UNIX host connects to VMS/IRAF. To +enable such "incoming" TCP/IP network connections one must make an entry +for each VMS host in the dev$hosts file on the UNIX/IRAF (client side) host, +as in the following example. +.XS +# VMS (decnet) nodes, via internet gateway robur. +robur r : -rcb robur!irafks +draco : @robur!draco +grian : @robur!grian +lenore : @robur!lenore +vela : @robur!vela +.XE +.LP +In this example all incoming (TCP/IP) connections are routed via the VMS +gateway machine robur. The "irafks" is a DCL symbol defined on the server +node in hlib$irafuser.com which runs the IRAF kernel server, +irafbin:irafks.exe. The "@robur!nodename" syntax for the VMS nodes other +than robur tells IRAF running on the UNIX host to use node robur as the +gateway. The connection to node robur is made via the rexec-callback IRAF +networking connect protocol (see \(sc7.1 and also the V2.10 IRAF system +notes file). The connection from the gateway machine to the target VMS node +is controlled by the dev$hosts file on the \fIgateway\fR (VMS) node, and +will often be a DECNET connection, hence the gateway can serve to connect +the TCP/IP and DECNET domains. +.PP +Once again, for gateway connects to succeed either proxy logins must be +enabled on the gateway machine, or each user must have a .irafhosts file on +the gateway machine containing password information. For incoming TCP/IP +network connections to work the VMS node must support the \fIrexec\fR +network service, which is only available via third party networking packages +such as Multinet. However, since IRAF networking supports gateways only +the gateway host need run this software. When properly configured, gateways +are transparent to the user. +.PP +To fully configure IRAF networking some VMS-level configuration is necessary +in addition to editing the hosts, uhosts, and irafhosts files (for example +IRAFKS should be defined as a known DECNET service). This is discussed +further in \(sc7.1. + +.NH +Vector Graphics and Image Display using X Windows +.PP +In this section we discuss some DECwindows/VMS and Motif/VMS (X window +system) utilities for use with IRAF running on VMS workstations. Further +information can be found in the file \f(CW0readme\fR in the [IRAF.VMS.X11] +directory. Note that VMS/IRAF can also be used with an X user interface +running on a remote UNIX workstation, with only VMS/IRAF running on the VMS +host. This section is relevant only if you need to run the X clients +directly on a VMS host. We discuss only \fIxterm\fR and \fIsaoimage\fR here +since these were the only X clients available for graphics and image display +at the time this was written, but newer facilties may be available before +this document is again revised. Check with the IRAF group for more current +information on support for graphics and imaging under the X window system. +.NH 2 +Xterm +.PP +\fIXterm\fR is a public-domain version of the standard MIT X window system +terminal emulator, modified to work on VMS. It is a two-window tool capable +of emulating a VT102 terminal and a Tektronix 4014 terminal. Appropriate +escape sequences will cause \fIxterm\fR to switch between these two modes, but +some programs require the user to make the change (using the CTRL-middle +mouse button menu). It is especially valuable for IRAF use since it allows +a plotted graph to be kept in the Tektronix emulation window while commands +are given in the VT102 emulation window. +.PP +Due to significant changes between VMS and DECwindows versions, there are +three different versions of \fIxterm\fR: +.RS +.LP +1) Xterm 1.1 (XTERM11.EXE) - for VMS 5.1 to 5.3-x, with DECwindows +.br +2) Xterm 1.2 (XTERM12.EXE) - for VMS 5.4-x and later, with DECwindows +.br +3) Xterm 2.1 (XTERM21.EXE) - for VMS 5.4-x and later, with DECwindows/Motif +.RE +.LP +A common mistake is to run the CL from a DECterm window, which does not +support IRAF graphics. To use IRAF interactive graphics tasks one must +run IRAF from an \fIxterm\fR window (or any similar terminal emulator +supported by IRAF, e.g., \fIgterm\fR, \fIxgterm\fR, etc.). To use +\fIxterm\fR with IRAF we recommend that the "xtermr" graphcap entry be +used. This is set as follows: +.XS +cl> stty xtermr nl=54 +.XE +.LP +By default, this entry has 65 lines in the text window. If your setup +is different (perhaps 54 lines instead of 65) you can make +changes as shown on the stty command line. The "xterm" stty setting is +an alias for the "xtermr" stty setting; they can be used interchangeably. +.PP +The xtermr graphcap entry writes the status line in the TEK window, not +in the text window. This is the preferred setup, since DEC hasn't yet +made available the customize feature for "focus follows cursor", meaning +there is no way around needing to click-to-focus. Use of xtermr requires +the least amount of clicking. +.PP +You should not click inside the TEK window to focus on it, but on its header +or border. Otherwise, the mouse click returns a character which terminates +cursor mode. Clicking on the border provides focus without reporting any +events, since the cursor is not inside the "active" region. +.NH 2 +SAOimage +.PP +\fISaoimage\fP is an X-windows based image display server originally +developed by the Smithsonian Astrophysical Observatory. It provides a large +selection of options for zooming, panning, scaling, coloring, pixel +readback, display blinking, and region specifications. User interactions +are usually performed with the mouse. The version of \fIsaoimage\fR +included with the VMS/IRAF V2.10 distribution is 1.07; newer versions may be +available from the IRAF archives. You must have \fIsaoimage\fR running, +although it can be iconified, before attempting to write to it. More +information may be found in the \f(CW0readme\fR file in the [IRAF.VMS.X11] +directory. + +.NH +Additional System Configuration Issues +.NH 2 +New networking driver +.PP +This section contains notes on the new V2.10 IRAF networking interface as +implemented for VMS. Further information can be found in \(sc5.6 of +this manual, the \fIIRAF Version 2.10 Revisions Summary\fP, and the +VMS/IRAF system notes file, iraf$local/notes.vms. +.PP +The VMS/IRAF networking code was extensively revised for V2.10 to permit +client access to a VMS node via TCP/IP, and runtime selection of TCP/IP or +DECNET for the transport method. +.LP +Selection of the transport protocol is made in the dev$hosts file, as in +the examples below. +.XS +robur r : robur::0=irafks +ursa u : ursa!/local/iraf/bin.sparc/irafks.e +.XE +.LP +The first example above states that logical node robur, with alias r, is a +DECNET domain node named robur. The DECNET connection is to be made by +executing the command "irafks" on the remote node. User login information +is supplied by the user's .irafhosts file if any, otherwise by dev$irafhosts. +A numbered DECNET object could be used instead, in which case the syntax on +the right would change to "robur::\fIn\fR", where \fIn\fR is the number +of the DECNET object to connect to. +.PP +The second example states that logical node ursa, with alias u, is a TCP/IP +domain node with network name ursa. The network connection is made by +executing, on the remote node ursa, the host command given after the "!". +VMS/IRAF supports only the IRAF \fIrexec\fR connect protocol for outgoing +connections to TCP/IP servers. TCP/IP connections are discussed in more +detail below. +.NH 3 +DECNET networking +.PP +In the simplest form of a DECNET connection the hosts file entry for the +server node will reference a zero-numbered network object as in the example, +e.g., "hostname::0=irafks" (or "hostname::task=irafks"). If "irafks" is +\fInot\fR a defined DECNET network object then the user must have a file +IRAFKS.COM in their login directory, similar to the following: +.XS +$! IRAFKS.COM -- Fire up the iraf kernel server under DECNET. +$! +$ if f$mode() .nes. "NETWORK" then exit +$! +$! iraf ! uncomment if not in login.com +$ irafks :== "$irafbin:irafks" ! define irafks as a foreign task +$ irafks dn.irafks ! start the iraf kernel server +$ logout +.XE +.LP +This works, but has the disadvantage that every user account must have +an IRAFKS.COM file in the login directory, or IRAF DECNET-based networking +will not work. A better approach is to define IRAFKS as a known network +object which will execute the file IRAFKS.COM supplied in the IRAFHLIB +directory with V2.10 VMS/IRAF. This eliminates the need for each user to +have a private copy of the IRAFKS.COM file, and makes proxy logins possible, +which can eliminate the need for password prompts. +.PP +The following is an example of how to install irafks as a known network +object. This must be done on each DECNET host. The device name USR$3: +shown in the example should be replaced by the value of IRAFDISK: on the +local system. +.XS +$ run sys$system:ncp +ncp> define object irafks - + number 0 file usr$3:[iraf.vms.hlib]irafks.com +ncp> set object irafks - + number 0 file usr$3:[iraf.vms.hlib]irafks.com +ncp> exit +.XE +.LP +In normal operation the NCP configuration is automatically preserved when +the system is rebooted. If the local system has a network configuration +procedure to redefine the NCP settings in the event of damage to the network +database, then an NCP DEFINE command similar to that shown should be added +to this file. +.PP +An alternative to the above scheme is to define IRAFKS as a numbered system +object. This works as above, except that the "number 0" becomes "number +\fIn\fR", where \fIn\fR is the network object number, and the dev$hosts file +syntax for the server becomes "\fIhostname\fR::\fIn\fR". +.NH 3 +Proxy logins +.PP +The DECNET \fIproxy login\fR capability allows DECNET connections to be made +between a set of well-known cooperating systems (e.g., the local cluster) +without the need to supply login authentication information every time a +network connection is made. The effect is to eliminate password prompts, +thereby making networking much more transparent to the user. In some cases +eliminating password prompts is necessary to make the software function +correctly, for example when using a VMS host as a gateway machine +interactive prompting for passwords is not possible, and the gateway cannot +function correctly without some way to disable password prompts. In the +case of IRAF networking this can be done by having the user put password +information in their .irafhosts file, but the use of proxy logins is preferred +since it avoids plaintext passwords and avoids the need for the .irafhosts +file altogether. +.PP +To enable proxy logins for IRAF networking one must first define IRAFKS (the +IRAF kernel server) as a known network object, as outlined in the previous +section. The VMS \fIauthorize\fR utility is then used to enable proxy +logins. +.LP +For example, assume we have two nodes ROBUR and DRACO. +.XS +$ run sys$system:authorize ! run on node robur +authorize> add/proxy draco::* */default + +$ run sys$system:authorize ! run on node draco +authorize> add/proxy robur::* */default +.XE +.LP +This would enable proxy logins between nodes draco and robur for all user +accounts that have the same user login name on both systems. Alternatively +one could do this for only a specified set of user accounts. The authorize +utility automatically updates the affected disk files so that the change +will be preserved the next time the system is booted. +.PP +To eliminate the password prompts during IRAF networking connections one +must also edit the user .irafhosts file, or the system irafhosts file (in +dev) to disable login authentication. For example, if the dev$irafhosts +file contains +.XS +# dev$irafhosts + +draco : none +robur : none +* : ? +.XE +.LP +then authentication will be disabled for connections made between nodes +draco and robur, but a password will be required to connect to any other +node. The above irafhosts file would result in a DECNET login request +such as +.XS +hostname"username"::"0=irafks" +.XE +.LP +which forces a login as "username" on the remote host. If the user name is +omitted, the default proxy login on the remote node is used. +The user's .irafhosts file, if present, will be used instead and should +be configured similarly. +.PP +These changes make IRAF DECNET based networking transparent between +cooperating nodes in a local network, without requiring users to place +password information in .irafhosts files. This is especially desirable if a +routing node is used to route IRAF networking connections between TCP/IP and +DECNET networks. +.NH 3 +Configuring a VMS host as a TCP/IP server +.PP +For incoming TCP/IP connections (VMS node acting as server) VMS/IRAF supports +two connect protocols, \fIrexec\fR and \fIrexec-callback\fR. The \fIrsh\fR +protocol, the default connect protocol for V2.10 UNIX/IRAF systems, is not +supported by VMS/IRAF. To act as a TCP/IP server a VMS node must run a +host-level networking package (such as Multinet) which supports the +\fIrexecd\fR networking daemon. +.LP +On the UNIX side the dev$hosts entry for a directly-connected VMS node +should be similar to the following example. +.XS +robur r : -rcb robur!irafks +.XE +.LP +This specifies that for logical node robur, alias r, the rexec-callback +connect protocol (TCP/IP) should be used to connect to the network node +robur. The command to be executed on the remote node is whatever is to +the right of the "!", i.e., the command "irafks" in our example. +.PP +When the \fIrexecd\fR daemon executing on the remote VMS node responds, +the first thing it will do is login using the username and password +supplied with the rexec request, and execute the user's LOGIN.COM file. +For an IRAF user this must contain the command \fIiraf\fR, which causes +the IRAFUSER.COM file in [IRAF.VMS.HLIB] to be interpreted by DCL. +This defines all the IRAF logical names and symbols. One of the sybols +defined is the \fIirafks\fR command which is subsequently executed to +complete the rexec network request. The \fIirafks\fR command is defined +in IRAFUSER.COM as follows: +.XS +$ irafks :== $irafbin:irafks ! IRAF network kernel server +.XE +.LP +Hence, as might be expected, the result of the rexec connect is to run the +IRAF kernel server irafbin:irafks.exe on the server node. In the case of +the rexec-callback connect protocol, the actual command passed to DCL +includes command line arguments to the IRAF kernel server telling it how to +call the client back on a private network socket. What happens is that the +client reserves a port and creates a socket on this port, then issues a +rexec call to the VMS system to run the kernel server. The port and host +name are passed on the rexec command line. The \fIrexecd\fR daemon on the +server runs the irafks.exe process on the VMS node, and irafks calls the +client back on the socket reserved by the client. The end result is a high +bandwidth direct socket connection between the client and server processes. +.PP +See the discussion in \(sc5.6 for a discussion of TCP/IP and DECNET +internetworking, including examples of how to configure a VMS node as an +Internet gateway for IRAF networking. +.NH 3 +Network security alarms +.PP +One potential consequence of IRAF networking is that, if IRAF networking is +not properly configured (either at the system level or at the user level), +network connection attempts may fail, and IRAF in its normal operation may +repeatedly generate failed connection attempts. Repeated failed connection +attempts can trigger network security alarms on a VMS system, even though no +real security problem exists. VMS systems managers should be aware of this +possibility so that they don't waste time trying to track down a potential +network security problem which doesn't exist. Should this circumstance +occur, the best solution is to properly configure IRAF networking so that +the connection attempts succeed, e.g., by setting up the user's .irafhosts +file, or by enabling proxy logins for the user. +.NH 2 +New magtape driver +.PP +This section contains notes on the new V2.10 IRAF magtape driver as +implemented for VMS. The reader is assumed to be familiar with the +basics of magtape access in IRAF, including remote access to a drive via +IRAF networking. Further information can be found in \(sc5.1 of this +manual, in the \fIIRAF Version 2.10 Revisions Summary\fP, and in the +VMS/IRAF system notes file, iraf$local/notes.vms. +.NH 3 +Allocation +.PP +Explicit allocation of magtape devices is now optional. If the drive is not +allocated with the CL \fIallocate\fR command it will be automatically +allocated and mounted when the first tape access occurs. Once allocated, it +stays allocated even if you log out of the CL and back in, allowing +successive IRAF or other processes to access the drive without it being +deallocated. +.PP +The tape drive can be allocated at the VMS level (e.g., "allocate tu4:") +before starting the CL. This reserves the drive but if you run +\fIdevstatus\fR in the CL it will report that the drive has not been +"allocated", because IRAF doesn't consider the drive allocated in the IRAF +sense unless it has been both allocated and mounted at the VMS level. One +can either allocate the drive in the CL, or run an IRAF magtape task which +accesses the drive to cause the drive to be automatically allocated and +mounted. +.PP +If the drive is allocated in DCL before starting IRAF, then allocated and +deallocated in the CL, when you log out of the CL the drive will still be +allocated at the VMS level even though it was deallocated in the CL. If the +drive is NOT allocated in DCL before starting the CL, allocating and +deallocating the drive in the CL and then exiting will result in the drive +not being allocated at the VMS level. +.NH 3 +Density +.PP +When a drive is automounted it is possible to set the density. The V2.10 +implementation supports this (you just write to mta1600 or whatever), but +this does not work reliably since VMS requires that the first operation +following a mount which changes the density be a write. Often the write +is preceded by a file positioning operation such as a rewind or seek to +end of tape, which prevents the density from being changed. +.PP +To reliably change the tape density, do an "init/density=NNN device" at the +DCL level and verify the new density with "show magtape" ("!init", "!show" +in IRAF). It may be necessary to repeat the operation before it succeeds. +.NH 3 +Status output logging +.PP +Status output logging is fully implemented in VMS/IRAF, i.e., one can +enable status output and direct the messages to a text file, a terminal, or +a network socket. +.PP +For VMS/IRAF the magtape naming conventions have been extended slightly +to allow the different types of status output logging devices to be indicated. +.DS +.TS +l l. +:so=.foo log to file "foo" +:so=>foo log to terminal "foo:" +:so=foo log to socket on node "foo" +.TE +.DE +.LP +For example, "mtexamine mta[:so=orion]" would examine the files on drive +\f(CWmta\fR, optionally sending status output messages to a tape status +daemon running on network node orion. Logging to a named terminal device +will usually fail due to permission problems, but logging to ">tt" will +direct status output to the current terminal window. +.LP +The VMS version of the driver will print a device type string such as +.XS +$2$MUA1: (ROBUR) - 9 track at 6250 bpi +.XE +.LP +where the first part of the message comes from VMS and the " - ..." is from +tapecap. The density field can be either the tapecap value or the runtime +GETDVI value. For example, if the density is shown as "6250" this is the +value from the tapecap entry. If the density is shown as "(6250)", i.e., in +parentheses, this is the actual device value as determined by a GETDVI call +to VMS. Note that it is possible for the density given in the tapecap entry +to differ from the actual device density setting. In this case the tape +will be written correctly, but the "Device Type", "Capacity" and "Tape Used +(%)" status fields will be incorrect. To avoid this problem be sure the +density of the tapecap entry you are using to access the drive matches the +density value of the physical device. +.PP +To enable status output logging to a socket a network magtape status display +server such as \fIxtapemon\fR must be started on the remote node before +accessing the tape drive. To permanently direct status output to a node a +statement such as 'set tapecap = ":so=\fIhostname\fR"' may be added to the +login.cl or loginuser.cl file. +.NH 3 +Using tape drives over the network +.PP +Changes in the VMS/IRAF V2.10 magtape and networking interfaces make it +possible to remotely use VMS tape drives from Internet (UNIX) or DECNET +hosts. In practice this is straightforward, but there are two caveats to +keep in mind: 1) do not explicitly allocate the device, 2) if you run IRAF +tasks in different packages that access the same tape drive, type \fIflpr\fR +before running a task in a different package. Aside from these two items, +everything should work as when accessing a magtape device directly on a UNIX +or VMS system. Both problems arise from the way VMS handles device +allocation. +.PP +Explicitly allocating a device does not work in VMS/IRAF when remotely +accessing a tape drive because the effect is to allocate the drive to the +kernel server process for the client CL, thereby preventing other client +IRAF processes from accessing the drive. In practice this is not a problem +since it is not necessary to explicitly allocate the device; the VMS/IRAF +kernel server will automatically allocate and mount the device when it is +accessed over the network. +.PP +An example of the problem of trying to access a remote VMS drive from two +different IRAF packages occurs when the \fIrewind\fR task, which is in the +SYSTEM package, is used in conjunction with DATAIO tasks such as +\fIrfits\fR, \fIwfits\fR, or \fImtexamine\fR. You can run tasks in a given +package at will, but if you try to access the drive with a task in a +different package there will be a conflict. Again, the problem is that when +remotely accessing a device, the VMS device allocation facilities cause the +device to be allocated to the kernel server \fIprocess\fR, rather than to +the user. There is a one-to-one correspondence between client-side IRAF +processes and kernel server processes. In IRAF each package has its own +executable, and hence its own kernel server, leading to the allocate +conflict. +.PP +For example if you have been using \fIrfits\fR (DATAIO) and you want to do a +\fIrewind\fR (SYSTEM), type "flpr rfits" and wait 5-10 seconds, then you +should be able to do the rewind. To run another DATAIO task, type "flpr +rewind" and again wait 5-10 seconds before running the DATAIO task. The +delay is necessary to wait for VMS to shutdown the kernel server for the +package which previously had the device allocated. +.NH 2 +Configuring user accounts for IRAF +.PP +User accounts should be loosely modeled after the IRAF account. All that is +required for a user to run IRAF is that they run \fImkiraf\fR in their +desired IRAF login directory before starting up the CL. Each user should +review the resulting login.cl file and make any changes they wish. Any user +wanting to run batch jobs, including printer access, must execute the +`\fIiraf\fP' command in their LOGIN.COM file, making sure it is executed for +non-interactive jobs. Individual process quotas for IRAF users should be +set as described in the next section. +.NH 2 +VMS quotas and privileges required to run IRAF +.PP +The only privilege required by IRAF is TMPMBX, which is probably +already standard on your system. Systems with DECNET capabilities should also +give their users NETMBX privilege, although it is not required to run IRAF. +No other privileges are required or useful for normal activities. +.PP +Although privileges are no problem for VMS/IRAF, it is essential that the +IRAF user have sufficient VMS quota, and that the system tuning parameters +be set correctly, otherwise IRAF will not be able to function well or may +not function at all. If a quota is exceeded, or if the system runs out of +some limited resource, the affected VMS system service will return an error +code to IRAF and the operation will fail (this frequently happens when +trying to spawn a connected subprocess). The current recommended ranges of +per-user quotas are summarized below. Users running DECwindows/Motif may +already have, and may definitely need, larger numbers for these quotas, so +don't reduce them to these values. +.DS +.TS +ci ci ci +l n n. +quota minimum recommended +.sp +BYTLM 20480 30720 +PGFLQUOTA 15000 30720 +PRCLM 5 10 +WSDEFAULT 512 512 +WSEXTENT 4096 WSMAX +JTQUOTA 2048 2048 +FILLM 30 60 +.TE +.DE +.PP +The significance of most of these quotas is no different for IRAF than for +any other VMS program, hence we will not discuss them further here. +The PRCLM quota is especially significant for IRAF since an IRAF job +typically executes as several concurrent processes. The PRCLM quota +determines the maximum number of subprocesses a root process (user) may have. +Once the quota has been reached process spawns will fail causing the IRAF +job or operation to abort. +.PP +The minimum number of subprocesses a CL process can have is 1 (x_system.e). +As soon as a DCL command is executed via OS escape a DCL subprocess is +spawned, and we have 2 subprocesses. The typical process cache limit is 3, +one slot in the cache being used by x_system.e, hence with a full cache we +have 4 subprocesses (the user can increase the process cache size if +sufficient quota is available to avoid excessive process spawning when +running complex scripts). It is common to have one graphics kernel +connected, hence in normal use the typical maximum subprocess count is 5. +However, it is conceivable to have up to 3 graphics kernel processes +connected at any one time, and whenever a background job is submitted to run +as a subprocess a whole new subprocess tree is created. Hence, it is +possible to run IRAF with a PRCLM of 5, but occasional process spawn +failures can be expected. Process spawn failures are possible even with a +PRCLM of 10 if subprocess type batch jobs are used (the default), but in +practice such failures are rare. If all batch jobs are run in batch queues +it should be possible to work comfortably with a PRCLM of 5-6, but in +practice users seem to prefer to avoid the use of batch queues, except for +very large jobs. +.PP +Since IRAF uses memory efficiently the working set parameters do not seem +critical to IRAF, provided the values are not set unrealistically low, and +provided WSEXTENT is set large enough to permit automatic growth of a +process working set when needed. Configuring VMS to steal pages from +inactive processes is not recommended as it partially cancels the effect of +the process cache, causing process pagein whenever a task is executed. It +is better to allow at least a minimum size working set to each process. +However, this is not a hard and fast rule, being dependent on individual +system configurations and workloads. +.PP +In addition to sufficient per user authorized quota, the system tuning +parameters must be set to provide enough dynamically allocatable global +pages and global sections to handle the expected load. If these parameters +are set too small, process connects will fail intermittently, usually when +the system load is high. Each subprocess needs about 8 global pages when +activated (IRAF uses global pages and shared memory for interprocess +communications, due to the relatively low bandwidth achievable with the +VMS mailbox facilities). +.PP +With IRAF in heavy use (i.e., a dozen simultaneous users) this can easily +reach a requirement for several hundred additional global pages. Each +installed image and subprocess also needs at least one, usually two, global +sections. Note that the size of the executable found by doing a +DIR/SIZE=ALL on [IRAF.BIN]*.EXE can be considered an upper bound to the +number of pages needed to install it (if anyone wants to play it safe: +typically, it's about 50-70 percent of this size). Currently, for 2.10, we +have CL=357, S_IRAF=1267, IRAFKS=23, X_SYSTEM=106, X_PLOT=159, and +X_IMAGES=786. The system parameters on our 8600 (which is probably a worst +case example) are currently set to GBLPAGES = 12120 and GBLSECTIONS = 230. +For every increment of 512 in GBLPAGES, GBLSECTIONS must be increased by 4. +After making any of these changes, we recommend running AUTOGEN to ensure +correct relationships among the many sysgen parameters. +.NH 2 +Interfacing new graphics devices +.PP +There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +.NH 3 +Graphics terminals +.PP +The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal or terminal emulator, using the stdgraph +graphics kernel supplied with the system. All one need do to interface to a +new graphics terminal is add new graphcap and termcap entries for the +device. This can take anywhere from a few hours to a few days, depending on +one's level of expertise, and the characteristics of the device. Be sure to +check the contents of the dev$graphcap file to see if the terminal is +already supported, before trying to write a new entry. Useful documentation +for writing graphcap entries is the GIO reference manual and the HELP pages +for the \fIshowcap\fP and \fIstty\fP tasks (see \(sc5.5). Assistance with +interfacing new graphics terminals is available via the IRAF Hotline. +.NH 3 +Graphics plotters +.PP +The current IRAF system comes with several graphics kernels used to drive +graphics plotters. The standard plotter interface is the SGI graphics kernel, +which is interfaced as the tasks \fIsgikern\fP and \fIstdplot\fP in the +PLOT package. Further information on the SGI plotter interface is given in +the paper \fIThe IRAF Simple Graphics Interface\fP, a copy of which is +available from the network archive. +.PP +SGI device interfaces for most plotter devices already exist, and adding +support for new devices is straightforward. Sources for the SGI device +translators supplied with the distributed system are maintained in the +directory iraf$vms/gdev/sgidev. NOAO serves as a clearinghouse for new SGI +plotter device interfaces; contact us if you do not find support for a local +plotter device in the distributed system, and if you plan to implement a new +device interface let us know so that we may help other sites with the same +device. +.PP +The older NCAR kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +plots on devices supported by host-level NCAR metacode translators. The +host level NCAR metacode translators are not included in the standard IRAF +distribution, but public domain versions of the NCAR implementation for VMS +systems are widely available. A site which already has the NCAR software +may wish to go this route, but the SGI interface will provide a more +efficient and simpler solution in most cases. +.PP +The remaining possibility with the current system is the calcomp kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. To make use of such a library to get +plotter output on any devices supported by the interface, one may copy +the library to the hlib directory and relink the Calcomp graphics +kernel. +.PP +A graphcap entry for each new device will also be required. Information on +preparing graphcap entries for graphics devices is given in the GIO design +document, and many actual working examples will be found in the graphcap +file. The best approach is usually to copy one of these and modify it. +.NH 3 +Image display devices +.PP +The majority of VMS/IRAF users will use a networked UNIX or VMS workstation +running some version of the X window system (DECwindows/VMS or Motif/VMS in +the case of VMS) for IRAF graphics and image display. X clients for +graphics and image display are available for all IRAF platforms. See \(sc6.1 +of this manual for information about the \fIxterm\fR graphics terminal +emulator and the \fIsaoimage\fR image display server. +.PP +Those VMS/IRAF sites that have VAX/VMS workstations running the VWS display +system can use the UISDISP.EXE display task in [IRAF.VMS.UIS] for image +display. This is a standalone IMFORT program, i.e. it does not communicate +with the tasks in the TV.DISPLAY package. See the file uisdisp.txt in the +same directory for information on using the task. +.PP +Some interfaces for hardware image display devices are also available, +although a general display interface is not yet included in the system. +Only the IIS model 70 and 75 are currently supported by NOAO. Interfaces +for other devices are possible using the current datastream interface, +which is based on the IIS model 70 datastream protocol with extensions +for passing the WCS, image cursor readback, etc. (see the ZFIOGD driver +in iraf$vms/gdev). This is how all the current displays, e.g., imtool +and saoimage, and the IIS devices, are interfaced, and there is no reason +why other devices could not be interfaced to IRAF via the same interface. +Eventually this prototype interface will be obsoleted and replaced by a +more general interface. +.PP +If there is no IRAF interface for your device, the best approach at present +is to use the IMFORT interface and whatever non-IRAF display software you +currently have to construct a host level Fortran or C display program. The +IMFORT library provides host system Fortran or C programs with access to +IRAF images on disk. Documentation on the IMFORT interface is available in +\fIA User's Guide to Fortran Programming in IRAF -- The IMFORT Interface\fP, +Doug Tody, September 1986, a copy of which is included in the IRAF User +Handbook, Volume 1A. If you do not have an existing image display program +into which to insert IMFORT calls, it is not recommended that the TV.DISPLAY +package code be used as a template. Rather, a standalone image display +server should be constructed using the datastream protocol in the +iraf$vms/gdev/zfiogd.x driver mentioned above (but that could be a very +lengthy job; contact the Hotline). + +.NH +Tuning Considerations +.PP +There are a number of things that can be done to tune VMS/IRAF for a +particular host system: +.RS +.IP \(bu +Install the executables to permit shared memory. +.IP \(bu +Render the large runtime files contiguous to increase i/o efficiency. +.IP \(bu +Precompile selected TERMCAP and GRAPHCAP entries. +.IP \(bu +Strip the system to reduce disk consumption. +.RE +.NH 2 +Stripping the system to reduce disk consumption +.PP +If the system is to be installed on multiple cpu's, or on a particularly +small host like a MicroVAX, it may be necessary or desirable to strip the +system of all non-runtime files to save disk space. This is done by deleting +all the program sources and all the sources for the reference manuals and +other printed documentation, but not the online manual pages. A special +utility called \fIrmfiles\fP (in the SOFTOOLS package) is provided for this +purpose. It is not however necessary to run rmfiles directly to strip +the system. This may be done either from DCL or from within the CL. +.XS +$ set default [iraf] +$ mkpkg strip +$ set default [iraf.noao] +$ mkpkg strip +.XE +.LP +This will preserve all runtime files, permitting use of the standard runtime +system as well as user software development. Stripping the system will +\fInot\fP, however, permit relinking standard IRAF executables, as would be +required for bug fixes or caching termcap and graphcap entries. The size of +the system is reduced by about half. We do not recommend stripping the +system libraries, as this would preclude all IRAF related software +development or bug fixes, including user written Fortran programs (IMFORT), +and we no longer provide a "\fIstripall\fR" option. +.NH 2 +Installing executable images +.PP +The standard distribution of VMS/IRAF is configured to use a shared library +for the bulk of the IRAF runtime system code. Use of this shared library +considerably reduces the disk requirements of the system, while reducing +runtime system memory usage and process pagein time, and speeding up process +links during software development. +.PP +If the goal of minimizing physical memory utilization is to be achieved +when running IRAF, it is essential that the IRAF shared library be "installed" +in VMS system shared memory. Further memory savings through memory sharing +can be achieved if some of the more commonly used IRAF executables are also +installed. This becomes increasingly important as the number of IRAF users +increases, but some memory savings may result even if there is only one user, +since a single user may spawn batch jobs. Hence, the shared library +s_iraf.exe should always be installed if IRAF is used at all, and +cl.exe and x_system.exe are used by all IRAF jobs and should +be installed if there is usually at least one IRAF user on the system. +If there are usually several IRAF users on the system x_images.exe and +x_plot.exe are probably worth installing as well. +.PP +Installation of task images in system shared memory is done with the VMS +INSTALL utility, which requires CMKRNL privilege to execute (also discussed +in \(sc2.3.2). Installation of the IRAF shared library and other task +images is most conveniently done by executing the INSTALL.COM command +procedure in hlib. The list of files to be installed is in INSTALL.LST. +This file should be reviewed and edited during system installation to select +those images to be installed on the local host. Then INSTALL.COM may be +directly executed to temporarily install the images, but to permanently +install the images the system bootstrap procedure should be modified to +execute the INSTALL.COM script (or explicitly install the images by name) +whenever the system is booted. Note that the global pages used by an +installed image are not actually freed until any and all processes using +those global pages terminate. +.PP +The procedure for installing images will fail if there are insufficient +global pages available in the system (for example, the number of global +pages required to install the shared library in VMS/IRAF V2.10 is about +1267). If the system has insufficient free global pages to run the +INSTALL.COM script one must either increase the number of system global +pages (which requires rebooting the system), or one must edit the +INSTALL.LST file to reduce the number of images to be installed. +.NH 2 +Rendering large runtime files contiguous +.PP +The speed with which large disk files can be read into memory in VMS can +degrade significantly if the disk is highly fragmented, which causes a +large file to be physically stored in many small fragments on the disk. +IRAF performance as well as VMS system throughput can therefore be improved +by rendering frequently referenced large files contiguous. Examples of +files which it might pay to render contiguous are the executables in +\f(CWbin\fP, all of the runtime files in \f(CWdev\fP, and the large system +libraries in \f(CWlib\fP (this last is only useful to speed software +development, i.e., linking). +.PP +The easiest way to render a file contiguous in VMS is to use COPY/CONTIGUOUS +to copy the file onto itself, and then purge the old version. Various +nonstandard utility programs are available commercially which will perform +this function automatically. The contents of an entire disk may be rendered +contiguous or nearly contiguous by backing up the disk onto tape and then +restoring it onto a clean disk. +.NH 2 +Precompiling TERMCAP and GRAPHCAP entries +.PP +Precompilation of a termcap or graphcap entry is a technique used to speed +runtime access of the entry for that device. If the entry is not +precompiled the termcap or graphcap file must be physically opened and +scanned at runtime to read the desired entry. This causes a slight delay +when clearing the terminal screen or plotting a graph, hence it may be +worthwhile to cache the entries for commonly used video and graphics +terminals. We do not recommend that sites attempt to relink the IRAF system +to cache new terminal device entries, but system managers may wish to be +aware of this option. +.PP +The system comes with selected termcap and graphcap entries already +precompiled. To see which devices are precompiled, page the cache data +files, dev$cachet.dat (for termcap) and dev$cacheg.dat (for graphcap). To +cache a different set of entries one must regenerate these files with the +\fImkttydata\fP task in the SOFTOOLS package, and then do a full sysgen +relink with the \fImkpkg\fP utility. Detailed instructions are given in the +manual page for \fImkttydata\fR.\(dg +.FS +\(dg\fBImportant Note\fR: If the system is configured to use the IRAF shared +library (the default), you must update the system libraries (\(sc9.7.2) and +rebuild the shared library (\(sc9.7.3) before relinking the system +(\(sc9.7.4), else the changes to the termcap and graphcap cache files will +have no effect. The use of the shared library is peculiar to VMS/IRAF and +is not discussed in the \fImkttydata\fR documentation. +.FE + +.NH +Software Management +.NH 2 +Shared libraries +.PP +VMS/IRAF provides a shared library facility to reduce disk and memory +requirements. What the shared library facility does is take most of the +IRAF system software (currently the contents of the EX, SYS, VOPS, and OS +libraries) and link it together into a special shareable image, the file +\f(CWs_iraf.e\fR in the core BIN directory. This file is mapped into the +virtual memory of each IRAF process at process startup time. Since the +shared image is shared by all IRAF processes, each process uses less +physical memory, and the process pagein time is reduced, speeding process +execution. Likewise, since the subroutines forming the shared image are no +longer linked into each individual process executable, substantial disk +space is saved for the BIN directory. Link time is correspondingly reduced, +speeding software development. For the shared library to be effective, it +must be installed in system memory as described in \(sc8.2. +.PP +.NH 2 +Layered software support +.PP +An IRAF installation consists of the \fIcore system\fP and any number of +\fIexternal packages\fP, or "layered" software products. As the name +suggests, layered software products are layered upon the core IRAF system. +Layered software depends upon the core system for all of its functionality +and is portable to any computer which already runs IRAF. Any number of +layered products can be combined with the core system to produce the IRAF +system used at a specific site. Due to disk space limitations it is likely +that a given site will not wish to have all the available layered software +products installed and on line at any one time. +.PP +The support provided for layered software is essentially the same as that +provided for maintaining the core system itself. Each "external package" +(in most cases this actually refers to a tree of packages) is a system in +itself, similar in structure to the core IRAF system. Hence, there is a +LIB, one or more BINs, a HELP database, and all the sources and runtime +files. A good example of an external package is the NOAO package. Except +for the fact that NOAO happens to be located in the IRAF root directory, +NOAO is equivalent to any other layered product, e.g., STSDAS, PROS, +CTIOLOCAL, KPNOLOCAL, etc. Other layered products should be rooted +somewhere outside the \f(CW[IRAF]\fR directory tree to simplify updates. +.NH 2 +Software management tools +.PP +IRAF software management is performed with a standard set of tools, +consisting of the tasks in the SOFTOOLS package, plus the host system +editors and debuggers. Some of the most important and often used tools for +IRAF software development and software maintenance are the following. +.sp +.RS +.IP "\fBmkhelpdb\fP" 20 +Updates the HELP database of the core IRAF system or an external package +installed in hlib$extern.pkg. +The core system, and each external package, has its own help database. +The help database is the machine independent file helpdb.mip in the +package library (LIB directory). The help database file is generated with +\fImkhelpdb\fP by compiling the root.hd file in the same directory. +.IP "\fBmkpkg\fP" 20 +The "make-package" utility. Used to make or update package trees. +Will update the contents of the current directory tree. When run at +the root iraf directory, updates the full IRAF system; when run at the +root directory of an external package, updates the external package. +Note that updating the core IRAF system does not update any external +packages (including NOAO). When updating an external package, the +package name must be specified, e.g., "mkpkg -p noao", and the command +issued within the package directory, not from the IRAF root. +.IP "\fBrmbin\fP" 20 +Descends a directory tree or trees, finding and optionally listing or +deleting all binary files therein. This is used, for example, to strip +the binaries from a directory tree to leave only sources, to force +\fImkpkg\fP to do a full recompile of a package, or to locate all the +binary files for some reason. IRAF has its own notion of what a binary +file is. By default, files with the "known" IRAF virtual file extensions +(.a, .o, .e, .x, .f, .h, etc.) are classified as binary or text +(machine independent) files immediately, +while a heuristic involving examination of the file data +is used to classify other files. Alternatively, a list of file extensions +to be searched for may optionally be given. +.IP "\fBrtar,wtar\fP" 20 +These are the portable IRAF tarfile writer (\fIwtar\fP) and reader +(\fIrtar\fP) programs. These tasks produce archives compatible with +the UNIX \fItar\fP program. In addition they can move only the machine +independent or source files +(\fIwtar\fP, like \fIrmbin\fP, can discriminate between machine +generated and machine independent files). A tarfile written on a VMS/IRAF +system has the files blank padded, but \fIrtar\fP when used on a UNIX +system will strip the trailing blanks by default. +.IP "\fBxc\fP" 20 +The X (SPP) compiler. This task can compile ".x" or SPP source files, knows +how to link with the IRAF system libraries and the shared library, knows how +to read the environment of external packages, and so on. +.RE +.sp +.PP +The SOFTOOLS package contains other tasks of interest, e.g., a program +\fImktags\fP for making a tags file for the \fIvi\fP editor, a help +database examine tool, and other tasks. Further information on these +tasks is available in the online help pages. +.NH 2 +Modifying and updating a package +.PP +IRAF applications development (including revisions to existing programs) +is most conveniently performed from within the IRAF environment, since +testing must be done from within the environment. The usual development +cycle is as follows. This takes place within the \fIpackage directory\fP +containing all the sources and mkpkg-files for the package. +.RS +.IP \(bu +Edit one or more source files. +.IP \(bu +Use \fImkpkg\fP to compile any modified files, or files which include a +modified file, and relink the package executable. +.IP \(bu +Test the new executable. +.RE +.LP +The \fImkpkg\fP file for a package can be written to do anything, +but by convention the following commands are usually provided. +.sp +.RS +.IP "\fBmkpkg\fP" 20 +Same as \fBmkpkg relink\fP below. +.IP "\fBmkpkg libpkg.a\fP" 20 +Updates the package library, compiling any files which have been modified +or which reference include files which have been modified. Private package +libraries are intentionally given the generic name libpkg.a to +symbolize that they are private to the package. +.IP "\fBmkpkg relink\fP" 20 +Rebuilds the package executable, i.e., updates the package library and +relinks the package executable. By convention, this is the file +xx_foo.e in the package directory, where \fIfoo\fP is the package name. +.IP "\fBmkpkg install\fP" 20 +Installs the package executable, i.e., renames the xx_foo.e +file to x_foo.e in the global BIN directory for the system +to which the package \fIfoo\fP belongs. +.IP "\fBmkpkg update\fP" 20 +Does everything, i.e., a \fIrelink\fP followed by an \fIinstall\fP. +.RE +.sp +.PP +If one wishes to test the new program before installing it one should do +a \fIrelink\fP (i.e., merely type "mkpkg" since that defaults to relink), +then run the host system debugger on the resultant executable. The process +is debugged standalone, running the task by typing its name into the +standalone process interpreter. The CL task \fIdparam\fP is useful +for dumping a task's parameters to a text file to avoid having to answer +innumerable parameter queries during process execution. If the new program +is to be tested under the CL before installation, a \fItask\fP statement +can be interactively typed into the CL to cause the CL to run the "xx_" +version of the package executable, rather than the old installed version. +.PP +When updating a package other than in the core system, the \fB-p\fP flag, +or the equivalent PKGENV logical name, \fImust\fP be used +to indicate the system or layered product being updated. For example, +"mkpkg -p noao update" would be used to update one of the packages +forming the NOAO system of packages. +.PP +The CL \fBprocess cache\fP can complicate debugging and testing if one +forgets that it is there. Recall that when a task is run under the CL, +the executing process remains idle in the CL process cache following +task termination. If a new executable is installed while the old one +is still in the process cache, the \fIflprcache\fP command must be +entered to force the CL to run the new executable. If an executable is +currently running, either in the process cache or because some other +user is using the program, it may not be possible to set breakpoints +under the debugger. +.PP +The \fBshared library\fP can also complicate debugging, although for most +applications-level debugging the shared library is transparent. If it +is necessary to debug IRAF system libraries, contact the IRAF Hotline +for assistance. +.PP +A full description of these techniques is beyond the scope of this manual, +but one need not be an expert at IRAF software development techniques to +perform simple updates. Most simple revisions, e.g., bug fixes or updates, +can be made by merely editing or replacing the affected files and typing +.XS +cl> mkpkg update +.XE +.LP +plus maybe a \fIflpr\fP if the old executable is still sitting idle +in the process cache. +.NH 2 +Installing and maintaining layered software +.PP +The procedures for installing layered software products are similar to those +used to install the core IRAF system, or update a package. Layered software +may be distributed in source only form, or with binaries. The exact +procedures to be followed to install a layered product will in general be +product dependent, and should be documented in the installation guide for +the product. +.LP +In brief, the procedure to be followed should resemble the following: +.RS +.IP \(bu +Create the root directory for the new software, somewhere outside the +IRAF directories. +.IP \(bu +Restore the files to disk from a tape or network archive distribution file. +.IP \(bu +Edit the core system file hlib$extern.pkg to "install" the new package in +IRAF. Note that any `$' characters in a VMS pathname should be escaped with +a backslash as in the examples. This file is the sole link between the IRAF +core system and the external package. +.IP \(bu +Configure the package BIN directory or directories, either by restoring +the BIN to disk from an archive file, or by recompiling and relinking the +package with \fImkpkg\fP. +.RE +.LP +As always, there are some little things to watch out for. When using +\fImkpkg\fP on a layered package, you must give the name of the package +being updated, plus the names of any other external packages used to build +the target package, e.g., +.DS +\f(CWcl> mkpkg -p foo update\fP +.DE +where \fIfoo\fP is the name of the package being update, e.g., "noao", +"local", etc. The \fB-p\fP flag can be omitted by defining PKGENV +as a VMS logical name. +.PP +Once installed and configured, a layered product may be deinstalled merely +by archiving the package directory tree, deleting the files, and commenting +out the affected lines in hlib$extern.pkg. With the BINs already configured +reinstallation is a simple matter of restoring the files to disk and editing +the extern.pkg file. +.NH 2 +Configuring a custom LOCAL package +.PP +Anyone who uses IRAF enough will eventually want to add their own software +to the system, by copying and modifying the distributed versions of +programs, by obtaining and installing isolated programs written elsewhere, +or by writing new programs of their own. A single user can do this by +developing software for personal use, defining the necessary \fItask\fP +statements, etc. to run the software in the personal login.cl file. To go +one step further and install the new software in IRAF so that it can be used +by everyone at a site, one must configure a \fBcustom local package\fP. +.PP +The procedures for configuring and maintaining a custom LOCAL package are +similar to those outlined in \(sc9.5 for installing and maintaining layered +software, since a custom LOCAL will in fact be a layered software product, +possibly even something one might want to export to another site (although +custom LOCALs often contain non-portable or site specific software). +.PP +To set up a custom LOCAL, start by making a local copy of the \fBtemplate +local\fP package that comes with the distributed system and editing +hlib$extern.pkg to make the location of the new package known. If you make +a source only \fItar\fR or \fIbackup\fR archive of iraf$local and install +it as outlined in \(sc9.4, you will have a custom LOCAL. The purpose of the +template LOCAL is to provide the framework necessary for an external +package; a couple of simple tasks are provided in the template LOCAL to +serve as examples. Once you have configured a local copy of the template +LOCAL and gotten it to compile and link, it should be a simple matter to add +new tasks to the existing framework. +.NH 2 +Updating the full IRAF system +.NH 3 +The BOOTSTRAP +.PP +All current IRAF distributions come with the system already bootstrapped, +i.e., the host system interface (HSI) comes with the HSI binary executables +already built. A bootstrap should not be necessary unless one is doing +something unusual, e.g., installing a bugfix or making some other revision +to the HSI. +.PP +A bootstrap is like a full system sysgen, except that it is the host +system interface (kernel and bootstrap utilities) which is compiled and +linked, rather than IRAF itself. The system must be bootstrapped before +a sysgen is possible, since the bootstrap utilities are required to do a +sysgen. The two operations are distinct because only the bootstrap is +machine dependent; everything else works the same on all IRAF systems. +.PP +The bootstrap utilities are required for system maintenance of the main +system and hence must be linked first. However, unless a bug fix or other +revision is made to one of the main system libraries (particularly LIBOS), +there should be no reason for a user site ever to need to bootstrap the +system. The bootstrap utilities are linked with the option /NOSYSSHARE, +hence they should run on most versions of VMS. +.PP +The bootstrap utilities are written in C, and the DEC C compiler is required +to compile or link these utilities. The C compiler is \fInot\fR required to +run the prelinked binaries distributed with the system. To recompile and link +the bootstrap utilities, i.e., to "bootstrap" IRAF, enter the commands shown +below. Note that the HSI is always recompiled during a bootstrap; there +is no provision for merely relinking the entire HSI (some individual programs +can however be relinked manually by doing a "mkpkg update" in the program +source directory). +.XS +$ set default [iraf.vms] +$ set verify +$ @rmbin.com +$ @mkpkg.com +.DE +.LP +The bootstrap should take 30 to 45 minutes on an unloaded 11/780. Once the +bootstrap utilities have been relinked and installed in hlib, the main +system may be relinked. +.NH 3 +Updating the system libraries +.PP +Updating the system libraries, i.e., recompiling selected object modules and +inserting them into the system object libraries, is necessary if any system +source files are edited or otherwise modified. +.PP +The system libraries may be updated either from within the IRAF CL, or from +DCL. For example, from within DCL: +.XS +$ set def [iraf] +$ mkpkg syslibs \fR[\fPmathlibs\fR] +.XE +.LP +The brackets around mathlibs just mean "optional"; do not actually include +the brackets if you need to rebuild the math libraries. This command will +run the \fImkpkg\fR utility, which will update each system library in turn, +descending into the tree of source directories and checking the date of each +object module therein against the dates of the source files and dependency +files used to produce the object module, and recompiling any object modules +which are out of date. In the worst case, e.g., if the system libraries +have been deleted, the entire VOS (virtual operating system) will be +recompiled. If it is known that no changes have been made to the math +library source files, the optional mathlibs argument may be omitted to save +some time. +.NH 3 +Relinking the IRAF shared library +.PP +The IRAF shared library ([IRAF.BIN]S_IRAF.EXE) is constructed by linking the +contents of the four main IRAF system libraries LIBEX, LIBSYS, LIBVOPS, and +LIBOS. Hence, the system libraries must exist and be up to date before +linking the shared library. The shared library must be installed in +\f(CWbin\fR before it can be used to link any applications programs. At +present, the shared library does not use transfer vectors, hence the full +system must be relinked following any changes to the shared library. Note +that since the shared library is normally installed in system memory, all +installed IRAF images should be deinstalled and later reinstalled whenever +the shared library is rebuilt. IRAF will not be runnable while this is +taking place. +.PP +In the current release of IRAF the procedure for building the shared library +has not yet been integrated into the automatic system generation procedure. +Furthermore, utility tasks in the main IRAF system are currently used to +build the shared library, so it is necessary to have at least part of the +main system functioning before the shared library can be built. These +problems (and the transfer vector problem) will be fixed in a future release +of VMS/IRAF. +.PP +The shared library is rebuilt from within a running IRAF system that +provides at a minimum the three executables CL.EXE, X_SYSTEM.EXE, and +X_LISTS.EXE. If these executables do not yet exist or are not runnable, +rebuild them as follows. Note the use of the "-z" link flag to link the new +executables without the shared library. +.XS +$ set default [iraf.pkg.cl] +$ mkpkg update lflags=-z +$ set default [iraf.pkg.system] +$ mkpkg update lflags=-z +$ set default [iraf.pkg.lists] +$ mkpkg update lflags=-z\fR +.XE +.LP +Now startup the CL and change to the directory hlib$share, which +contains the code used to build the shared library. +.XS +$ set default [iraf.local] +$ cl + \fR(cl starts up...)\fP +cl> cd hlib$share +.XE +.LP +The following commands will rebuild the shared library and install it in +\f(CWbin\fR. This takes ten minutes or so. +.XS +cl> cl < makeshare.cl + \fR(takes a while)\fP +cl> mkpkg install +cl> purge +cl> logout +.XE +.LP +The system libraries can be updated (\(sc9.7.2) and the shared library +rebuilt while IRAF is in use by normal users, however as soon as the command +\f(CWmkpkg install\fR is executed (moving the new S_IRAF.EXE to bin) +execution of normal user programs is at risk and one should kick all IRAF +users off the machine and deinstall any installed IRAF images. The system +may now be relinked and the newly linked shared library and images +reinstalled, after which the system is ready for normal use again. Note +that makeshare creates a load map s_iraf.map for s_iraf.e that should be +deleted when no longer needed (it is quite large). +.NH 3 +Relinking the main IRAF system +.PP +The following DCL commands may be entered to relink the main IRAF system, +installing the newly linked executables in \f(CWbin\fR. Note that any +IRAF executables that have been installed in system memory must be +deinstalled and reinstalled (\(sc8.2) following the relink. +.XS +$ set default [iraf] +$ mkpkg update +.XE +.LP +The command shown causes the full system to be relinked (or recompiled and +relinked if any files have been modified) using the default compile and link +switches defined in the global \fImkpkg\fR include file hlib$mkpkg.inc. Any +system wide changes in how the system is generated should be implemented by +editing the contents of this file. For example, the default file supplied +with the system includes the following line: +.XS +$set LFLAGS = "" # default XC link flags +.XE +.LP +This switch defines the switches to be passed to the HSI bootstrap utility +program \fIxc\fR to link the IRAF executables (no switches are given, hence +the default link action will be taken). The switch "-z" may be included in +the \fIxc\fR command line to link an executable directly against the system +object libraries, rather than using the shared library. Hence, to relink +IRAF without using the IRAF shared library (as is necessary for all but one +system when there are multiple versions of IRAF simultaneously installed on +the same machine) we would change the definition of LFLAGS as follows: +.XS +$set LFLAGS = "-z" # default XC link flags +.XE +.LP +A full system relink takes approximately 30 minutes, or significantly less +if the shared library is used. A full system compile and relink takes 9-24 +hours depending upon the host system. +.PP +The above procedure only updates the core IRAF system. To update a layered +product one must repeat the sysgen process for the layered system. +For example, to update the NOAO package: +.XS +$ set default [iraf.noao] +$ mkpkg -p noao +.XE +.LP +Layered systems are completely independent of one another and hence must +be updated separately. + +.NH +Miscellaneous Notes +.PP +Magtape deallocation will not work properly in VMS/IRAF if the CL is run from +a privileged account such as one that has BYPASS or SYSPRV privilege +(a \f(CWcl> !dismount\fP may unmount the drive). +.PP +Under VMS 5, the AUTOGEN procedure includes feedback information. +It is worth running the system, with IRAF users, for a couple of weeks +and then re-running AUTOGEN (as detailed in the VMS System Management +documentation) to adjust some of the system parameters (global pages, +various memory structures) for the new work load. +.PP +"If all else fails", e.g., hung tape drives, etc., \(em our VMS system +manager recommends kicking everyone off the system, perhaps even rebooting +if it gets desperate, and then inspecting this Installation Guide again, +before calling us. And please, if you need to call, try to have available +the exact text of any error messages you may have encountered. + +.bp +.DS C +\fBAppendix A. Private TMP and IMDIR Directories\fR +.DE +.PP +If local system management policies require that private \f(CWtmp\fP and +\f(CWimdir\fP directories be defined for each user, you can define these +directories for each user as subdirectories of their SYS$LOGIN directory. +One way to do this is define imdir to be the same as tmp, and modify the +definition of IRAFTMP in the IRAFUSER.COM file as shown below. +.XS +$! ----------- add these lines to irafhlib:irafuser.com ---------- +$! This block of DCL assigns the logical name IRAFTMP to a +$! subdirectory of the user's VMS login directory. It is necessary +$! to escape the "$" and "[" because they are IRAF filename +$! metacharacters. This block of code should replace the current +$! definition in irafuser.com of IRAFTMP: +$! +$! define/job IRAFTMP TEMPDISK:[IRAFTMP] ! scratch files +$! +$! We assume only one occurrence of "$" or "[". +$! +$ tmpdir = f$logical ("SYS$LOGIN") +$ tmpdir = f$extract (0, f$locate("]",tmpdir), tmpdir) + ".IRAFTMP]" +$ define/job vmstmp 'tmpdir' +$ off = f$locate ("$", tmpdir) +$ tend = f$length (tmpdir) +$ if (off .ne. tend) then - + tmpdir = f$extract (0, off, tmpdir) + - + "\e$" + f$extract (off+1, tend, tmpdir) +$ off = f$locate ("[", tmpdir) +$ if (off .ne. tend+1) then - + tmpdir = f$extract (0, off, tmpdir) + - + "\e[" + f$extract (off+1, tend, tmpdir) +$ define/job iraftmp "''tmpdir'"\s0\fR +.sp +In irafhlib:login.cl, replace U_IMDIR with "tmp$". +.XE +.LP +In irafhlib:mkiraf.com, replace the block of statements beginning +"imdir_file :=" with the following: +.XS +$ if (f$search ("sys$login:iraftmp.dir") .eqs. "") then - + create/directory vmstmp +.XE +.LP diff --git a/doc/vmsiraf.ms.v25 b/doc/vmsiraf.ms.v25 new file mode 100644 index 00000000..1c37167a --- /dev/null +++ b/doc/vmsiraf.ms.v25 @@ -0,0 +1,1466 @@ +.RP +.TL +VMS/IRAF Installation and Maintenance Guide +.AU +Doug Tody +.br +Steve Rooke +.AI +.K2 "" "" "*" +July 1987 + +.AB +.ti 0.75i +Instructions are presented for installing, updating, and maintaining the VMS +version of the portable IRAF system (Image Reduction and Analysis Facility). +Step by step procedures are presented both for the initial IRAF installation +and for updating an existing installation to the latest release of the system. +Procedures for improving performance, minimizing disk and memory usage, and +interfacing site dependent devices such as video or graphics terminals, +plotters, image displays, and magnetic tape drives are discussed. +.AE + +.pn 1 +.bp +.sp 2.5i +.ce +.ps 11 +.ps +2 +\fBHistorical Notes\fR +.ps -2 +.sp 3 +The initial port of IRAF to VMS was carried out during 1984 and early 1985 +at STScI (the Space Telescope Science Institute) by Jay Travisano +and Fred Romelfanger, working under the supervision of Peter Shames, with +some assistance early on from Jim Rose. The major system components +implemented during this period were the SPP compiler (XC) and the OS +interface routines for VMS, as specified in \fIA Reference Manual for the +IRAF System Interface\fR, Doug Tody, May 1984. +.sp +Completion of VMS/IRAF took place at NOAO in the fall of 1985. This period +saw the definition of a major new interface, the HSI (host system interface), +and the implementation of the \fLmkpkg\fR system maintenance utility and +many of the other HSI bootstrap utilities. This eliminated the final +differences between the different versions of IRAF, allowing software to be +routinely ported between UNIX/IRAF, VMS/IRAF, and so on, without any changes +to the program sources or configuration control files, and allowing full +automation of the system configuration control procedures. +.sp +The initial implementation of shared libraries for VMS/IRAF was carried out +in the fall of 1986 by Dennis Crabtree of DAO (the Dominion Astrophysical +Observatory, UBC, Canada), while on leave at STScI. + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInitial System Installation\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Create the IRAF Account\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'Read the BACKUP Tape\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.3.\h'|0.9i'Edit the System Configuration Files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.3.1.\h'|1.5i'[IRAF.VMS.HLIB]IRAFUSER.COM\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.3.2.\h'|1.5i'[IRAF.VMS.HLIB.LIBC]IRAF.H\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.3.\h'|1.5i'[IRAF.VMS.HLIB]INSTALL.COM\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.4.\h'|0.9i'Relink If Necessary\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.5.\h'|0.9i'Complete the Initial System Configuration\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.6.\h'|0.9i'Edit the System Dependent Device Files\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.6.1.\h'|1.5i'[IRAF.VMS.HLIB]ZZSETENV.DEF\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.6.2.\h'|1.5i'[IRAF.DEV]DEVICES\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.6.3.\h'|1.5i'[IRAF.DEV]TERMCAP\l'|5.6i.'\0\08 +.br +\h'|0.9i'2.6.4.\h'|1.5i'[IRAF.DEV]GRAPHCAP\l'|5.6i.'\0\08 +.br +\h'|0.9i'2.6.5.\h'|1.5i'IRAF Networking\l'|5.6i.'\0\08 +.sp +3.\h'|0.4i'\fBUpdating an Existing IRAF Installation\fP\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.1.\h'|0.9i'Save Locally Modified Files\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.2.\h'|0.9i'Read the Distribution Tape or Tapes\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.3.\h'|0.9i'Merge Saved Files Back Into the New System\l'|5.6i.'\0\010 +.br +\h'|0.4i'3.4.\h'|0.9i'Relink If Necessary\l'|5.6i.'\0\011 +.br +\h'|0.4i'3.5.\h'|0.9i'Update VMS\l'|5.6i.'\0\011 +.sp +4.\h'|0.4i'\fBTesting a Newly Installed or Updated System\fP\l'|5.6i.'\0\011 +.sp +5.\h'|0.4i'\fBSystem Maintenance\fP\l'|5.6i.'\0\012 +.br +\h'|0.4i'5.1.\h'|0.9i'Recompiling or Relinking the System\l'|5.6i.'\0\012 +.br +\h'|0.9i'5.1.1.\h'|1.5i'Bootstrapping the HSI\l'|5.6i.'\0\013 +.br +\h'|0.9i'5.1.2.\h'|1.5i'Updating the System Libraries\l'|5.6i.'\0\013 +.br +\h'|0.9i'5.1.3.\h'|1.5i'Relinking the IRAF Shared Library\l'|5.6i.'\0\014 +.br +\h'|0.9i'5.1.4.\h'|1.5i'Relinking the Main IRAF System\l'|5.6i.'\0\015 +.br +\h'|0.9i'5.1.5.\h'|1.5i'Relinking or Updating IRAF Packages\l'|5.6i.'\0\015 +.br +\h'|0.4i'5.2.\h'|0.9i'Tuning Considerations\l'|5.6i.'\0\016 +.br +\h'|0.9i'5.2.1.\h'|1.5i'Installing Executable Images\l'|5.6i.'\0\016 +.br +\h'|0.9i'5.2.2.\h'|1.5i'Rendering Large Runtime Files Contiguous\l'|5.6i.'\0\017 +.br +\h'|0.9i'5.2.3.\h'|1.5i'Precompiling TERMCAP and GRAPHCAP Entries\l'|5.6i.'\0\017 +.br +\h'|0.9i'5.2.4.\h'|1.5i'Stripping the System to Reduce Disk Consumption\l'|5.6i.'\0\018 +.br +\h'|0.4i'5.3.\h'|0.9i'VMS Quotas and Privileges Required to Run IRAF\l'|5.6i.'\0\018 +.sp +6.\h'|0.4i'\fBInterfacing New Graphics Devices\fP\l'|5.6i.'\0\019 +.br +\h'|0.4i'6.1.\h'|0.9i'Graphics Terminals\l'|5.6i.'\0\019 +.br +\h'|0.4i'6.2.\h'|0.9i'Graphics Plotters\l'|5.6i.'\0\020 +.br +\h'|0.4i'6.3.\h'|0.9i'Image Displays\l'|5.6i.'\0\020 +.sp +7.\h'|0.4i'\fBThe IRAF Directory Structure\fP\l'|5.6i.'\0\021 + +.nr PN 0 +.bp +.NH +Introduction +.PP +Installing VMS/IRAF is easy and fast, provided one takes the trouble to read +and follow the instructions in this installation guide. Instructions are given +both for the initial system installation (\(sc2, immediately following) +and for updating an existing installation (\(sc3). Variations on the +recommended system configuration are certainly possible and may be necessary +at some sites due to restrictions or quotas, but not following the standard +installation procedure or departing from the recommended system configuration +may cause the system to function incorrectly, inefficiently, or not at all. +.PP +The distribution tape is a snapshot of our local (NOAO/Tucson) VMS/IRAF system. +The device and system configuration tables come configured for our system, +and will have to be modified as part of the installation process. +These modifications are discussed in detail in this document. +To simplify the installation process as well as future upgrades, we have tried +to isolate the site dependent files to the minimum number of directories, i.e., +\fLdev\fR, \fLhlib\fR, and \fLlocal\fR and its subdirectories (the equivalent +VMS pathnames are \fL[IRAF.DEV]\fR, \fL[IRAF.VMS.HLIB]\fR, +and \fL[IRAF.LOCAL]\fR). +The remainder of the system should not require any modifications. +.PP +An installation typically takes about an hour, perhaps longer if relinking is +necessary. Interfacing new graphics terminals, plotters, or image displays +can take considerably longer, of course, and we will only touch upon such +matters in the installation guide. Feel free to contact the IRAF hotline for +assistance if any problems should arise during the installation, or for help +in interfacing new devices. +.sp +.TS +center; +cb s s +l l l. +IRAF HOTLINE +.sp +telephone \fL(602) 323-4160\fP +bitnet \fLiraf%draco@\fP\fR...\fP (via the Wisconsin gateway) +internet \fLiraf@noao.arpa\fP +span \fLdraco::iraf\fP (draco = 5356) +uucp \fLseismo!noao!iraf\fP +.TE + +.NH +Initial System Installation +.PP +It is only necessary to follow the full installation procedure if IRAF has +not yet been installed on your system. If an old version of IRAF has already +been installed, proceed to \(sc3. +.PP +Briefly, the steps to be followed to install IRAF for the first time are the +following. This summary is provided only to introduce the basic installation +procedure: it is important to read the detailed installation instructions +for additional details, to avoid certain errors or omissions which are +otherwise highly likely (IRAF does not always follow VMS conventions). +.RS +.IP \(bu +Login as SYSTEM and create an account for user IRAF, root directory +\fL[IRAF]\fR, login directory \fL[IRAF.LOCAL]\fR, to be used by the IRAF +system manager to maintain IRAF. +.IP \(bu +Login as IRAF and run the \fLBACKUP\fR utility to restore the IRAF distribution +tape or tapes to disk. Make sure the files belong to user IRAF. +.IP \(bu +Edit the basic IRAF system configuration files \fLIRAFUSER.COM\fR and +\fLIRAF.H\fR (in \fLhlib\fR and \fLhlib/libc\fR), e.g., to change the system +dependent disk and batch queue names, and define the VMS pathnames to +the major IRAF directories. +.IP \(bu +Login again as SYSTEM and [1] copy the \fLIRAF.H\fR file edited above +to the VMS system library directory \fLSYS$LIBRARY\fR, +[2] to the \fLSYLOGIN.COM\fR file, add a global symbol \fLiraf\fR which when +executed by the user will execute the \fLIRAFUSER.COM\fR file to define the +rest of the IRAF logicals, and +[3] edit and execute the \fLINSTALL.COM\fR script (in \fLhlib\fR) to "install" +in system shared memory at least the IRAF shared library, and probably some of +the most frequently used executables as well. +.RE +.PP +Although the system installation is not yet complete, +any user should now be able to run IRAF, i.e., +run the \fLiraf\fR command procedure to define the IRAF logicals, +run the \fLmkiraf\fR command procedure to initialize the IRAF environment, +and type the command \fLcl\fR to start up the IRAF Command Language (CL). +Following the basic installation procedure shown here, +it will still be necessary to modify the IRAF device tables to tell the system +about the local magtape devices, line printers, terminals, plotters, and so on. +This should be done from within the running IRAF system to facilitate +testing of the new device interfaces, and is an ongoing activity as new +devices are interfaced to the system. + +.NH 2 +Create the IRAF Account +.PP +Login as SYSTEM and run the \fLAUTHORIZE\fR utility to create an account for +user `\fLIRAF\fR'. Select a disk device with sufficient free space for the +system (see \(sc2.2 below). If necessary, the system can be stripped after +installation to save space (\(sc5.2.4), but the full amount of space will be +needed during installation. There is no need to worry about VMS quotas and +privileges yet; this is not a concern during installation and is discussed +in a later section (\(sc5.3). +.DS +\fL$ run sys$system:authorize +UAF>\fR (etc) +.DE +The root directory for the IRAF account should be set to \fL[IRAF]\fR, +as this name is explicitly assumed in various places in the configuration files. +We recommend that the login directory for the IRAF account be set to +\fL[IRAF.LOCAL]\fR rather than \fL[IRAF]\fR as one would expect, to provide +a place to keep all the miscellaneous files required locally to maintain the +system without cluttering up the standard IRAF system directories. +This will simplify the installation of future updates since +it makes it obvious what is part of the standard system and what has been +added locally, and having all the local stuff in a separate subdirectory will +make it easier to ensure that it is not lost when the next version of the +system is installed. + +.NH 2 +Read the BACKUP Tape +.PP +Login as IRAF (ignore the \fLLOGIN.COM\fR not found error message) +and run the VMS \fLBACKUP\fR utility to read the BACKUP tape or tapes provided. +The tape contains approximately 7400 files in 260 directories, for a total +of 39 Mb or 76,700 512-byte blocks (including binaries). +The system as distributed uses a shared library to reduce disk and +memory requirements. +If IRAF is relinked and run without the shared library (e.g., if two or +more versions of IRAF are installed on the same machine), the system will +take up about 49 Mb or 98,300 blocks. +.DS +\fL$ mount/foreign \fItape\fL: +$ set default \fIdisk\fL:[iraf] +$ backup/rew \fItape\fL:iraf.bck/select=[iraf...] [...]\fR +.DE +In this and all the following examples, names like \fIdisk:\fR, \fItape:\fR, +etc. denote site dependent device names for which you must supply values. +The tape may be restored while logged in as SYSTEM if desired, but the switch +\fL/OWNER=[IRAF]\fR should be appended to give the IRAF system manager +(anyone who logs in as IRAF) write permission on the files. +.PP +It typically takes twenty minutes to half an hour to read the tape on a +lightly loaded system. + +.NH 2 +Edit the System Configuration Files +.PP +The files listed below must be edited before the system can be run. +The principal change required is to change the pathnames of the major IRAF +logical directories for the local machine. If any of these files are edited +while logged in as SYSTEM, be sure to do a \fLSET FILE/OWNER=[IRAF]\fR to +restore ownership of the edited file to IRAF. +.NH 3 +[IRAF.VMS.HLIB]IRAFUSER.COM +.PP +This file defines the VMS logical names and symbols needed to run IRAF. +The site dependent ones are grouped at the beginning of the file. + +.IP \fLIRAFDISK\fR +.br +Set to the name of the disk the \fL[IRAF]\fR directory is on. + +.IP \fLIMDIRDISK\fR +.br +Set to the name of a public scratch device, if available. +The \fLmkiraf\fR script will try to create the default user image storage +directories on this disk, e.g., \fLIMDIRDISK:[\fIuser\fP]\fR. +All potential IRAF users should have write permission and quota on this +device. +.sp +A public scratch device is desirable because this is where bulk image data +will be stored by default. It is often best for this to be on a different +disk than that used for user logins, to minimize the amount of disk that has +to be backed up on tape, and to permit a different quota and file expiration +date policy to be used for large datafiles than is used for the small, +relatively long lived files normally kept on the user disk. + +.IP \fLTEMPDISK\fR +.br +Set to the name of a public scratch device and create a public directory +\fL[IRAFTMP]\fR on this device. +The device may be the same as is used for \fLIMDIRDISK\fR if desired. +The IRAF logical directory "\fLtmp\fR" +(known as \fLIRAFTMP\fR in the \fLIRAFUSER.COM\fR file) +is defined as \fLTEMPDISK:[IRAFTMP]\fR.\(dg +.FS +\(dgIf local system management policies require that private \fLtmp\fR and +\fLimdir\fR directories be defined for each user, you can define these +directories for each user as subdirectories of their \fLSYS$LOGIN\fR +directory. One way to do this is define \fLimdir\fR to be the same as +\fLtmp\fR, and modify the definition of \fLIRAFTMP\fR in the +\fLIRAFUSER.COM\fR file as shown below. +.sp +.nf +\fL $ dir := 'f$logical ("SYS$LOGIN")' \fR(add to irafuser.com)\fL + $ off := 'f$locate ("]", dir)' + $ dir := 'f$extract (0, off, dir)'".IRAFTMP]" + $ define/job iraftmp 'dir'\fR +.fi +.sp +As a final step, edit the file \fLLOGIN.CL\fR in the \fLhlib\fR directory +(this is the master template \fLLOGIN.CL\fR file), replacing the \fLU_IMDIR\fR +therein by \fLtmp$\fR, and in the file \fLMKIRAF.COM\fR, also in \fLhlib\fR, +replace the block of statements beginning \fLimdir_file :=\fR with the +following: +.sp +.nf +\fL $ if (f$search ("sys$login:iraftmp.dir") .nes. "") then goto endif_mktmp + $ create/directory iraftmp + $ endif_mktmp: \fR(add to mkiraf.com) +.fi +.sp +Thereafter, execution of the \fLmkiraf\fR command procedure by a user will +cause a private \fLtmp\fR directory (\fLIRAFTMP = [\fIuser\fP.IRAFTMP]\fR) +to be created in their VMS login directory if it does not already exist. +The \fLLOGIN.CL\fR file will be configured to place both temporary files +and pixel storage files in this directory by default. +.FE +.sp +The IRAF system will create temporary files in this directory at runtime. +These files are always deleted immediately after use (unless a task aborts), +hence any files in "\fLtmp\fR" older than a day or so are garbage and should +be deleted. It is best if "\fLtmp\fR" points to a public directory which +is cleaned periodically by the system, e.g., whenever the system is booted, +so that junk temporary files do not accumulate. This is a good reason for +using a single public directory for this purpose rather than per-user private +directories. The files created in \fLtmp\fR are rarely very large. + +.IP \fLFAST,BATCH,SLOW\fR +.br +These are the logical names of the standard IRAF logical batch queues. +They should be redefined to reference the queues used on your machine, +e.g., the standard VMS batch queue \fLSYS$BATCH\fR (all three names +may point to the same batch queue if desired). The fast queue is intended +for small jobs to be executed at interactive priorities, the batch queue +is for medium sized jobs, and the slow queue is for large jobs that need +a lot of system resources and are expected to run a long time. + +.NH 3 +[IRAF.VMS.HLIB.LIBC]IRAF.H +.PP +This file (often referred to as \fL\fR) +is required to compile any of the C source files used in IRAF. +Most sites will not need to recompile the C +sources and indeed may not even have the DEC C compiler, but the file is +also used by the runtime system in some cases to resolve logical names, +hence must be edited and installed in the VMS system library. +Change the following directory names as required for your system, +referencing only system wide logical names in the new directory pathnames. +.DS +.TS +center; +ci ci +n l. +IRAF Logical Directory VMS directory + +\fL\&HOST\fR \fLIRAFDISK:[IRAF.VMS]\fR +\fL\&IRAF\fR \fLIRAFDISK:[IRAF]\fR +\fL\&TMP\fR \fLTEMPDISK:[IRAFTMP]\fR (may vary\(dg) +.TE +.DE +.FS +\(dgIf local system restrictions forbid a public \fLIRAFTMP\fR directory, +set this entry to the pathname of a suitable directory in IRAF, e.g., +\fL[IRAF.LOCAL.UPARM]\fR. This should work in most circumstances, +since it is most likely to be the +IRAF system manager who runs a program that accesses these pathnames. +.FE +.PP +These directory definitions are referenced only if logical name translation +fails for some reason, as sometimes happens on VMS systems for various reasons. +It is therefore essential that only system wide logical names be used in +these directory pathnames. Do not use job or process logicals. Do not +change the order in which the entries appear, or otherwise alter the syntax; +the kernel code which scans \fL\fR is very strict about the syntax. + +.NH 3 +[IRAF.VMS.HLIB]INSTALL.COM +.PP +This command procedure is run by the system manager, or by the system at +boot time, to install the IRAF shared library and selected executable images. +Installing images in system memory is necessary to permit memory sharing in +VMS, and can greatly reduce physical memory usage and paging on a busy system. +Installing images also consumes system global pages, however, of which there +is a limited supply. Hence, one should only install those images which will +be used enough to make it worthwhile. +.PP +Edit the \fLINSTALL.COM\fR file to select those executable images to be +installed (by commenting out those \fInot\fR to be installed). +The shared library \fLs_iraf.exe\fR should always be installed if IRAF is +going to be used at all, or the system will execute very inefficiently (the +IRAF shared library is used by all executing IRAF processes). +Normally the images \fLcl.exe\fR and \fLx_system.exe\fR +should also be installed, since these are used by anyone using IRAF, as well +as by all batch IRAF jobs. If IRAF is heavily used and sufficient global +pages are available it is also desirable to install \fLx_images.exe\fR and +\fLx_plot.exe\fR, since virtually everyone uses these executable images +frequently when using IRAF. It is probably not worthwhile to install any +other images, unless usage at the local site involves heavy use of specific +additional executable images. + +.NH 2 +Relink If Necessary +.PP +If you received a full binary distribution of VMS/IRAF and you are not running +an old version of VMS, you do not need to relink the system and may proceed +to \(sc2.5. A "you relink" distribution is shipped without binaries so of +course requires linking. Linking may also be necessary when running a version +of VMS older than that installed on our NOAO system when the executables in +a binary release were linked, since the VMS operating system may refuse to +run executables linked on a possibly incompatible "future" revision of VMS. +.PP +In any case, relinking the system is easy and fast. The basic procedure is +outlined below; additional information is given in \(sc5.1. The following +commands should be executed while logged in as IRAF. +.DS +\fL$ set default [iraf] +$ mkpkg update\fR +.DE +.PP +By default, the system is linked against the IRAF shared library +\fLS_IRAF.EXE\fR which should already be present in the \fL[IRAF.BIN]\fR +directory after restoring the distribution tape. This speeds up linking and +considerably reduces the size of the resultant executables. It should not +be necessary to relink the HSI executables (in \fLhlib\fR), as these are +linked with \fL/NOSYSSHARE\fR on our system and are included in all VMS/IRAF +distributions. + +.NH 2 +Complete the Initial System Configuration +.PP +Login again as SYSTEM and copy the \fLIRAF.H\fR file to the system library, +ensuring that the file has world read permission:\(dg +.FS +\(dgOn a VMS cluster, make sure the \fLIRAF.H\fR file is added to +\fLSYS$COMMON:[SYSLIB]\fR rather than \fLSYS$SYSROOT:[SYSLIB]\fR, +so that all nodes in the cluster may transparently access the file. +The same precaution is needed when editing the \fLSYLOGIN.COM\fR file, +which will probably want to go into \fLSYS$COMMON:[SYSTEM]\fR. +The \fLSYSTARTUP.COM\fR file, on the other hand, +should go into \fLSYS$SYSROOT:[SYSTEM]\fR if the bootstrap procedure is +different for each node. +.FE +.DS +\fL$ set default sys$library +$ copy \fIdisk\fL:[iraf.vms.hlib.libc]iraf.h [] +$ set protection = (w:r) iraf.h\fR +.DE +.PP +Add the following statement to the system \fLSYLOGIN.COM\fR file, making the +appropriate substitution for \fIdisk\fR. +.DS +\fL$ iraf :== "@\fIdisk\fL:[iraf.vms.hlib]irafuser.com"\fR +.DE +.PP +Add the following statement to the \fLSYSTARTUP.COM\fR file, read by the +system at startup time. This is necessary to cause the IRAF images to be +reinstalled in system memory when the system is rebooted. +.DS +\fL$ @\fIdisk\fP:[iraf.vms.hlib]install.com\fR +.DE +.PP +Lastly, while still logged in as SYSTEM, type in the above command +interactively to perform the initial image installation. It may be necessary +to increase the number of system global pages for the command to execute +successfully. If any of the images have been installed before (e.g., if +the first attempt fails part way through), remember to deinstall the old +images before attempting to install the new ones. + +.PP +At this point it should be possible for any user to run IRAF. To verify this, +log out and log back in as IRAF. The default \fLLOGIN.COM\fR in the IRAF +login directory \fL[IRAF.LOCAL]\fR will automatically execute the \fL'iraf'\fR +command to read the \fLIRAFUSER.COM\fR file and define the IRAF logicals. +Type \fLmkiraf\fR to initialize the IRAF \fLuparm\fR directory and create +a new \fLLOGIN.CL\fR (a \fLpurge\fR is necessary to delete the old one). +Typing \fLcl\fR next should cause the CL to run. If the CL runs successfully, +the screen should be cleared (if the terminal is set correctly) and the +message of the day printed. You can then type \fLlogout\fR to stop the CL +and return to DCL, or stay in the CL to edit and test the device files +described in the next section. When logging back into the CL (as `IRAF'), +always return to the \fL[IRAF.LOCAL]\fR directory before logging in. +A little command \fLh\fR (for `home') is defined in the default IRAF +\fLLOGIN.COM\fR file for this purpose. + +.NH 2 +Edit the System Dependent Device Files +.PP +The files listed below must be edited before IRAF can be used with the +video terminals, graphics terminals, plotters, printers, magtape devices, +and so on in use at the local site. +.NH 3 +[IRAF.VMS.HLIB]ZZSETENV.DEF +.PP +This file contains the name of the default editor, the default names of all +the standard devices, and a number of other definitions which are not site +dependent and which can therefore be ignored. To be accessible by the IRAF +system, each local device named must also have an entry in the \fLTERMCAP\fR +file (terminals and printers) or \fLGRAPHCAP\fR file (graphics terminals, +image displays, and plotters) in \fL[IRAF.DEV]\fR. +There must also be an "\fLeditor.ED\fR" +file in \fL[IRAF.DEV]\fR for the named editor; EDT, EMACS, and VI are currently +supported (VI support is approximate). Edit the quoted value in the +following entries to change the defaults. Sample values are shown. +.DS +\fLset editor = "vi" +set printer = "imagen" +set terminal = "vt640" +set stdgraph = "vt640" +set stdimage = "iism70l" +set stdplot = "versatec"\fR +.DE +For example, you may wish to change the default editor to "\fLedt\fR", +the default printer to "\fLvmsprint\fR", +the default image display to "\fLiism75\fR", +and the default terminal to "\fLvt100\fR". +Note that only a limited number of image displays are currently supported. +Most video terminals, graphics terminals, and plotters are already supported +by the current system. +.NH 3 +[IRAF.DEV]DEVICES +.PP +This file contains a list of the allocatable devices (primarily tape drives) +for the local system. It should be obvious how to change it by reading the +comments in the file and studying the current values, which are for our system. +By convention drives are assigned the logical names \fLmta\fR, \fLmtb\fR, +and so on. Note that in a VMS cluster where all nodes access the same version +of IRAF, the tape drives for all systems must be defined in this one file, +even though an individual drive may not be accessible on all nodes. +.NH 3 +[IRAF.DEV]TERMCAP +.PP +There must be entries in this file for all video terminal, graphics terminal, +and printer devices you wish to access from IRAF. +The printer is easy, since the +"\fLvmsprint\fR" entry provided should work on any VMS system. +To prepare entries for other devices, simply copy the "\fLvmsprint\fR" +entry and change the queue name from \fLSYS$PRINT\fR to the name of the queue +for the new printer.\(dg +.FS +\(dgIf the printer device is on a remote node which is not clustered with +the local node but which is accessible via DECNET, IRAF networking must be +used to access the remote device. IRAF networking is also frequently used +to access devices on non-VMS (e.g., UNIX) nodes. Contact us for assistance +to help configure your system for IRAF networking. +.FE +Any number of these entries may be placed in the termcap file, +and there can be multiple entries or aliases for each device. +If you have a new terminal which has no entry in the termcap file +provided, a new entry will have to be added (termcap is widely used, +so it is highly likely that someone somewhere will already have written it). +A copy of the UNIX manual page documenting the termcap database is appended +in case you need to construct a new termcap entry for some device. +.NH 3 +[IRAF.DEV]GRAPHCAP +.PP +There must be entries in this file for all graphics terminals, batch plotters, +and image displays accessed by IRAF programs. Many graphics terminals are +already supported; page the file to determine if entries are already available +for the graphics terminals in use at your site, before attempting to write a +new one. The IRAF file \fLsys$gio/doc/gio.hlp\fR contains a description of +the graphcap database and instructions for adding an entry for a new device. +A printed copy of this document is available upon request, however once +IRAF is up you may find it easier to generate your own copy using \fLhelp\fR, +as follows: +.DS +\fLcl> cd sys$gio/doc +cl> help gio.hlp fi+ | lprint\fR +.DE +The manual page for the \fLshowcap\fR task should also be printed since this +utility is useful for generating new graphcap entries. +More focused documentation will be available eventually. +Telephone consultation via the IRAF Hotline is available for those +who need it. We ask that new graphcap entries be sent back to us so +that we may include them in the master graphcap file for other sites +to use. + +.NH 3 +IRAF Networking +.PP +The \fLdev\fR directory also contains the files (\fLHOSTS\fR, \fLHOSTLOGIN\fR, +and \fLUHOSTS\fR), which are used by the IRAF networking software. +Sites which have a local TCP/IP based network can enable IRAF networking +by editing these files, substituting the hostnames and network +addresses of the machines in the local network for the entries currently +in the files, and by installing IRAF on the other nodes (or enough of IRAF +to run the IRAF kernel server). It does not matter what native operating +system runs on the remote nodes, so long as it runs IRAF as well. +.PP +We also provide limited support for DECNET based networking, but the current +system as distributed must be relinked before DECNET networking can be used. +As this capability is still under development, please contact the Hotline for +assistance and advice if you wish to use the IRAF DECNET interface. + +.NH +Updating an Existing IRAF Installation +.PP +Skip to \(sc4 if you have just completed the initial IRAF installation. +This section is for sites upgrading to a new version of IRAF. +.PP +Updating is very similar to the initial installation (\(sc2). +The main difference is that material which has been added to the site +dependent files since the initial installation should be saved and then +merged back into the generic system from the distribution tape. +The typical update process consists of the following steps: +.RS +.IP \(bu +Save any site-specific files. +.IP \(bu +Delete the old system. +.IP \(bu +Restore the new system to disk from the distribution tape. +.IP \(bu +Merge contents of saved site-specific files into new system. +.IP \(bu +Relink the system if necessary. +.IP \(bu +Update any "installed" images, the \fL\fR file, etc. +.RE +.PP +Variations on this basic procedure are possible and may be preferred at +some sites. For example, sites which make heavy use of IRAF and which have +sufficient disk space may wish to install the new version of the system as +a separate version on disk, e.g., calling the new version of the system +the new `IRAF' and keeping the old version around as `IRAFO'. At NOAO we +maintain three separate versions of the system, IRAF (the current default user +system), IRAFO (the old system, for backup), and IRAFX (the developmental +system). Sites which wish to maintain multiple versions of the system +should beware that only one version of the system can use the shared library, +due to global section name conflicts. For efficiency reasons the default +user version of the system `IRAF' should use the shared library. +The remaining versions of the system must be relinked (\(sc5.1.4) to keep +them from erroneously trying to use the shared library from a different +release of IRAF. + +.NH 2 +Save Locally Modified Files +.PP +Login as IRAF. +Ordinarily the only directories containing files you may wish to save are +\fLdev\fR, \fLhlib\fR, and \fLlocal\fR. +The safest and easiest way to do this is to save the entire contents of those +directories. For example: +.DS +\fL$ set default [iraf] +$ rename dev.dir,local.dir,[.vms]hlib.dir [\fIdirectory\fP]\fR +.DE +This would physically move (not copy) the \fLdev\fR, \fLlocal\fR, and +\fLhlib\fR directories to the named directory, which must be on the same +disk device as \fL[IRAF]\fR. Many variations on this are possible. +The destination directory should be somewhere outside the \fL[IRAF...]\fR +directory tree, else it may get deleted when we delete the old system, below. + +.NH 2 +Read the Distribution Tape or Tapes +.PP +Having temporarily preserved all the locally modified files, it is now +time to delete the old system and read in the new one. If you are +the cautious (prudent?) type you may wish to first preserve the entire +existing IRAF system on a backup tape (e.g. if something were to have +happened to the distribution tape en route). Using only the standard +VMS utilities, the old system may be deleted as follows (assuming IRAF +owns all the files in \fL[IRAF...]\fR). +.DS +\fL$ set default [iraf] +$ set protection=(owner:wd) [...]*.*;* +$ delete [...]*.*;* + \fR(repeat with until done) +.DE +.LP +It is normal for the \fLdelete\fR command shown to generate lots of messages +during execution warning that it cannot delete directories because they are +not yet empty. When the command finally executes without any warning messages +this means the directory tree has been fully deleted. +.LP +Now read the new distribution tape(s). +.DS +\fL$ mount/foreign \fItape\fL: +$ set default \fIdisk\fL:[iraf] +$ backup/rew \fItape\fL:iraf.bck/select=[iraf...] [...]\fR +.DE +.LP +Instead of explicitly deleting the old system it is possible to read the +distribution tape with \fLBACKUP/REPLACE\fR, but this really isn't any +faster since an implicit delete of each existing file is implied, and +if any files or directories have been renamed in the new release, junk +files or directories will be left behind. + +.NH 2 +Merge Saved Files Back Into the New System +.PP +You can either merge the contents of locally modified files saved from +the previous installation into their counterparts in the new system, or edit +the new ones from scratch. Whichever is easier depends on how much editing +you had to do in the first place, which probably depends upon the complexity +of your local computer network and the number of peripheral devices. +Any of the site configuration files might be modified in the distributed +system from version to version of IRAF, so in general one cannot simply +replace such a file with the one that was saved. +.PP +Merging means inspecting the two files (newly distributed vs. its +saved counterpart) for differences, and deciding how to update the new +file with local device names, directory pathnames, etc. +The VMS \fLDIFFERENCES\fR utility may or may not be useful for this, +depending on how much a file has changed, and how extensively it +was modified locally. One thing that is a big help is to keep track of +all local changes made to the standard system in a local "notes" file; +when the next system update occurs or when the installation is repeated on +another cpu at the local site, one can then go down the list and make all +the same changes to the newly installed system. +.KS +.TS +center; +ci ci +l l. +directory files +.sp +\fLdev\fR devices, graphcap, termcap +\fLhlib\fR irafuser.com, install.com, zzsetenv.def, login.cl +\fLhlib/libc\fR iraf.h (\(-> sys$library:iraf.h) +.TE +.KE +.PP +The files which must be edited, via a diff/merge operation on the saved +files or otherwise, are summarized in the table above. +If you have added packages or tasks of your own to IRAF this would be +a good time to merge them back into the new system and relink them, +although this may be deferred until the new system is up and running if +desired. + +.NH 2 +Relink If Necessary +.PP +If you received a fully binary distribution of VMS/IRAF and you are not +running an old version of VMS, you do not need to relink and may proceed +to the next section. See \(sc2.4 for further information on relinking the +system. + +.NH 2 +Update VMS +.PP +These next operations require system privileges, so login as SYSTEM. +Perform the following series of operations: +.RS +.IP \(bu +The \fL\fR file may have changed in the new version of the system, +so it should be updated in the VMS system library \fLsys$library\fR. +.IP \(bu +Run the VMS \fLINSTALL\fR utility and deinstall the previously installed IRAF +shared library and executables from the old system, if any. +(In \fLINSTALL\fR, use \fL/list\fR\(dg +.FS +\(dgThe actual \fLINSTALL\fR syntax used is site dependent. +.FE +to see what is currently installed, and \fI\fL/del\fR to +delete individual images; note that actual image deletion will not occur +until any currently executing processes which reference the shared image +terminate). +.IP \(bu +Execute the \fLinstall.com\fR command procedure in \fLhlib\fR to install the +shared library and selected executables from the new system. +.RE +.PP +In a VMS cluster, the shared images must be deinstalled and +reinstalled on all nodes in the cluster which share the same version of IRAF. +Aside from the additional step of deinstalling any previously installed +shared images, these steps are as discussed in \(sc2.5; please refer to that +section for additional information. + +.NH +Testing a Newly Installed or Updated System +.PP +Before testing a newly installed or upgraded system it is wise to read the +\fICL User's Guide\fR, the revisions notes, and the list of known bugs, +if one has not already done so. Before starting the CL you should +do what a regular user would do, i.e., run \fLmkiraf\fR to initialize +the IRAF environment, and then edit the \fLLOGIN.CL\fR file created by +\fLmkiraf\fR as desired. Any modifications you wish to preserve across +another \fLmkiraf\fR may be placed into the optional \fLLOGINUSER.CL\fR file +to avoid having to edit the \fLLOGIN.CL\fR file. +.DS +\fL$ set default [iraf.local] +$ mkiraf\fR +.DE +.LP +Once the IRAF environment is configured one need only enter the command +`\fLcl\fR' to start up the CL. After a bit IRAF should print the message of +the day and type out the root IRAF menu, then issue the "\fLcl> \fR" prompt +indicating that it is ready for the first command. +This assumes that the `\fLiraf\fR' command is executed in the \fLLOGIN.COM\fR +file at login time; if this is not the case, `\fLiraf\fR' must first be entered +to define \fLcl\fR and the other VMS logical names and symbols used by IRAF. +.DS +\fL$ cl\fR +.DE +.LP +Once in the CL, you will probably have magtape and printer access, are likely +to have graphics terminal access, and very possibly will not have either +image display access or graphics plotter access. If the graphics terminal +capability is ready the next step is to run the IRAF test procedure to +verify that all is working well, as well as try out a few of the many tasks +in the system. If the graphics terminal is not up yet, there is probably +no point in running the test procedure. To run the test procedure, read +the documentation in the \fIIRAF User Handbook\fR, Volumn 1A, and follow the +instructions therein. You may also wish to run some of the benchmarks +described in the benchmarks paper included with the installation materials, +to make sure that your VMS system (user quotas and working set) is configured +properly for efficient execution of IRAF. + +.NH +System Maintenance +.NH 2 +Recompiling or Relinking the System +.PP +The prelinked executables supplied on the distribution tape should +execute on most systems without need to relink. Relinking is necessary +[1] when installing a "you relink" version of the system, [2] if the local +system runs a significantly older version of VMS than that used when the +distribution tape was made (VMS is conservative and may refuse to execute +images which were linked on a "future" version of the system, i.e., any +release of VMS with a higher version number than the locally installed +system, because the VMS shared libraries may have changed in the newer +revision of the system), or [3] after a bug fix or other revision to a +system library.\(dg +.FS +\(dgIf a module in one of the system libraries is changed it may be necessary +to rebuild the IRAF shared library \fL[IRAF.BIN]S_IRAF.EXE\fR before relinking +the system. +.FE +.PP +The system generation procedures are fully automated hence it is easy +to modify, recompile, or relink all or any portion of the system. The full +system generation procedure, starting from the system sources, is as follows: +.RS +.IP \(bu +Bootstrap the HSI (done with VMS \fL.COM\fR files). Requires the DEC C +compiler and old versions of \fLLIBSYS\fR and \fLLIBVOPS\fR, used for VOS +filename mapping. User sites should \fInever\fR need to bootstrap VMS/IRAF +unless some catastrophe occurs, e.g., an important HSI binary file is deleted +and the VMS/IRAF distribution tape can no longer be located. +.IP \(bu +Recompile the main system libraries. All VMS/IRAF distributions include +full object libraries, hence it should never be necessary to fully recompile +the system object libraries from scratch, but updating the system libraries +may be necessary before changes to system files will take effect, e.g., when +caching new termcap or graphcap device entries (\(sc5.2.3). +.IP \(bu +Rebuild the IRAF shared library if used (the system can be linked without +the shared library if desired). This will be necessary if a module +is updated in a system library, e.g., to fix a bug or change a compile time +option (as when caching new termcap or graphcap entries). The shared library +must be rebuilt for changes to modules in the main system object libraries +to have any effect. Relinking the shared library may also be necessary on +old versions of VMS; this is indicated if after relinking with the shared +library provided on the distribution tape, VMS still refuses to run the +newly linked process (make sure an old executable is not being run mistakenly +because it is still "installed"). +.IP \(bu +Recompile and relink the applications packages. Relinking is necessary when +installing a "you relink" version of the system, and may be necessary when +installing the distributed system on an old version of VMS. The system must +be relinked before changes to the shared library or the system object libraries +will have any effect. Note also that any installed images (\(sc2.3.3) must +be deinstalled and reinstalled after relinking, before changes to the installed +executables will take effect. +.RE +.PP +All VMS/IRAF distributions come with the bootstrap already performed, and with +the system and package object libraries already compiled and the shared library +already built. A fully binary distribution includes the executables as well, +and can be run as is. +.PP +Once the system has been bootstrapped the HSI bootstrap utility program +\fLmkpkg\fR is used for all system maintenance. +Documentation for this and the other utilities in the SOFTOOLS package +may be found in the \fIIRAF User Handbook\fR, and is also available in +the online system via \fLhelp\fR. The \fLmkpkg\fR program, +like all the HSI utilities, may be run either from DCL or from the IRAF CL. + +.NH 3 +Bootstrapping the HSI +.PP +There are two different sets of executables in the system, the so-called +"bootstrap utilities" (part of the HSI, or host system interface), and the +regular system executables. The bootstrap utilities are the \fL.exe\fR files +in \fLhlib\fR, e.g., \fLmkpkg\fR, \fLrtar\fR, and so on. The regular IRAF +executables are those maintained in the \fLbin\fR directory. +.PP +The bootstrap utilities are required for system maintenance of the main system +and hence must be linked first. However, unless a bug fix or other revision +is made to one of the main system libraries (particularly \fLlibos\fR), there +should be no reason for a user site to ever need to bootstrap the system. +The bootstrap utilities are linked with the option \fL/NOSYSSHARE\fR, hence +they should run on any version of VMS. +.PP +The bootstrap utilities are written in C, and the DEC C compiler is required +to compile or link these utilities. The C compiler is \fInot\fR required to +run the prelinked binaries distributed with the system. To recompile and link +the bootstrap utilities, i.e., to "bootstrap" IRAF, enter the commands shown +below. Note that the HSI is always recompiled during a bootstrap; there +is no provision for merely relinking the entire HSI (some individual programs +can however be relinked manually by doing a \fLmkpkg update\fR in the program +source directory). +.DS +\fL$ set default [iraf.vms] +$ set verify +$ @rmbin.com +$ @mkpkg.com\fR +.DE +.PP +The bootstrap should take 30 to 45 minutes on an unloaded 11/780. +Once the bootstrap utilities have been relinked and installed in \fLhlib\fR, +the main system may be relinked. + +.NH 3 +Updating the System Libraries +.PP +Updating the system libraries, i.e., recompiling selected object modules and +inserting them into the system object libraries, is necessary if any system +source files are edited or otherwise modified, as when using the +\fLmkttydata\fR utility program to cache new termcap or graphcap device +entries. +.PP +The system libraries may be updated either from within the IRAF CL, or from +DCL. For example, from within DCL: +.DS +\fL$ set def [iraf] +$ mkpkg syslibs \fR[\fPmathlibs\fR]\fR +.DE +This command will run the \fLmkpkg\fR utility, which will update each system +library in turn, descending into the tree of source directories and checking +the date of each object module therein against the dates of the source files +and dependency files used to produce the object module, and recompiling any +object modules which are out of date. In the worst case, e.g., if the +system libraries have been deleted, the entire VOS (virtual operating system) +will be recompiled. If it is known that no changes have been made to the +math library source files, the optional \fLmathlibs\fR argument may be +omitted to save some time. + +.NH 3 +Relinking the IRAF Shared Library +.PP +The IRAF shared library (\fL[IRAF.BIN]S_IRAF.EXE\fR) is constructed by +linking the contents of the four main IRAF system libraries \fLLIBEX\fR, +\fLLIBSYS\fR, \fLLIBVOPS\fR, and \fLLIBOS\fR. Hence, the system libraries +must exist and be up to date before linking the shared library. The shared +library must be installed in \fLbin\fR before it can be used to link any +applications programs. At present, the shared library does not use +transfer vectors, hence the full system must be relinked following any +changes to the shared library. Note that since the shared library is +normally installed in system memory, all installed IRAF images should be +deinstalled and later reinstalled whenever the shared library is rebuilt. +IRAF will not be runnable while this is taking place. +.PP +In the current release of IRAF (V2.5) the procedure for building the shared +library has not yet been integrated into the automatic system generation +procedure. Furthermore, utility tasks in the main IRAF system are currently +used to build the shared library, so it is necessary to have at least part +of the main system functioning before the shared library can be built. These +problems (and the transfer vector problem) will be fixed in a future release +of VMS/IRAF. +.PP +The shared library is rebuilt from within a running IRAF system providing +at a minimum the three executables \fLCL.EXE\fR, \fLX_SYSTEM.EXE\fR, and +\fLX_LISTS.EXE\fR. If these executables do not yet exist or not runnable, +rebuild them as follows. Note the use of the \fL-z\fR link flag to link +the new executables without the shared library. +.DS +\fL$ set default [iraf.pkg.cl] +$ mkpkg update lflags=-z +$ set default [iraf.pkg.system] +$ mkpkg update lflags=-z +$ set default [iraf.pkg.lists] +$ mkpkg update lflags=-z\fR +.DE +.LP +Now login to the CL and proceed to the directory \fLhlib$share\fR, which +contains the code used to build the shared library. +.DS +\fL$ set default [iraf.local] +$ cl + \fR(cl starts up...)\fP +cl> cd hlib$share\fR +.LP +.DE +The following commands will rebuild the shared library and install it in +\fLbin\fR. This takes ten minutes or so. +.DS +\fLcl> cl < makeshare.cl + \fR(takes a while)\fP +cl> mkpkg install +cl> purge +cl> logout\fR +.DE +.PP +The system library can be updated (\(sc5.1.2) and the shared library rebuilt +while IRAF is in use by normal users, however as soon as the command +\fLmkpkg install\fR is executed (moving the new \fLS_IRAF.EXE\fR to +\fLbin\fR) execution of normal user programs is at risk and one should +kick all IRAF users off the machine and deinstall any installed IRAF images. +The system may now be relinked and the newly linked shared library and images +reinstalled, after which the system is ready for normal use again. + +.NH 3 +Relinking the Main IRAF System +.PP +The following DCL commands may be entered to relink the main IRAF system, +installing the newly linked executables in \fLbin\fR. Note that any +IRAF executables that have been installed in system memory must be +deinstalled and reinstalled (\(sc2.3.3) following the relink. +.DS +\fL$ set default [iraf] +$ mkpkg update\fR +.DE +.PP +The command shown causes the full system to be relinked (or recompiled and +relinked if any files have been modified) using the default compile and +link switches defined in the global \fLmkpkg\fR include file \fLmkpkg.inc\fR +in \fLhlib\fR. Any system wide changes in how the system is generated should +be implemented by editing the contents of this file. For example, the default +file supplied with the system includes the following line: +.DS +\fL$set LFLAGS = "" # default XC link flags\fR +.DE +This switch defines the switches to be passed to the HSI bootstrap utility +program \fLxc\fR to link the IRAF executables (no switches are given, hence +the default link action will be taken). +The switch \fL-z\fR may be included in the \fLxc\fR command line to link +an executable directly against the system object libraries, rather than +using the shared library. Hence, to relink IRAF without using the IRAF +shared library (as is necessary for all but one system when there are multiple +versions of IRAF simultaneously installed on the same machine) we would change +the definition of \fLLFLAGS\fR as follows: +.DS +\fL$set LFLAGS = "-z" # default XC link flags\fR +.DE +.PP +A full system relink takes approximately 30 minutes, or significantly less +if the shared library is used. A full system compile and relink takes 9-24 +hours depending upon the host system. + +.NH 3 +Relinking or Updating IRAF Packages +.PP +Should it be necessary to fix a bug in one of the applications packages, +it is very easy to recompile and relink the package and install the new +executable. After editing the affected files, enter any of the following +commands (this is normally done from within the CL): +.DS +.TS +l l. +\fLmkpkg\fR Makes an executable in the package directory. +\fLmkdebug\fR Same, but with the debugger linked in. Linking with the + debugger does not defeat use of the shared libraries. +\fLmkpkg install\fR Used after "mkpkg" (but not mkdebug!) to + install the new executable in BIN. +\fLmkpkg udpate\fR Relinks the new executable and installs it in + BIN all in one shot. +.TE +.DE +.LP +The preferred command is \fLmkpkg update\fR when it is desired to update +the package library, relink the package executable (or executables), and +install these in \fLbin\fR for use in the runtime system. +.PP +If extensive revisions are contemplated, a copy of the entire package should +be made and moved out of the system, and that version of the package modified, +rather than modifying the standard package, which will only make updating the +system more difficult. It will be necessary to delete or replace the installed +executables in \fLbin\fR before the revised ones can be used. +One need only redefine or modify the directory pathname in the \fLtask\fR +declaration for the package to cause a different version of the package +to be used. It is not necessary to physically install locally modified code +in the main system to make use of it, and this is not recommended as it may +be lost when the system is subsequently updated. + +.NH 2 +Tuning Considerations +.PP +There are a number of things that can be done to tune VMS/IRAF for a +particular host system: +.sp +.RS +.IP \(bu +Install the executables to permit shared memory. +.IP \(bu +Render the large runtime files contiguous to increase i/o efficiency. +.IP \(bu +Precompile selected \fLTERMCAP\fR and \fLGRAPHCAP\fR entries. +.IP \(bu +Strip the system to reduce disk consumption. +.RE + +.NH 3 +Installing Executable Images +.PP +The standard distribution of VMS/IRAF is configured to use a shared library +for the bulk of the IRAF runtime system code. Use of this shared library +considerably reduces the disk requirements of the system, while reducing +runtime system memory usage and process pagein time, and speeding up process +links during software development. +.PP +If the goal of minimizing physical memory utilization is to be achieved +when running IRAF, it is essential that the IRAF shared library be "installed" +in VMS system shared memory. Further memory savings through memory sharing +can be achieved if some of the more commonly used IRAF executables are also +installed. This becomes increasingly important as the number of IRAF users +increases, but some memory savings may result even if there is only one user, +since a single user may spawn batch jobs. Hence, the shared library +\fLs_iraf.exe\fR should always be installed if IRAF is used at all, and +\fLcl.exe\fR and \fLx_system.exe\fR are used by all IRAF jobs and should +be installed if there is usually at least one IRAF user on the system. +If there are usually several IRAF users on the system \fLx_images.exe\fR and +\fLx_plot.exe\fR are probably worth installing as well. +.PP +Installation of images in system shared memory is done with the VMS +\fLINSTALL\fR utility, +which requires SYSTEM privilege to execute (see also \(sc2.3.3). +Installation of the IRAF shared library and other images is most conveniently +done by executing the \fLINSTALL.COM\fR command procedure in \fLhlib\fR. +This file should be reviewed and edited during system installation to +select those images to be installed on the local host. The file may be +directly executed to temporarily install the images, but to permanently +install the images the system bootstrap procedure should be modified to +execute the \fLINSTALL.COM\fR script (or explicitly install the images by +name) whenever the system is booted. Note that any currently installed +images must be explicitly deinstalled before a new version can be installed, +and that the global pages used by an installed image are not actually freed +until any and all processes using those global pages terminate. +.PP +The procedure for installing images will fail if there are insufficient +global pages available in the system (for example, the number of global +pages required to install the shared library in VMS/IRAF V2.5 is about 760). +If the system has insufficient free global pages to run the \fLINSTALL.COM\fR +script one must either increase the number of system global pages (which +requires rebooting the system), or one must edit the \fLINSTALL.COM\fR +script to reduce the number of images to be installed. + +.NH 3 +Rendering Large Runtime Files Contiguous +.PP +The speed with which large disk files can be read into memory in VMS can +degrade significantly if the disk is highly fragmented, which causes a +large file to be physically stored in many small fragments on the disk. +IRAF performance as well as VMS system throughput can therefore be improved +by rendering frequently referenced large files contiguous. Examples of +files which it might pay to render contiguous are the executables in +\fLbin\fR, all of the runtime files in \fLdev\fR, and the large system +libraries in \fLlib\fR (this last is only useful to speed software +development, i.e., linking). +.PP +The easiest way to render a file contiguous in VMS is to use +\fLCOPY/CONTIGUOUS\fR to copy the file onto itself, and then purge the +old version. Various nonstandard utility programs are available commercially +which will perform this function automatically. The contents of an entire +disk may be rendered contiguous or nearly contiguous by backing up the disk +onto tape and then restoring it onto a clean disk. + +.NH 3 +Precompiling TERMCAP and GRAPHCAP Entries +.PP +Precompilation of a termcap or graphcap entry is a technique used to +speed runtime access of the entry for that device. If the entry is not +precompiled the termcap or graphcap file must be physically opened and +scanned at runtime to read the desired entry. This causes a noticeable +delay of as much as a second when clearing the terminal screen or plotting +a graph, hence it is usually worthwhile to cache the entries for commonly +used video and graphics terminals. It is generally not worthwhile for +printers, plotters, and image displays. +.PP +The system comes with selected termcap and graphcap entries already +precompiled. To see which devices are precompiled, page the cache data files, +\fLdev$cachet.dat\fR (for termcap) and \fLdev$cacheg.dat\fR (for graphcap). +To cache a different set of entries one must regenerate these files with the +\fLmkttydata\fR task in the SOFTOOLS package, and then do a full sysgen relink +with the \fLmkpkg\fR utility. Detailed instructions are given in the manual +page for \fLmkttydata\fR.\(dg +.FS +\(dg\fBImportant Note\fR: If the system is configured to use the IRAF shared +library (the default), you must update the system libraries (\(sc5.1.2) and +rebuild the shared library (\(sc5.1.3) before relinking the system \(sc5.1.4), +else the changes to the termcap and graphcap cache files will have no effect. +The use of the shared library is peculiar to VMS/IRAF and is not discussed +in the \fLmkttydata\fR documentation. +.FE + +.NH 3 +Stripping the System to Reduce Disk Consumption +.PP +If the system is to be installed on multiple cpu's, or on a particularly +small host like a MicroVAX, it may be necessary or desirable to strip the +system of all non-runtime files to save disk space. This is done by deleting +all the program sources and all the sources for the reference manuals and +other printed documentation, but not the online manual pages. A special +utility called \fLrmfiles\fR (in the SOFTOOLS package) is provided for this +purpose. It is not however necessary to run \fLrmfiles\fR directly to strip +the system. This may be done either from DCL or from within the CL. +.DS +\fL$ set default [iraf] +$ mkpkg strip\fR +.DE +This will preserve all runtime files, permitting use of the standard runtime +system as well as user software development. The size of the system (the +figures are for V2.5) is reduced from about 39 Mb (megabytes) to around 13 Mb. +One can optionally enter the command "\fLmkpkg stripall\fR" to delete +the system libraries as well, but this saves only another couple of Mb and +precludes all IRAF related software development, including user written +Fortran programs (IMFORT), hence is not recommended. + +.NH 2 +VMS Quotas and Privileges Required to Run IRAF +.PP +The only special privilege required by IRAF is TMPMBX, which is probably +already standard on your system. Systems with DECNET capabilities should also +give their users NETMBX privilege, although it is not required to run IRAF. +No other privileges are required or useful for normal activities. +.PP +Although privileges are no problem for VMS/IRAF, +it is essential that the IRAF user have sufficient VMS quota, +and that the system tuning parameters be set correctly, +otherwise IRAF will not be able to function well or may not function at all. +If a quota is exceeded, or if the system runs out of some limited resource, +the affected VMS system service will return an error code to IRAF and the +operation will fail (this frequently happens when trying to spawn a connected +subprocess). The current recommended ranges of per-user quotas are summarized +below. +.KS +.TS +center; +ci ci ci +l n n. +quota minimum recommended +.sp +\fLBYTLM\fR 20480 30720 +\fLPGFLQUOTA\fR 15000 30720 +\fLPRCLM\fR 5 10 +\fLWSDEFAULT\fR 512 512 +\fLWSEXTENT\fR 4096 WSMAX +\fLJTQUOTA\fR 2048 2048 +.TE +.KE +.PP +The significance of most of these quotas is no different for IRAF than for +any other VMS program, hence we will not discuss them further here. +The \fLPRCLM\fR quota is especially significant for IRAF since an IRAF job +typically executes as several concurrent processes. The \fLPRCLM\fR quota +determines the maximum number of subprocesses a root process (user) may have. +Once the quota has been reached process spawns will fail causing the IRAF +job or operation to abort. +.PP +The minimum number of subprocesses a CL process +can have is 1 (\fLx_system.e\fR). As soon as a DCL command is executed via +OS escape a DCL subprocess is spawned, and we have 2 subprocesses. +The typical process cache limit is 3, one slot in the cache being used by +\fLx_system.e\fR, hence with a full cache we have 4 subprocesses (the user +can increase the process cache size if sufficient quota is available to +avoid excessive process spawning when running complex scripts). It is common +to have one graphics kernel connected, hence in normal use the typical +maximum subprocess count is 5. However, it is conceivable to have up to +3 graphics kernel processes connected at any one time, and whenever a +background job is submitted to run as a subprocess a whole new subprocess +tree is created. Hence, it is possible to run IRAF with a \fLPRCLM\fR of +5, but occasional process spawn failures can be expected. Process spawn +failures are possible even with a \fLPRCLM\fR of 10 if subprocess type batch +jobs are used (the default), but in practice such failures are rare. +If all batch jobs are run in batch queues it should be possible to work +comfortably with a \fLPRCLM\fR of 5-6, but in practice users seem to prefer +to not use the batch queues, except for very large jobs. +.PP +Since IRAF uses memory efficiently the working set parameters do not +seem critical to IRAF, provided the values are not set unrealistically low, +and provided \fLWSEXTENT\fR is set large enough to permit automatic growth +of a process working set when needed. Configuring VMS to steal pages from +inactive processes is not recommended as it largely cancels the effect of +the process cache, causing process pagein whenever a task is executed. +It is better to allow at least a minimum size working set to each process. +.PP +In addition to sufficient per user authorized quota, the system tuning +parameters must be set to provide enough dynamically allocatable global +pages and global sections to handle the expected load. If these parameters +are set too small, process connects will fail intermittently, usually when +the system load is high. Each subprocess needs about 10 global pages when +activated (IRAF uses global pages and shared memory for interprocess +communications, due to the relatively low bandwidth achievable with the +VMS mailbox facilities). +With IRAF in heavy use (i.e., a dozen simultaneous users) this can easily +reach a requirement for several hundred additional global pages. +Each installed image and subprocess also needs at least one, usually two, +global sections. The system parameters on our 8600 (which is probably a +worst case example) are currently set to \fLGBLPAGES\fR = 12220 +and \fLGBLSECTIONS\fR = 230. + +.NH +Interfacing New Graphics Devices +.PP +There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +The topic of interfacing to these devices has already been discussed in +prior IRAF Newsletters, hence the discussion given here will be brief. + +.NH 2 +Graphics Terminals +.PP +The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal and most workstations, using the \fLSTDGRAPH\fR +graphics kernel supplied with the system. All one need do to interface to a +new graphics terminal is add a new graphcap entry for the device. This can +take anywhere from a few hours to a few days, depending on one's level of +expertise, and the perversity of the device in question. Be sure to check +the contents of the \fLdev$graphcap\fR file to see if the terminal is already +supported, before trying to write a new entry. Assistance in interfacing new +graphics terminals is available via the IRAF Hotline. + +.NH 2 +Graphics Plotters +.PP +The current IRAF system comes with several graphics kernels usable to drive +graphics plotters. The standard plotter interface is via the SGI graphics +kernel, which has largely replaced the older \fLNCAR\fR kernel used in earlier +versions of IRAF (in those earlier versions the \fLNCAR\fR kernel was called +the \fLSTDPLOT\fR kernel). Further information on the SGI plotter interface +is given in the paper \fIThe IRAF Simple Graphics Interface\fR, a copy of which +is included with the installation kit. SGI device interfaces for most VAX/VMS +plotter devices already exist, and adding support for new devices is +straightforward. Sources for the SGI device translators supplied with the +distributed system are maintained in the directory \fL[iraf.vms.gdev.sgidev]\fR. +NOAO serves as a clearinghouse for new SGI plotter device interfaces; +contact us if you do not find support for a local plotter device in the +distributed system, and if you plan to implement a new device interface let +us know so that we may help other sites with the same device. +.PP +The older \fLNCAR\fR kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +plots on devices supported by host-level NCAR metacode translators. +The host level NCAR metacode translators are not included in the standard +IRAF distribution, but public domain versions of the NCAR implementation for +VAX/VMS (called MCVAX) are widely available. A site which already has the +NCAR software may wish to go this route, but the SGI interface will provide +a more efficient and simpler solution in most cases. +.PP +The remaining possibility with the current system is the \fLCALCOMP\fR kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. To make use of such a library to get +plotter output on any devices supported by the interface, one may copy +the library to the \fLhlib\fR directory and relink the Calcomp graphics +kernel. The following commands should suffice to install the calcomp or +Versaplot library, and relink and install the Calcomp graphics kernel in IRAF: +.DS +\fL$ set default [iraf.vms.hlib] +$ copy \fI\fP libcalcomp.olb +$ set default [iraf.sys.gio.calcomp] +$ mkpkg update\fR +.DE +A graphcap entry for each supported device may also be required. +.PP +Note that sites having a Versatec plotter but lacking the system software +driver \fLLVDRIVER\fR (or whose only driver is Versatec's RASM, e.g. +\fLSYS$SYSTEM:RASM.EXE\fR) must link the Calcomp graphics kernel with +the Versaplot library (usually \fLSYS$LIBRARY:PHASE1.OLB\fR -- copy to +libcalcomp as shown above) and then use that kernel to access those plotters. +In that case you will still need to execute the RASM task after the +kernel finishes executing. Sites in this situation should contact us +for advice on how to make plotting easier. + +.NH 2 +Image Displays +.PP +The current IRAF system does not yet have a well defined and well isolated +device independent image display interface. Work on such an interface is +currently underway; contact the IRAF group at NOAO for further information +on the status of the new display interfaces. Further information on the +image display interfaces currently available may be found in the +\fIIRAF Newsletter\fR. +.PP +If there is no IRAF interface for your device, the best approach at present is +to use the IMFORT interface and whatever non-IRAF display software you +currently have to construct a host level Fortran or C display program +(a number of people have also managed to construct an interface by hacking +the IRAF display software in \fLpkg$images/tv/display\fR). +The IMFORT library provides host system Fortran or C programs with access +to IRAF images on disk. Documentation on the IMFORT interface is available in +\fIA User's Guide to Fortran Programming in IRAF -- The IMFORT Interface\fR, +Doug Tody, September 1986, a copy of which is included in the IRAF User +Handbook, Volume 1A. + +.NH +The IRAF Directory Structure +.PP +The current full VMS/IRAF directory structure is documented graphically in +the appendix. The main branches of the tree are the following; beneath the +directories shown are some 250 subdirectories, the largest directory trees +being \fLsys\fR, \fLpkg\fR, and \fLnoao\fR. The entire contents of all +directories other than \fLvms\fR, \fLlocal\fR, and a few configuration files +in \fLdev\fR are fully portable, and are identical in all installations +of IRAF sharing the same version number. +.DS +\fLbin \fR- installed executables +\fLdev \fR- device tables (\fLtermcap\fR, \fLgraphcap\fR, etc.) +\fLdoc \fR- assorted IRAF manuals +\fLlib \fR- the system library; object libraries, global files +\fLlocal \fR- iraf login directory; locally added software +\fLmath \fR- sources for the mathematical libraries +\fLnoao \fR- packages for NOAO data reduction +\fLpkg \fR- the IRAF applications packages +\fLsys \fR- the virtual operating system (VOS) +\fLvms \fR- the VMS host system interface (HSI = kernel + bootstrap utilities) +.DE +.LP +The contents of the \fLvms\fR directory (the VMS host system interface) are +as follows: +.DS +\fLas \fR- assembler sources for VMS/IRAF +\fLboot \fR- bootstrap utilities (mkpkg, rtar, wtar, etc.) +\fLgdev \fR- graphics device interfaces (SGI device translators) +\fLhlib \fR- host dependent runtime files +\fLmkpkg.com \fR- executed to bootstrap the VMS/IRAF HSI +\fLos \fR- OS interface routines (VMS/IRAF kernel) +\fLrmbin.com \fR- executed to delete binary files in subdirectories +.DE +.PP +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. diff --git a/doc/vmsiraf.ms.v29 b/doc/vmsiraf.ms.v29 new file mode 100644 index 00000000..ed3c271b --- /dev/null +++ b/doc/vmsiraf.ms.v29 @@ -0,0 +1,2673 @@ +.RP +.TL +VMS/IRAF Installation and Maintenance Guide +.AU +Doug Tody +.br +Steve Rooke, Suzanne Jacoby, Nigel Sharp +.AI +.K2 "" "" "*" +July 1987, Revised July 1989 + +.AB +.ti 0.75i +Instructions are presented for installing, updating, and maintaining the VMS +version of the portable IRAF system (Image Reduction and Analysis Facility). +Step by step procedures are presented both for the initial IRAF installation +and for updating an existing installation to the latest release of the system. +Procedures for improving performance, minimizing disk and memory usage, and +interfacing site dependent devices such as video or graphics terminals, +plotters, image displays, and magnetic tape drives are discussed. +.AE + +.pn 1 +.bp +.sp 2.5i +.ce +.ps 11 +.ps +2 +\fBHistorical Notes\fR +.ps -2 +.sp 3 +The initial port of IRAF to VMS was carried out during 1984 and early 1985 +at STScI (the Space Telescope Science Institute) by Jay Travisano +and Fred Romelfanger, working under the supervision of Peter Shames, with +some assistance early on from Jim Rose. The major system components +implemented during this period were the SPP compiler (XC) and the OS +interface routines for VMS, as specified in \fIA Reference Manual for the +IRAF System Interface\fP, Doug Tody, May 1984. +.sp +Completion of VMS/IRAF took place at NOAO in the fall of 1985. This period +saw the definition of a major new interface, the HSI (host system interface), +and the implementation of the \f(CWmkpkg\fP system maintenance utility and +many of the other HSI bootstrap utilities. This eliminated the final +differences between the different versions of IRAF, allowing software to be +routinely ported between UNIX/IRAF, VMS/IRAF, and so on, without any changes +to the program sources or configuration control files, and allowing full +automation of the system configuration control procedures. +.sp +The initial implementation of shared libraries for VMS/IRAF was carried out +in the fall of 1986 by Dennis Crabtree of DAO (the Dominion Astrophysical +Observatory, UBC, Canada), while on leave at STScI. + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fP +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInitial System Installation\fP\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.1.\h'|0.9i'Create the IRAF Account\l'|5.6i.'\0\02 +.br +\h'|0.4i'2.2.\h'|0.9i'Read the BACKUP Tape\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.3.\h'|0.9i'Edit the System Configuration Files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.3.1.\h'|1.5i'[IRAF.VMS.HLIB]IRAFUSER.COM\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.3.2.\h'|1.5i'[IRAF.VMS.HLIB]INSTALL.COM\l'|5.6i.'\0\05 +.br +\h'|0.9i'2.3.3.\h'|1.5i'[IRAF.VMS.HLIB.LIBC]IRAF.H\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.4.\h'|0.9i'Relink If Necessary\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.5.\h'|0.9i'Complete the Initial System Configuration\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.6.\h'|0.9i'Edit the System Dependent Device Files\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.6.1.\h'|1.5i'[IRAF.VMS.HLIB]ZZSETENV.DEF\l'|5.6i.'\0\07 +.br +\h'|0.9i'2.6.2.\h'|1.5i'[IRAF.DEV]DEVICES\l'|5.6i.'\0\08 +.br +\h'|0.9i'2.6.3.\h'|1.5i'[IRAF.DEV]TERMCAP\l'|5.6i.'\0\08 +.br +\h'|0.9i'2.6.4.\h'|1.5i'[IRAF.DEV]GRAPHCAP\l'|5.6i.'\0\08 +.br +\h'|0.9i'2.6.5.\h'|1.5i'IRAF Networking\l'|5.6i.'\0\09 +.sp +3.\h'|0.4i'\fBUpdating an Existing IRAF Installation\fP\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.1.\h'|0.9i'Save Locally Modified Files\l'|5.6i.'\0\09 +.br +\h'|0.4i'3.2.\h'|0.9i'Read the Distribution Tape or Tapes\l'|5.6i.'\0\10 +.br +\h'|0.4i'3.3.\h'|0.9i'Merge Saved Files Back Into the New System\l'|5.6i.'\0\10 +.br +\h'|0.4i'3.4.\h'|0.9i'Relink If Necessary\l'|5.6i.'\0\11 +.br +\h'|0.4i'3.5.\h'|0.9i'Update VMS\l'|5.6i.'\0\11 +.sp +4.\h'|0.4i'\fBTesting a Newly Installed or Updated System\fP\l'|5.6i.'\0\12 +.sp +5.\h'|0.4i'\fBSystem Maintenance\fP\l'|5.6i.'\0\12 +.br +\h'|0.4i'5.1.\h'|0.9i'Software Management\l'|5.6i.'\0\12 +.br +\h'|0.9i'5.1.1.\h'|1.5i'Layered Software Support\l'|5.6i.'\0\12 +.br +\h'|0.9i'5.1.2.\h'|1.5i'Software Management Tools\l'|5.6i.'\0\13 +.br +\h'|0.9i'5.1.3.\h'|1.5i'Modifying and Updating a Package\l'|5.6i.'\0\14 +.br +\h'|0.9i'5.1.4.\h'|1.5i'Installing and maintaining layered software\l'|5.6i.'\0\15 +.br +\h'|0.9i'5.1.5.\h'|1.5i'Configuring a custom LOCAL package\l'|5.6i.'\0\16 +.br +\h'|0.9i'5.1.6.\h'|1.5i'Bootstrapping the HSI\l'|5.6i.'\0\16 +.br +\h'|0.9i'5.1.7.\h'|1.5i'Updating the System Libraries\l'|5.6i.'\0\17 +.br +\h'|0.9i'5.1.8.\h'|1.5i'Relinking the IRAF Shared Library\l'|5.6i.'\0\17 +.br +\h'|0.9i'5.1.9.\h'|1.5i'Relinking the Main IRAF System\l'|5.6i.'\0\18 +.br +\h'|0.4i'5.2.\h'|0.9i'Tuning Considerations\l'|5.6i.'\0\19 +.br +\h'|0.9i'5.2.1.\h'|1.5i'Installing Executable Images\l'|5.6i.'\0\19 +.br +\h'|0.9i'5.2.2.\h'|1.5i'Rendering Large Runtime Files Contiguous\l'|5.6i.'\0\20 +.br +\h'|0.9i'5.2.3.\h'|1.5i'Precompiling TERMCAP and GRAPHCAP Entries\l'|5.6i.'\0\20 +.br +\h'|0.9i'5.2.4.\h'|1.5i'Stripping the System to Reduce Disk Consumption\l'|5.6i.'\0\20 +.br +\h'|0.4i'5.3.\h'|0.9i'VMS Quotas and Privileges Required to Run IRAF\l'|5.6i.'\0\21 +.br +\h'|0.4i'5.4.\h'|0.9i'Miscellaneous Notes\l'|5.6i.'\0\22 +.sp +6.\h'|0.4i'\fBInterfacing New Graphics Devices\fP\l'|5.6i.'\0\22 +.br +\h'|0.4i'6.1.\h'|0.9i'Graphics Terminals\l'|5.6i.'\0\22 +.br +\h'|0.4i'6.2.\h'|0.9i'Graphics Plotters\l'|5.6i.'\0\23 +.br +\h'|0.4i'6.3.\h'|0.9i'Image Display Devices\l'|5.6i.'\0\23 +.sp +7.\h'|0.4i'\fBThe IRAF Directory Structure\fP\l'|5.6i.'\0\24 +.sp +\fBAppendix A. \0Private TMP and IMDIR Directories\fR\l'|5.6i.'\0\26 +.sp +\fBAppendix B. \0Upgrading a Pre-IRAF 2.8 [iraf.local] Directory\fR\l'|5.6i.'\0\27 +.sp +\fBAppendix C. \0Notes on Networking with DECNET in VMS/IRAF V2.8\fR\l'|5.6i.'\0\31 + +.nr PN 0 +.bp +.NH +Introduction +.PP +Installing VMS/IRAF is easy and fast, provided one takes the trouble to read +and follow the instructions in this installation guide. Instructions are given +both for the initial system installation (\(sc2, immediately following) +and for updating an existing installation (\(sc3). Variations on the +recommended system configuration are certainly possible and may be necessary +at some sites due to restrictions or quotas, but not following the standard +installation procedure or departing from the recommended system configuration +may cause the system to function incorrectly, inefficiently, or not at all. +.PP +The distribution tape is a snapshot of our local (NOAO/Tucson) VMS/IRAF system. +The device and system configuration tables come configured for our system, +and will have to be modified as part of the installation process. +These modifications are discussed in detail in this document. +To simplify the installation process as well as future upgrades, we have tried +to isolate the site dependent files to the minimum number of directories, i.e., +\f(CWdev\fP, \f(CWhlib\fP, and \f(CWlocal\fP and its subdirectories (the equivalent +VMS pathnames are \f(CW[IRAF.DEV]\fP, \f(CW[IRAF.VMS.HLIB]\fP, +and \f(CW[IRAF.LOCAL]\fP). +The remainder of the system should not require any modifications. +.PP +An installation typically takes about an hour, perhaps longer if relinking is +necessary. Interfacing new graphics terminals, plotters, or image displays +can take considerably longer, of course, and we will only touch upon such +matters in the installation guide. Feel free to contact the IRAF hotline for +assistance if any problems should arise during the installation, or for help +in interfacing new devices. +.sp +.TS +center; +cb s s +l l l. +IRAF HOTLINE +.sp +telephone \f(CW(602) 323-4160\fP +internet \f(CWiraf@noao.edu\fP +span/hepnet \f(CWnoao::iraf\fP (noao = 5355) +uucp \f(CW{arizona,decvax,ncar}!noao!iraf\fP or +uucp \f(CWuunet!noao.edu!iraf\fP +bitnet \f(CWiraf@noao.edu\fP (through a gateway) +.TE + +.NH +Initial System Installation +.PP +It is only necessary to follow the full installation procedure if IRAF has +not yet been installed on your system. If an old version of IRAF has already +been installed, proceed to \(sc3. +.PP +Briefly, the steps to be followed to install IRAF for the first time are the +following. This summary is provided only to introduce the basic installation +procedure: it is important to read the detailed installation instructions +for additional details, to avoid certain errors or omissions which are +otherwise highly likely (IRAF does not always follow VMS conventions). +.RS +.IP \(bu +Login as SYSTEM and create an account for user IRAF, root directory +\f(CW[IRAF]\fP, login directory \f(CW[IRAF.LOCAL]\fP, to be used by the IRAF +system manager to maintain IRAF. +.IP \(bu +Login as IRAF and run the \f(CWBACKUP\fP utility to restore the IRAF distribution +tape or tapes to disk. Make sure the files belong to user IRAF. +.IP \(bu +Edit the basic IRAF system configuration files \f(CWIRAFUSER.COM\fP and +\f(CWIRAF.H\fP (in \f(CWhlib\fP and \f(CWhlib/libc\fP), e.g., to change the system +dependent disk and batch queue names, and define the VMS pathnames to +the major IRAF directories. +.IP \(bu +Login again as SYSTEM and [1] copy the \f(CWIRAF.H\fP file edited above +to the VMS system library directory \f(CWSYS$LIBRARY\fP, +[2] add a global symbol \f(CWiraf\fP to the system-wide user login procedure +(e.g. \f(CWSYLOGIN.COM\fP) which when +executed by the user will execute the \f(CWIRAFUSER.COM\fP file to define the +rest of the IRAF logicals, and +[3] edit \f(CWINSTALL.LST\fP and execute the \f(CWINSTALL.COM\fP script +(in \f(CWhlib\fP) to "install" +in system shared memory at least the IRAF shared library, and probably some of +the most frequently used executables as well. +.RE +.PP +Although the system installation is not yet complete, +any user should now be able to run IRAF, i.e., +run the \f(CWiraf\fP command procedure to define the IRAF logicals, +run the \f(CWmkiraf\fP command procedure to initialize the IRAF environment, +and type the command \f(CWcl\fP to start up the IRAF Command Language (CL). +Following the basic installation procedure shown here, +it will still be necessary to modify the IRAF device tables to tell the system +about the local magtape devices, line printers, terminals, plotters, and so on. +This should be done from within the running IRAF system to facilitate +testing of the new device interfaces, and is an ongoing activity as new +devices are interfaced to the system. + +.NH 2 +Create the IRAF Account +.PP +Create an account for user `\f(CWIRAF\fP'. This is recommended for the +following reasons: +.DS +.IP \(bu +All IRAF system management should be performed using the default protections +etc. provided in the IRAF \f(CWlogin.com\fP. +.IP \(bu +Multiple people may need to be IRAF system manager. Having a separate account +avoids the need for one user to know another user's password. Even if there +is only one site manager at your site, it may be necessary to give login +information to the IRAF HOTLINE personnel to allow them to investigate a +problem. +.IP \(bu +Having IRAF owned by SYSMAN, SYSTEM or other management account is not a good +solution as then anyone who needs to serve as IRAF site manager would +require the manager's password, and furthermore, the protections etc. of +a privileged account would cause problems for normal users. +.DE +.PP +System management policies vary +from site to site, so we do not give specific instructions for \fIhow\fP +to create the account (e.g. \f(CW$ run sys$system:authorize\fP), but the +account itself should be structured as follows: +.RS +.IP \(bu +Select a disk device with sufficient free space for the system (see \(sc2.2 +below). If necessary, the system can be stripped after installation to save +space (\(sc5.2.4), but the full amount of space will be needed during +installation. The disk should not be a "rooted logical" \(dg. +.FS +\(dgA rooted logical might be something like \f(CWlocal_disk = +dub4:[local.]\fR, with the IRAF disk set to \f(CWlocal_disk\fR. This will +not work. +.FE +.IP \(bu +The root directory for the IRAF account should be set to \f(CW[IRAF]\fP, +as this name is explicitly assumed in various places in the configuration files. +A "rooted logical" directory will not work. +.IP \(bu +The \fIlogin\fR directory for the IRAF account should be set to +\f(CW[IRAF.LOCAL]\fP +rather than \f(CW[IRAF]\fP as one would expect, as we want to keep all the +locally modified files in subdirectories off the iraf login directory, to +simplify site management and future updates. If this point is missed the +iraf environment will not be set up properly, and later problems are sure +to result. +.IP \(bu +Do not create a \f(CWLOGIN.COM\fP for IRAF; one will be read from the +distribution tape, as will the \f(CW[IRAF.LOCAL]\fR directory. +(If for some local management reason the directory \f(CW[IRAF.LOCAL]\fR is +created at this +time, make sure it has the proper protections [e.g. "\f(CWset protection = +(s:rwd,o:rwd,g:r,w:r)\fR"].) +.IP \(bu +There is no need to worry about VMS quotas and privileges yet; this is not +a concern during installation and is discussed in a later section (\(sc5.3). +.RE +.NH 2 +Read the BACKUP Tape +.PP +Login as IRAF (ignore any \f(CWLOGIN.COM\fP not found error message) +and run the VMS \f(CWBACKUP\fP utility to read the BACKUP tape or tapes provided. +The tape contains approximately 8500 files in 300 directories, for a total +of 48 Mb or 96000 512-byte blocks (including binaries). This disk size +assumes a Disk Cluster Factor of 1; if your site has a larger DCF, IRAF +will take more space (you can distinguish between allocated size and used size +with \f(CW$dir/size=all\fP). +The system as distributed uses a shared library to reduce disk and +memory requirements. +If IRAF is relinked and run without the shared library (e.g., if two or +more versions of IRAF are installed on the same machine), the system will +take up about 63 Mb or 125000 blocks. +.DS +\f(CW\s-1$ mount/foreign \fItape\f(CW: +$ set default \fIdisk\f(CW:[iraf] +$ backup/rew \fItape\f(CW:iraf.bck/select=[iraf...] [...]/own=iraf/prot=w:r +\s0\fP +.DE +In this and all the following examples, names like \fIdisk:\fP, \fItape:\fP, +etc. denote site dependent device names for which you must supply values. +The tape may be restored while logged in as SYSTEM if desired, but the switch +\f(CW/OWNER=IRAF\fP should be appended to give the IRAF system manager +(anyone who logs in as IRAF) write permission on the files. +.PP +It typically takes twenty minutes to half an hour to read the tape on a +lightly loaded system. + +.NH 2 +Edit the System Configuration Files +.PP +The files listed below must be edited before the system can be run. +The principal change required is to change the pathnames of the major IRAF +logical directories for the local machine. If any of these files are edited +while logged in as SYSTEM, be sure to do a \f(CWSET FILE/OWNER=IRAF\fP to +restore ownership of the edited file to IRAF. +.NH 3 +[IRAF.VMS.HLIB]IRAFUSER.COM +.PP +This file defines the VMS logical names and symbols needed to run IRAF. +The site dependent ones are grouped at the beginning of the file. + +.IP \f(CWIRAFDISK\fP +.br +Set to the name of the disk the \f(CW[IRAF]\fP directory is on; this may +be another logical name but not a "rooted logical". + +.IP \f(CWIMDIRDISK\fP +.br +Set to the name of a public scratch device, if available. +The \f(CWmkiraf\fP script will try to create the default user image storage +directories on this disk, e.g., \f(CWIMDIRDISK:[\fIuser\f(CW]\fR. +All potential IRAF users should have write permission and quota on this +device. IRAF does not yet know about ACLs (access control lists). +.sp +A public scratch device is desirable because this is where bulk image data +will be stored by default. It is often best for this to be on a different +disk than that used for user logins, to minimize the amount of disk that has +to be backed up on tape, and to permit a different quota and file expiration +date policy to be used for large datafiles than is used for the small, +relatively long lived files normally kept on the user disk.\(dg +.sp +[Note for sites that use "rooted logicals": the VMS/IRAF kernel +does not yet understand rooted logicals. If you use one, e.g. for +\f(CWIMDIRDISK\fR, batch jobs that need to access it will fail. To avoid +problems, you must either choose \f(CWIMDIRDISK\fR to be truly just a disk +specification, or inform all users to edit their \f(CWlogin.cl\fR files after +a \f(CWMKIRAF\fR. +For example, if you define \f(CWIMDIRDISK\fR to be \f(CWDATA_DISK:\fR, +where \f(CWDATA_DISK\fR is a logical name for \f(CWdub4:[data.]\fR, +user ICHABOD's \f(CWlogin.cl\fR would have: +"\f(CWset imdir = DATA_DISK:[ICHABOD]\fR", +but this would not work for batch jobs. +The user should edit \f(CWlogin.cl\fR after a \f(CWMKIRAF\fR to use an +expanded directory specification, in this case: +"\f(CWset imdir = dub4:[data.ichabod]\fR".] +.IP \f(CWTEMPDISK\fR +.br +Set to the name of a public scratch device and create a public directory +\f(CW[IRAFTMP]\fR on this device. +The device may be the same as is used for \f(CWIMDIRDISK\fP if desired. +The IRAF logical directory "\f(CWtmp\fR" +(known as \f(CWIRAFTMP\fP in the \f(CWIRAFUSER.COM\fR file) +is defined as \f(CWTEMPDISK:[IRAFTMP]\fR.\(dg +.FS +\(dgIf local system management or accounting policies require that +private \f(CWtmp\fR and \f(CWimdir\fR directories be defined for each +user, rather than the public ones we recommend, see Appendix A. +.FE +The IRAF system will create temporary files in this directory at runtime. +These files are always deleted immediately after use (unless a task aborts), +hence any files in "\f(CWtmp\fP" older than a day or so are garbage and should +be deleted. It is best if "\f(CWtmp\fP" points to a public directory which +is cleaned periodically by the system, e.g., whenever the system is booted, +so that junk temporary files do not accumulate. This is a good reason for +using a single public directory for this purpose rather than per-user private +directories. The files created in \f(CWtmp\fP are rarely very large. +.sp +[See note under \f(CWIMDIRDISK\fP concerning rooted logicals, if you plan to +locate \f(CWTEMPDISK\fP at a rooted logical.] + +.IP \f(CWFAST,BATCH,SLOW\fP +.br +These are the logical names of the standard IRAF logical batch queues. +They should be redefined to reference the queues used on your machine, +e.g., the standard VMS batch queue \f(CWSYS$BATCH\fP (all three names +may point to the same batch queue if desired). The fast queue is intended +for small jobs to be executed at interactive priorities, the batch queue +is for medium sized jobs, and the slow queue is for large jobs that need +a lot of system resources and are expected to run a long time. + +.IP \f(CWSYS$NODE\fP +.br +If you have DECNET installed, the system logical \f(CWSYS$NODE\fP will +probably already be defined (\f(CW$ show logical sys$node\fP). If it +is not defined, uncomment the line containing the sys$node definition, +and set \f(CWNODE\fP to "::", as: +.br +.sp + \f(CW$ define/job SYS$NODE "::"\fP +.sp +.NH 3 +[IRAF.VMS.HLIB]INSTALL.COM +.PP +This command procedure is run by the system manager, or by the system at +boot time, to install the IRAF shared library and selected executable +images.\(dg +.FS +\(dg\fRIn VMS terminology, \fIimage\fR, as in "executable image" refers to the +executable program, and has nothing to do with IRAF image data. +.FE +Installing images in system memory is necessary to permit memory sharing in +VMS, and can greatly reduce physical memory usage and paging on a busy system. +Installing images also consumes system global pages, however, of which there +is a limited supply. Hence, one should only install those images which will +be used enough to make it worthwhile. See \(sc5.2.1 for more information. +.PP +The \f(CWinstall.com\fP procedure both installs the IRAF executables and replaces +them after any have been changed. It works from a separate list of files, +so you should not edit \f(CWinstall.com\fP itself. Instead, edit +\f(CWinstall.lst\fP to select files by commenting out only those which are +\fInot\fP to be installed (the comment character is a "\f(CW!\fP" at the +beginning of the line). +The shared library \f(CWs_iraf.exe\fP should always be installed if IRAF is +going to be used at all, or the system will execute very inefficiently (the +IRAF shared library is used by all executing IRAF processes). +Normally the executables \f(CWcl.exe\fP and \f(CWx_system.exe\fP +should also be installed, since these are used by anyone using IRAF, as well +as by all batch IRAF jobs. If IRAF is heavily used and sufficient global +pages are available it is also desirable to install \f(CWx_images.exe\fP and +\f(CWx_plot.exe\fP, since virtually everyone uses these executable images +frequently when using IRAF. It is probably not worthwhile to install any +other executables, unless usage at the local site involves heavy use of +specific additional executable images. + +.NH 3 +[IRAF.VMS.HLIB.LIBC]IRAF.H +.PP +This file (often referred to as \f(CW\fP) +is required to compile any of the C source files used in IRAF. +Most sites will not need to recompile the C +sources and indeed may not even have the DEC C compiler, but the file is +also used by the runtime system in some cases to resolve logical names, +hence must be edited and installed in the VMS system library. +Change the following disk names as required for your system, +referencing only system wide logical names in the new directory pathnames +(i.e. \f(CWusr1:[IRAF.VMS]\fP, where \f(CWusr1\fP is a system logical name; +do not leave the IRAF logicals like \f(CWirafdisk\fP in the definition). +.DS +.TS +center; +ci ci +n l. +IRAF Logical Directory VMS directory + +\f(CW\&HOST\fP \fIirafdisk\f(CW:[IRAF.VMS]\fP +\f(CW\&IRAF\fP \fIirafdisk\f(CW:[IRAF]\fP +\f(CW\&TMP\fP \fItempdisk\f(CW:[IRAFTMP]\fP (may vary\(dg\(dg) +.TE +.DE +.FS +\(dg\(dg\fRIf local system restrictions forbid a +public \f(CWIRAFTMP\fP directory, +set this entry to the pathname of a suitable directory in IRAF, e.g., +\f(CW[IRAF.LOCAL.UPARM]\fP. This should work in most circumstances, +since it is most likely to be the +IRAF system manager who runs a program that accesses these pathnames. +This is separate from the user-level private \f(CWtmp\fR directory discussed +in Appendix A. +.FE +.PP +These directory definitions are referenced only if logical name translation +fails for some reason, as sometimes happens on VMS systems for various reasons. +It is therefore essential that only system wide logical names be used in +these directory pathnames. Do not use job or process logicals. Do not +change the order in which the entries appear, or otherwise alter the syntax; +the kernel code which scans \f(CW\fP is very strict about the syntax. + +.NH 2 +Relink If Necessary +.PP +If you received a full binary distribution of VMS/IRAF and you are not running +an old version of VMS, you do not need to relink the system and may proceed +to \(sc2.5. A "you relink" distribution is shipped without binaries so of +course requires linking. Linking may also be necessary when running a version +of VMS older than that installed on our NOAO system when the executables in +a binary release were linked, since the VMS operating system may refuse to +run executables linked on a possibly incompatible "future" revision of VMS. +.PP +In any case, relinking the system is easy and fast. The basic procedure is +outlined below; additional information is given in \(sc5.1.9. +The following commands should be executed while logged in as IRAF. +.DS +\f(CW$ set default [iraf] +$ mkpkg update +$ set default [iraf.noao] +$ mkpkg update\fR +.DE +.PP +By default, the system is linked against the IRAF shared library +\f(CWS_IRAF.EXE\fP which should already be present in the \f(CW[IRAF.BIN]\fP +directory after restoring the distribution tape. This speeds up linking and +considerably reduces the size of the resultant executables. It should not +be necessary to relink the HSI executables (in \f(CWhlib\fP), as these are +linked with \f(CW/NOSYSSHARE\fP on our system and are included in all VMS/IRAF +distributions. + +.NH 2 +Complete the Initial System Configuration +.PP +Login again as SYSTEM and copy the recently edited file +\f(CWirafdisk:[iraf.vms.hlib.libc]iraf.h\fP to the system library, +ensuring that the file has world read permission (be sure not to +copy \f(CW[iraf.vms.hlib]iraf.h\fR by mistake):\(dg +.FS +\(dg\fROn a VMS cluster, make sure the \f(CWIRAF.H\fR file is added to +\f(CWSYS$COMMON:[SYSLIB]\fR rather than \f(CWSYS$SYSROOT:[SYSLIB]\fR, +so that all nodes in the cluster may transparently access the file. +The same precaution is needed when editing the system-wide login procedure +file (e.g. \f(CWSYLOGIN.COM\fR), +which will probably want to go into \f(CWSYS$COMMON:[SYSMGR]\fP. +The \f(CWSYSTARTUP.COM\fR file (or \f(CWSYSTARTUP_V5.COM\fR in VMS V5.x), +on the other hand, +should go into \f(CWSYS$SYSROOT:[SYSMGR]\fP if the bootstrap procedure is +different for each node. +.FE +.DS +\f(CW$ set default sys$library +$ copy \fIdisk\f(CW:[iraf.vms.hlib.libc]iraf.h []/protection=w:r +.DE +.PP +Add the following statement to the system \f(CWSYLOGIN.COM\fP file, making the +appropriate substitution for \fIdisk\fP. +.DS +\f(CW$ iraf :== "@\fIdisk\f(CW:[iraf.vms.hlib]irafuser.com"\fP +.DE +.PP +Add the following statement to the \f(CWSYSTARTUP.COM\fP file +(or \f(CWSYSTARTUP_V5.COM\fP), read by the +system at startup time. This is necessary to cause the IRAF executables to be +reinstalled in system memory when the system is rebooted. +.DS +\f(CW$ @\fIdisk\fP:[iraf.vms.hlib]install.com\fP +.DE +.PP +While still logged in as SYSTEM, type in the above command +interactively to perform the initial executable image installation. +It may be necessary +to increase the number of system global pages for the command to execute +successfully. If you do not want to install the set of IRAF executables +normally installed at NOAO, edit \f(CW[iraf.vms.hlib]install.lst\fR before +executing \f(CWinstall.com\fR; see \(sc5.2.1. +.PP +Lastly, log out of SYSTEM, and back in as IRAF. Update the date stamp +of a file that is used to ensure that newly updated parameter sets are +used rather than any old versions a user might have around: +.DS +\f(CW$ set default irafhlib +$ copy utime. utime. +$ purge utime. +.DE +.PP +At this point it should be possible for any user to run IRAF. First you +can verify this by using the IRAF account itself; then individual users +should set up their own IRAF startup directory by running \f(CWmkiraf\fR. +The default \f(CWLOGIN.COM\fR in the IRAF +login directory \f(CW[IRAF.LOCAL]\fR will automatically execute +the \f(CWiraf\fR +command to read the \f(CWIRAFUSER.COM\fR file and define the IRAF logicals. +Type \f(CWmkiraf\fR to initialize the IRAF \f(CWuparm\fR directory and create +a new \f(CWLOGIN.CL\fR (answer yes to the \f(CWpurge\fR query, as it is +advisable to delete the contents of the old \f(CWuparm\fR). +Typing \f(CWcl\fR next should cause the CL to run. If the CL runs successfully, +the screen should be cleared (if the terminal is set correctly) and the +message of the day printed. You can then type \f(CWlogout\fR to stop the CL +and return to DCL, or stay in the CL to edit and test the device files +described in the next section. When logging back into the CL (as `IRAF'), +always return to the \f(CW[IRAF.LOCAL]\fR directory before logging in. +A little command \f(CWh\fR (for `home') is defined in the default IRAF +\f(CWLOGIN.COM\fR file for this purpose. + +.NH 2 +Edit the System Dependent Device Files +.PP +The files listed below must be edited before IRAF can be used with the +video terminals, graphics terminals, plotters, printers, magtape devices, +and so on in use at the local site. +.NH 3 +[IRAF.VMS.HLIB]ZZSETENV.DEF +.PP +This file contains the name of the default editor, the default names of all +the standard devices, and a number of other definitions which are not site +dependent and which can therefore be ignored. To be accessible by the IRAF +system, each local device named must also have an entry in the \f(CWTERMCAP\fP +file (terminals and printers) or \f(CWGRAPHCAP\fP file (graphics terminals, +image displays, and plotters) in \f(CW[IRAF.DEV]\fP. +There must also be an "\fIeditor\f(CW.ED\fR" +file in \f(CW[IRAF.DEV]\fR for the named editor; EDT, EMACS, and VI are currently +supported (VI support is approximate). Edit the quoted value in the +following entries to change the defaults. Sample values are shown. +.DS +\f(CWset editor = "vi" +set printer = "imagen" +set terminal = "vt640" +set stdgraph = "vt640" +set stdimage = "iism70l" +set stdplot = "versatec"\fR +.DE +For example, you may wish to change the default editor to "\f(CWedt\fR", +the default printer to "\f(CWvmsprint\fR", +the default image display to "\f(CWiism75\fR", +and the default terminal to "\f(CWvt100\fR". +Note that only a limited number of image displays is currently supported. +Most video terminals, graphics terminals, and plotters are already supported +by the current system. If you have no device in a given class, you may +wish to set the default to a nonexistent name, to generate a meaningful +error message if someone should try to access it (e.g. \f(CWset stdimage = +"nosuchdev"\fR). +.NH 3 +[IRAF.DEV]DEVICES +.PP +This file contains a list of the allocatable devices (primarily tape drives) +for the local system. It should be obvious how to change it by reading the +comments in the file and studying the current values, which are for our system. +By convention drives are assigned the logical names \f(CWmta\fP, \f(CWmtb\fP, +and so on. The "\f(CWmt\fP" part is \fIrequired\fP for a magtape device. +Note that in a VMS cluster where all nodes access the same version +of IRAF, the tape drives for all systems must be defined in this one file, +even though an individual drive may not be accessible on all nodes. +.NH 3 +[IRAF.DEV]TERMCAP +.PP +There must be entries in this file for all video terminal, graphics terminal, +and printer devices you wish to access from IRAF. +The printer is easy, since the +"\f(CWvmsprint\fP" entry provided should work on any VMS system. +To prepare entries for other devices, simply copy the "\f(CWvmsprint\fP" +entry and change the queue name from \f(CWSYS$PRINT\fR to the name of the queue +for the new printer.\(dg +.FS +\(dgIf the printer or plotter device is on a remote node which is not +clustered with +the local node but which is accessible via DECNET, IRAF networking must be +used to access the remote device. IRAF networking is also frequently used +to access devices on non-VMS (e.g., UNIX) nodes. See Appendix C or +contact us for assistance +to help configure your system for IRAF networking. +.FE +Any number of these entries may be placed in the termcap file, +and there can be multiple entries or aliases for each device. +If you have a new terminal which has no entry in the termcap file +provided, a new entry will have to be added (termcap is widely used, +so it is highly likely that someone somewhere will already have written it). +A copy of the UNIX manual page documenting the termcap database is included +with the installation kit +in case you need to construct a new termcap entry for some device. Local +additions should be placed at the top of the file to make it easier to merge +the changes into a future IRAF release. +.NH 3 +[IRAF.DEV]GRAPHCAP +.PP +There must be entries in this file for all graphics terminals, batch plotters, +and image displays accessed by IRAF programs. Many graphics terminals are +already supported; page the file to determine if entries are already available +for the graphics terminals in use at your site, before attempting to write a +new one. The IRAF file \f(CWsys$gio/doc/gio.hlp\fR contains a description of +the graphcap database and instructions for adding an entry for a new device. +A printed copy of this document is available upon request, however once IRAF +is up you may find it easier to generate your own copy using \f(CWhelp\fP +(the document is some 60 pages long), as follows: +.DS +\f(CWcl> cd sys$gio/doc +cl> help gio.hlp fi+ | lprint\fP +.DE +The manual page for the \f(CWshowcap\fP and \f(CWstty\fP tasks should also be +printed since these +utilities are useful for generating new graphcap entries. +More focused documentation will be available eventually. +Telephone consultation via the IRAF Hotline is available for those +who need it. We ask that new graphcap entries be sent back to us so +that we may include them in the master graphcap file for other sites +to use. + +.NH 3 +IRAF Networking +.PP +The \f(CWdev\fP directory also contains the files (\f(CWHOSTS\fP, \f(CWHOSTLOGIN\fP, +and \f(CWUHOSTS\fP), which are used by the IRAF networking software. +Sites which have a local TCP/IP based network can enable IRAF networking +by editing these files, substituting the hostnames and network +addresses of the machines in the local network for the entries currently +in the files, and by installing IRAF on the other nodes (or enough of IRAF +to run the IRAF kernel server). It does not matter what native operating +system runs on the remote nodes, so long as it runs IRAF as well. +.PP +We also provide limited support for DECNET based networking, but the current +system as distributed must be relinked before DECNET networking can be used. +Appendix C is included with notes on steps to be taken to implement DECNET +networking, which should work in most cases. Be warned that only TCP/IP or +DECNET style networking can be implemented, but not both. +As this capability is still under development, please contact the Hotline for +advice if you wish to use the IRAF DECNET interface. + +.NH +Updating an Existing IRAF Installation +.PP +Skip to \(sc4 if you have just completed the initial IRAF installation. +This section is for sites upgrading to a new version of IRAF. +.PP +Updating is very similar to the initial installation (\(sc2). +The main difference is that material which has been added to the site +dependent files since the initial installation should be saved and then +merged back into the generic system from the distribution tape. +The typical update process is summarized in the following steps and detailed +further below: +.RS +.IP \(bu +Save any site-specific files. +.IP \(bu +Delete the old system. +.IP \(bu +Restore the new system to disk from the distribution tape or network archive. +.IP \(bu +Merge contents of saved site-specific files into new system. +.IP \(bu +Relink the system if necessary. +.IP \(bu +Update any "installed" images, the \f(CW\fP file, etc. +.RE +.PP +Variations on this basic procedure are possible and may be preferred at +some sites. For example, sites which make heavy use of IRAF and which have +sufficient disk space may wish to install the new version of the system as +a separate version on disk, e.g., calling the new version of the system +the new `IRAF' and keeping the old version around as `IRAFO'. At NOAO we +maintain three separate versions of the system, IRAF (the current default user +system), IRAFO (the old system, for backup), and IRAFX (the developmental +system). Sites which wish to maintain multiple versions of the system +should beware that only one version of the system can use the shared library, +due to global section name conflicts. For efficiency reasons the default +user version of the system `IRAF' should use the shared library. +The remaining versions of the system must be relinked (\(sc5.1.9) to keep +them from erroneously trying to use the shared library from a different +release of IRAF. + +.NH 2 +Save Locally Modified Files \(dg +.FS +\(dgNOTE: Even if you had not modified the pre-2.8 \f(CW[iraf.local]\fR +directory, you may want to save it. +If you are installing IRAF 2.8 for the first time, with an earlier +version of the system already present, it may be \fIvery\fP important that you +preserve the \f(CW[iraf.local]\fP directory, as a number of things have changed, +and certain \f(CWlocal\fP tasks that were present in earlier releases are no +longer supported in the standard system (e.g. \f(CWdsttoi, itodst, peritek, +grinnell\fP tasks). This is not necessary if you do not plan to use these +unsupported tasks from the pre-2.8 \f(CWlocal\fP directory. +.FE + +.PP +Login as IRAF. +Ordinarily the only directories containing files you may wish to save are +\f(CWdev\fP, \f(CWhlib\fP, and \f(CWlocal\fP. +The safest and easiest way to do this is to save the entire contents of those +directories. For example: +.DS +\f(CW$ set default [iraf] +$ rename dev.dir,local.dir,[.vms]hlib.dir [\fIdirectory\fP]\fP +.DE +This would physically move (not copy) the \f(CWdev\fP, \f(CWlocal\fP, and +\f(CWhlib\fP directories to the named directory, which must be on the same +disk device as \f(CW[IRAF]\fP. Many variations on this are possible. +The destination directory should be somewhere \fIoutside\fP the \f(CW[IRAF...]\fP +directory tree, else it may get deleted when we delete the old system, below. + +.NH 2 +Read the Distribution Tape or Tapes +.PP +Having temporarily preserved all the locally modified files, it is now +time to delete the old system and read in the new one. If you are +the cautious (prudent?) type you may wish to first preserve the entire +existing IRAF system on a backup tape (e.g. if something were to have +happened to the distribution tape en route). Using only the standard +VMS utilities, the old system may be deleted as follows (assuming IRAF +owns all the files in \f(CW[IRAF...]\fP). +.DS +\f(CW$ set default [iraf] +$ delete [...]*.*;* /nolog/noconfirm +$ set protection=(owner:wd) [...]*.*;* +$ delete [...]*.*;* /nolog/noconfirm + \fP(repeat \f(CWdelete\fR command with until done) +.DE +.LP +It is normal for the \f(CWdelete\fP command shown to generate lots of messages +during execution warning that it cannot delete directories because they are +not yet empty. When the command finally executes without any warning messages +this means the directory tree has been fully deleted. +.LP +Now read the new distribution tape(s); it is important that this be done +from the IRAF account, so the ownership and protections will be correct. +.DS +\f(CW$ mount/foreign \fItape\f(CW: +$ set default \fIdisk\f(CW:[iraf] +$ backup/rew \fItape\f(CW:iraf.bck/select=[iraf...] [...]\fP +.DE +.LP +Instead of explicitly deleting the old system it is possible to read the +distribution tape with \f(CWBACKUP/REPLACE\fP, but this really isn't any +faster since a delete of each existing file is implied, and for +those files or directories that have been renamed in the new release, junk +files or directories will be left behind. + +.NH 2 +Merge Saved Files Back Into the New System +.PP +You can either merge the contents of locally modified files saved from +the previous installation into their counterparts in the new system, or edit +the new ones from scratch. Whichever is easier depends on how much editing +you had to do in the first place, which probably depends upon the complexity +of your local computer network and the number of peripheral devices. +Any of the site configuration files might be modified in the distributed +system from version to version of IRAF, so in general one cannot simply +replace such a file with the one that was saved. +.PP +Merging means inspecting the two files (newly distributed vs. its +saved counterpart) for differences, and deciding how to update the new +file with local device names, directory pathnames, etc. +The VMS \f(CWDIFFERENCES\fP utility may or may not be useful for this, +depending on how much a file has changed, and how extensively it +was modified locally. One thing that is a big help is to keep track of +all local changes made to the standard system in a local "notes" file; +when the next system update occurs or when the installation is repeated on +another cpu at the local site, one can then go down the list and make all +the same changes to the newly installed system. By convention, that file +would be called \f(CWnotes.\fImysite\fR, in the \f(CW[iraf.local]\fR directory. +.KS +.TS +center; +ci ci +l l. +directory files +.sp +\f(CWdev devices, graphcap, termcap, devices.hlp \fRif present +\f(CWhlib irafuser.com, install.lst\fR\(dg\f(CW, zzsetenv.def, login.cl +\f(CWhlib/libc iraf.h (\(-> sys$library:iraf.h +\f(CWlocal \fR(see Appendix B) +.TE +.KE +.FS +\(dgSee \(sc5.2.1; if you are just now upgrading to IRAF 2.8, your old file +will still be \f(CWinstall.com\fR, but you will want to edit only the new +\f(CWinstall.lst\fR. +.FE +.PP +The files which must be edited, via a diff/merge operation on the saved +files or otherwise, are summarized in the table above. +If you have added packages or tasks of your own to IRAF in versions prior +to V2.8, you will probably no longer want to install them under the +\f(CW[iraf]\fP directory tree, as facilities are now available for external +layered packages; see \(sc5.1.4. This may be deferred until the system is +up and running if desired. The \f(CW[iraf.local]\fR directory is covered in +Appendix B and in \(sc5.1.5. + +.NH 2 +Relink If Necessary +.PP +If you received a fully binary distribution of VMS/IRAF and you are not +running an old version of VMS, you do not need to relink and may proceed +to the next section. See \(sc5.1.9 for further information on relinking the +system. + +.NH 2 +Update VMS +.PP +These next operations require system privileges, so login as SYSTEM. +Perform the following series of operations: +.RS +.IP \(bu +The \f(CW\fP file (\f(CW[iraf.vms.hlib.libc]iraf.h\fP) may have +changed in the new version of the system, +so it should be recopied into the VMS system library \f(CWsys$library\fP +after editing HOST, IRAF, and TMP for local pathnames as described in \(sc2.3.3. +.IP \(bu +The \f(CWinstall.com\fP procedure was changed at version 2.8 to allow for simple +updating of the installed files. If you are already running IRAF 2.8 or later, +and are now installing an even newer version, +simply replace your old version of \f(CWinstall.lst\fP and re-run +\f(CWinstall.com\fP. [Otherwise, if you have been running a version of IRAF prior +to 2.8, then you should not +replace your old version of \f(CWinstall.com\fP, but instead compare the +set of executables you had installed in it to those in the new +file \f(CWinstall.lst\fP. +This latter file contains a list of all of the IRAF executables. +Files which are \fInot\fP to be installed should be commented out, +using a "!" at +the beginning of the line. This list of installed files should agree with +those from your old \f(CWinstall.com\fP.] Make sure that nobody on the system is +running IRAF, and thereby locking the old IRAF executables, and then execute +the new \f(CWINSTALL\fP procedure. This will clear away +the old installed executables +and install the new ones, paying as much attention as possible to clearing +the global page structures. +.RE +.PP +In a VMS cluster, the shared images must be deinstalled and +reinstalled on all nodes in the cluster which share the same version of IRAF. +These steps are as discussed in \(sc5.2.1; please refer to that +section for additional information. +.PP +Lastly, logged in as IRAF, update the date stamp +of a file that is used to ensure that newly updated parameter sets are +used rather than any old versions a user might have around: +.DS +\f(CW$ set default irafhlib +$ copy utime. utime. +$ purge utime. +.DE + +.NH +Testing a Newly Installed or Updated System +.PP +Before testing a newly installed or upgraded system it is wise to read the +\fICL User's Guide\fP, the revisions notes, and the list of known bugs, +if one has not already done so. Before starting the CL you should +do what a regular user would do, i.e., run \f(CWmkiraf\fP to initialize +the IRAF environment, and then edit the \f(CWlogin.cl\fP file created by +\f(CWmkiraf\fP as desired. Any modifications you wish to preserve across +another \f(CWmkiraf\fP should be placed into the +optional \f(CWloginuser.cl\fP file +to avoid having to edit the \f(CWlogin.cl\fP file. (The \f(CWloginuser.cl\fR +file can have the same kinds of commands in it as the +template login.cl, but \fImust\fR have the statement \f(CWkeep\fR as the last +line.) +.DS +\f(CW$ set default [iraf.local] +$ mkiraf\fP +.DE +.LP +Once the IRAF environment is configured one need only enter the command +`\f(CWcl\fP' to start up the CL. After a bit IRAF should print the message of +the day and type out the root IRAF menu, then issue the "\f(CWcl> \fP" prompt +indicating that it is ready for the first command. +This assumes that the `\f(CWiraf\fP' command is executed in the \f(CWLOGIN.COM\fP +file at login time; if this is not the case, the command `\f(CWiraf\fP' must +first be entered from VMS +to define \f(CWcl\fP and the other VMS logical names and symbols used by IRAF. +.sp +[Important Note: any users wishing to execute IRAF tasks in VMS batch +queues \fImust\fP issue the `\f(CWiraf\fP' command inside their +\f(CWlogin.com\fP, prior to any "\f(CWif f$mode().nes."INTERACTIVE" then +exit\fR" command, otherwise critical IRAF logical names will be undefined.] +.DS +\f(CW$ cl\fP +.DE +.LP +Once in the CL, you will probably have magtape and printer access, are likely +to have graphics terminal access, and very possibly will not have either +image display access or graphics plotter access. If the graphics terminal +capability is ready the next step is to run the IRAF test procedure to +verify that all is working well, as well as try out a few of the many tasks +in the system. If the graphics terminal is not up yet, there is probably +no point in running the test procedure. To run the test procedure, read +the documentation in the \fIIRAF User Handbook\fP, Volumn 1A, and follow the +instructions therein. You may also wish to run some of the benchmarks +described in the benchmarks paper included with the installation materials, +to make sure that your VMS system (user quotas and working set) is configured +properly for efficient execution of IRAF. + +.NH +System Maintenance +.NH 2 +Software Management +.NH 3 +Layered software support +.PP +An IRAF installation consists of the \fBcore system\fP and any number of +\fBexternal packages\fP, or \fBlayered software products\fP. As the name +suggests, layered software products are layered upon the core IRAF system. +Layered software depends upon the core system for all of its functionality +and is portable to any computer which already runs IRAF. Any number of +layered products can be combined with the core system to produce the IRAF +system used at a specific site. Due to disk space limitations it is likely +that a given site will not wish to have all the available layered software +products installed and on line at any one time. +.PP +The support provided for layered software is essentially the same as that +provided for maintaining the core system itself. Each "external package" +(usually this refers to a tree of packages) is a system in itself, similar +in structure to the core IRAF system. Hence, there is a LIB, one or more BINs, +a HELP database, and all the sources and runtime files. A good example of +an external package is the NOAO package. Except for the fact that NOAO +happens to be rooted in the \f(CWiraf\fP directory, NOAO is equivalent to +any other layered product, e.g., STSDAS, PROS, CTIOLOCAL, KPNOLOCAL, etc. +Other layered products should be rooted somewhere outside the \f(CW[IRAF]\fR +directory tree to simplify updates. + +.NH 3 +Software management tools +.PP +IRAF software management is performed with a standard set of tools, +consisting of the tasks in the SOFTOOLS package, plus the host system +editors and debuggers. Some of the most important and often used tools for +IRAF software development and software maintenance are the following. +.sp +.RS +.IP \f(CWmkhelpdb\fP 20 +Updates the HELP database of the core IRAF system or an external package +installed in \f(CWhlib$extern.pkg\fR. +The core system, and each external package, has its own help database. +The help database is the machine independent file \f(CWhelpdb.mip\fP in the +package library (LIB directory). The help database file is generated with +\f(CWmkhelpdb\fP by compiling the \f(CWroot.hd\fP file in the same directory. +.IP \f(CWmkpkg\fP 20 +The "make-package" utility. Used to make or update package trees. +Will update the contents of the current directory tree. When run at +the root iraf directory, updates the full IRAF system; when run at the +root directory of an external package, updates the external package. +Note that updating the core IRAF system does not update any external +packages (including NOAO). When updating an external package, the +package name must be specified, e.g., "\f(CWmkpkg -p noao\fP", and the command +issued within the package directory, not from the IRAF root. +.IP \f(CWrmbin\fP 20 +Descends a directory tree or trees, finding and optionally listing or +deleting all binary files therein. This is used, for example, to strip +the binaries from a directory tree to leave only sources, to force +\f(CWmkpkg\fP to do a full recompile of a package, or to locate all the +binary files for some reason. IRAF has its own notion of what a binary +file is. By default, files with the "known" IRAF virtual file extensions +(.a, .o, .e, .x, .f, .h etc.) are classified as binary or text +(machine independent) files immediately, +while a heuristic involving examination of the file data +is used to classify other files. Alternatively, a list of file extensions +to be searched for may optionally be given. +.IP \f(CWrtar,wtar\fP 20 +These are the portable IRAF tarfile writer (\f(CWwtar\fP) and reader +(\f(CWrtar\fP) programs. These tasks produce archives compatible with +the UNIX \f(CWtar\fP program. In addition they +can move only the machine independent or source files +(\f(CWwtar\fP, like \f(CWrmbin\fP, can discriminate between machine +generated and machine independent files). A tarfile written on a VMS/IRAF +system has the files blank padded, but \f(CWrtar\fP when used on a UNIX +system will strip the trailing blanks by default. +.IP \f(CWxc\fP 20 +The X (SPP) compiler. This is analogous to the VMS \f(CWFORTRAN\fP except +that it can compile "\f(CW.x\fR" or SPP source files, knows how to link with the +IRAF system libraries and the shared library, knows how to read the +environment of external packages, and so on. +.RE +.sp +.PP +The SOFTOOLS package contains other tasks of interest, e.g., a program +\f(CWmktags\fP for making a tags file for the \f(CWvi\fP editor, a HELP +database examine tool, and other tasks. Further information on these +tasks is available in the online HELP pages. + +.NH 3 +Modifying and updating a package +.PP +IRAF applications development (including revisions to existing programs) +is most conveniently performed from within the IRAF environment, since +testing must be done from within the environment. The usual development +cycle is as follows. This takes place within the \fIpackage directory\fP +containing all the sources and mkpkg-files for the package. +.RS +.IP \(bu +Edit one or more source files. +.IP \(bu +Use \f(CWmkpkg\fP to compile any modified files, or files which include a +modified file, and relink the package executable. +.IP \(bu +Test the new executable. +.RE +.PP +The \f(CWmkpkg\fP file for a package can be written to do anything, +but by convention the following commands are usually provided. +.sp +.RS +.IP "\f(CWmkpkg\fP" 20 +Same as \f(CWmkpkg relink\fP below. +.IP "\f(CWmkpkg libpkg.a\fP" 20 +Updates the package library, compiling any files which have been modified +or which reference include files which have been modified. Private package +libraries are intentionally given the generic name \f(CWlibpkg.a\fP to +symbolize that they are private to the package. +.IP "\f(CWmkpkg relink\fP" 20 +Rebuilds the package executable, i.e., updates the package library and +relinks the package executable. By convention, this is the file +\f(CWxx_foo.e\fP in the package directory, where \fIfoo\fP is the +package name. +.IP "\f(CWmkpkg install\fP" 20 +Installs the package executable, i.e., renames the \f(CWxx_foo.e\fP +file to \f(CWx_foo.e\fP in the global BIN directory for the system +to which the package \fIfoo\fP belongs. +.IP "\f(CWmkpkg update\fP" 20 +Does everything, i.e., a \fIrelink\fP followed by an \fIinstall\fP. +.RE +.sp +.PP +If one wishes to test the new program before installing it one should do +a \fIrelink\fP (i.e., merely type "mkpkg" since that defaults to relink), +then run the host system debugger on the resultant executable. The process +is debugged standalone, running the task by typing its name into the +standalone process interpreter. The CL task \f(CWdparam\fP is useful +for dumping a task's parameters to a text file to avoid having to answer +innumerable parameter queries during process execution. If the new program +is to be tested under the CL before installation, a \fItask\fP statement +can be interactively typed into the CL to cause the CL to run the "xx_" +version of the package executable, rather than the old installed version. +.PP +When updating a package other than in the core system, the \fB-p\fP flag, +or the equivalent \f(CWPKGENV\fP logical name, \fImust\fP be used +to indicate the system or layered product being updated. For example, +"\f(CWmkpkg -p noao update\fP" would be used to update one of the packages +forming the NOAO system of packages. +.PP +The CL \fBprocess cache\fP can complicate debugging and testing if one +forgets that it is there. Recall that when a task is run under the CL, +the executing process remains idle in the CL process cache following +task termination. If a new executable is installed while the old one +is still in the process cache, the \f(CWflprcache\fP command must be +entered to force the CL to run the new executable. If an executable is +currently running, either in the process cache or because some other +user is using the program, it may not be possible to set breakpoints +under the debugger. +.PP +The \fBshared library\fP can also complicate debugging, although for most +applications-level debugging the shared library is transparent. If it +is necessary to debug IRAF system libraries, contact the IRAF hotline +for assistance. +.PP +A full description of these techniques is beyond the scope of this manual, +but one need not be an expert at IRAF software development techniques to +perform simple updates. Most simple revisions, e.g., bug fixes or updates, +can be made by merely editing or replacing the affected files and typing +.DS +\f(CWcl> mkpkg update\fP +.DE +plus maybe a \f(CWflpr\fP if the old executable is still sitting idle +in the process cache. + +.NH 3 +Installing and maintaining layered software +.PP +The procedures for installing layered software products are similar to those +used to install the core IRAF system, or update a package. +Layered software may be distributed in source only form, or with binaries. +The exact procedures to be followed +to install a layered product will in general be product dependent, and should +be documented in the installation guide for the product. +.LP +In brief, the procedure to be followed should resemble the following: +.RS +.IP \(bu +Create the root directory for the new software, somewhere outside the +IRAF directories. +.IP \(bu +Restore the files to disk from a tape or network archive distribution file. +.IP \(bu +Edit the core system file \f(CWhlib$extern.pkg\fP to "install" the new +package in IRAF. Note that any \f(CW$\fR in a VMS pathname should be +escaped with a backslash as in some of the examples. +This file is the sole link between the IRAF core system +and the external package. +.IP \(bu +Configure the package BIN directory or directories, either by restoring +the BIN to disk from an archive file, or by recompiling and relinking the +package with \f(CWmkpkg\fP. +.RE +.LP +As always, there are some little things to watch out for. +When using \f(CWmkpkg\fP on a layered product, you must give the name +of the system being operated upon, e.g., +.DS +\f(CWcl> mkpkg -p foo update\fP +.DE +where \fIfoo\fP is the system or package name, e.g., "noao", "local", etc. +The \fB-p\fP flag can be omitted by defining \f(CWPKGENV\fP as a VMS logical +name, but this only works for updates to a single package. +.PP +Once installed and configured, a layered product may be deinstalled merely +by archiving the package directory tree, deleting the files, and commenting +out the affected lines of \f(CWhlib$extern.pkg\fP. With the BINs already +configured reinstallation is a simple matter of restoring the files to disk +and editing the \f(CWextern.pkg\fP file. + +.NH 3 +Configuring a custom LOCAL package +.PP +Anyone who uses IRAF enough will eventually want to add their own software +to the system, by copying and modifying the distributed versions of programs, +by obtaining and installing isolated programs written elsewhere, or by writing +new programs of their own. A single user can do this by developing software +for personal use, defining the necessary \fItask\fP statements etc. +to run the software in the personal \f(CWlogin.cl\fP file. To go one step +further and install the new software in IRAF so that it can be used by +everyone at a site, one must configure a \fBcustom local package\fP. +.PP +The procedures for configuring and maintaining a custom LOCAL package are +similar to those outlined in \(sc5.1.4 for installing and maintaining +layered software, since a custom LOCAL will in fact be a layered software +product, possibly even something one might want to export to another site +(although custom LOCALs often contain non-portable or site specific software). +.PP +To set up a custom LOCAL, start by making a local copy of the +\fBtemplate local\fP package that comes with the distributed system +and editing \f(CWhlib$extern.pkg\fR to make the location of the new +package known. +If you make a source only \f(CWwtar\fR or \f(CWBACKUP\fR archive +of \f(CWiraf$local\fR and install +it as outlined in \(sc5.1.3, you will have a custom LOCAL. The purpose +of the template LOCAL is to provide the framework necessary for an external +package; a couple of simple tasks are provided in the template LOCAL +to serve as examples. Once you have configured a local copy of the template +LOCAL and gotten it to compile and link, it should be a simple matter to +add new tasks to the existing framework. + +.NH 3 +Bootstrapping the HSI +.PP +All current IRAF distributions come with the system already bootstrapped, +i.e., the host system interface (HSI) comes with the HSI binary executables +already +built. A bootstrap should not be necessary unless one is doing something +unusual, e.g., installing a bugfix or making some other revision to the HSI. +.PP +A bootstrap is like a full system sysgen, except that it is the host +system interface (kernel and bootstrap utilities) which is compiled and +linked, rather than IRAF itself. The system must be bootstrapped before +a sysgen is possible, since the bootstrap utilities are required to do a +sysgen. The two operations are distinct because only the bootstrap is +machine dependent; everything else works the same on all IRAF systems. +.PP +The bootstrap utilities are required for system maintenance of the main system +and hence must be linked first. However, unless a bug fix or other revision +is made to one of the main system libraries (particularly \f(CWlibos\fR), there +should be no reason for a user site ever to need to bootstrap the system. +The bootstrap utilities are linked with the option \f(CW/NOSYSSHARE\fR, hence +they should run on most versions of VMS. +.PP +The bootstrap utilities are written in C, and the DEC C compiler is required +to compile or link these utilities. The C compiler is \fInot\fR required to +run the prelinked binaries distributed with the system. To recompile and link +the bootstrap utilities, i.e., to "bootstrap" IRAF, enter the commands shown +below. Note that the HSI is always recompiled during a bootstrap; there +is no provision for merely relinking the entire HSI (some individual programs +can however be relinked manually by doing a \f(CWmkpkg update\fR in the program +source directory). +.DS +\f(CW$ set default [iraf.vms] +$ set verify +$ @rmbin.com +$ @mkpkg.com\fR +.DE +.PP +The bootstrap should take 30 to 45 minutes on an unloaded 11/780. +Once the bootstrap utilities have been relinked and installed in \f(CWhlib\fR, +the main system may be relinked. + +.NH 3 +Updating the System Libraries +.PP +Updating the system libraries, i.e., recompiling selected object modules and +inserting them into the system object libraries, is necessary if any system +source files are edited or otherwise modified, as when using the +\f(CWmkttydata\fR utility program to cache new termcap or graphcap device +entries, or switching from TCP/IP to DECNET networking. +.PP +The system libraries may be updated either from within the IRAF CL, or from +DCL. For example, from within DCL: +.DS +\f(CW$ set def [iraf] +$ mkpkg syslibs \fR[\fPmathlibs\fR]\fR +.DE +The brackets around \f(CWmathlibs\fR just mean "optional"; do not actually +include the brackets if you need to rebuild the math libraries. +This command will run the \f(CWmkpkg\fR utility, which will update each system +library in turn, descending into the tree of source directories and checking +the date of each object module therein against the dates of the source files +and dependency files used to produce the object module, and recompiling any +object modules which are out of date. In the worst case, e.g., if the +system libraries have been deleted, the entire VOS (virtual operating system) +will be recompiled. If it is known that no changes have been made to the +math library source files, the optional \f(CWmathlibs\fR argument may be +omitted to save some time. + +.NH 3 +Relinking the IRAF Shared Library +.PP +The IRAF shared library (\f(CW[IRAF.BIN]S_IRAF.EXE\fR) is constructed by +linking the contents of the four main IRAF system libraries \f(CWLIBEX\fR, +\f(CWLIBSYS\fR, \f(CWLIBVOPS\fR, and \f(CWLIBOS\fR. Hence, the system libraries +must exist and be up to date before linking the shared library. The shared +library must be installed in \f(CWbin\fR before it can be used to link any +applications programs. At present, the shared library does not use +transfer vectors, hence the full system must be relinked following any +changes to the shared library. Note that since the shared library is +normally installed in system memory, all installed IRAF images should be +deinstalled and later reinstalled whenever the shared library is rebuilt. +IRAF will not be runnable while this is taking place. +.PP +In the current release of IRAF (V2.8) the procedure for building the shared +library has not yet been integrated into the automatic system generation +procedure. Furthermore, utility tasks in the main IRAF system are currently +used to build the shared library, so it is necessary to have at least part +of the main system functioning before the shared library can be built. These +problems (and the transfer vector problem) will be fixed in a future release +of VMS/IRAF. +.PP +The shared library is rebuilt from within a running IRAF system that provides +at a minimum the three executables \f(CWCL.EXE\fR, \f(CWX_SYSTEM.EXE\fR, and +\f(CWX_LISTS.EXE\fR. If these executables do not yet exist or are +not runnable, +rebuild them as follows. Note the use of the \f(CW-z\fR link flag to link +the new executables without the shared library. +.DS +\f(CW$ set default [iraf.pkg.cl] +$ mkpkg update lflags=-z +$ set default [iraf.pkg.system] +$ mkpkg update lflags=-z +$ set default [iraf.pkg.lists] +$ mkpkg update lflags=-z\fR +.DE +.LP +Now login to the CL and proceed to the directory \f(CWhlib$share\fR, which +contains the code used to build the shared library. +.DS +\f(CW$ set default [iraf.local] +$ cl + \fR(cl starts up...)\fP +cl> cd hlib$share\fR +.LP +.DE +The following commands will rebuild the shared library and install it in +\f(CWbin\fR. This takes ten minutes or so. +.DS +\f(CWcl> cl < makeshare.cl + \fR(takes a while)\fP +cl> mkpkg install +cl> purge +cl> logout\fR +.DE +.PP +The system libraries can be updated (\(sc5.1.7) and the shared library rebuilt +while IRAF is in use by normal users, however as soon as the command +\f(CWmkpkg install\fR is executed (moving the new \f(CWS_IRAF.EXE\fR to +\f(CWbin\fR) execution of normal user programs is at risk and one should +kick all IRAF users off the machine and deinstall any installed IRAF images. +The system may now be relinked and the newly linked shared library and images +reinstalled, after which the system is ready for normal use again. + +.NH 3 +Relinking the Main IRAF System +.PP +The following DCL commands may be entered to relink the main IRAF system, +installing the newly linked executables in \f(CWbin\fR. Note that any +IRAF executables that have been installed in system memory must be +deinstalled and reinstalled (\(sc5.2.1) following the relink. +.DS +\f(CW$ set default [iraf] +$ mkpkg update\fR +.DE +.PP +The command shown causes the full system to be relinked (or recompiled and +relinked if any files have been modified) using the default compile and +link switches defined in the global \f(CWmkpkg\fR include file \f(CWmkpkg.inc\fR +in \f(CWhlib\fR. Any system wide changes in how the system is generated should +be implemented by editing the contents of this file. For example, the default +file supplied with the system includes the following line: +.DS +\f(CW$set LFLAGS = "" # default XC link flags\fR +.DE +This switch defines the switches to be passed to the HSI bootstrap utility +program \f(CWxc\fR to link the IRAF executables (no switches are given, hence +the default link action will be taken). +The switch \f(CW-z\fR may be included in the \f(CWxc\fR command line to link +an executable directly against the system object libraries, rather than using +the shared library. Hence, to relink IRAF without using the IRAF shared +library (as is necessary for all but one system when there are multiple +versions of IRAF simultaneously installed on the same machine) we would +change the definition of \f(CWLFLAGS\fR as follows: +.DS +\f(CW$set LFLAGS = "-z" # default XC link flags\fR +.DE +.PP +A full system relink takes approximately 30 minutes, or significantly less +if the shared library is used. A full system compile and relink takes 9-24 +hours depending upon the host system. +.PP +The above procedure only updates the core IRAF system. To update a layered +product one must repeat the sysgen process for the layered system. +For example, to update the NOAO package: +.DS +\f(CW$ set default [iraf.noao] +$ mkpkg -p noao\fP +.DE +Layered systems are +completely independent of one another and hence must be updated separately. + +.NH 2 +Tuning Considerations +.PP +There are a number of things that can be done to tune VMS/IRAF for a +particular host system: +.sp +.RS +.IP \(bu +Install the executables to permit shared memory. +.IP \(bu +Render the large runtime files contiguous to increase i/o efficiency. +.IP \(bu +Precompile selected \f(CWTERMCAP\fP and \f(CWGRAPHCAP\fP entries. +.IP \(bu +Strip the system to reduce disk consumption. +.RE + +.NH 3 +Installing Executable Images +.PP +The standard distribution of VMS/IRAF is configured to use a shared library +for the bulk of the IRAF runtime system code. Use of this shared library +considerably reduces the disk requirements of the system, while reducing +runtime system memory usage and process pagein time, and speeding up process +links during software development. +.PP +If the goal of minimizing physical memory utilization is to be achieved +when running IRAF, it is essential that the IRAF shared library be "installed" +in VMS system shared memory. Further memory savings through memory sharing +can be achieved if some of the more commonly used IRAF executables are also +installed. This becomes increasingly important as the number of IRAF users +increases, but some memory savings may result even if there is only one user, +since a single user may spawn batch jobs. Hence, the shared library +\f(CWs_iraf.exe\fP should always be installed if IRAF is used at all, and +\f(CWcl.exe\fP and \f(CWx_system.exe\fP are used by all IRAF jobs and should +be installed if there is usually at least one IRAF user on the system. +If there are usually several IRAF users on the system \f(CWx_images.exe\fP and +\f(CWx_plot.exe\fP are probably worth installing as well. +.PP +Installation of task images in system shared memory is done with the VMS +\f(CWINSTALL\fP utility, +which requires CMKRNL privilege to execute (also discussed in \(sc2.3.2). +Installation of the IRAF shared library and other task images is most +conveniently +done by executing the \f(CWINSTALL.COM\fP command procedure in \f(CWhlib\fP. +In IRAF 2.8 or later, the list of files to be installed is in +\f(CWinstall.lst\fP. +This file should be reviewed and edited during system installation to +select those images to be installed on the local host. +Then \f(CWINSTALL.COM\fP may be +directly executed to temporarily install the images, but to permanently +install the images the system bootstrap procedure should be modified to +execute the \f(CWINSTALL.COM\fP script (or explicitly install the images by +name) whenever the system is booted. Note that any currently installed +images must be explicitly deinstalled before a new version can be installed +(handled automatically in 2.8 by \f(CWinstall.com, install.lst\fP), +and that the global pages used by an installed image are not actually freed +until any and all processes using those global pages terminate. +.PP +The procedure for installing images will fail if there are insufficient +global pages available in the system (for example, the number of global +pages required to install the shared library in VMS/IRAF V2.8 is about 1062). +If the system has insufficient free global pages to run the \f(CWINSTALL.COM\fP +script one must either increase the number of system global pages (which +requires rebooting the system), or one must edit the \f(CWINSTALL.COM\fP +script to reduce the number of images to be installed. + +.NH 3 +Rendering Large Runtime Files Contiguous +.PP +The speed with which large disk files can be read into memory in VMS can +degrade significantly if the disk is highly fragmented, which causes a +large file to be physically stored in many small fragments on the disk. +IRAF performance as well as VMS system throughput can therefore be improved +by rendering frequently referenced large files contiguous. Examples of +files which it might pay to render contiguous are the executables in +\f(CWbin\fP, all of the runtime files in \f(CWdev\fP, and the large system +libraries in \f(CWlib\fP (this last is only useful to speed software +development, i.e., linking). +.PP +The easiest way to render a file contiguous in VMS is to use +\f(CWCOPY/CONTIGUOUS\fP to copy the file onto itself, and then purge the +old version. Various nonstandard utility programs are available commercially +which will perform this function automatically. The contents of an entire +disk may be rendered contiguous or nearly contiguous by backing up the disk +onto tape and then restoring it onto a clean disk. + +.NH 3 +Precompiling TERMCAP and GRAPHCAP Entries +.PP +Precompilation of a termcap or graphcap entry is a technique used to +speed runtime access of the entry for that device. If the entry is not +precompiled the termcap or graphcap file must be physically opened and +scanned at runtime to read the desired entry. This causes a noticeable +delay of as much as a second when clearing the terminal screen or plotting +a graph, hence it is usually worthwhile to cache the entries for commonly +used video and graphics terminals. It is generally not worthwhile for +printers, plotters, and image displays. +.PP +The system comes with selected termcap and graphcap entries already +precompiled. To see which devices are precompiled, page the cache data files, +\f(CWdev$cachet.dat\fP (for termcap) and \f(CWdev$cacheg.dat\fP (for graphcap). +To cache a different set of entries one must regenerate these files with the +\f(CWmkttydata\fP task in the SOFTOOLS package, and then do a full sysgen relink +with the \f(CWmkpkg\fP utility. Detailed instructions are given in the manual +page for \f(CWmkttydata\fR.\(dg +.FS +\(dg\fBImportant Note\fR: If the system is configured to use the IRAF shared +library (the default), you must update the system libraries (\(sc5.1.7) and +rebuild the shared library (\(sc5.1.8) before relinking the system \(sc5.1.9), +else the changes to the termcap and graphcap cache files will have no effect. +The use of the shared library is peculiar to VMS/IRAF and is not discussed +in the \f(CWmkttydata\fP documentation. +.FE + +.NH 3 +Stripping the System to Reduce Disk Consumption +.PP +If the system is to be installed on multiple cpu's, or on a particularly +small host like a MicroVAX, it may be necessary or desirable to strip the +system of all non-runtime files to save disk space. This is done by deleting +all the program sources and all the sources for the reference manuals and +other printed documentation, but not the online manual pages. A special +utility called \f(CWrmfiles\fP (in the SOFTOOLS package) is provided for this +purpose. It is not however necessary to run \f(CWrmfiles\fP directly to strip +the system. This may be done either from DCL or from within the CL. +.DS +\f(CW$ set default [iraf] +$ mkpkg strip +$ set default [iraf.noao] +$ mkpkg strip\fR +.DE +This will preserve all runtime files, permitting use of the standard runtime +system as well as user software development. Stripping the system +will \fInot\fP, however, permit relinking standard IRAF executables, as +would be required for bug fixes, caching termcap and graphcap entries, or +switching to DECNET networking. +The size of the system (the +figures are for V2.8) is reduced from about 48 Mb (megabytes) to around +25 Mb.\(dg +.FS +\(dg\fRDue to a bug in the stripping files in VMS/IRAF 2.8 not caught +before the distribution tapes were cut, a \f(CWstrip\fR will not +delete quite as many files as it should (a few Mb). +Contact the hotline for help in further stripping the system if this is +necessary. +.FE +We do not recommend stripping the system libraries, as this would preclude +all IRAF related software development or bug fixes, including user written +Fortran programs (IMFORT), and we no longer provide a "\f(CWstripall\fR" +option. + +.NH 2 +VMS Quotas and Privileges Required to Run IRAF +.PP +The only privilege required by IRAF is TMPMBX, which is probably +already standard on your system. Systems with DECNET capabilities should also +give their users NETMBX privilege, although it is not required to run IRAF. +No other privileges are required or useful for normal activities. +.PP +Although privileges are no problem for VMS/IRAF, +it is essential that the IRAF user have sufficient VMS quota, +and that the system tuning parameters be set correctly, +otherwise IRAF will not be able to function well or may not function at all. +If a quota is exceeded, or if the system runs out of some limited resource, +the affected VMS system service will return an error code to IRAF and the +operation will fail (this frequently happens when trying to spawn a connected +subprocess). The current recommended ranges of per-user quotas are summarized +below. +.KS +.TS +center; +ci ci ci +l n n. +quota minimum recommended +.sp +\f(CWBYTLM\fP 20480 30720 +\f(CWPGFLQUOTA\fP 15000 30720 +\f(CWPRCLM\fP 5 10 +\f(CWWSDEFAULT\fP 512 512 +\f(CWWSEXTENT\fP 4096 WSMAX +\f(CWJTQUOTA\fP 2048 2048 +\f(CWFILLM\fP 30 60 +.TE +.KE +.PP +The significance of most of these quotas is no different for IRAF than for +any other VMS program, hence we will not discuss them further here. +The \f(CWPRCLM\fP quota is especially significant for IRAF since an IRAF job +typically executes as several concurrent processes. The \f(CWPRCLM\fP quota +determines the maximum number of subprocesses a root process (user) may have. +Once the quota has been reached process spawns will fail causing the IRAF +job or operation to abort. +.PP +The minimum number of subprocesses a CL process +can have is 1 (\f(CWx_system.e\fP). As soon as a DCL command is executed via +OS escape a DCL subprocess is spawned, and we have 2 subprocesses. +The typical process cache limit is 3, one slot in the cache being used by +\f(CWx_system.e\fP, hence with a full cache we have 4 subprocesses (the user +can increase the process cache size if sufficient quota is available to +avoid excessive process spawning when running complex scripts). It is common +to have one graphics kernel connected, hence in normal use the typical +maximum subprocess count is 5. However, it is conceivable to have up to +3 graphics kernel processes connected at any one time, and whenever a +background job is submitted to run as a subprocess a whole new subprocess +tree is created. Hence, it is possible to run IRAF with a \f(CWPRCLM\fP of +5, but occasional process spawn failures can be expected. Process spawn +failures are possible even with a \f(CWPRCLM\fP of 10 if subprocess type batch +jobs are used (the default), but in practice such failures are rare. +If all batch jobs are run in batch queues it should be possible to work +comfortably with a \f(CWPRCLM\fP of 5-6, but in practice users seem to prefer +to not use the batch queues, except for very large jobs. +.PP +Since IRAF uses memory efficiently the working set parameters do not +seem critical to IRAF, provided the values are not set unrealistically low, +and provided \f(CWWSEXTENT\fP is set large enough to permit automatic growth +of a process working set when needed. Configuring VMS to steal pages from +inactive processes is not recommended as it partially cancels the effect of +the process cache, causing process pagein whenever a task is executed. +It is better to allow at least a minimum size working set to each process. +However, this is not a hard and fast rule, being dependent on individual +system configurations and workloads. +.PP +In addition to sufficient per user authorized quota, the system tuning +parameters must be set to provide enough dynamically allocatable global +pages and global sections to handle the expected load. If these parameters +are set too small, process connects will fail intermittently, usually when +the system load is high. Each subprocess needs about 8 global pages when +activated (IRAF uses global pages and shared memory for interprocess +communications, due to the relatively low bandwidth achievable with the +VMS mailbox facilities). +With IRAF in heavy use (i.e., a dozen simultaneous users) this can easily +reach a requirement for several hundred additional global pages. +Each installed image and subprocess also needs at least one, usually two, +global sections. +Note that the size of the executable found by doing a \f(CWdir/size=all\fP on +\f(CW[iraf.bin]*.exe\fP can be considered an upper bound to the number of pages +needed to install it (if anyone wants to play it safe: typically, it's +about 50-70 percent of this size). Currently, for 2.8, we have CL=324, +S_IRAF=1062, X_SYSTEM=103, X_PLOT=118, and X_IMAGES=789. +The system parameters on our 8600 (which is probably a +worst case example) are currently set to \f(CWGBLPAGES\fP = 12120 +and \f(CWGBLSECTIONS\fP = 230. For every increment of 512 in GBLPAGES, +GBLSECTIONS must be increased by 4. After making any of these changes, we +recommend running AUTOGEN to ensure correct relationships among the +many sysgen parameters. + +.NH 2 +Miscellaneous Notes +.PP +Magtape deallocation will not work properly in VMS/IRAF if the CL is run from +a privileged account such as one that has BYPASS or SYSPRV privilege +(a \f(CWcl> !dismount\fP may +unmount the drive). +.PP +Under VMS 5, the AUTOGEN procedure includes feedback information. +It is worth running the system, with IRAF users, for a couple of weeks +and then re-running AUTOGEN (as detailed in the System Management +documentation) to adjust some of the system parameters (global pages, +various memory structures) for the new work load. +.PP +"If all else fails", e.g. hung tape drives etc. \(em our VMS system manager +recommends kicking everyone +off the system, perhaps even rebooting if it gets desperate, and then +inspecting this Installation Guide again, before calling us. +And please, if you need to call, try to have available the exact text +of any error messages you may have encountered. + +.NH +Interfacing New Graphics Devices +.PP +There are three types of graphics devices that concern us here. +These are the graphics terminals, graphics plotters, and image displays. +.NH 2 +Graphics terminals +.PP +The IRAF system as distributed is capable of talking to just about any +conventional graphics terminal or terminal emulator, using the \f(CWstdgraph\fP +graphics kernel supplied with the system. All one need do to interface to a +new graphics terminal is add new graphcap and termcap entries for the device. +This can take anywhere from a few hours to a few days, depending on one's +level of expertise, and the characteristics of the device. Be sure to check +the contents of the \f(CWdev$graphcap\fP file to see if the terminal is already +supported, before trying to write a new entry. Useful documentation for +writing graphcap entries is the GIO reference manual and the HELP pages for +the \f(CWshowcap\fP and \f(CWstty\fP tasks (see \(sc2.6.4). Assistance with +interfacing new graphics terminals is available via the IRAF Hotline. +.NH 2 +Graphics plotters +.PP +The current IRAF system comes with several graphics kernels used to drive +graphics plotters. The standard plotter interface is the SGI graphics kernel, +which is interfaced as the tasks \f(CWsgikern\fP and \f(CWstdplot\fP in the +PLOT package. Further information on the SGI plotter interface is given in +the paper \fIThe IRAF Simple Graphics Interface\fP, a copy of which is +included with the IRAF installation kit. +.PP +SGI device interfaces for most plotter devices already exist, and adding +support for new devices is straightforward. Sources for the SGI device +translators supplied with the distributed system are maintained in the +directory \f(CW$iraf/vms/gdev/sgidev\fP. +NOAO serves as a clearinghouse for new SGI plotter device interfaces; +contact us if you do not find support for a local plotter device in the +distributed system, and if you plan to implement a new device interface let +us know so that we may help other sites with the same device. +.PP +The older \f(CWNCAR\fP kernel is used to generate NCAR metacode and can be +interfaced to an NCAR metacode translator at the host system level to get +plots on devices supported by host-level NCAR metacode translators. +The host level NCAR metacode translators are not included in the standard +IRAF distribution, but public domain versions of the NCAR implementation for +VMS systems are widely available. A site which already has the +NCAR software may wish to go this route, but the SGI interface will provide +a more efficient and simpler solution in most cases. +.PP +The remaining possibility with the current system is the \f(CWcalcomp\fP kernel. +Many sites will have a Calcomp or Versaplot library (or Calcomp compatible +library) already available locally. To make use of such a library to get +plotter output on any devices supported by the interface, one may copy +the library to the \f(CWhlib\fP directory and relink the Calcomp graphics +kernel. +.PP +A graphcap entry for each new device will also be required. Information on +preparing graphcap entries for graphics devices is given in the GIO design +document, and many actual working examples will be found in the graphcap +file. The best approach is usually to copy one of these and modify it. +.NH 2 +Image display devices +.PP +The current IRAF system does not yet have a well defined and well isolated +device independent image display interface. Work on such an interface is +currently underway; contact the IRAF group at NOAO for further information +on the status of the new display interfaces. Further information on the +image display interfaces currently available may be found in the +\fIIRAF Newsletter\fP. +.PP +Those VMS/IRAF sites that have VAX/VMS workstations running the VWS display +system (e.g. VAXstation) may run the \f(CWNEWUISDISP.EXE\fP +display task directly in \f(CW[IRAF.VMS.UIS]\fP. +This is a standalone IMFORT program, +i.e. it does not communicate with the tasks in the \f(CWtv$display\fP package. +See the file \f(CWnewuisdisp.txt\fP in the same directory for help. +.PP +Sun workstations running \f(CWIMTOOL\fP and \f(CWGTERM\fP may be used as front +ends to VAXes that use the default TCP/IP networking. See the \f(CWimtool(1)\fP +manual pages on the Sun. +.PP +Likewise, workstations running the MIT X window system may also be used as +front ends, using the \fIximage\fP display server \(dg. +.FS +\(dgAt press time for IRAF 2.8, \f(CWximage\fR was only available for X10, +with an X11 version under development. +.FE +This was developed +for IRAF by CfA (SIAO), but is distributed by the IRAF project; a distribution +kit is available upon request. We are looking forward to the release of +X11/NeWS by Sun sometime during 1989, and will provide X11 based versions +of gterm and imtool for Sun/IRAF once a vendor supported version of X11 is +available for the Sun (the X11 versions of imtool and gterm should run on +any manufacturer's X11 based workstation). Contact the hotline for advice. +.PP +Some interfaces for hardware image display devices are also available, +although a general display interface is not yet included in the system. +Only the IIS model 70 and 75 are currently supported by NOAO. Interfaces +for other devices are possible using the current datastream interface, +which is based on the IIS model 70 datastream protocol with extensions +for passing the WCS, image cursor readback, etc. (see the ZFIOGD driver +in \f(CWvms/gdev\fP). This is how all the current displays, e.g., imtool +and ximage, and the IIS devices, are interfaced, and there is no reason +why other devices could not be interfaced to IRAF via the same interface. +Eventually this prototype interface will be obsoleted and replaced by a +more general interface. +.PP +If there is no IRAF interface for your device, the best approach at present is +to use the IMFORT interface and whatever non-IRAF display software you +currently have to construct a host level Fortran or C display program. +The IMFORT library provides host system Fortran or C programs with access +to IRAF images on disk. Documentation on the IMFORT interface is available in +\fIA User's Guide to Fortran Programming in IRAF -- The IMFORT Interface\fP, +Doug Tody, September 1986, a copy of which is included in the IRAF User +Handbook, Volume 1A. If you do not have an existing image display program +into which to insert IMFORT calls, it is not recommended that the +\f(CWtv$display\fR package code be used as a template. +Rather, a standalone image display server should be constructed using the +datastream protocol in the \f(CWvms/gdev/zfiogd.x\fR driver mentioned above +(but that could be a very lengthy job; contact the hotline). +.PP +A few sites may have the Gould IP8400 or IP8500 displays; code for the +Gould is not automatically supplied with VMS/IRAF, and must be requested +separately. The interface is not very satisfactory, but can be used in +a pinch. +(If you are installing IRAF 2.8, the Gould interface has not changed since +version 2.5, so if you have an old version, you will not need to request a +new one.) + +.NH +The IRAF Directory Structure +.PP +A graph of the current full VMS/IRAF directory structure is given at the +end of this document. The main branches of the tree are summarized below. +Beneath the directories shown are some 300 subdirectories, the largest +directory trees being \f(CWsys\fP, \f(CWpkg\fP, and \f(CWnoao\fP. +The entire contents of all directories other than \f(CWvms\fP, \f(CWlocal\fP, +and \f(CWdev\fP are fully portable, and are identical in all installations +of IRAF sharing the same version number. +.DS +\f(CWbin \fP- the IRAF BIN directories +\f(CWdev \fP- device tables (\f(CWtermcap\fP, \f(CWgraphcap\fP, etc.) +\f(CWdoc \fP- assorted IRAF manuals +\f(CWlib \fP- the system library; global files +\f(CWlocal \fP- iraf login directory; locally added software +\f(CWmath \fP- sources for the mathematical libraries +\f(CWnoao \fP- packages for NOAO data reduction +\f(CWpkg \fP- the IRAF applications packages +\f(CWsys \fP- the virtual operating system (VOS) +\f(CWvms \fP- the VMS host system interface (HSI = kernel + bootstrap utilities) +.DE +.LP +The contents of the \f(CWvms\fP directory (host system interface) are +as follows: +.DS +\f(CWas \fP- assembler sources for VMS/IRAF +\f(CWboot \fP- bootstrap utilities (mkpkg, rtar, wtar, etc.) +\f(CWgdev \fP- graphics device interfaces (SGI device translators) +\f(CWhlib \fP- host dependent runtime files +\f(CWmkpkg.com \fP- executed to bootstrap the VMS/IRAF HSI +\f(CWos \fP- OS interface routines (VMS/IRAF kernel) +\f(CWrmbin.com \fP- executed to delete binary files in subdirectories +\f(CWuis \fP- UIS display program for VAX workstations +.DE +.PP +If you will be working with the system much at the system level, it will be +well worthwhile to spend some time exploring these directories and gaining +familiarity with the system. + +.bp +.DS C +\fBAppendix A. Private TMP and IMDIR Directories\fR +.DE +.PP +If local system management policies require that private \f(CWtmp\fP and +\f(CWimdir\fP directories be defined for each user, you can define these +directories for each user as subdirectories of their \f(CWSYS$LOGIN\fP +directory. One way to do this is define \f(CWimdir\fP to be the same as +\f(CWtmp\fP, and modify the definition of \f(CWIRAFTMP\fP in the +\f(CWIRAFUSER.COM\fP file as shown below. +.nf +.sp +\f(CW\s-1 +$! ----------- add these lines to irafhlib:irafuser.com ---------- +$! This block of DCL assigns the logical name IRAFTMP to a subdirectory of +$! the user's VMS login directory. It is necessary to escape the "$" and "[" +$! because they are IRAF filename metacharacters. This block of code +$! should replace the current definition in irafuser.com of IRAFTMP: +$! define/job IRAFTMP TEMPDISK:[IRAFTMP] ! scratch files +$! +$! We assume only one occurrence of "$" or "[". +$! +$ tmpdir = f$logical ("SYS$LOGIN") +$ tmpdir = f$extract (0, f$locate("]",tmpdir), tmpdir) + ".IRAFTMP]" +$ define/job vmstmp 'tmpdir' +$ off = f$locate ("$", tmpdir) +$ tend = f$length (tmpdir) +$ if (off .ne. tend) then - + tmpdir = f$extract (0, off, tmpdir) + "\e$" + f$extract (off+1, tend, tmpdir) +$ off = f$locate ("[", tmpdir) +$ if (off .ne. tend+1) then - + tmpdir = f$extract (0, off, tmpdir) + "\e[" + f$extract (off+1, tend, tmpdir) +$ define/job iraftmp "''tmpdir'"\s0\fR +.sp +In \f(CWirafhlib:login.cl\fR, replace \f(CWU_IMDIR\fR with \f(CWtmp$\fP +.fi +.sp +In \f(CWirafhlib:mkiraf.com\fR, replace the block of statements beginning +"\f(CWimdir_file :=\fR" with the following: +.sp +.nf +\f(CW$ if (f$search ("sys$login:iraftmp.dir") .eqs. "") then - + create/directory vmstmp\fR +.fi + +.bp +.DS C +\fBAppendix B. Upgrading a Pre-IRAF 2.8 \f(CW[iraf.local]\fP Directory\fR +.DE +.PP +If you are installing IRAF 2.8 for the first time on a system which had +an earlier version of IRAF, \fIand\fP you either had your own tasks in +\f(CW[iraf.local]\fP or you want to use the unsupported tasks formerly +distributed in \f(CWlocal\fP (\f(CWdsttoi, itodst, peritek, grinnell\fP), you +will need to change a few things. If you did not make local additions or +use those unsupported tasks, or if you are installing a later version of IRAF +than 2.8, you may skip the rest of this section. +.PP +Starting at IRAF 2.8, there is support +for external layered packages, which will largely free you from having to merge +local additions into future updates. The new \f(CWlocal\fP directory is +set up as a \fItemplate\fP external package, and it is best that it remain +that way. True local additions (plus the former, unsupported tasks mentioned +above) are best placed in a directory of your choice outside the IRAF tree. +The external layered package mechanism is discussed in \(sc5.1.4 and +5.1.5, to which you should refer for background information now, +prior to completing this section. The instructions below are intended as +a guide and may not be enough for all sites, depending on the complexity of +the local additions. The \f(CW[iraf.noao]\fR directory may be used as an +additional guide. This all sounds a bit complex, but it will be worth it +because it only need be done once, and all you will need to do in future +IRAF releases is edit \f(CWhlib$extern.pkg\fR to hook up your local package. +.PP +Briefly, you will need to create your own \f(CWlocal\fP directory, preferably +outside the IRAF tree, e.g. \f(CW[kpnolocal]\fR, (\fIyourlocal\fR used for +explanatory purposes below). +Copy the \fInew template\fR \f(CW[iraf.local]\fP directory into it: +.DS +\f(CW$ set default [\fIyourlocal\f(CW] +$ backup [iraf.local...] [...] +$ delete login.*;*, bugs.*;*, notes.*;*, irafks.*;* +$ delete $forward.;*, *readme.;*, telinit.;*, [.uparm]*.*;* +$ set protection=(owner:wd) uparm.dir +$ delete uparm.dir;*\fR +.DE +This is a summary of the steps needed to upgrade a pre-2.8 local directory +to use the new layered package mechanism; an example follows: +.RS +.IP \(bu +In what follows it is assumed you want your new package to be known only +as \f(CWlocal\fR; the pathname for \f(CWlocal\fR defined +in \f(CW[iraf.vms.hlib]extern.pkg\fR will take care of its location. +.IP \(bu +Copy the source, parameter, and object files and libraries from your +saved copy of the +old \f(CW[iraf.local]\fR directory tree (as saved in \(sc3.1) +into \f(CW[\fIyourlocal\f(CW.src]\fR or subdirectories, and any executables +into \f(CW[\fIyourlocal\f(CW.bin]\fR. Help files (\f(CW.hlp\fR) should +go into \f(CW[\fIyourlocal\f(CW.src.doc]\fR. +.IP \(bu +In \f(CW[\fIyourlocal\f(CW.src]\fR edit \f(CWx_local.x\fR to add your tasks, +and edit the \f(CWmkpkg\fR file along the lines of the templates. +.IP \(bu +Edit the package \f(CWlocal.cl, .hd, \fR and \f(CW.men\fR files +in \f(CW[\fIyourlocal\f(CW.src]\fR. +.IP \(bu +Edit \f(CW[iraf.vms.hlib]extern.pkg\fP to replace the \f(CWiraf$local/\fR +pathname with your VMS specific one as in the commented-out example +for \f(CWkpnolocal\fR, +escaping any \f(CW$\fR in VMS pathnames with a backslash. +.IP \(bu +Execute \f(CWMKPKG\fR from \f(CW[\fIyourlocal\f(CW]\fR to build the +package (\f(CW$ mkpkg -p local update\fR). +.IP \(bu +After logging into the CL, execute \f(CWMKHELPDB\fR to install your package and +task help pages into IRAF from the package directory, +giving \f(CWlib/root.hd\fR and \f(CWlib/helpdb.mip\fR as the task parameters. + +.RE +When finished, the next time a user logs into the CL, the \f(CWlocal\fR +package will +appear listed in the main package menu, help will be available, and the tasks +will be installed. +.sp +.LP +\fBExample:\fR Add a brand new task to the new \f(CWlocal\fR package. +.PP +Let's add a simple "hello world" task to a new copy of the template local +package in the directory \f(CW[ourlocal]\fR on disk \f(CWscr$2\fR. +Log into the IRAF account. +.sp +.nf +\f(CW\s-1$ create/directory scr$2:[ourlocal] +$ set default scr$2:[ourlocal] +$ backup irafdisk:[iraf.local...] [...] +$ delete login.*;*, bugs.*;*, notes.*;*, irafks.*;* +$ delete $forward.;*, *readme.;*, telinit.;*, [.uparm]*.*;* +$ set protection=(owner:wd) uparm.dir +$ delete uparm.dir;* +$ edit irafhlib:extern.pkg\s0\fR +.fi +.sp +Change the pathname of the local directory: +.DS +\f(CW\s-1reset local = scr\e$2:[ourlocal]\s0 +.DE +.nf +\f(CW\s-1$ set default sys$login +$ cl +cl> cd local$src +cl> ed x_local.x\s0 +.fi +.DS +\f(CW\s-1task bswap = t_bswap, + pavg = t_pavg, + hello = t_hello\s0 +.DE +.sp +\f(CW\s-1cl> ed hello.x\s0 +.DS +\f(CW\s-1procedure t_hello +.sp +bool verbose +bool clgetb() +.sp +begin + verbose = clgetb ("verbose") + + if (verbose) + call printf ("Hello world! (the long version)\en") + else + call printf ("Hello\en") +end\s0 +.DE +\f(CW\s-1cl> ed hello.par\s0 +.DS +\f(CW\s-1verbose,b,h,no,,,"use the long form of hello?"\s0 +.DE +\f(CW\s-1cl> ed local.cl\s0 +.DS +\f(CW\s-1#{ Package script task for the LOCAL package. Add task declarations here +# for any locally added tasks or subpackages. +.sp +cl < "local$lib/zzsetenv.def" +package local, bin=localbin$ +.sp +task bswap, + pavg, + hello = "local$src/x_local.e" +.sp +clbye()\s0 +.DE +\f(CW\s-1cl> ed local.hd\s0 +.DS +\f(CW\s-1# Help directory for the LOCAL package. +.sp +$defdir = "local$src/" +$doc = "local$src/doc/" +.sp +bswap hlp=doc$bswap.hlp, src=bswap.x +pavg hlp=doc$pavg.hlp, src=pavg.x +hello hlp=doc$hello.hlp, src=hello.x\s0 +.DE +\f(CW\s-1cl> ed local.men\s0 +.DS +\f(CW\s-1 +bswap - Swap the bytes in a file + pavg - Plot the average of the lines of an image or image section +hello - Hello world demo task\s0 +.DE +.nf +\f(CW\s-1cl> cd doc +cl> ed hello.hlp\s0 +.fi +.DS +\f(CW\s-1 + .help hello Jul89 local + .ih + NAME + hello - demo task + .ih + USAGE + hello verbose + .ih + PARAMETERS + .ls verbose + Use verbose=yes to test the parameter mechanism. + .le + .ih + DESCRIPTION + This is a demo task to assist in adding local additions to the template + local package. + .ih + EXAMPLE + 1. Use the long version +.sp + cl> hello verbose+ + .ih + BUGS +.sp + .ih + SEE ALSO + .endhelp\s0 +.DE +.nf +\f(CW\s-1cl> cd local +([ourlocal])\s0 +.sp +\f(CW\s-1cl> softools +so> mkpkg -p local update +so> mkhelpdb lib/root.hd lib/helpdb.mip +so> bye +cl> local + bswap hello pavg +.sp +lo> hello +.sp +Hello +.sp +lo> hello verbose+ +.sp +Hello world! (the long version) +.sp +lo> help hello\s0\fR +(etc.) +.sp +.fi + +.bp +.LP +.DS C +\fBAppendix C. Notes on Networking with DECNET in VMS/IRAF V2.8\fR +.DE +.LP +IRAF networking is the preferred way to gain access to peripherals on a +remote computer. These peripherals might include printers, plotters, +disks, image display devices and possibly magnetic tape drives. IRAF +networking can be used to access peripherals on nodes in a local area +network, where the networking protocol in use is internally supported by IRAF. +We presently distribute IRAF configured for TCP/IP networking. A DECNET +networking interface is also available for VMS nodes and is the focus of +this document. The IRAF/DECNET network interface does not, at present, +permit access to tape drives on a remote machine [contact the hotline for +advice; there may be a workaround for this before long]. +If tape drive access +is needed, it will be necessary to perform a normal IRAF installation on +the remote node and use the tape reading facilities on that machine directly +(once installed, the system may be stripped considerably). +.LP +If your system uses only DECNET, it may or may not be necessary to use IRAF +networking, depending upon what peripherals it is desired to access on the +remote node. Installing IRAF networking with a minimal 'kernel server' +implementation is easy to set up. An alternative to this approach may +be to supply DCL command procedures IRAF can use to send printer and plotter +output to the remote node without using IRAF networking. Contact us to find +out if this will work on your system. +.LP +The default network protocol on the distributed systems is TCP/IP, because +that is what we use in the local NOAO network. In its present form, the +choice of network protocol is a compile-time option. In IRAF V2.8 the +appropriate object file is supplied automatically (unless you have a +source-only distribution or have stripped all object files from the system), +but you still need to rebuild the shared library and perform a relink sysgen. +.LP +There are two ways to use internal IRAF networking: between two fully +installed IRAF systems, and between one fully-installed system and a +`kernel server' system. The steps below under `Configuring IRAF networking +for DECNET' apply to a fully-installed system, and would have to be taken +for at least one node in an IRAF network. See the section below under +"Server Nodes" if you are using the remote purely for access to peripheral +devices, but not for running IRAF. In node name references in these notes +we will use the convention HOMENODE = fully-installed system, and SERVERNODE = +the server-only node. +.LP +VMS/IRAF networking using DECNET continues to be supported in a limited way +in IRAF V2.8. These notes should be sufficient for you to successfully +install IRAF/DECNET networking, but don't hesitate to call the HOTLINE if +questions arise. We have not tested these procedures in all possible +environments, so they may be inaccurate or incomplete for some configurations. +There are at least two special situations to be aware of: +.IP [1] +If you use "rooted logicals" for the IRAF root directory on any of +your nodes, you will need to get some modified networking code from us. +.IP [2] +If your system management policies prohibit establishing a logical +link connection with a remote task addressed as object type 0, +you will not be able to use IRAF/DECNET networking without a possible +workaround from the hotline. The task +specification string used in the networking code is of the form: +.sp +.DS + \f(CWNODE"USERNAME PASSWORD"::"TASK=IRAFKS"\fR +.DE +.sp +.IP [3] +An additional note for users rebuilding the VMS/IRAF shared library is +that when you remake the shared library (\f(CWmakeshare.cl\fR) on a MicroVAX, +warning messages may appear from the linker. These are harmless, +and are due to the fact that on a MicroVAX (as opposed to +other VAXes) the system services show up in a load map as virtual +addresses (\f(CW7FFF****\fR). You can modify \f(CWhlib$share/makeshare.cl\fR so +it filters these addresses out of the load map generated when +rebuilding the shared library. The warnings are harmless, but +can be avoided by editing \f(CWmakeshare.cl\fR so the section of the script +that filters the addresses using the IRAF match task reads as follows:\f(CW +.sp +.nf +\f(CW\s-1 +# Now do the UNIVERSAL symbols +# Select out those psects with attributes like Fortran Common blocks +.sp +match (pattern = "-R", files = "common.map") | words | + match (pattern = "^00", stop=yes) | + match (pattern = "^7FF", stop=yes) | + match (pattern = "^CC_", stop=yes) | + sort > symbol.tab\s0\fR +.fi +.sp +.SH +I. Configuring IRAF networking for DECNET on a fully-installed system +.LP +This is a summary of the steps you will take: +.sp +.RS +.IP \(bu +build a decnet version of \f(CWzfioks.obj\fR and load it into a library +.IP \(bu +rebuild the shared library +.IP \(bu +relink all the IRAF executables +.IP \(bu +relink irafks.e without the shared library +.IP \(bu +edit \f(CWdev$hosts\fR +.IP \(bu +create \f(CW.irafhosts\fR files in IRAF home directories on home node +.IP \(bu +create \f(CWirafks.com\fR files in VMS login directories on server node +.RE +.sp +.IP [1] +Get into the directory \f(CWos$net\fR (\f(CW[iraf.vms.os.net]\fR). +Check to see if there +is a file \f(CWzfioks_obj.dna\fR. +If there is not, go to step [2]. If there is, copy it:\f(CW +.sp +.DS +\f(CW +$ copy zfioks_obj.dna zfioks.obj\fR +.DE +.sp +...and proceed to step [3]. +.sp +.IP [2] +(There was no \f(CWzfioks_obj.dna\fR file in \f(CW[iraf.vms.os.net]\fR, +so we will attempt to create one.) +.sp +If you do not have a DEC C compiler, contact us to see about getting +a copy of \f(CWzfioks.obj\fR built for DECNET; you will not be able to proceed +further until you do. +.sp +.IP +You do have a DEC C compiler, so edit \f(CWzfioks.c\fR and compile it: +.sp +.DS +\f(CW$ edit zfioks.c\fR +.sp +change from:\f(CW +.sp +#define DECNET 0 +#define TCP 1\fR +.sp +to:\f(CW +.sp +#define DECNET 1 +#define TCP 0 +.sp +$ cc/nolist zfioks.c\fR +.DE +.sp +.IP [3] +Load the zfioks object file into the IRAF kernel library:\f(CW +.sp +.DS +\f(CW +$ lib/replace [iraf.vms.hlib]libos.olb zfioks.obj +$ delete zfioks.obj;*\fR +.DE +.sp +.IP [4] +Make sure the system is configured for IRAF networking. Examine +the file \f(CW[iraf.vms.hlib]mkpkg.inc\fR, and make sure \f(CWUSE_KNET = yes: +.sp +.DS +\f(CW +$set USE_KNET = yes # use the KI (network interface)\fR +.DE +.sp +.IP [5] +\fRAssuming you are using the shared library, the default, you now +need to regenerate that library. If for some reason you are not +using the shared library, you may proceed to step [6]. To rebuild +the shared library, carry out the steps in section 5.1.8 +then proceed to step [6]. +.IP [6] +Relink the main IRAF system. To do this, carry out the instructions +in section 5.1.9 of the Installation Guide. Make sure you have +deinstalled all IRAF executables before relinking. A common mistake +is to have the old shared library installed while trying to relink +with the new version. The iraf kernel server executable (\f(CWbin$irafks.e\fR) +should NOT be linked against the shared library. So, after you have +relinked the IRAF executables (including \f(CWirafks.e\fR) with the new shared +library, go back to the \f(CWiraf$sys/ki\fR directory and relink the kernel +server without the shared library:\f(CW +.sp +.DS +\f(CW +$ xc -z irafks.o +.DE +.sp +\fRReplace the \f(CWirafks.e\fR currently in \f(CWiraf$bin\fR with this version. +.IP [7] +Edit two files in \f(CWdev$: +.sp +.DS +\f(CW +hosts\fR set up node names for your site\f(CW +hostlogin\fR (optional) set up default public logins if any +.DE +.sp +\fRA common error is to edit the \f(CWdev$hosts\fR file incorrectly. Make sure +you add an entry for each node, including the local node, to this file. +.IP [8] +Create \f(CW.irafhosts\fR files in the IRAF login directories of users who plan +to use networking on HOMENODE. The file format is a series of lines +of the form: +.sp +.DS +\f(CWalias1 alias2 ... aliasN : loginname password\fR +.DE +.sp +If the same login name and password are used on several nodes, +an "\f(CW*\fR" may +be used as the alias. The file should be read protected; also, +a "\f(CW?\fR" may +be used in place of the password (you will be prompted). For example: +.sp +.DS +\f(CW +# .irafhosts file +node1 node3 : mylogin mypassword +* : otherlogin ?\fR +.DE +.sp +.IP [9] +Place a DCL command file called "\f(CWirafks.com\fR" in the VMS +login directories +of all IRAF network users on SERVERNODE (or on both nodes for two-way +network traffic); note the editing required after\f(CW +"$! If this is a standalone...\fR", if the target node is a fully +configured IRAF system \(em the default assumes the target is a kernel +server only system:\f(CW +.sp +.nf +\f(CW\s-1 +$! IRAFKS.COM -- DCL command file to run the IRAF/DECNET kernel server. +$! Note: the path to the server directory MUST be fully specified +$! below (i.e. substitute your actual disk name for "DISK"). +$! +$! set verify !*debug* +$! netserver$verify = 1 !*debug* +$! +$! If this is a standalone irafks server,... +$ set default DISK:[irafserve] ! comment out if full IRAF +$ @irafuser.com ! comment out if full IRAF +$ run irafks.exe ! comment out if full IRAF +$! ..., else if this is a fully-configured IRAF system,... +$! iraf ! <- uncomment if full IRAF +$! run irafbin:irafks.exe ! <- uncomment if full IRAF +$ logout\s0\fR +.fi +.sp +where \f(CWDISK\fR is of course the IRAF disk; the decnet server has no access +to globally defined IRAF symbols or logicals like \f(CWIRAFDISK\fR until it can +execute \f(CWirafuser.com\fR. +.LP +This completes the basic installation; the steps are the same for both +nodes if two-way IRAF network traffic is desired. +.SH +II. Server Nodes +.LP +If a remote node is to be used purely for access to peripherals (you don't +plan actually to run anything in IRAF on the remote node directly), you need +only install a small subset of the IRAF system on it. +This is a summary of the steps you will take: +.sp +.RS +.IP \(bu +build a version of \f(CWirafks.exe\fR without the shared library +.IP \(bu +install and edit the following files in \f(CW[irafserve]\fR on the server node: +.sp +.DS +\f(CWirafks.exe +irafuser.com +irafks.com +login.com +zzsetenv.def\fR +.DE +.RE +.sp +.IP [1] +On the existing fully-installed IRAF system, HOMENODE, verify that +the kernel server executable in \f(CWirafbin\fR is indeed the version you just +created, linked without the shared library. You will be copying it +to the SERVERNODE in a following step. +.IP [2] +On the remote, or `kernel server' system, SERVERNODE, create an IRAF +account as was done for the the main IRAF installation, +as in section 2.1 of the +Installation Guide. Although it is not strictly necessary to have an +actual account for IRAF on this machine, it would be helpful should +it ever be necessary for us to debug anything on it. Have its default +directory set to \f(CW[IRAFSERVE]\fR rather than \f(CW[iraf.local]\fR, +and create the +directory \f(CW[irafserve]\fR (this could be put elsewhere; you would simply +change all references to \f(CW[irafserve]\fR in these notes). +.sp +Also have the system manager insert the following global symbol definition +into the system-wide login file (e.g. \f(CWsys$manager:sylogin.com\fR):\f(CW +.sp +.DS +\f(CW +$ irafserve :== @DISK:[irafserve]irafuser.com\fR +.DE +.sp +\fRIf this is not done, then each user must explicitly execute that `@' +command in their own \f(CWlogin.com\fR files. +.IP [3] +On the remote, or `kernel server' system, SERVERNODE, log in as IRAF. +You should be in the \f(CW[irafserve]\fR directory. +Copy the newly-created kernel server executable and some other files +from the fully-installed system onto the kernel server system. +The file \f(CWirafks.com\fR was discussed in step [9] above; if you do not +have one on HOMENODE, just create it here.\f(CW +.sp +.nf +\f(CW\s-1 +$ set def [irafserve] +$ copy HOMENODE"account password"::DISK:[iraf.bin]irafks.exe [] +$ copy HOMENODE"account password"::DISK:[iraf.vms.hlib]irafuser.com [] +$ copy HOMENODE"account password"::DISK:[iraf.vms.hlib]zzsetenv.def [] +$ copy HOMENODE"account password"::DISK:[iraf.local]login.com [] +$ copy HOMENODE"account password"::DISK:[iraf.local]irafks.com []\s0 +.fi +.sp +\fRwith the appropriate substitutions of course. +.sp +Edit \f(CWirafuser.com\fR to set the logical name definitions \f(CWIRAFDISK, +IMDIRDISK\fR, and \f(CWTEMPDISK\fR for the server node.\f(CW +.sp +.DS +\f(CW +$ edit irafuser.com\fR (etc.) +.DE +.sp +\fRMake sure the first executable lines in \f(CWlogin.com\fR are as below:\f(CW +.sp +\f(CW$ edit login.com +.DS +\f(CW +$ set prot=(s:rwd,o:rwd,g:rwd,w:r)/default +$ if (f$mode() .eqs. "NETWORK") then exit +.DE +.sp +\fRChange the DISK specification for the server system in \f(CWirafks.com\fR to +be the actual disk (or a system-wide logical name for it) -- see +step [9] above.\f(CW +.sp +\f(CW +$ edit irafks.com\fR (etc.) +.sp +.IP [4] +Insert \f(CWirafks.com\fR files into the VMS login directories on the server +node of any IRAF users wanting access to this node. If plotter +access is desired, it is essential that the users' \f(CWlogin.com\fR files +explicitly execute the \f(CW[irafserve]irafuser.com\fR file, and desirable +that they exit if mode = \f(CWNETWORK\fR (to avoid lots of error messages +in \f(CWNETSERVER.LOG\fR files). For example +(in user's \f(CWlogin.com\fR):\f(CW +.sp +.DS +\f(CW +$ set prot=(s:rwd,o:rwd,g:rwd,w:r)/default +$ if (f$mode() .eqs. "NETWORK") then exit +... +$ irafserve ! define IRAF logicals for plotting\fR +.DE +.sp +\fR(The global symbol "\f(CWirafserve\fR" was defined in the system-wide login +file in step [2] above.) +.sp +.LP +This completes the basic network configuration. Although setting up plotting +devices in a network environment can be complicated, here are some guidelines +for installing SGI translators on a kernel server node. +.SH +III. Guidelines for installing SGI translators on kernel server node +.LP +This is a summary of the steps needed: +.sp +.RS +.IP \(bu +on home node, edit \f(CWdev$graphcap\fR (and \f(CWdev$hosts\fR if necessary) +.IP \(bu +copy \f(CWhlib$sgiqueue.com\fR to server and edit it +.IP \(bu +copy \f(CWhlib$sgi2XXXX.exe\fR to server (one for each XXXX SGI translator) +.RE +.sp +.IP [1] +On the home node, edit the graphcap file (\f(CWdev$graphcap\fR) to insert the +server node prefix into the device name part of the \f(CWDD\fR string. For +example, if device \f(CWvver\fR lives on SERVERNODE, and the \f(CWDD\fR string +for that device begins with:\f(CW +.sp +.DS +\f(CW +:DD=vver,tmp$sgk,\fR... +.DE +.sp +\fRchange it to:\f(CW +.sp +.DS +\f(CW +:DD=SERVERNODE!vver,tmp$sgk,\fR... +.DE +.sp +\fRwith appropriate substitution for SERVERNODE. If all the plotters to +which you want access are on the same node, you can use the \f(CWplnode\fR +alias; just make sure \f(CWplnode\fR is an alias for SERVERNODE +in \f(CWdev$hosts\fR +(see `Configuring IRAF networking for DECNET' above). Also make sure +the printer queue names in the \f(CWDD\fR string are appropriate for SERVERNODE +or "\f(CWnone\fR" if the devices are not spooled. E.g.:\f(CW +.sp +.DS +\f(CW +:DD=plot!vver,tmp$sgk,submit/que=fast/noprint/nolog \e +/para=\e050"vver","$F","$(PX) $(PY) VERSAQUEUE"\e051 \e +irafhlib\e072sgiqueue.com:tc=sgi_versatec: +.DE +.sp +.IP [2] +\fRCopy the home node's \f(CWhlib$sgiqueue.com\fR file to the\f(CW +[irafserve]\fR directory +on SERVERNODE and edit it for the local printer queue names, etc. +Also replace the "\f(CWirafhlib\fR" in the VMS task definitions, +as the translators +on SERVERNODE reside in the same directory as \f(CWsgiqueue.com\fR, i.e.\f(CW +[irafserve]\fR. E.g.:\f(CW +.sp +.DS +\f(CW +$ sgi2vver := $DISK:[irafserve]sgi2vver ! versatec interface\fR +.DE +.sp +.IP [3] +Copy the home node's SGI translators to the \f(CW[irafserve]\fR directory on +SERVERNODE. +.sp +There are many different ways of interfacing plotters in VMS environments, +so these notes will not work in all cases. Call the IRAF Hotline if you +have any trouble at all [(602) 323-4160]. +.SH +IV. Using the network +.LP +Each user desiring IRAF network access should have the +following files, as described above: +.sp +.nf + on HOMENODE: \f(CW.irafhosts\fR in IRAF home directory + on SERVERNODE: \f(CWirafks.com\fR in VMS login directory + on SERVERNODE: "\f(CWirafserve\fR" command in VMS \f(CWlogin.com\fR file +.fi +.sp +.LP +In some cases, for example where the local node is a MicroVAX with +comparatively slow disk drives and the remote is a big VAX with very +fast disk drives, an image may actually be accessed faster on the remote +over the IRAF network than it can be locally. +.LP +When working on images across the network, it is best to store the pixel +files in the same directory as the image headers, or in a subdirectory. +This is done by "\f(CWcl> set imdir = HDR$\fR". +Or, to cut the size of the directory +in half by placing the pixel files in a subdirectory called "\f(CWpixels\fR", +"\f(CWset imdir = HDR$pixels/\fR". To cut down on typing, you might also define +a logical directory for your data area on the remote, "\f(CWdd\fR" for example. +Thus you could place the following lines in your \f(CWlogin.cl\fR file: +.sp +.DS +\f(CW +set imdir = HDR$pixels/ +set dd = bigvax!mydisk:\e[mydir.iraf.data]\fR +.DE +.sp +Suppose you are now in the CL on the HOMENODE, and you want to +run \f(CWIMPLOT\fR +on an image called \f(CWtest001\fR on the remote node BIGVAX, in directory +\f(CW[mydir.iraf.data]\fR, and then copy it to your current directory on node A: +.sp +.DS +\f(CWpl> implot dd$test001 +pl> imcopy dd$test001 test001\fR +.DE +.sp +The logical directory \f(CWdd$\fR may be used +in most of the normal fashions (you +won't be able to "\f(CWchdir\fR" to it). +Both IRAF virtual file names may be used +(including all the usual system logical directories) and host file names. +As usual in VMS/IRAF, any "$" and "[" in host-system pathnames must be +escaped with "\e", and lowercase filenames should only be used in IRAF +virtual filenames. Various file access examples follow: +.sp +Use of environment variable (see above) to cut down on typing: +.sp +.DS +\f(CWcl> set dd = bigvax!mydisk\e$1:\e[mydir.iraf.data] +cl> dir dd$ +cl> page dd$README +im> imhead dd$*.imh\fR +.DE +.sp +Use of IRAF virtual filenames explicitly: (this will only work on +systems where bigvax is a fully-installed system; the IRAF virtual +directories may not be present on a server-only system) +.sp +.DS +\f(CWcl> count bigvax!local$notes +cl> tail bigvax!local$notes nl=100 | page +cl> dir bigvax!hlib$*.com long+ +cl> dir bigvax!sys$gio/R* long+ +cl> page bigvax!sys$gio/README +cl> page bigvax!home$login.cl +cl> dir bigvax!tmp$sgk* long+\fR +.DE +.sp +Use of host-system pathnames: +.sp +.DS +\f(CWcl> dir bigvax!usr\e$0:\e[mydir.iraf]*.imh +cl> copy bigvax!usr\e$0:\e[mydir.doc]letter.txt newletter.txt +cl> history 100 > bigvax!usr1:\e[mydir]test.his\fR +.DE +.sp +.LP +Please remember that this is a developing interface, and that it has not +yet been tested as extensively as we would like. We would appreciate being +contacted about any problems you uncover. + + diff --git a/doc/vmsprog.hlp b/doc/vmsprog.hlp new file mode 100644 index 00000000..bd8c7b2e --- /dev/null +++ b/doc/vmsprog.hlp @@ -0,0 +1,572 @@ +.help vms Nov85 "VMS/IRAF Programming Notes" +.ce +\fBVMS/IRAF Programming Notes\fR +.ce +Doug Tody +.ce +25 November 1985 +.sp 2 +.sh +Preface + + The purpose of this document is to serve as a guide to programming in the +VMS version of the IRAF environment. The discussion focuses on the +peculiarities of the NOAO VMS/IRAF environment rather than on the basics of +programming in IRAF; this is not an IRAF programming tutorial. The discussion +is intended for the practicing programmer using the NOAO/Tucson version of +VMS/IRAF, which includes the Eunice UNIX emulator and which is embedded in +a local network of four Vaxes and one Sun workstation. The discussion +describes the VMS version of IRAF as it currently exists at NOAO, with all +its bugs and defects, hence the document will rapidly become dated. + +.nh +Introduction + + The foreign task interface is now working well enough in the VMS version +of IRAF for me to recommend that IRAF software development and testing be +done from within the IRAF environment rather than in DCL. +All of the VMS facilities are easily and efficiently accessible, +plus one has the many advantages of the CL, e.g., +multiple commands on a command line, i/o redirection, ease of +spawning background jobs, logical directories, networking facilities etc. +The environment provides the basic tools we are used to on our UNIX based +systems (with help from Eunice), although the more subtle features of +UNIX are missing (e.g., OS escapes in VI or the debugger, job control, etc.). + +.nh +The NOAO VMS/IRAF Programming Environment +.nh 2 +The USER Package + + The USER package provides a way for the IRAF user to extend the IRAF +environment by adding IRAF or foreign tasks of their own choosing. +These extensions will normally be site dependent and will often vary from +user to user. In this section we describe the USER package for the IRAF +login on the NOAO VMS systems. The USER package is defined in the IRAF +login.cl file (usr1:[iraf.local]login.cl), which uses VMS logical names +defined in the IRAF login.com file (usr1:[iraf]login.com). + +The USER package is automatically loaded at login time since it is in the +login.cl file. The current contents of the package are summarized in the +menu below ("?u" to print when in the CL). The contents of this package +change frequently but it is likely that the present package already contains +the most frequently used utilities. Note that the standard \fBsoftools\fR +task are included for convenience. + + +.ks +.nf + adb grep mklib ps rlogin ruptime top who + chmod ls mkpkg purge rpp rwho touch wtar + diff mail mon pwd rsh sed update xc + finger make od rcp rtar su vdir xpp + generic man omake replace run telnet whereis +.fi +.ke + + +Many of the tasks shown here are simply foreign task definitions for the +Eunice/UNIX tools, which are used just as they are on a UNIX system. +Some of the others are less obvious and are described in the notes below. +.ls 4 +.ls 10 adb +Debug a VMS executable; short for "!run/debug". +For example, "adb x_x" will run the VMS debugger on file "x_x.e". +You should log in directly on the class 6 VAX rather than via \fBtelnet\fR, +else the screen will scroll rather than be randomly updated. +On VMS a process must be linked specially to be used with the debugger. +To do this, add the "-x" flag to the XC command line. +A task linked in this fashion CANNOT presently be run from the CL in the +normal fashion, so always use the "-o" flag to give the debug executable +a different name than the installed executable, e.g, "x_x.e". +.le +.ls run +The opposite of ADB. Runs a process linked with the debugger with DEBUG +turned off (i.e., a VMS run/nodebug). Will also run any normal (nondebug) +executable. +.le +.ls generic +The IRAF generic preprocessor. Usually run explicitly on VMS since the +Eunice MAKE has filename, etc. problems and cannot run many UNIX/IRAF +makefiles. Look in the UNIX makefile to get the command to feed to generic. +.le +.ls ls +The Eunice/UNIX directory lister. Used when you want to see multiple file +versions (these are invisible in an IRAF "dir" listing), +or when you want an "ls -lt" time sorted file listing. +The disadvantages of LS for normal use are that it +does not expand templates and does not unmap filenames. Note also that +recursive descent does not work in Eunice (at least not for me), hence commands +like "ls -R" will hang. +.le +.ls mail +Calls the VMS mail program. Whenever possible use UNIX mail instead to send +messages, unless you are sending mail to Nigel or some other diehard VMS type +who reads their VMS mail frequently. +.le +.ls mklib +The IRAF library maintenance utility. Also available in the \fBsoftools\fR +package. Essentially equivalent capability to the UNIX version. +A VMS manual page is appended. +.le +.ls mkpkg +Make package. Runs the "mkpkg.com" script in the current directory. +This is the VMS/IRAF equivalent of the "make" used on a UNIX system to +make or update a package. +.le +.ls mon +Monitor system. Equivalent to "!monitor system". Not as useful as the +UNIX task of the same name, but the output is prettier. +.le +.ls omake +Makes an object version of a file if one does not already exist; needed because +Make is not available on VMS. The only alternative in VMS is "xc -c file" +which is much slower since it always recompiles the named file. Note that +OMAKE does not check any include file dependencies. +.le +.ls ps +The Eunice version of PS. Contains a lot more information than the VMS +"show sys". The output from "ps -axu" is particularly useful. +PS is currently about the only thing on VMS which can tell you what command +another user is running. +.le +.ls purge +The VMS purge-old-versions task. Type "pu *.*" often when working in VMS. +The form "pu [...]*.*" will purge all old versions in the current directory +and below. +.le +.ls replace +Replace the named module in the named LIB$ library, e.g., + + cl> replace read.x sys + +would recompile "read.x" and replace the object module in the library +"lib$libsys.a", aka "iraflib:libsys.olb". This is primarily of interest +to systems programmers, since it works only on the system libraries in LIB$. +NOTE: this is a dangerous utility, since it is easy to replace (insert) +the module into the wrong library. +.le +.ls rtar +The IRAF read tarfile task. Used to unpack IRAF files from a tar tape, +or more commonly, from a tar format disk file pushed through the Ethernet. +A VMS manual page is appended. +.le +.ls telnet +Used to log in on a remote node. When logging onto a UNIX node from a VMS +node, frequent 's will be necessary when using utilities like PAGE +and VI to keep the terminal talking. +.le +.ls top +Display the processes currently using the most cpu cycles. Equivalent to +a "!monitor proc/topcpu". Similar to the UNIX "top" but takes no arguments +and returns less information about the resources consumed by the processes. +.le +.ls update +Update the named LIB$ system library by running MKLIB on the contents of +the current directory. This is like REPLACE except that it will hopefully +find and replace all recently modified modules in the current directory. +UPDATE is equivalent to the following sequence of VMS commands: + +.ks +.nf + $ copy iraflib:libXXX.olb [] + $ mklib libXXX.a + $ rename libXXX.olb iraflib +.fi +.ke + +Note the use of [] to signify the current directory, and the use of RENAME +to move a file to another directory. +.le +.ls vdir +The VMS directory lister. Used when one wants to ask VMS questions about +files, e.g., to query protections, get /full listings, etc. The advantage +of having this available as a foreign task (rather than just using an OS +escape) is that the output can be redirected into a file. For example, + + cl> vdir /full [...]*.exe > _exec + +will save in file "_exec" a /full format directory listing of all executables +in the current directory and below. +.le +.ls who +Equivalent to a "!show users". +.le +.ls wtar +The UNIX write tarfile utility. Used to save a directory tree in a portable +a UNIX "tar" format binary file. Use this with the "-o" (omit binaries) flag +to move sources back to UNIX. For example, + +.ks +.nf + cl> cd pkg + cl> wtar -of home:plarc [.plot] +.fi +.ke + +will make a tarfile "plarc" of the subdirectory "plot", assuming that HOME is +defined as a VMS logical directory name. Most variations on the command +shown here do not currently work. +A VMS manual page is appended. +.le +.ls xc +The IRAF XC portable compile/link utility. This task is also available in +the \fBsoftools\fR package. A VMS manual page is appended. +.le +.le + + +The USER package described here may be extended by copying the package +definition to your own login.cl file, then adding additional task definitions. + +.nh 2 +Foreign Tasks + + New foreign tasks may easily be defined at run time, for example when one +wants to capture the output of a VMS utility without having to edit a .com +file and submit a batch job (many VMS tasks do however have a /OUTPUT switch +which does much the same thing), or when one wants to run a foreign task +in the background. For example, + + +.ks +.nf + cl> task $vll = "$library/list/full" + cl> vll osfn("lib$libos.a") > _lib +.fi +.ke + + +defines a new task VLL which uses the VMS library to list the contents of a +library, then uses the new task to list the contents of the system library +LIBOS, saving the output in the file "_lib". Note the use of the string +valued intrinsic function OSFN to generate a VMS filename for the foreign +task. To discard a foreign task definition (or any task definition), exit the +package in which it was defined, or type "cl" before defining the task, +followed by "bye" at some later time to discard everything back to the "cl". + +A foreign task command is parsed by the CL just like any other IRAF command, +as is evident from the second example above. The arguments to a foreign +task may be arbitrary expressions; the CL reduces each such argument +expression to a constant value and passes this value to the host system as +a string. Note that VMS will convert all arguments to a single case unless +they are quoted. For example, + + cl> xc '"-cO"' file.x + +is the command to compile a file with optimization (the current XC default +is to not optimize). +Note that the first set of quotes are stripped off the by the CL, and the +second by DCL. + +.nh 2 +Filenames + + Avoid using the VMS meta-characters [ and $ in filenames when working +within the IRAF environment (except in calls to foreign tasks). To reference +a file in an arbitrary VMS directory you must first define the VMS directory +as an IRAF logical directory. Directories which are frequently referenced +should be defined in your login.cl file. + + +.ks +.nf + cl> set iis = sdk:[kpno.iis.prim] + cl> ed iis$foreign.f + cl> cd iis + cl> dir *.f + cl> back +.fi +.ke + + +The example above defines a new logical directory IIS and uses it to edit a +file therein, change to the directory, and so on. A reference such as the +following would fail because the system would try to do template expansion +on the [] delimited field. + + cl> page sdk:[kpno.iis.prim]foreign.for # won't work + +The following should work and will work in a future version of the system, +but does not work at present. + + cl> page sdk:\[kpno.iis.prim]foreign.for + +The mixture of IRAF, Eunice, and VMS tasks present in the USER package can be +confusing when it comes to filenames. +Most references to files in the current directory +are the same in all environments, but there are major differences +when pathnames are involved. To work effectively and without aggravation +you must know what type of task you are calling and supply the appropriate +type of filename. This is the price we pay for having direct access to +foreign tasks. + +.nh 2 +I/O Redirection and Background Execution + + I/O redirection will now work on VMS/IRAF for foreign tasks as well as +true IRAF tasks. The input or output of a foreign task may be redirected +on the command line; foreign tasks may be used in pipes. This is particularly +useful in combination with background execution, e.g.,: + + +.ks +.nf + cl> mkpkg >& spool & +or + cl> xc -c file1.x,file2.x,file3.f >& spool & +.fi +.ke + + +Background jobs currently run at a reduced priority on both UNIX and VMS. +At present any IRAF background jobs will be terminated when you log out of VMS. +Support for submission of IRAF background jobs to the VMS batch queues is +being actively worked on and will be available in the near future. + +.nh 2 +Editor Interface + + The NOAO VMS/IRAF editor interface currently supports the VI and EDT +editors (Emacs is also supported but we do not have the actual editor at NOAO). +One types "edit" or "ed" to invoke the editor; the choice of the actual +editor to be used is controlled by the \fBeditor\fR environment variable, +which may be set in your login file. + +The major limitation in the editor interface to VI is that template expansion +is not currently supported (the template is passed to the Eunice VI but it +is not expanded, since the UNIX shell normally does this for VI). +The ":!" OS escape mechanism does not currently work (for all but a few +commands) in the IRAF environment, although it does work in the Eunice cshell +environment. It is possible for the editor to have a different idea of the +current default directory than IRAF; if you suspect that this is the case, +type ":!pwd" to check and ":!cd /newdir" to fix it up. + +.nh 2 +Network Facilities + + Network access is currently available for the class 1, 2, and 5 Vaxes +from any other IRAF node, including the two VMS Vaxes and the Sun workstation. +All binary and text files and the class 2 (lyra) IIS may be accessed over +the network. Access to VAX/8600 hosted resources from the 750's will be +available shortly. For example, to copy a file from lyra to the current +directory when logged into IRAF on the 8600, any of the following equivalent +commands would work: + + +.ks +.nf + cl> copy lyra!/iraf/lib/fio.h fio.h + cl> copy 2!/iraf/lib/fio.h . + cl> copy 2!lib$fio.h . +.fi +.ke + + +Images may also be accessed over the network, provided there is a VAX at +both ends (this restriction will be removed when the DBIO based IMIO is +installed). + + +.ks +.nf + cl> set pix = 2!/tmp2/iraf/images/ + cl> implot pix$canon + cl> imcopy pix$canon canon2 +.fi +.ke + + +Copying an image from the local node to a remote node does not work at +present, even when IMDIR is defined to be on the remote node. I have not +yet had time to figure out why. + +Whenever a local process accesses a resource on a remote node the system will +spawn a "kernel server" process on the remote node. The kernel server +remains connected for the life of the local process, hence there is a delay +the first time a node is referenced (while the kernel server process is being +spawned), but all subsequent commands execute almost as fast as on the local +node. For example, there is a fixed delay of several seconds when an image +is first displayed from the 8600 on the lyra IIS, but thereafter image load +will be quite fast, so long as the image load process remains in the process +cache. + +The kernel server process must authenticate on the remote node with a login +and a password. By default the NOAO system currently uses the "ace" login for +this purpose; this is adequate for most purposes but, for example, printer +output will come out with an ACE jobname, and you will not have network write +access to your own files and directories. To have a fully functional network +interface you must add the file ".irafhosts" to your host system login +directory. This structure of this file is very simple and is best explained +by an example: + + +.ks +.nf + # Sample .irafhosts file. + + aquila lyra carina : login1 password1 + vela draco : login2 password2 + * : login3 password3 +.fi +.ke + + +Each line in the file associates a login name and password with a set of +hosts. Use the "real" host names in this file (e.g., "lyra"), not the +aliases (e.g., "2, class2"). The "*" line supplies a login and password +for any host machine and terminates scanning of the file, hence should be +given last. In the simplest case, i.e., where your login name and password +are the same on all hosts, the file may contain a single "*" type entry. +If the file contains your password it should of course be read protected. +For additional security the password may be given as "?" in which case you +will be asked for the actual password whenever a kernel server is spawned. + +.nh +VMS/IRAF Software Maintenance + + The IRAF group currently maintains IRAF simultaneously on a UNIX 11/750 +(node \fIlyra\fR) and on the VMS cluster (including both of the nodes +\fIdraco\fR and \fIvela\fR). Software is written and tested on the UNIX +11/750 and then installed and tested on the 8600, merging any bug fixes +from the VMS testing back into the UNIX version of the system. The UNIX 11/750 +is the primary software development system and contains the "master copy" +of IRAF. The 8600 is a production data processing machine and should not +be used for routine software development (algorithm development requiring the +speed of the 8600 is permitted, however). + +Each member of the IRAF group is responsible for installing and testing their +software on the 8600. Since the IRAF environment permits identical software +to be run on all IRAF hosts, the procedure for doing this is quite +straightforward. For example, assume we want to install a new version of +the PLOT package on the 8600. The following sequence of commands would +suffice to install an entire new version of the package. Incremental changes +are faster, but a full installation should be done occasionally to ensure +that the same software is running on both nodes. + + +.ks +.nf + (login on the 8600, get into the CL) + cl> telnet lyra + (log into lyra) + + % cd plot + % tar -cf ~/plarc . # make tar archive of plot + % rcp ~/plarc 6: # move tarfile to node 6=draco + % logout # go back to draco + + cl> cd pkg + cl> wtar -of usr0:[tody]plarc.bak [.plot] # make backup + cl> cd plot + cl> !show default # just in case... + cl> !del [...]*.*;* # delete nondir files + cl> !set prot [...]*.*;* # unprotect dir files + cl> !del [...]*.*;* # delete directory files + (repeat until all .dir files gone) + + cl> rtar -xof usr0:[tody]plarc # unpack new version + (fix up mkpkg.com files, if necessary) + cl> mkpkg >& spool & + (test everything once package is rebuilt) +.fi +.ke + + +At present the VMS version of each package is maintained by a DCL +"mkpkg.com" file. This is the only machine dependent software in an +IRAF package. To avoid having to recover the mkpkg.com files from the +WTAR savefile, you may wish to install the files in the UNIX version of +the package. The mkpkg.com files are quite simple since they just call +the portable IRAF utilities MKLIB and XC, but hopefully we will be able +replace the UNIX Makefiles and VMS mkpkg.com files by a single facility +in the future. + +As an example, the MKPKG.COM file for the plot package is shown below. +Note that the Makelib files, used by MKLIB to maintain the package libraries, +are portable since MKLIB is an (bootstrap) IRAF utility. + + +.ks +.nf + $! Make the PLOT package (VMS) + $! + $ mklib -i libpkg.a + $! + $ omake x_plot.x + $ omake x_ncar.x + $ xc x_plot.o libpkg.a -lncar -lgks -lxtools -o x_plot.e + $ xc x_ncar.o libpkg.a -lncar -lgks -lxtools -o x_ncar.e +.fi +.ke + + +Each time MKPKG is run new VMS versions of the executables will be added +to the PLOT directory. An occasional PURGE is necessary to remove the +old versions. + +.nh +Debugging on VMS + + Before an IRAF process can be debugged on VMS, the process must first +be linked using the "-x" flag to XC. For example the "x_plot.e" executable +shown above in the example of a MKPKG.COM file would be relinked for +debugging with the following command: + + cl> xc -x x_plot.o libpkg.a -lncar -lgks -lxtools -o x_x.e + +Note that the new executable is NOT called "x_plot.e", in case someone tries +to use the plot package while we are debugging it. To debug the newly +linked process we first check the ZZSETENV.DEF file to make sure that the +pathnames therein are up to date; they won't be if the package was recently +moved over from the UNIX system. + +Before debugging the executable make sure that you are logged in directly +on the VMS machine; do not login remotely via \fBtelnet\fR. Enter the +following command to begin debugging the process: + + cl> adb x_x + +For use in the IRAF environment the VMS debugger is run in screen mode, +language MACRO (assembler language debugging). Type GO to run the program +(the IRAF main prompt will appear); type EXIT to exit the debugger when +through debugging. This will sometimes leave the screen in a funny state +(a scrolling window less than the full screen may be defined). If this +happens, physically reset your terminal. The initial state of the debugger +is setup by the file "iraf$vms/init.dbg" which is referenced by the VMS logical +name DBG$INIT (which should be defined in your VMS login.com file). +You can change the initial state of the debugger by redefining DBG$INIT to +reference your own initialization file. + +Instruction in the actual VAX/DEBUG commands is beyond the scope of this +document; the best way to learn the debugger is to get an experienced IRAF +programmer to give a demo. The VMS document "Programming in VAX FORTRAN" +is the best documentation currently available for the VMS debugger. + +.nh +Comments on Performance + + Process spawning and inter-process communication appear to be slow in the +VMS operating system, compared to UNIX. When programming in an equivalent VMS +system (e.g., the VMS 11/750) all operations which involve process spawning +or inter-process communication will be noticeable slow compared to UNIX. +When programming on the VMS/8600 these operations seem to be comparable +in speed to an 11/750 running UNIX (actual process execution is of course +much faster on the 8600). Large files will compile faster on VMS than on +UNIX, but when compiling many small files the two systems are comparable. +Linking takes about the same amount of time on the UNIX 750 and on the 8600, +but the UNIX linker may actually be faster once the current cpu bound +inefficiencies in the UNIX linker are corrected (UNIX may win in the end +because of the UNIX buffer cache and the prelink facility provided by the +UNIX linker, but if we ever get sharable libraries working on VMS then it +may be faster). + +When it comes to actually executing a single scientific task, however, +VMS is in general slightly faster than UNIX running on equivalent hardware, +because the Fortran optimizer is slightly better, and VMS supports +asynchronous i/o. For these and other reasons (e.g., the availability of +UNIX on virtually all machines, the facilities provided by UNIX for software +development, etc.) it is best to do software development and other timesharing +activities on UNIX, reserving VMS for production use, i.e., data processing. +This is of course our current policy at NOAO. +.endhelp diff --git a/doc/vxuxiraf.ms b/doc/vxuxiraf.ms new file mode 100644 index 00000000..f0cfad0e --- /dev/null +++ b/doc/vxuxiraf.ms @@ -0,0 +1,631 @@ +.RP +.de XS +.DS +.ps -1 +.vs -2p +.ft CB +.. +.de XE +.DE +.ft R +.ps +.vs +.. +.TL +VAX Ultrix/IRAF Installation Guide +.AU +Mike Fitzpatrick +Doug Tody +.AI +IRAF Group +.br +.K2 "" "" "\(dg" +.br +June 1989 +.br +Revised September 1992 + +.AB +This document describes how to install or update IRAF on an DEC VAX +workstation or server running Ultrix. Both standalone and networked, +multiple architecture configurations are described. Only those issues which +one must understand to install VAX Ultrix/IRAF are discussed here; a companion +document, \fIUNIX/IRAF Site Manager's Guide\fR, deals with other issues such +as interfacing new devices, configuring the IRAF networking system, adding +layered software, and so on. +.AE + +.pn 1 +.bp +.ce +.ps +2 +\fBContents\fR +.ps -2 +.sp 3 +.sp +1.\h'|0.4i'\fBIntroduction\fP\l'|5.6i.'\0\01 +.sp +2.\h'|0.4i'\fBInstalling Ultrix/IRAF\fP\l'|5.6i.'\0\01 +.br +\h'|0.4i'2.1.\h'|0.9i'Prepare the root IRAF directory\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.1.\h'|1.5i'If updating an existing IRAF installation...\l'|5.6i.'\0\02 +.br +\h'|0.9i'2.1.2.\h'|1.5i'If installing IRAF for the first time...\l'|5.6i.'\0\03 +.br +\h'|0.4i'2.2.\h'|0.9i'Install the files\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.1.\h'|1.5i'Installing from a network distribution\l'|5.6i.'\0\03 +.br +\h'|0.9i'2.2.2.\h'|1.5i'Installing from tape\l'|5.6i.'\0\04 +.br +\h'|0.9i'2.2.3.\h'|1.5i'Configuring the BIN directories\l'|5.6i.'\0\05 +.br +\h'|0.4i'2.3.\h'|0.9i'Merge local revisions back into the new system\l'|5.6i.'\0\06 +.br +\h'|0.4i'2.4.\h'|0.9i'Run the INSTALL Script\l'|5.6i.'\0\06 +.sp +3.\h'|0.4i'\fBSystem Checkout\fP\l'|5.6i.'\0\08 +.sp +\fBAppendix A.\0A Complete Example\fP\l'|5.6i.'\0\09 +.nr PN 0 +.bp + +.NH +Introduction +.PP +Before installing Ultrix/IRAF on a VAX, one must 1) obtain an appropriate +Ultrix/IRAF distribution, e.g., from the IRAF network archive on +\f(CWiraf.noao.edu\fR (or by ordering a tape distribution from NOAO), 2) +select the server or node on which the system is to be installed and arrange +for sufficient disk space to hold the system, and 3) set aside sufficient +time to do the installation. If these directions are followed carefully and +mistakes are avoided the basic installation should only take a half hour or +so. Additional time may be required to customize the system, to configure +the local tape drives and other devices, set up IRAF networking, and so on. +.PP +This Installation Guide is intended primarily for sites installing IRAF on a +VAX running Ultrix 4.3 or later. Other popular UNIX systems for which IRAF +is available, e.g. IRIX and SunOS, have their own system specific IRAF +installation guides. In particular, there is a separate installation guide +and IRAF distribution for the Decstation version of Ultrix/IRAF, as well as +for IRAF on VAXes running VMS. + +.NH +Installing Ultrix/IRAF +.PP +Although the details of how Ultrix/IRAF is installed or updated depend upon the +type of distribution and the desired local system configuration, the basic +procedure is always the same. First one obtains the distribution files, +then one follows the procedure outlined below to install the system. Most +of these steps should be performed while logged in as IRAF; superuser +permission is required in the final stages of the installation, to run the +\fIinstall\fP script. +.PP +System managers familiar with the installation of typical UNIX programs +should beware that IRAF, being a large system in its own right and not a +UNIX program, does not always follow to the usual conventions. It is wise +to read and adhere to the installation instructions to avoid problems. +.XS +\fR# Prepare the root IRAF directory.\fP +if new installation + create iraf account +else if updating an old installation + save locally modified files; delete old system + +\fR# Install the files.\fP +login as iraf +unpack the core system distribution +configure the BIN directories + +\fR# Merge local revisions into new system.\fP +if updating an old installation + merge locally modified files back into new system + +run the iraf install script to complete the installation +checkout the new system +.XE +.PP +If problems should arise during the installation help is available via the +IRAF HOTLINE (602-323-4160), or by sending email to \f(CWiraf@noao.edu\fP. + +.NH 2 +Prepare the root IRAF directory +.NH 3 +If updating an existing IRAF installation... +.PP +If you are updating an existing IRAF installation then you will be replacing +IRAF by the new version, and IRAF should already have an account and root +directory on the desired host system. You should save any locally modified +files and delete the old system, e.g., login as IRAF and enter something +like the following. +.XS +% cd $iraf\(dg +% tar -cf /scr0/oiraf.tar local dev unix/hlib +% /bin/rm -rf * +.XE +.FS +\(dg\0\(CW$iraf\fP symbolizes the UNIX pathname of the root IRAF directory. +If no "iraf" environment variable is defined just supply the actual pathname. +.FE +.PP +There are many possible variations on this, e.g., you could use \fImv\fR to +move the above directories to someplace outside the main IRAF directory +tree. Although it is probably simplest and safest to save entire +directories as in the example, in practice only a few files are likely to +have been modified. These are the following. +.XS +dev/graphcap +dev/hosts +dev/tapecap +dev/termcap +hlib/extern.pkg +hlib/login.cl +hlib/zzsetenv.def +local/.login +.XE +.PP +Once the old system has been deleted you are ready to install the new one, +as described in \(sc2.2. It is important to delete the old system first to +avoid creating junk files or directories when the new system is installed +(due to file or directory name changes or deletions). Once the new system +has been restored to disk, do \fInot\fR merely restore the files saved above, +as you will need to carefully merge local changes into the versions of the +files supplied with the new IRAF release (more on this later). +.NH 3 +If installing IRAF for the first time... +.PP +If you are installing IRAF for the first time then the first step is to set +up a new account for the user `\f(CWiraf\fP'. This is necessary for IRAF +system management, which should always be done from the IRAF account. The +IRAF account has special login files which set up a custom UNIX environment +for IRAF system management. Having an IRAF account provides a convenient +place (the IRAF system manager's login directory) to keep scratch files +created during system configuration. +.PP +The location of the IRAF root directory is arbitrary. Our practice here is +to locate the software in a system file storage area separate from the +Ultrix system files (to simplify Ultrix upgrades), and then use a symbolic +link such as /iraf or /usr/iraf to point to the actual root directory. This +makes life simpler if IRAF is NFS mounted on several machines and it is +later necessary to move the IRAF files. Try to keep the path to the +physical IRAF root directory short to avoid filename truncation problems +when IRAF is run. +.PP +The login directory for the iraf account should be $iraf/local (e.g., +/iraf/iraf/local), rather than the IRAF root directory $iraf as one might +expect. This is done to provide a work area for local files separate from +the main IRAF directory tree, to simplify updates and make it easier to keep +track of what has been locally added and what is standard IRAF. In any +case, make sure that when the IRAF account is set up the login directory is +set correctly, or the IRAF environment will not be set up properly, and +later problems are sure to result. +.PP +A typical IRAF installation consists of the main IRAF release, a number of +BIN directories (the IRAF binaries), and additional directories for layered +software such as STSDAS, PROS, and so on. If sufficient disk space is +available to keep everything in one area the following directory structure +is recommended. +.XS +/iraf/iraf \fR# iraf root directory ($iraf)\fP +/iraf/iraf/local \fR# iraf login directory (~iraf)\fP +/iraf/irafbin \fR# iraf BIN directories\fP +/iraf/irafbin/bin.vax \fR# VAX binaries - iraf core system\fP +/iraf/irafbin/noao.bin.vax \fR# VAX binaries - iraf NOAO package\fP +/iraf/stsdas \fR# layered package\fP +/iraf/xray \fR# layered package\fP + \fI(etc.)\fP +.XE +.PP +For the purpose of this example we assume that the IRAF files are stored in +/iraf; as we say this might be a link and the actual directory is +arbitrary. Given this directory the IRAF root $iraf would be "/iraf/iraf/" +and the login directory for the IRAF account would be /iraf/iraf/local. The +binaries for the core IRAF system would be in /iraf/irafbin/bin.vax, +with a link $iraf/bin.vax pointing to this directory (more on this +later). +.PP +Given the above directory structure the \f(CWpasswd\fR file entry for the +IRAF account would be something like the following. +.XS +iraf:abcdef:312:12:IRAF system login:/iraf/iraf/local:/bin/csh +.XE +.PP +Do not worry about configuring the environment files for the new account as +these will be created when the iraf system is later restored to disk. + +.NH 2 +Install the files +.PP +If you are installing from tape skip forward to \(sc2.2.2. If you are +installing from a network distribution (i.e., from disk) continue with the +next section. +.NH 3 +Installing from a network distribution +.PP +Ultrix/IRAF is available over the network via anonymous ftp from the node +\f(CWiraf.noao.edu\fR, in the subdirectory \f(CWiraf/v\fInnn\fP/VXUX\fR, +where "\f(CWv\fInnn\fR" is the IRAF version number, e.g., subdirectory +\f(CWiraf/v210/VXUX\fR for V2.10 Ultrix/IRAF for the VAX. +.PP +If IRAF is being installed from a network distribution all the architecture +independent IRAF files for both the core IRAF system and the NOAO packages +will be in the distribution file \f(CWas.vxux.gen\fR. This "file" is stored +in the network archive as a directory wherein the large distribution file +has been split into a number of smaller pieces, e.g., +.XS +% ls as.vxux.gen +CHECKSUMS as.vxux.gen.Z.12 as.vxux.gen.Z.26 +FILES.Z as.vxux.gen.Z.13 as.vxux.gen.Z.27 +as.vxux.gen.Z.00 as.vxux.gen.Z.14 as.vxux.gen.Z.28 +as.vxux.gen.Z.01 as.vxux.gen.Z.15 as.vxux.gen.Z.29 +as.vxux.gen.Z.02 as.vxux.gen.Z.16 as.vxux.gen.Z.30 +as.vxux.gen.Z.03 as.vxux.gen.Z.17 as.vxux.gen.Z.31 + \fI(etc.)\fP +.XE +.LP +Assume that the directory \f(CWas.vxux.gen\fR as shown above has been +recreated somewhere on the machine on which IRAF is to be installed. +We can restore the main IRAF source tree as follows. +.XS +% whoami +iraf +% cd $iraf +% cat /\fIpath\fP/as.vxux.gen/as.* | uncompress | tar -xpf - +.XE +After the above finishes the root IRAF directory should appear as follows +(this is for V2.10). +.XS +HS.VXUX.GEN bin.generic doc math pkg unix +IS.PORT.GEN bin.vax lib mkpkg sys +bin dev local noao tags +.XE +The file \f(CWbin.vax\fR is a symbolic link to the BIN directory containing +the VAX/Ultrix IRAF binaries, which probably does not exist yet. +Configuring the BIN directories is discussed in section \(sc2.2.3. +.NH 3 +Installing from tape +.PP +If you have not already done so, log into the IRAF account so that the files +when restored will belong to IRAF. Mount the distribution tape, which may +be a cartridge tape, a 6250 bpi 9 track tape, a DAT tape, an Exabyte, or +whatever. +.PP +IRAF distribution tapes consist of multiple files separated by tape marks, +with a TOC (table of contents) file as the first file on the tape. To find +out what is on the tape, rewind it and read out the TOC file as follows (the +actual device name will likely be different than that shown in the examples). +.XS +% mt -f /dev/rmt0h rew; cat /dev/rmt0h +.XE +This should cause a TOC file to be listed similar to the following, except +for the file names which will vary depending upon what type of distribution +you have (the file sizes may vary from what is shown). The example below is +for a distribution of Ultrix/IRAF for the VAX, including the VAX binaries. +.XS +0 Table of Contents + +1 AS.VXUX.GEN 46.4Mb IRAF, NOAO packages and Ultrix/OS sources +2 IB.VXUX.VAX 19.9Mb VAX binaries for IRAF system +3 NB.VXUX.VAX 18.9Mb VAX binaries for NOAO packages +.XE +.PP +Here, the first column is the file number on the tape, the TOC file being +file zero (the first distribution file is number one), the second column is +the name of the tape file, the third column is the file size in megabytes +(this tells you how much space will be needed to unpack the file on disk), +and the last column is a description of the file contents. +.PP +There are three types of tape files in the example shown: the \f(CWAS\fR +file, which is all the IRAF sources (the core IRAF system, NOAO packages, +and the Ultrix host system interface), the \f(CWIB\fR files, or IRAF core +system binaries, one for each architecture, and the \f(CWNB\fR files, or +NOAO package binaries. The NOAO package sources are included in the +\f(CWAS\fR file since most people requesting IRAF are expected to want the +astronomical reduction software, although IRAF can be configured without +this if desired. All of the file objects are UNIX \fItar\fR format files, +with the exception of the TOC file which is a simple text file. The +distribution files may be compressed if this was necessary to fit all the +files on a tape. +.PP +In the above example, the \f(CWVXUX\fR in the file names indicates that +these files are for VAX Ultrix. A Sun version 4 distribution is indicated +by a \f(CWSOS4\fR in the file names, and a DECstation Ultrix distribution is +indicated by a \f(CWDSUX\fP, and so on. In principle a given distribution +tape may contain any combination of these files. +.PP +The following commands would suffice to restore the main IRAF system to +disk, given the distribution tape described by the TOC file in our example +above. Once again, the tape device file and possibly the block size will +likely have to be changed to whatever is needed for the actual tape device +used. +.XS +% whoami +iraf +% cd $iraf +% mt -f /dev/rmt0h rew; mt -f /dev/rmt0h fsf 1 +% tar -xpf /dev/rmt0h +.XE +.PP +After the above tar file read operation, the tape is left positioned to +\fIjust before the EOF of the file just read\fR, since \fItar\fP stops +reading the file data before reading the physical EOF. Hence, an +\fImt\0fsf\fR will be required to position to the next file on the tape. +Any combination of \fIfsf\fP (forward skip file) or \fIbsf\fR (backward skip +file) operations may be used to position to a file on a 9 track tape. On a +some tape drives, it is safest to plan things so that only forward file +skips are used, using a rewind and forward skip if it is necessary to +position to an earlier file on the tape. +.PP +Once the main system, containing only sources, is installed it is possible to +create one or more empty BIN directories for the executables, then compile +and link the full system. More commonly one will merely read the precompiled +executables off the distribution tape, as we discuss in the next section. +.NH 3 +Configuring the BIN directories +.PP +In IRAF all the files specific to any particular software or hardware +architecture are contained in a single directory called the BIN, or +"binary", directory. To run IRAF you must install not only the \f(CWAS\fR +(all-sources) directory tree, but the BIN directory for each architecture +you wish to be able to run on. The IRAF core system and the NOAO packages +have separate BIN directories. +.PP +The BIN directories for the IRAF core system or a layered package (such as +NOAO) are located, logically or physically, in the root directory of the +IRAF core system or layered package. Every layered package has its own set +of BIN directories. In the distributed V2.10 system you will find the +following BIN files (directories or symbolic links) at the IRAF root. +.XS +link bin -> bin.generic +directory bin.generic +link bin.vax -> ../irafbin/bin.vax +link noao/bin.vax -> ../../irafbin/noao.bin.vax +.XE +.PP +If the IRAF directory structure is set up as described in \(sc2.1.2, with +$iraf located at iraf/iraf and the BIN directories stored in iraf/irafbin, +then these links will not have to be modified. If a different directory +structure is used you will have to modify the links accordingly. +.PP +The \fIbin\fR link and the \fIbin.generic\fR directory are required for the +correct operation of the IRAF system software (\fImkpkg\fR) and are +maintained automatically by the IRAF software management utilities. +\fIUnder no circumstances should "bin" or "bin.generic" be modified or +deleted\fR. It is a very common error to manually delete the bin link and +manually set it to bin.vax or some other architecture. The bin.vax link +can be modified as desired but bin and bin.generic should be left alone. +.PP +Assume that the bin.vax directory has been created somewhere (e.g. in the +iraf/irafbin directory) and that the \f(CWib.vxux.vax\fR distribution files +for the core IRAF system VAX binaries have been downloaded from the +network archive. We can restore the VAX binaries with the following +commands. +.XS +% cd $iraf/bin.vax +% cat /\fIpath\fP/ib.vxux.vax/ib.* | uncompress | tar -xpf - +.XE +Similarly, to restore the NOAO package VAX binaries: +.XS +% cd $iraf/noao/bin.vax +% cat /\fIpath\fP/nb.vxux.vax/nb.* | uncompress | tar -xpf - +.XE +This process is repeated for each architecture. In the case of a VAX Ultrix +system the standard IRAF distribution supports only the VAX architecture as +illustrated in the above examples. +.PP +The procedure for restoring a BIN directory from a tape distribution is +similar to that described in \(sc2.2.2 for the core system. For example, +.XS +% cd $iraf/bin.vax +% mt -f /dev/rmt0h rew; mt -f /dev/rmt0h fsf 2 +% tar -xpf /dev/rmt0h +.XE +would restore the core system bin.vax directory from a TK50 cartridge +containing an uncompressed \f(CWib.vxux.vax\fR as file 2 on the tape. + +.NH 2 +Merge local revisions back into the new system +.PP +If this is a new IRAF installation this step can be skipped. Otherwise, +once the new system has been restored to disk any local revisions made to +the previous IRAF installation should be merged back into the new system. +See \(sc2.1.1 for a list of the files most likely to be affected. +When propagating revisions made to these files, be sure to not replace the +entire file with your saved version, as the version of the file in the new +release of IRAF will often contain important additions or changes which +must be preserved. It is best to merge your revisions into the version of +the file which comes with the new IRAF.\(dg +.FS +\(dgThe UNIX utility \fIdiff\fP is useful for comparing files to see +what has changed. +.FE +This task will be easier if the revisions have been localized as far as +possible, e.g., keep all \f(CWtermcap\fP additions together at the head of +the file, so that they may merely be transferred to the new file with the +editor. The task of propagating revisions will also be much easier if +detailed notes have been kept of all revisions made since the the last +release was installed. +.PP +Beginning with IRAF version 2.8, one should no longer install locally added +software in the core system LOCAL package. This significantly complicates +updates and is no longer necessary as, due to the layered software +enhancements introduced in V2.8 IRAF, it is now straightforward for each +site to maintain their own custom LOCAL package external to the core IRAF +system. The core system LOCAL is now only a \fItemplate-local\fR to be +copied and used as the starting point for a custom LOCAL layered package. +The layered software enhancements, and the procedure for building a custom +LOCAL, are discussed further in the \fIUltrix/IRAF Site Manager's Guide\fR. + +.NH 2 +Run the INSTALL Script +.PP +Once all of the IRAF files have been restored to disk the Ultrix/IRAF +installation script must be run to complete the system installation. The +install script modifies the system as necessary to reflect the new root +directory and new default image storage and local bin directories, checks +the mode and ownership of a number of files, installs a small set of IRAF +commands in UNIX, and so on. +.LP +To make a trial run of the install script, enter the following commands: +.XS +% setenv iraf /\fIpath\fP/iraf/ +% cd $iraf/unix/hlib +% source irafuser.csh +% ./install -n +.XE +and answer the questions (don't forget the trailing `/' in the "setenv +iraf"). The "-n" argument tells install to go through the motions without +actually doing anything, so that one can see what will be done before +committing to it. +.PP +Installing IRAF requires a few changes to be made to system directories +outside the IRAF directory tree. Two fifo device entries are made in /dev. +A symbolic link "iraf.h" is created in /usr/include. A number of links (cl, +mkiraf, etc.) are made in /usr/local/bin or some similar directory which +most users can be expected to have in their search path. The tape +allocation task alloc.e is made suid root (there are no known security +loopholes, although we cannot make any guarantees). A symbolic link +imtoolrc is created in /usr/local/lib. +.PP +Following one or more trial "no execute" ("-n") runs to see what the install +script will do, the install script should be run without the "-n" to +complete the installation. This must be done by the superuser as superuser +permission is required to carry out the necessary additions to UNIX. +.PP +It is necessary to run the install script separately on each node from which +IRAF will be used. If a single version of IRAF is installed on a server and +NFS mounted on one or more clients, the install script must be run first on +the server and then on \fIeach\fR client (when installing on a client there +will be warnings about insufficient permission to make changes to files on +the NFS mounted partitions, which can be ignored). To install IRAF on a +diskless client it may be necessary to run the install script \fIon the +server\fR to do the install for the client, since the client's /usr/include +and /dev directories may only be writable by root on the server. On some +systems /usr is mounted read-only, and must be unmounted and remounted +read-write before doing the installation to allow an entry to be made in +/usr/include. Once the installation is complete the default mount access +mode may be restored. +.LP +The exchange with the install script will be along the lines of the +following. +.XS +% ./install -n +new iraf root directory (/iraf/iraf): +default root image storage directory (/d0/iraf): +local unix commands directory (/usr/local/bin): +install iraf for machine type vax +old iraf root = /usr/iraf, old imdir = /d0/iraf +installing iraf at /iraf/iraf, imdir=/d0/iraf, lbindir=/usr/local/bin +proceed with installation? (yes): +.XE +.LP +The "iraf root directory" is the value of $iraf (minus the trailing `/'in +this case). The "root image storage directory" is the default place to put +image data for users; the program may prompt with /tmp if it cannot find any +likely looking data storage areas on your system, but /tmp is not a good +place to put image data as the contents are deleted whenever the system +reboots. The value entered should be the path to a public iraf subdirectory +of a designated data or scratch disk on your system. Lastly, the "local +unix command directory" is where the UNIX callable IRAF startup commands +will be defined. This should be a UNIX directory which is in the default +path of anyone who might want to use IRAF; /usr/local/bin is the most common +value. +.PP +After answering with "yes" or hitting return in response to the "proceed with +installation" query, the script will issue a series of messages as it checks +the system and performs the installation, possibly answering additional +questions in the process. + +.NH +System Checkout +.PP +The basic IRAF system should be usable once the files have been restored to +disk, the binaries have been configured or generated, and the install script +has been run. To verify that the basic system comes up and runs +successfully, login as iraf and startup the CL (IRAF command language) from +the iraf account. You should be able to login as IRAF and type "cl" to +start IRAF, using the login files which come with the distributed system. +.XS +% login iraf +% cl +.XE +.LP +To more thoroughly test the installation it is a good idea to test IRAF from +a user account. To do this you login to a user account and run the +\fImkiraf\fR task to set up the IRAF login files. This will create or +initialize the user's \f(CWuparm\fP (user parameter) directory, and create a +new \f(CWlogin.cl\fP file. It may also be desirable to edit the +user's \f(CW.login\fP file to modify the way the environment variable +\f(CWIRAFARCH\fP is defined. This variable, required for software +development but optional for merely using IRAF, must be set to the name of +the desired machine architecture, in this case \fIvax\fR. +.XS +% mkiraf +Initialize uparm? (y|n): y +Terminal types: xterm,gterm,vt640,vt100,etc." +Enter terminal type: xterm +A new LOGIN.CL file has been created in the current directory. +You may wish to review and edit this file to change the defaults. +.XE +The \fIcl\fR command should now start up the CL, which will clear the screen +and print out a startup message. The standard test procedure included in +Volume 1A of the \fIIRAF User Handbook\fP should be run to verify the +installation. + +.bp +.SH +Appendix A. A Complete Example +.PP +Assume we are installing IRAF for the first time on a VAXstation running VAX +Ultrix. The IRAF directories will be located at /u3/iraf using a symbolic +link /iraf to point to this location. We will configure only vax binaries, +locating the BIN directories in the directory /iraf/irafbin. The local user +commands will be placed in /usr/local/bin. We will be installing from a +network distribution with the distribution files located in /scr0. +.PP +The first step is for the superuser to create an account for the fictitious +user `\f(CWiraf\fP', with home directory /iraf/iraf/local and shell +/bin/csh. The /u3/iraf directory is created owned by IRAF, and pointed to +by the link /iraf. We then login as IRAF (a warning message will be printed +since there is no login directory) and proceed as follows. +.XS +% whoami +iraf +% +% setenv iraf /iraf/iraf/ \fR# set root directory\fP +% mkdir /iraf/iraf +% +% cd $iraf \fR# unpack main IRAF distribution\fP +% cat /scr0/as.vxux.gen/as.* | uncompress | tar -xpf - +% +% cd /iraf \fR# create BIN directories\fP +% mkdir irafbin +% mkdir irafbin/bin.vax +% mkdir irafbin/noao.bin.vax +% +% cd $iraf/bin.vax \fR# unpack core bin.vax\fP +% cat /scr0/ib.vxux.vax/ib.* | uncompress | tar -xpf - +% +% cd $iraf/noao/bin.vax \fR# unpack NOAO bin.vax\fP +% cat /scr0/nb.vxux.vax/nb.* | uncompress | tar -xpf - +% +% cd $iraf/unix/hlib \fR# run the INSTALL script\fP +% source irafuser.csh +% ./install -n +% su +# ./install +# exit +% +% cd +% source .login \fR# read new .login\fP +% rehash \fR# pick up new iraf commands\fP +% cl \fR# verify that the CL runs\fP +.XE +.LP +This will fully install IRAF on a server or a standalone system. If this +version of IRAF will be accessed via NFS by client nodes then the IRAF +install script must be run on each client node as well. Installing IRAF +does not allow one to access local tape drives, printers, and so on. +Refer to the \fIUltrix/IRAF Site Manager's Guide\fR for information on how +to configure IRAF for the local site. -- cgit