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: Patrick Dills <address@hidden> >Organization: UCAR/COMET >Keywords: 200311122238.hACMchOb005683 McIDAS ADDE Hi Patrick, >Say, we're having some trouble accessing one of the NESDIS ADDE data >servers, specifically the 'PLR' server (140.90.195.52). I've run into a >dead end, and was wondering if you might have some ideas. OK, ready. I also have been allowed to access that server, so I should be able to replicate your results. >I was talking to one of the contracters at NESDIS and we explored a >number of avenues to see if the server was visible from our MCIDAS-X >machine 'gizmo' here at COMET...ping, telnet and 'DSINFO IMAGE PLR' for >example. At the same time I checked some of my other server entries, e.g. >ULY, RTIMAGES, SUOMI and appear to have no trouble. Yes, but those datasets are hosted on different machines. I am glad that you checked, however, since it confirms that your McIDAS installation is working. >Both 'ping' and 'telnet 140.90.195.52 500' to the 'PLR' servers produced >positive responses, with 'telnet' they were able to see and accept my >connect request. >But whenever I entered a 'dsinfo' from the McIDAS side, >it attempts to connect, and then after about 45 sec., responds with --> > >--------- >dsinfo.k: Cannot contact server (connect() failed) > No Datasets found of Type: IMAGE in Group: PLR >dsinfo.k: Cannot contact server (connect() failed) > No Datasets found of Type: POINT in Group: PLR > >...and so on... >--------- > I am also able to telnet to port 500 on the server, but not to port 503. This means that doing uncompressed data transfers should work, but "compress" compressed transfers should/will not. To test this, I tried to do the same DSINFO command as you ran for PLR first using compressed transfers: DSINFO IMAGE PLR This eventually timed just as yours did. Next, I EXITed McIDAS and restarted specifying use of uncompressed transfers: mcidas -config <choose to use uncompressed transfers, not compressed ones> DSINFO IMAGE PLR Dataset Names of Type: IMAGE in Group: PLR Name NumPos Content ------------ ------ -------------------------------------- AMGAC 14 NOAA AM GAC data AMHRPT 14 NOAA AM HRPT data AMLAC 14 NOAA AM LAC data AMSUA54 1 Latest NOAA-KLM AMSU-A CH07 54 GHz BT ... So, like I supposed, uncompressed transfers work, but compressed ones do not. You should EXIT your McIDAS session and start a new one that uses uncompressed transfers in the same way as I indicated above. >Matthew Marshall, a systems guy at NESDIS in charge of the trouble >ticket, mentioned he had an IP entry for you in their server access table >for the 'PLR' server and I was wondering if you had any similar problems >recently? Might help us narrow the problem a bit? I don't know. We need to get those guys to setup their remote ADDE server to support compressed transfers. Do you have the name of the person responsible for the McIDAS/ADDE setup there? If yes, I could contact him and help him to get compressed ADDE transfers working. >Any insights you might come up with Tom would be greatly appreciated. I think that the only problem is compressed vs uncompressed transfers. If you find that you still have problems when using uncompressed transfers, please let me know. Cheers, Tom