Tasks and run units opened when accessing a non-SQL defined database are handled automatically during the execution of a CA ADS application. Tasks and run units for CA ADS are discussed separately below.
Tasks
A task is a logical unit of work performed by the DC/UCF system that consists of one or more programs.
The CA ADS runtime system executes as a series of tasks within the DC/UCF environment. The first task begins when the user initiates the runtime system, as discussed in Initiating the CA ADS Runtime System. Subsequent tasks begin on mapin from the terminal.
A task terminates when the runtime system performs a mapout operation to the terminal with no errors or when the application terminates. When a task terminates, CA ADS returns control to DC/UCF automatically; the application developer does not code a DC RETURN command.
After a mapin operation, CA ADS determines whether the response entered by the user is valid. If the response is valid, the task continues and the runtime system resumes processing as directed by the response. If the response is not valid, the task terminates and the runtime system performs a new mapout operation with an error message.
Run Units
Communication with the database is established by means of run units. A run unit begins when an application signals its intent to perform database operations and ends when the program releases all database resources from its control. A run unit can consist of any number of CA IDMS/DB database requests.
CA ADS can have 0 to 2 run units open at a time. With SQL access, run units are a physical aspect of data access that is hidden, as the SQL model requires. CA ADS can have a network run unit open and access the database using SQL at the same time.
If a dialog issues non-SQL DML and SQL DML against the same non-SQL defined database at one time, deadlock of the run units is possible.
Establishing a run unit to access the database and extending run units using CA ADS is discussed below.
Transactions
A database transaction is a unit of recovery within an SQL session.
CA IDMS/DB begins a database transaction when the dialog submits an SQL statement that results in access to either user data or the dictionary, and ends a transaction when a COMMIT or ROLLBACK is executed or when the SQL session is terminated.
Note: For more information on transactions within an SQL session, see the CA IDMS SQL Programming Guide. For a list of SQL statements that start and end a database transaction, see the CA IDMS SQL Programming Guide.
|
Copyright © 2014 CA.
All rights reserved.
|
|