Oracle sails through Y2k but still watchfulgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Oracle sails through Y2K but still watchful Reuters
Wednesday, January 12, 2000
Twelve days have passed since the date rolled over to Jan. 1, 2000, and there still haven't been any major computer-system blowouts, crashes or mass infections of software viruses.
The same goes for Oracle Corp., the world's second-biggest independent software company, the No. 1 purveyor of database software and second-largest seller of business management software.
It's what the 23-year-old company was hoping for.
``In general, it has been a big yawn,'' said Brad Smith, global program manager for Oracle's customer service continuity program, in an interview. ``That's what you're hoping for.''
Like most, if not all, global corporations Oracle got hopping on the Y2K bug long ago and, as a result, didn't expect the sky to fall when clocks rolled over across the globe's 24 time zones.
The Y2K bug stems from mainly older computer systems which were programmed to read only the last two digits of a year. If the glitch is uncorrected, computers could misread 2000 as 1900, causing systems to malfunction or even crash.
Special teams of Oracle employees began tackling the problem three years ago. The U.S. government, the 10 biggest Internet sites, banks, insurance companies, and many of the world's biggest companies rely on Oracle database software to help manage and run their businesses.
Oracle also has scores of customers who use its powerful business management software to help automate payroll, manufacturing, sales, human resources and other company functions.
Now that the initial crisis, or lack thereof, has passed, Oracle and many other companies are shifting into a phase of chronic searching for potential glitches. Many Y2K experts expressed some concern over Feb. 29, 2000 being a leap year. Much of that worry has since abated.
Indeed, the concerns now are more mundane and focus on a company's so-called back-office software. These are powerful programs, coupled with a database, that track inventory, accounts receivable and payable and managing a firm's supply chain.
``As companies close the books, this is where I see some problems popping up,'' Smith said. ``It's the links between all these systems.''
On Jan. 15, then again at the end of the month and again in February, companies will be rolling up the books for the first time after the much ballyhooed date change. ``We'll be watching traffic closely.''
DIGITAL DUCT TAPE
Companies with deep pockets such as General Electric Co., Ford Motor Co., Intel Corp., Dell Computer Corp., long-distance company Sprint, UAL Corp., parent of United Airlines, PNC Bank Corp., the Nasdaq stock market and Duke Energy Corp. all gave the green light as the date rolled over to 2000 in time zones throughout the world.
But many smaller companies, or those which got a late start, may have resorted to a sort of ``digital duct tape,'' Smith said.
``A lot of companies did some pretty crazy things to get ready for Y2K at the last moment,'' Smith said. ``They may have rolled their computers back to 1972 or threw up a bunch of (software) patches all over the place.''
But that form of preparation will only work for so long.
``Now comes the payday,'' Smith said. ``You've got to back out all that stuff and fix it correctly and we might see some trip-ups there.''
-- Homer Beanfang (Bats@inbellfry.com), January 12, 2000
Oh, yeah? From a company memo:
Our first "real" Y2K bug have now surfaced in production.
The following is a the message that I received _________date:
The Y2K error appeared in our new (from 1999) ATKS application system. This system has been built with ORACLE tools including Forms 4.5 (see specification of tools below).
We use a dateformat called DD/MM-RRRR where RRRR is a "smart" format of YYYY. The RRRR format is what causes the error. When entering dates in January 2000 while still in 1999, the date are shown as being in DECEMBER 2000!
According to ORACLE the only known work-around in Forms 4.5 is to use "fixed" format, i.e. specify the format DD/MM-RRRR with prefix "FX". The consequence of this is, that the user must enter 4 digits for the year. An alternative is to use the YYYY format. There is an alternative work-around in Forms 5, and the problem does not exist in Forms 6.
We have decided to code our way out of the problem and now use the format YYYY (the ATKS is not so big a system).
We use the following versions of the ORACLE tools:
Forms [32 Bit] Version 22.214.171.124.6 (Production) Oracle Toolkit Version 126.96.36.199.0 (Production) PL/SQL Version 188.8.131.52.0 (Production) Oracle Procedure Builder V184.108.40.206.3 - Production Oracle Virtual Graphics System Version 220.127.116.11.0 (Production) Oracle Tools GUI Utilities Version 18.104.22.168.0 (Production) Oracle Multimedia Version 22.214.171.124.0 (Production) Oracle Tools Integration Version 126.96.36.199.0 (Production) Oracle Tools Common Area Version 188.8.131.52.0 Oracle CORE Version 184.108.40.206.0 - Production
-- Forum Regular (Cannotsay@obvious.rsn), January 12, 2000.
My company bought ORACLE for our ERP. It works, but it is slow and clumsy. It crashes frequently. What used to take milliseconds now takes minutes.
-- John Litmann (LITTMANJ@AOL.COM), January 12, 2000.