Unisys OS 2200 databases

The OS 2200 database managers are all part of the Universal Data System (UDS). UDS provides a common control structure for multiple different data models. Flat files (sequential, multi-keyed indexed sequential – MSAM, and fixed-block),[1] network (DMS),[2] and relational (RDMS)[3] data models all share a common locking, recovery, and clustering mechanism. OS 2200 applications can use any mixture of these data models along with the high-volume transaction file system[4] within the same program while retaining a single common recovery mechanism.[5]

The database managers are implemented as a protected subsystem and are called a procedure from user programs and other subsystems. The implementation as a subsystem means that there is no upper limit to the potential concurrency of activities (threads) executing in the database manager. The thread of each user executes the database manager code but within its protection domain so that misbehaved and malicious programs cannot affect the integrity of the database. This approach also reduces the path lengths and overhead involved as messages do not have to be sent between the caller and the database manager. All communication is through parameters.

This commonality has made it possible for clients to modernize applications moving from language files, to a network database, to a relational database. They can use a mixture of these at the same time in a single program while retaining full recoverability. With all the recovery, clustering, locking, and cache management centralized, applications do not have to deal with those aspects. In OS 2200 locking is generally implicit in the database verbs used. For example, a read-for-update implies setting a certain type of lock and the corresponding update write implies clearing it.

The database managers support access using many common distributed data access protocols and APIs including JDBC, OLE DB, and ODBC. See also Unisys OS 2200 distributed processing.

The heart of the database and transaction system is Integrated Recovery. “Integrated” implies the integration of all data models, the transaction file manager, the transaction scheduler, and the message queues. All activity in all of these areas is journaled (written to the audit trail). The audit trail is managed by the Exec which ensures synchronization for all users.[6]

The Integrated Recovery Utility (IRU) is the heart of the recovery system. It provides database backup synchronized with executing transactions and the audit trails. Transactions and batch applications do not need to be stopped to back up the database. IRU makes that unnecessary. All backups can be performed in a running system. Start-of-backup and complete-backup sentinel blocks are written to the audit trail. IRU uses these blocks and other information on the audit trail to perform the fastest possible recovery operations.

There are three main types of recovery actions. All are designed to work across clustered systems. Short recovery is normally used when an application or system failure necessitates performing recovery. Most transactional updates are not written to the database files on disk until the transaction completes successfully and instead are kept in memory or in a roll-forward file. Recovery then means indicating which transactions were in progress and need to be rescheduled. Transactions that had completed but whose data was not yet written to disk have their data written to the disk files.

Recovery to a point in time is most often used when an application update with errors was inserted in the system or a human mistake has partially corrupted the database. The IRU may be told to simply take all the state back to a previous time.

A full recovery is used when a catastrophic failure has caused loss of some or all of the mass storage holding the database. Affected files are reloaded from the last backup and appropriated updates are applied from the audit trail files.