RE: Retrieve Source of RPG Programs -- MIDRANGE-L

On Tuesday, September 08, 1998 2:24 PM, Hans Boldt [SMTP:boldt@ca.ibm.com] 
wrote:
> Buck Calabro wrote:
> >> Note that while there are some companies that can do this
> >> for OPM RPG programs, the task is much more difficult for
> >> ILE RPG programs. Likely impossible, since the techniques
> >> used to produce source from an OPM RPG program can't be
> >> used for ILE RPG programs.
> >
> >Even if I use DBGVIEW(*SOURCE) or (*LIST)?
>
> DBGVIEW(*SOURCE) requires you to have the actual source
> file for the program available on your system.
>
> DBGVIEW(*LIST) could be used by some utility to reconstruct
> the program source, but that option increases the size of
> the program object dramatically.  For many production
> programs, this information will not be available.

I'm interested in understanding what happens "under the covers" during an 
ILE compile.

I compiled (CRTBDNRPG) the same RPG IV program in the default activation 
group 4 ways: DBGVIEW(*LIST), *NONE, *SOURCE and *STMT.  Here are the 
object sizes I came up with:
*LIST     299008
*NONE     188416
*SOURCE   237568
*STMT     229376

This program's object size goes up roughly 26% from *NONE to *SOURCE, and 
roughly by the same amount from *SOURCE to *LIST.  You can see that the 
difference between *STMT (the default) and *SOURCE is small; some 3%.

If I follow your remarks properly (no guarantees!) then I would guess that 
*SOURCE has only enough information to tie the generated code back to the 
original source statement, but it does not contain the actual source 
statement that generated the code.  At "debug" time, the debugger would 
have to use this table of statement numbers to retrieve the source 
statements dynamically.

*LIST would appear to store the actual line from the compiler listing that 
generated the code, and the debugger would use that copy, not the original 
source file.  This would mean that I could debug an object on a machine 
other than the one I have the source.  We have customers where we deploy 
the object but not the source.  (Yes, I know about using DDM files to 
debug through...)

What does *STMT do that *SOURCE does not?  How does it save that 8kb?

> >> Note that these services are no substitute for proper
> >> maintenance and archiving of program source.  Source
> >> files for the programs your business depend on must be
> >> considered vital resources with proper backup, archival,
> >> and restore procedures in place.
> >
> >100% agree!  Your business relies on that source code, but there *are*
> >those cases of malicious intent or ultimate disaster where your backup
> >posture is compromised and you really need source retrieval!
>
> Considering that it's very likely (IMHO) that no company
> will ever offer source recovery services for ILE programs,
> will that make a difference in your disaster recovery plan
> for your ILE apps?

Oddly enough, not for me or my shop.  We have multi-generational off-site 
backup schemes at all customer sites (and our own central development 
site, too!)  I offered the above scenario as... justification? for the 
current existence of source recovery services.  They make money somehow! 
:-)

Thank you so much for your contributions to the midrange-l list!  I 
appreciate the time you spend helping us out.

Buck Calabro
Commsoft, Albany, NY
mailto:mcalabro@commsoft.net

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---