Trying to retrieve *ENTRY parms from OPM RPG dumps, part II -- MI400

(Part I appeared in the RPG400-L and MIDRANGE-L lists on Monday, but got a
reply from Leif and another reply suggesting I post to MI400. So, now I'm
here with additional questions.)  My original post follows:

We are trying to determine the parameters for OPM RPG program objects that
we do not have source for.  We have forced a dump of the program by
temporarily renaming a file that the program expects to be there, then
calling the program, causing CPF4101, which allows a 'D' response.

The dump shows:

RPG/400 FORMATTED DUMP
NAME     OFFSET  ATTRIBUTES    VALUE
WP0001   01031B  CHAR(3)       '111'
WP0001.P 011BE0  POINTER(SPP)
                 SPACE OFFSET  66331                   '0001031B'X
                 OBJECT        QPADEV0001DBALE     550049
WP0002   01031E  CHAR(3)       '222'
WP0002.P 011BF0  POINTER(SPP)
                 SPACE OFFSET  66334                   '0001031E'X
                 OBJECT        QPADEV0001DBALE     550049
WP0003           NOT ADDRESSABLE
WP0003.P         NOT ADDRESSABLE

Some investigation with other programs that we do have source for seem to
indicate that the '.P' appended to a field name seems to indicate that it is
a program's *ENTRY parameter.  WP0003, as shown here, seems to be a
parameter that had no value passed.  (So, I called the program again with a
3rd parameter value specified, and dump for WP0003 showed similar
information to the first two fields.)  Also, the SPACE OFFSET would seem to
indicate the position of the parameters.

Have I pretty much nailed this?  Are there other considerations?  Again,
this concerns only OPM RPG, although I'm sure RPG-IV dumps have something
similar.
< ... End of original post ... >

Leif thought my assumptions looked good.  So I went with it, and wrote a
program to organize this information and another program to build *ENTRY
parm specs from that information.  The first test went extremely well; it
had a parameter with a data structure that had 30 subfields and my program
built it on the money.

Today, I ran this on another program and I am surprised to see that
variables seem to be overlapping each other according to their offsets and
sizes.  Just to give a glimpse:

 RPG/400 FORMATTED DUMP
 NAME     OFFSET  ATTRIBUTES    VALUE
 P0RTN    000646  CHAR(7)       '       '
 P0RTN.P  000000  POINTER(SPP)
                  SPACE OFFSET  1606       '00000646'X
<snip to:>
 ZWORK    000646  PACKED(5,0)   0

<snip to:>
 ##WSC    000649  PACKED(3,0)   0

Unless I am misunderstanding the offsets, it would appear that ZWORK & ##WSC
are directly overlaying P0RTN.  We know this cannot be true because we know
from experience that P0RTN is a 7-character return parameter that is used to
pass message IDs.  Also, the values show that P0RTN has blanks and the other
two packed numeric fields are zero.  There are other parameters suffering
from the same "overlaying" that I did not include here.

On a whim from another reply to my original post, I downloaded Gene's
DSPPGMSYM program from iSeriesNetwork, hoping this might help me.  Not much,
but I did glean this from the listing:

 ODT#   Symbol Name / Array Size  Symbol Type   Length
------------------- / --------------------------------
/009A   P0RTN       /             CHAR VAR        7
<snip>
/00F5   ZWORK       /             PACKED VAR      5, 0
/00F6   ##WSC       /             PACKED VAR      3, 0

I was a little surprised to see the difference in the offsets for the .P
(POINTER(SPP)) entries in the dump.  The first program (which worked
perfectly), had the first parameter's offset at 0C9260, while the second
program's first parameter's offset was 000000.

Can anyone understand what's going on here?  I would re-iterate that the
first program I did this to worked flawlessly.

Gene, could your program be modified to retrieve *ENTRY parameters?  With
data structures, if defined?

- Dan Bale
(I am *NOT* "Dale"
http://archive.midrange.com/midrange-l/200105/msg00281.html )