>From: Adam Burnett <address@hidden> >Organization: Colgate >Keywords: 200002291726.KAA26578 McIDAS-X 7.60 Adam, >Thanks for the help in building Mcidas 7.6. Now I have another problem and >it seems unusually weird. It involves my efforts to get the ldm working >with mcidas-xcd. I had most of this working with my 7.4 version but for >some reason I have these new issues. The basic problem is that I'm not >getting my MD files and grid files decoding from xcd. In addition, I'm >having strange behavior with my ldm (which may explain my MD and GRID >problems). Let me start with the LDM. Here goes... >When I upgraded to Mcidas 7.6, I used the new copy of xcd_run to replace my >old copy. I probably didn't need to do this but I wanted to make sure that >everything was up to date. This was not needed, but it should cause no problems as long as the definitions for MCDATA, MCPATH, etc. are set the same as they were in the old copy of xcd_run. >I then made the necessary changes to xcd_run. >My mcidas installation is in /data2/mcidas. I want xcd to decode data into >/data3/xcd (for your information, my area files are going into >/data3/mcfiles) OK. >My xcd_run looks like: > >MCHOME=/data2/mcidas >MCDATA=/data3/xcd MCDATA should be: MCDATA=/data2/mcidas/workdata It is the McIDAS working directory for the user 'mcidas'. >MCLOG=$MCDATA/XCD_START.LOG >MCPATH=${MCDATA}:$MCHOME/data:$MCHOME/workdata:$MCHOME/help MCPATH should be: MCPATH=${MDATA}:$MCHOME/data:$MCHOME/help ># Setup PATH so that the McIDAS-X executables can be found > >PATH=$MCHOME/bin:/usr/openwin/bin:/usr/openwin/share/include:/bin:/data1/pro >gram/SUNWspro/bin:/usr/ccs/bin:/usr/bin:/usr/local/bin:/usr/ucb This looks correct ># Set LD_LIBRARY_PATH to include all directories (other than those searched ># by default) that are needed to be searched to find shared libraries. ># For this example, I assume that the shared Fortran library is located ># in /opt/SUNWspro/SC4.2/lib > >LD_LIBRARY_PATH=/usr/openwin/lib:/data1/program/SUNWspro/SC4.2/lib:/data1/pr >ogram/SUNWspro/lib:$MCHOME/lib:/usr/lib:/usr/ucblib OK. If the Sun compilers are installed correctly, this could be set to be: LD_LIBRARY_PATH=/usr/openwin/lib:/data1/program/SUNWspro/lib:$MCHOME/lib:/usr/lib:/usr/ucblib >My pqact.conf file has the following lines: > >#Entries for Mcidas-XCD decoders ># >DDPLUS|IDS ^.* PIPE xcd_run DDS >HRS ^.* PIPE xcd_run HRS ># Assuming tabs in appropriate places, this should be fine. I personally prefer to put the portions of the invocation on separate lines: DDPLUS|IDS ^.* PIPE xcd_run DDS HRS ^.* PIPE xcd_run HRS but this is not absolutely necessary. >My ldmd.conf file has these lines. I've always had the pqsurf commented out >but I don't know why. > ># >exec "pqexpire" >exec "xcd_run MONITOR" >exec "pqbinstats -d /data2/ldm/logs" >exec "pqact -d /data2/ldm /data2/ldm/etc/pqact.conf" ># exec "pqsurf" This looks good. It assumes that xcd_run is in the PATH of the user 'ldm'. >After I made sure that I had things set correctly, I ran the ldmadmin start >command. Normally, the program returns a message saying that ldm has >started. Now it just sits there: > >gissun% ldmadmin start >starting the LDM server... At this point I would kill ldmadmin and kill all LDM processes. That way you can start fresh. >I open another command window and run the ldmadmin watch command, and it >appears as if stuff is comming in. Here is an example: > >gissun% ldmadmin watch >(Type ^D or ^C when finished) >Mar 03 15:08:45 pqutil: 1651 20000303141541.053 IDS|DDPLUS 149 ASUS45 >KGTF 031415 /pSWRSK >Mar 03 15:08:45 pqutil: 759 20000303141546.599 IDS|DDPLUS 155 SAUS70 >KWBC 031413 /pMETAR >Mar 03 15:08:45 pqutil: 334 20000303141546.780 IDS|DDPLUS 156 FTXX62 >KWBC 031411 >Mar 03 15:08:45 pqutil: 104 20000303141546.783 IDS|DDPLUS 157 SAFR32 >LFPW 031400 CCA >Mar 03 15:08:45 pqutil: 256 20000303141546.787 IDS|DDPLUS 158 UDEU40 >ESWI 031408 >Mar 03 15:08:45 pqutil: 781 20000303141546.796 IDS|DDPLUS 160 FPAK11 >PAFA 031411 The hanging of ldmadmin (which is simply a Perl script that, in this mode ('start') is looking for indication that processes have started) usually is an indication that your OS is lacking some needed pathes. >Also, my mcidas decoders for area, nids, and lightning are working >perfectly. OK, the LDM is running at this point, but ldmadmin has not been able to determine that. I will have to check with our system administrator to find out if there is a specific OS patch that needs to be applied, or if a series of patches is needed. >The XCD-START.LOG looks like: > >Starting DDS at 00063.150757 >Domestic Data Service >150757 >High Resolution Data Service Looks OK. >When I go to stop ldm with the ldmadmin stop command I get the following >message: > >stopping the LDM server... >Mar 3 15:02:59 UTC gissun.colgate.edu : make_lockfile: another ldmadmin >process exists >gissun% This is related to the same problem as ldmadmin never returning with an indication that the LDM has been started. >Meanwhile, I am getting tons and tons of stuff dumped into my /data3/xcd >directory. I'm not even sure what most of this stuff is. What is all this >stuff? (this is one of the burning questions I've had for about 2 years). The majority of things will be files with the .IDX suffix. These are index files by product type into the daily spool file that has the .XCD suffix. The index files are needed for text access to the data files. >I >don't seem to be getting any MD or GRID files written to the /data3/xcd >directory. I am a little suspicious of your setup given the settings of MCDATA and MCPATH in your xcd_run. The way I found that it was best to run XCD was to set MCDATA and MCPATH the way I indicated and have file REDIRECTions that point to where you want various files read/written. This was the purpose of the settings in EXAMPLE.NAM which you are advised to copy to LOCAL.NAM and edit to match your system setup. >One other piece of infomation - I don't remember if I should be seeing >xcd_run "things" happening in my ldm log. No, not really. xcd_run is a shell script wrapper around the XCD routines startxcd.k, ingebin.k, and ingetext.k. These routines know nothing about the LDM, so you would not expect to see logging information sent to the LDM log. >All I see are nids, area, and lightning stuff. OK, so the ldm-mcidas setup in pqact.conf is correct. >Sorry to present this mystery. Is it too weird? No, it is not too weird. What I would do is the following: <login as 'ldm'> o stop the LDM o make sure that all LDM processes have ended; if they have not, you may need to kill them by hand o after all of the LDM processes have exited, then run 'ldmadmin stop' once more. This time it may complain, but it should return you back to the OS command prompt <login as 'mcidas'> o to start with a clean slate, cd to the /data3/xcd directory and remove all of the .IDX, .XCD, .RAP, .RAT files. A real cleanup should leave you with the files SCHEMA and SYSKEY.TAB in this directory. SYSKEY.TAB should be a link to the copy in the directory in which you are storing AREA files. SCHEMA should be the one from the 7.6 distribution and it should also be a link to the copy in the directory where ldm-mcidas point source decoders (nldn2md and proftomd) are creating their output o after cleaning out the XCD data directory, then start going through the McIDAS installation and configuration instructions in our online documentation. A quick overview of the things you will be doing is: cd ~mcidas/data cp EXAMPLE.NAM LOCAL.NAM <edit LOCAL.NAM and set directories to match your system setup> cp DSSERVE.BAT LSSERVE.BAT cp DATALOC.BAT LOCDATA.BAT <edit LOCDATA.BAT and change "fully_qualified..." to the full name of your machine) cd ~mcidas/workdata <start a McIDAS-X session> BATCH XCD.BAT REDIRECT REST LOCAL.NAM TE XCDDATA "/data3/xcd BATCH XCDDEC.BAT BATCH LOCDATA.BAT BATCH LSSERVE.BAT At this point, your system should be ready for XCD to run correctly. <login as 'ldm'> ldmadmin start Let me know what happens. By the way, did you do the ADDE remote server installation as pre the web pages? If not, you should, but you will need 'root' access to do it. >Thanks If things still don't work, I will be happy to login and look around. If you want me to do that, I will need the login and full machine name. Talk to you later... Tom
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.