We were small, even then. Bu, it was in the programmers interest to avoid x#7 abends. And, for a time, I had authority o make the required JCL changes for SPACE and BLKSIZE myself. Mos programmers would approve the change if they didn't need to do it themselves. On of the Adabas files I did 8 digit and the DBA insited on fullword vs. packed had something like 8 or 10 date fields. If I remember correctly, some of those were in periodic groups of potentially 40 or 50 per record.
> -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Seymour J Metz > Sent: Wednesday, April 22, 2020 3:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > Maybe at your shop people were more on the ball, or you had the authority > to force them to listen, but in the shops I know of every man had his own > fiefdom and did things his way. It's not the techies who call the shots, with > few exceptions. > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY0HMszNaDT!9YcE6wIyzskPUXdoKFo237FSi0w6UDz6RplYVBhp5h_mk7wgAI > D06JMnJb0r0w$ > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of scott Ford [idfli...@gmail.com] > Sent: Wednesday, April 22, 2020 3:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > 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 > > > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY > > > 0HMszNaDT!9YcE6wIyzskPUXdoKFo237FSi0w6UDz6RplYVBhp5h_mk7wgAID0 > 6JMnJb0r > > 0w$ > > > > ________________________________________ > > 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 > > ---------------------------------------------------------------------- > 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