IBM Universal Remote SG24 5360 00 User Manual

IBM  
RAMAC Virtual Array,  
Peer-to-Peer Remote Copy,  
and IXFP/SnapShot for VSE/ESA  
Alison Pate Dionisio Dychioco Guenter Rebmann Bill Worthington  
International Technical Support Organization  
This book was printed at 240 dpi (dots per inch). The final production redbook with the RED cover will  
be printed at 1200 dpi and will provide superior graphics resolution. Please see “How to Get ITSO  
Redbooks” at the back of this book for ordering instructions.  
SG24-5360-00  
 
SG24-5360-00  
International Technical Support Organization  
IBM  
RAMAC Virtual Array,  
Peer-to-Peer Remote Copy,  
and IXFP/SnapShot for VSE/ESA  
January 1999  
 
Take Note!  
Before using this information and the product it supports, be sure to read the general information in  
Appendix E, “Special Notices” on page 65.  
First Edition (January 1999)  
This edition applies to Version 6 of VSE Central functions, Program Number 5686-066, Version 2, Release 3.1 of  
VSE/ESA, Program Number 5590-VSE, and Version 1, Release 16 of Initialize Disk (ICKDSF), Program Number  
5747-DS2 for use with the VSE/ESA operating system.  
Comments may be addressed to:  
IBM Corporation, International Technical Support Organization  
Dept. QXXE Building 80-E2  
650 Harry Road  
San Jose, California 95120-6099  
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any  
way it believes appropriate without incurring any obligation to you.  
Copyright International Business Machines Corporation 1999. All rights reserved.  
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is  
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.  
 
Contents  
Preface  
The Team That Wrote This Redbook  
Comments Welcome  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. vii  
.
vii  
.
.
.
.
.
.
.
.
viii  
Chapter 1. The IBM RAMAC Virtual Array  
1.1 What Is an IBM RAMAC Virtual Array?  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
2
3
3
3
4
5
1.1.1 Overview of RVA and the Virtual Disk Architecture  
1.1.2 Log Structured File  
1.1.3 Data Compression and Compaction  
1.2 VSE/ESA Support for the RVA  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1.2.1 What Is IXFP/SnapShot for VSE/ESA?  
1.2.2 What Is SnapShot?  
1.2.3 What Is IXFP?  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1.3 What Is Peer-to-Peer Remote Copy?  
Chapter 2. RVA Benefits for VSE/ESA  
2.1 RVA Simplifies Your Storage Management  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
8
8
9
9
10  
10  
10  
11  
11  
2.1.1 Disk Capacity  
2.1.2 Administration  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.1.3 IXFP  
.
.
.
.
.
.
2.2 Batch Window Improvement  
2.2.1 RAMAC Virtual Array  
.
.
2.2.2 IXFP/SnapShot for VSE/ESA  
2.3 Application Development  
2.4 RVA Data Availability  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.4.1 Hardware  
2.4.2 SnapShot  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.4.3 PPRC  
.
.
Chapter 3. VSE/ESA Support for the RVA  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13  
13  
14  
14  
14  
15  
15  
15  
3.1 Prerequisites  
3.2 Volumes  
3.3 Host Connection  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.3.1 VSE/ESA Input/Output Configuration Program  
3.4 ICKDSF  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.4.1 Volume Minimal Init  
3.4.2 Partial Disk Minimal Init  
.
.
.
Chapter 4. IXFP/SnapShot for VSE/ESA  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17  
21  
21  
23  
24  
25  
25  
26  
26  
27  
27  
29  
31  
4.1 IXFP SNAP  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.1.1 A Full Volume  
.
.
.
.
4.1.2 A Range of Cylinders  
4.1.3 A Non-VSAM File  
.
.
.
.
.
.
.
.
4.2 IXFP DDSR  
4.2.1 Expired Files  
4.2.2 A Total Volume  
.
.
.
.
.
.
.
.
.
.
.
4.2.3 A Range of Cylinders  
4.2.4 A Specified File  
4.3 IXFP REPORT  
.
.
.
.
.
.
.
.
.
.
4.3.1 Device Detail Report  
4.3.2 Device Summary Report  
Copyright IBM Corp. 1999  
iii  
 
4.3.3 Subsystem Summary Report  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31  
Chapter 5. Peer-to-Peer Remote Copy  
5.1 PPRC and VSE/ESA Software Requirements  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33  
34  
35  
35  
36  
36  
36  
36  
37  
37  
38  
38  
38  
39  
39  
5.2 PPRC Hardware Requirements  
5.3 Invoking peer-to-peer remote copy  
5.4 SnapShot Considerations  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.4.1 Primary Devices of a PPRC Pair  
5.4.2 Secondary Devices of a PPRC Pair  
5.5 Examples of PPRCOPY Commands  
5.5.1 Setting Up PPRC Paths and Pairs  
5.5.2 Recovering from a Primary Site Failure  
5.5.3 Recovering from a Secondary Site Failure  
5.5.4 Deleting PPRC Pairs and Paths  
5.6 Physical Connections to the RVA  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.6.1 Determining the Logical Control Unit Number for RVA  
5.6.2 Determining the Channel Connection Address  
.
.
.
.
.
.
Appendix A. RVA Functional Device Configuration  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41  
Appendix B. IXFP Command Examples  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43  
43  
43  
45  
47  
47  
48  
49  
49  
50  
50  
51  
52  
52  
53  
53  
53  
54  
B.1 SNAP Command  
B.1.1 Syntax  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.1.2 Using SnapShot to Copy One Volume to Another  
B.1.3 Using SnapShot to Copy a File from One Volume to Another  
B.1.4 Using SnapShot to Copy Files with Relocation  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.1.5 Other Uses of SnapShot  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.2 DDSR Command  
B.2.1 Syntax  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.2.2 Using DDSR to Delete a Single Data Set  
B.2.3 Using DDSR to Delete the Contents of a Volume  
B.2.4 Using DDSR to Delete the Free Space on an RVA  
B.3 Report Command  
B.3.1 Syntax  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.3.2 Reporting on the Capacity of a Single Volume  
B.3.3 Reporting on the Capacity of Multiple Volumes  
B.3.4 Reporting on the Capacity of the RVA Subsystem  
B.4 IXFP/SnapShot Setup Job Streams  
.
.
.
.
.
.
.
.
.
.
.
.
Appendix C. VSE/VSAM Considerations  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59  
60  
C.1 Backing up VSAM Volumes  
Appendix D. IOCDS Example  
Appendix E. Special Notices  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63  
65  
Appendix F. Related Publications  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67  
67  
67  
67  
F.1 International Technical Support Organization Publications  
F.2 Redbooks on CD-ROMs  
F.3 Other Publications  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
How to Get ITSO Redbooks  
IBM Redbook Fax Order Form  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69  
70  
Index  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71  
iv RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
ITSO Redbook Evaluation  
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
73  
Contents  
v
 
vi RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Preface  
This redbook provides a foundation for understanding VSE/ESAs support for the  
IBM 9393 RAMAC Virtual Array (RVA). It covers existing support and the  
recently available IXFP/SnapShot for VSE/ESA and peer-to-peer remote copy  
support for the RVA. It also covers using IXFP/SnapShot for VSE/ESA for  
VSE/VSAM.  
The redbook is intended for use by IBM client representatives, IBM technical  
specialists, IBM Business Partners, and IBM customers who are planning to  
implement IXFP/SnapShot for VSE/ESA on the RVA.  
The Team That Wrote This Redbook  
This redbook was produced by a team of specialists from around the world  
working at the International Technical Support Organization, San Jose Center.  
Alison Pate is a project leader in the International Technical Support  
Organization, San Jose Center. She joined IBM in the UK after completing an  
MSc in Information Technology. A large-systems specialist since 1990, Alison  
has eight years of practical experience in using and implementing IBM DASD  
solutions. She has acted as a consultant to some of the largest, leading-edge  
customers in the United Kingdom—providing technical support and guidance to  
their key business projects.  
Guenter Rebmann is a DASD HW Support Specialist in Germany. He joined IBM  
in 1983 as a Customer Engineer for large system customers. Since 1993 Guenter  
has worked in the DASD-EPSG (EMEA Product Support Group) in Mainz,  
Germany. His area of expertise is large system hardware products.  
Dionisio Dychioco III is a Technical Support Manager in the Philippines. He has  
19 years of experience in data processing, including 17 years in technical  
support in the IBM mainframe environment. Dionisio has worked at the Far East  
Bank & Trust Co. for 12 years. His areas of expertise include MVS, VSE, and  
mainframe-PC connectivity.  
Bill Worthington is a Consulting IT Technical Specialist in the United States. He  
has 38 years of experience in data processing, including 34 years in technical  
sales support within IBM. His areas of expertise include high-end disk storage  
products as well as VSE/ESA and VM/ESA. Bill has been in his current position  
supporting RAMAC DASD products since 1995.  
Thanks to the following people for their invaluable contributions to this project:  
Janet Anglin, Storage Systems Division, San Jose  
Maria Sueli Almeida, International Technical Support Organization, San Jose  
Fred Borchers, International Technical Support Organization, Poughkeepsie  
Jack Flynn, Storage Systems Division, San Jose  
Bob Haimowitz, International Technical Support Organization, Poughkeepsie  
Dan Janda, Jr., Advanced Technical Support, Endicott  
Teresa Leamon, Storage Systems Division, San Jose  
Axel Pieper, VSE Development, Boeblingen, Germany  
Hanns-Joachim Uhl, VSE Development, Boeblingen, Germany  
Copyright IBM Corp. 1999  
vii  
 
Comments Welcome  
Your comments are important to us!  
We want our redbooks to be as helpful as possible. Please send us your  
comments about this or other redbooks in one of the following ways:  
Fax the evaluation form found in “ITSO Redbook Evaluation” on page 73 to  
the fax number shown on the form.  
Use the online evaluation form found at http://www.redbooks.ibm.com/  
Send your comments in an Internet note to [email protected]  
viii RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Chapter 1. The IBM RAMAC Virtual Array  
In this chapter we describe the RAMAC Virtual Array (RVA) and the support that  
VSE/ESA delivers for it.  
1.1 What Is an IBM RAMAC Virtual Array?  
We explain functions here on a level that is needed to understand how data is  
stored and organized on an RVA. If you would like more detailed descriptions of  
this interesting virtual disk architecture, see the redbook entitled IBM RAMAC  
Virtual Array, SG24-4951.  
1.1.1 Overview of RVA and the Virtual Disk Architecture  
Traditional storage subsystems such as the 3990 and 3390 use the count key  
data (CKD) architecture. The CKD architecture defines how and where on the  
disk device the data is physically stored. Any updates to the data are written  
directly to the same position on the physical disk from which the updated data  
was read. This is referred to as update in place.  
IBMs RVA provides a high-availability, high-performance storage solution thanks  
to its revolutionary virtual disk architecture. To the host, the RVA appears as up  
to four traditional 3990 storage controls, with up to 256 3380 or 3390 volumes—64  
functional volumes on each 3990. These devices do not physically exist in the  
subsystem and are referred to as functional devices. Physically, the subsystem  
contains RAID 6-protected arrays of fixed block architecture (FBA) disk devices.  
1.1.2 Log Structured File  
The RAID-protected FBA disk arrays that make up the RVAs physical disk space  
are sequentially filled with data. New and updated data is placed at the end of  
the file, as it is on a sequential or log file. We call this architecture a log  
structured file.  
Updates leave areas in the log file that are no longer needed. A microcode  
process called freespace collection ensures that these areas are put back so that  
there is always enough freespace for writing. This process runs as a  
background task. You can control the freespace by observing the net capacity  
load (NCL) of the RVA and using the IBM Extended Facilities Product (IXFP)  
program. See the RVA redbook entitled IBM RAMAC Virtual Array for more  
information. The RVAs physical disk space typically should be kept below 75%  
NCL. Above that level, the freespace collection process runs with higher priority,  
and performance degradation may result. A service information message (SIM)  
informs operators when this threshold is reached.  
The following tables are used to map the tracks of functional devices to the FBA  
blocks related to those tracks:  
Functional device table  
The functional device table (FDT) holds the information about the functional  
volumes that have been defined to the RVA.  
Functional track directory  
Copyright IBM Corp. 1999  
1
 
The functional track directory (FTD) is the collective name for two tables that  
together map each functional track to an area in the RVAs physical storage:  
Functional track table  
The functional track table (FTT) contains the host-related pointers, that is,  
the functional-device-related track pointers of the FTD.  
Track number table  
The track number table (TNT) contains the back-end data pointers of the  
FTD. A reference counter is also part of this table.  
Although the FTD consists of two tables, we discuss it as one entity (see  
Figure 1). In fact, each functional track has an entry in the FDT. If a functional  
track contains data, its associated FTD entry has a pointer to the FBA block  
where the data starts. The data of a functional track may fit on one or more FBA  
blocks.  
If the data of a functional track is updated, the RVA puts the new data in a new  
place in the log structured file, and the FTD entry points to the new data location.  
There is no update in place.  
Figure 1. The RAMAC Virtual Array Tables  
1.1.3 Data Compression and Compaction  
All data in the RVA is compressed; compression occurs when data enters an  
RVA. In addition, the gaps between the records, as they appear on the CKD  
devices, are removed before the data is written to disk. Similarly, the unused  
space at the end of a track is removed. This is called compaction. The  
compression and compaction ratio depends on the nature of the data.  
Experience shows that RVA customers can achieve an overall compression and  
compaction ratio of 3.6:1.  
Data compression speeds up the transfer from and to the arrays. It increases  
the effectiveness of cache memory because when compressed more data can fit  
in cache.  
2
RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
1.2 VSE/ESA Support for the RVA  
The RVA has been supported by VSE/ESA since its introduction. Because the  
RVA presents itself as logical 3380 or 3390 direct access storage devices (DASD)  
attached to a logical 3990 Model 3 storage control, releases of VSE/ESA  
supporting this logical environment have functioned with the RVA. However,  
until now, VSE/ESA has not provided SnapShot, deleted data space release  
(DDSR) or capacity reporting natively. It has depended on VM/ESAs IXFP and  
SnapShot to provide that benefit to VSE/ESA guests.  
1.2.1 What Is IXFP/SnapShot for VSE/ESA?  
IXFP/SnapShot for VSE/ESA is a feature of VSE Central Functions in conjunction  
with VSE/ESA Version 2, Release 3.1. It provides SnapShot, DDSR, and capacity  
reporting support for the RVA. OS/390 and VM/ESA provide two distinct  
products—IXFP and SnapShot—for supporting the RVA, whereas VSE/ESA has  
integrated many of the functions provided by these products into a single feature  
that implements the support in an Attention Routine command.  
1.2.2 What Is SnapShot?  
SnapShot, one of the three functions in IXFP/SnapShot for VSE/ESA, enables you  
to produce almost instantaneous copies of non-VSAM data sets, volumes, and  
data within CYLINDER ranges.  
Note: Although not officially supported, VSAM data sets can be indirectly copied  
through techniques we discuss in Appendix C, “VSE/VSAM Considerations” on  
page 59.  
The speed in copying is attained by exploiting the RVAs virtual disk architecture.  
Snapshot produces copies without data movement. We call making a copy with  
SnapShot a snap. The result of a SnapShot is also called a snap.  
Conventional methods of copying data on DASD consist of making a physical  
copy of the data on either DASD or tape. Host processors, channels, tape, and  
DASD controllers are involved in these conventional copy processes. Copying  
may take a long time, depending on available system resources.  
In the RVAs virtual disk architecture, a functional device is represented by a  
certain number of pointers in the FTD. Every used track has a pointer in the FTD  
to its back-end data. You snap a copy of the data by copying its FTD pointers.  
As you can imagine, snapping is a very fast process that takes seconds rather  
than minutes or hours. No data movement takes place, and no additional  
back-end physical space is used. Both FTD pointers, the original and the copy,  
point to the same physical data location (see Figure 2 on page 4). Notice too  
that the TNT entry now has a value of 2, which indicates that the data is in use  
by two logical volumes.  
Chapter 1. The IBM RAMAC Virtual Array  
 
3
Figure 2. Data Snapping. SnapShot creates a logical copy by copying the FTD pointers.  
Only when either the original or the copied track is updated is its associated FTD  
pointer changed to point to the new data location. The other FTD pointer  
remains unchanged. Additional space is needed in this case. As long as there  
is a pointer to a data block in the physical disk storage, the block cannot become  
free for the freespace collection process. A reference counter in the TNT  
prevents the block from becoming free.  
Although the creation of the copy is a logical manipulation of pointers, the data  
exists on disk, so in this sense is not a logical copy. As far as the operating  
system is concerned, the two copies are completely independent of each other.  
On the RVA hardware side, the snap is a virtual copy of the data.  
1.2.3 What Is IXFP?  
The IXFP portion of IXFP/SnapShot for VSE/ESA provides two functions: DDSR  
and reporting.  
1.2.3.1 Deleted Data Space Release  
The RVA manages the freespace in the back-end storage by monitoring space  
that is no longer occupied by active data. This may be space formerly occupied  
by temporary files, such as DFSORT for VSE work files, or it may be space that  
previously held data that has been updated and written back to a different array  
track in the back-end storage of the RVA. The difference is that the RVA does  
not know that the sort work space is no longer needed without being explicitly  
told to release it into the free space pool.  
The DDSR option of the IXFP operator command provides the ability to release  
this freespace back to the RVA. Using DDSR, allocated space can be returned to  
the RVA on a subsystem or volume basis. Individual files can also be deleted  
and their space returned. DDSR is done using the new IXFP Attention Routine  
command when space reclamation is needed. Either the operator can invoke  
the commands, or a job stream can include them.  
4
RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
1.2.3.2 Reporting Functions  
The IXFP/SnapShot for VSE/ESA reporting functiion displays logical volume  
utilization, such as space allocated and data stored on the volume. It can also  
display a summary of the entire subsystem and its NCL, freespace, capacity  
allocated and used, and the compression and compaction ratio.  
For the capacity management functions supported by OS/390 and VM/ESA, such  
as reconfiguring the DASD, adding or deleting volumes, and draining an array,  
you use the RVAs local operator panel.  
1.3 What Is Peer-to-Peer Remote Copy?  
We explain functions here on a level that is needed to understand how  
peer-to-peer remote copy (PPRC) functions on an RVA. If you would like more  
detailed descriptions of this data availability architecture, see the RVA redbook  
entitled Implementing PPRC on RVA, SG24-4951.  
PPRC allows the synchronous copying of data from a primary RVA to one or  
more secondary RVAs at the same or a different location while providing  
enterprisewide data protection, availability, and ease of system management.  
The secondary site may be up to 43 km away from the primary. The  
synchronous nature of PPRC offers a full recovery solution while delivering the  
highest levels of data integrity and data availability for both operational and  
disaster recovery environments.  
The availability of PPRC on the RVA Model T82 now places the RVA at the heart  
of mission-critical enterprise storage solutions—including remote site disaster  
recovery protection, high availability, and data migration capabilities.  
Chapter 1. The IBM RAMAC Virtual Array  
5
 
6
RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Chapter 2. RVA Benefits for VSE/ESA  
In this chapter we describe how VSE/ESAs support for the RVA assists in  
managing storage, affects batch window characteristics, improves application  
development, and increases the availability of data to the applications running  
on the host system.  
2.1 RVA Simplifies Your Storage Management  
The RVA virtual disk architecture has many benefits to simplify your storage  
management. In this section we discuss the improvements in storage  
management that the functions and features of the RVA provide.  
The space management improvements come from; more effective space use  
from compression, minimizing adminstration, and ease of management using  
IXFP/SnapShot for VSE/ESA (see Figure 3).  
Figure 3. Space Management Improvements  
2.1.1 Disk Capacity  
The virtual disk architecture and the use of data compression enable you to  
store data more effectively in the arrays of the RVA than in a traditional disk  
architecture subsystem. The virtual disk architecture reduces the cost per  
megabyte in your subsystem and increases the internal transfer rate in the RVA.  
There is no allocation of physical disk space for logical volumes, as there is in  
traditional subsystems, so unused disk space is not given away. When data is  
written to the RVA, the arrays are filled sequentially, independent of the volume  
or data set to which the data belongs. The logical capacity that you define is  
independent of the physical capacity that you have installed. Therefore you can  
define more logical volumes than you would be able to define in a traditional  
Copyright IBM Corp. 1999  
7
 
disk architecture, for the same physical space. Thus you can spread data over  
more volumes to improve performance and data availability of the subsystem.  
The hardware design of the RVA allows you to upgrade physical disk space to  
726 GB without any subsystem outage time and without any change to the logical  
device configuration. Cache upgrades are also concurrent with subsystem  
operation. Therefore you have a high level of data availability and low  
subsystem outage time for planned configuration changes.  
2.1.2 Administration  
The subsystem administration activity is reduced for space management. Space  
management is simplified with the RVA, because there is no penalty for  
overallocation. Data placement activity is also reduced. With the use of the log  
structure file, the data from all volumes is spread across all physical disks in the  
array. This eliminates the requirement to separate data for availability or  
performance reasons, such as preventing high activity data sets, tables, or  
indexes from being placed on the same disk volumes.  
When the RVA is installed, you can define up to 256 volumes as either 3390 or  
3380 devices. This gives you flexibility in your configuration and eases migration  
from previous installed hardware. With the virtual disk architecture data  
management and tuning activities are minimized. Data is spread across all  
disks in the array, automatically balancing the I/O load. When data is updated it  
is written to another physical location in the array. As a result uncollected  
freespace is created, which the RVA recycles independently in a background  
routine to have it available for further use. This automatic freespace collection  
keeps the level of the NCL as low as possible without any intervention from  
space management, thus reducing the time and cost of storage management.  
2.1.3 IXFP  
With IXFP it is easy to manage the subsystem and monitor the NCL. With the  
use of IXFP SnapShot, the time expended to copy volumes, data sets, or files is  
considerably reduced. Backups can be done more often to increase the  
consistency and data availability of your system.  
The IXFP reporting function provides information about the space utilization of a  
single RVA device or range of RVA devices. With the DDSR function of IXFP you  
can release expired files residing on all VSE-managed RVA volumes whose  
expiration date has been reached. You can process a complete volume, a  
cylinder range, or a specified file. Thus the RVA can manage subsystem  
freespace more efficiently than before.  
2.2 Batch Window Improvement  
Reducing the batch processing time increases the availability of online  
applications. RVA and IXFP/SnapShot for VSE/ESA help reduce batch processing  
time in several areas.  
8
RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
2.2.1 RAMAC Virtual Array  
The RVAs virtual disk architecture enables performance improvement in batch  
processing. This new architecture, coupled with data compression and  
self-tuning capabilities, improves disk capacity utilization. Data from all logical  
volumes is written across all the physical disks the array. Automatic load  
balancing across the volumes occurs as data is written to the array. Further, the  
ability of the RVA to dynamically configure additional volumes of various sizes  
eliminates volume contention and thereby reduces I/O bottlenecks.  
In the RVA, space that has never been allocated or is allocated but unused takes  
up no capacity. Data set size can increase and new files can be created with  
minimal need to reorganize existing stored data. Users of traditional storage  
systems keep lots of available free space to avoid batch application failures,  
wasting valuable space and increasing storage costs. With the RVA it is not  
necessary to keep lots of free space to avoid out-of-space conditions.  
2.2.2 IXFP/SnapShot for VSE/ESA  
Based on the belief that the best I/O is no I/O, IXFP/SnapShot for VSE/ESA  
reduces online system outage by reducing the amount of elapsed time backups  
and copies need to complete. IXFP/SnapShot for VSE/ESA improves these  
aspects of batch processing:  
Data backup  
Data is backed up during batch processing for many different reasons.  
Copying data to protect against a hardware, software, or application failure  
in the computer center is considered an operational backup. The backup  
might be a complete copy of all data, or an incremental copy, that is, a  
backup of the changes made since the last backup.  
Data backups can be taken between processing steps to protect against data  
loss if a subsequent job or step fails. These backups are called interim  
backups. In some data centers, interim backups are done with tapes.  
Using SnapShot to replace the backup and/or copy operations speeds up  
processing. Tapes are no longer required, and interim backups are done  
more quickly. Additional interim backup points are now possible because of  
the instantaneous copy capability and reduced batch processing time. The  
interim backups are deleted after successful completion of the batch  
process.  
In many cases the operational backups made are also used for disaster  
recovery. Many of the considerations for disaster recovery are also valid for  
operational backup. You can minimize the time for disaster backups using  
SnapShot, by making a SnapShot copy to disk. You can then restart online  
applications before making a tape backup of the SnapShot copy.  
Data set reorganization  
Data set reorganization is very often a time-consuming part of nightly batch  
processing. The REORG becomes important especially when it is part of the  
critical path of batch processing. Traditional reorganization procedures copy  
the affected VSAM key-sequenced data set (KSDS) into a sequential data set  
on tape or on another DASD. This activity takes a long time when large data  
sets are copied. SnapShot can dramatically reduce the run time when used  
in place of IDCAMS REPRO to copy the KSDS into a sequential data set on  
another DASD.  
Chapter 2. RVA Benefits for VSE/ESA  
 
9
Report generation  
A large part of batch processing is often dedicated to generating output  
reports from production data. Often read access only is required by the  
applications. SnapShot can be used to decrease the contention of multiple  
read jobs accessing the same data set by replicating critical files and  
allowing parallel access to multiple copies of the data.  
Production problem resolution  
You can use SnapShot to create a copy of the production database when you  
need to simulate and resolve problem conditions in production. This  
reduces disruption to the production environment as it is possible to snap  
complete copies of the production database in a very short time.  
Application processing  
SnapShot can be used to speed up any data copy steps during batch  
processing.  
2.3 Application Development  
In the area of application development, the RVA and IXFP/SnapShot for VSE/ESA  
provide dynamic volume configuration and rapid data duplication.  
Dynamic volume configuration  
Additional volumes can be easily created if and when required. Using the  
RVA local operator panel and device address predefinition in the VSE I/O  
Configuration Program (IOCP), you can dynamically create or remove  
volumes. You can easily add volumes required to simulate the production  
environment. Temporary scratch volumes needed as work areas or testing  
areas can be easily created. Production volumes can be cloned to re-create  
and resolve a problem.  
Data duplication (including Year 2000)  
Several copies of test databases can be easily produced for several testing  
units to use at the same time, for example, maintenance, user acceptance  
testing, and enhancements. After a test cycle the test database can be reset  
by resnapping from the original with SnapShot. Year 2000 testing requires  
several iterations, to verify code changes with a new date. You can snap  
your existing production database to create a new test database.  
2.4 RVA Data Availability  
The design and concept of the RVA are predicated on a very high level of data  
availability. In this section we discuss the components, functions, and features  
that guarantee and improve the data availability of the RVA.  
2.4.1 Hardware  
The RVA hardware is based on an N+1 concept. All functional areas in the  
machine are duplicated. If one of these areas becomes inoperable because of a  
hardware problem, other parts of the machine can take over its functions,  
without losing data availability. In most cases there is no significant  
performance degradation.  
The disk arrays have two spare drives. If a drive fails, the data is immediately  
reconstructed on one of the spare drives, and the broken drive is fenced. During  
this process data availability is maintained without performance degradation.  
10 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
All necessary repair actions due to a hardware failure are performed  
concurrently with customer operation.  
With the RVA, data availability is also maintained during upgrades. Upgrading  
disk arrays or cache size can be done concurrently with subsystem operation,  
without impact or performance degradation.  
2.4.2 SnapShot  
2.4.3 PPRC  
With SnapShot you can make a copy of your online data to use for different tests  
while the original data is available to the production system. In the same way,  
you can use a SnapShot copy to back up volumes to tape or other media while  
online applications continue to have access to the original data.  
PPRC provides a synchronous copying capability for protection against loss of  
access to data in the event of an outage at the primary site. Whenever a  
disaster occurs at the primary site and the data there is no longer available, you  
can switch to the secondary site. The switch is nearly without impact to or  
outage of your operating system, and all data is again available with minimal  
effort.  
Chapter 2. RVA Benefits for VSE/ESA 11  
 
12 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Chapter 3. VSE/ESA Support for the RVA  
In this chapter we cover several utilities and the VSE/ESA Base Programs that  
support the RVA.  
3.1 Prerequisites  
The RVA has been supported since VSE/ESA Version 1.4 and RVA microcode  
level of LIC 03.00.00 or higher. An equivalent microcode level is required for the  
StorageTek Iceberg 9200.  
To use IXFP/SnapShot and PPRC for VSE/ESA (see Chapter 4, “IXFP/SnapShot  
for VSE/ESA” on page 17 and Chapter 5, “Peer-to-Peer Remote Copy” on  
page 33) the prerequisites are different from the basic RVA support. The  
requirements for IXFP/SnapShot for VSE/ESA support are:  
RAMAC Virtual Array Licensed Internal Code (LIC) 04.03.00 or higher. An  
equivalent microcode level is required for the StorageTek Iceberg 9200.  
Note: LIC level 03.02.00 contains support for SnapShot. However, level  
04.03.00 introduced nondisruptive code load for the RVAs microcode and is  
the recommended minimum level.  
VSE/ESA 2.3.0 (5690-VSE) installed with VSE/AF Supervisor with PTF DY44820  
or higher.  
SnapShot requires Feature 6001 for existing 9393 systems or RPQ 8S0421 for  
StorageTek Icebergs.  
If IXFP/SnapShot for VSE/ESA is used in a VM/VSE environment, VM APAR  
VM61486 is required for minidisk cache (MDC) support.  
For PPRC, the requirements are discussed in 5.1, “PPRC and VSE/ESA Software  
Requirements” on page 34 and 5.2, “PPRC Hardware Requirements” on  
page 35.  
The RVA subsystem provides a set of control and monitoring functions that  
extend the set of IBM 3990 control functions. Many of these functions can be  
invoked either from the host with the IXFP/SnapShot for VSE/ESA or directly from  
the RVA. The Extended Control and Monitoring (ECAM) interface is the protocol  
for communications between the host CPU and the RVA. The use of the ECAM  
interface is generally transparent to the user.  
These functions require that APAR DY44820 be installed and the phase $IJBIXFP  
has been loaded to the SVA via the SET SDL interface. Once the phase has  
loaded, any of above functions can be invoked through simple operator  
commands.  
If you want to enable SnapShot on a StorageTek 9200, you must submit an RPQ  
to IBM for each serial number.  
Before you use IXFP/SnapShot or PPRC for the RVA, we recommend checking  
with your local IBM support center to get information about the latest levels of  
VSE/ESA, microcode, and required APARs.  
Copyright IBM Corp. 1999  
13  
 
3.2 Volumes  
With VSE/ESA and the RVA, the subsystem volumes can be defined in different  
emulation modes. This makes the RVA absolutely adaptable to your needs.  
The following device type emulations are supported with the RVA:  
3380 model J, K, and KE (KE is a 3380K compatible device with the same  
number of cylinders (1770) as a 3380E).  
3390 models 1, 2, and 3  
3.3 Host Connection  
Host connectivity options include parallel and/or ESCON attachment. Extended  
connectivity parallel channel configurations of up to 32 channels are available  
and supported without bus and tag output connections. The bus and tag outputs  
are internally terminated, so the RVA must physically be the last in a  
daisy-chained configuration. ESCON configurations include up to 128 logical  
links, either as direct links or through an ESCON Director.  
The physical channel configuration must match the definitions in the I/O  
configuration data set (IOCDS). The physical connections on the CPU and the  
RVA must reflect the statements in the IOCDS. Mistakes can go undetected until  
later maintenance actions cause unnecessary impact. The channel configuration  
should be planned such that the impact of a single component failure is  
minimized. For an IOCDS example, refer to Appendix D, “IOCDS Example” on  
page 63.  
3.3.1 VSE/ESA Input/Output Configuration Program  
Support for the stand-alone IOCP is supplied with the hardware systems service  
processor or processor controller. IOCP describes a systems I/O configuration  
to the CPU.  
Before you install VSE/ESA natively (not under VM/ESA or an LPAR), make sure  
that you have fully configured your system through IOCP. Starting with VSE/ESA  
1.3, the VSE/ESA IOCP is automatically installed during initial installation of  
VSE/ESA. You can use the IOCP batch program to create a new IOCDS when  
you change the hardware configuration. You can use the IOCP batch program to  
define and validate the IOCP macro instructions if you prepare for the installation  
of a new processor. Use skeleton SKIOCPCN (available in VSE/ICCF library 59)  
as a base for configuration changes.  
An IOCDS must be generated for the hardware the first time through the  
stand-alone IOCP delivered with the processor. For this program you can use  
prepared IOCP macro instructions that have been generated on another  
processor. The specified device numbers for VSE/ESA must be within the range  
0000 through 0FFF. The devices themselves can be attached to any available  
link.  
For more information about IOCP, refer to the processors IOCP manual and to  
the IOCP Users Guide and ESCON Channel-to-Channel Reference, GC38-0401.  
14 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
3.4 ICKDSF  
Once the 9393 is installed and the functional devices are defined on the operator  
panel (see Appendix A, “RVA Functional Device Configuration” on page 41) the  
only initialization needed for the RVA functional devices is a minimal init,  
ICKDSF INIT, with the additional parameters needed to define the VOLID and the  
volume table of contents (VTOC) size and location. The CHECK parameter is not  
supported, because surface checking is not needed on an RVA. Other ICKDSF  
functions for surface checking, such as INSTALL or REVALIDATE, also are not  
supported for the RVA.  
The RVA internally uses FBA disk drives with internal data error recovery, so  
surface checking in this way is inappropriate. If a media surface check is  
needed, the IBM service representative can do this on the maintenance panel.  
ICKDSF Release 16 with applicable PTFs is needed to support the RVA. To run  
the VSE version of ICKDSF in batch mode, submit a job with an EXEC ICKDSF job  
control statement.  
3.4.1 Volume Minimal Init  
In the example in Figure 4 a volume is initialized at minimal level under VSE. A  
VSE format VTOC is written at cylinder 32, track 0 for a length of 20 tracks. The  
volume is labeled 338001.  
// JOB  
// ASSGN  
// EXEC  
jobname  
SYS002,151  
ICKDSF,SIZE=AUTO  
INIT SYSNAME(SYS002) NOVERIFY -  
VSEVTOC(X20′, X0′ , X14′) VOLID(338001)  
/*  
/&  
Figure 4. ICKDSF INIT Volume at the Minimal Level  
3.4.2 Partial Disk Minimal Init  
In the example in Figure 5, an emulated partial disk is initialized under VSE. A  
VSE format VTOC is written at cylinder 0, track 1 for a length of one track. The  
volume is labeled AA3380.  
// JOB  
// ASSGN  
// EXEC  
jobname  
SYS000,353  
ICKDSF,SIZE=AUTO  
INIT SYSNAME(SYS000) NVFY VSEVTOC(0,1,1) -  
VOLID(AA3380) MIMIC(EMU(20))  
/*  
/&  
Figure 5. ICKDSF INIT Emulated Partial Disk  
For more information about and examples of running ICKDSF under VSE, refer to  
the ICKDSF R16 Users Guide, GC35-0033.  
Chapter 3. VSE/ESA Support for the RVA 15  
 
16 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Chapter 4. IXFP/SnapShot for VSE/ESA  
IXFP/SnapShot for VSE/ESA is a combination of software and RVA microcode  
functions. It has three main functions, namely, SnapShot, DDSR, and Report.  
SnapShot is the data duplication utility that exploits the RVAs virtual disk  
architecture to achieve instantaneous copy without actually using resources.  
DDSR releases space occupied by a volume, a cylinder range, and a specified  
data set. The report functions provide information about the space utilization  
and subsystem utilization summary of the RVA.  
A new attention routine ($IJBIXFP) has been provided in VSE. You invoke  
IXFP/SnapShot for VSE/ESA functions through the attention routine in three basic  
ways:  
1. From a console  
You enter the IXFP/SnapShot for VSE/ESA functions on the command line of  
the VSE operator console or through the interactive computing and control  
facility (ICCF) console operator interface.  
Note: Make sure that you are authorized to enter operator commands when  
using the ICCF console operator interface.  
Figure 6 illustrates invoking IXFP REPORT functions directly from the  
operator console.  
SYSTEM : VSE/ESA  
VSE/ESA 2.3  
USER :  
TIME :  
AR 0015 1I40I READY  
-------------------------------------------------------------------------  
==> IXFP REPORT<enter>  
Figure 6. Sample Operator Console Screen to Invoke IXFP REPORT Functions  
Copyright IBM Corp. 1999  
17  
 
2. From a batch job  
You can code the function you want to invoke in the PARM field of the  
VSE-provided DTRIATTN module and submit the batch job for execution.  
Figure 7 illustrates the report function (IXFP REPORT) being invoked by a  
batch job using DTRIATTN.  
// JOB  
// log  
// EXEC  
/&  
jobname  
DTRIATTN,PARM=IXFP REPORT′  
Figure 7. Sample Batch Job to Invoke IXFP Report Function  
3. From a REXX CLIST  
You can code the IXFP function in the SENDCMD of REXX. Use of a REXX  
CLIST allows use of logic for automated procedures. Figure 8 shows the  
statements required to catalog the REXX procedure. Figure 9 on page 19  
illustrates invoking the report function (IXFP REPORT) from a REXX CLIST in  
a batch job. The second SENDCMD in the job is a dummy. It is coded to  
illustrate the possibility of coding other IXFP/SnapShot for VSE/ESA or VSE  
commands, thus providing flexibility for creating automated procedures.  
* $$ JOB JNM=IXFPREXC,CLASS=0,DISP=D  
// JOB IXFPREXC  
// EXEC LIBR  
ACC S=PRD2.CONFIG  
CAT IXFPREXX.PROC R=Y  
/* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- */  
/*  
REXX/VSE procedure to issue console commands  
*/  
/* -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- */  
trace off  
arg parm_string  
parse var parm_string command1 #command2  
rc = SENDCMD( command1 )  
if rc = 0  
then do  
call sleep 5  
rc = SENDCMD( command2 )  
end  
/* Submit first command  
*/  
/* Wait before submitting next command */  
/* Submit second command */  
exit rc  
/+  
/*  
/&  
* $$ EOJ  
Figure 8. Cataloging a REXX CLIST Procedure to Invoke an IXFP Function  
18 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
* $$ JOB JNM=IXFPREXX,CLASS=0,DISP=D  
// JOB IXFPREXX  
// LIBDEF *,SEARCH=(PRD2.CONFIG,PRD1.BASE)  
// EXEC REXX=IXFPREXX,PARM=IXFP REPORT#<your-console-cmd-2>′  
/&  
* $$ EOJ  
Figure 9. Using a REXX CLIST As a Batch Job Step to Invoke an IXFP Function  
Note: More information about the REXX/VSE console automation capability  
can be found in Chapter 14 of the REXX/VSE V6 R1.2 Reference Manual,  
SC33-6642-01.  
Chapter 4. IXFP/SnapShot for VSE/ESA 19  
 
Figure 10 displays the RVA subsystem status on the operator console.  
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
369.2 2468.7 N/A  
0.8 2837.1 N/A  
13.01 86.99 213.6  
0.03 99.97 0.0  
1.72  
9.65  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
370.129 MB  
213.688 MB  
5305.903 MB  
6.52  
3.76  
1.73  
93.48  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57752.311 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 51.01 51.01  
0.00 47.55 47.55 0.00 1.44  
1.44  
AR 0015 1I40I READY  
Figure 10. Sample Console Output of the IXFP REPORT Function  
Figure 11 shows the general syntax of the IXFP command.  
┌─,───────────────────────────────────────────────────────────────┐  
ꢀꢀ──IXFP──┬─SNAP,─┬──source─┬───────────────────┬─:target─┬────────┬──┬─────────────┬─┴─┬──┬───────────┬──┬─────────ꢀꢂ  
└─(scyl─┬─-scyl─┬─)─┘  
└─.ncyl─┘  
└─(tcyl)─┘ └─,VOL1=volid─┘ │ └─,NOPROMPT─┘ │  
└─source(DSN=data-set-name′ ) : target─┬────────┬───────────────────────┘  
└─(tcyl)─┘  
├─DDSR─┬────────────────────────────────┬──┬───────────┬────────────────────────────────────────┤  
│ ┌────────────────────────────┐ │ └─,NOPROMPT─┘  
├──,unit─┬───────────────────┬─┴─┤  
└─(dcyl─┬─-dcyl─┬─)─┘  
└─.ncyl─┘  
└─,unit(DSN=data-set-name′ ) ─────┘  
┌───────┐  
└─REPORT──┬─────┬┴──────────────────────────────────────────────────────────────────────────────┘  
└─,id─┘  
Figure 11. General Syntax of IXFP Command  
See Appendix B, “IXFP Command Examples” on page 43 for an explanation of  
the IXFP specifications.  
20 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
4.1 IXFP SNAP  
SNAP identifies this command as a SNAP function. Figure 12 shows the syntax  
of the IXFP SNAP command.  
┌─,───────────────────────────────────────────────────────────────┐  
ꢀꢀ──IXFP────SNAP,─┬──source─┬───────────────────┬─:target─┬────────┬──┬─────────────┬─┴─┬──┬───────────┬────────────ꢀꢂ  
└─(scyl─┬─-scyl─┬─)─┘  
└─.ncyl─┘  
└─(tcyl)─┘ └─,VOL1=volid─┘ │ └─,NOPROMPT─┘  
└─source(DSN=data-set-name′ ) : target─┬────────┬───────────────────────┘  
└─(tcyl)─┘  
Figure 12. Syntax of IXFP SNAP Command  
Note: SnapShot commands can be set up to be invoked by end users as well as  
by database administrators and system programmers.  
There are three ways to do a SnapShot. You can take a copy of:  
A full volume  
A range of cylinders  
A non-VSAM file  
4.1.1 A Full Volume  
You copy a full volume by identifying the device address (cuu) or VOLID label of  
the source and target in the IXFP SNAP command. Intermixing of the device  
address and VOLID label to specify the source and target in the IXFP command  
is allowed. Use the VOL1= parameter to specify the volume label that the  
target will assume after the copy has completed. If the VOL1= parameter is  
omitted, the source and target volumes will have the same VOLID label when the  
copy is completed.  
To illustrate, we use two volumes: PATEV1 and PATEV2. The device addresses  
of these volumes are 80E and 80F, respectively. To copy the first volume onto  
the second volume, issue any of the following commands:  
IXFP SNAP,80E:80F,NOPROMPT  
IXFP SNAP,PATEV1:PATEV2,NOPROMPT  
IXFP SNAP,PATEV1:80F,NOPROMPT  
In this case the source 80E and target 80F will have the same VOLID label  
(PATEV1) after the snap completes. A VOL1= parameter can be used to give  
the target a specific VOLID label after the snap of the source volume. Continuing  
with the example, to give the target volume a VOLID label of PATEV3, we include  
a VOL1= parameter indicating VOLID label PATEV3. Use one of the following  
commands;  
IXFP SNAP,80E:80F,VOL1=PATEV3,NOPROMPT  
IXFP SNAP,PATEV1:80F,VOL1=PATEV3,NOPROMPT  
The NOPROMPT parameter is included to prevent decision-type messages from  
being issued. Otherwise, decision-type messages are issued for the operator to  
verify and confirm (see Figure 13 on page 22).  
Chapter 4. IXFP/SnapShot for VSE/ESA 21  
 
AR 0015 1I40I READY  
ixfp snap,80e:80f,vol1=patev3  
AR+0015 IXFP23D SNAP FROM CUU=80E CYL=′0000′ TO CUU=80F CYL=′0000′ NCYL=0D0B  
- REPLY YESTO PROCEED  
15 yes  
AR 0015 IXFP22I SNAP TO CUU= 80F STARTED AT 18:46:51 11/16/1998  
AR 0015 IXFP20I SNAP FUNCTION COMPLETED AT 18:46:51 11/16/1998  
AR 0015 1I40I READY  
Figure 13. Decision-Type Message Issued to Confirm SNAP  
VSE/VSAM  
VSE/VSAM support is not currently included in IXFP/SnapShot for VSE/ESA.  
However, you can still take advantage of IXFP/SnapShot for VSE/ESA with  
VSE/VSAM data sets. With volume snap, VSAM data sets can be indirectly  
copied when the VSAM catalog, space, and cluster are in the same volume.  
In VSE, you can reference the two USER CATALOGs individually through the  
use of the ASSGN JCL statement; however, the VSAM share option  
restrictions still apply. The ideal scenario is to assign the target volume into  
another LPAR so as not to encounter the restrictions and further processing  
or copy to tape using IDCAMS REPRO. If the purpose of the volume snap is  
for backup using FASTCOPY or DDR (VM), the VSAM share option  
restrictions will not be encountered.  
See Appendix C, “VSE/VSAM Considerations” on page 59.  
Notes:  
If the source is identified by its VOLID, it must be either the only volume with  
that VOLID or the only VOLUME with that VOLID that is up (DVCUP).  
Otherwise an error message will be issued.  
The target device must be down (DVCDN) before you initiate the volume  
snap.  
If the target device is identified by its VOLID, it must be either the only  
volume with that VOLID or the only volume with that VOLID which is down  
(DVCDN). Otherwise an error message will be issued.  
Only when doing full volume snaps can you use the VOL1 parameter.  
Volume copying is done unconditionally within the specified or assumed  
boundaries. VSE does not perform any VTOC checking on the specified  
target device and thus does not provide any warning messages regarding  
overlapping extents or secured or unexpired files.  
When you duplicate a volume, both the source and the target must be within  
the same RVA. (If you are using test partitions, the source and the target  
must also be in the same partition.)  
22 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
4.1.2 A Range of Cylinders  
You copy a range of cylinders by identifying the device address or VOL1 label of  
the source and target in the IXFP SNAP command. In addition, the decimal start  
cylinder (scyl) and end cylinder (-scyl) or number of cylinders (,ncyl) are  
specified in parentheses and appended to the source specification. Optionally,  
the target start cylinder (tcyl) can be included to specify where copying is to start  
on the target device.  
To illustrate, we use two volumes: PATEV1 and PATEV2. The device addresses  
of these volumes are 80E and 80F, respectively. To copy cylinders 0 through 999  
in the first volume onto the second volume, issue one of the following  
commands:  
IXFP SNAP,80E(0000-0999):80F,NOPROMPT  
IXFP SNAP,80E(0000,1000):80F,NOPROMPT  
IXFP SNAP,PATEV1(0000-0999):PATEV2,NOPROMPT  
IXFP SNAP,PATEV1(0000,1000):PATEV2,NOPROMPT  
You specify the target start-cylinder (tcyl) to relocate the range of cylinders on  
the target volume. Indicate target start-cylinder 1000 to relocate the range of  
cylinders on the target volume. You can issue one of the following modified  
commands:  
IXFP SNAP,80E(0000-0999):80F(1000),NOPROMPT  
IXFP SNAP,80E(0000,1000):80F(1000),NOPROMPT  
IXFP SNAP,PATEV1(0000-0999):PATEV2(1000),NOPROMPT  
IXFP SNAP,PATEV1(0000,1000):PATEV2(1000),NOPROMPT  
You may or may not include the NOPROMPT parameter to prevent or allow  
decision-type messages (see Figure 13 on page 22).  
Notes:  
If the source is identified by its VOLID, it must be either the only volume with  
that VOLID or the only VOLUME with that VOLID which is up (DVCUP).  
Otherwise an error message will be issued.  
The target device must be down (DVCDN) before you initiate the volume  
snap, except when the source and the target device are the same device.  
If the target device is identified by its VOLID, it must be either the only  
volume with that VOLID or the only volume with that VOLID which is down  
(DVCDN). Otherwise an error message will be issued.  
The highest (end) cylinder number must not exceed 32767 or the maximum  
number of cylinders of the devices. The start cylinder number must not be  
greater than the end cylinder number.  
You cannot use the VOL1 parameter when copying cylinder ranges.  
Cylinder range copying is done unconditionally within the specified or  
assumed boundaries. VSE does not perform any VTOC checking on the  
specified target device and thus does not provide any warning messages  
regarding overlapping extents or secured or unexpired files.  
Chapter 4. IXFP/SnapShot for VSE/ESA 23  
 
The source and the target device must be of the same type and must be  
within the same RVA subsystem. (If you are using test partitions, the source  
and the target must also be in the same partition.)  
4.1.3 A Non-VSAM File  
You copy a file by indicating the data set name on the source device, using the  
DSN= (data set name) parameter, in addition to identifying the source and  
target device address or VOLID labels. The file specified must be non-VSAM.  
Optionally, the target start cylinder (tcyl) can be included to specify where  
copying is to start on the target device if relocation is required.  
To illustrate, we use two volumes: PATEV1 and PATEV2. The device addresses  
of these volumes are 80E and 80F, respectively. To copy file test.data.1in  
volume 80E onto volume 80F, issue one of the following commands:  
IXFP SNAP,80E(DSN=test.data.1): 80F,NOPROMPT  
IXFP SNAP,PATEV1(DSN=test.data.1): 80F,NOPROMPT  
If you want to copy file test.data.1to cylinder 1000 on volume 80F, you must  
specify the target start cylinder (tcyl). Issue one of the following modified  
commands:  
IXFP SNAP,80E(DSN=test.data.1): 80F(1000),NOPROMPT  
IXFP SNAP,80E(DSN=test.data.1′ ) : PATEV2(1000),NOPROMPT  
Notes:  
If source is identified by its VOLID, it must be either the only volume with  
that VOLID or the only VOLUME with that VOLID that is up (DVCUP).  
Otherwise an error message will be issued.  
The target device must be down (DVCDN) before you initiate the volume  
snap, except when the source and the target are the same device.  
If the target device is identified by its VOLID, it must be either the only  
volume with that VOLID or the only volume with that VOLID that is down  
(DVCDN). Otherwise an error message will be issued.  
The highest (end) cylinder number must not exceed 32767 or the maximum  
number of cylinders of the devices. The start cylinder number must not be  
greater than the end cylinder number.  
You cannot use the VOL1 parameter when copying a non-VSAM file.  
When you snap files, VSE performs VTOC checking on the specified target  
device and provides warning messages regarding overlapping extents or  
secured or unexpired files.  
The source and the target device must be of the same type and must be  
within the same RVA subsystem. (If you are using test partitions, the source  
and the target must also be in the same partition.)  
See B.1, “SNAP Command” on page 43 for additional illustrations.  
24 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
4.2 IXFP DDSR  
DDSR identifies this command as a DDSR function. DDSR causes the release of  
the physical storage space associated with:  
Expired files  
A total volume  
A range of cylinders  
A specified file  
This function ensures that all space releases done on the VSE system (normally  
through deletes) result in space releases in the RVA subsystem. Figure 14  
shows the syntax of the IXFP DDSR command.  
ꢀꢀ──IXFP────DDSR─┬────────────────────────────────┬──┬───────────┬──────────────────────────────────────────────────ꢀꢂ  
│ ┌────────────────────────────┐ │ └─,NOPROMPT─┘  
├──,unit─┬───────────────────┬─┴─┤  
└─(dcyl─┬─-dcyl─┬─)─┘  
└─.ncyl─┘  
└─,unit(DSN=data-set-name′ ) ─────┘  
Figure 14. Syntax of IXFP DDSR Command  
4.2.1 Expired Files  
DDSR, when specified without any additional parameters, deletes the VTOC  
entries and all physical space for all expired nonsecured files residing on VSE  
managed RVA devices. These extents are freed up and become part of free  
space.  
To illustrate, we use two volumes: PATEV1 and PATEV3. The device addresses  
of these volumes are 80E and 80F, respectively. To delete all VSE-recognized  
expired files, issue the following command:  
IXFP DDSR,NOPROMPT  
The NOPROMPT parameter is included to prevent decision-type messages from  
being issued. Otherwise, decision-type messages are issued for the operator to  
verify and confirm (see Figure 15).  
AR 0015 1I40I READY  
IXFP DDSR  
AR+0015 IXFP26D TEST.DATA.1HAS EXPIRED ON CUU=80E - REPLY YESFOR DELETION  
15 YES  
AR+0015 IXFP26D TEST.DATA.1HAS EXPIRED ON CUU=80F - REPLY YESFOR DELETION  
15 YES  
AR 0015 1I40I READY  
Figure 15. Decision-Type Message Issued to Confirm DDSR Expired Files  
Chapter 4. IXFP/SnapShot for VSE/ESA 25  
 
Notes:  
When you do DDSR for expired files, VSE performs checking on the online  
(up) units.  
DDSR checks only those RVA devices managed by the VSE system.  
DDSR considers only the files created by VSE.  
4.2.2 A Total Volume  
It is possible to delete and release space for an entire volume when you include  
the device address or VOLID label with no other operands.  
To illustrate, we use volume PATEV3 with device address 80F. To delete all data  
including the VTOC and VOLID label of PATEV3, issue the following command:  
IXFP DDSR,PATEV3  
The NOPROMPT parameter is included to prevent decision-type messages from  
being issued. Otherwise, decision-type messages are issued for the operator to  
verify and confirm (see Figure 16).  
AR 0015 1I40I READY  
IXFP DDSR,PATEV3  
AR+0015 IXFP29D DDSR FOR CUU=80F (WHOLE VOLUME) - REPLY YESFOR DELETION  
15 YES  
AR 0015 1I40I READY  
Figure 16. Decision-Type Message Issued to Confirm DDSR Volume  
Notes:  
The device should belong to the RVA subsystem managed by the VSE  
system.  
The device should be in the offline (DVCDN) condition.  
The device should be reinitialized before you use it as a regular volume  
again. However, if you are going to use it as a target for a volume snap, you  
can leave it as is.  
4.2.3 A Range of Cylinders  
This command is similar to the DDSR volume command, except that additional  
specifications are added to signify the decimal start cylinder and end cylinder  
(dcyl-dcyl) or the decimal start cylinder and the number of cylinders (dcyl,ncyl) to  
delete.  
To illustrate, we use volume PATEV3 with device address 80F. To delete all data  
from cylinders 0 through cylinder 999, issue the following command:  
IXFP DDSR,PATEV3(0000-0999),NOPROMPT  
26 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
The NOPROMPT parameter is included to prevent decision-type messages from  
being issued. Otherwise, decision-type messages are issued for the operator to  
verify and confirm (similar to Figure 16).  
Notes:  
The device should belong to the RVA subsystem managed by the VSE  
system.  
The device should be in the offline (DVCDN) condition.  
The highest (end) cylinder number must not exceed 32767 or the maximum  
number of cylinders of the devices. The start cylinder number must not be  
greater than the end cylinder number.  
4.2.4 A Specified File  
This command is similar to doing DDSR for a specific range of cylinders. The  
difference is that a DSN= specification is coded in place of the decimal start  
cylinder and decimal end cylinder (dcyl-dcyl).  
To illustrate, we use volume PATEV3 with device address 80F. To delete file  
test.data.3on volume PATEV3, issue the following command:  
IXFP DDSR,PATEV3(DSN=test.data.3′ ) , NOPROMPT  
The NOPROMPT parameter is included to prevent decision-type messages from  
being issued. Otherwise, decision-type messages are issued for the operator to  
verify and confirm (similar to Figure 16 on page 26).  
Notes:  
The device should belong to the RVA subsystem managed by the VSE  
system.  
The device should be in the online (DVCUP) condition. Otherwise the  
command is rejected, and an error message is displayed.  
The file must be non-VSAM.  
The file will be deleted unconditionally and the space returned to the RVA  
freespace.  
When you process multivolume files, repeat DDSR for all volumes containing  
the file extents.  
See B.2, “DDSR Command” on page 49 for additional illustrations.  
4.3 IXFP REPORT  
The IXFP REPORT command provides information about the space utilization of a  
single RVA device or a range of RVA devices. It also provides information about  
the space utilization of all devices (that were added during IPL) of an RVA  
subsystem as well as important subsystem utilization summary information.  
Figure 17 on page 28 shows the syntax of the IXFP REPORT command.  
Chapter 4. IXFP/SnapShot for VSE/ESA 27  
 
┌───────┐  
ꢀꢀ──IXFP────REPORT──┬─────┬┴────────────────────────────────────────────────────────────────────────────────────────ꢀꢂ  
└─,id─┘  
Figure 17. Syntax of IXFP REPORT Command  
When the command is issued without the id parameter, all information about  
every RVA subsystem, including all devices known to the VSE system, is  
displayed.  
If you need information about a specific device, a specific range of devices, or a  
specific RVA subsystem, include the id parameter to limit the scope of the report  
output.  
To illustrate, we use two volumes: PATEV1 and PATEV2. The device addresses  
of these volumes are 80E and 80F, respectively. To display space utilization for  
one of the devices, issue one of the following commands:  
IXFP REPORT,80E  
IXFP REPORT,80F  
It is also possible to display the space utilization of the two devices in one  
command by including the addresses of the two devices. Issue the following  
command:  
IXFP REPORT,80E,80F  
To get all space information for the entire VSE system, issue the command  
without any additional parameter:  
IXFP REPORT  
Notes:  
The device must belong to the RVA subsystem managed by the VSE system.  
If used under VM, REPORT only works for full-pack minidisks or dedicated  
devices.  
NOPROMPT is not a valid parameter for IXFP REPORT.  
Issuing IXFP REPORT or IXFP REPORT,80 yields the same result because we  
are only using one RVA subsystem and there is only one device address  
range (80).  
Figure 18 on page 29 shows a sample IXFP REPORT output.  
28 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
369.2 2468.7 N/A  
0.8 2837.1 N/A  
13.01 86.99 213.6  
0.03 99.97 0.0  
1.72  
9.65  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
370.129 MB  
213.688 MB  
5305.903 MB  
6.52  
3.76  
1.73  
93.48  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57752.311 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 51.01 51.01  
0.00 47.55 47.55 0.00 1.44  
1.44  
AR 0015 1I40I READY  
Figure 18. Sample Output of IXFP REPORT Command  
See B.3, “Report Command” on page 52 for further illustrations.  
In the sections that follow we define the field names and column headings of the  
reports that IXFP REPORT provides.  
4.3.1 Device Detail Report  
cuu  
This is the device ID of the device to which the data applies.  
<---FUNC. CAPACITY (MB)---> This heading covers the fields that provide  
information about the functional capacity in megabytes for a certain  
device. Functional capacity in this sense is the capacity that would  
exist on traditional count key data (CKD) or extended count key data  
(ECKD) devices.  
DEF  
This field contains the functional capacity in megabytes  
defined to the subsystem for this specific device.  
This field is the functional space allocated by the VTOC.  
This data is not currently available for VSE/ESA.  
ALLOC  
STORED This field contains the functional capacity in megabytes  
stored (occupying disk array storage) for the device or  
subsystem.  
UNUSED This field contains the part of the functional capacity  
defined for the device or subsystem that is not mapped  
and thus unused (that is, not occupying disk array  
storage).  
<--- CAPACITY (%)---> This heading covers the fields that provide information  
about the percentage of the defined functional capacity assigned to  
the individual groups.  
ALLOC  
This field is the percentage of functional space allocated  
by the VTOC. This data is not currently available for  
VSE/ESA.  
Chapter 4. IXFP/SnapShot for VSE/ESA 29  
 
STORED This field contains the percentage of the defined functional  
capacity that contains stored data (occupying disk array  
storage) for the device or subsystem.  
UNUSED This field contains the percentage of the defined functional  
capacity for the device or subsystem that does not yet  
contain data and is thus unused (that is, not occupying  
disk array storage).  
PHYS. USED(MB) This heading covers the field containing the real capacity in  
megabytes, that occupies disk array storage, as opposed to the  
functional capacity. The difference between the stored and the  
physical used capacity is the savings due to compression and  
compaction performed by the RVA subsystem for this device.  
COMP. RATIO This heading covers the field containing the real compaction ratio,  
which is the quotient of functional capacity stored/physical used  
capacity.  
30 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
4.3.2 Device Summary Report  
CAPACITY This column covers the capacity groups that are being differentiated.  
<-----TOTAL-----> This column covers the total capacity in megabytes that has  
been allocated to the appropriate group in that line. The capacity is  
the sum of all the devices that were selected for the report.  
<------TOTALS %------> This column shows the percentage of capacity that the  
group in the appropriate line is occupying, always compared to the  
100% defined functional capacity in the first row. The percentage is  
based on all the devices that were selected for the report.  
COMP. RATIO This column shows the real compaction ratio, which is the  
quotient of the total functional capacity stored/total physical used  
capacity and is a measure of the overall compaction for the devices  
selected for the report.  
4.3.3 Subsystem Summary Report  
SYSTEM This column identifies the system to which the capacity outlined in the  
appropriate line applies. If a test system has not been configured,  
only the PROD system information is provided.  
DEFINED-CAPACITY This column contains the functional capacity in megabytes  
for the whole subsystem as it has been configured.  
DISK-ARRAY-CAP This column contains the total disk array capacity in  
megabytes for the whole subsystem that has been installed.  
FREE-DISK-ARRAY-CAP This column contains the current free disk array  
capacity in megabytes that is still available for allocation by the RVA  
subsystem.  
NET-CAPACITY-LOAD(%) This column contains the percentage of the disk array  
capacity that is currently being occupied by the TEST, PROD, or both  
(OVERALL) systems. This is probably the most important value and  
has been placed at the beginning of the very last report line to make  
it easy to find.  
COLL.-FREE-SPACE(%) This column contains the percentage of the array  
cylinders in the subsystem that are free array cylinders (that is, the  
total space that can be written to).  
UNCOLL-FREESPACE(%) This column contains the percentage of the array  
capacity originally occupied when a functional track has been  
rewritten to a new location in the disk array.  
Chapter 4. IXFP/SnapShot for VSE/ESA 31  
 
32 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Chapter 5. Peer-to-Peer Remote Copy  
In this chapter we describe the VSE/ESA support for the RVA and the PPRC.  
As part of the continuing effort to meet customer requirements for 24-hour 7-day  
availability, the RVA Model T82 provides remote copy for disaster and critical  
volume protection. PPRC is supported by OS/390, VSE/ESA, and VM/ESA. PPRC  
complements the existing availability functions of the RVA, such as the dual  
power systems, nonvolatile storage (NVS), and nondisruptive installation and  
repair.  
PPRC standardizes and streamlines todays disaster recovery data backup  
capabilities by providing data-type independent remote copy. The  
implementation provides a choice based on business requirements such as  
performance needs, data synchrony criteria, system resource considerations,  
operational control requirements, and recovery distance requirements.  
PPRC provides an RVA synchronous data copying capability for protection  
against loss of access to data in the event of an outage at the primary site.  
Updates are sent from the primary RVA directly to the recovery RVA in a cache  
to cache communication through dedicated ESCON links between the two RVAs.  
The RVA can be located up to 43 km (26.7 mi) from the host. The primary and  
secondary volumes must be of the same track geometry.  
Figure 19 shows two host systems with an RVA attached to each. The two RVAs  
are attached on at least one ESCON path. ESCON Directors can be used to  
extend the distance between the two hosts up to 43 km. The second host is  
optional if PPRC is being used to migrate data from one RVA to a second within  
the same data center.  
Figure 19. Peer-to-Peer Remote Copy  
Both RVAs can treat writes as DASD fast write (DFW) operations. The primary  
RVA write is handled normally, and it is processed as a cache hit whenever  
possible; the write to the secondary subsystem is always treated as a write hit.  
This capability, and the inherent performance capabilities of the RVA, help to  
mitigate the unavoidable performance impacts of writing the data to both RVAs  
before signaling the operation as complete to the primary host application.  
Copyright IBM Corp. 1999  
33  
 
Figure 20 on page 34 shows the data flow between the host and the two RVAs.  
This would be the sequence of a write operation to the primary RVA:  
1. The host application issues a write request to a file, and the VSE/ESA  
supervisor converts the request to a start subchannel request to the RVA.  
The RVA receives the request, compresses the data as it comes across the  
ESCON host adapter, and stores the data in both its cache and NVS.  
2. Channel end is returned to the host, indicating that the channel and device  
are available for additional I/O operations.  
3. At the same time, the updated array data, in its compressed and compacted  
form, is transferred across the ESCON channel to the secondary RVA.  
Because the primary RVA looks like a host to the secondary, the secondary  
RVA stores the data in its cache and NVS and returns channel end to the  
primary.  
4. When the primary RVA receives the channel end from the secondary, it  
presents device end for the write request.  
Figure 20. PPRC Data Flow  
5.1 PPRC and VSE/ESA Software Requirements  
As always, when preparing for new functions, be sure to check with the IBM  
Software Support Center before implementing PPRC. Order, install, and test  
PTFs, using the customers normal change management processes. Check  
Information APAR II08303 for the latest list of APARs and PTFs required to use  
the PPRC functions.  
VSE/ESA Version 2 Release 3.1 is the minimum release level for PPRC support.  
APAR fixes DY44407 and DY44616 are needed to support PPRC.  
ICKDSF Release 16 refreshedby APAR PQ20390 contains the support for PPRC  
on the RVA.  
34 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
5.2 PPRC Hardware Requirements  
The hardware requirements for both the primary and secondary RVAs to support  
PPRC are:  
RVA Model T82  
Feature code 7001  
PPRC-enabling LIC  
(LIC level T04.05.xx is the minimum level)  
Remote Service capability  
Note: We recommend that 4 GB of cache be installed on the RVAs to maximize  
performance. We also recommend four ESCON links between the two  
subsystems.  
5.3 Invoking peer-to-peer remote copy  
You initiate PPRC by using the ICKDSF PPRCOPY command with the options  
shown in Table 1.  
Table 1. ICKDSF PPRCOPY Command Options  
PPRCOPY  
Command  
Option  
Function  
Primary  
Site  
Secondary  
Site  
ESTPATH  
Establishes ESCON paths between the RVA of an application  
(primary) site and a recovery (secondary) site.  
Yes  
Yes  
No  
No  
DELPATH  
Deletes all established ESCON paths between primary and  
secondary site RVA.  
ESTPAIR  
DELPAIR  
Establishes a remote copy device pair.  
Yes  
Yes  
No  
No  
Removes primary and secondary volumes from PPRC and  
returns the devices to a simplex state.  
QUERY  
Queries the status of a PPRC volume pair and the paths  
associated with the RVA for the addressed device.  
Yes  
No  
Yes  
Yes  
Yes  
RECOVER  
SUSPEND  
Allows the recovery site system to regain control of a DASD  
volume on its RVA.  
Suspends PPRC operation between a primary and secondary  
pair.  
Yes  
Note: The ICKDSF PPRCOPY commands for the primary device are issued at the primary (application) site.  
Commands for the secondary device are issued at the secondary (recovery) site.  
Note: The PPRCOPY QUERY VOLUME command should be used to display the  
subsystem identifier (SSID), serial number, and channel connection (logical)  
address (CCA) of a device. (The CONTROL CONFIGURE (DISPLAY) command  
does not work with the RVA. It works only with the 3990/9390 storage controls.)  
For an example of using the PPRCOPY command, see 5.5, “Examples of  
PPRCOPY Commands” on page 36. For a more detailed description of the  
PPRCOPY command, see Device Support Facilities Users Guide and Reference,  
Release 16 Refresh with Peer-to-Peer Remote Copy, GC35-0033.  
Chapter 5. Peer-to-Peer Remote Copy 35  
 
5.4 SnapShot Considerations  
The RVA provides the unique ability to combine SnapShot functions with PPRC  
functions. There are some considerations regarding the interaction of SnapShot  
with volumes that are part of a PPRC pair.  
You cannot use SnapShot to copy data onto any volume that is part of a PPRC  
pair. SnapShot requires that addresses be available on the same RVA  
subsystem where the source of the copy resides. If SnapShot is going to be  
used on an RVA subsystem that also has PPRC pairs, there must be some  
logical volumes on that subsystem that are not part of a PPRC pair. Therefore,  
all 256 logical volumes in an RVA subsystem cannot be part of a PPRC pair and  
also use SnapShot on that same RVA.  
5.4.1 Primary Devices of a PPRC Pair  
You cannot use SnapShot to copy to a target that is the primary of a PPRC pair,  
regardless of whether the primary is in an active or suspended state. The  
primary volume can be the source for a SnapShot copy. Making a copy does not  
require modifying the PPRC state of the primary volume.  
When dynamically allocating space for a SnapShot target, SnapShot uses all  
volumes available to it on a space available basis. It does not check PPRC  
status. SnapShot should not be provided a volume list that includes volumes  
that are part of a PPRC pair. The SnapShot copy will fail if any part of a data set  
is allocated to a volume that is part of a PPRC pair.  
5.4.2 Secondary Devices of a PPRC Pair  
If SnapShot will be used on a secondary RVA subsystem, there must be space  
available on the subsystem in addition to that used by PPRC pairs. You cannot  
have all 256 logical volumes as part of PPRC pairs.  
Remember that you cannot issue reads or writes to a secondary volume of a  
PPRC pair. However, by using a procedure like the following, you can make  
SnapShot copies of data from the secondary device—and return it to active  
status very quickly:  
1. SUSPEND the pair.  
2. RECOVER the secondary—returning it to simplex status.  
3. Make the SnapShot copy.  
4. ESTPAIR RESYNC the secondary to copy only the changes from the primary.  
5.5 Examples of PPRCOPY Commands  
In this section we demonstrate the use of the ICKDSF PPRCOPY commands to  
initiate a PPRC pair.  
In the examples that follow, two devices are used. At the primary site, the RVAs  
SSID is x′0057′, the serial number of the storage control is 7390007, and the CCA  
is xD48′. (The serial number actually has two parts—the first two digits indicate  
the plant of manufacture, and the last five digits are the machine serial number.)  
At the secondary site, the RVAs SSID is x′053F′, the serial number of the  
storage control is 7390014, and the CCA is xD8C′. (See 5.6, “Physical  
Connections to the RVA” on page 38 for the relationship between the logical  
control unit number and the CCA.)  
36 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
In the examples that follow, the short form of some of the parameters is used.  
The long form of these parameters is:  
NoVeriFY  
PRIMary  
SECondary  
UNITaddress  
5.5.1 Setting Up PPRC Paths and Pairs  
The sequence of tasks for setting up PPRC at the primary site is:  
1. Obtain the SSID, serial number, and CCA for both the primary and secondary  
sitesstorage controls. The PPRCOPY QUERY command can be used to  
obtain this information. Issue the following commands at the respective host  
processors:  
PPRCOPY QUERY UNIT(D48)  
PPRCOPY QUERY UNIT(D8C)  
2. Obtain the physical RVA system adapter IDs (SAIDs). There are 8 for an  
8-channel machine and 16 for a 16-channel machine.  
3. Use the PPRCOPY QUERY command to check the status of the primary and  
secondary devices to determine whether they are in simplex mode and the  
paths are already set. Issue the following commands at the respective host  
processors:  
PPRCOPY QUERY UNIT(D48) PATHS  
PPRCOPY QUERY UNIT(D8C) PATHS  
4. Establish the path, using ESTPATH:  
PPRCOPY ESTPATH UNIT(D48)  
PRIM(X′0057′,7390007) SEC(X′053F′,7390014)  
LINK(X′004D600′ , X′00510003′)  
Warning: The ESTPATH command acts as a replace function. The paths  
specified in it establish the link between the storage controls at the primary  
and secondary sites. They replace any PPRC paths previously established  
between the pair of storage controls.  
Note: This example uses two links. Although a single link is possible, it is  
advisable to define more than one LINK between the primary and secondary  
for availability reasons.  
5. Establish a pair, using ESTPAIR:  
PPRCOPY ESTPAIR UNIT(D48) MODE(COPY)  
PRIM(X′0057′,7390007,X07′) SEC(X′053F′,7390014,X0F′ )  
Note: The PACE parameter of the ESTPAIR command is ignored.  
6. Monitor the progress, using QUERY:  
PPRCOPY QUERY UNIT(D48)  
5.5.2 Recovering from a Primary Site Failure  
Assume that a primary site failure occurred after step 6 above, PPRC has been  
activated, and the pair has been established. This example shows the recovery  
at the secondary site:  
1. Suspend the secondary site device, using SUSPEND:  
Chapter 5. Peer-to-Peer Remote Copy 37  
 
PPRCOPY SUSPEND(SEC) UNIT(D48)  
PRIM(X′0057′,7390007,X07′) SEC(X′053F′,7390014,X0F′ )  
2. Check on the secondary device, using QUERY at the recovery site:  
PPRCOPY QUERY UNIT(D8C)  
3. Issue the RECOVER command at the recovery site:  
PPRCOPY RECOVER UNIT(D8C) NVFY  
PRIM(X′0057′,7390007,X07′) SEC(X′053F′,7390014,X0F′ )  
The secondary device is now available for use at the recovery site.  
5.5.3 Recovering from a Secondary Site Failure  
Assume that a secondary site failure occurred after step 6 of 5.5.1, “Setting Up  
PPRC Paths and Pairs” on page 37, PPRC has been activated, and the ESTPAIR  
was completed. This example shows the recovery at the primary site:  
1. Suspend the primary site device, using SUSPEND:  
PPRCOPY SUSPEND(PRIM) UNIT(D48)  
PRIM(X′0057′,7390007,X07′) SEC(X′053F′,7390014,X0F′ )  
2. Repair the problem with the secondary device.  
3. Reestablish the PPRC pair. Update the volume by copying only the changed  
track(s), using ESTPAIR:  
PPRCOPY ESTPAIR UNIT(D48) MODE(RESYNC)  
PRIM(X′0057′,7390007,X07′) SEC(X′053F′,7390014,X0F′ )  
5.5.4 Deleting PPRC Pairs and Paths  
Now, assume that you want to terminate the pair—if no failure occurred after  
step 6 of 5.5.1, “Setting Up PPRC Paths and Pairs” on page 37. (This example  
could be used if you were using PPRC to migrate data from the primary site to  
the secondary site.)  
1. Issue DELPAIR:  
PPRCOPY DELPAIR UNIT(D48)  
PRIM(X′0057′,7390007,X07′) SEC(X′053F′,7390014,X0F′ )  
This command must complete before the paths can be deleted.  
2. Issue DELPATH:  
PPRCOPY DELPATH UNIT(D48) PRIM(X′0057′,7390007) SEC(X′053F′,7390014)  
Note: Execute the PPRCOPY DELPATH command if there are no actively  
paired devices between the primary and secondary site RVAs. There is no  
single ICKDSF command that can identify all active PPRC devices. For each  
device attached to an RVA for which you want to suspend a path, you must  
use the PPRCOPY QUERY command.  
5.6 Physical Connections to the RVA  
Neither the logical control unit (LCU) nor the CCA is intuitively obvious.  
38 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
5.6.1 Determining the Logical Control Unit Number for RVA  
You can calculate the LCU number by using the CUADD value used in the IOCP  
configuration for each LCU. Each of the four CUADDs contains 64 devices.  
If the device numbers on the RVA have been generated as a contiguous group of  
256 addresses, the LCU can be calculated from the last two digits of the device  
number. For example, for devices with an address between A40 and A7F, the  
corresponding LCU is LCU1. Table 2 shows the relationship between the device  
numbers and LCUs.  
5.6.2 Determining the Channel Connection Address  
The CCA on an RVA is relative to the LCU and is always between 00 and 3F. If  
the device numbers have been generated as a contiguous group of 256  
addresses, the CCA can be calculated from the last two digits of the device  
number as shown in Table 2. For example, for device numbers AC0 through  
AFF, subtract xC0from the last two digits of the device number, and the  
corresponding CCAs are 00 through 3F.  
Table 2. Determining LCU and CCA Values for the RVA  
Device Number  
Logical Control  
Unit Number  
Channel Connection Address  
00 - 3F  
40 - 7F  
80 - BF  
C0 - FF  
LCU00  
LCU01  
LCU02  
LCU03  
00 - 3F  
00 - 3F (subtract x40′ from device number)  
00 - 3F (subtract x80′ from device number)  
00 - 3F (subtract xC0from device number)  
Chapter 5. Peer-to-Peer Remote Copy 39  
 
40 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Appendix A. RVA Functional Device Configuration  
The procedure presented here describes the steps to configure functional  
devices through the 9393 operator panel. Figure 21 shows the steps required to  
get to the Functional Device Configuration screen.  
Figure 21. Functional Device Configuration  
On Functional Device Configuration screen CD23 (Figure 22 on page 42) follow  
the steps to modify the devices:  
Copyright IBM Corp. 1999  
41  
 
Figure 22. Functional Device Configuration Screen CD23  
1. Move the cursor up or down to select the device you want to modify and  
press Enter to get to Modify Functional Device screen CD32 (Figure 23).  
Figure 23. Modify Functional Device Screen CD32  
2. On screen CD32 enter the name of the device, modify the device accordingly,  
and press F10 to save and go back to CD23.  
3. Repeat steps 1 and 2 for each device you want to modify, or press F3 several  
times to leave the screen.  
42 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Appendix B. IXFP Command Examples  
In this appendix we present the syntax and use of the various IXFP commands.  
B.1 SNAP Command  
In this section we present examples of the IXFP SNAP command. The command  
syntax is followed by examples of using the command.  
Remember: Before you can use the SNAP option, you must bring the target  
offline by using the VSE/ESA DVCDN command.  
B.1.1 Syntax  
Figure 24 shows the syntax of the SNAP command.  
┌─,───────────────────────────────────────────────────────────────┐  
ꢀꢀ──IXFP────SNAP,─┬──source─┬───────────────────┬─:target─┬────────┬──┬─────────────┬─┴─┬──┬───────────┬────────────ꢀꢂ  
└─(scyl─┬─-scyl─┬─)─┘  
└─.ncyl─┘  
└─(tcyl)─┘ └─,VOL1=volid─┘ │ └─,NOPROMPT─┘  
└─source(DSN=data-set-name′ ) : target─┬────────┬───────────────────────┘  
└─(tcyl)─┘  
Figure 24. Syntax of IXFP SNAP Command: Details  
SNAP  
identifies this command as a SNAP command.  
source The device ID=(cuu) or the VOL1 label of the source device  
that the user wants to be used as the source when copying  
data to a target device. If the source device is identified by its  
VOLID, it must be either the only volume with that VOLID or the  
only volume with that VOLID that is up (DVCUP). Otherwise an  
error message will be issued. The whole volume will be  
copied unless the operator has provided additional information  
that either identifies a cylinder range or a DSN on the source  
device that he or she wants to be copied.  
scyl-scyl Specifies the decimal start cylinder and end cylinder  
range where copying is to start and to end on the  
source device. Cylinder is the smallest entity that can  
be specified for any SNAP command function. The  
highest (end) cylinder number must not exceed 32767  
or the devices primary number of cylinders and the  
start cylinder number must not be higher than the end  
cylinder number.  
scyl.ncyl Specifies the decimal start cylinder where copying is  
to start on the source device and provides the number  
of cylinders (ncyl) that should be copied. Cylinder is  
the smallest entity that can be specified for any SNAP  
command function. The highest resulting cylinder  
number must not exceed 32767 or the devices number  
of primary cylinders.  
DSN= The data set name identifying the file on the source  
device that the operator wants to be copied onto the  
target device. The file must be a non-VSAM file. The  
file will be copied into the exact extent boundaries  
where it was located on the source device. Sequential  
Copyright IBM Corp. 1999  
43  
 
access method (SAM) files, however, can be relocated  
to a different, single extent disk location on the target  
device. In this case, the tcyl operand must be  
supplied, but the device must not be a VM partial pack  
minidisk. The proper label information (single  
FORMAT-1 label) will be created and added to the  
target VTOC. Processing multivolume files is the  
responsibility of the operator, such that the SNAP  
command should be repeated for all the source  
volumes containing file extents. The number of  
extents to be copied is limited by the limits existing for  
the source device. Copying will be performed only if  
the appropriate extent boundaries on the target device  
are available or have already expired. Otherwise an  
error message will be issued. Use the DDSR  
command to delete the overlaid file and release the  
space.  
target  
The device ID (cuu) or the VOL1 label of the target device to  
which the user wants the data to be copied. You must set the  
target device DOWN (DVCDN command) before initiating the  
SNAP function, unless the source and target devices are the  
same device. If the target device is identified by its VOLID, it  
must be either the only volume with that VOLID or the only  
volume with that VOLID that is DOWN (DVCDN). Otherwise an  
error message is issued. As many extents as allocated on the  
source device will be used for file copying to the target device  
(DSN=). Otherwise as many cylinders as specified for the  
source device, or the entire source volume will be copied to  
the target device. Relocation of data records will be assumed  
if the specified cylinder range does not match the cylinder  
range that was given for the source device. If the cylinder  
range does not match the cylinder range of the source device  
and the target device is a VM partial-pack minidisk, the  
command will be rejected because VM uses virtual cylinder  
values for partial-pack minidisks, and the cylinder ranges must  
match for VM partial-pack minidisks. The source and the  
target devices must be of the same type and must be in the  
same RVA subsystem.  
tcyl  
The decimal specification of where copying is to start  
on the target device. Cylinder is the smallest entity  
that can be specified for any SNAP command function.  
The target cyl specification (tcyl) added to the  
specified or calculated ncyl-1 value for the source  
device is the resulting target end cylinder address and  
must not exceed 32767 or the devices primary  
number of cylinders.  
VOL1= Specifies the VOL1 label that the target device is to  
receive after the source volume has been copied.  
This operand is required if unique VOLIDs are to be  
maintained. Otherwise the source and the target  
devices would have the same VOL1 label after the  
copy function has completed. The VOL1 label  
specification for a target device is accepted only when  
both the cyl and the DSN= specification have been  
omitted, that is, for full volume snaps only.  
44 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
NOPROMPT  
Prevents decision-type messages from being issued. Some  
messages require an operator reply before the specified  
function is initiated. The specification of the NOPROMPT  
keyword causes the system to bypass this decision-type  
message and initiates the function without any additional  
notice.  
Note: With the exception of file snapping (DSN=), VSE does not  
perform any VTOC checking on the specified target device and thus  
does not provide any warning message of any kind, be it overlapping  
extents, secured or unexpired files, or anything else. Cylinder or  
volume copying will be done unconditionally within the specified or  
assumed boundaries.  
B.1.2 Using SnapShot to Copy One Volume to Another  
In Figure 25 on page 46, we show the copying of one volume to another. We  
duplicate the contents of device 80E onto device 80F.  
Appendix B. IXFP Command Examples 45  
 
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
369.2 2468.7 N/A  
0.8 2837.1 N/A  
13.01 86.99 213.6  
0.03 99.97 0.0  
1.72  
9.65  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
370.129 MB  
213.688 MB  
5305.903 MB  
6.52  
3.76  
1.73  
93.48  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57752.311 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 51.01 51.01  
AR 0015 1I40I READY  
0.00 47.55 47.55 0.00 1.44  
1.44  
ixfp snap,80e:80f,vol1=patev3  
AR+0015 IXFP23D SNAP FROM CUU=80E CYL=′0000′ TO CUU=80F CYL=′0000′ NCYL=0D0B  
- REPLY YESTO PROCEED  
15 yes  
AR 0015 IXFP22I SNAP TO CUU= 80F STARTED AT 18:46:51 11/16/1998  
AR 0015 IXFP20I SNAP FUNCTION COMPLETED AT 18:46:51 11/16/1998  
AR 0015 1I40I READY  
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
369.2 2468.7 N/A  
369.2 2468.7 N/A  
13.01 86.99 213.6  
13.01 86.99 213.6  
1.72  
1.72  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
738.558 MB  
427.200 MB  
4937.474 MB  
13.01  
7.53  
1.72  
86.99  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57752.578 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 51.01 51.01  
0.00 47.67 47.67 0.00 1.32  
1.32  
AR 0015 1I40I READY  
Figure 25. Console Log from Volume Snap Operation  
46 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Notes: In Figure 25, in the DEVICE DETAIL REPORT, the data stored for device  
80F reflects snapping the data from 80E. Also, the physical used capacity  
reflects its source on device 80E. The key indicator is the  
NET-CAPACITY-LOAD (%), which shows that the PROD capacity of the  
RVA has remained constant at 51.01%.  
Using the VOLUME command, we verified that the target volume serial  
number had been changed to PATEV3.  
The actual time to accomplish the copy was less than 1 sec, as indicated  
by messages IXFP22I and IXFP20I, which show the start and end times for  
the copy.  
We used the above configuration as the base for all other manipulations of the  
RVA during the creation of this redbook. The RVA now contains two volumes,  
which have the same content but different volume serial numbers.  
B.1.3 Using SnapShot to Copy a File from One Volume to Another  
In the Figure 26, we show the snapping of a single file from one volume to  
another. The example shows the copy being done twice—once without the  
NOPROMPT option, and once with it. When NOPROMPT is selected, message  
IXFP23D is suppressed.  
ixfp snap,80e(dsn=test.data.1): 80f  
AR+0015 IXFP23D SNAP FROM CUU=80E DSN=TEST.DATA.1TO CUU=80F - REPLY YES′  
TO PROCEED  
15 yes  
AR 0015 IXFP22I SNAP TO CUU= 80F STARTED AT 11:44:44 11/20/1998  
AR 0015 IXFP20I SNAP FUNCTION COMPLETED AT 11:44:44 11/20/1998  
AR 0015 1I40I READY  
ixfp snap,80e(dsn=test.data.1): 80f,noprompt  
AR 0015 IXFP22I SNAP TO CUU= 80F STARTED AT 18:16:59 11/17/1998  
AR 0015 IXFP20I SNAP FUNCTION COMPLETED AT 18:16:59 11/17/1998  
AR 0015 1I40I READY  
Figure 26. Making a SnapShot of a Single File  
B.1.4 Using SnapShot to Copy Files with Relocation  
In the Figure 27 on page 48, we show two attempts to copy a file from device  
80E to 80F with relocation of the data on the target volume. The first copy is  
successful. The second copy fails because there is already a file on the target  
with the same file ID in the VTOC and it is unexpired. (The first would have  
failed also except that the first files expiration date had been reached.)  
Appendix B. IXFP Command Examples 47  
 
ixfp snap,80e(dsn=test.data.1): 80f(1000),noprompt  
AR 0015 IXFP22I SNAP TO CUU= 80F STARTED AT 18:52:48 11/17/1998  
AR 0015 IXFP20I SNAP FUNCTION COMPLETED AT 18:52:48 11/17/1998  
AR 0015 1I40I READY  
ixfp snap,80e(dsn=test.data.2): 80f(2000),noprompt  
AR 0015 IXFP25I VTOC ERROR DURING WRITEANY PROCESSING RC=10′ ON DEVICE=80F  
AR 0015 1I40I READY  
Figure 27. Making a SnapShot with Relocation  
B.1.5 Other Uses of SnapShot  
In this section we present some other uses of SnapShot in a VSE/ESA  
environment.  
B.1.5.1 Creating a Test Copy of a VSE/ESA System  
SnapShot can be used to make a copy of VSE/ESA system-resident volumes for  
use in testing new applications in another LPAR. Before taking the snap copy of  
DOSRES and SYSWK1, however, you need to be sure that all open files on these  
volumes have been closed. An example of this would be the shutting down of  
CICS. After DOSRES and SYSWK1 have been snapped, the target volumes could  
be reassigned from the production LPAR and reallocated to the test LPAR. You  
now have an exact copy of the production systems DOSRES and SYSWK1.  
B.1.5.2 Copying Data from a Production Virtual Machine to a Test  
System  
IXFP/SnapShot for VSE/ESA can be used to copy selected volumes from the  
production virtual machine to the test LPAR, using the procedure in B.1.5.1,  
“Creating a Test Copy of a VSE/ESA System.” The difference here is that we  
have a functioning VSE/ESA system already running in the test virtual machine  
and now want to provide updated data to it.  
An example would be that the production virtual machine has access to the full  
range of device addresses for the RVA—while the test virtual machine has a  
subset of those addresses. The addresses of the test virtual machine would be  
in a DVCDN condition to the production virtual machine and thus are available  
as a target.  
In this case, the production data would be quiesced to ensure that all updates  
were completed. SnapShot would be invoked to copy the selected volumes to  
addresses accessible by the test virtual machine. The volumes would be made  
available again to the production virtual machine.  
The test partition would then be able to use a current copy of live data for testing  
of new or revised applications.  
Notes: The same process could be used for a data warehousing application  
where there is no need for up-to-the-minute information, but the full set of  
data is required to be in the warehouse.  
The same approach could be used where the test virtual machine is  
assigned the task of backing up the data as a low priority virtual machine.  
48 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
B.2 DDSR Command  
In this section we present examples of the IXFP DDSR command.  
Remember: Before you can use the DDSR option against a volume, you must  
bring it offline by using the DVCDN VSE/ESA command.  
B.2.1 Syntax  
ꢀꢀ──IXFP────DDSR─┬────────────────────────────────┬──┬───────────┬──────────────────────────────────────────────────ꢀꢂ  
│ ┌────────────────────────────┐ │ └─,NOPROMPT─┘  
├──,unit─┬───────────────────┬─┴─┤  
└─(dcyl─┬─-dcyl─┬─)─┘  
└─.ncyl─┘  
└─,unit(DSN=data-set-name′ ) ─────┘  
Figure 28. Syntax of IXFP DDSR Command: Details  
DDSR  
If specified without any additional operand, the operator can delete the  
VTOC entries and all physical space for all non secured files residing on  
VSE-managed RVA devices whose associated expiration date has been  
reached and which have been created by VSE. A request is sent to the  
RVA subsystem, causing the RVA subsystem to release the physical  
extents that VSE considers as free space. Once released, these extents  
are reclaimed for free space allocation.  
If a unit parameter is used, without any additional operands, the data on  
the entire volume will be deleted (including the VTOC and the VOL1  
label). Therefore the volume must be reinitialized (ICKDSF) before it is  
used as a regular data-pack again, assuming it is not going to be used  
as a SNAP target device, in which case such an initialization run would  
be obsolete. VSE requires the volume to be DOWN (DVCDN command)  
if the whole volume or a range of cylinders is to be deleted.  
unit  
The device ID (cuu) or the VOL1 label of the device that should  
be either totally released or, if a data set name (DSN=) or a  
cylinder range has been specified, partially released. The  
VTOC on this device will remain unchanged unless a file was  
released, in which case the appropriate labels will be deleted  
from the VTOC. If you release the whole volume, or the  
cylinder range containing the VTOC, the VTOC will be deleted.  
dcyl-dcyl Specifies the decimal start cylinder and end cylinder  
where deletion is to start and to end. Cylinder is the  
smallest entity that can be specified for any DDSR  
command function. The highest (end) cylinder number  
must not exceed 32767, and the start cylinder number  
must not be higher than the end cylinder number.  
dcyl.ncyl Specifies the decimal start cylinder where deletion is  
to start and provides the number of cylinders (ncyl)  
that should be released. Cylinder is the smallest  
entity that can be specified for any DDSR command  
function. The highest resulting cylinder number must  
not exceed 32767 or the devices number of primary  
cylinders.  
DSN= The data set name identifying the file on the specified  
unit that the operator wants to be deleted. The file  
must be a non-VSAM file, If the specified unit is in the  
Appendix B. IXFP Command Examples 49  
 
UP (DVCUP) state, the file will be deleted  
unconditionally and the space returned to the RVA  
freespace. If the device is DOWN (DVCDN), the  
command will be rejected and an error message  
provided. Processing multivolume files is the  
responsibility of the operator, such that the DDSR  
command should be repeated for all volumes  
containing file extents.  
NOPROMPT  
Prevents decision-type messages from being issued. Some  
messages require an operator reply before the specified  
function is initiated. The specification of the NOPROMPT  
keyword causes the system to bypass this decision-type  
message and initiates the function without any additional  
notice.  
B.2.2 Using DDSR to Delete a Single Data Set  
To show the effects of using DDSR on the RVA, we deleted a single data set from  
the RVA, using the commands in Figure 29.  
ixfp report,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80F 2838.0 N/A  
AR 0015 1I40I READY  
ixfp ddsr,patev3(dsn=test.data.3′ )  
AR+0015 IXFP29D DDSR FOR CUU=80F DSN=TEST.DATA.3 - REPLY YESFOR DELETION  
369.2 2468.7 N/A  
13.01 86.99 213.6  
1.72  
15 yes  
AR 0015 1I40I READY  
ixfp report,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015 <---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80F 2838.0 N/A  
288.9 2549.0 N/A  
10.18 89.82 210.6  
1.37  
AR 0015 1I40I READY  
Figure 29. Console Log from Releasing the Space of One Data Set on a Volume  
B.2.3 Using DDSR to Delete the Contents of a Volume  
In Figure 30 on page 51, we used the DDSR option to free the entire volume with  
serial number PATEV3. After the space was released, all the data and the  
volume serial number were erased from the volume. The volume must be  
reinitialized to put the volume label back on the device.  
50 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
ixfp report,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80F 2838.0 N/A  
AR 0015 1I40I READY  
ixfp ddsr,patev3  
AR+0015 IXFP29D DDSR FOR CUU=80F (WHOLE VOLUME) - REPLY YESFOR DELETION  
15 yes  
369.2 2468.7 N/A  
13.01 86.99 213.6  
1.72  
AR 0015 1I40I READY  
ixfp report,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015 <---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80F 2838.0 N/A  
0.0 2838.0 N/A  
0.00 100.00  
0.0 N/A  
AR 0015 1I40I READY  
Figure 30. Console Log from Releasing the Space of an Entire Volume  
Note: When you use DDSR, IXFP/SnapShot for VSE/ESA always prompts the  
operator before executing the desired function, unless the NOPROMPT keyword  
is selected—in which case, the function will execute without an operator prompt.  
B.2.4 Using DDSR to Delete the Free Space on an RVA  
Figure 31 on page 52 shows the result of using DDSR to release the space  
occupied by expired files in a subsystem. Both the space occupied by the data  
and the VTOC entry are released. (There are two occurrences of TEST.DATA.1  
because device 80E was snapped to 80F.) Note that the capacity stored  
decreases while the capacity unused increases.  
Appendix B. IXFP Command Examples 51  
 
ixfp report,80e,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015 1I40I READY  
ixfp ddsr  
369.2 2468.7 N/A  
369.2 2468.7 N/A  
13.01 86.99 213.6  
13.01 86.99 213.6  
1.72  
1.72  
AR+0015 IXFP26D TEST.DATA.1HAS EXPIRED ON CUU=80E - REPLY YESFOR  
DELETION  
15 yes  
AR+0015 IXFP26D TEST.DATA.1HAS EXPIRED ON CUU=80F - REPLY YESFOR  
DELETION  
15 yes  
AR 0015 1I40I READY  
ixfp report,80e,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015 <---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
DETAIL REPORT ***  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
345.6 2492.3 N/A  
345.6 2492.3 N/A  
12.18 87.82 212.7  
12.18 87.82 212.7  
1.62  
1.62  
AR 0015 1I40I READY  
Figure 31. Console Log from Releasing the Space of All Expired Files in the RVA  
B.3 Report Command  
In this section we present examples of using the IXFP REPORT command.  
B.3.1 Syntax  
┌───────┐  
ꢀꢀ──IXFP────REPORT──┬─────┬┴────────────────────────────────────────────────────────────────────────────────────────ꢀꢂ  
└─,id─┘  
Figure 32. Syntax of IXFP REPORT Command: Details  
REPORT Provides information about the utilization of the RVA devices or, if the  
id parameter has been omitted, of the whole subsystem including all  
devices known (ADDed) to the VSE system.  
id  
The id of the device or the scope of devices for which detailed  
device utilization information is requested.  
The id can be either a VOL1 label, a channel ID, a  
channel+CU ID, or the device ID.  
IXFP REPORT,80will thus provide report information for all  
capable devices (non-partial-pack minidisks) in the device ID  
range X′800′ through X80Fthat have been ADDed to the  
VSE/ESA system during IPL.  
If we had specified the address for a non-RVA device, a report  
would not be produced. If the RVA had 256 devices specified  
52 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
and they were all on channel 8, IXFP REPORT,8would show  
all the devices in the RVA, because a storage control address  
was not specified.  
Note: The REPORT function, if used under VM, only works for full-pack  
minidisks or dedicated devices.  
B.3.2 Reporting on the Capacity of a Single Volume  
Figure 33 shows the response to a single volume request.  
ixfp report,80e  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
392.9 2445.1 N/A  
13.84 86.16 214.4  
1.83  
AR 0015 1I40I READY  
Figure 33. Single Volume IXFP REPORT  
B.3.3 Reporting on the Capacity of Multiple Volumes  
Figure 34 shows the response to a multiple volume request.  
ixfp report,80e,80f  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
DETAIL REPORT ***  
AR 0015  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015 1I40I READY  
392.9 2445.1 N/A  
392.9 2445.1 N/A  
13.84 86.16 214.4  
13.84 86.16 214.4  
1.83  
1.83  
Figure 34. Multiple Volume IXFP REPORT  
B.3.4 Reporting on the Capacity of the RVA Subsystem  
Figure 35 on page 54 shows the response to an entire subsystem request.  
Appendix B. IXFP Command Examples 53  
 
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
392.9 2445.1 N/A  
392.9 2445.1 N/A  
13.84 86.16 214.4  
13.84 86.16 214.4  
1.83  
1.83  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
785.816 MB  
428.908 MB  
4890.216 MB  
13.84  
7.56  
1.83  
86.16  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57750.030 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 51.01 51.01  
0.00 47.55 47.55 0.00 1.44  
1.44  
AR 0015 1I40I READY  
Figure 35. Entire Subsystem IXFP REPORT  
Submitting the batch job shown in Figure 36 would achieve the same results.  
// JOB WCWTEST1  
// LOG  
// EXEC DTRIATTN,PARM=IXFP REPORT′  
/&  
Figure 36. JCL to Produce an Entire Subsystem IXFP REPORT  
B.4 IXFP/SnapShot Setup Job Streams  
For the verification of IXFP/SnapShot for VSE/ESA, two RVA disks were made  
available. In this section we present the job streams used to allocate and create  
the test data. We used the following job stream to release the space on the RVA  
and write the VTOCs to the disks:  
// JOB INITDISK  
DVCDN X′80E′  
// EXEC DTRIATTN,PARM=IXFP DDSR,80E′  
DVCDN X′80F′  
// EXEC DTRIATTN,PARM=IXFP DDSR,80F′  
// LOG  
* WAIT UNTIL IXFP/SNAPSHOT HAS RELEASED THE SPACE BEFORE CONTINUING  
// EXEC IESWAIT  
DVCUP X′80E′  
DVCUP X′80F′  
// ASSGN SYS004,80E,SHR  
// EXEC ICKDSF,SIZE=AUTO  
54 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
INIT SYSNAME(SYS004) NOVERIFY PURGE VOLID(PATEV1)  
/*  
// ASSGN SYS004,80F,SHR  
// EXEC ICKDSF,SIZE=AUTO  
INIT SYSNAME(SYS004) NOVERIFY PURGE VOLID(PATEV2)  
/*  
/&  
Figure 37 shows the console log from the above job stream. Notice that we  
used DDSR to free any extraneous space on the disks.  
BG 0000 // JOB INITDISK  
DATE 11/16/1998, CLOCK 14/39/38  
BG 0000 1A86I FOLLOWING ASSIGNMENTS ARE RELEASED  
BG 0000  
IXFP DDSR,80E  
** NONE **  
AR+0015 IXFP29D DDSR FOR CUU=80E (WHOLE VOLUME) - REPLY YESFOR DELETION  
BG 0000 1A86I FOLLOWING ASSIGNMENTS ARE RELEASED  
BG 0000  
15 yes  
** NONE **  
AR 0015 1I40I READY  
IXFP DDSR,80F  
AR+0015 IXFP29D DDSR FOR CUU=80F (WHOLE VOLUME) - REPLY YESFOR DELETION  
BG 0000 * WAIT UNTIL IXFP/SNAPSHOT HAS RELEASED THE SPACE BEFORE CONTINUING  
15 yes  
AR 0015 1I40I READY  
BG 0000 DVCUP X′80E′  
BG 0000 DVCUP X′80F′  
BG 0000 EOJ INITDISK MAX.RETURN CODE=0000  
DATE 11/16/1998, CLOCK 14/40/03, DURATION 00/00/24  
Figure 37. Console Log from Formatting RVA to Receive Test Data  
Figure 38 on page 56 shows the report of the setup job. Notice that there is no  
data stored on either of the volumes.  
Appendix B. IXFP Command Examples 55  
 
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
0.0 2838.0 N/A  
0.0 2838.0 N/A  
0.00 100.00  
0.00 100.00  
0.0 N/A  
0.0 N/A  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
0.000 MB  
0.000 MB  
5676.032 MB  
0.00  
0.00  
0.00  
100.00  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57966.680 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 50.83 50.83  
0.00 47.86 47.86 0.00 1.31  
1.31  
AR 0015 1I40I READY  
Figure 38. RVA Status before Loading Any Data  
We used the following job stream (which uses DITTO to create six files) to load  
the data onto the RVA:  
// JOB BUILD DATA ON PATEV1 (80E)  
// OPTION NODUMP  
// ASSGN SYS005,DISK,VOL=PATEV1,SHR  
// DLBL OUTPUT,EXPIRED.DSF.DATA.FILE′,1998/300,SD,DSF  
// EXTENT SYS005,PATEV1,1,1,4035,1500  
// UPSI 1  
// LOG  
* DISPLAY RVA DATA FOR PATEV1 (80E) -- BEFORE DATA LOAD.  
// NOLOG  
// EXEC DTRIATTN,PARM=IXFP REPORT,PATEV1′  
// LOG  
* BUILD EXPIRED, DATA-SECURED FILE ON 80E  
*
17,000 RECORDS, 4,000 BYTES LONG, RANDOM FILL CHARACTER  
// NOLOG  
// EXEC DITTO,SIZE=AUTO  
$$DITTO BSQ FILEOUT=OUTPUT,RECSIZE=4000,NLRECS=17000,FILLCHAR=RAND,  
$$DITTO  
$$DITTO EOJ  
/*  
X
BLKFACTOR=1  
// DLBL OUTPUT,UNEXPRED.DSF.DATA.FILE′,1998/365,SD,DSF  
// EXTENT SYS005,PATEV1,1,1,5535,1500  
// LOG  
* BUILD UNEXPIRED, DATA-SECURED FILE ON 80E  
*
17,000 RECORDS, 4,000 BYTES LONG, RANDOM FILL CHARACTER  
// NOLOG  
// EXEC DITTO,SIZE=AUTO  
$$DITTO BSQ FILEOUT=OUTPUT,RECSIZE=4000,NLRECS=17000,FILLCHAR=RAND,  
$$DITTO  
$$DITTO EOJ  
X
BLKFACTOR=1  
56 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
/*  
// DLBL OUTPUT,TEST.DATA.1′,1998/300,SD  
// EXTENT SYS005,PATEV1,1,1,135,450  
// LOG  
* BUILD EXPIRED SEQUENTIAL FILE ON 80E  
*
5,000 RECORDS, 4,000 BYTES LONG, ″1″ FILL CHARACTER  
// NOLOG  
// EXEC DITTO,SIZE=AUTO  
$$DITTO BSQ FILEOUT=OUTPUT,RECSIZE=4000,NLRECS=5000,FILLCHAR=1,  
$$DITTO  
$$DITTO EOJ  
/*  
X
X
X
X
BLKFACTOR=1  
// DLBL OUTPUT,TEST.DATA.2′ , , SD  
// EXTENT SYS005,PATEV1,1,1,585,450  
// LOG  
* BUILD SEQUENTIAL FILE ON 80E  
*
5,000 RECORDS, 4,000 BYTES LONG, ″2″ FILL CHARACTER  
// NOLOG  
// EXEC DITTO,SIZE=AUTO  
$$DITTO BSQ FILEOUT=OUTPUT,RECSIZE=4000,NLRECS=5000,FILLCHAR=2,  
$$DITTO  
$$DITTO EOJ  
/*  
BLKFACTOR=1  
// DLBL OUTPUT,TEST.DATA.3′ , , SD  
// EXTENT SYS005,PATEV1,1,1,1035,1500  
// LOG  
* BUILD SEQUENTIAL FILE ON 80E  
*
17,000 RECORDS, 4,000 BYTES LONG, ″3″ FILL CHARACTER  
// NOLOG  
// EXEC DITTO,SIZE=AUTO  
$$DITTO BSQ FILEOUT=OUTPUT,RECSIZE=4000,NLRECS=17000,FILLCHAR=3,  
$$DITTO  
$$DITTO EOJ  
/*  
BLKFACTOR=1  
* BUILD SEQUENTIAL FILE ON 80E  
*
5,000 RECORDS, 4,000 BYTES LONG, ″1″ FILL  
// LOG  
* BUILD SEQUENTIAL FILE ON 80E  
*
17,000 RECORDS, 4,000 BYTES LONG, RANDOM FILL CHARACTER  
// NOLOG  
// EXEC DITTO,SIZE=AUTO  
$$DITTO BSQ FILEOUT=OUTPUT,RECSIZE=4000,NLRECS=17000,FILLCHAR=RAND,  
$$DITTO  
$$DITTO EOJ  
/*  
BLKFACTOR=1  
// LOG  
* DISPLAY RVA DATA FOR PATEV1 (80E) -- AFTER DATA LOAD.  
// NOLOG  
// EXEC DTRIATTN,PARM=IXFP REPORT,PATEV1′  
// EXEC IESWAIT  
// EXEC LISTLOG  
/&  
The result (Figure 39 on page 58) is six sequential files with varying types of  
data. Two of the files are data secured to prevent unauthorizedaccess. Three  
of the files are highly compressible because they contain a repeating data  
character, and the other three have random fill characters.  
Appendix B. IXFP Command Examples 57  
 
ixfp report  
AR 0015 SUBSYSTEM 1321117  
AR 0015 *** DEVICE  
AR 0015  
DETAIL REPORT ***  
<---FUNC. CAPACITY (MB)---> <---CAPACITY (%)---> PHYS. COMP.  
AR 0015 CUU DEF ALLOC STORED UNUSED ALLOC STORED UNUSED USED(MB) RATIO  
AR 0015 80E 2838.0 N/A  
AR 0015 80F 2838.0 N/A  
AR 0015  
AR 0015 *** DEVICE  
AR 0015 CAPACITY  
369.2 2468.7 N/A  
0.8 2837.1 N/A  
13.01 86.99 213.6  
0.03 99.97 0.0  
1.72  
9.65  
SUMMARY REPORT  
<-----TOTAL-----> <------TOTALS %------>  
5676.032 MB 100.00  
COMP.  
RATIO  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
AR 0015  
DEFINED  
STORED  
PHYS.USED  
UNUSED  
370.129 MB  
213.688 MB  
5305.903 MB  
6.52  
3.76  
1.73  
93.48  
AR 0015 *** SUBSYSTEM SUMMARY REPORT ***  
AR 0015 SYSTEM  
AR 0015 PROD  
AR 0015  
DEFINED-CAPACITY  
726532.208 MB  
DISK-ARRAY-CAP FREE-DISK-ARRAY-CAP  
117880.209 MB 57754.953 MB  
AR 0015 NET-CAPACITY-LOAD(%) COLL.-FREE-SPACE(%) UNCOLL-FREE-SPACE(%)  
AR 0015 TEST PROD OVERALL TEST PROD OVERALL TEST PROD OVERALL  
AR 0015 0.00 51.01 51.01  
0.00 47.67 47.67 0.00 1.32  
1.32  
AR 0015 1I40I READY  
Figure 39. RVA Status after Loading Data  
58 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Appendix C. VSE/VSAM Considerations  
VSE/VSAM support is not included in IXFP/SnapShot for VSE/ESA. This does not  
mean however that you cannot take advantage of IXFP/SnapShot for VSE/ESA  
with VSE/VSAM data sets.  
It does mean that there is no support in IXFP/SnapShot for VSE/ESA to  
dynamically adjust the VSAM catalog to reflect the target of the SnapShot copy.  
However, through job control, a user catalog can point to the SnapShot copy and  
access the data on the copy. In our test, we created a VSAM user catalog  
(UCAT), space, and cluster on a volume at address 80E with serial number  
PATEV1. We then snapped the volume to device address 80F with serial number  
PATEV2, changing the volume serial number to PATEV1 in the process using the  
following procedure:  
1. Close any opened files on the volume. (This may include shutting down  
CICS or other applications.)  
2. Issue the following commands:  
0 dvcdn 80f  
ixfp snap,patev1:80f,vol1=patev1  
0 dvcup 80f  
3. The JCL to access the source volume is:  
// DLBL UCAT01,VOLSER.USER.CATALOG′,,VSAM  
// DLBL DDNAME,USER.FILE.ID′,,VSAM,CAT=UCAT01  
4. To process data from the target volume, use the following JCL to access the  
VSAM file:  
// DLBL UCAT01,VOLSER.USER.CATALOG′,,VSAM  
// EXTENT SYS099,PATEV1  
// ASSGN SYS099,80F,SHR  
// DLBL DDNAME,USER.FILE.ID′,,VSAM,CAT=UCAT01  
// EXTENT SYS099,PATEV1  
The first JCL finds the source volume because its device address is lower  
than the target volumes. The second JCL can only use the data from device  
address 80F because we have explicitly pointed to that device with the  
ASSGN statement. In this case, we can access the snapped copy of the  
VSAM files on device 80F and copy it to the original volume, if required as  
part of a recovery effort.  
5. After using the target volume and its VSAM file, release the space back to  
the RVA by issuing the ixfp ddsr 80f command. (Remember that 80F would  
have to be DVCDNed before the IXFP DDSR command could be successfully  
executed.) You can also retain it online for use in a VSE/ESA partition—as  
long as the duplicate volume serial number and UCAT will not create a  
problem.  
Copyright IBM Corp. 1999  
59  
 
Warning  
This approach may not work with VSAM files that specify share options 2 or  
4. The reason for the problem here is that, with SHROPTN(2), or  
SHROPTN(4), VSE/VSAMs method of enqueuing the file (to protect it during a  
write) uses the file ID of the VSAM catalog and the volume serial number of  
the volume.  
Notes:  
Share option 2 provides that the file may be opened by more than one  
request for input processing and, at the same time, by one request for  
output processing. This option ensures write integrity; however, the  
file might be modified while records are retrieved from it, so every  
user must ensure his or her own files read integrity.  
Share option 4 provides that a key-sequenced or relative-record file  
can be opened by any number of requests (ACBs) for both input and  
output processing by users in the first system requesting output to the  
file. Once a file has been opened for output by one system,  
VSE/VSAM accepts only open for input requests from another system.  
Share option 4 for an entry-sequenced file is treated as though it were  
a share option 2.  
If, for any reason, the file were to be opened for output processing  
while the target is online to the VSE/ESA system, return code xA8′  
(168) might be returned indicating that the data set is in use. This is  
caused by the lock with duplicate volume serial numbers. The  
situation can be corrected by canceling and restarting the job after  
taking the target offline; there is no data integrity exposure.  
C.1 Backing up VSAM Volumes  
There are several instances where SnapShot can be used to back up VSAM  
volumes for use within the same LPAR or different LPARs. In a first example,  
we wanted to copy a VSAM volume that contained both the user catalog (UCAT)  
and all of the UCATs files on a single volume. In this case, we would make a  
snap copy of the volume with the target volume having a volume serial number  
different from that of the source. Before we actually issue the IXFP SNAP  
command, any files that are open have to be closed so that the data is written to  
the disk. Then a utility like VSE/FASTCOPY or the VM/ESA DDR could be used  
to back up the volume to tape. If all that we were trying to establish was a  
restart copy in case there was an application failure, the tape backup is  
superfluous. The VSAM volume cannot be used because the VSAM catalogs  
contents include the volume serial number of the volume on which it was  
created. If VSAM finds a different volume serial number, it cannot process the  
catalog.  
In a second example, the VSAM files reside on several volumes and have a  
unique UCAT for these files. Here, we would use the same procedure as above  
to quiesce activity against the files. The volumes containing the files would then  
be snap copied and, optionally, backed up to tape.  
In a third example, we again have one or more VSAM volumes controlled by a  
single UCAT. This time, we would like to carry the data from our production  
60 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
LPAR to a test LPAR. We would quiesce the files as above. And we would also  
make the SnapShot copy. But, this time, the volume serial number of the source  
would be retained on the target. Because the target volume for a SNAP copy is  
always in a DVCDN condition, the duplicate volume serial number would not  
interfere with the production system. The target volumes would then be taken  
away from the VSE production system through the use of the offline command.  
The volumes would then be placed online to the test LPAR and then, using the  
IDCAMS IMPORT CONNECT to access the UCAT, you can use the files in the test  
LPAR. In this case, IDCAMS BACKUP could be used to back up the files.  
Appendix C. VSE/VSAM Considerations 61  
 
62 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Appendix D. IOCDS Example  
IOCDS must have an LCU defined for each group of 64 functional devices. Each  
LCU should have two CNTLUNIT macros, one for each cluster.  
Figure 40 shows a sample IOCDS from the RVA.  
CHPID  
PATH=((0A),(0B),(0C),(0D)),TYPE=CNC  
CNTLUNIT CUNUMBR=001,  
UNIT=3990,  
UNITADD=((00,64)),  
PATH=(0A,0B),  
CUADD=2  
CNTLUNIT CUNUMBR=002,  
UNIT=3990,  
UNITADD=((00,64)),  
PATH=(0C,0D),  
CUADD=2  
CNTLUNIT CUNUMBR=003,  
UNIT=3990,  
UNITADD=((00,64)),  
PATH=(0A,0B),  
CUADD=3  
CNTLUNIT CUNUMBR=004,  
UNIT=3990,  
UNITADD=((00,64)),  
PATH=(0C,0D),  
CUADD=3  
IODEVICE UNIT=3390,  
ADDRESS=(180,64),  
UNITADD=00,  
STADET=Y,  
CUNUMBR=(001,002),  
IODEVICE UNIT=3390,  
ADDRESS=(1C0,64),  
UNITADD=00,  
STADET=Y,  
CUNUMBR=(003,004),  
Figure 40. IOCDS Example  
Copyright IBM Corp. 1999  
63  
 
64 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Appendix E. Special Notices  
This publication is intended to help IBM, Business Partner, and customer  
personnel understand how VSE/ESA provides support for the RAMAC Virtual  
Array. The information in this publication is not intended as the specification of  
any programming interfaces that are provided by IXFP/SnapShot for VSE/ESA,  
RAMAC Virtual Array, and peer-to-peer remote copy. See the PUBLICATIONS  
section of the IBM Programming Announcement for IXFP/SnapShot for VSE/ESA  
and peer-to-peer remote copy for the RAMAC Virtual Array for more information  
about what publications are considered to be product documentation.  
References in this publication to IBM products, programs or services do not  
imply that IBM intends to make these available in all countries in which IBM  
operates. Any reference to an IBM product, program, or service is not intended  
to state or imply that only IBMs product, program, or service may be used. Any  
functionally equivalent program that does not infringe any of IBMs intellectual  
property rights may be used instead of the IBM product, program or service.  
Information in this book was developed in conjunction with use of the equipment  
specified, and is limited in application to those specific hardware and software  
products and levels.  
IBM may have patents or pending patent applications covering subject matter in  
this document. The furnishing of this document does not give you any license to  
these patents. You can send license inquiries, in writing, to the IBM Director of  
Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.  
Licensees of this program who wish to have information about it for the purpose  
of enabling: (i) the exchange of information between independently created  
programs and other programs (including this one) and (ii) the mutual use of the  
information which has been exchanged, should contact IBM Corporation, Dept.  
600A, Mail Drop 1329, Somers, NY 10589 USA.  
Such information may be available, subject to appropriate terms and conditions,  
including in some cases, payment of a fee.  
The information contained in this document has not been submitted to any  
formal IBM test and is distributed AS IS. The information about non-IBM  
(vendor″) products in this manual has been supplied by the vendor and IBM  
assumes no responsibility for its accuracy or completeness. The use of this  
information or the implementation of any of these techniques is a customer  
responsibility and depends on the customers ability to evaluate and integrate  
them into the customers operational environment. While each item may have  
been reviewed by IBM for accuracy in a specific situation, there is no guarantee  
that the same or similar results will be obtained elsewhere. Customers  
attempting to adapt these techniques to their own environments do so at their  
own risk.  
Any pointers in this publication to external Web sites are provided for  
convenience only and do not in any manner serve as an endorsement of these  
Web sites.  
Any performance data contained in this document was determined in a  
controlled environment, and therefore, the results that may be obtained in other  
Copyright IBM Corp. 1999  
65  
 
operating environments may vary significantly. Users of this document should  
verify the applicable data for their specific environment.  
Reference to PTF numbers that have not been released through the normal  
distribution process does not imply general availability. The purpose of  
including these reference numbers is to alert IBM customers to specific  
information relative to the implementation of the PTF when it becomes available  
to each customer according to the normal IBM PTF distribution process.  
The following terms are trademarks of the International Business Machines  
Corporation in the United States and/or other countries:  
CICS  
ECKD  
IBM  
RAMAC  
VSE/ESA  
DFSORT  
ESCON  
OS/390  
VM/ESA  
The following terms are trademarks of other companies:  
IXFP  
Storage Technology Corporation  
Iceberg  
StorageTek  
Storage Technology Corporation  
Storage Technology Corporation  
C-bus is a trademark of Corollary, Inc.  
Java and HotJava are trademarks of Sun Microsystems, Incorporated.  
Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks  
or registered trademarks of Microsoft Corporation.  
PC Direct is a trademark of Ziff Communications Company and is used  
by IBM Corporation under license.  
Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks or  
registered trademarks of Intel Corporation in the U.S. and other  
countries.  
UNIX is a registered trademark in the United States and other  
countries licensed exclusively through X/Open Company Limited.  
Other company, product, and service names may be trademarks or  
service marks of others.  
66 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Appendix F. Related Publications  
The publications listed in this section are considered particularly suitable for a  
more detailed discussion of the topics covered in this redbook.  
F.1 International Technical Support Organization Publications  
For information on ordering these ITSO publications see “How to Get ITSO  
Redbooks” on page 69.  
IBM RAMAC Virtual Array, SG24-4951  
RAMAC Virtual Array: Implementing Peer-to-Peer Remote Copy, SG24-5338  
Implementing SnapShot, SG24-2241  
F.2 Redbooks on CD-ROMs  
Redbooks are also available on CD-ROMs. Order a subscription and receive  
updates 2-4 times a year.  
CD-ROM Title  
Subscription  
Number  
Collection Kit  
Number  
System/390 Redbooks Collection  
SBOF-7201  
SBOF-7370  
SBOF-7240  
SBOF-6899  
SBOF-6898  
SBOF-7270  
SBOF-7230  
SBOF-7205  
SBOF-8700  
SBOF-7290  
SK2T-2177  
SK2T-6022  
SK2T-8038  
SK2T-8039  
SK2T-8044  
SK2T-2849  
SK2T-8040  
SK2T-8041  
SK2T-8043  
SK2T-8037  
Networking and Systems Management Redbooks Collection  
Transaction Processing and Data Management Redbook  
Lotus Redbooks Collection  
Tivoli Redbooks Collection  
AS/400 Redbooks Collection  
RS/6000 Redbooks Collection (HTML, BkMgr)  
RS/6000 Redbooks Collection (PostScript)  
RS/6000 Redbooks Collection (PDF Format)  
Application Development Redbooks Collection  
F.3 Other Publications  
These publications are also relevant as further information sources:  
Device Support Facilities Users Guide and Reference, Release 16 Refresh  
with Peer-to-Peer Remote Copy, GC35-0033  
IOCP Users Guide and ESCON Channel-to-Channel Reference, GC38-0401  
Memo to Licensees (ships with the IXFP/SnapShot for VSE/ESA feature)  
Copyright IBM Corp. 1999  
67  
 
68 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
How to Get ITSO Redbooks  
This section explains how both customers and IBM employees can find out about ITSO redbooks, redpieces, and  
CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.  
Search for, view, download or order hardcopy/CD-ROMs redbooks from the redbooks Web site. Also read  
redpieces and download additional materials (code samples or diskette/CD-ROM images) from this redbooks  
site.  
Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few chapters  
will be published this way. The intent is to get the information out much quicker than the formal publishing  
process allows.  
E-mail Orders  
Send orders via e-mail including information from the redbook order form to:  
IBMMAIL  
Internet  
In United States:  
In Canada:  
usib6fpl at ibmmail  
caibmbkz at ibmmail  
dkibmbsh at ibmmail  
Outside North America:  
Telephone Orders  
United States (toll free)  
Canada (toll free)  
1-800-879-2755  
1-800-IBM-4YOU  
Outside North America  
(+45) 4810-1320 - Danish  
(+45) 4810-1420 - Dutch  
(+45) 4810-1540 - English  
(+45) 4810-1670 - Finnish  
(long distance charges apply)  
(+45) 4810-1220 - French  
(+45) 4810-1020 - German  
(+45) 4810-1620 - Italian  
(+45) 4810-1270 - Norwegian  
(+45) 4810-1120 - Spanish  
(+45) 4810-1170 - Swedish  
This information was current at the time of publication, but is continually subject to change. The latest information  
for customers may be found at http://www.redbooks.ibm.com/ and for IBM employees at  
IBM Intranet for Employees  
IBM employees may register for information on workshops, residencies, and redbooks by accessing the IBM  
Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials  
repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical  
professionals; click the Additional Materials button. Employees may also view redbook, residency and  
workshop announcements at http://inews.ibm.com/.  
Copyright IBM Corp. 1999  
69  
 
IBM Redbook Fax Order Form  
Fax your redbook orders to:  
United States (toll free)  
Canada  
1-800-445-9269  
1-403-267-4455  
Outside North America  
(+45) 48 14 2207 (long distance charge)  
Please send me the following:  
Title  
Order Number  
Quantity  
First name  
Company  
Address  
Last name  
City  
Postal code  
Country  
Telephone number  
Telefax number  
VAT number  
Invoice to customer number  
Credit card number  
Credit card expiration date  
Card issued to  
Signature  
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not  
available in all countries. Signature mandatory for credit card payment.  
70 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
Index  
functional device table  
See FDT  
functional track directory  
See FTD  
functional track table  
See FTT  
B
batch  
application processing 10  
data set reorganization  
incremental backup  
interim backup 10  
report generation 10  
9
9
H
hardware  
C
availability 10  
requirements 13  
catalog  
implications  
CKD  
4
1
compaction  
compression  
configuration  
device 41  
count key data  
See CKD  
2
I
2
I/O configuration definition data set  
See IOCDS  
I/O Configuration Program  
See IOCP  
IBM Extended Facilities Program  
See IXFP  
ICKDSF  
D
commands 15  
initialization 15  
IOCDS  
data placement  
DDSR  
8
command detail 49  
command syntax 25  
cylinder range 26  
example 50  
example 63  
IOCP  
definition 14  
IXFP  
expired files 25  
file 27  
volume 26  
function  
1
IXFP/SnapShot for VSE/ESA  
command environment 17  
command syntax 20  
functions 17  
deleted data space release  
See DDSR  
device definition 41  
device emulation 14  
dynamic configuration 10  
L
LIC requirements 13  
E
ESCON connectivity 14  
N
NCL  
description  
net capacity load  
See NCL  
1
F
FBA  
FDT  
1
1
fixed block architecture  
See FBA  
P
freespace collection  
1
peer-to-peer remote copy  
See PPRC  
FTD  
FTT  
1
2
physical copy  
PPRC  
3
functional device  
description  
functional device definition 41  
5
1
addressing 38  
benefits 33  
command syntax 36  
Copyright IBM Corp. 1999  
71  
 
PPRC (continued)  
V
distance 33  
hardware requirements 34  
operation 33  
PPRCOPY command 35  
recovery 37  
virtual disk architecture  
VM minidisks 17  
VSE/VSAM  
1
sample JCL 59  
SnapShot 22, 59  
volume backup 60  
SnapShot considerations 36  
software requirements 34  
PPRCOPY command  
parameters 35  
R
REPORT  
command detail 52  
command syntax 27  
device detail 29  
device summary 31  
example 53  
sample output 54  
requirements  
PPRC 34  
S
SnapShot  
architecture  
3
command details 43  
command syntax 21  
cylinder range 23  
example 45  
file relocation 47  
file snap 24  
logical copy  
operation  
3
4
PPRC considerations 36  
resources  
3
test system 48  
volume snap 21  
VSE/VSAM 22, 59  
software  
requirements 13  
space management  
storage management  
system testing  
7
7
SnapShot 48  
T
TNT  
description  
2
reference counter 2, 4  
track number table  
See TNT  
U
update in place  
1
72 RAMAC Virtual Array, Peer-to Peer Remote VSE/ESA  
 
ITSO Redbook Evaluation  
RAMAC Virtual Array, Peer-to-Peer Remote Copy,  
SG24-5360-00  
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this  
questionnaire and Fax it to: USA International Access Code + 1 914 432 8264 or:  
Send your comments in an Internet note to [email protected]  
Which of the following best describes you?  
__Customer  
__Business Partner  
__Solution Developer  
__IBM employee  
__None of the above  
Please rate your overall satisfaction with this book using the scale:  
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)  
Overall Satisfaction ____________  
Please answer the following questions:  
Was this redbook published in time for your needs?  
If no, please explain:  
Yes____ No____  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
What other redbooks would you like to see published?  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
Comments/Suggestions:  
(THANK YOU FOR YOUR FEEDBACK!)  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
_____________________________________________________________________________________________________  
Copyright IBM Corp. 1999  
73  
 
RAMAC Virtual Array, Peer-to-Peer Remote Copy,  
and IXFP/SnapShot for VSE/ESA  
SG24-5360-00  
 

Halo Lighting System Indoor Furnishings L1735 User Manual
Hamilton Beach Juicer 67333 User Manual
Hans Grohe Indoor Furnishings 35115801 User Manual
Harbor Freight Tools Paint Sprayer 90985 User Manual
Harbor Freight Tools Utility Trailer 47845 User Manual
Heat Glo LifeStyle Indoor Fireplace fb grand User Manual
HP Hewlett Packard Network Card HEWLETT PACKARD User Manual
Husqvarna Lawn Mower 2042 LS CA User Manual
IBM Network Card 501 User Manual
IBM Printer TF6 User Manual