1. Initially, OpenVMS VAX compatible alignment is specified either by NOALIGNMENT or the absence of ALIGN on the compile command.
2. The SET ALIGNMENT directive specifies alignment along natural boundaries, superseding the initial OpenVMS VAX compatible alignment.
3. The SET NOALIGNMENT directive specifies VAX compatible alignment; data is now byte-aligned.
4. The END-SET ALIGNMENT directive terminates the alignment specified with the previous SET directive ((3) SET NOALIGNMENT). Alignment is once again along the natural boundaries as specified by (2), the SET ALIGNMENT directive.
5. This END-SET ALIGNMENT directive terminates the alignment specified with the original directive ((2) SET ALIGNMENT). Alignment is now OpenVMS VAX compatible as specified by the default command-line option.

The alignment examples that follow illustrate the following important points:

• Compaq COBOL for OpenVMS VAX and Compaq COBOL align 01 (and 77) data items along different boundaries, as follows:
  • Compaq COBOL for OpenVMS VAX aligns 01 data records and items along longword boundaries. It byte-aligns all other fields unless SYNC has been specified.
  • Compaq COBOL aligns 01 records and items along quadword boundaries. It byte-aligns all other fields unless SYNC or the alignment option has been specified.
• The effects of the SYNCHRONIZED clause, the alignment command-line option, and the SET ALIGNMENT directive on elementary data alignment are identical.

Example 16-2 through Example 16-6 show a comparison of the use and results of several alignment cases. They are applicable to both Tru64 UNIX and OpenVMS Alpha. Example 16-2 shows the effects of the SYNCHRONIZED clause in program source, as compared with the /ALIGNMENT qualifier on the command line.

Example 16-2 Using /ALIGNMENT with SYNCHRONIZED

01 comp-group. 02 cg-x1 pic x. (1) 02 cg-c1 pic 9(1) comp. (2) 02 cg-c3 pic 9(3) comp. (3) 02 cg-c7 pic 9(7) comp. (4) 02 cg-c12 pic 9(12) comp. (5) 01 comp-group-synch. 02 cg-x1-synch pic x. (6) 02 cg-c1-synch pic 9(1) comp synchronized. (7) 02 cg-c3-synch pic 9(3) comp synchronized. (8) 02 cg-c7-synch pic 9(7) comp synchronized. (9) 02 cg-c12-synch pic 9(12) comp synchronized. (10)

The data is aligned as shown in the following examples using different alignment configurations. In the accompanying data diagrams, a number (n) indicates that that byte is occupied by the nth field of the record, and a dash (---) indicates a filler byte. The fields are indicated by the callouts in the right column of Example 16-2.

Compaq COBOL for OpenVMS VAX would align the data as follows:

| | | | | 1111 | 1111 | | 1223 | 3444 | 4555 | 5555 | 5 | 6-77 | 88-- | 9999 | ---- | 0000 | 0000 | |

Compaq 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, Compaq 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 |

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 OpenVMS Alpha and Tru64 UNIX environments.

The program fragment in Example 16-3 was extracted from a COBOL program that was compiled three times on Compaq COBOL, using the following qualifiers for each compilation:

1. /LIST/MAP=D---No alignment and no padding, as in Compaq COBOL for OpenVMS VAX (see Example 16-4)
2. /ALIGN/LIST/MAP=D---Compaq 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 sub-structures 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

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

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.

Example 16-5 Data Map for /ALIGNMENT, -align

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.

Example 16-6 Data Map for /ALIGNMENT =PADDING, -align pad

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.

The following list summarizes the specifications and restrictions for the Compaq COBOL compiler. The compiler issues diagnostic messages whenever you exceed its design parameters.

• Run-time storage (generated object code and data) for COBOL programs cannot exceed 2,147,483,647 bytes.
• The length of an FD's record cannot exceed 32,767 bytes for a sequential file, 32,234 bytes for an indexed file, or 32,255 bytes for a relative file. For SD records, the length cannot exceed 32,759 bytes for a sequential file, 32,226 bytes for an indexed file, or 32,247 bytes for a relative file.
• On OpenVMS, bucket size for relative and indexed files cannot be greater than 63.
• A sequential disk file's multiblock count cannot be greater than 127.
• The physical block size for a sequential tape file must be from 20 to 65,532 bytes, inclusively. <>
• Run-time storage for an indexed file's RECORD KEY or ALTERNATE RECORD KEY data item must not be greater than:
  • 255 bytes on OpenVMS Alpha systems
  • 120 bytes on Tru64 UNIX systems
  • 128 bytes on Windows NT systems
• The number of bytes in the string making up a VALUE OF ID file name or data name must not exceed 255.
• The number of indexed file RECORD KEY and ALTERNATE RECORD KEY data items must not exceed 255 per file.
• The maximum number of segments in a segmented key is eight.
• The number of literal phrases specified to define an alphabet in an ALPHABET clause of the SPECIAL-NAMES paragraph must not be greater than 256.
• The value of a numeric literal in a literal phrase of an ALPHABET clause must not be greater than 255.
• The value of a switch number in the SWITCH clause of the SPECIAL-NAMES paragraph must be from 1 to 16, inclusively.
• The value of a numeric literal in the SYMBOLIC CHARACTERS clause must be from 1 to 256, inclusively.
• On OpenVMS, the value of an integer in the EXTENSION option of the APPLY clause must be from 0 to 65,535, inclusive.
• The value of an integer in the WINDOW option of the APPLY clause must be from 0 to 127, inclusive, or equal to 255.
• The value of the integer in the RESERVE AREAS clause must not be greater than 127.
• If a data item is allocated more than 65,535 bytes, a COBOL program cannot reference it except with INITIALIZE and CALL BY REFERENCE.
• Alphanumeric or numeric edited picture character-strings cannot represent more than 255 standard data format characters.
• Alphanumeric or alphabetic picture character-strings cannot represent more than 65,535 standard data format characters.
• A nonnumeric literal cannot be greater than 256 characters.
• A hexadecimal literal cannot be greater than 256 hexadecimal digits.
• A PICTURE character-string cannot contain more than 256 characters.
• The number of operands in the USING phrase of a CALL statement cannot be greater than 255.
• The number of USING files in a SORT or MERGE statement cannot exceed 10.
• On OpenVMS, the maximum number of characters in a subschema pathname specification is 256. <>
• The maximum static nesting depth of contained programs is 256.
• The maximum number of characters in a user-word in Compaq COBOL is 31. The maximum number of characters allowed in a user-word as defined by the ANSI COBOL standard is 30. The compiler issues an informational diagnostic if you use 31-character user-words. The maximum number of characters in an external report file name is 30.
• On OpenVMS, the maximum number of strings associated with the /AUDIT command line qualifier is 64.
• The maximum number of characters in a Oracle CDD/Repository pathname specification is 256.
• The maximum number of levels in a database subschema record definition supported by Compaq COBOL is 49.
• The maximum number of digits in a numeric database data item supported by Compaq COBOL is 31.
• The maximum number of standard data format characters in a character-type database data item is 65,535. <>
• The maximum number of digits in a picture character string describing fixed-point numeric and numeric-edited data items is 31.
• The maximum number of digits in numeric literals is 31.
• The maximum number of characters in a picture character string is 50.
• The maximum number of digits supported in most intrinsic functions is 31.
• The maximum number of digits in numeric SORT/MERGE keys is 31.
• The maximum number of digits in PACKED-DECIMAL (COMP-3) numeric and unsigned DISPLAY numeric ISAM keys is 31.
• The Sort-32 (available on OpenVMS) record size limit is 65,535 bytes.
• The Sort-32 key size limit is 65,529 bytes. <>
• The Hypersort key size limit is 65,535 bytes.
• If a file is assigned to magnetic tape media and you use the BLOCK CONTAINS clause in the associated file description, the number of characters in a physical block determined from the BLOCK CONTAINS clause must be an even multiple of 8.
• If a file is assigned to a disk medium and you use the BLOCK CONTAINS clause in the associated file description, the BLOCK CONTAINS value must be an even multiple of 1024.
• The maximum number of lines in any report file is 999,998,000,001.
• The maximum subscript value for any subscript or index name is 2,147,483,647.
• In the OCCURS n TIMES clause of a Data Description entry, the maximum allowable value for n is 2,147,483,647.
• On OpenVMS, the maximum static scoping depth of database USE procedures is 84.
• The maximum number of operands in a given COBOL DML statement
  is 255. <>
• In a PERFORM n TIMES statement, the maximum allowable value for n is 2,147,483,647.
• The maximum static nesting depth of nested IF statements is 64.
• The maximum number of levels for subscripts is 48.
• The maximum number of files in a MULTIPLE FILE TAPE clause is 255.
• For files assigned to magnetic tape, the record size for variable-length record files cannot exceed 9995 characters.
• For files assigned to magnetic tape, the block size must be from 20 to 999,999 characters, inclusive.
• For files assigned to magnetic tape, the number of files in a given volume set cannot exceed 9999 files.
• The number of magnetic tapes spanned by a single file cannot exceed 9999 tapes.