>From: William C Klein <address@hidden> >Organization: Valparaiso >Keywords: 200202061926.g16JQSx10267 McIDAS-XCD McIDAS LDM Bill, I got onto aeolus and started looking around to see why you were getting xcd_run invocation error messages in the LDM log file. Very quickly I discovered that none of the McIDAS executables could be executed. Here is an example of me attempting to run decinfo.k: <login as 'mcidas'> cd workdata decinfo.k ld.so.1: decinfo.k: fatal: relocation error: file decinfo.k: symbol __s_rsFe_pv: referenced symbol not found Killed Was an update to the OS done on aeolus recently? Something has sure changed since McIDAS was built. Given the execution failure, it is no wonder that you were getting the xcd_run error messages in the LDM log files! This is because the LDM runs xcd_run which, in turn, runs either ~mcidas/bin/startxcd.k (xcd_run MONITOR option), ~mcidas/bin/ingetext.k (xcd_run DDS option), or ~mcidas/bin/ingebin.k (xcd_run HRS option). None of the McIDAS executables were executable (all gave the same error message as decinfo.k gave above), so errors were generated by pqact and saved in the ~ldm/logs/ldmd.log file. Since the Sun C and Fortran compilers seem to be in the appropriate spot, I decided to see if rebuilding McIDAS from source would set things right. Before doing this, I downloaded the latest McIDAS addendum (January 3) and then rebuilt: <as 'mcidas'> cd mcidas7.8/update ftp ftp.unidata.ucar.edu <user for distribution> <pass> cd unix/780/bugfix binary get mcupdate.tar.Z quit ./mcunpack cd ../src make clobber make all make install.all After rebuilding, the McIDAS executables were once again executable. While at it, I decided to resetup the XCD decoding and ADDE serving on aeolus. This included (all done as 'mcidas') and was done while the LDM was not running: o cd ~mcidas/workdata rm *.DAT <verify that the McIDAS string XCDDATA pointed to the XCD decode directory> tl.k XCDDATA batch.k XCD.BAT batch.k XCDDEC.BAT o cd ~mcidas/data cp DSSERVE.BAT LSSERVE.BAT <edit LSSERVE.BAT and remove datasets that aeolus does not have/will not serve. Also change the RTNEXRAD configuration file from NNEXRAD.CFG to VALPNEXR.CFG (this already existed in ~mcidas/workdata)> o cd ~mcidas/workdata rm RESOLV.SRV batch.k LSSERVE.BAT After doing the above, I restarted the LDM and verified that data was being ingested, filed, and decoded. Now, I was going to setup logging of ADDE server transactions on aeolus, but I ran into problems editing ~mcidas/.mcenv. This file is owned by 'mcadde', and 'mcadde' is shown to be in the same group as 'mcidas' and 'ldm': [ 129 ] > id mcadde uid=103(mcadde) gid=100(vumcidas) [ 130 ] > id mcidas uid=102(mcidas) gid=100(vumcidas) [ 131 ] > id ldm uid=101(ldm) gid=100(vumcidas) The problem is that a long list of ~mcidas/.mcenv shows that it is owned by 'mcadde', but the group is 'other': [ 132 ] > ls -alt .mcenv -rw-rw-r-- 1 mcadde other 488 Mar 23 2001 .mcenv This tells me that the group for 'mcadde' has apparently changed since .mcenv was created. 'root' should now change the group of .mcenv to vumcidas: chgrp vumcidas /home/mcidas/.mcenv After this is done, I can setup ADDE server logging by adding the following lines to it: ADDE_LOGGING=YES export MCHOME MCDATA MCPATH MCTABLE_READ MCTABLE_WRITE PATH ADDE_LOGGING I already added rotating of the ADDE log files to the crontab of 'ldm', so that part is finished. Also while poking around to setup ADDE logging, I noted that stats files generated by the LDM were not getting scoured from ~ldm/logs (there were thousands of *.stats files in that directory). I deleted the old files and setup sending of the stats files to Unidata. This was done by adding a 'ldmadmin dostats' action to cron for 'ldm'. Synopsis: Things appear to be working on aeolus again. Please let me know when you have changed the group for ~mcidas/.mcenv. When that is done, I will finish setting up ADDE logging. Tom >From address@hidden Fri Feb 8 14:16:29 2002 >Subject: Re: 20020207: crontabs on aeolus (fwd) Tom, Done. Thanks for your help. Bill
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.