We have referred the manuals for the various options as mentioned. Let me give you a glimpse of the situation.
01 ABCD PIC X(3).
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.
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.
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: 6968 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.
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.
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.