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

Re: SAUS4* headers not being processed

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.

  • Subject: Re: SAUS4* headers not being processed
  • Date: Sat, 05 Aug 2000 15:31:08 -0600
Gilbert,

> [your pqsurf.conf]
> Anything wrong here? Otherwise, I have a 20 MB queue, which is well above
> what should be expected per hour...

Your pqsurf.conf looks OK to me.  I just tried using it with pqsurf
and some canned IDD data, and it created lots of files in the
domestic/surface_obs/ directory, as expected, e.g. a file 00aug03_15
containing METARs.

> I have had no problems with it, and even if this IS a bug, it means that
> pqsurf still has the functionality found in 5.0.9.

Do you mean the problem with breaking apart METARs sent under the
SAUS4* headers that you're seeing with 5.1.2beta was also a problem
with LDM 5.0.9?  I guess I didn't know about that problem, but I'd be
happy to hear we haven't introduced a new problem that wasn't in
5.0.9.  I'm not very familiar with pqsurf, so maybe I misunderstood or
was unaware of an existing problem that the new release was supposed
to fix.  Maybe Robb knows something more about this.  If not, I'll
need an explicit description of the problem so I can duplicate it here.

About the only other thing I can suggest would be to have pqsurf log
verbosely for a while to see what it is doing (add a -v to wherever
pqsurf gets invoked, probably in the ldmadmin script).  This will
create a big log pretty quickly, but might show a problem.  With the
data I am using, about the only problem I see logged is lots of 

Aug 05 21:12:29 pqsurf[22907]: Product already in queue:       66 
20000805211143.431 IDS|DDPLUS 673001  metar KMCC 031222

messages, which I assume are to be expected when logging verbosely.

--Russ