We do this fairly frequently because we typically replace DASD at end of warranty so that cost is capital expense rather than O&M. It's never trivial but has gotten easier over the decades. There two main areas of complexity depending on your configuration.
1. If you share DASD subsystems among LPARs/sysplexes, you have tricky maneuvers to execute. 2. For active volumes, you have to coordinate moves so as not to lose updates in the process. Our most important tool for this purpose is TDMF. We were early adopters ages ago; now owned by IBM. I still think of it as smoke and mirrors magic. It dynamically moves a volume from one location to another with no outage. Quite remarkable. . . 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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Carmen Vitullo Sent: Friday, June 26, 2020 8:46 AM To: [email protected] Subject: (External):Re: DASD migration -- Re: Hitachi RAID box going out of support CAUTION EXTERNAL EMAIL Carmen Vitullo ----- Original Message ----- From: "Grant Taylor" <[email protected]> To: [email protected] Sent: Friday, June 26, 2020 10:33:02 AM Subject: Re: DASD migration -- Re: Hitachi RAID box going out of support On 6/26/20 9:18 AM, Carmen Vitullo wrote: > it's not that difficult and most vendor will provide a migration > solution depending on your requirements . Do the vendors support migrating between vendors? Or is this vendor specific? yes, one vendor I used migrated from DASD from company A to DASD from company B. we used a third party vendor that is a partner with IBM and we used FDR for one migration to migrate the DATA but as others have said, there are a number of tools that run on Z that can migrate the data for you seamlessly one vendor provided a solution when the box was replicated without the need to run anything on Z, > some provide a tool to replicate the data, flip the switch > (figuratively) and you are now running on the new DASD subsystem. > (once DASD is cabled and new GEN is activated) I was naively thinking that there might be a way to do this within z/OS. there is, but most resellers provide services and tools to aid in the migration or do the migration for you. very simple to use DFSMS/DSS ADRDSSU to copy and flip the volser if you choose to do this yourself AIX / Linux / Solaris / Windows offer an ability to add new disks to (special) storage volumes, copy / migrate data between them, and remove the old disks, all as part of contemporary OS versions. Special meaning that the storage is provisioned with this in mind in the beginning. Each OS is slightly different in this. Note how this is done at the OS level and does not require external vendor support. pretty much the same for Z.. Does z/OS have anything similar? Or is storage fundamentally different? depending on your requirements the storage can be partitioned the way you like, most sites I've worked all DASD was used in a production environment containing volumes within storage pools, every site is different. we currently have a # of UCB's available to use and a limit of storage, if I need more storage, I add more volumes to a storage pool, simply put. > I've been a part of a couple different migrations at different shops, > all were non disruptive. :-) > as with any new subsystem, you need to make sure you have the > toleration maint for the subsystem you are installing, and the > functions/features you are going to use, P2PRC....for example Prerequisites always exist. -- Grant. . . . unix || die ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
