Control block interrelationship diagrams

Online system contents directory (SCD)

The following graphics show the online system contents directory.

Figure 1. Online system contents directory (SCD) Part 1 of 6

• Note 1: See Figure 8 and Figure 10.

Figure 2. Online system contents directory (SCD) Part 2 of 6

Figure 3. Online system contents directory (SCD) Part 3 of 6

• Note 1: See Figure 13.
• Note 2: See Figure 8.

Figure 4. Online system contents directory (SCD) Part 4 of 6

Figure 5. Online system contents directory (SCD) Part 5 of 6

Figure 6. Online system contents directory (SCD) Part 6 of 6

DFSPRPX0–parameter blocks

The following figure shows the parameter blocks for DFSPRPX0.

Figure 7. DFSPRPX0–parameter blocks

• Note 1: See Figure 1
• Note 2: See Figure 18
• Note 3: See Figure 23

DL/I OSAM buffer pool

The following figure shows the control blocks for DL/I OSAM buffer pool.

Figure 8. DL/I OSAM buffer pool

Sequential buffering control blocks

The following figure shows the sequential buffering control blocks.

Figure 9. Sequential buffering control blocks

Notes to Figure 9:

1. SCD is the IMS systems content directory.
2. SBSCD is a sequential buffering extension to the SCD.
3. SBHEs are sequential buffering hash entries located within the SBSCD (sequential buffering extension to the systems content directory). IMS uses SBHEs to:
   • Anchor the sequential buffering extension to the DCB (SDCB)
   • Serialize the SDCB and SDSG subsystem chains (defined in notes 4 and 8).
4. SDCB is a sequential buffering extension to the data communication block. There is one SDCB for each data set that is actively being sequentially buffered. There must be a separate SDCB for each SBPST that references a HALDB partition, because information in the SDSG will change as the DL/I calls go from partition to partition. As a result, multiple SBPSTs cannot share an SDCB, as is possible for non-HALDB databases. For HALDB, there is one SDCB for each partition used by a PST. IMS uses each SDCB to anchor any sequential buffering SDSGs that have buffer pools allocated to them.
5. The chains of SDCBs and SDSGs anchored in the SBHEs are called the SDCB and SDSG subsystem chains.
6. The program specification blocks, DBPCBs, job control blocks, and the data set group control blocks in the figure are DL/I control blocks.
7. EDSG is a sequential buffering extension to the DSG. The field EDSGSDP points to the SDSG if the data set group control block is potentially buffered by SB. If the DSG is not potentially buffered (but another DSG for the same data set and same application is), then the field EDSGSDPR points to one of the SDSGs of these other DSGs.
8. SDSG is a sequential buffering extension to the data set group control block. The SDSG is present if the user wants to have the DSG sequentially buffered. The SDSG is the control block that controls one sequential buffering buffer pool.
9. SRAN is a sequential buffering control block that describes references in one set of recently referenced consecutive data set blocks.
10. SBUF is a sequential buffering control block that describes one individual buffer.

Buffer handler pool (VSAM)

The following figure shows the buffer handler pool (VSAM).

Figure 10. Buffer handler pool (VSAM)

OSAM DECB with IOB in use

The following figure shows the OSAM DECB with IOB in use.

Figure 11. OSAM DECB with IOB in use

OSAM IOB pool showing available IOBs

The following figure shows OSAM IOB pool showing available IOBs.

Figure 12. OSAM IOB pool showing available IOBs

Storage allocated using the ICREATE/IDESTROY macros is obtained from the MAIN (WKAP) pool. The control block relationship for the MAIN pool is shown in Figure 13.

Storage management control block relationships created for the MAIN pool

The following figure shows storage management control block relationships created for the MAIN pool.

Figure 13. Storage management control block relationships created for the MAIN pool

Storage management control block relationships for preallocated storage blocks

The following diagram shows the control block relationships for those pools managed by the DFSISMN0 Storage Manager.

Figure 14. Storage management control block relationships for preallocated storage blocks

Figure 15 shows the control block relationship for pools managed by the DFSPOOL Storage Manager. Each pool consists of zero or more noncontiguous storage blocks anchored off a pool header. By obtaining new blocks and releasing unused blocks, you can expand and contract a pool as needed during the execution of IMS.

Each block is divided into a number of fixed-length buffers that are used to satisfy storage requirements. The size and number of buffers can vary from block to block within a pool. Each block also has a block header which contains various information on the block

Each pool can be allocated with a maximum of thirty-two different buffer sizes. The pool header contains a noncompressible block pointer and a compressible block chain anchor for each buffer size available.

The pool header also contains an oversized block chain anchor. If the request size is larger than the largest buffer size available, a block is obtained containing a single buffer of the requested size. Blocks obtained in this manner are placed on the oversized chain. The intention of the oversized chain is to allow for exceptional requests, since normal processing should not need any oversized buffers.

The first block allocated for each buffer size is referred to as the primary block. The number of buffers contained within the primary block can vary from any secondary blocks of the same buffer size. If the primary block is obtained when the pool is allocated, it is held until IMS termination. Because it cannot be compressed, serialization logic is not required when allocating or releasing a buffer from one of these blocks.

If the primary block is not obtained until the first GET request, it along with any secondary blocks are placed on the compressible block chain anchored off the pool header. Serialization logic must be used when scanning the blocks on the compressible chains.

An 8-byte prefix and an 8-byte suffix is added to each buffer. The prefix and suffix are used by the Storage Manager exclusively. The size of the prefix and suffix is included in the current pool size.

The buffer size used to satisfy an incoming request is determined on a best fit basis. Unless the size of the buffer requested is the same size as the actual buffer, there is some unused storage between what the caller views as the end of the buffer and the actual end of the buffer. The buffer the user receives appears to be of the size requested. Any unused space is transparent.

The following pools are defined with user overlay detection: AOIP, CIOP, CMDP, DYNP, EMHB, HIOP, LUMC, LUMP, and SPAP. If a pool is defined with user overlay detection, an 8-byte constant is added to the user portion of the buffer. As far as the caller is concerned, the length of the buffer received is the length requested, followed by an 8-byte constant. For example, if a caller requests a 100-byte buffer from a pool with a user overlay detection, and the smallest buffer size available to satisfy the request is 128 bytes, the user overlay detection constant is placed at an offset of 100 bytes into the buffer. Bytes 107 through 127 are unused.

The user overlay detection constant is used by IMS modules. The Storage Manager does not look at the user overlay detection constant.

Storage management control block relationships (DFSPOOL pools)

The following figure shows storage management control block relationships (DFSPOOL pools).

Figure 15. Storage management control block relationships (DFSPOOL pools)

Storage management control block relationships (DFSCBT00 pools)

The following figure shows the Storage Management (DFSCBT00 Pools) control blocks relationships.

Figure 16. Storage management control block relationships (DFSCBT00 pools)

Database Manager control blocks for a representative database

The following figure shows the Database Manager control blocks for a representative database.

Figure 17. Database Manager control blocks for a representative database

Note the following HALDB differences for Figure 17:

• The SDBs pointer to the DDIR always points to the HALDB Master's DDIR.
• The PSDBs are under the HALDB master DMB in the DMB pool. The partition DMBs do not contain PSDBs.
• There is no separately defined DDIR or DMB for the primary INDEX database of a PHIDAM. Instead there is an additional AMP in the partition DMB for the primary index.
• There is an ILE DSG for the ILDS which follows the Delete/Replace DSG.

Database control blocks

The following figure shows the relationships between database control blocks.

Figure 18. Database control blocks: Part 1 of 2

See the notes that follow Figure 18.

Figure 19. Database control blocks: Part 2 of 2

Notes to Figure 18:

1. See Figure 1.
2. See Figure 7.
3. This is a unique HALDB control block. This control block points the partition DDIR to each other and points the partition DDIR to the master DDIR.
4. For HALDB, the SDB points to the Master DDIR.

Diagram of a Data Management Block (DMB)

The following figure shows a diagram of a Data Management Block (DMB).

Figure 20. Diagram of a Data Management Block (DMB)

Note to Figure 20: For a HALDB, dual DMBs exist in storage. When HALDB Online Reorganization is not in progress, one DMB is active and the other inactive. When HALDB Online Reorganization is in progress, both DMBs are active, with one DMB representing the input data sets, and one DMB representing the output data sets.

Overview of Fast Path control blocks

The following figure shows an overview of Fast Path Control Blocks.

Figure 21. Overview of Fast Path control blocks

Relationships between buffer control blocks for Fast Path databases

The following figure shows the relationships between buffer control blocks for Fast Path databases.

Figure 22. Relationships between buffer control blocks for Fast Path databases

GSAM control block overview

The following figure shows a GSAM control block overview.

Figure 23. GSAM control block overview

GSAM control blocks

The following figure shows the GSAM control blocks.

Figure 24. GSAM control blocks

DL/I control block relationships

The following figure shows the DL/I control block relationships.

Figure 25. DL/I control block relationships

Notes to Figure 25:

1. The FSBLIST contains pointers to the Field Sensitivity Block (FSB). The FSB describes this user's logical use of the sensitive field.
2. A partition HALDB DMB is not in the DMB pool. For HALDB, only the Master DMB is in the DMB pool.

IMS Transaction Manager control blocks

The following figure shows the IMS Transaction Manager control blocks.

Figure 26. IMS Transaction Manager control blocks

Intersystem communication control block structure

The following figure shows the intersystem communication control block structure.

Figure 27. Intersystem communication control block structure

VTCB load module

The following figure shows the VTCB Load Module.

Figure 28. VTCB load module

As illustrated in the following figure, IMS maintains a VTAM® terminal control block (VTCB) for each VTAM terminal except MSC VTAM terminals. A VTCB can contain a:

• Communication line block (CLB)
• Communication terminal block (CTB)
• Communication restart block (CRB)
• Communication interface block (CIB)
• Device-dependent module (DDM) work area
• Communication terminal table (CTT) (used only for ETO terminals)

The system of pointers between blocks within a VTCB is the same as the system of pointers used for VTAM terminals.

Some terminals do not require all six blocks. For example, static VTAM blocks use a statically created CTT.

You can find the VTCB for a terminal through the terminal's node name. To do so, you use the DFSCBTS macro interface.

Multiple Systems Coupling (MSC) control block overview

The following figure shows the Multiple Systems Coupling (MSC) control block overview.

Figure 29. Multiple Systems Coupling (MSC) control block overview

Multiple Systems Coupling (MSC) main storage-to-main storage control block overview

The following figure shows the Multiple Systems Coupling (MSC) Main Storage-to-Main Storage control block overview.

Figure 30. Multiple Systems Coupling (MSC) main storage-to-main storage control block overview

z/OS storage map showing IMS-to-IRLM interrelationships

The following figure shows a z/OS® storage map displaying IMS-to-IRLM interrelationships.

Figure 31. z/OS storage map showing IMS-to-IRLM interrelationships

Notes to Figure 31:

1. (a), (b), and (c) are z/OS address spaces that make up one online IMS subsystem.
2. (d) is a z/OS address space containing an IMS batch subsystem.
3. (e) is an IRLM address space to which the two IMS subsystems are connected.
4. The RLPLs used by both IMS subsystems reside in the z/OS common services area (CSA).
5. To obtain and release global locks, the IMS subsystems branch to the IRLM code (The subsystems enter the IRLM code through the RLMREQ branch vector within the RLMCB that resides in the CSA.)
6. The IRLM control block structure that controls the global locks resides in the CSA.
7. When PC=YES is in effect, the RHT is in a private address space.

IRLM overall control block structure

The following figure shows the overall control block structure of IRLM.

Figure 32. IRLM overall control block structure

IRLM storage manager pools

The following figure shows the IRLM Storage Manager pools.

Figure 33. IRLM storage manager pools

IRLM lock request examples

The following figure shows examples of IRLM lock requests.

Figure 34. IRLM lock request examples

Control block overview of Database Recovery Control (DBRC)

The following figure shows an overview of the Database Recovery Control (DBRC) control blocks.

Figure 35. Control block overview of Database Recovery Control (DBRC)

Organization and basic linkages: DOF (Device Output Format) and MOD (Message Output Descriptor)

The following figure shows the organization and basic linkages of Description Output Format (DOF) and Message Output Descriptor (MOD).

Figure 36. Organization and basic linkages: DOF (Device Output Format) and MOD (Message Output Descriptor)

Organization and basic linkages: DIF (Device Input Format) and MID (Message Input Descriptor)

The following figure shows the organization and basic linkages between Device Input Format (DIT) and Message Input Descriptor (MID).

Figure 37. Organization and basic linkages: DIF (Device Input Format) and MID (Message Input Descriptor)