I just read http://techsupport.informationbuilders.com/tech/all/all_tmo_dst2007.html

and I need to have something clarified.

When they mention "the WebFOCUS Client" - what do they mean? Do they mean Developer Studio? Anyone using Developer Studio would have to get their Java upgraded?

The tech support fellow for one of my clients thinks he needs to upgrade Java on the workstations of every WebFOCUS user - I think he's wrong. What have other people decided?

Is this getting more confusing than Y2K, or am I crazy?

Cheers,

My take on it seems to me it is the application server that needs to have proper processing to handle the daylight savings time change and the WebFOCUS world will be fine. Of course if the applications are all run localhost may cause some issues.

You're right this is almost as bad as Y2k, and we had a fallout from that just this past week, ah will it never end.

For those of you having snow, stay warm, stay safe.

Microsoft and many other OS vendors have issued hotfixes for the changes in daylight saving.

If those fixes are applied then there should be no issue as far as any WebFocus user is concerned. Except when Java is involved.

SUN certainly say you need to upgrade, see the following

http://java.sun.com/developer/technicalArticles/Intl/USDST/

Microsoft has also issued updates for it's JVM
so it's patches will need applying to clients.

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

The article says that the JVM should be above 1.4.2_10. However IBI only certifies 7.1.4 with 1.4.2_10, any thing above this it only "supports".

Is any one out there running 7.1.4 on 1.4.2_11 and above without any issues?.

"Except when Java is involved" - is it not involved in MRE, in Dashboard?

"However IBI only certifies..." Different versions, different issues.

Still confused :<

Welcome back JG.

yes, welcome back JG
and if you're running WIN2k, there's no hot fix.

We are running WebFOCUS 7.1.7 using Sun JRE 1.4.2_06 or higher. This is fine. However, we also have WebFOCUS 5.3.2 which does not work with JRE 1.5.7 or higher. As long as we staywithin that range of releases, both versions work fine. The issue is that the DST patch from Sun is 1.5.9 and that creates a problem for the 5.3.2 version of WebFOCUS. It is only the aspects of webFOCUS that use java that are affected. e.g. Report Caster Console, MRE, etc. The Report Caster issue only affects access to the console (in our case, developers and administrators only - we use API calls for caster). Report Caster itself works fine. We don't use MRE, so not sure of the details of impact there. Our solution is to upgrade the apps in 5.3.2 to 7.1.7
Francis, to answer your question regarding WebFOCUS client, the WF Client is the component that directly interacts with your web server. Our site has this on a separate machine than the WebFOCUS server.

quote:

the WF Client is the component that directly interacts with your web server

Then, doesn't everyone use the WF Client?

Diptesh, thank you for the explanation. I'm not sure the client wants to upgrade from 5.3.2 to 7.1.7 just because of the DST issue - upgrading will cause a whole pile of other issues that have to tested.

SO far, this all doesn't sound too good.

Susannah the following link has a utility that you can down load to patch
any widows operating system (XP, NT, 2000, 2003, Vista).

Intelliadmin has kindly made this available free of charge but it has to be run on every machine.

For $129 they have a network tool that can manage it for you.

It's only of any use to those of you in North America but it's better than nothing.

http://www.intelliadmin.com/Daylight%20Saving%20Fix%20Download.asp

We are on WebFOCUS 528 we are in the current process of upgrading to 714. Anyone on WebFOCUS52?

Kevin,

We are on 5.2.8 server, 5.2.4 Dev Studio desktop. We're going to use the tzupdater tool to modify the time zone data in Java for ReportCaster.

Carol

Are we getting needlessly involved with Java Runtime Environment (JRE) and the requirement to implement Sun's latest version just to get unneeded DST functionality?

If the advancing/retarding of a server's or a desktop workstation's clock by one hour at the proper moment is the responsibility of the computer's operating system, and its manufacturer (i.e. Microsoft, IBM, etc.) offers patches for that, then what does IBI and its WebFOCUS application care about whether DST is in effect or not at any moment of program execution?

I can think of only three situations in which a program (WebFOCUS itself or an executing FEX) will produce wrong results if it runs with inmproper DST 'rules':
(1) Performs arithmetic on date-time variables where the range of dates involved spans the DST start/end hour (two 2am's each year). If an algorythm's date range is wholy within a DST phase (Summer/'on' or Winter/ 'off') the results produced are indifferent to any aspect of DST.
(2) Analyzing the content of a date-time variable to determine if DST is in effect at the moment represented by the variable's content.
(3) Geographical time-of-day/elapsed-time computations where DST is 'on' at one/some locations and 'off' at others. (But, DST and time zone 'rules' for the locations involved are likely to be wholy witin the algorithm and not subject to the time shown by the executing computer's clock.)

The only reason to update JRE in the current DST context is to update whatever rules it may contain about the start/stop dates of DST so that these three situations produce correct results.

IBI uses Sun's JRE to implement many WebFOCUS functions. Most, I suspect, enable it's 'multi-platform' characteristics. But after working with (Web)FOCUS for 20+ years I haven't seen any IBI functionality that implies these three situations.

If all of WebFOCUS were implemented with JRE (it's not), then where would it do tasks 1-3, that would be corrected by a DST update?
- MRE and Developer Studio just store, edit, and submit text for execution. No date-math involved there.
- The FOCUS 'engine' executing a *.fex doesn't care about time, except as coded within the *.fex, and to compute elapsed and accumulated job-time.
- Generating Synonyms and metadata, and administrating server and workstation configurations and environment are all time indifferent.
- ReportCaster only cares about time when computing the moment of a job's next execution, and determining if a job's start time has passed since the clock was last checked. I read TM4617 and can see that when the computer's clock suddently changes by 1 hour on at 2am on the 'magic' dates, then RCaster's continually asking "has this job's start time passed since I last looked at the clock?" will result in jobs being dispatched as described.

My experience in IT applications has not touched some with whom other members of this forum are familiar, but in consideration of the above arguments, will we really see any change in WebFOCUS behavior if we update Windows for DST2007 and leave Java alone?

The Windows XP operating system and Java on my and thousands of other workstations of a major financial institution were patched for the new DST date.

The patches have caused a problem in Microsoft Outlook: meetings scheduled between the new DST date and the old DST date are scheduled one hour later than they should be.

I would say this would have a major impact to businesses that rely on a meeting scheduler like Microsoft Outlook.

A message from Tech Support of said financial institution:

"Microsoft and IBM have stated that due to the change in DST this year, Microsoft Outlook and Lotus Notes users may see start/end times for calendar entries made between March 11 - April 1 and October 28 - November 4 (extended DST weeks) display incorrectly by one-hour in their calendars.

Technology and Operations is implementing changes to correct this calendaring issue, however calendar entries created prior to February 19, 2007, which are scheduled during the 4 weeks indicated above may still display incorrect times."

The recommendation:

"... recommends calendar users add the meeting time and appropriate time zone to the “subject” or “body” of each calendar entry scheduled between March 11 - April 1 and October 28 - November 4 (e.g. Project Status Meeting – 10am-11am EDT)"

Just adding my two cents to this topic.

Here's a simple question:

We have WF 7.1.3 using the Java JDK 1.4.2_12 on a Windows 2000 Server. Am I good to go with DST in 2007? Windows admins will apply the necessary patches to the OS so that is a given.

The IBI statement indicates "Since the WebFOCUS Client and ReportCaster obtain date/time information from the Java Virtual Machine (JVM), be aware that releases earlier than Java JDK 1.4.2_11 and 1.5.0_06 do not account for U.S. daylight savings time changes that begin in 2007."

Well 1.4.2_12 is later than 1.4.2_11 but earlier than 1.5.0_06. So my answer is yes and no? I assume since I am still on the 1.4.x release path and I am past 1.4.2_11 then I am covered.

To top things off, the Sun web site is vague as well. It says you can run this TZupdater Tool to update JDK versions 1.4.0 and higher. However, on the same page it says "The US2007DST data changes for the USA were incorporated into the following releases of the JRE and JDK software: 1.3.1_18, 1.4.2_11, 5.0_u6". If changes were incorporated into these releases, why do I need to run the TZupdater Tool? It says "The TZupdater tool is provided to allow you to update installed Java Developement Kit (JDK) and Java Runtime Environment (JRE) software with more recent timezone data". Again, if changes were already incorporated into the above mentioned releases, why the need to upgrade or run the TZupdater tool.

The page also does not say to what version it will upgrade the JDK.

http://java.sun.com/javase/tzupdater_README.html

We are not currently using ReportCaster or MRE so the point is mute for us at this time but we will use these tools in the future.

Mickey, this is why I pleaded for "In Plain English Please", though if someone could explain it in plain French, I'd be happy too.

I think that neither Microsoft, Sun nor Information Builders want to make a clear statement, lest they become liable for some problem.

After the Windows XP patch was applied here, Outlook meetings get messed up. It appears Microsoft may not do anything about it.

quote:

Originally posted by Francis Mariani:
Mickey, this is why I pleaded for "In Plain English Please", though if someone could explain it in plain French, I'd be happy too.

I think that neither Microsoft, Sun nor Information Builders want to make a clear statement, lest they become liable for some problem.

After the Windows XP patch was applied here, Outlook meetings get messed up. It appears Microsoft may not do anything about it.

We had the same problem at your university with Novell Groupwise calendar events. Once the change is made you can't just go through and globally change the times lest a new event be changed as well. It stinks but I understand why they can't do anything.

As for the Java Updates... I'd just like to know where (specifically) to download the latest patch for Java that will have DST taken care of for the WF 7.1.1 and 7.1.3 environments.

quote:

Originally posted by Carol Dobson:
Kevin,

We are on 5.2.8 server, 5.2.4 Dev Studio desktop. We're going to use the tzupdater tool to modify the time zone data in Java for ReportCaster.

Carol

What is the tzupdater tool?

Kevin,

It seems that Sun created a tool called the TZupdater that is intended to be used to update JAva JDK installs. They created the tool and the name.

Hi All,

I have question on the same topic since it bit confusing which version Java fix need to install for report caster and webfocus client.

Current version of WF 7.1.6 / OS - WIN2003
Currently have J2SE 1.4.2_06 and J2 SDK 1.4.2_06 which are not supported for DST.

I found version J2SE 1.5_09 for DST how about SDK version ? or need to install JDK 1.5_09 should be fine for DST.

Anybody pls. suggest on this.

Thanks in advance !

carol, how are you going to handle the change in win2k? (Mr Gates doesn't support it anymore.) are you just going to set the time by hand?
we have the exact same config as you do.

I have been reading the posts here and do not see anyone giving a short answer. I will try

For WebFOCUS products.
For Servers like Iway and WebFOCUS reporting servers, the time is taken from the System clock. As long a the machine the server is on is set correctly, the time should work.

Any of the products that use Java (clients, RC distribution server, Devstudio, Application servers like tomcat) will work if they have a Java version that is either
1)fixed (a service patch version from SUN)
or
2)has been fixed with the Tzupdater (last choice, but will work)

The issue is that SUN has built into Java date time and timezone code
either get the java code with the replacement or fix it

The Microsoft fixes (available with OS updates) will fix NEW Outlook calendar events.
However you should read their disclaimers and explanations.

If I fix my Outlook and send you a calendar appointment during those two weeks, and you have not fixed your outlook... the calendar will be off. Since you cannot know for sure if every appointment made by someone else is coming from a fixed system. Microsoft is saying beware.

The OS will work, but appointments in outlook should be considered suspious.

Susannah,

We used the tzupdater tool to update the ReportCaster servers without problems (was updated last weekend) We have not updated Java on each workstation.

I believe we are either patching or updating a registry on the win2k servers, I will check for you.

I also saw on our build sheets that there's an Outlook DST tool to update Outlook calender items. I guess that gets rolled out to all desktops while we are sleeping!

Carol

Francis, In plain English, cross your fingers, pray and call in sick on March 12th.

quote:

cross your fingers, pray and call in sick on March 12th

Best answer yet!

A short while ago, tech support here applied the DST patch to the AIX server, forgetting to stop DB2 first. The DST patch appeared to work, but DB2 got Scr~w~d up - updating tables stopped working. They had to get a patch from IBM to fix that problem.

From what I've read, the Outlook situation appears to be a bit of a mess, but I wasn't expecting better from a Micro$oft product.

We applied the tzupdater patch on the ReportCaster Server and all was well for a couple of weeks. We did not update the Java on the desktops (yet).

When a RC job is updated the next run time gets screwed up in the display, yet the job runs at the right time.

I have a job that kicks off every morning at 7:00 am. ReportCaster shows the Next Run Time as 2:00 am. - 5 hours earlier, yet it really runs at 7:00

Next I used tzupdater to update the Java on my desktop and it still hasn't helped.

Has anyone seen this behavior? The ReportCaster log also shows the incorrect time.
Maybe the tzupdater tool only works for GMT!

We're using an older version of Java 1.4.2_05 along with our older version of WebFOCUS 5.2.8

It's getting scary!

i think i'll just change my schedule times
and then change 'em back.
sounds too scary.
i just read your post up there... you actually get to sleep??

We found that the tzupdater patch has a backward compatability feature. They are going to apply the update again this weekend and hopefully that will correct our time zone problem in ReportCaster. I'll let you know what happens!

Y'all are right about this entire drill being "scary" Carol & Susannah !!

I have decided to leave our schedules alone. They will be off by an hour, but in our case, that is not a show stopper.

Sandeep Mamidenna