Re: 3592-E07
Tony, I'm pretty sure I understand RPO and RTO correctly. I'm used to teach it. However please, take care - we talk about backup copy only, not about the system. We don't know whole system setup and components. We know that tape waiting for PTAM (truck delivery to secondary DC) cause some additional period between backup is finished and backup is available in secondary data center. Of course any backup on tape is being done periodically, so one could loose some data between backups. That's true despite of backup replication/delivery method - however delivery process or asynchronous replication process adds extra time to this window. Last but not least: sometimes it is possible to recover from last existing backup only, previous copy is marked as unusable or it's hard to use it. In such scenario your systeme (DASD replicated) could be aware of last backup, but your last backup is not delivered and will never be delivered because of fire on server room. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 31.01.2020 o 17:44, Tony Thigpen pisze: Radoslaw, I think you don't understand RPO correctly. read: https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html Tony Thigpen R.S. wrote on 1/31/20 11:24 AM: W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: Radoslaw Skorupka wrote: To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. No, your RPO certainly won't be zero. A backup is a (hopefully useful) representation of data as it existed historically, at some particular past moment(s) in time. It takes some amount of time to run a backup -- let's call that "minutes or longer" for working purposes. Backups run at periodic intervals -- let's call that "hourly or less often" for working purposes. Your backups, without something else, facilitate a best case RPO that's as long/big as the maximum (worst case) time elapsed since the start of your last good backup. That practically always(*) means a RPO of "a couple hours or more." A long/big RPO usually holds RTO back too, but there are a few rare exceptions. On the other hand, it's quite possible to have a long/big RTO with a RPO of zero. (*) Why not "always"? Exotic, contrived exceptions might be possible, such as custom software that synchronizes writes directly to local and remote tape. No, my RPO *is* zero. We do not talk about backup itself, which is ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media the backup is representation of historical data. What I'm talking about is time delta between primary and secondary (local, remote) backup copies. And again: some (typical?) modes of VTS replication are not synchronous, so there is time delta between local copy is closed (and marked as done) and remote copy is also finished. For duplex write in HSM both tapes are being written simultaneously, so end of backup job means you have both copies ready. Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* the time to "historical representation". VTS non-synchronous mode adds the time also (much less). but HSM duplex write add zero. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . == 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.2019 r. wynosi 169.347.928 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:
Re: [External] Re: 3592-E07
Tony, I'm not impressed with the writing in the article. Parts of it are misleading. The picture showing the disaster and the RPO/RTO timelines on it are OK, but this paragraph leaves a bit to be desired: For example, if you have a 4-hour RPO for an application then you will have a maximum 4-hour gap between backup and data loss. Having a 4-hour RPO does not necessarily mean you will lose 4 hours' worth of data. Should a word processing application go down at midnight and come up by 1:15 am, you might not have much (or any) data to lose. But if a busy application goes down at 10 am and isn't restored until 2:00 pm, you will potentially lose 4 hours' worth of highly valuable, perhaps irreplaceable data. In this case, arrange for more frequent backup that will let you hit your application-specific RPO. The example of a busy application going down at 10 and not being restored until 2 has nothing to do with a 4 hour RPO, they're describing a 4 hour RTO. The RPO could still be 5 minutes, if the data had been backed up at 9:55 and the application went down - and trashed the data requiring a data restore - at 10:00. In a nutshell, RPO has to do with how much elapsed time you can handle between the time a backup is done and a data loss occurs, and RTO is after the loss, how long you can handle being down before your applications are back. The example in the article didn't show that. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Friday, January 31, 2020 10:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: 3592-E07 Radoslaw, I think you don't understand RPO correctly. read: https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html Tony Thigpen R.S. wrote on 1/31/20 11:24 AM: > W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: >> Radoslaw Skorupka wrote: >>> To complement and clarify: when using physical tapes (* see below) >>> your RPO and RTO may be 36 hours or zero. >> No, your RPO certainly won't be zero. A backup is a (hopefully >> useful) representation of data as it existed historically, at some >> particular past >> >> moment(s) in time. It takes some amount of time to run a backup -- >> let's call that "minutes or longer" for working purposes. Backups run >> at periodic intervals -- let's call that "hourly or less often" for >> working purposes. Your backups, without something else, facilitate a >> best case RPO >> >> that's as long/big as the maximum (worst case) time elapsed since the >> start of your last good backup. That practically always(*) means a >> RPO of "a couple hours or more." >> >> A long/big RPO usually holds RTO back too, but there are a few rare >> exceptions. On the other hand, it's quite possible to have a long/big >> RTO with a RPO of zero. >> >> (*) Why not "always"? Exotic, contrived exceptions might be possible, >> such >> >> as custom software that synchronizes writes directly to local and >> remote tape. > > No, my RPO *is* zero. We do not talk about backup itself, which is > ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media > the backup is representation of historical data. > What I'm talking about is time delta between primary and secondary > (local, remote) backup copies. > And again: some (typical?) modes of VTS replication are not > synchronous, so there is time delta between local copy is closed (and > marked as done) and remote copy is also finished. For duplex write in > HSM both tapes are being written simultaneously, so end of backup job > means you have both copies ready. > > Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* > the time to "historical representation". VTS non-synchronous mode adds > the time also (much less). but HSM duplex write add zero. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
Radoslaw, I think you don't understand RPO correctly. read: https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html Tony Thigpen R.S. wrote on 1/31/20 11:24 AM: W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: Radoslaw Skorupka wrote: To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. No, your RPO certainly won't be zero. A backup is a (hopefully useful) representation of data as it existed historically, at some particular past moment(s) in time. It takes some amount of time to run a backup -- let's call that "minutes or longer" for working purposes. Backups run at periodic intervals -- let's call that "hourly or less often" for working purposes. Your backups, without something else, facilitate a best case RPO that's as long/big as the maximum (worst case) time elapsed since the start of your last good backup. That practically always(*) means a RPO of "a couple hours or more." A long/big RPO usually holds RTO back too, but there are a few rare exceptions. On the other hand, it's quite possible to have a long/big RTO with a RPO of zero. (*) Why not "always"? Exotic, contrived exceptions might be possible, such as custom software that synchronizes writes directly to local and remote tape. No, my RPO *is* zero. We do not talk about backup itself, which is ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media the backup is representation of historical data. What I'm talking about is time delta between primary and secondary (local, remote) backup copies. And again: some (typical?) modes of VTS replication are not synchronous, so there is time delta between local copy is closed (and marked as done) and remote copy is also finished. For duplex write in HSM both tapes are being written simultaneously, so end of backup job means you have both copies ready. Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* the time to "historical representation". VTS non-synchronous mode adds the time also (much less). but HSM duplex write add zero. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: Radoslaw Skorupka wrote: To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. No, your RPO certainly won't be zero. A backup is a (hopefully useful) representation of data as it existed historically, at some particular past moment(s) in time. It takes some amount of time to run a backup -- let's call that "minutes or longer" for working purposes. Backups run at periodic intervals -- let's call that "hourly or less often" for working purposes. Your backups, without something else, facilitate a best case RPO that's as long/big as the maximum (worst case) time elapsed since the start of your last good backup. That practically always(*) means a RPO of "a couple hours or more." A long/big RPO usually holds RTO back too, but there are a few rare exceptions. On the other hand, it's quite possible to have a long/big RTO with a RPO of zero. (*) Why not "always"? Exotic, contrived exceptions might be possible, such as custom software that synchronizes writes directly to local and remote tape. No, my RPO *is* zero. We do not talk about backup itself, which is ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media the backup is representation of historical data. What I'm talking about is time delta between primary and secondary (local, remote) backup copies. And again: some (typical?) modes of VTS replication are not synchronous, so there is time delta between local copy is closed (and marked as done) and remote copy is also finished. For duplex write in HSM both tapes are being written simultaneously, so end of backup job means you have both copies ready. Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* the time to "historical representation". VTS non-synchronous mode adds the time also (much less). but HSM duplex write add zero. -- 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.2019 r. wynosi 169.347.928 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.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
Radoslaw Skorupka wrote: >To complement and clarify: when using physical tapes (* >see below) your RPO and RTO may be 36 hours or zero. No, your RPO certainly won't be zero. A backup is a (hopefully useful) representation of data as it existed historically, at some particular past moment(s) in time. It takes some amount of time to run a backup -- let's call that "minutes or longer" for working purposes. Backups run at periodic intervals -- let's call that "hourly or less often" for working purposes. Your backups, without something else, facilitate a best case RPO that's as long/big as the maximum (worst case) time elapsed since the start of your last good backup. That practically always(*) means a RPO of "a couple hours or more." A long/big RPO usually holds RTO back too, but there are a few rare exceptions. On the other hand, it's quite possible to have a long/big RTO with a RPO of zero. (*) Why not "always"? Exotic, contrived exceptions might be possible, such as custom software that synchronizes writes directly to local and remote tape. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com Mobile/SMS: +65 8526 7454 or +1 213 222 6397 or +372 5322 0545 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
I also moved to virtual tapes, however for completely different reasons. 1. Dealing with physical tapes is not a problem in ATL. The only "dealing" was to insert bunch of tapes inside. Infrequent, maybe once a half year. Also add/remove cleaning carts and remove failing data carts (very unusual). 2. Floor space. Not a problem at all, of course YMMV. It depends on tape media and drive type. Let's compare MAGSTAR B with HPCT to TS1150 with JD carts. It is thousand to one! So, instead of thousands of tapes you need few of them. 3. Labour costs. Close to zero. Last, but not least: typical VTS solution include real tape library at backend. Of course there are tapeless configurations, but usually smaller and much less expandable. In that case you have all of the issues/labours/dealings as with regular "classic" ATL. Plus all of the things related to additional cabinet contaning VTS equipment. Of course it's good to have supported equipment, so IBM real tapes attached to z/OS host are fading. There is no way to buy new solution. I'm not sure about STK/Sun/Oracle, however they cancelled T1 (tape drive) project, so there are no new tape drive models. I think they still sell existing drives (GA 2013) and it is supported, but seems to be closed also. BTW: I installed and upgraded first, the largest and probably the last mainframe tape installation from STK in Poland. It was interesting. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 30.01.2020 o 17:26, Jesse 1 Robinson pisze: We moved to virtual tape a long time ago. When projecting costs, you should consider the savings in not having to deal with physical tapes. Just the real estate alone occupied by thousands of tapes is significant, not to mention the labor costs. . . 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 R.S. Sent: Thursday, January 30, 2020 4:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: 3592-E07 To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. The advantage of TS7700 is replication feature. However for physical drives in ATL you have to have two libraries in two locations. However you can write to both libraries simultaneously. It requires HSM, DSS or FDR, however for backup purposes it is no problem. More: for some TS7700 (or Oracle VSM) modes of replication your backup on tape maybe replicated asynchronously, with delays of minutes, tens of minutes, etc. For real tape duplexing both copies are closed at the same time of job fails. (*) Physical tape - tape visible to z/OS as a device (via controller as always). Virtual tape - emulated tape drive is visible to z/OS as a device. -- Radoslaw Skorupka Lodz, Poland W dniu 23.01.2020 o 07:31, Timothy Sipples pisze: Dean Nai wrote: Currently we backup everything on 3592 nightly and the next morning they go off site for DR purposes, circa 1980’s OK, so my guess was a good one then. :-) So right now your "Recovery Point Objective" (RPO) is circa 36 hours, probably higher. For example, if you start your backup at 10:00 p.m., the tapes physically leave at 9:00 a.m., they arrive at your DR site at 10:00 a.m., and then the next batch arrives every day thereafter at 10:00 a.m., that's your 36 hours. If, organizationally, your 36 hour RPO is known, documented, agreed, accepted, and periodically reviewed, great. Then your goal is simply to get the best (lowest) RPO you can within the minimum required budgetary and other limits that at least meet the 36 hour RPO. Basically, you should be free and welcome to exceed the required 36 hour RPO as long as you don't spend any extra taxpayer dollars to exceed it. :-) If the current 36 hour RPO isn't acceptable, different story. It doesn't seem like RPO=36h would be or should be acceptable, but let's assume for now it's acceptable. I'd like to comment first on some ideas Rex raises: Rex Pommier wrote: Since it's leased, I don't know if this would even be feasible: sticking with the 3592-C07 controller but going to third party maintenance. IDK how long parts will be available for them. It's a fair question to research, as a contingency anyway. The DR site operator may have a point of view, of course. Will IBM offer some kind of extended (read: for an extra fee) support for the C07 controllers? That'll depend on parts availability as well. We got it for our C06s while we were migrating off the local physical tape. Also a fair question to research, as a contingency. Another contingency possibility to research is "stockpiling." For example, if you have one 3592-C07 controller per site, install a second one per site (two more), procured from the secondary market. If one breaks and isn't repair
Re: 3592-E07
We moved to virtual tape a long time ago. When projecting costs, you should consider the savings in not having to deal with physical tapes. Just the real estate alone occupied by thousands of tapes is significant, not to mention the labor costs. . . 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 R.S. Sent: Thursday, January 30, 2020 4:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: 3592-E07 To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. The advantage of TS7700 is replication feature. However for physical drives in ATL you have to have two libraries in two locations. However you can write to both libraries simultaneously. It requires HSM, DSS or FDR, however for backup purposes it is no problem. More: for some TS7700 (or Oracle VSM) modes of replication your backup on tape maybe replicated asynchronously, with delays of minutes, tens of minutes, etc. For real tape duplexing both copies are closed at the same time of job fails. (*) Physical tape - tape visible to z/OS as a device (via controller as always). Virtual tape - emulated tape drive is visible to z/OS as a device. -- Radoslaw Skorupka Lodz, Poland W dniu 23.01.2020 o 07:31, Timothy Sipples pisze: > Dean Nai wrote: >> Currently we backup everything on 3592 nightly and the next >> morning they go off site for DR purposes, circa 1980’s > OK, so my guess was a good one then. :-) > > So right now your "Recovery Point Objective" (RPO) is circa 36 hours, > probably higher. For example, if you start your backup at 10:00 p.m., the > tapes physically leave at 9:00 a.m., they arrive at your DR site at 10:00 > a.m., and then the next batch arrives every day thereafter at 10:00 a.m., > that's your 36 hours. If, organizationally, your 36 hour RPO is known, > documented, agreed, accepted, and periodically reviewed, great. Then your > goal is simply to get the best (lowest) RPO you can within the minimum > required budgetary and other limits that at least meet the 36 hour RPO. > Basically, you should be free and welcome to exceed the required 36 hour > RPO as long as you don't spend any extra taxpayer dollars to exceed it. :-) > > If the current 36 hour RPO isn't acceptable, different story. It doesn't > seem like RPO=36h would be or should be acceptable, but let's assume for > now it's acceptable. > > I'd like to comment first on some ideas Rex raises: > > Rex Pommier wrote: >> Since it's leased, I don't know if this would even be feasible: >> sticking with the 3592-C07 controller but going to third party >> maintenance. IDK how long parts will be available for them. > It's a fair question to research, as a contingency anyway. The DR site > operator may have a point of view, of course. > >> Will IBM offer some kind of extended (read: for an extra fee) >> support for the C07 controllers? That'll depend on parts availability >> as well. We got it for our C06s while we were migrating off the >> local physical tape. > Also a fair question to research, as a contingency. > > Another contingency possibility to research is "stockpiling." For example, > if you have one 3592-C07 controller per site, install a second one per site > (two more), procured from the secondary market. If one breaks and isn't > repairable, the other hopefully still works. I don't recommend this, and > it's not really a long-term solution. > >> Installing a small VTS at your primary site, and swinging the >> (presumably) 3584 library behind the VTS. The VTS would then become >> in essence a large cache for the tape library. This is one of the >> options we looked at when our 3592-C06 controllers fell off maintenance >> - because we couldn't find and C07s to replace them with. > Yes, the direct replacement is a "smart" controller, which is so smart it > isn't obligatory to equip it with physical tape libraries and tape drives. > Currently that's the IBM TS7770, which became generally available on > November 22, 2019. The TS7770 optionally, currently supports IBM TS1120 > through TS1150 tape drives, depending on which suitably configured tape > library you have (TS3500 or TS4500). When attached to physical tape > libraries/drives it's known as the "TS7770T." The TS7760 is also currently > available. > > I understand Dean has some concerns about direct replacement economics, > though. If the data volumes are quite low, then he could be right. > >> We ended up installing a larger VTS at the local site and a smaller >> one at our s
Re: 3592-E07
To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. The advantage of TS7700 is replication feature. However for physical drives in ATL you have to have two libraries in two locations. However you can write to both libraries simultaneously. It requires HSM, DSS or FDR, however for backup purposes it is no problem. More: for some TS7700 (or Oracle VSM) modes of replication your backup on tape maybe replicated asynchronously, with delays of minutes, tens of minutes, etc. For real tape duplexing both copies are closed at the same time of job fails. (*) Physical tape - tape visible to z/OS as a device (via controller as always). Virtual tape - emulated tape drive is visible to z/OS as a device. -- Radoslaw Skorupka Lodz, Poland W dniu 23.01.2020 o 07:31, Timothy Sipples pisze: Dean Nai wrote: Currently we backup everything on 3592 nightly and the next morning they go off site for DR purposes, circa 1980’s OK, so my guess was a good one then. :-) So right now your "Recovery Point Objective" (RPO) is circa 36 hours, probably higher. For example, if you start your backup at 10:00 p.m., the tapes physically leave at 9:00 a.m., they arrive at your DR site at 10:00 a.m., and then the next batch arrives every day thereafter at 10:00 a.m., that's your 36 hours. If, organizationally, your 36 hour RPO is known, documented, agreed, accepted, and periodically reviewed, great. Then your goal is simply to get the best (lowest) RPO you can within the minimum required budgetary and other limits that at least meet the 36 hour RPO. Basically, you should be free and welcome to exceed the required 36 hour RPO as long as you don't spend any extra taxpayer dollars to exceed it. :-) If the current 36 hour RPO isn't acceptable, different story. It doesn't seem like RPO=36h would be or should be acceptable, but let's assume for now it's acceptable. I'd like to comment first on some ideas Rex raises: Rex Pommier wrote: Since it's leased, I don't know if this would even be feasible: sticking with the 3592-C07 controller but going to third party maintenance. IDK how long parts will be available for them. It's a fair question to research, as a contingency anyway. The DR site operator may have a point of view, of course. Will IBM offer some kind of extended (read: for an extra fee) support for the C07 controllers? That'll depend on parts availability as well. We got it for our C06s while we were migrating off the local physical tape. Also a fair question to research, as a contingency. Another contingency possibility to research is "stockpiling." For example, if you have one 3592-C07 controller per site, install a second one per site (two more), procured from the secondary market. If one breaks and isn't repairable, the other hopefully still works. I don't recommend this, and it's not really a long-term solution. Installing a small VTS at your primary site, and swinging the (presumably) 3584 library behind the VTS. The VTS would then become in essence a large cache for the tape library. This is one of the options we looked at when our 3592-C06 controllers fell off maintenance - because we couldn't find and C07s to replace them with. Yes, the direct replacement is a "smart" controller, which is so smart it isn't obligatory to equip it with physical tape libraries and tape drives. Currently that's the IBM TS7770, which became generally available on November 22, 2019. The TS7770 optionally, currently supports IBM TS1120 through TS1150 tape drives, depending on which suitably configured tape library you have (TS3500 or TS4500). When attached to physical tape libraries/drives it's known as the "TS7770T." The TS7760 is also currently available. I understand Dean has some concerns about direct replacement economics, though. If the data volumes are quite low, then he could be right. We ended up installing a larger VTS at the local site and a smaller one at our secondary location, replicating between them, but we did put a 3584 library on the back end of the remote one so we still have data going to tape for long term archival. Yes, that's quite common. If we consider Dean's current DR strategy mostly in isolation, and meeting or beating the current RPO, I'd like to nominate some possible parsimonious options, in no particular order and often combinable: 1. Use a combination of nearline disk (rather than virtual or physical tape) as your backup target, SafeGuarded Copy (a feature available in IBM DS8880 and DS8890 storage units), and Global Mirror. This IBM redbook describes SafeGuarded Copy: http://www.redbooks.ibm.com/redpapers/pdfs/redp5506.pdf The primary considerations are whether you already have the storage (or plan to this year) and whether you have the right network connectivity to your DR site to support Global Mirror (versus the current "tape pickup truck" connectivity). 2. Use cloud object storage along the lines I suggested. Your
Re: 3592-E07
Hi Dean For what you are looking for the Visara VI-5990 would fit the bill. Ken Kenneth A. Bloom Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com > On Jan 26, 2020, at 11:54 AM, Russell Witt > <025adb32e6d7-dmarc-requ...@listserv.ua.edu> wrote: > > Dean, > > I have to agree with Ken, have you actually looked at small replicated > Virtual-Tape solutions on a price point? You say "The C07 is the > controller..." - indicating you might only have one (or a second one for > backup); which would then mean you probably only have 8 to 16 drives. While > the cost of a 256-drive IBM TS7700 might seem out-of-reach; there are smaller > options that add replication. Both Luminex and Optica come to mind, and I > believe there are others as well. You don't have to up to an EMC DLM or an > IBM TS7700; you can aim much smaller with replication. That would cut your DR > time down to "how long to restore my backups" instead of "how long to ship my > tapes". > > Price it out yourself. > > Russell Witt > CA 1 Architect > Broadcom > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Nai, Dean > Sent: Tuesday, January 21, 2020 2:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: 3592-E07 > > We have a 3592-E07 and our leasing company is telling us the following. > Anyone have any thoughts? We really don’t have the funding for a mirrored VTS > and if it’s not mirrored then we lose our DR plan. > > > From leasing company. > The first item to be withdrawn from service will be the 3592-C07 at the end > of 2020. The C07 is the controller for the tape drives and is required for > z/OS or z/VM to communicate with the 3592-E07 drives. > > IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best > option is to go with a VTS and locate a 2nd VTS at your DR site with > replication between the two sites. There is also the option to have an IBM > VTS with access to tape drives in a 3584 and then send those tapes offsite. > To be able to use those tapes for DR you would need another IBM VTS at you DR > location. > > > Dean Nai > >> > > -- > 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: 3592-E07
Dean, I have to agree with Ken, have you actually looked at small replicated Virtual-Tape solutions on a price point? You say "The C07 is the controller..." - indicating you might only have one (or a second one for backup); which would then mean you probably only have 8 to 16 drives. While the cost of a 256-drive IBM TS7700 might seem out-of-reach; there are smaller options that add replication. Both Luminex and Optica come to mind, and I believe there are others as well. You don't have to up to an EMC DLM or an IBM TS7700; you can aim much smaller with replication. That would cut your DR time down to "how long to restore my backups" instead of "how long to ship my tapes". Price it out yourself. Russell Witt CA 1 Architect Broadcom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. >From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- 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: 3592-E07
Dean Nai wrote: >Currently we backup everything on 3592 nightly and the next >morning they go off site for DR purposes, circa 1980’s OK, so my guess was a good one then. :-) So right now your "Recovery Point Objective" (RPO) is circa 36 hours, probably higher. For example, if you start your backup at 10:00 p.m., the tapes physically leave at 9:00 a.m., they arrive at your DR site at 10:00 a.m., and then the next batch arrives every day thereafter at 10:00 a.m., that's your 36 hours. If, organizationally, your 36 hour RPO is known, documented, agreed, accepted, and periodically reviewed, great. Then your goal is simply to get the best (lowest) RPO you can within the minimum required budgetary and other limits that at least meet the 36 hour RPO. Basically, you should be free and welcome to exceed the required 36 hour RPO as long as you don't spend any extra taxpayer dollars to exceed it. :-) If the current 36 hour RPO isn't acceptable, different story. It doesn't seem like RPO=36h would be or should be acceptable, but let's assume for now it's acceptable. I'd like to comment first on some ideas Rex raises: Rex Pommier wrote: >Since it's leased, I don't know if this would even be feasible: >sticking with the 3592-C07 controller but going to third party >maintenance. IDK how long parts will be available for them. It's a fair question to research, as a contingency anyway. The DR site operator may have a point of view, of course. >Will IBM offer some kind of extended (read: for an extra fee) >support for the C07 controllers? That'll depend on parts availability >as well. We got it for our C06s while we were migrating off the >local physical tape. Also a fair question to research, as a contingency. Another contingency possibility to research is "stockpiling." For example, if you have one 3592-C07 controller per site, install a second one per site (two more), procured from the secondary market. If one breaks and isn't repairable, the other hopefully still works. I don't recommend this, and it's not really a long-term solution. >Installing a small VTS at your primary site, and swinging the >(presumably) 3584 library behind the VTS. The VTS would then become >in essence a large cache for the tape library. This is one of the >options we looked at when our 3592-C06 controllers fell off maintenance >- because we couldn't find and C07s to replace them with. Yes, the direct replacement is a "smart" controller, which is so smart it isn't obligatory to equip it with physical tape libraries and tape drives. Currently that's the IBM TS7770, which became generally available on November 22, 2019. The TS7770 optionally, currently supports IBM TS1120 through TS1150 tape drives, depending on which suitably configured tape library you have (TS3500 or TS4500). When attached to physical tape libraries/drives it's known as the "TS7770T." The TS7760 is also currently available. I understand Dean has some concerns about direct replacement economics, though. If the data volumes are quite low, then he could be right. >We ended up installing a larger VTS at the local site and a smaller >one at our secondary location, replicating between them, but we did >put a 3584 library on the back end of the remote one so we still have >data going to tape for long term archival. Yes, that's quite common. If we consider Dean's current DR strategy mostly in isolation, and meeting or beating the current RPO, I'd like to nominate some possible parsimonious options, in no particular order and often combinable: 1. Use a combination of nearline disk (rather than virtual or physical tape) as your backup target, SafeGuarded Copy (a feature available in IBM DS8880 and DS8890 storage units), and Global Mirror. This IBM redbook describes SafeGuarded Copy: http://www.redbooks.ibm.com/redpapers/pdfs/redp5506.pdf The primary considerations are whether you already have the storage (or plan to this year) and whether you have the right network connectivity to your DR site to support Global Mirror (versus the current "tape pickup truck" connectivity). 2. Use cloud object storage along the lines I suggested. Your backup target and recovery source are the public cloud (such as IBM Cloud Object Storage), and you simply add the right software to z/OS to use cloud object storage as if it were (virtual) tape, such as IBM Cloud Tape Connector for z/OS.(*) As long as at least one cloud object storage pool with a good backup is adequately reachable from the DR site when you need to recover, and provided you have a minimum emergency z/OS image (including the cloud object storage enabling software) for quick IPL from emergency media (DVD with older HMCs, or USB media on newer) if you need it, you can restore from the cloud backup to the last good backup point. There are some variations, such as contracting with two cloud object storage providers and running backups to both (just in case one is offline, somebody forgot to renew the contract, or whatever),
Re: 3592-E07
Dean, A couple more alternatives, some better than others. Since it's leased, I don't know if this would even be feasible: sticking with the 3592-C07 controller but going to third party maintenance. IDK how long parts will be available for them. Will IBM offer some kind of extended (read: for an extra fee) support for the C07 controllers? That'll depend on parts availability as well. We got it for our C06s while we were migrating off the local physical tape. Installing a small VTS at your primary site, and swinging the (presumably) 3584 library behind the VTS. The VTS would then become in essence a large cache for the tape library. This is one of the options we looked at when our 3592-C06 controllers fell off maintenance - because we couldn't find and C07s to replace them with. We ended up installing a larger VTS at the local site and a smaller one at our secondary location, replicating between them, but we did put a 3584 library on the back end of the remote one so we still have data going to tape for long term archival. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Wednesday, January 22, 2020 5:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: 3592-E07 All good info. Currently we backup everything on 3592 nightly and the next morning they go off site for DR purposes, circa 1980’s Dean Nai On 1/22/20, 3:15 AM, "IBM Mainframe Discussion List on behalf of Timothy Sipples" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Dean Nai wrote: >>We have a 3592-E07 and our leasing company is telling us the >>following. Anyone have any thoughts? We really don’t have the funding >>for a mirrored VTS and if it’s not mirrored then we lose our DR plan. > >How are you set up today? For example, do you simply take periodic >backups to physical tape then ship the tapes to your DR site? It's not >yet clear to me whether and why you necessarily need a mirrored VTS. > >>From leasing company. >>The first item to be withdrawn from service will be the 3592-C07 at >>the end of 2020. The C07 is the controller for the tape drives and is >>required for z/OS or z/VM to communicate with the >>3592-E07 drives. >>IBM has no direct attach tape products for z/OS, z/VM or zVSE. > >Just to editorialize here, IBM has not offered "direct attach tape >products" for those operating systems (or for z/TPF) for a LONG time. >There must be a controller in the connection path, either a "smart" or "dumb" >one, in order for z/OS, z/VM, z/VSE, and/or z/TPF to use the drives. >(Linux is the exception and can work with the drives either way.) > >IBM maintenance for the last in the line of "dumb" tape controllers, >the 3592-C07, is ending at the end of 2020. > >>The best option is to go with a VTS and locate a 2nd VTS at your DR >>site with replication between the two sites. There is also the option >>to have an IBM VTS with access to tape drives in a 3584 and then send >>those tapes offsite. To be able to use those tapes for DR you would >>need another IBM VTS at you DR location. > >Before suggesting "the" answer, another relevant capability is cloud >object storage. There are a couple software products for z/OS that >equip z/OS to use cloud object storage -- whether on premises, off >premises (public cloud), or both -- as virtual tape. IBM Cloud Tape >Connector for z/OS is one such example. > >The basic approach with Cloud Tape Connector for z/OS is that you'd run >your backups pretty much per normal, but the target(s) would be any >cloud object storage that supports IBM Cloud Object Storage S3 >protocol, Amazon S3, Hitachi HCP protocol, or EMC Elastic Cloud Service >Protocol. These storage pools could be public, private, or both. >Storage pools can be backed by any sort of media, including physical >tape. Cloud Tape Connector for z/OS can encrypt data before it's saved >to cloud object storage, and you really ought to do that. For example, >you might decide to have one private pool of cloud object storage at >your DR site and also buy a subscription to IBM Cloud Object Storage as >another, duplicate pool. (IBM then further duplicates your data across >IBM's multiple sites. Where and how many depends on your subscription.) >Then, in a disaster, you'd need to get at least one basic z/OS instance >up and running, with Cloud Tape Connector for z/OS fired up, connect to >whichever cloud object storage pool has survived and is reachable, >restore, and you're back in business to the last good backup point. In >a dire emergency the first two steps would typically start from USB m
Re: 3592-E07
All good info. Currently we backup everything on 3592 nightly and the next morning they go off site for DR purposes, circa 1980’s Dean Nai On 1/22/20, 3:15 AM, "IBM Mainframe Discussion List on behalf of Timothy Sipples" wrote: > EXTERNAL: Do not open attachments or click on links unless you recognize and > trust the sender. > >Dean Nai wrote: >>We have a 3592-E07 and our leasing company is telling us >>the following. Anyone have any thoughts? We really don’t >>have the funding for a mirrored VTS and if it’s not mirrored >>then we lose our DR plan. > >How are you set up today? For example, do you simply take periodic backups >to physical tape then ship the tapes to your DR site? It's not yet clear to >me whether and why you necessarily need a mirrored VTS. > >>From leasing company. >>The first item to be withdrawn from service will be the 3592-C07 >>at the end of 2020. The C07 is the controller for the tape >>drives and is required for z/OS or z/VM to communicate with the >>3592-E07 drives. >>IBM has no direct attach tape products for z/OS, z/VM or zVSE. > >Just to editorialize here, IBM has not offered "direct attach tape >products" for those operating systems (or for z/TPF) for a LONG time. There >must be a controller in the connection path, either a "smart" or "dumb" >one, in order for z/OS, z/VM, z/VSE, and/or z/TPF to use the drives. (Linux >is the exception and can work with the drives either way.) > >IBM maintenance for the last in the line of "dumb" tape controllers, the >3592-C07, is ending at the end of 2020. > >>The best option is to go with a VTS and locate a 2nd VTS at your >>DR site with replication between the two sites. There is also the >>option to have an IBM VTS with access to tape drives in a 3584 and >>then send those tapes offsite. To be able to use those tapes for >>DR you would need another IBM VTS at you DR location. > >Before suggesting "the" answer, another relevant capability is cloud object >storage. There are a couple software products for z/OS that equip z/OS to >use cloud object storage -- whether on premises, off premises (public >cloud), or both -- as virtual tape. IBM Cloud Tape Connector for z/OS is >one such example. > >The basic approach with Cloud Tape Connector for z/OS is that you'd run >your backups pretty much per normal, but the target(s) would be any cloud >object storage that supports IBM Cloud Object Storage S3 protocol, Amazon >S3, Hitachi HCP protocol, or EMC Elastic Cloud Service Protocol. These >storage pools could be public, private, or both. Storage pools can be >backed by any sort of media, including physical tape. Cloud Tape Connector >for z/OS can encrypt data before it's saved to cloud object storage, and >you really ought to do that. For example, you might decide to have one >private pool of cloud object storage at your DR site and also buy a >subscription to IBM Cloud Object Storage as another, duplicate pool. (IBM >then further duplicates your data across IBM's multiple sites. Where and >how many depends on your subscription.) Then, in a disaster, you'd need to >get at least one basic z/OS instance up and running, with Cloud Tape >Connector for z/OS fired up, connect to whichever cloud object storage pool >has survived and is reachable, restore, and you're back in business to the >last good backup point. In a dire emergency the first two steps would >typically start from USB media at the HMC these days. > >Anyway, that's the "cloud" way to do things, and there's a lot of merit in >it. It's also combinable with VTS. For example, perhaps you take backups to >both public cloud object storage (encrypted of course) and to remote (DR >site) VTS, with no local VTS. There's a lot of flexibility in all of this, >including economic flexibility, but I'd like to understand a little more >before backing a specific alternative. > > >Timothy Sipples >IT 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
Dean Nai wrote: >We have a 3592-E07 and our leasing company is telling us >the following. Anyone have any thoughts? We really don’t >have the funding for a mirrored VTS and if it’s not mirrored >then we lose our DR plan. How are you set up today? For example, do you simply take periodic backups to physical tape then ship the tapes to your DR site? It's not yet clear to me whether and why you necessarily need a mirrored VTS. >From leasing company. >The first item to be withdrawn from service will be the 3592-C07 >at the end of 2020. The C07 is the controller for the tape >drives and is required for z/OS or z/VM to communicate with the >3592-E07 drives. >IBM has no direct attach tape products for z/OS, z/VM or zVSE. Just to editorialize here, IBM has not offered "direct attach tape products" for those operating systems (or for z/TPF) for a LONG time. There must be a controller in the connection path, either a "smart" or "dumb" one, in order for z/OS, z/VM, z/VSE, and/or z/TPF to use the drives. (Linux is the exception and can work with the drives either way.) IBM maintenance for the last in the line of "dumb" tape controllers, the 3592-C07, is ending at the end of 2020. >The best option is to go with a VTS and locate a 2nd VTS at your >DR site with replication between the two sites. There is also the >option to have an IBM VTS with access to tape drives in a 3584 and >then send those tapes offsite. To be able to use those tapes for >DR you would need another IBM VTS at you DR location. Before suggesting "the" answer, another relevant capability is cloud object storage. There are a couple software products for z/OS that equip z/OS to use cloud object storage -- whether on premises, off premises (public cloud), or both -- as virtual tape. IBM Cloud Tape Connector for z/OS is one such example. The basic approach with Cloud Tape Connector for z/OS is that you'd run your backups pretty much per normal, but the target(s) would be any cloud object storage that supports IBM Cloud Object Storage S3 protocol, Amazon S3, Hitachi HCP protocol, or EMC Elastic Cloud Service Protocol. These storage pools could be public, private, or both. Storage pools can be backed by any sort of media, including physical tape. Cloud Tape Connector for z/OS can encrypt data before it's saved to cloud object storage, and you really ought to do that. For example, you might decide to have one private pool of cloud object storage at your DR site and also buy a subscription to IBM Cloud Object Storage as another, duplicate pool. (IBM then further duplicates your data across IBM's multiple sites. Where and how many depends on your subscription.) Then, in a disaster, you'd need to get at least one basic z/OS instance up and running, with Cloud Tape Connector for z/OS fired up, connect to whichever cloud object storage pool has survived and is reachable, restore, and you're back in business to the last good backup point. In a dire emergency the first two steps would typically start from USB media at the HMC these days. Anyway, that's the "cloud" way to do things, and there's a lot of merit in it. It's also combinable with VTS. For example, perhaps you take backups to both public cloud object storage (encrypted of course) and to remote (DR site) VTS, with no local VTS. There's a lot of flexibility in all of this, including economic flexibility, but I'd like to understand a little more before backing a specific alternative. Timothy Sipples IT 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: 3592-E07
We are using Ken's Visara VTL solution and are very happy with it. Tony Thigpen Ken Bloom wrote on 1/21/20 3:10 PM: Hi Dean VTS solutions are not as expensive as you think they are depending on the amount of storage and number of channels required. Besides the vastly improved performance of a VTS over std tape, you get the additional reduction in footprint and power requirements which have the secondary effect of reducing your DR costs. If you would like to consider this option, please contact me off line. Regards Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai -- 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: 3592-E07
Neal, We use this "grid" type VTL solution here at A - one locally in Texas, and the other at our DR co-lo in MD. Work well, as long as your internet connection is sound. Regards, James Lund | Chief Systems Engineer Mainframe and Enterprise Backup Service | Division of Information Technology Texas A University 3363 TAMU | College Station, TX 77843-3363 ph: 979.845.8410 | fax: 979.845.2074 | james-l...@tamu.edu - - - - - - - - - - - - - - - - - - - - - - - - IT.tamu.edu -Original Message- From: IBM Mainframe Discussion List On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 2:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- 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: 3592-E07
Hi Dean VTS solutions are not as expensive as you think they are depending on the amount of storage and number of channels required. Besides the vastly improved performance of a VTS over std tape, you get the additional reduction in footprint and power requirements which have the secondary effect of reducing your DR costs. If you would like to consider this option, please contact me off line. Regards Ken Kenneth A. Bloom CEO Avenir Technologies Inc /d/b/a Visara International 203-984-2235 bl...@visara.com www.visara.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Nai, Dean Sent: Tuesday, January 21, 2020 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 3592-E07 We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- 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
3592-E07
We have a 3592-E07 and our leasing company is telling us the following. Anyone have any thoughts? We really don’t have the funding for a mirrored VTS and if it’s not mirrored then we lose our DR plan. From leasing company. The first item to be withdrawn from service will be the 3592-C07 at the end of 2020. The C07 is the controller for the tape drives and is required for z/OS or z/VM to communicate with the 3592-E07 drives. IBM has no direct attach tape products for z/OS, z/VM or zVSE. The best option is to go with a VTS and locate a 2nd VTS at your DR site with replication between the two sites. There is also the option to have an IBM VTS with access to tape drives in a 3584 and then send those tapes offsite. To be able to use those tapes for DR you would need another IBM VTS at you DR location. Dean Nai > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
