20050429: LDM - Binaries available?

Scott,

>Date: Tue, 03 May 2005 15:56:26 -0800
>From: "Scott Swank" <address@hidden>
>Organization: NOAA/NWS
>To: Steve Emmerson <address@hidden>
>Subject: Re: 20050429: LDM - Binaries available?
>Keywords: 200504291922.j3TJMbKx001883

The above message contained the following:

> EXEC calls runDecoder.sh which in turn decides which script to call to 
> process the data in the queue.  In this case, the script ldm_metar.ksh 
> is called to process and when it is called, it logs this to its own log.

Ah.

[snip]
> > Does this happen if you replace
> > 
> >     EXP     ^(METAR)
> >             EXEC    -wait   /apps/datatools/runDecoder.ksh
> > 
> > with, for example,
> > 
> >     EXP     ^(METAR.*)
> >             PIPE    -close  /apps/datatools/metarDecoder.ksh        \1

I'm sorry, the above should have had a space between the ".ksh" and the
"\1" instead of a tab, i.e.,

EXP     ^(METAR.*)
        PIPE    -close  /apps/datatools/metarDecoder.ksh \1

> Did this, and now I'm back to overwriting/multiple calls of the same 
> file.  Ie: I get 3 files inserted into the queue at roughly the same 
> time, the last one gets PIPE'd 3 times and my metarDecoder script gets 
> called 3 times on the 3rd product.

Was it invoked with three different arguments?  It should have been.

> > The above is more efficient than using an EXEC entry in the pqact(1)
> > configuration-file coupled with a script that uses pqcat(1) to obtain
> > the desired data-product.  It would require, however, that the script be
> > rewritten to read the data-product from standard input rather than use
> > pqact(1).
> Easily done and tested, but didn't work out.  Is there a way to force 
> PIPE to perform the -wait like on an EXEC?

The "-close" option will cause the data-product to be completely written
to the pipe before another decoder is executed.  It will also cause the
pipe to be closed after the data-product is written.

I suggest replacing the decoding script with one that merely logs the
argument (e.g., "METAR_vrh_SAUS20KNKA.86263.123215455") to verify that
the decoder is being invoked with a different argument each time.

> Thanks,
> Scott

Regards,
Steve Emmerson