Testing the FDR System

This section provides guidelines for testing various components of the FDR system. Use these guidelines to create and execute a test plan for testing the new version of FDR, testing the FDR components that you have installed.

At this point, customers with ABR can test everything except functions requiring the ABR Operating System Exits, primarily auto-recall of archived data sets, and automatic restore from backup of scratched data sets. Customers with FDRREORG can test everything except transparent intercept of IEBCOPY compress requests. Instructions for testing these functions with the new exits are in Testing-the-FDR-z-OS-Exits.

All of the example job streams shown in the various sections of this manual may be found in the JCL library loaded as part of the FDR installation. The member names include the section number of the manual in which the example is found so that you can easily find an example that you see in the manual.

Testing FDR, FDRDSF, and FDRCOPY

New installations

You can test the basic functions of backup, restore, and copy/move with simple batch job streams. If FDR has not yet been installed in the system link list (LNKLST), a STEPLIB DD statement must be used to point to the FDR library.

Existing installations

You can test the basic functions of backup, restore, and copy/move with simple batch job streams. A STEPLIB DD statement must be used to point to the FDR library.

FDR full-volume backups and restores can be tested using the sample job streams found in FDR-Fast-Dump-Restore. You can backup any volumes you like (FDR backups make no changes to the input volume) but if you backup live data, be sure you restore to a spare scratch volume with the CPYVOLID=NO operand to preserve the output volume serial and avoid back-leveling the live volumes.

Important

The CPYVOLID=NO restore creates uncataloged copies of the restored data sets; non-VSAM data sets can be accessed by specifying the volume serial of the scratch volume but VSAM clusters on the scratch volume will not be usable.

FDRDSF data set backups and restores can be tested using the sample job streams found in FDRDSF-Data-Set-Functions. You can backup any data sets you like (DSF backups make no changes to the input data sets) but if you backup live data, be sure that you restore data sets to new names (the NEWNAME= or NEWINDEX= operands on the SELECT statement) to avoid back-leveling the live data sets. You may wish to test restoring individual data sets with FDRDSF from full-volume backup tapes created by FDR. You may want to browse the restored data sets or run other programs to verify their contents.

You may want to test backup to and restore from backup data sets on DASD as well as backups on tape.

Important

FDR and FDRDSF use the same backup and restore modules that are used internally by ABR backups and restores, so by testing FDR and FDRDSF you are also testing much of the code used by ABR.

You can test FDRCOPY COPY and MOVE of data sets using sample job streams found in FDRCOPY-Copy-or-Move-Data-Sets. You can copy any data sets you like (COPY makes no changes to the input data set) but be sure to specify new output names (the NEWNAME= or NEWINDEX= operands on the SELECT statement). MOVE tests should be done on data sets specially created for the test since MOVE scratches the input data set; you might use COPY to create test data sets for MOVE. You may want to browse the copied data sets or run other programs to verify their contents.

Testing FDRREORG

New installations

You can test all functions of FDRREORG except transparent intercept of IEBCOPY compress requests. If FDR was not installed in the link list (LNKLST), a STEPLIB DD statement should be used to point to the FDR library.

Existing installations

You can test all functions of FDRREORG except transparent intercept of IEBCOPY compress requests. A STEPLIB DD statement should be used to point to the FDR library containing the new version.

You can test the FDRCOPY REORG function, to unconditionally compress PDSs, using the sample job streams found at the end of FDRCOPY-Copy-or-Move-Data-Sets. The SIMREORG statement can be used to simulate compression of any PDSs, reporting on the results that would be accomplished by a real compression. You can also execute a live REORG against test data sets.

Important

An FDRCOPY COPY of a PDS will copy that PDS in its existing state, without reorganizing it, so you can copy PDSs needing compression, and then test the REORG of that copy. Compare utilities (such as IEBCOMPR or ISPF option 3.12) can be used to verify that the members are unchanged after the compression.

You can test the FDRREORG functions using sample job streams found in FDRREORG-Examples (FDRREORG). The SIMULATE (SIM) statement of FDRREORG can be used to simulate reorganization.

Important

SIM normally only reports on the data sets it would select for reorganization. You can specify the SIMPDSCOMP operand on the SIMULATE statement to invoke FDRCOPY to do a SIMREORG of any selected PDSs. You can also do a real REORG with the NOREORG operand; this will cause FDRREORG to actually read and create backups for selected VSAM and IAM data sets but not to read those backups back for reorganization, thus testing the backup process.

Actual reorganizations should be tested with care, selecting data sets or volumes that have backups or can be recreated, if necessary.

Testing SAR

Many installations neglect to test Stand Alone Restore (SAR). It is the most awkward component of FDR to test, but when SAR is required to recover from a hardware failure or disaster, it may be the most critical component.

Before scheduling an SAR test, you should create a non-labeled tape containing SAR, and place IPLable copies of SAR on one or more DASD volumes, using the instructions in Load-SAR-onto-DASD or Stand-Alone-Loader-Utility.

SAR must be tested on a dedicated CPU or LPAR, so test time will probably have to be scheduled. SAR can also be tested on a VM virtual machine, but unless this is the environment that SAR will actually be used, it is not recommended since it may not reflect your real recovery environment that SAR will face.

Follow the instructions in SAR-Stand-Alone-Restore for loading and executing SAR. You should test the full-volume backup and restore functions of SAR. You will probably want to be sure that SAR can restore from a tape created by FDR, and that FDR can restore from a tape created by SAR.

Important

FDRDSF can restore non-VSAM data sets from an SAR full-volume backup, but not VSAM clusters

Be sure to restore your test backups to spare (scratch) output volumes. During the SAR restores, you can specify the CPY=N option (equivalent to the FDR CPYVOLID=NO operand) to preserve the output volume serial during the restore.

Testing COMPAKTOR

New installations

You can test all functions of COMPAKTOR. If FDR was not installed in the link list (LNKLST), a STEPLIB DD statement should be used to point to the FDR library.

Existing installations

You can test all functions COMPAKTOR. A STEPLIB DD statement should be used to point to the FDR library containing the new version.

You can test COMPAKTOR using sample job streams found in COMPAKTOR-Examples. Most COMPAKTOR functions can also be tested using the A.C (COMPAKTOR) and A.R (RELEASE) options on the FDR Primary Options Menu panel.

All COMPAKTOR functions except MAP can be simulated with the SIMULATE (SIM) statement. SIMULATE reports on exactly what volume changes will be made by the equivalent real COMPAKTOR function; for a FAST COMPAKTion (FASTCPK) it also estimates the elapsed time of the real function (based on the number of tracks that must be moved).

Testing ABR

New installations

You can test all functions of ABR except functions requiring the ABR Operating System Exits, primarily auto-recall of archived data sets and automatic restore from backup of scratched data sets. However, you can create ABR backups and ARCHIVEs now that can be used when testing the exits later (Testing-the-FDR-z-OS-Exits). If FDR was not installed in the link list (LNKLST), a STEPLIB DD statement should be used to point to the FDR library.

Existing installations

You can test all functions of ABR except functions requiring the ABR Operating System Exits (but some functions may work with your existing exits). Take care that the ABR functions being tested do not affect your production ABR environment; this is especially important for full-volume and incremental backups since any backups you create of volumes currently being backed up by ABR will become part of the production ABR system. This is not a problem for ABR application backups. ARCHIVEs can be tested using a separate Archive Control File. A STEPLIB DD statement should be used to point to the FDR library containing the new version.

Testing ABR volume backups

ABR volumes backups can be simulated (SIM statement). This shows you the volumes and data sets that will be processed. However, since no actual backup is performed, this cannot be used to test the actual operation of incremental backups. A SIM of a volume that has never been actually processed by ABR volume backup always simulates a full-volume backup.

Full-volume and incremental backups can be tested using the sample job streams found in FDRABR-Volume-Backups. You probably want to setup a few special test volumes for these tests. Initialize the volumes for ABR processing using panel A.I.8 (Set-ABR-Disk-Volume-Processing-Options); be sure to enable OLDBACKUP.

The first backup of each test volume must be an ABR full-volume backup (DUMP TYPE=FDR). Actually, the full-volume backup is forced if you try to do an incremental backup. Incremental backups (TYPE=ABR or TYPE=AUTO) can be executed after that. In addition, incremental backups are usually executed once a day, you can execute as many as you like on any day to simulate the normal operation of ABR.

You probably want to update a number of data sets on the volumes between each backup; otherwise, incremental backup will have nothing to do. You can do this with ISPF EDIT or any other program that opens files for output.

You may want to execute enough cycles of full and incremental backups to verify that the old ABR generations are uncataloged from the ABR cataloged (based on the GEN value used to initialize the volume).

You will want to test data set restores and full-volume recoveries. Data set restores can be executed in batch (using sample job streams from FDRABR-Volume-Backups), but they can also be executed from the FDR ISPF dialogs, using either the ABR RESTORE panel (A.2) or the SRS dialog (A.S) which allows you to display the backups available for data sets and restore any of them.

Testing ABR application backup

ABR application backup (TYPE=APPL) is easy to test, since the backups can be run against any data sets or volumes. Application backup has no effect on the data sets backed up so you can test against live data. There are no special initialization requirements. The sample job streams in FDRAPPL-Application-Backup can be used to setup tests.

When restoring from application backup tests, you should probably restore to new names (using the NEWINDEX= operand on the SELECT statement) and may want to direct the restored data sets to new volumes (the NVOL= operand) to avoid overlaying any live data.

Testing ABR archive and Superscratch

ABR ARCHIVE (TYPE=ARC) and Superscratch (TYPE=SCR) should be tested against data sets and volumes created especially for the test, since both functions will scratch the data sets from the DASD volumes. The job streams in FDRABR-Archiving-and-Superscratch can be used to setup tests.

For existing customers with archiving already in production, you should setup an Archive Control File just for testing, to avoid mingling test records with live records in the normal control file. The test control file can be created using ISPF panel A.I.9 (Create-the-Archive-Control-File); the name of the control file is set in the FDR Global Options in the test FDR program library (panel A.I.4.5, ABR-Options) so that the DYNARC operand of ABR can be used. This control file can also be used for auto-recall testing when testing the ABR exits as in Testing-the-FDR-z-OS-Exits.

You can test Superscratch by creating some test data sets (VSAM and non-VSAM) and then selecting them in a DUMP TYPE=SCR test. The data sets should be deleted and uncataloged.

You can test ARCHIVE by creating some test data sets (VSAM and non-VSAM) and then selecting them in a DUMP TYPE=ARC test. The data sets should be backed up, recorded in the Archive Control File, deleted and uncataloged (except that if you run with the RECALL=YES option specified or defaulted, they will remain cataloged with a special auto-recall indicator; if you also specify or default to MIGRAT=YES, the volume serial in the catalog is changed to MIGRAT).

You should test ARCHIVE with the backups directed to tape, and to DASD.

You can then test restoring some of the archived data sets, both singly and collectively (several together), restoring from DASD and tape backups. You can submit batch job streams to restore (using examples from FDRABR-Archiving-and-Superscratch) or you can use the FDR ISPF dialogs using either the ABR RESTORE panel (A.2) or the SRS dialog (A.S) that allows you to display the ARCHIVEs available for data sets and restore any of them.

You should also test the FDRARCH REORG function (FDRARCH-REORG-Statement) to reorganize the Archive Control File. You can use the FDRARCH MODIFY statement to change the recorded expiration dates of a few of your archived data sets (or the DELETE statement to flag them for deletion), so that you can see the REORG operation deleting the records and reclaiming the space.

Testing FDREPORT

You may want to test FDREPORT, the generalized reporting program. FDREPORT makes no changes to any input volume, so you can run any reports you desire. The examples in FDREPORT-Generalized-Report-Writer can be used, but you may also want to use the BMC Corporation Health Check job streams in the FDR JCL Library, member names HCHECKx, both to test FDREPORT and to give you valuable information about your DASD system (see FDREPORT-Health-Check for more information).

The SRS (Search, Report, Services) ISPF dialog (panel A.S) uses FDREPORT internally for most of its information gathering. You can execute a variety of SRS displays to test both SRS and FDREPORT. SRS is described in FDRSRS-Search-Report-and-Services-Dialog.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*