Re: The Great Year-2000 Hoax!
On Thu, 17 Oct 1996 17:44:18 GMT, mbovee@ukans.edu <mbovee@ukans.edu> posted: >Sam >You seem to misunderstand my question. I am not looking for an answer >to "What will happen to MY system (ie. what I are using at the >moment)." I am writing a white paper for a graduate class on database >applications, and am trying to find out if Y2K will have an impact on >various specific database uses, databases, and database management. > >Indivual users can set their computer to 2000, certainly. It is >recommended that they give it a shot, in fact. Corporate systems may >not wish to use such a test to see if the system will go "face down in >the water." It just might. You can readily set your PC to the 2000 date. As can I. My employer could probably do similar tests fairly "readily" (I can hear system administrators shuddering...); since there's about 15-20 mainframes in the data centre. Sparing one for Y2K testing is, if not desirable, at least *theoretically* feasible. For a company that only has one mainframe, and has code that they can't maintain anymore because the developers retired 15 years ago, it may prove more of a challenge. >I'm beginning to get the idea that a lot of people know of Y2K, that >for many it is a non-problem for their local system (but they haven't >thought about the broader implications of upstream or downstream >users), or they just haven't thought about it very much. Maybe I'm >wrong...maybe everybody out there is working on software that's so >flash that the millenium date change isn't a problem - just a toggle >or global default change and presto! the system now can interpret the >new century just fine. New software is not a problem. You would have to be a *complete* idiot to write code today that doesn't allow 4 digit year values. Database systems support it; development libraries support it. It's not a big deal to make new systems work. >Of course, there's all that data that, if stored w/a two-digit year, >is indistinguishable w/regard to the century. What the hell are folks >gonna do about that? Historical, epidemiologic, and other archival >data has lots of potential for problems as systems, old or new, go to >retrieve data that cannot be deciphered w/regard to the century. > >If I'm wrong, please tell me, but tell me w/specific examples as to >why, since my aim is to gather information and bring the level of my >understanding (and that of my classmates) about Y2K as it regards >databases and database management up to the highest level I can. Some software has been written using YYMMDD, and has been kludged to handle the century change. I was involved with a system that was (until its retirement last year) used to manage RRIFs (Registered Retirement Investment Funds). It used a YYMMDD date format because the institution wanted to save disk space, and expected the system to be a 6 month prototype. (Seven years later...) In the last year it ran, some bond certificates were starting to pass over the century mark, and obscure bugs started popping up. Peoples' ages had to be assumed to be able to be in the 1800's (all the individuals were over 71), which meant that there was clever code hacking with dates. Bonds expiring after 1999 means more clever code to handle the design flaws. *All* of the problems represented design flaws, as any reasonably forward-thinking design would have extended the date type to YYYYMMDD, and removed all need for "cleverness." Out of the probably 20 "systems" I have worked with professionally, probably 6-7 of them had much this sort of problem. I would be reluctant to assume that this extends across the software industry; I would also be reluctant to assume that it *doesn't* so extend. -- Christopher B. Browne, cbbrowne@unicomp.net, chris_browne@sdt.com Web: http://www.conline.com/~cbbrowne SAP Basis Consultant, UNIX Guy Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286