>From: address@hidden >Organization: St. Cloud State >Keywords: 199904091934.NAA23884 ldm-mcidas Alan, After I saw this message, I took the liberty of logging onto waldo to snoop around. My comments are included below. >After your message of yesterday, 4/26, we have checked our pqact.conf >but are having a problem. Note, we have commented out all lines except >those dealing with mcidas products for now. > >The ldm starts ok, but after waiting and checking our log file, we see >lines such as the following. > >Output from ldmd.log on 4-27-99 for ldm on waldo > >Apr 27 19:50:12 waldo pqexpire: > Recycled 4867.924 kb/hr ( >1422.365 prods per hour) >Apr 27 19:55:12 waldo pqexpire: > Recycled 4803.895 kb/hr ( >1446.684 prods per hour) >Apr 27 19:57:27 waldo pqact: pbuf_flush (4) write: Broken pipe >Apr 27 19:57:27 waldo pqact: pipe_dbufput: >-closelwtoa3-d/var/data/mcidas-v write error >Apr 27 19:57:27 waldo pqact: pipe_prodput: trying again >Apr 27 19:57:27 waldo pqact: pbuf_flush (4) write: Broken pipe >Apr 27 19:57:27 waldo pqact: pipe_dbufput: >-closelwtoa3-d/var/data/mcidas-v write error >Apr 27 19:57:27 waldo pqact: child 9197 exited with status 127 >Apr 27 19:57:27 waldo pqact: child 9195 exited with status 127 >Apr 27 20:00:12 waldo pqexpire: > Recycled 4789.934 kb/hr ( >1527.129 prods per hour) > >I have checked to make sure that /var/data/mcidas is there, and it is >owned by ldm, with write permission. I verified this by doing: touch /var/data/mcidas/xxx rm /var/data/xxx Both worked with no problems. >I believe the lines in pqact that >invoke the lwtoa3 decoder are written just as they occur in the example >pqact.conf we have talked about before, so decided it is time to talk >with Tom or Don. What is breaking my pipe? I logged in as your user 'ldm' and did: which lwtoa3 no lwtoa3 in /usr/local/ldm/bin /usr/local/ldm/decoders /usr/local/ldm/man /bin /usr/bin /usr/ucb /etc /usr/local/bin . This shows that either you have not yet installed the ldm-mcidas decoders, or they are in a directory that is not in 'ldm's PATH. >Note that this ldm (on >waldo) is feeding from our other machine hobbes. You have commented >that hobbes' ldm has some problems with these decoders, but I assume >the raw products are sent over to waldo, so those problems should not >be passed over. You are correct, the original products are fed from one LDM to the next. The problem appears to be that the decoders are not available. >Another issue, that I do not think is related, is that I notice the >lines in pqact.conf specify the full path name when listing where >products are to be stored, i.e. /var/data/mcidas. Yet when ldm is set >up, we create ~ldm/data as a link to a 'volatile' file system. I >expected the paths listed in pqact.conf to somehow reflect that link, >although I can see that listing the full path should work just fine. >Maybe it is just that we do not want to put items in ~ldm/data. >Could you comment? You can either specify a full pathname or a relative pathname for data product output. On your system, you have ~ldm/data setup as a link to /var/data/ldm. If you wanted to use relative pathnames for ldm-mcidas created products (e.g. data/mcidas or data/mcidasd), then your McIDAS data directories would be /var/data/ldm/mcidas and /var/data/ldm/mcidasd. As it stands now, you are writing to a directory that is not a subdirectory of ~ldm/data, so you need to use full pathnames IF you want the output directory to stay as it is. There is no harm in keeping things as they are, and there would be no harm or special advantage in changing the output pathnames to being relative. The choice is strictly up to you. I snooped around quite a bit and could not figure out where you might have installed the ldm-mcidas package. I even went so far as to do: find / -name lwtoa3 -print This searched every directory under / (the very top level for the disk) and did not find the AREA file decoder. I assume, therefore, that you have not installed the ldm-mcidas package (although you did get the pattern action example file from the ldm-mcidas distribution and use it in ~ldm/etc/pqact.conf). To get you rolling, I decided to grab the binary ldm-mcidas distribution from our FTP server. The problem is that this binary was created with the Sun Workshop compilers and you don't have these. The second option was to grab the ldm-mcidas source distribution and build the decoders on your system cd /usr/local/ldm ftp ftp.unidata.ucar.edu <user = anonymous> <pass = your email address> cd pub/ldm-mcidas bin get ldm-mcidas.tar.Z quit This will be a real test since I have not tried building the ldm-mcidas package using gcc/f2c on a Solaris x86 system yet. In order to build the ldm-mcidas decoders from source, however, I have to install the netCDF package first. Unfortunately, I have to leave for the night. I will return and continue my efforts tomorrow. I hope my fooling around on your system is OK with you (please let me know if it isn't!). >Thanks Talk to you tomorrow. 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.