Migration
This chapter explains aspects of migrating to a TS7700 Virtualization Engine environment from a Virtual Tape Server (VTS) or from other tape drive technologies. It presents various options that can be tailored to your current environment.
Guidance is provided to help you achieve the migration scenario that best fits your needs. For this reason, methods, tools, and software products that can help make the migration easier are highlighted.
TS7700 Virtualization Engine updates to new models introduced with TS7700 Release 3.2 are also described in this section.
This chapter includes the following sections:
7.1 Migration to a TS7700 Virtualization Engine
This section covers various aspects of migrating from an existing tape technology to the TS7700 Virtualization Engine. Depending on the source configuration, which can be an IBM VTS, IBM or other equipment manufacturer (OEM) native tape drives, or some other possibility, one of the descriptions applies partially or completely to your migration scenario.
Migrations to a TS7720 Virtualization Engine can only be done by using the host. The TS7720 Virtualization Engine does not have any attached back-end tape drives. Therefore, data needs to be copied into the TS7720 Virtualization Engine using host programs.
Migration of VTS Model B10 or B20 hardware to a TS7740 Virtualization Engine, also called outboard VTS migration, is possible depending on the target configuration. It provides an upgrade path for existing B10 or B20 VTS models to a TS7740 Virtualization Engine if the VTS system contains only 3592-formatted data. The outboard migration is offered as IBM Data Migration Services for Tape Systems. Outboard migration provides the following functions:
•Planning for migration, including consideration related to hardware and z/OS
•Project management for this portion of the project
•Assistance with the integration into a complete change plan, if required
•The actual migration of data from a 3494 VTS B10 or B20 to the TS7740
Work with your IBM representative for more details about IBM Migration Services for Tape Systems. These services are available from an IBM migration team and can assist you in the preparation phase of the migration. The migration team performs the migration on the hardware.
When migrating data from a VTS to a new TS7740 installed in the same tape library, the process is called data migrate without tape move. If a source VTS is attached to one tape library and the new target TS7740 is attached to another tape library, the process is called data migration with tape move. When a source VTS is migrated to an existing TS7740, or two VTSs are migrated to the same target TS7740, the process is called merge.
Migration from VTS with 3590 Tape Drives, or native tape drives to the TS7740 Virtualization Engine, always requires host involvement to copy the data into the TS7700 Virtualization Engine. For more information about the methods you can use, see 7.3, “Moving data in and out of the TS7700 Virtualization Engine” on page 256.
The hardware migration scenarios have the following aspects:
•Software changes in storage management subsystem (SMS), hardware configuration definition (HCD), tape configuration database (TCDB), and tape management system (TMS)
|
Tip: The TMS can be Removable Media Management (DFSMSrmm) or other products from other vendors.
|
•Connectivity for the new configuration
•Migration of the Library Manager database from an existing tape library to the TS7700 Virtualization Engine
•Physical swap of the B10/B20 VTS to the TS7700 Virtualization Engine hardware
•Migration of the database from B10/B20 VTS to TS7700 Virtualization Engine
Information is provided about the TS7700 family replacement procedures that are available with the new hardware platform and the TS7700 Virtualization Engine R3.2 Licensed Internal Code (LIC) level.
With the availability of the new generation hardware, an upgrade path is provided for existing TS7700 users to migrate to this new hardware.
Upgrading tape drive models in an existing TS7740 or TS7720 tape attach to get more capacity from their existing media or to provide encryption support is further addressed in this section. It details the hardware upgrade procedure and the cartridge migration aspects.
7.2 Upgrading drive models in an existing TS7740 or TS7740T
This scenario is an existing TS7740 or TS7720 tape attach cluster with data. You might want to upgrade back-end tape drives to a higher model to get more capacity from the existing media, or because the actual drives are not encryption-capable, or for any other reason. Because the tape drives are in the TS7740 or TS7720 tape attach R3.2, the supported drive types include the 3592-J1A, the TS1120 (3592-E05), TS1130 (3592-E06/EU6), and the TS1140 (3592-E07) tape drives.
|
Restriction: Drive model changes can only be made in an upward direction (from an older to a newer model). Fallback to the older models is not supported.
|
Hardware configuration and limitations
Check 4.1.2, “Tape drives and media support (TS7740 and the TS7720T Virtualization Engines only)” on page 119 for detailed information about tape drives and supported media.
Starting with Release 2.1 pre-general availability 0 (PGA0), the reading of JA and JJ media by the TS1140-E07 Tape Drive is supported. This capability enables users to upgrade the tape library tape drives to the TS1140 Model E07 while still having active data in JA or JJ media.
After upgrading drives to the TS1140 3592-E07 model, all existing JA and JJ media will be made read-only and ejected from the library after being reclaimed.
|
The TS1140 (3592 model E07) cannot be intermixed with any other model of the 3592 Tape Drive.
|
Drive change scenarios
The drive change is performed by your IBM SSR. Work with the IBM SSR when you plan for cluster downtime.
When you change drive types, the main concern is whether the new drive type can read the existing logical volumes that are written to the existing media. There are two concerns:
•Is the new drive capable of reading the format in which existing data was written?
•Can the new drive use the existing media type?
Check Table 4-7 on page 121 for the drive model’s capabilities.
|
Clarification: This section provides high-level information about the subject. Do not use this information as a step-by-step guide. Work with your IBM SSR to prepare for an upgrade.
|
Replacing existing 3592-J1A, TS1120, or TS1130 drives with new TS1140 3592-E07 drives
This scenario assumes that new drives will be installed in place of the existing drives. No prior installation can be performed.
|
Remember: No intermix of drive models is allowed within the TS7740.
|
After this procedure, your TS7740 will be fully equipped with TS1140 3592-E07 drives. There is no intermix in this case.
Before you start to change the tape drives, you need to stop all host activity to this cluster. If this TS7740 is part of a grid, vary the logical drives online in the other clusters to provide tape resources to the host.
If this is a stand-alone cluster, plan for a 3 - 4 hour outage.
Vary off all logical drives in this cluster. The IBM SSR places this cluster in service mode (if part of a grid) and offline. All physical drives must be unloaded and emptied of cartridges. Next, from the TS3500 Management Interface (MI), the drives must be unassigned from the TS7740 Logical Library.
Now, drives can be removed and the new drives installed in their places. The IBM SSR installs new drives, checks the configuration and firmware code level by using the TS3500 MI or another tool. If necessary, the IBM SSR updates the firmware level of the new drives. Also, 4 Gb fiber switches can be replaced with the new 8 Gb switches, if ordered.
New drives are assigned back to the TS7740 Logical Library by the TS3500 MI, and the control paths are correctly assigned. Drive fibers are reconnected, and connections to the switches are verified. If everything appears correct, the IBM SSR runs a drive reconfiguration at the TS7740 cluster.
After the reconfiguration, all new drives and paths must be available and healthy. If not, the IBM SSR acts upon the errors to correct them. This completes the drive upgrade change. Now, the TS7740 can be taken out-of-service mode and varied online by the IBM SSR.
|
Remember: In the previous scenario, all cartridges in the filling state are closed if the new drives do not support writing in the original tape format. Otherwise, the cartridges continue to be written in the same format to the end. Scratch tapes that are in use after the change are automatically reinitialized to the new tape format.
|
You can use the same description to understand what happens when changing the tape emulation mode in the TS7740 from 3592-J1A emulation to TS112-E05 native mode. All steps apply but the steps that relate to changing drives physically or assignments within the TS3500. The drives are the same.
The only change is made in the drive emulation mode. Drive emulation is changed in the TS3500 web interface (see Figure 8-154 on page 489 for a reference) by using a specific command in the TS7740 by the IBM SSR. The media format is handled as described in the previous scenario.
Migrating TS7740 or TS7720 tape attach data from an existing media type to another
|
Consideration: Restrictions apply to some configurations. See 4.1.2, “Tape drives and media support (TS7740 and the TS7720T Virtualization Engines only)” on page 119 for the valid combinations of media type and drive models within the TS7740 or TS7720 tape attach.
|
This procedure can be helpful when upgrading your tape drives to the TS1140 3592-E07 Tape Drives or replacing the existing media cartridges to a newer type to increase the storage capacity of your library. The E07 drives can only read JA or JJ tapes, so you must have JB, JC, or JK media for the TS7740 or TS7720 tape attach operation.
In this scenario, coming from a previous 3592 tape drive model to the E07, all JA media will be sunset, which means that after reclaiming the active logical volumes still contained in it, the JA media will be ejected from the library.
In this case, you must have a working pool of stacked volumes of the supported media, such as the 3592 Expanded Capacity Cartridge JB, 3592 Advanced Tape Cartridge JC, or 3592 Economy Advanced Tape cartridge JK. Your data, formerly in a JA or JJ media, is forcibly migrated into the supported media.
Considering that you might want to change your 3592 Extended Data Cartridges JB to 3592 Advanced Tape Cartridges JC for a capacity upgrade, complete the following steps:
1. Create a range of physical volumes in the TS7740 or TS7720 tape attach for the new JC media. See Figure 8-76 on page 378 for guidance.
2. Create a Cartridge Assignment Policy (CAP) for the new JC range and assign it to the correct TS7740 or TS7720 tape attach logical partition (LPAR). See “Defining Cartridge Assignment Policies” on page 490 for reference.
3. Insert the new JC cartridges in the TS3500 Tape Library. See “Inserting TS7740 or TS7720T Virtualization Engine physical volumes” on page 491.
4. Assign an existing pool or pools of physical volumes in the TS7740 or TS7720 tape attach to the new media type. See “Defining physical volume pools in the TS7740 or TS7720T” on page 500.
5. Modify the Storage Group in the TS7740 or TS7720 tape attach constructs to point to the new JC cartridge pools. See “Defining TS7700 constructs” on page 520.
6. Modify the reclaim settings in the JB media pool using JC pools as the target pools. See “Defining physical volume pools in the TS7740 or TS7720T” on page 500 for more details.
These settings cause the TS7740 or TS7720 tape attach to start using the new JC media for stacking newly created logical volumes. Existing JB physical volumes are reclaimed into the new JC media, becoming empty.
You might prefer to keep your pool definitions unchanged throughout the media change process. In this case, empty the common scratch pool of the previous media type and fill it up with the new cartridges. Also, in the Pool Properties table, set the new media type as your choice of First Media. You can keep the previous media type as the secondary media type as a precaution to not run out of scratch media. See “Defining physical volume pools in the TS7740 or TS7720T” on page 500 for details.
You can temporarily change the pools’ setup from Borrow, Return to Borrow, Keep during transition, when both media types coexist in the tape library. See “Defining physical volume pools in the TS7740 or TS7720T” on page 500. This way, cartridges of the previous media type are not available for selection in the common scratch pool. After the old-type cartridges are emptied, they can be ejected from the tape library.
The pools can be set back to Borrow, Return after the old media-type cartridges have been removed from the TS7740’s inventory or at your convenience.
|
Clarification: You might use the new Host Console Request Resident on Recall for Sunsetting RRCLSUN (ReCaLl SUNset) to expedite the replacement of the older media with newer media. In this case, ensure that the common scratch pool has the new media type available and the storage pools are set to borrow from the common scratch pool. Otherwise, the logical volumes are premigrated again to the older media type.
This function invalidates the logical volume on the older physical volume just after recall, regardless of the logical volume being updated or not. As a result, any recalled volume is premigrated to another physical volume. The library request command is shown:
LI REQ, lib_name,RRCLSUN ENABLE/DISABLE/STATUS
where:
Enable Activates the force residency on recall function
Disable Deactivates the force residency on recall function
Status Displays the current setting
|
If you are changing existing drives to new drive models using the same media type, use the Library Request (LI REQ) command to accelerate the drive format conversion. This process enables you to reclaim capacity from your existing media. In this scenario, you are not changing the existing cartridges already in use. There are no changes needed regarding the existing physical volume pools.
7.3 Moving data in and out of the TS7700 Virtualization Engine
When moving data into the TS7700 Virtualization Engine, it is not possible to simply move the cartridges out of a 3494-Bxx VTS and insert them into a stand-alone cluster TS7700 Virtualization Engine and copy the control data sets. This migration approach is only supported for the scenarios described in the hardware migration scenarios for the TS7740 Virtualization Engine, described in previous TS7700 Redbooks publications (R1.7, R2.0, and R3.0, which are still available at:
In all other scenarios, migrating data into the TS7700 Virtualization Engine requires that the TS7700 Virtualization Engine and the existing environment remain installed in parallel until the data has been migrated through the host attached to them.
Examples of this type of configuration are native tape drives, VTS with 3590 Tape Drives, or other vendor tape solutions. Although they can all be migrated to TS7700 Virtualization Engine, the process requires host involvement to copy the data into the TS7700 Virtualization Engine.
This section describes techniques for moving data in and out of the TS7700 Virtualization Engine. You can start using the TS7700 Virtualization Engine by moving data into it. The best method depends on the application you want to manage with the TS7700 Virtualization Engine.
There are two methods:
Phased method This method consists of using the TS7700 Virtualization Engine with new allocations. The migration of data takes longer, but it can be more controlled and flexible.
Quick method Use this method when you want to move existing data into the TS7700 Virtualization Engine. It is considered a quick method because it swiftly puts all the data that you want to move under TS7700 Virtualization Engine control.
Hints about how to move data out of the TS7700 Virtualization Engine are provided in 7.3.6, “Moving data out of the TS7700 Virtualization Engine” on page 263. However, the TS7700 Virtualization Engine is a closed-storage method, so you must be careful about selecting data to move into it. You do not want to store a large amount of data in the TS7700 Virtualization Engine that will need to be moved back out.
7.3.1 Phased method of moving data
The data movement techniques outlined here depend more on changes in parameters, routines, or procedures than on overt data movement.
Selecting the data
If you select DFSMShsm-owned data, you can group your data as listed according to any or all of the items in the following list:
•Migration data (DFSMShsm level 2)
•Backup copies (user data, control data set (CDS) data, or both)
•Dump copies
You can select data based on data set name, by application, or by any other variable that you can use in the automatic class selection (ACS) routines. You can also select data based on type, such as System Management Facilities (SMF) data or DASD DUMP data.
Updating the applicable parameters
If you select DFSMShsm-owned data, review the ARCCMDxx member according to the guidelines in 7.4, “Migration of DFSMShsm-managed data” on page 266 and update the following definitions:
•Data Class ACS routines (if used)
•Management Class ACS routines (if used)
•Storage Class ACS routines (required)
•Storage Group ACS routines (required)
•For Basic Tape Library Support (BTLS), the unit parameter in the JCL
For DFSMSdss, update the following definitions:
•Data Class ACS routines (if used)
•Management Class ACS routines (if used)
•Storage Class ACS routines (required)
•Storage Group ACS routines (required)
•For BTLS, the unit parameter in the JCL
If you use database data, such as logs or image copy, direct new allocations into the TS7700 Virtualization Engine by updating the following definitions:
•Data Class ACS routines (if used)
•Management Class ACS routines (if used)
•Storage Class ACS routines (required)
•Storage Group ACS routines (required)
For data other than DFSMShsm and DFSMSdss, if you are using SMS tape, update the ACS routines to include the data you want to move. You decide which data to filter and how you write the ACS routines. You can also migrate based on the UNIT parameter in the JCL to reflect the applicable unit for the TS7700 Virtualization Engine.
Updating the tape management system
Although you are not overtly copying data in this option, ensure that you update the tape management system (TMS) catalog or control data set to reflect the changes that you expect. Check the retention rules and limits, and update accordingly. If you change data set names when moving to TS7700 Virtualization Engine, you must validate changes against retention rules in your TMS. See 7.5, “DFSMSrmm and other tape management systems” on page 275 for more information.
Watching the data move to the TS7700 Virtualization Engine
Data movement using this option does not involve overt actions, such as COPY, RECYCLE, or DUMP. When you activate the ACS routines that contain the code for the TS7700 Virtualization Engine, all new data allocations for the data that you selected are written to the TS7700 Virtualization Engine. Verify that data is going where you expect it to go, and add code to the ACS routines to manage more data as you see fit.
You can select data types that create large quantities of data, such as SMF records or DASD DUMPS, and you can also select data types that create many small data sets. By observing how the TS7700 Virtualization Engine handles each type of data, you become familiar with the TS7700 Virtualization Engine, its functions, and capabilities.
7.3.2 Quick method of moving data
The steps outlined in this section involve overt actions on your part to move data into the TS7700 Virtualization Engine. As with the techniques outlined in 7.3.1, “Phased method of moving data” on page 257, you choose the data that you want to move to the TS7700 Virtualization Engine.
Selecting the data to copy
The data that you select influences all the subsequent steps in this process. If you select DFSMShsm-owned data, the process for moving the data to the TS7700 Virtualization Engine differs from the process that you use for moving DFSMSdss data. You can select data based on the data’s attributes, such as the expiration date. For example, you can select data that you keep for seven years. Probably the best method for selecting data to copy in the TS7700 Virtualization Engine is based on the data set name, application by application.
Certain applications have knowledge of the VOLSER where the data is stored. There are special considerations for these applications. If you change the VOLSER on which the data is stored, the application has no way of knowing where the data is. For more information about this topic, see 7.3.4, “Considerations for static VOLSERs” on page 262.
An easy method is to obtain information from the TMS database. Reports can give you details about the data you have in the tape shop, which helps you select the input volumes.
If you are using DFSMSrmm, you can easily acquire data from a Removable Media Management (RMM) EXTRACT file, which is normally created as part of the regular maintenance. Then, using a REXX EXEC or ICETOOL JCL program, you extract the needed information, such as data set name, VOLSER, and file sequence of the input volumes.
Moving data to a new TS7700 Virtualization Engine
Although you must use the Tape Copy Utility Tool to move data to TS7700 Virtualization Engine, not all z/OS data can be moved by using these tools. In general, this tool is able to move any data on tape, except those products that manage their own data, for example, DFSMShsm, DFSMdfp object access method (OAM), or IBM Tivoli Storage Manager.
When using SMS tape, the first step is to update the ACS routines to direct all new data to the TS7700 Virtualization Engine. With this change, new data on tapes gets created in the TS7700 Virtualization Engine, so that moving it again later is not necessary.
If you move DFSMShsm-owned data, you can use, as appropriate, the OAM recycle process, OAM Storage Management Component (OSMC), or the OAM MOVEVOL utility to move the data to the TS7700 Virtualization Engine. Use a COPYDUMP job to move DFSMSdss data to the TS7700 Virtualization Engine. The utility to use depends on the data selected. In most cases, it is sequential data that can be copied by using the IEBGENER utility, DITTO/ESA. If you have DFSORT, ICEGENER and ICETOOL perform better.
You must use a specific utility when the input data is in a special format, for example, DFSMSdss dump data. DFSMSdss uses blocks up to 256 KB blocksize and only the proper DSS utility, such as COPYDUMP, can copy with that blocksize. Be careful when copying multifile and multivolume chains.
In general, all other data (except data owned by an application, such as DFSMShsm) belongs to batch and backup workloads. Use EXPDT and RETPD from the DFSMSrmm Extract file to discover which tapes have a distant expiration date, begin moving these tapes, and leave the short-term retention tapes to the last phase of data movement. They likely will be moved by the everyday process.
Updating the tape management system with the correct retention information
When the manual copy operation has been successful, it might be necessary to update the TMS catalog. The following data must be updated on the output volume:
•File sequence number
•Creation date and time
•Last read and last write date
•Jobname
Optionally, you can also update the following items:
•Stepname
•DDname
•Account number
•Device number
In RMM, this step can be done with a CHANGEDATASET command that has special authority to update O/C/EOV recorded fields. For detailed information about this command, see z/OS DFSMSrmm Managing and Using Removable Media, SC23-6873.
To avoid this time-consuming process, use a tape copy tool because they can make all the necessary changes in a TMS.
Updating the ICF catalog with the correct output volume
The next step is to uncatalog the input data sets (if they were cataloged) and recatalog the output data sets with the new volume information. This can be done with IDCAMS DELETE NOSCRATCH or within TSO with the ‘U’ command followed by DEFINE NONVSAM or a ‘C’ command in TSO. For more information, see z/OS DFSMS Access Method Services Commands, SC23-6846.
Tape copy tools recatalog tapes during movement without the need for manual intervention.
Releasing the input volume for SCRATCH processing
This final step must be done after you are sure that the data has been correctly copied. You must also verify that the retention and catalog information is correct.
Using this quick-method sequence, you can copy every kind of tape data, including generation data groups (GDGs), without modifying the generation number.
In an RMM environment, you can use REXX CLIST and RMM commands, listing data from the input volumes and then using the RMM REXX variables with the CD command to update the output. Then, call IDCAMS to update the integrated catalog facility (ICF) catalog. For more information, see z/OS DFSMS Access Method Services Commands, SC23-6846.
When the operation completes and all errors are corrected, use the RMM DELETEVOLUME command to release the input volumes. For more information about RMM commands and REXX variables, see z/OS DFSMSrmm Managing and Using Removable Media, SC23-6873. If you are using a TMS other than RMM, see the appropriate product functions to obtain the same results.
Migrating data inside the TS7700 Virtualization Engine can be made easier by using products, such as DFSMShsm or IBM Tivoli Storage Manager. If you are planning to put DFSMShsm or IBM Tivoli Storage Manager data in the TS7700 Virtualization Engine, see the following sections:
With DFSMShsm, you can change the ARCCMDxx tape device definitions to an esoteric name with TS7700 Virtualization Engine virtual drives (in a BTLS environment) or change SMS ACS routines to direct DFSMShsm data in the TS7700 Virtualization Engine. The DFSMShsm RECYCLE command can help speed the movement of the data.
A similar process can be used with IBM Tivoli Storage Manager, changing the device class definitions for the selected data to put in the TS7700 Virtualization Engine and then starting the space reclamation process.
If you are moving DB2 data into the TS7700 Virtualization Engine, ensure that, when copying the data, the DB2 catalog is also updated with the new volume information. You can use the DB2 MERGECOPY utility to speed up processing, using TS7700 Virtualization Engine virtual volumes as output.
In general, DB2 image copies and Archlog are not retained for a long time. After all new write activity goes to the TS7740 Virtualization Engine, you can expect that this data is moved by the everyday process.
7.3.3 Products to simplify the task
You might want to consider using a product designed to copy data from one medium to another. The first choice is the IBM offering that interacts with DFSMSrmm called Tape Copy Tool (see Table 7-1 on page 262). The Tape Copy Tool function of the internal IBM ADDONS package is designed to copy all types of MVS tape data sets from one or more volumes or volume sets to a new tape volume or tape volume set. This tool supports any tape media supported by DFSMSrmm. The input tape media can be different from the output tape media.
Do not use the tool to copy tape data sets owned by Hierarchical Storage Manager (DFSMShsm), IBM Tivoli Storage Manager, or similar products, where information of old VOLSERs is kept within the product and not reflected after a copy is made. This challenge typically applies to products where tapes are not cataloged in an ICF catalog, but kept in the product’s own database.
The DFSMSrmm Tape Copy Tool cannot be used when you have a TMS other than DFSMSrmm. You must choose another Tape Copy Tool from Table 7-1.
Consider the following factors when you evaluate a tape copy product:
•Interaction with your TMS
•Degree of automation of the process
•Speed and efficiency of the copy operation
•Flexibility in using the product for other functions, such as duplicate tape creation
•Ease of use
•Ability to create a pull list for any manual tape mounts
•Ability to handle multivolume data sets
•Ability to handle volume size changes, whether from small to large, or large to small
•Ability to review the list of data sets before submission
•Audit trail of data sets already copied
•Ability to handle failures during the copy operation, such as input volume media failures
•Flexibility in filtering the data sets by wildcards or other criteria, such as expiration or creation date
Table 7-1 lists several common tape copy products. You can choose one of these products or perhaps use your own utility for tape copy. You do not need any of these products, but a tape copy product can make your job easier if you have many tapes to move into the TS7700 Virtualization Engine.
Table 7-1 Selection of tape copy tools
|
Product name
|
Vendor name
|
For more information
|
|
Tape Copy Tool/
DFSMSrmm
|
IBM
|
Contact your IBM representative for more information about this service offering. Do not confuse this with the Tape Analysis Tools that are mentioned in 10.8.2, “Tools download and installation” on page 662, which can be download from IBM for no extra fee.
|
|
Tape Optimizer
|
IBM
|
|
|
Beta55
|
Beta Systems
Software AG |
|
|
CA-1/TLMS
Copycat
|
Computer Associates
International, Inc. |
|
|
Tape/Copy
|
Rocket Software
|
|
|
TelTape
|
Cartagena Software
Ltd. |
|
|
Zela
|
Software Engineering
of America |
|
|
FATScopy
|
Innovation
|
In addition to using one of these products, consider using IBM Global Technology Services (GTS) to assist you in planning and moving the data into the TS7700 Virtualization Engine.
7.3.4 Considerations for static VOLSERs
Some applications have knowledge of the VOLSER of the volume where the data is stored. DFSMShsm is one of these applications. When moving data for these applications, you have two choices:
•You can use instructions from the application author to copy the data.
•You can copy the data to a volume with the same VOLSER.
For assistance with DFSMShsm tapes, see 7.3.2, “Quick method of moving data” on page 258.
The preferred method for moving this type of data is to use instructions from the application author. However, if you must copy the data to a volume with the same VOLSER, consider the following information:
•The source and target media might not be the exact same size.
•You cannot mount two volumes with the same VOLSER at the same time.
•If the source tape is a system-managed tape, you cannot have two volumes with the same VOLSER.
As much as possible, avoid having dataset-to-VOLSER relationships. In general, these relationships are only necessary in old backup tapes or tapes that are retained for legal reasons. Using only one scratch pool greatly simplifies tape management from all perspectives.
This method is not preferred for moving data to the TS7700 Virtualization Engine. This method applies only if you must maintain the dataset-to-VOLSER relationship. It has limitations and weaknesses.
To move data to the TS7700 Virtualization Engine, complete the following steps:
1. Copy the non-TS7700 Virtualization Engine tape volumes to DASD or other tape volumes.
2. If the source volume is resident on a 3494 Tape Library, eject the cartridge from the 3494 Tape Library using the LIBRARY EJECT command or the ISMF EJECT line operator command from the Interactive Storage Management Facility (ISMF) window.
3. Delete the ejected volume from the TMS by using RMM DELETEVOLUME or the equivalent command in your TMS.
4. Define the VOLSER range, including the once-duplicated number, to the TS7700 Virtualization Engine.
5. Update the ACS routines so that the data is directed to the TS7700 Virtualization Engine. For BTLS, update the UNIT parameter in the JCL.
6. Create a job to copy the data currently on DASD to the TS7700 Virtualization Engine.
7. Run the copy job.
8. Update the TMS records and any other catalog structures.
7.3.5 Combining methods to move data into the TS7700 Virtualization Engine
You will most likely want to use a combination of the phased and quick methods for moving data into the TS7700 Virtualization Engine. One approach is to classify your data as static or dynamic.
Static data is information that will be around for a long time. These data can be moved into the TS7700 Virtualization Engine only with the quick method. You must decide how much of this data will be moved into the TS7700 Virtualization Engine. One way to decide this is to examine expiration dates. You can then set a future time when all volumes, or a subset, are copied into the TS7700 Virtualization Engine. There might be no reason to copy volumes that are going to expire in two months. By enabling these volumes go to SCRATCH status, you can save yourself some work.
Dynamic data is of a temporary nature. Full volume backups and log tapes are one example. These volumes typically have a short expiration period. You can move this type of data with the phased method. There is no reason to copy these volumes if they are going to expire soon.
7.3.6 Moving data out of the TS7700 Virtualization Engine
There are many reasons why you might want to move data out of the TS7700 Virtualization Engine. The most common reason is for disaster recovery or data interchange. You can move data out of the TS7700 Virtualization Engine in three ways:
Host-based copy tools
You can use a host-based tool to copy the data from the TS7700 Virtualization Engine to the target.
With this method, the data is reprocessed by the host and copied to another medium. This method is described in 7.3.1, “Phased method of moving data” on page 257. The only difference is that you need to address the TS7700 Virtualization Engine as input and the non-TS7700 Virtualization Engine drives as output.
Copy Export and Copy Export Merge
You can use the Copy Export function to copy data from one TS7700 to another empty TS7740. With this function, a copy of the selected logical volumes that are in the TS7700 Virtualization Engine can be removed and taken offsite.
In addition to the traditional role in a disaster recovery scenario, Copy Export has been enhanced to enable you to merge Copy Export content from one grid to another. This can help you to move workloads without using your host. This option can save you some tape subsystem outages. Client-initiated Copy Export can only be done to an empty TS7700 but Copy Export Merge can move data into an active TS7700 cluster. It is only available as a Service offering.
This service provides an IBM storage specialist to help you plan for and implement the merge of logical tape volumes copy exported from an IBM TS7740 cluster to another TS7740 cluster that is part of a different IBM TS7700 Grid. The source and the target TS7740 can be a stand-alone TS7740 or part of a TS7700 Grid. This helps enhance disaster recovery capability by enabling data recovery to an existing TS7740 without effect to existing data. Contact your IBM representative for this service offer.
You can find more details about Copy Export and Copy Export Merge in this book in Chapter 11, “Copy Export” on page 697.
DFSMShsm aggregate backup and recovery support
The third way is to copy the data with the DFSMShsm aggregate backup and recovery support (ABARS) function.
ABARS is the command-driven DFSMShsm function that backs up a user-defined group (called an aggregate group) of data sets (usually for recovery purposes) at another computer site or at the same site. ABARS can be used to back up and recover both SMS-managed and non-SMS-managed data, on DASD and on tape.
Using the DFSMShsm ABARS function, group the data you want to move outside the TS7700 Virtualization Engine. Then start addressing other tape drives outside the TS7700 Virtualization Engine, or use the Copy Export function. In this way, you obtain an exportable copy of the data that can be put in an offsite location.
You can use this process to perform these tasks:
Create a selection data set
Before you can run an aggregate backup, create one or more selection data sets. The selection data set lists the names of the data sets to be processed during aggregate backup.
You can identify the data set names in a single selection data set, or you can divide the names among as many as five selection data sets. You can specify six types of data set lists in a selection data set. The type that you specify determines which data sets are backed up and how they are recovered.
An INCLUDE data set list is a list of data sets to be copied by aggregate backup to a tape data file where they can be transported to the recovery site and recovered by aggregate recovery. The list can contain fully qualified data set names or partially qualified names with placeholders. DFSMShsm expands the list to fully qualified data set names.
Using a selection data set with the names of the data sets you want to export from the TS7700 Virtualization Engine, obtain a list of files on logical volumes that the ABARS function copies to non-TS7700 Virtualization Engine drives.
You can also use the Copy Export function to move the ABARS tapes to a data recovery site outside of the library.
Define an aggregate group
Define an aggregate group and related Management Class to specify exactly which data sets are to be backed up.
Define the aggregate group and Management Class used for aggregate backup to DFSMS through ISMF panels.
The aggregate group lists the selection data set names, instruction data set name, and extra control information used by the aggregate backup to determine which data sets to back up.
Run the ABACKUP VERIFY command
You can use the ABACKUP command to verify the contents of the aggregate backup without backing up any data sets. This is the same as performing a test run of aggregate backup. The following example shows the ABACKUP command:
HSEND ABACKUP agname VERIFY UNIT(non_TS7700_unit) PROCESSONLY(USERTAPE)
With the PROCESSONLY(USERTAPE) keyword, only tape data sets are processed. In this way, you can be sure that only the input data from TS7700 Virtualization Engine logical volumes
is used.
is used.
Run the ABACKUP EXECUTE command
When you are ready, start the actual backup by using the following command:
HSEND ABACKUP agname EXECUTE UNIT(non_TS7700_unit) PROCESSONLY(USERTAPE)
When you enter the ABACKUP command with the EXECUTE option, the following tape files are created for later use as input for aggregate recovery:
•Data file: Contains copies of the data sets that have been backed up.
•Control file: Contains control information that is needed by aggregate recovery to verify or recover the application’s data sets.
•Instruction/activity log file: Contains the instruction data set, which is optional.
Summary
At the end of this process, you obtain an exportable copy of the TS7700 Virtualization Engine data, which can be used for disaster recovery and stored offsite using other physical tapes. Consider using the Copy Export function, which enables you to move a copy of the original logical volumes to an offsite location without reading the tape data twice. The Copy Export function operates on another Physical Volume Pool in the library and creates the copy in the background without any process required on the host. However, Copy Export requires an empty TS7700 Virtualization Engine at your disaster site.
For more information, see the following resources:
•For Copy Export, see 11.2, “Implementing and running Copy Export” on page 708.
•For Copy Export Recovery, see 11.3, “Using Copy Export Recovery” on page 717.
•For using the DFSMShsm ABARS function, see the z/OS DFSMShsm Storage Administration, SC23-6871.
7.4 Migration of DFSMShsm-managed data
DFSMShsm is an application that can use the full cartridge capacity, but for various reasons, you might want to consider using the TS7700 Virtualization Engine rather than native physical drives for DFSMShsm data. For example, when writing Migration Level 2 (ML2) data onto a cartridge with an uncompressed capacity of 300 GB, chances are higher that a recall request needs exactly this cartridge that is being written to by a space management task. This incident is known as recall takeaway.
The effects of recall takeaway can be a real disadvantage when writing Migration Level 2 data onto native, high-capacity cartridges because the space management task must set aside its output tape to make it available to the recall task. Although the partially filled output tape remains eligible for subsequent selection, the next time that space management runs, it is possible to accumulate several partial tapes beyond DFSMShsm needs if recall takeaway activity occurs frequently.
Excess partial tapes created by recall takeaway activity result in poor use of native cartridges. In addition, because recall takeaway activity does not cause the set-aside tape to be marked full, it is not automatically eligible for recycling, despite its poor utilization.
High-capacity cartridges are more likely to experience both frequent recall takeaway activity, and also frequent piggy-back recall activity, in which recalls for multiple data sets on a single tape are received while the tape is mounted. Although piggy-back recalls have a positive effect by reducing the number of mounts required to run several recalls. You must also consider that multiple recalls from the same tape must be performed serially by the same recall task.
If those same data sets are on separate tapes, the recalls can potentially be performed in parallel, given enough recall tasks. In addition, the persistence of the virtual tape in the Tape Volume Cache (TVC) after it has been unmounted enables DFSMShsm to run ML2 recalls from the disk cache without requiring that a physical tape be mounted.
Other reasons also exist for directing DFSMShsm data into a TS7700 Virtualization Engine. The number of native drives limits the number of DFSMShsm tasks that can run concurrently. With the large number of up to 256 virtual drives in a stand-alone cluster configuration or 512 virtual drives in a two-cluster grid configuration, you can dedicate a larger number of virtual drives to each DFSMShsm function and enable higher throughput during your limited backup and space management window.
When increasing the number of DFSMShsm tasks to take advantage of the large number of virtual drives in a TS7700 Virtualization Engine, consider adding more DFSMShsm auxiliary tasks (MASH), rather than simply increasing the number of functional tasks within the existing started tasks. Each DFSMShsm started task can support up to 15 AUTOBACKUP tasks.
Other reasons for using the TS7700 Virtualization Engine with DFSMShsm are the greatly reduced run times of DFSMShsm operations that process the entire volume, such as AUDIT MEDIACONTROLS and TAPECOPY.
DFSMShsm can benefit from the TS7700 Virtualization Engine’s high throughput and from its large TVC size, which enables long periods of peak throughput.
DFSMShsm data is well-suited for the TS7700 Virtualization Engine because the appropriate tailoring of those parameters that can affect DFSMShsm performance. The subsequent sections describe this tailoring in more detail.
For more information, see the z/OS DFSMShsm Storage Administration Guide, SC23-6871.
7.4.1 Volume and data set sizes
The size of user data sets is important when you choose between a TS7700 Virtualization Engine and native drives such as 3592. DFSMShsm Migration, Backup, and Recycle use only Single File Format to write to tape cartridges.
z/OS supported data set sizes
Different data set sizes are supported for disk and tape data sets, based on the data set organization and the number of volumes that a single data set can span:
•DASD data sets are limited to 59 volumes, except for partitioned data sets (PDS) and partitioned data set extended (PDSE) data sets, which are limited to one volume.
•A data set on a virtual I/O (VIO)-simulated device is limited to 65,535 tracks and to one volume.
•Tape data sets are limited to 255 volumes.
Table 7-2 lists the maximum data set sizes supported in z/OS environments.
Table 7-2 Maximum supported data set sizes
|
Storage medium
|
Maximum volume size
|
Maximum number of volumes
|
Maximum
data set size |
|
DASD: IBM System Storage DS8000®
|
65,520 CYL = 54 GB
|
59
|
3.18 TB
|
|
Tape: TS1120
|
700 GB x 2.5 compression
|
40
|
70 TB
|
|
Tape: TS7700 Virtualization Engine
|
6,000 MB x 2.5 compression
|
40
|
600 GB
|
DFSMShsm supported data set sizes
Single-file format, as used by DFSMShsm, reduces I/O and system serialization because only one label is required for each connected set (as opposed to multiple file format tapes that require a label for each data set). The standard-label tape data set that is associated with the connected set can span up to the allocation limit of 255 tapes. This standard-label tape data set is called the DFSMShsm tape data set. Each user data set is written in 16 K logical blocks to the DFSMShsm tape data set.
|
Important: A single DFSMShsm user data set can span up to 40 tapes (with z/OS V2R1, this limit is now 254). This limit is for migration, backup, and recycle.
|
After DFSMShsm writes a user data set to tape, it checks the volume count for the DFSMShsm tape data set. If the volume count is greater than 215, the DFSMShsm tape data set is closed, and the currently mounted tape is marked full and is de-allocated.
The number 215 is used so that a data set spanning 40 tapes fits within the 255-volume allocation limit. DFSMShsm selects another tape, and then starts a different DFSMShsm tape data set. Data set spanning can be reduced by using the SETSYS TAPESPANSIZE command.
DFSMShsm and large logical volumes
The TS7700 Virtualization Engine supports logical volume sizes of 400, 800, 1000, 2000, 4000, and 6000 MiB. With a maximum of 40 volumes supported and assuming a compression ratio of 2.5:1, the maximum user data set size for 800 MB volumes is 80 GB:
800 MB x 2.5 x 40 = 80 GB
Assume that you have a very large data set of 300 GB. This data set does not fit on 40 volumes of 800 MB each, but it can fit on 6000 MB large virtual volumes, as shown in the following example:
6000 MB x 2.5 x 40 = 600 GB
Any single user data set larger than 600 GB is a candidate for native 3592 Tape Drives. Assuming a compression rate of 2.5:1, they might not fit onto the supported number of 40 volumes. In this case, consider using native 3592-E06 (TS1130) or 3592-E07 (TS1140) tape drives rather than TS7700 Virtualization Engine.
IDCAMS DCOLLECT BACKUPDATA can be used to determine the maximum size of backed-up data sets in DFSMShsm’s inventory. MIGRATEDATA can be used to determine the maximum size of migrated data sets in DFSMShsm’s inventory.
|
Important: DFSMShsm can consist of more than one address space on a single LPAR (Multi-Address Space HSM or MASH), or you can have multiple HSMs sharing a single set of CDSs, called an HSMplex. In either case, you can define commands in the ARCCMDxx member of your DFSMShsm parmlib to only apply to specific DFSMShsm hosts by using the ONLYIF statement, or you can have commands apply to all HOSTs in an HSMplex.
Each instance of DFSMShsm can have a unique MIGUNIT specified. For instance, one host can specify MIGUNIT(3590-1) and another MIGUNIT(TS7700). The same is true for BUUNIT.
The DFSMShsm host that has 3590-1 specified as a migration or backup unit should only process space management or automatic backup for the Storage Groups where your large data sets such as z/FS reside. The other DFSMShsm hosts can then migrate and back up Storage Groups containing the smaller data sets to the TS7700 Virtualization Engine.
To direct a command to a specific instance of DFSMShsm, you can use an MVS MODIFY command with the started task name of the instance of DFSMShsm that you want to process the command. For example, "F DFSMS2, BACKDS..." or "F DFSMS2, BACKVOL SG(SG)...".
The following commands affect which output device is used by a specific function:
•SETSYS TAPEMIGRATION(ML2TAPE(TAPE(unittype))
•SETSYS RECYCLEOUTPUT(MIGRATION(unittype))
•SETSYS BACKUP(TAPE(unittype))
•SETSYS RECYCLEOUTPUT(BACKUP(unittype))
|
Migration to a different logical volume size
To ensure that DFSMShsm starts using larger data sets, you must mark as full any empty or partially filled tapes that are written using the previous logical volume size. To identify these tapes, enter the following DFSMShsm command:
LIST TTOC SELECT(NOTFULL)
Each tape identified as being empty or partially filled must be marked full by using one of the following DFSMShsm commands:
DELVOL volser MIGRATION(MARKFULL)
DELVOL volser BACKUP(MARKFULL)
As DFSMShsm migrates data and creates backup copies, it prefers to add to an existing migration/backup volume. As the volume nears full, it handles spanning of data sets, as described in “Tape spanning” on page 271. If a data set spans across DFSMShsm volumes, it becomes a connected set in DFSMShsm terms.
However, a key point is that whether or not the data set spans, DFSMShsm uses Force end-of-volume (FEOV) processing to get the next volume mounted. Therefore, the system thinks that the volume is part of a multivolume set regardless of whether DFSMShsm identifies it as a connected set. Because of the end-of-volume (EOV) processing, the newly mounted DFSMShsm volume uses the same Data Class and other SMS constructs as the previous volume.
With the DFSMShsm SETSYS PARTIALTAPE MARKFULL option, DFSMShsm marks the last output tape full, even though it has not reached its physical capacity. By marking the last volume full, the next time processing starts, DFSMShsm will use a new volume, starting a new multivolume set and enabling for the use of a new Data Class and other SMS constructs. If the volume is not marked full, the existing multivolume set continues to grow and to use the old constructs.
Use the SETSYS PARTIALTAPE MARKFULL option because it reduces the number of occasions in which DFSMShsm appends to a partial tape. This results not only in the need to mount a physical tape, but also in the invalidation of the existing virtual tape, which eventually must be reclaimed by the TS7700 Virtualization Engine.
This is relevant to Outboard policy management and the implementation of different logical volume sizes. If all volumes have been marked full, you can simply update your ACS routines to assign a new Data Class and other SMS constructs. From then on, each new migration or backup volume uses the new size.
7.4.2 TS7700 Virtualization Engine implementation considerations
This section summarizes DFSMShsm implementation considerations regarding the TS7700 Virtualization Engine.
Mount wait time
You can direct DFSMShsm data into a TS7700 Virtualization Engine (TS7720 or TS7740). For a TS7740, modify your DFSMShsm mount wait timer to be 12 minutes. This modification enables possibly needed extra time on specific mounts for the TS7740 Virtualization Engine to stage the data back into cache. Member IECIOSxx is in PARMLIB. Consider defining a special missing-interrupt handler (MIH) value named MIH MOUNTMSG=YES,MNTS=10:00 to ensure mount-pending messages if delays in specific mounts occur. The value of 10 can be adjusted to your specific value.
Logical volume size
Consider using large logical volumes, such as 6000 MB, for backup and smaller logical volumes for migration, especially if you are using the TS7740 Virtualization Engine. If you have a high recall rate from ML2, you might not even want to use the entire capacity of a MEDIA1 or MEDIA2 virtual volume. Installations in which recalls from ML2 are rare and installations in which very large data sets are migrated that might result in reaching the 40-volume limit must use the maximum capacity of the virtual volume. Write your ACS routines to select a different SMS DATACLAS for backup and migration activities that is based on the optimum volume size.
See Table 7-3 on page 273 when tailoring the ARCCMDxx SETSYS parameters. HSM is aware of the large virtual volume capacity; it is not necessary to use high PERCENTFULL values to tune capacity of tapes from a DFSMShsm point of view. The maximum PERCENTFULL value that can be defined is 110% but it is no longer necessary to go above 100%.
Other applications might have a similar existing TAPECAPACITY-type specification or a PERCENTFULL-type specification to enable applications to write beyond the default volume sizes for MEDIA1 (cartridge system tape) and MEDIA2 (enhanced capacity cartridge system tape).
In OAM’s Object Tape Support, the TAPECAPACITY parameter in the SETOAM statement of the CBROAMxx PARMLIB member is used to specify the larger logical volume sizes. Because OAM also obtains the size of the logical volume from the TS7700, defining TAPECAPACITY in the CBROAMxx PARMLIB member is not necessary. For more information about Outboard policy management, see the z/OS DFSMS Object Access Method Planning, Installation and Storage Administration Guide for Tape Libraries, SC23-6867.
Multisystem considerations
If multiple TS7700 Virtualization Engines are eligible for a request, also consider that the same logical volume size is used for the request across all libraries. When displaying the volumes through your tape management system, the tape management system might continue to display the volume capacity based on the default volume size for the media type with the volume usage (or a similar parameter) showing how much data has actually been written to the volume reflecting its larger capacity.
Scratch volumes
The default volume size is overridden at the library through the Data Class policy specification, and is assigned or reassigned when the volume is mounted for a scratch mount or rewritten from load point as a specific mount. Using a global scratch pool, you benefit from a fast mount time by establishing your scratch (Fast Ready) categories as explained in “Defining scratch (Fast Ready) categories” on page 516. Consider using the following definitions to benefit from the fast scratch mount times:
•SETSYS SELECTVOLUME(SCRATCH): Requests DFSMShsm to use volumes from the common scratch pool
•SETSYS TAPEDELETION(SCRATCHTAPE): Defines that DFSMShsm returns tapes to the common scratch pool
•SETSYS PARTIALTAPE(MARKFULL): Defines that an DFSMShsm task will mark the last tape it used in a cycle to be full, therefore avoiding a specific mount during the next cycle.
The MARKFULL parameter does not mean a waste of space using TS7700 Virtualization Engine because the stacked volume contains only the written data of each logical volume copied and the same applies to the TVC.
Tape spanning
You can use the optional TAPESPANSIZE parameter of the SETSYS command to reduce the spanning of data sets across migration or backup tape volumes, for example:
SETSYS TAPESPANSIZE(4000)
The value in parentheses represents the maximum number of megabytes of tape (ML2 or backup) that DFSMShsm might leave unused while it tries to eliminate the spanning of data sets. To state this in another way, this value is the minimum size of a data set that is allowed to span tape volumes. Data sets whose size is less than the value do not normally span volumes. Only those data sets whose size is greater than or equal to the specified value are allowed to span volumes.
This parameter offers a trade-off: It reduces the occurrences of a user data set spanning tapes in exchange for writing less data to a given tape volume than its capacity otherwise enables. The amount of unused media can vary from 0 to nnnn physical megabytes, but roughly averages 50% of the median data set size. For example, if you specify 4000 MB and your median data set size is 2 MB, on average, only 1 MB of media is unused per cartridge.
Installations that currently experience an excessive number of spanning data sets need to consider specifying a larger value in the SETSYS TAPESPANSIZE command. Using a high value reduces tape spanning. In a TS7700 Virtualization Engine, this value reduces the number of virtual volumes that need to be recalled to satisfy DFSMShsm recall or recover requests.
You can be generous with the value because no space is wasted. For example, a TAPESPANSIZE of 4000 means that any data set with less than 4000 MB that does not fit on the remaining space of a virtual volume is started on a fresh new virtual volume.
7.4.3 DFSMShsm task-related considerations
To better understand the use of DFSMShsm with TS7700 Virtualization Engine, this section summarizes the DFSMShsm functions that use tapes and analyzes the benefit of tape virtualization for these functions.
Backups of DFSMShsm control data sets
DFSMShsm control data sets (CDSs) can be backed up easily in a TS7700 Virtualization Engine, using the benefit of using virtual volumes rather than physical volumes, which might otherwise be underused.
Volume dumps
When using TS7700 Virtualization Engine as output for the DFSMShsm AUTODUMP function, do not specify the following parameters:
DEFINE DUMPCLASS(dclass STACK(nn))
BACKVOL SG(sgname)|VOLUMES(volser) DUMP(dclass STACK(10))
These parameters were introduced to force DFSMShsm to use the capacity of native physical cartridges. If used with TS7700 Virtualization Engine, they cause unnecessary multivolume files and reduce the level of parallelism possible when the dump copies are restored. Use the default value, which is NOSTACK.
Migrate or recall (DFSMShsm Migration Level 2)
When using a TS7740 Virtualization Engine as DFSMShsm Migration Level 2, consider the number of simultaneous recall processes. Consider how many recall tasks are started at the same time, and compare that number with the number of physical drives that are assigned to your TS7740 Virtualization Engine.
For example, if your installation often has more than 10 tape recall tasks at one time, you probably need 12 back-end drives to satisfy this throughput request because all migrated data sets might already have been removed from the TVC and need to be recalled from tape.
Backup and recovery
Unlike the DFSMShsm RECALL operation, RECOVERY usually has a lower frequency in an DFSMShsm environment. Therefore, using TS7700 Virtualization Engine for DFSMShsm backup and recovery functions benefits you without affecting DFSMShsm performance. However, review your DFSMShsm performance requirements before moving DFSMShsm BACKUP to the TS7700 Virtualization Engine.
TAPECOPY
The DFSMShsm TAPECOPY function requires that original and target tape volumes are of the same media type and use the same recording technology. Using a TS7700 Virtualization Engine as the target for the TAPECOPY operation from an original volume that is not a TS7700 volume might cause problems in DFSMShsm because TS7700 Virtualization Engine virtual volumes have different volume sizes.
Use the information in Table 7-3 to tailor your TAPECOPY environment.
Table 7-3 TAPECOPY usage
|
ORIGINAL volume unit name
|
ALTERNATE volume unit name
|
Percent full to be defined (assuming 2:1 compression)
|
|
TS7700 (CST): 400 MB
|
3490E (CST)
|
100%
|
|
TS7700 (ECCST): 800 MB
|
3490E (ECCST)
|
100%
|
|
3490E (CST): 400 MB
|
TS7700 CST: 400 MB
|
45%
|
|
3490E (ECCST): 800 MB
|
TS7700 (ECCST): 800 MB
|
45%
|
|
TS7700 (CST): 400 MB
|
TS7700 (CST): 400 MB
|
100%
|
|
TS7700 (CST): 1 GB
|
TS7700 (CST): 1 GB
|
100%
|
|
TS7700 (CST): 2 GB
|
TS7700 (CST): 2 GB
|
100%
|
|
TS7700 (CST): 4 GB
|
TS7700 (CST): 4 GB
|
100%
|
|
TS7700(CST): 6 GB
|
TS7700 (CST): 6 GB
|
100%
|
|
TS7700 (ECCST): 800 MB
|
TS7700 (ECCST): 800 MB
|
100%
|
|
TS7700 (ECCST): 1 GB
|
TS7700 (ECCST): 1 GB
|
100%
|
|
TS7700 (ECCST): 2 GB
|
TS7700 (ECCST): 2 GB
|
100%
|
|
TS7700 (ECCST): 4 GB
|
TS7700 (ECCST): 4 GB
|
100%
|
|
TS7700 (ECCST): 6 GB
|
TS7700 (ECCST): 6 GB
|
100%
|
For example, if you are planning to put DFSMShsm alternative copies into a TS7700 Virtualization Engine, a tape capacity of 45% might not be enough for the input non-TS7700 Virtualization Engine ECCST cartridges. TAPECOPY fails if the (virtual) output cartridge encounters EOV before the input volume has been copied completely.
However, using TS7700 Virtualization Engine logical volumes as the original and 3490E native as the TAPECOPY target might cause EOV at the alternative volume because of the higher LZ data compression algorithm, IBMLZ1, compression seen on the virtual drive compared to the improved data-recording capability (IDRC) compression on the native drive.
For special situations where copying from standard to enhanced capacity media is needed, the following patch command can be used:
PATCH .MCVT.+4F3 BITS(.....1..)
DUPLEX TAPE
For duplexed migration, both output tapes must be of the exact same size and unit type. A preferred practice is to use a multicluster grid and the new Synchronous mode copy support, and enable the hardware to run the duplex rather than the DFSMShsm software function. This method also enables you to more easily manage the disaster side. You can use Geographically Dispersed Parallel Sysplex (GDPS) and switch to the remote DASD side and the tape VOLSER itself does not need to be changed. No TAPEREPL or SETSYS DISASTERMODE commands are needed.
When HSM writes ML2 data to tape, it deletes the source data as it goes along, but before the RUN is sent to the TS7700 Virtualization Engine. Therefore, until the copy is made, only one copy of the ML2 data might exist. The reason is because the TS7700 Virtualization Engine grid, even with a Copy Consistency Point of [R,R], makes a second copy at RUN time.
By using the appropriate Management Class settings in SMS, you can ensure that a data set is not migrated to ML2 before a valid backup copy of this data set exists. This way, there are always two valid instances from which the data set can be retrieved: One backup and one ML2 version. After the second copy is written at rewind-unload time, two copies of the ML2 data will exist in the grid.
Another way to ensure that two copies of the ML2 data exist is to use hierarchical storage management (HSM) duplexing or the new Synchronous copy mode option support in the TS7700 Virtualization Engine. Both ways create two separate copies of the ML2 data before HSM deletes it. Ideally, with a multicluster grid, you want one copy of the data in one cluster and the second copy in another cluster to avoid loss of data if one of the clusters experiences a disaster. You can use the Copy Consistency Points to ensure that each copy of the duplexed data is sent to a separate cluster.
RECYCLE
The DFSMShsm RECYCLE function reduces the number of logical volumes inside the TS7700 Virtualization Engine, but when started, it can cause bottlenecks in the TS7740 Virtualization Engine recall process. If you have a TS7740 Virtualization Engine with four physical drives, use a maximum of two concurrent DFSMShsm RECYCLE tasks. If you have a TS7740 Virtualization Engine with six physical drives, use no more than five concurrent DFSMShsm RECYCLE tasks.
Select the RECYCLEPERCENT and consider the following information:
•You will free up logical volumes on a stacked volume with hundreds of other logical volumes.
•The space occupied by the logical volume is freed up only if and when the logical volume is used (overwritten) again, unless you are using Expired Volume Management.
•To RECYCLE, the TS7700 Virtualization Engine must load the input volumes into the TVC.
Use a RECYCLEPERCENT value that depends on the logical volume size, for example:
•5 for 1000 MB, 2000 MB, 4000 MB, or 6000 MB volumes
•10 for 400 MB or 800 MB volumes
You can use the following commands to limit which volumes can be selected for DFSMShsm RECYCLE processing. For instance, you might want to limit RECYCLE to only your old technology, and exclude the newer tape technology from RECYCLE until the conversion is complete. You can use the following commands to limit which tape volume ranges are selected for RECYCLE:
•RECYCLE SELECT (INCLUDE(RANGE(nnnnn:mmmmm)))
•RECYCLE SELECT (EXCLUDE(RANGE(nnnnn:mmmmm)))
You can also use the SETSYS RECYCLEOUTPUT to determine which tape unit to use for the RECYCLE output tapes. You can use your ACS routines to route the RECYCLEOUTPUT unit to the wanted library using the &UNIT variable.
See IBM z/OS DFSMShsm Primer, SG24-5272 for more information about implementing DFSMShsm.
7.5 DFSMSrmm and other tape management systems
No changes are required to any tape management system to support basic TS7700 Virtualization Engine. You only need to review the retention and movement criteria for the data in the TS7700 Virtualization Engine. You also need to check your daily tape management process to delete any step that relates to EJECT activities.
DFSMSrmm accepts logical volume capacity from an open close end-of volume (OCE) module. DFSMSrmm can now always list the actual reported capacity from TS7700 Virtualization Engine.
To start the low-on-scratch procedure, DFSMSrmm uses these messages:
•CBR3660A
•CBR3792E
•CBR3794A
When you direct allocations inside the TS7700 Virtualization Engine, the vital record specifications (VRSs), or vault rules, indicate to the tape management system that the data set will never be moved outside the library. During VRSEL processing, each data set and volume is matched to one or more VRSs, and the required location for the volume is determined based on priority. The volume’s required location is set.
The volume is not moved unless DSTORE is run for the location pair that includes the current volume location and its required location. For logical volumes, this required location can be used to determine which volume must be exported. For Copy Export, the required location is only used for stacked volumes that have been Copy Exported.
Other tape management systems must modify their definitions in a similar way. For example, CA-1 Tape Management must modify their RDS and VPD definitions in CA/1 PARMLIB. Control-M/Tape (Control-T) must modify its rules definitions in the Control-T PARMLIB.
The DFSMSrmm return-to-scratch process has been enhanced to enable more parallelism in the return-to-scratch process. EDGSPLCS is a new option for the EDGHSKP SYSIN file EXPROC command that can be used to return to scratch tapes in an asynchronous way. With the most recent software support changes, EDGSPLCS can be used to run scratch processing in parallel across multiple libraries, or in parallel within a library.
The only necessary step is to run different instances of CBRSPLCS. For more information about the enhanced return-to-scratch process, see z/OS DFSMSrmm Implementation and Customization Guide, SC23-6874.
Stacked volumes cannot be used by the host; they are managed exclusively by the TS7740 Virtualization Engine. Do not enable any host to either implicitly or explicitly address these stacked volumes. To indicate that the stacked VOLSER range is reserved and cannot be used by any host system, define the VOLSERs of the stacked volumes to RMM.
Use the following PARMLIB parameter, assuming that VT is the prefix of your stacked TS7700 Virtualization Engine cartridges:
REJECT ANYUSE(VT*)
This parameter causes RMM to deny any attempt to read or write those volumes on native drives. There are no similar REJECT parameters in other tape management systems.
You do not need to explicitly define the virtual volumes to RMM. During entry processing, the active RMM automatically records information about each volume in its control data set. RMM uses the defaults that you specified in ISMF for the library entry values if there is no existing RMM entry for an inserted volume. Set the default entry status to SCRATCH.
When adding 1,000,000 virtual volumes, the size of the RMM CDS and the amount of secondary space available must be checked. RMM uses 1 MB for every 1,000 volumes defined in its CDS. An extra 1,000,000 volumes need 1,000 MB of space. However, do not add all the volumes initially. See “Inserting virtual volumes” on page 514 for more information.
To increase the size of the RMM CDS, you must quiesce RMM activities, back up the CDS, and then reallocate a new CDS with a larger size and restore the CDS from the backup copy. To calculate the correct size of the RMM CDS, see z/OS DFSMSrmm Implementation and Customization Guide, SC23-6874. You might consider using VSAM extended format in your CDS. Extended format and Multivolume support almost any growth rate in the Configuration Data Set.
Other tape management systems, such as BrightStor, CA-1 Tape Management Copycat Utility (BrightStor CA-1 Copycat), and BrightStor CA-Dynam/TLMS Tape Management Copycat Utility (BrightStor CA-Dynam/TLMS Copycat) must reformat their database to add more volumes. Therefore, they must stop to define more cartridges.
Additionally, some tape management systems do not enable the specification of tape volumes with alphanumeric characters or require user modifications to do so. See the correct product documentation for this operation.
In both RMM and the other tape management systems, the virtual volumes do not have to be initialized. The first time that a VOLSER is used, TS7700 Virtualization Engine marks the virtual volume with VOL1, HDR1, and a tape mark, as though it had been done by EDGINERS or IEHINITT.
7.6 IBM Tivoli Storage Manager
IBM Spectrum Protect (Tivoli Storage Manager family) provides backup, snapshot, archive, recovery, space management, bare machine recovery and disaster recovery capabilities. Throughout this publication the Tivoli Storage Manager name will be referenced.IBM Tivoli Storage Manager, like DFSMShsm, can automatically fill a native 3592 cartridge. It can use the tape up to EOV, independent of the media type.
Tivoli Storage Manager 6.1, released in 2009, had no Tivoli Storage Manager Server support for z/OS. IBM Tivoli Storage Manager for z/OS Media V6.3 and IBM Tivoli Storage Manager for z/OS Media Extended Edition V6.3 are replacement products for Tivoli Storage Manager V5.5 and Tivoli Storage Manager Extended Edition for z/OS V5.5, with new functions available in Tivoli Storage Manager V6, while maintaining the ability to access Fibre Channel connection (FICON)-attached storage on a z/OS system.
IBM Tivoli Storage Manager for z/OS Media and IBM Tivoli Storage Manager for z/OS Media Extended Edition, introduced with Version 6.3, are designed to enable IBM Tivoli Storage Manager V6.3 servers running on IBM AIX® and Linux on System z to access various FICON-attached tape libraries on z/OS, including the TS7700 Virtualization Engine family.
For the latest Tivoli Storage Manager supported levels for Linux on z Systems see the IBM Knowledge Center:
Figure 7-1 shows a high-level drawing of the data flow in a Tivoli Storage Manager for z/OS Media environment.
Figure 7-1 Data flow from the backup-archive client to z/OS media server storage
The following numbers correspond to the numbers in Figure 7-1:
1. The Tivoli Storage Manager backup-archive client contacts the Tivoli Storage Manager server.
2. The Tivoli Storage Manager server selects a library resource and volume for the backup operation.
3. The Tivoli Storage Manager server contacts the z/OS media server to request a volume mount.
4. The z/OS media server mounts the tape volume.
5. The z/OS media server responds to the Tivoli Storage Manager server that the mount operation is complete.
6. The backup-archive client begins sending data to the Tivoli Storage Manager server.
7. The Tivoli Storage Manager server stores metadata in the database and manages the data transaction.
8. The Tivoli Storage Manager server sends the backup-archive client data to the z/OS media server.
9. The z/OS media server writes the data to z/OS storage.
If you plan to store IBM Tivoli Storage Manager data into the TS7700 Virtualization Engine, consider the following suggestions for placing data on your TS7700 Virtualization Engine:
•Use TS7740 Virtualization Engine for IBM Tivoli Storage Manager archiving for archiving and backing up large files or databases for which you do not have a high-performance requirement during backup and restore. TS7740 Virtualization Engine is ideal for IBM Tivoli Storage Manager archive or long-term storage because archive data is infrequently retrieved. Archives and restorations for large files can see less effect from the staging.
Small files, such as individual files on file servers, can see performance effects from the TS7740 Virtualization Engine staging. If a volume is not in cache, the entire volume must be staged before any restore can occur.
•Set IBM Tivoli Storage Manager reclamation off by setting the reclamation threshold to 100%. IBM Tivoli Storage Manager, like DFSMShsm, has a reclamation function to consolidate valid data from tapes with a low valid data percentage onto scratch tapes so that tapes can be freed up for reuse. IBM Tivoli Storage Manager reclamation with TS7740 Virtualization Engine can be slower because all volumes must be staged to the cache.
Periodically, set IBM Tivoli Storage Manager reclamation on by setting the threshold to a lower value to regain the use of TS7700 Virtualization Engine volumes with a small amount of valid data that will not expire for a longer period. IBM Tivoli Storage Manager reclamation must be scheduled for off-peak hours.
•Use collocation to reduce the number of TS7700 Virtualization Engine volumes required for a full restore. IBM Tivoli Storage Manager has a collocation function to group IBM Tivoli Storage Manager client data onto a minimum set of tapes to provide a faster restore and to provide separation of client data onto separate physical tapes. Collocation with TS7740 Virtualization Engine does not minimize the physical tapes used, but minimizes the number of logical volumes used.
Collocation with TS7740 Virtualization Engine can improve restore time for large amounts of data. TS7740 Virtualization Engine does not ensure physical tape separation when collocation is used because separate logical volumes can be on the same physical tape.
•Use TS7740 Virtualization Engine for IBM Tivoli Storage Manager database backups that are to be used for recovery from local media, and use TS7740 Virtualization Engine at a recovery site or native drives for backups that are to be used for recovery from offsite media. IBM Tivoli Storage Manager requires a separate tape for every backup of the IBM Tivoli Storage Manager database, so many logical volumes with less data is created.
When using the TS7700 Virtualization Engine, you do not have to worry about the unused capacity of logical volumes.
•Use TS7740 Virtualization Engine for backups of primary pools, noting that similar considerations apply to copy storage pools. If only one copy pool is used for local backups, that storage pool must not be in the TS7740 Virtualization Engine because there is no guarantee that data in the copy storage pools is on separate physical volumes.
If storage pools for local and offsite backups are used, the copy storage pools for local backups can be in the TS7740 Virtualization Engine. The copy storage pools for offsite backups must use native drives or a TS7740 Virtualization Engine at the recovery site.
•Use TS7700 Virtualization Engine in server-to-server configurations for multiple IBM Tivoli Storage Manager server implementations. If you are using an IBM Tivoli Storage Manager server-to-server configuration, the data from your remote IBM Tivoli Storage Manager servers is stored as virtual volumes in the TS7700 Virtualization Engine, which appear as sequential media volumes on the source server and are stored as archive files on a target server. These are ideal candidates for a TS7700 Virtualization Engine.
Native or virtual drives
When only one stand-alone TS7740 is available, you might choose native drives for data that will be used for frequent individual file restores or require high performance for backup and restore without any delays because of staging activity. IBM Tivoli Storage Manager uses the EXPORT function to move data from one IBM Tivoli Storage Manager server to another.
This way requires that both servers have compatible devices for the EXPORT media. Use native drives for IBM Tivoli Storage Manager EXPORT unless you have multiple TS7740 and can IMPORT/EXPORT between the TS7740 Virtualization Engines.
IBM Tivoli Storage Manager parameter settings
The settings for the following parameters can affect the performance of IBM Tivoli Storage Manager with TS7700 Virtualization Engine:
•MAXSCRATCH (storage pool definition). As for DFSMShsm, IBM Tivoli Storage Manager must use a scratch pool for tapes because you do not have to predefine tapes to Tivoli Storage Manager, and you can benefit from the faster TS7700 Virtualization Engine scratch mounts.
•MOUNTLimit (device class definition). With one TS7700 Virtualization Engine, you have up to 256 virtual drives available. The number of drives available for IBM Tivoli Storage Manager use can probably be increased, considering TS7700 Virtualization Engine performance. Set the MOUNTLimit high enough so that the number of available drives does not limit the performance of IBM Tivoli Storage Manager tape operations.
•MOUNTRetention (device class definition). When storing data in the TS7700 Virtualization Engine, you can set this parameter to zero because you have a greater chance of finding the virtual volume still in the TVC when IBM Tivoli Storage Manager needs it. This avoids the need to keep the virtual volume mounted and frees a virtual drive for other users.
•MAXCAPacity (device class definition). With this parameter, you can tailor the size of the data written in a virtual volume. Having smaller virtual volumes can speed up recall processing. Using the full capacity of the virtual volume can limit the number of volumes used by Tivoli Storage Manager.
•Backup DB (database backup). Use SCRATCH=YES to use tapes from the Tivoli Storage Manager scratch pool and benefit from the faster TS7700 Virtualization Engine scratch mounts.
For more information about setting up Tivoli Storage Manager, see the following web page:
7.7 DFSMSdss
This section describes the uses of DFSMSdss with the TS7700 Virtualization Engine.
7.7.1 Full volume dumps
DFSMSdss full volume dumps can use the TS7700 Virtualization Engine well. Plan to make sure that you can achieve the required throughput. A DFSMSdss full volume physical dump can easily provide a data transfer rate of 10 MBps and higher for a single job. However, with today’s TS7700 Virtualization Engine throughput capabilities, the TS7700 Virtualization Engine throughput capabilities most likely will not be a limiting factor. In the past, the data rate was often limited by the bandwidth of the DASD subsystem as the weakest part in the chain.
With TS7740 Virtualization Engine, you fill the stacked cartridge completely without changing JCL, using multiple virtual volumes. TS7740 Virtualization Engine then moves the virtual volumes that are created onto a stacked volume.
The only problem that you might experience when using TS7700 Virtualization Engine for the Data Set Services (DSS) volume dumps is related to the size of the virtual volumes. If a single dump does not fit onto five logical volumes, you can use an SMS DATACLAS specification, Volume Count nn, to enable more than five volumes. A better method is to choose a 6000 MB logical volume through your SMS DATACLAS. This method prevents unneeded multivolume files.
Using the COMPRESS keyword of the DUMP command, you obtain a software compression of the data at the host level. Because data is compressed at the TS7700 Virtualization Engine before being written into the TVC, host compression is not required unless channel use is high already.
7.7.2 Stand-Alone Services
Stand-Alone Services of DFSMSdss provides a stand-alone restore function that enables you to restore vital system packs without needing to rely on a System z environment.
Stand-Alone Services supports the 3494 and 3584 (TS3500) Tape Library and the Virtual Tape Server. You can use it to restore from native and virtual tape volumes in a TS7700 Virtualization Engine. With Stand-Alone Services, you specify the input volumes on the RESTORE command and send the necessary mount requests to the tape library.
You can use an initial program load (IPL) of the Stand-Alone Services core image from a virtual tape device and use it to restore dump data sets from virtual tape volumes.
Stand-Alone Services is provided as a replacement to the previous DFDSS V2.5 and DFSMS/MVS V1 stand-alone functions. The installation procedure for Stand-Alone Services retains, rather than replaces, the existing stand-alone restore program so you do not have to immediately change your recovery procedures. Implement the procedures as soon as you can and start using the enhanced Stand-Alone Services.
To use Stand-Alone Services, create a stand-alone core image suitable for IPL by using the new BUILDSA command of DFSMSdss. Create a new virtual tape as non-labeled and then put the stand-alone program on it.
For more information about how to use the TS7700 MI to set a device in stand-alone mode, see “Modify Virtual Volumes window” on page 367.
Complete these steps to use an IPL of the Stand-Alone Services program from a virtual device and restore a dump data set from virtual volumes:
1. Ensure that the virtual devices you will be using are offline to other host systems. Tape drives to be used for stand-alone operations must remain offline to other systems.
2. Set in stand-alone mode the virtual device from which you will load the Stand-Alone Services program by selecting Virtual Drives on the TS7700 MI of the cluster where you want to mount the logical volume.
3. Follow the sequence shown in the Figure 7-2 to select a logical drive and logical volume for a stand-alone mount. Then click OK, and the logical volume is mounted in the designated logical drive.
Figure 7-2 The MI sequence to perform a stand-alone mount
Figure 7-2 (lower-right corner) shows the window that opens, where you specify the virtual volume that contains the core image for IPL.
4. Load the Stand-Alone Services program from the device you set in stand-alone mode. As part of this process, select the operator console and specify the input device for entering Stand-Alone Services commands.
5. When the IPL is complete, enter the Stand-Alone Services RESTORE command from the specified input device. Example 7-1 shows a group of statements for using this command.
Example 7-1 RESTORE command
RESTORE FROMDEV(TAPE) FROMADDR(0A40) TOADDR(0900) -
NOVERIFY TAPEVOL((L00001),(L00002))
L00001 and L00002 are virtual volumes that contain the dump data set to be restored. 0A40 is the virtual device used for reading source volumes L00001 and L00002. And, 0900 is the device address of the DASD target volume to be restored.
Stand-Alone Services requests the TS7700 to mount the source volumes in the order in which they are specified on the TAPEVOL parameter. It automatically unloads each volume, then requests the TS7700 Virtualization Engine to unmount it and to mount the next volume.
6. When the restore is complete, unload and unmount the IPL volume from the virtual device by using the TS7700 MI’s Setup Stand-alone Device window.
7. In the Virtual Drives window in Figure 8-59 on page 348, click Actions → Unmount logical volume to unload the virtual drive and finish the Stand-alone Mount operation.
Stand-Alone Services sends the necessary mount and unmount orders to the library. If you are using another stand-alone restore program that does not support the mounting of library resident volumes, you must set the source device in stand-alone mode and manually instruct the TS7700 Virtualization Engine to mount the volumes by using the Setup Stand-alone Device window.
For more information about how to use Stand-Alone Services, see the z/OS DFSMSdss Storage Administration, SC23-6868.
7.8 Object access method
Tape cartridges provide a low-cost storage medium for storing primary and backup copies of object access method (OAM) objects.
Enabling objects to be stored on tape volumes with DASD and optical media provides flexibility and more efficiency within the storage management facility.
OAM stores objects on a TS7700 Virtualization Engine as they are stored in a normal TS3500 Tape Library, with up to 256 virtual drives and many virtual volumes available.
When using the TS7740 Virtualization Engine, consider using the TAPEPERCENTFULL parameter with object tape data because the retrieval time of an OAM object is important. The recall time for smaller logical volumes can be reduced considerably.
The OAM TAPECAPACITY parameter is no longer needed when using the TS7700 Virtualization Engine with OAM. Starting with Release 1.4 of the TS7700 and with APAR OA24966 installed, OAM now obtains the capacity of the logical volume from the library.
Virtual volumes in a TS7700 Virtualization Engine can be used to store your object data (OBJECT or OBJECT BACKUP Storage Group data). With the data in cache, the TS7720 Virtualization Engine can be ideal for your primary OBJECT Storage Group needs. Your OBJECT BACKUP Storage Groups can then be in a TS7720, a TS7740, or on native tape, depending on your recovery needs.
As with DFSMShsm, the Synchronous mode copy option can be used to replicate your data to other clusters in the grid. This replicated copy (and others in the grid) is then managed by the TS7700 Virtualization Engine. The replication capabilities in the grid can be used in addition to any OAM-managed backup copies.
A virtual volume can contain multiple OAM objects. To optimize the use of TS7700 Virtualization Engine storing OAM object data, consider the following suggestions:
•Review the MOUNTWAITTIME parameter when using TS7740 Virtualization Engine to store OAM object tape data. The default (5 minutes) probably needs to be increased. Twelve minutes is a better number in case you must recall a logical volume to read object data and there are other recall requests queued at the time. The TS7740 Virtualization Engine might need to stage the data back into cache, which accounts for the extra mount time.
•Review the MAXTAPERETRIEVETASKS and MAXTAPESTORETASKS parameters when using TS7700 Virtualization Engine because you have more virtual tape drives available.
•Other parameters, such as DEMOUNTWAITTIME, TAPEPERCENTFULL, and TAPEFULLTHRESHOLD, also might need to be reviewed when using TS7700 Virtualization Engine to store OAM data.
7.9 Database backups
Using a TS7700 Virtualization Engine as output confers several advantages to database backups. This section provides a detailed description of these benefits for database products, such as DB2.
7.9.1 DB2 data
DB2 uses tapes for storing archive logs and for storing image copies. Either one can be created in multiple copies, to be stored both onsite for local recovery purposes and offsite for disaster recovery purposes. To use DB2 tape data with the TS7700 Virtualization Engine, use the approaches that are described in this section.
Archive logs
DB2 tracks database changes in its active log. The active log uses up to 31 DASD data sets (up to 62 with dual logging) in this way: When a data set becomes full, DB2 switches to the next one and automatically offloads the full active log to an archive log.
Archive logs are sequential data sets that are allocated on either DASD or tape. When archiving to tape, a scratch tape volume is requested each time.
Archive logs contain unique information necessary for DB2 data recovery. Therefore, to ensure DB2 recovery, make backups of archive logs. You can use general backup facilities or DB2’s dual archive logging function.
When creating a Dual Copy of the archive log, usually one is local and the other is for disaster recovery. The local copy can be written to DASD, then moved to tape, using Tape Mount Management (TMM). The other copy can be written directly to tape and then moved to an offsite location.
With TS7700 Virtualization Engine, you can write the local archive log directly inside the TS7700 Virtualization Engine. Avoiding the use of TMM saves DASD space, saves DFSMShsm CPU cycles, and simplifies the process. The disaster recovery copy can be created using Copy Export capabilities in the TS7740, or using native tape drives, so that it can be moved offsite.
The size of an archive log data set varies from 150 MB to 1 GB. The size of a virtual volume on a TS7700 Virtualization Engine can be up to 6000 MB, so be sure that your archive log can fit in only one virtual volume. Use a single volume when unloading an archive log to tape. The size of a virtual volume on a TS7700 Virtualization Engine can be up to 18,000 MB, assuming a 3:1 compression ratio.
Tailoring the size and number of active log DASD data sets enables you to obtain an archive log on tape whose size does not exceed the virtual volume size.
Limiting data set size might increase the frequency of offload operations and reduce the amount of active log data on DASD. However, this is not a problem with the TS7720 or the TS7740 Virtualization Engine because neither requires manual operation. Even with the TS7740, the archive logs stay in the TVC for some time and are available for fast recovery.
One form of DB2 recovery is backward recovery, typically done after a processing failure, where DB2 backs out uncommitted changes to resources. When doing so, DB2 processes log records in reverse order, from the latest back toward the oldest.
If the application being recovered has a large data set and makes only a few commit operations, you probably need to read the old archive logs that are on tape. When archive logs are on tape, DB2 uses read-backward channel commands to read the log records. Read-backward is a slow operation on tape cartridges processed on real IBM 3480 (if improved data-recording capability (IDRC) is enabled) and IBM 3490 tape drives.
On a TS7700 Virtualization Engine, it is only about 20% slower than a normal I/O because data is retrieved from the TVC, so the tape drive characteristics are replaced by the random access disk characteristics. Another benefit TS7700 Virtualization Engine can provide for DB2 operations is the availability of up to 256 (stand-alone cluster) or 1536 virtual drives (six-cluster grid configuration) because DB2 often needs many drives concurrently to run recovery or backup functions.
Image copies
Image copies are backup copies of table spaces in a DB2 database. DB2 can create both full and incremental image copies. A full image copy contains an image of the whole table space at the time the copy was taken. An incremental image copy contains only those pages of a table space that have changed since the last full image copy was taken. Incremental image copies are typically taken daily. Full image copies are typically taken weekly.
DB2 provides the option for multiple image copies. You can create up to four identical image copies of a table space, one pair for local recovery use and one pair for offsite storage.
The size of the table spaces to be copied varies from a few megabytes to several gigabytes. The TS7700 Virtualization Engine solution is best for small-sized and medium-sized table spaces because you need a higher bandwidth for large table spaces.
When a database is recovered from image copies, a full image copy and the subsequent incremental image copies need to be allocated at the same time. This can potentially tie up many tape drives and, in smaller installations, can prevent other work from being run. With one TS7700 Virtualization Engine, with its 256 virtual drives, this is not an issue.
The large number of tape drives is important also for creating DB2 image copies. Having more drives available enables you to run multiple copies concurrently and use the MERGECOPY DB2 utility without effect. An advisable solution is to run a full image copy of the DB2 databases once a week outside the TS7700 Virtualization Engine, and run the incremental image copies daily using TS7700 Virtualization Engine. The smaller incremental copy fits better with the TS7700 Virtualization Engine volume sizes.
7.9.2 CICS and IMS
As with DB2, both IBM CICS® and IMS™ use tapes to store logs and image copies of databases.
CICS is only a data communication product. IMS has both the data communication and the database function (IMS-DL/1). CICS uses the same DL/1 database function to store its data.
CICS journals and IMS logs
CICS tracks database changes in its journal data sets. IMS tracks database changes in its online log data sets. After these data sets become full, both CICS and IMS offload the logs to tape.
CICS and IMS logs are sequential data sets. When offloading these logs to tape, you must request a scratch volume every time.
The logs contain the information necessary to recover databases and usually those logs are offloaded, as with DB2, in two copies, one local and one remote. You can write one local copy and then create the second for disaster recovery purposes later, or you can create the two copies in the same job stream.
With TS7700 Virtualization Engine, you can create the local copy directly on TS7700 Virtualization Engine virtual volumes, and then copy those volumes to non-TS7700 Virtualization Engine tape drives, or to a remote TS7700 Virtualization Engine.
Having a local copy of the logs written inside the TS7700 Virtualization Engine enables you faster recovery because the data stays in the TVC for some time.
When recovering a database, you can complete back out operations in significantly less time with the TS7700 Virtualization Engine because when reading logs from tape, IMS uses the slow read backward operation (100 KBps) on real tape drives. With the TS7700 Virtualization Engine, the same operation is much faster because the data is read from TVC.
Lab measurements do not see much difference between read forward and read backward in a TS7700 Virtualization Engine. Both perform much better than on physical drives. The reason is not just that the data is in the TVC, but the TS7700 Virtualization Engine code also fully buffers the records in the reverse order that they are on the volume when in read backwards mode.
Another benefit TS7700 Virtualization Engine provides to recovery operations is the availability of up to 256 virtual drives per cluster. This configuration enables you to mount several logs concurrently and therefore to back out the database to be recovered faster.
The IMS change accumulation utility is used to accumulate changes to a group of databases from several IMS logs. This implies the use of many input logs that will be merged into an output accumulation log. With the TS7700 Virtualization Engine, you can use more tape drives for this function.
Image copies
Image copies are backup copies of the IMS databases. IMS can create only full image copies. To create an image copy of a database, use a batch utility, copying one or more databases
to tape.
to tape.
With the TS7700 Virtualization Engine, you do not have to stack multiple small image copies to fill a tape cartridge. Using one virtual volume per database does not waste space because the TS7700 Virtualization Engine then groups these copies into a stacked volume.
IMS, unlike DB2, has a batch function that works with databases through an IMS batch region. If you do not use logs when running an IMS batch region, you must use an image copy taken before running the batch job to recover the database. Otherwise, you can use logs and checkpoints, which enable you to restart from a consistent database image taken during the batch execution processing. Using TS7700 Virtualization Engine, you can access these image copies and logs at a higher speed.
The TS7700 Virtualization Engine volume stacking function is the best solution for every database backup because it is transparent to the application and does not require any JCL procedure change.
7.9.3 Batch data
The following applications write to tape and benefit from using the TS7700 Virtualization Engine:
•VSAM REPRO
•IEBGENER/IEBCOPY/ICETOOL
•DSS data set COPY or DUMP
•DFSMSrmm Tape Copy Tool (an IBM service offering)
•IBM Tivoli Tape Optimizer
•Any other tape copy utility
The amount of data from these applications can be huge if your environment does not use TMM or if you do not have DFSMShsm installed. All of this data benefits from using the TS7700 Virtualization Engine for output.
With TS7700 Virtualization Engine, the application can write one file per volume, using only part of the volume capacity. The TS7740 Virtualization Engine takes care of completely filling the stacked cartridge for you, without JCL changes.
The only step that you must remember is that if you need to move the data offsite, you must address a device outside the local TS7700 Virtualization Engine, or use other techniques to copy TS7700 Virtualization Engine data onto other movable tapes, as described in 7.3.6, “Moving data out of the TS7700 Virtualization Engine” on page 263.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.