STScI Logo

networking stsdas.sobsolete



networking -- Description of IRAF Networking


IRAF has the ability to transfer files, display images, and access devices such as tape drives, on one computer host from another in a local area network. IRAF networking can be used with most any IRAF/STSDAS task because the networking capability is part of the Virtual Operating System, upon which all IRAF tasks are layered. HOWEVER, file access between hosts with incompatible architectures (like Unix machines vs. VMS VAXes) will NOT generally be possible unless the files are stored in a machine-independent format. (The exceptions are the tasks in the `stsdas.toolbox.convfile' package, which are specifically designed for transferring images and binary TABLES across machine architectures.) Note that OIF (.imh) and GEIS (.hhh) images and binary TABLES are stored in the native machine format, so accessing such images or tables WILL NOT work UNLESS the local and remote hosts are both Unix, or both VMS, etc. FITS (.fit), pixel list (.pl), and ASCII files ARE machine independent, so numerical compatibility is not an issue in these cases.

The user must have a login on each machine to which IRAF networking is needed, and IRAF V2.10.2 or later (or at least the IRAF Kernel Server) must be installed on these machines. It is also necessary that the IRAF site manager create a set of files in the "dev$" directory which contain, among other things, the names of all the nodes on the network; these files must reside on all the servers in the network. To see if your machine is in this list, run the `netstatus' task. If it is not listed, it must be added before you can use IRAF networking.


To use the networking facility, you need to have a file named ".irafhosts" in your login directory on EACH cluster to which you wish to network. This file tells the IRAF networking system how to connect to the IRAF kernel server on a remote node. To obtain a copy this file "cd" to your system login directory, and type:

	cl> copy dev$irafhosts ./.irafhosts 

The contents of this file are machine dependent. For Suns and other Unix machines, it is:

	port = default
	auth = default
	hiport = default
	timeout = default
	*	: <user> <user>		# host list

For VAXes, only the host list is used. For Unix systems, the networking parameters are set automatically by the networking system and should rarely need to be modified by the user. PORT may be set to "none" to prevent the use of networking daemons, or to an explicit TCP port number if the default value generated by the networking code cannot be used for some reason. AUTH is an authorization code used to prevent unauthorized access to your networking servers. The value is "default" initially but is filled in by the networking system when networking is first used. For maximum efficiency, AUTH should be the same on all hosts (after using networking for the first time copy the .irafhosts file to your other local hosts). Each user should have a unique AUTH value (the value provided by the system ensures this). HIPORT is used by the networking code to generate PORT. TIMEOUT is the time in seconds after which an idle networking daemon will shut down.

The syntax of the host list is "hostname : loginname password". There should be one host per line, with the last hostname set to "*" (i.e, match any host). The loginname should be "<user>" (use your local login name), an explicit login name, or "none" to disable networking for that host. The password can be "<user>" (use your local password), and "?" to be queried for the password at run time. If an explicit password is given the REXEC protocol is used, otherwise RSH is used. However, placing your password in this file (to avoid being prompted) presents a glaring security risk! Usually, you will get a prompt only once for each IRAF session per remote machine per task.


Most users have a "LOGIN.COM" file in their root directories so that various system logicals, aliases, etc., are defined during the login procedure. However, it is important to realize that this command file will be executed for non-interactive sessions as well, including IRAF networking. Therefore it is important to bypass those portions that would conflict with a network process. Users should place the following lines in their "LOGIN.COM" file:

	! < first line of LOGIN.COM: >

	!	:
	! < contents of LOGIN.COM file >
	!	:

	! < set logicals for IRAF: >

If "IRAF" is not in the system symbol table, you can define the logicals explicitly by replacing "IRAF" line with one like: "@DISK$STSDAS:[IRAF.VMX.HLIB]IRAFUSER.COM". Note that the name of the disk and/or the pathname may be different for your site.

The VAX machine must be running MULTINET if access from UNIX machines is desired. Network access via DECNET -- i.e., to another VAX on the same cluster -- is also possible, in which case you can substitute "none" for "<user>" in your host list to avoid being prompted for your password. That is, access by user "kilroy" to the node "AIRY" from "AVION" (if both are VAX machines) would be accomodated in your AVION host list as:

	airy	: kilroy none


When referring to files on remote machines, use the syntax <node>!<pathname>. The pathname for the remote host and directory can be referred to with IRAF environment variables. This is usually good practise (it helps to avoid typo's), but it is often necessary for IRAF networking because wildcards in file names are NOT expanded if the path begins with a node name. Simply append the "$" character to the environment variable and use it in place of the "node!pathname" syntax.

The pathname is machine-specific, and would look something the following:

To refer to a Unix machine:
	cl> set sd = sol!/sol/data1/kilroy/galaxies/

Please note the trailing "/" !  For a VAX machine:
	cl> set vd = avion!disk\$data1:[kilroy.galaxies]

Note that special CL characters, such as "$" and "[", must be escaped with a backslash (\).


As mentioned, most IRAF/STSDAS tasks can be used in conjunction with IRAF networking. What follows are a few of the most common tasks that could make use of networking.

1. This example is both routine, independent of the local host machine type, and useful for determining whether IRAF networking is functioning properly. Obtain a directory listing of all the images on the remote UNIX machine "sol", in the directory "/sol/data1/kilroy/galaxies".

	cl> set sd = sol!/sol/data1/kilroy/galaxies/
	cl> dir sd$*.??h

2. Display an image on the local SUN machine "sol" that is stored on the remote VAX disk "AVION::disk$data1:[kilroy.galaxies]" in a MACHINE INDEPENDENT FORMAT file called "M51.FIT". Note that the image display server (e.g., SAOImage) must be running in a window of the local Sun host.

	cl> set vd = avion!disk\$data1:\[kilroy.galaxies]
	cl> display vd$ 1

3. Log in to a VAX host through a window on the local Sun "sol", display an image on the SUN machine that is stored (on the remote VAX host) in a GEIS-format file called "M51.HHH". This assumes that the image display server is running in a window of the Sun host. Note that the byte-order of the native host file is immaterial in this case, since the display buffer is of type "byte".

	cl> reset node =
	cl> display m51.hhh 1

4. Determine the status of the tapedrive "mta" on the remote Sun machine "ra" from a local VAX machine.

	cl> devstatus ra!mta
	device ra!mta is not currently allocated
	tape position for ra!mta is undefined

5. Tranfer all images beginning with the letter "v" from the remote SUN machine "sol" to the local directory on another Sun. The pixel files for the OIF-format (.imh) images will be created in the "imdir" directory. Notice that the local directory is specified with a "." (i.e., a period). WARNING: this will NOT work between a Sun and a VAX unless the files are in machine-independent format!

 	cl> set sd = sol!/sol/data1/kilroy/galaxies/
  	cl> gcopy sd$v*.??h .

6. Tranfer all images beginning with "v" from the local Sun host to the remote VAX host "AVION". Both GEIS (.hhh) and OIF images will be transferred, and pixel files for the `.imh' files will be created in the same directory as the header file (HDR$).

   st> set dvax = scivax!disk\$data1:\[kilroy.galaxies]
   st> sun2vax  v*.??h  dvax$


Very often, when IRAF is unable to establish a connection to a remote machine, the message is obscure or incorrect. For example, if the .irafhosts file is absent or incorrectly set up, an attempt to use IRAF networking may generate the message "no files found". It is generally a good idea to first use the "dir" command to be sure that IRAF can "see" the files in question, before attempting to access them over the network.


devices, devstatus, netstatus, sun2vax, tconvert, vax2sun

Type "help geis" for more information about GEIS format files.

Source Code · Package Help · Search Form · STSDAS