>From: "Rob Gillies ." <address@hidden> >Organization: USU >Keywords: 200210222244.g9MMiEp01962 McIDAS ADDE LDM ldm-mcidas Hi Rob, >Tom - the information I was requesting was located locally on Allegan. So you >can point to Allegan like you did in class and see if you receive the >requested data. I pointed at allegan for images in the RTIMAGES dataset group, and got the following: DSINFO I RTIMAGES DSINFO: Cannot contact server (connect() failed) No Datasets found of Type: IMAGE in Group: RTIMAGES DSINFO -- done This tells me that the problem you are seeing is either with the ADDE remote server setup on allegan.nr.usu.edu or access to allegan. (Note: while I was writing this email, ADDE access to allegan started working. I will leave in the troubleshooting comments I wanted to make when there was no access mainly so they get put into our inquiry tracking system.) I notice that someone at USU downloaded both the 7.8 and 2002 distributions of McIDAS recently (yesterday and today, respectively). While reloading McIDAS or upgrading to a new distribution can't hurt, it is probably not necessary in this case. What we need to determine is why access to the remote ADDE server on allegan suddenly is no longer available. Some possibilities are: o the file ~mcidas/.mcenv got damaged or deleted o the contents of /etc/services and/or /etc/inetd.conf got changed (these files contain system definitions for the ports that ADDE will use and the program that needs to be run by inet when a request comes in on either of the ports that ADDE uses) o security on the net (e.g., a firewall) was changed, and the change is now blocking access to allegan on port 500 and/or 503 The way I typically test to see if McIDAS ADDE is listening on either port 500 or 503 is by using telnet (this is crude, and subject to the telnet service being turned off). Here are the tests that I run and their results: 1) to the port used for uncompressed ADDE transfers: telnet allegan.nr.usu.edu 500 Escape character is '^]'. laskdjflajd ÿprotocol version mismatch:client wants 1634493546, server knows 1 Connection to allegan.nr.usu.edu closed by foreign host. 2) to the port used for compressed ADDE transfers: telnet allegan.nr.usu.edu 503 Escape character is '^]'. laskdjflajd ÿprotocol version mismatch:client wants 1818325867, server knows 1 Connection to allegan.nr.usu.edu closed by foreign host. In both cases, the sequence 'laskdjflajd' is just some random letters I typed in to evoke a response from the ADDE remote server. So, the remote server is now accessible to me from may machine at the UPC. The next thing I did was to rerun the DSINFO command I listed above: DSINFO I RTIMAGES Dataset Names of Type: IMAGE in Group: RTIMAGES Name NumPos Content ------------ ------ -------------------------------------- ANTARCTIC 10 Antarctic IR Composite EDFLOATER-I 10 Educational Floater EDFLOATER-II 10 Educational Floater II GE-IR 10 GOES-East North America IR GE-IRTOPO 10 GOES-East IR/TOPO Composite GE-VIS 10 GOES-East North America VIS GE-VISTOPO 10 GOES-East VIS/TOPO Composite GE-WV 10 GOES-East North America H2O GEW-IR 10 GOES-East/West IR Composite GEW-IRTOPO 10 GOES-East/West IR/TOPO Composite GEW-VIS 10 GOES-East/West VIS Composite GEW-VISTOPO 10 GOES-East/West VIS/TOPO Composite GEW-WV 10 GOES-East/West H2O Composite GW-IR 10 GOES-West Western US IR GW-IRTOPO 10 GOES-West IR/TOPO Composite GW-VIS 10 GOES-West Western US VIS GW-VISTOPO 10 GOES-West VIS/TOPO Composite GW-WV 10 GOES-West Western US H2O MDR 10 Manually Digitized Radar MDRTOPO 10 MDR/TOPO Composite MOLL-IR 10 Mollweide Composite IR MOLL-IRTOPO 10 Mollweide IR/TOPO Composite MOLL-WV 10 Mollweide Composite H2O RESFLOATER 10 Research Floater DSINFO -- done This tells me that the ADDE server is correctly setup to list its setup for the RTIMAGES dataset. The the next step is to see if the server can find data files: IMGLIST RTIMAGES/GW-IR.ALL Image file directory listing for:RTIMAGES/GW-IR IMGLIST: No images satisfy the selection criteria IMGLIST: done IMGLIST failed, RC=2 Now we are making progress. This is telling us that the images that are supposed to make up the RTIMAGES/GE-IR set can not be found by the remote server on allegan. This means one of two things: o the images are not there -> they are not being decoded correctly (since you say your LDM is receiving the data) o the images are being decoded, but are no longer accessible from the 'mcidas' account. This could be due to their being in a different file system, or by the set of file REDIRECTions used by the user 'mcidas' having been altered/deleted. The thing to test now is: <login as 'mcidas'> cd workdata dmap.k AREA Does the 'dmap.k AREA' invocation list back any files? If not, it means that the files are no longer there and/or are in a different place. Again, if the listing is empty, continue to probe: redirect.k LIST Are there entries for AREA files in the listing? These would look something like: AREA006* /var/data/mcidas AREA007* /var/data/mcidas ... The listing pairs are a regular expression for a set of AREA files and the directory in which to find them. The directory you are using will likely be different from the two listed above. Again, if you have REDIRECTions in place, you will see where McIDAS is trying to find the AREA files. Use the Unix 'ls' command to see if the images are, in fact, there. For example: ls /var/data/mcidas/AREA* Now, if the images are not there, it means that the decoding of the products being received by the LDM has stopped or is failing. To see if this is the case, you should look through the log file you are using for outputting of messages from the ldm-mcidas PNG compressed AREA file decoder, pnga2area (check ~ldm/etc/pqact.conf to see where this might be; if no log file is specified, the log messages will be in ~ldm/logs/ldmd.log*). OK. That is probably enough for one email message. Please let me know what you find. Tom -- +-----------------------------------------------------------------------------+ * Tom Yoksas UCAR Unidata Program * * (303) 497-8642 (last resort) P.O. Box 3000 * * address@hidden Boulder, CO 80307 * * Unidata WWW Service http://www.unidata.ucar.edu/* +-----------------------------------------------------------------------------+
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.