This file is C$DOC:CDFSGA_BAD_IDEAS.NOTE



We have found that running the program
   > xlock
which is a pretty screen saver program, 
is a bad idea on cdfsga.  This screen
lock consumes almost one full CPU while running.



We have also found that running the programs
   > xterm
or 
   > xwsh 
which are terminal emulation programs, 
is a bad idea on cdfsga.   The problem with xterm and xwsh
is that each keystroke must go from your desk over
to the Feynman Center and back again.  It is
far better to run a terminal emulation on the
workstation on your desk, or on the Xterminal on
your desk.   If this is not possible, running
terminal emulation on a machine in the trailers
is still far better than using cdfsga.

People using xterm or xwsh on cdfsga almost invariably 
complain that "cdfsga is slow", when in fact
the problem is shipping all these packets back
and forth.


Clearly, running
   > mwm
The Motif Window Manager
from cdfsga is even a poorer idea than running xterm
(see paragraph above) for the same reasons.

It is far better to run a window manager on the
workstation on your desk, or on the Xterminal on
your desk.   If this is not possible, running
window manager on a machine in the trailers
is still better than using cdfsga.


Similarly, it is better to run Mosaic or Netscape on a workstation
in the trailers instead of on cdfsga.


And clearly, it is better to run xclock or clock on
a UNIX workstation in the trailers, rather than on
cdfsga.




It is neither necessary nor desirable to specify
that the 8mm tape not be unloaded on cdfsga.  That is,
     ANA>> Tape Dismount/Nounload              <- (don't use this)
is not a good idea.   It leaves the tape door closed, which
makes it hard for the operators to put in the next tape.
Instead please use
     ANA>> Tape Dismount                       <- (use this)
except in rather special circumstances.



As 8mm tapes are not perfectly reliable, it might be
best to read just one tape per job.  Reading many
tapes in a single job can be highly problematic.



We have found that replacing an executable with an
updated version while a job is running can lead
to unpredicible results.  Most often, the
running job will terminate with the laconic message 
"Killed".




We have found that issuing a global search similar to: 
> find / -name qsub -print
is not a good idea, as this searches all the disks on 
the system, and all the NFS mounted disks as well.

A better idea is 
> find /an/appropriate/directory -local -name qsub -print



We have found that putting a line similar to 
set path = ( $USR_SCRATCH/rebcdf )
in the .login file is not a good idea, as then one can no longer 
find most of the utilities.  

A better way is to ADD to the path, in a manner similar to
set path = ( $path $USR_SCRATCH/rebcdf )



The command
   > limit coredumpsize 0
causes no core file to be produced, which greatly increases
the difficulty of problem debugging.   If you would like
someone to help you debug your program, please don't
inhibit the core dumps.