Good news, they installed tzupdater with the backward campatable feature this weekend and our jobs now know what time zone we're in.

Now let's see what happens on next Monday!

Carol

CArol, We updated our 2k server with 4 little files from Microsoft..Our IT guys slogged thru their KB document and figured it out. The KB doc makes it seem really hard so you'll pay MS $4k to come fix it, but it was easy.. 4 little files, 2 run, then reboot and run 2 more.
If anyone wants more info, pm me.

Caster, now that's still another problem.

Hi Susannah,

Thanks for the win2k information!

About Caster, you can run the tzupdater to update the DST rules. We've not had problems all week and we hope all is well on Monday. We use Caster heavily here.

GOOD LUCK to everyone on Sunday and Monday!

we just ran tzupdater for our older production box, ran fine! didn't touch the java.
ran it in -t option first, then in -u option.
we parked the tzupdater.exe right in the directory with the java.exe.


and on the 716 box, updated java to jdk1.4.2_13 and changed the system path using the 'environmental variables' button in system properties.
all seems to be working just fine.

update: tzupdater appears to have had no impact at all. all our schedules are off 1 hour this morning.

This message has been edited. Last edited by: susannah,

It appears that TZupdater isn't quite the magic bullet.
Existing schedules in Caster will show their times in STANDARD times.
If you have a schedule set to run at 6:30, it will still run at 6:30 standard time, which is 7:30 daylihgt.
If you OPEN that schedule and just change 1 minute of the setting, and resave it, it will magically show its next schedule at 5:31 standard, which is 6:30 daylight.
so it appears
that EVERY schedule has to be opened and touched in order to make this TZupdater solution actually work.
If you have any schedules in your list whose next run is april, you will see caster showing EDT, not EST, so Caster is capable of showing EDT, just doesn't seem to know to do it NOW.
Anyone else having a fun Sunday??

This message has been edited. Last edited by: susannah,

it appears that caster in 7 is showing EDT this morning, all is well,
but caster in 5, post TZupdater is still showing EST..standard time.
so...to make it work....
1) any existing schedule at 6:30 will run at 6:30 EST, not EDT.
2) open that schedule, tweak something, anything, rock the AM to PM and back again, and RESAVE it , and magic. it now shows 5:30 EST,
which is exactly what you want.
The schedule pop up window shows 6:30, but the next run time will be 5:30...perfect!...5:30 EST is 6:30 EST.
so..every schedule has to be touched...
..at least that's what we're finding...
..Whats everyone else finding?

Susannah,

We're fine here! The tzupdater tool did correct our problem. I didn't do the install so I don't know all the details. I'll print out this information and run it by our server guys.

This message has been edited. Last edited by: Carol Dobson,

Susannah,

Here's what I was told....

IBI doesn't support 1.4.2_13

When running the tzupdater you need to run it with -bc option for backward compitble.

Hope this helps! Carol

quote:

March 12, 2007 08:44 AM

Susannah and Carol:

I've the same problem.

- The server in question is in NY, runs WebFOCUS 7.1.3, and was updated with the Windows DST update, Java updated to 1.4.2_12-b03, and Sun's TZupdater.

Schedule 'start times' were set long ago on the basis that they represented the system's clock which would reflect the 'current time of day' at the server's location in whatever time scheme was effective there and then.

Now all our reports are running an hour late.
They run at the same 'sun-time' as the old EST, but that's an hour later in the workday so the reports are late!
- Example:
a) "Start Time" is set at 12:00PM because user wants his report at noontime. (Note to IBI: There is no way to specify any time system or basis of time for "Start Time".)
b) Locating schedule in list of UserID's jobs now shows me (in NY) that it is to execute at 1:00 PM EDT and at 3:00 PM MDT when viewed by my associate in Colorado (both are same astronomical moment as the former 12:00 EST).
c) Report runs late at 1:00 PM EDT and is received in Colorado just after 3:00 PM MDT, which my customer considers to be an hour late because he used to have it 3 hours before quitting for the day; now he gets it two hours before he goes home.

We re-applied the TZupdater with '-bc' as Carol suggested, and I've played with updating 'Start Time' as Susannah suggested. Both caused no change in the resulting execution time.

What to do? We've got over 400 HUNDRED schedules running late. Fortunately most are in the wee hours of the day so an hour late is no problem.

Did some idiot decide that scheduled "Start Time" equates to GMT and not to 'time within the business day' or 'server local time'?

IBI Case #30712035 applies. I've not gotten a satisfactory fix (or reason for this) yet.

Chris Burtt

Chris, from my reading of sun's site, upgrade to 1.4.2-13
and you should be fine
-

Sorry Susannah,
- Upgraded Java. Server is now WF 7.1.3 with Java 1.4.2_13-b06.
- Then edited job's 'Schedule' tab Start Time to '12:02 AM'.
- Exited and restarted IE and RCaster's list of user's jobs still showed 'Next Run Time' as an hour late at '01:02 PM EDT'!
Chris

Susannah,
Checked my workstation running the IE and it's got no WF and Java 1.5.0_10-b03.
Chris

Hi Chris,

We have a really old version of Java 1.4.2_06-b03

When we first ran tzupupdater to update the DST rules, we didn't select the -bc (backward compatible) and our next run times were all screwed up (only when we would change a RC job)

When tzupdater was applied the second try with -bc it fixed all of our jobs. So the tool solved our next run time problem. We have loads of RC jobs and all is fine!!

Sorry to hear your having trouble. Carol

Carol -
When you ran tzupdater the second time with the -bc option did you have to remove anything or did you just say
java -jar tzupdater.jar -bc

Very confusing indeed, we also noticed our report Casters running 1 hour late. We are at release 7.1.1 and have Java 1.4.2_06-b03)

Investigating our options we were told thru IBI support...
"should be able to upgrade to Java 1.4.2_12, which contains the DST changes
and stay at 7.1.1"

Based upon Chris's note, I wonder if the Java 1.4.2_12 will work?


Another option explored, but we don't have time for a production environment upgrade now...:
"It appears that the customer should upgrade to Java 1.5_09, but it looks like
that would mean upgrading to 7.1.6"
==================================================
Current status: I've got a request to get the JAVA JVM upgraded to 1.4.2_12, now wondering if that's the best option?

Also, I know Sun says _13 has the DST, does _12 have DST updated??? (The IBI Supperted level for 7.1.1 WF)

IBI didn't mention the Sun TZupdater... The network people do not like multiple requests! (Who does?) I want to give them good direction...

I don't need anymore surprises this week!

Suggestions anybody?
Thanks, Ed Kandel

We updated the server in question to Java 1.4.0_13 and as he did so, the "server guy" observed that it had 3 versions of Java installed. The one he updated was in a library by itself, the two other, older ones, were inside Oracle libraries.
He pointed out the CMD ">java -version" displays the first Java found along the "path" Environment Variable, which lead to an Oracle library, not the place he put _13!
(You can see/edit your environmental variables by right clicking on My Computer, selecting Properties, the Advanced tab, and clicking the Environment button.)

We have two EVs that are involved, "path" that starts off with two Oracle directories and "JAVA_HOME" that points to the library containing Java _13.
IBI told me that WebFOCUS finds it's Java by searching the "path" EV [not the JAVA_HOME ??!!), and that I should put the path to the Java _13 at the start of the "path" EV.
Before doing so I consulted my Oracle DBA who said I might luck out and find that Oracle9 works OK with Java _13 in our environment. Luckily he was correct!

After changing "path" as suggested, and confirming that *.fex which query Oracle RDBMS still worked, I found no change in my DST dates issue!!
There was still a 1 hour difference between our schedule's StartTime and RCaster's NextRunTime (Scheduled at 12noon is Run at 1pm).

As an emergency 'fix' I advanced the server's clock by 1 hour so that RCaster's reports would come out at the same 'time-of-workday' as they did on March 9th and before. This is not a good fix at all because I suspect that rebooting the server, which we do automatically once daily, will reset the clock back to match a time server somehere. Should this happen, I plan to set the server's time zone to the next one east of the USA east coast (Canada's maritime, or Greenland, or ...) and that should hold us for three weeks until the old DST 'spring ahead' date comes 'round. ... Then, who knows what will happen!

Meanwhle I'm still pressing IBI for either a fix or an explination of what causes this.

Suggestion to all: find out how many versions of Java are on your WF platform and trace through or adjust the pathing as necessary.

Chris Burtt

We are having problems here too. We are using WF 5.23, java 1.4.0_02. I feel your pain. The goods news is our reports are running when they are scheduled to but if you look at the 'next run' time it is not correct. I have a case open with IBI but they are as puzzled as I am. I did install the Java path, tried with just the -u for update and then returned everything back to it's original state and tried applying the patch with -bc -u. Didn't seem to make a difference.

Cheri,

I've sent your question about the install to our server guys and am waiting for a response. We did have the same problem as Chris, where we had multiple installs of Java and it was looking at the wrong version at first.

When you guys say it didn't make a difference, we found we needed to edit the job (as Susannah said, rock the am/pm button) to have the next run time show up correctly on the RC jobs that had incorrect next run times (from the previous bad installation of tzupdater)

I feel very lucky at the moment! Carol

We have Case 30722031 opened. They are needed to have a webex session in order to figure out what is going on. I guess they should be reading this post to realize that it's not just me.

Glad/sorry to hear that others are having the issue. Hope a solution is found soon. Oh wait. Give it two weeks and you won't have to worry about it all summer.

It's happening on 5.2.3 and 7.1.6 for us.

i found i didn't even have to rock the am/pm button...just the act of opening and resaving , changing nada, was sufficient to change the time back an hour in EST.
yep, i'm feeling very lucky, too.

One issue we ran into with our (5.2.3 Windows) schedules being off by 1 hours was due to our Servlet Container (New Atlanta) not picking up the DST change. I finally figured it out after turning on all the traces for Distro and found the servlet trace was logging PST instead of PDT. After trying to uninstall prior versions of the JDK/JRE and reinstalling jdk 1.4.2_06 we installed the jdk 1.4.2_13. After a reboot New Atlanta finally picked up the time change and our schedules seemed to be back on track. But, it turns out that we had to open and close some of the pre-DST schedules to complete the loop. One (there may be others I am not aware of) remaining issues is that for a pre DST job scheduled between 2-3. It says its 1:00 and even when we try to change it to any time between 2-3 is staying in at a 1-2 next runtime. A new schedule can be scheduled in the 2-3 am window with out a problem. We have an Caster implementation on Unix didn't miss a beat as far as we can tell (7.1.3 Distro Server on AIX 5.2 ).

Jon

This message has been edited. Last edited by: jmdoyl1,

Thanks Susanna and Jon for the thought about editing schedules with execution times of 12-2am, and the New Atlanta bit. I'll investigate those solutions, too.
Sadly, we have over 400 schedules in production, between nightly end of invoice processing and the start of next day's business, so the the edit-by-1-hour process is not an easy option for us. The time-zone shift seems to work OK.
Chris Burtt

Chris, been there so I know what you are going through. We ended up with Java 1.4.2_20 and removed other references. Have the admin take a look at the system iadmin profile. You may need to point to a classlib or export certain var's. The contacts I spoke with at IBI on our case were Kelly Wiggins and Soon Lye Lim, although we ended up fixing this porblem in house - they were quie helpful. Good luck.
What release of WF are you working with? I..

Please let me know if Java 1.7 is compatible with webfocus 7611.Our current version of webfocus and reportcaster is 7611 and we are using java 1.6.0 on our webfocus servers and java 1.632(Version 6 update 32) on our local machine.Everything works fine.Now we are asked to upgrdae for java to version 1.7.I am not able to access Webfocus applet and Reportcaster with this new version.Is this a java version issue...Please help