In a message dated 12/20/2007 7:43:02 A.M. Central Standard Time, [EMAIL PROTECTED] writes: >AFAIK it is 86, for equal blocks up to 22 bytes. Q: What is the reason for the limitation ? Surely, it's not track capacity. Where can I find further information (some RTFM) ? The maximum number of physical blocks (CKD) on any given device has always been the number of blocks with key length 0 and data length 0. For many years now, even if you specify data length 0 the control unit would write one byte on the track in the data field. But originally, if you asked for X bytes in the data field, you would get X bytes on the track at that location. Some time in the 1980s (I think), IBM began recording data on the track not in bytes but rather in units of some larger size, possibly called "chunks" (at least by me). The size of the chunk has varied from device type to device type. Using units of chunks allowed for greater levels of error detection and correction. The 3390's chunk size is around 34 bytes, I think. No matter how many bytes you want in your data field, 12 more bytes are added by the controller for a 3390 track (I think it's 12). So the smallest amount of data, a data length of 0, requires the controller to add 12 bytes, which requires one full chunk. Any data length between 0 and 22 will result in one chunk on the track. Any data length between 23 and 56 uses up two chunks on the track. And so on. Besides recording data in chunks, inter-record gaps have also been required on real CKD devices since day 1. There are plenty of other gaps on the track also, such as immediately after the home address and after each count field. All this overhead reduces the amount of space effectively available for user records. All this overhead is now unnecessary, since real devices are FBA and not CKD, and the control unit maps virtual to real when writing and real to virtual when reading. The internal real device's characteristics can literally be anything, and some day they may even be replaced by bunches of atoms instead of magnetized areas on rapidly spinning platters. The controller just has to know how to do the mapping. Our software back in the mainframe has to conform to what the access methods require, and they still require adherence to the ancient physical CKD limitations. Now if you want to know why the gaps were required since day one, that's another story, and equally fascinating (at least to me). :-) Bill Fairchild Franklin, TN
**************************************See AOL's top rated recipes (http://food.aol.com/top-rated-recipes?NCID=aoltop00030000000004) ---------------------------------------------------------------------- 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
