David, I laugh at these comments/observations. Early days 70-80s System Programmers like myself helped programmers determine blocksize and dataset location, etc. and then DBAs were born or made and then the system optimized.
Evolution Scott On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz <sme...@gmu.edu> wrote: > My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 > word disk drive and two tape drives. I may have been a tad more constrained > than you were when you started. I agree with Mr. Adam; people would have > saved far more DASD space with intelligent choice of block size than the > miniscule amount they saved by truncating the year. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Joel C. Ewing [jcew...@acm.org] > Sent: Wednesday, April 22, 2020 3:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > Should we presume you didn't work on mainframes prior to the advent of > cheap memory and cheap RAID DASD in TB chunks? > > Even after advent of 3380, 3390, and even native 3390-3, drives our > company didn't lease DASD drives without doing cost analysis. In late > 1970's and early 1980's we were on 3330's and later 3350's, where > physical constraints were also an issue -- when I started as SysProg in > 1978, the computer room was maxed out space-wise at 29 3330 drives, or > only 2.9GB total DASD space. We didn't have DASD sitting around that > wasn't 95% or more utilized. Batch jobs typically got one dedicated > 3330 DASD work volume that they could allocate only for the duration of > the job stream, staging data from/to tape as necessary to fit and to > preserve for next job-stream run. It wasn't until 1995 and beyond, > that it finally made economic sense for us to acquire DASD capacity a > year or two before we might actually be able to justify a need. > > Our company believed in investing more money in people to retain good IT > personnel rather than throwing money at hardware. That mind-set was one > of the reasons why of the 50 some-odd companies in that line of > business in 1950, of the 3 still in business in 2000, one was ours. > > Saving one or two bytes per date field in that kind of environment was > not "marketing nonsense". By performance tuning and efficient > application design we consistently delayed the need for a DASD or > processor upgrades, resulting in *considerable* monetary savings over > decades. You don't "waste" DASD or memory space just because it's > available at the time without first considering the long-term impact on > future upgrades. A "good" programmer/analyst was trained to err on the > side of conserving resources. > > You can't judge decisions of the past without first understanding the > cost, physical space, memory, and I/O configuration constraints under > which those decisions were made. Unlike now where where easy > incremental upgrades are possible, back then every upgrade, assuming one > was possible, involved a substantial cost increase. > JC Ewing > > On 4/22/20 12:05 PM, Gerhard adam wrote: > > > > > > > > > > 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 > > > > > > > > Get Outlook for iOS > > > > > > > > > > > > > > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" < > dspiegel...@hotmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > It was also the physical size of the dataset. > > > > On 2020-04-22 12:55, Gibney, Dave wrote: > >> In the 80's a byte of DASD savings could be thousands of dollars. > >> > >>> -----Original Message----- > >>> From: IBM Mainframe Discussion List On > >>> Behalf Of Phil Smith III > >>> Sent: Wednesday, April 22, 2020 9:12 AM > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: Here we go again; > >>> > >>> As others have suggested, many companies do still have SSNs stored as > >>> packed decimal. So sure, a namespace expansion is possible, but it's a > bigger > >>> change than one might think, however it's done. I've even seen at > least one > >>> company who stored them as binary! I sure hope someone got a big bonus > >>> for saving that byte... > >>> > >>> > >>> > >>> > >>> > >>> Peter Farley wrote: > >>> > >>>> There are also many non-human entities like corporations that use the > >>> same SSN value space. > >>> > >>> > >>> > >>>> There are a LOT of those . . . and they spring up and fade away at a > rate far > >>> higher than human births and deaths. > >>> > >>> > >>> > >>> They use the same namespace--that is, if your SSN is 123-45-6789, an > estate > >>> or business could also have that number. Since they're uses for > different > >>> things, it's more that they happened (!) to choose the same format > than that > >>> they're "the same". (And actually they're theoretically formatted > differently: > >>> an EIN is xx-xxxxxxx vs. the SSN xxx-xx-xxxx, not that most folks > store them > >>> with the hyphens.) > >>> > >>> > >>> > >>> ...phsiii > >>> > >>> > >>> ... > > > -- > Joel C. Ewing > > ---------------------------------------------------------------------- > 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 > -- Scott Ford IDMWORKS z/OS Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
