× 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.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.