IMS legacy systems reliably serve the core business processes in many of the world's largest corporations. Indeed, IMS supports a variety of business applications that directly affect customers through automated teller machines, credit card transactions, airline and hotel reservations, package tracking and delivery as well as ordinary financial accounting and billing systems. Web-based applications are enriching their content by tapping into these treasure troves of data. The high availability and performance demands of these types of continuously available applications are ably met by IMS Fast Path structures called Data Entry Databases (DEDBs).

The DEDB's partitioning architecture provides the high storage capacity and operational flexibility necessary for continuous online activity. This enduring quality affords IMS application designers a ready alternative to any artificial partitioning schemes, like IMS 7.1's High Availability Large Database (HALDB), that overlay full function databases. However, DEDB performance benefits come at the expense of efficient space utilization; consequently, DEDBs require vigilant space monitoring because they do not dynamically extend their data sets. If a DEDB area data set should suffer space problems because the overflow or sequential dependent portions have been filled, then the business application will incur an expensive outage.

Resolving a full area condition has historically been a disruptive and protracted process. The conventional procedure of unloading and reloading all of the segment data can easily take more than an hour for even a modestly sized area. This document describes the techniques by which DEDB area data sets can be quickly and efficiently extended using a programmatic solution.

Extending DEDB Data Sets

DEDBs, like all IMS databases, are defined by the Database Description (DBD) control block. The AREA macros are used in the DBD to describe the number, name and size attributes of each area within the database. The UOW keyword specifies the number of root anchor point (RAP) and dependent overflow (DOVF) control intervals (CIs) allocated to a single unit of work (UOW). The ROOT keyword designates the size of the root addressable area (RAA) and the independent overflow (IOVF) in terms of units of work. The sequential dependent (SDEP) portion of an area is the residual space between the reorganization UOW and the end of the area data set. Therefore, the size of the RAA, IOVF and SDEP portions are a function of the UOW, ROOT, and data set allocation parameter values.

Beginning with IMS V3.1 (plus APAR PL72767), the online area open process started to tolerate DEDB areas with DEDB Area Control List (DMAC) CIs that described an IOVF portion that was larger than the actual DBD definition. The IMS Version 7 Administration Guide: Database Manager outlines a fourteen step procedure for extending a DEDB area data set and placing it back online. This procedure describes the necessary steps for modifying the DBD by proportionately increasing the area's ROOT parameter values. The overall size of the RAA cannot change in any way, nor can the dimension of the IOVF be decreased. The size of the SDEP portion can be changed, but should be large enough to accommodate all preexisting segments. After regenerating the DBD and Application Control Block (ACB), the segment data in the area is then unloaded and subsequently reloaded, using the new ACB, into a larger sized area data set. This new area data set is then placed back online without needing to swap control blocks or cycle the entire subsystem. This cumbersome procedure is effective, but chronically error prone, resource intensive and, more importantly, too slow.

Using a Programmic Solution to Extend the Data Set

Extending the area data set with a utility program is a much faster solution for physically increasing the available IOVF or SDEP space within a DEDB area. The extension process only needs to format the enlarged portion of the area data set and update the DMAC to reflect the new size. This programmatic approach completely eliminates the processing overhead of reading and rewriting all of the segment data in the area and limits the I/O activity to just the portion of the area that is changing. These combined factors give this extension process a significant speed advantage over the traditional method.

Extending an area data set for increased SDEP capacity is the simplest of the extension processes (refer to Figure 1). Once the data set extent has been taken, all of the newly addressable space should be properly formatted and written as empty SDEP CIs. The DMAC CI then needs be updated and rewritten to reflect the new physical boundary of the area data set. The field DMACFBAD must be changed to the block number representation of what is now the area data set's new high used relative byte address (RBA). The SDEP segments are frequently found to be in a logically wrapped condition, that is where the logical beginning RBA (DMACXVAL) is greater than the logical ending RBA (DMACNXTS). In this case, the additional space will not be available to the application until after the DEDB Sequential Dependent Delete utility (DBFUMDL0) is run.

Figure 1: SDEP extension

Extending the IOVF portion of an area that does not have a defined SDEP segment is also a rather straightforward process (refer to Figure 2). After the data set extent is taken, a section of the area must be reformatted from the beginning of the old reorganization UOW to the end of the new extent. Because the IOVF size of an area is defined in terms of UOWs, the additional IOVF space can only be increased by multiples of the UOW. As the newly formatted and empty IOVF data CIs are successively written, new space map (SMAP) CIs must also be progressively written at overflow unit intervals (DMACIOUS). The reorganization UOW needs to be formatted and written at the end of the new IOVF portion. Although the DEDB does not have a defined SDEP segment, any residual space between the reorganization UOW and the end of the area data set should be formatted and written as empty SDEP CIs.

Figure 2: IOVF extension with no SDEPs

Once the reformatting process is complete, the formerly last SMAP CI must be revised to encompass any newly addressable IOVF CIs, and then rewritten. The DMAC CI needs to be refreshed and rewritten to show the new physical boundaries and block counts within the area data set. Several of the DMAC fields need to be updated. DMACFBAD must be changed to the block number representation of what is now the area data set's new high used RBA. The number of newly formatted SMAP CIs needs to be added to DMACOUNO. DMACOCNT should include the number of new IOVF data CIs. DMACFROW needs to have the beginning relative block number of the new reorganization UOW. Likewise, DMACFSEQ needs the relative block number of the first SDEP CI. For completeness, DMACXVAL and DMACNXTS should respectively reflect the new SDEP logical beginning and logical ending RBAs.

Extending the IOVF portion of an area with a defined SDEP segment is a hybrid between the two previously described processes (refer to Figure 3). Though this process is technically feasible, the convenience of retaining the SDEP segments in the area will probably forfeit most of the performance benefits. Therefore, running the DEDB Sequential Dependent Scan utility (DBFUMSC0) and deleting the SDEP segments before the extension is recommended. The process starts the same as an ordinary SDEP extension by taking a data set extent and properly formatting and writing empty SDEP CIs to the newly addressable space. If all the SDEP segments had been deleted, then the rest of this extension process would be the same as an ordinary IOVF extension.

Figure 3. IOVF extension with SDEPs

However, if the SDEP segments had been retained, then all of the previous SDEP CIs need to be shifted down to the newly formatted SDEP CIs. The sequential dependent physical twin pointers, in the SDEP segments, need to be recalculated by the size of the IOVF increase. This can be done while the SDEP CIs are being translated, one at a time, from the old physical end (DMACFBAD) back through the old physical beginning (DMACFSEQ). Then the section between the old reorganization UOW (DMACFROW) and the new SDEP physical beginning (DMACFSEQ) needs to be reformatted into valid IOVF data, SMAP and reorganization UOW CIs. The previously last SMAP CI needs to then be revised to include any newly addressable IOVF CIs and rewritten. Now the DMAC CI needs to be updated in the same way as a regular IOVF extension and recommitted. Finally, all the sequential dependent physical child first pointers in the root segment prefixes need to be adjusted by the size of the IOVF increase to reflect the new SDEP segment locations. Given the scope of this type of processing, it is probably furnished better from within a reorganization utility program.

The enhanced speed of extending a DEDB area data set with these basic processes is well worth the programmatic complexity and effort. Furthermore, it avoids the risk of human error when following a manual procedure or generating errant control blocks. Exposing the area data to unintended control block changes is a serious concern because the new area can load successfully and still be rejected or corrupted because of an ACB conflict when the area data set is put back online. Simply adding an extent to the area data set can prevent these problems and minimize the online outage time to only a few minutes.

Once an area data set has been extended, it is always good practice to image copy it before placing it back online. If the extended area data set is registered with Database Recover Control (DBRC) as only one of several Multiple Area Data Sets (MADS), then the companion area data sets must be marked unavailable before this area data set is put back online. After an extended area data set is successfully opened online, IMS changes and logs the in-core DMAC with the extended values. This information persists across warm starts, and IMS will recognize and report the extended area data set every time it is opened. This will continue until a new ACB, with the extended values, is eventually swapped in. If the area data set is ever recovered, reloaded, or reinitialized back to a smaller sized IOVF, then IMS will prohibit that area data set from being placed online. These common problems can be avoided by promptly staging a revised ACB and updating the cluster definition for the area data set.

Applying Extension Techniques Online

If even a minimal application outage is unacceptable, then these extension techniques can also be applied within the arena of the online environment. The DEDB Area Data Set Create utility (DBFUMRI0) already exploits the internal facilities of IMS for formatting multiple DEDB area data sets. A modified IMS Fast Path (IFP) dependent region can perform a DEDB area extension by utilizing those facilities in conjunction with the full complement of locking, logging, communication, and I/O services that are at its disposal. Features such as Block Level Sharing (BLS) require careful control block coordination between all sharing partners. The locking requirements and recovery hazards of extending the IOVF portion of an area with a defined SDEP segment make this kind of extension a practical impossibility.

Continuous availability during an online extension does come with a price. During the execution of the utility, all application access to the affected area will use UOW level locks. This higher level of locking can lead to greater resource contention and a corresponding reduction in transaction response time. Also, note that the entire portion of the area extension will be wholly logged. This is required for recovery purposes, but the extra logging activity can degrade the throughput of the entire subsystem. Because of the added overhead costs, online extensions will run noticeably slower than their batch counterparts. If these restrictions and costs are worth the premium of continuous availability, then online extensions can be an attractive alternative.

Conclusion

IMS legacy systems will remain as established cornerstones of corporate data processing for some time to come. Accordingly, Fast Path Data Entry Databases will continue to service those fundamental business needs. As this strategic mainframe environment fulfills an ever more pivotal server role, the need to attend database maintenance and availability will only increase. Part of this objective can be successfully achieved by expediting DEDB space problems by utilizing these area data set extension techniques.

---

Scott Heronimus is a product developer currently working on products for the IMS Fast Path DEDB databases. He has been at BMC Software since 1991 and has held several positions working on a wide variety of products in the IMS line.