Browse Prior Art Database

Method to handle changing the date/time on a system that uses DB2 Disclosure Number: IPCOM000129214D
Original Publication Date: 2005-Oct-01
Included in the Prior Art Database: 2005-Oct-01
Document File: 1 page(s) / 20K

Publishing Venue



DB2 is a world-class database program, and has much functionality while also being very flexible. However, a drawback of using DB2 is that it is not tolerant when the date/time is set back on the machine. (One might argue that it is actually doing the correct thing, but it is difficult to deal with nonetheless.) Essentially, if the date/time is set backward to prior to the date/time that some important action took place, DB2 might (rightly?) consider action had in fact not yet took place. This can be a problem. For example, if the date/time is set back prior to the creation of a user-defined function, DB2 might say that the function cannot be found when an attempt is made to use it. Disclosed is an automatic method (that is, does not require the user to perform any DB2-related actions at all) to avoid such problems.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 1

Method to handle changing the date /time on a system that uses DB 2

In summary, the method has a number of aspects: - Before performing initial setup of the DB2 system, the date/time is set back on the system, to two days after the license begin date (this date will be called "t1"). - Prohibit the user from setting the date/time back prior to t1, and if by some mechanism the current date/time is prior to t1 at boot, force it back to after t1. - If the date/time is set back prior to database/table creation (call this date/time "t2"), either rerun the database/table creation (losing all data in the tables) or do an export/import around a recreate of the database/tables (thus not losing any data). - If the date/time is set back prior to creation of dynamic aspects of the database (such as triggers, views, and functions), simply rerun the creation of these things.

There seem to be a number of possible date/times that are of interest:
1) The date that the DB2 license starts.
2) The date that DB2, or a fixpack, was installed.
3) The date that the instance was created.
4) The date that the database and its tables were created.
5) The date that "dynamic" aspects such as triggers, views, and functions were created.

In this article, t1 will be the date/time that step 3 was completed, t2 the date/time that step 4 was completed, and t3 the date/time that step 5 was completed.

The method encompasses the following: - Before performing all 5 steps above, set the date/time back on the system to two days after the license begin date. For example, if the l...