View previous topic :: View next topic
|
Author |
Message |
Aditya.Srivastava
New User
Joined: 21 Aug 2012 Posts: 13 Location: India
|
|
|
|
Hello,
I am facing a situation in my z/OS shop where my QA team is doing a compare between unit test and integration load library and getting mismatches in few modules.
When I research about these mismatches I found that the differences are seen in V adcon which are part of literal pool and they have an address which differs by x'10' bytes between the two loads. Interestingly, all V adcon literal differences has a difference factor of x'10' bytes.
I checked in production library load module for program X which calls program A as
Code: |
L R15,=V(A)
BASR R14,R15
|
In program X, =V(A) goes in to literal pool. I brought this program in my work library and assembled there and generated a load module in my private library. When I compares my load module with production I am getting a mismatch in =V(A) and the difference between the two addresses is x'10'.
Example, if production value of =V(A) in load module of X is x'000712A0' then the value of =V(A) in my personal library is x'000712B0'.
I have read about V adcons but I am not sure about how it gets addresses during link edit and what can be a reason for difference in loads with always a value of x'10'.
Any help is appreciated.
Thanks,
Aditya[/code] |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2127 Location: USA
|
|
|
|
First of all, compare the maps of load modules created by the Binder (Linkage Editor) for both versions.
Then, maybe, you'll need also to compare the maps from their Assembler listings, too.
A dull comparison of binary modules may be a very bad idea... |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
As Sergeyken says, compare the load module maps of both modules. Carefully.
Conversion of V-cons to addresses is rather complex. A V con is both an address and it implies the address is an external symbol. Most of the time a V con contains the actual address of an external symbol. The major exception is for modules in a planned overlay structure. When a V con is used as linkage to a module in a different segment of the overlay - and planned overlay load modules are very rare any more - the V con actually points to an address in a special internal module created by the Linkage Editor or Binder identified as a $SEGTAB or $ENDTAB (I no longer remember which) that has code to tell a special piece of code to in the supervisor to load, if necessary, the segment containing the code to run, and then branch to the code. From the point of view of the original program, the CALL goes directly to the affected code with no intervention of the code in the $SEGTAB or $ENDTAB.
If anyone is interested - and I doubt if there is any interest - I can prepare a fuller report. |
|
Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008 Posts: 2127 Location: USA
|
|
|
|
I would not recommend the TS to go deeper into the physical structure of a binary load module. At least - for this QA purposes, for sure. |
|
Back to top |
|
|
Aditya.Srivastava
New User
Joined: 21 Aug 2012 Posts: 13 Location: India
|
|
|
|
Thank You for your responses !!
I think the team is using FILE AID software's load module compare option to do a compare. May be its not a best idea to that and I will advise them after some more research.
Thank You |
|
Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Aditya.Srivastava wrote: |
Thank You for your responses !!
I think the team is using FILE AID software's load module compare option to do a compare. May be its not a best idea to that and I will advise them after some more research.
Thank You |
Yes, even programs that claim to know something about load module structure can easily be confused by address constants. Comparing load modules is extremely difficult.
What you should try is to run IMBLIST LISTLOAD OUTPUT=XREF on both load modules, and check - not the nominal value as reported by Fileaid, but the XREF as reported by IMBLIST. |
|
Back to top |
|
|
|