0

In trying to find which RPG source file has been used to create an object, I'm looking to use object size, number of MI instructions and number of ODT (object definition table) entries to confirm which source file was used to create the object. There seems to be an opinion that the first two may vary with different versions of the compiler.

So wondered whether there is a correspondance between the particular type of statements in RPG source and the number of ODT entires.

I've googled extensively on this subject and not found any explanation that is comprehensible to the average application programmer about ODT entires. This article has a very detailed descrition of ODT but I'm finding it difficult to relate it to an RPG program and the number ODT entries.

This glossary defines ODT as a table built at compile time by the system to keep track of objects declared in the program. The program objects in the table include variables, constants, labels, operand lists and exception descriptions. The table resides in the compiled program object. So does this mean compiling an RPG source at different versions of the operating system would result in the number of ODT entries remaining same for each object created from the same source?

  • There will of course be a correlation between ODT entries and the source supplied to the compiler. But I can't see any useful way to use the ODT as a guide. Far too many ODT changes will come from objects external to the program, e.g., file fields, even if no compiler or source changes happen at all. The source file/member names from the *PGM and *MODULE objects should be more reliable. Can you clarify the actual problem? – user2338816 Aug 22 '15 at 02:03
  • There is an object, RPG *PGM OPM, that was created in 1998 with source that there is about five versions of in different libraries that is not under change control management. I was trying to determine which copy of the source the object was created from. The library of the source file that is shown from DSPOBJD *SERVICE no longer exists and there are no backups of.. Please let me know if you need any further clarification. – user3880011 Aug 24 '15 at 07:25
  • Does the program have full debug info? You might STRDBG to see if a list view is visible. If so, you might see if it compares with any existing source. – user2338816 Aug 25 '15 at 00:09
  • Good idea. I thought I had tried this but have just have double checked, in case not and have received a "(Source not available.)" message. – user3880011 Aug 25 '15 at 06:38
  • A source view can't be available if the library is gone. Only a list view could be possible. – user2338816 Aug 25 '15 at 10:55
  • Not sure what the difference is. How do I attempt to see the list view? – user3880011 Aug 25 '15 at 13:03
  • Can't see an option on STRDBG to use the list view. – user3880011 Aug 25 '15 at 13:27
  • The program in question is an OPM program. – user3880011 Aug 25 '15 at 13:40
  • Use STRDBG OPMSRC(*YES). See the parameter help text for details. It's "a shot in the dark", since the OPM compile option wasn't used a lot. But maybe...? If it works, the list view should immediately appear when the command runs. – user2338816 Aug 26 '15 at 07:01
  • Entering STRDBG OPM(*YES) then pressing F4, I reviewed all parameter help text but couldn't find any parameters which would allow you to see the list view. Thanks for taking the time to think about and comment on this issue. – user3880011 Aug 26 '15 at 10:17
  • correction to above comment: STRDBG OPMSRC(*YES) – user3880011 Aug 26 '15 at 10:28
  • Typos... never good for a programmer. The OPMSRC() parameter help text describes what happens for a "list" view... assuming one was requested at compile-time. What OS version? – user2338816 Aug 26 '15 at 10:41
  • The help text for this parm says that "the parameter is valid for ...OPM RPG...created with option (*LSTDBG)", however, it doesn't tell me how to access the list view. I'm not sure I know what the list view is, I probably need to do more googling about this. The pgm was compiled at V3R7M0. The machine it's running on V5R4. – user3880011 Aug 26 '15 at 10:59
  • I got a msg from the debugger saying that the program "does not contain OPM source debug data". So I think that rules out using STRDBG to retrieve the source. thanks for your comments anyway. – user3880011 Aug 26 '15 at 11:41
  • Next would be to run source comparisons and eliminate ones that can't be correct. E.G., If one has a line that causes some display or report artifact that doesn't show up when the program runs, you know it's the wrong source. Ones that are left might actually be duplicates, and can be consolidated. You might end up with just one. – user2338816 Aug 26 '15 at 12:48
  • Yes, I've done this. I did a DSPPGMREF on the object and eliminated versions of source that referenced objects that the object did not refer to. With the remaining source files, I still need to verify whether they were used to create the iobject, as the object's source file could have been deleted. – user3880011 Aug 26 '15 at 12:54
  • As a final note that maybe useful to others with the same issue: The command to restore source from an object, RTVSRC, has it's source code published at http://www2.systeminetwork.com/code/index.cfm?fuseaction=ShowAllIssueCode (from the September 1997 issue selected via the drop down box). – user3880011 Sep 01 '15 at 07:31

2 Answers2

1

Object size, MI instructions, ODT could all change between compiler versions. Or even PTF application.

There are two supported methods for tieing source to program object.

The display program (DSPPGM) command:

Type of program  . . . . . . . . . . . . . . . . :   OPM                
Source file  . . . . . . . . . . . . . . . . . . :   QRPGSRC            
  Library  . . . . . . . . . . . . . . . . . . . :     OLSMLSRC         
Source member  . . . . . . . . . . . . . . . . . :   OP510B             
Source file change date/time . . . . . . . . . . :   08/07/05  08:45:11 

Note for ILE RPG, DSPPGM provides a third screen that lists the modules used and you can 5=Display Description and see:

Module . . . . . . . . . . . . . . . . . . . . :   OP021B            
  Library  . . . . . . . . . . . . . . . . . . :     QTEMP           
Source file  . . . . . . . . . . . . . . . . . :   QRPGLESRC         
  Library  . . . . . . . . . . . . . . . . . . :     OLSMLSRC        
Source member  . . . . . . . . . . . . . . . . :   OP021B            
Module attribute . . . . . . . . . . . . . . . :   RPGLE             
Module creation date/time  . . . . . . . . . . :   04/04/14  10:27:41
Source file change date/time . . . . . . . . . :   03/25/14  14:08:49

Commercial change control packages make use of the object control level attribute that can be set via API and viewed via API or DSPOBJD DETAIL(*SERVICE)

Object . . . . . . . . . . . . . . . :   OP021B      
  Library  . . . . . . . . . . . . . :     OLSMLPRG  
Library ASP device . . . . . . . . . :   *SYSBAS     
Library ASP group  . . . . . . . . . :   *SYSBAS     
Type . . . . . . . . . . . . . . . . :   *PGM        

Object control level . . . . . . . . :   00N0001X    

Note that for ILE programs/service programs. The object change control can be set for both the *PGM object and the module objects used. The module level object change control is available via DSPPGM with the module source info.

Charles
  • 21,637
  • 1
  • 20
  • 44
  • Thank you for the answer Charles I did not know about the object control level. Unfortunately the source I'm looking at was maintained outside a of change control package. – user3880011 Aug 21 '15 at 13:29
  • I had interpreted IBMs definition of ODT in the gloassary above as meaning that if the number objects declared in the program remain constant i.e. variables, constants, labels, operand lists and exception descriptions then each object created from the same source irresepective of compiler versions would have the same number of ODT entries.. – user3880011 Aug 21 '15 at 13:34
  • Not sure now, I agree with your answer. Because it seems some ODT entries are created by compiler for internal purposes according to DSPPGM help where it says " ODT entries... is the number of program objects declared by the compiler. Program objects include variables, constants, labels, operand lists, and exception descriptions. Typically, one or more ODT entries are used for each variable, constant, and label in your program, and some are used by the compiler for internal purposes. " – user3880011 Aug 21 '15 at 13:54
  • @user3880011, I glanced through the docs you provided a link for. Nowhere does IBM say ODT won't change between compiler releases. For that matter I suspect that ODT could change between OS releases, such as from v5r4 to 6.1+; which required all executables to be retranslated. A current ex-IBM'er with intimate knowledge of the internals might provide a "better" answer. But I suspect they'd recommend against trying to use it. I can tell you that during install of a CMS, it validates source against programs using the DSPPGM info I talk about. – Charles Aug 21 '15 at 14:16
0

The DSPPGM command is independent of any change control package. It shows the attributes of the *PGM object as it was created.

Montana
  • 81
  • 5