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 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 FIRST TENNESSEE Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
