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

20000306: ldm-generated data files

>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