Choosing a logical record length for a HISAM database

Logical record length considerations

The following should be considered:

• Only complete segments can be stored in a logical record. Therefore, the space between the last segment that fit in the logical record and the end of the logical record is unused.
• Each database record starts at the beginning of a logical record. The space between the end of the database record and the end of the last logical record containing it is unused. This unused space is relative to the average size of your database records.
• Very short or very long logical records tend to increase wasted space. If logical records are short, the number of areas of unused space increases. If logical records are long, the size of areas of unused space increases. The following figure shows why short or long logical records increase wasted space.

Choose a logical record length that minimizes the amount of unused space at the end of logical records.

The database record shown in the following figure is stored on three short logical records in Figure 2 and in two longer logical records in Figure 3. Note the three areas of unused space.

Figure 1. Database record for logical record examples

In the following figure, note the three areas of unused space. In Figure 3, there are only two areas of unused space, rather than three, but the total size of the areas is larger.

Figure 2. Short logical records

Figure 3. Long logical records

Segments in a database record that do not fit in the logical record in the primary data set are put in one or more logical records in the overflow data set. More read and seek operations, and therefore longer access time, are required to access logical records in the overflow data set than in the primary data set. This is especially true as the database grows in size and chains of overflow records develop. Therefore, you should try to put the most-used segments in your database record in the primary data set. When choosing a logical record length the primary data set should be as close to average database record length as possible. This results in a minimum of overflow logical records and thereby minimizes performance problems. When you calculate the average record length, beware of unusually long or short records that can skew the results.

A read operation reads one CI into the buffer pool. CIs contain one or more logical records in a database record. Because of this, it takes as many read and seek operations to access an entire database record as it takes CIs to contain it. In Figure 5, each CI contains two logical records, and two CIs are required to contain the database record shown in the following figure. Consequently, it takes two read operations to get these four logical records into the buffer.

Figure 4. Database record for logical records example

Figure 5. Logical records example with two read operations

The number of read and seek operations required to access a database record increases as the size of the logical record decreases. The question to consider is: Do you often need access to the entire database record? If so, you should try to choose a logical record size that will usually contain an entire database record. If, however, you typically access only one or a few segments in a database record, choice of a logical record size large enough to contain the average database record is not as important.

Consider what will happen in the following setup example in which you need to read database records, one after another:

• Your CI or block size is 2048 bytes.
• Your Logical record size is 512 bytes.
• Your Average database record size is 500 bytes.
• The range of your database record sizes is 300 to 700 bytes.

Because your logical and average database record sizes are about equal (512 and 500), approximately one of every two database records will be read into the buffer pool with one read operation. (This assumption is based on the average size of database records.) If, however, your logical record size were 650, you would access most database records with a single read operation. An obvious trade-off exists here, one you must consider in picking a logical record length for HISAM data sets. If your logical record size were 650, much unused space would exist between the end of an average database record and the last logical record containing it.

Rules to observe

The following rules must be observed when choosing a logical record length for HISAM data sets:

• Logical record size in the primary data set must be at least equal to the size of the root segment, plus its prefix, plus overhead. If variable-length segments are used, logical record size must be at least equal to the size of the longest root segment, plus its prefix, plus overhead. Five bytes of overhead is required for VSAM.
• Logical record size in the overflow data set must be at least equal to the size of the longest segment in the overflow data set, plus its prefix, plus overhead. Five bytes of overhead is required for VSAM.
• Logical record lengths in the overflow data set must be equal to or greater than logical record length in the primary data set.
• The maximum logical record size is 30720 bytes.
• Except for SHISAM databases, logical record lengths must be an even number.

Calculating how many logical records are needed to hold a database record

Calculate the average size of a database record before plotting various logical record sizes. By calculating the average size of a database record, given a specific logical record size, you can see how many logical records it takes to hold a database record (of average size).

Specifying logical record length

Specify the length of the logical records on the RECORD= parameter in the DATASET statement of the DBD Generation utility.