[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20011008: Unidata ADDE sites

>From:  Tom Whittaker <address@hidden>
>Organization:  SSEC
>Keywords:  200110081413.f98EDe114987 Unidata cooperating ADDE servers

Dave,

I would like to alter Tom's list and add the list of Unidata cooperating 
servers:

>The ones that come up in the Java image-fetching GUI are:
>
>adde.unidata.ucar.edu
>suomi.ssec.wisc.edu
>motherload.ucar.edu
>uwamrc.ssec.wisc.edu

Since one has the tendency to think of these in some sort of order, I
would rather the list be:

- standard sites -
papagayo.unl.edu       (community site)
cacimbo.ggy.uga.edu    (community site)
stratus.al.noaa.gov    (community site)
snow.plymouth.edu      (community site)
adde.ucar.edu          (UCAR site, aka motherlode)
twister.millersv.edu   (community site, not yet announced)
weather.admin.niu.edu  (community site, not yet announced)

- non-standard sites -
io.sca.uqam.edu        (community site)
uwamrc.ssec.wisc.edu   (SSEC/AMRC site)
suomi.ssec.wisc.edu    (SSEC/CIMSS site)

A number of Unidata sites are running the remote ADDE server, but have
not (yet) agreed to participate in the list of cooperating servers
for the Unidata community.

>you MUST use the PUBLIC.SRV file and NOT the RESOLV.SRV if you are groping
>these sites.

This is not entirely true for my McIDAS MCGUI.

>That is the agreement, since it gives the site admins control
>over what is exposed -- now if I could only get the Data Center to sign up...

Right.  The PUBLIC.SRV list approach can be useful.

>I know there are a few others that Tom oversees, that show up in their
>GUI...but I don't know about the *.SRV situation on those machines....

The primary machines should be setup with the PUBLIC.SRV file.  The newer
sites may not be setup, or at least they may not be setup correctly.

Tom

>From address@hidden Mon Oct  8 09:05:42 2001
>CC: Tom Whittaker <address@hidden>, Todd Smith <address@hidden>,
>   address@hidden
>Subject: Re: 20011008: Unidata ADDE sites

Thanx guys!

One missing link for us.....how do you read the PUBLIC.SRV file?

dave

From: Tom Whittaker <address@hidden>
Date: Mon, 08 Oct 2001 10:13:41 -0500
To: address@hidden
CC: Tom Yoksas <address@hidden>
Subject: Re: 20011008: Unidata ADDE sites

Why, we use ADDE ;-))  [Seriously, that's how I do it...just make a text
request for this file...and I think that's the way it should happen...]

tom

p.s. I must also add that the Java-based GUI will also read RESOLV.SRV, but
requires that the user know the datagroup name (which they must type in, they
will not be prompted by a list like they are when the info comes from
PUBLIC.SRV) before being able to do anything else.  This allows people who have
accounts on "closed" servers to still access the data.  BTW, if the initial
read fails for "invalid accounting", then a window pops up asking for a valid
name/proj number combo, which is then appended to subsequent requests.  This
seems like a reasonable way to handle this.

-- 
Tom Whittaker (address@hidden)
University of Wisconsin-Madison
Space Science and Engineering Center
Phone/VoiceMail: 608/262-2759
Fax: 608/262-5974


>From address@hidden Mon Oct  8 09:47:36 2001
>Subject: Re: 20011008: Unidata ADDE sites

Dave:

Turns out the debug output is easy.  Here's what it looks like.  Perhaps the
key is spelling out the word NULL?:

Service = [B@25ab41
uCmd=debug=true&file=public.srv
NULL NULL FILE=PUBLIC.SRV VERSION=1
numBinaryBytes= 0
byte #0 = 78 = N
byte #1 = 85 = U
byte #2 = 76 = L
byte #3 = 76 = L
byte #4 = 32 =
byte #5 = 78 = N
byte #6 = 85 = U
byte #7 = 76 = L
byte #8 = 76 = L
byte #9 = 32 =
byte #10 = 70 = F
byte #11 = 73 = I
byte #12 = 76 = L
byte #13 = 69 = E
byte #14 = 61 = =
byte #15 = 80 = P
byte #16 = 85 = U
byte #17 = 66 = B
byte #18 = 76 = L
byte #19 = 73 = I
byte #20 = 67 = C
byte #21 = 46 = .
byte #22 = 83 = S
byte #23 = 82 = R
byte #24 = 86 = V
byte #25 = 32 =
byte #26 = 86 = V
byte #27 = 69 = E
byte #28 = 82 = R
byte #29 = 83 = S
byte #30 = 73 = I
byte #31 = 79 = O
byte #32 = 78 = N
byte #33 = 61 = =
byte #34 = 49 = 1
server is sending: 4 bytes
Status = OK
N1=IMAGES,N2=ANTARCTIC,TYPE=IMAGE,RT=N,K=AREA,R1=190,R2=199,C=Antarctic IR
Compo
site,
N1=IMAGES,N2=EDFLOATER-I,TYPE=IMAGE,RT=N,K=AREA,R1=160,R2=169,C=Educational
Floa
ter,
N1=IMAGES,N2=EDFLOATER-II,TYPE=IMAGE,RT=N,K=AREA,R1=60,R2=69,C=Educational
Float
er II,
N1=IMAGES,N2=MOLL-IR,TYPE=IMAGE,RT=N,K=AREA,R1=100,R2=109,C=Mollweide Composite
IR,
N1=IMAGES,N2=MOLL-WV,TYPE=IMAGE,RT=N,K=AREA,R1=110,R2=119,C=Mollweide Composite
-- 
Tom Whittaker (address@hidden)
University of Wisconsin-Madison
Space Science and Engineering Center
Phone/VoiceMail: 608/262-2759
Fax: 608/262-5974

>From address@hidden Mon Oct  8 09:55:05 2001
>Subject: Re: 20011008: Unidata ADDE sites

Actually, the key seems to be that there is no way in
core McIDAS to send a FILE= as part of the text request [using
the READ command].

TomY....have you written a McIDAS program to do this?

dave

>From address@hidden Mon Oct  8 11:39:18 2001
>Date: Mon, 08 Oct 2001 11:39:17 -0600

Dave,

>Actually, the key seems to be that there is no way in
>core McIDAS to send a FILE= as part of the text request [using
>the READ command].

Right.

>TomY....have you written a McIDAS program to do this?

I have one laying around somewhere, but I havn't been able to put my
finger on it yet.  I will let you know when I find it.

Tom