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.
Arthur and André, > To: <address@hidden> > From: "Arthur A. Person" <address@hidden> > Subject: Problem with the data access via LDM ( Inidata) (fwd) > Organization: UCAR/Unidata > Keywords: 200306041302.h54D2PLd014788 The above message contained the following: > We haven't been able to receive the GEM data from CMC since we upgraded to > LDM 6.0.12. You folks are apparently aware of this (as noted in my emails > from CMC below) but I thought I would let you know we're having this > trouble too. > > Art. > > Arthur A. Person > Research Assistant, System Administrator > Penn State Department of Meteorology > email: address@hidden, phone: 814-863-1563 Thanks for letting us know. In particular, thanks for including the email from the CMC. From our end, it appears that the operating system of the CMC host in question has a bug that prevents a requesting LDM 6.0.12 from receiving data. With an email address of a CMC contact, we can, hopefully, begin to fix the problem. In the meantime, you can fallback to using LDM 6.0.11 at the slight risk of connecting to other, upstream LDM-s using the much less efficient LDM-5 protocols. Andre, Bonjour! Je suis aussi une Canadien -- but of the ex-patriot, English-speaking variety. :-) I'm very glad to be sending you this email (because I'm worried that my LDM 6.0.12 users are going to do something nasty to me :-) The problem seems to be with the RPC library used by the LDM on host dns2.cmc.ec.gc.ca. LDM 6.0.11 would sometimes connect to a restarted, upstream LDM-6 using less efficient LDM-5 protocols due to a "window of vulnerability" in the code and unlucky timing. This window was closed in version 6.0.12 by ensuring that LDM-5 protocols would only be tried if the upstream RPC layer responded with the RPC error RPC_PROGVERSMISMATCH. I tested this change on almost all pairwise combinations of the systems listed at http://my.unidata.ucar.edu/content/software/ldm/ldm-6.0.12/install/supported-systems.html In particular, it worked correctly for all downstream LDM-6's when connecting to an upstream LDM-5 running on our IRIX 6.5.20m system. For example, here's the log entry for a downstream LDM 6.0.12 connecting to the upstream LDM-5 on our IRIX system: Jun 03 18:39:55 lenny.unidata.ucar.edu chevy[3571]: NOTICE: requester6.c:421; ldm_clnt.c:272: nullproc_6 failure to chevy.unidata.ucar.edu; ldm_clnt.c:141: RPC: Program/version mismatch; low version = 4, high version = 5 Jun 03 18:39:55 lenny.unidata.ucar.edu chevy[3571]: Connected to upstream LDM-5 Jun 03 18:39:55 lenny.unidata.ucar.edu chevy[3571]: FEEDME(chevy.unidata.ucar.edu): OK When a downstream LDM-6.0.12 tries to connect to dns2.cmc.ec.gc.ca, however, it receives an RPC_TIMEDOUT error rather than a RPC_PROGVERSMISMATCH error. This can be seen in the logfile of the LDM 6.0.12: Jun 03 23:00:31 shemp.unidata.ucar.edu ftp[25926]: NOTICE: requester6.c:416; ldm_clnt.c:266: nullproc_6 failure to ftp.cmc.ec.gc.ca; ldm_clnt.c:140: RPC: Timed out From Christian Pagé <address@hidden>, it appears that host dns2.cmc.ec.gc.ca is running a slightly older version of the IRIX operating sytem: The command uname -aR on dns2.cmc.ec.gc.ca gives the following: IRIX dns2 6.5 6.5.5f 07151439 IP22 I suspect that the RPC library of RIX 6.5 was upgraded or patched between versions 6.5.5 and 6.5.20. Our system administrator is going to investigate this possibility around noon our time. I'll keep you apprised. With regards, Steve Emmerson LDM Developer >From address@hidden Wed Jun 4 10:27:14 2003 >To: "Dumas,Rejean [CMC]" <address@hidden>, > "Silva,Peter [CMC]" <address@hidden> >Cc: address@hidden, > "Methot,Andre [CMC]" <address@hidden>, > "Arthur A. Person" <address@hidden>, > "'Steve Emmerson'" <address@hidden> Rejean & Peter, it appears that the operating system of the CMC host in question has a bug that prevents a requesting LDM 6.0.12 from receiving data. Action is require at our end. Thanks, Andre Methot Chief of Implementation & Operational Services >From address@hidden Wed Jun 4 11:29:23 2003 Steve, this file was passed on to the Data Acquisition & Distribution group. Peter & Rejean, who receive copy of this note will be looking into this this afternoon. The area I have control on, is the data production and GRIB encoding (which works okay). However, you can keep me in the loop, as I'm concern about data services. Regards, Andre -----Message d'origine----- De : Steve Emmerson [mailto:address@hidden] Envoye : 04 juin, 2003 12:26 A : Methot,Andre [CMC] Cc : address@hidden Objet : 20030604: LDM 6.0.12 not getting GEM data from dns2.cmc.ec.gc.ca. Andre, As a temporary workaround for our sites that upgraded to LDM 6.0.12 and also want the GEM data, could you add an ALLOW entry in your LDM-5 configuration file (ldmd.conf) for host atm.geo.nsf.gov (which is still running version 6.0.10 of the LDM)? We can then inform those sites to switch their GEM request to host Atm. Regards, Steve Emmerson