Re: DASD migration -- Re: Hitachi RAID box going out of support
Bill Bishop wrote: >One issue that you may encounter with going to a new storage >system on a z9 processor is the speed of the ficon cards and >whether the new unit can z9 cards. I am not sure the new >Hitachi's can work with 4GB ficon. While Radoslaw Skorupka clarified that it's possible to worry less about link speeds when there's a switch/director in the mix, I should point out that the IBM z9 machine might not be using 4 Gb/s FICON with its storage device. FICON4 was only the maximum configurable storage I/O attachment. Other maximums were possible. The z9 generation of IBM Z machines also supported 1 Gb/s and 2 Gb/s FICON and/or ESCON, even as maximums. For direct storage attachment it's important to clarify which link type(s) and speed(s) are actually operating. I should also point out that the IBM z9 machines have passed IBM End of Service, and so have all z/OS releases (2.1 and prior) that the IBM z9 machine supported. The storage device is by no means unique in this respect. IBM is still offering a Service Extension for z/OS 2.1, available for an additional monthly fee (minimum 3 months) through September 30, 2021. Service extensions may also be available for other software. I agree with the other posters suggesting serious, quick investigation of other options involving "rebasing" these critical applications on systems and middleware that are aligned with their importance. Many people are able to help. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - 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: DASD migration -- Re: Hitachi RAID box going out of support
I have used FDRPAS, TDMF which were all vendor compatible, and Dell z/OS Migrator which must have their hardware as the target. Most movement was done with the system running at full speed. The different software packages did require different software products to be down to SWAP their files. Did require IPL to use new volumes. 25TB 3000 volumes in two days from an IBM F20 / 800 source with vendor assistance for the z/OS migrator to Dell / EMC VMAX. TDMF was in house and did as 'time as available' task. Consolidating onto bigger volumes is what takes time and we would have exceeded UCB count limit on LCU without it. But you are unlikely to be attempting that process. So your purchase should include software to move your data while the system is operating. Probably a 90 day window once the hardware is operating, with one week vendor assistance (onsite / webex). For the mainframe, I would suggest a z13 so you can IPL your old system with 31 bit IPL text that switches to 64 bit operation. Its old so you should be able to get a cheap one but with a maintenance contract. And watch the compatibility on FICON cards / directors. On Fri, Jun 26, 2020 at 3:04 PM Grant Taylor <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > On 6/26/20 3:16 AM, R.S. wrote: > > 3. 18 months is close to half of typical service contract for new dasd > > array. Still we don't know how sure is 18 months - maybe it would be 36 > > months? Even 12 months means the dasd array would have some residual value. > > n00b questions: > > 1) Is it possible to migrate from old DASD to new DASD? > > 2) How disruptive would this be to the day-to-day operation of the > existing mainframe? > > 3) What sort of prerequisites exist for this? > > I have some experience with this in the Open Systems environment, but > I'd like to know more about how such a storage migration would be done > in the mainframe world. > > > > -- > Grant. . . . > unix || die > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD migration -- Re: Hitachi RAID box going out of support
Hi. If you are interested in upgrading your dasd, you may want to consider the visara VI-8810. It’s rack mounted, SSD drives, compatible with all IBM OS and processors. Will certainly work with your Z9 Contact me offline and you can tell me what you require in terms of channels and storage and we can go from there. Regards Ken Kenneth A. Bloom Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jun 26, 2020, at 11:33 AM, Grant Taylor > <023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > > 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? > >> 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. > > 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. > > Does z/OS have anything similar? Or is storage fundamentally different? > >> 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, P2PRCfor example > > Prerequisites always exist. > > > > -- > Grant. . . . > unix || die > > -- > 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: DASD migration -- Re: Hitachi RAID box going out of support
We do this fairly frequently because we typically replace DASD at end of warranty so that cost is capital expense rather than O 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 robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Carmen Vitullo Sent: Friday, June 26, 2020 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: DASD migration -- Re: Hitachi RAID box going out of support CAUTION EXTERNAL EMAIL Carmen Vitullo - Original Message - From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU 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, P2PRCfor example Prerequisites always exist. -- Grant. . . . unix || die -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD migration -- Re: Hitachi RAID box going out of support
Carmen Vitullo - Original Message - From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU 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, P2PRCfor example Prerequisites always exist. -- Grant. . . . unix || die -- 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: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support
Simply no. 4Gbps can work with 4, 8 and 16Gbps interface on the other end. I think even current newest Hitachi DASD boxes may have 16Gbps interfaces, not 32Gbps as the only choice. Last, but not least: DIRECTOR. FICON switch allows to connect any to any speed. Yes, including 1Gbps to 32Gbps. More obviously one can connect 4Gbps FICON port to a switch with any (2,4,8,16) SFP and this port can connect to a dasd box connected in similar way, lets say 32Gbps device port connected to 16Gbps SFP. The switch can "transmit" FICON traffic from any to any port, despite of SFP speed. The "window of compatibility" apply to physical fiber optic link and transceivers on both ends (SFPs). The window is "n-2", which means 1Gbps will talk to 1, 2, 4Gbps. 2Gbps will talk to 2, 4, 8 Gbps. 4Gbps will talk to 4, 8, 16 Gbps. Note, there are other things to consider, but it regards very old CUs and microcode - older than z9. AFAIK the change was in z196 machine. -- Radoslaw Skorupka Lodz, Poland W dniu 26.06.2020 o 17:09, Bill Bishop (TMNA) pisze: One issue that you may encounter with going to a new storage system on a z9 processor is the speed of the ficon cards and whether the new unit can z9 cards. I am not sure the new Hitachi's can work with 4GB ficon. I would make sure that if you replace it, with whichever vendor, that the new unit can work with those old z9 cards. Thanks Bill Bishop Consultant, Mainframe Engineer Mainframe and Scheduling | Infrastructure Technology Services Toyota Motor North America bill.bis...@toyota.com Office: (469) 292-5149 Cell: (502) 316-4386 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Grant Taylor Sent: Friday, June 26, 2020 10:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support On 6/26/20 3:16 AM, R.S. wrote: 3. 18 months is close to half of typical service contract for new dasd array. Still we don't know how sure is 18 months - maybe it would be 36 months? Even 12 months means the dasd array would have some residual value. n00b questions: 1) Is it possible to migrate from old DASD to new DASD? 2) How disruptive would this be to the day-to-day operation of the existing mainframe? 3) What sort of prerequisites exist for this? I have some experience with this in the Open Systems environment, but I'd like to know more about how such a storage migration would be done in the mainframe world. == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? 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. 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. Does z/OS have anything similar? Or is storage fundamentally different? 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, P2PRCfor example Prerequisites always exist. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD migration -- Re: Hitachi RAID box going out of support
W dniu 26.06.2020 o 17:04, Grant Taylor pisze: On 6/26/20 3:16 AM, R.S. wrote: 3. 18 months is close to half of typical service contract for new dasd array. Still we don't know how sure is 18 months - maybe it would be 36 months? Even 12 months means the dasd array would have some residual value. n00b questions: 1) Is it possible to migrate from old DASD to new DASD? Obviously YES. And it is quite simple, IMHO simpler than in distributed systems world. I did it many times. 2) How disruptive would this be to the day-to-day operation of the existing mainframe? Do you mean migration? For parallel sysplex it can be non-disruptive. However even for the most basic configuration (monoplex, no tools like TDMF) it can be single short night outage. 3) What sort of prerequisites exist for this? Almost nothing except skilled personnel, maybe one or two persons. In order to connect new DASD you need some FICON ports, but even that is not necessary, depending on details. I have some experience with this in the Open Systems environment, but I'd like to know more about how such a storage migration would be done in the mainframe world. I have some comparison to Windows world and IMHO storage migration inn mainframe is simple and straightforward. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD migration -- Re: Hitachi RAID box going out of support
it's not that difficult and most vendor will provide a migration solution depending on your requirements . 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'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, P2PRCfor example Carmen Vitullo - Original Message - From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, June 26, 2020 10:04:36 AM Subject: DASD migration -- Re: Hitachi RAID box going out of support On 6/26/20 3:16 AM, R.S. wrote: > 3. 18 months is close to half of typical service contract for new dasd > array. Still we don't know how sure is 18 months - maybe it would be 36 > months? Even 12 months means the dasd array would have some residual value. n00b questions: 1) Is it possible to migrate from old DASD to new DASD? 2) How disruptive would this be to the day-to-day operation of the existing mainframe? 3) What sort of prerequisites exist for this? I have some experience with this in the Open Systems environment, but I'd like to know more about how such a storage migration would be done in the mainframe world. -- Grant. . . . unix || die -- 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: DASD migration -- Re: Hitachi RAID box going out of support
There are several OEM products such as FDR from Innovation, and CA, which can speedily migrate between different disk drive architectures. I think IBM utilities can do it as well, but my experience has been with the OEM's. In general, migration is easily solved. On Fri, Jun 26, 2020 at 8:04 AM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 6/26/20 3:16 AM, R.S. wrote: > > 3. 18 months is close to half of typical service contract for new dasd > > array. Still we don't know how sure is 18 months - maybe it would be 36 > > months? Even 12 months means the dasd array would have some residual > value. > > n00b questions: > > 1) Is it possible to migrate from old DASD to new DASD? > > 2) How disruptive would this be to the day-to-day operation of the > existing mainframe? > > 3) What sort of prerequisites exist for this? > > I have some experience with this in the Open Systems environment, but > I'd like to know more about how such a storage migration would be done > in the mainframe world. > > > > -- > Grant. . . . > unix || die > > -- > 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: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support
One issue that you may encounter with going to a new storage system on a z9 processor is the speed of the ficon cards and whether the new unit can z9 cards. I am not sure the new Hitachi's can work with 4GB ficon. I would make sure that if you replace it, with whichever vendor, that the new unit can work with those old z9 cards. Thanks Bill Bishop Consultant, Mainframe Engineer Mainframe and Scheduling | Infrastructure Technology Services Toyota Motor North America bill.bis...@toyota.com Office: (469) 292-5149 Cell: (502) 316-4386 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Grant Taylor Sent: Friday, June 26, 2020 10:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support On 6/26/20 3:16 AM, R.S. wrote: > 3. 18 months is close to half of typical service contract for new dasd > array. Still we don't know how sure is 18 months - maybe it would be > 36 months? Even 12 months means the dasd array would have some residual value. n00b questions: 1) Is it possible to migrate from old DASD to new DASD? 2) How disruptive would this be to the day-to-day operation of the existing mainframe? 3) What sort of prerequisites exist for this? I have some experience with this in the Open Systems environment, but I'd like to know more about how such a storage migration would be done in the mainframe world. -- Grant. . . . unix || die -- 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
DASD migration -- Re: Hitachi RAID box going out of support
On 6/26/20 3:16 AM, R.S. wrote: 3. 18 months is close to half of typical service contract for new dasd array. Still we don't know how sure is 18 months - maybe it would be 36 months? Even 12 months means the dasd array would have some residual value. n00b questions: 1) Is it possible to migrate from old DASD to new DASD? 2) How disruptive would this be to the day-to-day operation of the existing mainframe? 3) What sort of prerequisites exist for this? I have some experience with this in the Open Systems environment, but I'd like to know more about how such a storage migration would be done in the mainframe world. -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
