Crash 2000 - wir bleiben verschont
Das ATARI-Betriebssystem hat im Unterschied zur WINTEL-Plattform mit der Jahrtausendwende keinerlei Probleme, jedoch kann im Einzelfall ungeeignet programmierte Software (bei jeder Rechnerplattform!) trotzdem Schwierigkeiten verursachen. Für diesen Fall werden einige unverbindliche Ratschläge gegeben.
Computer-Gau zur Jahrtausendwende (andere Systeme)
Zahlreiche Presse- und TV-Veröffentlichungen haben Computerspezialisten und hoffentlich auch alle Entscheidungsträger wachgerüttelt: voraussichtlicher Computer-Gau bei Großrechnern, der WINTEL- Plattform und Steuerungs-Microprozessoren um 0.00 Uhr im Jahr 2000 wegen zu knapp bemessenen Speichers für die Jahreszahl. So drohe beispielsweise der Stillstand von Fahrstühlen, deren Microprozessoren "glauben", die letzte Wartung läge bereits ca. 100 Jahre zurück (Wechsel von 99 zu 00). Noch kritischer könne es im Bankgeschäft oder gar bei Kernkraftwerken werden. Hoffen wir, alle für die o.g. Systeme Verantwortlichen ergreifen rechtzeitig, d.h. sofort, Gegenmaßnahmen. Schließlich gibt es nicht unbegrenzt viele Programmierer, insbesondere für alte Programmiersprachen.
ATARI-Betriebssystem weitsichtig programmiert
Glücklicherweise sieht das ATARI-Betriebssystem als größtes Datum den 31.12.2099 vor, so dass vom Betriebssystem her der ATARI-Gau erst im 21. Jahrhundert eintritt, d.h. nicht mehr zu unseren Lebzeiten. Laut ATARI-Profibuch für ST-STE-TT von Jankowski/Rabich/Reschke sind für die Datumsbehandlung die Befehle Gettime (XBIOS 23) und Settime (XBIOS 22) mit den Bits 25 bis 31 bzw. Tgetdate (GEMDOS 42) und Tsetdate (GEMDOS 43) mit den Bits 9 bis 15 zuständig, d.h. mit jeweils 7 Bits. Dabei stehen z.B. 0 für das Jahr 1980 und 119 für das Jahr 2099 (dies ist wegen einer Plausibilitätsprüfung die Obergrenze, maximal darstellbar wäre bei 7 Bits eigentlich 2 hoch 7 minus 1, d.h. 127). Nach Auslesen des Registers erhält man das Kalenderjahr durch Addition von 1980, umgekehrt subtrahiert man vom Kalenderjahr vorher 1980. Die Registerwerte 19 und 20 entsprechen somit den Jahren 1999 und 2000 und weisen keinerlei Unterschiede zu anderen zulässigen Registerwerten auf, d.h. von dieser Seite sind nicht die geringsten Probleme beim Wechsei in das nächste Jahrtausend zu erwarten. Stellt man z.B. mit dem ATARI-Tool CONTROL.ACC (von der Systemdiskette bis TOS 1.06, dann abgelöst durch XCONTROL.ACC) den 31.12.99, 23:59 Uhr ein, so zeigt der nächste Aufruf fehlerfrei Datum und Uhrzeit im nächsten Jahrtausend (Jahr 00).
Probleme im Einzelfall
Bei unglücklicher Programmierung sind im wohl seltenen Einzelfall Probleme denkbar. So verwende ich aus Platzgründen zum Briefeschreiben meist ein Minimalsystem ohne Festplatte und Hardware- Uhr. Das von mir verwendete Zeit-Einstellprogrämmchen im Bootsektor fragt nur ab, wenn Datum und Uhrzeit (jjmmddhhmm) nicht mit den Grunddaten einer TOS-Version übereinstimmen. Da im Bootsektor noch weitere Extras möglich sind, wurde die Prüfung wohl etwas zu sehr gestrafft, jedenfalls wird j=00 nicht akzeptiert. Falls kein Update erscheint, Uhrprogramme gibt es wie Sand am Meer.
Bei den modernen ATARI-Programmiersprachen (die ältesten entstanden erst nach 1985) und der großzügigen Speicherausstattung im Vergleich zu früheren Großrechnern dürfte ein Datumsproblem auf Programmebene im Normalfall nicht bestehen. Wer das Jahr möglichst kompakt speichern will, verwendet einfach die Verschlüsselung des Betriebssystems und kommt mit einem Byte aus. Weniger wird es auch dann nicht, wenn man, wie bei Großrechnern üblich, die Hunderterstellen kappt (z.B. 81 für 1981). Mehr wurde dort wohl auch nicht verkürzt, sonst bestünde das Problem nicht erst im Jahr 2000. Verwendet ein Programm die Betriebssystemdarstellung des Jahres, so ist alles o.k. Das Abschneiden der Hunderterstellen ist bei ATARI-Programmen nicht naheliegend, da immer wieder zwischen der Betriebssystemdarstellung (0 bis 119) und der gekappten Darstellung gewandelt werden muss. Anders sieht es aus, wenn Befehle für diese Umwandlung in der Programmiersprache enthalten sind. Wenn deren Schöpfer jedoch so weit gedacht hat, dann hat er wohl auch an die systemkonforme Umwandlung gedacht.
Leider beherrsche ich nur einen geringen Teil der auf dem ATARI verfügbaren Programmiersprachen. Bereits beim Urvater GFA-Basic (Version 2, Version 1 besitze ich nicht) ist es tatsächlich laut Handbuch so, dass zweistellige Zahlen richtig umgesetzt werden, d.h. 80 bis 99 als 1980 bis 1999 interpretiert werden und 00 bis 79 als 2000 bis 2079, d.h. zu unseren Lebzeiten kann bei Verwendung der Datumsbefehle das o.g. Problem nicht auftauchen.
Aufruf zu etwas Informationsaustausch
Vielleicht können die Experten dem Verlag eine Postkarte (neues Porto 1 DM) schicken, Text z.B. "Prospero-Fortran in 2000 o.k." oder noch wichtiger "Assembler Blabadu XY in 2000 fehlerhaft", als Kurzinfo zu allen von ihnen verwendeten Programmiersprachen. Auch exotische Sprachen interessieren. Der Verlag kann dann je Sprache und Risiko ja oder nein eine Strichliste führen und ohne Gewähr veröffentlichen.
Problematische Programme
Folgende Programmtypen (ohne Anspruch auf Vollständigkeit) können ein Problem bedeuten, jedoch nur, falls nicht vernünftig programmiert wurde (nicht mit dem vorgesehenen internen ATARI-Datumsformat, nicht mit den entsprechenden Systembefehlen, nicht mit einer das Datum richtig verarbeitenden Programmiersprache oder nicht sauber):
- zur Berechnung neuer Daten werden auch Daten eines früheren Zeitpunkts oder Zeitraums verarbeitet,
- eine Prozeßsteuerung oder Verarbeitung ist an bestimmte Termine oder Zeitabstände gekoppelt.
Risikominimierung
Das Risiko für den Privatanwender ist wohl sehr gering. Zwar sind auch die besten Programmierer nur Menschen, aber wieviel Programme verarbeiten denn das Datum und wie viele von diesen gefährden Ihre Finanzen usw. und wie viele davon verarbeiten das Jahr falsch? Wenn Sie natürlich Ihre Badewanne täglich per Rechner ferngesteuert füllen, sollten Sie ebenso wie professionelle Anwender, die industrielle Prozesse mit dem ATARI steuern, möglichst einen Testlauf mit Vorsichtsmaßnahmen starten.
Bei registrierter Kaufsoftware und Shareware, bei der das Datum eine Rolle spielt(!), können Sie noch einfacher nachfragen, indem Sie der Firma bzw. dem Programmierer in einem Umschlag (z.Zt. 1,10 DM Porto) eine an Sie selbst adressierte und frankierte Postkarte (z.Zt. 1 DM Porto) schicken. Text auf der Postkarte sinngemäß:
"Softwareprodukt XYZ, Version abc hat Probleme mit der Umstellung auf das Jahr 2000: ja/nein (bitte markieren!). Falls ja, Update erscheint voraussichtlich am......
Stellen Sie sich bitte vor, wie oft nachgefragt wird, daher so kurz wie möglich! Sie wollen doch schnell eine Antwort!
Falls diese Möglichkeit nicht (mehr) besteht, müssen andere Wege beschritten werden. Bitte lesen Sie diesen Textbeitrag zunächst sorgfältig bis zum Ende und beauftragen Sie Experten. Wichtig ist, dass Ihre vorhandenen Daten nicht gefährdet werden, insbesondere (mindestens zwei) Sicherheitskopien anfertigen. Falls mit auswechselbaren Datenträgern gearbeitet wird, kann alles auch mit einer „Spielkopie“ der Software gemacht werden. Nähere Ratschläge über ein Einbeziehen in Wartungsarbeiten oder Systemtests sind hier nicht möglich. Verhindern Sie unbedingt, dass ein nicht zeitgerechtes Starten irgendwelchen Prozesse (z. B. Pilzzuchtheizung) Katastrophen, auch finanzieller Art, auslöst. Eigentlich müsste bei Prozeßsteuerung eine Simulation durch Lämpchen oder was weiß ich - möglich sein. Wenn alle Vorbereitungen und Sicherheitsmaßnahmen getroffen sind, stellen die Experten möglicherweise das Datum auf ca. 23:50 Uhr am 31.12.99, falls vorhanden, mit der Einstellfunktion der zu prüfenden Software. In einer leeren (neuen) Datendatei erzeugen sie einen Test-Datensatz bzw. stellen einen periodischen Prozeßstart alle 20 Minuten ein o.ä. Sie achten darauf, was sich 10 Minuten später tut („Mitternacht“). Dann erzeugen die Experten mit denselben Testdaten wie eben 20 Minuten später einen weiteren Datensatz bzw. beobachten, ob der Prozeß dann startet. Ein Vergleich der beiden Datensätze mit einem Texteditor (z.B. TEMPUS oder QED) als ASCII-Datei ist empfehlenswert. (Die Datei erkennt man notfalls am Erstellungsdatum. Wenn dieses nicht 00 ist, hat Ihr Programm die Systemzeit durcheinandergebracht und ist nicht 2000-tauglich.) Beide Datensätze dürften sich nur in Uhrzeit und Datum des zweiten Datensatzes, dürfte meiner Ansicht nach bei dieser Software das Problem wohl nicht bestehen.
(Schließlich wurden die Zeitdaten beim Einstellen der Uhr vor Mitternacht in den rechnereigenen Zeitzähler eingespeist, dort um 20 Minuten (mit Datumswechsel) hochgezählt und dann wieder richtig ausgegeben.)
Natürlich muss die Sicherheitskopie anschließend wieder aufgespielt werden und evtl. die Testdatei gelöscht bzw. das gesteuerte Gerät/Prozeß wieder initialisiert werden. Abweichende Meinungen und Verbesserungen bitte an den Verlag als Leserbrief.
Wichtig
Alle Ratschläge und Ansichten sind als unvollständig, mit Fehlern behaftet, völlig unverbindlich und beispielhaft zu verstehen, ohne die Zusicherung eines gewünschten Ergebnisses. Sie gefährden durch die Befolgung möglicherweise Ihr Leben und das anderer, Ihre Hardware, Software, Ihre Datenbestände und, ggf. durch Folgeschäden, weitere Vermögens- und sonstige Werte.
Alle daraus abgeleiteten Vorgehensweisen und sonstige Aktivitäten erfolgen ausschließlich auf Ihr eigenes Risiko, eine Haftung muss ausgeschlossen werden.
Sicher erwarten Sie gratis auch nicht mehr. Wenden Sie sich für eine ordnungsgemäße Vorgehensweise an entsprechend ausgebildete und haftpflichtversicherte Fachleute.
Für Leser mit mehrgleisiger Ausstattung: Die o.g. Beipiele sind für WINTEL-PCs (IBM-Kompatible) gefährlich. Dort wird mit gewisser Wahrscheinlichkeit ein Crash ausgelöst. Sogar noch bei einem Teil der 486er PCs soll laut Zeitungsmeldungen das BIOS (der Kern des Betriebssystems) nicht 2000-tauglich sein.
Was die Programme mit den ganzen Ini-Dateien u.ä. unkontrolliert anstellen, scheint eine weitere Gefahr für einen Test zu sein (vgl. die Schwierigkeiten, bei Windows ein installiertes Programm und seine zahlreichen Hilfsdateien restlos zu beseitigen - jeder Bups ergibt eine eigene Datei und verbrät mindestens einen Cluster). Der Systemzusammenbruch würde dort dann vorverlegt! Bei Apple soll es keine Probleme geben, sowohl vom Betriebssystem her als auch (vermutlich) durch die strengen Rahmenbedingungen für die Programmierung.
Aber das ist sowieso eine andere Preisklasse bei Hard- und Software, und zumindest bei WINTEL kann man sich, wenn man einmal angefangen hat, der unheiligen teuren Update- und Bluff-Spirale nicht mehr entziehen.
Dieter Koch