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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
