20010119: RTNEXRAD ADDE service messed up with addition of GINI datasets

>From: Eirh-Yu Hsie <address@hidden>
>Organization: CU/CIRES
>Keywords: 200101161904.f0GJ4se05380 McIDAS ADDE

Hsie,

I still have not figured out the remote ADDE services problem on
cumulus, but I did figure out the problem that you ran into when using
the Fkey menu to display NIDS images.

The menu does not have a problem.  What was going on was that the
NEXRAD listing server was exiting when it found an empty directory
during the searches for a list of valid stations when using the ID=LIST
option. i.e., the following was failing:

IMGLIST RTNEXRAD/N0R ID=LIST

/wrk/data/nexrad/GUA/N0R|N0V|NCR|etc are all empty directories.  The
server generated a list of station names that should have files and
then was descending into each directory looking for a list of files.
Instead of simply eliminating a station from the list of available
stations for a particular product type, it was exiting with an error.
The implicit, incorrect assumption was that all directories found
matching /wrk/data/nexrad/\ID/\TYPE would have files.  In the case of
/wrk/data/nexrad/GUA/N0R, this was not true.

I fixed the code on stratus and reinstalled the nexradir and nexraget
executables.  I then tested getting a list of available stations from
stratus in my McIDAS session running at home both by running:

IMGLIST RTNEXRAD/N0R ID=LIST

from the command line and by using the Fkey menu to do the same.  Both
work as they should now.

The reason you never saw a problem running IMGLIST was that you were
asking for a list of files for a particular station, say FTG:

IMGLIST RTNEXRAD/N0R ID=FTG

Since FTG was reporting N0R products, the listing worked.

I will continue to ponder the remote ADDE server failure on cumulus
and let you know if I come up with anything.

Tom