Re: Reply list entry handling?

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Mark

Your point is well-taken, but I think it is not a problem. The lengths 
and offsets are part of the contents. Proper parsing, just as with APIs, 
would mean using those structural values.

So the layout of the contents is manageable, if you correctly 
reverse-engineer what any codes mean. Given that you can run DMPSYSOBJ - 
might be security restrictions there, too. I see that it is *PUBLIC 
*EXCLUDE, too. Given that, processing the printed output - using your 
OVRPRTF idea to push output to a PF - is fairly easily done.

But this still probably needs profile swapping, if David can do that. 
Someone suggested he can with jt400.

Vern

On 11/30/2012 9:13 AM, Mark S Waterbury wrote:
> Vern:
>
> Assuming you can somehow avoid the MCH6801 that will result from trying
> to use a pointer to a system domain object to examine the internals of
> an IBM-defined object, this approach seems far more likely to be subject
> to change from release to release than relying on the layout of spool
> file records, e.g. using the output of the WRKRPYLE *PRINT command.  :-o
>
> Mark S. Waterbury
>
>   > On 11/30/2012 9:53 AM, Vernon Hamberg wrote:
> > I ran the DMPSYSOBJ command on this object -
> >
> > QSYS/DMPSYSOBJ OBJ(QSYSRPYL) CONTEXT(QSYS) TYPE(19) SUBTYPE(D8)
> >
> > Here's the result -
> >
> > 0000A0   00000000 00000000 00000000 00000005   00000000 00000000
> > 00000000 00000000  *                                *
> > 0000C0   00000000 00000000 00000000 00000000   00000020 000000F0
> > 00000010 A100000A  *                       0    ~   *
> > 0000E0   C3D7C1F0 F7F0F000 01C40000 00000000   00000020 00000110
> > 000000D0 B1000014  *CPA0700  D                 }£   *
> > 000100   D9D7C7F0 F0F0F000 01C40000 00000000   00000020 00000130
> > 000000F0 B100001E  *RPG0000  D                 0£   *
> > 000120   C3C2C5F0 F0F0F000 01C40000 00000000   00000020 00000150
> > 00000110 B1000028  *CBE0000  D             &    £   *
> > 000140   D7D3C9F0 F0F0F000 01C40000 00000000   00000040 00000010
> > 00000130 82200CD2  *PLI0000  D                  b  K*
> > 000160   C3D7C1F3 F2C2F200 01C90011 89E28599   8985A240 D581A589
> > 8781A396 990000FF  *CPA32B2  I  iSeries Navigator   *
> > 000180   FF00FFFF 00000000 00000000 00000000   00000E70 00000000
> > 00000150 00001B58  *                   ø       &   ì*
> >
> > Seems to be a count (x'05' in line 1), an entry length (x'20' and x'40'
> > here) and number of codesor offsets - do I hear the term "reverse
> > engineering"?
> >
> > Vern