Controlling Foreign Tasks with the IRAF cl

David L. Terrett

Rutherford Appleton Laboratory, Chilton, Didcot, Oxfordshire OX11 0QX, United Kingdom

Abstract:

1. Introduction

As astronomical data reduction packages have become larger and more complex it has become increasingly difficult for users to make use of more than one package. The barriers to using a second package include a new command language, a different look-and-feel to the applications and an unfamiliar documentation layout. This leads to ever-increasing duplication of functionality between packages as the users of any particular package demand that the full range of applications they require are available in their chosen environment in spite of the same applications already being available in other systems. Furthermore, by restricting their choice in this way they may not be using the best available algorithms for the job in hand. If the applications from other environments could be run from within the user's current environment the choice of applications would be wider and there would, perhaps, be less wasteful duplication.

The architectures of IRAF and the Starlink software environment are very similar in that they both have tasks which run as independent processes which are sent commands by the command language, and individual commands each have a set of named parameters. In view of these similarities we have attempted to construct an ``adaptor'' that enables the IRAF command language (cl) to load and control Starlink applications.

2. The Adaptor Process

The adaptor communicates with the IRAF cl using the clio protocol, and communicates with Starlink applications using the Starlink inter-process messaging system; to the cl it behaves like a normal IRAF task and to the Starlink application it appears to be a command language (Figure 1). It is written in tcl, which has been extended to include commands for sending and receiving messages with both messaging systems.

 
Figure 1: IRAF/Starlink adaptor architecture.

2.1. The clio Protocol

The IRAF cl (as implemented on UNIX) communicates with a task by reading from and writing to the task's standard output and standard input. Each message has a 2 byte header, a 2 byte byte count and then the message itself as a stream of 2 byte characters. This protocol is implemented in os$zfiopr.c. Anything the task writes to its standard error stream will be written to the terminal window running the cl and can be used for debugging output.

3. Typical cl/Task Dialog

A task is loaded the first time one of the commands it supports is used and the cl sends it a series of set commands to set the task's environment. For example,

set editor=vi
set clobber=no
set host=/iraf/iraf/unix/
set iraf=/iraf/iraf/

chdir rlssp0!/home/user/dlt/

_go_

A typical command looks like:

cadd in=comwest label="Kappa - Cadd" mode='ql' $nargs=0

The adapter now sends all the parameter values to the Starlink application, followed by the instruction to start executing the command. The adaptor now switches to waiting for messages from the task. In the case of Starlink applications, the sorts of messages that can be expected are:

• Requests to display some text to the user. The adapter passes the request to the cl by sending a command of the form:

  xmit(4,13)Message text\n
  

  The first number specifies that the message should be written to standard output and the second is the number of characters in the message.

• Requests for parameter values. Parameter values can be obtained from the cl by sending, for example:

  =out
  

  where out is the name of the parameter. The cl will prompt the user if necessary and reply with a message containing the parameter value.

• A termination message. When the application has finished processing the command the adaptor must send a message to the cl consisting of either:

  bye
  

  if the command was successful or:

  error(1,"Error text")
  

  if it failed.

Once a ``bye'' or ``error'' command has been set to the cl, the adaptor reverts to waiting for the next command from the cl. This can be any of the messages discussed so far or ``bye'' which is a signal to the adaptor to unload the application task and exit.

4. Interacting with the Parameter System

A task can interact with the parameter system in a number of ways in addition to simply retrieving the values of parameters.

A parameter's value can be set by sending, for example:

in=comwest

The various parameter attributes can be obtained by, for example:

=in.p_type

It is also possible to change some parameter attributes (but not p_name, p_type or p_xtype), but the changes may not have the desired effect while a task is active. Also, the storage for the prompt string ( p_prompt) is allocated when the task's parameter file is read and cannot be increased.

5. Signals

The adaptor must also handle the SIGTERM signal that the cl sends to a task when the user attempts to interrupt a task by typing Control C. The cl expects the task to respond with an ``error'' command and return to a state where it is ready for another command to the cl. If this is impossible, it is acceptable for the adaptor to exit after sending the ``error'' command; when the next command is typed, the cl will report that the task has died unexpectedly and re-load it.

Acknowledgments:

I would like to thank Doug Tody, NOAO, for encouraging me to embark on this project, describing the clio protocol for me and answering my many questions about the internal workings of IRAF.

¹The value of p_type is not necessarily the same as the type field in the parameter file; for example. ``file'' is changed to ``string'' by the cl.