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

Re: works for us (fwd)

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: works for us (fwd)
  • Date: Thu, 11 Mar 1999 10:09:19 -0700 (MST)

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================

---------- Forwarded message ----------
Date: Mon, 8 Mar 1999 16:28:34 -0700
From: "Glenn P. Davis" <address@hidden>
To: Gilbert Sebenste <address@hidden>
Subject: Re: works for us (fwd)


> Indeed they are, but suddenly, the TTAA00 appeared on the second line,
> when it should appear on the first with the AFOS PIL.

Gilbert:

It would be helpful to me if you could be clearer about what is going on.
Ldm product identifiers don't have 'lines'.
In the data part of an ldm product, we just pass on the bytes that were on
the input.

Are you claiming that a more recent version of pqing
is allowing a '\n' character in the ldm product id, that an older version
wasn't? Are you claiming that the data portion of the ldm product has
a '\n' between the AFOS PIL and the optional WMO abbreviated id?

-glenn