Request Blocked GETIT Support

Learn to request blocked GETIT support with Datacom VSAM Transparency.

Parameters Controlling Required Resources

Records are stored on disk in blocks; the number of records which fit into a block is determined by the maximum record length, compression, slack, and the physical block size of the area, that is, the BLOCK-SIZE parameter of the AREA occurrence. When MUF retrieves records from disk, it retrieves them in blocks. Whether one block or multiple blocks are retrieved at one time is determined by the number of buffers available to receive the transferred records. Each sequential buffer can hold exactly one block of records. Exactly half of the available sequential buffers are filled during each blocked transfer.
The MUF region uses two types of buffers: buffers used for non-GETIT type processing (DATANO), and sequential buffers used for GETIT type processing. Your specification of SEQBUF= determines the number of sequential buffers that are used when processing the current table in GETIT mode.
If blocked GETIT processing is not used or if blocked GETIT is used with
SEQBUF=
2
, only one block of records is retrieved at a time. If blocked GETIT is used with
SEQBUF
>
2
, multiple blocks are retrieved at a time. The exact number that is retrieved is one-half the value you specify for
SEQBUF=
in the VSAM Interface Table. If many tables are being concurrently processed in GETIT mode, the
SEQBUF=
parameter determines the number of sequential buffers available to each table. The
GETITMX=
parameter specifies the maximum number of converted files in one job step that can run concurrently in GETIT mode. Whenever
GETIT=
YES
is specified for a table being opened,
GETITMX=
is evaluated to determine whether GETIT resources are available.
GBMAXR=
specifies the maximum number of records that can be transferred in a group from the MUF region to the RWTSA (Read/Write Task Save Area), and from there to the Transparency's GETIT buffer. The size of the Transparency's GETIT buffer is determined by
GETBLK=
. The value that is specified for
EXCTLNO
in the
Datacom/DB
MUF startup options establishes the upper limit for the number of records
Datacom/DB
can hold simultaneously under primary exclusive control for all tables being updated within a task. During update processing, the maximum number of records that are allowed in the blocked GETIT buffer, which is specified by
GBMAXR=
, is the maximum number of records
Datacom/DB
can hold simultaneously under primary exclusive control for this converted table. During update processing, the value for
GBMAXR=
must be accommodated by the limit that is assigned through EXCTLNO. For example, consider three tables—AAA, BBB, and CCC—where AAA and BBB each have one record that is held under exclusive control when CCC begins update processing in GETIT mode. If
EXCTLNO
10 is specified,
GBMAXR=
can be no greater than 8 if the update processing is to be implemented successfully.
The valid values for
STRNO=
, the parameter for specifying the maximum number of strings, depends on whether the programs using the current VIT definition are requesting blocked GETIT resources to do read-only processing or to update the file. A file with
STRNO
>
1
does not qualify for GETIT access in update mode. A file may use multiple strings with blocked GETITs if processing for read-only.

Assumptions for Comparison Example

To simplify comparisons between sequential processing with and without GETIT support, let us assume that processing is done on the Native Key, that records are loaded in Native Key sequence, and that processing is forward. (GETIT support is not recommended when processing a file backward sequentially.)

Sequential Processing without GETIT Support

When the Transparency handles requests to process a converted file sequentially
without
GETIT support, the following single block-at-a-time retrieval and single record-at-a-time data transfer are used:
  1. When the Transparency requests the first record from
    Datacom/DB
    , the following processing occurs:
    1. MUF retrieves the block of records containing the requested record from disk and transfers it to a regular data buffer.
    2. Datacom/DB
      transfers the requested record to the user work area in the Transparency region/partition.
  2. To retrieve each sequential record, the Transparency makes a separate request through
    Datacom/DB
    Interface (DBINFPR) to MUF. Processing varies as follows depending on whether the requested record is in core:
    • If it is,
      Datacom/DB
      transfers it to the user work area without a Data I/O, that is, without an Execute Channel Program (EXCP).
    • If it is not, MUF transfers the correct block from disk to a buffer, then transfers the requested record to the user work area. (If the requested record is not found, the appropriate return code is returned.)
  3. The record-at-a-time transfer that is described in step 2 in Sequential Processing without GETIT Support is repeated until the last requested record in the current series is processed.

Sequential Processing with GETIT Support

When the Transparency handles requests to process a converted file sequentially with GETIT support, the following multiple blocks-at-a-time retrieval and multiple records-at-a-time data transfer are used:
  1. When the Transparency issues the first blocked GETIT request to
    Datacom/DB
    , the following processing occurs:
    1. In general, MUF retrieves one block (if
      SEQBUF=
      2
      ) or multiple blocks of records (1/2 the
      SEQBUF=
      value) from disk and transfers each block to a separate sequential buffer. This retrieval uses chained I/O techniques to minimize the number of EXCP calls to the operating system.
    2. MUF transfers a group of records beginning with the first requested record in the first sequential buffer to the RWTSA. The number of records in the group is as many as can fit into the GETIT buffer of the Transparency, of
      GETBLK=
      size, but not more than the number specified by
      GBMAXR=
      .
      When MUF moves the first record from the first half of the sequential buffers to the RWTSA, it performs another multiple block I/O transfer. This transfer fills the second half of the sequential buffers. If the move to the RWTSA transfers records from the second half of the sequential buffers to the RWTSA, MUF retrieves the correct number of blocks from the disk and overwrites the records in the first half of the sequential buffers. MUF performs as many extra data I/Os as are needed to fill the GETIT buffer.
    3. Datacom/DB
      transfers all records from the RWTSA to the Transparency's GETIT buffer in the address space of the application.
    4. Datacom/DB
      Interface (DBINFPR) transfers the first record from the Transparency's GETIT buffer to the work area of the user.
  2. When the Transparency issues each subsequent GETIT request, the following processing takes place:
    1. If the GETIT buffer is not exhausted, DBINFPR moves the next record to the work area of the user.
    2. If the last record in the GETIT buffer has already been processed, DBINFPR passes the request to MUF. MUF fills the RWTSA with the next group of records. If filling the RWTSA requires one or more I/Os to disk, those multiple block transfers of records are made. When the RWTSA is filled,
      Datacom/DB
      transfers its contents to the GETIT buffer of the Transparency. DBINFPR then moves the requested record to the user work area.
  3. Step 2 in Sequential Processing with GETIT Support is repeated until the last requested record is processed.

Impact of GETITs on Performance

When you compare the difference between sequential processing with and without blocked GETIT support, consider:
  • Data I/Os are conserved when the transfer of records from disk to MUF buffers is accomplished multiple blocks at a time as opposed to one block at a time.
  • SVCs or other communication resources are conserved when the transfer of records from MUF buffers to the program address space is accomplished multiple records at a time as opposed to one record at a time.
Conservation of Data I/Os and conservation of the transfer events which are related to moving records across region or LPAR boundaries increases operating efficiency.
When you specify blocked GETIT support in the VIT, you are requesting use of the group-at-a-time method for transferring records to be sequentially processed from the MUF region using an RWTSA to the Transparency-controlled buffer in the application's address space. When you specify SEQBUF > 2 in the VIT, you are requesting that the transfer of records from disk to sequential buffers be accomplished multiple blocks at a time in the Multi-User address space.

Conditions for Allocating GETIT Resources when GETIT=YES

Specifying
GETIT=
YES
in the VSAM Interface Table does not guarantee that blocked GETIT resources are allocated; it simply requests that the Transparency make an evaluation to determine eligibility from its standpoint and, if all prerequisites are met, that
Datacom/DB
do the same. If all prerequisites evaluated by both the transparency and
Datacom/DB
are met, blocked GETIT resources are allocated. When the Transparency processes the VSAM OPEN request to a converted file, it evaluates the processing options that are specified in the file's ACB and in the file's
DBVUFIL
macro in the VSAM Interface Table. The Transparency also examines the current utilization of resources. The Transparency requests blocked GETIT resources from
Datacom/DB
for processing the tables that are converted from the file being opened only under the following conditions:
  • Blocked GETIT resources are requested using the
    GETIT=
    YES
    in the
    DBVUFIL
    macro.
  • If
    BASE=
    YES
    ,
    GETIT=
    YES
    is valid only if
    MDB=
    NO
    .
  • If
    BASE=
    NO
    ,
    GETIT=
    YES
    is valid only if
    AIXDUP=
    NO
    .
  • The number of currently active tables using the GETIT resource is smaller than the number specified as
    GETITMX=
    in the
    DBVUEND
    macro.
  • The file's ACB includes
    MACRF=
    SEQ
    , that is, sequential processing is permitted.
  • If the ACB specifies output access, no other ACB is open for output against the same
    Datacom/DB
    table and the maximum string number that is specified in the
    DBVUFIL
    macro is 1, that is, either by
    STRNO=
    1 or
    STRNO=
    ACB
    , where the ACB specification is for one string.
Upon receipt of the Transparency's request for blocked GETIT resources, MUF tries to obtain the resources that are requested for blocked GETIT processing.
  • Obtain the necessary memory for more buffers, based on the number you have indicated by the specification of the
    SEQBUF=
    parameter.
  • Compare the size of the work area allocated for the RWTSA (Read-Write Task Save Area), using the value that is specified for
    size
    in the
    TASKS
    MUF startup option, with the size of the blocked GETIT buffer indicated by
    GETBLK=
    in the VIT. If the
    size
    is not greater than or equal to
    GETBLK=
    , the
    Datacom/DB
    OPEN request fails and the program is terminated.
  • If the memory for more buffers is successfully obtained and the buffer space that is reserved by the value that is specified for
    size
    in the TASKS MUF startup option is sufficient to meet the requirement indicated by
    GETBLK=
    , MUF opens the URT and begins processing the table in GETIT mode.
If the table is to be updated, as opposed to read-only, all records that are transferred to the RWTSA are placed under exclusive control. If the limit specified for
EXCTLNO
(in the MUF startup options) is exceeded during this process, the request fails.

GETIT Processing in Update Mode

The Transparency interprets the ACB specification
MACRF=
OUT
as the file being eligible for update processing. If the ACB specifies
MACRF=
OUT
, a file with
STRNO
> 1 does not qualify for GETIT access. For restrictions applicable to GETIT processing in update mode, see Program Restrictions.
When the Transparency is using blocked GETITs to update a table, it rejects any attempt to open that file for update using a second ACB because a
GSETL
which would be issued for one of the ACBs would result in the release of exclusive control for all records of the table, including the ones held under exclusive control for the other ACB.