sap oracle hp-ux and dst

[gbruner]

Can someone please tell me how these three products exchange time with each other? I am getting some resistance within my organization to apply hp-ux dst patch because it is argued that sap is self-sufficient with regard to time and does its own time-processing internally. Could sap and oracle function properly without this hp-ux dst patch?

[Jan van den Ende]

gbruner,

WELCOME to the VMS forum, dealing with the greatest and most stable OS around.

But, to improve your chances for a correct answers for your question, you might be better served in the HPUX forum:

http://forums1.itrc.hp.com/service/forums/familyhome.do?familyId=117

Proost.

Have one on me.

jpe

[melvyn burnard]

posted in wrong forum, moved to more appropriate forum

[Rick Garland]

The absolute answer to your question really cannot be answered until after the DST change. However, there is no reason to believe that SAP and Oracle will crash because of the time change. his typically happens twice a year anyway - just this year it is at different times.

What is probably going to be an issue is the timing. SAP and Oracle do work with the OS time in addition to some of their own time settings - embedded java comes to mind.

Your log files, transaction times, etc, could be off an hour.

If you can deal with the 1 hr difference for 4 weeks a year, ...

[Bill Hassell]

The paranoia for this year's DST changes is amazing. There have been many, many changes to the tztab file over the years, most for non-US locations. It would be interesting to see how SAP can figure out the time of day without help from HP-UX.

Were there a bunch of special SAP and Oracle patches to fix it's internal table or does SAP and Oracle use GMT (ie, UTC or Zulu time)? If SAP/Oracle uses GMT, are your servers set correctly (hint: date -u) When sysadmins change time, they almost NEVER use date -u and are therefore setting the HP-UX time (which is always GMT and never changes for DST) with the current login value of TZ and the rule in tztab.

The tztab patch is a trivial ASCII file with rules that any sysadmin can change at any time. The man page for tztab is quite helpful here. Note that SAP and Oracle often have ancillary or middleware software manufactured by another company -- how will a broken HP-UX work with those programs?

If you do *NOT* update the tztab file then HP-UX time will be wrong and the first knee-jerk reaction will be to change the time 4 times this year:

1. Change time forward earlier than the old tztab file states;
2. Later, the old tztab file changes the time forward and now time is an hour too fast, so change time backwards;
3. In the fall, the old tztab file will move time backwards too early and another time correction is needed;
4. When the correct DST change hits, manually change the time again.

Repeat each year from now on until new legislation changes it again. Oh, if the sysadmin changes the HP-UX time and SAP gets the current time from HP-UX, data records will be indeed messed up.

Tell the DBAs to talk directly to SAP/Oracle and middleware vendors. I'm sure they will all agree that the OS must keep correct time for their products to work. There are some other exceptions such as Java that must be addressed separately.

[gbruner]

From my research, it seems that Oracle gets its system time from HP-UX. It then passes that time to SAP R/3 Database server and synchronizes time on the SAP R/3 Application server(s). SAP R/3 seems to be self-sufficient in terms of time management. It provides a table of offsets to configure time adjustments within its own environment.

We have 9 servers with sap/oracle/hp-ux.

6 Integritys running 11.23 located in US doing business worldwide. these are patched to PHCO_34669 which makes us partially compliant w/ 2007 DST because it covers only US timezones. Rather than apply the subsequent OS patches which address Canadian timezones, I think we will handle Canadian Timezone offsets within SAP.

3 PA-RISC in Germany running 11.0 doing business only in Europe, but system time is set to EST. These have no DST patches. Since they dont do business in North America, I think if we just set system time to GMT on these servers, we will be alright..