2000 and the computer
David B. Greene
bill...@aol.com (BillH1108) wrote:
>I hope to hear from someone who has really good mainframe skills who can
>put this 2000 problem into prespective. We got into a really torrid
>discussion at a MENSA meeting about the 2000 problem. I took the position
>that there is no substantial problem, but that the computer programer
>consulting firms were creating a dragon and then slaying it. I asked what
>was the "exact" description of the problem. The closest I got to an exact
>explanation was that most of the "older" computer programs looked at a
>date only by the last two numbers and for computational or other output,
>just added a "19" before it. The machines, therefore had no capability to
>write a date with any number other than 19, as the prefix. I can't
>believe that this is a "multi-billion dollar problem". One guy said that
>there are millions of mortgage lenders that will not be able to compute
>the payments. Is this real? I would just like to be told what the exact
>problem is, or be told where (preferably on the internet) that I can find
>a good exposition of this potential crisis.
OK, here's the deal, Bill. Programmers are inflating the problem to
sell the public on the need for their services as the public is getting
feed up to their eyeballs with cost over runs on defective computer
projects. That is why, right now, programmers "don't get no respect"
like real engineers and scientists do. So, to keep their collective
butts out of the unemployment line, they have rallied around their savior,
Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
because they know the problem will be easy to fix and they wll look like
heros for once and maybe even get a TV documentry on how they "saved"
civilization.
Thomas R. Truscott
>>I hope to hear from someone who has really good mainframe skills who can
>>put this 2000 problem into prespective.
This is not just a "mainframe" or even conventional "computer" problem.
We will have plenty of trouble just with the Global Positioning Systems (GPS).
For example,
http://catless.ncl.ac.uk/Risks/18.24.html#subj3
points out that many GPS receivers manufactured to date
will start malfunctioning at 0000 22 Aug 1999.
This is due to a roll-over that is part of the GPS spec.
(Apparently one or two manufacturers noticed the hazard,
but kept quiet to gain a competitive advantage.)
Since GPS prices have been following, the cheapest fix
is probably to to throw away the other units and buy new ones.
But potential GPS y2k problems go much deeper than that.
A recent study uncovered about a dozens different ways that GPS
can go awry due to problems related to y2k.
(Sorry, I don't have a reference.)
One aspect of this problem is that digital systems use finite arithmetic,
somewhat like a car odometer, and when the number "rolls over"
bad things can happen unless special care is taken.
But only rarely is such care taken, and even then people often get it wrong.
This has caused numerous problems in computers over the years.
The special thing about the year 2000 is that LOTS of
odometers roll over then, and we can expect LOTS of problems.
The problem is not so much the difficulty of fixing the problems
as it is the disruption that will be caused while the systems are down.
One source of info on the y2k problem is http://www.year2000.com
Are some people over-hyping this problem? Sure.
But that is better than what most people are doing about it.
Tom Truscott
Robert Israel
bill...@aol.com (BillH1108) wrote:
|> I hope to hear from someone who has really good mainframe skills who can
|> put this 2000 problem into prespective. We got into a really torrid
|> discussion at a MENSA meeting about the 2000 problem. I took the position
|> that there is no substantial problem, but that the computer programer
|> consulting firms were creating a dragon and then slaying it. I asked what
|> was the "exact" description of the problem. The closest I got to an exact
|> explanation was that most of the "older" computer programs looked at a
|> date only by the last two numbers and for computational or other output,
|> just added a "19" before it. The machines, therefore had no capability to
|> write a date with any number other than 19, as the prefix. I can't
|> believe that this is a "multi-billion dollar problem". One guy said that
|> there are millions of mortgage lenders that will not be able to compute
|> the payments. Is this real? I would just like to be told what the exact
|> problem is, or be told where (preferably on the internet) that I can find
|> a good exposition of this potential crisis.
Look at the comp.risks newsgroup for ongoing discussions of the Year 2000
problem. It may sometimes be exaggerated, but it is a substantial problem,
and its effects are already being felt as, e.g., many credit cards and drivers' licenses now have expiration dates >= 2000. It's not so much that the computer
can't write the date 2000, but that it confuses that date with 1900 and either rejects the data completely or calculates that your mortgage payment is 100 years overdue. Compounding the confusion is that many of the older programs are poorly
documented, and it is difficult to check whether there are going to be problems
before the problems actually arise.
Robert Israel isr...@math.ubc.ca
Department of Mathematics (604) 822-3629
University of British Columbia fax 822-6074
Vancouver, BC, Canada V6T 1Y4
Edward Edmondson
"David B. Greene" <da...@antispam.hacyon.com> wrote
>bill...@aol.com (BillH1108) wrote:
>
>>I hope to hear from someone who has really good mainframe skills who can
>>put this 2000 problem into prespective. We got into a really torrid
>>discussion at a MENSA meeting about the 2000 problem. I took the position
>>that there is no substantial problem, but that the computer programer
>>consulting firms were creating a dragon and then slaying it. I asked what
>>was the "exact" description of the problem. The closest I got to an exact
>>explanation was that most of the "older" computer programs looked at a
>>date only by the last two numbers and for computational or other output,
>>just added a "19" before it. The machines, therefore had no capability to
>>write a date with any number other than 19, as the prefix. I can't
>>believe that this is a "multi-billion dollar problem". One guy said that
>>there are millions of mortgage lenders that will not be able to compute
>>the payments. Is this real? I would just like to be told what the exact
>>problem is, or be told where (preferably on the internet) that I can find
>>a good exposition of this potential crisis.
>
>sell the public on the need for their services as the public is getting
>feed up to their eyeballs with cost over runs on defective computer
>projects. That is why, right now, programmers "don't get no respect"
>like real engineers and scientists do. So, to keep their collective
>butts out of the unemployment line, they have rallied around their savior,
>Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>because they know the problem will be easy to fix and they wll look like
>heros for once and maybe even get a TV documentry on how they "saved"
>civilization.
>
http://www.parliament.gov.uk/ [ I think ] and work through the POST
(Parliamentary Office of Science and Technology) and download the
relevant PDF Acrobat file.
--
Edward Edmondson
Feel free to contradict.
Mail me as: edw...@yendor.demon.co.uk
Jay R. Ashworth
Craig Yourdon has nothing to do with this.
And, in fact, it's already causing problems in "the real world".
Here's but one simple example:
Do you have a credit card?
They have expiration dates, some time in the future.
The terminals you swipe them through when you want to buy something
compare the expiration date on the card to today's date, to see if your
card is still valid, or should be rejected.
So, now, it's 1997, and your card expires in three years.
In 2000.
So the expiration date encoded on the card is "04/00".
You buy something, the $5/hr clerk swipes the card, the terminal says
"duh, '00'. That's less than '97'. I guess the card is expired"...
and rejects your purchase.
This has already started happening... Verifone Inc., one of the
manufacturers thereof, is working to fix the problem... but in the mean
time, several card issuers have had to recall cards expiring in 2000.
So, no, it's not a straw man, cooked up by the computer industry for
any reason at all, and it's the _height_ of malice to minimize the
problem this way.
Yes. Malice.
For more information, go read http://cnn.com/TECH/9601/2000/index.html,
and the resources it points to.
And be afraid. Be _very_ afraid.
Cheers,
-- jra
--
Jay R. Ashworth j...@scfn.thpl.lib.fl.us
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "To really blow up an investment house requires
Tampa Bay, Florida a human being." - Mark Stalzer +1 813 790 7592
Daniel Zepeda
I hate it when people that have absolutely no idea what they are talking
about chime in with misinformation and make it seem like they have got the
answers. Mr. Green, sure its a simple problem, all you have to do is change
a few lines of code to compensate. The cost and "sky is falling" comes in
because those few lines of code are buried in literally millions of lines
of code that have to be searched through and corrected. The few lines of
code have to be changed in thousands of places, making it a huge job. As a
simple illustration of the problem, suppose, Mr. Green, that I have a penny
laying on the ground face up, and a gun to your head. I say "I want the
penny face down now, or I'll shoot you." No problem right? Simple
operation, just turn the penny over, what is so difficult about that? Now,
suppose that I have an *entire salt lake* covered with face up and face
down pennies. I say "Mr. Green, I want all of the pennies face down in 1
month, or I'm going to shoot you." Simple operation, right? All you have to
find the face up pennies and turn them over. What is so hard about that?
Would you be worried? I would if I were the one having to turn the pennies
over.
Bill, there is a good discussion of the topic at
http://www.year2000.com/y2kbio.html.
Dave Rusin
bill...@aol.com (BillH1108) wrote:
>One guy said that
>there are millions of mortgage lenders that will not be able to compute
>the payments. Is this real?
This is precisely the example I use to suggest the problem is _not_ quite
as extensive as it is sometimes made out to be. Most people in the US who have
purchased a house in the last _quarter century_ have contracts which
expire in a year past 2000. Clearly banks have for some time had software
which can express these dates, and even (for example) provide payment
schedules which include them.
More generally, the image presented of a vast blinking-out of everything
computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
far-fetched. Certainly a number of unexpected glitches will occur from
computers on autopilot, but we expect most major systems will be the
objects of at least some experimentation before 2000, during which time
the likely problems will be discovered.
Having said that, I would like to point out that it _is_ important to
run such experiments! Especially for complex integrated systems, time is
running out if it is to be hoped that corrections or replacements can be
in place in 33 months. Massive operations such as the IRS are already
working on this issue, but all of us who use machines have a duty to
see what our hardware and software will do. Unless you take the date from
some external source, these experiments are usually easy.
For example, if you use a PC, set the date to 31 Dec 1999 and
the time to 23:58, shut it off, and come back in 3 minutes. If the date
is not 1 Jan 2000, you now know that your operating system will feed
incorrect data to all your programs after that day; you have a couple of
years to save up for a new machine. I'm in that position (although there's
an old XT in the basement which thinks every day is 1 Jan 1980 and it can
still crunch numbers, so I keep it; my present machine may have the same fate).
Do you use an old version of Quicken? Try writing a check dated in 2000.
It may not let you do so. I don't want to have to run out for new software
while trying to pay bills in Jan 2000, so I tested my copy and now I know it's
time to upgrade.
Little of my other software is date-dependent. Nowadays when I notice
a date field, I try crossing the century mark. Software that messes up
I don't use. Fortunately I'm not very integrated into the date-conscious
world anyway :-).
If you're basically computer-savvy, and use fairly limited systems,
you can discharge your responsibilities in the Y2K problem. If you're
prone to paranoia, or if you're in charge of a major date-dependent
system, it's past time to begin scrutiny.
dave
Dene Bebbington
"David B. Greene" <da...@antispam.hacyon.com> wrote:
>bill...@aol.com (BillH1108) wrote:
>
>>I hope to hear from someone who has really good mainframe skills who can
>>put this 2000 problem into prespective. We got into a really torrid
>>discussion at a MENSA meeting about the 2000 problem. I took the position
>>that there is no substantial problem, but that the computer programer
>>consulting firms were creating a dragon and then slaying it. I asked what
>>was the "exact" description of the problem. The closest I got to an exact
>>explanation was that most of the "older" computer programs looked at a
>>date only by the last two numbers and for computational or other output,
>>just added a "19" before it. The machines, therefore had no capability to
>>write a date with any number other than 19, as the prefix. I can't
>>there are millions of mortgage lenders that will not be able to compute
>>problem is, or be told where (preferably on the internet) that I can find
>>a good exposition of this potential crisis.
>
>OK, here's the deal, Bill. Programmers are inflating the problem to
>sell the public on the need for their services as the public is getting
>feed up to their eyeballs with cost over runs on defective computer
>projects.
Whilst programmers are largely responsible for the problem, they are
definitely not inflating this problem which does exist, consider just
how much software there is in the world and this is no minor issue.
There are many applications which will produce incorrect results in the
year 2000, and just the investigative work on projects will be enormous,
plus there's then the costs of fixing and regression testing.
> That is why, right now, programmers "don't get no respect"
>like real engineers and scientists do. So, to keep their collective
>butts out of the unemployment line,
Hardly, here in Britain there's plenty of work in software, with demand
for programmers apparently outstripping supply, at least supply of good
people with the right skills. The year 2000 problem will just lead to
extra work on top of this, work which I might add that many programmers
do not get very excited about - after all who wants to trawl other
people's code just to fix date based bugs?!
> they have rallied around their savior,
>Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>because they know the problem will be easy to fix and they wll look like
>heros for once and maybe even get a TV documentry on how they "saved"
>civilization.
Well, for all sorts of reasons programmers are the culprit in the first
place, so they're hardly heroes. As for Yourdon he is not viewed as a
saviour by anyone in the software industry that I've spoken to.
--
Dene Bebbington
"I mean, who would have noticed | "It is impossible to enjoy idling
another madman around here?!" | thoroughly unless one has plenty
- Blackadder | of work to do." - Jerome K Jerome
Eugene A. Pallat
David B. Greene <da...@antispam.hacyon.com> wrote in article
<5ikkij$g9f$4...@brokaw.wa.com>...
> bill...@aol.com (BillH1108) wrote:
>
> >I hope to hear from someone who has really good mainframe skills who can
> >put this 2000 problem into prespective. We got into a really torrid
> >discussion at a MENSA meeting about the 2000 problem. I took the
position
> >that there is no substantial problem
snip
>
> OK, here's the deal, Bill. Programmers are inflating the problem to
> sell the public on the need for their services as the public is getting
> feed up to their eyeballs with cost over runs on defective computer
> projects
snip
The problem is far worse that you people can even imagine. There are
already people who have had credit card purchases rejected because the
expiration date of "00" interprets to 1900 - ergo expired card.
The are computer systems that WILL lockup or crash. On the mainframes,
tape expiration dates are of the form YYDDD and they will automatically be
scratched.
Whether you realize it or not, the companies that do are almost panic
stricken The "dinosaur" COBOL programmers are getting big bucks to fix
this problem.
Try setting the date and time on your PC to 12/21/99 24:55 and power off.
Turn it back on after 10 minutes and see what happens. Most of them will
have a problem. Supposedly NT can survive.
Remove the '.' from orion.data for sending email to me.
Orion Data Systems
Solicitations to me must be pre-approved in writing
by me after soliciitor pays $1,000 US per incident.
Solicitations sent to me are proof you accept this
notice and will send a certified check forthwith.
Larry Anderson & Diane Hare
> bill...@aol.com (BillH1108) wrote:
>
> >I hope to hear from someone who has really good mainframe skills who can
> >put this 2000 problem into prespective. We got into a really torrid
> >discussion at a MENSA meeting about the 2000 problem. I took the position
> >consulting firms were creating a dragon and then slaying it. I asked what
> >was the "exact" description of the problem. The closest I got to an exact
> >explanation was that most of the "older" computer programs looked at a
> >date only by the last two numbers and for computational or other output,
> >just added a "19" before it. The machines, therefore had no capability to
> >write a date with any number other than 19, as the prefix. I can't
> >believe that this is a "multi-billion dollar problem". One guy said that
> >there are millions of mortgage lenders that will not be able to compute
> >the payments. Is this real? I would just like to be told what the exact
> >problem is, or be told where (preferably on the internet) that I can find
> >a good exposition of this potential crisis.
>
>From what I've read and my opinion...(It's an opinion, not an invitation
to flaming, ok?)
* Many programs that use the two digit years are older programs designed
for older machines (some of these programs were originally developed in
the 60s and 70s).
* Some of these programs do not have source code (or incomplete source
code, lost over the years).
* Some of the languages/compilers used to create said programs cannot
operate on the current hardware the programs are currently running,
making the source code inaccessible unless translated to newer
development platforms.
* There are vast amounts of data containing two digit years that will
have to be interpreted when comparing against updated data, or read and
re-recorded in the new format (think birthdates in DMV, Social Security,
etc. files.)
* Federal/State Government are doing cost reductions and does not have
any inclination to fund any data/program conversions, so many agencies
have to do this extra work (as well as performing their normal work, on
schedule, with the same -or possibly cut- budget.)
* There are a bunch of different schemes to correcting the year 2000
problem (from 2 to 4 digit conversion to offset algorithms, etc.) and
some programmers are stubburn about not using 'their idea' (nothing new
there).
* If I were a programmer on one of those projects I would be inclined to
do a lot more updating to the code than just the date, and that of
course takes time...
* The computer consulting firms ARE hyping it up in hopes to rake in the
bucks, but since government is buracracy and and more re-active than
pro-active, they will proabably stall till the last minute and panic at
the end.
Larry Anderson
P.S. Most of the dilemma will be for projects that track spans of time
between dates, such things as age calculation, billing periods, fiscal
years, etc. You will see alot of folks freak out on Jan 1, 2000 because
their accounting packages mess up. After that it will be just mainly
those with date/time span tracking problems. 12/31/99 to 01/01/00. is
-99 years to a computer.
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Visit our web page at: http://www.goldrush.com/~foxnhare
Call our BBS (Silicon Realms BBS 300-2400 baud) at: (209) 754-1363
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Maryse Turcotte
Hello!
I've always wondered why programmers didn't use 4 digits date in the
first place. The best explanation I could come up with was of course that
it must have been a way to economize on storage and time of execution which
I heard was very costly back then... Still, I find it hard to believe
that they didn't anticipate the problem which wasn't that far away...
???
Thanks in advance.
Maryse Turcotte
E-mail : maryse....@sympatico.ca
do...@no.spam
In article <334F0C...@sympatico.ca>, maryse....@sympatico.ca
says...
> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course that
> it must have been a way to economize on storage and time of execution which
> I heard was very costly back then... Still, I find it hard to believe
> that they didn't anticipate the problem which wasn't that far away...
Well....
'WE' had to scrape and scrounge every last bit of RAM
and CPU cycles to make 'our' software usable.
As to anticipating the problem:
a) Not my problem.
b) Who woulda thought someone would still be using this in 20xx?
c) It works, doesn't it?
But seriously folks,
How many of you are going to need new checkbooks on
1/1/00?
All my checks start with '19__'
Who the hell is going to honor a check written in 1900?
My thoughts, your actual thoughts may vary,
Doug
p.s.
Yes, I'm a programmer.
--
Remove 'REMOVE_ME' from address below to reply
mailto: spamless@REMOVE_MEpacbell.net
Spam: It's not just for breakfast anymore.
For help in joining the war on SPAM:
http://www.rlabs.com/sputum/sputools.html
http://kryten.eng.monash.edu.au/gspam.html
http://spam.abuse.net/spam/
http://www.cnet.com/Content/Features/Howto/Spam/ss02.html
David Carrell
In article <5ilu26$6uo$7...@news.usf.edu>,
j...@scfn.thpl.lib.fl.us (Jay R. Ashworth) wrote:
>David B. Greene (da...@antispam.hacyon.com) wrote:
>: >I hope to hear from someone who has really good mainframe skills who can
>: >put this 2000 problem into prespective. We got into a really torrid
>: >discussion at a MENSA meeting about the 2000 problem. I took the
position
>: >that there is no substantial problem, but that the computer programer
>: >consulting firms were creating a dragon and then slaying it. I asked
what
>: >was the "exact" description of the problem. The closest I got to an
exact
>: >explanation was that most of the "older" computer programs looked at a
>: >date only by the last two numbers and for computational or other output,
>: >just added a "19" before it. The machines, therefore had no capability
to
>: >write a date with any number other than 19, as the prefix. I can't
>: >believe that this is a "multi-billion dollar problem". One guy said
that
>: >there are millions of mortgage lenders that will not be able to compute
>: >the payments. Is this real? I would just like to be told what the exact
>: >problem is, or be told where (preferably on the internet) that I can
find
>: >a good exposition of this potential crisis.
>
>: feed up to their eyeballs with cost over runs on defective computer
>: Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>: because they know the problem will be easy to fix and they wll look like
>: heros for once and maybe even get a TV documentry on how they "saved"
>: civilization.
>
>
>Here's but one simple example:
>
< CLIPPED >
Here is another about to hit some users of VMS fro DEC.
Briefly, Unix (and also VMS) use(d) the time origin of 1-Jan-1970. On
19-May-1997 the time delta from then will be 10,000 days. Some VMS system
calls will fail when the time delta becomes >= 10,000. So on 19-May-1997 (or
there about, some VAXEN will experience anomalies. For more precise info and
details see:
http://www.openvms.digital.com/openvms/letter.html
This is a much smaller (and easier) problem to fix. Yes, I feel sometimes
the media (general and computing) a) get the problem wrong and b) exagerate
its significance but I do know the a) it is a real problem, b) will have
financial impact, c) is going to 'bite' some people/companies.
Another factoid to lend credance to the problem is that the SEC (the stock
market guys) are interested in companies plans/response. Not because they
think the market will be shut down but they feel that the cost of the fix
AND/OR the cost of NOT fixing the problem in time MAY impact some companies
financial performance significantly.
No I do not work in the computer field directly. I am only a user (work and
recreation) who is working/watching to minimize any impact on me and mine.
DAC
-------------------------------------------------------------------------
David Carrell All comments above are mine, and
Process Control Engineer do not necessarily reflect the
Conoco, Inc. opinions of Dupont and/or Conoco,
*carrelda*@pore.dnet.dupont.com* [and why should they]
(return address altered to reduce
adds, remove *'s for real address)
akrolak millcomm.com
In article <5ikkij$g9f$4...@brokaw.wa.com>, da...@antispam.hacyon.com says...
>OK, here's the deal, Bill. Programmers are inflating the problem to
>sell the public on the need for their services as the public is getting
>feed up to their eyeballs with cost over runs on defective computer
>projects. That is why, right now, programmers "don't get no respect"
>like real engineers and scientists do. So, to keep their collective
>butts out of the unemployment line, they have rallied around their savior,
>Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
>because they know the problem will be easy to fix and they wll look like
>heros for once and maybe even get a TV documentry on how they "saved"
>civilization.
>
I used to work for a company that did the IS for a major auto
manufacturer. Year 2000 problems were already being addressed,
though generally as a side issue, but we did encounter stuff
where fixes had to be made immediately. For example, consumer
relations cases were assigned 'expiration' dates - how long we
kept the case in the online database before we purged it out. Different
types of cases get kept for different lengths of time. In january
1995 we had to change the database to a 4 digit year - some cases
needed expiration dates 5 years out.
In most cases, data isn't independant - its used by multiple programs,
sometimes sent to multiple companies. Data format changes must be
carefully coordinated, or you break multiple processes.
Worse yet, you may be running object code that you no longer have
the source for, or, if you do have the source, its written in a
much older version of a language, and you need to modify it just
to get it to compile.
It adds up.
--
Paul Krolak
akrolak(at)millcomm.com
Bruce Glassford
On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
wrote:
>bill...@aol.com (BillH1108) wrote:
<snip>
>
>More generally, the image presented of a vast blinking-out of everything
>computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
>far-fetched. Certainly a number of unexpected glitches will occur from
>computers on autopilot, but we expect most major systems will be the
>objects of at least some experimentation before 2000, during which time
>the likely problems will be discovered.
>
<snip>
An interesting discussion arose at lunch today about the Y2K problem
(hey, we're all in the computing/management consulting business - why
talk about something interesting?). Someone made the point that he
didn't want to rely on any imbedded system on January 1, 2000, but
didn't worry about financial systems until December 31, 2000, when
they'll all go crazy trying to do year end. Also, there will be an
interesting test on March 1, 2000 - let's see how many programmers
caught the fact there's no February 29, 2000. (me being lazy, looked
up my old date calculation routine - it will work for 2000, but failed
for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
in the leap year if divided by 100 and the non-leap year if divided by
400 routine)
... Bruce
Lulu of the Lotus-Eaters
*}>I hope to hear from someone who has really good mainframe skills who can
*}>put this 2000 problem into prespective. We got into a really torrid
*}>discussion at a MENSA meeting about the 2000 problem.
Ummm gee... somehow this confirms everything I ever thought about MENSA.
Yours, Lulu (nope, no number for me)...
quilty@ _/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: \_\_\_\_ n o
philos. _/_/ Postmodern Enterprises \_\_
umass. _/_/ \_\_ d o
edu _/_/_/ IN A WORLD W/O WALLS, THERE WOULD BE NO GATES \_\_\_ z e
Chas ('cha-s vb)
Correction: There is a February 29th in the year 2000. The rules are:
1. Leap year if year is divisible by four.
2. Not Leap year if year is divisible by 100.
3. Leap year if year is divisible by 400.
--B. Chas Parisher
Tony Quinn
In article <334f01fe...@news.mindspring.com>, Bruce Glassford
<bglas...@earthling.net> writes
>An interesting discussion arose at lunch today about the Y2K problem
>(hey, we're all in the computing/management consulting business - why
>talk about something interesting?). Someone made the point that he
>didn't want to rely on any imbedded system on January 1, 2000, but
>didn't worry about financial systems until December 31, 2000, when
>they'll all go crazy trying to do year end. Also, there will be an
>interesting test on March 1, 2000 - let's see how many programmers
>caught the fact there's no February 29, 2000. (me being lazy, looked
>up my old date calculation routine - it will work for 2000, but failed
>for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
>in the leap year if divided by 100 and the non-leap year if divided by
>400 routine)
I'm glad you don't write s/w for me - your leap-year algorithm is arse
about face - non-leap when not dividible by 400, leap WHEN divisible by
400.
--
--------------------------------------------------------------
Tony Quinn --- The Voice of Insanity
replies to tony...@sixpints.demon.co.uk
--------------------------------------------------------------
Rick Tyler
On 11 Apr 1997 23:48:09 GMT, "Eugene A. Pallat"
<eapa...@orion.data.com> wrote:
:David B. Greene <da...@antispam.hacyon.com> wrote in article
:<5ikkij$g9f$4...@brokaw.wa.com>...
:> bill...@aol.com (BillH1108) wrote:
:The problem is far worse that you people can even imagine.
:The are computer systems that WILL lockup or crash.
:On the mainframes,tape expiration dates are of the form YYDDD and they
:will automatically be scratched.
:
:Whether you realize it or not, the companies that do are almost panic
:stricken.
:
:Try setting the date and time on your PC to 12/21/99 24:55 and power off.
:Turn it back on after 10 minutes and see what happens. Most of them will
:have a problem.
So ...
"Drink, drink, everyone drink,
It's not as bad as they used to think,
With every Manhattan your stomach will flatten,
So drink, drink, drink."
-- Rick "Ashes to ashes, dust to dust, if the A-bomb don't get you,
Strontium must" Tyler
-----------------------------------------------------
"I can 'splain it to you, but I can't understand it
for you" -- Lizz Braver
+ The real address would leave out "goaway" +
Paul Keinänen
"Eugene A. Pallat" <eapa...@orion.data.com> wrote:
>David B. Greene <da...@antispam.hacyon.com> wrote in article
>>
>> OK, here's the deal, Bill. Programmers are inflating the problem to
>> sell the public on the need for their services as the public is getting
>> feed up to their eyeballs with cost over runs on defective computer
>> projects
>snip
>
>The problem is far worse that you people can even imagine. There are
>already people who have had credit card purchases rejected because the
>expiration date of "00" interprets to 1900 - ergo expired card.
I did not know that you have credit cards that are valid for many
years, but anyway, there is an easy solution to this problem. All
cards issued before the year 2000 should have a validity date of Dec
31, 1999 (or earlier). New cards are delivered to all customers in
December 1999 and the new cards are valid _starting_ from Jan 1, 2000
and valid until any convenient date in year 200x. Any systems
comparing only the last two digits of the year would still work with
the new cards in year 2000. This arrangement would not need more cards
if the validity period of the old cards would be extended to Dec 31,
1999 if the normal validity period would end in say, August 1999. With
colorful new "2000" cards you could turn the date problem to a great
PR stunt :-).
My point is, in certain circumstances there can be other ways to work
around the date problems than fixing the program.
Brett Frankenberger
In article <334F0C...@sympatico.ca>,
Maryse Turcotte <maryse....@sympatico.ca> wrote:
>Hello!
>
>I've always wondered why programmers didn't use 4 digits date in the
>first place. The best explanation I could come up with was of course that
>it must have been a way to economize on storage and time of execution which
>I heard was very costly back then...
There's many reasons ... DASD (hard disk) was expensive, core (RAM) was
expensive, a lot of data entry was done via punched cards which
limited you to 80 characters per record, so including the "19" cost you
2.5% of the available columns ... telecom lines were slow so there was a
marginal improvement from not sending 19 to all the remote terminals
... and so on.
>Still, I find it hard to believe
>that they didn't anticipate the problem which wasn't that far away...
They didn't expect that their code would be in use 30 years from when
they wrote it. The 32 bit time in Unix wraps in 2038 or something like
that ... how many programmers writing Unix code today are writing code
that will properly handle that? (No doubt some are, but many aren't).
--
- Brett (bre...@netcom.com)
------------------------------------------------------------------------------
... Coming soon to a | Brett Frankenberger
.sig near you ... a Humorous Quote ... | bre...@netcom.com
Tony Buckland
In article <xxod8s1...@ringer.cs.utsa.edu>,
Daniel Zepeda <dze...@ringer.cs.utsa.edu> wrote:
>
>I hate it when people that have absolutely no idea what they are talking
>about chime in with misinformation and make it seem like they have got the
>answers. Mr. Green, sure its a simple problem, all you have to do is change
>a few lines of code to compensate. ...
Those few lines of code, however, often access and modify data structures
in which only two characters were reserved to express a date. Changing the
code will be worse than useless unless all those structures are expanded.
Perhaps dozens of routines, perhaps alignment problems where the next
item in the structure was put on a doubleword boundary, perhaps memory
allocation routines that manage instances of the structure; you could end
up with thousands of lines to change, in source which most likely is
minimally documented, in languages and versions thereof that haven't been
used in the organization for years -- and sometimes the source no longer
even exists.
James M. Curran
In <<5ilu26$6uo$7...@news.usf.edu>>,
>So, no, it's not a straw man, cooked up by the computer industry for
>any reason at all, and it's the _height_ of malice to minimize the
>problem this way.
>Yes. Malice.
Well, it's not a "strawman" but it is blown way out of proportion.
Bank's won't have problems with mortgages --- Thay already had the
problems back in 1970 -- when a thirty year mortgage ended in 2000 --
and dealt with it then. Social Security Admin had to deal with this
problem back when the first guy born in 1935 (retiring in 2000) asked
for a SS card.
Truth,
James
Eugene A. Pallat
do...@no.spam wrote in article
<MPG.db8bdce6...@news.pacbell.net>...snip
> But seriously folks,
> How many of you are going to need new checkbooks on
> 1/1/00?
>
> All my checks start with '19__'
> Who the hell is going to honor a check written in 1900?
>
> My thoughts, your actual thoughts may vary,
My bank has the printers producing checks with no year. That means that
they could be used in 3417. :-)
Drox
Maryse Turcotte wrote:
>
> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course that
> it must have been a way to economize on storage and time of execution which
> that they didn't anticipate the problem which wasn't that far away...
Yes, storage was at a premium then, and any extra bits one could squeeze
out of a program was money in the bank, so to speak, so programmers
economized wherever they could. Also, keep in mind that this started
back in the 50's and 60's (there - I'm doing it myself. Should have
said 1950's and 1960's) and the millenium was a very long way away yet,
at least in computer terms. If computer technology had developed a few
decades earlier, the century-turnaround might have been on people's
minds more (having happened more recently), and they might have
accounted for it in their programming. If the development had been
delayed a few more decades the impending millenium would almost
certainly have been considered in the way programmers wrote their
programs. Guess it was just bad luck that early computers with their
expensive memory came along when they did. Oh well...
-Drox
Quantum Leaper
Eugene A. Pallat wrote:
>
> do...@no.spam wrote in article
> <MPG.db8bdce6...@news.pacbell.net>...
> > In article <334F0C...@sympatico.ca>, maryse....@sympatico.ca
> > All my checks start with '19__'
> > Who the hell is going to honor a check written in 1900?
> >
> > My thoughts, your actual thoughts may vary,
>
> My bank has the printers producing checks with no year. That means that
> they could be used in 3417. :-)
>
Same with my checks, it says DATE, but look at the deposit slips in the
back? My say 19__ as a date field. So I can write checks til the end
of time but I just can't deposit any money! ;)
Bruce Glassford
On 12 Apr 1997 05:22:28 GMT, ch...@ncsu.edu (Chas (\'cha-s\ vb)) wrote:
>On Sat, 12 Apr 1997 03:34:51 GMT, Bruce Glassford <bglas...@earthling.net> wrote:
>>On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
>>wrote:
>>
>>>bill...@aol.com (BillH1108) wrote:
>><snip>
>>>
>>>More generally, the image presented of a vast blinking-out of everything
>>>computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
>>>far-fetched. Certainly a number of unexpected glitches will occur from
>>>computers on autopilot, but we expect most major systems will be the
>>>objects of at least some experimentation before 2000, during which time
>>>the likely problems will be discovered.
>>>
>><snip>
>>An interesting discussion arose at lunch today about the Y2K problem
>>(hey, we're all in the computing/management consulting business - why
>>talk about something interesting?). Someone made the point that he
>>didn't want to rely on any imbedded system on January 1, 2000, but
>>didn't worry about financial systems until December 31, 2000, when
>>they'll all go crazy trying to do year end. Also, there will be an
>>interesting test on March 1, 2000 - let's see how many programmers
>>caught the fact there's no February 29, 2000. (me being lazy, looked
>>up my old date calculation routine - it will work for 2000, but failed
>>for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
>>in the leap year if divided by 100 and the non-leap year if divided by
>>400 routine)
>
>Correction: There is a February 29th in the year 2000. The rules are:
>
>1. Leap year if year is divisible by four.
>2. Not Leap year if year is divisible by 100.
>3. Leap year if year is divisible by 400.
>
>--B. Chas Parisher
Good thing I don't write date routines any more, eh? <blush>
Never could remember that stuff - I tend to just check calendars.
Thanks for the correction.
... Bruce
Hugh Young
In <334f01fe...@news.mindspring.com> bglas...@earthling.net (Bruce
Glassford) wrote:
>On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
>wrote:
>
>>bill...@aol.com (BillH1108) wrote:
>>Also, there will be an
>interesting test on March 1, 2000 - let's see how many programmers
>caught the fact there's no February 29, 2000. (me being lazy, looked
>up my old date calculation routine - it will work for 2000, but failed
>for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
>in the leap year if divided by 100 and the non-leap year if divided by
>400 routine)
>... Bruce
No, its' the other way around. There wasn't a Feb 29 1900 but there will be
one in 2000.
--
Hugh Young, Pukerua Bay, Nuclear-free Aotearoa / NEW ZEALAND
#158 Welcome to Earth. Do not leave your vehicle.
Don McKenzie
In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
<eapa...@orion.data.com> wrote:
[snip]
> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
> Turn it back on after 10 minutes and see what happens. Most of them will
> have a problem. Supposedly NT can survive.
>
Or use a Mac. No problem.
--
Don McKenzie <mca...@wavenet.com>
Republican environmentalists:
Check out <http://www.rep.org>
ecsd
Daniel Zepeda wrote:
> Bill, there is a good discussion of the topic at
> http://www.year2000.com/y2kbio.html.
>
> da...@antispam.hacyon.com (David B. Greene) writes:
> >
> > bill...@aol.com (BillH1108) wrote:
> >
> > >I hope to hear from someone who has really good mainframe skills who can
> > >put this 2000 problem into prespective. We got into a really torrid
> > >discussion at a MENSA meeting about the 2000 problem. I took the position
> > >that there is no substantial problem, but that the computer programer
> > >consulting firms were creating a dragon and then slaying it. I asked what
> > >was the "exact" description of the problem. The closest I got to an exact
> > >explanation was that most of the "older" computer programs looked at a
> > >date only by the last two numbers and for computational or other output,
> > >just added a "19" before it. The machines, therefore had no capability to
> > >write a date with any number other than 19, as the prefix. I can't
> > >believe that this is a "multi-billion dollar problem". One guy said that
> > >there are millions of mortgage lenders that will not be able to compute
> > >the payments. Is this real? I would just like to be told what the exact
> > >problem is, or be told where (preferably on the internet) that I can find
> > >a good exposition of this potential crisis.
> >
> > OK, here's the deal, Bill. Programmers are inflating the problem to
> > sell the public on the need for their services as the public is getting
> > feed up to their eyeballs with cost over runs on defective computer
> > projects. That is why, right now, programmers "don't get no respect"
> > like real engineers and scientists do. So, to keep their collective
> > butts out of the unemployment line, they have rallied around their savior,
> > Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
> > because they know the problem will be easy to fix and they wll look like
> > heros for once and maybe even get a TV documentry on how they "saved"
> > civilization.
Whoever said "the problem is not real" never coded any systems code
that related to the date.
The poster who mentioned (here or elsewhere) that tapes will be
scratched actually added a very important observation, though I don't
know how the age calculations will be handled.
I'm quite glad that everything I coded from early on handled this
and will not expire until between 2069 and 2088, or even 9999,
depending.
The problem is not only finding and correcting the code, but in many
cases the source code NO LONGER EXISTS. It won't just be a matter
of correcting the code, but making sure the code will still compile,
still makes sense in the current context, etc. and no doubt some
millions and millions and millions of lines of code will just have
to BE REWRITTEN FROM SCRATCH.
Worse (tee hee) yet is that hundreds and thousands of programmers
will have their noses rubbed into MVS system code and Cobol ...
fate worse than death. No wonder there are so many conservatives
at large ... anyone whose job that is can't be liberal after a
few grueling years.
On the upside, they will make shitloads of money.
On the downside, those costs will be passed on to YOU,
o dear consumer.
I remember JCL. God, what fun.
Eugene A. Pallat
Maryse Turcotte <maryse....@sympatico.ca> wrote in article
<334F0C...@sympatico.ca>...
> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course
that
> it must have been a way to economize on storage and time of execution
which
> I heard was very costly back then... Still, I find it hard to believe
> that they didn't anticipate the problem which wasn't that far away...
I did work for a government agency that used ONE digit years with the
excuse that "No program / project lasted more than 10 years."
Then the exceptions. For this year, you have to check this other field and
if it's so and so, it's that year. And if it's that value, it's another
year, ad nauseum.
They wasted 20 to 30 times as much space figuring out what they actually
had compared to using 4 digit years in the first place.
And believe me, that was the least of the probems with their programs.
Clive D.W. Feather
In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
>The problem is far worse that you people can even imagine. There are
>already people who have had credit card purchases rejected because the
>expiration date of "00" interprets to 1900 - ergo expired card.
Or even 12/99 - see my posting to comp.risks a month or two ago.
>Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>Turn it back on after 10 minutes and see what happens. Most of them will
>have a problem.
If it lets you set that date and time, you've already got problems.
--
Clive D.W. Feather | Director of Software Development | Home email:
Tel: +44 181 371 1138 | Demon Internet Ltd. | <cl...@davros.org>
Fax: +44 181 371 1037 | <cl...@demon.net> | Abuse:
Written on my laptop; please observe the Reply-To address | <cl...@bofh.org>
Clive D.W. Feather
In article <33553d1d....@news.sci.fi>, =?iso-
8859-1?q?Paul_Kein=E4nen?= <kein...@sci.fi> writes
>I did not know that you have credit cards that are valid for many
>years, but anyway, there is an easy solution to this problem. All
>cards issued before the year 2000 should have a validity date of Dec
>31, 1999 (or earlier). New cards are delivered to all customers in
>December 1999 and the new cards are valid _starting_ from Jan 1, 2000
>and valid until any convenient date in year 200x.
Sheesh !
To add to all the other hassles, you want to multiply the workload of
the renewals department by 36 ? [or 24 or 48, depending on your bank]
DaveHatunen
In article <01bc46d2$5a0402a0$30a036cf@alpha>,
Eugene A. Pallat <eapa...@orion.data.com> wrote:
[...]
>Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>Turn it back on after 10 minutes and see what happens. Most of them will
>have a problem. Supposedly NT can survive.
You mean it won't go to 12/22/99?
--
*********** DAVE HATUNEN (hat...@netcom.com) ***********
* In the land of the blind, the one-eyed man is king... *
* Until they find out he can see, then they kill him *
*********************************************************
Peter de Jager
In article <334f01fe...@news.mindspring.com>,
bglas...@earthling.net (Bruce Glassford) wrote:
let's see how many programmers
> caught the fact there's no February 29, 2000. (me being lazy, looked
> up my old date calculation routine - it will work for 2000, but failed
> for 1900. Sloppiness here equals extreme accuracy :-) - forgot to put
> in the leap year if divided by 100 and the non-leap year if divided by
> 400 routine)
> ... Bruce
Sigh.... here we go again...
There is a Feb 29th 2000
The rule is... if it's evenly divisible by 4 it's a leap year...
unless it's evenly divisible by 100 in which case it isn't
unless it's ALSO evenly divisible by 400 in which case it is
Sigh...
Please... pull out the encylopedia Britannica
Look under Gregorian calendar
sigh...
And we think we're capable of solving the Year 2000 problem when we
can't even figure out the leap year rule... ????
Peter de Jager
In article <5iob49$n...@lal.interserv.com>, James...@CIS.CompuServe.com
(James M. Curran) wrote:
ahem... consider the following please...
The end date of a mortgage had to handle the century rollover because
in 1970 a 30 yr mortgage would already have an end dat there... so the
programmer wrote the program to accomdate the situation...
However... the START date of the mortgage in 1970 did NOT have to
handle 2000+ and there they typically only used a 2 digit date for 'start
dates'...
The beauty about this little problem... is that we'll very soon be able
to see who was wrong about this issue... the weird thing is that I hope I
am.
Roy Dent
In message <334f01fe...@news.mindspring.com>bglas...@earthling.net, bglas...@earthling.net said:
> ==========
> alt.folklore.urban #91, 2338 chars, Apr 12 03:34 97
> From: bglas...@earthling.net,
> ----------
> Article: 263388 of alt.folklore.urban
> Xref: cix.compulink.co.uk rec.org.mensa:160615 sci.math:132384 sci.misc:18
> 917 sci.skeptic:208918 comp.misc:25333 alt.folklore.computers:119244 alt
> science:33635 alt.folklore.urban:263388
> Path: cix.compulink.co.uk!betanews.compulink.co.uk!dispatch.news.demon.net
> !demon!feed1.news.erols.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.c
> ndspring.com!usenet
> From: bglas...@earthling.net (Bruce Glassford)
> Newsgroups: rec.org.mensa,sci.math,sci.misc,sci.skeptic,comp.misc,alt.folk
> Subject: Re: 2000 and the computer
> Date: Sat, 12 Apr 1997 03:34:51 GMT
> Organization: MindSpring Enterprises
> Message-ID: <334f01fe...@news.mindspring.com>
> References: <19970410182...@ladder01.news.aol.com> <5ikkij$g9f$4@
> NNTP-Posting-Host: ip137.washington6.dc.pub-ip.psi.net
> X-Server-Date: 12 Apr 1997 03:35:14 GMT
> X-Newsreader: Forte Free Agent 1.1/32.230
> Lines: 28
>
>
> On 11 Apr 1997 21:14:35 GMT, ru...@vesuvius.math.niu.edu (Dave Rusin)
> wrote:
>
>> bill...@aol.com (BillH1108) wrote:
>>
>> More generally, the image presented of a vast blinking-out of everything
>> computer-controlled at the stroke of midnight, 1 Jan 2000, is a little
>> far-fetched. Certainly a number of unexpected glitches will occur from
>> computers on autopilot, but we expect most major systems will be the
>> objects of at least some experimentation before 2000, during which time
>> the likely problems will be discovered.
>>
> <snip> An interesting discussion arose at lunch today about the Y2K
> problem (hey, we're all in the computing/management consulting business -
> why talk about something interesting?). Someone made the point that he
> didn't want to rely on any imbedded system on January 1, 2000, but didn't
> worry about financial systems until December 31, 2000, when they'll all
> on March 1, 2000 - let's see how many programmers caught the fact there's
> no February 29, 2000. (me being lazy, looked up my old date calculation
> routine - it will work for 2000, but failed for 1900. Sloppiness here
> equals extreme accuracy :-) - forgot to put in the leap year if divided
> by 100 and the non-leap year if divided by 400 routine) ... Bruce
>
Oh boy, have you got a *problem* Bruce!
I may not be a hot computing/management bod, but I can read and divide
2000 by 400 in my head without computer assistance. You _really_ should
be able to locate this kind of information for yourself but, as you seem
unable, let me quote this from Whitaker's Almanac which sums things up
pretty concisely:
" A year is a leap year if the date of the year is divisible by four
without remainder, unless it is the _last_ (my emphasis) year of the
century. The last year of a century is a leap year only if its number is
divisible by 400 without remainder, e.g. the years 1800 and 1900 had only
365 days but the year 2000 will have 366 days. "
Check it out for yourself, unless you care to wait until Tuesday 29th
February 2000 comes around!
Adn yes, did you notice that the year 2000 is the _last_ year of this
century?
Cheers,
Roy
Dene Bebbington
Don McKenzie <mc...@wavnet.com> wrote:
>In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
><eapa...@orion.data.com> wrote:
>
>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> Turn it back on after 10 minutes and see what happens. Most of them will
>> have a problem. Supposedly NT can survive.
>>
That's because the Mac OS wasn't written by Microsoft!!
--
Dene Bebbington
"I mean, who would have noticed | "It is impossible to enjoy idling
another madman around here?!" | thoroughly unless one has plenty
- Blackadder | of work to do." - Jerome K Jerome
Mark Zavislan
Eugene A. Pallat wrote:
>
> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
> Turn it back on after 10 minutes and see what happens. Most of them will
> have a problem. Supposedly NT can survive.
>
My PC came back with 12/22/99 00:05. No problem.
Mark "what's ten days among friends" Zavislan
--
* Mark A. Zavislan * I don't give them hell, *
* zavi...@lr.net * I just tell the truth and *
* * and they think it is hell - Truman *
Robert Billing
> I remember JCL. God, what fun.
Remember it? I've still got the manual...
--
I am Robert Billing, Christian, inventor, traveller, cook and animal
lover, I live near 0:46W 51:22N. http://www.tnglwood.demon.co.uk/
"might there be some celestial tribunal at which a crafty advocate
could get a sinner off hell? ...my heart sank at the thought of
eternal work before a jury of prejudiced saints."
Brett Frankenberger
In article <SSnrxrAU...@bebbo.demon.co.uk>,
Dene Bebbington <de...@bebbo.demon.co.uk> wrote:
>Don McKenzie <mc...@wavnet.com> wrote:
>>In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
>>
>>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>>> Turn it back on after 10 minutes and see what happens. Most of them will
>>> have a problem. Supposedly NT can survive.
DOS/Windows/NT/etc. will all survive. That will also all show the
incorrect date if the PC is vulnerable to this problem. It is not
related to the OS. (Also, YM 23:55, not 24:55).
>>Or use a Mac. No problem.
>
>That's because the Mac OS wasn't written by Microsoft!!
As much as it pains me to defend Bill, this isn't a Microsoft issue.
NT, Win95, and even DOS, handle Y2K just fine. Notice that the above
procedure requires that your PC be *powered off* at 00:00 on 1/1/00.
That's because if it on, DOS, Windows, NT, 95, whatever, will handle it
just fine -- they maintain a perfectly viable clock. The problem is
with the hardware clock on the PC, which keeps time in between reboots
and power-cycles.
It, in many cases, cannot deal with Y2K correctly. AFAIK, Bill neither
designs CMOS clocks nor writes BIOSs ... so it's not a case of
Microsoft writing non-Y2K code.
Brett Frankenberger
In article <33513E...@mail1.lr.net>,
Mark Zavislan <zavi...@mail1.lr.net> wrote:
>Eugene A. Pallat wrote:
>
>>
>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>
Did you actually try it?
Brett "25:05" Frankenberger
Bob Casanova
On Sun, 13 Apr 1997 14:23:55 GMT, hat...@netcom.com (DaveHatunen)
wrote:
>
>In article <01bc46d2$5a0402a0$30a036cf@alpha>,
>Eugene A. Pallat <eapa...@orion.data.com> wrote:
>
>[...]
>
>>Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>>Turn it back on after 10 minutes and see what happens. Most of them will
>>have a problem. Supposedly NT can survive.
>
>You mean it won't go to 12/22/99?
From 24:55?
;-)
Bob Casanova
On Sun, 13 Apr 1997 16:14:32 -0400, Mark Zavislan
<zavi...@mail1.lr.net> wrote:
>Eugene A. Pallat wrote:
>
>>
>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> Turn it back on after 10 minutes and see what happens. Most of them will
>> have a problem. Supposedly NT can survive.
>>
>
>My PC came back with 12/22/99 00:05. No problem.
Just to satisfy my curiosity, how'd you set the time to 24:55 without
an error?
"What's an extra hour in the day between friends?"
;-)
Jay R. Ashworth
James M. Curran (James...@CIS.CompuServe.com) wrote:
: In <<5ilu26$6uo$7...@news.usf.edu>>,
: j...@scfn.thpl.lib.fl.us (Jay R. Ashworth) wrote:
: >So, no, it's not a straw man, cooked up by the computer industry for
: >any reason at all, and it's the _height_ of malice to minimize the
: >problem this way.
: >Yes. Malice.
: Well, it's not a "strawman" but it is blown way out of proportion.
: Bank's won't have problems with mortgages --- Thay already had the
: problems back in 1970 -- when a thirty year mortgage ended in 2000 --
: and dealt with it then. Social Security Admin had to deal with this
: problem back when the first guy born in 1935 (retiring in 2000) asked
: for a SS card.
But the bank situation is _worse_.
They _already_ had notice...
_and they still didn't fix the OTHER systems_.
That, my friends, is _negligence_. Pure, simple, and actionable.
Cheers,
-- jr 'tell me I'm wrong' a
--
Jay R. Ashworth j...@scfn.thpl.lib.fl.us
Member of the Technical Staff Unsolicited Commercial Emailers Sued
The Suncoast Freenet "To really blow up an investment house requires
Tampa Bay, Florida a human being." - Mark Stalzer +1 813 790 7592
Eugene A. Pallat
Try setting the date and time on your PC to 12/31/99 23:55 and power off.
have a problem. Supposedly NT can survive.
OOPS! "Ffinger check" there - hit wrong key - hit 2 instead of 3 - I meant
12/31/99. Sorry about that! And a 4 instead of a 3.
Eugene A. Pallat
Robert Billing <uncl...@tnglwood.demon.co.uk> wrote in article
<860962...@tnglwood.demon.co.uk>...
> In article <334F3E6D...@transbay.net> ec...@transbay.net "ecsd"
writes:
>
> > I remember JCL. God, what fun.
>
> Remember it? I've still got the manual...
When I saw JCL when it came out, I thought they were kidding.
Unfortunately, they weren't. So I bypassed the JCL mess and wrote my own
JCL compiler (in FORTRAN) so I could ignore it. Worked fine.
Eugene A. Pallat
Try setting the date and time on your PC to 12/31/99 24:55 and power off.
have a problem. Supposedly NT can survive.
OOPS! "Ffinger check" there - hit wrong key - hit 2 instead of 3 - I meant
12/31/99. Sorry about that!
Remove the '.' from orion.data for sending email to me.
Virginia Krenn
>> I remember JCL. God, what fun.
> Remember it? I've still got the manual...
I wrote the JCL manual for our university.
Nick Bell
> (snip) I would just like to be told what the exact
> >problem is, or be told where (preferably on the internet) that I can find
> >a good exposition of this potential crisis.
Try http://www.ibm.com/IBM/year2000/ for a good resource on this.
> David Green wrote:
> OK, here's the deal, Bill. Programmers are inflating the problem to
> sell the public on the need for their services as the public is getting
> feed up to their eyeballs with cost over runs on defective computer
> projects.
that it's not programmers who are selling this, it's management. It's
also not programmers who are responsible for project overruns, it's
management (typically non-technical) who won't believe what the
programmers tell them and try to set unrealistic timescales. Read 'The
mythical man-month' by Fred Brooks, a classic description of this.
Furthermore, nobody is trying to sell this to the public, they're trying
to sell it to ... that same non-technical management that doesn't
understand the issues and doesn't want to make the intellectual effort
to do so.
> like real engineers and scientists do.
than engineers and scientists...
> So, to keep their collective
> butts out of the unemployment line, they have rallied around their savior,
> Mr. Yourdon, and adopted his "the sky is falling in the year 2000" line
> because they know the problem will be easy to fix and they wll look like
> heros for once and maybe even get a TV documentry on how they "saved"
> civilization.
million each on this. Banks aren't known for spending unnecessarily...
Supermarket suppliers have had truckloads of goods marked to expire in
year 00 sent right back from the depot because the supermarkets' systems
interpreted this as being 97 years past its expiry date ... In a similar
case, a steel works (in Australia I think) shut down at 0001 on December
31st last year because it was only expecting a 365-day year. And so on.
Fortunately I'm not involved in the programming side of things, though I
understand the details, so I have no axe to grind. I'm looking forward
to the chaos in January 2000. Or earlier, because lots of systems were
programmed to interpret 9/9/99 as the end of history (all 9s), so they
should be pretty sick on September 10th 99 too...
Millennially yours,
Nick.
grandma
>Maryse Turcotte wrote:
>
>> I've always wondered why programmers didn't use 4 digits date in the
>> first place. The best explanation I could come up with was of course that
>> it must have been a way to economize on storage and time of execution which
>> I heard was very costly back then... Still, I find it hard to believe
>> that they didn't anticipate the problem which wasn't that far away...
We got a brand new system in 1995 - we were the beta test site. And
they were using a 2 digit date. I said, Hey what about 2000. And
about 3 months later, suddenly the system would only accept a four
digit year. Our default date, incidentally is Dec 31, 1899.
Rick Tyler
On 13 Apr 1997 23:29:47 GMT, "Eugene A. Pallat"
<eapa...@orion.data.com> wrote:
>When I saw JCL when it came out, I thought they were kidding.
>Unfortunately, they weren't. So I bypassed the JCL mess and wrote my own
>JCL compiler (in FORTRAN) so I could ignore it. Worked fine.
>
I dealt with JCL when it was already getting old, so I wrote my JCL
builder in CLIST. Worked fine. Way more fun than just writing JCL
itself. Not that I saved any time or anything, it was just a more
interesting way of doing it.
Now, JES2, that was a technology ...
-- Rick "Not really that old, but I did see a 1401 doing payroll in
1985" Tyler
------------------------------------------------------------------------------
"I came in late on this thread, which of course grants me license to make wild
unsubstantiated claims based on utter ignorance." -- Kevin Vigor
+ Remove the extra stuff to e-mail +
Paul Ciszek
bre...@netcom.com (Brett Frankenberger) writes:
>As much as it pains me to defend Bill, this isn't a Microsoft issue.
>NT, Win95, and even DOS, handle Y2K just fine. Notice that the above
>procedure requires that your PC be *powered off* at 00:00 on 1/1/00.
>That's because if it on, DOS, Windows, NT, 95, whatever, will handle it
>just fine -- they maintain a perfectly viable clock. The problem is
>with the hardware clock on the PC, which keeps time in between reboots
>and power-cycles.
My computer, and many others, revert to a date in the eighties if the
power is shut off any time after 12/31/99
Robert Billing
In article <01bc4862$177ec4b0$2fa036cf@alpha>
eapa...@orion.data.com "Eugene A. Pallat" writes:
> When I saw JCL when it came out, I thought they were kidding.
> Unfortunately, they weren't. So I bypassed the JCL mess and wrote my own
> JCL compiler (in FORTRAN) so I could ignore it. Worked fine.
Cambridge had a supersystem called Phoenix sitting on top of JCL that
allowed you to write in a perfectly reasonable command language. I
don't know if anyone else used it.
-Stewart,G.M.
In article <860962...@tnglwood.demon.co.uk>,
Robert Billing <uncl...@tnglwood.demon.co.uk> wrote:
>In article <334F3E6D...@transbay.net> ec...@transbay.net "ecsd" writes:
>
>> I remember JCL. God, what fun.
>
> Remember it? I've still got the manual...
Well, put it back, dammit. I needed that last week.
-Stewart,G.M.
In article <33513E...@mail1.lr.net>,>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> Turn it back on after 10 minutes and see what happens. Most of them will
>> have a problem. Supposedly NT can survive.
>>
>
I did that with mine and the screen went black, and then I
saw this guy with horns come on the screen saying something about
the "wrath of the dark lord" or some crap. He looked like Bill
Gates after holding his breath a long time. Anyway, I couldn't
get the terminal emulator back on, I saw a bunch of stuff fly
by the screen about "rapture" and "apocalypse" and stuff and
the power supply blew up. Plus, I've been changed into a newt.
Which sucks because my inseam is really way out of wack, among
other things. And I've got meetings.
Gary Hampson
In article <mcdon-12049...@la-dial1-26.wavenet.com>, Don
McKenzie <mc...@wavnet.com> writes
>In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
><eapa...@orion.data.com> wrote:
>
>[snip]
>> Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> Turn it back on after 10 minutes and see what happens. Most of them will
>> have a problem. Supposedly NT can survive.
>>
I tried this some time ago. I have a Tosh t4400sxc+maths processsor dos5
and win3.1. I did not power it down and up - I just watched (at a safe
distace ;)
I tried a number of well known applications and everything worked ok.
The only thing I noticed were file dates reported as 00.
However I am still prepared to be paranoid!
-- Gary Hampson
-- to e-mail remove >>.NO.SPAM<< from above address
Robert Billing
In article <5ismqf$h...@ssbunews.ih.lucent.com>
gm...@ihgp3.ih.lucent.com "-Stewart,G.M." writes:
> Well, put it back, dammit. I needed that last week.
Shan't. It's my copy, I paid for it in the Computer Lab bookshop 20
years ago, and I keep it to remind me that not only can things get
worse, they have been worse before...
Kurt Foster
Eugene A. Pallat (eapa...@orion.data.com) wrote:
: Try setting the date and time on your PC to 12/31/99 24:55 and power off.
:
I did some experiments on a PC with a 1990 AMI BIOS and DOS, with the
following results:
1) Setting time & date to 23:59:50 on 12-31-1999 and powering down,
waiting 30 seconds, and powering back up, caused the BIOS SETUP
program to report a date of 01-01-1980.
2) Setting time & date to 23:59:40 on 12-31-1999, rebooting IMMEDIATELY
and running SETUP, the time went from 23:59:59 on 12-31-1999 to
00:00:00 on 01-01-1980, with only the BIOS SETUP program running the
computer.
3) With DOS running at 23:59:59 on 12-31-1999, the DOS "date" command
subsequently correctly reported the date as Sat 01-01-2000. However,
a reboot put the date back to 01-01-80 in SETUP.
4) In cases (1) - (3) above, the botched date transition as reported by
SETUP was compounded during bootup, and the DOS "date" command reported
Fri Jan 4, 1980 instead of Tues Jan 1.
5) If a date of at least 01-01-2000 is entered *manually* using the DOS
"date" command, the date information survives a complete reboot. Both
the SETUP program and DOS handle the transition to 01-01-2001 properly.
Perhaps the ability of the computer to "survive" the transition to the
year 2000 lies more with the BIOS than the operating system. This
particular problem is easily avoided. One way is to have the system
prompt the user to enter the time and date at startup.
Jay R. Ashworth
Peter de Jager (pdej...@year2000.com) wrote:
^^^^^^^^
: There is a Feb 29th 2000
Well, I guess this is authoritative.
:-)
Cheers,
-- jr 'tonight we're gonna party like...' a
Jay R. Ashworth
Mark Zavislan (zavi...@mail1.lr.net) wrote:
: Eugene A. Pallat wrote:
: > Try setting the date and time on your PC to 12/21/99 24:55 and power off.
: > Turn it back on after 10 minutes and see what happens. Most of them will
: > have a problem. Supposedly NT can survive.
: My PC came back with 12/22/99 00:05. No problem.
Um, should that not have been 12/22/99 0_1_:05?
Cheers,
-- jr 'what's an hour among friends?' a
Paul Tomblin
In a previous article, uncl...@tnglwood.demon.co.uk said:
>In article <334F3E6D...@transbay.net> ec...@transbay.net "ecsd" writes:
>
>> I remember JCL. God, what fun.
>
> Remember it? I've still got the manual...
I don't have the manual, but I still have the mental scars.
--
Paul Tomblin (ptom...@xcski.com), Rochester Flying Club
<a href="http://www.servtech.com/public/ptomblin/rfc/">RFC Web Page</a>
RFC is selling two of our PA28-181 Piper Archer IIs. See web page for details.
G. Mark Stewart
Robert Billing (uncl...@tnglwood.demon.co.uk) wrote:
: In article <5ismqf$h...@ssbunews.ih.lucent.com>
: gm...@ihgp3.ih.lucent.com "-Stewart,G.M." writes:
: > Well, put it back, dammit. I needed that last week.
: Shan't. It's my copy, I paid for it in the Computer Lab bookshop 20
: years ago, and I keep it to remind me that not only can things get
: worse, they have been worse before...
Got a receipt?
No receipt, it's mine.
Russ Jones
On Fri, 11 Apr 1997, Maryse Turcotte wrote:
> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course that
> it must have been a way to economize on storage and time of execution which
> I heard was very costly back then... Still, I find it hard to believe
> that they didn't anticipate the problem which wasn't that far away...
>
Back in the '60's when computer memory was made up of little rings of magnetic
metal strung on grids of wires, when a really big computer had 4K of memory,
when computer speed was measured in instructions per second, not millions or
billions of instructions per second, when the operator could tell what the
program was doing by watching the flashing lights, when there were no consoles,
when all input was on cards and all output was on printers, every single byte
of data was very expensive. So we economized, figuring that these shabby old
programs would NEVER be still running after 1999. And in fact, most of them
are not running now. But the data structures that were created for those old
programs are still here. The original program
Ah piss on you. You don't care, you just want to argue. Go ahead, argue.
---
Russ Jones - Boeing Information Support Services - Wichita Kansas
russ....@boeing.com - (316) 526-9364
Views and/or opinions expressed herein are those of the sender and should
not be construed to represent policies or positions of The Boeing Company.
Bill Henneman
Maryse Turcotte wrote:
>
> Hello!
>
> I've always wondered why programmers didn't use 4 digits date in the
> first place. The best explanation I could come up with was of course that
> it must have been a way to economize on storage and time of execution which
> I heard was very costly back then... Still, I find it hard to believe
> that they didn't anticipate the problem which wasn't that far away...
>
>
> Thanks in advance.
>
> Maryse Turcotte
>
> E-mail : maryse....@sympatico.ca
As one of those slovenly programmers from the olden times, I'll try to
make it clear.
The first "big" machine I worked on had 1000 72-bit words (UNIVAC I).
This is 9KB memory. An add instruction executed on average in 50
milliseconds. My first big project was a target tracking simulation
program. The program ran in overlays, since the entire program wouldn't
fit in memory at once, much less memory + data. About 90% of the effort
in this project was to make sure no overlay was done in an inner loop
("thrashing" in a jargon which would exist 15 years later). Every effort
was made to squeeze things down to the minimum to make the critical
inner loop calculation + data needed fit in a memory image. Did I worry
about what would happen to the poor programmers who would have to update
this incredibly obscure piece of code 30 years hence? No! If I hadn't
been such a good hacker, they wouldn't have anything to inherit - it had
to run in the 1950's environment.
I wrote a lot of code in the '60s and '70s with the (reasonable)
expectation that it wouldn't have a long lifetime. Many of us who used 2
digit years fully expected our programs to be rewritten - it's not that
we were shortsighted, it's just that we failed to appeciate what cheap
b*st*rds the customers were.
Hope this helps ...
DONALD G. DAVIS
bre...@netcom.com (Brett Frankenberger) writes:
>As much as it pains me to defend Bill, this isn't a Microsoft issue.
>NT, Win95, and even DOS, handle Y2K just fine. Notice that the above
>procedure requires that your PC be *powered off* at 00:00 on 1/1/00.
>That's because if it on, DOS, Windows, NT, 95, whatever, will handle it
>just fine -- they maintain a perfectly viable clock. The problem is
>with the hardware clock on the PC, which keeps time in between reboots
>and power-cycles.
>It, in many cases, cannot deal with Y2K correctly. AFAIK, Bill neither
>designs CMOS clocks nor writes BIOSs ... so it's not a case of
>Microsoft writing non-Y2K code.
This is true. The root cause of Y2K problems on some PCs is
simply that the real-time clock hardware on the CMOS chip does not
automatically update the century byte, as it does the second, minute,
hour, date, month, and 2-digit year. Thus, if the computer is off during
the century turnover, the CMOS date will change from 12/31/1999 to
1/1/1900, not 1/1/2000. On the next startup, the OS sees this as an
invalid date and resets the date to 1/4/1980 (this, at least, is the date
set under DOS 6.22; I'm not sure about other OSs). If this happens on your
system, you need only reset the date manually after startup, and it will
stay correct thereafter. Just don't do any file operations after
12/31/1999 until you've made sure of this!
--Donald Davis
Greg Limes
ecsd <ec...@transbay.net> writes:
>
> I'm quite glad that everything I coded from early on handled this
> and will not expire until between 2069 and 2088, or even 9999,
> depending.
I hope you documented the "expiration date" for each package?
Or at least kept notes, so your grandson can make some bucks
consulting for whoever is still using that dusty code :)
--
Greg Limes using alternate account to deflect SPAM
delivery of email to this account may be delayed.
Greg Limes
"Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
>
> In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
> <eapa...@orion.data.com> writes
> >The problem is far worse that you people can even imagine. There are
> >already people who have had credit card purchases rejected because the
> >expiration date of "00" interprets to 1900 - ergo expired card.
>
> Or even 12/99 - see my posting to comp.risks a month or two ago.
>
> >Try setting the date and time on your PC to 12/21/99 24:55 and power off.
> >Turn it back on after 10 minutes and see what happens. Most of them will
> >have a problem.
>
> If it lets you set that date and time, you've already got problems.
Didn't you know about the Leap Hour being added at the
end of this century?
Clive D.W. Feather
In article <861001...@tnglwood.demon.co.uk>, Robert Billing <unclebob@
tnglwood.demon.co.uk> writes
> Cambridge had a supersystem called Phoenix sitting on top of JCL that
>allowed you to write in a perfectly reasonable command language. I
>don't know if anyone else used it.
Me.
Clive "was present at the original derivation of 'Chemist' in the Jargon
File" Feather
--
Clive D.W. Feather | Director of Software Development | Home email:
Tel: +44 181 371 1138 | Demon Internet Ltd. | <cl...@davros.org>
Fax: +44 181 371 1037 | <cl...@demon.net> | Abuse:
Written on my laptop; please observe the Reply-To address | <cl...@bofh.org>
David Carrell
In article <brettfE8...@netcom.com>,
bre...@netcom.com (Brett Frankenberger) wrote:
>They didn't expect that their code would be in use 30 years from when
>they wrote it. The 32 bit time in Unix wraps in 2038 or something like
>that ... how many programmers writing Unix code today are writing code
>that will properly handle that? (No doubt some are, but many aren't).
Let's go even one better. VMS (from DEC) and maybe some UNIX software (not
system software though) is going to have problems even sooner than 01/01/00
:). Like on May 19, 1997 (yes, about 5 weeks). Unix used Jan 1, 1970 as an
'epoch' date and May 19 is 10,000 days since then. Some VMS system routines
will 'break' when this 10,000 day delta is crossed. For more detailed info
see
http://www.openvms.digital.com/openvms/letter.html
or
http://www.openvms.digital.com/openvms/delta_guide.html
And an additional factoid. The SEC (the stock market guys) are concerned
because the cost or addressing and/or not addressing the Y2K problem MAY
have an impact on the finances of SOME companies. (Imagine an automated
billing system that thinks all the customers are overpaid and issues
M(B)illions of $'s of rebates/credits. Now that could affect your quarterly
earnings estimates.:) )
Yes the problem is real. Yes it may be being hyped (most news is). But if
the problem is not addressed, nearly everyone could be affected, and
probably negatively for most.
Regards,
DAC
P.S. Luckily most of the code I deal with use YYYY format and also use short
deltas. I may have some problems on 01/01/00 but by 01/02/00 nearly all my
problems go away. But we are working on the problem already, and it is not
going to make me anymore $$'s.
-------------------------------------------------------------------------
David Carrell All comments above are mine, and
Process Control Engineer do not necessarily reflect the
Conoco, Inc. opinions of Dupont and/or Conoco,
*carrelda*@pore.dnet.dupont.com* [and why should they]
(return address altered to reduce
adds, remove *'s for real address)
drdave
> bill...@aol.com (BillH1108) wrote:
>
> >I hope to hear from someone who has really good mainframe skills who can
> >put this 2000 problem into prespective. We got into a really torrid
As I understand it, the problem is real but only for certain
applications.
My wife is a computer engineer and she tells me that dates calculated by
the system (ie not a number in a spreadsheet), are done by counting the
number of seconds since the arbitrarily defined time zero (1907??).
But computers now are stil only 32 bit, and there are only so many
seconds that can be represented by 32 bits. Once you run out, you can no
longer count.
So it's not actually the year 2000 exactly that is the problem. It's 32
bit worth of seconds from the defined time zero. (I don't know when that
is, but it's coming up soon).
***************************************
"Do you consider Skipper more relevant than Gardner?"
Justice John Paul Stevens while hearing a brief for
the Supreme Court 18-March-97 (no, I'm *not* joking)
But what about Gilligan?
***************************************
drd...@netgate.net http://www.netgate.net/~drdave
Peter Kerr
> > Try setting the date and time on your PC to 12/21/99 24:55 and power off.
> > Turn it back on after 10 minutes and see what happens. Most of them will
> > have a problem. Supposedly NT can survive.
> >
The replies I've seen so far worried about the 24:55 bit, but my concern
is why a PC should be worried about the shortest day, 12/*21*/99
This should spawn a whole thread on which day really is the shortest in 1999 ;-)
Hint: I live in the southern hemisphere, and that has nothing to do with it...
--
Peter Kerr bodger
School of Music chandler
University of Auckland NZ neo-Luddite
Humor Impaired
Greg Limes <net...@straylight.engr.sgi.com> wrote:
>"Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
>>
>> In article <01bc46d2$5a0402a0$30a036cf@alpha>, "Eugene A. Pallat"
>> <eapa...@orion.data.com> writes
>> >The problem is far worse that you people can even imagine. There are
>> >already people who have had credit card purchases rejected because the
>> >expiration date of "00" interprets to 1900 - ergo expired card.
>>
>> Or even 12/99 - see my posting to comp.risks a month or two ago.
>>
>> >Try setting the date and time on your PC to 12/21/99 24:55 and power off.
>> >Turn it back on after 10 minutes and see what happens. Most of them will
>> >have a problem.
>>
>> If it lets you set that date and time, you've already got problems.
>Didn't you know about the Leap Hour being added at the
>end of this century?
Which reminds me that a consultant also told us to set our computers
to Feb 28 11:59 pm 2000 to see if they roll over to Feb 29.
Angela
Thomas M. Root
Bill Henneman wrote:
>
> Maryse Turcotte wrote:
> >
> > Hello!
> >
> > I've always wondered why programmers didn't use 4 digits date in the
> > first place. The best explanation I could come up with was of course that
> > it must have been a way to economize on storage and time of execution which
> > I heard was very costly back then... Still, I find it hard to believe
> > that they didn't anticipate the problem which wasn't that far away...
> >
> >
> As one of those slovenly programmers from the olden times, I'll try to
> make it clear.
>
> The first "big" machine I worked on had 1000 72-bit words (UNIVAC I).
> This is 9KB memory. An add instruction executed on average in 50
> milliseconds. My first big project was a target tracking simulation
> program. The program ran in overlays, since the entire program wouldn't
> fit in memory at once, much less memory + data. About 90% of the effort
> in this project was to make sure no overlay was done in an inner loop
> ("thrashing" in a jargon which would exist 15 years later). Every effort
> was made to squeeze things down to the minimum to make the critical
> inner loop calculation + data needed fit in a memory image. Did I worry
> about what would happen to the poor programmers who would have to update
> this incredibly obscure piece of code 30 years hence? No! If I hadn't
> been such a good hacker, they wouldn't have anything to inherit - it had
> to run in the 1950's environment.
>
> I wrote a lot of code in the '60s and '70s with the (reasonable)
> expectation that it wouldn't have a long lifetime. Many of us who used 2
> digit years fully expected our programs to be rewritten - it's not that
> we were shortsighted, it's just that we failed to appeciate what cheap
> b*st*rds the customers were.
>
> Hope this helps ...
Maryse, what makes you think that programmers didn't anticipate the
century roll over problem when we wrote all those programs in the '60s
and '70s? I worked on systems with as little as 900 words of drum
memory and reveled in the luxury of having as much as 64K of genuine
core.
On my last major banking application ('72), we spent a great deal
of time evaluating the pros and cons of various date formats.
Binary formats would provide denser storage and speed up the 'days
between dates' calculations but they would require conversions when-
ever they were input or output. ASCII formats would provide faster
I/O and be easier to recognize in binary dumps, but they would take
more storage and be much slower when calculating daily interest
accruals. We finally decided on a 2 byte binary format, with 7
bits for year and 9 bits for the day. We documented this format
carefully, INCLUDING A STATEMENT THAT DATE DIFFERENCES WOULD BE IN
ERROR FOR DATES AFTER 2027. We also isolated all the code that
dealt with date data in a single library that could be updated if
the system lived long enough to make it necessary.
I do not know if subsequent users and programmers kept our documen-
tation or paid any attention to the thought we put in on this issue,
but the choices that were made were considered carefully and the
project was completed on time and within budget and it did what the
customer (users) wanted it to do (and it actually ran an a system
with a maximum of 64K of core).
Tom
--
Illegitimi Non Carborundum
tmr...@spessart.com
McMinnville, OR
Thomas M. Root
Whatever problems may be associated with the "Y2K Problem", I'm
looking forward to the IRS's computers thinking its 1900 and
decidinging that their agency won't be authorized for 14 more
years. Thank an otherwise incompetent computer programmer.
TMR
Ken West
In article <Pine.BSI.3.91.970414...@ng.netgate.net>,
drdave <drd...@ng.netgate.net> wrote:
> > bill...@aol.com (BillH1108) wrote:
> > >I hope to hear from someone who has really good mainframe skills who can
> > >put this 2000 problem into prespective. We got into a really torrid
> As I understand it, the problem is real but only for certain
> applications.
>
> My wife is a computer engineer
as opposed to an applications programmer, obviously,
>and she tells me that dates calculated by the system
What is "the system" ?
>(ie not a number in a spreadsheet), are done by counting the
> number of seconds since the arbitrarily defined time zero (1907??).
?? indeed
> But computers now are stil only 32 bit, and there are only so many
> seconds that can be represented by 32 bits. Once you run out, you can no
> longer count.
> So it's not actually the year 2000 exactly that is the problem. It's 32
> bit worth of seconds from the defined time zero. (I don't know when that
> is, but it's coming up soon).
Breathtakingly informative.
Regardless of the number of seconds that any given operating system can
define on any give piece of software, the REAL problem is all the
teralines of application code floating around out there that compare
2-digit dates, and sort 2-digit dates, and sequence 2-digit dates, and
make decisions based on those comparisons and sorts and sequences, and
because 01 compares and sorts and sequences before 99, they will make
decisions based on the fact that eg., (20)01 is "less than" (19)99.
Lots of those teralines of code don't even look at the system date as part
of their logic -- they take it from a "control card" or some computer
operator's keystrokes at 2AM, and regardless of the number of bits and
seconds that their operating system uses to represent the system date,
they will malfunction when they process data which contains dates which
cross the millenium boundary, regardless of whether they are running on
New Years day 2000, or New Years eve 1999, or, by the way, today.
regards,
Ken West
Ken West
In article <01bc4862$8ac1e8d0$2fa036cf@alpha>, "Eugene A. Pallat"
<eapa...@orion.data.com> wrote:
> Try setting the date and time on your PC to 12/31/99 24:55 and power off.
> Turn it back on after 10 minutes and see what happens. Most of them will
> have a problem. Supposedly NT can survive.
>
> OOPS! "Ffinger check" there - hit wrong key - hit 2 instead of 3 - I meant
> 12/31/99. Sorry about that!
It is true, that the cost of Y2K is dwarfed by ordinary bugs created by
computer programmers who think they write good code, but do stuff like the
above -- 2 mistakes in 6 keystrokes. The last figure I saw was that 15
lines of WORKING code per day was all we can expect from these highly paid
technicians.
regards,
Ken West
Robert Billing
In article <335417...@spessart.com>
tmr...@spessart.com "Thomas M. Root" writes:
> bits for year and 9 bits for the day. We documented this format
> carefully, INCLUDING A STATEMENT THAT DATE DIFFERENCES WOULD BE IN
> ERROR FOR DATES AFTER 2027. We also isolated all the code that
> dealt with date data in a single library that could be updated if
> the system lived long enough to make it necessary.
I went through a similar performance with a firm I used to work for,
and came up with a format which was "Days Since 01-Jan-1970" in 16-bit.
This dies on 31-Dec-2069, but there are two manifest definitions which
can be changed to move the epoch date on, and a *comment* which
explains exactly how to do it.
The reason it dies when it does is that the input routines assume
70-99 means 1970-1999 and 00-69 are 2000-2069. The wraparound date can
be changed independently of the epoch.
Before anyone says it, it was a diskless (battery RAM) system, and
kept records of hours worked, so moving the epoch would only cause a
problem with old records if someone worked for the same firm for over
100 years.
Clive D.W. Feather
In article <p.kerr.unknown-...@news.auckland.ac.nz>, Peter
Kerr <p.kerr....@host.auckland.ac.nz> writes
>This should spawn a whole thread on which day really is the shortest in 1999 ;-)
Okay, I'll bite.
The earth rotates in 23h56m. A day consists of that plus the length of
time required to rotate through an angle equal to the angle it moved
along its orbit since the last midnight. Therefore the shortest day is
the one where it moves the smallest angle, which must be at apohelion.
Which is, from memory, July 8th.
Bryan L. Dumka
>David B. Greene (da...@antispam.hacyon.com) wrote:
>: bill...@aol.com (BillH1108) wrote:
In the early days (1960's) when storage cost thousands of dollars a
megabyte, programmers had to save space any way possible. One of the
techniques was to reduce the year to 2 digits. The programs
automatically added 1900 to the year if it was necessary for
calculations.
The current problem is that all files that use a 2 digit year must be
re-built to contain a 4 digit year and all references to a date in
programs must be located and fixed.
All of the forms in use must be expanded to accept a 4 digit year.
All the reports printed must be expanded to use a 4 digit year.
In a perfect world, there would be current documentation and any
entry-level programmer could patch the code.
In the real world, no one has any idea where the documentation is, if
it ever existed. A large percentage of the source code no longer
exists, and, when it does exist, it has been patched so many times
that you have to use senior programmers to find anything.
Access 95 has the 2000 bug and must be upgraded to deal with dates
properly, which shows the short sighted attitude in the microcomputer
world.
No one expected that programs would remain in use as long as they
have. The assumption was a complete re-write every five to ten years,
so no need to worry.
Even after the storage problem is corrected by expanding to four
digits, the program has to contain logic that decides whether to add
1900 or 2000.
People are living longer. I have great aunts over 100 years old who
have had problems because their birthdays are in the 1800's.
This could have been a minor blip on the screen, but government and
business have waited, and now it has become a crisis.
Robert Billing
In article <3354e94a...@news.nuc.net>
bld...@nuc.net "Bryan L. Dumka" writes:
> People are living longer. I have great aunts over 100 years old who
> have had problems because their birthdays are in the 1800's.
There is one recorded case of a school attendance officer turning up
to demand to know why someone aged 6 was not attending school, only to
be introduced to a great-grandmother aged 106.
Jim Everman
Lulu of the Lotus-Eaters wrote:
>
> *}>discussion at a MENSA meeting about the 2000 problem.
>
> Ummm gee... somehow this confirms everything I ever thought about MENSA.
>
Then I assume you will be joining soon .?..
--
Jim Everman eve...@Anet-STL.com
Never attribute to malice what can be adequately explained by
stupidity.
Robert Billing
In article <p.kerr.unknown-...@news.auckland.ac.nz>
p.kerr....@host.auckland.ac.nz "Peter Kerr" writes:
> This should spawn a whole thread on which day really is the shortest
in 1999 ;-)
> Hint: I live in the southern hemisphere, and that has
nothing to do with it...
Of course one can simply sort the days into length order.
Today
Monday
Friday
Sunday
Tuesday
Thursday
Saturday
Birthday
Wednesday
Yesterday
Christmas_Day
April_Fool's_Day
Continue ad nauseam... :*)
mzaw...@starnet.lenfest.com
> David Green wrote:
> OK, here's the deal, Bill. Programmers are inflating the problem to
> sell the public on the need for their services as the public is getting
> feed up to their eyeballs with cost over runs on defective computer
> projects.
Recently caught this on the news : More than 180,000 new software
positions open yearly (in the US alone), while colleges graduate only
some 35,000 individuals capable of filling these positions. There
will be no programmers on the unemployment line or programmers needing
to invent makework here anytime soon -- 2k problems or not.
Mark Zawadzki, late of Waynesboro, Va.
"Philadelphia is ours and fairly won"
Kenneth Brody
Humor Impaired wrote:
>
> Which reminds me that a consultant also told us to set our computers
> to Feb 28 11:59 pm 2000 to see if they roll over to Feb 29.
What did the consultant say should happen?
(Just for the record, the year 2000 _is_ a leap year.)
--
+---------+----------------------------------+--------------------------------+
| Kenneth | kenb...@bestweb.net | "The opinions expressed herein |
| J. | | are not necessarily those of |
| Brody | http://www.bestweb.net/~kenbrody | AdminaStar Communications." |
+---------+----------------------------------+--------------------------------+
GM/CS (ver 2.1) d-- H+() s+++:+> !g p? au+ a w+@ v>+ C++$(+++) UACS?++++$
UL++++ P+ L+(++) 3- E- N++>+ K(---) W++$ M-- V(-) -po+ Y+ t+ !5 j++ R
G? tv+ b+ !D B->? e+>++ u+@ h->++--- f>+ r++>+++ n---(+) y+(*)>++++
David B. Greene
And you uncritically accept this crock-o-guano!? Industry management
tries to over-inflate the need so the government will be ammenable to
an influx of foreign programmers which will keep salaries lower.
Virginia Krenn
On Wed, 16 Apr 1997, Bryan L. Dumka wrote:
> In the early days (1960's) when storage cost thousands of dollars a
> megabyte, programmers had to save space any way possible. One of the
> techniques was to reduce the year to 2 digits. The programs
> automatically added 1900 to the year if it was necessary for
> calculations.
It was uncommon to add 1900 prior to calculations. About twenty years
ago, I pointed out to my supervisor that, in the year 2000, there would
be a problem with a program that he had asked me to modify. He ignored my
suggestion that we fix it. He was either too shortsighted to see it or
didn't care.
> The current problem is that all files that use a 2 digit year must be
> re-built to contain a 4 digit year and all references to a date in
> programs must be located and fixed.
A major problem will be the synchronization of efforts. For example, If a
government agency notifies everyone that the data sent to it as of a
certain date will have to have the four digit year, then everyone else
will have to have the data available in that format at that time. But,
perhaps, other places (e.g., the banking industry) will not be able to
accept that format at the exact same time. This will necessitate that
everyone do parallel processing until all systems are converted.
Dave Seaman
In article <qL9oArAN...@on-the-train.demon.co.uk>,
Clive D.W. Feather <cl...@demon.net> wrote:
>In article <p.kerr.unknown-...@news.auckland.ac.nz>, Peter
>>This should spawn a whole thread on which day really is the shortest in 1999 ;-)
>
>
>The earth rotates in 23h56m. A day consists of that plus the length of
>time required to rotate through an angle equal to the angle it moved
>along its orbit since the last midnight. Therefore the shortest day is
>the one where it moves the smallest angle, which must be at apohelion.
>Which is, from memory, July 8th.
Not true. Although aphelion does cause the solar day to be somewhat
shorter in July than it is in January, the fact is that the solar days
in both July and January are still longer than the annual average of 24
hours. The shortest solar days come near the equinoxes, in March and
September.
The length of the solar day is directly related to the component of the
sun's daily movement that is in *right ascension*, which is analogous
to longitude in the sky's equatorial coordinate system. Right ascension
refers to an object's east-west position with respect to the fixed
stars, and is not affected by the earth's rotation. The north-south
direction, analogous to latitude, is called declination.
A part of the sun's daily movement along the ecliptic is actually in
declination (northward until it reaches the summer solstice, then
southward until it reaches the winter solstice), but the declination
component has no effect on the length of a solar day. When near the
equinoxes, the component of the sun's movement that is in declination
is at a maximum, and therefore the movement in right ascension is at a
minimum. This makes the solar days shorter at the equinoxes. When
near the solstices, the sun's daily movement is almost entirely in
right ascension, and therefore the solar days are longer than average.
The effect is more pronounced at the winter solstice, which happens to
be near perihelion, than at the summer solstice, which is near
aphelion, but the eccentricity effect is smaller than the effect of the
obliquity of the ecliptic.
--
Dave Seaman dse...@purdue.edu
++++ stop the execution of Mumia Abu-Jamal ++++
++++ if you agree copy these lines to your sig ++++
++++ see http://www.xs4all.nl/~tank/spg-l/sigaction.htm ++++
Jerry Bryson
> People are living longer. I have great aunts over 100 years old who
> have had problems because their birthdays are in the 1800's.
>
Like my Uncle Willie, who was born in 1898 and locked up the Arkansas DMV
when he renewed his driver's licence. The new license declared him under
age until 2019, and he had to carry a letter from DMV stating that he
really was over 21.
j
ken...@lxglobal.com (Ken West) wrote:
This fact should suggest how many programmer-hours will be
required to fix all y2k-related problems in all existing
programs (software + firmware). I'm not sure there are
enough programmers to accomplish the task - even if they
all started today (which they won't ... there will have
to be several "studies" of the problem first).
-j
R Looney
Kenneth Brody <kenb...@bestweb.net> wrote in article
<33550A...@bestweb.net>...
> Humor Impaired wrote:
> >
> > Which reminds me that a consultant also told us to set our computers
> > to Feb 28 11:59 pm 2000 to see if they roll over to Feb 29.
>
> What did the consultant say should happen?
>
> (Just for the record, the year 2000 _is_ a leap year.)
>
For the record, 2000 is *not* a Leap Year. Yes, years divisible by 4 are
leap years, *except* millinium years. The Leap Day's used to make the
calendar catch up to the stars, but a correction's necessary every
thousand years or so. Ask an astronomer.
Bruce Cox
I don't have an astronomer on hand, but I do know the 2000 is a leap year.
For a nice short description of the history of leap years from the Egyptians
to the present (and beyond!), see
http://www.mitre.org/research/y2k/docs/LEAP.html
Cheers,
bruce
--
Bruce Cox br...@maths.usyd.edu.au
School of Mathematics and Statistics F07 +61 2 9351 3814
University of Sydney 2006
AUSTRALIA
John Winters
In article <01bc4ae3$dac97a40$afb4...@wco.com.wco.com>,
R Looney <rlo...@dnai.com> wrote:
>Kenneth Brody <kenb...@bestweb.net> wrote in article
><33550A...@bestweb.net>...
>> Humor Impaired wrote:
>> >
>> > Which reminds me that a consultant also told us to set our computers
>> > to Feb 28 11:59 pm 2000 to see if they roll over to Feb 29.
>>
>> What did the consultant say should happen?
>>
>> (Just for the record, the year 2000 _is_ a leap year.)
>>
>Aha!
>For the record, 2000 is *not* a Leap Year. Yes, years divisible by 4 are
>leap years, *except* millinium years. The Leap Day's used to make the
>calendar catch up to the stars, but a correction's necessary every
>thousand years or so. Ask an astronomer.
Is the name of this poster a clue?
John
--
John Winters. Wallingford, Oxon, England.
nancy g.
John Winters wrote:
> >> (Just for the record, the year 2000 _is_ a leap year.)
>>Aha!
>>For the record, 2000 is *not* a Leap Year. Yes, years divisible by 4 are
>>leap years, *except* millinium years. The Leap Day's used to make the
>>calendar catch up to the stars, but a correction's necessary every
>>thousand years or so. Ask an astronomer.
Don't need to. What you say is simply not correct.
Years ending in *00* are not leap years, *EXCEPT* when the first two
digits are divisible by four.
Thus, 1700, 1800, 1900, are not leap years, but 2000 *is*.
Hope this helps.
Clive D.W. Feather
<rlo...@dnai.com> writes
>For the record, 2000 is *not* a Leap Year. Yes, years divisible by 4 are
>leap years, *except* millinium years.
Isn't that hook a bit *too* obvious ?
>Ask an astronomer.
Clive "used to be the staff programmer for the Institute of Astronomy
in Cambridge" Feather
John Winters
In article <3355F2...@tiac.net>, nancy g. <nan...@tiac.net> wrote:
>John Winters wrote:
No I didn't. You snipped everything I wrote. Do try to get your
attributions right.
Bernd Meyer
jo...@polo.demon.co.uk (John Winters) writes:
>In article <01bc4ae3$dac97a40$afb4...@wco.com.wco.com>,
>R Looney <rlo...@dnai.com> wrote:
>>For the record, 2000 is *not* a Leap Year. Yes, years divisible by 4 are
>>leap years, *except* millinium years. The Leap Day's used to make the
>>calendar catch up to the stars, but a correction's necessary every
>>thousand years or so. Ask an astronomer.
>Is the name of this poster a clue?
Yes. But isn't it always fun to see those discussions. It's almost a pity
that we use the leapyear rules in first year now, so all Monash CS
graduates will (hopefully) know the right stuff.
Oh, and _his_ rule gives 498 leapdays in 2000 years, while the right one
gives 485 leapdays, i.e. a difference of 13 days in 2000 years, or
0.0065 days per year. You'd think this is enough to tip people of (considering
that the Julian calendar, which had 500 leapdays in 2000 years, was
already 11 days off after only about 1800 years ;-).
Bernie
--
============================================================================
"It's a magical world, Hobbes ol' buddy...
...let's go exploring"
Calvin's final words, on December 31st, 1995
Geoff. Lane
In article <ouohbem...@maths.usyd.edu.au>,
>> leap years, *except* millinium years. The Leap Day's used to make the
>> calendar catch up to the stars, but a correction's necessary every
>> thousand years or so. Ask an astronomer.
>
> For a nice short description of the history of leap years from the Egyptians
> to the present (and beyond!), see
> http://www.mitre.org/research/y2k/docs/LEAP.html
Or even a nearby Unix system...
$ cal 2 2000
February 2000
Su Mo Tu We Th Fr Sa
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29
Looks like a leap year to me.
--
Geoff. Lane.
A clean disk is the sign of a warped drive.
Arne Dehli Halvorsen
On Thu, 17 Apr 1997 07:18:20 +0100, "Clive D.W. Feather"
<cl...@on-the-train.demon.co.uk> wrote:
>
>Clive "used to be the staff programmer for the Institute of Astronomy
>in Cambridge" Feather
Interesting. What did you program them in?
Arne
nancy g.
John Winters wrote:
(and this time, he really did; I double-checked ...)
> In article <3355F2...@tiac.net>,
> nancy g. <nan...@tiac.net> wrote:
>> John Winters wrote:
> No I didn't. You snipped everything I wrote.
Quite right. Sorry. One of the hazards of very-late-at-night newsgroup
posting is that one's proofreading accuracy rate degrades rather quickly.
I had *tried* to snip all the attributions, since there were several
of them and they weren't really relevant any more, but my newsreader
somehow snuck yours back in.
> Do try to get your attributions right.
Oh, but I *did* try. I just didn't *succeed.*