Postsellado por inmersión y rociado

Chapter 7

Bad Data Sets

If you run a utility and there are problems with the output data sets, then DBRC will be aware that the utility was unsuccessful and the normal action is to rerun the utility. If, on the other hand, you are running a utility where you have problems with reading one of the input data sets (e.g., image copy data set in recovery), then you will discover that these read I/Os are not notified to DBRC. You have to tell DBRC that the data sets are bad. When DBRC generates JCL, it looks at the PRILOG records and primary image copy records. To force it to use secondary data sets, you have to tell it that the primary is broken.

Bad Image Copy Data Set

If an image copy is unreadable, DBRC does not automatically select the secondary image copy. You must flag the primary image copy as being broken and regenerate the JCL. DBRC then selects the secondary. The command to do this isCHANGE.IC... INVALID—see my GENJCL.USER Examples and Description manual for an example. If you have been really sensible and have bought BMC Software’s RECOVERY PLUS, then you don’t need to do anything to DBRC—just use theSIC parameter (aren’t we nice to you!?)

If you do not have a secondary image copy, DBRC selects the previous generation, the necessary logs, and change accumulation, but if there has been a reorganization since the last good image copy, then DBRC cannot generate any JCL for you.

Bad Image Copy Data Set

Figure 27 DBRC and Unreadable Image Copies

Your possible actions are:

1. If the broken database is an index, use BMC Software’s SECONDARY INDEX UTILITY/EP to rebuild it.

OR

2. If you still have the unload data set, rerun the reload outside DBRC (you run this outside DBRC as you don’t want RECON to have yet another REORG record to get confused by).

NOTIFY this to DBRC as a timestamp recovery to IC2 (i.e.RCVTIME=time of IC2 andRUNTIME=CURRENT), followed by aGENJCL.RECOV with the

USEDBDS parameter. This will apply logs 4, 5, 6 on top of the database. This is horrendous and not recommended for the faint-hearted. I tried it once and got it to work after much blood, sweat, and tears. Avoid if you can.

OR

3. Run a timestamp recovery to the end of log 3. Now, reorganize the database (outside DBRC) exactly as the previous reorg was run. Then continue as in the second course of action, listed above. This, of course, assumes that reorg runs exactly the same way twice, which I frankly would not count on.

The moral here is to use dual image copy output after a reorg!

IC1 Logs IC2

1 2 3 4 5 6 Logs Reorg Unreadable

Bad Change Accumulation Data Set

BMC Software, Inc., Confidential and Proprietary Information

Chapter 7 Bad Data Sets 69

Bad Change Accumulation Data Set

There is no support in IMS for dual change accumulation output data sets. If you get an error here, mark the data set as bad using theCHANGE.CA ... INVALIDcommand. The next time you run change accumulation, DBRC will select the appropriate input data sets.

If you have been sensible once again and bought BMC Software’s CHANGE ACCUMULATION PLUS, you will find that it supports dual output.

Unfortunately, DBRC only allows us to register the primary copy in RECON. If this later proves to be unreadable, then use aCHANGE.CA command to point at the secondary copy and rerun your job—again, there is an example in my GENJCL.USER Examples and Description manual.

How to Use a SLDS in Place of a Bad RLDS

You cannot use DFSULTR0 to repair an RLDS because DFSULTR0 checks sequence numbers that are not contiguous in an RLDS.

If a write error occurs on an RLDS during archive, rerun the archive. If a read error occurs on an RLDS and there is a secondary RLDS available, flag the primary as being in error by using theCHANGE.PRILOG ... ERROR command. Regenerate the JCL and DBRC will select the secondary RLDS (SECLOG record in RECON).

Note: BMC Software’s RECOVERY PLUS product (the one you licensed two pages ago) has a special parameterSLOG, which selects the secondary log(s) without having to issue DBRC commands to flag the primary logs(s) as ERROR. Will this generosity never end? If a read error occurs on an RLDS and there is no secondary RLDS available, use the SLDS instead. DBRC does not automatically select the SLDS instead of the RLDS (because it looks at PRILOG records forGENJCL.CAand

GENJCL.RECOV, not PRISLD records). If you want to update RECON to reflect this (or you are in DBRC Recovery or Share Control where you must update RECON), perform one of the following steps:

• Manually update the PRILOG record in RECON (with DSN and VOLSER information) to point at the SLDS.

CHANGE.PRILOG RLDS STARTIME(...) DSN(new dsname) OLDVOL(oldvol) - NEWVOL(newvol) DSSTART(...)

How to Use a SLDS in Place of a Bad RLDS

• Copy the SLDS to a new data set with the same name and VOLSER as the bad RLDS using IEGBENER or DFSUARC0. In this case, no update of RECON is necessary.

If the RLDS has been produced by archiving an OLDS, use DFSUARC0 withPARM='DBRC=N' (which is possible even if you haveDBRC=FORCE) and use the SLDS as input. This will run outside DBRC control.

Warning! I have tried running this with DBRC turned on, and the resulting updates in RECON are unpredictable because DBRC thinks you are trying to archive the SLDS as a batch log. However, the PRILOG/PRISLD records have multiple entries (online record types) and DBRC gets very confused.

A Clever Archiving Technique

The following technique is used by some customers to give them secondary SLDS and secondary RLDS without having to create both data sets.

Archive output is:

• primary SLDS — PRISLD record in RECON

• secondary SLDS — SECSLD record in RECON (will be used if PRISLD marked in ERROR)

• primary RLDS — PRILOG record in RECON • no secondary RLDS

In this case, DBRC still builds a SECLOG record that points at the secondary SLDS data set. This means both the SECLOG and SECSLD records contain the same information and are used if PRILOG is marked in ERROR.

If you use this technique, you must ensure that the PRILOG and SECSLD are on the same device type, or use one of the techniques described in “Concatenated Tape and Disk” on page 62 to handle mixed device types.

BMC Software, Inc., Confidential and Proprietary Information

Chapter 8 Batch Backout, Signon, and Authorization 71