When I try to make an IRAF plot on my screen all I get is garbage in my window. How can I get an IRAF plot?

 You need to be running from a window that is capable of displaying IRAF
graphics and have the window type properly identified in the CL.  If you
are running IRAF in a workstation environment then check to be sure that
you are running IRAF from either an XGterm or an XTerm window.  Other
terminal emulators (such as cmdtool, rxvt, aixterm, etc) on your desktop
do not support graphics.
The next step is be sure you have the value of your terminal type set
      cl> stty			       # reports current settings
      cl> stty xgterm nlines=###       # for XGterm
      cl> stty xterm nlines=###        # for XTERM, status line in
				       # graphics window
      cl> stty xtermjh nlines=###      # for XTERM, status line in
				       # text window
      cl> stty vt640                   # for retrographics terminal
Look at the dev$graphcap file for other valid terminal types if you are using
a standard terminal and not a workstation.

How is stty "xtermjh" different from a standard "xterm" window?

 They are identical except for the location of the status line, the single
line used within graphics applications for user input.  With xterm, this
line is written in reverse video at the bottom of the graphics window.  Since
xterm can't erase and overwrite this line, the status line is written to a
new location within the graphics window each time it is used, consuming
window space until the window is redrawn.  The xtermjh terminal type writes
the status line to the text window, leaving the graphics window entirely
free of status line i/o.  Most people using tasks that make even moderate
use of the graphics status line prefer the "xtermjh" setting.

Why can't I get vector graphics from AIX/IRAF in an AIXterm window?

	The AIXterm window is not a supported graphics terminal emulator,
users should use an XTerm window instead.  This requires that the X11rte.obj
product be installed (use the "lslpp -l" command t verify this).  Another
possible source of confusion is the fact that /usr/bin/X11/xterm is a symbolic
link which could be pointing to the aixterm executable.  If so this link
should be reset so it points to /usr/lpp/X11/Xamples/bin/xterm.  If a
graphics task results in garbage being written to the screen it is usually
a sign that the wrong terminal emulator is being run.

Are we limited to having a single SAOimage process running per CPU?

 	No, we have a workaround for this frequently encountered limitation.
By default, there is a single set of fifo pipes in /dev used for communication
with the DISPLAY task, limiting the number of successful SAOimage processes to
one per cpu.  (See IRAF Newsletter #11, April 1991, "Setting up Multiple Fifo
Pipes for [V1.02] SAOimage".)  However, SAOimage allows the user to specify a
set of personal fifo pipes to be used instead of the ones in the system /dev
directory.  For multiple SAOimage processes to run per CPU, the user must
create personal pipes and define the paths to these new pipes in a private
copy of graphcap as described below.
To create the personal pipes and graphcap file it is suggested you create
a subdirectory of your iraf login directory named 'dev' in which to put
the files.  A sequence of commands such as the following should be all that
is needed (note the location of the 'mknod' command may differ, on some
systems the 'mkfifo' command is preferred):
	% cd ~/iraf			# create the 'dev' subdirectory
	% mkdir dev
	% cd dev
	% /usr/sbin/mknod imt1i p	# create the fifo pipes
	% /usr/sbin/mknod imt1o p
	% chmod 600 imt1o imt1i
        % sed s+imtool,,+imtool,$cwd/imt1,+g $iraf/dev/graphcap > mygraphcap
The last command edits a personal copy of the graphcap file.
	To start up SAOimage with the "new" fifo pipes, use the following
command  with  appropriate  pathname  substitutions.  Note that the "idev"
to SAOimage  is  the  imt1o  pipe  (the SAOimage input is the DISPLAY task
   % saoimage -idev /mydir/dev/imt1o -odev /mydir/dev/imt1i &
To direct the CL to use your private copy of graphcap, put this line in your file:
   set graphcap = home$dev/mygraphcap
Note that the "saoimage" command above is valid for V1.07; earlier versions
of SAOimage require a "-imtool" inserted before the &.

Can I run multiple SAOimage processes simultaneously from my account?

	It is possible for a user to have multiple SAOimages running.  This
situation is not the same as multiple users each running SAOimage on the same
CPU.  That was addressed in an IRAF Newsletter article (INL #11, April 1991,
"Setting up Multiple Fifo Pipes for SAOimage") which is included in the prev-
ious entry of this FAQ listing.  There are similarities between the two
scenarios, so you should understand the NL article before continuing with
this discussion.  We assume you are running v1.06 or v1.07 of SAOimage.
	Say a user wants to have 2 SAOimage windows running and be able to
display to them independently from a CL session.  For each SAOimage process,
the user must provide the following 4 items: fifo pipes, saoimage aliases,
dev$graphcap modifications, and a private imtoolrc file.  In this example,
two SAOimages are defined, each recognizing 3 frame buffer sizes.
1) Create the fifo pipes, perhaps in /mydir/dev/devices where /mydir/ refers
   to the login directory of the user in this and the following items.  I
   will name the pipes imt1i, imt1o and imt2i, imt2o:
   % cd
   % mkdir dev
   % cd dev
   % /usr/sbin/mknod imt1i p
   % /usr/sbin/mknod imt1o p
   % chmod 600 imt1o imt1i
   % /usr/sbin/mknod imt2i p
   % /usr/sbin/mknod imt2o p
   % chmod 600 imt2o imt2i
2) Define two aliases for saoimage, specifying the personal pipes created
   above, perhaps in a .cshrc file (with idev, odev as defined above):
 % alias   saoimage1 'saoimage -idev /mydir/dev/imt1o -odev /mydir/dev/imt1i &'
 % alias   saoimage2 'saoimage -idev /mydir/dev/imt2o -odev /mydir/dev/imt2i &'
3) For each frame buffer size, make an entry in dev$graphcap with a unique
   name and proper fifo pipe specification in the DD string.  As the NL
   article recommends, copy dev$graphcap into /mydir/dev/mygraphcap and
   add a "reset graphcap = home$dev/mygraphcap" statement to your
   file.  In these sample graphcap entries, stdimage devices imt1, imt2, and
   imt3 use the imt1 fifo pipes with frame buffer sizes 512, 800 and 1024
   square respectively.  The devices imt61, imt62, and imt63 use the imt2
   fifo pipes with frame buffer sizes 512, 800, and 1024 square.
   imt1|imt512|imtool|Imtool display server:\
   imt61|imt512a|imtool|Imtool display server:\
4) Corresponding to each graphcap entry, make an entry in imtoolrc.  SAOimage
   looks for a user imtoolrc file defined in your environment (setenv imtoolrc
   or setenv IMTOOLRC), and if that's not found, ~/.imtoolrc is used.  If
   that's not found, /usr/local/lib/imtoolrc is used; imtoolrc was copied into
   this directory from dev$imtoolrc  by the install script.  So copy the
   original imtoolrc file in ~/.imtoolrc (for example) and edit it to include
   the following entries (entries 1-3 are unchanged from the original file):
 1  2  512  512         # imt1|imt512
 2  2  800  800         # imt2|imt800
 3  2 1024 1024         # imt3|imt1024
 # User added formats.
 61  2  512  512         # imt61|imt512a
 62  2  800  800         # imt62|imt800a
 63  2 1024 1024         # imt63|imt1024a
   SAOimage allows only 64 frame buffer configurations.  XImtool allows more
   and the distributed imtoolrc file has more than 64 entries.  To add your
   new entries, you'll have to clobber some of the first 64 entries and
   replace them with your own.  In this example, I redefined imt61-63.
And, that's all there is to it!  Start up saoimage1 and saoimage2, login to
the CL (with your graphcap redefined) and try displaying to imt1 and imt61.
One thing to watch for in debugging this is "zombie saoimage processes".  If
you interrupt the DISPLAY task with ^C and certainly in other ways, you can
end up with an SAOimage process running without a connected window.  If you
try to display and you get no output and no error, this may be the cause.
Use "ps -aux" to find the process and then kill it.

What do I do about "Warning libxxx.s.o older than expected"?

      This usually indicates a missing or insufficient definition for
the LD_LIBRARY_PATH host environment variable.  For example, on a Sun
system this may be set to simply '/usr/openwin/lib',  but if the application
in question was compiled under the local X11R5 system the missing shared
object may be in /usr/lib/X11 (or some other path).  In rare cases the missing
object is in the compiler directory (e.g. in /usr/lang/SC1.x under SunOS).
        To find out where the missing file is and reset the LD_LIBRARY_PATH
variable appropriately, try the following:
        % echo $LD_LIBRARY_PATH         # see what the current setting is
        % ldd `which saoimage`          # check dependencies
             -lX11.4 => /usr/openwin/lib/
             -lc.1 => /usr/lib/
             -ldl.1 => /usr/lib/
        % setenv LD_LIBRARY_PATH  /usr/lib/X11:/usr/openwin/lib
This last command reset the variable so both /usr/lib/X11 and /usr/openwin/lib
are searched for the needed file, the command should run normally after that,
the directories /lib, /usr/lib and /usr/local/lib are searched by default.