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)
[EMAIL PROTECTED]
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
<<inline: ecblank.gif>>
