When trying to write a custom query that involves DMH_COMPILE_UNIT, we came up this question:
DMH_COMPILE_UNIT table has 2 different columns - (1) COMP_UNIT_ID (2) MEMBER_ID
Based on RAA online help, here is what I understand:
COMP_UNIT_ID is supposed to be a unique id for each compile unit; while MEMBER_ID would be the foriegn key reference to FILE_ID of DMH_FILE table.
After scanning inventory, I observe that, both COMP_UNIT_ID and MEMBER_ID are same for all components being scanned so far.
Question 1. Why do we have 2 seperate columns - when they seem to have the same value? (I'm guessing, these will differ in future versions, when RAA allows a single file to have multiple compilation units, is this correct?)
Question 2. In v 18.104.22.168, can these columns be used interchangeably in custom queries (in join \ where clauses)?
Pinned topic DMH_COMPILE_UNIT table - COMP_UNIT_ID versus MEMBER_ID
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-11-12T08:34:20Z at 2012-11-12T08:34:20Z by SystemAdmin
Re: DMH_COMPILE_UNIT table - COMP_UNIT_ID versus MEMBER_ID2012-11-09T14:32:00ZThis is the accepted answer. This is the accepted answer.COMP_UNIT_ID name of the main CSECT
MEMBER_ID name of the library member containing the compiling unit_id
When you create an executable you can name it different than the member id.
For example in COBOL I have source file in member name MEMFIL and I code in
I understand that member_id will be MEMFIL and COMP_UNIT_ID will be PROGNAM
jcdelmo 0600012HN8370 Posts
Re: DMH_COMPILE_UNIT table - COMP_UNIT_ID versus MEMBER_ID2012-11-09T15:46:46ZThis is the accepted answer. This is the accepted answer.The PROGRAM (compile unit) assets primary key is COMP_UNIT_ID in the DMH_COMPILE_UNIT table. The FILE (member) assets primary key is FILE_ID in the DMH_FILE table. Prior to RAA v6, the FILE_ID column was named MEMBER_ID - explaining why some of the tables use FILE_ID and some (still) use MEMBER_ID.
The MEMBER_ID column in the DMH_COMPILE_UNIT table is (obviously) a foreign key to the DMH_FILE table - representing the program's main file.
The intent, as you suspect, is to eventually support multiple compile units per file.
Currently the value of the two ids are the same.
Because they are the same one could use them interchangeably, but I would strongly discourage doing that as your custom queries may not work as expected any future release that supports multiple compile units per file.