So you agree that poor Blocksizes give rise to poor disk usage?
As to space allocations, I’m sorry but for as many problems as you’re
describing the staff couldn’t have been that serious.
If management was as serious as being claimed there would have been no problem.
Yet I find that few people understand blocking. They invariably get it wrong
with load modules, VSAM, ISAM (in the old days) and BDAM. Come to think of it,
this only applies to sequential files.
As for incompetent programmers? Spare me the exaggerations. Even today, few
people understand it and most get it wrong when assuming that half-track
blocking is optimum when other than sequential files are considered
Get Outlook for iOS
On Wed, Apr 22, 2020 at 4:11 PM -0700, "Gibney, Dave" <gib...@wsu.edu> wrote:
Full volumes due to excessive space wasted due to crap blksizes had everything
to do with x37 abends. I am sorry that your experience included so many
incompetent programmers. Mine did care, and my management cared more. Before
SDB, it was a periodic take for me to review and clean DASD, fix BLKSIZES, Etc.
In that era, I was cheaper the STOPX37. I'm not cheaper today.
> -----Original Message-----
> From: IBM Mainframe Discussion List On
> Behalf Of Gerhard adam
> Sent: Wednesday, April 22, 2020 3:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
>
>
>
>
>
> X37 abends have nothing to do with block sizes Furthermore the role
> of secondary space allocations was so bad among programmers that many
> installations installed a vendor product called STOPX37 because it was easier
> then actual planning and calculating space.
>
>
>
> Get Outlook for iOS
>
>
>
>
>
>
> On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz"
> wrote:
>
>
>
>
>
>
>
>
>
>
> Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was
> 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger,
> even before the 1301, and the 2311 larger still. Only the 1130 was close to
> the
> 650's mere megabyte.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg
> BY0HMszNaDT!5_-I8aqsL8R5a9A-
> Z5U0vXKBJCfgDQPHsOlqGSGWCHFohipMYPShrUZqJpXBag$
>
> ________________________________________
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Pommier, Rex [rpomm...@sfgmembers.com]
> Sent: Wednesday, April 22, 2020 3:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: Here we go again;
>
> 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
