When IBM announced System/360 back in 1964 with 24-bit addressing, people said "who will ever need 2**24 = 16M bytes?"
The 640K limit was CHOSEN by IBM to avoid their PCs threatening their mainframes. IBM had a choice between Intel 8086 (20-bit = 1M addressing) and Motorola 68000 (architected 32-bit = 4G addressing, but the first model had only 24 address lines = 16M addressing). Some IBMers claim they chose the 8086 because they didn't think Motorola could produce enough 68000s, but I prefer the above story. IMNSHO. ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alan Ackerman z/Linux Platform Build Bank of America 510-529-4128 [email protected] ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: CMSTSO Pipelines Discussion List [mailto:[email protected]] On Behalf Of Gregg Sent: Friday, April 22, 2016 8:38 AM To: [email protected] Subject: Re: [CMS-PIPELINES] Pipe from FILELIST line to XEDIT buffer Back in Yore, who ever thought we'd need more than 640K or 8M? On Fri, Apr 22, 2016 at 10:46 AM, Paul Gilmartin <[email protected]> wrote: > On 2016-04-21, at 19:38, Glenn Knickerbocker wrote: > > > On 4/19/2016 11:09 AM, Paul Gilmartin wrote: > >>>> Trust No 1 V 255 Trunc=255 Size=0 Line=1 Col=1 Alt=0 > >>>> > >> Still an unfortunate choice. For BFS, the Width and Trunc default > >> should be, "Doesn't matter", or "As much as you like". > > > > That would require XEDIT to use whole a different model for the file in > > storage. XEDIT's model has always been a set of fixed-length records, > > which it pads on loading and strips on saving if the file is RECFM V. > > It needs to know the WIDTH before it can load the file. > > > In days of yore, wouldn't it have saved storage, then precious, if it > had stripped the blanks on input rather than on output? > > -- gil > -- Gregg Reed "No Plan, survives execution" ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
