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

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 
distribution.

Preferably, you'd be running 5.6.K for the entire installation, but the 
decoders 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 of
operating systems without core dumps. If you are dumping core with the current 
distribution,
then I can investigate. Otherwise, its like trying to go back and figure out 
what's
wrong with your AMC Pacer.

Steve Chiswell




>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 frequent
>>>core dumps converting SAO/METAR data to GEMPAK format, it cause a large loss
>>>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 alrea
> 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 Program 
>>(303)497-8643                                                  P.O. Box 3000 
>>address@hidden                                   Boulder, CO 80307 
>>---------------------------------------------------------------------------- 
>>Unidata WWW Service              http://my.unidata.ucar.edu/content/support  
>>**************************************************************************** 
>
>       == kwthomas ==
>