[Default] On 22 Apr 2020 12:44:41 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) 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. In reviewing this discussion, I suddenly realized that the saving by using 2 digit years was not just disk and tape space but also on forms, printer lines, punched cards, data entry screens and data entry key strokes. I know that in many cases I was scrambling for space on print lines. Clark Morris > > >-- >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 someones 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 >>>> >>>> >>>> ... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
