How Datacom VSAM Transparency Works with Batch Processing
Learn how Datacom VSAM Transparency works with batch processing.
The following discussion assumes that the
Datacom VSAM Transparency
Subsystem(s) have been activated as described in Activating the Transparency. When activated, the Datacom VSAM Transparency
Subsystem gets control.Job Step Processing
When the job step being executed contains DD statements which specify a
Datacom VSAM Transparency
Subsystem with the SUBSYS=
parameter, the subsystem processes as follows:- Edits the DD statements containing theSUBSYS=parameter to ensure that there are no syntax errors.
- Verifies that the job step includes a DD statement that names the Transparency's model VSAM file.
- Loads the VSAM Interface Table that is specified in the DD statements.
- Loads the Request Processor (DVVUPPR/DVV2PPR).When a batchDatacom VSAM Transparencymodule loads another batchDatacom VSAM Transparencymodule or table, the version and release number of the loading module is compared to that of the loaded module. If they are not the same, an error message is issued to the operator (system console) and batchDatacom VSAM Transparencyprocessing is terminated.
- Interprets the OPEN request and marks the file open from the application's point of view.
- Ensures that all subsequent action requests for this file are automatically routed to the Request Processor.
- Issues aDatacom/DBcheckpoint at each CLOSE request unlessCLOSE=DEFERis specified with theSUBSYS=parameter.
Such a checkpoint affects only
Datacom/DB
processing under Datacom VSAM Transparency
control; other Datacom/DB
processing within the job step is not
affected by this Datacom/DB
checkpoint.Pre-MUF Request Handling
At the receipt of the first action request, the Request Processor processes as follows:
- Edits the syntax of the VSAM request to determine whether it conforms to VSAM standards and is supported byDatacom VSAM Transparency.For example,Datacom VSAM Transparencyuses the position plus length of the key defined closest to the record end as the standard for the minimum record length with which it compares all read and write requests. Any attempt to write a record shorter than the minimum length is rejected.Datacom VSAM Transparencyuses the base cluster and path definitions to build a chain linking the base cluster to all of its unique paths. When processing a request to add a record to a base cluster possessing a path defined with AIXDUP=NO, the Transparency determines whether the added record violates the requirement for key uniqueness. If it is a duplicate, the Transparency does not add the record, but instead returns the VSAM feedback code that indicates a duplicate key. This processing also applies when a record is updated.
- Generates a User Requirements Table based on VSAM Interface Table processing options, ACB values, and resource availability; issues a request toDatacom/DBto open that User Requirements Table.
- If the VSAM action request is syntactically accurate, issues an OPEN request to MUF, then translates the action request, constructs aDatacom/DBRequest Area using information from the VSAM Interface Table, and gathers the Element List data that are generated during the assembly of the VIT macros.
- If the file is eligible to run in GETIT-mode and criteria (described in Conditions for Allocating GETIT Resources whenGETIT=YES) are met, requests thatDatacom/DBuse blocked-GETIT processing if resources are available.
- If MDB support is required, loads the MDB program (DVMDBPR) and the appropriate MultipleDatacom/DBTable; uses information that is provided there.
- If WF2 support is requested, the resource is allocated if all criteria (described in the section about prerequisites to WF2 Resource Allocation when WF2=YES) are met.
- Transfers theDatacom/DBrequest, including the command, Request Area, Element List, and so on, to the MUF using theDatacom/DBInterface (DBINFPR).
At the receipt of each subsequent action request, the Request Processor simply verifies the syntax, modifies the Request Area if the translated request differs from the preceding one, then transfers the required information to MUF using the
Datacom/DB
Interface.Post-MUF Request Handling
After
Datacom/DB
services the request, the Datacom/DB
Interface passes the results to the Request Processor. The Request Processor translates the results to a form expected by the VSAM application program and routes the results to the source program.Abend Processing without CLOSE=DEFER
When an application program terminates abnormally,
Datacom VSAM Transparency
causes Datacom/DB
to remove the database updates performed since the last CLOSE request if the following requirements are met:
- TXNUNDO=YESis specified in theDBVUSTRmacro in the batch VSAM Interface Table.
- Affected tables are defined inDatacom Datadictionaryfor active logging and recovery.
Application programs which access multiple
Datacom VSAM Transparency
files may issue multiple OPEN and CLOSE requests while updating records. When a transaction backout is active and such a program terminates abnormally, the Datacom/DB
transaction backout function is invoked. When invoked, this function backs out updates to the last Datacom VSAM Transparency
-generated Datacom/DB
checkpoint. If multiple OPENs and CLOSEs are encountered, the status of the file after backout may not match its status at the start of the task.Abend Processing with CLOSE=DEFER
To back out all updates made during a task (and multiple OPEN and CLOSE requests are issued) when the task ends abnormally, code
CLOSE=
DEFER
as an option of the SUBSYS=
parameter in the appropriate DD statement, for example,
//ddname DD SUBSYS=(CAVT,'VUTNM=xxxxx','CLOSE=DEFER'
This ensures that all program-issued CLOSEs to the file which occur before the task ends are treated as logical rather than physical and that the physical CLOSE is deferred until the end of the task. A logical close marks the file closed but issues no CLOSE or checkpoint request to
Datacom/DB
; a physical close marks the file closed and issues a CLOSE request to Datacom/DB
.Consider, for example, the following sequence within a single program:
- Step 1: File A is opened, updated, closed
- Step 2: File B is opened, updated
- Step 3: File A is reopened, updated, closed
- Step 4: File B is closed
- Step 5: Task ends
In this sequence, the CLOSE requests issued in Steps 1, 2, and 4 are deferred until Step 5. If an abend occurs, all updates that are made during each step of the task are backed out, that is, at the beginning of Step 1 for File A and at the beginning of Step 2 for File B.
Do not specify
CLOSE=
DEFER
in an environment where task termination is through other than the standard linkage conventions (for example, by using the EXIT macro - SVC 3
). Such nonstandard terminations bypass the CLOSE=
DEFER
intercept and result in the transparency's failure to issue a CLOSE request to Datacom/DB
, resulting in SA03 abends.CLOSE Processing
Normally, when your program issues a CLOSE request, the Transparency translates that request to the corresponding
Datacom/DB
command and passes it to the Datacom/DB
Interface, which sends it to the MUF. When the corresponding table is closed in Datacom/DB
, the Transparency returns a code to the VSAM application which indicates that the file has been successfully closed.If you specify
CLOSE=
DEFER
with the SUBSYS=
parameter, the Transparency processes your program-issued CLOSE requests differently. For each CLOSE, the Transparency simply returns a code to the VSAM application indicating a successful close without actually sending a translated request to Datacom/DB
. When the Transparency gets control at the end of the task, it processes all the deferred closes, that is, the Transparency ensures the physical close of all files logically closed within the current task.If the transaction backout is active and you specify
TRBOFE=
YES
in the DBVUFIL
macro for the file being processed, the Transparency does some additional work before acting on any CLOSE request using normal close processing or deferred close processing. This work involves examining the fate of the preceding request to determine if it resulted in a file error other than EOF (or no record found). If no file error occurred, or if the result was simply a EOF (or no record found), the Transparency proceeds with normal or deferred close processing. If a real file error preceded the CLOSE request, the Transparency backs out the updates, produces a special message describing the file error, and terminates processing.