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 : Y2K (Year 2000) Personal Contingency Planning -- Ignore unavailable to you. Want to Upgrade?

To: Bill Wexler who wrote (68)	4/16/1998 4:26:00 AM
From: James Baloun	Respond to of 888

Why hasn't it happened yet? I don't think I can keep this short...sorry... From my understanding, we have not seen noticeable significant failures to date because we have been operating under the umbrella of the first cycles of the clocks and because the failures have been infrequent enough to he able to be handled by regular system maintenance, maybe a few small emergencies. Yes, it seems not much has happened. How long will this last? I have heard a few logical arguments for failures to become more frequent in the next two years. I think they will occur in more of a statistical distribution roughly centered on the turn of the century. Other clock roll over dates have been discussed. But will too many failures in a short time push us over the edge? I used to think the stock market didn't like uncertainty but the bull charges on... For example a coded equation that tries to divide by year 00 etc. The situation in the mainframes and PC's is bad enough. Programmers will be working hard to check what they can. What concerns me is the read only memory code in the embedded chips. I have worked with an engineer burning custom code into an EPROM chip. It is a mini computer that is then installed in a box and deployed to operate by itself. It could possibly have a date code included. Independent systems are widely used. I worked at Douglas Aircraft and heard about the magnitude of computer software difficulties involved in building the C-17 aircraft. Newer planes have more software. Planes can sustain substantial failures and survive and can operate on many systems other than the GPS. But is there a potential conflict somewhere in the lines of code? No one knows. The risk goes up. I only had the required semester of FORTRAN and I am impressed by how rigid was the logic and functions of the early languages. It was hard enough to get it to run. That's the problem with this problem. Logically there is the potential for a problem, no one knows when or where. You can take care of the problems you can remember, but have you forgotten anything? Will some of the few remaining problems happen where it is most inconvenient and lead to a cascade? General Motors is taking it seriously. Banks are the tightest tight-wads, yet they are coughing up millions. They squeeze us for every penny. Engineers study a system until the risk is brought down to a practical , acceptable level. Many planes fly, and some planes crash. This bug is one big wild card of unknown risk. How do I analyze it? I can understand it, but I can't say if you do this, everything will be all right. Even under normal conditions we live with an affordable risk. Risk that is carefully understood. The problem with Y2K is no one knows how big is the risk. It can't be carefully defined, there isn't enough time. Sorry if this sounds like a cop out, It is just the way it is. James

To: Bill Wexler who wrote (68)	4/16/1998 12:05:00 PM
From: Quad Sevens	Respond to of 888

Bill: For embedded systems, the answer is obvious. Close to 100% of date sensitive systems on the factory floor, for example, use date calculations over small time intervals. In the business IT world, a huge % of date calculations are also over relatively short intervals of time (securities trading, interest calculations, just-in-time inventory, billing, etc.). The sorts of calculations you mentioned have been dealt with in piecemeal fashion over the years. You're right: 30 year mortgage calculations have had to deal with y2k since the 70s. (There's no reason, BTW, a fixed rate mortgage has to be date sensitive at all. The payment schedule is a function of principal and interest-rate alone.) Life insurance calculations also come to mind. Programmers have known about y2k for forty years. I would expect the percentage of COBOL programs referring to date calculations for periods over 1 year is quite small. Finally, about "cataclysms": If Bank A's applications had crashed due to a long-term date calculation malfunction, it likely happened at a different time than it did for a similar problem at Bank B. At year 2000, you have the possibility of lots of things going haywire all at once with the programs dealing with day-to-day, week-to-week, month-to month stuff. It's the "all at once" part that is cause for concern. (Not to mention the huge amount of interaction among such programs.) Wade

To: Bill Wexler who wrote (68)	4/16/1998 8:08:00 PM
From: Bill Ounce	Respond to of 888

re: Bill's Questions What exactly is so magical about New Year's day - 1/1/2000? If we are going to experience significant impact from this "crisis", then why haven't these cataclysms occured now or in the past? Here's an attempt to answer these questions 2000/01/01 is "magical" for the following reasons: (1) It's the boundary of a data-space that many released systems have not been adequately tested against. Systems that use only the last two digits of the year have many extra discontinuities that must be addressed that never occur for systems that use a 4-digit date. One obvious example is division by zero. Then why haven't similar such cataclysms occurred yet? Actually isolated cataclysms occur from time-to-time. An unexpected condition causes an automated system to fail. So far, when such events happen, companies focus their resources to fix it. For example, earlier this week, AT&T's frame relay network crashed. (http://biz.yahoo.com/finance/980414/telecom_at_1.html) But it was only a single crisis, so AT&T focused on it and restored service after less than a day of down-time. If AT&T had multiple, simultaneous problems, it would have been much more difficult for them, and their customers (who used the network for financial transaction processing). Y2K is potentially very nasty because century transition bugs have been demonstrated to cause problems in an extraordinary variety of automated systems. If not fixed, a multitude of problems will be encountered in a very short amount of calendar time (from mid 1999 to first quarter 2000). Bonus question :-) Why do I take Y2K seriously (1) From personal experience, I know that large system (software, hardware, ...) upgrades rarely finish on time. Alot of large system upgrades are promised to fix things ahead of time. The track record for earlier such promises is not very good. (2) I used to do software testing for a living. I learned how to break things by identifying unexpected pivotal areas in the data space. 2000 is clearly one such area. (3) I've done coding and maintenance support for a living. I know how easy it is to mess up on date-involved calculations, and how long it takes to fix such problems. (4) I've done some systems integration for a living as well. It can actually be fun tracking down a problem when many systems are inter-connected. Lots of simultaneous problems may create a cataclysm that can't be easily fixed. (5) I have industry peers that tell me they know of Y2K bugs in software where they have lost the source code. (6) Their already exists a shortage of engineers and programmers. As remedation efforts pick up, will there be enough professionals to get the job done on time? CAVEATS Please note that this has zero to do with the "survivalist/religious nutcases" hyping Y2K. Easy profits for the Y2K industry are not guaranteed. IT labor shortage with its lack of workers and rising profits may put a damper on profits. Unrealistic contracts to fix unfixable systems may bankrupt some Y2K companies.

To: Bill Wexler who wrote (68)	4/16/1998 10:42:00 PM
From: RH	Respond to of 888

Here's a simple question, Bill. Why has every major corporation that I deal with, set up large departments to deal with the Y2K problem? They are spending a lot of money and have set up well organized PR departments to answer questions regarding their efforts etc. Seems to me its an awful lot of effort over a 'non issue', don't you think? But you know more than all the major banks, airlines, utilities, governments, telecommunications, auto makers....?

To: Bill Wexler who wrote (68)	4/16/1998 11:31:00 PM
From: Jeffrey S. Mitchell	Respond to of 888

Re: Why birthday logic will cause Y2K problems but works now This is a piece of cake. Here's an example in pseudo code: How old are you? (store result to variable "birthday") If year(birthday) <= year(today) year = "19" else year = "18" Endif etc. Yes, if the person is over 100 years old you have a problem. If you foresee that happening, you simply allow for a four character year. Dealing with past events is much different than, say, in 1975 coding for 25 years in the future. Re: Why mortgage calculations don't cause Y2K problems ...because they use "Year 1... Year 30" logic. Dates are irrelevant. - Jeff