[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20051024: TXTGSERV problems
- Subject: 20051024: TXTGSERV problems
- Date: Mon, 24 Oct 2005 22:08:40 -0600
>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