RPG IV pointers in datastructure (debugging)
claus_ni...@my-deja.com
can anyone tell me why the interactive debugger displays different
values for a pointer field in a datastructure when displaying
(evaluating) the value of the subfield alone than when displaying the
whole structure ?
I've a got a structure that looks something like this:
d resInf ds
d riTrnTree *
d riResc like(rbResc)
d riWhse like(rbWhse)
In the debugger "ev riTrnTree" and "ev resInf" gives the following
output:
> EVAL riTrnTree
RITRNTREE = SPP:E15E8C04DF0018F0
> EVAL resInf
RITRNTREE OF RESINF = SPP:D448175848001EF0
RIRESC OF RESINF = 'A010 '
RIWHSE OF RESINF = '02'
There is NOT a local field with the same name as the DS subfield, but
when a value is assigned to riTrnTree it looks like the contents of the
datastructure subfield doesn't change (the result of "EVAL riTrnTree"
changes, the result of "EVAL resInf" does not). WHY ????
All this may be caused by the debugger. The real problem is that I
temporarily move the whole resInf structure to some other field (defined
as a character field), and when it is moved back and I try to use the
riTrnTree pointer it is no longer valid. How come ?
Best regards
Claus Nielsen
Sent via Deja.com http://www.deja.com/
Before you buy.
Njål Fisketjøn
>All this may be caused by the debugger. The real problem is that I
>temporarily move the whole resInf structure to some other field (defined
>as a character field), and when it is moved back and I try to use the
>riTrnTree pointer it is no longer valid. How come ?
For security reasons AS/400 pointers can only be manipulated by pointer
operation codes. That means that a pointer will loose it's "pointer
flag" if you is's manipulated by string op-codes. MI has a Copy Bytes
With Pointers instruction, but RPG has not. You will have to implement
another scheme, e.g. an array of pointers or something similar.
Njål Fisketjøn, FIGU DATA AS
n...@figu.no
http://www.robin.no/~nfisketj
Peter Levy
As to why the two pointer displays are different. it's got to be a problem
with the debugger. I've had a lot of problems debugging deep pointer stuff
in RPG-IV and C/400 so I know how you feel.
As to why the pointer isn't valid when you move it back. That's because when
you moved it to the character field it ceased to be a valid pointer,
probably because the character field wasn't on a 16 byte boundary. When you
moved it, either to or from the character variable, the AS/400 hardware sets
the high order "valid pointer" bit off and then it can no longer be used.
Hope this helps.
Peter Levy
Arkay Computer Consultants, Inc.
peter...@arkayusa.com
201-847-9798
<claus_ni...@my-deja.com> wrote in message
news:895ve6$k75$1...@nnrp1.deja.com...
> Hi,
>
> can anyone tell me why the interactive debugger displays different
> values for a pointer field in a datastructure when displaying
> (evaluating) the value of the subfield alone than when displaying the
> whole structure ?
>
> I've a got a structure that looks something like this:
>
> d resInf ds
> d riTrnTree *
> d riResc like(rbResc)
> d riWhse like(rbWhse)
>
> In the debugger "ev riTrnTree" and "ev resInf" gives the following
> output:
>
> > EVAL riTrnTree
> RITRNTREE = SPP:E15E8C04DF0018F0
> > EVAL resInf
> RITRNTREE OF RESINF = SPP:D448175848001EF0
> RIRESC OF RESINF = 'A010 '
> RIWHSE OF RESINF = '02'
>
> There is NOT a local field with the same name as the DS subfield, but
> when a value is assigned to riTrnTree it looks like the contents of the
> datastructure subfield doesn't change (the result of "EVAL riTrnTree"
> changes, the result of "EVAL resInf" does not). WHY ????
>
> All this may be caused by the debugger. The real problem is that I
> temporarily move the whole resInf structure to some other field (defined
> as a character field), and when it is moved back and I try to use the
> riTrnTree pointer it is no longer valid. How come ?
>
Karl Hanson
> >temporarily move the whole resInf structure to some other field (defined
> >as a character field), and when it is moved back and I try to use the
> >riTrnTree pointer it is no longer valid. How come ?
>
> operation codes. That means that a pointer will loose it's "pointer
> flag" if you is's manipulated by string op-codes. MI has a Copy Bytes
> With Pointers instruction, but RPG has not. You will have to implement
> another scheme, e.g. an array of pointers or something similar.
>
Yes this is likely the problem. However if the target of the move is
another data structure with identical description (ie with a pointer in
the same spot - not simply a character field the size of the structure)
the compiler should (in my opinion) generate the proper machine
instructions to copy and preserve the pointer tags. You might try this
solution and see if it helps.
--
Karl Hanson
Carsten Flensburg
Karl Hanson <kcha...@us.ibm.com> wrote in message
news:38B70FF9...@us.ibm.com...
>
> Yes this is likely the problem. However if the target of the move is
> another data structure with identical description (ie with a pointer in
> the same spot - not simply a character field the size of the structure)
> the compiler should (in my opinion) generate the proper machine
> instructions to copy and preserve the pointer tags.
I once had a similar problem and was told (by a kind soul in Toronto) that I
could prevent the compiler from messing up pointer subfields in data
structures if I specified the NoOpt keyword for the data structure.
Best regards,
Carsten Flensburg
Barbara Morris
As long as the target contains a pointer somewhere, it can be used to
copy structures with pointers. The pointers don't have to be at the
same offsets. Here's a way to define storage to hold a copy of data
structure DS1 that has pointers anywhere in the structure:
D DS
D temp like(ds1)
D * overlay(temp)
Barbara Morris
Karl Hanson wrote:
>
> ...However if the target of the move is
> another data structure with identical description (ie with a pointer in
> the same spot - not simply a character field the size of the structure)
> the compiler should (in my opinion) generate the proper machine
> instructions to copy and preserve the pointer tags.
> ...
Barbara Morris
the temporary storage is not aligned correctly, or if the compiler
doesn't know that the target contains pointers.
Barbara Morris
Carsten Flensburg wrote:
>
> Karl Hanson <kcha...@us.ibm.com> wrote in message
> news:38B70FF9...@us.ibm.com...
> >
> > Yes this is likely the problem. However if the target of the move is
> > another data structure with identical description (ie with a pointer in
> > the same spot - not simply a character field the size of the structure)
> > the compiler should (in my opinion) generate the proper machine
> > instructions to copy and preserve the pointer tags.
>
Carsten Flensburg
Barbara Morris <bmo...@ca.ibm.com> wrote in message
news:38BB2361...@ca.ibm.com...
> Carsten, that must have been a different problem. NOOPT won't help if
> the temporary storage is not aligned correctly, or if the compiler
> doesn't know that the target contains pointers.
That's what I found out back then too: I had a pointer declared at the
beginning of a data structure but that got messed up unless I declared a
dummy pointer at the end of the data structure too - or added the NoOpt
keyword (thanks!).
My comment here was referring to Karl's scenario of "another data structure
with identical description (ie with a pointer in the same spot - not simply
a character field the size of the structure)".
Best regards,
Carsten Flensburg
Karl Hanson
>
> Karl (and Claus),
> As long as the target contains a pointer somewhere, it can be used to
> copy structures with pointers. The pointers don't have to be at the
> same offsets. Here's a way to define storage to hold a copy of data
> structure DS1 that has pointers anywhere in the structure:
>
> D DS
> D temp like(ds1)
> D * overlay(temp)
>
> Barbara Morris
>
> Karl Hanson wrote:
> >
> > another data structure with identical description (ie with a pointer in
> > the same spot - not simply a character field the size of the structure)
> > instructions to copy and preserve the pointer tags.
This makes sense - my "identical description" was overkill. Without
knowing the problem background (nor much about RPG ;), it seemed more
obvious to clone the structure for the save area. But I can see
circumstances where defining a pointer anywhere in the target structure
(16 byte aligned of course) would be useful.
--
Karl Hanson