HP3000-L Archives

December 1998, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Larry Boyd <[log in to unmask]>
Reply To:
Date:
Thu, 17 Dec 1998 11:03:41 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (62 lines)
Chris Enderle wrote:

> We have converted our data and applications to accomodate 8 digit dates.
> We tested with Time Machine and Time Shift and everything is performing
> normally.   Our customer has asked us to perform a 'real' simulation by
> booting the system with a date in the year 2000 and then testing
> system and
> application software.  Has anyone done this before?  I know we have to be
> concerned with software licensing since some of the software licenses
> require annual renewal.  Are there issues we need to be concerned
> with when
> we roll back the system to the current date.  Does anyone have a project
> plan with which they have done this?   We plan on taking an entire weekend
> to roll forward, test and then roll back.  Is this enough time?  Thanks in
> advance for anyone's help.

Chris,

There are additional issues you need to be concerned about if the test is
being performed on a production (or temporary test) machine.  As you know,
when the system clock is changed, *all* date/time requests will see the
advanced date.  On a system that contains data files, system log files,
database log files, etc. that relate to any production activity, the dates
will be the advance date.  Is that a problem?  Only if you don't realize
this before starting the test.

If there are production data, you will need to restore all of the affected
information.  For data files, the purpose is to ensure that normal
production procedures, such as backups, are not adversely affected when the
system clock is reset to the real date/time and production begins to run
again.  If you use your system log files, these will also need to be
restored (or erased) after the test, so that reporting issues do not contain
abnormal dates/times.  Database log files, such as for Oracle, Allbase and
Image, will also need to be restored, in case there is a need to rebuild the
database using the log files.

There are a lot of arguments over exactly what you do need to restore or not
restore.  In our opinion, we recommend the better-safe-than-sorry approach.
We recommend that all customers do the test that your customer is requiring
to make 100% sure that incoming and outgoing data (no computer is an island
anymore) actually work between the other computers.  We also recommend that
a full backup occur *before* changing the system clock (even on a test
machine), and once the tests are completed, to restore the whole system
*after* resetting the system clock to the real time.  This procedure will
ensure, 100%, that the system is back to the pre-system clock change.

Yes, this is time consuming.  However, it is like insurance.  When you need
it, you really need it.  Some will argue that this is "overkill".  On the
other hand, we have seen instances where the customer did not fully restore
the system, and problems resulted from the advanced date entries.

Good luck, and glad to see you are so far ahead of the game!

lb
--------------------------------------------------
Larry Boyd   (Mailto:[log in to unmask])
Director of Business Development
SolutionSoft Systems, Inc.
http://www.solution-soft.com
Tel: (408) 988-7378   Fax: (408) 988-4777
--------------------------------------------------

ATOM RSS1 RSS2