Fast/Backup
Fast/Backup is a plug-compatible replacement for the DUMP and RESTORE commands provided with Model 204. The Fast/Backup add-on combines the functional appeal of the Model 204 backup program with the speed of a system backup utility such as IBM's DF/DSS®.
As of Model 204 7.5, the Fast/Backup modules are linked into the Online. If you are authorized to use Fast/Backup, a Model DUMP command invokes Fast/Backup. If you are not so authorized, a DUMP command executes the standard Model 204 code for dumping a file. The same is true for RESTORE.
Prior to Model 204 7.5, Fast/Backup was installed as part of the Sirius Mods, and no Sirius Mods products were required to run Fast/Backup other than itself.
Using Fast/Backup under z/OS
Fast/Backup supports the same command structure as the Model 204 DUMP and RESTORE commands. Fast/Backup also provides the additional options described below in Fast/Backup options.
Fast/Backup acquires its own database buffers to avoid impacting Model&n|bsp;204 buffer pool performance. The storage is acquired "above the line" in XA and ESA environments.
A special subtask is created for Fast/Backup under z/OS to avoid delays in the Online environment due to tape volume mounts.
You can set the DUMPTMIN and DUMPTMAX parameters to optimize dumps in an updating environment. Normally, updating transactions are delayed while second or subsequent tape volumes are mounted during a DUMP. But Fast/Backup writes updated pages to CCATEMP while waiting for a volume mount. This allows updating transactions to continue, since a pre-image page is immediately logged in CCATEMP. As soon as the tape volume becomes available, the CCATEMP pages are written to it and freed.
DUMPTMIN sets the minimum number of CCATEMP pages that must be available when Fast/Backup requires one for pre-image logging. DUMPTMAX sets the maximum number of pages a single DUMP can use. You can set the DUMPOPTS flag to indicate the action to take if either of these page limits are violated:
| Flag | Action |
|---|---|
| X'00' | Wait. This causes the DUMP process to wait for the volume mount, which forces any updating transactions to wait also. |
| X'80' | Cancel. This terminates the DUMP immediately (any other dumps in progress continue). |
Fast/Backup automatically selects the best possible blocksize for the sequential data set. Unless you have special restrictions or considerations, do not code a BLKSIZE parameter on your DD statement or in your ALLOCATE command.
If, for any reason, you want to use standard Model 204 DUMP or RESTORE after you have installed Fast/Backup, you can do so by changing your DUMP commands to DUMPX, and your RESTORE commands to RESTOREX. These commands will invoke the standard DUMP and RESTORE functionality.
Using Fast/Backup under CMS
Fast/Backup supports the same command structure as the Model 204 DUMP and RESTORE commands. Fast/Backup also provides the additional options described below in Fast/Backup options.
Fast/Backup acquires its own database buffers to avoid impacting Model 204 buffer pool performance. The storage is acquired "above the line" in XA and ESA environments.
Fast/Backup automatically selects the best possible blocksize for the sequential data set. Unless you have special restrictions or considerations, do not code a BLKSIZE parameter on your DD statement or in your ALLOCATE command.
If, for any reason, you want to use standard CCA DUMP or RESTORE after you've installed Fast/Backup, you can do so by changing your DUMP commands to DUMPX, and your RESTORE commands to RESTOREX. These commands will invoke the standard Model 204 commands.
Fast/Backup does not support DUMP or RESTORE for database files that reside on a CMS minidisk. DUMP or RESTORE will revert to the standard Model 204 routines in this case.
Performance considerations
Fast/Backup examines the device type and allocation of the database files before allocating I/O buffers. Fast/Backup attempts to use full cylinder I/O whenever possible, but any physical extents in the database that are not cylinder aligned are read a track at a time. Thus, you can maximize the performance of Fast/Backup by ensuring that all database extents are allocated on cylinder boundaries.
Fast/Backup reads and writes full tracks or cylinders in each database I/O operation, and requires two database I/O buffers to achieve best performance. For 3380 devices this means that 1.3 Megabytes of "above the line" storage is required for the database buffers. You may need to adjust the size of your region before using Fast/Backup.
The NBUFF option (described below in Fast/Backup options) sets the number of sequential I/O buffers for the DUMP or RESTORE operation. You should set this value as high as possible to avoid sequential I/O bottlenecks, but this storage is allocated for use by BSAM and must be "below the line," except in DF/SMS environments. Setting NBUFF too high can induce high paging rates if corresponding real storage is not available, or it can exhaust free storage in the Online.
Fast/Backup options
| NBUFF | NBUFF sets the number of sequential I/O buffers for BACKUP or RESTORE. Code the NBUFF keyword after the DUMP or RESTORE command. For example:
RESTORE 192 FROM TESTFILE NBUFF 50 Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20,and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive. NBUFF is automatically set to: pagesize * 180 / blocksize | ||||
|---|---|---|---|---|---|
| DUMPTMIN | This user resettable system parameter sets the minimum number of free CCATEMP pages that must be available for DUMP to use for pre-imaging when waiting for second or subsequent tape volume mounts. | ||||
| DUMPTMAX | This user resettable system parameter set the maximum number of CCATEMP pages any individual DUMP can use. | ||||
| DUMPOPTS | This user resettable system parameter sets system-wide DUMP options.
|