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

Reply via email to