Unisys DMSII

DMSII provided an ISAM (indexed sequential access method) model for data access, transaction isolation and database-recovery capabilities. The database schema was written in the proprietary Data and Structure Definition Language (DASDL). The DASDL source code was compiled with a system utility into a file containing the metadata for the database (known as the description file). A database-utility program would use the database description file to create the remaining components of the database.

Proprietary language compilers (such as COBOL and ALGOL) would use the database description file to create database-related elements in the object code of the compiled program. These compilers used language extensions to provide a more natural interface to the database by the programmer. A number of intrinsic functions were inserted by the compiler to ensure the program and database used the same definition of database structures.

Originally, DMSII maintained a data dictionary that the application programmer referenced in its source code. The source for the data structures was maintained in an ordinary CANDE source file. That source was then compiled with the DASDL compiler, which created the dictionary (description file) if none existed prior. If a dictionary did exist, the new design indicated by the source file was incorporated into the dictionary; the programs to copy the data from the old file structure(s) and write to the new file structure(s) were automatically generated (a database reorganization task). The application programmer merely needed to re-compile his application source (typically COBOL) against the new description file and the programmer could take advantage of new data elements in the structures.

DMSII used the concept of "sets" for data storage. A data set contained rows of data, and could be random or ordered. Since DMSII supported both hierarchical and relational models, a data set could be disjointed or embedded. Table indexes were implemented in index sets, and could be full sets or subsets of the target data set. Subsets could be designated as automatic subsets (with rules to select records from the target data set for inclusion) or manual subsets (which used programmatic interfaces to insert and remove records).

Index sets included ISAM styles (which used field keys to reference records) and bit-vectored sets (which used Boolean representation of set membership if the data set record met conditions defined in the set). Like ISAM, it used sets (indexes where all records were referenced, such as the index in Microsoft Access), subsets (a partial list of records dependent upon a definable condition, e.g. females for a database with a "sex" field) and bitmaps (a set of records meeting a certain condition (true/false) on the data set). Those features achieved considerably faster performance in accessing data, with the small penalty of extra time spent on creating a new record if many subsets were defined.

It was claimed that a network-type database could be built using manual-subset capability. This was risky, since it depended upon user programs to add and remove records in a manual subset. There is a substantial difference between DMSII and relational databases: in DMSII, a record can only be retrieved via an index if the index was designed initially (or after a reorganization which generates a new subset from all the data in the set). In the relational model, this is a runtime operation.

In 1988 Burroughs attempted to make an object-oriented model database known as Infoexec, which was an extra layer atop DMSII. That layer was programmed in Pascal and followed the runtime-selection approach, as the relational model does. Designed by Mike Hammer and Dennis McLeod at the Massachusetts Institute of Technology, it performed poorly.

• LINC 4GL