Scheduler Not Adjusting for Daylight Saving During 1st week

JDEList,

Scheduler is not adjusting for daylight saving during 1st week after daylight saving started. Jobs are being scheduled correctly for the second week and after.

Has anyone experienced this problem?

I opened a case with Oracle and they have got back with a SAR (8436001), for exactly the same problem, that has been closed because they could not duplicate the problem.

Details of the SAR are as follows:

Title 8436001 Scheduler out of synch by 1 ho RPT1637600000 SystemH95

SAR Number 8436001
ICE Report ID 1637600000
Parent Number (none)
Program ID SD-SMT-OE -
System Code H95 - Tech Resources/Applications
Release Fixed (none)
Product EnterpriseOne Tools and Technology
Priority 2 Priority
Type 1 - Correction
Status 08 - Returned-Could not Duplicate
Code Change (none)
Date Entered 2007-04-03
Date Complete 2007-10-12

Description
A ORIGINAL REQUEST

Description of Problem
Several Customers have reported that after start of daylight
saving on March 25 2007, every scheduled job start 1
hour
after scheduled time.
PO Value version of P91300 used
View Local Time = 2
Local TimeZone = 12
Adj time = 1
Daylight Savings Rule = EUROPE1
DST Rule definition for rule EUROPE1
starts on Last Sunday of March at 01:00 and
ends on Last Sunday of October at 01:00
Customer release is EnterpriseOne SP1 TR 8.95.P1.
This issue occurred last year to a nubmer of customers.
The
incident was reported to Engineering who worked at length
to recratethis issue. Apparently, this issue is still
not
fixed.
Please ensure that this is resolved before the next occurenc
e of Europe DST change.
We have established that this problem only occurs when
changing from 'winter time' to 'summer time'.
The Change from 'summer time' to 'winter time' next October
shouldn't show any problems.

Hi Peter,

I've just been looking at this. There is a special code value for the Instance code to represent the last occurence of the day in the month. This is the value that is used to return the last Sunday in October as the DST end date. Program P00085 Daylight Savings Revisions thinks that the code value is '05' (held in the UDC H91/WK), but function B9800009 (UTC Time Functions) which calculates the dates thinks that the value should be '99' (hardcoded in B91300A.h). The value that P00085 stores on the F00085 is therefore '05'. When B9800009 calculates the date, instead of returning the last Sunday in October it returns the fifth Sunday in October! It does this by starting with the 7-Oct (first Sunday in Oct) and then advancing 5 weeks and ends up with the 4-Nov.

I have not been able to test this yet but I believe the following should fix the error.

1. Change UDC H91/WK entry for 'Last' from '05' to '99' in all environments.

2. Update the Instances on the Daylight Savings Time records so that the values on the F00085 change from '05' to '99'. This can be done via P00085 by changing the values and then changing them back again.

3. Refresh the schedule to update the incorrect records.

D

One more thing.... I am in the UK but the same should apply in your situation. I think that SAR is wrong... this happens for both clock changes. Good luck!

Dominic,

Tried your solution BUT it would not allow me to change the settings in the P00085 application after changing the UDC value for last to 99.

It gave me a different idea as to the solution though in that if you change the setting for the Daylight Saving Ends on from Last to Fourth Sunday then that should cure it as the Fourth Sunday has already gone.

Refresh your schedule.

You can always change it back to last in a couple of weeks time as the 4th Nov will have gone.

Dom,

Champion!!!

I successfully tried your recommendations in our test system and then everything worked as it should.

Finally got the UDC (99) to take and tried your solution to no avail. Also tried the other possible solution I mentioned by changing the last value to fourth (in Daytie savings application) at another customer and that did not work either! Strange. Will have to do some more research as to why it works for Peter and not for us.

I tried opening up UDC revisions directly from the fast path and changing to the new 99 status but then it wouldn't validate when I returned to P00085. Some problem with caching I expect.

There will be no validation problems in P00085 with the new UDC value (99) if the change is made by opening UDC revisions using search and select from P00085. Alternatively change the UDC and log out and back in.

This has corrected the schedule for my customer too. They are on B9 with tools release 8.94.

Dom

Terry and Dom,

I have heard back from Oracle. SAR # 7855714 removes the hardcoding and this SAR is included in JJ14765 (Stop Press: To apply JJ14765, need to apply JJ14789 as well) . We, of course have not applied JJ14765.

We are using E8.11sp1 8.96C1. On an admin fat client, I opened the Daylight Savings app (P00085) added a new rule. In the field, I clicked the torch. In the UDC search & select I clicked the Revisions Form Exit. I then changed the description for code '05' from 'Last' to 'Fifth', then added a new code '99' with the description 'Last'. Saved and exited back to the UDC search & select where I clicked Find and selected the new '99'. I used '99' for both the start and end of daylight saving. Everything was accepted and saved without any problem.

Hi Peter, Thanks heaps for pointing Salmat (8.11 SP1 8.96I1) in the right direction. We have had the same issue with Daylight Saving this week with all of our jobs running an hour late and now have a workaround until we apply the ESUs.

By Copy, Terry
Good to see a familair name from the UK and still do wonderful work.

Regards, Maria Hugo (previously Balsamo)

JDEList

Oracle have created Solution ID 201054526 for this problem. Details as follows:

Summary:
E1: SCHED: Scheduler not adjusting for Daylight Saving during first week
Details: SOLUTION ID: 201054526 E1TECHPLAT E1: SCHED: Scheduler not adjusting for daylight saving during first week of daylight savings and jobs are running 1 hour late.

ISSUE:
For daylight saving start last Sunday in October and finish last Sunday in April, the scheduler is scheduling jobs that are scheduled to run during the first week after daylight saving starts without adjusting for daylight saving and therefore the jobs run an hour late. Jobs sheduled to run after the first week after daylight saving starts are scheduled correctly. This can happen to any daylight saving rule that start on last week of the month.Currently only EMEA and Australia have the daylight saving starting on the last week of the month.

SOLUTION:
The cause of the issue is a hardcoding of 99 for the LAST_DOW_INST in b91300a.h business function header file.
At the base install of 8.11 SP1 without ESU installed, 99 is hardcoded into B91300A.H. SAR # 7855714 removes the hardcoding and this SAR is included in JJ14765. ESU JJ14789 needs to be applied when applying JJ14765.

Apply the following ESU to the following release if b91300a.h contains the hardcode of 99 to LAST_DOW_INST 99

8.10 PG5813
8.11 PH11301
8.11 SP1 JJ14765 and JJ14789

WORKAROUND:

Workaround 1 Manually adjusted scheduled jobs between the last Sunday in October and the 1st Sunday in November, inclusive, to run an hour earlier.

Workaround 2 Please do this only if you have not applied the ESU for your respective releases. Once you have applied the ESU, the UDC values should be changed back to '05' and code '99' deleted away.

Change UDC H91/WK code '05' description from 'Last' to 'Fifth', add code '99' with description of 'Last' and apply to Daylight Saving Rules. Refresh the schedule to update the incorrect records. Need to refresh the schedule by clicking the Form Exit - Reset Schedule for each job in the scheduler so that the records in the F91320 will be updated with the adjusted UTC date/time. You use P91300, but it doesn't matter if you are viewing local time or UTC time.


KEYWORDS:
Daylight saving Rule
B91300A

System Code: H91
Program ID: B91300A
Application Release: 8.10, 8.11, 8.11SP1
Service Pack/Tools Release: ALL
Platform: ALL

Maria,

I would like to thank Dom Bowker again - he came up with the UDC work around/fix. The Oracle consultant that was helping me found the ESUs.