FW: Daylight Savings Time is this Saturday, please review the Web shpere MQ for iSeries Best Practice Guide

We just received this e-mail from IBM... It is specifically aimed at MQ
Series, but I think this is something that anyone using application
journaling should think about. We are lucky that we can afford to bring our
system down, wait and hour and then IPL, setting the clock back on the way
up. 
 
I believe V5R3 has finally given us a way to adjust the clock forward or
backwards gradually over a period of time... but if your system is PRE-V5R3,
like mine, be aware of the consequences of moving the system clock back an
hour...
 
Kenneth 
 
-----Original Message-----
From: Joel Pointer [mailto:joelp@xxxxxxxxxx]On Behalf Of
MQHOST/Raleigh/IBM%IBMUS
Sent: Thursday, October 28, 2004 8:55 AM
Subject: Daylight Savings Time is this Saturday, please review the Webshpere
MQ for iSeries Best Practice Guide
Importance: High



Daylight Savings Time is this Saturday - Please review the Webshpere MQ for
iSeries Best Practice Guide 

3.8 Daylight saving time 
OS/400 does not have automatic provision to adjust the clock for daylight
saving time. iSeries 
users must adjust the system clock (and UTC offset) when making adjustments
for daylight savings time. 
This causes problems for WebSphere MQ on iSeries, because WebSphere MQ uses
timestamps based on 
the system clock to access data in the queue manager's journal. If the
system clock changes while 
WebSphere MQ is running, then WebSphere MQ can fail to access journal data
correctly. It is therefore 
necessary to quiesce WebSphere MQ before changing the system clock. 

3.8.1 Spring time change 
When the clocks go forward one hour in the spring, WebSphere MQ can just be
shut down for the time it 
takes to adjust the clock. The queue manager can be restarted immediately
after changing the clock 
and UTC offset. 

3.8.2 Autumn or fall time change 
When the clocks go backward in the autumn or fall, you cannot restart the
queue manager immediately 
after changing the clock backwards. If you do so, there is a risk that
WebSphere MQ will write 
duplicate timestamps to the journal. You should ensure that WebSphere MQ is
stopped for an hour 
either before, or after the time change and UTC offset update, to avoid the
problems associated 
with setting the system clock backward by an hour. 

In environments where downtime must be minimized, an enforced outage of one
hour may not be acceptable. 
IBM is looking into providing a better solution, but until this is
available, the only alternative to 
quiescing the queue manager for an hour is to perform a controlled cold
start of the system (see section 
3.5 for a discussion of the Cold Start). A controlled cold start is one
where all queues are emptied of 
any persistent messages and the queue manager is cleanly shut down. The
queue manager journal data can 
then be deleted per the cold start procedure. This eliminates the risk of
losing messages, but it still 
deletes all media recovery information. You will not be able to recover
damaged objects without media 
recovery information, so you should ensure that you have backed up your
object definitions prior to 
attempting this (see section 3.6.2). Your IBM service representative will be
able provide details of 
the cold start procedure. 


WebSphere MQ - Host mailbox (OS/390, z/OS, AS/400, VSE)
An open problem record (PMR) is required before sending email to
mqhost@xxxxxxxxxx
Call  your IBM Support Center to requeue, update, or open a PMR to Level 2
(In the U.S., call 1-800-237-5511)