This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Clint, Thanks for the code mods/ideas. At this time nobody has requested that type of service but that doesn't mean it will not be needed in the future. I put the code on file. One comment, if you only want to capture headers of products not already process in the pqact.conf, you can use ^_ELSE_$ pattern ie, HRS ^_ELSE_$ PIPE gribdump_new -b -o data/HDS_(\3:yyyy)(\3:mm)\3\4.log After all your other HDS pqact entries. Robb.... On Wed, 16 Feb 2000, Clint Rowe wrote: > Robb, > > I don't know if anyone else would find it useful, but I had a need > to find out what GRIB products we were not saving/decoding. I didn't > want to save the entire GRIB product, since that could consume quite > a bit of disk space quickly. So I hit upon the idea of using gribdump. > It turned out to be easier than I expected, since gribdump already > read from stdin if no filename was given. All I had to do was put in > an option for an output filename and change the printf's to fprintf's. > Even though I'm not a C programmer, the structure you have in gribdump > made both tasks easy. The only tricky thing I had to do was to keep it > from writing the header before each message. > > Here's the pqact.conf entry for capturing all GRIB headers into hourly > logs: > > HRS ^(......) (....) ([0-3][0-9])([0-2][0-9])(.*) > PIPE gribdump_new -b -o data/HDS_(\3:yyyy)(\3:mm)\3\4.log > > It works okay, but there are two minor problems. First, I end up with a > bunch of gribdump_new processes hanging around (i.e., they don't seem to > time out properly). I haven't worried about this, as I'm running this as > the only action on a separate machine than are normal ingester, so I only > run it occasionally and for relatively short time periods. Second, I end > up creating log files every hour, even though no GRIB products arrrive > since any HRS product will kick off the process but non-GRIB products are > not processed by gribdump. Again, this is a big problem since they're > zero-length files. > > I've attached the modified file. Feel free to use it any way you want. > > Clint > > ==================================================================== > Clinton M. Rowe > Associate Professor > Meteorology/Climatology Program phone:(402)472-1946 > Department of Geosciences fax:(402)472-4917 > University of Nebraska-Lincoln address@hidden > =============================================================================== Robb Kambic Unidata Program Center Software Engineer III Univ. Corp for Atmospheric Research address@hidden WWW: http://www.unidata.ucar.edu/ ===============================================================================