Step 3. Determine the number of CIs or blocks needed

The calculations in this step are done by database type.

To determine how many CIs or blocks are needed to hold your database records, go to the topic in this step that applies to the database type you are using. If you are using VSAM, the first CI in the database is reserved for VSAM.

HISAM: determining the number of CIs or blocks needed

A CI in HISAM can contain one or more logical records. In the primary data set a logical record can only contain one database record (or part of one database record). In the overflow data set a logical record can only contain segments of the same database record, but more than one logical record can be used for the overflow segments of a single database record.

In HISAM, you should remember how logical records work, because you need to factor logical record overhead into your calculations before you can determine how many CIs (control intervals) are needed to hold your database records. Logical record overhead is a combination of the overhead that is always required for a logical record and the overhead that exists because of the way in which database records are stored in logical records (that is, storage of segments almost always results in residual or unused space).

Because some overhead is associated with each logical record, you need to calculate the amount of space that is available after factoring in logical record overhead. Once you know the amount of space in a logical record available for data, you can determine how many logical records are needed to hold your database records. If you know how many logical records are required, you can determine how many CIs or blocks are needed.

For example, assume you need to load 500 database records using VSAM, and to use a CI size of 2048 bytes for both the KSDS and ESDS. Also, assume you need to store four logical records in each KSDS CI and two logical records in each ESDS CI.

  1. First factor in CI overhead by subtracting the overhead from the CI size: 2048 - 10 = 2038 bytes for both the KSDS and the ESDS. The 10 bytes of overhead consists of a 4-byte CIDF and two 3-byte RDFs.
  2. Then, calculate logical record size by dividing the available CI space by the number of logical records per CI: 2038/4 = 509 bytes for the KSDS and 2038/2 = 1019 bytes for the ESDS. Because logical record size in HISAM must be an even value, use 508 bytes for the KSDS and 1018 bytes for the ESDS.
  3. Finally, factor in logical record overhead by subtracting the overhead from logical record size: 508 - 5 = 503 bytes for the KSDS and 1018 - 5 bytes for the ESDS. HISAM logical record overhead consists of 5 bytes for VSAM (a 4-byte RBA pointer for chaining logical records and a 1-byte end-of-data indicator).

    This means if you specify a logical record size of 508 bytes for the KSDS, you have 503 bytes available in it for storing data. If you specify a logical record size of 1018 bytes for the ESDS, you have 1013 bytes available in it for storing data.

Refer to the previous example. Because the average size of a database record is 1336 bytes, the space available for data in the KSDS is not large enough to contain it. It takes the available space in one KSDS logical record plus one ESDS logical record to hold the average database record (503 + 1013 = 1516 bytes of available space). This record size is greater than an average database record of 1336 bytes. Because you need to load 500 database records, you need 500 logical records in both the KSDS and ESDS.

  • To store four logical records per CI in the KSDS, you need a minimum of 500/4 = 125 CIs of 2048 bytes each for the KSDS.
  • To store two logical records per CI in the ESDS, you need a minimum of 500/2 = 250 CIs of 2048 bytes each for the ESDS.

HIDAM or PHIDAM: determining the number of CIs or blocks needed

With HIDAM or PHIDAM, one VSAM logical record exists per CI or block. In this context, logical record is the unit of transfer when invoking an access method (such as VSAM), to get or put records. Logical record overhead consists of an FSEAP (4 bytes). If you are using RAPs (HIDAM only), the logical record overhead consists of one RAP (4 bytes). For example, assume you need to load 500 database records using VSAM and to use a CI size of 2048 bytes and no RAP (specify PTR=TB on the root to suppress the RAP for HIDAM).

  1. First, determine the size of a logical record by subtracting CI overhead from CI size: 2048 - 7 = 2041 bytes for the ESDS logical record size. The 7 bytes of overhead consists of a 4-byte CIDF and a 3-byte RDF.
  2. Then, determine the amount of logical record space available for data by factoring in logical record overhead. In this example, logical record overhead consists of an FSEAP: 2041 - 4 = 2037 bytes. This means you have 2037 bytes available to store data in each logical record.

HIDAM or PHIDAM index: calculating the space needed

Calculating space for a HIDAM or PHIDAM index is similar to calculating space for a HISAM KSDS. The difference is that no logical record overhead exists. One index record is stored in one logical record, and multiple logical records can be stored in one CI or block.

HDAM or PHDAM: determining the amount of space needed

Because of the many variables in HDAM or PHDAM, no exact formula exists for estimating database space requirements. Therefore, you should use a space calculation aid to help determine the amount of space needed for HDAM or PHDAM databases.

If you are using VSAM, and you decide to estimate, without use of an aid, the amount of space to allocate for the database, the first CI in the database is reserved for VSAM. Because of this, the bitmap is in the second CI.

With HDAM or PHDAM, logical record overhead depends on the database design options you have selected. You must choose the number of CIs or blocks in the root addressable area and the number of RAPS for each CI or block. These choices are based on your knowledge of the database.

A perfect randomizer requires as many RAPs as there are database records. Because a perfect randomizer does not exist, plan for approximately 20% more RAPs than you have database records. The extra RAPs reduces the likelihood of synonym chains. For example, assume you need to store 500 database records. Then, for the root addressable area, if you use:

  • One RAP per CI or block, you need 600 CIs or blocks
  • Two RAPs per CI or block, you need 300 CIs or blocks
  • Three RAPs per CI or block, you need 200 CIs or blocks

Because of the way your randomizer works, you decide 300 CIs or blocks with two RAPs each works best. Assume you need to store 500 database records using VSAM, and you have chosen to use 300 CIs in the root addressable area and two RAPs for each CI. This decision influences your choice of CI size. Because you are using two RAPs per CI, you expect two database records to be stored in each CI. You know that a 2048-byte CI is not large enough to hold two database records (2 x 1336 = 2672 bytes). And you know that a 3072-byte CI is too large for two database records of average size. Therefore, you would probably use 2048-byte CIs and the byte limit count to ensure that on average you would store two database records in the CI.

To determine the byte limit count:

  1. First, determine the size of a logical record by subtracting CI overhead from CI size: 2048 - 7 = 2041 bytes for the ESDS logical record size.
  2. Then, determine the amount of logical record space available for data by factoring in logical record overhead. (Remember only one logical record exists per CI in HDAM or PHDAM.) In this example, logical record overhead consists of a 4-byte FSEAP and two 4-byte RAPs: 2041 - 4 - (2 x 4) = 2029 bytes. This means you have 2029 bytes available for storing data in each logical record in the root addressable area.
  3. Finally, determine the available space per RAP by dividing the available logical record space by the number of RAPs per CI: 2029/2 = 1014 bytes. Therefore, you must use a byte limit count of about 1000 bytes.

Continuing our example, you know you need 300 CIs of 2048 bytes each in the root addressable area. Now you need to calculate how many CIs you need in the overflow area. To do this:

  • Determine the average number of bytes that will not fit in the root addressable area. Assume a byte limit count of 1000 bytes. Subtract the byte limit count from the average database record size: 1336 - 1000 = 336 bytes. Multiply the average number of overflow bytes by the number of database records: 500 x 336 = 168000 bytes needed in the non-root addressable area.
  • Determine the number of CIs needed in the non-root addressable area by dividing the number of overflow bytes by the bytes in a CI available for data. Determine the bytes in a CI available for data by subtracting CI and logical record overhead from CI size: 2048 - 7 - 4 = 2037 (7 bytes of CI overhead and 4 bytes for the FSEAP). Overflow bytes divided by CI data bytes is 168000/2037 = 83 CIs for the overflow area.

You have estimated you need a minimum of 300 CIs in the root addressable area and a minimum of 83 CIs in the non-root addressable area.