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 : Formerly About Applied Materials -- Ignore unavailable to you. Want to Upgrade?

To: Ian@SI who wrote (20493)	6/17/1998 10:13:00 AM
From: Clarksterh	Read Replies (1) \| Respond to of 70976

Y2K problems primarily occur when dates from different millennia are compared. This has been happening for decades. i.e. - consider the determination of interest owed/paid on a 30 year bond/mortgage/etc; calculation of Pension entitlements,... Sure, and pensions, ... . As a consequence those problems have been largely fixed already. Remember the big problems the Social Security Admin computers in the late 80s? As a consequence they have fixed their systems. But most programs don't check that far ahead, and so they haven't yet been given priority. The expectation is that there will be a growing number of problems as we get closer to 2000, with a particularly big spike Jan 1, 1999. The concern is that a lot of systems just won't work, and it won't be so simple as just setting the system back 30 years. Today's computers are too tied in with other computers, so they will get conflicting info which itself causes problems. 2. Prime elevator concern is for the scheduling control software - i.e. Weekday vs weekend schedule. For non Y2K compliant software, a quick and easy bypass for that problem is to set the system date back by 28 years (in order to preserve the relationship between weekdays and weekends). Most elevator riders are unconcerned whether or not their elevator software believes the date is 1972 or 2000. This somewhat misses the point. Many products involved in public safety have maintenance requirements. Many, and probably most, use a countdown timer, but some use absolute date, and may refuse to operate nominally come sometime near Jan 1, 2000. 4. Most systems will be replaced by already planned enhancements, retired (because they've been of limited or no value for years), or patched because that can be done by upgrading the logic alone. This is, in part, the function that has been performed by maintenance programmers for decades. In fact, maintenance at the best organizations consumes more than 30% of the total manpower budget for IT technology; in most corporations maintenance approaches 70% of that budget. Well, there are several problems with this, but the primary one is that although there is a lot of 'maintenance', it is also true that most of it tends to be of the form of adding new features to old code. For instance, this fact explains why it is that up until recently there were very few COBOL programmers, but now it is in great demand. Up until recently no one was checking the old COBOL code, just adding new front-ends, or ... (in C, C++, ...). Clark PS This doesn't mean that I think Y2K is going to be a complete disaster, but I suspect that there will be a substantial hiccup(s) to the economy due to the problem. (After all, you can see the effects of the weather on the economy.)

To: Ian@SI who wrote (20493)	6/17/1998 1:13:00 PM
From: Katherine Derbyshire	Read Replies (2) \| Respond to of 70976

I think you're missing my point, probably because I don't think I've actually made it.... My point is that a lot of fab automation software uses dates to track things like maintenance intervals, cycle time, and things like that. Some of this software may treat "00" as an invalid date, and may or may not have robust handling for invalid dates. The consequences of poor handling of invalid dates are potentially severe. Probably nothing life-threatening, but there is a possibility of shutting either individual tools or entire fabs down for some period of time. If process tool Y2K problems shut down fabs for extended periods, fab owners will demand compensation, which could affect the tool supplier's bottom line. As individual tools have grown more intelligent, they have developed a vulnerability to this kind of error. Since process tools are much more complex than elevators, both the potential problems and possible workarounds are also likely to be more complex. My concern arises because AMAT's Y2K warning demonstrates no awareness whatsoever of fab floor issues, but only of back office potential problems (billing, accounting, etc.). Katherine