By default, most PL/I data is ALIGNED. String data, with IBM compatibility compiler options, by default is UNALIGNED. CHAR VARYING data is unaligned unless you specify the ALIGNED attribute. In general, aligned data gives you better performance.
It is good practice to not allow the compiler to insert padding bytes. Use the compiler option -map to produce the compiler listing; within the listing, look for -pad- which indicates compiler-inserted pad bytes. You can then design your data structures such that you do not give the compiler the opportunity to add padding bytes.
If you are compiling existing 32-bit designed programs in 64-bit mode, it is very likely that you will get padding that you did not get in 32-bit compiled programs. This can occur because POINTERs are now aligned on an 8-byte boundary, whereas they were previously aligned on a 4-byte boundary. In general, there is no reason to be alarmed but you must be aware of this extra padding and thus the change in the size of the structure.
This change may affect other assumptions on your part, which may or may not affect performance. For example:
DCL 1 LIST, 2 next ptr, 2 f fixed bin(31), 2 prev ptr, 2 data char(16);
SIZE(LIST) is 28 on 32-bit systems (no padding) but is 40 (8 + 4 + 4 byte pad + 8 + 16) on 64-bit systems.
UNIONs are the most efficient way to overlay data of like or un-like types. For example:
DCL 1 st, 3 * union,
5 binval fixed bin(15),
5 *,
7 hi_char char(1),
7 lo_char char(1);
is much more efficient than:
DCL binval fixed bin(15);
DCL 1 st based(addr(binval)),
7 hi_char char(1),
7 lo_char char(1);