The independent DBH consists of a number of tasks (also called UDS/SQL tasks below):
the master task
one or more server tasks
(whose number is defined by the load parameter PP SERVERTASK)the administrator task
The master task (module UDSSQL) prepares the actual session phase when the DBH is started and performs all the necessary tests for this; it also controls DBH termination.
The master task loads the server task(s) as one or more ENTER jobs on starting the DBH and subsequently terminates them on ending the DBH.
In addition, the master task must perform special functions during the session in order to guarantee that everything runs smoothly.
To be on the safe side you are advised to start the master task in an ENTER job.It is also possible to start the master task interactively. In this case you must make sure that it is never interrupted unnecessarily and that you always enter RESUME-PROG after issuing BS2000 commands.
The server task (module UDSSUB) accepts the request from the communication pool and executes it. It accesses the database via the common pool and transfers data which the application program wishes to write into or read from the database from the communication pool to the common pool, and vice versa. When the server task has finished processing the call, it informs the application program.
The standard inputs and outputs from the server task are processed asynchronously (load parameter PP IO=ASYNC). It is therefore sufficient to start one server task on a monoprocessor system and a maximum of one server task per processor on a multiprocessor system (see section “Optimizing processor utilization with the independent DBH”). These server tasks must then have a correspondingly high priority (see ”RUN-PRIO“ in chapter "Starting DBH" and especially section “Performance-oriented BS2000 settings”).
The database administrator uses the administrator task (module UDSADM) to control the session. Use of the administrator task ensures that the master task can run without interruption and that the database administrator is connected to the session in an easy way (see section “Administration of UDS/SQL via UDSADM”). This form of administration should generally be used.
An area of the communication pool is reserved for each transaction. The following information is stored in this area when a call is processed:
the transaction identifier
the call and its parameters
the data to be transferred
The common pool is a memory area that can be accessed by all UDS/SQL tasks of the DBH. It contains, among other things:
system tables
the system buffer pools and exclusive buffer pools for database pages
The system buffer pools contain a number of 2, 4, or 8-Kbyte buffers, each of which can accommodate one database page. The size of the system buffer pool in Mbytes is determined by the load parameters PP 2KB-BUFFER-SIZE, PP 4KB-BUFFER-SIZE or PP 8KB-BUFFER-SIZE.
For each database, an exclusive buffer pool can be created in addition to the system buffer pools. The size of the exclusive buffer pool can be defined with the load parameter PP DBNAME or the DAL command ADD DB.
Each database page to be processed by a server task is read into a buffer of the corresponding system buffer pool or exclusive buffer pool and remains there until
the session is terminated or
the database is detached with DROP DB or
the buffer is required for another database page.
The server task thus does not need to access the database for each DML call, but can operate in the system buffer pools or exclusive buffer pools.
When SQL is used, there is a UDS/SQL conversation for every SQL application (see chapter “The SQL conversation”), and there are system tables relating to these conversations in the communication pool and in the common pool.
Figure 3: The independent DBH
Processing of a COBOL DML statement by the independent DBH
The following paragraphs outline the processing of a DML statement by the independent DBH using a COBOL program as an example; the following diagram illustrates the processing sequence:
Figure 4: Handling of a COBOL DML statement by the independent DBH
A work area, the record area, is available to the application program through the subschema module. This area is at the same time part of the BASE INTERFACE BLOCK (BIB), which is the interface between UDS/SQL and the database user.The record area of the BIB is used to pass the data associated with a DML statement.The COBOL runtime system places the required parameters for the DML statement into the BIB parameter area.
In a CALL statement, the COBOL runtime system passes the address of the BIB to the connection module.The connection module transfers the BIB to the communication pool, in which an area is reserved for this purpose at the start of a transaction.
This BIB is passed to a server task and processed.
If no server task is available, the BIB must wait until a server task becomes free. The connection module places itself in wait status until the DML statement has been processed.
In order to process the DML statement, the server task accesses the BIB in the communication pool and the buffer pools in the common pool.
If the DML statement is to read data from the database, the server task transfers the data in the buffer pools to the appropriate BIB in the communication pool. Conversely, if the DML statement is to write data to the database, the server task transfers the data in the BIB to the buffer pools.
However, the server task does not write a buffer from the buffer pools back to the database until another database page needs the space in the buffer.If the database page into which the DML statement is to write the data of the BIB or from which it is to read data is not in the buffer pools, a search is made in the specified database for the appropriate database page, which is then read into the buffer pools.
After the DML statement has been processed, the server task activates the user task associated with the transaction, thereby removing the connection module from wait status.
The connection module writes the processed BIB from the communication pool back to the application program.
The connection module returns control to the application program. The application program can now process the data in the record area.
Processing of a CALL DML statement by the independent DBH
The following paragraphs describe the processing of a DML statement using a CALL DML program as an example; the following diagram illustrates the processing sequence:
Figure 5: Handling of a CALL DML statement independent DBH
The role of the SSITAB pool and the connection module UDSCON is explained here.
If the application program is the first CALL DML application program of the current UDS/SQL session, the SSITAB pool is set up by the connection module.
All tasks of the UDS/SQL task family must also attach themselves to the SSITAB pool at this time. If this is accomplished, it will be possible to work with the CALL DML from now until the end of the session. The SSITAB pool remains in existence until the end of the session.
Each application program that works with the CALL DML attaches itself to the pool and checks whether the SSITAB module is already in the SSITAB pool. If this is not the case, an attempt is made to load the SSITAB module dynamically from a library which was assigned with the link name $UDSSSI before the application program was started. For detailed information on the dynamic loading of SSITAB modules, see "Starting DBH" and the “Application Programming” manual, section “Linking, loading and starting a UDS/SQL-TIAM application program”.
Now if the application module issues a DML request at the CALL interface, the request is received by the connection module. The connection module forwards the request to the CALL DML converter, which converts the request into a BIB that UDS/SQL can understand. The connection module then writes the BIB into the communication pool.
This BIB is passed to a server task and processed. If no server task is available, the BIB must wait until a server task becomes free. The connection module places itself in wait status until the DML statement has been processed. Only after this does the application program regain control.
In order to process the DML statement, the server task accesses the BIB in the communication pool and the buffer pools in the common pool.
If the DML statement is to read data from the database, the server task transfers the data in the buffer pools to the appropriate BIB in the communication pool. Conversely, if the DML statement is to write data to the database, the server task transfers the data in the BIB to the buffer pools.
Generally, however, the server task does not write a buffer from the buffer pools back to the database until another database page needs the space in the buffer.If the database page into which the DML statement is to write the data of the BIB or from which it is to read data is not in the buffer pools, a search is made in the specified database for the appropriate database page, which is then read into the buffer pools.
After the DML statement has been processed, the server task activates the user task associated with the transaction, thereby removing the connection module from wait status.
When the BIB has been processed by UDS/SQL, the connection module takes it and passes it on to the CALL DML converter, which converts the results from the BIB to the CALL interface that the user can understand.