Previous Topic: Quick Availability, Recovery of Previous ChangeNext Topic: OpenExtensions VM Support


Detailed Backup and Recovery Steps

This section presents detailed information about the various backup and recovery steps presented in previous sections.

IPLing Without Starting CA ACF2 for VM

There can be situations (such as a catastrophic hardware error) when you must IPL VM without CA ACF2 for VM active. CA ACF2 for VM lets you IPL the system in force mode. When the system runs in force mode, the following restrictions exist:

To IPL in force mode:

  1. IPL VM according to your site's procedures. Watch for the following message:
    ACFpgm000R Enter ACF2 startup options or press Enter
    

    When it appears, enter the following command:

    NOAUTO
    

    Press Enter to prevent the service machine autolog. VM will be running in FORCE mode. No CA ACF2 for VM security validations will take place.

  2. Any user defined in the FORCEID list can now log on without a password. (An exception is if NOAUTO=DIRPASS. FORCEID users must enter their valid VM directory passwords.)
  3. Repair the problem as soon as possible. CA ACF2 for VM does no validations while it is in FORCE mode.
  4. After the problem is resolved, IPL the system normally autologging the CA ACF2 for VM service machine.

Restoring Backup Files to Usable Databases

Use the ACFDBRST utility to restore backup files to usable databases. You can use the sample exec, ACFREST, to help you run this utility. Use a FILEDEF to define the file ID of the backup file. Use a FILEDEF or a DLBL (for VSAM) to define the database to restore into. The utility expects a parameter of LID, RULE, INFO, or ALL to determine which databases to process. Also, the minidisks you are restoring must be reserved disks and in 4K blocks. If they are existing database disks, this is already done.

Below is an example of running this utility:

FILEDEF BKPLIDS DISK BKLID BACKUPDB Z FILEDEF LIDS DISK LID DATABASE U FILEDEF BKPRULES DISK BKRULES BACKUPDB Z FILEDEF RULES DISK RULES DATABASE V FILEDEF BCPINFO DISK BKINFO BACKUPDB Z FILEDEF INFO DISK INFO DATABASE W ACFDBRST ALL

In this example, the backup files disk is accessed as Z. The Logonid, Rule, and Infostorage databases reserved disks are accessed as U, V, and W, respectively. After issuing the FILEDEF statements, enter the ACFDBRST ALL command to restore all three database files from backups. You must restore all three databases with this utility. For detailed information about the ACFDBRST utility, see the Reports and Utilities Guide.

The ACFRECVR Utility

This utility merges SMF records with the databases. The next section explains the SMF files needed for recovery.

SMF Files Necessary for Recovery

The SMF files necessary for recovery depend on which approach to recovery you take. Choose the SMF files dated in the date and time interval needed for the desired approach, based on the filetype of the SMF files. The filetype has the format yydddsss.

yy

The year

ddd

The julian date

sss

A sequential suffix from 1 to FFF, indicating the number of the SMF file for the day.

Running the ACFRECVR Utility

To run the ACFRECVR utility, issue the FILEDEFs for each database to recover or put the FILEDEF statements in the ACFRECVR EXEC.

For example:

FILEDEF LIDS DISK LID DATABASE U FILEDEF RULES DISK RULES DATABASE V FILEDEF INFO DISK INFO DATABASE W

Invoke the ACFRECVR EXEC and respond to SMF prompts. For more information on this exec, see the Reports and Utilities Guide.

Starting CA ACF2 for VM Using Alternate Databases

The following procedure assumes that at least one set of alternate databases is available. See the Alternate CA ACF2 for VM Database section for more information about the alternate databases.

IPL VM. Specify the name of an alternate set of databases in response to the service machine startup options message.

ACFpgm000R Enter ACF2 startup options or press ENTER, ddsn(altcms) nobackup

The user reply DDSN(ALTCMS) NOBACKUP directs CA ACF2 for VM to use the filenames defined in the @DDSN macro named ALTCMS. The NOBACKUP parameter deactivates the CA ACF2 for VM automatic backup facility, preventing automatic backups from writing over backup files. This procedure is completed. CA ACF2 for VM is now running with the alternate databases active.

Copying CA ACF2 for VM Databases

Use the ACFDBCPY utility to copy a CMS format CA ACF2 for VM database. You cannot use COPYFILE because the databases are on reserved disks. Use the ACFDBCPY utility to copy CMS databases for recovery purposes, such as copying alternate databases to primary databases or expanding the size of the minidisk a database is on. To run the ACFDBCPY utility, enter the following:

ACFDBCPY ALTLID DATABASE Z LID DATABASE U.

If you are using VSAM databases, use the VSAM REPRO utility to copy the databases as follows:

  1. REPRO the VSAM databases to sequential files
  2. Delete and define the target VSAM clusters
  3. REPRO the sequential files to the target clusters just defined.

For more information about the ACFDBCPY utility, see the Reports and Utilities Guide.

Taking a Manual Backup

There can be a situation when you want to manually back up the CA ACF2 for VM databases. Use the ACFSERVE command to take manual backups. To back up all the databases, issue the ACFSERVE BACKUP command. You can back up any or all CA ACF2 for VM databases manually. By default, CA ACF2 for VM uses the names in the @DDSN macro, specified in the DDSNID= operand of the BACKUP VMO record. You can specify the name of the @DDSN macro for the filenames you are using to override this default.

To back up all databases using the filenames from the BKWEEKLY @DDSN macro, issue the ACFSERVE BACKUP BKWEEKLY command. To back up only the Logonid database using the filenames from the BKWEEKLY @DDSN macro, issue the ACFSERVE BACKUP BKWEEKLY LID command.

After the ACFSERVE BACKUP command successfully completes, the post backup service machine is autologged if you specified one in the AUTOLOG operand of the BACKUP VMO record.

Disabling the Automatic Backup Facility

You can disable the CA ACF2 for VM automatic backup facility if necessary. CA ACF2 for VM continues functioning normally, even if the alternate databases are not available when automatic backup is initiated. However, there would be a series of error messages to indicate that the backup failed.

The procedure for disabling the automatic backup facility is shown below. After the facility is disabled, you cannot activate it again until you IPL CA ACF2 for VM. To deactivate the CA ACF2 for VM automatic backup facility

  1. IPL VM according to your site's procedures.
  2. Watch for the following message:
    ACFpgm000R Enter ACF2 startup options or press Enter
    
  3. When it appears, enter this command:
    NOBACKUP
    

    Press Enter to disable the backup facility.

    ACFpgm000R Enter ACF2 startup options or press Enter nobackup

    VM is now running normally. However, no automatic backup of the databases is taken. You can still use the ACFSERVE command to take manual backups. See the Taking a Manual Backup section for information about doing manual backups.

Post Backup Service Machine

Use the post backup service machine to build copies of the database that you can run after a backup.

Post Backup Service Machine Execs

CA ACF2 for VM supplies three sample execs for configuring the post backup service machine and rebuilding the databases:

ACF2PBSM SAMPEXEC

This exec is the CA ACF2 for VM Post Backup Service Machine SAMPEXEC. It initiates the database rebuild process. You have to customize it to your local environment and rename it PROFILE EXEC. Then place it on the post backup service machine 191 minidisk.

This exec processes the program stack and initiates the RESTCMS or RESTVSAM EXECs. When you customize the exec, you should ensure that the appropriate exec is invoked depending on whether you are rebuilding CMS or VSAM CA ACF2 for VM databases.

CA ACF2 for VM autologs the post backup service machine at the end of the backup. You can either schedule an automatic backup or manually initiate a backup with the ACFSERVE BACKUP command. A scheduled backup backs up all three CA ACF2 for VM databases of the active database set. A manual backup backs up one database or a combination of databases in any set defined in the @DDSN macro in the ACFFDR.

When the post backup service machine is autologged, the program stack contains information about which databases were backed up, what database set they belonged to, and what VM user ID initiated the backup if the ACFSERVE command invoked it. The program stack has a line of data in it in the following form:

LIDOPT RULEOPT INFOOPT invoker DDSN ddsnname.

The variables for the data are described below.

LIDOPT

LIDDB if the LID file was backed up.

NOLID if the LID file was not backed up.

RULEOPT

RULEDB if the RULE file was backed up.

NORULE if the RULE file was not backed up.

INFOOPT

INFODB if the INFO file was backed up.

NOINFO if the INFO file was not backed up.

invoker

SYSTEM, if the backup was automatic.

USERID that issued the command, if the backup was manually generated.

DDSN

The keyword indicating the ACFSERVE BACKUP command was invoked with an alternate DDSN name (optional).

ddsnname

The name the user specified when issuing the ACFSERVE command (optional).

RESTCMS SAMPEXEC

Sample exec for restoring alternate CMS databases. This exec rebuilds copies of the databases.

RESTVSAM SAMPEXEC

Sample exec for restoring alternate VSAM databases, and also rebuilds copies of the CA ACF2 for VM databases. This exec, in turn, calls the following sample execs:

These sample execs perform the IDCAMS DELETE and DEFINE functions for each VSAM database. There are also three AMSERV control statement files, one each of the above DDEFxxx sample execs uses:

You must rename all of the above sample exec files to have a filetype of EXEC. You must rename all of the SAMPAMS files to an AMSERV filetype. Modify VOL IDs, data set names, minidisk addresses, and VSAM extents to tailor each of these files.

For more information on the post backup service machine, see Installation Guide.