| View previous topic :: View next topic |
| Author |
Message |
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
 Posted: Wed Jun 02, 2021 4:21 am Post subject: Trying to understand how storage is allocated with COMP-5 |
 |
|
I'm racking my brains trying to see some sort of logic to how storage is allocated to an OCCURS field containing COMP-5 fields.
Here's the compiler listing
| Code: |
111 3 SOKTALAN2-NUM . . . . . . . . . . . . . 0000001B0 DS 1F Binary
113 3 SOKTALAN. . . . . . . . . . . . . . . . . 0000001B4 DS 0CL60 Group O <--- occurs 5
115 4 BELOPP-NUM. . . . . . . . . . . . . . . 0000001B4 DS 1F Binary
118 4 BELOPP. . . . . . . . . . . . . . . . . 0000001B8 DS 7C Disp-Num
120 4 DELPRODUKTKOD-NUM . . . . . . . . . . 0000001C0 DS 1F Binary
123 4 DELPRODUKTKOD . . . . . . . . . . . . . 0000001C4 DS 20C Display
125 4 SYFTE-NUM . . . . . . . . . . . . . . . 0000001D8 DS 1F Binary
128 4 SYFTE . . . . . . . . . . . . . . . . . 0000001DC DS 3C Disp-Num
130 4 AMORTERINGSTID-NUM. . . . . . . . . . . 0000001E0 DS 1F Binary
133 4 AMORTERINGSTID. . . . . . . . . . . . . 0000001E4 DS 2C Disp-Num
135 4 RANTESATS-NUM . . . . . . . . . . . . . 0000001E8 DS 1F Binary
138 4 RANTESATS . . . . . . . . . . . . . . . 0000001EC DS 3P Packed-Dec
139 4 FILLER. . . . . . . . . . . . . . . . . 0000001EF DS 1C Display
141 3 BEFINTLIGALAN2-NUM. . . . . . . . . . . . 0000002E0 DS 1F Binary
143 3 BEFINTLIGALAN . . . . . . . . . . . . . . 0000002E4 DS 0CL160 Group O
|
I appreciate that every COMP-5 variable is placed on a full-word boundary, but this is how I'm analyzing it (incorrectly it would seem).
1B4 (hex) is 436 (dec) which is exactly divisible by 4, which means that SOKTALAN is already on a full-word boundary.
The total number of bytes in the group is 56 bytes which is also divisble by 4, so this means that EVERY row of the 5 occurs will start on a full-word boundary. So WHY is the length of each row defined as 60 bytes as it is ?
At the same time, I have another occurs defined as follows: -
| Code: |
43 3 KAMPANJKODER2-NUM . . . . . . . . . . . . 0000000A8 DS 1F Binary
44 3 KAMPANJKODER. . . . . . . . . . . . . . . 0000000AC DS 0CL12 Group O <---- occurs 5
45 4 KOD-NUM . . . . . . . . . . . . . . . . 0000000AC DS 1F Binary
47 4 KOD . . . . . . . . . . . . . . . . . . 0000000B0 DS 6C Display
48 4 FILLER. . . . . . . . . . . . . . . . . 0000000B6 DS 2C Display
51 3 SOKANDEN2-NUM . . . . . . . . . . . . . . 0000000E8 DS 1F Binary
|
In this example, KAMPANJKODER starts at offset AC (hex) or 172 (dec) which is ALSO exactly divisible by 4 which means that it TOO starts on a full-word boundary.
The length of each row here is 12, so again, all rows will start on a full-word boundary.
So why does SOKTALAN have an extra 4 bytes added to each row's length but not KAMPANJKODER?
BTW. We're on Cobol 6.3.0.
_________________
Michael |
|
| Back to top |
|
 |
Spolacek
Beginner
Joined: 17 Dec 2002
Posts: 17
Topics: 2
Location: NJ, USA
|
| Posted: Wed Jun 02, 2021 1:57 pm Post subject: |
|
|
Hello Michael
The answer is slack bytes. The compiler is inserting slack bytes between some fields in order that the binary fields align on the proper boundary.
For example, field SYFTE is 3 character positions beginning at displacement 1DC. So it occupies bytes 1DC, 1DD, and 1DE. The next field is AMORTERINGSTID-NUM, which is a 4 byte binary field. Under the rules of boundary alignment, it must begin on a full-word boundary. However, the first byte available after field SYFTE is 1DF, which is not a full-word boundary. Therefore, the compiler inserted a slack byte at 1DF in order to cause AMORTERINGSTID-NUM to begin on a full-word boundary at 1E0. |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12367
Topics: 75
Location: San Jose
|
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 618
Topics: 172
Location: Stockholm, Sweden
|
| Posted: Thu Jun 03, 2021 12:44 am Post subject: |
|
|
Thanks to both of you. I as aware of slack bytes, but it must have go to the stage where I couldn't see the wood for the trees.
Anyway, thought I'd include a "layout" of of the SOKTALAN layout so the slack bytes become obvious.
| Code: |
Offset Length Start offset End offset
(hex) (dec) (dec)
3 SOKTALAN. . . . . . . . . . . . . . . . . 0000001B4 0CL60
4 BELOPP-NUM. . . . . . . . . . . . . . . 0000001B4 1F 436 439
4 BELOPP. . . . . . . . . . . . . . . . . 0000001B8 7C 440 446
1 slack byte needed here
4 DELPRODUKTKOD-NUM . . . . . . . . . . . 0000001C0 1F 448 451
4 DELPRODUKTKOD . . . . . . . . . . . . . 0000001C4 20C 452 471
4 SYFTE-NUM . . . . . . . . . . . . . . . 0000001D8 1F 472 475
4 SYFTE . . . . . . . . . . . . . . . . . 0000001DC 3C 476 478
1 slack byte needed here
4 AMORTERINGSTID-NUM. . . . . . . . . . . 0000001E0 1F 480 483
4 AMORTERINGSTID. . . . . . . . . . . . . 0000001E4 2C 484 485
2 slack bytes needed here
4 RANTESATS-NUM . . . . . . . . . . . . . 0000001E8 1F 488 491
4 RANTESATS . . . . . . . . . . . . . . . 0000001EC 3P 492 494
4 FILLER. . . . . . . . . . . . . . . . . 0000001EF 1C 495 495
|
Now we can see that the "original" row length of 56 needs to be increased by 4 bytes making the length 60 bytes (which of course is exactly what is in the compiler listing).
Thanks again for forcing me to do my homework better.
_________________
Michael |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
