Daylight saving time changes in March - potential mini Y2K

[Former Member]

Just a heads up.....

If you have servers in United States of America, Canada, and Brazil you may want to check note 1001092.

Daylight saving time is changing early in March and there are a number of issues for SAP systems. There is an IBM APAR plus Java fix packs etc.....

Matt

PS this is not just a SAP issue...

[Former Member]

Hmmm. After reading all of the posts wouldn't it be easier to just modify the PASE_TZ parameter to reflect the new dates for the DST change? Using the WRKENVVAR to change the value of PASE_TZ to fit your time zone? example: Eastern TZ "EST5EDT,M3.2.0,M11.1.0" instead of "EST5EDT,M4.1.0,M10.5.0'.

Chris

[Former Member]

Hi Chris,

I FULLY agree with you here and that's exact the same as I discussed with Doreen last night ...

This DEFINETELY will work ... the other options will work in most cases as well ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

We performed all the O/S patches that we could find identified for DST in general and specific to SAP (see below)

These are V5R3 specific

PTF’s for V5R3M0 5722SS1

SI26039 and SI25991

Per OSS NOTE 983147

iSeries: V5R3 with Java Fix Pack 11

SI25968 - 5722JV1 Opt 5

SI25960 5722SS1 Opt 3

(default JDK)

Applying the patches listed above, automatically changed our system value QTIMZON from QN0600CST to QN0600CST2

Reviewing of the timezone values, showed that QN0600CST2 reflected the new start & end dates for DST effective with 2007

The box has been running with these patches for a week

The business config team applied OSS note 919538 to a test client in DEV

We then took the box to March 11 at 2am which automatically rolled to 3am

We thought we were golden.

Then started SAP -- it came up but you couldn't run a single transaction without dumping due the the ZDATE_LARGE_TIME_DIFF errors being generated (see below was taken from the dump)

Time difference between DB and appl. server.. 3600 s

Local time zone.............................. "UTC+21600 sec

(CST6CDT5,M4.1.0/2,M10.5.0/2)"

Local time................................... "2007/03/11 03:05:37 CST"

UTC time..................................... "2007/03/11 09:05:37"

Local time in internal format................ 1173603937

Database time................................ 20070311040537

When reviewing the dumps, it didn't immediately register with us that the (CST6CDT5,M4.1.0/2,M10.5.0/2) value was coming from the PASE_TZ environment value.

Also, it was strange that at the i5/os level, the time was 02:05 but the SM21 SAP logs & ST22 dumps were all timestamped at 03:05; so while we changed the server time, SAP had it's own way of determining the time.

We determined that SAP was pulling the time of day from the PASE_TZ environment variable and at the same time found OSS note 960259 which talked about patching R3INLPGM to level 11 (6.40 kernel)

We patched R3INLPGM in the kernel & deleted the *SYS PASE_TZ environment variable on the box and then SAP ran without issue.

This was not fun

[Former Member]

Hi Doreen,

I'm glad to hear, that you really tested it that good ))

Sorry, that you struggled a bit the first times.I guess, that the problem with the "hard-coded" PASE_TZ will hit a lot more customers I would assume :-((

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hi Doreen,

I made a great experience in Chicago as well:

We decided to NOT use DST => our QTIMZON is QN0600UTCS.

Now we removed the PASE_TZ environment variable and R3INLPGM Patch 14 created the following:

PASE_TZ 'UTC:S6'

... for me this looked promissing )

... until I saw the following with the next SAP restart:

The error probably occurred when installing the

R/3 system.

There is a considerable time difference between the local time of the

application server and that of the database, which prevents your SAP

System from operating correctly.

Time difference between DB and appl. server.. "-21600" s

Local time zone.............................. "UTC+0 sec (UTC:S6)" <<<<

Local time................................... "2007/03/04 03:16:30 UTC"

UTC time..................................... "2007/03/04 03:16:30"

Local time in internal format................ 1172978190

Database time................................ 20070303211630

get the error corrected immediately.

Local time................................................ "2007/03/04 03:16:30

UTC"

UTC time.................................................. "2007/03/04

03:16:30"

Local time in internal representation..................... 1172978190

Database time............................................. 20070303211630

Obviously 'UTC:S6' is seen as UTC+0 and not UTC-6 :-((

So, we set it systemwide again to the following and now it works:

PASE_TZ 'CST6'

... and it should not switch next week with the DST ...

So, these automatic tools are really "interesting" ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hello Matt,

Thank you very much for the headup!

Just want to add a bit more info folks here might need:

After the PTF being applied, <SID>OFR then WRKENVVAR should show different value of PASE_TZ, like "EST5EDT,M3.2.0,M11.1.0" instead of "EST5EDT,M4.1.0,M10.5.0'.

Note 919538 needs to be applied on ABAP stack. (SNOTE doesn't work)

Note 983147 - JDK (need Java Group PTF as Matt pointed out)

Best regards,

Victor

[Former Member]

We are at V5R3 & applied all ptf's I could find --- this did not change the PASE_TZ value. Do you have the specific ptf that addresses this?

ptf's did change the TIME ZONE (WRKTIMZON) value

Rolling the box date / time to March 11 - 2am produced errors in SAP and basically was not usable

Then found patch #11 KERNEL 6.40 for R3INLPGM -- applied the patch and still had the errors. SAP was getting the wrong value for timezone (was still pulling from ENVVAR PASE_TZ)

Then WRKENVVAR *SYS & deleted ENVVAR PASE_TZ

Restarted SAP & now it's finally running ok March 11 - 4am

Yes, we are quite far behind on kernel patching ECC 5.0 6.40

Yes, we are running V5R3 of the O/S

BUT - searched and searched for ALL U.S. DAYLIGHT SAVINGS TIME (DST) considerations on SAP & IBM sites and did not run across this requirement. We did not review the APAR.

[Former Member]

Hello Doreen,

Thank you very much for testing the time change like this! You could save many folk from struggling with it at 2 AM March 11.

If I understand what you experienced correctly... the issue was solved by removing PASE_TZ from WRKENVVAR *SYS eventually.

What I noticed before (last year or earlier) is that when PASE_TZ is configured in WRKENVVAR *SYS, SAP kernel would simply copy the value, instead of manipulating it itself. And the result from the SAP kernel could be different what I manually got from IBM support/document and put into WRKENVVAR *SYS. But if PASE_TZ is removed from WRKENVVAR *SYS, SAP kernel did handle it smoothly.

Note 391658 says that "First, use the WRKENVVAR LEVEL(*SYS) command to check whether the environment variables PASE_TZ or TZ are set system wide, and delete them if necessary."

With what you tested, it might be better to clearly state that PASE_TZ should be removed from WRKENVVAR *SYS. (It might be just due to translation...)

Please correct/comment...

Best regards,

Victor

[Former Member]

Hi

Do you have to apply Note 919538 to all the clients apart from the ones we have created ?? I mean what about client 000 and 061...?????

Thanks

Abhi

[Former Member]

Hi all

Got my answer in another post...has to be done in all clients

Thanks anyway

Abhi