Hi all,

Engineers in CSY have checked the STORE documentation and online
help and have determined that the STORE product is working as expected
and documented. We appreciate the notice to the HP3000-L list provided
by Stan Sieler, as this will alert STORE customers that compute dates
from the predefined HP variables to check their results. Two viable
solutions to the problem cited in HP3000-L are:

   1. use the predefined HPYYYY CI variable which provides a four digit
      year instead of HPYEAR CI variable, or

   2. use a method to pad the year with a leading zero,
      e.g., RHT("0!HPYEAR",2)

If anyone has any questions please contact Bijo at [log in to unmask]

Regards,
MPE/iX Store team


        -----Original Message-----
        From:   Stan Sieler [SMTP:[log in to unmask]]
        Sent:   Thursday, January 06, 2000 2:29 PM

        Hi,

        I just helped diagnose a problem where a site's
        partial backups weren't running since the start of the year.

        Turns out they were essentially doing:

           STORE / ; ; date>=1/2/0

        where the date was composed from: !HPMONTH/!HPDATE/!HPYEAR

        Unfortunately, STORE requires at least *TWO* digits for the year.

        Yes, you can argue that the STORE syntax says:

           DATE>=mm/dd/[yy]yy

        but...it allows m instead of mm, and d instead of dd ... so ...
        I classify it as a STORE bug.

        Here's what you get:

           :STORE / ; ; DATE >= 1/2/0

           YEAR PORTION OF DATE IS INVALID.  IT MUST BE GREATER
           THAN 1970 (70) AND LESS THAN 2027 (27).
           DATE SYNTAX 'mm/dd/yy[yy]'  (S/R 597)

        If you change it to:

           :STORE / ; ; DATE >= 1/2/00

        it works.

        So...check your backup scripts/jobs...I saw several postings on
        HP3000-L over the last few years where the date is composed using
        HPYEAR!

        (Remember, HPYEAR is an integer variable...so it can't "return
         00".)

        Stan Sieler