4 Jan
1999
4 Jan
'99
1:25 p.m.
What boggles the mind is that this is a problem at all. It seems hard to
believe (in retrospect) that people really did deliberately build software
with only 2 digit years. I know it saved a few bytes, and yes, I remember
when a byte of memory was a significant amount, but still. How did standard
programming practice come to be so short sighted as to assume that software
infrastructure would be thrown out and replaced on a regular basis?
--
Jim Strickland
jim(a)DIESPAMMERSCUMcalico.litterbox.com
-----------------------------------------------------------------------
Vote Meadocrat! Bill and Opus in 2000 - Who ELSE is there?
-----------------------------------------------------------------------
4 Jan
4 Jan
1:36 p.m.
On Mon, 4 Jan 1999, Jim Strickland wrote:
What boggles the mind is that this is a problem at
all. It seems hard to
believe (in retrospect) that people really did deliberately build software
with only 2 digit years. I know it saved a few bytes, and yes, I remember
when a byte of memory was a significant amount, but still. How did standard
programming practice come to be so short sighted as to assume that software
infrastructure would be thrown out and replaced on a regular basis?
With the rate of change in the computer industry, who 30 years ago would
have thought that their programs would still be operating? Its seemed
stupid and silly to think they would. The driving factor was the fact
that 1K 30 years ago was like 50gigs today (actually, I don't think a
comparison on memory even applies anymore today...memory is almost an
inifinte commodity these days). Suffice it to say if you could save bytes
then you did, and 30 years is like a long time (in 30 years I'll be a
middle-aged dufas in a bad (19)90's suit chasing 20-something year old
women).
What I wonder is why people didn't just store the date as decimal in those
two bytes. You can go up to the year 65535 that way. I'm positive there
were good reasons for not doing that as well. Its easy for us to look
back and scoff at our forebearer programmers.
Sellam Alternate e-mail: dastar(a)siconic.com
------------------------------------------------------------------------------
Always being hassled by the man.
Coming in 1999: Vintage Computer Festival 3.0
See http://www.vintage.org/vcf for details!
[Last web site update: 12/27/98]
1:39 p.m.
What I wonder is why people didn't just store the
date as decimal in those
two bytes. You can go up to the year 65535 that way. I'm positive there
were good reasons for not doing that as well. Its easy for us to look
back and scoff at our forebearer programmers.
I am not knowledegable in this area, but I would suggest that 2 BCD digits
(0-9) encoded in a single byte would possibly be the reason. 1 byte is
better than 2 :)
A
5 Jan
5 Jan
8:09 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 541 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19990105/1f51f638/at…
11 Jan
11 Jan
9:59 a.m.
> What I wonder is why people didn't just store
the date as decimal in those
> two bytes. You can go up to the year 65535 that way. I'm positive there
Maybe because the software was written on a machine
(or for an OS that
simulated a machine) using punched cards or something. You can't
necessarily represent 256 different values using standard punches in a
column of a card. Some combinations are illegal.
Nop - or better partly correct - it is true that not every punch
combination was legel (that would be 4096 possible) but at least
there was a legal combination for any possible 8-Bit combination.
Otherways I would have been impossible to boot from a punch card
reader !
Anyway, a 'byte', or more particularly a
character, is not necessarily 8
bits. It may be _now_, but it wasn't then.
I love your comments (and I guess you had also some contact with
these 9 Bit Byte Bull Mini computers :)
Gruss
H.
--
Ich denke, also bin ich, also gut
HRK
12:43 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 1541 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19990111/f80b9ac9/at…
1:28 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 755 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19990111/41103d0f/at…
12 Jan
12 Jan
4:02 a.m.
> Nop - or better partly correct - it is true that
not every punch
> combination was legel (that would be 4096 possible) but at least
------------
> there was a legal combination for any possible
8-Bit combination.
> Otherways I would have been impossible to boot from a punch card
> reader !
Since when do all machines have 8-bit instructions,
and since when do all
machines represent one instruction as one column on a card, and since
when do all machines have binary instructions?
Did I say this ? I just mentioned that there is a legal (within
IBM style 12 row cards) method to code all opssible 256 combinations
for 8 bit bytes - starting from 12,0,9,8,1 for x'00' up to 12,11,
0,9,8,7 for x'FF'.
I see no way why such a thing is conected to an 8 bit instruction -
it's only the way to encode a byte on one columne, which gives
80 bytes on a card - enough for the first step of a boot loader
There is no requirement for 256 legal punchings in a
column AFAIK.
Just to enter raw binary data from punch cards, and of course
to boot a machine - my main experiance about that comes from
the /370 world, or more exactly from SIEMENS /370 compatible
systems. I still love the simple but _extremly_ variable
structure of almost everything within this systems. You just
entered a valid device address via two turning wheels and
hit the load button - no matter if it was a tape, a disk, a
card reader, a magnetic card reader, a punch tape reader or
what ever (later on even FD drives), the machine starts the
IPL from this device - just reads the first available block
and execute it - simple and powerfull - no boot manager, no
nothing, just any device - you could run the computer just
with card reader and card puncher (if you wanted to have an
output :).
As an aside, the Philips P850 series have machine-code
bootstrap tapes
that only use printable characters. A single (16 bit binary) machine word
is stored as 4 characters on the paper tape. The requirements are :
1) There must be at least one hole punched per character, apart from the
leader which is all nuls
2) the lower 4 bits of the character are the binary encoding of that nybble.
Talking about paper tapes ?
That's all. I normally use the characters @ to O
when I write tapes.
Philips tapes use 0-9 and J-O I think.
This machine, therefore will boot from a tape
containing only a subset of
all possible punchings. And I can well believe some card-based machines
would do the same.
At least /360, /370ish machines want binaty data from
boot devices.
> > Anyway, a 'byte', or more
particularly a character, is not necessarily 8
> > bits. It may be _now_, but it wasn't then.
> I love your comments (and I guess you had also
some contact with
> these 9 Bit Byte Bull Mini computers :)
I've come across enough machines that use 6-bit
characters internally....
6 Bit ? thats new - I never have seen a 6 Bit byte computer - I
know 6 Bit only from some serial line encodings.
Servus
H.
--
Ich denke, also bin ich, also gut
HRK
8:24 a.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 3446 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/19990112/032962cb/at…
10:30 a.m.
Hans Franke said...
|
|> > I love your comments (and I guess you had also some contact with
|> > these 9 Bit Byte Bull Mini computers :)
I think it was Hughes that made 18 bit and 36 bit computers, too.
9 bit byte machines weren't exactly common in the 60s and 70s,
but they weren't exactly rare, either.
|6 Bit ? thats new - I never have seen a 6 Bit byte computer - I
|know 6 Bit only from some serial line encodings.
The CDC Cybers (at least the 60 and 70 series systems) used
6 bit bytes, and 60 bit words. So one word held 10 characters.
Upper case only, of course, but they did something (I forget
what) to extend that (I forget what) to include lower case,
and pretty much the whole ASCII character set.
I'll have to scrounge up the old NOS guide...
-Miles
11:06 a.m.
On Tue, 12 Jan 1999, Miles O'Neal wrote:
Hans Franke said...
|
|> > I love your comments (and I guess you had also some contact with
|> > these 9 Bit Byte Bull Mini computers :)
I think it was Hughes that made 18 bit and 36 bit computers, too.
9 bit byte machines weren't exactly common in the 60s and 70s,
but they weren't exactly rare, either.
The TX-2 at MIT was either a 9, 18, 27 or 36 bit machine based on how you
programmed it.
Sellam Alternate e-mail: dastar(a)siconic.com
------------------------------------------------------------------------------
Always being hassled by the man.
Coming in 1999: Vintage Computer Festival 3.0
See http://www.vintage.org/vcf for details!
[Last web site update: 12/27/98]
11 Jan
11 Jan
3:57 p.m.
New subject: character codes and punched cards (was Re: y2k stuff)
"Hans Franke" <Hans.Franke(a)mch20.sbs.de> wrote:
Nop - or better partly correct - it is true that not
every punch
combination was legel (that would be 4096 possible) but at least
there was a legal combination for any possible 8-Bit combination.
Otherways I would have been impossible to boot from a punch card
reader !
Still wrong.
Not all machines that had card readers could boot from cards, and even
the ones that could do so didn't necessarily have a 256-character set
(or 8-bit bytes).
For instance, the IBM 1401, which typically was booted from cards, but
had only 64 distinct characters.
12 Jan
12 Jan
5:17 a.m.
New subject: character codes and punched cards (was Re: y2k stuff)
> Nop - or better partly correct - it is true that
not every punch
> combination was legel (that would be 4096 possible) but at least
> there was a legal combination for any possible 8-Bit combination.
> Otherways I would have been impossible to boot from a punch card
> reader !
Still wrong.
Not all machines that had card readers could boot from cards, and even
the ones that could do so didn't necessarily have a 256-character set
(or 8-bit bytes).
For instance, the IBM 1401, which typically was booted
from cards, but
had only 64 distinct characters.
Shure ? the 1401 is a bit before my time, but didn't they
already use 12 row cards with EBCDIC coding (like 12,1 to
12,9; 11,1 to 11,9 and 0,2 to 0,9 for A-i; J-R and S-Z) ?
Gruss
H
--
Ich denke, also bin ich, also gut
HRK
12:01 p.m.
New subject: character codes and punched cards (was Re: y2k stuff)
I wrote:
For instance, the IBM 1401, which typically was booted
from cards, but
had only 64 distinct characters.
Hans replied:
Shure ? the 1401 is a bit before my time, but
didn't they
already use 12 row cards with EBCDIC coding (like 12,1 to
12,9; 11,1 to 11,9 and 0,2 to 0,9 for A-i; J-R and S-Z) ?
The 1401 most definitely did not use EBCDIC. It only had six
bit characters, with a seventh bit to serve as a word mark,
and an eighth (non-programmer-accessible) parity bit. The
word mark was used to denote the (leftmost?) end of a field,
for variable-field-length instructions.
However, since EBCDIC was by design (and by name) an extended
version of existing codes, the 1401's card code is similar.
Eric
4 Jan
4 Jan
3:58 p.m.
Jim Strickland <jim(a)calico.litterbox.com> wrote:
What boggles the mind is that this is a problem at
all. It seems hard to
believe (in retrospect) that people really did deliberately build software
with only 2 digit years. I know it saved a few bytes, and yes, I remember
when a byte of memory was a significant amount, but still.
Yes, but do you remember back when 80 characters was the total amount you
had for an entire "database" record? That's the origin of the problem.
And although I don't know of any software from those days (pre-1960) still
running, there are many systems that evolved from those origins.
Once databases started being kept on disk drives, saving two bytes for each
date may not have sounded like much, but it literally did save money. It
takes fewer disk packs (and perhaps fewer drives) to store 92-byte records
than 94-byte records. I don't know how many decisions were made on that
basis, but you can't realistically ignore it.
Of course, it would still save money to do that today, but instead of
saving about two cents per date (IBM RAMAC, 1956) it is now one cent per
million dates (Quantum FB312700A 12.7G drive for $249 from Dirt Cheap Drives).
Eric
5 Jan
5 Jan
5:01 a.m.
At 02:58 AM 1/5/99 -0000, Eric Smith wrote:
Once databases started being kept on disk drives, saving two bytes for each
date may not have sounded like much, but it literally did save money. It
takes fewer disk packs (and perhaps fewer drives) to store 92-byte records
than 94-byte records. I don't know how many decisions were made on that
basis, but you can't realistically ignore it.
There's a dozen lame excuses as to why They Did It That Way. Few of
them make any sense. If they'd stored the year in a seven or eight
bits offset from their earliest year, instead of two ASCII or BCD
digits, they'd halve their storage requirements. There is a good
discussion of this at <http://language.perl.com/news/y2k.html>.
At 04:37 PM 1/4/99 -0800, Chuck McManis wrote:
I attended a talk by a Y2K consultant (Bruce Webster)
I remember him from a decade ago, writing for Byte, and doing something
(games?) with the Amiga. I seem to remember him at the Amiga dev cons
where I once met you, too. His resume at <http://www.bfwa.com/prof/> shows
he's been busy at other things, and has certainly been around for a while
in the world of computers. However, I'll always remain a bit skeptical
of opinions from anyone who's routinely paid to speak or write their
opinions. :-)
Your discussion of being FreeGate's Y2K rep reminded me of when I was
asked whether the software I developed was susceptible. At first
I thought "no way, not a thing." Then I remembered the node-locking
on the SGI version - nope, it wisely used an offset from 1900 and
stored it in enough bits. A few sprintf("%s") of ctime(), though.
- John
6:49 a.m.
At 02:58 AM 1/5/99 -0000, Eric Smith wrote:
I wrote a response to that very discussion. It was summarily ignored. The
gist of it was to refute the author's assertion that "they couldn't have
done it to save two bytes." Look at the design of an IBM 1401 sometime.
It has BCD-oriented memory. It's 8-bits, but four of them are the BCD
representation of the bottom 10 rows of a punch card, two bits are for the
top two rows, then two other bits for out-of-band control of the data.
The 1401 was not built to manipulate binary data. It would be incredibly
complicated to do so on such a machine. You could never just store raw
binary in memory.
Not all machines do things the way we do them today. Leave the nice
orthogonal 8/16/32-bit world and you see people doing interesting things
to get the job done. It's one of the reasons I love classic computers;
you have to think differently to make them work.
-ethan
Once databases started being kept on disk drives, saving two bytes for each
date may not have sounded like much, but it literally did save money...
There's a dozen lame excuses as to why They Did It That Way. Few of
them make any sense. If they'd stored the year in a seven or eight
bits offset from their earliest year, instead of two ASCII or BCD
digits, they'd halve their storage requirements. There is a good
discussion of this at <http://language.perl.com/news/y2k.html>.
7:11 a.m.
At 12:49 PM 1/5/99 -0500, Ethan Dicks wrote:
Tom Christiansen was a college friend of mine; that's exactly the
kind of person he is. :-)
There is a
good
discussion of this at <http://language.perl.com/news/y2k.html>.
I wrote a response to that very discussion. It was summarily ignored. The gist of it was to refute the author's assertion
that "they couldn't have
done it to save two bytes." Look at the design of an IBM 1401 sometime.
It has BCD-oriented memory.
I'm not expert on the 1401, but I understand what you're getting at.
I'm sympathetic to the view that two-digit Y2K problems exist because
of constraints of input devices, storage devices, dain-bramaged COBOL,
punched cards, and lack of code memory and processing time for
performing input validation, and the reticent nature of programmers
who didn't want to be blamed for errors resulting from updating
data or code as machines improved and data migrated.
As you said, though, you'd be surprised what ancient computers can do.
I'd hate to say something was impossible; I'll happily admit that a Y2K
problem arose because at the time it seemed the most sensible way to do it.
- John
8:05 a.m.
At 12:49 PM 1/5/99 -0500, Ethan Dicks wrote:
Tom Christiansen was a college friend of mine; that's exactly the
kind of person he is. :-)
I take no personal offense, but I did get a rather curt blowoff.
There is
a good
discussion of this at <http://language.perl.com/news/y2k.html>.
I wrote a response to that very discussion. It was summarily ignored. I'm not expert on the 1401, but I understand what
you're getting at.
I'm sympathetic to the view that two-digit Y2K problems exist because
of constraints of input devices, storage devices, dain-bramaged COBOL...
Another so-far-unmentioned scarce resource: 80 columns of data per card.
Think about it. A customer ID card. If you have a date on it, that's
two less characters of something else, the name, perhaps?
Imagine a metropolitan utility company with 1 million customers. One card
per month per customer. Two megabytes of "19" per month with only one date
per card. That's 800 feet of tape per month per date (at 200 bpi). Handling,
storage, time, money, space. It all adds up. The physical volume of that
amount of data is incomprehensible today when they are sewing digitized
samples containing hundreds of Kbytes into novelty underwear.
-ethan
8:10 a.m.
John Foust <jfoust(a)threedee.com> wrote:
There's a dozen lame excuses as to why They Did It
That Way. Few of
them make any sense. If they'd stored the year in a seven or eight
bits offset from their earliest year, instead of two ASCII or BCD
digits, they'd halve their storage requirements. There is a good
discussion of this at <http://language.perl.com/news/y2k.html>.
I'd love to see code to do this for an IBM business computer of the
late 50s or early 60s. I.e., IBM 702, 705, 705-III, 1401, 1410, 7010, 7070,
7080 or even the 650.
AFAIK, *NONE* of those machines had the capability of storing a binary
number into a character of memory. I suppose it might have been possible
to wedge a six-bit number into a character, but it would probably have
required a 64-character lookup table to encode (not too bad), and a loop to
decode (horribly inefficient).
I think it is necessary to understand a bit more about what was actually going
on at the time, rather than just reasoning that since modern computers are
good at storing binary integers, the programmers in the 50s and early 60s
must have been idiots.
Eric
11 Jan
11 Jan
9:59 a.m.
>Once databases started being kept on disk drives,
saving two bytes for each
>date may not have sounded like much, but it literally did save money. It
>takes fewer disk packs (and perhaps fewer drives) to store 92-byte records
>than 94-byte records. I don't know how many decisions were made on that
>basis, but you can't realistically ignore it.
There's a dozen lame excuses as to why They Did It
That Way. Few of
them make any sense. If they'd stored the year in a seven or eight
bits offset from their earliest year, instead of two ASCII or BCD
digits, they'd halve their storage requirements.
Lame excuse ?
Sorry, but there is a _big_ difference. Stored as (unsigned) BCD,
I can convert a date in just two machine instructions (UNPK and OI)
- not only the year but the whole date and maybe even time - but if
I use a binary year, I need at least 5 instructions (XR, IC, CVD,
UNPK, OI) just for the year (not to mention 8 additional bytes
of scrap mem :) - and, at least in our case, time was more important.
We had to serve up to 300 users on a 0.8 MIPS CPU (Average of 4
transactions per second) in 1980. So, instruction counting was a
serious business (and it still is !). Of course The space was also
limited, when the biggest disk available was just 144 MB - and in fact,
althrough instruction count isn't that important anymore, space still
is - If you have life data bases of more than 20 million entries, hundred
bytes more or less is just another disk drive .)
At least for this project we are finished since more than half a
year with all Y2K changes - did anybody say Europe is late ? Doing
a job is (in most cases) a silent thing and don't need any morning
and ranting about the upcomming doom - Lets wait and see.
Gruss
H.
P.S.: And for the Russian thing (Zane), there is no real difference
between a still in use PDP11 in the US, Germany or Russia - in fact,
I trust some russian military technology a more than US or German.
Tricks are alway better than transistors (Glenn Henry).
--
Ich denke, also bin ich, also gut
HRK
4 Jan
4 Jan
4 p.m.
Jim Strickland <jim(a)calico.litterbox.com> wrote:
It seems hard to believe (in retrospect) that people
really did
deliberately build software with only 2 digit years.
Oh, and one other reason: people were accustomed to only writing two digit
years when they dated things. It was natural to enter things into computers
in the same way. And it was natural to store the data in the same format
(or at least a similar format) to what the user entered.
Eric
5 Jan
5 Jan
7:07 p.m.
At 05:25 PM 04-01-99 -0700, Jim Strickland wrote:
What boggles the mind is that this is a problem at all.
It seems hard to
believe (in retrospect) that people really did deliberately build software
with only 2 digit years. I know it saved a few bytes, and yes, I remember
when a byte of memory was a significant amount, but still. How did standard
programming practice come to be so short sighted as to assume that software
infrastructure would be thrown out and replaced on a regular basis?
Well as someone who worked on a major software project (a Student Records
System) in the early 1980s in which we made the very deliberate decision
not to include the '19' in all our dates the reasoning was simple. We had a
system (a VAX-11/780) which had 1.25Mb of main memory and two 60Mb disk
drives (subsequently upgraded to an RA81 (450Mb) which I seem to recall
cost something like $60K). Memory (both disk and RAM) was in short supply
and the savings of two bytes per student record that involved dates (we had
about 20K students on file and I guess each student had about 100 records
with dates in them) was considered sufficiently significant to make that
decision.
In retrospect, with 2020 hindsight was this a good thing? Well, probably
no, and I'm certainly glad that the system has been retired (although
updating it wouldn't be that bad). To answer the obvious question as to why
we didn't use VMS date/time internally, one of the project specifications
was that we had to use readable data (ie letters and digits) for all files
to allow easy migration (and debugging).
Huw Davies | e-mail: Huw.Davies(a)latrobe.edu.au
Information Technology Services | Phone: +61 3 9479 1550 Fax: +61 3 9479 1999
La Trobe University | "If God had wanted soccer played in the
Melbourne Australia 3083 | air, the sky would be painted green"
9364
days inactive
9372
days old
22 comments
11 participants
participants (11)
-
adavie＠mad.scientist.com -
ard＠p850ug1.demon.co.uk -
ckaiser＠oa.ptloma.edu -
dastar＠ncal.verio.com -
erd＠infinet.com -
eric＠brouhaha.com -
H.Davies＠latrobe.edu.au -
Hans.Franke＠mch20.sbs.de -
jfoust＠threedee.com -
jim＠calico.litterbox.com -
meo＠netads.com