11.01.2013 Views

ABCs of z/OS System Programming Volume 3 - IBM Redbooks

ABCs of z/OS System Programming Volume 3 - IBM Redbooks

ABCs of z/OS System Programming Volume 3 - IBM Redbooks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Aliases to the catalog can be defined if you use DFSMSdss, DFSMShsm, or if you specify<br />

ALIAS on the IMPORT command. If you have not deleted and redefined the catalog, all existing<br />

aliases are maintained, and any aliases defined in the backup copy are redefined if they are<br />

not already defined.<br />

Lock the BCS before you start recovery so that no one else has access to it while you recover<br />

the BCS. If you do not restrict access to the catalog, users might be able to update the<br />

catalog during recovery or maintenance and create a data integrity exposure. The catalog<br />

also will be unavailable to any system that shares the catalog. You cannot lock a master<br />

catalog.<br />

After you recover the catalog, update the BCS with any changes which have occurred since<br />

the last backup, for example, by running IDCAMS DEFINE RECATALOG for all missing entries.<br />

You can use the access method services DIAGN<strong>OS</strong>E command to identify certain<br />

unsynchronized entries.<br />

The Integrated Catalog Forward Recovery Utility<br />

You also can use the Integrated Catalog Forward Recovery Utility (ICFRU) to recover a<br />

damaged catalog to a correct and current status. This utility uses SMF records that record<br />

changes to the catalog, updating the catalog with changes made since the BCS was backed<br />

up. The SMF records are used by ICFRU as a login database. Use ICFRU to avoid the loss <strong>of</strong><br />

catalog data even after recovery.<br />

Recovery step by step<br />

Follow these steps to recover a BCS using the IDCAMS IMPORT command:<br />

1. If the catalog is used by the job scheduler for any batch jobs, hold the job queue for all job<br />

classes except the one you use for the recovery.<br />

2. Lock the catalog using the IDCAMS ALTER LOCK command.<br />

3. Use ICFRU to create an updated version <strong>of</strong> your last EXPORT backup.<br />

4. Import the most current backup copy <strong>of</strong> the BCS (which contains the BCS's aliases as<br />

they existed when the backup was made). For example, use this JCL:<br />

//RECOVER EXEC PGM=IDCAMS<br />

//BACKCOPY DD DSN=BACKUP.SYS1.ICFCAT.PROJECT1,DISP=OLD<br />

//SYSPRINT DD SYSOUT=A<br />

//SYSIN DD *<br />

IMPORT INFILE(BACKCOPY) -<br />

OUTDATASET(SYS1.ICFCAT.PROJECT1) -<br />

ALIAS -<br />

LOCK<br />

5. If you did not run step 3, manually update the catalog with the changes made between the<br />

last backup and the time <strong>of</strong> error, for example by using IDCAMS DEFINE RECATALOG.<br />

6. Use IDCAMS DIAGN<strong>OS</strong>E and EXAMINE commands to check the contents and integrity <strong>of</strong> the<br />

catalog (see 6.15, “Checking the integrity on an ICF structure” on page 357).<br />

7. If the catalog is shared by other systems and was disconnect there for recovery, run<br />

IDCAMS IMPORT CONNECT ALIAS on those systems to reconnect the user catalog to the<br />

master catalog.<br />

8. Unlock the catalog using IDCAMS ALTER UNLOCK.<br />

9. Free the job queue if you put it on hold.<br />

For further information about recovery procedures, see z/<strong>OS</strong> DFSMS: Managing Catalogs,<br />

SC26-7409. For information about the IDCAMS facility, see z/<strong>OS</strong> DFSMS Access Method<br />

Services for Catalogs, SC26-7394.<br />

356 <strong>ABCs</strong> <strong>of</strong> z/<strong>OS</strong> <strong>System</strong> <strong>Programming</strong> <strong>Volume</strong> 3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!