Recommendation: For QSAM, use the automatic technique so that the system can rebuild the pool automatically when using concatenated data sets.

For the basic access methods, these techniques cannot build buffers above the 16 MB line or build buffers longer than 32␠760 bytes.

If QSAM is used, the buffers are automatically returned to the pool when the data set is closed. If you did not use the BUILD macro and the buffer pool is not above the 16 MB line due to RMODE31=BUFF on the DCBE macro, you should use the FREEPOOL macro to return the virtual storage area to the system. If you code RMODE31=BUFF on a DCBE macro, then FREEPOOL has no effect and is optional. The system automatically frees the buffer pool.

The following applies to DASD, most tape devices, spooled, subsystem, and dummy data sets, TSO/E terminals, and UNIX files. For both data areas and buffers that have virtual addresses greater than 16 MB or less than 16 MB, the real address can exceed 2 GB. In other words, the real addresses of buffers can have 64 bits. IBM recommends that when you obtain storage for buffers or data areas with GETMAIN or STORAGE that you specify that the real addresses can be above the 2 GB bar. Therefore, you can code LOC=(xx,64). To get storage with real addresses below the 2 GB bar, you can code LOC=(xx,ANY) or LOC=(xx,31). This coding has no effect on your application program unless it deals with real storage addresses, which is uncommon.

For tape devices that do not support 64 bit IDAWs, your program cannot use storage that has 64-bit real addresses. For these drives, bit UCBEIDAW is zero. These drives are the reel tape drives (IBM 3420) and some non-IBM cartridge drives. In addition for reel tape devices, the real addresses must be 24-bit. For all tape drives, the value in UCBTBYT3 is X'80'. For all tape drives with reels the value in UCBTBYT4 is less than X'80'.

In some rare applications, fullword or doubleword alignment of a block within a buffer is significant. You can specify in the DCB that buffers are to start on either a doubleword boundary or on a fullword boundary that is not also a doubleword boundary (by coding BFALN=D or F). If doubleword alignment is specified for format-V records, the fifth byte of the first record in the block is so aligned. For that reason, fullword alignment must be requested to align the first byte of the variable-length record on a doubleword boundary. The alignment of the records following the first in the block depends on the length of the previous records.

Buffer alignment provides alignment for only the buffer. If records from ASCII magnetic tape are read and the records use the block prefix, the boundary alignment of logical records within the buffer depends on the length of the block prefix. If the length is 4, logical records are on fullword boundaries. If the length is 8, logical records are on doubleword boundaries.

If you use the BUILD macro to construct the buffer pool, alignment depends on the alignment of the first byte of the reserved storage area.

When you code RMODE31=BUFF for QSAM, the theoretical upper limit for the size of the buffer pool is 2 GB. This imposes a limit on the buffer size, and thus on block size, of 2 GB divided by the number of buffers. If the system is to build the buffer pool, and the computed buffer pool size exceeds 2 GB, an ABEND 013 is issued. In practice, you can expect maximum buffer pool size to be less than 2 GB because of maximum device block sizes.