C(r)ash 2000

Jahr 2000: das Geschäft mit der Angst

Wissen | Hintergrund

Die einen sehen darin die größte Softwarekrise überhaupt, die anderen einen genialen Marketingfeldzug, um überteuerte Beratungsleistung und dergleichen unter die Leute zu bringen. Die Wahrheit liegt diesmal keineswegs in der Mitte.

Ja, es wird Probleme mit dem Jahr 2000 geben, aber deren Tragweite hängt sehr stark vom Einzelfall ab. Eine Vielzahl Menschen wird von dem Problem betroffen sein, unabhängig davon, ob sie unmittelbar selbst mit Computern zu tun hat oder nicht. Aber ein Pauschalchaos wird nicht eintreten. Insbesondere gilt das für den heimischen PC: Niemand muß befürchten, daß sein PC am 1. 1. 2000 aufwendig umgebaut werden müßte oder gar schrottreif ist (siehe [#Kasten106 Kasten]).

Der Keim allen Übels liegt in der Software. Die Programmierer waren sparsam: Anstatt Kalenderdaten in ihren Programmen mit einer vierstelligen Jahreszahl inklusive Jahrhundert zu versehen, geizten sie mit Speicherplatz. So nimmt manche Software nur die letzten beiden Stellen für voll. Auch knausrige Hardwareentwickler sind keine Rarität. Die Real Time Clock (RTC), die in jedem PC tickt, läßt das Jahrhundert außer acht.

Doch wer 1980 (oder noch früher) Software schrieb, hat bei den irrwitzigen Innovationszyklen in der Computerbranche einfach nicht damit gerechnet, daß Überbleibsel seiner Programme noch die Jahrhundertwende überdauern könnten. Viele Programmierer haben dabei die Rechnung ohne die Kompatibilität gemacht: Cobol als Weltwirtschaftsdialekt ist nicht totzukriegen, und auf PCs wie Mainframes läuft immer noch Software aus der 'Steinzeit'.

Bereits beim Sortieren von Rechnungen kann eine fehlende Jahrhundertangabe oder eine nur zweistellige Behandlung der Jahreszahl erhebliche Verwirrung stiften: In einer Liste mit offenen Posten erscheinen Rechnungen für das Jahr 2001 vor denen von 1999. Wenn der Sachbearbeiter eine solche Liste nicht bis ans Ende durchsieht, entgehen ihm wichtige Zahlungen - und verjähren womöglich.

Viel problematischer aber sind alle Berechnungen von Zeiträumen über den Jahrhundertwechsel hinweg: Wird 2002 als 1902 behandelt, ergibt sich zwischen 1998 und 2002 (1902) kein Zeitraum von 4, sondern einer von 96 Jahren. Da kann man fast hoffen, daß das Programm aufgrund des 'negativen' Zeitraums abstürzt und nicht mit der völlig falschen Zahl vorzeichenlos weiterrechnet.

Über Auswirkungen derartiger Aussetzer läßt sich vortrefflich spekulieren. Ob 2000 tatsächlich Rentner eingeschult und ABC-Schützen in Rente geschickt werden, die Zinsbelastung für den Häuslebauer ins Unermeßliche wächst, Flugzeuge und Satelliten vom Himmel fallen, Kernkraftwerke ihren Dreck in die Atmosphäre entlassen, darf bezweifelt werden: Für Banken und Versicherungen ist das Jahr 2000 schon längst Realität, denn schließlich profitieren sie nicht erst seit gestern von Verträgen, deren Laufzeit übers kritische Datum hinausreicht.

Ein Großteil jüngster Veröffentlichungen ist und bleibt deshalb Panikmache. Auch Flugzeuge kann man durch Vorstellen der internen Zeitgeber schon vorab ohne Passagiere testen und Problemen entgegenwirken. Zudem sind alle lebenswichtigen Systeme darin mehrfach redundant und meist diversitär (unterschiedliche Hard- und Software) vorhanden, so daß selbst der Ausfall einer Komponente nicht zum Absturz führt.

Daß die Programmierung mancher Videorecorder unter Umständen versagt, wenn sie am Silvesterabend 1999 und am Neujahrstag Sendungen aufzeichnen sollen, ist zu verschmerzen. Ebenso relativieren sich andere Verkündungen der Computerapokalypse.

Letztlich macht das Jahr 2000 aber auf einen generellen Mißstand von Software (und Hardware) aufmerksam: Ein Programm kann nur so vollständig sein, wie die Anforderungen, anhand derer es spezifiziert wurde. Enthält die Spezifikation keinen Punkt, der die zeitliche Lauffähigkeit beschreibt, hängt alles von der Weitsicht der Entwickler ab. Die greifen gern in die Trickkiste: Manches Programm stellt so nicht erst 2000 den Dienst ein, sondern am 9.9.99, weil gerade dieses Datum als 'Symbol' für nichtinitialisierte Datumsfelder oder als Marke dient...

Artverwandte Probleme machten der Softwarebranche schon immer zu schaffen. Sie schlagen meist nur deshalb nicht so große Wogen, weil der geographische Geltungsraum kleiner ist. Vor der hierzulande bevorstehenden Umstellung der Postleitzahlen anno '93 ging ein Aufschrei durch die Branche: Versandhäuser wie zum Beispiel Quelle bezifferten EDV-Umstellungskosten in Millionenhöhe. Neben dem Jahr-2000-Problem gesellt sich seit neuestem die bevorstehende Umstellung auf den Euro. Allen Problemen aber ist gemein, daß sie zwar durchaus - mitunter erhebliche - Kosten verursachen, aber dennoch alle bewältigt wurden.

Es gilt also, einen kühlen Kopf zu bewahren. Auf der einen Seite darf man das Problem nicht einfach ignorieren, auf der anderen Seite sollte man sich nicht in Panik versetzen lassen. Leider gehen die ausschließlich sachlichen Kritiker im Geschrei der unzähligen Berater und Dienstleister unter, die rund um die Angst vor dem Jahr 2000 ein gutes Geschäft wittern. Auch der Zusammenschluß etlicher Unternehmen in einer deutschen 'Initiative 2000' rekrutiert sich aus derartigen Dienstleistern und befindet sich in guter internationaler Gesellschaft.

Die Marktschreier malen düsterste Szenarien, untermauert durch Umfragen, in denen hierzulande viele Unternehmen einfach untätig abwarten. Sie sollen bisher weder Geld noch Zeit in Projekte fürs Jahr 2000 investiert haben, nicht einmal in Bestandsaufnahmen oder Analysen. Dabei sähe man angesichts mehrerer tausend Cobol-Programme, die einzeln zu untersuchen wären, dringenden Handlungsbedarf. Einige Analysten gehen sogar so weit zu behaupten, daß etliche Firmen eine Softwareumstellung nicht mehr rechtzeitig gelingen kann.

Die Hysterie, die entfacht wurde, entlädt sich zum Beispiel in einer Anfrage der Fraktion der Grünen an die Regierung zum Jahr 2000 und der Staats-DV. Die Antwort ließ nicht allzu lange auf sich warten: Es gibt keine nennenswerten Aktivitäten seitens der Verantwortlichen. Damit steht die deutsche Regierung fast allein. In Amerika und vielen unserer Nachbarstaaten laufen mittlerweile Projekte, die in regelmäßigen Abständen zu berichten haben. Es könnte sein, daß sich hier ein neues Loch für Theo Waigel auftut.

Ganz klar: Eine EDV mit zig Cobol-Programmen im Einsatz, die den Jahrhundertwechsel bisher ignoriert, dürfte in der Tat in Bedrängnis geraten. Und vielleicht sind hysterische Übertreibungen für diese sogar heilsam, damit etwas passiert. Doch entsteht immer mehr der Eindruck, daß hier lediglich einem '2000-Jahrmarkt' der Weg geebnet werden soll: Anbieter von Dienstleitungen oder Tools zur Umstellung zitieren gern Veröffentlichungen, in denen astronomische Kosten in Aussicht gestellt werden: So ist mittlerweile von einer Mark pro Zeile Quelltext die Rede, was sich schnell zu Milliardenbeträgen summiert. Ein idealer Hintergrund zur Abgabe eigener Angebote.

Immerhin zeigt sich ein Erfolg an einem Nebenschauplatz: Am Arbeitsmarkt wächst die Nachfrage nach Cobol- und Assembler-Programmierern alter Schule, um mit ihrer Hilfe alte Programme auf Vordermann zu bringen.

Zum eher sachlichen Lager kann man Peter de Jaeger rechnen. Er gilt in der Branche wenn nicht als Entdecker, so doch als Pionier des Jahr-2000-Problems. Er unterhält auf seiner Website den eindeutig besten zentralen Umschlagplatz für alle Arten von Informationen rund ums Jahr 2000. Allerdings haben die zusammengetragenen Informationen einen Umfang und eine Menge erreicht, die kaum noch zu überschauen ist.

Allmählich finden sich pragmatische Lösungen für das Jahr 2000. Um beim Umstellen von Software nicht auch den kompletten Datenbestand vom zwei- ins vierstellige Format konvertieren zu müssen, kann man sich mit einfachen Korrekturen über ein 'Zeitfenster' behelfen. Weiterhin zweistellig ausgeführte Datumsfelder werden unterschiedlich interpretiert: Liegt ein Datum etwa vor dem 1. 1. (19)70, so nimmt die Software an, es handele sich um die Jahre 2000 bis 2069. Lediglich Eingabe- und Rechenroutinen sind dann gegebenenfalls zu überarbeiten. Das ist natürlich keine Lösung für Situationen, in denen Verträge (etwa für Renten) oder generell Berechnungen über Geburtsdaten anfallen, die bis 1900/1901 zurückreichen.

Einen Schritt weiter ging der Amerikaner Harvey Alter mit seinem Vorschlag, doch die internen Uhren einfach um ein Vielfaches von 28 Jahren zurückzustellen. Das ist vor allem dort sinnvoll, wo es nicht auf die eigentliche Jahreszahl ankommt (etwa in autarken, allenfalls zu ersetzenden Geräten), sondern nur auf die Übereinstimmung von Wochentagen (der 1. 1. 1972 ist wie der erste 1. 1. 2000 ein Samstag in einem Schaltjahr). Harvey Alter hält für diese Idee ein US-Patent.

Unter den Defätisten raunt man währenddessen schon von einer 'Triage': Wer in Druck mit seinem Jahr-2000-Projekt gerät, soll sich nach Aufwandsabschätzung nur um eine Umstellung der Software kümmern, bei der überhaupt Aussicht auf Erfolg besteht und wo dieser zudem rechtzeitig erreichbar ist. Für alles andere, auf das nicht verzichtet werden kann, muß natürlich geeigneter Ersatz geschaffen werden.

In der ganzen Diskussion um vermeintliche Kosten und Zeitaufwand kommt eines viel zu kurz: die Situation für kleine Unternehmen ohne Mainframe im Keller und für Privatanwender. Sofern sie nicht nur Software von der Stange einsetzen, sondern womöglich im Auftrag erstellte Individuallösungen benutzen, sollten sie rechtzeitig Kontakt mit dem Hersteller aufnehmen oder sich anderweitig umtun. Die Nachfrage wird hier wie dort ganz bestimmt steigen, je näher das Jahr 2000 heranrückt.

Wer Software von der Stange einsetzt, läuft Gefahr ein Opfer des Jahr-2000-Problems zu werden, wenn er mit den kurzen Update-Zyklen nicht Schritt hält. Microsoft bespielsweise stellt nur dem aktuellen Jahrgang seiner Produktpalette einen Jahr-2000-Freibrief aus und hat bei dieser Gelegenheit auch die Verfallsdaten spezifiziert. Andere prominente Hersteller verfahren ähnlich. In der Regel genügt es, auf der Homepage die Suchfunktion anzusteuern und sie mit '2000' zu füttern, um an eine Liste der auf Funktionstüchtigkeit im Jahr 2000 getesteten Applikationen zu gelangen.

Doch der schönste 'Jahr-2000'-Bempel schützt nicht vor den Details. Angesichts der Funktionsvielfalt heutiger Software sollte man gerade zu Beginn skeptisch sein. Die Auswirkungen sind subtil: So lieferte die IBM Jahr-2000-Patches für die TCP/IP-Unterstützung von OS/2. Andere Hersteller werden mit ähnlichen Korrekturen folgen.

Auf einen Anspruch auf Schadensersatz oder ähnliches sollte sich bei Software niemand verlassen. Zwar sieht das Lager der Unheilspropheten eine Prozeßlawine auf die Branche zurollen, aber zumindest für Privatanwender und kleine Unternehmen dürfte sie bedeutungslos bleiben. In der Regel ist der Streitwert zu gering, als daß sich ein höheres Gericht überhaupt damit abgeben würde. Einziger Retter könnten die Verbraucherverbände sein, denen Gerichte entsprechende Vertretungsansprüche einräumen.

Jede Software, die mit zweistelligen Jahreszahlen arbeitet, ist ein potentieller Problemfall. Manche Hardware wie Videorecorder oder Uhrenradio könnte vorübergehend Überraschungen bescheren. Auf der anderen Seite findet sich aber ebenso eine Menge heiße Luft, wo teure Tools die Behebung von Problemen suggerieren, die es gar nicht gibt - etwa zur Korrektur der Echtzeituhr in PCs. Vor diesem Hintergrund gilt es generell darauf zu achten, keinem Scharlatan in die Hände zu fallen. Es ist daher dringend angebracht, jedes Angebot zu Hilfen bei der Umstellung gründlich zu prüfen. (ps)

[1] NSTL White Paper - Year 2000 Compliance and the 'Industry Standard' PC

[#anfang Seitenanfang]


Web-Browser in älterer Version von Microsoft und Netscape kommen beim Einsatz von JavaScript aus dem Tritt, wenn darin Datumsangaben aus dem Jahr 2000 vorkommen. Inzwischen ist das Problem behoben.

DOS, Windows 3.1 und Windows 95 melden nach einem Wechsel auf das Jahr 2000 im ausgeschalteten Zustand bei älterem BIOS den 4. 1. 1980. Meist läßt sich das Problem einfach beheben (s. Kasten [#Kasten106 auf der letzten Seite]).

EC- und Kreditkarten mit einer Gültigkeitsdauer ins Jahr 2000 hinein werden an einigen Zahlstellen abgewiesen - die meisten ausgegebenen Karten sollten inzwischen wieder eingezogen worden sein.

Raucher müssen im US-Bundesstaat Nebraska 2 Cent Sonderabgabe auf die Zigarettensteuer entrichten, damit die Behörden ihr Jahr-2000-Projekt finanzieren können.

GPS-Empfänger sind zwar nicht unmittelbar betroffen, arbeiten aber mit einer 10 Bit breiten Wochenangabe ausgehend vom 5. Januar 1980. Am 21. August 1999 findet hier ein Überlauf statt; ältere Firmware-Versionen könnten Probleme verursachen.

Bill Gates sammelt offene Briefe: Jetzt hat auch Peter de Jaeger einen geschickt - er bittet Gates, als Leithammel der Branche öffentlich Stellung zur Brisanz des Jahres 2000 zu beziehen.

[#anfang Seitenanfang]


DOS-Diskette booten. Datum und Uhrzeit kurz vor den Jahreswechsel 1999, also etwa 23:58. PC sofort ausschalten. Warten, bis die Stunde Null geschlagen hat. Bringt der date-Befehl nach dem erneuten Booten von der DOS-Diskette den 1.1.2000 zum Vorschein, ist ein System 2000-fest. Falls nicht, zeigt ein weiterer Test nach Umstellen auf den 1.1.2000 (via date) mit anschließendem Abschalten oder Kaltstart (Reset), ob das 'inkompatible' System sich belehren läßt - in der Redaktion tat das selbst das alte 386er Urgestein.

Das Aus- und Einschalten ist wichtig, weil ein harter Reset (Kaltstart) kaum so genau zu terminieren ist, daß der Überlauf der Real Time Clock (RTC) ohne aktives Betriebssystem passiert. Mit laufendem Betriebssystem ist der Test witzlos, da es in der Regel ein eigenes von der RTC losgelöstes Zeitmanagement enthält. Der Kaltstart ist wichtig, da nur dann einige Codeteile des BIOS, vor allem der Selbsttest (POST) durchlaufen werden. (Mehr im Kasten [#Kasten106 auf der letzten Seite].)

[#anfang Seitenanfang]


In einer Diskussion um EDV-Fragen in Zusammenhang mit dem Jahr 2000 ist der Euro nicht weit. Und mancher Programmierer schaut bedröppelt aus der Wäsche - schwant ihm doch Böses. Aber so schlimm ist es nicht: Wenn es zur Währungsunion kommt, dann werden Anfang 1999 die Wechselkurse der Teilnehmer eingefroren. Die nationalen Währungen bleiben zweieinhalb Jahre gültig. Erst dann ersetzt der Euro die jeweilige Landeswährung.

In der Übergangsphase kann bargeldlos sowohl in Euro als auch der nationalen Währung bezahlt werden. Da der Wechselkurs mit Einführung des Euro festliegt, kann Software mit einer festen Umrechnungstabelle (oder der Benutzer mit einer Rechenmaschine) arbeiten. Wenn die Landeswährungen abgeschafft sind, braucht ein Programm ebenfalls nur mit einer Sorte Geld umzugehen. Das heißt dann zwar anders, aber das sollte sich schließlich bewältigen lassen. Allerdings wäre es langsam an der Zeit, das Euro-Symbol in den Zeichensätzen der Rechner zu definieren.

[#anfang Seitenanfang]


Wer den unzähligen Verweisen im Internet folgt, die sich mit den Problemen von PCs im Jahr 2000 befassen, trifft mit 99prozentiger Wahrscheinlichkeit auf Unsinn. Noch hanebüchener geht es in mancher Zeitschrift zu: Da entsteht teilweise der Eindruck, man müsse PCs im Jahr 2000 verschrotten. Auf diesem mit Unfug gedüngten Acker blüht sogar schon das erste Unkraut.

Einige Firmen bieten gegen klingende Münze Software an, die PCs auf ihre Jahr-2000-Tauglichkeit hin überprüft. Da nimmt es kaum Wunder, daß es vom gleichen Hersteller dann auch Programme gibt, die die vermeintlichen Probleme beheben. Festzuhalten bleibt aber, daß eigentlich jeder die Software bereits besitzt, mit der er das Verhalten eines PC zum Jahreswechsel 2000 erforschen und etwaiges Fehlverhalten korrigieren kann. Wer dafür Geld ausgibt, ist schlecht beraten.

Die heutige PC-Zeitrechnung wird bestimmt vom AT, in dem IBM dereinst eine Uhr vorsah, mir deren Hilfe er auch im ausgeschalteten Zustand am Puls der Zeit bleibt. Im Motorola-Sortiment fanden die IBM-Ingenieure mit dem MC146818 einen geeigneten Baustein. Die Real Time Clock (RTC) enthält zusätzlich noch einige Dutzend Byte Speicher, in denen der AT und jeder heutige PC seine Konfigurationsdaten aufbewahrt (zum Beispiel Festplattenparameter und Chipsatzeinstellungen).

Die autonome RTC umfaßt einen kleinen Kalender, der um Mitternacht auch das Datum anpaßt. Unglücklicherweise arbeitet der Chip nur mit Jahrzehnten. Das heißt, zum Jahreswechsel 2000 springt er von 99 auf 00 zurück. Zwar hat die IBM ein Byte des CMOS-RAMs geopfert, um das Jahrhundert zu speichern, aber es bleibt unberührt von der Vorgängen in der eigentlichen Uhr. Es läßt sich nur durch direkte Manipulation des CMOS-RAMs verändern.

Die meisten PCs (jedenfalls alle, bei denen wir nachgeschaut haben) benutzen heute das Byte an Adresse 32h, nur IBMs PS/2-Modelle nehmen statt dessen 37h. Letztlich hat dabei jeder BIOS-Hersteller die freie Wahl. Das ist auch kein Problem, weil eigentlich kein Programm das Jahrhundertbyte direkt aus dem CMOS-RAM holt, selbst wenn es die Uhr direkt auslesen sollte. Die Anbieter besagter 2000-Software wollen den Kunden allerdings anderes glauben machen.

Statt direkt das CMOS-RAM und die RTC anzusprechen, greift Anwendungssoftware auf Uhrzeit und Datum über Betriebssystemfunktionen zu. Ältere DOS-Software geht gern auch direkte (Ab-)Wege und benutzt BIOS-Funktionen dafür (Int 1A, Funktion 4). Sie liefern erfreulicherweise auch gleich das der RTC fehlende Jahrhundertbyte frei Haus, so wie es im CMOS abgelegt ist. Die heutzutage im BIOS integrierten Setup-Programme ermöglichen das Einstellen der RTC inklusive Jahrhundertbyte.

Festzuhalten bleibt: Ein Betriebssystem kann das aktuelle Jahrhundert nur über BIOS-Aufrufe feststellen. Lediglich das Jahrzehnt liegt in einer einheitlichen Speicherzelle der RTC und kann so direkt ausgelesen werden. Kein PC beherrscht den Wechsel ins Jahr 2000 allein in Hardware. Das BIOS oder das Betriebssystem muß also unterstützend eingreifen.

Der Aberglaube, daß ältere PCs zum Übergang ins Jahr 2000 zusätzliche Software benötigen, basiert auf nicht unmittelbar einsichtigen Eigenschaften des BIOS, seines Setup-Programms und des Betriebssystems DOS, das momentan noch am weitesten verbreitet ist, wenn man die grafischen Aufsätze einschließlich Windows 95 dazurechnet - ja, Sie haben richtig gelesen: Auch Windows 95 bedient sich wie Windows 3.x des Datums, das DOS (7.0) beim Booten über den Aufruf von BIOS-Funktionen ermittelt.

Einige BIOS-Versionen respektive deren Setup-Programme, die wir uns angesehen haben, legen eine gewisse Intelligenz an den Tag: Sie überprüfen das im CMOS eingestellte Datum auf seine Gültigkeit, wenn man versucht, es im Setup zu ändern. So akzeptiert manches BIOS kein Datum vor dem 1. 1. 1980, manches keines vor 1994. Eine andere aktive Überprüfung findet aus naheliegenden Gründen indes nicht statt: Das BIOS müßte Schaltjahre et cetera kennen. (Einzige Ausnahme: Jahr-2000-Korrekturen, Erklärung folgt).

DOS akzeptiert als sinnvolles Datum alles ab dem 1. 1. 1980. Erhält es beim Booten ein seiner Meinung nach ungültiges Datum, so fällt es auf den 4. 1. 1980 zurück. Genau das passiert, wenn ein älterer PC im Jahr 2000 das erste Mal eingeschaltet wird, weil das Jahrhundertbyte nicht automatisch umgesetzt wurde. Seit DOS 3.3 genügt es, das Datum einmal auf den 1. 1. 2000 zu setzen (oder welchen Tag auch immer).

Der date-Befehl auf der Kommandozeile erledigt das ebenso wie die Uhrzeit- und Datumseinstellung von Windows (3.x und 95). Beide greifen auf die passende BIOS-Funktion zurück. Das BIOS paßt seinerseits das Jahrhundertbyte im CMOS an. Fürderhin bootet also auch ein PC, der den Übergang ins Jahr 2000 nicht selbst schafft, mit korrektem Datum. Es bedarf keiner zusätzlichen Soft- oder womöglich Hardware.

Ein moderner PC respektive sein BIOS erledigt das selbständig: Stellt er beim Einschalten oder beim Aufruf der Datumsfunktionen (die Art der Implementierung variiert von Hersteller zu Hersteller) fest, daß das Jahrzehnt unterhalb eines bestimmten Schwellwertes liegt (meist 80), korrigiert er das Jahrhundertbyte im CMOS. Das heißt aber, daß man sich spätestens 2080 von seinem PC getrennt haben muß...

Noch überflüssiger ist Software, die angeblich Jahr-2000-Fehler ausbügelt, für andere PC-Betriebssysteme: Linux (2.0.29), OS/2 Warp 4 (mit aktuellem Fixpack) und Windows NT (4.0) ignorieren das Jahrhundert im CMOS-RAM völlig. Sie arbeiten alle ähnlich wie der BIOS-Korrekturcode mit einem Zeitfenster, lesen lediglich das Jahrzehnt der RTC und schlagen unterhalb gewisser Grenzen die Jahre dem Jahr 2000 ff. zu. Entsprechend korrigieren sie das Jahrhundert im CMOS nicht.

Bliebe noch die Schaltjahreserkennung, also der korrekte Überlauf vom 28. 2. auf den 29. 2. oder 1. 3. je nach Jahreszahl. Hier kommt den PC-Besitzern wohl lediglich die Ausnahmeregel zur Hilfe, die besagt, daß alle vierhundert Jahre eben doch ein Schaltjahr ist; die RTC schaltet alle vier Jahre.

Nachzutragen ist noch, daß der sogenannte 'Wochentagtest' (ob das BIOS den 1. 1. 2000 als Samstag erkennt) keine hinreichende Aussage über die Jahr-2000-Konformität des Rechners trifft. Das korrespondierende Byte in der RTC wertet kein Betriebssystem wirklich aus; ja, DOS setzt es sogar, unabhängig vom tatsächlichen Wochentag, beim Einstellen des Datums via date-Kommando stets auf Null.

Anzeige