Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Ask Michael Burke -- Ignore unavailable to you. Want to Upgrade?

To: Mary Cluney who wrote (36348)	11/16/1998 12:19:00 AM
From: Amir Shalit	Respond to of 132070

Marry, so are you saying that 600-800 billion lines of Cobol/PL1/Fortran code can be converted to C++/Java in a year as long as you buy the latest crap from Intel? <g> Give me a big break. If it was that easy no one would have waited to 1999 to do this conversion. Only specing what these older systems do would take more than a year. What type of fantasy world are you living in??? On another note, most of these systems are running on IBM mainframes and minis. IBM is still in business as you may or may not know and it's mainframe business is doing just fine. Amir

To: Mary Cluney who wrote (36348)	11/16/1998 12:26:00 AM
From: novice investor	Read Replies (4) \| Respond to of 132070

Hi Mary, >> You are right in so far as what the media is covering concerning the Y2K problem. It is 99% software related - very little if any is hardware related. << While old main frame software written in COBOL is the most obvious candidate for the Y2K problems, there are many hardware related Y2K problems. During 60s, 70s and even in 80s, small machines that happen to use time as data were designed to use only the lower 2 digits of the year to save space; in these devices, the software is stored in small amount of ROM within the machine. Unlike large COBOL programs, these ROM based software (often called "firmware") is essentially hardware problems because the only way to fix it is by replacing entire machine containing the ROM. Perhaps you may consider those millions of cash registers, answering machines, microwave ovens, VCRs, gas station pumps may cause no more than minor nuisance on Jan. 1, 2000. However the magnitude of the "firmware Y2K problem" becomes more serious when the same firmware based timer is used on airplane instruments, timed patient monitor systems at hospitals, nuclear power plant local valve controls, and countless number of military equipment. I am currently working at a medical instrument company where they are setting up a major task force to replace blood oxygen level monitoring device with Y2K compliant version. This device never displayed the date and it does not appear as something with Y2K problem; however, in diagnostic mode it prints out dates and that tiny code was found to be sufficient for it to systematically malfunction on year 2000. With all due respect to the Gartner Consulting Group, I believe they only addressed the problems found in the "computers" and their findings would not be accurate for all machines. Perhaps this is the most tricky part of Y2K problem, it is deeply ingrained in machines and devices that are not computers and manifestation of the problem is neither obvious nor expected. By the way, I'd like to add the IBM's infamous Report Program Generator (RPG) as another major culprit on your list of languages for the Y2K problem. During 60s, IBM in response for acute shortage of programmers, designed RPG as a programming language to be used by accountants. It accepts data in fixed formats similar to ledgers and, yes, it routinely used 2 digit for the year field. NI