On Tue, Dec 16, 2014 at 12:25 PM, Paul Gilmartin < [email protected]> wrote:
> On Tue, 16 Dec 2014 18:06:20 +0000, Nims,Alva John (Al) wrote: > > >Oh boy, did someone go off on a tangent. > > > >Let me throw in my $0.02 on this: > > > >#1. YES, the RDW (4 bytes) MUST BE included in the length specified in > LRECL= > >#2. From the MVS JCL Reference: the value of LRECL is either: "1 to > 32,760 for non-VSAM data sets." Or " 1 to 32,761 for VSAM key-sequenced > (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does > not apply to VSAM linear space, RECORG=LS, data sets.)" > > > >So specifying 32,767 exceeds the maximum allowed, just as the error > message states. > > > My question is, why should there be a limit of 32761? I understand the > signed > halfword format imposes a limit of 32767. I see no reason for any smaller > limit. > > -- gil > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
