Re: MCH0601 - Space offset X'00FFF000' or X'0000000000000000' is outside current limit for object PTMINB_BACMISSLICE06931056.

On 16-Jun-2016 08:08 -0500, Steinmetz, Paul wrote:

On 15-Jun-2016 15:14 -0500, Steinmetz, Paul wrote:

On 15-Jun-2016 14:37 -0500, Steinmetz, Paul wrote:

After applying latest V7R1 cum/all groups, etc, I'm receiving
INTERMITTANT MCH0601 within a 3rd party app job.
Sent the error with joblog to the 3rd party vendor.
Response from vendor is that this is an IBM issue, not their apps
issue.

I did search and found a hit.
SI58998, recently applied, did fix an issue related to MCH0601.

I'm wondering if there could be additional issues with MCH0601?

Any thoughts from the group?

DESCRIPTION OF PROBLEM FIXED FOR APAR SE63436 :
-----------------------------------------------
msgMCH0601 F/QDBRNMME T/QDBRNMME. First touch of a database
directory object via a rename member operation fails.

CORRECTION FOR APAR SE63436 :
-----------------------------
Rename member is modified to correctly modify the database
directory object.

MCH0601 Escape 40 06/13/16 10:50:08.780083
PTMINTIB IC08XXCHGP *STMT
PTMINTIB IC08XXCHGP *STMT
From module . . . . . . . . : PTMINTIB
From procedure . . . . . . : SOCKRD
Statement . . . . . . . . . : 2430
To module . . . . . . . . . : PTMINTIB
To procedure . . . . . . . : SOCKRD
Statement . . . . . . . . . : 2430
Message . . . . : Space offset X'00FFF000' or X'0000000000000000' is
outside current limit for object PTMINB_BACMISSLICE06931056.
Cause . . . . . : A program tried to set a space pointer, tried to
use storage outside a space, or tried to use an unallocated page in
teraspace. The space class is X'04'. The space class designates the
type of space:
...
04-implicit process space for heap identifier
X'00000000' in activation group mark X'0000000000000000'. ...
Offset X'00FFF000' only applies to storage outside
teraspace.
X'8000000000000000F8A8579526001000' is a pointer to the teraspace
page or the start of the implicit process space for the allocation.

We ran the same process, no errors.
I'm wondering if this is related to the "first touch" <<SNIP>>

I would say approaching 100% certainty, that error is _not_ the same issue from the APAR noted in the OP. That the /intermittent/ problem did not transpire again is insufficient evidence the problem does not lie with the application, and insufficient evidence that any database object conversions succeeded such that the original problem did not recur.

The error shown is the symptom msgMCH0601 T/PTMINTIB [in non-IBM library IC08XXCHGP] TM/PTMINTIB TP/SOCKRD scX04 [or rcx04] which indicates a _heap_ storage addressing issue. Everything about the error suggests an error with the application program; though possibly, arising from a heap-storage management issue as part of the [run-time features of the] HLL language or the LIC heap feature... but the application owner normally would be required to debug\diagnose that the issue is not simply their improper addressing of the heap, and report any suspected defect with the heap to their service provider [which is likely to be IBM].

The *DBDIR object is a simple _space object_ with object type x/19 and subtype x/50. Even if the DB Directory conversion were being done within heap storage [which with almost 100% certainty, again, is not the case], the failure almost surely would be diagnosed within an IBM program, and almost surely in a program named QDB* in the QSYS library. The system integrity, via the storage domain of the object being in the system-domain and the user application being in the user domain, would prevent a user application from addressing the space; and the user code likely would not even be navigating the down-level object with the up-level\converted offsets, which is almost 100% certain to have been the origin for the APAR SE63436 -- where the new Database Rename Member program [for processing RNMM requests] failed to invoke conversion of the directory object before attempting to refer to the stored offsets with a prior-release layout\definition.