On 08/12/2015 07:38 AM, Jerry Callen wrote: > In another thread, [email protected] 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 [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
