 |
HP COBOL
User Manual
HP COBOL without the
-align
flag or the /ALIGNMENT qualifier or with the /NOALIGNMENT qualifier
would align the data as follows:
| | | | | | 1111 1111 |
| 1223 | 3444 | 4555 | 5555 | 5 | | 6-77 | 88-- | 9999 | ---- | 0000 | 0000 |
|
And finally, HP COBOL with the
-align
flag or the /ALIGNMENT qualifier would align the data as follows:
| | | | | | 1111 1111 |
| 1-22 | 33-- | 4444 | ---- | 5555 | 5555 | 6-77 | 88-- | 9999 | ---- | 0000 | 0000 |
|
The examples that follow are applicable to Alpha and I64 only.
Example 16-3 shows the differences in the actions of /NOALIGN, /ALIGN
and
-align
, and /ALIGN=PADDING and
-align pad
on the internal alignments of data fields within COBOL data
structures in the Alpha, I64 and Tru64 UNIX environments.
The program fragment in Example 16-3 was extracted from a
COBOL program that was compiled three times on HP COBOL,
using the following qualifiers for each compilation:
- /LIST/MAP=D---No alignment and no padding, as in
HP COBOL for OpenVMS VAX (see Example 16-4)
- /ALIGN/LIST/MAP=D---HP COBOL V1.0-style
field elementary alignment, but no Alpha natural alignment and
padding (see Example 16-5)
- /ALIGN=PAD/LIST/MAP=D---Alpha natural
alignment and padding (see Example 16-6)
The excerpts of the Data Names in Declared Order from the listing maps
show the differences in vertical format in the Location and Byte
columns. Note the horizontal byte layouts to make it easier to read in
that orientation.
Example 16-3 shows that /ALIGNMENT without PADDING will align
internal COMP fields in the record format on longword boundaries, but
will not pad out the lengths of substructures to be multiples of the
alignments of the most strongly aligned fields within them. Also, it
does not pad the entire data structure. Alternatively,
/ALIGNMENT=PADDING pads internal substructures as well as the entire
record. The result is many more slack bytes in the record layout for
Example 16-6.
| Example 16-3 Comparing /NOALIGN, /ALIGN and
/ALIGN =PADDING (Alpha, I64) |
4 DATA DIVISION.
5 WORKING-STORAGE SECTION.
6
7 01 REC1.
8 02 FLD1.
9 03 FLD1-1 PIC S9(9) USAGE COMP.
10 03 FLD1-2 PIC S9(03)V9(04) USAGE DISPLAY.
11 02 FLD2 PIC X(005).
12 02 FLD3.
13 03 FLD3-1 PIC X.
14 03 FLD3-2 PIC S9(9) USAGE COMP.
15 03 FLD3-3 PIC S9(5) USAGE DISPLAY.
|
| Example 16-4 Data Map for /NOALIGNMENT
(Alpha, I64) |
Source Listing
Data Names in Declared Order
Line Level Name Location Size Bytes Usage Category
----- ----- -------- ------------- ---- ----- ------- --------
7 01 REC1 2 00000000 26 26 DISPLAY Group
8 02 FLD1 2 00000000 11 11 DISPLAY Group
9 03 FLD1-1 2 00000000 9 4 COMP N
10 03 FLD1-2 2 00000004 7 7 DISPLAY N
11 02 FLD2 2 0000000B 5 5 DISPLAY AN
12 02 FLD3 2 00000010 10 10 DISPLAY Group
13 03 FLD3-1 2 00000010 1 1 DISPLAY AN
14 03 FLD3-2 2 00000011 9 4 COMP N
15 03 FLD3-3 2 00000015 5 5 DISPLAY N
|
Byte Layout for Example 16-4:
|REC1 |
|FLD1 |FLD2 |FLD3 |
|FLD1-1 |FLD1-2 | |*|FLD3-2 |FLD3-3 |
| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 5 12 17 22
18
Begin byte number (starting with 0)
Record length is 26 bytes.
|
Note
The asterisk (*) designates FLD3-1. Also, no padding
or filler will result, just as with HP COBOL for OpenVMS VAX on OpenVMS VAX.
|
| Example 16-5 Data Map for /ALIGNMENT, -align
(Alpha, I64) |
Source Listing
Data Names in Declared Order
Line Level Name Location Size Bytes Usage Category
----- ----- ------ ----------- ----- ---- ------ --------
7 01 REC1 2 00000000 29 29 DISPLAY Group
8 02 FLD1 2 00000000 11 11 DISPLAY Group
9 03 FLD1-1 2 00000000 9 4 COMP N
10 03 FLD1-2 2 00000004 7 7 DISPLAY N
11 02 FLD2 2 0000000B 5 5 DISPLAY AN
12 02 FLD3 2 00000010 13 13 DISPLAY Group
13 03 FLD3-1 2 00000010 1 1 DISPLAY AN
14 03 FLD3-2 2 00000014 9 4 COMP N
15 03 FLD3-3 2 00000018 5 5 DISPLAY N
|
Byte Layout for Example 16-5:
|REC1 |
|FLD1 |FLD2 |FLD3 |
|FLD1-1 |FLD1-2 | |*| |FLD3-2 |FLD3-3 |
| | | | |f f f| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 5 12 17 21 25
Begin byte number (starting with 0)
Record length is 29 bytes.
|
Notes:
The asterisk (*) designates FLD3-1.
The letter f designates internal filler bytes produced
because the field FLD3-2 has to start on the boundary that is the next
higher multiple of 4 because it is longword-aligned. The intervening
three bytes following FLD3-1 are skipped over.
|
| Example 16-6 Data Map for /ALIGNMENT
=PADDING, -align pad (Alpha, I64) |
Source Listing
Data Names in Declared Order
Line Level Name Location Size Bytes Usage Category
---- ----- ------- ------------ ----- ----- -------- --------
7 01 REC1 2 00000000 36 36 DISPLAY Group
8 02 FLD1 2 00000000 12 12 DISPLAY Group
9 03 FLD1-1 2 00000000 9 4 COMP N
10 03 FLD1-2 2 00000004 7 7 DISPLAY N
11 02 FLD2 2 0000000C 5 5 DISPLAY AN
12 02 FLD3 2 00000014 16 16 DISPLAY Group
13 03 FLD3-1 2 00000014 1 1 DISPLAY AN
14 03 FLD3-2 2 00000018 9 4 COMP N
15 03 FLD3-3 2 0000001C 5 5 DISPLAY N
|
Byte Layout for Example 16-6:
|REC1
|FLD1 |FLD2 |FLD3 |
|FLD1-1 |FLD1-2 (1)| | (2) |*| |FLD3-2 |FLD3-3 | (3) |
| | |p| |p p p| |f f f| | |p p p|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 5 13 18 21 25 29 34 36
Begin byte number (starting with 0)
Record length is 36 bytes.
|
- This pad byte brings substructure FLD1 up to:
12 = 3 * 4 bytes - multiple of longword alignment
|
- These three pad bytes are skipped over. They are required because
FLD3, the next substructure, has to start on a longword boundary
because it contains FLD3-2.
FLD2 contains five bytes and is padded
three bytes out to eight.
- These three pad bytes bring FLD3 up to:
- The total number of bytes in the record is now:
- *, p, f apply in the same way as for /ALIGN without PADDING.
<>
 |
|
|
|
