Additional considerations and restrictions for FlashCopy

To use FlashCopy Version 2 with XBM, you must meet the following requirements:

  • For the operating system, the DFSMS level must be OS/390 2.10 or z/OS 1.3 (or later) and all appropriate IBM maintenance must be installed.
  • You must configure XBM with the security authority to create and delete the database objects upon which you are performing hardware snapshots.
  • For FlashCopy Version 2, you must ensure that all IBM-provided APARs that enable FlashCopy version 2 to support data-set-level operations have been applied. FlashCopy Version 2 did not initially support the data-set-level operations that XBM requires to perform hardware snapshots. These IBM APARs provide the required operations, such as copying to an existing data set.

Related topic

Setting-up-the-hardware-environment

The following restrictions exist when using XBM with FlashCopy to produce data-set-level snapshots:

  • Hardware snapshot processing uses the FASTREPLICATION(REQUIRED) keyword when the SSI option or the value supplied by the utility for DATAMOVER(.....) has a value of NONE or nulls. If the value is something other than NONE or nulls, hardware snapshot processing uses the FASTREPLICATION(PREFERRED) keyword.

Important

PTF BPE0316 changed the functionally of the XBM SET DATAMOVER option. The DATAMVR parameter of the snapshot-enabled utility now overrides the XBM SET DATAMOVER option entirely.

The default value of the DATAMVR parameter of snapshot-enabled utility is NONE if it not used. Therefore, if the snapshot-enabled utility does not request to use the DATAMVR feature, any XBM SET DATAMOVER option is ignored and is not used. If the utility issues the DATAMVR parameter, the XBM SET DATAMOVER option is overridden and the DATAMVR setting of the utility is used (FDR, DSS, and so on.).

  • You must be able to use the DFSMSdss COPY command with FASTREPLICATION(REQUIRED) keyword in batch mode to use FlashCopy.

The following functional IBM restrictions currently affect FlashCopy use:

  • FlashCopy requires all volumes containing target data set extents to reside in the volume list. XBM adds the required volumes if necessary.
  • All source volumes in a multiple-volume data set must reside within the same IBM Shark, Hitachi, or EMC enclosure. This restriction applies to System Managed Storage (SMS) and non-SMS managed data sets.
  • The ESOTERIC unit parameter is not supported.
  • The SMS classes of the data source and target volumes can affect the expected results, as shown in the following table:

SMS class results

Source

Target

Description

SMS source

SMS target

  • The default class is in the same SMS class as a source.
  • The snapshot options, supported utility, or Automatic Class Selection (ACS) routines can specify an alternate SMS class.

Non-SMS target

  • A non-SMS target is supported only if a target data set already exists. The snapshot uses existing extents.
  • If the target data set does not exist, the snapshot ignores the volume list and the target is in the same SMS class as the source.

Non-SMS source

SMS target

The class is specified through an XBM or utility input or through ACS routines.

Non-SMS target

  • If a target data set does not exist, the snapshot uses the user-supplied or XBM-supplied volumes.
  • If the target data set exists, the snapshot adds the volumes of the target data set to the volume list.
  • If an existing target is in a different storage enclosure, the snapshot fails.

When you set up an XBM subsystem to process hardware snapshots with any of the supported hardware devices (regardless of vendor), BMC recommends that you disable volume allocation or volume pooling software to avoid their affecting XBM. Because XBM is a long-running task and because of the way that FlashCopy processes hardware snapshots, any products that manage storage allocations might accrue excessive entries over time if you do not disable allocation control for XBM.

An example of such products is the BMC AMI Storage product. To prevent BMC AMI Storage from changing the snapshot allocations, specify the following DD statement in the XBM started task:

//PROIGN DD DUMMY

For more information about controlling allocation, see the BMC AMI Storage documentation or the documentation for your volume allocation or pooling software.

You can use XBM with FlashCopy to produce hardware snapshots in an all SMS-managed database environment or in a mixed SMS-managed and non SMS-managed environment.  The following table shows how allocations will work in these environments with and without ACS rules:

Allocation considerations for hardware snapshots

Source

ACS rule exists and volume list passed

No ACS rule exists and volume list passed

SMS-managed data set

Allocation controlled by ACS rule

Allocation on same SMS storage class as source

Non-SMS-managed data set

Allocation controlled by ACS rule

Allocation will use the volume list that was passed

As seen in the table Allocation considerations for hardware snapshots, if the target for the hardware snapshots needs to reside on a specific SMS volume pool, you should have ACS rules set up to control that allocation.



 

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