>From: Super-User <address@hidden> >Organization: AFIT >Keywords: 199901051727.KAA02639 ldm-mcidas lwtoa3 ROUTE.SYS Pete, >I switched servers last week and thought I had everything configured right, but >apparently I'm missing something, because I haven't seen a satellite image >using garp since. I checked the ldm-mcidas logfile, and see a continuous >stream of messages that read: >Jan 05 05:07:43 lwtoa3[10655]: Starting Up >Jan 05 05:07:43 lwtoa3[10655]: changing to directory /usr/local/ldm/data/mcida > sd >Jan 05 05:07:43 lwtoa3[10655]: decoding "LWTOA3 204 DIALPROD=U3 99005 50525" >Jan 05 05:07:44 lwtoa3[10655]: BATCH U3 207 99005 050525 1 TWIN=0 "MDR.BAT >Jan 05 05:07:44 lwtoa3[10655]: BATCH not found. >Jan 05 05:07:44 lwtoa3[10655]: Exiting >Jan 05 05:15:40 lwtoa3[10711]: Starting Up >Jan 05 05:15:40 lwtoa3[10711]: changing to directory /usr/local/ldm/data/mcida > sd >Jan 05 05:15:40 lwtoa3[10711]: decoding "LWTOA3 172 DIALPROD=UB 99005 51605" >Jan 05 05:15:42 lwtoa3[10711]: BATCH UB 177 99005 051605 1 TWIN=0 "H2O9.BAT >Jan 05 05:15:42 lwtoa3[10711]: BATCH not found. >Jan 05 05:15:42 lwtoa3[10711]: Exiting The BATCH not found messages are caused by: o the copy of ROUTE.SYS you have in the directory in which 'lwtoa3' is to create its output is configured to run a McIDAS ROUTE PostProcess BATCH file upon successful receipt/decode of the image o there is no 'batch.k' executable found in the user running the LDM's search PATH The lack of 'batch.k' and the above "BATCH not found." messages can be safely ignored unless you _are_ trying to run McIDAS ROUTE PostProcess BATCH files. >Also, in the ldmd.log, I get these: > >Jan 05 14:32:27 fujita pqact[27719]: pbuf_flush (14) write: Broken pipe >Jan 05 14:32:27 fujita pqact[27719]: pipe_dbufput: /usr/local/ldm/ldm-mcidas/b > in >/lwtmd2-l/usr/local/ldm/logs/ldm-mcidas.log-v-d/usr/l >Jan 05 14:32:27 fujita pqact[27719]: pipe_prodput: trying again >Jan 05 14:32:27 fujita pqact[27719]: pbuf_flush (14) write: Broken pipe >Jan 05 14:32:27 fujita pqact[27719]: pipe_dbufput: /usr/local/ldm/ldm-mcidas/b > in >/lwtmd2-l/usr/local/ldm/logs/ldm-mcidas.log-v-d/usr/l You will note that these broken pipe messages are associated with the McIDAS MD file decoder lwtmd2, not the AREA file decoder lwtoa3. I suspect that the entries in your ROUTE.SYS for MD file decoding are SUSpended. This would cause the decoder lwtmd2 to exit before decoding any of the data in the pipe that the LDM creates to feed it. When the read end of the pipe is closed (by lwtmd2 exiting), the LDM will issue a Broken pipe message. There is no harm in this way of not decoding MD files other than the annoying Broken pipe messages in ldmd.log. If you never want to decode the MD files from the Unidata-Wisconsin datastream, then the best thing to do is to comment out the lwtmd2 actions in your pqact.conf file and send a HUP to pqact so it will reread pqact.conf. >I haven't changed directory structure, (everything is still linked through >/usr/local). Any clues? The first set of messages you sent in indicate that the AREA file decoder should be working. Did you look in the output directory /usr/local/ldm/data/mcidasd and verify that there are no new images? The reason I ask is that you may have a configuration error on the GARP side even though you are in fact getting and decoding the images. >Pete Rahe >AFIT/ENP >(937)255-3636 x4646 >e-mail address@hidden Let me know the results of your looking for AREA files created by lwtoa3. If no new files are being created, we will have to look more closely at your ldm-mcidas setup including read/write permissions on the output directory and files that the decoder wants to read/write (ROUTE.SYS and SYSKEY.TAB). Tom Yoksas >From address@hidden Tue Jan 5 13:34:42 1999 >Stupid me! The problem with the lack of imagery was that I had a bad path >in my nsat_links script that still sourced Gemenviron using the old servers >directory structure and the cron job was not finding it, so the script >didn't execute. Fixed! Thanks. >MSgt Peter J. Rahe
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.