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:
  1. Edits the DD statements containing the
    SUBSYS=
    parameter to ensure that there are no syntax errors.
  2. Verifies that the job step includes a DD statement that names the Transparency's model VSAM file.
  3. Loads the VSAM Interface Table that is specified in the DD statements.
  4. Loads the Request Processor (DVVUPPR/DVV2PPR).
    When a batch
    Datacom VSAM Transparency
    module loads another batch
    Datacom VSAM Transparency
    module 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 batch
    Datacom VSAM Transparency
    processing is terminated.
  5. Interprets the OPEN request and marks the file open from the application's point of view.
  6. Ensures that all subsequent action requests for this file are automatically routed to the Request Processor.
  7. Issues a
    Datacom/DB
    checkpoint at each CLOSE request unless
    CLOSE=
    DEFER
    is specified with the
    SUBSYS=
    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:
  1. Edits the syntax of the VSAM request to determine whether it conforms to VSAM standards and is supported by
    Datacom VSAM Transparency
    .
    For example,
    Datacom VSAM Transparency
    uses 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 Transparency
    uses 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.
  2. Generates a User Requirements Table based on VSAM Interface Table processing options, ACB values, and resource availability; issues a request to
    Datacom/DB
    to open that User Requirements Table.
  3. If the VSAM action request is syntactically accurate, issues an OPEN request to MUF, then translates the action request, constructs a
    Datacom/DB
    Request 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 when
      GETIT=
      YES
      ) are met, requests that
      Datacom/DB
      use blocked-GETIT processing if resources are available.
    • If MDB support is required, loads the MDB program (DVMDBPR) and the appropriate Multiple
      Datacom/DB
      Table; 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.
  4. Transfers the
    Datacom/DB
    request, including the command, Request Area, Element List, and so on, to the MUF using the
    Datacom/DB
    Interface (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=
    YES
    is specified in the
    DBVUSTR
    macro in the batch VSAM Interface Table.
  • Affected tables are defined in
    Datacom Datadictionary
    for 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.