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

This article covers topics related to monitoring the status of your RECON data sets and what to do if something goes wrong with them.

Monitoring Status of RECONs

Loss or corruption of all RECON data sets is a major catastrophe, causing loss of service and probably jeopardizing system and data integrity. Adhering to the following guidelines will reduce the likelihood of RECON data sets being lost or corrupted.

1. Use the parameter STARTNEW(NO) on the INIT.RECON or CHANGE.RECON command.
2. Allocate a third spare RECON data set.
3. Use dynamic allocation.
4. Position all three data sets sensibly.

These precautions are important because only one RECON data set can be discarded without impacting availability.

Methods of Monitoring

Following are methods for monitoring RECON data sets in three different environments: online IMS system, batch, and CICS-DL/1.

Online IMS System

The status of the RECONs can be determined from any online IMS system using those RECONs (depending on terminal security for the /RML command) by entering the following:

     /RML (LTERM xxxxxxxx) DBRC='RECON STATUS'

The optional LTERM parameter permits you to route the output from the RMLIST command to an alternative terminal (usually a printer). This method of monitoring the RECONs is only applicable while online IMS is running.

You can also issue online DBRC commands from automated operator programs. Many users set up batch message processing (BMP) programs that monitor the status of the RECONs regularly.

Batch

You can monitor the status of the RECONs in batch mode through a two-step job. First, issue a LIST.RECON STATUS command and write the file SYSPRINT to a data set. Second, analyze that output with a program. The advantage to this method is that it uses the standard dynamic allocation for RECONs.

CICS-DL/1

In CICS-DL/1, you can use the DBRC online transaction to issue the LIST.RECON STATUS command. However, DBRC commands are infrequently used in CICS-DL/1 because they require 430K additional virtual storage in the CICS-DL/1 region.

Satisfactory Status of the RECONs

RECON1, RECON2, and RECON3 should be of unequal size. If RECON3 is the largest, then RECON1 and RECON2 should be COPY1 and COPY2 (either order), and RECON3 should be the SPARE. A SPARE RECON is an empty VSAM KSDS.

Reorganization of RECONs

Periodically, reorganization is necessary because the RECONs are VSAM KSDSs. DBRC automatically deletes some records; the user must delete others. After this cleanup, the user should perform a reorganization to reclaim free space and eliminate any CI and CA splits.

The Easy Way

The easiest way to reorganize a VSAM KSDS with the NOREUSE attribute is to REPRO the data set to a sequential (if record size is less than 32K) or VSAM data set, delete and redefine the KSDS, and REPRO the data back. However, this is not the safest method. With this method there will only be one valid RECON. If RECON(s) have been discarded, there may not be any valid RECONs.

A Safer Method

A safer method of reorganizing a VSAM KSDS is to successively use the CHANGE.RECON command with the REPLACE parameter, followed by the IDCAMS command to delete and define the discarded RECON.

You can write a program in a high-level language to determine the current status of the RECONs (see ¡°Monitoring Status of RECONs¡± on page 21), invoke an Assembler routine that will link to DBRC (DSPURX00) and replace a RECON, and link to IDCAMS to delete and define the discarded RECON.

Note: It is not possible to delete a data set while it is allocated elsewhere. However, as far as I am aware (unless they have changed VSAM recently), you can delete a VSAM data set on one CPU while it is allocated on another CPU. This means that such a program cannot operate while any DBRC job is active.

An online IMS system will free a discarded RECON when it next accesses the RECONs. So you can write a BMP automated operator interface (AOI) program to check the STATUS of the three RECONs, issue the /RMCHANGE command to discard the first RECON, issue a /DIS OLDS or /RML RECON STATUS command to force IMS to access the RECONs and force deallocation of the now discarded RECON. Now run IDCAMS to delete and redefine the discarded RECON. You can repeat this procedure for the second RECON.

This procedure will work if this online IMS system is the only job currently using the RECONs. If other jobs are active, IDCAMS will have to wait until the other jobs have also discarded and deallocated the "bad" RECON. This can, for instance, be a problem when sharing the RECONs across CPUs.

If you issue a write-to-operator with reply (WTOR) or programming language one (PL/1) display after each CHANGE.RECON, you can also operate the program in a multi-online IMS environment. A message instructing the master terminal operator (MTO) to issue a /DIS OLDS to each online system before replying to the program would be displayed on job entry subsystem (JES) consoles.

/DIS OLDS

The /DIS OLDS command gives the status of all the OLDS and WADS¡ªit accesses the RECONs as part of this process and hence can be used as outlined above to trigger the deallocation of a ¡°bad¡± RECON.

Recovery Following a Discarded RECON

An advantage to having a program that reorganizes the RECONs is that you can very easily design it to recover from a situation like a RECON being discarded. All you have to do is wait for the ¡°bad¡± RECON to be discarded (= deallocated) by all the subsystems currently running and then use IDCAMS DELETE/DEFINE to create an empty VSAM KSDS. The next job step to access the RECONs will then find this data set and recognize it as a SPARE RECON. The trick is noticing that you have lost a RECON¡ªeither trap the RECON messages in an MVS exit or run a LIST.RECON STATUS on a regular basis to see if any of the RECONs is bad.

Losing Two RECONs

If you lose two RECONs and you have NONEW specified, then no new jobs will start. If you now issue LIST.RECON STATUS you will get output similar to the following:

Identify which is the correct valid RECON, delete/define the other two, and then issue CHANGE.RECON DUAL or LIST.RECON STATUS. This will reestablish dual RECONs with a SPARE.

Losing All Three RECONs

It is impossible to recreate all the information in the RECONs using commands. Restoring RECON to an earlier point in time and adding missing log etc. data is not a correct method (in the Recovery Control and Share Control environments). With careful planning, you should never lose all three RECONs.

The quickest and only safe method of rebuilding and re-synchronizing the RECON data sets in these circumstances is to clean up the abended jobs, which will involve backout of in-flight work, take a fresh set of RECONs with all the databases, groups etc. registered (it is worth keeping a PDS member handy with all these INIT definitions stored in it¡ªif I ever get time, I will try and write a GENJCL.USER to create all the INIT commands from an existing RECON) and then image copy everything.

I met the man in charge of the IBM Red Books the other day, and he pointed out to me that there is a sample procedure for building the INIT.DB and INIT.DBDS commands from an existing RECON in SG24-2211 — so that's saved me some work!

BACKUP.RECON

Why do I use BACKUP.RECON then, if not to cater for loss of the RECONs? BACKUP.RECON should still be used for several reasons:

1. Taking a copy of the RECONs offsite. Whenever you take data offsite (e.g. image copies and/or logs), you should take a copy of the RECONs at the same time.
2. Before applying maintenance — e.g. the Migration and Coexistence SPE — see Changing Versions — the UPGRADE command for further details.
3. When something has gone wrong and you don't know what to do — take a BACKUP of the RECONs and play with them. When you've sorted out what commands to issue, go back and use the production RECONs.

BACKUP.RECON uses IDCAMS REPRO internally, but it also does an en queue on the RECONs to guarantee that no updates occur during the BACKUP — a fuzzy backup is useless — so you should always use BACKUP.RECON rather than pack dumps or other software.

However, your RECON record size may be greater than 32K (e.g. SUBSYS record—see Creating a RECON Data Set or PRILOG/PRISLD record) and REPRO will not copy a VSAM KSDS to a non-VSAM data set when the maximum record size is greater than 32,760 bytes. You have to back up the RECON to VSAM KSDS (use BACKUP.RECON so that you still get the en queue, but point the output to an empty VSAM KSDS). When using this method of backup (rather than to non-VSAM data sets), you must use empty—IDCAMS DELETE/DEFINEd—KSDS. Otherwise, your output will be merged with the previous backup copy. Once you have backed up your RECONs to VSAM KSDS, then use another piece of software like DFDSS or FDR to copy this data set to tape/cartridge.

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