Performance of the self-healing process

The performance of the self-healing process can be much more efficient than you might anticipate.

Many pointers can be healed with a small number of ILDS reads. This is due to the use of IMS database buffering. ILDSs are database data sets. They use database buffer pools in the same way that other database data sets use them. If a CI is already in its buffer pool, it does not have to be read from DASD.

Each ILE is 50 bytes. You specify the CI sizes for your ILDSs. An 8 KB ILDS CI holds up to 163 ILEs and a 16 KB CI holds up to 327 ILEs, so a single CI can hold many ILEs. After a reorganization, IMS might need to heal many pointers to the reorganized partitions.

When there are frequent uses of the CIs in an ILDS, they tend to remain in their buffer pool. One read of an ILDS CI might be sufficient to heal hundreds of pointers. As with most IMS database tuning, having a large number of buffers for frequently used data sets can be highly beneficial.

Another benefit of the self-healing process is that it does not waste resources healing pointers that are not used. In many secondary indexes, only a small number of entries are actually used. With a non-HALDB database, the entire index is rebuilt every time the indexed database is reorganized. With HALDB, the index is not rebuilt and only a small number of referenced index entries are updated. HALDB does not use resources to update pointers that are never used.

When an EPS is updated, an application marks buffers as altered only if the application is allowed to make updates. If updates are allowed and a block-level data sharing environment is being used, a block lock is requested for the altered block. Block level data sharing environments exist when the IRLM is used and the share level for the database is either 2 or 3. The block locks are held until the application program commits its unit of work, which could cause a performance problem.