FDR functions and features

This section documents many of the features and characteristics that are common to all or almost all FDR components. The term “FDR” in this section refers to all the FDR components.

Operating system support

FDRsupports all versions of z/OS, including z/OS 2.4. They are referred to collectively as z/OS in this manual. All functions described in this manual work on all versions of the operating system, except where a certain level of z/OS is required for support of a particular device type or data set type. If new versions of z/OS require changes in FDR, those changes are available at GA (General Availability) of the new release. Refer to BMC Latest Product Release Information web page for the current releases of the operating system supported by FDR products.

FDR runs on a sysplex, including a Parallel Sysplex, but does not use or require any sysplex services.

Tape device support

FDR supports all current tape types supported by the z/OS versions supported.

Encrypted data set support

System services that manage the data set (as opposed to the data) ensure that data remains in encrypted form:

• During FDR functions, COPY, DUMP, and RESTORE
• During FDRABR functions, ARCHIVE, BACKUP, and RESTORE
• During reorganization functions, FDRCPK and FDRREORG

Error processing

During backup and restore operations, FDR continually analyzes the processing and reports any unusual conditions detected. Physical and logical errors are handled, including:

• Physical I/O errors reported by the DASD hardware, such as data checks. FDR prints out details on the error and on the I/O being executed.
• Physical I/O errors on the backup data set (DASD or tape). FDR prints details of the error. For tape, it will attempt to close the current tape and write the failed data to a new tape volume; depending on the nature of the tape error, this may not be possible.
• Invalid DASD track format, including non-standard or invalid Record 0 (R0) format. This usually indicates a data track that does not meet IBM standards and cannot contain useful data so the track will not be written to the backup.
• Incorrect count fields where the CCHH (cylinder and head number) in the count field of a record does not match the physical CCHH of the data track. Since this is not necessarily an error (VM-formatted volumes containing mini-disks may have this condition), the number of such tracks is simply counted.
• I/O errors in the VTOC, including physical errors and logical errors such as the wrong number of DSCBs on a track. VTOC errors always terminate data set backups; for full-volume backups it forces FDR to backup all physical tracks on the volume.
• I/O errors in the VVDS. The backup continues but VSAM and SMS-managed data sets may not be able to be restored.

On RAID-based subsystems and cartridge tape drives, physical I/O errors are rare. Almost all error recovery is done in the DASD or tape control unit, and recovered errors are never even presented to FDR.

VSE volumes

VSE (DOS) volumes are similar to z/OS volumes, but may not follow all of the same rules. Any VSE volume that can be mounted to operating system can be dumped or restored with FDR or FDRDSF. However, ABR functions should not be used.

 VM volumes

FDR and ABR can dump and restore volumes belonging to a VM system, both from z/OS systems running as VM guests, and from independent z/OS systems that can access the DASD drives in use by VM. There are several variations that you must be aware of:

• If the volume was formatted by VM (such as VM residence, spool or paging volumes or volumes containing CMS mini-disks), the volume contains a dummy z/OS VTOC on CYL 0 TRK 0 so that it can be mounted on z/OS systems. Since a z/OS-formatted VTOC never starts at that location, FDR recognizes that dummy VTOC and automatically dumps or restores all of the physical tracks on the DASD. Since there are no data sets in that VTOC, DSF can only do ABSOLUTE TRACK ADDRESS operations on such volumes. An individual CMS formatted mini-disk may be restored from an FDR or DSF full-volume backup if you know its extents on the volume, but only to its original DASD locations; DSF cannot be used to move CMS mini-disks.
  • COMPAKTOR operations cannot be done on such DASD.
  • Other FDR functions can be done by an independent z/OS system.
  • FDR functions cannot be done by a z/OS guest under VM since it cannot access the full VM volume.
• If the volume is defined as several mini-disks (with the first mini-disk starting at physical cylinder 0) and each is formatted as a z/OS volume:
  • All FDR functions can be executed against each mini-disk by a z/OS guest running under VM. The z/OS virtual machine must have each mini-disk defined as a device.
  • From an independent z/OS system, z/OS sees only the first mini-disk on the physical volume (it is possible to use DSF physical track processing to include the additional mini-disks, but this is not recommended).
• If the volume is defined as z/OS mini-disks, but the first mini-disk starts on physical cylinder 1 or later,:
  • An independent z/OS system treats it as a VM-formatted volume and backs up/restores all physical tracks
  • For a z/OS guest under VM, each mini-disk should be defined to the z/OS system so it can be processed normally.
• If the volume is defined as a full-volume z/OS-formatted DASD volume, it can be processed normally from either a z/OS guest (where the DASD device must be dedicated/attached or defined as a full-volume mini-disk) or from an independent z/OS system.

Stand Alone Restore (SAR) has the ability to do backups and restores on any VM virtual machine without an operating system. You must IPL SAR on a virtual machine just like you IPL CMS or z/OS. SAR can process individual mini-disks (OS or CMS formatted) if they are defined to the virtual machine, and can be used to move a mini-disk to another of the same size (SAR absolute track operations are used for CMS mini-disks). For more information see Working-with-SAR.

 Linux volumes

FDR supports volumes formatted for Linux on S/390 or IBM Z® processors. Linux volumes come in two types:

• Original Disk Layout (ODL) volumes were the only type supported prior to Linux V2.4. ODL volumes cannot be mounted z/OS systems. However, if the DASD devices are accessible, although offline, you can do full-volume backups and restores from your operating system using FDRINSTANT.
• Compatible Disk Layout (CDL) volumes are supported in Linux V2.4 and beyond; CDL is the default layout in those systems. CDL volumes have a volume serial and a VTOC so they can be mounted on z/OS systems. You can do full-volume backups and restores with normal FDR. CDL volumes can be divided into up to 3 partitions (file systems) each of which appears to be a data set in the VTOC, so you can backup and restore individual partitions with FDRDSF.

Linux volumes of either type that are mini-disks on a larger VM volume can be backed up and restored with FDR and FDRDSF (see VM Volumes).

Member LINUX in the FDR Installation FDRSAMP has additional notes on Linux volumes.

ABR support for z/VM and Linux DASD

ABR supports full-volume backup and restore for z/VM volumes in CPVOL format, and for Linux full-volume DASD in CDL (Compatible Disk Layout) format. Previously, these volumes could be backed up only by FDR. Details are in ABR Backup of VM and Linux Volumes. The advantages of using ABR include:

• simpler JCL
  • no need for a separate DISKx and TAPEx DD statement for each volume
  • backups can be automatically stacked on multi-file tapes without special JCL
• uniformity of backups; if MVS volumes are backed up by ABR, VM and Linux volumes can be brought into the same system
• VM and Linux volumes can be included in ABR backup reports
• VM and Linux volumes can be included in FDRDRP restores, for faster and easier disaster recovery

FDRINSTANT backups can be used for VM and Linux volumes under either FDR or ABR.

Changing the VOLSER or VTOC during restore

If a full-volume RESTORE or COPY changes the volume serial of the output volume or changes the location of the VTOC or Indexed VTOC, FDR automatically updates the proper operating system control blocks and pointers with the new information, on the operating system it was executed on. If the new volume serial duplicates the serial of another online volume, the output DASD volume is placed offline and a warning message issued to the operator.

E-mail messages

Many FDR programs support sending automatic e-mail messages when an FDR operation fails, and optionally when it is successful. The messages are sent via TCP/IP to a SMTP-compatible mail server. Messages can be sent to regular e-mail recipients and also to text-enabled pagers and cell phones.

This might be used to automatically notify operators, technical support personnel, or storage management personnel when failures occur. E-mail is supported in FDR, FDRDSF, FDRCOPY, and FDRABR.

Supported data set types

FDR supports backup and restore of all types of data sets that can reside on DASD on supported operating systems, including:

• Physical Sequential (PS)
• Partitioned (PDS)
• Direct Access (DA)
• VSAM (ESDS, KSDS, RRDS, VRRDS, Linear, Alternate Indexes (AIXs))
• DB2 data files and catalogs
• Innovation Access Method (IAM) – an alternate to VSAM KSDS and ESDS
• Partitioned Data Set Extended (PDSE) – an alternate to PDSs
• Physical Sequential Extended (PSE) – Extended format PS data sets on SMS-managed volumes (may be striped and/or compressed)
• Extended Format KSDS VSAM – on SMS-managed volumes, may be compressed and may exceed 4GB in size
• Large Format data sets
• Hierarchical File System (HFS) – used with UNIX System Services (USS). FDR can backup/restore entire HFS data sets but not individual files within the HFS data set
• zSeries File System (zFS) – also used with UNIX System Services (USS) and are functionally similar to HFS files.

See FDR Processing by Type of Data  for details on the FDR support for these various data set types.

Object Access Method (OAM) stores of collections of data called “objects” (such as scanned images). OAM files may exist on DASD or on optical storage DASD. OAM files on DASD are DB2 files, which are supported by FDR.

SMS support

FDR supports backup and restore of volumes and data sets that are under the control of System Managed Storage (SMS). This includes those data sets that must be SMS-managed, such as extended format sequential data sets and VSAM clusters. See Working-with-System-Managed-Storage for the special considerations in using FDR, DSF, and ABR with SMS-managed volumes.

zEDC support

The FDR system supports compression and decompression using IBM zEnterprise Data Compression (zEDC). zEDC is an optional compression accelerator on z12, x13, and z14 CPUs, designed for fast compression with low CPU overhead. FDR and ABR backups invoke zEDC if the CPU and the operating system support it and both the ZEDC=YES and COMPRESS= operands are specified. zEDC may reduce elapsed time and CPU time and use less space on disk than FDR software compression. It may even use less tape than IDRC. For more information, see Working-with-FDR.