HP OpenVMS Systems Documentation
Content starts here

HP COBOL
User Manual

Previous Contents Index

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:

  1. /LIST/MAP=D---No alignment and no padding, as in HP COBOL for OpenVMS VAX (see Example 16-4)
  2. /ALIGN/LIST/MAP=D---HP COBOL V1.0-style field elementary alignment, but no Alpha natural alignment and padding (see Example 16-5)
  3. /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.
  1. This pad byte brings substructure FLD1 up to: 


    12 = 3 * 4 bytes - multiple of longword alignment
  2. 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.
  3. These three pad bytes bring FLD3 up to: 


    16 = 4*4 bytes
  4. The total number of bytes in the record is now: 


    36 = 12 + 8 + 16 bytes
  5. *, p, f apply in the same way as for /ALIGN without PADDING. <>

Previous Next Contents Index