Backup and recovery of catalogs is a complex and critical procedure. To assume that it can be reduced to a process that is as simple as pushing a button is to make a serious mistake! The myriad of dependencies among the operating system, the type of catalog (OS CVOL, VSAM user catalog, or ICF catalog), and the data related to the catalog entries almost always demands unique recovery steps to obtain a catalog that is truly useful.
Recovering a catalog from a backup copy can be meaningful or useful for both ICF catalogs and OS CVOLS, but rarely (if ever) for VSAM user catalogs. The old VSAM user catalogs have many dependencies such as time stamps and volume ownership that make it nearly impossible to use them if they are recovered independently from all of their clusters. The ability (IDCAMS functions) to re synchronize them is just not available. IBM addressed these concerns by providing ICF catalogs, and the enhanced abilities in IDCAMS to re synchronize them. For these reasons, CA Disk provides the ability to automate and extend the catalog backup process for ICF catalogs, but you must provide the knowledge and analysis to see that the correct recovery steps are taken—steps that suit your particular case and achieve the results you desire.
Backing up ICF catalogs can be automated simply by specifying SELECT CATALOGS= in front of a BACKUP command, or by adding the BACKUP parameter to the SCAN CATALOGS= command. If a SELECT statement is not specified with the SCAN CATALOGS= command, CA Disk will backup ICF catalogs. As each catalog is selected for processing, CA Disk links to the IDCAMS EXPORT function, intercepts the records, and writes them in CA Disk format to the archive media. To extend or enhance the backup and recovery process, the ALIAS entries for the catalog are also extracted from the master catalog and appended to the exported catalog data. This provides CA Disk with the ability to dynamically redefine them in the master catalog per the DEFALIAS=YES/no parameter on the RECOVER command. Without this ability, all alias pointers in the master catalog must be rebuilt manually because they are deleted (lost) when a catalog is imported.
Parameter EXPORTF=NO/yes is also available for the RECOVER command. Specifying YES instructs CA Disk not to IMPORT the catalog, but to create a sequential data set on disk that can be used as direct input to a native IMPORT; that is, the data set will be in export format that IMPORT can use. When running with this option, messages are issued to identify the ALIAS entries that you can need to redefine in the master catalog after you actually do the IMPORT. (As mentioned in previous, a backup copy and an IMPORT done under DFP 2.3 or above should preserve the ALIAS entries. For earlier versions of DFP you will need to redefine them manually.) This option can be used as just described, but is also provided for use with IBM's catalog forward recovery utility (ICFRU 5798-DXQ), which requires an EXPORT copy as input.
It should be evident from the descriptions previous that CA Disk automates and extends the use of IBM's IDCAMS EXPORT and IMPORT functions to provide for much easier backup and recovery of ICF catalogs. It is not the intent of this documentation, however, to present a tutorial or guideline regarding a multitude of recovery scenarios, the problems encountered in each, and the steps necessary to recover successfully. Other publications or classes specifically designed to address the complexity of these topics should be consulted if needed. Your analysis and planning should be based upon the abilities provided by EXPORT and IMPORT (as automated and extended by CA Disk) and the other ICF resynchronization functions within IDCAMS.
If a catalog being recovered still exists on disk, IDCAMS will overlay it only if its temporary export flag is on. Otherwise the existing catalog must be deleted before the IMPORT can be done. See sysparm CATBKDELn in the Systems Guide, for an option to have CA Disk attempt this delete automatically for you. A DELETE usercat UCAT RECOVERY command is issued.
If a catalog being recovered does not exist on disk, but its entry in the master catalog still exists (for example, the volume containing the catalog has been reinitialized due to a hardware failure), you will probably need to issue an IDCAMS "EXPORT usercat/masterpassword DISCONNECT" command before the recovery will succeed.
One very important planning item to consider is the following. Depending upon which catalog is lost, the ability to submit and initiate jobs can be impossible without hardcoding volume information in the JCL (because the catalog normally used to provide this information is the one that was lost). One of these jobs can be the CA Disk recovery run, or perhaps the IDCAMS IMPORT job! Being prepared to provide the volumes in the JCL for either of these jobs can be essentia!
IDCAMS can dynamically allocate each ICF catalog as it begins the EXPORT function, but it does so with DISP=OLD and does not deallocate (free) the catalog when it is done (it waits for step termination to do so). To avoid what can be a lengthy tie-up, CA Disk uses its own dynamic allocation to allocate each needed catalog, and then deallocates (frees) it immediately after the EXPORT. For importing a catalog, however, CA Disk lets IDCAMS perform its own allocation.
Before recovering an ICF catalog and its associated clusters, review the value specified for sysparm VSPREDEF carefully. The default value of N prevents CA Disk from overwriting preallocated (or in this case, pre-existing) VSAM clusters during restore processing. If it is specified with a value of Y (not recommended), CA Disk will overwrite the existing clusters with the REUSE attribute. However, if the information in the VVDS is incorrect or not present, this can cause errors in recovering the VSAM clusters. The best method would be to leave VSPREDEF with the default value (N). Recover the ICF catalog and the clusters. Then restore the exceptions (if necessary) using the SCRATCH parameter of Restore.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|