z/OS DFSMS Using Data Sets
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Characteristics of Compressed Format Data Sets

z/OS DFSMS Using Data Sets
SC23-6855-00

Most characteristics which apply to extended-format data sets continue to apply to compressed format data sets. However, due to the differences in data format, the following characteristics describe compressed format data sets:
  • A compressed format data set might or might not contain compressed records.
  • The data format for a compressed format data set consists of physical blocks whose length has no correlation to the logical block size of the data set in the DCB, DCBE, and the data set label. The actual physical block size is calculated by the system and is never returned to the user. However, the system maintains the user's block boundaries when the data set is created so that the system can return the original user blocks to the user when the data set is read.
  • A compressed format data set cannot be opened for update.
  • When issued for a compressed format data set, the BSAM CHECK macro does not ensure that data is written to DASD. However, it does ensure that the data in the buffer has been moved to an internal system buffer, and that the user buffer is available to be reused.
  • The block locator token returned by NOTE and used as input to POINT continues to be the relative block number (RBN) within each logical volume of the data set. A multistriped data set is seen by the user as a single logical volume. Therefore, for a multistriped data set the RBN is relative to the beginning of the data set and incorporates all stripes. To provide compatibility, this RBN refers to the logical user blocks within the data set as opposed to the physical blocks of the data set.
  • However, due to the NOTE/POINT limitation of the 3 byte token, issuing a READ or WRITE macro for a logical block whose RBN value exceeds 3 bytes results in an ABEND if the DCB specifies NOTE/POINT (MACRF=P).
  • When the data set is created, the system attempts to derive a compression token when enough data is written to the data set (between 8K and 64K for DBB compression and much more for tailored compression). If the system is successful in deriving a compression token, the access method attempts to compress any additional records written to the data set. However, if an efficient compression token could not be derived, the data set is marked as noncompressible and there is no attempt to compress any records written to the data set. However, if created with tailored compression, it is still possible to have system blocks imbedded within the data set although a tailored dictionary could not be derived.

    If the compressed format data set is closed before the system is able to derive a compression token, the data set is marked as noncompressible. Additional OPENs for output do not attempt to generate a compression token once the data set has been marked as noncompressible.

  • A compressed format data set can be created using the LIKE keyword and not just through a DATACLAS.
Restrictions: The following types of data sets cannot be allocated as compressed-format:
  • Non-extended-format data sets
  • VSAM extended-format data sets that are not key-sequenced
  • AIX data sets
  • Temporary data sets
  • Uncataloged data sets.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014