Sharing secondary index databases

An index database can contain up to 16 secondary indexes. When a database contains more than one secondary index, the database is called a shared index database. HALDBs and DEDBs do not support shared secondary indexes.

Although using a shared index database can save some main storage, the disadvantages of using a shared index database generally outweigh the small amount of space that is saved by its use.

The original advantage of a shared index database was that it saved a significant amount of main storage for buffers and some control blocks. However, when VSAM was enhanced with shared resources, the savings in storage became less significant.

For example, performance can decrease when more than one application program simultaneously uses the shared index database. (Search time is increased because the arm must move back and forth between more than one secondary index.) In addition, maintenance, recovery, and reorganization of the shared index database can decrease performance because all secondary indexes are, to some extent, affected if one is. For example, when a database that is accessed using a secondary index is reorganized, IMS automatically builds a new secondary index. This means all other indexes in the shared database must be copied to the new shared index.

If you are using a shared index database, you need to know the following information:

• A shared index database is created, accessed, and maintained just like an index database with a single secondary index.
• The various secondary indexes in the shared index database do not need to index the same database.
• One shared index database could contain all secondary indexes for your installation (if the number of secondary indexes does not exceed 16).

In a shared index database:

• All index segments must be the same length.
• All keys must be the same length.
• The offset from the beginning of all segments to the search field must be the same. This means all keys must be either unique or non-unique. With non-unique keys, a pointer field exists in the target segment. With unique keys, it does not. So the offset to the key field, if unique and non-unique keys were mixed, would differ by 4 bytes.

  If the search fields in your secondary indexes are not the same length, you might be able to force key fields of equal length by using the subsequence field. You can put the number of bytes you need to make each key field an equal length in the subsequence field.

• Each shared secondary index requires a constant specified for it, a constant that uniquely identifies it from other indexes in the secondary index database. IMS puts this identifier in the constant field of each pointer segment in the secondary index database. For shared indexes, the key is the constant, search, and (if used) the subsequence field.

Shared secondary index database commands

Commands sometimes operate differently depending on whether they are issued for the first of the secondary indexes or for subsequent secondary indexes. The first secondary index is the first database name specified in the DBDUMP statement of the shared secondary index DBDGEN. This first database is the real database. Other secondary index databases are physically part of the real database but they are logically distinct.

The first column in the following table lists the issuing command, the second column lists where the command is issued, the third column lists the affects of the command that was issued, and the fourth column provides additional comments.

Table 1. The effects of issuing shared secondary index database commands

Issuing the Commands…	On the…	Affects…	Comments
/STOP /LOCK UPDATE DB STOP(SCHD) UPDATE DB SET(LOCK(ON))	First secondary index	Only the named database	If no applications are scheduled on any shared secondary indexes that cause the authorization of the real database by DBRC, the commands have the same effect as the /DBRECOVERY or UPD DB STOP(ACCESS)command on the first secondary index. When a /DISPLAY DB or QUERY DB command is issued on the shared secondary index database, the subsequent secondary indexes are shown as stopped or locked only if the /STOP, UPD DB STOP(SCHD), /LOCK, UPD DB SET(LOCK(ON)), UPD DB STOP(ACCESS), or /DBRECOVERY command was issued. To undo the /STOP, UPD DB STOP(SCHD), UPD DB SET(LOCK(ON)), or /LOCK command, issue a /START, UPD DB START(ACCESS), UPD DB SET lOCK(OFF)), or /UNLOCK command on the first secondary index.
/STOP UPD DB STOP(SCHD) /LOCK UPD DB SET(LOCK(ON))	Subsequent secondary indexes	Only the named database	To undo the /STOP, UPD DB STOP(SCHD), UPD DB SET(LOCK(ON)), or /LOCK command, issue a /START, UPD DB START(ACCESS), UPD DB SET(LOCK(OFF)), or /UNLOCK command on the named database.
/DBDUMP UPD DB STOP(UPDATES)	First secondary index	All databases sharing the secondary index data set	The /DBDUMP or UPD DB STOP(UPDATES) command quiesces activity on all the indexes in the shared database. The database is then closed and reopened for input only. To undo the /DBDUMP or UPD DB STOP(UPDATES) command, issue a /START or UPD DB START(ACCESS) command on the first secondary index.
/DBDUMP UPD DB STOP(UPDATES)	Subsequent secondary indexes	Only the named database	The secondary index is available for read only. To undo the /DBDUMP or UPD DB STOP(UPDATES) command, issue a /START or UPD DB START(ACCESS)command on the named database.
/DBRECOVERY UPD DB STOP(ACCESS)	First secondary index	All databases sharing the secondary index data set	The /DBRECOVERY and UPD DB STOP(ACCESS) command quiesces activity on all the indexes in the shared database. The database is then closed and stopped. When the /DISPLAY command is issued on the shared secondary index database, the subsequent secondary indexes are shown as stopped or locked only if the /STOP, UPD DB STOP(SCHD), /LOCK, UPD DB SET(LOCK(ON)), /DBRECOVERY, or UPD DB STOP(ACCESS) command was issued. To undo the /DBRECOVERY or UPD DB STOP(ACCESS) command, issue a /START or UPD DB START(ACCESS) command on the first secondary index.
/DBRECOVERY UPD DB STOP(ACCESS)	Subsequent secondary indexes	Only the named database	This command is the same as the /STOP and UPD DB STOP(SCHD) command for the named database. However, the /DBRECOVERY and UPD DB STOP(ACCESS) command works immediately, but the /STOP and UPD DB STOP(SCHD) command allows current work to quiesce. To undo the /DBRECOVERY or UPD DB STOP(ACCESS) command, issue a /START or UPD DB START(ACCESS) command on the named database.