Re: TDMF or FDRPAS or how to migrate data
Radoslaw Skorupka: >a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same >vendor, since HDS won't talk to IBM or EMC. Unfortunately this is not an >option. That's a bit too pessimistic, I think. IBM and Hitachi Vantara both support Metro Mirror (PPRC). See here for Hitachi Vantara's whitepaper (October, 2016): https://www.hitachivantara.com/en-us/pdf/white-paper/mainframe-storage-compatibility-and-innovation-with-hitachi-vsp-g1000-whitepaper.pdf If the fiber distance is about 150 Km, that's "far-ish" but not automatically too far for these purposes. Whether a Metro Mirror-based storage migration is viable will depend on the workloads (and their storage I/O characteristics) that must run during the final pre-cutover preparation stages, and the minimum required service levels for those workloads. In many cases you can pick a "quiet" time, and the migration would be viable. If the fiber distance poses a challenge for a Metro Mirror-based storage migration, even for "quiet time" workloads, then another technically possible Metro Mirror-based approach is to deploy a "staging" storage unit (perhaps an off lease/refurbished, temporarily vendor-supplied, older model unit that's "good enough" for the short-term mission) at a shorter fiber distance to handle the cross-vendor transition, then leapfrog asynchronously from there. z/OS Basic HyperSwap could be in the picture. Please talk with the storage vendors, of course, to get their viewpoints. I'm merely providing some hypotheticals. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z and LinuxONE, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TDMF or FDRPAS or how to migrate data
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. 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TDMF or FDRPAS or how to migrate data
When we insourced our data center six years ago, we used TDMF to migrate more than 3300 volumes of various sizes approximately a thousand kilometers using a "spare" DS3 line. It required seven master sessions and corresponding agents on each source LPAR, and we ensured time-consistency between them by running the masters and agents under the master subsystem and shutting down everything else, including JES2, prior to copy session finalization. At that line speed, it took a few days to reach full copy, and we generally had less than an hour to wait for full synch to be reached during the mock and final cutover events. The solution worked amazingly well, and I highly recommend it over XRC for a migration. At the time, we were working with IBM through a VAR, so TDMF was the obvious choice. Since then I've worked with Hitachi, who prefers to use FDR, which has equivalent functionality. In either case, you can use the software short-term under the terms of whatever SOW you work out with the storage vendor for implementation. If you end up going the TDMF route, let me know if you'd be interested in a program I wrote to generate master and agent sessions, as well as CLIPs, INITs, vary jobs, and some other stuff. It was very helpful for me, as the JCL and control cards can be laborious, especially when keeping up with a changing source pool of volumes not under your control. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, November 06, 2017 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data [External Email] I feel like Paul Harvey... now for the rest of the story: We also had problems with the extended protocol, but it was not the vendor's (CNT, I think) fault. IIRC correctly, HDS had promised that they were fully functional to do XRC (or HRC as they called it then) from themselves to IBM over the CNT topology. Over the course of a year, we experienced enough transmission issues pointing to HDS that we replaced their DASD in the source side and upgraded the DASD on the target side to the fastest available from IBM at the time. I assume those issues have been resolved by HDS and CNT/McData was ultimately acquired by Brocade? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, November 06, 2017 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data Excellent warning. That's why I said "(more or less) invisible to systems on the source side". We had a similar experience when we started mirroring around Y2K. In our case, the DASD was comparable at both sides, but protocol was ESCON extended by third party technology. We got around the problem then with tuning. Today the problem is non-existent. DASD is FICON extended by DWDM. Most important, XRC works differently. Originally any changed data not yet mirrored was captured in the 'controller'; that was obviously limited by subsystem memory capacity. Now if a volume mirror falls behind, the subsystem maintains only a track map of changed data. That map cannot exceed the number of tracks regardless of the amount of data involved. Today we rarely run more than one or two seconds behind. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, November 06, 2017 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: TDMF or FDRPAS or how to migrate data One word of caution to what Skip wrote about a "pull" XRC setup that I experienced problems with in the past (12 yrs. ago). If the source side has faster DASD than the target side, the target side sent I/O pacing back to the source requesting that it slow down. This had a ripple effect on DASD response times on the source side that was definitely unacceptable. I am not sure if this is still an issue or not, but thought it worth mentioning as a point to research/consider. We replaced the slower DASD on the target side with equal or faster DASD and the issue never arose again. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, November 06, 2017 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data We use XRC and TDMF. No experience with PPRC or FDRPAS. XRC requires DS8* DASD on the source side only, and an XRC code license on the source DS8* only. DASD on the target side can be any brand because data is written out using normal I/O process. The
Re: TDMF or FDRPAS or how to migrate data
I feel like Paul Harvey... now for the rest of the story: We also had problems with the extended protocol, but it was not the vendor's (CNT, I think) fault. IIRC correctly, HDS had promised that they were fully functional to do XRC (or HRC as they called it then) from themselves to IBM over the CNT topology. Over the course of a year, we experienced enough transmission issues pointing to HDS that we replaced their DASD in the source side and upgraded the DASD on the target side to the fastest available from IBM at the time. I assume those issues have been resolved by HDS and CNT/McData was ultimately acquired by Brocade? Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, November 06, 2017 1:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data Excellent warning. That's why I said "(more or less) invisible to systems on the source side". We had a similar experience when we started mirroring around Y2K. In our case, the DASD was comparable at both sides, but protocol was ESCON extended by third party technology. We got around the problem then with tuning. Today the problem is non-existent. DASD is FICON extended by DWDM. Most important, XRC works differently. Originally any changed data not yet mirrored was captured in the 'controller'; that was obviously limited by subsystem memory capacity. Now if a volume mirror falls behind, the subsystem maintains only a track map of changed data. That map cannot exceed the number of tracks regardless of the amount of data involved. Today we rarely run more than one or two seconds behind. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, November 06, 2017 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: TDMF or FDRPAS or how to migrate data One word of caution to what Skip wrote about a "pull" XRC setup that I experienced problems with in the past (12 yrs. ago). If the source side has faster DASD than the target side, the target side sent I/O pacing back to the source requesting that it slow down. This had a ripple effect on DASD response times on the source side that was definitely unacceptable. I am not sure if this is still an issue or not, but thought it worth mentioning as a point to research/consider. We replaced the slower DASD on the target side with equal or faster DASD and the issue never arose again. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, November 06, 2017 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data We use XRC and TDMF. No experience with PPRC or FDRPAS. XRC requires DS8* DASD on the source side only, and an XRC code license on the source DS8* only. DASD on the target side can be any brand because data is written out using normal I/O process. The only requirement is that each source and target volume pair geometry must match: 3390-x must be mapped to identical 3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems on the source side because data goes straight from the source volume to the target system. Although we implemented XRC for DR purposes, we have used it twice to migrate data from one data center to another. It works extremely well for migration. There is very little outage for the actual migration because all data is already in place; just IPL and perform any necessary reconfiguration. For DR purposes, we run the SDM data mover on the target side to 'pull' data. You can run SDM on the source side, but that did not make sense to us for DR. If you have no running system on the target side, and migration is your only goal, you can run SDM on the source side and 'push' data; final result should be the same. TDMF is used for moving a volume from one UCB address to another within the same complex. When a TDMF move is complete, all sharing systems see the volser only at its new location. The old volume UCB is no longer used. I can't imagine using TDMF for center-to-center migration because the original volume 'disappears' on the source side. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, November 06, 2017 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):TDMF or FDRPAS
Re: TDMF or FDRPAS or how to migrate data
Excellent warning. That's why I said "(more or less) invisible to systems on the source side". We had a similar experience when we started mirroring around Y2K. In our case, the DASD was comparable at both sides, but protocol was ESCON extended by third party technology. We got around the problem then with tuning. Today the problem is non-existent. DASD is FICON extended by DWDM. Most important, XRC works differently. Originally any changed data not yet mirrored was captured in the 'controller'; that was obviously limited by subsystem memory capacity. Now if a volume mirror falls behind, the subsystem maintains only a track map of changed data. That map cannot exceed the number of tracks regardless of the amount of data involved. Today we rarely run more than one or two seconds behind. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, November 06, 2017 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: TDMF or FDRPAS or how to migrate data One word of caution to what Skip wrote about a "pull" XRC setup that I experienced problems with in the past (12 yrs. ago). If the source side has faster DASD than the target side, the target side sent I/O pacing back to the source requesting that it slow down. This had a ripple effect on DASD response times on the source side that was definitely unacceptable. I am not sure if this is still an issue or not, but thought it worth mentioning as a point to research/consider. We replaced the slower DASD on the target side with equal or faster DASD and the issue never arose again. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, November 06, 2017 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data We use XRC and TDMF. No experience with PPRC or FDRPAS. XRC requires DS8* DASD on the source side only, and an XRC code license on the source DS8* only. DASD on the target side can be any brand because data is written out using normal I/O process. The only requirement is that each source and target volume pair geometry must match: 3390-x must be mapped to identical 3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems on the source side because data goes straight from the source volume to the target system. Although we implemented XRC for DR purposes, we have used it twice to migrate data from one data center to another. It works extremely well for migration. There is very little outage for the actual migration because all data is already in place; just IPL and perform any necessary reconfiguration. For DR purposes, we run the SDM data mover on the target side to 'pull' data. You can run SDM on the source side, but that did not make sense to us for DR. If you have no running system on the target side, and migration is your only goal, you can run SDM on the source side and 'push' data; final result should be the same. TDMF is used for moving a volume from one UCB address to another within the same complex. When a TDMF move is complete, all sharing systems see the volser only at its new location. The old volume UCB is no longer used. I can't imagine using TDMF for center-to-center migration because the original volume 'disappears' on the source side. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, November 06, 2017 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):TDMF or FDRPAS or how to migrate data 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. Possible solutions, I'm aware: a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same vendor, since HDS won't talk to IBM or EMC. Unfortunately this is not an option. b) XRC. Require data mover. Where should it be located? In source or destination datacenter? Which DISK need XRC feature, is it source? c) software
Re: TDMF or FDRPAS or how to migrate data
One word of caution to what Skip wrote about a "pull" XRC setup that I experienced problems with in the past (12 yrs. ago). If the source side has faster DASD than the target side, the target side sent I/O pacing back to the source requesting that it slow down. This had a ripple effect on DASD response times on the source side that was definitely unacceptable. I am not sure if this is still an issue or not, but thought it worth mentioning as a point to research/consider. We replaced the slower DASD on the target side with equal or faster DASD and the issue never arose again. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, November 06, 2017 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TDMF or FDRPAS or how to migrate data We use XRC and TDMF. No experience with PPRC or FDRPAS. XRC requires DS8* DASD on the source side only, and an XRC code license on the source DS8* only. DASD on the target side can be any brand because data is written out using normal I/O process. The only requirement is that each source and target volume pair geometry must match: 3390-x must be mapped to identical 3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems on the source side because data goes straight from the source volume to the target system. Although we implemented XRC for DR purposes, we have used it twice to migrate data from one data center to another. It works extremely well for migration. There is very little outage for the actual migration because all data is already in place; just IPL and perform any necessary reconfiguration. For DR purposes, we run the SDM data mover on the target side to 'pull' data. You can run SDM on the source side, but that did not make sense to us for DR. If you have no running system on the target side, and migration is your only goal, you can run SDM on the source side and 'push' data; final result should be the same. TDMF is used for moving a volume from one UCB address to another within the same complex. When a TDMF move is complete, all sharing systems see the volser only at its new location. The old volume UCB is no longer used. I can't imagine using TDMF for center-to-center migration because the original volume 'disappears' on the source side. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, November 06, 2017 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):TDMF or FDRPAS or how to migrate data 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. Possible solutions, I'm aware: a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same vendor, since HDS won't talk to IBM or EMC. Unfortunately this is not an option. b) XRC. Require data mover. Where should it be located? In source or destination datacenter? Which DISK need XRC feature, is it source? c) software like TDMF or FDRPAS. I have no idea whether such software would help for remote target. Would it? Any other clue or idea? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TDMF or FDRPAS or how to migrate data
We use XRC and TDMF. No experience with PPRC or FDRPAS. XRC requires DS8* DASD on the source side only, and an XRC code license on the source DS8* only. DASD on the target side can be any brand because data is written out using normal I/O process. The only requirement is that each source and target volume pair geometry must match: 3390-x must be mapped to identical 3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems on the source side because data goes straight from the source volume to the target system. Although we implemented XRC for DR purposes, we have used it twice to migrate data from one data center to another. It works extremely well for migration. There is very little outage for the actual migration because all data is already in place; just IPL and perform any necessary reconfiguration. For DR purposes, we run the SDM data mover on the target side to 'pull' data. You can run SDM on the source side, but that did not make sense to us for DR. If you have no running system on the target side, and migration is your only goal, you can run SDM on the source side and 'push' data; final result should be the same. TDMF is used for moving a volume from one UCB address to another within the same complex. When a TDMF move is complete, all sharing systems see the volser only at its new location. The old volume UCB is no longer used. I can't imagine using TDMF for center-to-center migration because the original volume 'disappears' on the source side. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, November 06, 2017 8:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):TDMF or FDRPAS or how to migrate data 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. Possible solutions, I'm aware: a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same vendor, since HDS won't talk to IBM or EMC. Unfortunately this is not an option. b) XRC. Require data mover. Where should it be located? In source or destination datacenter? Which DISK need XRC feature, is it source? c) software like TDMF or FDRPAS. I have no idea whether such software would help for remote target. Would it? Any other clue or idea? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
