Re: Another IBM tape not for z/OS
On Mon, 21 Jan 2019 22:31:52 -0600, Tim Hare wrote: >I moved a lot of tape datasets to SMS managed disk, also, but one group of >application people fought the idea of using unique, catalog-able names for >their datasets. Pure laziness - they didn't want to go through the work of >making the changes and testing. They did eventually have to do it though - >AFTER a scheduler/operator looked up the dataset name in CA-1 and put the >_wrong_ set of volume numbers into the production JCL for job involving >mailouts for jury duty.The ensuing brouhaha over citizens getting jury >notices two months in a row caused inquiries from levels of management they >hadn't heard from in years! > Aha! But that could as easily have been caused by entering an incorrect High Level Qualifier. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
I moved a lot of tape datasets to SMS managed disk, also, but one group of application people fought the idea of using unique, catalog-able names for their datasets. Pure laziness - they didn't want to go through the work of making the changes and testing. They did eventually have to do it though - AFTER a scheduler/operator looked up the dataset name in CA-1 and put the _wrong_ set of volume numbers into the production JCL for job involving mailouts for jury duty.The ensuing brouhaha over citizens getting jury notices two months in a row caused inquiries from levels of management they hadn't heard from in years! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
I did NOT say "replicated copy". Backup on DASD means some form of *backup*, but on DASD. "Replicated copy" - I understand it as remote copy, like PPRC, SRDF, TrueCopy, etc. - it is NOT a backup. Such copy protect my data against datacenter disaster, but not against software or human error. That's obvious. "air gap" could mean it cannot be destroyed by the human or software error, just by mistake. It can be really air gap - like cart on desk (or better in some safe). Less secured (against human) is copy in the ATL or VTS or on DASD. However every of the three provide *the same* in my opinion level of "air gap". I'm sorry, but the only reasons for using VTS with no real tapes at backend are: 1. VTS disk storage is cheaper than MF DASD. 2. Backup software cannot use disks as a media, it demands tape-like devices. Even emulated. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2018-12-07 o 14:29, Russell Witt pisze: Where I disagree is when you compare a "backup with air gap" to a "replicated copy". A replicated copy is corrupted at the same time that primary is corrupted. A "backup with air gap" is not. Now, can you create a "backup with air gap" on DASD - yes, I believe you can now. However, a "backup on DASD with air gap" means having the backup on expensive MF-DASD while "backup on virtual-tape" implies both the air-gap and usage of cheaper DASD. Plus, replicated virtual-tape means the air-gap backup is both a local copy and a remote copy. Sorry, but for backups I still believe that tape is the superior solution. Now, granted the new HSM-archive to the cloud is wonderful and will further decrease the usage of tape in most data centers; but many of the production sites I have reviewed show that HSM-archive data is only about 25% of their overall tape usage. Still, a large chunk - no question. Russell -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, December 7, 2018 2:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS IMHO, the air gap for tape in ATL or even more for virtual tape is as (in)secure as copy on DASD. Disclaimer: I understand "air gap" as "physical separation" backup from the system, just to be sure the backup cannot be destroyed by human mistake or any other error. I hope I understood this idiom correctly. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-12-05 o 14:39, Russell Witt pisze: So very true. And the concept of an "air-gap" backup has become a real issue and shows one of the problems with replication. And nothing is better for an "air-gap" backup than tape, including Virtual Tape. The other point is that while dasd-management products (HSM, FDR/ABR, CA-Disk) are one of the biggest users, and together with backup-solutions like DFDSS and FDR account for the majority of tape usage there are other uses as well. I have seen some production sites where DB2 backups from the DB2 utility use as much tape (measured in Mb of data) as either one. Russell Witt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Tuesday, December 4, 2018 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS On 12/02/2018 07:55 PM, Rugen, Len wrote: Batch tape should be dead, even if batch JCL still looks like tape is used. One of my last SMS projects was to manage tape, redirecting almost all to SMS disk. Before employing any technique to convert all tape data sets to DASD, one should I hope first consider whether replacing a tape data set with a DASD data set is a reasonable act based on the application design. The one logical capability of a tape data set, even one using virtual tape, that is not normally associated with a DASD data set is the innate ability to continue to exist for hours, days, or even longer after a new data set with identical name has been created, depending on how tapes volumes are scratched. The use of tape could mean the application is depending on that retention as an implicit and essential part of recovery should programming errors or other disasters occur during application processing, especially if the problem is a subtle one that isn't caught immediately. Throwing out that capability without providing a suitable substitute is something you may live to regret. Joel C. Ewing -- == 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
Re: Another IBM tape not for z/OS
Where I disagree is when you compare a "backup with air gap" to a "replicated copy". A replicated copy is corrupted at the same time that primary is corrupted. A "backup with air gap" is not. Now, can you create a "backup with air gap" on DASD - yes, I believe you can now. However, a "backup on DASD with air gap" means having the backup on expensive MF-DASD while "backup on virtual-tape" implies both the air-gap and usage of cheaper DASD. Plus, replicated virtual-tape means the air-gap backup is both a local copy and a remote copy. Sorry, but for backups I still believe that tape is the superior solution. Now, granted the new HSM-archive to the cloud is wonderful and will further decrease the usage of tape in most data centers; but many of the production sites I have reviewed show that HSM-archive data is only about 25% of their overall tape usage. Still, a large chunk - no question. Russell -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, December 7, 2018 2:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS IMHO, the air gap for tape in ATL or even more for virtual tape is as (in)secure as copy on DASD. Disclaimer: I understand "air gap" as "physical separation" backup from the system, just to be sure the backup cannot be destroyed by human mistake or any other error. I hope I understood this idiom correctly. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-12-05 o 14:39, Russell Witt pisze: > So very true. And the concept of an "air-gap" backup has become a real issue > and shows one of the problems with replication. And nothing is better for an > "air-gap" backup than tape, including Virtual Tape. > > The other point is that while dasd-management products (HSM, FDR/ABR, > CA-Disk) are one of the biggest users, and together with backup-solutions > like DFDSS and FDR account for the majority of tape usage there are other > uses as well. I have seen some production sites where DB2 backups from the > DB2 utility use as much tape (measured in Mb of data) as either one. > > Russell Witt > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joel C. Ewing > Sent: Tuesday, December 4, 2018 9:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Another IBM tape not for z/OS > > On 12/02/2018 07:55 PM, Rugen, Len wrote: >> Batch tape should be dead, even if batch JCL still looks like tape is used. >> One of my last SMS projects was to manage tape, redirecting almost all to >> SMS disk. >> >> >> > Before employing any technique to convert all tape data sets to DASD, one > should I hope first consider whether replacing a tape data set with a DASD > data set is a reasonable act based on the application design. The one logical > capability of a tape data set, even one using virtual tape, that is not > normally associated with a DASD data set is the innate ability to continue > to exist for hours, days, or even longer after a new data set with identical > name has been created, depending on how tapes volumes are scratched. The > use of tape could mean the application is depending on that retention as an > implicit and essential part of recovery should programming errors or other > disasters occur during application processing, especially if the problem is a > subtle one that isn't caught immediately. Throwing out that capability > without providing a suitable substitute is something you may live to regret. > > Joel C. Ewing > > -- > == 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.2018 r. wynosi 169.248.488 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 a
Re: Another IBM tape not for z/OS
IMHO, the air gap for tape in ATL or even more for virtual tape is as (in)secure as copy on DASD. Disclaimer: I understand "air gap" as "physical separation" backup from the system, just to be sure the backup cannot be destroyed by human mistake or any other error. I hope I understood this idiom correctly. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-12-05 o 14:39, Russell Witt pisze: So very true. And the concept of an "air-gap" backup has become a real issue and shows one of the problems with replication. And nothing is better for an "air-gap" backup than tape, including Virtual Tape. The other point is that while dasd-management products (HSM, FDR/ABR, CA-Disk) are one of the biggest users, and together with backup-solutions like DFDSS and FDR account for the majority of tape usage there are other uses as well. I have seen some production sites where DB2 backups from the DB2 utility use as much tape (measured in Mb of data) as either one. Russell Witt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Tuesday, December 4, 2018 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS On 12/02/2018 07:55 PM, Rugen, Len wrote: Batch tape should be dead, even if batch JCL still looks like tape is used. One of my last SMS projects was to manage tape, redirecting almost all to SMS disk. Before employing any technique to convert all tape data sets to DASD, one should I hope first consider whether replacing a tape data set with a DASD data set is a reasonable act based on the application design. The one logical capability of a tape data set, even one using virtual tape, that is not normally associated with a DASD data set is the innate ability to continue to exist for hours, days, or even longer after a new data set with identical name has been created, depending on how tapes volumes are scratched. The use of tape could mean the application is depending on that retention as an implicit and essential part of recovery should programming errors or other disasters occur during application processing, especially if the problem is a subtle one that isn't caught immediately. Throwing out that capability without providing a suitable substitute is something you may live to regret. Joel C. Ewing -- == 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
Roger Lowe wrote: >The "SafeGuarded Copy" feature of the IBM DS8000 disk subsystem >creates backups that are not accessible by the host and protects >them from corruption that can occur in the production environment. >Safeguarded Copy can create multiple backups on a regular basis, >such as hourly or daily. Yes, and the DS8880's direct support for z/OS DFSMShsm-managed transparent [private, public, or hybrid] cloud object storage tiering is also darn clever: http://www.redbooks.ibm.com/redbooks/pdfs/sg248381.pdf Timothy Sipples IT Architect Executive, 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: Another IBM tape not for z/OS
On Wed, 5 Dec 2018 07:39:22 -0600, Russell Witt wrote: >So very true. And the concept of an "air-gap" backup has become a real issue >and shows one of the problems with replication. And nothing is better for an >"air-gap" backup than tape, including Virtual Tape. > >The other point is that while dasd-management products (HSM, FDR/ABR, CA-Disk) >are one of the biggest users, and together with backup-solutions like DFDSS >and FDR account for the majority of tape usage there are other uses as well. I >have seen some production sites where DB2 backups from the DB2 utility use as >much tape (measured in Mb of data) as either one. > The "SafeGuarded Copy" feature of the IBM DS8000 disk subsystem creates backups that are not accessible by the host and protects them from corruption that can occur in the production environment. Safeguarded Copy can create multiple backups on a regular basis, such as hourly or daily. Roger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
So very true. And the concept of an "air-gap" backup has become a real issue and shows one of the problems with replication. And nothing is better for an "air-gap" backup than tape, including Virtual Tape. The other point is that while dasd-management products (HSM, FDR/ABR, CA-Disk) are one of the biggest users, and together with backup-solutions like DFDSS and FDR account for the majority of tape usage there are other uses as well. I have seen some production sites where DB2 backups from the DB2 utility use as much tape (measured in Mb of data) as either one. Russell Witt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Tuesday, December 4, 2018 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS On 12/02/2018 07:55 PM, Rugen, Len wrote: > Batch tape should be dead, even if batch JCL still looks like tape is used. > One of my last SMS projects was to manage tape, redirecting almost all to SMS > disk. > > > Before employing any technique to convert all tape data sets to DASD, one should I hope first consider whether replacing a tape data set with a DASD data set is a reasonable act based on the application design. The one logical capability of a tape data set, even one using virtual tape, that is not normally associated with a DASD data set is the innate ability to continue to exist for hours, days, or even longer after a new data set with identical name has been created, depending on how tapes volumes are scratched. The use of tape could mean the application is depending on that retention as an implicit and essential part of recovery should programming errors or other disasters occur during application processing, especially if the problem is a subtle one that isn't caught immediately. Throwing out that capability without providing a suitable substitute is something you may live to regret. Joel C. Ewing -- Joel C. Ewing -- 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] Re: Another IBM tape not for z/OS
Hi, I'd have to agree. Management of dataset and volume backups and dumps is tricky without HSM taking care of it by writing to tape, either real or virtual, quickly becoming a management overhead - though it did say "almost all". thanks, Simon Wheeler -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: 04 December 2018 15:30 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Another IBM tape not for z/OS WARNING: this email has originated from outside of the SSE Group. Please treat any links or attachments with caution. ** On 12/02/2018 07:55 PM, Rugen, Len wrote: > Batch tape should be dead, even if batch JCL still looks like tape is used. > One of my last SMS projects was to manage tape, redirecting almost all to SMS > disk. > > > Before employing any technique to convert all tape data sets to DASD, one should I hope first consider whether replacing a tape data set with a DASD data set is a reasonable act based on the application design. The one logical capability of a tape data set, even one using virtual tape, that is not normally associated with a DASD data set is the innate ability to continue to exist for hours, days, or even longer after a new data set with identical name has been created, depending on how tapes volumes are scratched. The use of tape could mean the application is depending on that retention as an implicit and essential part of recovery should programming errors or other disasters occur during application processing, especially if the problem is a subtle one that isn't caught immediately. Throwing out that capability without providing a suitable substitute is something you may live to regret. Joel C. Ewing -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ** SSE and associated brands: Southern Electric, Scottish Hydro, SWALEC and Atlantic are all trading names of SSE Electricity Limited registered in England and Wales number 04094263 (supply of electricity and Feed-In Tariffs); Southern Electric Gas Limited registered in England and Wales number 02716495 (supply of gas); SSE Retail Telecoms Limited registered in England and Wales number 10086511 (supply of home phone and broadband); SSE Home Services Limited registered in Scotland number SC292102 (boiler and heating repair, servicing, cover, boiler Installations and electrical wiring cover); SSE Energy Solutions Limited registered in Scotland number SC386054 (energy efficiency installations and insulation products). All members of the SSE Group. The registered office of SSE Electricity Limited, Southern Electric Gas Limited and SSE Retail Telecoms Limited is No. 1 Forbury Place, 43 Forbury Road, Reading, RG1 3JH. The registered office of SSE Home Services Limited and SSE Energy Solutions Limited is Inveralmond House, 200 Dunkeld Road, Perth, PH1 3AQ. SSE Electricity Limited is an appointed representative of SSE Home Services Limited. SSE Home Services Limited is authorised and regulated by the Financial Conduct Authority (FCA) under reference number 695476. You can check this on the Financial Services Register by visiting the FCA website. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
Years of rules enforced by tape management systems, extensive GDG use and "If you don't use catalog control, you get what you deserve" made this possible. I don't remember the SMS rules, but I'm pretty sure they required SL and catalog control. First passes didn't get all of them, but tape mount hate weeded out the rest quickly. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel C. Ewing Sent: Tuesday, December 4, 2018 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS On 12/02/2018 07:55 PM, Rugen, Len wrote: > Batch tape should be dead, even if batch JCL still looks like tape is used. > One of my last SMS projects was to manage tape, redirecting almost all to SMS > disk. > > > Before employing any technique to convert all tape data sets to DASD, one should I hope first consider whether replacing a tape data set with a DASD data set is a reasonable act based on the application design. The one logical capability of a tape data set, even one using virtual tape, that is not normally associated with a DASD data set is the innate ability to continue to exist for hours, days, or even longer after a new data set with identical name has been created, depending on how tapes volumes are scratched. The use of tape could mean the application is depending on that retention as an implicit and essential part of recovery should programming errors or other disasters occur during application processing, especially if the problem is a subtle one that isn't caught immediately. Throwing out that capability without providing a suitable substitute is something you may live to regret. Joel C. Ewing -- Joel C. Ewing -- 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: Another IBM tape not for z/OS
On 12/02/2018 07:55 PM, Rugen, Len wrote: > Batch tape should be dead, even if batch JCL still looks like tape is used. > One of my last SMS projects was to manage tape, redirecting almost all to SMS > disk. > > > Before employing any technique to convert all tape data sets to DASD, one should I hope first consider whether replacing a tape data set with a DASD data set is a reasonable act based on the application design. The one logical capability of a tape data set, even one using virtual tape, that is not normally associated with a DASD data set is the innate ability to continue to exist for hours, days, or even longer after a new data set with identical name has been created, depending on how tapes volumes are scratched. The use of tape could mean the application is depending on that retention as an implicit and essential part of recovery should programming errors or other disasters occur during application processing, especially if the problem is a subtle one that isn't caught immediately. Throwing out that capability without providing a suitable substitute is something you may live to regret. Joel C. Ewing -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
Batch tape should be dead, even if batch JCL still looks like tape is used. One of my last SMS projects was to manage tape, redirecting almost all to SMS disk. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
AFAIR, the STK product was ExHPDM - Extended High Performance Data Mover. It was "multiplexer" combining data streams from different backup jobs into one large stream. Good for drives which cannot slow down, but fortunately current drives can slow down to adjust the speed of recording to the speed of data source (which is crucial to performance). Regarding caacity - DFSMShsm can easily fill up any tape cart. Of course, due to data expiration there is a need for recycling, but ...it has always been taking place, even for MAGSTAR or 3490E drives. Yes, larger capacity means longer time per cart, but also less mounts. Regarding non-HSM data on tape ...NO. No direct tape use nowadays. Tapes in batch are so 70's. Last, but not least: VTS (optionally) utilize real tapes. Just like DFSMShsm does. Those awful huge carts. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2018-11-23 o 18:38, Russell Witt pisze: With the 20Tb/60Tb capacity, the only thing that would come close to "fully utilizing" such a tape would be some massive single-thread backups (remember, only 1 application can write to a tape at any given time) or be used as a backstore in a VTS solution. For that, they are perfect (IMHO). You can run 4, 8, 16, 64, or even 128 concurrent backups to a VTS solution so you are done with backups much quicker. Then, as a background task copy all those virtual-tape-volumes to a high-capacity physical tape(s) with a 20Tb or 60Tb capacity. Best of both worlds. Fast concurrent backups and physical tape for high reliability and portability. Most sites prefer to use replication, but I like a copy on physical tape. But, I have a huge affinity for physical tape (actually, tape in any form suits me). I remember the neat system that STK had for a while (still might) where you can run 3 or 4 DFDSS backups to a single tape volume (the tape volume was allocated to a different sub-task that the 4 DFDSS backups were communicating with). It was neat that you could run 4 DFDSS backups concurrently and since the tape was so fast it could keep up with 4 DFDSS systems writing to it concurrently. But the benefits of a VTS solution doomed that as well. Russell Witt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, November 23, 2018 10:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS Lately, all I have seen is virtual Tape emulated in dedicated VTS filled with DASD. That's all we have now. Read/write and recalls are on par with standard disk. _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, November 23, 2018 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Another IBM tape not for z/OS **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** IBM released new tape drive TS1160. 20TB/60TB capacity, up to 400/900MB/s data transfer, dual 16Gbps interface. You can attach it to your Windows server, or Linux (x64), but mainframe is excluded, no FICON attachment. -- 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.2018 r. wynosi 169.248.488 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
Re: Another IBM tape not for z/OS
W dniu 2018-11-26 o 11:18, Timothy Sipples pisze: Radoslaw Skorupka wrote: IBM released new tape drive TS1160. 20TB/60TB capacity, up to 400/900MB/s data transfer, dual 16Gbps interface. You can attach it to your Windows server, or Linux (x64), but mainframe is excluded, no FICON attachment. I think you might have missed the last 10+ years. :-) IBM has not shipped *any* IBM tape *drives* that attach to mainframes using FICON for many, many years now. Even the non-virtualized tape controllers, which did attach to mainframes via FICON (thence to IBM tape drives via FCP), are now historical. The last model in the IBM non-virtualized tape controller line was the IBM 3592-C07, which is still IBM supported but no longer marketed. Semantics. It was still mainframe-attached tape drive. MVS device was the real device, MVS volume was real tape cart. You should know that mainframe I/O is MVS-channel-CU-DEV. And CU is the controller. It has always been here. And the connection between CU and DEVice can be any type, including FC. 2. Through IBM TS7700 series virtual tape libraries, which can be optionally "backed" with tape libraries and tape drives, *currently* IBM TS4500 libraries with IBM TS1150 drives (or prior). Currently? What about TS1155? Is is still "currently" not supported as VTS backend? How many years it is? I think IBM finally will add TS1160 support to VTS. Maybe... -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another IBM tape not for z/OS
Radoslaw Skorupka wrote: >IBM released new tape drive TS1160. >20TB/60TB capacity, up to 400/900MB/s data >transfer, dual 16Gbps interface. >You can attach it to your Windows server, or >Linux (x64), but mainframe >is excluded, no FICON attachment. I think you might have missed the last 10+ years. :-) IBM has not shipped *any* IBM tape *drives* that attach to mainframes using FICON for many, many years now. Even the non-virtualized tape controllers, which did attach to mainframes via FICON (thence to IBM tape drives via FCP), are now historical. The last model in the IBM non-virtualized tape controller line was the IBM 3592-C07, which is still IBM supported but no longer marketed. There are approximately three modern ways to attach IBM tape drives to mainframes: 1. Through Fibre Channel Protocol (FCP) attachment directly to IBM mainframes, which Linux on Z and LinuxONE supports. This attachment is classic, "pure physical." 2. Through IBM TS7700 series virtual tape libraries, which can be optionally "backed" with tape libraries and tape drives, *currently* IBM TS4500 libraries with IBM TS1150 drives (or prior). The IBM announcement letter for the IBM TS1160 includes the important word "currently" not available for TS7700 configurations. (I would also point out that the JE tape media for IBM TS1160 tape drives won't be available for a few months, so it's not yet possible to write 20 TB tape cartridges.) This attachment is virtual, or as a "smart" controller if you prefer to think of it that way. Modern z/OS has fully graduated to virtual attachment, at least. Just as we no longer deal with physical 3390 volumes with direct correspondence to tracks, cylinders, and the rest, so too tape has fully virtualized for/with z/OS. This is a good thing! 3. Through cloud attachment, specifically for z/OS using the IBM Cloud Tape Connector for z/OS. Version 2.1 was also announced very recently: https://www.ibm.com/common/ssi/rep_ca/3/897/ENUS218-493/ENUS218-493.PDF Cloud Tape Connector for z/OS allows you to connect everything z/OS tape-related (and "tape"-related) to any cloud object storage that supports any of these standard interfaces: IBM Cloud Object Storage, Amazon S3, Hitachi Content Platform (HCP), or EMC Elastic Cloud Storage (ECS), most of which in turn can be backed with physical tape libraries, tape drives, and tape cartridges. You can think of this approach as "hyper virtual" or at least "double virtual" if you like. It's a little bit of a mind bender if you're not familiar with the concepts yet, but it's well worth exploring, especially if you have a lot of data to manage. For example, the tape libraries and tape drives (and standard interfaces in front of them) might not be yours, or even in your data center(s), all the while z/OS "sees" lots of tape. The IBM DS8880 series of enterprise storage units also support cloud object storage in coordinated fashion with z/OS DFSMShsm, which is also extremely clever and cool IMHO. And all of this works beautifully with z/OS Data Set Encryption enabled. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography 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: Another IBM tape not for z/OS
With the 20Tb/60Tb capacity, the only thing that would come close to "fully utilizing" such a tape would be some massive single-thread backups (remember, only 1 application can write to a tape at any given time) or be used as a backstore in a VTS solution. For that, they are perfect (IMHO). You can run 4, 8, 16, 64, or even 128 concurrent backups to a VTS solution so you are done with backups much quicker. Then, as a background task copy all those virtual-tape-volumes to a high-capacity physical tape(s) with a 20Tb or 60Tb capacity. Best of both worlds. Fast concurrent backups and physical tape for high reliability and portability. Most sites prefer to use replication, but I like a copy on physical tape. But, I have a huge affinity for physical tape (actually, tape in any form suits me). I remember the neat system that STK had for a while (still might) where you can run 3 or 4 DFDSS backups to a single tape volume (the tape volume was allocated to a different sub-task that the 4 DFDSS backups were communicating with). It was neat that you could run 4 DFDSS backups concurrently and since the tape was so fast it could keep up with 4 DFDSS systems writing to it concurrently. But the benefits of a VTS solution doomed that as well. Russell Witt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, November 23, 2018 10:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another IBM tape not for z/OS Lately, all I have seen is virtual Tape emulated in dedicated VTS filled with DASD. That's all we have now. Read/write and recalls are on par with standard disk. _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, November 23, 2018 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Another IBM tape not for z/OS **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** IBM released new tape drive TS1160. 20TB/60TB capacity, up to 400/900MB/s data transfer, dual 16Gbps interface. You can attach it to your Windows server, or Linux (x64), but mainframe is excluded, no FICON attachment. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer sy
Re: Another IBM tape not for z/OS
Lately, all I have seen is virtual Tape emulated in dedicated VTS filled with DASD. That's all we have now. Read/write and recalls are on par with standard disk. _ Dave Jousma Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Friday, November 23, 2018 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Another IBM tape not for z/OS **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** IBM released new tape drive TS1160. 20TB/60TB capacity, up to 400/900MB/s data transfer, dual 16Gbps interface. You can attach it to your Windows server, or Linux (x64), but mainframe is excluded, no FICON attachment. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Another IBM tape not for z/OS
IBM released new tape drive TS1160. 20TB/60TB capacity, up to 400/900MB/s data transfer, dual 16Gbps interface. You can attach it to your Windows server, or Linux (x64), but mainframe is excluded, no FICON attachment. -- 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.2018 r. wynosi 169.248.488 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,248,488 as at 1 January 2018. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
