Normal Control Interval Improved control Interval
6.3 DEDS CONCEPT
A DEDB is an HD-type data base containing up to eight segment types in a two level data base structure (Figure 39). The possible combinations of segment types are:
• A root segment with a sequential dependent segment with up to six direct dependent segment types.
• A root segment with maximum of seven direct dependent segment types.
ROOT SEGMENT
/ / - - - ,
SDEP or OOEP OOEP
.
DOE?SEGMENT SEGMENT SEGf'1ENT
Figure 39. DEDB Record Structure
R~ot segments and
direct dependent
(ODEP) segments are similar to DL/I data base segments. Retrieve and update calls are a compatible subset of the current DL/I calls. As in HDAM, root segments are chained off a Root Anchor Point (RAP) and a randomizing routine is used to derive a RAP num-ber.Sequential dependent
(SDE?) segments are of a new type that is especially designed to provide fast insert capability. Their intended use is to col-lect data very quickly and insert them in mass in the data base cutting down the number of I/O operations that would normally be required with other data base organizations. Sequential dependent segments can only be inserted and retrie~ed, no update capability is available.Variable length segments are fully supported. Because VSAM ICIP uses User Buffering only, VSAM is not concerned with variable length data. Each eI consists of one logical VSAMrecord, one RDF, and one CIDF.
FP does the. management within the CI'buffers and merely request VSAM to read or write those buffers using ICI processing.
There are several features included in DEDB for optimization processing
an~ extended operation. Described here are those that pertain directly to the use of VSAM ICIP by the Fast Path feature.
6.3.1 Fast
P~thuse of VSAH ICXP
The MVS implementation of the Fast Path feature is based on SRB p~ocessing
which has a significantly shorter path length than TCB processing. TCB processing of the. DEDB is used in the OS/VS1 implementation.
To compensate for the fact that ICIP requests have to be synchronous, the implementation allows multiple parallel requests to take place concur-rently.
Read access to the DEDB is done directly from the dependent regions.
Therefore mUltiple requests can be run in parallel. The unit of allocation is the CI. Thus if there is no contention at the CI level, the level of parallelism that could potentiallY be achieved is equal to the number of dependent regions active in the system.
On the output side, the implementation is different. CIs are not written back in the data base during the life of the transaction but after its successful completion. This has two advantages: first, in case of an ABEND, no backout of the data base is necessary, second, region occupancy is lower.
To free up the dependent region as soon as possible, CIs are transferred to an SRB (MVS) processing called Output Thread that invokes VSAM ICIP.
Multiple Output Thread can be defined up to a maximum of 10 to allow for more parallel processing. Each Output Thread handles all the CIs updated by a single transaction. Because of VSAM ICIP, each CI is written by one request at a time. the DEDB action module is then internally redriven until all the CIs on the Output Thread have been written back. At which time. the Output Thread is made available for further processing.
Because of VSAM ICIP, AREAs cannot be extended. Out-of-space conditions can happen in the root addressable part and in the sequential dependent segment part. Appropriate warnings are sent to the master terminal opera-tor when those conditions arise.
A
/DISPLAY
command and a new data base call (POS) can be used at any timeto 1valuate the utilization of both parts.
The following considerations are mainly concerned with the VSAM aspect of the DEDB data base definition. Discussed are the sizes of
eI
and UOW, fol-lowed by comments on the AREA concept.6.3.1.1 DEDB CI Size
The choice of a CI size depends on the following factors:
• Because of VSAM ICIP. four different CI sizes are supported. A choice must be made between 512, 1024, 2048. and 4096 bytes CI sizes.
• There is only one RAP per CI. The average record length has to be tak-en into account. In the base section of the root addressable part, a CI can be shared only by the roots, which randomize to its RAP and their DDEP segments.
• CSA main storage availability. It should be noted that the largest CI size among all the opened DEDBs sets the size of the f? buffer. There is only one FP buffer pool used for processing all DEDB data bases.
Although C1 sizes can vary between AREACs) and DEDBs, a comoon CI size will save storage space.
If only one AREA is defined with a CI size of 4096 bytes, no matter what the other CI sizes are, the entire buffer pool will be set up with 4096 bytes buffers.
• Track utilization according to the device type.
• Performance of sequential dependent segment writes. A larger CI requires a fewer number of 1/Os to write the same amount of sequential dependent segments.
• The maximum segment size which is 3976 bytes if using a 4096 CI size.
6.3.1.2 DEDB unit-of-Work (UOWl Size
The UOW is the unit of space allocation by which one specifies how large the root addressable and the independent overflow parts are to be.
Three factors might affect the size of the UOW:
• The DEDB Direct Reorganization Utility runs on a UOW basis.
Therefore, while the UOW is being reorganized, none of the CIs and data they contain are available to other processing.
A large UOW could cause resource contention, resulting in increased response time if the utility is run during the online period.
A small UOW could cause some overhead during reorganization as the utility switches from one UOW to the next one with very little useful work each time. But this might not matter so much if reorganization time is not critical.
• Another factor that could affect the size of the UOW is the sequential processing of DEDB using FP non-message-driven regions or BN?
regions. There is a facility known as the processing option 'P' that can be used to speed up sequential processing of DEDB in batch mode.
This facility is directly related to the size of the UOW. Refer to the
FAST PATH FEATURE DESCRIPTION AND DESIGN
GUIDE,G320-5775
for a dis-cussion on this subject.• The dependent overflow (DASD space) usage is more efficient with a large UOW than with a small UOW.