| FDRABR SUPPORT FOR ALLOWUSERKEYCSA(NO) IN Z/OS 1.8 |
In z/OS 1.8 there is a new PARMLIB option VSM ALLOWUSERKEYCSA(YES|NO). This option controls
the ability of a program to GETMAIN CSA in key 8. The default is YES (allow the GETMAIN) but you
may choose to set it to NO (NO is the default in z/OS 1.9 and above).
ABR Auto-Recall used to GETMAIN a CSA area in key 8 but it has been modified so that it no longer does
so. ABR customers who install z/OS 1.8 and specify VSM ALLOWUSERKEYCSA(NO) in PARMLIB must install
FDRABR V5.4 level 60; otherwise ABENDs will occur during auto-recall. |
| AUTOMATIC QUIESCE OF ZFS FILES |
If HFS=QUIESCE is specified in FDR, FDRDSF or FDRABR steps, any zFS files which are dumped
will also be automatically quiesced during the backup or copy, just as is currently done for HFS
files. However, this only works for FDRINSTANT (where the main control statement is SNAP,
FCOPY, PSPLIT, or SPLIT). |
| EMC SNAP IMPROVEMENTS |
FDRINSTANT volume backup has been enhanced when TimeFinder/Clone (SNAP) is used on EMC disk
subsystems to do instant replication of volumes to offline disks.
Performance improvements have been made in the FDRINSTANT SNAP code. You should insure that
you have the latest version of the EMC TimeFinder/Clone software installed, since some of the
improvements are in the EMC code. Some bugs have also been fixed by EMC; SNAP operations may
fail if you are running with back-level EMC software.
There is a significant improvement in the CONSNAP (Consistent SNAP) function for ABR
full-volume operations. CONSNAP will usually be faster than SNAP for ABR volume backups.
If SNAP=(USE,RET) is specified on the DUMP statement, the snapped volumes will be left in a
differential SNAP “pre-copy” state, where tracks that are updated on the source disk
are immediately copied to the target disk, maintaining the target as a current copy of the
source disk. When the SNAP command is executed, it may be faster since the SNAP target disk
just needs to be frozen. This is similar to the way that BCVs work. This also improves
backup performance since all data tracks are already on the target disk when the DUMP
is executed.
The differential SNAP (which was already supported when SNAP=USE was specified),
insures that only updated tracks are copied, which improves performance. However,
the very first SNAP to a given offline target disk will need to copy the entire volume,
which may impact performance of the first DUMP of the volume if run too soon after the SNAP. |
| VTOC PROCESSING IMPROVEMENTS |
Changes have been made to improve the performance of VTOC operations in all FDR
and FDRABR backups and restores, as well as FDRCOPY dataset copy and move.
In most cases, FDR used to read the entire VTOC on the input volume for backups
and the output volume for restores, but it now uses an IBM service to identify
the end of active data in the VTOC and read only to that point (plus a few tracks
for safety). Since many customers are allocating large VTOCs for today’s larger
devices, such as the 3390-27 and 3390-54, this may significantly reduce the VTOC
read time.
Also, more efficient CCW chains are used to access the VTOC data, which may also
reduce the VTOC time.
Although this improvement affects all FDR and FDRABR backups and restores, the
improvement will be most noticeable in FDRCOPY with FDRINSTANT, where instant
replication techniques such as SNAP and FlashCopy are used to copy the data.
In this case, the VTOC times could be a significant part of the total step elapsed
time, and the changes may result in significant reductions. |
| FDRCOPY IMPROVEMENTS |
FDRCOPY used to process only one input disk volume at a time, although the
copied datasets could be allocated on multiple output volumes.
Now, a new operand MAXTASKS=n (n=1-5) allows FDRCOPY to process up to 5 input
volumes concurrently, which will usually improve elapsed time when copying or
moving datasets from multiple volumes. However, if MAXTASKS is greater than 1,
the SELECT statements in the step must specify CATDSN= to select the input datasets.
MAXTASKS= will improve FDRCOPY performance when doing real I/Os to copy the data,
but the most significant improvement will be with FDRCOPY with FDRINSTANT
(FlashCopy or SNAP). |
| FDRCOPY IMPROVEMENTS |
FDRCOPY used to process only one input disk volume at a time, although the
copied datasets could be allocated on multiple output volumes.
Now, a new operand MAXTASKS=n (n=1-5) allows FDRCOPY to process up to 5 input
volumes concurrently, which will usually improve elapsed time when copying or
moving datasets from multiple volumes. However, if MAXTASKS is greater than 1,
the SELECT statements in the step must specify CATDSN= to select the input datasets.
MAXTASKS= will improve FDRCOPY performance when doing real I/Os to copy the data,
but the most significant improvement will be with FDRCOPY with FDRINSTANT
(FlashCopy or SNAP). |
| FLASHCOPY IMPROVEMENTS |
FDRINSTANT has been enhanced when FlashCopy is used on IBM and Hitachi disk
subsystems to do instant replication of volumes and datasets. FDRINSTANT
used to invoke an IBM API for FlashCopy functions. Now it issues the FlashCopy
commands to the control unit directly in most cases. This can provide a
significant performance enhancement, especially for full-volume Flashes. |
