We have used both TDMF and FDRPAS in the past to migrate entire shop's DASD from one Vendors equipment to another, usually included in the deal for the new DASD. Both seemed to work equally well, and got the job done smoothly without disruption. (I do have personal preference for FDR's products).
I just now looked at FDRPAS (haven't used it in a few years) and found this new feature that sounds like it's made for you: FDRPAS now supports migration to a site where the disks are not connected to the CPU where FDRPAS is running. FDRPAS reads the data from the source volumes and uses TCP/IP to send the data to the remote site. At the remote site, FDR/UPSTREAM for FDRPAS TCP/IP receives the data and writes it to the target disks. For more information, see Chapter 317 “FDRPAS SWAPDUMP to a Remote Site via TCP/IP”. For a large scale synchronized migration, the new FDRPAS option KEEPACTIVE=REPEAT offers a new mode of operation for SWAPDUMP that greatly increases the number of source volumes that can be included in one job, thus reducing the required number of SWAPDUMP and monitor jobs as compared to CONFIRMSPLIT=YES. With KEEPACTIVE=REPEAT, first the initial copy pass is done for every source volume. The SWAPDUMP subtasks terminate, but the I/O intercepts are left active. Then, after a pause, all of the source volumes are processed again; since the I/O intercepts have remained active, only updated tracks need to be recopied. SWAPDUMP repeatedly cycles through all of the source volumes, keeping the target volumes synchronized, until you are ready to complete the operation. For more information, see Chapter 317 “FDRPAS SWAPDUMP to a Remote Site via TCP/IP”. HTH Dana On Mon, 6 Nov 2017 17:45:22 +0100, R.S. <[email protected]> wrote: >The following scenario: >CPC is connected to a DASD box of vendor A (DISK A). The goal is to move >the data to new DASD box of unlike vendor (DISK B). DISK B is located >150km away from DISK A. In location B there will be also another CPC. > >Of course it would be nice to do it with very limited disk utilisation >and as short as possible outage window. > >The idea is to move the data in the background over some cable, stop >production, synchronize all remaining changes, stop the z/OS in location >A, start z/OS in location B. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
