This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>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