|
What is the year 2000 problem? |
You must change the "short date style"
A setting located in Windows' Control Panel allows the system to use
a two-digit or four-digit year as the Windows default for "short date
style."
This is the format that many software applications use as their
default date format.
To avoid problems that may result with a two-digit year upon the change from 1999 to 2000, each user needs to change the short date style to indicate a four-digit year.
Windows `95
1. Click the Start button once.
2. Go to Settings, then click Control Panel once.
3. Double click the Regional Settings icon.
4. Click the Date tab at the top once.
5. For the short date style make sure that MM/dd/yyyy is selected.
6. Make sure that the long date style also has a yyyy format.
7. Click the Apply button, then the OK button.
Curtesy of Dennis Waldron
"The alternative to addressing the year 2000 will be going out of business."
-- Kevin Schick, The Gartner Group
The year 2000 date-change project presents organizations with one of the most interesting challenges since the dawn of the computer age. It is potentially the largest project the IS department has ever attempted. It has life-threatening implications for the business. It has an absolute, immovable deadline. It is a significant, unplanned, out-of-budget expense and it has no sponsor.
-- James A. Jones, Director of Year 2000 Group, Information Management Forum, in CIO Magazine, September 15, 1996
Mainframers are in serious denial these days about what will happen a couple of seconds after midnight on Dec. 31, 1999, when many thousands of mainframe programs handling critical business applications discover they don't know how to deal with dates that include the year 2000.
It's not that the world's COBOL programmers don't know how to fix the problem, or that current mainframe programming languages are incapable of handling dates in the next century. The problem is that mountain of old, fragile mainframe code still in use in business around the world - often running processes that lie right at the heart of a company's business. These applications have been around so long, were developed in such tangles of spaghetti code, and have been modified in undocumented ways so many times that no one now employed by the company knows how to fix them. In some cases, no one now alive knows how to fix them.
-- Jim Seymour, PC Magazine, Mar. 16, 1993
People see TIME as an endless continuum.
Computers record time and dates as just another number, and as time progresses the time number gets bigger - so a FUTURE date is always LARGER than a PAST date.
Some programmers interfered with this nice progression by deleting the century digits from dates - they didn't think they would be needed!
Without the century digits the last day of this millennium will be 99-12-31, and after the stroke of midnight many computers will see January 1, 2000, as 00-01-01 - a SMALLER number than the day before - time will appear to have REVERSED.
OLD will seem YOUNG, a FEW moments will seem like an ENTIRE century, FUTURE events will have ALREADY occurred.
-- Duncan G. Connall (dconnall@tiac.net), Global Software, Inc.
***
"As the year 2000 approaches, MIS organizations across the country have been wrestling with the problem of reprogramming date-dependent systems. Date-dependency refers to how most programs depend on the manner in which dates are represented in order to run computations. But as of the first day of the next decade, the way in which days, months, and years have been identified up to now will, in many cases, become invalid. For example, COBOL programs currently represent Feb. 26, 1990 as 900226, and Jan. 1, 1991 as 910101, allowing the computer to compare the two numbers and correctly assume that the smaller number represents the earlier date. On Jan. 1, 2000, or 000101, however, those comparisons will fall apart."
-- Informationweek, Feb. 18, 1991
Selected comments from the Year 2000 mailing list:
***
According to Gartner group, 90% of the applications will be affected by the Date 2000 problem, and systems will crash, if the century problem is not corrected before 1999. 20% of business applications will fail due to date computations in the year 1995. Most major corporations are expected to spend about $50-100 million. The Gartner Group estimates "A medium size shop with approximately 8000 programs, each program averages 1500 LOC, and a data reference to LOC ratio of 1:50 will cost in the range of $450/program to $600/program or $3.6-$4.8 million for the entire initiative".
There are an estimated 180 billion lines of COBOL code on MVS, and about 900,000 COBOL programmers dedicated to maintaining this code. If you would like to correct the date change operation, using automation tools and spread over a three year period 1996-1998, with out affecting the regular maintenance and new development, a minimum of 200,000 COBOL programmers should be added to the existing pool (Under the assumption that 1999 would be used, for fire-fighting measures). Going by the Gartner estimates, the total cost to correct the entire COBOL code would be US $48-65 billion. All these only for COBOL. Add Assembler, PL/I, Pick, ...
-- Raghavendra Rao (gr266@satyam.jvnc.net), Satyam Computer Services Limited
***
A bit more directly ... a major factor in the complexity of the Y2K issue is that we're dealing with many, many systems that have effectively been on autopilot for perhaps decades. What & how these systems work is entirely unknown to the current owners. The fact that System A somehow effects System Z is a very difficult & expensive piece of knowledge to have.
***
FYI, The July 1995 issue of CFO "The Magazine for Senior Financial Executives" ran a two page story by John Xenakis entitled: "The Millennium Bug, The Fin De Siecle Computer Virus -- COBOL programming can't handle dates after December 31, 1999. And don't count on your outsourcer to fix the problem."
The story paints a picture of a catastrophe in the making. According to Benny Popek of Coopers & Lybrand LLP, "This problem is so big that we will consider these bugs to be out of the scope of our normal software maintenance contracts. For those clients who insist that we should take responsibility, we'll exercise the cancellation clause and terminate the outsourcing contract."
And another quote from Popek, "We've found that a lot of our clients are in denial. We spoke to one CIO who just refused to deal with the problem, since he's going to retire next year."
-- Cliff Kurtzman (cliff.kurtzman@year2000.com), The Tenagra Corporation, http://www.tenagra.com/
***
Many of the denial party are saying they are going third party and so that will fix everything. But the reality is that there are many buried issues here as well such as conversion of existing systems and access to historical data (Data Dimensions published a very interesting Millennium Journal article about 3 months ago on third party issues). But it seems like it is human nature to try to push off the inevitable. Unfortunately for many, 2000 is a non-negotiable date. No one (not even IBM) can stop it.
-- Joe Warren (JoeWar110@aol.com), TransCentury Data Systems (in 1995)
***
This the first time I'm going to state some views 'publicly.' I've been holding back, because the title 'Chicken Little' is hardly one that sits well with me... nor is it one that reporters accept as 'credible.' AND the media have been remiss in helping businesses understand this problem, instead of describing it in detail, they've been treating it as 'Scientist Predicts All Computers Will Explode in 2000!' Hardly worthwhile reading material for a CEO, CFO or the Chair of the Board.
Take a look at the input screens of most accounting systems. These systems, typically legacy systems, the ones most likely to fail, control the true lifeblood of the organization... not INFORMATION! but something more mundane. Dollars.
Most of these systems accept ONLY 2-digit years. Why? Possibly because MOST data entry into these systems is date information and typing those 2 extra digits, time after time after time would be boring, tedious, inefficient and generally a pain in the arm.
Try entering 00 into one of these screens... you'll likely get... a data exception... or it won't accept the data as valid... or it will accept it... all of these will cause problems. The first two reject the data... that's good. The last is scary... will it process that 00 correctly?
Based on my personal programming experience, I'll predict that 90% of accounting systems will either reject the data or fail. To me, that's more than a reasonable estimate. Assume I'm off by 100% ... that only 45% of Accounting systems die. Watch what happens.
Okay... now it's 'whenever this happens' sometime between now and Day 1, Y2K. Most likely in 1999...
Your accounting system is dead in the water. What are the implications? Well... The most simple consequence is you can't cut or pay an invoice. No money will come into or leave your organization... (assume payroll is working... otherwise things only get worse... faster)
There are some organizations so literally computer dependant, they will NOT be able to get that cash flow moving EVEN if they hire 100 accounting clerks. What invoices do you pay? What do you bill? EVERYTHING is in the computer...The clock struck Jan 1, 2000 and the computer had a stroke.
Other companies will be able to generate a trickle of billing and payments by hiring manual labour... (How many clerks could you hire tomorrow? by next week?)
How FAST can you get an accounting system going? Can you fix the one you have? Or do you install a new one... Several of us, on this list have installed new accounting systems under pressure... how long did it take? 9 months? 6 Months?? 3 Months???
How fast can you install a new system when the entire company is a) screaming at you? and b) Blaming you? and c) the old system is dead and dead computers leave no audit trails.
How stable will your project team be ... when the company down the street is in the same predicament and offers huge 'incentives' to your staff to jump ship and help them? Will you lose your best and brightest or will you lose the bottom of your hope?
If you can't get your accounting system up and running in three months you're dead. Out of business, kaput ... Today's organizations CANNOT survive three months without cash flow. (and yes there WILL be a run on the banks as companies get desperate for cash advances NOW!)
Okay ... assume you have the very best and the very brightest ... your system is up and running in a week. (Loud laughter from the back of the room... not appreciated... nevertheless, the speaker continues unperturbed)
Remember that 45% failure rate? The VERY optimistic one? It means that 45% of the people you bill will not be able to pay. This is 100% out of your control ... 45% of your cash flow will be stopped even if your system is fine. Even if you have NO Y2K problems ... 45% of your clients do. So do 45% of your vendors ... can you order your raw materials if THEIR systems are dead? Oh, and remember that you've been pushing JIT inventory for years now ... your stock levels are deliberately low ... based on the assumption that the NEXT delivery is next week.
Can you build a car with 45% of the parts? Can you ship a product when 45% of the distribution channel is 'troubled' by the Y2K problem? Can you sell your product to me... If I have a Y2K problem? As Ted Nelson said in ComputerLib "Everything is InterTwingled"
Can you survive with 45% of your cash flow?
Will your computing staff stay around with salaries going through the roof? Especially for those who have PROVEN conclusively they can write Y2K compliant code!!!
How many companies need to fail...10% ? 25% ? 45% ? before a critical mass is achieved and it all comes tumbling down like a house of cards? We are all inter-dependant upon each other... we might NOT pass 'data' back and forth... BUT we DO pass invoices and other accounting and inventory information back and forth... managed by systems totally dependent upon digit deficient data.
-- Peter de Jager (pdejager@year2000.com) (in 1995)
Test and fix system hardware
The BIOS test is a floppy disk, date-safe test of the Real-Time Clock (RTC) and Basic Input/Output System (BIOS) of a system. It's date safe because it doesn't access the hard drive and doesn't endanger date-sensitive software or software licenses. The BIOS fix installs a device driver that monitors the RTC and BIOS date functions. The driver will automatically correct an erroneous century rollover. A convenient Windows-based System Date test checks the operating system's date handling characteristics.
Download Norton 2000's BIOS Test and Fix - for FREE!
http://www.symantec.com/sabu/n2000/
Here's how to check a PC's ability to roll over to Jan. 1, 2000:
1.Click the Start button, choose Programs, and look for MS-DOS Prompt.
2.When the MS-DOS prompt window opens, it may be so small that it's hard to read the text. If it is, click the Maximize button (the square box in the top-right corner of the DOS window). The prompt should say something like C:\WINDOWS.
3.Type the word date and press [Enter].
4.When the Enter new date prompt appears, type 12/31/1999 and press [Enter].
5.Now, type the word time and press [Enter]. When the Enter new time prompt appears, type 23:59:59 and press [Enter].
6.Wait a few seconds, then type date and press [Enter] again. If the system shows the current date is 1/1/2000, your system is okay. If it shows 1980 or 1900, you'll need to find out how to "patch" or fix your system, if a fix is available from the manufacturer.
Don't forget to reset
No matter how the test turns out, you must reset the date and time.
To do so, just type date, press [Enter], type the current date and press
[Enter] again. Then type time, press [Enter], and enter the current time
(in military or 24-hour format). To close the MS-DOS prompt window, type
exit and press [Enter].