20031001: 20030930: 20030930: upgrade to 6.0.14 and GEMPAK dcmetr problems (cont.)

Kevin,

You have 2 dcmetr decoder entries writing to the same output file.
This is unnecessary, and won't work- the decoders will be stepping on
the output file....and storing the same sets of data.

Note that WMO feedtype abbreviation is the aggregation of HDS, IDS, DDS, and 
PPS.
Also, DDPLUS is the aggregation of DDS and PPS.

So "WMO ^S[AP]" is essentially the same as "IDS|DDPLUS ^S[AP]" since
you won't find any SA or SP under the HDS feed.

Here is the entry that I provide with the distribution:
#
# US and Canadian sfc obs and specials
#
WMO     ^S[AP]
        PIPE    decoders/dcmetr -v 2 -a 500 -m 72 
        -s sfmetar_sa.tbl
        -d data/gempak/logs/dcmetr.log
        -e GEMTBL=@GEMTBL@
        data/gempak/surface/YYYYMMDD_sao.gem

also note, you have -v 999 in one of the entries. The GEMPAK logging 
supports levels up to 4. 

Steve Chiswell


>From: "Kevin W. Thomas" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200310012210.h91MAPk1011703

>>Kevin,
>>
>>Since I don't know the history of your problems as to what version of GEMPAK 
> you are using
>>and I don't know of any other report of this problem from you, I can
>>suggest at the very least grab the dcmetr decoder from the 5.6.K binary distr
> ibution.
>>
>>Preferably, you'd be running 5.6.K for the entire installation, but the decod
> ers are
>>mostly stand-alone and can be grabbed out of newer distributions (so long as 
> the
>>supporting tables are available...packing and station table for dcmetr).
>>
>>In general, as Tom said, we are running the decoders full bore on a variety o
> f
>>operating systems without core dumps. If you are dumping core with the curren
> t distribution,
>>then I can investigate. Otherwise, its like trying to go back and figure out 
> what's
>>wrong with your AMC Pacer.
>>
>>Steve Chiswell
>
>Our System Admin people have upgrade to the 5.6.K distribution.  Unfortunately
> ,
>"dcmetr" still core dumps.
>
>Here is my "pqact.conf" entries.  There are two, as this is what I inherited.
>Maybe that is the problem?
>
>WMO    ^S[AP].* .... ([0-3][0-9])
>       PIPE    /usr/GEMPAK5.6/bin/linux/dcmetr -b 9 -m 24
>       -p /usr/GEMPAK5.6/gempak/tables/pack/metar.pack
>       -s /usr/GEMPAK5.6/gempak/tables/stns/sfmetar_sa.tbl
>       -v 999
>       /arpsdata2/ldm3/ingest/gempak/surface/YYMMDD_sao.gem
>
>DDS|IDS        ^S[AP].* .... ([0-3][0-9])
>       PIPE    /usr/GEMPAK5.6/bin/linux/dcmetr -b 9 -m 24 
>       -p /usr/GEMPAK5.6/gempak/tables/pack/metar.pack
>       -s /usr/GEMPAK5.6/gempak/tables/stns/sfmetar_sa.tbl
>       /arpsdata2/ldm3/ingest/gempak/surface/YYMMDD_sao.gem
>
>Any help would be appreciated.
>
>       Kevin W. Thomas
>       Center for Analysis and Prediction of Storms
>       University of Oklahoma
>       Norman, Oklahoma
>       Email:  address@hidden
>
>
>>>From: "Kevin W. Thomas" <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200310010441.h914frk1025923
>>
>>>>Kevin,
>>>>
>>>>At the risk of belaboring a point (this conversation would be easier
>>>>in person :-)...
>>>
>>>Oh...you noticed.  :-)
>>>
>>>>re: GEMPAK dcmetr problem has nothing to do with LDM installation
>>>>
>>>>>No, it doesn't have anything to do with the LDM installation, however,
>>>>>"dcmetr" is a program referenced in "pqact.conf".
>>>>
>>>>Yes, that is correct.  What the LDM does is provide the specified products
>>>>to the decoder named in the PIPE action in pqact.conf.  This is simply
>>>>the sending of data from pqact through stdout to the decoder which
>>>>reads it through stdin.  The piping is the same as one doing something
>>>>like:
>>>>
>>>>ls | more
>>>>
>>>>If 'more' gave errors, it would not be because 'ls' changed.  It would
>>>>because there is a problem with 'more'.  So, the point is that one
>>>>can upgrade the LDM and experience no problems with decoders that
>>>>worked correctly before the upgrade.
>>>>
>>>>>Yes, we are talking about two different packages, however, if I get freque
> nt
>>>>>core dumps converting SAO/METAR data to GEMPAK format, it cause a large lo
> ss
>>>>>of data for our realtime system.
>>>>
>>>>Yes, but the problem is with the GEMPAK decoder, not the LDM.
>>>
>>>No argument here.  The "gotcha" is that with LDM 6.0.14, I'm getting a *lot*
>>>more SAO/METAR reports, on the order of twice as much data, that trips the
>>>"dcmetr" bug.
>>>
>>>>>I'm hoping to have the updated software installed in the next day or so.
>>>>>Since none of the other GEMPAK programs have any problems, I'm hoping that
>>>>>the update will fix things.  If not, I'll go into the code, and track down
>>>>>the problem myself.
>>>>
>>>>I know that Chiz as fixed a number of bugs in GEMPAK decoders in
>>>>various releases since those in 2002.  We are running the same v2003
>>>>(5.6.x) decoders under several different OSes with no problems, and
>>>>various Unidata sites are doing the same under Linux v7.x also with no
>>>>problems.
>>>
>>>We're running one of those old 2002 releases.  I'd like to correct that ASAP
> .
>>>
>>>>re: cat /etc/redhat-release
>>>>>Thanks.  It shows 7.2 (Enigma).
>>>>
>>>>OK.  Hopefully, the OS is fully patched.  Redhat 7.2 is known to
>>>>have a number of problems.
>>>
>>>It should be.  Our Admin people have put patches on it a couple of times
>>>recently.  I know NFS problems with RH 7.2 have keep him busy.
>>>
>>>>>FYI...my boss, Dan Weber is in Boulder at some meetings.  You may have alr
> ea
>>> dy
>>>>>talked to him.
>>>>
>>>>OK.
>>>>
>>>>>In any case, I'd like to get everything resolved by the end of the week.
>>>>
>>>>Sounds good.  Thanks for the update!
>>>
>>>I'll let you know when all is done.
>>>
>>>>Cheers,
>>>>
>>>>Tom
>>>>***************************************************************************
> * 
>>>>Unidata User Support                                    UCAR Unidata Progra
> m 
>>>>(303)497-8643                                                  P.O. Box 300
> 0 
>>>>address@hidden                                   Boulder, CO 8030
> 7 
>>>>---------------------------------------------------------------------------
> - 
>>>>Unidata WWW Service              http://my.unidata.ucar.edu/content/support
>   
>>>>***************************************************************************
> * 
>>>
>>>     == kwthomas ==
>>>
>>
>>**************************************************************************** 
>>Unidata User Support                                    UCAR Unidata Program 
>>(303)497-8643                                                  P.O. Box 3000 
>>address@hidden                                   Boulder, CO 80307 
>>---------------------------------------------------------------------------- 
>>Unidata WWW Service              http://my.unidata.ucar.edu/content/support  
>>**************************************************************************** 
>