NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>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