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: "Thomas L. Mote" <address@hidden> >Organization: UGA >Keywords: 200307031521.h63FLfLd024002 McIDAS-X -XCD v2002b LDM-6 Hi Tom, >I've noticed a couple of McIDAS issues that I was hoping you could >help with. These started after we upgraded cacimbo to RH8 about 2 months >ago. (It had been running a patched version of the same OS for three >years, but the university would no longer support RH7.0.) I'm just >now getting around to dealing with this. > >First, I'm occasionally noticing that a process like dmraob.k >or dmsfc.k will be using all the CPU time. I'll stop and restart >the ldm, and it will be fine. Just a few minutes ago, I noticed >dmraob.k was using 99.6% of the CPU for an extended period. >A restart of the ldm and it was fine. This sounds exactly like a problem I fixed in the v2002b addendum. If you are still running a version prior to this (check this by listing out the contents of ~mcidas/data/VERSION.TXT), then you need to install the addendum. I first saw this problme on Gilbert Sebenste's NIU machine. I traced the problem down to a severe memory leak in the station table database access routines. Installation of the v2002b addendum has fixed problems like this not only on more recent versions of Linux (8.0+) but also on Compaq/DEC OSF/1. >Secondly, it doesn't seem like our ADDE server is making the >NEXRAD products available, although everything else seems to be >there. I don't recall changing anything there, so I'm not sure >what the problem would be. This most likely an ADDE configuration problem. It could be that a file got damaged in the upgrade, or, more probably, that the setup in the system files got changed. The first thing I would do in troubleshooting this is to reinstall the McIDAS ADDE remote server stuff. This is a very simple process, but it must be done as 'root'. Here are the steps that you should have 'root' do _after_ you install the v2002b addendum: <login as 'root'> cd /home/mcidas sh ./mcinet2002.sh uninstall mcadde <wait> sh ./mcinet2002.sh install mcadde Just after I wrote this I did a simple telnet test to cacimbo on port 503: % telnet cacimbo.ggy.uga.edu 500 Trying... Connected to cacimbo.ggy.uga.edu. Escape character is '^]'. ^CConnection closed. The fact that cacimbo is listening on port 500 indicates that the ADDE server installation is there and probably working. One problem you may have run into during the upgrade from RH 7.0 to 8.0 is an incorrect conversion of the 7.0 /etc/inetd.conf entries into 8.0 /etc/xinetd.d files. The uninstall/install steps listed above should fix this. The other thing that is possible is that there are conflicting entries in /etc/services for port 500 and/or 503. After doing the uninstall/install steps above, please check to make sure that the only entries in /etc/services for 500 and 503 are the ones for McIDAS. If all of the above fails and you continue to have problems, I am always willing to logon and take a hard look at your setup. By the way, I want to take this opportunity to encourage you to upgrade your LDM to the latest release of LDM-6 and to start reporting real time statistcs back to us. We are offering everyone an installation and tuning service: we will do the installation and tuning of your ldmd.conf entries to maximize efficiency as long as we are given the appropriate logins for 'ldm' and possibly 'root'. 'root' access is need for the last bit of the LDM installation; it is not absolutely necessary that we have this access if you are willing to perform the last configuration step. Please let me know if you are interested in our LDM installation/tuning offer. >Thanks for your help. No worries. Talk to you later... Tom