From Database Recovery Control (DBRC) in Practice by Peter Armstrong (Third Edition); copyright 1990 BMC Software.

Part 1  |  Part 2  |  Part 3  | Part 4  |  Part 5  |  Part 6

Introduction

This article is a collection of pointers to various manuals about the best way to set up the RECON data sets.

The placement of the RECON data sets in the direct access storage device (DASD) configuration is very important. While the primary rule is to configure for availability, the performance implications should not be neglected. It is bad news to lose both of your active RECON data sets at the same time (to paraphrase Oscar Wilde, the loss of one RECON might be considered unfortunate, but the loss of both — or all three — is careless in the extreme).

See IBM's DBRC Guide and Reference manual for further details on placement and a discussion of Global Resource Serialization (GRS) with DBRC.

Creating a RECON Data Set

A RECON data set is a VSAM KSDS. It is created by the use of a DEFINE CLUSTER command. The high-level identifier should be different for each RECON data set. This allows them to be cataloged in different catalogs (this restriction is lifted in DFP version 3). It is recommended the low-level identifier be RECON1, RECON2, or RECON3 respectively. However, anything that conforms to your company standards is acceptable.

You should try to keep the RECONs small, as they can become a performance bottleneck (especially when shared amongst multiple MVS images). Each job step accessing the RECONs uses ENQ/DEQ to "hold" the RECONs while doing its updates, so don't submit 500 image copy jobs (one for each DBDS) at the same time-you will cripple your performance. Set up your jobs to copy and recover groups of database data sets in one job step.

Here are some things to keep in mind:

• Keep the number of image copy generations down to a sensible number. DBRC retains all recovery related records (IC, CA, ALLOC, LOGALL, RECOV, REORG, PRILOG, etc.) back to the oldest image copy in RECON. If you image copy once a week and keep 10 generations of image copy, then your RECONs will be at least 10 weeks big. Ask yourself how often you have had to go back to a previous generation of image copy. Three or four generations should be quite sufficient for most users.
• Keep the number of change accumulation generations down to a sensible number.
• Delete the INACTIVE log records/entries from RECON regularly.
• Reorganize the RECONs regularly.
• Consider compressing them with software.
• Put them behind a cache.

Here are some guidelines that one customer provided for allocating a primary space allocation for the RECON data set:

• The RECON data set holds approximately 30 days' worth of data.
• Jobs causing the entries in the RECON data set are run constantly.
• They use 8K control intervals with spanned records and a maximum record size of 64K.
• They always use dual image copies.

The records contained in the RECON data set are as follows:

• 2 change accumulation group (CAGRP) records
• 15 change accumulation records per CAGRP record
• 286 database records
• 396 DBDS records
• 5 IC records per DBDS record with an average of one volume each
• 30 ALLOC records per DBDS record
• 1970 primary recovery log (PRILOG) records-mainly with one volume each
• 1970 secondary recovery log (SECLOG) records-mainly with one volume each
• 1970 LOGALL records
• 2 SUBSYS records
• approximately 100 RECOV/REORG records

This information utilizes eight cylinders of a 3380 disk. If your RECON starts growing beyond 20 cylinders, you are probably not cleaning it up properly.

The RECORDSIZE(avg,max) average parameter for a RECON data set should set to be 128. The maximum record size should be large enough to contain the largest recovery or system log data set anticipated. Should this be larger than 32,760 bytes, which happens to be the largest CI size allowed in VSAM, then use the SPANNED parameter to spread the record over several CIs. (In fact, if your RECORDSIZE for RECON is greater than 8K, you are recommended to use 8K CIs and specify SPANNED.)

There are several record types in the RECON, which can grow to larger than 32K. The most common problem is the PRILOG record-see "Size of PRISLD/PRILOG Record" on page 61 for further details. The other record that can grow if you have a large number of databases authorized to a subsystem is the SUBSYS record-the size of this is 72 + (number of authorized DBs x 32 bytes).

The key size changes from 24 bytes to 32 bytes when you go to V6-see below for UPGRADE procedures.

Use different sizes and different FREESPACE specifications for each RECON, and make all three RECONs different sizes so they don't all fill up at the same time. Don't change any of the VSAM parameters while the RECONs are in use. Wait until the active subsystems have terminated, then go through a procedure of backup, change, check, backup, and start again.

Ensure that the smallest data CI size specified exceeds the largest index CI size specified by at least 2048 bytes. Failure to do so can seriously degrade your DBRC performance.

RECON Buffering

It is not easy to find this in the manuals, but it makes a big difference to your RECON performance. Use BookManager and search on DSPBUFFS-you will then find the details you require in the Customization Guide.

IMS TM and DBCTL users should specify ten times the default number of buffers, as the buffers are allocated in the DBRC separate address space, where you have plenty of space. CICS-DL/1 (and batch) users should allocate as many buffers as their virtual storage permits.

At physical open time, the maximum buffers used are the LSRPOOL plus three times the NSR (i.e., 6 data + 6 index) = 168K (for 2K index and 8K data). In steady state, the maximum buffers used are the LSRPOOL plus two times the maximum RECORDSIZE.

Here are some further tips I picked up from a customer via the IMS list server:

Besides looking at the DSPBUFFS CSECT, you might want to try looking closely at a LISTCAT for the RECONS. If you're on 3390s, then the 16K CI size results in a 4K physical record size. Try going to 18K CI for the data component; you'll get an 18K physical record size resulting in just 3 records per track instead of 12. That's 1/4th the I/O for each block. Going to 18K also increases the DASD usage from 86.74% to 97.59%.

As far as recommendations for DSPBUFFS goes, try to keep an entire control area of data in memory. For the 18K CI, that's 45. If you let the index CI default, VSAM will pick 512K since there are less CIs/CA. Look at the LISTCAT to see how many index CIs exist, then pick a number that will keep a manageable amount in storage.

But don't forget that more buffers means more region is needed. If you increase the batch numbers too much, jobs will start running out of memory. The online numbers should be safe to increase since you control the region size for the IMS tasks.

Changing Versions-the UPGRADE Command

When you migrate from one IMS version to another, the RECONs change (new record types, new record formats etc.), and you must apply an SPE to your previous system and UPGRADE the RECONs to the new level. The UPGRADE command comes as part of a Migration/Coexistence SPE for your current IMS version and uses a special DBRC utility-DSPURU00 (also part of the SPE), not the usual DSPURX00.

Prior to V6, this UPGRADE followed the following steps:

• Back up both RECON data sets.
• Install the Migration and Coexistence SPE.
• Back up.
• Install the new IMS release.
• Back up.
• UPGRADE.RECON-produces one good RECON.
• Back up new COPY1 RECON.
• Define new RECON.
• LIST.RECON STATUS or CHANGE.RECON DUAL to reinstate duality.
• Back up.
• Define SPARE RECON.

Note that UPGRADE.RECON only accepts a RECON1 DD statement and assumes that it is pointing at a valid copy. Use LIST.RECON STATUS to ensure that RECON1 is either COPY1 or COPY2. If it is not, use CHANGE.RECON REPLACE as described in Chapter 3, "RECON Care and Maintenance" to copy one of the current RECONs to RECON1.

No jobs that access RECON may be run during the UPGRADE process.

Version 6

Just to keep you on your toes, they changed it all in IMS V6 because the key length of the RECON records changes to accommodate the new UTC (year 2000) timestamps.

The procedure for V6 is documented in the DBRC Guide and Reference. Study it carefully and follow it religiously. There is no DOWNGRADE command-hence the recommendation to take BACKUPs at each stage of the process in case anything goes wrong.

Part 1  |  Part 2  |  Part 3  | Part 4  |  Part 5  |  Part 6

--

Peter Armstrong joined IBM in 1976 and was the UK Country IMS specialist. He helped design parts of DBRC and wrote the Recovery/Restart procedures for IMS disk logging. He joined BMC in 1986 and travels the world discussing computing issues with customers, analysts, etc. He has used all this technical and practical experience to write a book on how DBRC works in practice rather than a boring theoretical tome. He hopes you will enjoy it.

Peter Armstrong's Blog - Adopting a Service Mentality