19990113: ADDE Config Problems

>From: Bryan Rockwood <address@hidden>
>Organization: .
>Keywords: 199901140557.WAA05876

Bryan,

Sorry it took so long to respond, but I was at the AMS convention in
Dallas last week.

>Evening and hello.  I am writing with some problems and a question or two.
>First, the problem.  Over the break, our LDM box took a big hit and died a
>sad death.  I suppose this was a good thing as it gave me an excuse to
>completely redo the ingest system on the server.  The LDM is now better
>then ever with all data coming in smoothly.

Excellent.  I'm glad to hear that this went smoothly.

>I then went to install the
>ADDE server for the first time (by the first time, I mean to use to serve
>data as opposed to NFS).  I downloaded the latest source and compiled away
>with no problems what so ever.  I then installed the ADDE as root for user
>mcadde and went on from there.  Next came configuring the two client
>machines for use which I was able to get them up with simple redirects.
>Now, the problem.  I have configured the ADDE server to the best of my
>ability (creating the redirects, running LSSERVE.BAT, all that), When
>I do run LSSERVE.BAT, I can get the listing of the aliases in DSSERVE
>LIST, but when I do a DATALOC LIST, I don't get a listing of local data.
>Further, when I go to one of the clients and do a manual DATALOC ADD and
>point it to whistler.creighton.edu (or even 147.134.145.13), it will pop
>up and say done, but no listing for the aliases.  Any info would be
>appreciated, or you could even poke around if you would like!

I did pinpointed the problem with the following simple test:

/home/mcidas/% telnet whistler.creighton.edu 500
Trying 147.134.145.13...
Connected to whistler.creighton.edu.
Escape character is '^]'.
/home/mcidas/bin/mcservsh: 
/home/mcidas/workdata:/home/mcidas/data:/home/mcidas/help: No such file or 
directory

This told me that there was a problem in your .mcenv file (/home/mcidas/.mcenv).
I logged onto your machine and found the problem:

[mcidas@whistler]$ cat .mcenv
umask 002
MCHOME=/home/mcidas
MCDATA=${MCHOME}/workdata
MCPATH= ${MCDATA}:${MCHOME}/data:${MCHOME}/help
MCGUI=${MCHOME}/bin
MCTABLE_READ="${MCDATA}/MCTABLE.TXT;${MCHOME}/data/ADDESITE.TXT"
MCTABLE_WRITE="${MCHOME}/data/ADDESITE.TXT"
PATH=${MCGUI}:$PATH:/usr/sbin
export MCDATA MCPATH MCGUI MCTABLE_READ MCTABLE_WRITE PATH
cd $MCDATA

The line defining MCPATH has a space after the '='.  This is a no-no in
the Bourne shell.  The fix was simple: edit .mcenv and remove the unwanted
space.

Now I can list out information on your setup using ADDE commands:

DATALOC ADD RTIMAGES whistler.creighton.edu
DSINFO IMAGE RTIMAGES

        Dataset Names of Type: IMAGE in Group: RTIMAGES

Name         NumPos   Content
------------ ------   --------------------------------------
ANTARCTIC       10    Antarctic IR Composite
EDFLOATER-I     10    Educational Floater
EDFLOATER-II    10    Educational Floater II
GE-IR           10    GOES-East North America IR
GE-IRTOPO       10    GOES-East IR/TOPO Composite
GE-VIS          10    GOES-East North America VIS
GE-VISTOPO      10    GOES-East VIS/TOPO Composite
GE-WV           10    GOES-East North America H2O
GEW-IR          10    GOES-East/West IR Composite
GEW-IRTOPO      10    GOES-East/West IR/TOPO Composite
GEW-VIS         10    GOES-East/West VIS Composite
GEW-VISTOPO     10    GOES-East/West VIS/TOPO Composite
GEW-WV          10    GOES-East/West H2O Composite
GW-IR           10    GOES-West Western US IR
GW-IRTOPO       10    GOES-West IR/TOPO Composite
GW-VIS          10    GOES-West Western US VIS
GW-VISTOPO      10    GOES-West VIS/TOPO Composite
GW-WV           10    GOES-West Western US H2O
MDR             10    Manually Digitized Radar
MDRTOPO         10    MDR/TOPO Composite
MOLL-IR         10    Mollweide Composite IR
MOLL-IRTOPO     10    Mollweide IR/TOPO Composite
MOLL-WV         10    Mollweide Composite H2O
RESFLOATER      10    Research Floater

DSINFO -- done

IMGLIST RTIMAGES/GE-IR.ALL
Image file directory listing for:RTIMAGES/GE-IR
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  G-8 IMG       18 JAN 99018  14:15:00    23   71 4
   2  G-8 IMG       18 JAN 99018  15:15:00    23   71 4
   3  G-8 IMG       18 JAN 99018  16:15:00    23   71 4
   4  G-8 IMG       18 JAN 99018  17:15:00    23   71 4
   5  G-8 IMG       18 JAN 99018  18:15:00    23   71 4
   6  G-8 IMG       18 JAN 99018  09:15:00    23   71 4
   7  G-8 IMG       18 JAN 99018  10:15:00    23   71 4
   8  G-8 IMG       18 JAN 99018  11:15:00    23   71 4
   9  G-8 IMG       18 JAN 99018  12:15:00    23   71 4
  10  G-8 IMG       18 JAN 99018  13:15:00    23   71 4
IMGLIST: done

IMGDISP RTIMAGES/GE-IR STA=KDEN EU=IMAGE MAG=2 REFRESH='EG;MAP H'      
Beginning Image Data transfer, bytes= 81140                            
IMGDISP: loaded frame  1                                               
EG;MAP H                                                               
IMGDISP: done                                                          
Erased graphic frame(s) 1-1                                            
MAP: completed frame  1 

So, now remote access to at least the RTIMAGES dataset appears to work.

>Another question posed by one of the profs here is if there is a way to
>make the images full screen.  Maximizing just gets the same image with the
>grey background.  He was just curious.

One can start a McIDAS-X session with whatever sized frames that one
wants AND has system resources for (e.g. memory and swap).
Additionally, one can set aside memory on startup (using the '-e' flag)
so that s/he can create new frames on the fly, again of whatever size
that is desired.  After you have a frame as large as you want/need, you
can load an image so that it fills the frame.  If the question was if
McIDAS can resize the frame on the fly and have the image redisplayed,
the answer is no.  This has to do with McIDAS' basic design as an image
analysis tool, and not just an image visualizer (i.e. images in McIDAS
are not just "wallpaper").

>Yet another question.  The campus computer guys sent out a query a
>little while ago about the Internet 2 stuff and if there was enough
>interest on campus.  I was curious if the IDD would be available through
>the I2, or if that was going to stay the way it is now.  We would like
>to get more data, but our split T1 just can't handle all the traffic.

The IDD works through whatever TCP/IP network connection that you have.
Most of the toplevel redistribution machines are now on the VBNS, which
is the precursor for the I2.

>The last one and I know you are asking, "Does this guy every shut up?"

No, you can't learn without asking (or by reading a lot of source code).

>In all my prep for the ADDE stuff, I have the NIDS data decoding to
>separate files like the online docs say for ADDE and NIDS, you know,
>/var/data/ldm/nexrad/BREF1/20/9901141015.OAX.wsi (LDM is REALLY cool that
>way).

OK, we do that also.

>Since I throw it through the FILE action, it has stopped
>documenting through the ldmd.log file.

I guess that I don't understand this comment: "documenting"?  Do you mean
that your LDM log files are no longer recording information about products
being received?  If so, you could up your logging level by sending the
LDM process 'pqact' a USR2 signal:

kill <pid> -USR2

>Creighton's I'net connection has
>been real bad lately and I have been using the log file to keep track of
>the broken files to know whether to increase or decrease the amount of
>data coming in.  An idea would be appreciated.  As always, I bow before
>your technical might!

If I am off on interpreting your comment above regarding LDM logging,
please let me know.

Tom Yoksas