How to compare the content of catalogued modules?

, ,
1

Hello all!

We got three Natural-environments here at our company (Development, Test and Production). Now we have to compare the catalogued modules (=GPs) of all environments to find out code-differences. If we compare the timestamps of GPs, we got thousands of differences (e.g. a catall in Development-Environment changes all timestamps). So we got the idea to compare the content of the modules - i.e. comparing the md5-checksums of them. There are still thousands of differences. But this is not the real truth. I did some “investigations” and found out, that the naturals version and the version of the OS, some timestamps and lots of other stuff are stored inside the GPs. I guess many of the differences are coming from different Natural-Patchlevels or OS-Versions. The code itself should be the same in most cases.

So my idea is to cut out all version-info etc. and only to compare the code itself. But is there any documentation about Natural’s GP-Format on Open Systems?
It seems that the natural-Version is stored in Byte 27-30. The module’s timestamp is in Byte 41-48, the GDA-timestamp in Byte 49-56. But how can I find out the position of OS-Name and OS-Version?

Thanks,

Matthias

2

The format of the GP won’t help you.

Your technique was proposed at the Natural Conference a few years ago, and Software AG replied that the generated code could vary with each patchlevel of the compiler. That is, the generated code for a specific source statement could change. Even if you could ignore timestamps and version numbers, its very unlikely that two GPs would be identical.

3

I think you’re right. The code could vary - but in most cases it doesn’t. I did some hexdumps and diffs on some GPs and most differences are like that (screendump of my shell):

prompt> hexdump -Cv /path_to_dev_lib/GP/FRRX000N.NGN > FRRX000N.dev
prompt> hexdump -Cv /path_to_prod_lib/GP/FRRX000N.NGN > FRRX000N.prod
prompt> diff FRRX000N.dev FRRX000N.prod | tr '<>' 'dp'
2,3c2,3
d 00000010  ff ff ff ff ff ff 00 08  00 12 06 01 01 16 00 00  |................|
d 00000020  46 52 52 58 30 30 30 4e  c2 35 ad 80 bc bc a0 00  |FRRX000N.5......|
---
p 00000010  ff ff ff ff ff ff 00 08  00 12 06 01 01 05 00 00  |................|
p 00000020  46 52 52 58 30 30 30 4e  bc 4e 8f a5 2a 99 a0 00  |FRRX000N.N..*...|
43c43
d 000002a0  31 30 47 65 6e 65 72 69  63 5f 31 32 30 30 00 00  |10Generic_1200..|
---
p 000002a0  38 47 65 6e 65 72 69 63  5f 31 30 38 35 32 00 00  |8Generic_10852..|
57c57
d 00000380  20 20 41 ad 80 bc 60 a0  00 00 20 20 20 20 20 20  |  A...`...      |
---
p 00000380  20 20 41 4e 8f a5 2a 5d  e0 00 20 20 20 20 20 20  |  AN..*]..      |
69c69
d 00000440  20 20 20 20 20 20 41 ad  80 bc 60 a0 00 00 20 20  |      A...`...  |
---
p 00000440  20 20 20 20 20 20 41 4e  8f a5 2a 5d e0 00 20 20  |      AN..*]..  |

Differences are:

  • natural Patchlevel (hexdump-line 010)
  • the modules timestamp (hexdump-line 020)
  • the OS-Version (hexdump-line 2a0)
  • another timestamp (hexdump-line 380)
  • another timestamp (hexdump-line 440)

The only thing I’ve done is a stow on FRRX000N.dev. FRRX000N.prod is from 2005-01-30. And my conclusion: The code itself is identical.

The problem remains: Natural-Patchlevel and the module’s time stamp is on a fixed position inside the GP. The OS-Version and the timestamps are “variable”.