On Tue, Dec 16, 2014 at 1:11 PM, John McKown <john.archie.mck...@gmail.com> wrote: > I _think_ that I figured out where the 32760 came from. 32760 == 0x7FF8. > It is the largest multiple of 8 which can be kept in a signed half-word. > OS/360 used signed half-words to avoid sign extension > > when using the LH instruction. The original CCW had a two byte size field, > so that's likely where the half-word in all the I/O control blocks came > from. And we need a multiple of 8 because that's the granularity of the > GETMAIN / FREEMAIN allocation. To go to 32767 would really be to require > 32768 (due to 8 byte granularity), which is 0x8000. OOPS, there's the nasty > sign extension on the LH instruction. And, in OS/360 days, who's going to > write that large a block anyway? The only possibility would be on a tape > because disk drives in that era didn't have tracks that big. And, in any > case, who back then had that much core memory for such a big physical > block? We are constrained today by staying backwards compatible. Even > today, if I read it correctly, the Large Block Interface for physical > records >32760 bytes is _only_ for tape. And, in any case, everybody should > just convert to DB2 and not even worry about it. Right? > > -- > > While a transcendent vocabulary is laudable, one must be eternally careful > so that the calculated objective of communication does not become ensconced > in obscurity. In other words, eschew obfuscation. > > Maranatha! <>< > John McKown >
You could write a block longer than a track using track overflow. What didn't fit on the first track was continued onto the second track or subsequent tracks. Dropped on devices with track sizes over 32K. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
