Re: 3380 was actually FBA?
On Wed, 12 Aug 2015 13:21:45 -0500, Joel Ewing wrote: My strong impression was that the erased IBG between physical blocks was a requirement for proper sensing of beginning of a block. The requirement that some 32-byte increments must be left unused for IBGs indicates these 32-byte groupings do not play the same role as fixed data blocks in FBA architecture devices. left unused? or marked as unused? (although this may be a distinction without a difference). And it may depend on choice of encoding technique: NRZI? MFM? GCR: (0,2) RLL? The last is interesting because it has 17 encodings available to represent a 4-bit nybble. Some systems use the extra code point to signal control information, which might be a logical IBG. https://en.wikipedia.org/wiki/Run-length_limited#GCR:_.280.2C2.29_RLL -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3380 was actually FBA?
l...@garlic.com (Anne Lynn Wheeler) writes: hardware speed and error correction was going to fixed-sized blocks. You can see this in 3380 track capacity calculations where record sizes have to be rounded up, sort of compromise hack given that MVS wasn't going to support real FBA. The 3380 was smaller fixed-sized blocks ... but not true IBM FBA like 3310 3370. 3375 was the first CKD emulated on top of an IBM FBA (3370) device. 512-byte blocks have prevailed for a couple decades (IBM 3310 3370 and follow-ons ... but also all the other industry standard disks). There is currently inudstry move to 4096-byte fixed blocks for improved error correction and track capacity. https://en.wikipedia.org/wiki/Advanced_Format http://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/ re: http://www.garlic.com/~lynn/2015g.html#4 3380 was actually FBA? and https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/3QSdKeko604 IBM journal articles are behind IEEE membership wall ... have found this detailed description at Google Books (3380 error correcting) https://books.google.com/books?id=cG4Zgb8OqwECpg=PA495lpg=PA495dq=ibm+3380+error+correctingsource=blots=lMaYN_d94Fsig=o-R202AspjC1Ox09YNcZDb9Ljgchl=ensa=Xved=0CDgQ6AEwBGoVChMIxpHRg-KmxwIVVluICh1twgJy#v=onepageq=ibm%203380%20error%20correctingf=false which has each subblock consists of 96 data bytes and six first-level check bytes are appended in the form of two interleaved codewords after discussing details of 3380, it moves into RAID Reed-Solomon codes ... trivia, I worked with somebody in bldg14 that was awarded the original RAID patent. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
3380 was actually FBA?
In another thread, l...@garlic.com wrote: ... but then if MVS had FBA support wouldn't have needed to do 3380 as CKD (even tho inherently it was FBA underneath) ... I didn't know that. Was that the first (and/or last?) IBM SLED to be inherently FBA under the hood? Where were the smarts for that implemented, in the control unit, or the drive itself? -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3380 was actually FBA?
The important distinction of FBA is that block headers aren't rewritten when the data is changed. (Not counting when a low-level format is done, normally for the whole drive.) I don't know the low-level details of the 3380 to know. It might be that the 32 byte blocks are related to ECC, and are not FBA-like blocks. If block headers are not rewritten, then I would call it FBA-32 under the hood. -- glen -Original Message- (snip) Was that the first (and/or last?) IBM SLED to be inherently FBA under the hood? Where were the smarts for that implemented, in the control unit, or the drive itself? The count, key, and data field data on a native 3380 were written in 32-byte increments, but since a physical data block could be an arbitrary number of 32-byte chunks and unused 32-byte chunks at varying positions around the track had to be wasted between physical blocks for inter-block gaps, I wouldn't call this FBA-under-the-hood. The physical block size (up to 31-bytes larger than known to the Operating System) definitely wasn't Fixed, just restricted to a multiple of 32 bytes. The only fixed part of the track architecture was the 32-byte increment size. Perhaps at the actual device hardware level a 3380 could have been given the capability to randomly address, read, and write individual 32-byte track increments while using all possible 32-byte increments on the track for data, but I would expect that would have been a much more expensive design than was required to support CKD architecture. My strong impression was that the erased IBG between physical blocks was a requirement for proper sensing of beginning of a block. The requirement that some 32-byte increments must be left unused for IBGs indicates these 32-byte groupings do not play the same role as fixed data blocks in FBA architecture devices. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3380 was actually FBA?
jcal...@narsil.org (Jerry Callen) writes: In another thread, l...@garlic.com wrote: ... but then if MVS had FBA support wouldn't have needed to do 3380 as CKD (even tho inherently it was FBA underneath) ... I didn't know that. Was that the first (and/or last?) IBM SLED to be inherently FBA under the hood? Where were the smarts for that implemented, in the control unit, or the drive itself? re: http://www.garlic.com/~lynn/2015f.html#86 Formal definituion of Speed Matching Buffer hardware speed and error correction was going to fixed-sized blocks. You can see this in 3380 track capacity calculations where record sizes have to be rounded up, sort of compromise hack given that MVS wasn't going to support real FBA. The 3380 was smaller fixed-sized blocks ... but not true IBM FBA like 3310 3370. 3375 was the first CKD emulated on top of an IBM FBA (3370) device. 512-byte blocks have prevailed for a couple decades (IBM 3310 3370 and follow-ons ... but also all the other industry standard disks). There is currently inudstry move to 4096-byte fixed blocks for improved error correction and track capacity. https://en.wikipedia.org/wiki/Advanced_Format http://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/ eckd originally for speed-matching buffer ... was also trying to retrofit a little of the FBA benefits to CKD architecture (again because MVS wouldn't upgrade to real FBA). part of the issue for 3375 was there wasn't a mid-size CKD disk (just the high-end 3380). Large customers were buying hundreds ( thousands) of vm/4300s for distributed non-datacenter market (sort of leading edge of the coming distributed computing tsunami; for instanceNATO got 6000 vm/4341s) ... and MVS couldn't play in that new market with no mid-range CKD disk. Doing the 3375 CKD at least gave MVS a path ... however MVS support was really oriented around having 10-20 people in large datacenter. The idea of supporting a thousand distributed systems out in departmental areas wasn't very practical. I also got dragged into doing benchmarks for LLNL that was looking at 70 4341s for computer farm (sort of leading edge of the future supercomputing paradigm). 4341 was faster than 1583031 ... and clusters of 4341s were faster than 3033, lower aggregate cost, lower aggregate physical and environmental footprint, also higher aggregate memory and i/o throughput. old email http://www.garlic.com/~lynn/lhwemail.html#4341 past posts http://www.garlic.com/~lynn/submain.html#dasd -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3380 was actually FBA?
On 08/12/2015 07:38 AM, Jerry Callen wrote: In another thread, l...@garlic.com wrote: ... but then if MVS had FBA support wouldn't have needed to do 3380 as CKD (even tho inherently it was FBA underneath) ... I didn't know that. Was that the first (and/or last?) IBM SLED to be inherently FBA under the hood? Where were the smarts for that implemented, in the control unit, or the drive itself? -- Jerry The count, key, and data field data on a native 3380 were written in 32-byte increments, but since a physical data block could be an arbitrary number of 32-byte chunks and unused 32-byte chunks at varying positions around the track had to be wasted between physical blocks for inter-block gaps, I wouldn't call this FBA-under-the-hood. The physical block size (up to 31-bytes larger than known to the Operating System) definitely wasn't Fixed, just restricted to a multiple of 32 bytes. The only fixed part of the track architecture was the 32-byte increment size. Perhaps at the actual device hardware level a 3380 could have been given the capability to randomly address, read, and write individual 32-byte track increments while using all possible 32-byte increments on the track for data, but I would expect that would have been a much more expensive design than was required to support CKD architecture. My strong impression was that the erased IBG between physical blocks was a requirement for proper sensing of beginning of a block. The requirement that some 32-byte increments must be left unused for IBGs indicates these 32-byte groupings do not play the same role as fixed data blocks in FBA architecture devices. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
