wrote:
On Thu, 20 Mar 2008 11:51:14 -0600, Vic Smith
wrote:

When these mainframe apps were designed, conservation of precious disk
space, fast I/O and frugal CPU time was more important than thinking
20 years in the future.

Actually I am old enough to remember when 80 characters was the limit
and dates had 1 digit "years". Those folks seemed to handle the decade
change OK ... many times. That was a regular thing when "media" was a
card. IBM used a 5 digit date on lots of transactions until 1970 or
so.

Back then a byte had a very high cost. It was in the millions of dollars
for a accounting system.

"Vic Smith" wrote in message
...
On Thu, 20 Mar 2008 14:53:01 -0500, wrote:

On Thu, 20 Mar 2008 11:51:14 -0600, Vic Smith
wrote:

When these mainframe apps were designed, conservation of precious disk
space, fast I/O and frugal CPU time was more important than thinking
20 years in the future.

Actually I am old enough to remember when 80 characters was the limit
and dates had 1 digit "years". Those folks seemed to handle the decade
change OK ... many times. That was a regular thing when "media" was a
card. IBM used a 5 digit date on lots of transactions until 1970 or
so.

I'll answer both your responses here.
I worked on insurance and financial apps that handled tens of millions
of records daily. That's what most big companies of that type do, and
fixed dates are part of most transactions.
Some of my apps had +1000 programs/modules passing data and
interacting. They were initially designed with a 2 byte year which
was naturally woven into the data flow.
Almost all were in-house developed, and unique.
So I wasn't talking about PC stuff.
Even mainframe database software such as DB2 and IMS is restricted by
how the data is represented when the app is designed.
You simply can't represent a fixed year with one digit without serious
processing and computational drawbacks.
Century wasn't much an issue when most of these systems were developed
with 2 digit years. A simple check to see if birth year was greater
than current year meant plug 18 into the date calc.
Hardly any other fixed business processing date, which are many,
needed that. They were all computed as 19xx.
The usual exceptions were amortization and maturity dates, which were
either calculated on the fly or kludged with an "century indicator" or
some such if stored. Almost any date complexity was acceptable if it
saved a byte. There were no standards.
No need to get into binary manipulation/translation of bytes, since
that has it's own serious drawbacks, not the least of them the human
interface.
Without getting into how these systems got to where they were circa
late '90's, or getting too gearhead. there were big Y2K issues that
needed addressing, and if they weren't, nearly every major business in
the country would have been dead in the water when 2000 hit.
Of course they were addressed, at the cost of many millions of
dollars.
There was no reason for the general population to be scared.
Personally, I never met anybody who was, but I heard of people
hoarding food and that kind of crap.
Anyway, I'm quickly forgetting all the old data tricks, and modern
systems like SAP which I last worked with use a full 8 bytes to
represent CCYYMMDD.
They throw in another 8 bytes or so for a full timestamp to
thousandths of a second. That's occupied disk bytes, not what's
represented through a translation.
It's evident the SAP designers, not faced with the space constraints,
and seeing a century turn up close, see the value of a full date.
Don't hold me to all that though, as I'm quickly forgetting that too.
I'm even wondering if I just didn't make that all up.
Either way, I'm surprised to find it doesn't bother me much.

--Vic


Don't feel bad.
By the time I got to the end of your post, I forgot what you were talking
about.

Eisboch

On Thu, 20 Mar 2008 14:53:01 -0500, wrote:

On Thu, 20 Mar 2008 11:51:14 -0600, Vic Smith
wrote:

When these mainframe apps were designed, conservation of precious disk
space, fast I/O and frugal CPU time was more important than thinking
20 years in the future.

Actually I am old enough to remember when 80 characters was the limit
and dates had 1 digit "years". Those folks seemed to handle the decade
change OK ... many times. That was a regular thing when "media" was a
card. IBM used a 5 digit date on lots of transactions until 1970 or
so.

I'll answer both your responses here.
I worked on insurance and financial apps that handled tens of millions
of records daily. That's what most big companies of that type do, and
fixed dates are part of most transactions.
Some of my apps had +1000 programs/modules passing data and
interacting. They were initially designed with a 2 byte year which
was naturally woven into the data flow.
Almost all were in-house developed, and unique.
So I wasn't talking about PC stuff.
Even mainframe database software such as DB2 and IMS is restricted by
how the data is represented when the app is designed.
You simply can't represent a fixed year with one digit without serious
processing and computational drawbacks.
Century wasn't much an issue when most of these systems were developed
with 2 digit years. A simple check to see if birth year was greater
than current year meant plug 18 into the date calc.
Hardly any other fixed business processing date, which are many,
needed that. They were all computed as 19xx.
The usual exceptions were amortization and maturity dates, which were
either calculated on the fly or kludged with an "century indicator" or
some such if stored. Almost any date complexity was acceptable if it
saved a byte. There were no standards.
No need to get into binary manipulation/translation of bytes, since
that has it's own serious drawbacks, not the least of them the human
interface.
Without getting into how these systems got to where they were circa
late '90's, or getting too gearhead. there were big Y2K issues that
needed addressing, and if they weren't, nearly every major business in
the country would have been dead in the water when 2000 hit.
Of course they were addressed, at the cost of many millions of
dollars.
There was no reason for the general population to be scared.
Personally, I never met anybody who was, but I heard of people
hoarding food and that kind of crap.
Anyway, I'm quickly forgetting all the old data tricks, and modern
systems like SAP which I last worked with use a full 8 bytes to
represent CCYYMMDD.
They throw in another 8 bytes or so for a full timestamp to
thousandths of a second. That's occupied disk bytes, not what's
represented through a translation.
It's evident the SAP designers, not faced with the space constraints,
and seeing a century turn up close, see the value of a full date.
Don't hold me to all that though, as I'm quickly forgetting that too.
I'm even wondering if I just didn't make that all up.
Either way, I'm surprised to find it doesn't bother me much.

--Vic

On Thu, 20 Mar 2008 21:34:32 -0400, BAR wrote:

wrote:
On Thu, 20 Mar 2008 11:51:14 -0600, Vic Smith
wrote:

When these mainframe apps were designed, conservation of precious disk
space, fast I/O and frugal CPU time was more important than thinking
20 years in the future.

Actually I am old enough to remember when 80 characters was the limit
and dates had 1 digit "years". Those folks seemed to handle the decade
change OK ... many times. That was a regular thing when "media" was a
card. IBM used a 5 digit date on lots of transactions until 1970 or
so.

Back then a byte had a very high cost. It was in the millions of dollars
for a accounting system.

Yeah, at Y2K a lot of these systems designed when space and CPU
minutes were gold were still running.
Even when I first started coding in 1980 my boss got on me for letting
the compiler find my syntax errors and typos.
Said I should do more desk checking.
A minute of CPU time was worth more than 2 hours of mine.
That changed drastically pretty soon.
As late as 1995 when I was contracting at McDonald's corporate,
disk space was still tightly held.
Shortly after starting there I grabbed a couple hundred cylinders
to do some work and got a call from data management not to do it
without a request. Hadn't seen that in years.
Later that day out front for a smoke, I was introduced to the DM
manager, who when he heard my name, said something like
"Oh yeah, Vic. The guy who grabbed all my extra space."
He smiled when he said it.
I told him I had twice that on my hard drive at home.
He said, "Bring it in."
Still smiling, but barely. I'd never want his job, catching it on one
end by users wanting space, and the other end with budget constraints.

--Vic

On Fri, 21 Mar 2008 17:17:56 -0400, "Eisboch" wrote:


"Vic Smith" wrote in message

Don't hold me to all that though, as I'm quickly forgetting that too.
I'm even wondering if I just didn't make that all up.
Either way, I'm surprised to find it doesn't bother me much.

--Vic


Don't feel bad.
By the time I got to the end of your post, I forgot what you were talking
about.

The end was the important part, and I hope you skipped right to it.
Your retirement advice came to mind as I wrote it.
I'm well settled in.

--Vic

"Vic Smith" wrote in message
...


The end was the important part, and I hope you skipped right to it.
Your retirement advice came to mind as I wrote it.
I'm well settled in.

--Vic

What retirement advice was that?

I forget.

Eisboch (aka "thingy")

On Fri, 21 Mar 2008 20:36:14 -0400, "Eisboch" wrote:


"Vic Smith" wrote in message
.. .


The end was the important part, and I hope you skipped right to it.
Your retirement advice came to mind as I wrote it.
I'm well settled in.

--Vic

What retirement advice was that?

I forget.

Yes, that was it.

--Vic