DST Issues with Submitted Jobs

Finally have all the new DST patches applied to the servers and all of the clients.

If I change a record in an application, it gets the correct time stamp.

If I submit a job to the server, the submitted time is an hour off, the last activity time is correct.

If I submit a job from the server with runube, the times are correct.

When I view a UBE the log file gets the correct time, however the entry in the log file is an hour off.

The date/time on the file is Mar 15 13:38

2792/2660 Thu Mar 15 12:38:43 2007 JDEKNUBE.C4129
d:\jdedwardsoneworld\ddp\b7334\PrintQueue\R55PMWO_FMC0001_674875_PDF.pdf

This is true in a number of the logs as well - the file date is correct but the last entry in the log that caused the file to be updated is an hour off.

Haven't stopped and started the services but I wouldn't think this would be an issue.

We don't use the scheduler so we didn't change the rules for that until a bit ago to see if that would have an effect which it didn't.

Can't stop and start the services until later when we get everyone out but I'm not convinced that this will take care of the issue.

Anyone else seen this? If you fixed it, how did you do that?

Thanks,

Dave Schlieder

Hi Dave,

Yep... I had a similar problem at a customer running
E810 Tools 8.95I2 on Windows 2003/SQL2000.

All of their Scheduled Jobs got shifted forward by
one hour on March 11 (after DST change).

We applied all of the MS Windows Updates and JDE
instructions on P00085, we restarted services but
something went wrong on PSE1 Scheduler.

All of the jobs formerly scheduled for a given time now
get launched one hour later, and PSE1 Scheduler shows
them on their new time frame. Pretty weird!

By the way : had to manually modify all of them (169!)
to fix that mess.

I have to confess that I'm a bit worried on what may
happen on April 1st, the date DST should have changed
according to the old algorithm. Will it turn clock
back one hour?

I checked that all the PCs and servers were on the
right timezone with DayLight Savings checkbox on.

Last but not least, also had trouble with Veritas Backup
scripts that got shifted 3 hours later (!?) after this
DST change. Why 3 hours and not -1, +1 or +11?
Does 'Atlantic - 2" time zone have any special meaning
for Veritas Corporation? Is it due to the mythical
Atlantis that maybe hidden somewhere in that area?

I can't wait for the Year 2038 bug!

Regards,

Who knows...

Regards from the "Twilight DST Zone"

After stopping and starting my services last night all seems back in order for now.

First Sunday in April may provide more fun!

I've had an ongoing issue with ArcServe backups on one box at least - every time we change time it changes the times the backups are run - shifts them by an hour - which messes up other scheduled jobs that are supposed to run when the backups aren't...

What fun!

Have a good day!

Dave Schlieder

Hello-- We manually run this SQL statement to update the scheduler file properly.

In the Spring:

update sys7334/f91320
set jsschsttime = jsschsttime - 60
where jsschlncstat = '01'


In the fall:

update sys7334/f91320
set jsschsttime = jsschsttime + 60
where jsschlncstat = '01'


Works like a charm.

-Tim

Hi,

Thanks for your script, it's a smart idea!