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

20051024: TXTGSERV problems



>From:  Don Murray <address@hidden>
>Organization:  UCAR/Unidata
>Keywords:  200510242331.j9ONVY7u025400 McIDAS ADDE SATBAND remote read

Hi Don,

re:
>I've looked into this a little more, looking at the trce
>logs on motherlode and atm.  When I do the request to
>motherlode, the server thinks it's sending out the data, but
>on the client side, i'm not getting it back.

Interesting...

>The only system this seems to be a problem on is the new
>motherlode.  If I point to oldmotherlode and papagayo
>(which are presumably running the same versions as the
>new motherlode), everything seems to work.

papagayo is running v2005; the old motherlode is not.

Please try atm.geo.nsf.gov.  It is running the same version
of the OS as the new motherlode.

>I'm wondering if this is an OS thing?

I would doubt that it is an OS thing since atm.geo.nsf.gov is
running the same version of Solaris as the new motherlode.
I am wondering if it could be the firewall setup on the new
motherlode.  I will need to talk to Mike about this tomorrow.

Cheers,

Tom

Date: Tue, 25 Oct 2005 07:27:53 -0600
From: Don Murray <address@hidden>

Hi Tom-

Tom Yoksas wrote:

> papagayo is running v2005; the old motherlode is not.
> 
> Please try atm.geo.nsf.gov.  It is running the same version
> of the OS as the new motherlode.

atm works fine.  The only one that is a problem is the
new motherlode.

> I would doubt that it is an OS thing since atm.geo.nsf.gov is
> running the same version of Solaris as the new motherlode.
> I am wondering if it could be the firewall setup on the new
> motherlode.  I will need to talk to Mike about this tomorrow.

I only have problems reading text data.  Since m0sxsend is just
pushing bytes down the socket, I would think that if it was
a firewall issue, I wouldn't get any other data since they
all use that to send the data.

Drop by when you get in and we can talk about this more.

Don

PostScript:

It turns out that the problem was in the GetTextData procedure in
txtgserv.cp.  The variables 'len_line' and 'flipped_val' had been
declared to be of type 'size_t' even though they are both used as
arguments to M0sxsend which expects an 'int'.  The import of this error
is that 'txtgserv' would _never_ work on a 64-bit, big-endian OS!

Tom