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
