[email protected] (William H. Blair) writes: > I've never seen this documented. But I never looked that deeply, > either, so it might have been in my face since 1981. Regardless, > I was told it was only for purposes of allocating space on the > actual track -- AS IF the device actually wrote 32-byte (the > cell size) physical blocks (or multiples thereof). At the time, > prior to PCs, this meant nothing special to me. Of course fixed > sector sizes for PC drives made more sense, and I assumed the > underlying 3380 and 3375 hardware, like the 3370, used a fixed > block [or sector] size, which obviously had to a multiple of 32. > Later, I was told (by IBM) that this was, in fact, the case.
i remember that the 32byte data error correcting block was also the physical block on disk ... but I haven't found a documented reference to that effect. as I mentioned before ... 3380 was high-end ... while 3370 was considered mid-range. there was big explosion in the mid-range market with 43xx machines ... which MVS didn't fit well into. possibly somewhat as part of helping MVS possibly sell into that 43xx/midrange exploding market ... there was 3375 ... which emulated CKD on 3370 (there was also a major effort to get the MVS microcode assist from the 3033, required by all the new releases of MVS, implemented on 4341). recent post mentioning 3375 gave MVS CKD disk for mid-range: http://www.garlic.com/~lynn/2010l.html#13 Old EMAIL Index at the time, 3310/3370 were sometimes referred to as FBA-512 (rather than simply FBA) ... implying plans for moving to even larger block sizes. recent post referencing current FBA is looking at moving from 512 (with 512 byte data block error correcting) to 4096 (with 4096 byte data block error correcting) http://www.garlic.com/~lynn/2010m.html#1 History of Hard-coded Offsets the above has some articles about various FBA-512 compatibility/simulation efforts (for FBA-4096) ... very slightly analogous to CKD simulation on FBA. other recent posts mentioning fba, ckd, etc http://www.garlic.com/~lynn/2010k.html#10 Documenting the underlying FBA design of 3375, 3380 and 3390? http://www.garlic.com/~lynn/2010k.html#17 Documenting the underlying FBA design of 3375, 3380 and 3390? http://www.garlic.com/~lynn/2010l.html#76 History of Hard-coded Offsets Of course, VM had native FBA support and didn't have problems with low-end and mid-range markets. Part of this was that both VM kernel paging ... and the CMS filesystem organization (dating back to the mid-60s) have been logical FBA ... even when having to deploy on physical CKD devices. I've made past references that with the demise of FS that there was mad rush to get stuff back into the 370 hardware & software pipeline ... and it was going to take possibly 7-8 yrs to get XA (starting from time FS was killed). The MVS/XA group managed to make the case that VM370 product had to be killed, the development group shutdown and all the people moved to POK in order for MVS/XA to make its shipment schedule (endicott managed to save the vm370 product mission, but had to reconstitute a development group from scratch). misc. past posts mentioning future system effort http://www.garlic.com/~lynn/submain.html#futuresys Later in the 80s, POK decided to come out with vm/xa high-end product. However, there was some interesting back&forth about whether VM/XA would include FBA support ... they were under pressure to state that CKD was much better than FBA and that was why FBA support wasn't needed (as part of supporting MVS lack of FBA support). misc. past posts mentioning the disk division would let me come over and play disk engineer in bldgs. 14 (engineering lab) & 15 (product test lab) http://www.garlic.com/~lynn/subtopic.html#disk -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
