UBE Processes Forever

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
----------------------------------------------------------

John :

If you take a look at \oneworld\b7333\pd7333\spec you'll see a lot of
folders whose names match OneWorld users.
Shutdown JDE services, delete those temporary folders, start services again
and try to run your UBEs.
I've had similar problems with these temporary folders on B7332 and Xe.

Sebastian

----------------------------------------------------------------------------
Strictly Personal and Confidential.
This email may contain confidential and proprietary material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.Thanks.
.
Este mensaje es confidencial.
Puede contener informacion amparada por el secreto profesional. Si usted ha
recibido este e-mail por error, por favor comuniquenoslo inmediatamente via
e-mail y tenga la amabilidad de eliminarlo de su sistema; no debera copiar
el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.
----------------------------------------------------------------------------

I had something similar in my DV full build. I looked like the UBE was hung, lost in space. Ended up re-indexing my F98741. This was a suggestion from JDE. The whole thing took about 10 min or so to complete. Now my client build just errors out on the GBRSpec, which is a separate issue (I hope).

Unfortunately I noticed those folders earlier and deleted them. I also
did the uninstall/reinstall of the JDE services (using a domain admin
level id). I also tried the reindex of the F98741 table that was
mentioned. So far, I still get the same issue...
Any other ideas? I will let the group know once it is resolved as to
what the issue was caused by.

John

----------------------------------------------------------
OneWorld Xe (B733.3)
Update 2, SP 16
Oneoffs: SP16_011, _018, _019
Running on: WIN2K/SP2, SQL2k/SP2
Metaframe 1.8a
----------------------------------------------------------






Xe, Update2, SP16
SQL2k, Win2k
Metaframe 1.8a

Re: RE: UBE Processes Forever

Hi Sebastian,
In relation with your answer, Why I have these directories in PY but I haven't in PD?We have problems with a UBe that call another UBE to send mails, and in PY runs successfully but in PD the UBE hang and finally we have to kill it. Is it possible due to these directories?.Is at the moment the only thing that is different from one envir. to the other.
Please any idea?.
Thank you in advance.
Regards,

When you copied from system to system did you make sure that the server names in the sandbox were correct?

This looks similar to an issue where the servername is given instead of clustername during an install.

Do the jobs sit in W status or P status?

This was a problem in some SP16 and 16.1 service pack - it was a real mess for us. Had something to do with an incompatibility in the messaging that made UBEs either crash or run in subsystem mode when they weren't subsystems.
They fixed it in these places:
SP17 SAR is 5383063
SP17.1 SAR is 5408460
SP18 SAR is 5383442

It __might__ work if the clients and servers are on the exact same oneoffs. I noticed you listed several, so this might be worsening your problem. But I upgraded.

Since I went past the 16 stuff, things have been much better. SP16 oneoffs and 16.1 oneoff almost killed me.

I guess the call center hasn't mentioned it to their development guys, or you'd probably already know this.

Re: RE: UBE Processes Forever

Hi,
My SP is 17.1 I1. What is the purpose of these user directories?, in several user directories I have rdaspec.pak_1662, rdatext.pak_1664, etc..and when the Production users launch a UBE, the date of these directories, that are in PY7333/spec directory, is updated, why in PY if the UBE is running in PD?.
Anything that I have to check?.
Thank you.
The UBE is in P status, during long time, and finally we have to kill it. Maybe, the JDE.INI parameters, some parameter that I have to increase?.
Regards.