addpfm, allocate too large; was Re: Is a 9406-525 64-bit or 32-bit?

For those who do not want to read about nitty gritty stuff... skip on to some other messages.

The &1 in MCH2804 is not really a defect. That a replacement value for &1 can not be presented, is actually more of a design limitation.

That error condition is left in the joblog, as supporting information for the CPF3246; for problem debug. It is logged less for any case where &1 might have a value, than for its /from program/ so someone debugging the condition can see what processing encountered the condition; the type of object can be inferred. The &1 message data is a *SYP [System Pointer] type, so if the object is since-deleted, &1 appears. Because the *QDDS [dataspace] object for the *MEM [member] object could not be extended to the requested size, it is [either not created or] deleted. It is of no consequence, because in the given case [presuming MBR(*FILE) is the default] it would have said "object BIGFILE BIGFILE." which typically confuses everyone more than &1 does :-) since most people do not know the underlying\internal object naming.

Additionally if the dev [or anyone debugging the problem] was *really* curious, the *SYP message data type can be modified to the data type of *HEX for 16-bytes to show the address and type of the object; only if the [base] object had actually been created and the pointer passed in the message data.

Regards, Chuck