Yes, in the OS/360 era and the early MVS days the Link Editor imposed a restriction on *SYSLIN*, but that doesn't explain the hard wired block sizes for things other than object decks. Nor does it justify leaving the procedures that way after the restriction was lifted.
If nobody cares about space wasted by a poor choice of block size, why would they care about a much smaller amount of space consumed to avoid the need for future changes? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Spiegel [dspiegel...@hotmail.com] Sent: Wednesday, April 22, 2020 3:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; The 3200 Maximum Blocksize used to be a Linkage Editor restriction. Also, better JCL does not pay dividends for any software vendor. As long as the old stuff works, nobody cares that it has been around since 2314s and 2319s. On 2020-04-22 15:34, Seymour J Metz wrote: > Well, I used a DCB exit to select a block size if none was provided. OTOH, I > kept seeing IBM procedures with 3200 long after that was too small. > > > -- > Shmuel (Seymour J.) Metz > https://eur05.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gmu.edu%2F~smetz3&data=02%7C01%7C%7Cfe4606446a024ce1ef3f08d7e6f42b0f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637231808688902735&sdata=GUKRdPCZgletvLmWTX8AsrOEwexm2Ictr2aFQRNdU%2B0%3D&reserved=0 > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Gerhard adam [gada...@charter.net] > Sent: Wednesday, April 22, 2020 3:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: Here we go again; > > ... and so goes the mythology. The truth is that programmers > routinely used lousy block sizes and wastes tremendous amounts of space. JCL > sizes were rarely scrutinized nor was data set usage. It was entirely > possible for test data to exist for weeks or months beyond its usefulness > This isn’t to say that money was obviousness spent and even wasted, but few > installations took managing their DASD seriously. They would worry about > saving a byte by packing a date while wasting 100 tracks due to poor blocking. > This is why nothing really happened until System Determined Blocksize, and > the Storage Administrator tools became available. > People certainly wrung their hands but rarely did anything about it > > > > Get Outlook for iOS > > > > > > > On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" > <rpomm...@sfgmembers.com> wrote: > > > > > > > > > > > Agreed. Another thing to remember was that we were dealing with disk volumes > measured in kilobytes or megabytes instead of terabytes. In addition, the > site I cut my teeth on had all removable disk packs that got rotated onto the > drives for processing of each application. Every byte saved per record gave > us the better chance of fitting the entire set of datasets on a single disk > set so we could process it. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List On Behalf Of Charles Mills > Sent: Wednesday, April 22, 2020 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: Here we go again; > > Faulty logic there. A byte here and byte there and pretty soon you have to > buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets > nearly full you have to pay for another. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 10:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > > > > > The notion of “savings” was marketing nonsense. The DASD was paid > for regardless of whether it held a production database or someone’s golf > handicap. > It cost the same whether it was empty or full. The notion of “saving” was > nonsense and even under the best of circumstances could only be deferred > expenses > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
