Basic concepts of the UDS/SQL database system

UDS/SQL database

A UDS/SQL database contains large amounts of interrelated data. The data in a database is stored in such a way that it is independent of programming functions and can be accessed to optimum effect by a range of different programs, while keeping redundancy to a minimum. The addition of new data and the retrieval, updating or deletion of existing data are closely controlled.

With UDS/SQL, multiple databases can be combined to form a multi-DB system that is processed as a single unit (see also "Database configuration").

Database system

The database system is the sum of all the programs needed to create and maintain the data resources and to retrieve and store data.

Database handler (DBH)

The database handler (DBH), which controls access to the database, is the central component of UDS/SQL. It allows mono-DB operation or multi-DB operation.
The DBH is available in the following two versions:

• independent DBH

• linked-in DBH.

With the independent DBH, database operation is controlled by the following modules:

• UDSSQL

• UDSSUB

• UDSCT for UDS-D.

Each module executes as a separate task. Together, they form the task family of the independent DBH.

The modules have the following functions:

UDSSQL	Master task UDSSQL communicates with the database administrator and initiates, monitors and terminates the session.
UDSSUB	Server task (can be loaded more than once) UDSSUB receives the processing requests from the application programs and returns the results to the appropriate application program.
UDSCT	UDS-D task UDSCT handles the communication functions which are needed to process DML statements from remote application programs.

The linked-in DBH is not an independent program, but is linked into the application program concerned or loaded dynamically at runtime and runs as part of this program. An application program running under a linked-in DBH cannot update a database unless it is accessing it in EXCLUSIVE mode, although any number of linked-in DBHs can have RETRIEVAL mode access to a database. As the linked-in DBH, unlike the independent DBH, operates without task communication, it may produce improved runtimes.

Like the independent DBH, the linked-in DBH has multi-DB capability. The linked-in DBH cannot process SQL statements.

Session

A session is a period in which one or more users can work with the database(s). It begins with the loading of either DBH and ends with the message “NORMAL SYSTEM TERMINATION”. The database configuration for the session is defined by operands entered by the database administrator when loading the DBH or in DAL commands.

Database configuration

When starting the session, the database administrator uses the DBH load parameters to specify which databases are to take part in the session. The databases selected for the session and the environment in which the session is to take place are known as the database configuration.

Every configuration is assigned a name by the administrator. The configuration data is stored in the session log file (SLF) for the duration of the session so that the current database configuration can be restored in the event of a restart.

Transaction

Every database application program must open a transaction with the DBH in order to communicate with a
UDS/SQL database, regardless of the type of DBH used.

A transaction (TA) is a logically related sequence of DML statements that is either processed in its entirety or not at all. For example, a transaction in a COBOL-DML program begins with a READY statement and ends with FINISH.
In mono-DB mode, every READY statement opens a transaction and also the database. Thereafter, the application program can access the opened database any number of times using DML statements. In multi-DB mode, by contrast, each database needs to be opened independently with a READY statement. Consequently, a transaction in multi-DB mode may include several READY statements, where the first such statement opens the transaction itself.
Once the COBOL-DML application program has issued the DML statement FINISH to terminate the transaction, it cannot access the database(s) again until the following applies:

• In mono-DB operation: a new transaction, and thus the database, is opened by the application program by means of another READY statement.

• In multi-DB operation: a new transaction, and thus a database, is opened by the application program by means of a new READY statement. Note that additional databases may have also been opened within the same transaction by means of further READY statements.

Even an SQL program also only access UDS/SQL databases from within a transaction In SQL programs, a transaction begins with the first SQL statement that differs from COMMIT WORK and ends with the SQL statement COMMIT WORK.

Conversation

In an SQL application, SQL-specific administrative data is maintained beyond transaction boundaries.
Each such administrative unit is called a conversation.

In openUTM such an administrative unit is also called a service.