New technote on Daylight Savings Time (TSM).
Title * TSM and Time Zone/Daylight Savings Time FAQ
----------------------------------------------------------------------------------------
This document describes how Tivoli Storage Manager (TSM)
is affected
by time zone differences and Daylight Savings Time
adjustments.
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
TSM Scheduled Events
When using TSM's scheduling facilities, all scheduling
dates and
times are based on the TSM server host machine's system
clock. This
is generally not an issue when all TSM client machines are
in the
same time zone as the TSM server machine. In cases where
the TSM
server host machine's clock may differ from a client
machine - for
example, the server machine is located in New York and the
client
machine is located in California - then the difference
must be taken
into account when scheduling activity for that client. New
York is
three hours ahead of California, so if the client activity
needs to
begin at 8:00 PM local time (local to the client), then
the schedule
on the server must be defined to begin at 11:00 PM local
time (local
to the server).
NOTE: For the purposes of discussion, it is assumed that
system
clocks are set to their respective local time zones unless
explicitly stated otherwise.
The Effect of Daylight Savings Time
Suppose that the same TSM server described above has a TSM
client
located in Arizona. The state of Arizona does not observe
Daylight
Savings Time (DST). While New York observes Standard Time,
it is two
hours ahead of Arizona. While New York observes DST, it is
three
hours ahead of Arizona. Thus if the client activity must
begin at
8:00 PM local time, the schedule on the server must be
defined to
begin at 10:00 PM during Standard Time and changed to
11:00 PM
during DST.
What happens when the client machine's system time is
changed
This situation presents no difficulty. The TSM client
starts logging
new messages with the current (new) system time.
What happens when the server machine's system time is
changed
The TSM server performs a date and time ("date") check
whenever it
is started, and each hour thereafter. If the server
detects an
invalid date, then client sessions are disabled and
expiration,
migration, reclamation, and volume history deletion
operations are
disallowed. You either need to fix the system date if it
is indeed
in error, or else use the TSM administrative command
ACCEPT DATE to
force the server to accept the current date as valid. In
this case
you must follow the ACCEPT DATE command with ENABLE
SESSIONS in
order to re-enable the server for client sessions.
The TSM server treats any of the following as an invalid
date:
- Earlier than the date the TSM server was installed.
- More than one hour earlier than the last time the date
was
checked.
- More than 30 days later than the last time the date was
checked.
One-hour changes forward or back for DST are considered
valid.
Generally there are no problems when the TSM server
machine's date
is changed. The most typical changes occur when changing
between DST
and Standard Time. Considerations for these changes
include:
- Scheduled activity between TSM client and server that
reside in
different time zones, as discussed above.
- Scheduled activity that may not run. If a scheduled
event is to
occur between the current system time and the new system
time, then
the event may be missed for that day. For example, suppose
client
activity is scheduled to run between 2:15 AM and 2:45 AM
(the
schedule start time is 2:15 AM and the window is 30
minutes). If the
current time is 2:00 AM and the system time is advanced
one hour to
change to DST, then the new system time will be 3:00 AM.
The server
will thus treat the scheduled event as "Missed". The
exception is
for clients that use SCHEDMODE POLLING: their scheduled
activity
will still run. But the server will not prompt clients
that run with
SCHEDMODE PROMPTED. This situation can be avoided by
changing the
system time such that no scheduled activity falls between
the
current time and the new time.
When the system time is regressed then all scheduled
activity should
still run to completion. Scheduled events that occur
between the
current system time and the new time will not execute
twice. For
example, suppose client activity is scheduled to run
between 2:15 AM
and 2:45 AM (the schedule start time is 2:15 AM and the
window is 30
minutes). If the activity has already occurred and the
current time
is 3:00 AM, then if the system time is regressed one hour
to
Standard Time (so the new time is 2:00 AM), the 2:15 AM
event will
not run again when the clock reaches 2:15 AM.
Known problems and limitations
When the system time is changed on z/OS systems, the TSM
server
address space must be shut down and restarted in order to
pick up
the new system time. On all other platforms, when the
system time is
changed the TSM server automatically begins to use the new
system
time.
The following defect exists in TSM server versions below
5.2.2.0. It
is fixed in TSM server version 5.2.2 and higher.
PQ73834 - TSM server problem - Message "ANR9999D
SMNODE(nnn):
ThreadId<mmm> Error 19 initializing object set" occurred
when trying
to restore from a backup set that was created on or around
the
change between Standard Time and DST in a prior year. See
http://www-1.ibm.com/support/docview.wss?uid=swg1PQ73834
for further
information.
The following defects existed in client versions that are
no longer
supported.
IC13012 - TSM client for Windows problem - When a change
between DST
and Standard Time occurred on the client machine, the first
incremental backup of FAT partitions after the time change
resulted
in all files being backed up, even if the files hadn't
changed. This
problem existed in early ADSM version 2.1 Windows clients.
It is
corrected in version 2.1, level 0.5 and later. Due to the
age of
this defect and the affected clients, further information
is not
available on the web.
IC28544 - TSM client for Windows problem - When changes
between DST
and Standard Time occurred on the client machine
automatically via
the Windows feature "Automatically adjust clock for
Daylight Savings
Changes", the first incremental backups of NTFS partitions
after the
time change resulted in all files being backed up, even if
the files
didn't change. (The problem did not occur if the time was
adjusted
manually.) This problem existed in TSM client versions
3.7.2, 4.1.0,
and 4.1.1. It has been corrected in subsequent versions.
See
http://www-1.ibm.com/support/docview.wss?uid=swg1IC28544
for further
information.
----------------------------------------------------------------------------------------
Topic Daylight savings time , DST TSM server client
----------------------------------------------------------------------------------------
************************************************************************
Search on 7 digit technote number below (1164535):
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
Cordially,
Sam J. Giallanza
Tivoli Certified Consultant
Field Issues Manager
Field Input Communications (FIC)
giallanz AT us.ibm DOT com
520.799.5512 - T/L 321.5512
Our new web Support site and KB is at :
http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html
|