Scheduler down after DST on MS Cluster

mtrottier

Well Known Member
E812 SP 8.98.1.1 running 2 Windows Server 2003 R2 clustered in failover node. We put 8.98.1.1 on last summer so this is the first time the system had to go back on DST since the new SP.

Our Scheduler stop processing jobs after 2:00am on DST change day and now the P91300 cannot communicate with the Scheduler kernel.

When we try to use P93100 to stop or start the scheduler we get a window with the message "Failed to notify the Scheduler Server of the control record change" and an error in the JDE.LOG on the client "SCHEDULER - JDENET_ReceiveMsg failed with JDENET Error = 11"

We tryied restarting JDE services on the cluster and fully rebooting both servers in the cluster. The Scheduler kernal comes up after restart without anything unusual in the logs.

We've checked the JDE.INI, OCMs but the fact that scheduler was fine until DST we feel that the configuration is good.

We can also ping the virtual EONE Enterprise server and can still submit jobs to it using BV.

Is anyone else running 8.98 on a cluster having scheduler issues?
 
[ QUOTE ]
E812 SP 8.98.1.1 running 2 Windows Server 2003 R2 clustered in failover node. We put 8.98.1.1 on last summer so this is the first time the system had to go back on DST since the new SP.

Our Scheduler stop processing jobs after 2:00am on DST change day and now the P91300 cannot communicate with the Scheduler kernel.

When we try to use P93100 to stop or start the scheduler we get a window with the message "Failed to notify the Scheduler Server of the control record change" and an error in the JDE.LOG on the client "SCHEDULER - JDENET_ReceiveMsg failed with JDENET Error = 11"

We tryied restarting JDE services on the cluster and fully rebooting both servers in the cluster. The Scheduler kernal comes up after restart without anything unusual in the logs.

We've checked the JDE.INI, OCMs but the fact that scheduler was fine until DST we feel that the configuration is good.

We can also ping the virtual EONE Enterprise server and can still submit jobs to it using BV.

Is anyone else running 8.98 on a cluster having scheduler issues?

[/ QUOTE ]



What is the cluster name according to Cluster Administrator (the name all the way at the top/root)?

and

What is the E1 Network Name resource?

and

What is the E1 logical datasource name for the cluster?
 
Don't be fooled by the names of the servers these are the JDE Enterprise Servers:
Windows Cluster name ERPJAS
Windows Server 1: ERPJAS1
Windows Server 2. ERPJAS2

E1 Network name: EONESVR
E1 Logical Datasource: EONESVR

The Database server is another cluster called ERPDB with servers ERPDB1 and ERPDB2
See attached screen shot of Cluster admin.

Again everything worked just fine until the DST change and no one was on the system making any changes when things went downhill.
 

Attachments

  • 156746-Cluster.JPG
    156746-Cluster.JPG
    88.1 KB · Views: 110
[ QUOTE ]
Don't be fooled by the names of the servers these are the JDE Enterprise Servers:
Windows Cluster name ERPJAS
Windows Server 1: ERPJAS1
Windows Server 2. ERPJAS2

E1 Network name: EONESVR
E1 Logical Datasource: EONESVR

The Database server is another cluster called ERPDB with servers ERPDB1 and ERPDB2
See attached screen shot of Cluster admin.

Again everything worked just fine until the DST change and no one was on the system making any changes when things went downhill.

[/ QUOTE ]

That all looks good, there are issues if one does the cluster name the same as the network name the way we used to do it.

Anyway, take a look at ESU JK17059 which corrects a bunch of DST-related issues with the scheduler.

https://jde.oracle.com/softwaredownloads/ESU/html/JK17059_01_99.html
 
I solved my own problem. What I found was that one of my scheduled jobs was running at 2:00am when JDE tried to do the DST adjustment. This apparently caused a problem and the Scheduler Kernel “Froze”. This left the status of the running job at “Launched” in the F91320. It also appears that even after a restart of the JDE services this “Launched” status record was causing the scheduler kernel to not come up cleanly.

To resolve the problem all you need to do is clear this “Launched” status using the R91300B

Thanks again for the help.
 
Back
Top