Re: Mainframe Executive article on the death of tape
In m3k4sszmcm@garlic.com, on 03/31/2010 at 08:50 AM, Anne Lynn Wheeler l...@garlic.com said: There are systems running more than 8 drums. 2305 drums The 2305-1 and 2305-2 were disks; the drums were 2301 and 2303. Unlike the drums, the fixed-head disks had[1] 8 exposures and RPS. [1] AFAIK the 2305 was the first device to have multiple exposures, RPS or 2-byte channel connections. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
In 88626.7995...@web54602.mail.re2.yahoo.com, on 03/29/2010 at 09:20 PM, Ed Gould ps2...@yahoo.com said: The system they want to IPL won't because they refuse to believe you cannot just IPL any old version of MVS. Then there's a more fundamental problem; they weren't running periodic DR tests. The obsolete hardware might be the least of their problems. Do you know for a fact that they could recover if they had an identical box, or are you just hoping that they could? Without testing it's Russian Roulette. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Shmuel, I really don't think you need to correct Lynn. Besides, he himself mentioned that the 2305 was actually platter based, even though it is often referred to as a drum. Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net 3/31/2010 10:42 PM In m3k4sszmcm@garlic.com, on 03/31/2010 at 08:50 AM, Anne Lynn Wheeler l...@garlic.com said: There are systems running more than 8 drums. 2305 drums The 2305-1 and 2305-2 were disks; the drums were 2301 and 2303. Unlike the drums, the fixed-head disks had[1] 8 exposures and RPS. [1] AFAIK the 2305 was the first device to have multiple exposures, RPS or 2-byte channel connections. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes: The 2305-1 and 2305-2 were disks; the drums were 2301 and 2303. Unlike the drums, the fixed-head disks had[1] 8 exposures and RPS. [1] AFAIK the 2305 was the first device to have multiple exposures, RPS or 2-byte channel connections. re: http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape that was why i prefixed the lead into the email http://www.garlic.com/~lynn/2010g.html#email800710 with explanation that 2305 were physically fixed-head disks. however, it had become regular practice to refer to paging drums from the 2301 history ... and it carried over to referring to 2305 as paging drums I then repeated part of the explanation with the leadin to the immediate following email http://www.garlic.com/~lynn/2010g.html#email800804 as mentioned in earlier post in thread, I had tried to add multiple exposures for fixed-head 3350 feature ... but got shutdown by JUPITER effort in POK (which thot that they might be doing an electronic paging disk/drum) http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape other posts in thread: http://www.garlic.com/~lynn/2010f.html#65 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#24 Mainframe Executive article on the death of tape -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes: The 2305-1 and 2305-2 were disks; the drums were 2301 and 2303. Unlike the drums, the fixed-head disks had[1] 8 exposures and RPS. [1] AFAIK the 2305 was the first device to have multiple exposures, RPS or 2-byte channel connections. re: http://www.garlic.com/~lynn/2010f.html#65 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#24 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#30 Mainframe Executive article on the death of tape I've mentioned before that the science center had joint project with endicott to support 370 virtual memory architecture ... in cp67 virtual machines. this involved modifying cp67 to add support for virtual 370 ... as alternative to virtual 360/67 (aka the format of the tables were different and the control registers were different and some of the instructions were different). Partly because the cambridge cp67 had non-employees (students and others from educational institutions in the cambridge area, aka BU, MIT, Harvard, etc) ... the work went on with a version of cp67 that ran in a 360/67 virtual machine. basically: cp67 L ... running on real 360/67 cp67 H ... running in virtual 360/67 CP67 I ... running in virtual 370 The cp67i system was up and running regularly a year before there was real 370 engineering machine with virtual memory hardware. In fact, the cp67i system was used to test the first engineering 370 with virtual memory hardware (370/145 in endicott). then two engineers from san jose came out and added 3330 2305 device support to cp67i ... which was referred to as cp67sj. Then for a long time, there were large number of 370/145s running with the cp67sj system (both before and after 370 virtual memory was announced ... and even after vm370 rewrite was available). as referred to in comments about boeing 3033 and stc electronic paging ... i don't believe they ever got the 2-byte interface working. http://www.garlic.com/~lynn/2010g.html#email800804 370/158 would periodically have issues with just single-byte (1.5mbyte/sec) 2305s ... because of timing, latency and cable length issues ... and 303x channel director was 370/158 engine with just the integrated channel microcode (and w/o the 370 microcode). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Lynn, I don't recall the year, but there was an IBM annual report one year with a picture of a computer room and an STK Solid State Disk Subsystem standing proudly standing against the wall in teh background. Ron late 70s, early 80s ... internally there was a lot of 1655 from a vendor ... used for paging at large number of internal vm370 sites. they could be configured as 2305 fixed-head disk emulation or as native (if you wrote the support). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
ron.hawkins1...@sbcglobal.net (Ronald Hawkins) writes: Lynn, I don't recall the year, but there was an IBM annual report one year with a picture of a computer room and an STK Solid State Disk Subsystem standing proudly standing against the wall in teh background. Ron re: http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape Recent thread in a.f.c. newsgroup regarding some work I did as undergraduate in the 60s on working set, page replacement algorithms and page I/O implementation (I also cut the pathlength significantly, which then started growing with vm370). In the early 80s that got me in middle of disagreement with somebody doing Stanford Phd on paging (very similar to what I had done on cp67 in 60s) ... which was counter to some of the academic literature from the 60s. http://www.garlic.com/~lynn/2010f.html#85 16:32 far pointers in OpenWatcom C/C++ http://www.garlic.com/~lynn/2010f.html#89 16:32 far pointers in OpenWatcom C/C++ http://www.garlic.com/~lynn/2010f.html#90 16:32 far pointers in OpenWatcom C/C++ http://www.garlic.com/~lynn/2010f.html#91 16:32 far pointers in OpenWatcom C/C++ the above also mentions changing cp67 2301 drum page i/o from single operation at a time getting 80 page i/os per sec (avg. rotational delay for every i/o) to rotationally ordered chained requests (increase to 300 page i/os per sec) Three email references ... two from 1980 on STC solid state, and one from 1982 on the IBM 1655 (drums is from 2301 which was physically rotating drum/cylinder ... 2305 was physically multiple platter, head/track, fixed-head disk). Date: 07/10/80 08:13:08 From: wheeler There are systems running more than 8 drums. 2305 drums I don't think are any longer in production. I would guess that the configuration limit is an attempt to distribute whats available to as many people as possible. One place with 12+ drums has run out of floor space. They will probably go to STC solid state drums, not because they are faster require less cooling but because they don't have enuf floor space to install all the 2305s they think they need. STL, YKT, etc., most of the large 168 complexes I know about run 8 drums. STL is attempting to get more than 8 drums for the 3033s replacing 168s but they are hard to find. I would have to double check but I think STL has at least one 3033 with 10 or 12 drums. ... snip ... There were two models of 2305 fixed-head disk, 1.5mbyte/sec about 12mbytes and two-byte interface, 3mbyte/sec, 6mbytes and half the latency. In the 3mbyte/sec, it paired two heads per track, offset 180degrees (but didn't increase the numbers of heads so cut the number of tracks in half with two heads read/written simultaneously). Date: 08/04/80 09:18:57 To: wheeler Hi, The 2305 vs STC 4305 tests so far look like this: 1. The 4305 is definitely faster. Page i/o time 3.7 ms versus 5.8 avg for 2305. 2. Benchmark showed a 10% increase in paging rate and 60% reduction in pagewait. 3. Q length for q1 went from 14.8 to 7.8. Here is the amazing conclusion so far: 1. The cpu queue grew from 8.7 to 14.2 and the cpu became saturated. 2. The number of paging sios tripled on the 4305 because of the lack of page chaining resulting in an increase of 4-5% cpu. %chain was 84 on drum vs 54 on stc. Also average pages chained on drum was 6 vs 2 on stc. 3. The net effect was that the increase in paging overhead saturated the cpu and the actual problem state time to users was decreased from 30.29 to 28.03. In other words the faster paging device had a negative effect on boeing system (vm) and can be used only where there is a lot of cpu left to handle the additional paging and page sios. We have yet to test the two-byte interface with stc .. which according to what we have so far will make things even worse (it doubles data xfer rate) and therefore speed of paging. Thre have been a number of h/w problems with stc trying to get the 2-byte interface to work and it still doesnt. I will let you know what the results of that are. The benchmark used is pretty typical of boeing. The 3033 approachees cpu saturation with a paging rate of 300-400 and in in this case it looks like a faster paging device would only create a cpu bottleneck. STC may be ahead of its time since we dont have a fast enough cpu. An ap or mp may produce better results, however. ... snip ... The 3mbyte/sec, two-byte interface had lots of problems at installations (whether STC or 2305) because of timinglatency issues. The later 3880/3380 3mbyte/sec was done by introduction of data streaming ... relaxing the channel end-to-end handshaking for every byte transferred (allowing multiple byte transfer per end-to-end handshake). Data streaming relaxing the end-to-end handshaking also increased the maximum channel distance from 200ft to 400ft. Date: 03/03/82 07:52:54 To: wheeler Re model numbers.. yes lots of fun with those. For example, the Intel Drum we are getting
Re: Mainframe Executive article on the death of tape
As well you should, vendors claims should not be taken as gospel! I was just alerting you that when you hear SSD today, you should not assume it bears any resemblance to the SSD of yesteryear - they are completely different beasts. You should have been at Seattle, Bob Rogers and I went on a Firesign trip for about 20 minutes at SCIDS ;-) Did you know they got together again and did a Y2K album, and then put out a few more after that? Practically all their work is available on CD at George Carlin's laugh.com Rick Fochtman rfocht...@ync.net 3/30/2010 9:47 PM Been a LOONG time since I heard of Firesign Theater. Still have two of their albums. Point taken but I was paid very well for 23 years to be very skeptical of ALL hardware vendors' claims. Twice, that skepticism paid off. :-) Rick CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 30 Mar 2010 19:05:06 -0700, rfocht...@ync.net (Rick Fochtman) wrote: During the Chicago Flood of 1992, we discovered a number of holes in our disaster recovery procedures, but our provider was able to supply the necessary expertise and equipment to plug those holes. Consequently, we were able to recover our (admittedly small) shop in just over 5 hours, at least to the point where our basic business functions could proceed. Then we hit issues like how to distribute printed reports, and how to print them in a timely fashion. That's when we learned about channel extension, power supply and distribution at alternate sites. All in all, a very powerful learning experience. That's how we learn disaster preparedness.We wait and see what disasters we get then prepare for a recurrence, assuming that the disaster someone else gets won't happen to us. Even when the disaster was planned by enemies who see our preparation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
re: http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the death of tape http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the death of tape i don't remember for sure ... but i don't think that boeing ever got stc 3mbyte/sec 2byte interface working on 3033s. recent channel discussions http://www.garlic.com/~lynn/2010e.html#27 SHAREWARE at Its Finest http://www.garlic.com/~lynn/2010e.html#30 SHAREWARE at Its Finest http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water chilled) including this old email in above post: http://www.garlic.com/~lynn/2010e.html#email810617 303x channel directors were really 370/158s with only the integrated channel microcode and w/o the 370 microcode. i have recollection of 370/158 shooting hardware problems with 2305 1.5mbyte/sec where channel cable lengths starting getting much over 20-30 ft. 3mbyte/sec 2305s were pretty much 370/168 attachments (because of the faster channels). re: http://www.garlic.com/~lynn/2010g.html#email800710 so the floor space issue in the referenced email ... wasn't necessarily total datacenter floor space ... but floor space within the more limited channel cable length for 2305 1.5mbyte transfers. re: http://www.garlic.com/~lynn/2010g.html#email800804 the other reference to higher paging rates and compute intensive ... trivial interactive workloads have always tended to be dominated by paging latency (and cpu overhead to do page transfers). If an environment that was running 100% cpu utilization ... doing faster paging would tend to reduce interactive response, increase total interactive thruput, increase paging rate, and increase paging related cpu use (it isn't strictly doing less work ... it is shifting some of the work from the more compute intensive workload to the more interactive intensive workload). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Thanks, Rick. I was beginning to think that my post didn't hit the list, and I had figured it to raise more than a few hairs on the backs of heads. ;-) Anyway... Yes! I think (don't know at all, for sure, so this is just my opinion) that too many shops back up data and that's it. Without repeated testing, backups are worth squat. Not to mention all the other required facilities, such as telephony, internet connectivity, etc., etc., etc. All the best, Scott Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Tuesday, March 30, 2010 10:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape --snip- I think we would all be appalled and scared crap-less (to put it nicely) if we all really knew the true state of BCP's at many companies. There should be more customer involvement in DR; built into the contracts. IOW, review of required test results, etc., if the customer so chooses; at a minimum, so that they can tell that a test was done! Rigid accountability to those that make the company viable is the only way towards improvement here. --unsnip-- Complete agreement, Scott. But far too many IT Executives are interested only in the bottom line. DR planning and testing are an insurance policy that is all too often viewed as an unnecessary expense. During the Chicago Flood of 1992, we discovered a number of holes in our disaster recovery procedures, but our provider was able to supply the necessary expertise and equipment to plug those holes. Consequently, we were able to recover our (admittedly small) shop in just over 5 hours, at least to the point where our basic business functions could proceed. Then we hit issues like how to distribute printed reports, and how to print them in a timely fashion. That's when we learned about channel extension, power supply and distribution at alternate sites. All in all, a very powerful learning experience. Another shop that I know of never did get running at the DR site; quite a few heads were rolled after that little fiasco, and they were high-level heads! :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 31 Mar 2010 09:04:19 -0700, in bit.listserv.ibm-main you wrote: Thanks, Rick. I was beginning to think that my post didn't hit the list, and I had figured it to raise more than a few hairs on the backs of heads. ;-) Anyway... Yes! I think (don't know at all, for sure, so this is just my opinion) that too many shops back up data and that's it. Without repeated testing, backups are worth squat. Not to mention all the other required facilities, such as telephony, internet connectivity, etc., etc., etc. And the same is true for your personal PC. I hadn't done backups for 2 weeks when the hard drive on my computer decided to crash. I got a new computer and was grateful that I at least had that and that my email is on my USB key. I am now revising my backup and recovery procedures. All the best, Scott Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Fochtman Sent: Tuesday, March 30, 2010 10:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape --snip- I think we would all be appalled and scared crap-less (to put it nicely) if we all really knew the true state of BCP's at many companies. There should be more customer involvement in DR; built into the contracts. IOW, review of required test results, etc., if the customer so chooses; at a minimum, so that they can tell that a test was done! Rigid accountability to those that make the company viable is the only way towards improvement here. --unsnip-- Complete agreement, Scott. But far too many IT Executives are interested only in the bottom line. DR planning and testing are an insurance policy that is all too often viewed as an unnecessary expense. During the Chicago Flood of 1992, we discovered a number of holes in our disaster recovery procedures, but our provider was able to supply the necessary expertise and equipment to plug those holes. Consequently, we were able to recover our (admittedly small) shop in just over 5 hours, at least to the point where our basic business functions could proceed. Then we hit issues like how to distribute printed reports, and how to print them in a timely fashion. That's when we learned about channel extension, power supply and distribution at alternate sites. All in all, a very powerful learning experience. Another shop that I know of never did get running at the DR site; quite a few heads were rolled after that little fiasco, and they were high-level heads! :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 31 Mar 2010 09:04:19 -0700, scott.har...@embarqmail.com (Scott T. Harder) wrote: Anyway... Yes! I think (don't know at all, for sure, so this is just my opinion) that too many shops back up data and that's it. Without repeated testing, backups are worth squat. Not to mention all the other required facilities, such as telephony, internet connectivity, etc., etc., etc. We test our backup procedures all the time. Testing restore procedures?That would tie up my computer, we can't afford to do that. Running from a remote site? That would cost too much. Surviving a disaster? Hopefully that will be someone else's problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I often think I want to be one of the dead or at least unavailable if we ever have a disaster. If I have to do the recovery, it'll probably kill me. It'll be mostly seat of the pants. Very HOT SEAT. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Brazee Sent: Wednesday, March 31, 2010 10:48 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape On 31 Mar 2010 09:04:19 -0700, scott.har...@embarqmail.com (Scott T. Harder) wrote: Anyway... Yes! I think (don't know at all, for sure, so this is just my opinion) that too many shops back up data and that's it. Without repeated testing, backups are worth squat. Not to mention all the other required facilities, such as telephony, internet connectivity, etc., etc., etc. We test our backup procedures all the time. Testing restore procedures?That would tie up my computer, we can't afford to do that. Running from a remote site? That would cost too much. Surviving a disaster? Hopefully that will be someone else's problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ronald Hawkins pisze: Ted, I don't agree that this is conventional wisdom for SSD. The target datasets for SSD are (a) very low read cache hit percentage, (b) very high sibling pend delays, or (c) a net D2C and C2D IO demand that exceeds the capabiltiy of disk drives a used capacity ratio around 10% (depends on what you pay for disk and SSD). I would suggest that only part of many high profile databases meet that criteria. I think the 80/20 or 90/10 ROT are still alive and kicking. To complement: 1. Today SSD means Flash memory. There are other solutions (i.e. DRAM based), but extremely expensive and very limited capacity. 2. Enterprise SSD is more complex than USB stick. It is related among others to algorithms that cause memory cells evenly used and redundant cells. 2.1 (see above) SSDs are very susceptible to wear. After nnn writes the cell is destroyed. Every write means isolation breakdown. 3. SSD write is not so fast. SSD read is reasonable fast. The fastest is seek time. 4. SSD is not warranted/trusted to keep data for years. 5. SSD GB/Watts consumed ratio is poor! It's worse than for HDD. Don't confuse it with device/Watts ratio (usually SSDs are smaller in capacity). 6. Last but not least: this technology is being enhanced very dynamically. What you know today may be history tomorrow. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
R.S. r.skoru...@bremultibank.com.pl wrote in message news:4bb1a484.7080...@bremultibank.com.pl... Ronald Hawkins pisze: Ted, I don't agree that this is conventional wisdom for SSD. The target datasets for SSD are (a) very low read cache hit percentage, (b) very high sibling pend delays, or (c) a net D2C and C2D IO demand that exceeds the capabiltiy of disk drives a used capacity ratio around 10% (depends on what you pay for disk and SSD). I would suggest that only part of many high profile databases meet that criteria. I think the 80/20 or 90/10 ROT are still alive and kicking. To complement: 1. Today SSD means Flash memory. There are other solutions (i.e. DRAM based), but extremely expensive and very limited capacity. 2. Enterprise SSD is more complex than USB stick. It is related among others to algorithms that cause memory cells evenly used and redundant cells. 2.1 (see above) SSDs are very susceptible to wear. After nnn writes the cell is destroyed. Every write means isolation breakdown. Calculations I have seen for the current SSD drives for PCs, taking into consideration the amount of spare cells, the write access pattern and the lifetime of 10.000 writes per cell, show that they should last 10 years. That should be enough, compared to the lifetime of the average diskdrive in current storage systems. 3. SSD write is not so fast. SSD read is reasonable fast. The fastest is seek time. 4. SSD is not warranted/trusted to keep data for years. 5. SSD GB/Watts consumed ratio is poor! It's worse than for HDD. Don't confuse it with device/Watts ratio (usually SSDs are smaller in capacity). 6. Last but not least: this technology is being enhanced very dynamically. What you know today may be history tomorrow. Sure, a year ago SSD for PC's was very expensive, this year the internal management technology still has improved and they have become affordable and I suppose next year a 1 TB harddisk will be sold regularly for performance, with 10TB rotating disks for large storage. -- Radoslaw Skorupka Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ed Gould wrote: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. Sorry Ed, but perhaps I missed something obvious, do you really mean 24x7x365 instead of 24x7x7? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote in message news:listserv%201003300400254643.0...@bama.ua.edu... Ed Gould wrote: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. Sorry Ed, but perhaps I missed something obvious, do you really mean 24x7x365 instead of 24x7x7? Groete / Greetings Or maybe 24x7x52? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
This is the sort of pedantry up with which I will not put. - Winston Churchill . Sorry ... Is it Friday/Thursday yet ? Vernooij, CP - SPLXM kees.vern...@klm.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 30/03/2010 11:05 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: Mainframe Executive article on the death of tape Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote in message news:listserv%201003300400254643.0...@bama.ua.edu... Ed Gould wrote: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. Sorry Ed, but perhaps I missed something obvious, do you really mean 24x7x365 instead of 24x7x7? Groete / Greetings Or maybe 24x7x52? Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer: http://www.euroclear.com/site/public/disclaimer
Re: Mainframe Executive article on the death of tape
Vernooij, CP wrote: Sorry Ed, but perhaps I missed something obvious, do you really mean 24x7x365 instead of 24x7x7? Groete / Greetings Or maybe 24x7x52? Groan, I've indeed missed something obvious, something is loose between my ears somewhere in my decaying brain. If I could remember what was loose in the first place... :-D Thanks for your correction. Please continue your excellent posts here... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Elardus Engelbrecht pisze: Ed Gould wrote: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. Sorry Ed, but perhaps I missed something obvious, do you really mean 24x7x365 instead of 24x7x7? To be accurate: 24x7x365 is widely used, but it does not make more sense. It could mean 7 years, while it is understood as an abbreviation of 24 hours a day, 7 days a week, 365 days a year. Multiplication sign (x) is misleading here. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ed, Just to clarify, the place you were at with a DR scenario was to go offsite to an obsolete system was a company that you left 12-15 years ago. At the time, the site was either running MVS/XA with a 3090-200 at the main location and a 4381-Q13 at the offsite location, or running MVS/ESA with 3090-x00E's at both sites. I know because I worked there before you, and still are in touch with people that currently work there. Today they use a third party disaster recovery system, and have for at least 8-10 years. Wayne Driscoll -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Monday, March 29, 2010 11:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Ted: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. I was at one place and their DR scenario was to go offsite to an obsolete system that was 10 years old when it was started. They sit there at board meetings and with a straight face say they have DR working perfectly. Chuckle chuckle The system they want to IPL won't because they refuse to believe you cannot just IPL any old version of MVS. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
ps2...@yahoo.com (Ed Gould) writes: Rick: I do not remember the maker (this was probably 30 years ago) we had a Solid state device and we used it for two things. One was PLPA and the other was for a high activity dataset that an application needed. We fought with the application people for several years to redesign it. We finally convinced them (after a *LOT* of political cr*p) to use VIO. That small change decreased run time from 4+ hours to less than 1 hour. We also had issue with it when ever there was a power glitch it took a double IPL (delete/define the PLPA). Management finally said the change over to VIO was all that was needed and they kicked the vendor out. When it worked it worked fine when it didn't it crippled the system. late 70s, early 80s ... internally there was a lot of 1655 from a vendor ... used for paging at large number of internal vm370 sites. they could be configured as 2305 fixed-head disk emulation or as native (if you wrote the support). the vendor was maker of dram chips ... and the story was that the chips used in 1655 had failed processor memory acceptance tests. the characteristic of block i/o to/from 1655 allowed the i/o controller to compensate for some number of operational characteristics that wouldn't have been acceptable in processor memory. at that time ... i had also wanted to add separate exposure to the 3350 fixed-head feature (so i could do transfer from fixed head area overlapped with 3350 disk arm motion) ... I got shutdown by POK JUPITER effort that was planning on doing something similar to 1655 (JUPITER thot they were going after the paging device market and decided my alternate exposure for 3350 fixed-head feature would impact their sales). JUPITER then found out that the corporation didn't have any spare memory chips for use in emulated i/o device (especially when price as processor memory was much higher than could be gotten for emulated paging device). Eventually JUPITER effort threw in the towel ... but not before shutting me down for ever doing alternate exposure for 3350 fixed-head feature. Eventually there was Ironwood/Sheriff (3880-11 3880-13); 8mbyte disk controller cache ... Ironwood was 4k byte record cache ... and Sheriff was full-track cache. Some of this changed with 3090 and extended store ... but until then ... lots of systems were becoming more more real storage constrained (especially MVS systems) and 370 had trouble supporting more than 16mbyte real storage (except for the hack introduced for 3033 that fiddled two bits in the page table entry to get 26-bit real storage addressing). some past posts mentioning the 370 16mbyte hack http://www.garlic.com/~lynn/93.html#14 S/360 addressing http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure) http://www.garlic.com/~lynn/2002c.html#40 using =4GB of memory on a 32-bit processor http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing? http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi http://www.garlic.com/~lynn/2004.html#0 comp.arch classic: the 10-bit byte http://www.garlic.com/~lynn/2004.html#17 Holee shit! 30 years ago! http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone http://www.garlic.com/~lynn/2004n.html#50 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory? http://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design http://www.garlic.com/~lynn/2005p.html#19 address space http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?) http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series http://www.garlic.com/~lynn/2007o.html#56 360/30 memory http://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical http://www.garlic.com/~lynn/2010.html#84 locate mode, was Happy DEC-10 Day -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Edward Jaffe wrote: Our small shop does daily backups and weekly dumps using both HSM and Tivoli Storage Manager on z/OS. We use 3590 tape technology (triple-density H drives with double-long K [green stripe] tapes). Our tape inventory is currently 182 tapes in RMM. Failure is *extremely* rare. Gut feel is once every couple/few years we experience a tape media failure. Incredible! This popped out about five minutes ago. Haven't seen one of these in years. I think this thread jinxed us... |IOS000I 1503,13,IOE,01,0600,,**,B00150,DFHSM70 589 | 0A4414D050405050 0001FF00 0303023530335490 4B042300B18B1315 | WRITE ERROR DETECTED -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Wonder if Murphy is a subscriber? In a message dated 3/30/2010 12:07:33 P.M. Central Daylight Time, edja...@phoenixsoftware.com writes: Incredible! This popped out about five minutes ago. Haven't seen one of these in years. I think this thread jinxed us... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Been a LOONG time since I heard of Firesign Theater. Still have two of their albums. Point taken but I was paid very well for 23 years to be very skeptical of ALL hardware vendors' claims. Twice, that skepticism paid off. :-) Rick -- Scott Rowe wrote: Rick, Today's SSD is not like the ones we ran a decade ago. The SSD of today is made with Flash memory, like in the thumb drive you plug into you PC's USB port. They don't need power to retain data. Forgive the Firesign reference, but, Everything you know is wrong :-) Rick Fochtman rfocht...@ync.net 03/29/10 7:23 PM -snip--- A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. There are some shops, in the Greater Toronto Area, using them in production. --unsnip-- I was once in a shop that used them in production as well. As LOCAL page devices. The level of trust just wasn't there to allow any other usage. snip-- Also, power surges and vagaries in supply voltage and/or current levels are less likely to affect a hard drive, even though the cirtuitry to avoid these vagaries is becoming more and more prevalent today. UPS and power conditioning come to mind. Who powers their data centre straight from the grid, these days? ---unsnip- I thinkk you'll find a significant, though maybe not large, number of shops running straight from the grid today. For those shops, the cost of an outage may be lower than the cost of power conditioning and/or UPS equipment. Let's face it, not all business decisions make good sense, in spite of what we'd all like to think. -snip-- Can we all remember the STC Solid State Disk? And manufacturing vagaries can still have severe and detrimental effects on solid-state memory, whereas the manufacture of magnetic disks is fairly well solidified today, except for incremental changes that affect capacity. Then stop using Cache and CPU memory. It's the same chipsets, in most cases. unsnip The chip design may be the same, but are the manufacturing facilities up to the same quality control standards? More and more makers doesn't always mean equal quality across the board. The the firm of Dewey Cheatem How have the same standards as, for example, INTEL? To survive, the prices have to be competitive and so does the quality. And how many managerial-types will look at a lower price and make their decisions based entirely on price? Every business has its share of airheads and IT is certainly no exception. -snip- I predict that magnetic disk technology will bbe with us for the foreseeable future. No more than two or three mainframes will ever be sold. Nobody will ever need more than 640K of memory. -unsnip-- Yeah, we've all heard those predictions and seen just how incredibly wrong they were. I might be just as wrong. Only time will tell. :-) --snip- Too busy driving to stop for gas! --unsnip- You've been saying that for as long as I can remember. Eat lots of beans and you don't need to stop for gas! :-)) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
Re: Mainframe Executive article on the death of tape
--snip- I think we would all be appalled and scared crap-less (to put it nicely) if we all really knew the true state of BCP's at many companies. There should be more customer involvement in DR; built into the contracts. IOW, review of required test results, etc., if the customer so chooses; at a minimum, so that they can tell that a test was done! Rigid accountability to those that make the company viable is the only way towards improvement here. --unsnip-- Complete agreement, Scott. But far too many IT Executives are interested only in the bottom line. DR planning and testing are an insurance policy that is all too often viewed as an unnecessary expense. During the Chicago Flood of 1992, we discovered a number of holes in our disaster recovery procedures, but our provider was able to supply the necessary expertise and equipment to plug those holes. Consequently, we were able to recover our (admittedly small) shop in just over 5 hours, at least to the point where our basic business functions could proceed. Then we hit issues like how to distribute printed reports, and how to print them in a timely fashion. That's when we learned about channel extension, power supply and distribution at alternate sites. All in all, a very powerful learning experience. Another shop that I know of never did get running at the DR site; quite a few heads were rolled after that little fiasco, and they were high-level heads! :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Rick Fochtman writes: A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. Also, power surges and vagaries in supply voltage and/or current levels are less likely to affect a hard drive, even though the cirtuitry to avoid these vagaries is becoming more and more prevalent today. You may be thinking of traditional RAM parts of one kind or another, such as battery-backed DRAM. I was referring to flash memories, which are at least as nonvolatile as hard disks. (I'd feel more comfortable powering off an enterprise-grade flash memory array for, say, 10 years and then trying to read it versus its rotating counterpart.) Hard disks consume a lot more power (with associated hazards and environmental consequences) than flash or tape. Hard disks are (also) sensitive to external magnetic disturbances. Hard disks are more sensitive to kinetic shocks (e.g. cabinets falling over, data center floors collapsing) and temperature extremes (e.g. data center fires). It's a little hard to tell, but it looks to me like flash is now more physical space-efficient. Flash memory is presently significantly more expensive to acquire than hard disks, per gigabyte. (I think it's very roughly 20 to 1 right now.) The gap is closing. For what it's worth, my employer got out of the hard disk spindle business in 2003. But Hitachi now reports profits on its consolidated hard disk business. Margins are down, but volumes are way up. Hard disks are very, very popular. I think my question is more interesting than hard disk v. tape. (Tape has a cost advantage but is also addressing much different storage requirements.) But I don't know the answer to my question yet. The gap has already closed sufficiently for devices like the iPod. (All but a very few iPods rely on flash memory now, it's only a matter of time before the last holdout model disappears.) Laptops/notebooks seem to be switching over to flash at this point in time. (Witness the iPad and the SSD MacBook Air.) SSDs are certainly finding their place now in enterprise storage, but for almost everyone they're not yet a complete replacement for hard disks. Will SSDs ever completely replace hard disks? We'll see. - - - - - Timothy Sipples Resident Architect STG Value Creation and Complex Deals IBM Growth Markets E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Joel C. Ewing pisze: I finally got around to reading the actual Mainframe Executive article in question. The Publisher's Notes at the beginning of the issue repeats the article's quoted statistics in a manner that implies they relate to mainframe tape, and that fact the Mainframe is in the magazine title implies the article is relevant to mainframes; but if you read the actual article itself, whenever the author gets specific about problems in use of tape, (interleaved records from multiple data streams, managing physical tapes, Microsoft Exchange issues, etc., etc., etc.), it becomes increasingly clear he is not talking about IBM mainframes and and z-architecture, but primarily about Microsoft platforms and maybe some 'nix platforms. No doubt the referenced statistics sources make clear they are about Microsoft platforms, but the author and publisher both neglected to communicate this, which makes it very misleading for a mainframe magazine. This is neither excuse nor explanation. Microsoft or UNIX does not imply poor tape technology. I can assure your that LTO4 has significantly lower error ratio than presented in article, and - last but not least - almost every mainframe tape can be attached to open system. That inlcude Jaguar (3592), MAGSTAR (3590), 3490E, STK T1, 9940, 9840 families. Tape reliability does not depend on the platform using it. The only thrue sentence is: All the mainframe tapes are good and reliable. You cannot attach any poor tape technlogy to the mainframe *directly*. Fine print: you do it indirectly if you really want. BTW: Presented error stats are overstated even for non-mainframe tapes. LTO is much better, (S)DLT is much better, AIT family is much better, DAT family is horrible, but IMHO still better, Tandberg family (SLR, MLR) is much better, Exabyte was better, QIC is dead for years (born 1972, died 1998). I don't know SONY DTF, DIR, SAIT, so cannot comment it, but I doubt if someone would buy so expensive devices to get so poor quality. No comments on TRAVAN, DITTO, VXA, MAGSTAR MP. What technology was mentioned by author of the article? Where did he find so erroneous devices? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
In of54f37709.110ca5bf-on482576f5.00045a41-482576f5.00047...@us.ibm.com, on 03/29/2010 at 08:49 AM, Timothy Sipples timothy.sipp...@us.ibm.com said: Perhaps a more interesting question is whether hard disks are dead, felled (or soon to be) by solid state storage. :-) FSVO soon. I'm reminded of the conventional wisdom that thin film would replace core. It turned out that it was easier to improve core technology, so that semiconductor memory killed of thin film at a time when core was still going strong. My take is that solid state memory will eventually replace disks, but that the disk manufacturers will continue pushing the technology to higher densities and lower prices for at least a few more years. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 28 Mar 2010 21:00:24 -0700, tlk_sysp...@yahoo.com (Thomas Kern) wrote: I think it will be quite a while before all hard disks are gone, but it is inevitable. When my phone has a 16GB memory card in it and a slot for another 16GB, you have to accept that solid state storage is not far off. This has been just around the corner for decades now. I remember Jerry Pournelle discussing it in Byte.It's getting closer. We can buy choose to not buy disks in iPods and some laptops. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
-snip--- A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. There are some shops, in the Greater Toronto Area, using them in production. --unsnip-- I was once in a shop that used them in production as well. As LOCAL page devices. The level of trust just wasn't there to allow any other usage. snip-- Also, power surges and vagaries in supply voltage and/or current levels are less likely to affect a hard drive, even though the cirtuitry to avoid these vagaries is becoming more and more prevalent today. UPS and power conditioning come to mind. Who powers their data centre straight from the grid, these days? ---unsnip- I thinkk you'll find a significant, though maybe not large, number of shops running straight from the grid today. For those shops, the cost of an outage may be lower than the cost of power conditioning and/or UPS equipment. Let's face it, not all business decisions make good sense, in spite of what we'd all like to think. -snip-- Can we all remember the STC Solid State Disk? And manufacturing vagaries can still have severe and detrimental effects on solid-state memory, whereas the manufacture of magnetic disks is fairly well solidified today, except for incremental changes that affect capacity. Then stop using Cache and CPU memory. It's the same chipsets, in most cases. unsnip The chip design may be the same, but are the manufacturing facilities up to the same quality control standards? More and more makers doesn't always mean equal quality across the board. The the firm of Dewey Cheatem How have the same standards as, for example, INTEL? To survive, the prices have to be competitive and so does the quality. And how many managerial-types will look at a lower price and make their decisions based entirely on price? Every business has its share of airheads and IT is certainly no exception. -snip- I predict that magnetic disk technology will bbe with us for the foreseeable future. No more than two or three mainframes will ever be sold. Nobody will ever need more than 640K of memory. -unsnip-- Yeah, we've all heard those predictions and seen just how incredibly wrong they were. I might be just as wrong. Only time will tell. :-) --snip- Too busy driving to stop for gas! --unsnip- You've been saying that for as long as I can remember. Eat lots of beans and you don't need to stop for gas! :-)) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Will SSDs ever completely replace hard disks? We'll see. snip I'm missing a whole lot of experience with regards to the changes with SSD in the data center over the last 10+ years. Perhaps someone can fill me in a bit? I remember a SSD unit in a data center I worked in around 1990-92 (not sure, really. We still had a 3084 in production, so that should frame it somewhat). They had very performance-critical data sets on it... important system software checkpoint data sets, etc. It worked fine, until issues with the UPS caused extended power outages; and that happened quite a bit. What has changed in SSD (longer battery life?) or UPS systems (something to make them more reliable?) that would ever get us to the point of hard disks going away? If there is even the smallest chance of the batteries crapping out on the SSD's, it would be way too risky, no? Thanks! Scott T. Harder Mainframe Services, Inc. Naples, FL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
The chip design may be the same, but are the manufacturing facilities up to the same quality control standards? More and more makers doesn't always mean equal quality across the board. There aren't that many chip makers for cache, memory and solid state disk. At the mainframe level, I believe there's only one. And, the quality far surpasses the STK of 1984! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I thinkk you'll find a significant, though maybe not large, number of shops running straight from the grid today. For those shops, the cost of an outage may be lower than the cost of power conditioning and/or UPS equipment. Wow! I haven't worked at a shop without conditioning and UPS since the early 1980's. And, GTA power was pretty noisy back then. So, nobody ran raw, that I know of. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Rick, Today's SSD is not like the ones we ran a decade ago. The SSD of today is made with Flash memory, like in the thumb drive you plug into you PC's USB port. They don't need power to retain data. Forgive the Firesign reference, but, Everything you know is wrong :-) Rick Fochtman rfocht...@ync.net 03/29/10 7:23 PM -snip--- A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. There are some shops, in the Greater Toronto Area, using them in production. --unsnip-- I was once in a shop that used them in production as well. As LOCAL page devices. The level of trust just wasn't there to allow any other usage. snip-- Also, power surges and vagaries in supply voltage and/or current levels are less likely to affect a hard drive, even though the cirtuitry to avoid these vagaries is becoming more and more prevalent today. UPS and power conditioning come to mind. Who powers their data centre straight from the grid, these days? ---unsnip- I thinkk you'll find a significant, though maybe not large, number of shops running straight from the grid today. For those shops, the cost of an outage may be lower than the cost of power conditioning and/or UPS equipment. Let's face it, not all business decisions make good sense, in spite of what we'd all like to think. -snip-- Can we all remember the STC Solid State Disk? And manufacturing vagaries can still have severe and detrimental effects on solid-state memory, whereas the manufacture of magnetic disks is fairly well solidified today, except for incremental changes that affect capacity. Then stop using Cache and CPU memory. It's the same chipsets, in most cases. unsnip The chip design may be the same, but are the manufacturing facilities up to the same quality control standards? More and more makers doesn't always mean equal quality across the board. The the firm of Dewey Cheatem How have the same standards as, for example, INTEL? To survive, the prices have to be competitive and so does the quality. And how many managerial-types will look at a lower price and make their decisions based entirely on price? Every business has its share of airheads and IT is certainly no exception. -snip- I predict that magnetic disk technology will bbe with us for the foreseeable future. No more than two or three mainframes will ever be sold. Nobody will ever need more than 640K of memory. -unsnip-- Yeah, we've all heard those predictions and seen just how incredibly wrong they were. I might be just as wrong. Only time will tell. :-) --snip- Too busy driving to stop for gas! --unsnip- You've been saying that for as long as I can remember. Eat lots of beans and you don't need to stop for gas! :-)) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
From: Ted MacNEIL eamacn...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Mon, March 29, 2010 8:35:23 PM Subject: Re: Mainframe Executive article on the death of tape I thinkk you'll find a significant, though maybe not large, number of shops running straight from the grid today. For those shops, the cost of an outage may be lower than the cost of power conditioning and/or UPS equipment. Wow! I haven't worked at a shop without conditioning and UPS since the early 1980's. And, GTA power was pretty noisy back then. So, nobody ran raw, that I know of. Ted: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. I was at one place and their DR scenario was to go offsite to an obsolete system that was 10 years old when it was started. They sit there at board meetings and with a straight face say they have DR working perfectly. Chuckle chuckle The system they want to IPL won't because they refuse to believe you cannot just IPL any old version of MVS. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
snip--- A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. There are some shops, in the Greater Toronto Area, using them in production. --unsnip-- I was once in a shop that used them in production as well. As LOCAL page devices. The level of trust just wasn't there to allow any other usage. snip-- Rick: I do not remember the maker (this was probably 30 years ago) we had a Solid state device and we used it for two things. One was PLPA and the other was for a high activity dataset that an application needed. We fought with the application people for several years to redesign it. We finally convinced them (after a *LOT* of political cr*p) to use VIO. That small change decreased run time from 4+ hours to less than 1 hour. We also had issue with it when ever there was a power glitch it took a double IPL (delete/define the PLPA). Management finally said the change over to VIO was all that was needed and they kicked the vendor out. When it worked it worked fine when it didn't it crippled the system. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ed, Agreed... I think we would all be appalled and scared crap-less (to put it nicely) if we all really knew the true state of BCP's at many companies. There should be more customer involvement in DR; built into the contracts. IOW, review of required test results, etc., if the customer so chooses; at a minimum, so that they can tell that a test was done! Rigid accountability to those that make the company viable is the only way towards improvement here. Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Gould Sent: Tuesday, March 30, 2010 12:21 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape From: Ted MacNEIL eamacn...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Mon, March 29, 2010 8:35:23 PM Subject: Re: Mainframe Executive article on the death of tape I thinkk you'll find a significant, though maybe not large, number of shops running straight from the grid today. For those shops, the cost of an outage may be lower than the cost of power conditioning and/or UPS equipment. Wow! I haven't worked at a shop without conditioning and UPS since the early 1980's. And, GTA power was pretty noisy back then. So, nobody ran raw, that I know of. Ted: But there are more than a few out there that do not. I shudder at such places. Some places have 24 X 7 X 7 requirements and they still do not have it. I was at one place and their DR scenario was to go offsite to an obsolete system that was 10 years old when it was started. They sit there at board meetings and with a straight face say they have DR working perfectly. Chuckle chuckle The system they want to IPL won't because they refuse to believe you cannot just IPL any old version of MVS. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ted, I don't agree that this is conventional wisdom for SSD. The target datasets for SSD are (a) very low read cache hit percentage, (b) very high sibling pend delays, or (c) a net D2C and C2D IO demand that exceeds the capabiltiy of disk drives a used capacity ratio around 10% (depends on what you pay for disk and SSD). I would suggest that only part of many high profile databases meet that criteria. I think the 80/20 or 90/10 ROT are still alive and kicking. Ron From: Ted MacNEIL eamacn...@yahoo.ca To: IBM-MAIN@bama.ua.edu Sent: Mon, March 29, 2010 3:06:19 PM Subject: Re: [IBM-MAIN] Mainframe Executive article on the death of tape You have a very high profile database, get a solid-state storage system to put the data on. I know that is the conventional wisdom. Lower priority stuff gets to stay on the old hard round/brown disks. I saw a presentation, at CMG Canada last month, where the presenter showed the benefits, of putting something not so loved on SSD, and everybody won because it was moved out of the way. Commercial grade SSD is an order of magnitude more expensive than the stuff you find in cell phones and digital cameras. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Perhaps a more interesting question is whether hard disks are dead, felled (or soon to be) by solid state storage. :-) - - - - - Timothy Sipples Resident Architect STG Value Creation and Complex Deals IBM Growth Markets E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
---snip Perhaps a more interesting question is whether hard disks are dead, felled (or soon to be) by solid state storage. :-) --unsnip- I respectfully submit that solid state storage will not replace hard disks in the foreseeable future. A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. Also, power surges and vagaries in supply voltage and/or current levels are less likely to affect a hard drive, even though the cirtuitry to avoid these vagaries is becoming more and more prevalent today. Can we all remember the STC Solid State Disk? And manufacturing vagaries can still have severe and detrimental effects on solid-state memory, whereas the manufacture of magnetic disks is fairly well solidified today, except for incremental changes that affect capacity. I predict that magnetic disk technology will bbe with us for the foreseeable future. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Perhaps a more interesting question is whether hard disks are dead, felled (or soon to be) by solid state storage. :-) Not that soon. We need to see the price/GB fall a bit, to as lww as DASD was 5 or 6 years ago. Moore's law will help, and (fortunately) he over-stated the timeframe by about 4 or 5 months. But, it will happen. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
A long absence of power to affect refreshes of solid state storage can still render solid state storage unusable, while true disks don't need refreshing to maintain the content. There are some shops, in the Greater Toronto Area, using them in production. Also, power surges and vagaries in supply voltage and/or current levels are less likely to affect a hard drive, even though the cirtuitry to avoid these vagaries is becoming more and more prevalent today. UPS and power conditioning come to mind. Who powers their data centre straight from the grid, these days? Can we all remember the STC Solid State Disk? And manufacturing vagaries can still have severe and detrimental effects on solid-state memory, whereas the manufacture of magnetic disks is fairly well solidified today, except for incremental changes that affect capacity. Then stop using Cache and CPU memory. It's the same chipsets, in most cases. I predict that magnetic disk technology will bbe with us for the foreseeable future. No more than two or three mainframes will ever be sold. Nobody will ever need more than 640K of memory. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I think it will be quite a while before all hard disks are gone, but it is inevitable. When my phone has a 16GB memory card in it and a slot for another 16GB, you have to accept that solid state storage is not far off. I do see a migration from hard to solid-state, must the way we migrated from strings of real 3380/3390s to the emulated disk subsystems. Put stuff on different technologies based on performance until the high performance stuff is cheap enough to have all through the data center. You have a very high profile database, get a solid-state storage system to put the data on. Lower priority stuff gets to stay on the old hard round/brown disks. This migration will be faster than moving from real 3380/3390 disks to emulated disk subsystems. /Tom Kern Timothy Sipples wrote: Perhaps a more interesting question is whether hard disks are dead, felled (or soon to be) by solid state storage. :-) - - - - - Timothy Sipples Resident Architect STG Value Creation and Complex Deals IBM Growth Markets E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
You have a very high profile database, get a solid-state storage system to put the data on. I know that is the conventional wisdom. Lower priority stuff gets to stay on the old hard round/brown disks. I saw a presentation, at CMG Canada last month, where the presenter showed the benefits, of putting something not so loved on SSD, and everybody won because it was moved out of the way. Commercial grade SSD is an order of magnitude more expensive than the stuff you find in cell phones and digital cameras. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I finally got around to reading the actual Mainframe Executive article
in question. The Publisher's Notes at the beginning of the issue
repeats the article's quoted statistics in a manner that implies they
relate to mainframe tape, and that fact the Mainframe is in the
magazine title implies the article is relevant to mainframes; but if you
read the actual article itself, whenever the author gets specific about
problems in use of tape, (interleaved records from multiple data
streams, managing physical tapes, Microsoft Exchange issues, etc., etc.,
etc.), it becomes increasingly clear he is not talking about IBM
mainframes and and z-architecture, but primarily about Microsoft
platforms and maybe some 'nix platforms.
No doubt the referenced statistics sources make clear they are about
Microsoft platforms, but the author and publisher both neglected to
communicate this, which makes it very misleading for a mainframe magazine.
Sent an Email to editor pointing out the error of their ways. The
article has some relevancy to non mainframe server farms used in
Enterprise computing, but the fact that the author generalized to all
tape usage without realizing that most of his specific arguments against
tape usage are invalid in IBM mainframe, z/OS environments makes me
suspect that any mainframe experience of the author is very limited.
JC Ewing
On 03/24/2010 05:40 PM, Ted MacNEIL wrote:
He cites Gartner and Storage Magazine as the sources for his statistics.
Both credible sources, especially the former. (8-{]}
-
Too busy driving to stop for gas!
--
Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
From: Scott T. Harder scott.har...@embarqmail.com All I know is that many of the replies to the OP were in the no errors at all... what are you talking about? camp, and my memory as an MCO in a growth shop from 1987-1994 (about... until I finally made it to Technical Services and Storage Management for 10 months, before moving to system automation support until my resignation from this large telco in mid-1997) was that we did, indeed, receive DCK errors on 3480 media more times than I would like to have seen happen. Of course, some errors were due to hardware problems, but we definitely had our share of true data check (media) errors. Subsequent posts indicate the cause to be some sort of manufacturing issue with BASF tapes (that I *know* we used); as well as Imation tapes (that I *know* we used). So, I can only attribute our particular issues at the time to those problems (not knowing any better, really). My memory is not wonderful, but I do remember these occurrences. I really just wanted to convey my experience, which seemed to be so contrary to what most other posters to the thread were saying. Hi Scott, seeing as that your experience is different than 1% failure rate reported most posters, I am interested in an estimate of what kinds of error rates you saw. Were you seeing the 15-50% referenced in the article? Or rather just something in excess of the 1% being reported? I definitely saw many media errors, but in the scheme of the tens of thousands of tapes being passed, it was certainly below 1%. Of course that didn't help much when you took a tape error in the middle of a hundred reel file, and had to explain to the programmer once again the importance of making their two day jobs restartable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Right... This is why I said that I did not do a good job of staying on point as far as the original post. Those numbers in the failure rates reported were *multitudes* higher than anything I have ever seen or heard of. Again, I only chimed in because of the subsequent posts that made it sound like DCK errors went away with the advent of the 3480. All the best, Scott Scott T. Harder Mainframe Services, Inc. Naples, FL snip Hi Scott, seeing as that your experience is different than 1% failure rate reported most posters, I am interested in an estimate of what kinds of error rates you saw. Were you seeing the 15-50% referenced in the article? Or rather just something in excess of the 1% being reported? I definitely saw many media errors, but in the scheme of the tens of thousands of tapes being passed, it was certainly below 1%. Of course that didn't help much when you took a tape error in the middle of a hundred reel file, and had to explain to the programmer once again the importance of making their two day jobs restartable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 03/23/2010 05:29 PM, Pinnacle wrote: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley I can only conclude the author is totally ignorant of mainframe 3490, 3590, or later tape technology. Old reel-to-reel technology was getting very marginal when we finally got rid of our last drives - partly because you couldn't get any new media. We once had problems with 3480 cart reliability because we inherited some media from another company that hadn't properly maintained their library and the bad media constantly contaminated the drive heads. Once we realized what was happening and got rid of the bad carts, reliability went back to the usual 1% failures. We back up over 300 DASD volumes to 24 3590 carts every night, have never had an undetected write problem, and those at worst are one or two files of the 9,000+ created by this process during the month, and are corrected on the spot by restarting the job to new media for subsequent files. We have never had a problem reading one of those backups. Because of the large amount of data on one 3590, we do duplex much of the archival stuff on 3590s, because there is always the chance of accidental physical damage to a cart by either an Operator or a berserk tape drive. We rebuild a damaged 3590 cart maybe once every 6 months. -- Joel C. Ewing, Fort Smith, ARjremoveccapsew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
In IBM parlance, MTTR is Mean Time to Recovery. It wasn't in 1981, when I had the 'privilege' of doing availability reporting. The terminology has changed a bit since then; I don't have to worry about/do it anymore. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Hal Merritt pisze: No assumptions. This is all experience/observations from several iterations of DR plans and differing management objectives. Yes, assumptions. You observed several DR plans and made assumptions. I would call the plans old in terms of technology. PTAM is for dinos, data transfer to remote site rules. PTAM means day(s) of RPO and many hours of RTO (terms explained earlier). Remote data transfer could mean 0 to seconds of RPO and few hours to minutes of RTO. In fact you try to compare 20-years old Ford F to new Chevrolet Corvette. In many (most?) tape solutions (to include ATL), tapes are physically ejected, manually boxed, manually transported (via PTAM), manually stored, manually retrieved, manually received and inventoried, and manually reloaded into the ATL. That's a lot of human interventions. In every project I had to do tapes are NOT physically moved. Remote ATL is in use. That means you have one copy in local ATL and second copy in remote ATL. Data is sent over the cable. The same cable as with PPRC. FICON. The ATL in the DR center is not capable of mounting a tape from a shipping box. A human has to load the tapes into the ATL. Bad assumption, as explained above. True, an ATL in the DR center could be used as offsite backup. And that reduces the MTR somewhat by eliminating the PTAM step in the recovery script. But you still have to get the tape to the DR site. Since our subspace transporter is on backorder, we have to transport tapes by truck. Your point contrasting backup and replication is well taken. However, in a DR context, a 'backup' is just as critical as primary data and should be replicated. You are also correct in that I may not have used the acronyms correctly. But you got the ideas. I should also point out a new idea: networked VTS. The IBM TS7740 (and I'm sure some others) has the ability to be networked with other TS7740's to automatically replicate virtual tapes. Unlike the DASD XRC/PPRC solutions, the network pipe can be sized on average loads and be a bit smaller (less expensive). You should also point older VTS replication (Peer-to-Peer VTS), STK/Sun/Oracle VSM replication and last but not least: software managed replication on any tape drive including real tapes. Oh, I should mention solutions like Luminex or BusTech or InterKom - IMHO suitable for smaller shops, but do provide some remote replication possibilities under the cover. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ted MacNEIL pisze: MTR usually means time to REPAIR MTTR means Mean Time To Repair. MTR means Mean Time to recover. Why? Why do you exclude 'to' in one case and include it in another? I don't want to start 'USS war', however both terms could give the same acronym. ;-) I'd suggest http://en.wikipedia.org/wiki/MTTR (for lazy ones: *both* terms are under MTTR) I started in this business with the added responsibilty of track availability and assigning root causes (the 'advantage' of being the junior). The other common expression used to be MTBF - Mean Time Between Failures. Now, almost 30 years later, they've changed it to MTTF - Mean Time To Fail. I noticed that MTBF is becoming less popular, while AFR is being used. AFR mean Annual Failure Rate. How many drives (others) will fail during the year. I've also seen very interesting graphs presenting AFR during the time (for disk drives). Disclaimer: just my limited observation. YMMV. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Thanks! I was beginning to worry I was the only one that still occassionally gets woken up in the night for a tape error. Tapes wear out, heads get dirty, writes fail. These days the error is almost always caught on the write, but I did have a 3590 refuse to read a tape a few months ago. First one that I can remember in a long, long time though. Scott Chapman sy...@hotmail.com wrote: I had a tape error just last week. Tapes and drives are about 5 years old. 10079 08:52:11.45 STC06292 0080 IOS000I 0121,2C,IOE,01,0600,,**,A00298,EXHPDM 504 504 0080 0A4410D050405050 0001FF00 030C003117335490 4B04E8205C5B2011 504 0080 WRITE ERROR DETECTED Cliff McNeill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Scott Chapman pisze: Thanks! I was beginning to worry I was the only one that still occassionally gets woken up in the night for a tape error. Tapes wear out, heads get dirty, writes fail. These days the error is almost always caught on the write, but I did have a 3590 refuse to read a tape a few months ago. First one that I can remember in a long, long time though. Scott Chapman I would like to remind that none of responders said there are no tape errors. We say that error ratio is much lower than presented in origin of the thread. 1% does not mean 0. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
MTTR means Mean Time To Repair. MTR means Mean Time to recover. Why? Why do you exclude 'to' in one case and include it in another? Don't ask me! That's what I was taught, 30 years ago. I realise that the terminology has changed, but since I no longer do availability reporting, to me it doesn't matter. And, the last (of many) DR excercises I did (of many), the doc was all MTR. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ron, You are putting words in my mouth. I never said that writing a given file to tape would use less bandwidth than writing that file to disk. Looking back I realize I did not word it vary well, but my original point was that a DR solution using remote tape can be done with less bandwidth than using sync/async disk replication, and without the human cost that Hal was insisting. The only problem I raised with your statement was that you thought there was no remote tape in use, which is incorrect. Ron Hawkins ron.hawkins1...@sbcglobal.net 3/24/2010 10:18 PM Scott, OK, so in this context you mean tape drives connected by FICON channel Extenders. In that case I disagree with your point in that paragraph. It is incorrect to say that Remote Tape normally has lower bandwidth costs than remote disk. Writing the same file to remote tape or remote disk will use the same bandwidth. Do you have some information that says otherwise? Whether we compare remote tape and disk, or replicated tape and disk the bandwidth required is the same for duplication of the same data. For MTTR comparing Remote Disk and tape, one advantage of Remote Disk is that there are strategies where there is no need to restore. The backup datasets are in native DSORG and your applications just allocate them and go. There is no restore time. For strategies that use DFDSS or similar files that require a restore, we are talking about Disk Subsystems that can read in excess of 9.5GB/sec or 370K IOPS on FICON, depending on your blocksize and configuration - and not with virtualized SATA Disks. With HyperPAV allowing a high level of parallelism on Disk I'm just not sure that tape subsystems are in the same performance league as disk given that real or emulated tape IO is single threaded, the disk arrays front-ending virtual tape are usually not high end specs, and there will some amount of data that encounters staging delays in some Virtual Tape systems. (I still have nightmares about the original IBM ATL replication performance, but I'm sure it has improved). I'll agree that MTTR from Remote Disk or Tape may not be valuable to some sites, YMMV, but Remote Disk strategies can have a significantly better MTTR than Remote or Replicated Tape, but not as good as replicated disk. This faster MTTR may be valuable to some sites. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Wednesday, March 24, 2010 2:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Mainframe Executive article on the death of tape I don't know why you used replication in there, but there is quite definitely remote tape in use. Ron Hawkins ron.hawkins1...@sbcglobal.net 3/24/2010 5:24 PM Scott, Actually these implementations are remote disk, with some HSM in a can that may or may not age-out the data to tape at a later time. I don't think there is any true Remote Tape replication in the z/OS marketplace. YMMV, but there are shops that are finding a better TCO using commodity priced rack and stack systems to do this, either through appliances, virtualized DASD, or both. Radoslaw was talking about remote tape. Some sites have a remote tape library that they can backup into, this eliminates almost all tape handling, and normally has lower bandwidth costs than remote disk. Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY
Re: Mainframe Executive article on the death of tape
but my original point was that a DR solution using remote tape can be done with less bandwidth than using sync/async disk replication A point which I disagree with. You must completely replicate the newly written volume at the backup site, after writing.n before the next logical dismount and mount can happen. While a logical mount is in milliseconds, this synchronous replication is not. If you're stingy on the bandwidth you can back up your back ups. If you're going to do it, do it right. Anything less will be a nightmare. BTDT. GTTS. DLI. DWTDIA! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ted, I'm not talking about VTS replication. Ted MacNEIL eamacn...@yahoo.ca 3/25/2010 9:48 AM but my original point was that a DR solution using remote tape can be done with less bandwidth than using sync/async disk replication A point which I disagree with. You must completely replicate the newly written volume at the backup site, after writing.n before the next logical dismount and mount can happen. While a logical mount is in milliseconds, this synchronous replication is not. If you're stingy on the bandwidth you can back up your back ups. If you're going to do it, do it right. Anything less will be a nightmare. BTDT. GTTS. DLI. DWTDIA! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I'm not talking about VTS replication. Then what are you talking about? Not to be snarky, but on one hand you talk about all the problems, and on the other when something's brought up, you immediately shoot it down. My point, all along, is do it right or don't do it at all. This thread has so many statements, re-statements, and retractions, that I have lost track. I thought the issue was tape handling, which is gone with VTS, and completely gone with replication. But, I don't believe your form of 'remote tape' is very viable for the true insurance policy of a proper DR process. I'm not trying to be argumentative -- just trying to understand your point. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
In 351fdc6ace57d14b94beb5529e85df8e9112d0e...@exchmail1.courts.wa.gov, on 03/24/2010 at 08:25 AM, Longnecker, Dennis dennis.longnec...@courts.wa.gov said: Maybe he was referring to paper tape? Nah, Mylar. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
In e026a9d62f2a482887df291738a7c...@scotttharderpc, on 03/24/2010 at 07:07 AM, Scott T. Harder scott.har...@embarqmail.com said: I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. How many is many? Even with defective tapes I've never seen 2 digit failure rates on CDC's, IBM's, RCA's or STK's mainframe tape drives. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
In da971c16dc7f429f94df778e1cc46...@pinnacledesk1, on 03/23/2010 at 06:29 PM, Pinnacle pinnc...@rochester.rr.com said: He says the following: What is a tape? If it's QIC-80[1], then his figures may be optimistic. If it's open reel on a Potter[1] tape drive than his figures may may accurate. If it's any *mainframe* medium that I've seen in the last three decades, I don't believe it. So what are you guys seeing out there? Most common causes of failure? 1. Can't find the tape. 2. Someone overwrote it. 3. Gross physical damage. [1] Don't ask, don't tell. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Hi Shmuel, Rightly categorized as incredibly vague and not to the point of the original post. My apologies to all. ;-) All I know is that many of the replies to the OP were in the no errors at all... what are you talking about? camp, and my memory as an MCO in a growth shop from 1987-1994 (about... until I finally made it to Technical Services and Storage Management for 10 months, before moving to system automation support until my resignation from this large telco in mid-1997) was that we did, indeed, receive DCK errors on 3480 media more times than I would like to have seen happen. Of course, some errors were due to hardware problems, but we definitely had our share of true data check (media) errors. Subsequent posts indicate the cause to be some sort of manufacturing issue with BASF tapes (that I *know* we used); as well as Imation tapes (that I *know* we used). So, I can only attribute our particular issues at the time to those problems (not knowing any better, really). My memory is not wonderful, but I do remember these occurrences. I really just wanted to convey my experience, which seemed to be so contrary to what most other posters to the thread were saying. All the best, Scott Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, March 25, 2010 5:21 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape In e026a9d62f2a482887df291738a7c...@scotttharderpc, on 03/24/2010 at 07:07 AM, Scott T. Harder scott.har...@embarqmail.com said: I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. How many is many? Even with defective tapes I've never seen 2 digit failure rates on CDC's, IBM's, RCA's or STK's mainframe tape drives. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Perhaps the author (used to work for STK and Sun) was referring to STK Redwood. The first true Write-once-read-never tape media !!! aka Deadwood. :-) Many years ago I inherited an environment that was using Redwood for HSM migration and backup. We had failures to such an extent that I wrote a program to recreate migration data from backup in the event of a failed mig tape and to recall and create new backups in the event of a failed backup tape. Program would read the necessary CDS records and sort them based on the tape volume and the datasets position on the tape (to reduce rewind time etc.) Regards, Chris -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Wednesday, 24 March 2010 9:29 AM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Pinnacle pisze: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Explanatory question: what does he sell now? BTW: My experience is much closer to your than presented in article (that means: MUCH LESS than 1%). However I use tape mirroring for production data. Did he mention such possibility? vbg What about disk based solutions - don't they require any redundancy? BTW: tape mirroring solves both problems: media failure and DR. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
It's not what this guy is smoking, but what he is eating. We have a saying in Dutch: who's bread one eats, who's word one speaks (I hope I have the genetives correct). He clearly speaks the word of the company that feeds him. Kees. Rick Fochtman rfocht...@ync.net wrote in message news:4ba969df.9010...@ync.net... I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick --- Pinnacle wrote: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick /snip I have to agree with the list, the last error on a tape (MF) was a duplex tape where the physical tape was dropped and the case cracked. No big deal since it was a duplex tape. On the other hand, tapes on the open systems side do have some failures. The failures are not even close to what the article specified though. If he is smoking something, he should at least share with the list :-). Thanks, Kevin Fletcher (317) 817-3545 Transition Coordinator z/OS, DB2, AS400 support Conseco, LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fletcher, Kevin Sent: Wednesday, March 24, 2010 6:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick /snip I have to agree with the list, the last error on a tape (MF) was a duplex tape where the physical tape was dropped and the case cracked. No big deal since it was a duplex tape. On the other hand, tapes on the open systems side do have some failures. The failures are not even close to what the article specified though. If he is smoking something, he should at least share with the list :-). Thanks, Kevin Fletcher (317) 817-3545 Transition Coordinator z/OS, DB2, AS400 support Conseco, LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Good memory on the 3480 media. Many, many years ago, BASF had a problem with 3480 Tape Media cartridges. The company that I worked for at that time received a large batch of bad tapes in a shipment, causing us quite a few headaches. This was back around 1997/1998. Since then, I've used cartridge media of all densities and vendors, without experiencing any significant problems. Mike Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott T. Harder Sent: Wednesday, March 24, 2010 7:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fletcher, Kevin Sent: Wednesday, March 24, 2010 6:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick /snip I have to agree with the list, the last error on a tape (MF) was a duplex tape where the physical tape was dropped and the case cracked. No big deal since it was a duplex tape. On the other hand, tapes on the open systems side do have some failures. The failures are not even close to what the article specified though. If he is smoking something, he should at least share with the list :-). Thanks, Kevin Fletcher (317) 817-3545 Transition Coordinator z/OS, DB2, AS400 support Conseco, LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Scott, I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Spencer hit it on the head. The only significant problem with 3480 tapes was due to faulty media produced by BASF. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
The bad tapes would literally spew black dust. We had to have all of our 3480s cleaned thoroughly, and rotate out all of the bad tapes as quickly as possible. On Wed, Mar 24, 2010 at 8:06 AM, John Kington john.king...@convergys.comwrote: Scott, I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Spencer hit it on the head. The only significant problem with 3480 tapes was due to faulty media produced by BASF. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Even on 3420's, of which I have seen a few snapped tapes, error rates were much lower than these ones. I would be curious as to where he came up with these numbers. Given the thousands of 3420's I used, the error rate on those was below 1%, and on 3480, 3490, 3490E and 3590 tapes the rates have been far below 1%. On various tape systems I've used to back up PC workstations and network servers, on the other hand, I have definitely seen high error rates, although probably much closer to 15-20% at the highest than the up to 50% he reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
The only tape media I have worked with that had that sort of error rate was 8mm DAT. That was very unreliable. In 20+ years of 34xx/3590 experience I've never seen that sort of error rate. I don't think even the cassette tape used with the TRS-80 was as bad as the DAT tape. On Wed, Mar 24, 2010 at 8:18 AM, Dave Reinken da...@reinken.us wrote: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Even on 3420's, of which I have seen a few snapped tapes, error rates were much lower than these ones. I would be curious as to where he came up with these numbers. Given the thousands of 3420's I used, the error rate on those was below 1%, and on 3480, 3490, 3490E and 3590 tapes the rates have been far below 1%. On various tape systems I've used to back up PC workstations and network servers, on the other hand, I have definitely seen high error rates, although probably much closer to 15-20% at the highest than the up to 50% he reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Pinnacle Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? I can recall seeing only one bum tape in the past decade, and that was a product tape, not a backup tape. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Thanks, John. I wasn't sure of the circumstances; just a somewhat clear memory of DCK's on 3480's. Everyone else was so clear to the contrary that I just had to do a sanity check. It's good to know that I'm still somewhat sane. My best to you, John. Good to hear from you ;-) Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kington Sent: Wednesday, March 24, 2010 8:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Scott, I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Spencer hit it on the head. The only significant problem with 3480 tapes was due to faulty media produced by BASF. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
The only significant problem with 3480 tapes was due to faulty media produced by BASF. I was a customer of them, back then. I remember the pain. But, back to the article. Tape is NOT going to go away. It's still the cheapest backup media. It used to be the fastest for sequential processing, but I don't know if it still is. The last place I worked at just used it for backups. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Ted MacNEIL pisze: Tape is NOT going to go away. Agreed. It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. It used to be the fastest for sequential processing, but I don't know if it still is. It's still is, however it strongly depens on the data compression ratio and speed of the source (it shouldn't be irregular). -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
No, I haven't seen a tape failure yet. Except way back when we had a 3490 cartridge smashed and broken in places and the tape was hanging out of it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Could someone provide a link to this article. Looking through I see articles by Fred Moore and Jon Toigo (I know both and would consider them to be my friends). But, I could not find the article being referenced (more coffee will probably help me with that). I also spent 20 years at STK and then Sun so I would like to see who this person is and what they are posting, then I can comment on it. As another history note STK also had some media problmes with 9840's when a batch from Imation was bad but it was taken care of. There was also a problem with 9840c drives reading 9840a media but that was a drive issue that was fixed. Carl Swanson carl.swans...@verizon.net Mobile: 215.688.1459 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 9:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape No, I haven't seen a tape failure yet. Except way back when we had a 3490 cartridge smashed and broken in places and the tape was hanging out of it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Randy Chalfant was the author. Sorry, but my electronic copy is gone. I looked it up in my hardcopy on my desk. Mike Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Carl Swanson Sent: Wednesday, March 24, 2010 10:13 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Could someone provide a link to this article. Looking through I see articles by Fred Moore and Jon Toigo (I know both and would consider them to be my friends). But, I could not find the article being referenced (more coffee will probably help me with that). I also spent 20 years at STK and then Sun so I would like to see who this person is and what they are posting, then I can comment on it. As another history note STK also had some media problmes with 9840's when a batch from Imation was bad but it was taken care of. There was also a problem with 9840c drives reading 9840a media but that was a drive issue that was fixed. Carl Swanson carl.swans...@verizon.net Mobile: 215.688.1459 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 9:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape No, I haven't seen a tape failure yet. Except way back when we had a 3490 cartridge smashed and broken in places and the tape was hanging out of it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. As to tape reliability, I can remember DR drills from long ago where a bad or lost tape was almost a sure bet. Although it was only one out of hundreds (less then 1%), it was critical and caused serious delays. So, from that perspective, the failure rate of the tape -solution- was upwards of 90%. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. My $0.02. YMMV. It depends. In some cases. IMHO. IMNSHO. (Please sprinkle in the above to suit.) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, March 24, 2010 8:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape ..snip It's still the cheapest backup media. ..snip NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
From: Spencer, Mike mike_spen...@bmc.com Randy Chalfant was the author. Sorry, but my electronic copy is gone. I looked it up in my hardcopy on my desk. http://chalfant.wordpress.com/ He cites Gartner and Storage Magazine as the sources for his statistics. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On Wed, 24 Mar 2010 07:33:46 -0700, daver wrote: http://chalfant.wordpress.com/ He lost me with the first sentence. When a star is born, the mass of the star determines how long it will live, ranging from millions of years to trillions of years. Considering that the universe is only about 15 billion years old, he has put us on notice that he really likes to exaggerate. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Hal Merritt pisze: Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Bad assumptions. No human interventions are necessary. Have you seen about ATL? Autmated Tape Library? Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. Again, BAD ASSUMPTION. No need to PTAM. ATL can reside in DR datacentre. The second one. Forgive me malice: how fast are non-tape media when transported via PTAM? Are the disk any faster during transportation? These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. Don't confuse backup and replication. Even three-site solution does not protect you form human or application error. Mistakenly deleted dataset is deleted in both primary and secondary site. PiT copy is the solution but quite expensive for medium and large amounts of data. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. MTR usually means time to REPAIR. Your descriptions regards RTO - Recovery Time Objective (Recovery Point Objective, Recovery Time Objective - crucial parameters for any DR and backup plans). Of course this is acronym, and by definition can be overloaded (have different meanings). I presented popular ones in this context. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I found the article useless. Especially having just completed another successful Disaster Recovery test using tape. Brought up both z/os and windows using the same tape media without a single error. Maybe he was referring to paper tape? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
I had a tape error just last week. Tapes and drives are about 5 years old. 10079 08:52:11.45 STC06292 0080 IOS000I 0121,2C,IOE,01,0600,,**,A00298,EXHPDM 504 504 0080 0A4410D050405050 0001FF00 030C003117335490 4B04E8205C5B2011 504 0080 WRITE ERROR DETECTED Cliff McNeill Good memory on the 3480 media. Many, many years ago, BASF had a problem with 3480 Tape Media cartridges. The company that I worked for at that time received a large batch of bad tapes in a shipment, causing us quite a few headaches. This was back around 1997/1998. Since then, I've used cartridge media of all densities and vendors, without experiencing any significant problems. Mike Spencer snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/210850553/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Thanks, I am looking at the article now and will comment on specifics later. Randy and I go way back even prior to STK days, so I know him well and he is a friend. A quick review of the article (detailed review later), it is obvious to me that Randy is speaking about Open Systems Backup. While at STK both he and I would see a large number of customers go for the cheapest option available and then wonder why they had troubles. Another telling point in the article is he is speaking about streams to tape to gain operational improvements (performance), while this will make backups run much quicker they will make restores more painful (slower). It is these points that make me believe that the article is Open Systems focused. I will go through the artile later today in greater detail Carl Swanson carl.swans...@verizon.net Mobile: 215.688.1459 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of daver++ Sent: Wednesday, March 24, 2010 10:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape From: Spencer, Mike mike_spen...@bmc.com Randy Chalfant was the author. Sorry, but my electronic copy is gone. I looked it up in my hardcopy on my desk. http://chalfant.wordpress.com/ He cites Gartner and Storage Magazine as the sources for his statistics. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
No assumptions. This is all experience/observations from several iterations of DR plans and differing management objectives. In many (most?) tape solutions (to include ATL), tapes are physically ejected, manually boxed, manually transported (via PTAM), manually stored, manually retrieved, manually received and inventoried, and manually reloaded into the ATL. That's a lot of human interventions. The ATL in the DR center is not capable of mounting a tape from a shipping box. A human has to load the tapes into the ATL. True, an ATL in the DR center could be used as offsite backup. And that reduces the MTR somewhat by eliminating the PTAM step in the recovery script. But you still have to get the tape to the DR site. Since our subspace transporter is on backorder, we have to transport tapes by truck. Your point contrasting backup and replication is well taken. However, in a DR context, a 'backup' is just as critical as primary data and should be replicated. You are also correct in that I may not have used the acronyms correctly. But you got the ideas. I should also point out a new idea: networked VTS. The IBM TS7740 (and I'm sure some others) has the ability to be networked with other TS7740's to automatically replicate virtual tapes. Unlike the DASD XRC/PPRC solutions, the network pipe can be sized on average loads and be a bit smaller (less expensive). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, March 24, 2010 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Hal Merritt pisze: Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Bad assumptions. No human interventions are necessary. Have you seen about ATL? Autmated Tape Library? Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. Again, BAD ASSUMPTION. No need to PTAM. ATL can reside in DR datacentre. The second one. Forgive me malice: how fast are non-tape media when transported via PTAM? Are the disk any faster during transportation? These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. Don't confuse backup and replication. Even three-site solution does not protect you form human or application error. Mistakenly deleted dataset is deleted in both primary and secondary site. PiT copy is the solution but quite expensive for medium and large amounts of data. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. MTR usually means time to REPAIR. Your descriptions regards RTO - Recovery Time Objective (Recovery Point Objective, Recovery Time Objective - crucial parameters for any DR and backup plans). Of course this is acronym, and by definition can be overloaded (have different meanings). I presented popular ones in this context. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please
Re: Mainframe Executive article on the death of tape
On Wed, 24 Mar 2010 09:58:46 -0500, Tom Marchant wrote: On Wed, 24 Mar 2010 07:33:46 -0700, daver wrote: http://chalfant.wordpress.com/ He lost me with the first sentence. When a star is born, the mass of the star determines how long it will live, ranging from millions of years to trillions of years. Considering that the universe is only about 15 billion years old, he has put us on notice that he really likes to exaggerate. Can you say extrapolate? A Google search for stellar lifetime finds articles estimating the upper bound for the lifetime of a low-mass star up to 100 trillion years. I deem Chalfant's science good; his showmanship Saganesque. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. Who backs up small amounts of data at a time? When I said backup, I didn't mean users copying production fileds; I meant real backups run by storage admin types (human or automatic). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 24 March 2010 04:25, Vernooij, CP - SPLXM kees.vern...@klm.com wrote: It's not what this guy is smoking, but what he is eating. We have a saying in Dutch: who's bread one eats, who's word one speaks (I hope I have the genetives correct). That would be whose; who's is a contraction of who is or who has. He clearly speaks the word of the company that feeds him. I think the closest common English expression would be He who pays the piper calls the tune. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Automatic tape libraries. Virtual tape. Where's the human interaction? Also, when I said backup, I did not mean apps copying single files, but the kind done for storage admin. Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. No they don't. We had a GDPS solution, at each site their was a duplicate library from the the other. No pickup trucks involved. This can push a MTR* out to a couple of days. Disaster recovery MTR is more dependent on procedures on how your backup/restore decisions are made, rather than whether or not it's tape. The more live (nearly live) data/systems you have, the smaller the MTR. A duplicate library, while adding cost, can go a long way in that direction. DR is an insurance policy. The bigger the premium, the bigger the dividend (if I may mix a metaphore). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
On 24 Mar 2010 09:26:58 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. Who backs up small amounts of data at a time? When I said backup, I didn't mean users copying production fileds; I meant real backups run by storage admin types (human or automatic). Some critical small files get backed up as soon as they are created, often moved off-site.But more and more these days those are handled via FTP instead of tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
We do a lot of performance and capacity studies for customers. We used to only accept SMF/RMF data on tapes. Once we setup to allow customers to FTP data to us the use of tapes fell off. At the peak I received over 500 tapes in one year. Last I received 98 tapes, all the rest were FTP. On Wed, Mar 24, 2010 at 12:45 PM, Howard Brazee howard.bra...@cusys.eduwrote: On 24 Mar 2010 09:26:58 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. Who backs up small amounts of data at a time? When I said backup, I didn't mean users copying production fileds; I meant real backups run by storage admin types (human or automatic). Some critical small files get backed up as soon as they are created, often moved off-site.But more and more these days those are handled via FTP instead of tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Hal, You talk about the cost of tape handling being high, and use that to justify remote disk??? Have you any idea what the true cost of remote disk is? The fiber bandwidth cost alone far outweighs the cost of tape handling for most smaller shops. Radoslaw was talking about remote tape. Some sites have a remote tape library that they can backup into, this eliminates almost all tape handling, and normally has lower bandwidth costs than remote disk. Hal Merritt hmerr...@jackhenry.com 3/24/2010 11:57 AM No assumptions. This is all experience/observations from several iterations of DR plans and differing management objectives. In many (most?) tape solutions (to include ATL), tapes are physically ejected, manually boxed, manually transported (via PTAM), manually stored, manually retrieved, manually received and inventoried, and manually reloaded into the ATL. That's a lot of human interventions. The ATL in the DR center is not capable of mounting a tape from a shipping box. A human has to load the tapes into the ATL. True, an ATL in the DR center could be used as offsite backup. And that reduces the MTR somewhat by eliminating the PTAM step in the recovery script. But you still have to get the tape to the DR site. Since our subspace transporter is on backorder, we have to transport tapes by truck. Your point contrasting backup and replication is well taken. However, in a DR context, a 'backup' is just as critical as primary data and should be replicated. You are also correct in that I may not have used the acronyms correctly. But you got the ideas. I should also point out a new idea: networked VTS. The IBM TS7740 (and I'm sure some others) has the ability to be networked with other TS7740's to automatically replicate virtual tapes. Unlike the DASD XRC/PPRC solutions, the network pipe can be sized on average loads and be a bit smaller (less expensive). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, March 24, 2010 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Hal Merritt pisze: Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Bad assumptions. No human interventions are necessary. Have you seen about ATL? Autmated Tape Library? Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. Again, BAD ASSUMPTION. No need to PTAM. ATL can reside in DR datacentre. The second one. Forgive me malice: how fast are non-tape media when transported via PTAM? Are the disk any faster during transportation? These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. Don't confuse backup and replication. Even three-site solution does not protect you form human or application error. Mistakenly deleted dataset is deleted in both primary and secondary site. PiT copy is the solution but quite expensive for medium and large amounts of data. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. MTR usually means time to REPAIR. Your descriptions regards RTO - Recovery Time Objective (Recovery Point Objective, Recovery Time Objective - crucial parameters for any DR and backup plans). Of course this is acronym, and by definition can be overloaded (have different meanings). I presented popular ones in this context. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http
Re: Mainframe Executive article on the death of tape
As a wise friend of mine likes to say, Someone's been eating paint chips again. I've not seen permanent error rates anywhere near double-digits on any 3480 (and up). In fact, I still have a 3480 that I used to carry from job- to-job. It read in just fine when I started here, some 8+ years after it's creation, and most of its time spent in a box in my basement (with very little environmental control). As Carl mentioned, Jon William Toigo wrote an article in the January/February Mainframe Executive that went completely the other way. I usually find value in studying opposing ideas, but once statistics are thrown around, my ears go up. Not only are 84.9% of all statistics made up on the spot, but Figures don't lie, but liars can figure. (Or is that Liars, Damn Liars, and Statisticians?) Bah, humbug. Art Gutowski Ford Motor Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
You may not be the ONLY one, but rather one of the very few. Storage conditions may have had a lot to do with your error rate. Also drive maintenance, cleaning, etc. Rick -- Scott T. Harder wrote: I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fletcher, Kevin Sent: Wednesday, March 24, 2010 6:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Good point. We missed that little hiccup, since all of our media was either IBM or Memorex. IIRC 3M had some media problems as well, but they were caught very quickly and resolved almost as fast. Rick - Spencer, Mike wrote: Good memory on the 3480 media. Many, many years ago, BASF had a problem with 3480 Tape Media cartridges. The company that I worked for at that time received a large batch of bad tapes in a shipment, causing us quite a few headaches. This was back around 1997/1998. Since then, I've used cartridge media of all densities and vendors, without experiencing any significant problems. Mike Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott T. Harder Sent: Wednesday, March 24, 2010 7:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fletcher, Kevin Sent: Wednesday, March 24, 2010 6:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe Executive article on the death of tape
Give the little guys credit for trying. They just haven't been building drives and media for 40+ years and lack practical experience. Maybe in another 20-30 years they'll finally get it right. :-) Rick - Dave Reinken wrote: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Even on 3420's, of which I have seen a few snapped tapes, error rates were much lower than these ones. I would be curious as to where he came up with these numbers. Given the thousands of 3420's I used, the error rate on those was below 1%, and on 3480, 3490, 3490E and 3590 tapes the rates have been far below 1%. On various tape systems I've used to back up PC workstations and network servers, on the other hand, I have definitely seen high error rates, although probably much closer to 15-20% at the highest than the up to 50% he reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
