¢ o=o=o=o=o=¢¢ Y2K Revisited¢¢ It seems as if Y2K, and reactions to¢ it, won't go away. I've seen joke¢ after joke as well as serious comment¢ after serious comment about the Y2K¢ problem in the time between the last¢ issue and this writing. Some of what¢ has been written amounts to hysteria.¢ Although my comments to Joe Hicswa¢ weren't, I believe, hysterical in¢ nature, it seems that I may have been¢ a little too alarmist on some points.¢ Joe sent me a letter in which he said¢ that we're gaining publicity for¢ Atari user groups, and he thanked Tom¢ Andrews and me for the new newsletter¢ format. He also enclosed a letter¢ from A Mr. Thomas J. Pazel. Mr.¢ Pazel, who might have been a former¢ JACG member, describes himself as a¢ computer professional for the past¢ nineteen years with current mainframe¢ experience. I bow to that¢ experience, since my rather limited¢ mainframe experience goes back many¢ years. Also, some of what I said¢ about mainframes and the Y2K problem¢ stemmed from other writings and¢ comments that I now see as somewhat¢ hysterical.¢¢ Mr. Pazel states that the general¢ case with mainframes is that their OS¢ doesn't cause a Y2K issue. He feels¢ that those mainframes (probably the¢ majority in operation today) that run¢ IBM's MVS OS have the ability to¢ handle four digit years and have had¢ it for at least ten years.¢ Mainframes, as Mr. Pazel also points¢ out, can now go through power on¢ reset and initial program load in¢ minutes. Major upgrades can be done¢ in a couple of hours. If such is the¢ case, and I believe Mr. Pazel when he¢ says it is, there is no more¢ incentive for organizations to avoid¢ fixing their mainframe's Y2K¢ problems, if any such problems exist.¢ Yes, programmers might have to be¢ hired for big bucks. But the¢ alternatives can cause major problems¢ for those organizations.¢¢ Mr. Pazel also criticizes my letter¢ to Joe Hicswa, most justifiably,¢ where I imply that a mainframe in¢ Organization A may give another¢ mainframe in Organization B a report¢ that Organization A is about to go¢ bankrupt as a result of false¢ information generated in Organization¢ A due to a Y2K problem. He states,¢ correctly, that human intervention¢ should prevent such a situation from¢ happening. Hopefully, responsible¢ people will step in where this is¢ necessary. I'm reminded of a¢ situation many years ago. Our¢ military had built a series of radar¢ installations (the DEW Line) to¢ provide a distant early warning¢ against missle attacks by the former¢ Soviet Union. One day, a blip showed¢ up on the radar, quickly followed by¢ more and still more! It looked as¢ though the Soviets were throwing¢ their entire arsenal at us, and then,¢ MANY TIMES their entire arsenal! ¢ When the officers watching this¢ phenomenon finally realized that the¢ Soviets couldn't possibly have so¢ many missles and began to doubt that¢ such an attack was realy taking¢ place, the resulting alert was called¢ off. It was discovered that the DEW¢ system was responding to the moon¢ coming over the horizon, an event¢ against which it hadn't been¢ programmed! In short, we need¢ responsible people in responsible¢ positions who will intervene when¢ something that appears dire is really¢ the result of a Y2K problem. As Mr.¢ Pazel says, "My point here is that¢ most (if not all) companies are aware¢ of their Y2K exposures and will have¢ steps in place to handle any¢ unforseen problems. Those that don't¢ probably don't have much of a future,¢ anyway."¢¢ Mr. Pazel does, however, recognize¢ that there are systems out there with¢ Y2K problems. Those problematic¢ systems are not limited to¢ mainframes. They may also include¢ PCs and other computers and the¢ software that runs on them. One¢ illustration was brought home to me¢ during a coffee break at our last¢ OHAUG meeting. Some of the guys were¢ discussing Timewise, a time-¢ management program Atari put out some¢ years ago. Timewise has a Y2K¢ problem. However, if the only one¢ dependent on the output of the¢ program is the owner of the program,¢ that owner needs to know that he/she¢ can substitute the year 1972 for 2000¢ and the program will work properly.¢ Problem solved at the one-operator,¢ one-dependent level. Or, take the¢ case of electric typewriters (or¢ other appliances, for that matter)¢ with imbedded electronics for¢ maintaining time and date. Joe¢ Hicswa had such a typewriter and sent¢ it back to the factory because it had¢ a Y2K problem. Joe didn't make it¢ clear in his post card to me whether¢ the typewriter was recalled by its¢ manufacturer, or he discovered the¢ problem and sent it back. In either¢ case, the manufacturer is going to¢ remedy the situation. I wonder how¢ much brand loyalty that manufacturer¢ could muster if it were publicized¢ that they refused to remedy such Y2K¢ problems in their equipment!¢¢ You'd have to be living in a cave on¢ a mountaintop (with no radio, no TV¢ and no laptop) to claim that you're¢ not aware of Y2K these days.¢ Everybody has probably heard and seen¢ the same jokes and dire reports that¢ I've seen. Acting responsibly to fix¢ the problem -- or at least¢ maintaining a calm demeanor when¢ faced with the results of that¢ problem not getting fixed elsewhere -¢ - should be everyone's¢ responsibility. Closer to our Atari¢ 8-bit hearts, for those of us who use¢ SpartaDos and an RTime-8 cartridge,¢ for example, should be a willingness¢ to upgrade from version 3.2d to¢ 3.2g.¢¢ Thanks, Joe Hicswa, and thanks to¢ Thomas Pazel for pointing out what I¢ had overstated. I invite comment, as¢ usual, on this or any other topic¢ raised in this newsletter.¢¢ Alan Sharkis¢ Editor¢¢ o=o=o=o=o=¢¢¢¢
