×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 1/26/2016 5:51 PM, Jon Paris wrote:
This is a situation that often occurs in debug when the dealing with variables that are pointer based.
It is something to do with a limit on the number of levels of indirection that the debugger can handle. I’m betting that this is the same issue. I see it a lot when working with OA handlers.
Barbara can probably explain it better.
That issue with levels of indirection happens when there's a pointer
subfield in a data structure that's either based or passed by reference,
and there's something else based on the subfield pointer. (As you
mentioned, the OA parameter is full of this type of thing, since there
are so many pointers in the main parameter, which is passed by reference.)
Buck's program just has a single level of indirection. Even if his data
structure did have a pointer subfield, it wouldn't fall into this
scenario, because he's basing his data structure on a local pointer that
he assigns to the address of the parameter.
Here's an small example of the "based on based" problem. basedfld can't
be shown by either the debugger or the dump, even though the RPG program
can get its value with no problem.
dcl-ds ds;
p pointer inz(%addr(fld));
end-ds;
dcl-s fld char(10) inz('abcdefghij');
subproc (ds);
return;
dcl-proc subproc;
dcl-pi *n;
parm likeds(ds); // "based" on the parameter pointer
end-pi;
dcl-s basedfld char(10) based(parm.p); // "based on based"
dcl-s fldvalue char(10);
fldvalue = basedfld;
dump(a);
end-proc;
Local variables for subprocedure : SUBPROC
NAME ATTRIBUTES VALUE
_QRNL_PSTR_PARM POINTER SPP:D7EC8B6606057F80
BASEDFLD CHAR(10) NOT ADDRESSABLE
FLDVALUE CHAR(10) 'abcdefghij'
PARM DS
P POINTER SPP:D7EC8B6606057E40
midrange.com
