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:
- When the Transparency requests the first record fromDatacom/DB, the following processing occurs:
- MUF retrieves the block of records containing the requested record from disk and transfers it to a regular data buffer.
- Datacom/DBtransfers the requested record to the user work area in the Transparency region/partition.
- To retrieve each sequential record, the Transparency makes a separate request throughDatacom/DBInterface (DBINFPR) to MUF. Processing varies as follows depending on whether the requested record is in core:
- If it is,Datacom/DBtransfers 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.)
- 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:
- When the Transparency issues the first blocked GETIT request toDatacom/DB, the following processing occurs:
- In general, MUF retrieves one block (ifSEQBUF=2) or multiple blocks of records (1/2 theSEQBUF=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.
- 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, ofGETBLK=size, but not more than the number specified byGBMAXR=.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.
- Datacom/DBtransfers all records from the RWTSA to the Transparency's GETIT buffer in the address space of the application.
- Datacom/DBInterface (DBINFPR) transfers the first record from the Transparency's GETIT buffer to the work area of the user.
- When the Transparency issues each subsequent GETIT request, the following processing takes place:
- If the GETIT buffer is not exhausted, DBINFPR moves the next record to the work area of the user.
- 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/DBtransfers its contents to the GETIT buffer of the Transparency. DBINFPR then moves the requested record to the user work area.
- 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 theGETIT=YESin theDBVUFILmacro.
- IfBASE=YES,GETIT=YESis valid only ifMDB=NO.
- IfBASE=NO,GETIT=YESis valid only ifAIXDUP=NO.
- The number of currently active tables using the GETIT resource is smaller than the number specified asGETITMX=in theDBVUENDmacro.
- The file's ACB includesMACRF=SEQ, that is, sequential processing is permitted.
- If the ACB specifies output access, no other ACB is open for output against the sameDatacom/DBtable and the maximum string number that is specified in theDBVUFILmacro is 1, that is, either bySTRNO=1 orSTRNO=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 theSEQBUF=parameter.
- Compare the size of the work area allocated for the RWTSA (Read-Write Task Save Area), using the value that is specified forsizein theTASKSMUF startup option, with the size of the blocked GETIT buffer indicated byGETBLK=in the VIT. If thesizeis not greater than or equal toGETBLK=, theDatacom/DBOPEN 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 forsizein the TASKS MUF startup option is sufficient to meet the requirement indicated byGETBLK=, 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.