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
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.
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”.