Kbase P10442: How does Progress handle time changes?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/12/2005 |
|
Status: Verified
GOAL:
How does Progress handle time changes?
FIX:
Clock Changes and the Progress Database Manager
Introduction
------------
Customers are often concerned about how time changes, particularly
Daylight Savings Time, will affect the operation their database.
This Solution addresses these concerns.
Clock Changes and the Progress Database Manager
-----------------------------------------------
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 preceding
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.
Progress Software Technical Support Note # 16280.