I may be mistaken, but I get the impression you think you're disagreeing with 
Mr Pommier and maybe Mills.  If that's what you meant to do, I don't think 
you've succeeded yet.  They're saying that saving DASD space was often 
important; you're saying that some programmers at some companies were either 
wasteful of it, either carelessly or ignorantly.  Judging from my own 
experience, I think both are true.

---
Bob Bridges, [email protected], cell 336 382-7313

/* I am pretty sure that, if you will be quite honest, you will admit that a 
good rousing sneeze, one that tears open your collar and throws your hair into 
your eyes, is really one of life's sensational pleasures.  -Robert Benchley */


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 15:20

... 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 

--- On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" 
<[email protected]> 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.  

-----Original Message-----
From: IBM Mainframe Discussion List  On Behalf Of Charles Mills
Sent: Wednesday, April 22, 2020 12:32 PM

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.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Gerhard adam
Sent: Wednesday, April 22, 2020 10:06 AM
    
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 [email protected] with the message: INFO IBM-MAIN

Reply via email to