[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990105: ldm-mcidas not processing AREA files

>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