(Custom) UBE suddently runs forever

Frosty the Coder

Legendary Poster
I've a _monstrous_ UBE that trudges through the 901,
and selects and totals 902 into a workfile to then report
the workfile.

It _had_been_ running, for all business units, to
completion in 30 +/- MINUTES. This was processing
locally.

Early this week SOMETHING happened that is causing it
to run for 12+ hours before completing.

As it does complete, it's not hitting an infinite loop.

In an effort to find the "black hole of code", I've:

1: !'d out any/all code that I'd added this week.
2: Deleted and recreated the version.
3: Questioned the users as to whether A LOT more
data had been added. (no data has been added)
4: Questioned the CNC guys as to whether any
network changes were made. (no changes were
made).
5: Rebooted the client on which it is running locally.

I'm running out of straws to grasp at, and am looking
to those on the list to provide me w/other suggestions
as to what might have changed that I'm seeing this
change in processing.

As an aside question, at which point in development
does a VERSION stop getting the changes made w/in
a TEMPLATE? Throughout this project my template
mods have automatically shown in my version.
The UBE has NOT been promoted to PD.

Any/all help is greatly appreciated.

TIA

Gene
 
I can add a straw to grasp at.

Could it be related to indecies on the database?

AW
 
To the best of my (limited) knowledge,
no indices have been added/changed/or deleted.

Do you think I need to rebuild indices?
 
Have you tried to debug it to find out which lines of code are taking up all the time?
 
I've run it through debug looking for the cause.

Running a single cost center completes as it
had before "whatever" happened.

For debugging purposes, I'm going to write
addl records to my work file to chart the
ube's processing. While this will add
IO, it might give me a clue as to where
to look.
 
I assume you checked the logs for errors. But, did you check the SQL statements for delays. If this is index related I would expect a multi second delay between the issue of an SQL statement and the next line in the log.

This could also point to other types of delays but usually they are DB related.
 
You might also check to see if logging was turned on. Depending on the report logging can greatly effect performance.
 
I don't have any straws to help you grasp at, sorry. But in reply to your aside question:

I've noticed that as long as there is no overriding on the er specs in the version the changes to the parent UBE filter down to the version. However, if you do have changes to the ER specs on the version the changes to the parent UBE do not filter to the version.
 
Gene,

I'd take a look at your indices.
This is the first place I look
when things start slooowwwing
down.

Just a thought,

Jim.
 
A couple of people have suggested the indices as the root of the issue.

Is it that I should regenerate them or which index I'm using at which point
in the process?

If I should regen them, is there a method of seeing if they are corrupt
before the regen them, or is it a case of regen & see what happens?

TIA

Gene Piekarski, Jr.

Corning Data Services
[email protected]

(office) (716) 853-6215 <------------------------------
(cell) (716) 472-3589
(home) (716) 662-7171



Gene Piekarski, Jr

AS/400, B733, SP11.2, NT client
AS/400, B733, SP14, W2000 client
XE, SP15.1
 
Also, I would try regenerating the indices AND deleting all SQL packages according to JDE instructions available on the Knowledge Garden.
 
Back
Top