[frederic]

I had pb sunday on 2 production servers (i5 / automator 3.20).
After the change of the time ( 2h00 > 3h00) on March,29 , jobs are submitted with one hour delay. This became ok the next instance (monday).
The i5 concerned had their time changed by the TIMZONE set to QP0100CET2.
The Automator server had his time changed by the time zone in Windows.

One i5 worked fine, but the automator agent has been stop and restart during backup from saturday night to sunday morning.
Has anyone experience trouble like these ?
Thanks
Fred.

[Dennis Hickford]

Hi,

I have not heard of this problem for any other customers although there have been problems in past years when the time goes back or forwards. It is my understanding that all these problems have now been fixed.

If you think you have found another problem I think the best way forward for you is to call you local support and raise a new case id describing the problem.
We would then require the opspserver log files and the sp_200903....... file from the PS and the log file from the MS, so that support can build a picure of exactly what happened and when.

It is better to do this quickly before your log files get overwritten.

[pascal]

I had pb sunday on 2 production servers (i5 / automator 3.20).
After the change of the time ( 2h00 > 3h00) on March,29 , jobs are submitted with one hour delay. This became ok the next instance (monday).
The i5 concerned had their time changed by the TIMZONE set to QP0100CET2.
The Automator server had his time changed by the time zone in Windows.

One i5 worked fine, but the automator agent has been stop and restart during backup from saturday night to sunday morning.
Has anyone experience trouble like these ?
Thanks
Fred.

Hi,

There may be a problem depending on your OS version.
This is the official response from IBM:



The reason that mktime() computes a different value in V5R4 is because
of a system limitation. In V5R4, there is no system support to
determine whether any given date is within Daylight Savings Time (DST)
or not. Because of this, the mktime() function just uses the QUTCOFFSET
system value to compute the time zone offset. If the date given to
mktime() is within DST and the current system time is NOT within DST,
the value returned by mktime() is one hour (3600 seconds) off.
Similarly, if the date given to mktime() is NOT within DST and the
current system time is within DST, the value returned by mktime() is one
hour off. The mktime() function indicates this by setting the tm_isdst
field within the 'tm' structure to a negative value, indicating that the
DST status for the time is 'Unknown'.

In V6R1, the system was enhanced to provide this information and thus
mktime() works correctly. It can compute DST for any given date. The
mktime() function will set the tm_isdst field within the 'tm' structure
to zero or a positive value to indicate that DST is off or on,
respectively.

This change is not directly mentioned in the V6R1 Memo-To-Users, but is
indirectly part of the 'Time zone changes' mentioned on page 48 of the
V6R1 Memo-To-Users document.

Because of the complexity and range of the changes, it is not likely
that this V6R1 support will be provided in releases prior to V6R1.

There are several potential ways to deal with this difference in
behavior. Here are some options, in no particular order:

1) Ignore the difference on V5R4. The computed value may be 3600
seconds off, but the problem is fixed in V6R1.

2) Change the code to check the value of the tm_isdst field after the
call to mktime(). If it is set to a negative value, this indicates that
the result may be 3600 seconds off due to an unknown DST value.

3) Change to use a *LOCALE which contains time zone information. The
default locales provided on the system do not contain time zone
information and so the time zone information is retrieved from the
system (with the inherent limitations indicated above). If time zone
information is provided within the locale, the mktime() function will
use that information instead and correctly compute the DST value based
on the locale time zone information. Locale information can be found at
http://publib.boulder.ibm.com/infocenter/i...ic/nls/rbagsloc
ale.htm and to create a locale, look at the
http://publib.boulder.ibm.com/infocenter/i...ic/nls/rbagsixa
mplecreatelocale.htm web page.

If option 3 is chosen, here is an example with time zone information for
the United States Central Time Zone prior to the year 2007:

LC_TOD

tzdiff 360
tname "CST"
dstname "CDT"
dststart 4,1,1,7200
dstend 10,-1,1,7200
dstshift 3600

END LC_TOD

Here is an example with time zone information for the United States
Central Time Zone for year 2007 and later:

LC_TOD

tzdiff 360
tname "CST"
dstname "CDT"
dststart 3,2,1,7200
dstend 11,1,1,7200
dstshift 3600

END LC_TOD

Best thing it's to restart the production server if
you have a "bad" OS version.

Regards
Pascal