[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20000306: ldm-generated data files
- Subject: 20000306: ldm-generated data files
- Date: Mon, 06 Mar 2000 11:18:20 -0700
>From: Eric Pani <address@hidden>
>Organization: Northeast Louisiana University
>Keywords: 200003061756.KAA29509 LDM Y2K
Eric,
>We are running the latest version of ldm on a SPARC20 with Solaris 5.7.
>In the pqact.conf file, I have the following line:
>
>DDPLUS ^WWUS40 .... ([0-3][0-9])([0-2][0-9])
> FILE data/ddplus/(\1:yy)(\1:mm)\1\2_wws.wmo
>
>The data file generated this way seem to have the 2-digit year set as 10
>instead of 00. I've used date to check the system date and it seems
>okay:
>
>Mon Mar 6 11:55:20 CST 2000
>
>Got any ideas?
It appears that you did not get the Y2K patch announcement related to
the LDM back in December. The problem was just as you describe. The
announcement of the fix follows:
>From address@hidden Thu Dec 30 10:09:13 1999
>To: address@hidden, address@hidden
>Subject: 19991230: Y2K Bug Fix for pqact program of the LDM
>Date: Thu, 30 Dec 1999 10:09:13 -0700
>From: Unidata Support <address@hidden>
Hi,
A copy of this notice is available at
http://www.unidata.ucar.edu/packages/ldm/y2k-fix.html
Thanks to Al Taylor of NOAA's Air Resources Laboratory for being the
first to report a Y2K bug in the pqact program of the LDM (all
versions). The symptom of the bug is that pqact.conf entries that make
use of two-digit year substitution patterns such as (\1:yy) will
substitute the string "10" instead of the string "00" for products
whose WMO header indicates a date in January or later.
For example, the pqact.conf entry
WMO ^S[AP][AC-Z][A-Z].* .... ([0-3][0-9])
FILE data/obs/surface/hrly/(\1:yy)(\1:mm)\1.hrly
when presented with a matching product with a date component of 010212
(representing 1200 on January 2) will append the product to a file
with a name such as "100212.hrly" instead of the expected
"000212.hrly".
A fix for the bug is to change line 643 in the source file
ldm-5.0.8/src/pqact/palt.c from
(void) sprintf(ostring,"%d",year);
to
(void) sprintf(ostring,"%02d", year % 100);
and then rebuild pqact and reinstall it. An already-patched version of
the palt.c file is available from
ftp://ftp.unidata.ucar.edu/pub/ldm5/palt.c.
To make it easier to install this bug fix, we have built new versions
of pqact for all the common platforms for which we make binary
distributions. You can just FTP the appropriate version of pqact for
your platform and install it in /usr/local/ldm/bin/pqact (or wherever
you have pqact installed). Below is a list of the available pqact
binaries. Versions built for an earlier version of a platform, for
example sunos_5.6-sparc, will generally work on later versions of the
same platform such as sunos_5.7-sparc.
ftp://ftp.unidata.ucar.edu/pub/binary/aix_4.3-rs6000/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/hpux_10.20-hp9000/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/hpux_11.00-hp9000/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/irix64_6.5-mips/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/irix_6.5-mips/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/linux_2.2.5-i686/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/osf1_4.0-alpha/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/sunos_5.6-sparc/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/sunos_5.7-i86pc/pqact
ftp://ftp.unidata.ucar.edu/pub/binary/sunos_5.7-sparc/pqact
If you have a platform for which none of these binaries is appropriate
or if you need pqact built with the GDBM option, you will have to
build a new version of pqact from source after making the one-line
change above. Here's how to do that:
% cd ~ldm/runtime/src/pqact
% mv palt.c palt.sav
Then copy the new palt.c to this directory.
% make
% cp pqact ~ldm/bin
We will be happy to assist with this and give top priority to any
questions about this sent to address@hidden.
We're sorry for the inconvenience and the late notice on this bug, but
it slipped by our testing.
Tom Yoksas