Are you ready for Daylight Savings changes?

"This year, daylight saving is starting early--a change that could cause Y2K-like headaches for IT professionals, and even for consumers."

http://news.zdnet.com/2100-9589_22-6159840.html


From Oracle:

"PROBLEM: A change to the Daylight Savings Time (DST) rules the United States for 2007 will require that EnterpriseOne customers make a change to their systems.

The DST rule for 2006 in the United States is that DST begins on the first Sunday in April (April 2, 2006), and changes back to standard time on the last Sunday in October (October 29, 2006), but beginning in 2007, US DST will start on the second Sunday in March, and change back to standard time on the first Sunday in November. "

http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=201019165

I placed a call with Oracle and talked to a platform support analyst - one I highly respect. He stated if clients are using websphere only to host Enterpriseone, then no udpates are needed to the JDK in websphere. If clients are using websphere to run/host native, homegrown applications such as .NET, then the websphere patch is required. The timestamp is populated from the enterprise server for E1, not the .dll in websphere. Further, the analyst stated the documentation on the customer connection is misleading. All release are required to use the P00085 application to make the adjustments within E1 itself.

So does that mean the only change we need to perform is withing that P00085 application (inside JDE) and everything should be fine.. No need to change or apply any patch on the enterprise server, webserver, citrix and all

We have 2 Enterprise servers on UNIX, 2 Webservers on UNIX, and a couple of Citrix servers for clients and some for createform etc.. So what should be our course of action?

I saw something on Customer connection .. see this snippet..

"Please be sure that you verify individual DST requirements for all outside vendors associated with your solution including Operating System Vendors. The following is a list of sites from our platform partners about Daylight Savings Time issues for their products. Oracle recommends applying patches recommended by these vendors to address Daylight Savings Time issues with their products: "

http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=201035128

Please let me know your views.

Thanks in anticipation,

Cheers,
CNC Guy
E1 8.10
UNIX

For those of you who want to be safe, here is a link to an IBM site with information on how to patch WebSphere:

http://www-1.ibm.com/support/docview.wss?uid=swg21219396

I would suggest treating this the same way y'all did for Y2K. Remembe r
that? Check with each vendor individually. There's no way for Oracle to
certify WebSphere or for IBM to certify Citrix. Everyone will have the ir
own take on the issue and will have to provide solutions (if required) for
their own products. They won't certify other vendors' products even if
they work in concert with each other.

Regards,
Gerald.






CNC Guy
<shashankarora@ya
hoo.com> To
Sent by: [email protected]
jdelist-bounces@j cc
delist.com
Subj ect
Re: Are you ready for Daylight
21/02/2007 09:15 Savings changes?
AM


Please respond to
JD Edwards=AE
EnterpriseOne
<jdelist@jdelist.
com>






So does that mean the only change we need to perform is withing that P0 0085
application (inside JDE) and everything should be fine.. No need to cha nge
or apply any patch on the enterprise server, webserver, citrix and all

We have 2 Enterprise servers on UNIX, 2 Webservers on UNIX, and a coupl e of
Citrix servers for clients and some for createform etc.. So what should be
our course of action?

I saw something on Customer connection .. see this snippet..

"Please be sure that you verify individual DST requirements for all out side
vendors associated with your solution including Operating System Vendor s.
The following is a list of sites from our platform partners about Dayli ght
Savings Time issues for their products. Oracle recommends applying patc hes
recommended by these vendors to address Daylight Savings Time issues wi th
their products: "

http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_S UMMARY.GBL?page=3DC1_SOLN_SUMMARY&SETID=3DSHARE&SOLUTION_ID=3D201035128


Please let me know your views.

Thanks in anticipation,

Cheers,
CNC Guy
E1 8.10
UNIX

[ QUOTE ]
So does that mean the only change we need to perform is withing that P00085 application (inside JDE) and everything should be fine.. No need to change or apply any patch on the enterprise server, webserver, citrix and all

We have 2 Enterprise servers on UNIX, 2 Webservers on UNIX, and a couple of Citrix servers for clients and some for createform etc.. So what should be our course of action?

I saw something on Customer connection .. see this snippet..

"Please be sure that you verify individual DST requirements for all outside vendors associated with your solution including Operating System Vendors. The following is a list of sites from our platform partners about Daylight Savings Time issues for their products. Oracle recommends applying patches recommended by these vendors to address Daylight Savings Time issues with their products: "

http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=201035128

Please let me know your views.

Thanks in anticipation,

Cheers,
CNC Guy
E1 8.10
UNIX

[/ QUOTE ]


We are running on several AS400's and those will be patched, even though we manually adjust the time on those. This weekend, our Intel servers will be patched at the OS level. I plan on running some tests after the OS patch goes in on the Intel web servers. I will manually forward the date on the web server (while the enterprise server stay same in EST). By running transactions, I should still see the same timestamp - I think.

I spoke with our tech support reps from TomorrowNow. As an XE customer that is not using the JDE scheduler (we use Tidal instead), there are no JDE concerns. JDE releases 8.11 and higher require changes to P00085. I made the change anyway, just to be safe.

Websphere per se, does not have an issue, but Java does. Java does not look to the OS for time rules. It has it's own time rules. This is because Java is cross platform. We will need to either update Java to a release with the new rules, or use the tzupdater to update the time zone rules. Depending on your version of java, you will need a different tzupdater. Here are the versions:

1.3.1 tzupdater V1.0.1
1.4 & 1.5 tzupdater V1.0.1
1.4 & 1.5 tzupdater V1.0
Available from http://www.hp.com/go/java and click on
DST information link

Gregg Larkin
Praxair North American System Admin
JDE CNC and Security, Websphere, Tidal, Princeton Softech

Aside from OneWorld it's my understanding that there are Microsoft OS patches that are necessary and there were issue with the Outlook calendar even with the patches. I also heard there were no patches for Windows 2000.

I hope this post isn't construed as hijacking the thread.

Patty

[ QUOTE ]
Aside from OneWorld it's my understanding that there are Microsoft OS patches that are necessary and there were issue with the Outlook calendar even with the patches. I also heard there were no patches for Windows 2000.

I hope this post isn't construed as hijacking the thread.

Patty

[/ QUOTE ]

Correct. We applied to our Webservers and Deployment boxes already.

http://support.microsoft.com/kb/931836/

http://www.microsoft.com/windows/timezone.mspx

For those of you looking for a tool to test the web server, I found this web page at IBM that has a java tool to test if your jre is updated for the new DST changes:

http://www-1.ibm.com/support/docview.wss?rs=3068&context=SSNVBF&uid=swg21251761

I installed the new JDK, then ran the JTZU tool on our JDE test web server. Then I ran this java test tool. Leaving the tool running, I changed the time on the server to just before the DST change and waited. This java test tool displayed the correct time both before and after Windows updated the time.