[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

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.