Y2k testing

    [Ed: Please see II_DATE_CENTURY_BOUNDARY and II_DATE_FORMAT articles 
	 for more on Y2k]


> Next month, we are starting our Y2K tests. These tests will be for our apps.
> I'm pretty sure Ingres will be OK except for one thing.
> Before our tests, we will reboot the system and change the date to Dec
> 31st 1999. Will Ingres have trouble opening journal and config files that
> seem almost a year old ? Does Ingres check for stale dates ?
> 
> Andre



Hi Andre,

    There is no problem with setting the date forward by a year (or more) from
    an Ingres point of view. However, you may find you blow the OS licence
    agreement dates let alone any other software you use with a licence
    agreement. I think you can probably guess how I worked that out!

    Dont forget that a lot of installation 'cleaning' scripts you may have are
    based on the age of the files. After a date skip, files you may rely upon
    will become very old and may get wiped out. I suggest you turn off all
    your maintenance processes and run them by hand only. 

    Furthermore, if the host you use for the Y2K test is an ingres
    installation you regurly do testing or development on then you have
    another problem. That is, how to set the clock back to the current
    date/time after Y2K testing is finished. The date is stored in a variety
    of places ie log file, config files. I'm not sure I'd want to see what
    will happen if you simply restart Ingres at the current time when an awful
    lot of way future times exist in several important places. Could be messy!

    Hence If the installation is of any importance to you I'd suggest that 
    before you skip the date forward you checkpoint everything and then dump 
    the entire system to tape and put that tape on your desk where no pesky 
    operator can get their hands on it. After that you should be reasonably 
    safe to skip the date around. At worst, all you'll have to do on the back 
    step is reformat the log and recover the databases. 

    However, the biggest problem in Y2K testing we encountered (which I way
    underestimated the difficulty of) was not date skipping. We had to put a
    LOT of work into pushing the data forward in time. That is a lot of our
    databases have an intimate internal knowledge of time. Simply pushing the
    clock forward is not enough. Take a payroll database as an example. We had
    to push the damn thing through End of Financial year processes, end of
    Calander Year Leave Loading Allowances, plus fortnightly pay processes.
    Each of which required a seperate date/time jump forward before we got
    close to 2000!

    The Y2K Testing went like a dream after that! We actually found no
    problems from a Y2K point of view but the side benefit of all this testing
    was the the users discovered several unrelated minor bugs in the 
    applications. Handy.

    Martin Bowes
Ingres Q & A
Back to William's Home Page
Email William