Mixed Page Group Support Implementation

Products

• IDMS
• IDMS - Database

Issue/Introduction

How to implement Mixed Page Group Support.

Environment

Release: All supported releases.

Resolution

Mixed Page Group Support is a feature of IDMS that allows a single run-unit to access data residing in areas defined to different page groups. This facility allows larger databases to be created than would normally be able to be defined within a single page group resulting in the elimination of any practical software limitations on the amount of data that can be maintained within an IDMS database. This document examines how IDMS provides this support and the requirements and considerations that must be observed to implement the facility within an application environment.

What is Mixed Page Group Support?

A page group is an attribute assigned to a database segment when it is defined. All areas defined within that segment are associated with the specified page group. This serves to qualify the page numbers assigned to those areas such that they are unique from page numbers in other segments. Without Mixed Page Group Support, a single IDMS run-unit is limited to accessing only segments that have been defined with the same page group. With the facility enabled, a run-unit can access segments that are defined in any number of page groups.

An additional aspect of this facility is that a single run-unit can also access a database whose segments have been defined with a different maximum for the number of records that can be stored on a page. The maximum number of records per page is frequently referred to as the database area’s radix point. Varying the radix point for areas that contain large numbers of very small or very large record types provides a method for storing more records within their areas. Just like a page group, the radix point is common for all areas defined within a segment and it is highly recommended that all segments with the same page group have the same radix point.

A standard radix point allows 255 records per database page which means that the areas defined within the control of a page group are able to contain approximately 16 million pages. Up to 32,767 page groups can be defined, so Mixed Page Group Support significantly increases the size of a database that is accessible by a single run-unit.

IDMS determines which page group to access based upon the record, area, or set name specified on the DML command passed to the DBMS. The only time the DBMS cannot identify a proper page group is when an unqualified dbkey command is issued. Unqualified means that no record name has been coded on the command. When this type of command is issued in a mixed page group environment, IDMS assumes the page group to be the same as the one accessed by the previous DML command. It is recommended that these commands not be used in applications utilizing Mixed Page Group Support to avoid the possibility of accessing an incorrect page group.

How is Multiple Page Group Support implemented?

Enabling Multiple Page Group Support is a very simple matter. For non-SQL defined databases, all that is required to enable the feature is the addition of a single clause to the DBNAME’s definition indicating that Multiple Page Group Support is allowed. In the following example the feature is being enabled for a DBNAME called MPGDB.

CREATE DBNAME R190DBTB.MPGDB
    MIXED PAGE GROUP BINDS ALLOWED
    INCLUDE SEGMENT MPGSEG
    INCLUDE SEGMENT SYSDICT
    INCLUDE SEGMENT SYSMSG;

Mixed Page Group Support is always ALLOWED for SQL-defined databases.

However before enabling Multiple Page Group Support for a database, some careful planning is required to ensure that the database structure meets certain usage rules. Application program changes may also be required to accommodate any structural modifications made to comply with these usage rules. The usage rules are:

• Chained sets and linked-clustered referential constraints may not cross page group boundaries
• Starting with a mid-release enhancement to Release 18.0 of IDMS, indexes (system and user owned) may cross page group boundaries
• A record type whose occurrences reside in multiple page groups must be processed by multiple run-units
• Unqualified FIND/OBTAIN DML commands should not be issued within mixed page group run-units.

Chain sets and Referential Constraints

Chain sets and referential constraints (both linked and unlinked) may not cross page group boundaries. In other words, all owner and member records for a set must be in the same page group and be defined with the same number of records per page. After determining which areas are to be moved into each page group, the database structure must be examined to identify any of these relationships that cross a page group boundary.     

Chain sets that cross page group boundaries may have to be replaced with a different construct. There are many ways to accomplish this and many of the options require some form of application program change depending on how the programs accessed the original structure and what it is being replaced with. The following two options provide examples of some of the things that can be done to eliminate cross-page group chain sets. Each of these options has advantages and disadvantages that must be evaluated against the processing requirements of the associated application.

Diagram 1 describes a set relationship between the ORDER and ITEM records where the ORD-ITEM set has an order of SORTED and the owner of the set has a location mode of CALC. To place the ORDER-AREA and ITEM-AREA in different page groups, the ORD-ITEM set must be replaced with some other construct.  

One way to deal with the ORD-ITEM set is to replace it with a single system-level index that resides in an area defined in the ITEM-AREA page group. If the ITEM records do not already contain the ORDER record’s calc key, that calc key must be added to each ITEM record. The space for this field is inserted into the record using the RESTRUCTURE SEGMENT utility and a user-written program is executed to populate the field in each member occurrence with the corresponding ORDER record occurrence calc key value. The RESTRUCTURE SEGMENT utility is also used to remove the prefix pointer positions from each involved record and add any pointer positions in the ITEM records for the an index UP pointer if necessary. The MAINTAIN INDEX utility is then run to populate the new index. If the new index name is the same as the old set name, the application program changes are minimal and in some cases no changes may be required.

Diagram 2 represents the updated database structure.

A second option for replacing the ORD-ITEM set is to create a ‘stub’ record in the ITEM-AREA that only contains the calc key of the ORDER record and whose location mode is CALC. The ORD-ITEM set is redefined to use this ‘stub’ record as the owner so that the entire set structure is included in the same page group as the ITEM record. Application programs would issue an OBTAIN CALC command on the ‘stub’ record before walking the set to access the members. User-written programs are needed to disconnect the ITEM records from the original ORDER record, store the new ‘stub’ records, and connect the ITEM occurrences to the correct occurrence of the new ‘stub’ record. The RESTRUCTURE SEGMENT utility is used to remove any prefix pointer positions no longer required.  Diagram 3 represents this modified structure.

Indexes

Starting with IDMS Release 18.5, indexes will be able to span page group boundaries. This change will allow those areas used exclusively to hold system-owned indexes to be moved to a different page group and user-owned indexes can be utilized as another option to replace chain sets that cross page group boundaries.

Relocation of areas containing only the index structure (SR7 and SR8 records) of system-owned indexes to an alternate page group from the associated data records is a simple task. This just requires a new segment containing the index area(s) where the new segment is assigned a different page group. These areas are then removed from the original segment definition and the new segment is added to the DMCL and all related DBNAMEs within the DBTABLE. No application changes should have to be made to make this separation.

If a system-owned index resides in the same area as its data records and there is a desire to move these indexes to a different page group, the use of the MAINTAIN INDEX utility would be required to move the index structure to a new area assigned to a different page group. Since a new area will be added to the database it will be necessary to make schema and subschema changes to identify the area. Application changes may also be necessary to include the appropriate READY statements for the new area(s) where programs ready areas individually.

User-owned indexes will also be available to replace chain sets that span different page groups. The problem of the chain set in Diagram 1 was dealt with by removing the ORD-ITEM set between the ORDER and ITEM records and adding a construct within the page group into which ITEM-AREA was moved. In both of the examples presented earlier, a significant amount of application changes would be required to implement the suggested changes. By changing the ORD-ITEM set to a user-owned index as indicated in Diagram 4, areas ORDER-AREA and ITEM-AREA could be moved to different page groups with no application changes. 

To change the ORD-ITEM set from a chain set to a user-owned index would involve the use of the RESTRUCTURE SEGMENT utility to make any necessary pointer changes in the prefixes of the ORDER and ITEM records. MAINTAIN INDEX would also be necessary to efficiently build the index structures for each occurrence of an ORDER record within the ORDER-AREA. It should be noted that the processing of user-owned indexes by MAINTAIN INDEX does require a user-written program to extract the data necessary to build the indexes and to interface with the MAINTAIN INDEX utility.

An additional consideration to employing user-owned indexes to replace chain sets is an increase in the amount of space required within the owner’s area. The SR8 records used to support the index structures are stored VIA the owner of the sets. In this example, each occurrence of an ORDER record will have an additional cluster of SR8 records added within the ORDER-AREA. Therefore, it may be necessary to increase the size of the ORDER-AREA using the UNLOAD/RELOAD, DB-REORG, or REORG utilities during the conversion process.

Record Types Spanning Page Groups

 A second usage rule that must be observed is that a record type may only reside in one of the segments processed by a single run-unit regardless of whether Mixed Page Group Support is in effect. This is typically not a problem when trying to take a database that has existed within a single page group and is being broken across multiple page groups to allow access to more pages but is a significant consideration when trying to implement a segmentation strategy for increasing the amount of data that currently resides in a single area.

Although a topic unto itself, database segmentation is where all or a portion of a database structure is replicated and the data is separated based on some logical criteria. For example, a company doing business in Europe and North America may wish to use the same database for keeping track of each of its geographical customer bases. However time-zone differences and processing requirements may dictate that batch processing must be performed for European customers while the online window is still open for North America. A database segmentation strategy replicates those portions of the database dealing specifically with the customer data while sharing those portions of the database that are common for both locations. Those areas making up the common portion of the database are defined in a segment called CUSTCOMM while the Europe specific data is defined by segment CUSTEUR and North America’s data is defined in segment CUSTNA. Segments CUSTNA and CUSTEUR are mirrors of each other in regards to their database structure and differ only in the actual data values stored within each segment. Each of these three segments is assigned their own unique page group.     

Multiple Page Group Support allows segments CUSTCOMM and CUSTEUR or segments CUSTCOMM and CUSTNA to be processed by a single run-unit. This allows batch processing to update the European data while North America is still available for online processing. Since segments CUSTEUR and CUSTNA have the same database structure and therefore the same record types, they cannot be accessed together by a single run-unit. If there is a need to report on their combined data, each segment must be processed by different run-units and if necessary some form of merge processing performed to create the final report.

Unqualified FIND/OBTAIN/ACCEPT Commands

The final run-time usage rule to be considered is the inability of application programs to use an unqualified FIND/OBTAIN DB-KEY or ACCEPT CURRENCY command. An unqualified FIND/OBTAIN DB-KEY or ACCEPT CURRENCY command is one that does not specify a record name or set name. Since IDMS uses the record or set name to determine the proper page group to process, there is no way to ensure that the proper page group will be accessed. The PGINFO parameter is available to the FIND/OBTAIN DB-KEY commands to provide IDMS with the proper page group to process. Applications need to be modified to add this parameter to all occurrences of these unqualified commands or they can be replaced by a qualified command. Programs using the ACCEPT CURRENCY command must be modified to include a record or set name as part of the instruction.

Exit 34 is available for use with Multiple Page Group Support and can be used to help locate and correct applications that may require modifications to function correctly under the control of Multiple Page Group Support. RHDCUX34 is a sample Exit 34 program provided in an installation’s Distribution Source Library (DISTSRC) and as coded will display a message to the operator’s console when an unqualified FIND/OBTAIN DB-KEY command is detected by the DBMS. The code also has sample code for other options that a site might want to implement when enabling multiple page groups.

Summary

Multiple Page Group Support is a powerful feature of IDMS that allows the size of a database that is accessible to a single run-unit to be almost without limitation. The feature is often used with segmentation to handle large and complex environments. Although simple to enable, it is a feature that requires proper preparation to implement correctly and may involve application developers as well as the site’s DBA.

Additional Information

Page Groups