SI
SI
discoversearch

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
AMAT 339.29+0.7%1:16 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Ian@SI who wrote (20493)6/17/1998 10:13:00 AM
From: Clarksterh  Read Replies (1) 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.)
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext