Kbase P75193: Clock Changes and the Progress Database Manager
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
23/01/2007 |
|
Status: Verified
GOAL:
How does Progress handle time changes?
GOAL:
Clock Changes and the Progress Database Manager
GOAL:
How does Progress handles the Daylight Savings ?
GOAL:
Daylight Savings changes to the second Sunday in March in 2007.
FIX:
Customers are often concerned about how time changes, particularly Daylight Savings Time, will affect the operation their database.
This solution addresses these concerns.
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:
1) 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.
2) 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.
Before Version 7.3A
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 proceding
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.
7.3A and Later
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.
The 4GL TIME Function
The above discussion only addresses how the database manager deals with time changes. The 4GL TIME function returns seconds after midnight in local time. In the fall, it will see the clock going backwards and repeating an hour, and in the spring it will see an hour skipped..