diff options
Diffstat (limited to 'doc/news.old.hlp')
| -rw-r--r-- | doc/news.old.hlp | 199 |
1 files changed, 199 insertions, 0 deletions
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 |