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.
Tom, When upgrading to ldm 5.1.1 from ldm 5.0.x, ,you must make a new queue since the old queue format is not compatible with the new program. Similarly, the queue structure for 5.1.2beta is also different. Steve Chiswell >From: "Thomas L. Mote" <address@hidden> >Organization: UCAR/Unidata >Keywords: 200008092055.e79KtdT03050 > >Tom: > >I saw you were on my system this afternoon, and you >probably noticed a few changes. After I installed all of >those system patches last night, I changed the swap space >from my old drive to my new hard drive this afternoon. That >seems to have helped performance. (I actually checked on >the prices for new RAM for the SPARC 20, and found the >prices were outrageous. I doubt we'll be adding memory. I >would probably go to a new system first!) > >I also found we were having some problems writing to the >log files and to the gempak data driectories. I'm not sure >why, since they were all group writable directories and all >of the directories belonged to the "apps" group that is >shared by gempak, mcidas and ldm. Nevertheless, I made sure >all of the directories were owned by ldm, and this solved >the problem. I think that may have been the reason so many >decoders were hanging around and chewing up CPU cycles and >memory. The performance has been vastly better since then. > >I downloaded the latest patch level for GEMPAK and >installed it. I also downloaded and built ldm 5.1.1. I >tried throwing the runtime switch and starting it, but the >"ldmadmin start" hung. I don't have time this afternoon to >figure out why, so I went back to ldm 5.0.8. I'll have to >create a new log file and try it again. > >If the performance stays this good (loads around 1 or so), >I may actually try sending the GINI data across the LDM >from the NOAAport system, as I mentioned before. That can >wait for another day. > >Let me know if you are able to get the compressed GINI >files via ADDE. > >We're making progress! Thanks for your help. > >Tom > > > > >On Wed, 09 Aug 2000 00:09:04 -0600 Unidata Support ><address@hidden> wrote: > >> >From: "Thomas L. Mote" <address@hidden> >> >Organization: University of Georgia >> >Keywords: 200007172022.e6HKMuT11816 UGA McIDAS-X ADDE NOAAPORT GINI imagery >> >> Tom, >> >> It turns out that I can access your ADDE server through the uncompressed >> port (500), but not through the compressed one. This is strange since >> the entries for both look correct in /etc/services and /etc/inetd.conf. >> This _will_ have to wait until tomorrow, I fear. >> >> The good news is that I was able to get listings of your GINI imagery >> from your remote ADDE server! Now, once we get the compression part >> figured out, things will be operational. >> >> BTW, as I write this, I note that the LDM is not running on cacimbo. >> Was this by design, or did it shut down? >> >> Tom >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8644 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://www.unidata.ucar.edu/ >> **************************************************************************** > >********************************************************** >Thomas L. Mote address@hidden >Associate Professor of Geography ph: 706-542-2906 >University of Georgia lab: 706-542-6060 >Athens, GA 30602-2502 USA fax: 706-542-2388 >