if your entry does not appear here, try
reloading this document
Hey, dude this isn't really such a big problem. All of the "new"
operating systems such as OS/2 4.0 and Windows NT 4.0 already have fixes
for this problem, but I maybe wrong. For the old computers that use DOS
/ Windows 3.1 or 3.11 or Windows 95 or 97, just set the hardware date to
1990 instead of 2000 and use a TSR to intercept the date requests. If done
this way, the file dates maybe wrong, but the TSR(terminate and Stay Resident)
program could provide that extra bit that you refered to.
as proposed by: Jeremy
Garrett ..[Mar
8, 1997] ..Western Carolina University
Let's make our way into 2000 with a whole newway of computing. Forget
compatiblity. Let's get those 300 Mhz processors. 100 mgs of ram systems.Let's
make a cool new graphical interface.Let's make the computers all connect
via T3 lines.We're going to slow, it's time to change...Eventually you
have to give up compatibility..
as proposed by: Anonymous
..[Mar 14, 1997]
..Toronto, Ontario, Canada
I've fiddled with Windows 95 settings a bit, exploring the Year 2000
problem. I'm not much of a programmer, but I changed the date to December,
31st, 1999, and the time to 11:59:50 PM, to see what will happen when it
switches to the year 2000. Result? The computer correctly stated January
1st, 2000, when I hovered the mouse of the clock. I'm not sure how the
computer reads dates, as I said, I'm not a programmer, but January 1st,
2000 seems answer enough for me.
as proposed by: Daniel-san
..[Mar 15, 1997]
..Pasadena, MD, USA
What kind of software and hardware are being used to tackle this problem
as proposed by: Steve
Hurtado ..[Mar
16, 1997] ..Guildford,Surrey,England
Let's send Jean Luke Picard back to the beginning of the 21st Century,
and when he discovers that we were unable to solve the problem, then he
initiates the Star Date System.
This isn't my own solution you understand, but a conspirecy therorist
friend of mind swears that the following is an excerpt from a taped conversation
between Bill Gates and God. BG: "Hello, Hello ?" Receptionist:
"Hello, can I help you ?" BG: "God. I want to speak to God"
Receptionist: "Hold on a second, I'll put you through" St Peter:
"Hello" BG: "Who's that ? Identify yourself" St Peter:
"This is St Peter. I'm afraid God is unavailable at the moment. Can
I take a messege ?" BG "Unavailable ? Un - a - bloody - vailable
?!? Do you KNOW WHO THIS IS ?" St Peter: "I'm sorry, I don't
my son." BG: "!!?!!?!!?!? sehole" St Peter: "I'm afraid
God is on vacation for a while. Is there anything I can help you with ?"
BG: "Yes there bloody well is. I want to change the year 2000 to 1999a.
OK sonny ?" St Peter: "Er, I don't think that's possible"
BG: "Look pete, I'll spell it out for you. If you don't change the
date, then we are all buggered. Got it ?" St Peter: "Hmmm, yes,
I understand the problem but there really isn't much I can do about it.
You will have to wait until God returns from his vacation and talk to him
about it." BG: "??!?!?!?!?!sehole. When does he get back then
?" St Peter: "Hmm, well, he should be back by next week, give
or take a few decades. You know what these Gods are like. Can't get enough
of Euro-disney" Sounds like a good idea to me ! Martin Horton.
as proposed by: Martin
Horton ..[Mar
24, 1997] ..Cambridge, UK
If you will pardon my french, but it seems to me that a few of your
corispondents think that just because they own MAC's or such that will
not be afftected by this problem...well their f*cking wrong. Remember folks,
just because YOUR system will not be affected by the YR2K, your banking
institutions, your credit card services, your insurance services, and quite
a few others are still using main-frame based, COBOL language systems.
Believe me folks, if I was you I'de be scared. As for the solution that
you propose, while it does get to the root of the problem, it is fairly
shallow..no offense. Remember that when the folks wrote the code for most
of these programs, it was around 10 to 15 years ago. Many of the original
copy books, programs, and programers aren't even around any more. In addition
to this, many programmers at the time decided to use a fairly large amount
of acronyms for date fields. And on top of that there are mutliple links
inside most programs, many programs are over 500,000 lines of code...man
the nightmare goes on and on when thinking about how to fix this. Sorry
I don't have a easy solution...but there ain't one.
as proposed by: Joseph
M. Scott ..[Mar
26, 1997] ..Cincinnati, Ohio 45215
Confessions of a COBOL Programmer Y2K - The Millenium Bug - Year 2000
A COBOL Solution After leaving college in '87 (i.e. 1987), I spent several
years writing COBOL programs. Almost all of these programs contained "The
Millenium Bug". This, as I'm sure you know by now, is the name given
to the inherent system restriction caused by using only two digits to represent
the year. While I was designing these programs I was aware of this limitation.
In fact I remarked on it to my superiors and was told not to worry about
it. I was told that if the programs were still around by the year 2000,
we certainly wouldn't be, and it would be somebody else's problem. Well,
I have moved on and I haven't seen a COBOL program for many years, but
since I was partly to blame for creating this problem I must make some
contribution to resolving it. As such, let the following be my contribution
to the resolution of "The Millenium Bug" i.e. a method for re-designing
COBOL programs, so that the minimum of work is required to produce a system
which will continue to run well into the 21st century. The huge impact
of this "Bug", the pervasiveness of it, and the logistical problems
involved in fixing it, have been discussed many times before and I will
not repeat that lecture here. However, for the purposes of understanding
my solution to this problem, allow me to present the following points.
1) The problem was brought about by the short-sighted initial design of
systems. Therefore, it is a core part of the systems concerned and changes
made to rectify it are likely to stir up a hornet's nest of unforeseen
problems. It is therefore desireable to minimise the changes made. 2) Dates
are commonly stored in the following formats : DDMMYY, MMDDYY (USA), YYMMDD
(used for sorting), YYDDD (Julian, Sorting) In COBOL, for example in the
case of YYMMDD, this would be represented by something like the following
: 01 EXAMPLE-RECORD. 02 ER-DATE-YYMMDD. 03 ER-YEAR PIC 99. 03 ER-
as proposed by: Seán
Mc Laughlin ..[Apr
15, 1997] ..Dublin, Ireland
All of my CarriageReturn_LineFeeds seem to have disappeared from my
solution. Sorry if it's difficult to read.
as proposed by: Seán
Mc Laughlin ..[Apr
15, 1997] ..Dublin, Ireland
Right, I am a reasearch student, from Nottingham Trent University and
I have been looking into the problems of the Year 2000 for a local health
trust. Reading some of these solutions is painful to say the least. The
problem is both a hardware and a software problem. This Daniel chap from
Pasadena, going on about changing the date in the operating system. Of
course the date rolled over from 31/12/1999 to 01/01/2000 becasue the BIOS
date and Operating System date are two different things! What you need
to do is change the date and time of the BIOS to 23:58 on 31/12/1999 and
then turn your computer off for three minutes. Turn your computer back
on and now look at the date, you will possibly see the date has set to
1980 or 1900. All Microsoft Operating Systems are Year 2000 compliant from
MS-DOS 3.3. Macs don't have a problem. Well the hardware may not, but it
does not follow that the software will be O.K. On the P.C side just because
the BIOS does not roll over to 01-01-2000 automaticly, it does not mean
that it is useless. Most BIOS's (but not all) will actualy store the date
01-01-2000 by setting the date useing the DOS DATE command, and then it
will be o.k from this point on. All I have done on the Health Trusts P.C's
is write a piece of code that is called from the autoexec.bat file that
basicaly says if the BIOS date is less than 1990 then set date to 04-01-2000
(Whic is the first working day). One last point, you should be careful
about chanigng the date within windows 95 or NT as you could loose data
in electroincs diaries or a beta version of a program could stop working.
Any more comments would be appreciated. Peter Moore, Nottingham Trent University,
England
Sa aking palagay ay kinakailangan ng masusing pag-aaral sa problemang
ito. Yung lang masasabi ko salamat sa inyo....
as proposed by: A.
F. Rica ..[May
9, 1997] ..Muntinlupa State of Calamity ,
Africa
I'm not a computer programmer, but to me a simple solution would be
to change the way the date is written now, 00, to a three digit number,
such as 100.
as proposed by: John
D. Ostovic ..[May
31, 1997] ..Washington, PA, USA
Those of us who work on mainframes or minis have two main areas of
concern - databases and source code. I have developed a tool which scans
entire databases and finds dates that are not Y2K compliant and I am working
on a source scanner. Download a FREE trial now and get your YEAR2000 conversion
of to a start. http://freespace.virgin.net/c.young/y2k.html
Be strategic - Pass the buck We don't know what will happen Project
your vision to Jan 2000 when things have gone wrong and work out your response
1. Show the memo you wrote identifying the problem, that passes the problem
to the manager 2. If you are the manager, show them you did implement a
scheme. The law states you are responsible 'to take reasonable steps' 3.
same for directors 4. If you are the consultant who handled the project,
increase your professional liability 5. If you are the supplier, create
your IT systems solutions into a separate division, so when it goes up
the shoot you dont take the company with it 6. Finally, well most systems
will cope anyway, and if they don't a change of career is no bad thing
My first solution was rather simplistic. I had e-mailed Jess after
reading his article to suggest that his age calculation was not done correctly.
Actually, he would be -71 (00-71). Age is absolute, but computers are not.
Unless the code written for age calculations does use absolute numbers,
perhaps a TSR that adds 100 to the age should solve the problem. As for
legacy software, an upgrade that re-writes the section of code for age
calcs may work. For new, include it now. In word processing programs, the
function can still be in mm/dd/yy format. It will not matter. Only in age
calcs will the TSR or code change take affect. That's my opinion, I may
be wrong. ( Thanks, Dennis Miller.)
as proposed by: John
D. Ostovic ..[Jun
8, 1997] ..Washington, PA
I don't understand why we can't just make a simple program that will
change the 2 digit year storage into a 4 digit year storage. There has
been all this talk about manually changing the code which is billions of
lines, but this sounds like the job for a computer.
The solution to the problem will obviosly be very complex and probably
take many more years than we have. This sounds very simple and probably
has already been considered but if we run out of time and it is 11:59 Dec
31, 1999, why don't we reset the time back to 1980 and buy us some time.
Some things will be lost but it would be better than doing nothing
as proposed by: Chris
Peters ..[Jun
9, 1997] ..Russia
Create a digital micro-chip with the added information and provide
it to all necessary users. The company that creates this chip will be the
company that saved the world as it exists and beyond.
as proposed by: Diane Reed
..[Jun 16, 1997]
..Powell, Ohio USA
Most people are ignorant about y2k. They don't know what is going to
happen because important data will be lost, forever, and there will also
be a lot of confusion in which most probably a lot of people are going
to be hurt, mentally and physically. In richer countries these people will
be all kinds of people, rich , middle class, and poor people. In middle
income countries, rich, middle income and poor people will be affected.
In poor countries rich and middle income people will be affected. Only
the poorest of the poorest of the poor countries will not be affected,
because they are very far off from this great evil of computing which is
bound to occur.(they will have the good privilige of not having any contact
in name or number with any computer system. But they also will be effected
because they will be living on earth, which will probably just low up for
all I know! believe me, I don't know much, and this is not a threat of
any kind. It is for the good of mankind, this message) Of course the Internet
is going to crash, and so are all of the world's military forces(including
nuclear devices,chenical weapons, etcetera, etcetera, etcetera, if they
are not disabled now and fixed after the year 2000.) I expect a lot of
chaos and disorder. Do you? If the data or information or transactions
or whatever are not on paper(telling exactly when it happened) and the
papers are used to tell when the things occurred then there will be a lot
of confusion for everyone. My solution is only one solution: it is a paper/microfiche
solution. it is not a very good solution because most of it will be destroyed
when things start to get bad! The time at which the papers are printed
should also be dated. Disks or CDs, computer systems should not be used
for recording this data, since they all have the y2k problem. My solution
is because of time constraints, though proably my solution will probably
take more time unless more people are employed in recording old data. People
should slow
as proposed by: hassa
arif yaqub ..[Jun
18, 1997] ..Stillwater, Oklahoma, U.S.A. (Oklahoma
State University)
I have developed a COBOL subroutine which will window any year you
send to it and return it in with 2 century digits attached. For instance,
pass it the date 021271 and receive 02121971. You may pass it up to five
dates in one of six different formats. If anyone is interested or would
like to ask questions, please contact at leatj@zeus.dsu.edu.
as proposed by: Jeff
Leat ..[Jun
20, 1997] ..Sioux Falls, SD USA
Luckily, the company I'm working for right now will have little/no
problem with the Y2K problem. We've been storing dates in a horlog format.
Horlog is kinda like a Julian date...except it never resets itself. It
doesn't record the year when it puts down a date. Some genius invented
this system during the infancy of IT. So, if anyone is interested...today
is day 57154. Mathmatical computations involving these times just looks
to see how many days have passed. So when 2K hits, it'll just roll right
along to the next horlog day. Doesn't do a whole lot of good to help people
fix their 'bug', but is just a notice that not all companies will experience
this problem.
as proposed by: Chris
Nielsen ..[Jun
26, 1997] ..Omaha, NE
YEAR 2000 ASSESSMENT FOR PC SIDE Below is my year 2000 project on all
PC softwares in my company. I created all testing procedures and hope that
these informations would be useful to someone in the world. Please EMail
me of new testing procedures and solutions if I missed in my project. It
would be greatly appreciated. C = Compliant NC = Non Compliant TR = Test
Required · Testing procedures: 1. Create a table with a Date field.
Set the value of the Date field to 12/31/99. Edit the Date field and change
it to 1/1/2000 to see if the application saves the Date value correctly.
2. Create a table with a Date field. Set the value of the Date field to
2/28/2000. Edit the Date field and change it to 2/29/2000 to see if the
application saves the Date value correctly. 3. Test to make sure that 1/1/00
is later than 12/31/99 4. Test to make sure that the system calculates
1/1/2000 as Saturday 5. Add 1 day programmatically to 12/31/99 to make
sure that the new Date is saved as 1/1/2000. Subtract 1 day programmatically
from 1/1/2000 to make sure that the Date is saved as 12/31/99. Do the same
thing for 1 week, 6 months, 1 year and longer. 6. Add 1 day programmatically
to 2/28/2000 to make sure that the new Date is saved as 2/29/2000. Subtract
1 day programmatically from 3/1/2000 to make sure that the Date is saved
as 2/29/2000. 7. Use Date functions to subtract 12/31/99 from 1/1/2000
to make sure that the result is 1. Do the same thing for 1 week, 6 months,
1 year and longer. 8. Use Date functions to subtract 2/29/2000 from 3/1/2000
to make sure that the result is 1. Do the same thing for 1 week, 6 months,
1 year and longer. 9. Test to make sure that a Date of 9/9/99 is not used
for any special occasions. 10. Check that all reports display 1/1/00 as
1/1/2000, not 1/1/00. 11. When the extra space 20 is inserted in a report,
Make sure line wrapping doesn t make a mess of it. 12. Change the System
Date to Long Date Display Format which shows 4 digit years in the operating
environment. Run all applications to ensure that it behaves as expected.
13. Check source code where it deals with Date in the following ways: Hard
coded 19 in 4-digit year field, Short Date, Long Date, Date used for calculation,
fancy Date and so on... You might find some surprises there. 14. Change
the System Date to 1/1/2000 in Win 3.1, Win 3.11 for WorkGroup, Win 95,
Win NT, OS 2 and all operating system running in the company. Open a project,
make some changes to the project and save the project. The operating system
should recognizes 1/1/00 as 1/1/2000 in the Short Date Display Format.
15. Change the System Date to 12/31/99 and change the System Time to 22:00.
go and get a nice cool drink and make sure that you return to your computer
before the 2 minutes expires. Who know what will happen? 16. Test all applications
to ensure that you are able to issue a cheque on 1/1/2000 and later. Some
old applications revert the Date from 1/1/2000 to 1/4/1980. 17. Make sure
that all applications crossing the year boundary calculating the difference
between the two dates correctly. 18. When PC systems communicate with Mainframe
systems, make sure that the Date is appropriately formatted for both end
to work. 19. Install all PC softwares on a workstation with a System Date
set to 1/1/2000 to ensure that they can be successfully installed. 20.
Can you change the default Short Display Date Format to Long Display Date
Format inside the application? 21. Require input of 4 Digit Year 22. Display
4 Digit Year on reports · DBXL - Dbase V? - Dbase database V? ·
C1, C2, NC3, NC4, NC5, NC6, NC7, NC8, C9, C10, C11, NC12, NC13, NC14, C19,
NC20, NC21 Problems encountered during testing: 1. When the Date is set
to Long Date Display Format in Win 95, Paradox 5 and Access 2 treat date
field 1/1/00 as 1/1/1900. 2. Fix source code to accomodate Long Date Displ t input Date
in 4 digit mode What will you do with each application · Renovate:
The application requires Year 2000 renovation. · Retire: Dump the
application in the junk yard. · Rehost: The application requires
conversion to a Year 2000 programming language, Year 2000 database management
system, or Year 2000 platform. · Replace: Replace the application
with a software package or other in-house application. · Redevelop:
Redevelop or rewrite the application. · Outsource: Let an outsourcing
company takes care of the application. · Retain: The application
is retained, as is, with no change.
Here's kind of an idiotic one. Starting on 1/1/2000, add 12 to the
month number. So 1/1/2000 would be 13/1/00. This will only work for files
that keep the month in the date as 2 digits (2 separate bytes per digit)
or use more than 4 bits for the month field (more than 16 possible combinations)
though. Otherwise, it should be pretty easy to work and wouldn't require
any modification of existing data. Just adjust the software to count the
century as being the 21st one if the month number exceeds 12. Neither would
this require any adjustment for the timer. Just recompile the progs on
new year's eve and make the thing add 12 to every month number. Either
that, or just stop it from checking the month, and allow the user to input
seemingly insane numbers, which, in reality, signify the coming of a new
era. :]
solution to what? There is no problem! We are people! we have brains!
we will figure out whats wrong a few weeks into the millennium! WE ARE
NOT STUPID
KILL EVERYONE GET HIGH AND DRUNK AND KILL YOUR PC BY GIVING IT A DRINK.!!!!!
as proposed by: Russ
Empire ..[Jul
15, 1997] ..Buffo, Idaho USA
Okay..we're dead...fine...GOOD !
as proposed by: Michael
Warren ..[Jul
18, 1997] ..NY, NY
We did it before and we will do it again!!!!!!
as proposed by: Danielle
E. Ferrara ..[Jul
26, 1997] ..Scotts Valley, CA 95066
Le PC, la machine la plus impersonnelle qui puisse exister malgré
les efforts de Microsoft, vient de signer une fois de plus son ordre de
repliement face au discret MacIntosh. La solution, I don't it know, mais
tout ce que je peux dire c'est que si les rôles étaient inversés,
à cet instant, il n'y aurait plus de problème puisque d'ici
l'an 2000 avec le bug horloge,on retrouvera dans de l'ambre microsoft .
Notre bien aimé BillGates sortira son dernier grand film "Informatique
Jurrassic park"
as proposed by: Mib
..[Aug 2, 1997]
..Berry-Bouy, Cher, France
Ignore it. The year 2000 comes, and all the banks get messed up. Good!
Maybe we'll become a worldwide community that shares it resources! Ahhh...
Tell the corporations to get updated software that has the 2000 capabilities.
Thousands of dollars is nothing if one is considering the money lost if
nothing is fixed.