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.

Technology Stocks : Discuss Year 2000 Issues -- Ignore unavailable to you. Want to Upgrade?

To: Bill Ounce who wrote (1405)	4/10/1998 10:48:00 AM
From: Bill Ounce	Respond to of 9818

Another Y2K denier admits he was wrong From: "Joe Friday" <green77@pcisys.net> Newsgroups: comp.software.year-2000 Subject: Another Y2K denier admits he was wrong. Date: Thu, 9 Apr 1998 20:39:54 -0600 This was posted on the Kitco.com discussion group Date: Fri Apr 10 1998 00:31 EJ (Y2K: did my homework, changed my mind) ID#45173: Copyright ) 1998 EJ/Kitco Inc. All rights reserved I reluctantly admit I was wrong in my initial assessment of the Y2K threat as less than severe. After 15 years in the high tech biz, half in software development, I speculated that locating and fixing Y2K bugs would not be too hard. In the past few weeks I have spoken with ten associates from my past, all of whom either currently work for or have in the past few years worked for financial services companies as application developers, the preferred title for folks who write computer programs, aka "programmers." Here is what I found. I assumed you can easily find instances in source code of date functions that manipulate data and fix them to account for numbers greater than 1999. ( Source code is the text-based programming language that gets translated into computer code by a special program called a compiler. ) That assumption was naive. First of all, date functions may be used many, many times in one of many programs that make up a complete application, such as an application that calculates derivatives on long terms bonds over 30 years. So just finding them is a big job. There is no good way to automate this, so a programmer must analyze the logic of each and every function to understand how it may work in many contexts. This is of course greatly complicated by the fact that the source code may have been written by someone else long ago and poorly documented. In addition, different compilers ( the programs that convert source code into machine code ) will generate different machine code from the same source code, so that it executes in different ways. Sometimes a function correctly deals with date forms greater than 1999 and sometimes not, depending on how a compiler inteprets the source code. So everything must be tested, whether a bug can be seen in the logic of the code or not. This has to be done to code that was hardly tested in the first place because of time constraints. One friend works as a programmer at a very large and well known financial services company ( hint: name begins with "F" ) and he says he is one of few programmers there who are NOT working around the clock to find and fix Y2K bugs. He says the project leaders on most of the teams doing this work cannot say with any certainty that they will have found and located all of these bugs in time. They are keenly aware that the stakes are high, so it is just about all they are doing. As I said in my last post, watch the 10Q's for signs of trouble. That's the good news. The bad news is that this work is being done most successfully on client/server systems that are relatively new. Then there are older mainframe systems that run using machine code for which there is no longer any source code--it was lost. That means you can't look at the text for functions that may be a problem. To solve this, compiler companies are creating programs that dissassemble machine code ( the reverse process of compiling source code into machine code ) to try to convert it back to source code so that humans can try to find logic errors in the use of date functions. The problem is that the source code that these programs make out of machine code is hard for humans to read. So the time consuming process described above is even more difficult. Also, the reverse compiler may be dissassembling machine code that was generated by a compiler that was made by a company that went out of business years ago. So you cannot be certain that the reverse compiler is correctly intepreting the machine code that it is converting back to source code. Also, you don't compile source code by running the dissassembler backwards. You need yet another compiler, and it may intepret the new source code so that date functions don't work as expected. The bottom line is, fixing software is very likely to take a lot longer than the time available. The companies with the greatest resources and highest stakes, like the one I've referred to here, at least have a shot at it. Not understaffed government agencies and low-margin businesses running old equipment ( e.g., IRS, Airlines, etc). So a lot of stuff ain't gonna work right, and some things are going to work at all. If you fly on Jan. 1, 2000, you are definately a nut. As far as business goes, a lot of folks are going to have to learn how to do transactions manually, on paper, with a pen. Regards, EJ