Re: Pointer Error

Chuck

You mention using F6=print after F1=Help - I've never used that and probably will in the future.

What I HAVE used and recommend to our tech staff and customers is F9=Display message details - the latter is good, in my view, for a quick look, F6 looks great for sending the information to us here or to some other tech support agent.

Thanks
Vern

On 1/10/2012 1:37 PM, CRPence wrote:

On 10-Jan-2012 02:03 , PAPWORTH Paul wrote:

I'm unable to understand why in an RPG programme that writes to a
file in a loop, that after the first write we get the following
errors

MCH3601 Undefined pointer error<<SNIP>>

The message MCH3601 is an error suggesting that a pointer is "not set
for location referenced" and that the null [or disabled] pointer was
being "used, either directly or as a basing pointer, that has not been
set to an address." That information is available to anyone who can
DSPMSGD MCH3601 MSGF(QCPFMSG). Not very interesting nor informative.

While knowing that effectively the second write gets the error, what
really matters generally, after knowing that generic pointer exception
was signaled, is what signaled the exception and what was the target of
the exception in any particular scenario. That information is available
from F6=Print after F1=Help on that specific message, or from a spooled
joblog. Knowing that, there is the possibility to infer better where to
investigate further [in a trace and\or debug].

The processing before the write is complex and involves a number of
RPG ILE programmes and RPG service programmes. The Activation groups
look OK (Named) however interspaced in the processing are a couple
of RPG (OPM) programmes. Is it possible that these could be the cause
of our problem. We are at Version 6.

Yes. Any program on the stack with a pointer to storage in a
previous call stack entry [e.g. parameters passed by reference] has the
potential to update the storage in that prior program. Improper updates
to storage via these pointers can corrupt contents of variables in
adjacent automatic storage for example. Corrupted storage could be HLL
run-time variables, including pointers, used to implement something like
the .WRITE procedure. As an integrity measure by the OS, any pointer
which is modified by any means other than a proper /method/ would be
deactivated such that the next reference to the pointer will incur the
LIC exception 2401; i.e. the MCH3601.

Another possible origin for an MCH3601 is more mundane and alluded by
another reply; i.e. involving activity directed to a file that has
already been closed. However I believe a file previously closed as
detected by WRITE, will be manifest as a Data Management error to the
program, even if the MCH3601 remains logged.

Regards, Chuck