UDS-D is an add-on product for UDS/SQL that enables the processing and administration of UDS/SQL databases in homogeneous BS2000 computer networks.
UDS-D reduces the load on a system by eliminating the fixed association of databases and applications with the same computer. In other words, data can be maintained on the system that is used most often, and other systems can then query or update this data as required. This makes all the data held in distributed databases accessible to both the central offices and the branches of a company, for example.
UDS-D provides unrestricted support for distributed transaction processing with networkwide deadlock recognition and handling using COBOL and CALL DML statements.
UDS-D is easy to use, since the distribution is not visible at the user interfaces. This means, on one hand, that the programmer need not know on which computer specific data is stored and, on the other, that application programs can be used without modifications on all computers on the network.
The main advantages of using distributed databases with UDS-D can thus be summarized as follows:
Implementation of different organizational concepts:
Distributed databases can be used to map decentralized organizational structures. The data is processed at the location where it is generated (decentralization).
Isolated applications can be integrated into a single DB or DB/DC application across multiple systems.
Despite decentralization, the entire data repository can be accessed directly, thus making it easy to support ad-hoc queries and reports, for example.
System bottlenecks can be prevented by adding a further processor.
Availability is increased in the case of system failures.
UDS/SQL can be used in combination with the distributed transaction monitor openUTM-D, both with and without UDS-D.
The following basic differences must be noted in the distribution concepts of UDS-D and openUTM-D:
UDS-D
distributed databases
communication per DML statement
distribution not visible to application program
multi-DB programs compatible with programs for distributed processing
openUTM-D
distributed applications
communication per transaction
distribution visible to application program
Features of UDS-D
UDS-D is characterized by the following features:
Access to multiple database configurations
UDS-D enables application programs to access the databases of multiple mono- or multi-DB configurations. These DB configurations may be located on physically separate hosts that are connected via a network.
The type of distribution used can be customized exclusively to suit the requirements of users and is not subject to any restrictions, but each database should, in principle, be physically located wherever it is most frequently processed. When databases of remote DB configurations are accessed, data is transported via the network, so the response times in such cases will primarily depend on the transmission facilities of the network. Database accesses via the network may therefore be much slower than those for the local DB configuration.
No site-specific restrictions for application programs
The user does not need to know how the databases are actually distributed, and only the names of the subschemas to be processed must be known to the application program. The associated DB configuration and the corresponding host system need not be known.
Application programs can work with databases without knowing to which DB configuration they are connected. In other words, the application programs need not include any distribution-specific information.
DML statements are sent to the DB configuration on the host where the addressed database is located by means of a distribution table.Cross-configuration consistency and deadlock resolution
UDS-D guarantees the logical consistency of all databases involved throughout the network.
If a transaction has updated the databases of at least one remote DB configuration, UDS-D will terminate that transaction only after ensuring that the updates are performed on the databases of all DB configurations involved or on none of the databases. This is achieved by UDS-D by splitting the process of terminating a transaction into two phases, i.e. by means of a two-phase commit. The first phase ensures that all updates of the transaction have been recorded safely, and the second phase then writes the updates to the databases only after the first phase has been successfully completed. This ensures that all updates can either be committed or rolled back at any time on terminating the transaction.
Cross-configuration deadlocks are automatically detected and resolved.