This monograph describes how changes in the system clock affect the Progress database manager. In particular, what happens at the end of summertime ("daylight savings time") is described.
The Progress database manager generates a time stamp for each bi cluster at the time it is closed. This time stamp is used for two main purposes:
- to determine the relative age of two clusters. This is done during database startup when we examine the linked list of clusters to determine that the linkages are valid.
- to determine whether a cluster whose contents are no longer needed has aged sufficiently to allow it to be reused.
The time stamps are obtained from the current value of the system time. The database manager gets the current system time by using the system call time(), which returns the current time and date in the form of elapsed seconds from the start of the Epoch (00:00:00, January 1, 1970), in Universal Coordinated Time or UCT. This was formerly known as Greenwich Mean Time.
Note that the time() function must return the correct time in order for the two usages described above to operate correctly.
In all Unix systems, the system clock is supposed to be set (and kept to) to UCT. Local time is established through the use of the time-zone environment variable TZ. The system automatically adjusts local time to take daylight savings time into account without affecting the system time, which is always in UCT. The Progress database manager does not use local time for timestamps. It is thus unaffected by changes in the value of local time.
However: not everyone operates their system in this manner. Some people set the system clock to local time and make manual adjustments for daylight saving time. This can cause many programs, including Progress, to fail. Some other examples of programs that might fail are cron, make, backup utilities, etc. Any event that is associated with the time and date may be handled incorrectly. Files may have incorrect time stamps, e-mail may have the wrong date, etc.
The sections below describe how various releases of the Progress database manager react when the system clock is changed. Note that the clock may be changed for reasons other than the change for daylight savings time. It does not really matter what the reason is.
If the system clock is adjusted backward, the database manager may notice this. In versions *prior* to 7.3A, when the database manager calls the time() function to generate a time stamp, if the returned value is earlier than the previous time stamp, it will issue error message 853 and shut down the database. This is necessary because it is no longer possible to determine the relative age of bi clusters (the new timestamp is earlier than the prceding one).
No damage is done to the database when this happens. When you restart the database, it will perform crash recovery and resume normal operation.
If the system clock is adjusted forward, the database manager does not know this and takes no special action since a new time stamp will be later than the old one. In this case, the relative ages of clusters is known correctly. But the absolute cluster age will be incorrect. A cluster may be aged prematurely and reused too soon. If the system crashes at this point (within a few minutes of the time change), crash recovery may not be possible.
If you are running a Unix system with the system clock set to UTC and using the TZ environment variable to get local time, then the automatic daylight saving time adjustments performed by the system would have no effect on the database manager and error 853 would not occur.
In version 7.3A and later, the database manager generates time stamps slightly differently. If it notices that the system clock has gone backwards, instead of shutting down, it writes a message to the .lg file recording the error. Instead, the error is added to an "accumulated clock error" field kept internally and all bi cluster timestamps are adjusted by the accumulated error.
This allows the relative ages of clusters to be known correctly if the system clock is adjusted backwards. However, there will still be an error in the absolute cluster age. This may cause a cluster to be aged longer than needed. This will do no harm, but may result in temporary bi file growth.
If the clock is adjusted forward, the database manager does not know this and takes no special action since a new time stamp will be later than the old one. In this case, the relative ages of clusters is known correctly. But the absolute cluster age will be incorrect. A cluster may be aged prematurely and reused too soon. If the system crashes at this point (within a few minutes of the time change), crash recovery may not be possible.
Copyright 1997, Progress Software Corp., All Rights Reserved
