jgersic93
Active Member
Ok, here is one weird issue which neither myself (nor JDE so far) has been
able to figure out. I have a sandbox environment which consists of the same
equipment as my live system, on an insolated network. In this sandbox I
perform tests of various items before placing them into the live CRP system.
This has worked perfectly fine up until the last restore of the system. The
reason we restored the system was to get a pretty close copy what was in the
live system, in the sandbox system.
Since the last restore all UBEs now fail to end processing. If you watch
the task manager, runube uses cpu cycles for a bit, and then just goes to 0
percent. I have tried this with various, simple ubes and all exhibit the
same behavior, I also ran a ube from the enterprise server with the runbatch
command, same result.
The really weird thing is that if you look at the logs for a UBE, they all
basically do the same thing. It looks like when the ube is actually finished
processing, instead of the system updating the job master that it has
completed, it gets 'bumped' into a subsystem job:
ay 29 12:48:54 ** 1308/1624 LOCK: Total READ locks after operation: 1
May 29 12:48:54 ** 1308/1624 Unlocking TAM file
\jdedwardsoneworld\ddp\b7333\PD7333\spec\rdatext.ddb
May 29 12:48:54 ** 1308/1624 UNLOCK: Total READ locks after operation: 0
--UBE--[0]-- SS:Starting a subsystem job.
May 29 12:48:54 ** 1308/1624 Entering JDB_OpenTable( Table = F986113)
May 29 12:48:54 ** 1308/1624 Locking
\jdedwardsoneworld\ddp\b7333\PD7333\spec\gbrlink.ddb in READ mode.
May 29 12:48:54 ** 1308/1624 LOCK: Total READ locks after operation: 1
If you continue to look at the log:
SELECT * FROM SVM7333P.F986113 (UPDLOCK) WHERE ( SSPID = 'R0082P' AND
SSVERS = 'XJDE0001' AND SSENHV = 'PD7333' AND SSOPCR = 'W' AND ( SSJOBPTY =
'0' AND SSJOBNBR = 116555.000000 OR SSJOBPTY = '1' ) ) ORDER BY SSSBMDATE
ASC,SSSBMTIME ASC FOR UPDATE OF SSJOBNBR, SSOPCR, SSEXEHOST, SSACTDATE,
SSACTTIME, SSPROCESSID
--UBE--[0]-- SS:JDB_FetchKeyedForUpdate For SS Wait Failed.
It looks like the system is looking at the subsystem job master and not
finding the report..which it shouldn't because it is a normal ube not coded
as a subsystem job. The UBE will then continue in the above loop until it is
interrupted.
Looking more at the logs, all of the services come up without a problem, and
porttest is successful. A client can log in, and do all of their work
without any issues, the only problem is the processing of the UBEs..
Thinking the specs may have been corrupted, I have tried restoring the
specs and system directory from different days, and still get the same
issue. We have also run extensive hardware tests on the server and have not
detected any problems..
This has been an open call with tier II at JDE now for over a week, and we
are all pretty much stumped. Has anyone ever seen anything similar to this
before? Or ideas of what else to look at?
----------------------------------------------------------
OneWorld Xe (B733.3)
Update 2, SP 16
Oneoffs: SP16_011, _018, _019
Running on: WIN2K/SP2, SQL2k/SP2
Metaframe 1.8a
----------------------------------------------------------
able to figure out. I have a sandbox environment which consists of the same
equipment as my live system, on an insolated network. In this sandbox I
perform tests of various items before placing them into the live CRP system.
This has worked perfectly fine up until the last restore of the system. The
reason we restored the system was to get a pretty close copy what was in the
live system, in the sandbox system.
Since the last restore all UBEs now fail to end processing. If you watch
the task manager, runube uses cpu cycles for a bit, and then just goes to 0
percent. I have tried this with various, simple ubes and all exhibit the
same behavior, I also ran a ube from the enterprise server with the runbatch
command, same result.
The really weird thing is that if you look at the logs for a UBE, they all
basically do the same thing. It looks like when the ube is actually finished
processing, instead of the system updating the job master that it has
completed, it gets 'bumped' into a subsystem job:
ay 29 12:48:54 ** 1308/1624 LOCK: Total READ locks after operation: 1
May 29 12:48:54 ** 1308/1624 Unlocking TAM file
\jdedwardsoneworld\ddp\b7333\PD7333\spec\rdatext.ddb
May 29 12:48:54 ** 1308/1624 UNLOCK: Total READ locks after operation: 0
--UBE--[0]-- SS:Starting a subsystem job.
May 29 12:48:54 ** 1308/1624 Entering JDB_OpenTable( Table = F986113)
May 29 12:48:54 ** 1308/1624 Locking
\jdedwardsoneworld\ddp\b7333\PD7333\spec\gbrlink.ddb in READ mode.
May 29 12:48:54 ** 1308/1624 LOCK: Total READ locks after operation: 1
If you continue to look at the log:
SELECT * FROM SVM7333P.F986113 (UPDLOCK) WHERE ( SSPID = 'R0082P' AND
SSVERS = 'XJDE0001' AND SSENHV = 'PD7333' AND SSOPCR = 'W' AND ( SSJOBPTY =
'0' AND SSJOBNBR = 116555.000000 OR SSJOBPTY = '1' ) ) ORDER BY SSSBMDATE
ASC,SSSBMTIME ASC FOR UPDATE OF SSJOBNBR, SSOPCR, SSEXEHOST, SSACTDATE,
SSACTTIME, SSPROCESSID
--UBE--[0]-- SS:JDB_FetchKeyedForUpdate For SS Wait Failed.
It looks like the system is looking at the subsystem job master and not
finding the report..which it shouldn't because it is a normal ube not coded
as a subsystem job. The UBE will then continue in the above loop until it is
interrupted.
Looking more at the logs, all of the services come up without a problem, and
porttest is successful. A client can log in, and do all of their work
without any issues, the only problem is the processing of the UBEs..
Thinking the specs may have been corrupted, I have tried restoring the
specs and system directory from different days, and still get the same
issue. We have also run extensive hardware tests on the server and have not
detected any problems..
This has been an open call with tier II at JDE now for over a week, and we
are all pretty much stumped. Has anyone ever seen anything similar to this
before? Or ideas of what else to look at?
----------------------------------------------------------
OneWorld Xe (B733.3)
Update 2, SP 16
Oneoffs: SP16_011, _018, _019
Running on: WIN2K/SP2, SQL2k/SP2
Metaframe 1.8a
----------------------------------------------------------