UL/DB2 internals

From m204wiki
Jump to navigation Jump to search

This topic provides background information about certain aspects of the internal processing done by UL/DB2.

UL/DB2 communication between Model 204 and DB2

Before Model 204 can access DB2, UL/DB2 must:

  • Establish a connection from Model 204 to DB2
  • Create one or more threads on the connection

This connection establishes a communication link between Model 204 and DB2. Within this connection, a thread establishes a two-way path between a Model 204 user and a specific DB2 resource, the application PLAN. Multiple threads can be active within a single connection.

UL/DB2 maintains the thread until the request ends and all changes have been committed or rolled back.

Data and message transfer

Data and status information is passed over these threads between the Model 204 user and DB2.

  • Status information generated by DB2 is returned by the User Language $STATUS and $STATUSD functions
  • Call Attach Facility messages are returned by the $ERRMSG function
  • SQL messages are returned the $DB2EMSG function.

Call Attach Facility

UL/DB2 uses the Call Attach Facility (CAF) to manage the communication between Model 204 and DB2. CAF is an IBM-supplied attachment facility that gives UL/DB2 tight control over the connection between Model 204 and DB2. Using CAF, UL/DB2 monitors and controls the threads connecting Model 204 and DB2. UL/DB2 calls the CAF entry point DSNALI, which gives CAF, and therefore DB2, the appearance of a subroutine.

Accessing DB2

Each time that Model 204 requests access to DB2, UL/DB2 passes program control to DSNALI, a language interface module that is part of CAF. At this point, Model 204 is no longer in control. For this reason, each thread connecting a User Language procedure to DB2 executes under its own Task Control Block (TCB). This TCB is itself a subtask of the Model 204 maintask TCB. This approach avoids having a Model 204 TCB wait for DB2, and provides additional throughput in a multiprocessing environment.

UL/DB2 thread management

UL/DB2 provides no system manager commands to control subtasks. This section describes the thread manager component of the UL/DB2 Interface.

After a Model 204 Online initializes, a subtask TCB can be in one of four states:

  • Available
  • Active, meaning allocated and in use
  • Inactive, meaning allocated, but not in use
  • Dead, meaning unusable

When a user requests DB2 service, the thread manager assigns the next available subtask TCB to the user task. If no subtasks are available, the thread manager searches for subtasks on the inactive queue.

A TCB is on the inactive queue, because the procedure that initially activated it has ended and issued a CLOSE. Because CONNECT processing is expensive, however, no DISCONNECT is issued. Instead, the subtask control block is placed on the inactive queue as the most recently used control block.

If the user requests DB2 services again, and the subtask control block is available, no CONNECT processing is needed, and the user does not have to be revalidated.

If a new user requests DB2 services and no subtask control blocks are free, the thread manager steals a control block from the inactive chain, starting with the least recently used control block. This "stolen" control block address is removed from the user control block of the last active user. A DISCONNECT is requested for this control block, so that a CONNECT request can be driven to validate the new user ID.

Reusing the same control block is particularly useful for APSY subsystems. Even though a CLOSE is issued at procedure end, the next procedure most probably gets the same subtask control block back, and CONNECT processing can be avoided.

However, if the APSY is defined with an AUTOCOMMIT of NO, the subtask TCB is considered active even through procedure end(s). This is necessary, because the normal CLOSE of a DB2 thread causes a DB2 COMMIT. With an AUTOCOMMIT of NO, commit processing is deferred until the user specifies a Model 204 COMMIT. If there is no Model 204 COMMIT, then a DB2 CLOSE with an ABRT is generated to ensure that DB2 does a ROLLBACK.

Recovery and restart

The Call Attach Facility has no abend recovery routines. Instead, Model 204 provides abend exit routines. These recovery routines use tracking indicators to determine if an abend occurs during DB2 processing.

If an abend occurs while DB2 has control, UL/DB2 issues a CLOSE with the ABRT (abort) option. DB2 detects task termination and terminates the thread. The user loses all database changes since the last COMMIT point, and is also restarted. Any subtask that abends cannot be re-used.

During a user restart, if the user subtask control block has an associated subtask, restart releases the subtask back to the pool of free TCBs. This release terminates the DB2 connection with an ABRT request in order to rollback any uncommitted updates. The DB2 transaction is not atomic with the Model 204 transaction. There is no SYNCPOINT functionality.

Using the ACEE

For security processing, RACHECK processing first checks for an ACEE associated with the TCB. If there is none (TCBSENV = 0), RACHECK then checks the ACEE associated with the Address Space Control Block (ASXBSENV). All subtasks TCBs attached at initialization have the identifier `M204' inserted into the TCB in the TCBUSER field. During CONNECT processing, the requestor's user ID is copied into an ACEE, and the address of that ACEE is placed in the TCB at TCBSENV for the DB2 authorization exit to use for validation.

See also

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=UL/DB2_internals&oldid=81806"