I am using File Manager to compare COBOL-DB2(no SQL statements) Load modules, although there are some differences in both the loads in working-storage the utility return as "Matched".
The same source when compiled with IGYCRCTL directly without going thru pre compilation step, the differences are captured and the tool says "Load module don't match".
Is there any specific way to compare COBOL-DB2 loads where it can report the differences.
Hi I tried to compare COBOL load module by IBM file manager that the result of comparison should be "didn't matched" by we "Compile date" and "Link date and time" . The below is my JCL for compare
I suggest you confirm, in the manual, what all of the above mean and cause to be compared. I suspect you're comparing many things, but not the actual part you'd consider as the "program".
We have referred the manuals for the various options as mentioned. Let me give you a glimpse of the situation.
Example
----------
PROGA
---------
WORKING-STORAGE
01 ABCD PIC X(3).
PROGB
--------
WORKING-STORAGE
01 ABCD PIC X(6).
Compiled the bove two programs using Enterprise COBOL v 4.1, when comparing the load modules, ideally they shouldn't match, but to the surprise the tool says "Matched".
However, if the same programs are compiled using COBOL for VM MVS v 2.x compiler, the tools reports as not matched (compiler options used are same as used for above).
I would like to know, if there are any specific compiler options for Enterprise COBOL v 4.1 which will enable to report the differences.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
sanaanil wrote:
Hi Bill,
We have referred the manuals for the various options as mentioned. Let me give you a glimpse of the situation.
Example
----------
PROGA
---------
WORKING-STORAGE
01 ABCD PIC X(3).
PROGB
--------
WORKING-STORAGE
01 ABCD PIC X(6).
Compiled the bove two programs using Enterprise COBOL v 4.1, when comparing the load modules, ideally they shouldn't match, but to the surprise the tool says "Matched".
However, if the same programs are compiled using COBOL for VM MVS v 2.x compiler, the tools reports as not matched (compiler options used are same as used for above).
I would like to know, if there are any specific compiler options for Enterprise COBOL v 4.1 which will enable to report the differences.
As Dick says, the storage allocated for your fields to be contained in is the same. Eight bytes.
Each 01-level starts on a double-word boundary. Each 01 occupies eight bytes of storage. In one case you are using three bytes of storage, in the other six, but if you look at the compile output you'll see that the next 01-level starts at the same location in both cases.
If you are getting a mis-match with your other compiler, my best guess on the information we know is the link-editor/binder. There is (used to be) an option to set storage to binary zeros before putting the load together. If you are using that with the linkedit of Enterprise and not with the linkedit of the other, that could be the reason. If that is the case, it does not indicate that the loads are actually different, just a difference in some initial value somewhere.
If you want to try for getting a mismatch with your Enterprise, put VALUE SPACE (or some initial value) on the three/six byte field.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
why do you not use the load module attributes presented by AMBLIST
and compare those?
epecially since you don't appear qualified to properly parameterize a compare thru file-aid?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I'm curious about what you are trying to achieve. If you don't want to compare the executable code (which would be different for different-sized fields) you have to think much more about how to make the Working-Storage reliably mismatch. No chance with any Linkage Section changes, without going to the code. So what is your aim?
We are trying to find the differences in load modules(except compile date and time) generated by TEAMA and TEAMB. Even a difference like the above I mentioned should be reported.
I changed X(3) to X(9) and found the BLW for the next 01 level changed and the differences are reported, however if I change to X(6), the BLW for the next 01 level doesn't change and the differences are not reported.
Although the BLW for both of the programs are different when compiled with Enterprise COBOL 4.1 compiler, the load module differences are not reported.
The same source when compiled with IBM COBOL for MVS & VM 1.2.2 reports the differences.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
One Team in Thailand, one Team in India?
I haven't checked what options you are using for the compare.
If you compare the code, you will pick up differences in lengths of Working-Storage items.
You may not get differences if you change the type of the definition. You may, probably more often than not, but you won't be able to rely on it.
If you change working-storage in such a way that a double-word bounday is not crossed, then you may not see any difference "apparent" in the loadmodule. You are more likely to see the difference if you have a VALUE clause on the data.
Again, what are you trying to achieve? I know you are trying to compare things. What are you trying to achieve by comparing?
You have to do source comparison as part of this.
You first need to know exactly what you want to find out from looking at the loadmodules.
Then you need to find out which of those is possible.
Then you need to do it.
Then you need to "fill in" with other solutions for what it is that can't be readily achieved.
Or you need to hire someone for a short time who can set everything up for you from your stated requirements.... :-)
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
overlooked here is that the TS probably does not have the source.
also, you can never prove (other than by compiling/link-editing)
that a source belongs to this load. there are no time stamps.
at least with load modues, you have timestamps.
you can prove the differeneces in load modules,
by comparing their c-sects, which are available via AMBLIST.
if the attributes of a working storage (or linkage) variable are changed,
and it is referenced,
the code generated will be different.
isolation/description of differences, are a second step.
i believe the TS only wants
to prove or disprove that the two load modules are essentially the same,
though possibly compiled/link-edited at different times.
I do believe that comparing load modules of the same source
though generated by different compilers,
will always generate differences if the difference between the two compilers,
is exploited by the difference in generated code by the two compilers.
in otherwords,
if you are trying to compare two load modules of different COBOL Version,
you are wasting your time.
As Bill said, go to the source.
then see what the documented differences are between the two compilers.
We are doing a project named Automate build, where in the final step is the compare the load modules generated by TEAMA and TEAMB.
During our investigation last week, we have found few weird things happening, one among them is as below.
1. When ABC PIC X(3) changed to ABC PIC X(4), the tools shows up the load module differences, however if the same is put in a copybook the tool doesn't show up the differences.
As you said putting VALUE clause shall help, yes it is. But we cannot change 100s and 1000s of production copybooks. I hope you understand the constraints.
If there is no other way of getting the exact differences between two load modules, finally we will switch to source code comparison.
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
If there is no other way of getting the exact differences between two load modules,
I haven't seen an organization attempt load module comparison for a very long tme - across many clients. Basically because they understand that the load modules will almost never completely compare.
Why does someone in your organization believe comparing load modules will have value? If the source modules are exactly the same, what else would be of interest?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
As you've seen, and has been suggested, comparing the loads might be something that is not going to give you what you want.
If you compare working-storage areas, you can sometimes say for definite that some something is different, but in the case of uninitialised data you may be out of luck.
With no value clause, a PIC X, XX, XXX, XXXX, X(5), X(6), X(7) and X(8) could all "look" the same in a loadmodule, or could look different, depending. So not much use to you. And this can be extended to all data, in groups of eight bytes.
You can have different data definitions, and end up with identical working-storage in a loadmodule.
You have to go to sources. And, if you have them, the best way, to my mind, is the compile listing, as everything that is part of the program is in the listing, any SQL, CICS, COPYBOOKs etc. Let the compiler do the work.
