The truth is that everyone has such fond memories of their efforts yet
most were surprised when System Determined Blocksize was actually introduced.
They have forgotten the TSO CLISTS that were often written so that programmers
would specify more efficient block sizes.
Even today, the average IT person has a poor understanding of blocking and gets
confused when load libraries are involved (don’t understand RECFM=U)
Get Outlook for iOS
On Wed, Apr 22, 2020 at 12:15 PM -0700, "Joel C. Ewing" <jcew...@acm.org> wrote:
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" 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
