In this study I would elaborate on the need to recuperate code from an object, or to protect code when you don’t want that someone could recover your source.

Spanish version.

Portuguese version.

It could happen that you want to work on a program but you aren’t able to find source, the object description indicates a library/source file no more existing or the source member isn’t simply there.

If the source object is a CLP/CLLE and it was compiled with “Allow RTVCLSRC” parameter = *YES, you could easily use the IBM command RTVCLSRC to recover your source. If the source is RPG or RPGLE there isn’t a standard IBM command to let you retrieve the code source. Then if the object is compiled with “Source listing options” there are different ways to solve the problem: you can check it by executing DSPPGM command verifying the observability option (*ALL).

If the program is compiled with observability you could use STRISDB (Start Interactive Source Debugger) or STRDBG to debug it and recover the source. This could be heavy for source with a lot of lines because you should “cut and past” a lot of times.

A valid alternative could be RDI or, if you don’t have it, “System I Navigator” will help you with the following steps (program compiled with Debug *ALL or *LIST):

1) Under Databases, right click on the system name and select Run SQL Script

2)Select Run as Debugger

3)Enter the program name and library and press Enter.

For more details about “System I Navigator” please have a look at the site



But what happen if the code doesn’t have the debugging options?

I had a look around and it seems the only solution is to ask help for companies that have decompiling tools: the only one I found who could recover without observability is “juggersoft”. Check the site at http://www.juggersoft.com or the faq page at http://www.juggersoft.com/faq.htm


And when you want to debug your code on the customer environment? Your code could be unprotected….. So in version 7.1 the ILE compilers (RPG, COBOL, CL, C and C++) and precompilers have a new parameter that you can use to encrypt your debug views. You could send code that can be debugged but your code isn’t exposed.

With the DBGENCKEY option, you can specify the encryption key that is used to encrypt the program source. The debugger requires the user to enter the debug encryption key before the views are decrypted. The key can have 1-16 bytes, with blank if the user specifies less bytes. Length zero means *NONE.

So the steps to use this parameter are:

  • Encrypt the debug view:


  • Run the STRDBG PGM_NAME DBGENCKEY(‘my code’)

Leave a Reply

Your email address will not be published. Required fields are marked *