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

Those who know me will know that I have spent the last few years advocating the fact that IMS is not dead. Fortunately, both customers and IBM* now agree with me! IMS is alive and kicking and not going away. Furthermore DBRC is a prerequisite to most of it — in fact, running a production IMS system without DBRC is equivalent to shooting yourself in both feet. The forced migration to DBCTL in the CICS environment and the move towards n-way sharing has also made many customers realize that they can no longer ignore my favorite piece of software!

I have assumed that you are running IMS V4 or later — previous versions are only mentioned when it helps to make things more clear.

This information is supplied on an "as-is" basis. I have tested it to the best of my ability and believe it to be true. If you find DBRC behaves differently in your shop from the way described in this book, it could be due to various reasons such as maintenance levels, and so on. If you are unable to determine why, contact me, and we'll discuss it.

Conventions

The term "IMS" refers to all versions and releases of IMS/VS and IMS/ESA. The specific product name, version, and release numbers are noted only when this information is significant.

Several special visual conventions are used in this manual to make it easier to use. They are as follows:

• Note: Notes alert you to aspects of a discussion or instructions that deserve special attention.
• Warning! Warnings alert you to situations that could cause loss of data or serious damage to your system if you do not follow the instructions carefully.

All syntax and example JCL is presented in this typeface. In the text of a paragraph, commands are presented in THIS TYPEFACE.

1. Database Recovery Control

Suffering from insomnia, I was once reduced to reading the Database Recovery Control (DBRC) reference manual from cover to cover. I discovered that while it is a good reference document, it certainly does not tell you how DBRC actually works.

The objective of this book, therefore, is to discuss how DBRC works in practice. Some of the topics discussed in this work include

• the principles of DBRC-why it was written
• how to implement DBRC
• how to use it
• problem areas to avoid
• techniques people have developed to make DBRC easier/possible

DBRC Background-Why do I need it?

DBRC was originally written to keep track of Information Management System (IMS) logs, change accumulations, and other log and tracking information. Armed with this information, DBRC can select the correct inputs and outputs for backing up and recovering databases, and for running change accumulation.

DBRC has been enhanced considerably since its early days. DBRC is now a prerequisite to many features including:

• Generating any IMS Transaction Manager (TM) or Database Control (DBCTL) system, or Customer Information Control System using Data Language 1 (CICS-DL/1) system.
  
  You cannot generate a system running IMS TM, DBCTL, or CICS-DL/1 without DBRC. DBRC is also required for maintaining these systems.
• IMS Disk Logging (online IMS).

Whereas use of DBRC is optional in CICS-DL/1 or batch DL/1, you cannot run an IMS TM or DBCTL system without it. IMS TM uses DBRC to control the disk logging process — i.e., selection of the next online log, automatic archiving, and so on.

Note: As from IMS V3, DBRC is a prerequisite to the new database control (DBCTL) address space. This means that DBRC Log Control (next online log selection, archiving process, and so on) will be available to any system using DBCTL — for example, CICS.

Further note: IMS V4 is the last release to support CICS-DL/1. In the future, you have to run with DBCTL.

In CICS-DL/1 systems and batch systems, DBRC can record logs. However, there is no automatic archiving and no control over the following items:

Selecting logs

CICS selects journal A, B, or X as relevant. DBRC is just a recording mechanism here. For batch processing, log selection is dictated by your job control language (JCL).

Reusing the same log prior to archiving it

Exits in CICS enable you to trigger archiving. IBM manual GA19-5478 contains sample code for using them. Archiving is a user responsibility in batch systems. You must use generation data groups (GDGs), retention periods, etc., to control your batch logs. CICS V3.1 provides a degree of automation for the archive process. A far more complete solution is provided by the BMC Software JOURNAL MANAGER PLUS product.

• Share Control
  
  Sharing databases across one or two MVS images was introduced in IMS V1.2 for DL/I and in IMS V1.3 for Fast Path data entry databases (DEDBs). As from IMS V5, sharing has been extended to n-way sharing. This means that multiple IMS systems (up to 32) can now share data across multiple MVS images (up to 64). DBRC Share Control is required, and the following levels of sharing are allowed:
• SHARELVL 0-enforced single user
• SHARELVL 1-multiple readers or one update plus read-only
• SHARELVL 2-multiple updaters in one MVS image
• SHARELVL 3-multiple updaters across two or more MVS images
Support for shared sequential dependents (SDEPs) and shared VSO DEDBs (see below) comes in IMS V6. General sequential access method (GSAM) and main storage databases (MSDBs) cannot be shared.
• Multiple Area Data Sets (MADS) in Fast Path
Fast Path DEDB users can choose to maintain multiple copies of the data sets making up their DEDBs. This is known as maintaining multiple area data sets. DBRC Recovery Control or Share Control is required.
• Extended Recovery Facility (XRF)
DBRC Share Control is required.
• IMS V3
DBRC is a prerequisite for several features in IMS V3: for example, High Speed Sequential Processing (HSSP) and NONRECOV (non-recoverable databases).
• Remote Site Recovery (RSR)
Refer to the BMC Software manual RSR in Practice.
• Virtual Storage Option (VSO) DEDBs
IBM is gradually replacing main storage databases (MSDBs). The recommendation is to convert your existing MSDBs to VSO DEDBs (a VSO DEDB with only root segments is effectively the same as an MSDB, is supported by DBRC, can be block-level shared and also supports field calls). MSDBs are not supported by DBRC and neither is GSAM.

DBRC Levels

There are three levels to DBRC: Log Control, Recovery Control, and Share Control. In IMS V6, Recovery Control dies (about time too, frankly-if you're still using Recovery Control, then you are a sad individual and you should get yourself onto proper DBRC Share Control as soon as possible). I have come across several scenarios that work fine with Share Control, but do not work properly with Recovery Control.

Figure 1: Levels of DBRC.

Log Control

In Log Control, DBRC records information about logs. For CICS-DL/1, DBRC is optional. Turning on DBRC means that DBRC records the journals. If using DFSUARC0 (the recommended IMS archive utility) to archive the journals, the output is recorded in DBRC's control data sets-the RECONs. For DBCTL and online IMS, DBRC is mandatory. It is installed as part of the IMS generation process (through the DBRC parameter on the IMSCTRL macro).

Follow these steps to implement Log Control:

Step 1 Initialize the RECONs with RECOVCTL (SHARECTL if DBCTL or V6 user).

Step 2 Do not register any databases with DBRC.

Recovery Control

In Recovery Control, DBRC provides all the Log Control functions and records information about image copies (IC), change accumulations (CA), recoveries, and reorganizations. To use Recovery Control, register your databases with DBRC.

Also, in Recovery Control DBRC generates and verifies JCL for image copy, change accumulation, and recovery. In addition, DBRC also records output from image copy, change accumulation, recovery, and backout. This means DBRC will avoid errors like missing logs, wrong image copy data set, recovery to an invalid point in time etc.

DSLOG is a DBRC unique utility that is not recommended, because support for it was discontinued in IMS V3.1. This book does not cover DSLOG.

Note: There is no GENJCL.BACKOUT. See Chapter 8, "Batch Backout, Signon, and Authorization" for a description of the backout process.

Warning! Recovery Control does not enforce the correct utility to be run at the correct time. For example, the user must control

• image copy after reorganization
• recovery after database I/O error
• backout after batch failure
• /ERE after online failure

Follow these steps to implement Recovery Control:

Step 1 Initialize RECONs with RECOVCTL.

Step 2 Ensure that DBRC is turned on in online systems, batch jobs, and utilities.

Step 3 Register your databases.

Share Control

Share Control contains all of the features of Recovery Control, plus it guarantees the following:

• Only valid sharing combinations run concurrently.
• The correct job/utility is run at the right time (see examples above), ensuring database integrity.

Follow these steps to use Share Control:

Step 1 Initialize RECONs with SHARECTL.

(If you are changing from Recovery Control, wait for all jobs running against the RECONs to complete, and then use CHANGE.RECON SHARECTL).

Step 2 Ensure that DBRC is turned on in online systems, batch jobs, and utilities.

Step 3 Register your databases.

Share Control is in fact required for DBCTL, but you do not have to register any of your databases. However, you are strongly recommended to do so-you should think of DBRC as a security mechanism like RACF. It should be turned on everywhere, you should not be able to turn it off, and everything should be under its control.

Recommended Migration Path

These are the recommended steps to follow for a new DBRC user:

Step 1 Play with all of this in a test environment and get familiar with it before you start in earnest.

Step 2 Implement DBRC Log Control.

Step 3 Turn on DBRC everywhere, and prove that all your jobs run with DBRC. You turn on DBRC via parameters in the IMSCTRL macro and/or overrides in your JCL. The most likely problems here are:

• S80A abend-DBRC requires 500K or more extra.
• No log-any job with a PROCOPT > G needs a log. Some customers run batch jobs without logging, e.g. image copy, run a suite of batch jobs, image copy again. While this is operationally simple (just recover to last image copy and rerun the jobs if anything goes wrong), it is inefficient and not recognized as valid by DBRC. To run this scenario, you would have to turn on DBRC for the image copies and turn DBRC off for the batch jobs.

Warning! Any implementation which involves turning DBRC on and off is inherently dangerous. FORCEing DBRC to be turned on (DBRC=FORCE on the IMSCTRL macro), and FORCEing registration of all your databases (FORCER parameter on INIT.RECON / CHANGE.RECON commands) should be your ultimate objective, as this combined with Share Control provides the only safe environment.

The BMC Software BATCH CONTROL FACILITY product contains a feature called Exchange Log Device Type, which enables you to implement logging in batch jobs and run them under DBRC control with no JCL changes. It will also allow you to run batch jobs with no log under DBRC control. While I don't recommend the latter as a long-term solution to your batch operations, it is a great migration and testing environment aid.

• Wrong RECONs-this should not happen if you use dynamic allocation (recommended) and everybody runs from the correct RESLIB

Step 4 Change to SHARECTL. Prove everything works-for example, backout, recovery from a central processing unit (CPU) or power failure, etc.

Step 5 Register databases.

How It Works

The essential elements for operating DBRC are exits and hooks, RECONs, skeletal JCL, and commands.

Exits/Hooks

A log switch, job initialization, and other various parts of IMS code automatically invoke DBRC. When invoked, DBRC records and checks the events against its control data sets-the RECONs.

RECONs

DBRC keeps its information in a pair of virtual storage access method (VSAM) key-sequenced data sets (KSDSs). It is also recommended that you define an available empty RECON, which acts as a SPARE. See Chapter 2, "RECON Setup" for recommended options for setting up RECONs.

Skeletal JCL

DBRC generates JCL by taking a skeleton member from the JCLPDS DD library and replacing the DBRC keywords in the JCL with information from RECON. The installation process creates skeleton members that you can update to include buffering, accounting information, user IDs, passwords, etc. Full details of these members are given in the IBM manual DBRC Guide and Reference.

Figure 2: Sample Archive Skeletal JCL Member.

Use the JCLOUT data definition (DD) statement to route the generated JCL to an internal reader (recommended) or a data set for browsing, editing, etc. For example:

Figure 3: Sample DBRC Job Step.

DBRC writes its SYSPRINT data set with a block size of 133. This does not matter if the file is allocated to SYSOUT, but if you are writing it to DASD for perusal by a program, this is very bad. Adding DCB=BLKSIZE=23408 to the allocation for this data set at one customer site reduced EXCPs from 75,425 to 416, and reduced the run time of the step from five minutes to a few seconds.

Note: You have to include the appropriate %SELECT commands, %DELETE commands, etc. in your skeletal JCL. These commands allow you to control under which conditions JCL is to be generated. Examples are given throughout this manual and IBM manual GG24-3333; they are explained in the DBRC Guide and Reference manual. There is also an excellent BMC Software publication I put together after some lengthy testing of this feature, which is rather boringly entitled GENJCL.USER Examples and Description-a riveting read designed to cure your insomnia problems.

Commands

You can enter DBRC commands in lots of different ways. Some customers use ISPF front-ends to make command entry easier-I personally think these are a waste of time as your objective in life should be to automate the interface to DBRC and not spend your life entering commands with 12-digit timestamps.

Try to set up automated procedures, using GENJCL.USER (see below), MVS procedures, IMS automated operator programs (available to DBCTL as from IMS V5), etc. Any production procedure that requires you to look in RECON or enter a DBRC command is a non-starter in my opinion. Do not use TSO foreground for DBRC, as the enqueues can cause other systems (e.g. online IMS) to hang waiting for your TSO session to finish.

DBRC writes its SYSPRINT data set with a block size of 133. This does not matter if the file is allocated to SYSOUT, but if you are writing it to DASD for perusal by a program, this is very bad. Adding DCB=BLKSIZE=23408 to the allocation for this data set at one customer site reduced EXCPs from 75,425 to 416, and reduced the run time of the step from five minutes to a few seconds.

Note: You have to include the appropriate %SELECT commands, %DELETE commands, etc. in your skeletal JCL. These commands allow you to control under which conditions JCL is to be generated. Examples are given throughout this manual and IBM manual GG24-3333; they are explained in the DBRC Guide and Reference manual. There is also an excellent BMC Software publication I put together after some lengthy testing of this feature, which is rather boringly entitled GENJCL.USER Examples and Description-a riveting read designed to cure your insomnia problems.

Commands

You can enter DBRC commands in lots of different ways. Some customers use ISPF front-ends to make command entry easier-I personally think these are a waste of time as your objective in life should be to automate the interface to DBRC and not spend your life entering commands with 12-digit timestamps.

You can enter DBRC commands in lots of different ways. Some customers use ISPF front-ends to make command entry easier-I personally think these are a waste of time as your objective in life should be to automate the interface to DBRC and not spend your life entering commands with 12-digit timestamps.

Try to set up automated procedures, using GENJCL.USER (see below), MVS procedures, IMS automated operator programs (available to DBCTL as from IMS V5), etc. Any production procedure that requires you to look in RECON or enter a DBRC command is a non-starter in my opinion. Do not use TSO foreground for DBRC, as the enqueues can cause other systems (e.g. online IMS) to hang waiting for your TSO session to finish.

It is not possible to execute the DBRC Recovery Control utility under the control of UCF (Utility Control Facility). No checking is done to prevent this, and the results are unpredictable (actually, they are totally predictable-it doesn't work properly!).

GENJCL

There are several useful parameters available on the GENJCL commands.

• DEFAULTS(member)
  is an optional parameter you use to specify the skeletal JCL default
  members to be used when generating JCL. Up to 10 members can be
  specified. Default members are searched to resolve keywords in the order
  in which the members are specified on this parameter.
  If a keyword is assigned a value in both the DEFAULTS and USERKEYS
  parameters, the value specified in USERKEYS is used.
• JCLOUT(JCLOUT/ddname)
  is an optional parameter you use to specify the output data set for the
  generated JCL. The data set is specified by ddname. A JCL DD statement
  with this ddname must be included in the job step containing the GENJCL
  command. The specified data set can be a member of a partitioned data
  set (PDS) as long as it is not the same data set used for the default
  JCLOUT.
  JCLOUT(JCLOUT) is the default.
• JCLPDS(ddname)
  is an optional parameter you use to specify the skeletal JCL data set to be
  used for input when generating JCL. The data set is specified by ddname.
  A JCL DD statement with this ddname must be included in the job step containing the GENJCL command. JCLPDS(JCLPDS) is the default.
  
• JOB/JOB(member)/NOJOB
  are mutually exclusive, optional parameters you use to specify whether to produce the job statement in the generated JCL.
  
  JOB specifies that the job statement is produced. When JOB is specified without a member name, the IBM-supplied execution member JOBJCL produces the job statement, so if you are going to use this make sure that the JOBJCL member contains valid JCL for your environment. When JOB(member) is specified, the specified execution member produces the job statement. NOJOB specifies that the job statement is not produced in the generated JCL. JOB is the default.
• LIST/NOLIST
  are mutually exclusive, optional parameters you use to specify whether to print the generated JCL using the SYSPRINT data set. LIST prints the generated JCL. NOLIST suppresses printing of the generated JCL. NOLIST is the default. I use this a lot for testing-I generate JCL and list it to check it. When I've got it sorted out, then I route it to an internal reader to execute.
  
• USERKEYS(%key1,'value'/%key2)
  is an optional parameter you use to set the value of keywords you have defined. Up to 32 keywords can be specified.
  
  %key1 is the user-defined keyword being assigned a value. The maximum length of the keyword is 8 characters, including the percent sign. The first character after the percent sign must be alphabetic (A-Z). The remaining characters must be alphanumeric (A-Z, 0-9). value is the value assigned to the user-defined keyword when it is encountered. value can be any character string enclosed in quotes. The maximum length of value is 132 characters. If value contains a quote, use two single quotes. value can be a null string ('').
  
  %key2 is any simple keyword previously assigned a value, including DBRC and user-defined keywords.

Have a look in my GENJCL.USER Examples and Description manual for some scintillating examples of how to use these.

GENJCL and BMC Software

When you use GENJCL with the normal IMS utilities, it goes to RECON to extract the information required, combines this with your skeletal JCL and produces a job to execute. When this job starts, the first thing it does is to check that the JCL is correct by reading the RECONs again.

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