RUNUBE: Pointer Location Reference Error

[DBohner-(db)]

Howdy,

We see this error cropping up, more and more... Maybe someone on the list had already resolved it - JDE returned a 'huh??' when we asked them.

We go to the AS/400's Green Screen, enter the RUNUBE command (and fill in the parameters)... then, boom...

Message ID . . . . . . : MCH3601 Severity . . . . . . . : 40
Message type . . . . . : Escape
Date sent . . . . . . : 08/07/03 Time sent . . . . . . : 08:49:14

Message . . . . : Pointer not set for location referenced.
Cause . . . . . : A pointer was used, either directly or as a basing
pointer, that has not been set to an address.

This usually occurs with Custom UBEs - but is known to happen with JDE Native UBEs, too.

Thoughts/suggestions?

Daniel

 

[DBohner-(db)]

One other snip of the error message....
<snip>
Message . . . . : Application error. MCH3601 unmonitored by JDEKRNL at
statement *N, instruction X'0000'.
Cause . . . . . : The application ended abnormally because an exception
occurred and was not handled. The name of the program to which the
unhandled exception is sent is JDEKRNL JDECM_RB RBTREE_PostOrderDelete. The
program was stopped at the high-level language statement number(s) *N at the
time the message was sent. If more than one statement number is shown, the

</snip>

hmmmm what is that JDEKRNL JDECM_RB RBTREE_PostOrderDelet thing?

db

 

[MaxBrown]

Hi Daniel,
We have experienced this problem over the years and while I can't come
up with an answer I can list the scenarios. Because we interface to a
warehousing system that resides on a RS/6000 we run many UBEs throughout
the day (usually the R47nnnn types - EDI, plus invoicing R42565 ) from
CL programs. Our end-of-day CL programs also fire off many UBEs.
The problem that you experienced can occur when the version has become
corrupt or the CL/command line cannot get a handle on the version or the
CL/command line cannot get a handle on the UBE specs. At one stage the
UBE R47500 refused to work from the CL program, although it had been
running for years - with no code changes or new versions, but then one
day it came good and has not failed since. In some cases we have found
that a UBE will never run from a CL/command line and since we needed
them to run automatically the easiest thing to do was to a re-write.
UBEs that fail when run from the CL/command line will run faultlessly
when submitted within One World as, according to JDE, a package of
information is submitted/attached with the UBE and this appears to keep
the UBE under control.
The bottom line is, as you have found that JDE do not have an answer,
nor do they appear to take the problem on board.

Regards
Max Brown



AS/400,V4R5, B7321,SP 12.5,Coexistence,Going to Xe(before Y3K), NT4,Citrix,

 

[DBohner-(db)]

Max,

We have experienced the same issue as you. We have ube|versions that have run, untouched, for over a year - then, suddenly stop working (from RUNUBE). To resolve the issue, we have created new versions - Not Copied Existing Ones.

I do have an open ticket with JDE, on the current issue - and they appear to be processing through it. I'll update the thread when we have more info.

Thanks,

Daniel

 

[Bill Dotson]

Daniel,

We had this problem with R3483 DPR Regen. Turns out that there's a macro in one of the .h files that sets up the cache for the demand and supply branches, and it wasn't set high enough for all of our branches (which begs the question "Why in the world is this a MACRO?"). We upped the number of branches in the .h file and the problem went away (at least until we add a few more branches).

If you're having problems with corrupt specs, then I suggest you simply submit the specs only to the enterprise server. You can do this through BV by clicking "Advanced" and then checking the "Submit specs only" check box. We have seen this problem once in a while and resubmitting the specs seems to always clear it up. I also suggest that for UBEs run via RUNUBE that you create a separate version for that is used only for RUNUBE (to prevent users from accidentally corrupting your specs, PO settings, data selection, etc.). And Max is 100% correct -- create new versions (by copying from ZJDE or XJDE versions) but DO NOT copy your own versions.