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: "Corcoran, William T" <address@hidden> >Organization: Missouri State University >Keywords: 200508291349.j7TDnujo003962 McIDAS ADDE Hi Bill, re: need to touch base with your IT folks >OK. I have set some wheels spinning with IT. Please see below for new developments... >I have also trashed around with some of your examples on telneting to 80 >or 500. > >From long ago, pagagayo.unl.edu was our backup server...same result, >refused on port 500 (open on 80). Yup, I tried papagayo also. >So I looked at the web-page you have of community data servers. I was >able to get port 500 at weather3.admin.niu.edu and stratus.al.noaa.gov, >but not others, atm.geo.nsf.gov for example. Interesting. I only tried adde.ucar.edu, atm.geo.nsf.gov, and papagayo.unl.edu. Since access to all of these failed, I didn't check any further. >I could get into ice and unidata2 but not amrc at ssec. OK. >So, I changed DATALOC hosts and fired up some mcidas stuff off >weather3.admin.niu.edu. It, of course, works. So, in one sense things >are working. Well, weather3.admin.niu.edu is currently bandwidth constrained, but this situtation is due to change at the beginning of December when NIU's Internet connection gets upgraded to a Gbps connection to Internet2. Then, the access to weather3 will be nice and fast. >At this point, I have lower-level (not our networking specialists) >perplexed on why some machines are open and not others. > >I just wondered if you cared to speculate? Hmm... maybe the difference is which server's ADDE access has been configured to run with McIDAS v2004/v2005. The difference is that v2004 was distributed to work on any of ports 112, 500, and 503. v2005 _only_ supports use of port 112. I installed McIDAS v2005 on adde.ucar.edu, atm.geo.nsf.gov, and papagayo.unl.edu and configured the remote ADDE server on each of them to support port 112 only. I also did the installation on weather3.admin.niu.edu, but I have not yet redone the remote ADDE server configuration for v2005. I am in the process of updating unidata2.ssec.wisc.edu, so the remote server on it is still setup to support transfers on ports 500 and 503. I am sorry that this did not dawn on me before this moment: I think that your problem is that the newer servers are only talking on port 112, and your distribution only talks on ports 500 or 503. Now _I_ feel dumb for overlooking this! Tell you what... I will change the configuration on adde.ucar.edu and see if I can access it from cumulus... Nope, that wasn't it. Wait a minute, adde.ucar.edu's firewall is setup to not allow access on ports 500 and 503... That was it. I can now access adde.ucar.edu from cumulus. So, the bottom line is that the problem was not some configuration at your university/department, but versionitis in tryint to access the new ADDE server from an old version of McIDAS. Now what we need to do is get you upgraded to a current distribution of McIDAS. As I finish this note I see that cumulus is now accessing data on adde.ucar.edu. Not much yet, but it should go smoothly from now on. I apologize for not thinking of the version problem earlier! Cheers, 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. >From address@hidden Tue Nov 15 07:17:35 2005 Tom: All is well that ends well. I had gone looking at the Mcidas web pages at Unidata and seen the reference to port 112 also...of course it checked out on our machine. Anyway, I have set the wheels in motion to get a computer fairly soon (a used, older one, but infinitely newer than cumulus), and I've actually gotten a commitment both from hardware and software support to get a little help with it, so maybe we can make things work a little better on this end. I hate to be the lowest common denominator. So there were some good things that eventuated from this whole deal. Thanks again for your help. I'll get in touch when I screw up something with the new machine. Bill Dr. William T. Corcoran http://cumulus.smsu.edu (417) 836-5781 Dept. Geography, Geology, and Planning Missouri State University 901 S. National Springfield, MO 65897