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

[GEMPAK #AKU-273691]: LDM 6.4.4----two problems

>Also, I am not seeing any of the data decoded. I am receiving the MT.gfs*gr1* 
>data, both onedeg and 2p5 and >can see it coming. My pqact entry is:
>
>CONDUIT MT.(avn|gfs|mrf|ensg)
>PIPE decoders/dcgrib2 -m 22999 -d data/gempak/logs/dcgrib_nmc2.log
>-e GEMTBL=/usr/gempak/GEMPAK/gempak/tables
>data/gempak/model/gfs/YYYYMMDDHH_gfs@@@.gem
>
>Not only am I seeing no data decoded, but I don't even see anything written to 
>>data/gempak/logs/dcgrib_nmc2.log. But I can see CONDUIT feed arriving that 
>should match that pattern. I am >running Solaris 10 x86 on this box and using 
>the Sun compilers.

Robert,

The line above looks OK. Ensure that you have either copied or symbolically 
linked the dcgrib2 process 
from GEMEXE to ~ldm/decoders. You would see ldmd.log messages from pqact if the 
piping
to the decoder was failing. If you are not seeing anything there then:

If you have not as of yet after adding the pqact action above, make sure you 
have 
checked your conf file syntax with:
ldmadmin pqactcheck -p conffile
Then make sure you have HUP'd the pqact process to re-read the conf file.

Check your ldmd.conf invocation of pqact and make sure you haven't subsetted
the -f feedtype or -p pattern of data that the pqact process is allowed
to process.

If your ldmd.log file is full of pqact process messages about failing to
pipe the data to dcgrib2, then make sure the dcgrib2 process is executable by
the ldm user, and as well, the ldm user hass read access to the $GEMTBL/grid
directory and files specified in your conf line above: 
/usr/gempak/GEMPAK/gempak/tables/grid.

Steve Chiswell
Unidata User Support

Ticket Details
===================
Ticket ID: AKU-273691
Department: Support GEMPAK
Priority: Normal
Status: Closed