Das Jahr-2000-Problem - Ursachen, Auswirkungen, Lösungsansätze -

von Frank Ruschmeyer, E-Mail: 1ruschme@exvtc.de

[Inhaltsverzeichnis]


Kapitel 1


1.1 Einleitung

In der heutigen Zeit werden Planungen und Entscheidungen sowohl im wirtschaftlichen, als auch im privaten Bereich immer häufiger mit EDV-Unterstützung getroffen. Nur so ist es möglich die große Flut von Informationen in angemessener Zeit zu verarbeiten und auszuwerten. Hinzu kommt noch die Zuverlässigkeit der Verarbeitung und die Effizienz gegenüber manueller Datenhaltung, sowie ein Wettbewerbsvorteil in der jeweiligen Wirtschaftsbranche. Somit verwundert es nicht, daß in vielen Unternehmen die computergestützte Informationswirtschaft einen hohen Stellenwert einnimmt. Vielfach besteht bereits eine Abhängigkeit der Unternehmen von der eingesetzten EDV. Diese Abhängigkeiten sind besonders ausgeprägt, wenn es sich bei den EDV gestützten Prozessen um besonders kritische Prozesse handelt, deren Beeinträchtigung den Fortbestand des Unternehmens gefährden. Ein Teil- oder Totalausfall der computergestützten Informationswirtschaft würde ein solches Unternehmen vor große Probleme stellen, die möglicherweise den Konkurs bedeuten können. Auch ist zu beachten, daß es sich bei einem Unternehmen nicht um ein in sich geschlossenes System handelt, sondern daß unzählige Bindungen zu weiteren Unternehmen bestehen, mit denen intensiver Datenaustausch stattfindet. Infolgedessen ist ein Unternehmen nicht nur von der eigenen EDV-Infrastruktur abhängig, sondern auch von der Funktionstüchtigkeit seiner Umgebung.

Der in naher Zukunft bevorstehende Jahrtausendwechsel bringt ein EDV-Problem mit sich, daß es in dieser Form noch nicht gegeben hat. Die ersten zwei Stellen des Jahres im Datum werden von dem uns gewohnten Wert “19” auf “20” springen. Da viele Unternehmen für die Abwicklung ihrer täglichen Geschäftsprozesse mit dem Datum rechnen, wird diese Tatsache die Firmen mit EDV, sollte das Problem ignoriert werden, in eine Situation bringen, welche die oben genannten Folgen haben kann. Das außergewöhnliche an diesem Problem ist, daß eine “deadline” vorgegeben ist, die sich nicht verschieben läßt, der 01.01.2000. So beschreibt das Jahr-2000-Problem die Abbildung von Datumsfeldern in Elementen der EDV: Datumsfelder werden oft in sechs statt acht notwendigen Stellen repräsentiert. Der 24. Dezember 1997 wird so als “241297” gespeichert, wobei die 19 als Jahrhundertangabe suggeriert wird. Selbst in unserem täglichen Sprachgebrauch sprechen wir allzu oft vom Jahr 98 und nicht von 1998. Ein Problem ergibt sich dann, wenn ein Datum abgebildet werden soll, daß über das Jahr 1999 hinausgeht. Für den 01. Januar 2000 würde sich für einen Wert, der in einem sechsstelligen Datumsfeld gespeichert wird, “010100” ergeben. Die wenigsten Programme der derzeit eingesetzten EDV besitzen Mechanismen, welche die eindeutige Interpretation erlauben, ob es sich dabei um das Jahr 1900, um das Jahr 2000 oder um ein sonstiges Jahr mit der Endung 00 handelt. Beim Jahr-2000-Problem sollte man sein Augenmerk nicht nur auf die innerbetrieblichen Probleme der Unternehmen richten, deren Software am 01.01.2000 nicht mehr korrekt arbeiten könnte, sondern vielmehr auf die Folgewirkungen, die sich aus dem Datumswechsel ergeben. So trifft das Problem fast jeden Menschen auf dieser Welt, da jeder einzelne von uns auch indirekt, vielleicht sogar ohne es zu wissen, von der EDV abhängig ist. Nahezu alle automatisierbaren Prozesse wurden in den Industriestaaten mit entsprechender EDV von Handarbeit auf Computer oder Computerunterstützung umgestellt, um Zeit und Geld zu sparen. Würde das Problem also unbeachtet bleiben, ist mit einem Ausbleiben von Lieferungen, verspäteten Zahlungen oder einem Produktionsstillstand zu rechnen, um nur einige Beispiele zu nennen. Es wird folglich unabdingbar sein, die Datumsfelder in den Programmen in geeigneter Form zu korrigieren, so daß mit dem Wechsel ins Jahr 2000 ein reibungsloses Funktionieren der Software gewährleistet ist und Schäden an Menschen und in der Wirtschaft ausbleiben.

[Inhaltsverzeichnis]


Kapitel 2


2.1 Die Geschichtliche Entwicklung

Als Ende der 60er, Anfang der 70er Jahre die EDV Einzug in die Wirtschaft hielt, waren Computer, genauer gesagt die Speichermedien teuer. Dies betraf sowohl Speicherplatz in Form von RAM, als auch Disketten-, bzw. Festplattenplatz. Computer mit 64 Kilobyte Hauptspeicher und einer Festplatte, bzw. Magnettrommel von einem Megabyte waren groß und fast unbezahlbar. Eingabemedien wie Tastaturen oder Computermäuse waren noch Zukunftsmusik, weshalb man die Lochkarte, siehe Abbildung 2.1, als Eingabemöglichkeit für Daten nutzte. In Lochkarten wurden Löcher, die der codierten Information entsprachen, gestanzt und mit Hilfe eines Lichtstrahles ausgelesen. Erstmals war es möglich Routineaufgaben, wie Additionen oder Multiplikationen automatisch und jederzeit auf Knopfdruck durch Computer ausführten zu lassen. Diese Hollerith-Karten [1] faßten damals auf 12 Zeilen (Kanälen) und 80 Spalten, 80 codierbare Zeichen, was, verglichen mit den heute speicherbaren Datenmengen, sehr gering ist. Wenn man nur einmal seinen persönlichen Datensatz, bestehend aus Name, Vorname, Adresse, Telefon zusammen nimmt, überschreitet man diese Grenze um ein Vielfaches. So verwundert es nicht, daß ein Datumsfeld auf so einer Karte aus Speicherplatzgründen nicht achtstellig, also mit vierstelliger Jahreszahl, sondern sechsstellig codiert wurde. Diese Einschränkung war durchaus vertretbar, da man sich im 20. Jahrhundert wähnte und das fehlende Jahrhundert “dazu” dachte. Außerdem wäre dieser Umstand in der Zukunft sicherlich korrigierbar.

Mit der Einführung der ersten Programmiersprachen, wie FORTRAN, COBOL, BASIC, PL/1, u.a., konnte die Hardware noch effizienter und gezielter, vor allem aber eingabengesteuerter angesprochen werden. Diese Sprachen wurden vorwiegend im kaufmännischen Bereich eingesetzt, um Rechenoperationen zu automatisieren. Die Programmierer von einst blieben aber weiterhin bei dem bewähren, (speicher-) platzsparenden Programmierstil und implementierten ihre Programme mit zweistelliger Jahreszahl.

Mit dem technischen Fortschritt Mitte der 1970 Jahre setzte eine Miniaturisierung der Hardware ein. Zu dieser Zeit war die Entwicklung eines Programms noch recht kostengünstig. Die Hardware hingegen paßte sich in Ihren Kosten nur zögerlich der Software an. Aus diesem Grund wurden die verwendeten Datenstrukturen und Programme beibehalten und keine Änderungen hinsichtlich des Jahrtausendwechsels durchgeführt. Viele dieser Programme, vor allem branchenspezifische Lösungen, existieren deshalb heute noch. Niemand hätte damals angenommen, daß die Programme bis heute im Einsatz wären. In diesen Programmen wird in irgendeiner Form die Datumsberechnungen zweistellig ausgeführt sein, so daß eine Änderung des Programmcodes nötig ist. Ein Hauptaspekt dieser Programmentwicklung von damals war, daß in den frühen Computerjahren die Firmen spezielle Geschäftsinteressen verfolgten, wie zum Beispiel den “Ausbau Ihres Wirtschaftszweiges”, und die Computer deshalb als nützliches und arbeitserleichterndes Werkzeug verwandten. Mit dem Einsatz der Computer konnte man Arbeitsabläufe optimieren und rationalisieren. Eine Überarbeitung der bestehenden Programme, wie die Implementation von vierstelligen Jahresfeldern hielt man für unnötig, denn die Programme taten Ihre Pflicht und erfüllten ihren Zweck.


Abb. 2.1 Lochkarte

Als dann um 1980 herum die Personal Computer auf den Markt kamen, ging man dazu über, Software für immer wiederkehrende Berechnungen, fest in die Hardware zu implementieren. So entstanden Computerchips, wie das PC-BIOS (Basic Input Output System). Neben diesem Chip war unter anderem auch eine Echtzeituhr auf der Hauptplatine installiert, die ein Datum und eine Uhrzeit generierte, allerdings nur mit zweistellig ausgelegter Jahreszahl. Ein Fehler, der sich zur Jahrtausendwende als schwerwiegendes Problem darstellt, denn bis heute hat sich an der Grundarchitektur nichts geändert. Auch wurden immer häufiger Fernsehgeräte, Radios und digitale Uhren mit Computerchips ausgestattet, in denen ein festes Programm abläuft. Sollte diese “in Hardware gegossene” Software ein Datum verarbeiten müssen, kann sich unter Umständen auch hier ein Problem ergeben, wenn das Jahr nur zweistellig gespeichert wird.

Mitte der 80er Jahre trat eine weitere Wende in der EDV-Entwicklung ein: Die Hardware war plötzlich auch für Einzelanwender erschwinglich geworden. Die Software gestaltete sich aufwendiger und teurer, nicht zuletzt deshalb, weil Speicherplatz immer billiger wurde. Man war nicht mehr an zweistellige Jahresfelder gebunden, so daß die Programmiersprachen der 3. Generation, wie C++, u.a., über entsprechende Optionen zur Verarbeitung von vierstelligen Jahreszahlen verfügten. Dennoch wurde an alten Prinzipien, wie “never touch a running system” festgehalten, so daß die alten Programme nicht umgeschrieben oder ersetzt wurden und immer noch im Einsatz blieben. Wiederum verzögerten andere Geschäftsinteressen in vielen Firmen die Entscheidung dem Jahr-2000-Problem zu begegnen und eine Re-Programmierung der Software vorzunehmen.

Erst jetzt, Mitte der 90er Jahre, wo das Jahr 2000 näher und näher rückt, macht man sich Gedanken zu dem bevorstehenden Jahrtausendwechsel und den damit verbundenen Problemen von Berechnungen auf Datumsbasis, sowie der nach Datum gespeicherten Datenbankarchive. Meist wird die Zeit für viele Unternehmen mit einem großen EDV-Pool sehr knapp werden. Dennoch ist Eile geboten, eine Entscheidung hinsichtlich des Jahr-2000-Problems zu treffen, wenn ein programmtechnisch reibungsloser Wechsel ins nächste Jahrtausend gewährleistet werden soll.


2.2. Kalender und Schaltjahrberechnung

Auf Grund der verschiedensten geschichtlichen Entwicklungen auf unserer Erde unterscheiden sich auch die Kalendersysteme auf den einzelnen Erdteilen voneinander. So differenziert man zwischen gregorianischem, julianischem, hebräischem, islamischem und chinesischem Kalender. Unser heutiger europäischer und auch der nordamerikanische Kalender, ist auf die Ägypter und Griechen zurückzuführen. Wissenschaftler machten damals Zeitberechnungen auf astronomischen Beobachtungen der Mondphasen und definierten den synodischen Mond mit 29,5306 Tagen. Das Mondjahr umfaßte dadurch 354,397 Tage. Durch Julius Caesar wurde schließlich um 46 v. Chr. der julianische Kalender eingeführt, der sich auf das tropische Sonnenjahr von 365 Tagen stützt. Caesar legte darüber hinaus fest, daß alle 4 Jahre ein Schalttag eingeführt wird. Somit ergibt sich ein Durchschnittsjahr mit 365,25 Tagen. Dieser Kalender war bis ins 16. Jahrhundert Standard, ging aber auf Grund der Differenz von Mondjahr und Sonnenjahr 10 Tage vor (jedes Jahr 11 Min. und 12 Sek.), weshalb Papst Gregor XIII. um 1582 mit der Kalenderreform einen neuen Schaltalgorithmus einführte und die Berechnung des Kalenders um eine weitere Eigenschaft ergänzte Er errechnete, daß der Schalttag an vollen Jahrhunderten, mit Ausnahme der durch 4 dividierbaren , unterbleiben sollte. Durch diese Art der Berechnung ergibt sich ein Durchschnittsjahr mit 365,2425 Tagen. Dieser gregorianische Kalender wurde allmählich eingeführt. In Deutschland etablierte sich dieser Kalender im 17 Jahrhundert, in Griechenland beispielsweise erst 1923 !

Ein Schaltjahr berechnet sich nach Papst Gregor nach folgendem in einer fiktiven Sprache ausgedrücktem Algorithmus:

Wenn (Jahreszahl durch 4 teilbar ist) und
((Jahreszahl durch 100 teilbar) aber
(nicht durch 400 teilbar ist)) = ganze Zahl,
dann hat der Februar 29 Tage,
sonst hat der Februar 28 Tage.

Dem jüdischen und mohamedanischen Kalender liegt auch heute noch das Mondjahr mit 354 Tagen, 12 Monaten und 29 oder 30 Tage, zu Grunde.

Die Frage, die also entsteht ist, ob jedes Land ein Jahr-2000-Problem hat ? Grundsätzlich : Ja ! Einige Länder trifft das Problem nur früher als andere. Alle Länder, die EDV einsetzen, werden sich mit einem Datumsproblem auseinandersetzen müssen. Ob es nun Jahr 2000 oder ganz anders heißt, irgendwann wird jedes System datumsbegründet an eine Grenze stoßen, die Änderungen am Quellcode eines Programms unumgänglich macht.

Durch die verschiedenen Kalender ergeben sich auch verschiedene Bedeutungen für das Datum 01.01.2000. Die folgende Übersicht soll den Zusammenhang zwischen den verschiedenen Kalendern verdeutlichen:

Daraus folgt, daß das Jahr 2000 ein Schaltjahr ist, 1900 hingegen war keines. Testet man Computersysteme auf ein Schaltjahr im Jahr 2000, in dem man einen Datumswechsel am 28.02.2000 simuliert, werden viele Systeme mit dem 01.03.2000 antworten.

Aber auch bei Ländern, die das selbe Kalendersystem zur Grundlage haben können Probleme entstehen. So unterscheiden sich das U.S. amerikanische Datumsformat von dem europäischen durch eine Vertauschung von Tag und Monat. Der 31. Dezember 99, in Kurzschreibweise 31.12.99, wird im U.S.-Format als 12/31/99 dargestellt.


2.3. Datumsstandard nach ISO

Die Darstellung eines Datums sollte normalerweise eindeutig sein. So sollte man annehmen, daß die Industrienormen in dieser Sache richtungsweisend sind. Doch leider lassen die gängigsten Normen sowohl zwei- als auch vierstellige Datumsdarstellungen zu. Es gibt zwei Hauptnormen (und einige Varianten davon), die vorschreiben, wie Datumsangaben repräsentiert werden sollen:

Die eine Norm namens ANSI X3.30 - 1985 vom American National Standarts Institute gibt in ihrem Abschnitt über “Representation for Calendar Date and Ordinal Date for Information Interchange” (Repräsentation für Kalender- und ordinale Datumsangaben für Informationsaustausch) Auskunft über ein einheitliches Datumsformat. Diese Norm wurde als “FIPS 4-1” der Federal Information Processing Standards übernommen.

Die andere Norm ist unter ISO 8601 - 1988-06-15 zu finden und von der International Standards Organization aufgestellt. Hierin geht der Teil “Data elements and interchange formats - Information interchange - Representation of dates and times” (Datumselemente und Austauschformate - Informationsaustausch - Repräsentation von Datums- und Zeitangaben) auf das Datumsformat ein. Diese Norm wurde von der Canadian Standards Organisation als “CAN/CSA-Z234.5-89” übernommen.

Beide Normen stimmen darin überein, daß für gregorianische Datumsangaben die Form JJJJMMTT (alle Stellen numerisch, ohne Trennstriche) bevorzugt wird. Für ordinale Datumsangaben, also das julianische Format, besteht die Form JJJJTTT, wobei TTT für den Tag des Jahres steht. Man kann beide Formen verwenden, um sowohl mit der ANSI, als auch mit der ISO-Norm übereinzustimmen. Die Normen differieren in der Frage, wie das Jahr repräsentiert werden soll. Wenn eine Kürzung der Jahreszahl auf zwei Stellen erfolgen soll, weil einige Anwendungen dies erfordern, schreibt die ISO-Norm vor, daß die Bezeichnung “Jahr des Jahrhunderts” hinzuzufügen ist, damit weiterhin eindeutig das Jahr interpretiert werden kann. Diese Aussage scheint etwas irreführend zu sein, da zum einen in keinem Programm diese zusätzliche Bezeichnung auftaucht und zum anderen das Weglassen der Jahrhundertstellen die Ursache für das Jahr-2000-Problem ist. Die ANSI-Norm geht nicht näher auf dieses Thema ein. Beide Normen geben allerdings an, daß das Jahrhundert immer als das “aktuelle Jahrhundert” gelten soll, wenn die Jahrhundertstellen nicht verwendet werden. Das bedeutet, wenn heute “001224” verwendet wird, dann wird als Jahrhundert “19” vorausgesetzt, was folglich dem Datum “24. Dezember 1900” entspräche. Würde man im Jahr 2000 das Kurzdatum, zum Beispiel “991224” verwenden und als aktuelles Jahrhundert “20” voraussetzen, dann würde dieses Datum den 24. Dezember 2099 charakterisieren. Wenn ein Programm die Datumsangaben auf diese Weise behandeln würde, wäre es den Normen nach korrekt, das Resultat hingegen wäre falsch.

[Inhaltsverzeichnis]


Kapitel 3


3.1. Software

Die Software, die auf unseren Computern läuft, ist vielfältig. So unterscheidet man neben den verschiedenen Programmiersprachen, in denen Software geschrieben ist, die drei große Bereiche: Systemsoftware, Standard-Software und Individual-Software. Eine Systemsoftware, häufig auch als Betriebssystem bezeichnet, umfaßt alle Programme, welche die Ausführung der Benutzerprogramme, die Verteilung der Betriebsmittel auf die einzelnen Benutzerprogramme und die Aufrechterhaltung der Betriebsart steuern und überwachen. Anders ausgedrückt stellt das Betriebssystem eine Schnittstelle zwischen Benutzer und Hardware dar, die es ermöglicht, elementare Aufgaben und Funktionen auf einer Maschine auszuführen. Typische Betriebssysteme sind DOS ( disc operating system) im PC-Bereich oder UNIX auf Workstations. Als Standard-Software bezeichnet man meist ein Programm oder ein komplettes Programmpaket, daß ein eindeutig definiertes betriebliches Anwendungsgebiet abdeckt. Die Grundversion wird zu einem Festpreis vertrieben. Die Anpassung an die individuellen betrieblichen Anforderungen werden nach Aufwand berechnet. Als Beispiele lassen sich hier die Office-Familie aus dem Hause Microsoft nennen, oder das von SAP entwickelte R/3. Individual-Software kennzeichnet ein einzelnes Programm/Programmpaket, das meist in Eigenentwicklung entstanden ist oder von einem Softwarehaus speziell für dieses Unternehmen konzipiert wurde. Mit einer solchen Software wird z.B. die Prozeßsteuerung einer Fertigungsstraße geregelt und überwacht, die den Bedürfnissen dieser Firma optimal angepaßt wurde.

Die Standard-Software entwickelte sich erst Anfang der 80er Jahre, so daß in den Firmen, die damals schon EDV gestützt arbeiteten, meist eigens entwickelte Programme, also Individuallösungen, im Einsatz sind. Vielfach wurde nicht mit der nötigen Weitsicht geplant und eine Datumsinterpretation nur mit zweistelliger Jahreszahl angelegt. Auch die Systemsoftware hat Schwierigkeiten, das Datum korrekt und unzweideutig darzustellen. Hinzu kommt noch, daß all diese Programme in diversesten Programmiersprachen geschrieben sind. So wurden viele Anwendungen im kaufmännischen Bereich in COBOL geschrieben. Auch die Sprache PL/1, die für wissenschaftliche und kommerzielle Anwendungen, aber auch zur Systemprogrammierung eingesetzt wird, ist, wie COBOL, in den 60er Jahren weitläufig bei der Programmierung verwendet worden. PL/1 verwendet dieselben Datentypen wie COBOL. Weitere Beispiele wären FORTRAN, Assembler und BASIC ! Viele Programme, die in diesen Sprachen geschrieben wurden, haben eines gemeinsam: Eine Datumsinterpretation auf sechs Stellen, d.h. eine zweistellige Jahreszahl.


3.1.1 Systemsoftware

Die Systemsoftware läßt sich in weitere Bereiche unterteilen. So lassen sich dieser Gruppe zusätzlich zum Betriebssystem, auf das in diesem Abschnitt das Hauptaugenmerk gerichtet werden soll, noch Treiber, Bibliotheken und andere Komponenten zuordnen. Das Betriebssystem in einem Rechner übernimmt im allgemeinen das Datum und die Uhrzeit zunächst von der RTC ( Real Time Clock) und schreiben diese dann, unabhängig von den Einstellungen der RTC fort. Die RTC ist als fester Computerchip auf jeder Hauptplatine ( motherboard oder mainboard ) vorhanden. Sie enthält Register, die das Datum und die Uhrzeit speichern und auch beim ausgeschaltetem Rechner über eine Batterie mit Strom versorgt werden, so daß Datum und Uhrzeit weitergezählt werden.

Beim Anmelden an ein lokales Netzwerk ( LAN, Local Area Network) wird in den meisten Fällen die Uhrzeit und das Datum vom Hauptrechner ( Server) übernommen. Eine Korrektur der RTC durch das eigene Betriebssystem am Rechner (C lient) auf die Vorgabe durch den Server, erfolgt in aller Regel nicht. Es wird allerdings spekuliert, daß zukünftige Versionen von Betriebssystemen vom Benutzer eine Bestätigung, bzw. Korrektur bei Anomalien verlangen, die bei gewissen Systemen insbesondere beim Übergang ins Jahr 2000 auftreten können.


3.1.1.1 Microsoft DOS und Windows


Das auf vielen PC’s installierte Betriebssystem DOS ist ab Version 3.3 Jahr-2000-kompatibel. DOS ließt dazu aus einem Chip, dem BIOS ( Basic Input Output System), beim Bootvorgang das Datum und die Uhrzeit aus. Die Befehle time und date erlauben es dem Benutzer dann Einfluß auf die Systemzeit, bzw. das Systemdatum zu nehmen. DOS akzeptiert allerdings erst ein Datum, daß nach dem 01.01.1980 liegt. Dies liegt daran, daß 1980 das Entstehungsjahr des PC’s und damit auch von DOS ist. Die Obergrenze für einen Datumswert liegt bei DOS im Jahre 2108. Tests haben gezeigt, daß nach Änderung des Datums, mittels des Befehls date auf ein Datum im Jahr 2000, sowohl die Sortierung von Dateien in einem Inhaltsverzeichnisses ( directory), als auch die Ausgabe des Datums mittels date, korrekt wiedergegeben werden. Allerdings stellt DOS das mit dem Befehl dir aufgerufene Directory nur mit einer zweistelligen Jahreszahl dar, sortiert es aber dennoch, was die Ordnung betrifft, in der richtigen Reihenfolge.
Die Fensteroberfläche Windows ist eine grafische Oberfläche, die auf DOS aufsetzt. Dies bedeutet, daß die gängigen Windows-Versionen (3.x und 95) sich im Endeffekt des vom darunterliegenden DOS ermittelten Datums und der Uhrzeit bedienen. Auch wenn Windows 95 den Eindruck eines eigenständigen Betriebssystems vermitteln mag, wird das Datum von der DOS-Version 7.0 zur Verfügung gestellt.

Die ersten Windows-Versionen, Windows 3.x und Windows for Workgroups sind in 16bit Code geschrieben und haben in der Darstellung des Datums ein Jahr-2000-Problem. Der Dateimanger in der Version 3.1 zeigt das Jahr nur zweistellig an. Die Jahreszahl 2000 wird als “:0” angezeigt, aber beim Sortieren der Dateien richtig interpretiert. Microsoft hat aus diesem Grund ein Zusatzprogramm entwickelt, das diesen Umstand beheben soll. Dieses “Patch” soll die implementierte Datumsroutine in Windows umschreiben, so daß beim Jahrtausendwechsel das Jahr 2000 als “00” richtig dargestellt wird. Ohne dieses “Patch” kann es passieren, daß weitere Anwendungen, die auf Windows aufsetzen, das Jahr 2000 als 1900 interpretieren. Das Dateisystem dieses Windows ist allerdings Jahr-2000-tauglich und kann wie DOS das Datum bis zum Jahr 2108 fortschreiben.

In Windows 95, daß als 32bit Applikation verkauft wird, wurde das Jahr-2000-Problem berücksichtigt. Laut Aussage von Microsoft kann dieses Betriebssysteme Jahreszahlen von 1980 bis 2099, das Dateisystem jedoch bis 2108, verwalten. Hierzu muß man aber von Hand Einstellungen an Windows vornehmen. So existiert in den Ländereinstellungen der Systemsteuerung eine Möglichkeit, das Datumsformat auf eine vierstellige Jahreszahl zu setzten. Mit dieser Einstellung sollte es von Seiten Windows keine Probleme in der Darstellung des Datums geben. Windows NT geht sogar noch einen Schritt weiter. Hier wird das Datum direkt vom CMOS-RAM ausgelesen und in einem Zeitfenster verarbeitet. Das bedeutet, daß ab einem gewissen Schwellenwert das Datum unterhalb dieses Wertes zum 20., oberhalb des Wertes zum 21. Jahrhundert zugeordnet wird.


3.1.1.2 OS/2


Für das Betriebssystem OS/2 gilt im Prinzip dasselbe wie für das Betriebssystem UNIX, daß im Abschnitt 3.1.1.4 beschrieben wird. OS/2, auf einem PC-System installiert, bezieht das Datum und die Uhrzeit einmalig bei Booten von der RTC, die auf dem “motherboard” installiert ist. Das Datum wird aber anders als bei DOS in einem binären Zähler gespeichert, der sekundenweise aktualisiert wird. Das Register ist 32bit groß und erfährt einen Überlauf am 17. Sep. 2042. Das Filesystem arbeitet bis zum Jahr 2118 korrekt. Allerdings müssen die verschiedenen Versionen von OS/2 durch “Patches”, Jahr-2000-kompatibel gemacht werden. Das aktuelle “Fixpak (FP)” für Warp3 trägt die Versionsnummer 32 oder höher. Warp4 benötigt das FP 4 oder höher. Beim OS/2 Warp Server müssen 3 Module mit einem FP geändert werden.


3.1.1.3 Macintosh (Mac OS)


Bei Apple/Macintosh und Mac OS Computern besteht keine Sorge beim Jahrtausendwechsel. Seit der Entwicklung von Macintosh-Rechnern wird das Datum und die Uhrzeit, ähnlich wie in UNIX-Systemen, als ein Langwort (32bit) gespeichert, daß die Sekunden seit dem 01.01.1904 fortschreibt. Das Betriebssystem erfährt somit einen Überlauf am 06.02.2040 um 6:28 Uhr. In der Praxis wurde zur Darstellung mit einem Zeitfenster von 100 Jahren gearbeitet, um eine Kompatibilität zu älteren Macintoshsystemen der Version 6.x zu gewährleisten. Das Fenster deckt den Bereich von 1920 bis 2019 ab. Die neuesten Entwicklungstools von Macintosh arbeiten hingegen mit einem 64bit Integerwert, der eine ungefähre Zeitspanne von 30.081 v. Chr. bis 29.940 n. Chr. abdeckt. Das Mac OS unterstützt sowohl das Gregorianische Datumsformat, als auch das Arabische, das Persische und das Iranische.
Die zum Teil noch vereinzelt eingesetzten Apple Computer, der Serien II, II+, IIe, IIc und IIs sind unterschiedlich zu handhaben. So haben alle Modelle, bis auf den IIgs keine hardwaremäßig eingebaute Systemuhr. Es lassen sich diese aber von Drittherstellern nachrüsten. Alle Systeme sind dann Jahr-2000-kompatibel.


3.1.1.4 UNIX


UNIX ist ein Betriebssystem, daß von den Entwicklern mit der nötigen Weitsicht geplant wurde. So wird UNIX meist auf Computern mit 32bit Architektur eingesetzt. Aus diesem Grund verwaltet UNIX das Datum in Form einer 32bit Integer Zahl. Diese Art der Datumsinterpretation nennt man auch serielles Datum. In einer Integer-Variablen werden die Sekunden seit dem 01.01.1970, der Geburtsstunde von UNIX, fortgeschrieben. Ein Überlauf dieser Variablen findet am 19.01.2038 um 3:14:07 Uhr statt, denn dann ist der maximale Wert, den diese Variable speichern kann erreicht. UNIX wird also den Jahr-2000-Wechsel problemlos überstehen. Das Betriebssystem liefert das Datum den System- und Anwenderprogrammen über eine Vielzahl von API-Funktionen ( Application Programming Interface), sowie Verwalter- und Benutzerbefehle. Die API-Schnittstelle erlaubt es, mit gezielten Befehlen das Datum und die Uhrzeit abzufragen und/oder zu beeinflussen. So existieren einige Funktionen, die es durch zusätzliche Parameter erlauben, zwischen zwei- und vierstelliger Jahreszahlinterpretation sowohl in der Darstellung, als auch in der Verarbeitung zu unterscheiden. Hier gilt es, die Systemsoftware auf eventuell falsche Funktionsaufrufe zu überprüfen.


3.1.1.5 Sun Microsystems Solaris


Grundsätzlich sind alle Versionen ab 2.x von Sun Solaris Jahr-2000-kompatibel. Allerdings sind für die Versionen bis 2.5.1 ein “Patch” nötig, daß von Sun für Kunden mit Servicevertrag bereitgestellt wird. Mit Version 2.6 ist die Jahr-2000-Kompatibilität gewährleistet. Auch Sun OS ab Version 4.1.3 ist mit einem “Patch” Jahr-2000-kompatibel.


3.1.1.6 IBM’s AIX


Das Betriebssysteme AIX von IBM ist für verschiedene Computertypen konzipiert und deshalb auch unterschiedlich zu handhaben, was die Jahr-2000-Kompatibilität angeht. AIX ist ein auf IBM Computern, meist der Serie RS/6000, abgestimmter UNIX-Dialekt, der den Jahrtausendwechsel, wie UNIX selbst, problemlos mitmacht, da das Datum in Form von Sekunden in einer 32bit Integerzahl gespeichert wird. Von IBM sind in der Zukunft neue Versionen von AIX geplant, die das Datum in einer 64bit Integerzahl aufnehmen soll, wodurch sich der darstellbare Datumsbereich vervielfacht. Nach Auskunft von IBM ist die neueste Version 4.2.1. Jahr-2000-kompatibel. Die Versionen 4.2.0, 4.1.5, 4.1 und 3.2.5. sind durch ein “Patch” korrigierbar. Darunterliegende Versionen sollten durch ein Update ersetzt werden. Zu Bemerken ist noch, daß AIX in der Version 3.2.5 eine Jahreszahl bis 2037 verarbeitet, die Version 4.1.4. ein Datum bis 2038. Alle Versionen erkennen das Jahr 2000 als ein Schaltjahr.


3.1.1.7 HP-UX, MPE/iX, NetServer OS und RTE-A


HP-UX ist ein weiterer UNIX-Dialekt, der auf Computer der Serien HP9000 und HP 3000 PA-RISC, sowie Intel-basierten Servern eingesetzt wird. Die Versionen 10.01, 10.10 und 10.20 können durch ein “Patch”, das für Vertragskunden kostenfrei zur Verfügung steht, Jahr-2000-kompatibel gemacht werden. Kunden mit HP-UX Versionen der Serie 9.x oder niedriger, sollten ein Update auf die Version 10.x in Betracht ziehen, so HP. Das System MPE/iX ist in der Version 5.5 Express 4 mit einem “Patch” Jahr-2000-kompatibel. Betriebssysteme mit Versionsnummern darunter sollten durch ein “Update” ersetzt werden. Das auf PC-Basis entwickelte Betriebssystem NetServer OS arbeitet ähnlich wie DOS mit der RTC, von der Datum und Uhrzeit ausgelesen werden. Das Datum wird dann allerdings durch eine softwarebasierte Uhr fortgeschrieben, so daß diese Uhr unabhängig von der RTC arbeitet. Die meisten Server werden beim Jahrtausendwechsel das Datum und die Uhrzeit in der RTC automatisch korrigieren. Für die verbleibenden Systeme, zum Beispiel HP NetServer LC (4/66, 4/100, 5/66), HP NetServer LE und LF, sind manuelle Korrekturen mittels entsprechender Tools, oder durch Eingabe des Befehls date am DOS-Prompt nötig. Da diese Computer als Server fungieren, sollte nach einem ReBooten des Systems nach dem 01.01.2000, darauf geachtet werden, daß das Datum korrekt von der RTC übernommen wurde. Das Betriebssystem RTE-A, daß für Computer der Serie HP 1000 entwickelt wurde, ist bis auf eine Ausnahme Jahr-2000-kompatibel. In einem Editor (Edit/1000) wird mit einem Zeitstempel gearbeitet, der durch das Format YYMMDD:HHMM fest vorgegeben ist. Ansonsten sind das Betriebssystem und das Dateisystem bis zum Jahr 2038 kompatibel.


3.1.1.8 Siemens Nixdorf BS2000


Das von Siemens/Nixdorf entwickelt BS2000 wird auf Großrechnern ( mainframes) der Modellreihen C40 bis C80, H60 bis H130 und S110 bis S130 eingesetzt. Alle diese Rechner verfügen über eine interne, hardwareimplementierte und damit permanente RTC oder sind mit Funkuhren ausgerüstet, die von der Atomuhr in Braunschweig gesteuert werden. Das Betriebssystem kann das Datum korrekt bis zum Jahr 2048 darstellen und würde dann einen Überlauf erfahren. Das “Ursprungsjahr” ist der 01. Januar 1900. Alle aktuellen Versionen des BS2000 seit 1993 müssen nicht “gepatched” werden. Jedoch verfügt das Betriebssystem über systemnahe Funktionen, die direkten Einfluß auf die Datumsroutine nehmen können und somit bei eventuellen Fehleinstellungen Probleme hervorrufen. Diese Funktionsaufrufe sind von der BS2000 Liefermenge, bzw. Funktionsmenge abhängig.


3.1.2 Standardsoftware


Die meisten Standardanwendungen können Datum und Uhrzeit vom Betriebssystem lesen. Nicht alle Anwendungen verwenden das Datum jedoch in geeigneten Datumsformaten oder anderen zeitbezogenen Informationen. Es kann also durchaus möglich sein, daß ein Betriebssystem das Datum mit einem vierstelligem Jahr zur Verfügung stellt, das Anwendungsprogramm jedoch nur die letzen zwei Stellen verwendet, um Berechnungen auf Datumsbasis auszuführen. Eine andere Möglichkeit zur Datumsermittlung eines Anwendungsprogrammes ist das Umgehen des Betriebssystems und das direkte Auslesen des Datums aus der RTC. Meist erlaubt es auch die Standardsoftware selbst, über entsprechende Menüs das zu verwendende Datumsformat auszuwählen.
Eine weitere Schwierigkeit in Bezug auf das Jahr-2000-Problem stellen Updates dar. Gerade bei Standardsoftware, finden circa alle 3-5 Jahre Updates der Anwenderprogramme statt. Diese werden in den meisten Fällen nicht völlig neu entwickelt, sondern basieren auf bereits geschriebener Software, die dann um weitere Funktionen ergänzt wird. Somit werden interne Routinen, wie die Datumsberechnung, selten neu geschrieben, sondern einfach von der alten Version übernommen. Der Grund für diese Vorgehensweise ist einfach: Es muß eine Abwärtskompatibilität zu den älteren Versionen gewährleistet sein. Die implementierte Datumskalkulation pflanzt sich also in der neuesten Version fort. Auf älteren Systemen könnten Updates mit überarbeiteter Datumsroutine, die eventuell eine ganz andere Hardwarearchitektur voraussetzt, somit nicht eingesetzt werden.


3.1.2.1 Beispiel MS Office


Sind zusätzlich zur Windowsoberfläche noch Microsoft - Produkte aus dem Office-Paket installiert, so lassen sich auch hier Probleme bei der Datumsverarbeitung erkennen.
In der Tabellenkalkulationssoftware Excel Vers. 7.0 für MS Windows 95 haben die einzelnen Zellen spezielle Formate. Wählt man kein besonderes Format aus, ordnet Excel 7.0 automatisch ein Format zu, daß dem eingegebenen Wert am nächsten ist. Gibt man Datumswerte in die Zellen ein, werden alle Jahreszahlen anstandslos akzeptiert. Jedoch werden diese vom Programm unterschiedlich interpretiert und dargestellt. So wird, wenn der Benutzer ein Datum mit vierstelliger Jahreszahl eingibt, bis zum 31.12.2078 der Wert als Format “Datum” interpretiert, jedoch als 31.12.78 dargestellt, was zu Verwirrungen führen kann, wenn in einer Excel-Tabelle auch Datumswerte aus dem 20. Jahrhundert vorkommen. Ein Datum ab 01.01.2080 wird als “Standard”, also Text gespeichert. Hat man explizit ein Datumsformat mit zweistelligem Jahr eingestellt, verwaltet Excel 95 dieses bis zum Jahr 2019, Excel in der Version 97 bis 2029. Es wird in den unterschiedlichen Versionen mit verschiedenen Zeitfenstern gearbeitet. Zwar lassen sich in den Formatierungseigenschaften der Zellen verschiedene Formate zum Oberbegriff “Datum” auswählen, jedoch ist kein Format TT.MM.JJJJ implementiert. Man sollte also ein benutzerdefiniertes Format erstellen, um eine einwandfreie Darstellung und Berechnung zu gewährleisten.
Auch an der Datenbanksoftware MS Access 95 müssen vor dem Erstellen von Datumsfeldern Einstellungen vorgenommen werden, damit ein Datum größer 2000 richtig interpretiert wird. Das Format “JJ” würde tatsächlich nur bis 1999 funktionieren, während das Format “JJJJ” Datumswerte bis 9999 zuläßt. Das Update Access 97 interpretiert einen Wert im Datumsformat “JJ” bis 2029. Dies ist möglich, da mit einem Zeitfenster, hier also von 1930 bis 2029, gearbeitet wird ! Untersuchungen bei Access 2.0 haben gezeigt, daß die Datei “OLEAUT32.DLL”, also eine Bibliotheksdatei, die mit dem MS Internet Explorer 3.0 installiert wird, für die Interpretation der zweistelligen Jahreszahl verantwortlich ist.
Die folgende Tabelle zeigt die Office-Produkte mit ihrer Jahresbeschränkung beim entsprechend gewähltem Datumsformat.


Produktname
Datumsgrenze
Datumsformat
MS Excel 95
2019
Kurzform “JJ”
MS Excel 95
2078
Langform “JJJJ”
MS Excel (nächste Version)
2029
Kurzform “JJ”
MS Excel (nächste Version)
9999
Langform “JJJJ”
MS Access 2.0
1999
Kurzform “JJ”
MS Access 95
1999
Kurzform “JJ”
MS Access 95
9999
Langform “JJJJ”
MS Access (nächste Version)
2029
Kurzform “JJ”
MS Project 95
2049
Kurzform “JJ”
MS Visual FoxPro
9999
Langform “JJJJ”
MS Schedule+
2079
Kurz-/Langform
Tabelle 3.1.2.2: MS Office Produkte und deren Datumsobergrenze (Stand: 15.10.1997)
Quelle: http://www.microsoft.com/win32dev/guidelns/getready.htm

3.1.2.2 Beispiel Borland


In allen dBASE-Versionen, von Version III+ bis zum gegenwärtigen Visual dBASE für Windows 5.5, sind alle Datumsfelder als Textstring im Format “JJJJMMTT” gespeichert. In der Version III+ wurde ein neuer Befehl eingeführt, der es ermöglicht, die vierstellige Jahresdarstellung einzuschalten. Alle Berechnungen und die Speicherung von Datumswerten, verarbeiten die Jahreszahl richtig, unabhängig davon, ob die Ausgabe des Jahres zweistellig erfolgt. Eine Jahreszahl ohne Jahrhundert wird sowohl im Speicher, als auch auf der Festplatte in vierstelliger Zeichenfolge abgelegt. Häufig wird das dBASE-Format als Im-/ und Exportformat verwendet. Sollen Datensätze von Format X in Format Y konvertiert werden, eignet sich dBASE auf Grund seines eindeutigen Datumsformats als “Zwischenformat”, um die Daten korrekt auszutauschen. Diese Formate werden häufig auch als XBase bezeichnet. Andere Applikationen mit der selben Struktur sind FoxPro und Clipper. Alle arbeiten seit 1983 mit vierstelligen Jahreszahlen, so daß keine Probleme zu befürchten sind. Ein generelles Problem ist der Datenaustausch zwischen den verschiedenen Applikationen. Das häufig benutzte CSV-Format ( Comma Separated Value), also Datensätze in Hochkomma mit Trennzeichen, wird von den verschiedenen Anwendungen unterschiedlich verarbeitet. Ein Datum im Format JJJJ.MM.TT, das jedoch als JJ.MM.TT in CSV abgespeichert wird, kann beim erneuten Import Fehler produzieren.


3.1.1.3 Beispiel SAP R/3

Schon mit der Einführung von SAP R/3 im Jahr 1992 wurde weitsichtig an die Zukunft und den bevorstehenden Jahrtausendwechsel gedacht und die Software mit einer vierstelligen Jahreszahlinterpretation versehen. Alle Datenfelder, inklusive aller verwandten Datenstrukturen, Datendefinitionen und der eingebauten Datumslogik verarbeiten vierstellige Jahreszahlen. Darüberhinaus ist R/3 in der Lage, zweistellige Jahreszahlen innerhalb von Daten aus Fremdsystemen, die nach R/3 importiert werden sollen, automatisch zu identifizieren und in eine korrekte vierstellige Darstellung zu konvertieren. Aus diesem Grund wird sich mit dieser Software kein Jahr-2000-Problem ergeben. Da R/3 in seiner Komplexität viele EDV-gestützte Prozesse in der Wirtschaft nachbilden kann und Jahr-2000-Kompatibilität garantiert, erwägt eine Vielzahl von Unternehmen mit Datumsproblemen eine Umstellung ihrer jetzigen Anwendungssoftware auf R/3. SAP R/2 ist mit Release 5.0 auf das Jahr 2000 vorbereitet. Die benötigten Korrekturen für die Jahr-2000-Unterstützung sind im Release 5.0H enthalten und werden bis 5.0D herunter als separate Korrekturen in das System R/2 eingespielt.


3.1.2.4 Andere


Beispiele anderer Softwarehersteller zeigen Probleme mit Ihren Produkten, aber auch Lösungswege, um das Jahr-2000-Problem zu umgehen.

Hinzu kommt noch, daß auch die neuesten Programme immer noch alte Daten aus vergangenen Versionen problemlos einlesen sollten. Die dafür entwickelten Importfilter müssen ein “altes” Datumsfeld im Format TT.MM.JJ richtig interpretieren und verarbeiten können. Auch die Tatsache, daß ältere Software selten über entsprechende API- Funktionen (Application Program Interface) verfügen, die es ermöglichen würde, eine Routine zu implementieren, um das Jahr-2000-Problem zu beheben, zwingen die Programmierer zum Ersetzen der Software oder zu einer kompletten Neuentwicklung.


3.1.3 Individualsoftware


Die dritte große Gruppe der Programme mit Jahr-2000-Problem, ist die Individualsoftware. Sie macht, so nimmt man an, den wahrscheinlich höchsten Anteil an fehlerbehaftetem Code aus. Diese Annahme resultiert aus der Tatsache, daß die meisten Programme / Programmpakete schon vor langer Zeit geschrieben wurden und heute, meist unverändert, noch im Einsatz sind. Die damals implementierten zweistelligen Jahresfelder in einem Datum wurden selten überarbeitet und stellen nun die Projektteams, die mit der Korrektur der Software beauftragt wurden, vor große Probleme. Gründe für die Schwierigkeiten sind die meist nicht vorhandene Dokumentation zum Programm, ebenso der fehlende Quellcode, sowie die meist ausgefallene Programmiersprache und der Stil des Programmierers. Da diese Art der Programme speziell, sprich individuell, für ein Unternehmen geschrieben wurden und einen ganz genau spezifizierten Geschäftsprozeß erfüllen, erwägen viele Unternehmen, trotz der bekannten Probleme einer Umstellung dieser Software, deren Erhalt, da Standardlösungen einen Kompromiß darstellen würden. Speziell die Individualsoftware, die in COBOL geschrieben wurde, zeigt einen hohen Handlungsbedarf, da diese Sprache zur damaligen Zeit weltweit am häufigsten für die Programmierung verwendet wurde.


3.1.3.1 Die Programmiersprache COBOL


Stellvertretend für die ca. 500 verschiedenen Programmiersprachen, soll an Hand von COBOL verdeutlicht werden, warum Programme, die in dieser Sprache geschrieben sind, ein Jahr-2000-Problem haben.
Der Name COBOL kommt aus dem englischen und steht für common business oriented language, was soviel meint wie “allgemein geschäftsorientierte Sprache” und wird kurz als eine imperative, kommerzielle Programmiersprache beschrieben. Die Sprache wurde Ende der 50er Jahre entwickelt und fand im kaufmännischen Bereich reges Interesse. Da es zu dieser Zeit noch keine Tastaturen gab und man Eingaben in einen Computer mit Hilfe von Lochkarten tätigte, haben auch COBOL-Programme eine “lochkarten-ähnliche” Struktur. Es konnte, wie auf Lochkarten, nur eine Anweisung in einer Zeile codiert werden unter besonderer Einhaltung von Spaltenangaben. Die wahrscheinlich wichtigste Eigenschaft, die COBOL von anderen Programmiersprachen unterscheidet, ist die Tatsache, daß COBOL-Programme Dateien verarbeiten. Als Eingabedaten für ein COBOL-Programm dienen eine oder mehrere Dateien, die im Programm verarbeitet und in eine neue Ausgabedatei geschrieben werden. In COBOL wurde starker Wert auf die Ein-/ und Ausgabeoperationen gelegt, die in vielen Bereichen der kaufmännischen Datenverarbeitung eine große Rolle spielen. So bestehen eine Vielzahl von Programmen aus einfachen Algorithmen, wie Datensätze einlesen, formatieren, ausgeben und gegebenenfalls noch eine Berechnung durchführen. Problemstellungen, wie Datenmanipulation, o.ä. sind in COBOL nur schwer zu realisieren, da wichtige Informatikkonzepte, wie zum Beispiel Module und Rekursion, fehlen.
Da der kaufmännische Bereich der wichtigste und größte Anwender der Datenverarbeitung ist, besitzt die Sprache COBOL nach wie vor eine zentrale Bedeutung in der Praxis. Experten neigen sogar zu behaupten, daß die meisten auf der Welt geschrieben Programme, COBOL-Programme sind. Auch heute noch werden in großen Banken und Versicherungen COBOL-Programme neu geschrieben, alte Programme gewartet, umgeschrieben und angepaßt. Zwar mag es heutzutage bessere, schnellere und effizienter programmierbare Sprachen geben, aber das Ausmaß der Programme, die in COBOL verfaßt sind, ist so groß, daß ein Ersetzen der alten Programme größere Kosten, als derer Wartung verursachen würde. Gerade zur bevorstehenden Jahrtausendwende werden Systemprogrammierer mit COBOL-Erfahrung gesucht, die bestehende Programme umschreiben und Jahr-2000-kompatibel machen. Der Aufbau eines COBOL-Programms ist fest vorgegeben. So gliedert sich ein solches Programm in 4 Teile, die sogenannten divisions, die sich dann noch weiter in Sektionen ( sections), unterteilen lassen:



3.1.3.2 Variablen, Datentypen und Konstanten

In vielen existierenden Programmen werden Datentypen in Form von Konstanten, Variablen und Feldern verwendet, die durch eine nicht vorausschauende Implementation damals, heute zu einem Interpretationsproblem von Jahreszahlen führt. So wurde das Jahrhundert in Datumswerten, auf Grund von Speicherplatzmangel, zweistellig programmiert. Damals ging man davon aus, daß diese Programme das Jahr 2000 nicht überdauern würden. Man sparte also den Speicherplatz durch Variablendefinitionen in der Form TTMMJJ . Das folgende Beispiel in der Programmiersprache COBOL zeigt eine typische Variablendefinition, wie sie in der WORKING STORAGE SECTION zu finden ist:



01 datum.
10 dat-jj pic 9(02).
10 dat-mm pic 9(02).
10 dat-tt pic 9(02).






01 datum.
10 dat-jj pic 9(02).
88 jj-gueltig value 0 thru 99.
10 dat-mm pic 9(02).
88 mm-gueltig value 1 thru 12.
10 dat-tt pic 9(02).
88 tt-gueltig value 1 thru 31.

OHNE Gültigkeitsprüfung MIT Gültigkeitsprüfung

In diesem Beispiel wird die Variable “datum” aus 3 Untervariablen gebildet, die vom Typ “numerisch” (9) sind und aus 2 Stellen je Untervariable bestehen. Somit kann die Variable “datum” einen sechsstelligen Wert aufnehmen. Beim Beispiel rechts werden zusätzlich zu den Untervariablen Boolsche Gültigkeitsvariablen definiert, welche die spätere Prüfung der Variablen “datum” erleichtert. Alle Eingaben, die in einer solchen Variablen “datum” eine Jahreszahl ablegen, speichern einen zweistelligen Wert, der im Jahr 2000 die Zahl “00” aufweist und fälschlicherweise vom System als das Jahr 1900 interpretiert werden könnte. Im besten Fall verursacht dies einen Systemabsturz und macht somit auf das Problem aufmerksam. Im schlimmsten Fall könnten falsche Datumswerte gespeichert werden, was für die Zukunft gesehen einen größeren Schaden verursacht. In Variablendefinitionen wurden die Variablennamen, so zeigen analysierte Programme, von den Programmierern häufig willkürlich gewählt, so daß diese nicht eindeutig an deren Namen als Jahreszahl identifiziert werden können. Diese Tatsache erschwert die Analyse der Programme, um sie Jahr-2000-kompatibel zu machen. Eine Tabelle von möglichen Variablennamen ist im Anhang A1 [Seite 56] angeführt.

Ähnlich verhält sich das Problem mit Datentypen. Wenn vom Programmierer nicht auf Standarddatentypen zurückgegriffen, sondern eigene Typen im Programm verwendet wurden, können diese Typdefinitionen Schuld am Absturz des Programms im Jahr 2000 sein. Ein Programmierer könnte beispielsweise die Datumsdefinition im Deklarationsteil seines Programms wie folgt festgelegt haben:


type
JahrTyp: = {00,..,99}; MonatTyp := {01,..,12}; TagTyp := {01,..,31};
var
JahrVar := JahrTyp;
MonatVar := MonatTyp;
TagVar := TagTyp;

(Dieses Beispiel lehnt sich an keine offizielle Programmiersprache an)

Wenn nun ein Datum aus diesen 3 Variablen z.B. in einer Verbundvariablen ( record) definiert würde, ist die Jahreszahl für jedes eingegebene Datum zweistellig. Einen Wert in der Variablen “JahrVar”, der größer als 99 ist, würde vom System nicht akzeptiert werden, weil auf Grund der Typdefinition nur Zahlen im Bereich 00 bis 99 zugelassen sind.
Der dritte “Unsicherheitsfaktor” im Programmcode, der einen Fehler beim Jahrhundertsprung produzieren könnte, sind Konstanten. Die Konstante ‘19’ wurde verwendet, um das Datum zu vervollständigen, sei es in Formularen, um dem Anwender die Eingabe zu erleichtern (es müssen nur 2 Ziffern für das Jahr ergänzt werden) oder auch in der Speicherung von Datensätzen, um ein Datum in der gewünschten Form TT.MM.JJJJ abzulegen.


Das Ergebnis ist jedoch in beiden Fällen das gleiche: Die Zahl ‘19’ steht fest in einer Konstante im Programmcode und ist im Jahr 2000 nur durch Änderungen dieser Konstanten durch den Wert ‘20’ korrigierbar, vorausgesetzt, daß diese Konstante gefunden wird. Gravierendere Auswirkungen haben Konstanten, die das Jahr, und nicht das Jahrhundert betreffen. Diese Art Konstanten sind nicht als implementierte Konstanten aufzufassen, sondern als Eingaben vom Benutzer, die eine spezielle Routine im Programm ansprechen. Es handelt sich um reservierte Werte, die eine bestimmte Funktion ausführen. So haben die Werte ‘99’ oder ‘00’ in einigen Anwendungen die Bedeutung von : “Dieser Datensatz kann nicht gelöscht werden” oder “Dies ist ein Test-Konto für einen Demo-Benutzer”. Programme mit diesen “belegten” Jahreszahlen könnten also schon am 01.01.1999 Fehlfunktionen verursachen. Andere Beispiele solcher “magischen Zahlen” sind im Anhang A2 [Seite 56] zu finden.


3.1.3.3 Masken, Formulare, Berichte

Im vorherigen Abschnitt sind vorrangig konstante oder auch variable Datensätze betrachtet worden, die z.B. auf Festplattenspeichern oder in Datenbanken abgelegt werden. Diese spielen in der Jahr-2000-Problematik zwar die primäre Rolle, dennoch sollte man die Ein- und Ausgabeoberflächen auf Bildschirmen, sowie Druckerberichte nicht außer Acht lassen. Seit es fensterorientierte Bildschirmmasken und Eingabeformulare unter einer Oberfläche wie MS Windows gibt, wurden die Möglichkeiten, Werte in den Computer einzugeben, immer bequemer. Die Eingabe einer Jahreszahl beschränkt sich in vielen Fällen nur noch auf 2 Stellen. Das Jahrhundert wird vorgegeben, so daß nur noch das Jahr ergänzt werden muß. Dies soll Abbildung 3.1.3.3 illustrieren.


Abbildung 3.1.3.3: Eingabemaske unter MS Windows

Das Datum kann zwar intern im Computerprogramm mit 4stelliger Jahreszahl (19JJ) gespeichert sein, während die Eingabe der Jahreszahl vom Anwender nur zweistellig (JJ) war. Trotzdem bedarf diese Eingabemaske einer Überarbeitung und damit einer Änderung am Sourcecode. Dies einfache Beispiel läßt sich beliebig auf Abfragen, Druckreporte und alle anderen Bildschirmmasken erweitern.


3.1.3.4 Sortieren und Archivieren von Datensätzen


Als Datensätze bezeichnet man eine beliebige Menge von Eingabewerten, die unter einem gewissen Aspekt zusammengefaßt wurden, um beispielsweise ein Objekt zu beschreiben. So lassen sich z.B. alle personenrelevanten Daten auf einem Personalausweis als ein Datensatz auffassen. Aber auch nur ein Wert aus diesem Datensatz kann im Prinzip auch ein Datensatz für sich sein.
Solche Datensätze werden auf Festspeichern, wie Magnetbändern, Festplatten und MO Laufwerken, meist in Form von Datenbankstrukturen gespeichert. In vielen Firmen werden diese Datensätze über Jahre archiviert. Die Verwaltung solcher Datenarchive geschieht durch Computerprogramme. Ein kleines Beispiel soll das Problem dieser Datenarchivierung, aber auch der Datensortierung verdeutlichen:
Eine Firma speichert alle Ihre Kunden mit deren Bestellungen in einer Datenbank auf einer Festplatte. Ein Computerprogramm verwaltet dieses angelegte Datenarchiv und orientiert sich am Erstelldatum des Datensatzes. Diese Software hat ein Unterprogramm, daß veraltete Datensätze von der Festplatte löschen soll, wenn diese älter als 5 Jahre sind. Alle Datensätze werden in der Firma im Datumsformat TT.MM.JJ gespeichert. Am 01.01.2000 beginnt nun das Unterprogramm einen gerade neu erstellten und gespeicherten Datensatz zu löschen. Dies geschieht deshalb, weil das Programm auf Grund der zweistellig Jahreszahl den Wert “00” als einen Datensatz aus dem Jahr 1900 und damit als veraltet interpretiert.
Dieses Problem ergibt sich auch bei der Datensortierung. Angenommen, eine Person läßt sich durch ein Computerprogramm eine Liste generieren, in der immer der zuletzt eingegebene Datensatz ganz oben erscheint. Auch in diesem Fall wird das Programm bei zweistelliger Jahreszahl der Datensätze, am 01.01.2000 diese Daten ans Ende der Liste schreiben, weil diese fälschlicher Weise als von 1900 interpretiert werden und das, obwohl es die aktuellsten sind.

An diesen Beispielen erkennt man, daß nicht nur der Inhalt eines Datensatzes ein falsches Datumsformat haben kann, sondern auch bei deren Ablage Probleme auftreten können, wenn das Erstelldatum dieses Datensatzes in der Form TT.MM.JJ auf den Festspeicher geschrieben wird.


3.2 Systemplattformen


Unter Systemplattformen versteht man die verschiedenen Gruppen von Computern einer bestimmten Klasse (Hardwarekomponente). Vielfach wird auch die Systemsoftware, also das Betriebssystem, zur Systemplattform gerechnet (Softwarekomponente). Beides zusammen bildet eine individuelle Einheit, die selten zu Systemen einer anderen Klasse kompatibel ist. Die primäre Betrachtung liegt allerdings meist auf der Hardware. Mit Hardware wiederum bezeichnet man die Menge aller festen, technischen Geräte einer Rechnenanlage. So zählt man Speicher, Prozessor, Drucker, Ein-/Ausgabegeräte, sowie “in Chips gegossene” Schaltungen zur Hardware. Es handelt sich also um physikalische, materielle Teile und damit um unveränderbare Komponenten eines Systems. Dies trifft für fast alle Bestandteile einer Rechenanlage zu. Eine Ausnahme bildet hier z.B. das PC-BIOS, daß heutzutage wiederbeschreibbar und damit eine nicht “unveränderbare Komponente” ist. Ein BIOS enthält ein in Hardware implementiertes Programm. Das Jahr-2000-Problem betrifft aber nicht nur Personal Computer, sondern auch Großrechner ( mainframes oder hosts), midrange-Rechner und Arbeitsplatzstationen ( workstations), die alle verschiedene Systemplattformen darstellen.


3.2.1 Einzelarbeitsplätze


Dieser Abschnitt gliedert sich in die folgenden Einzelplatzsysteme: Den PC (Personal Computer) und die Macintosh-Systeme. Einzelarbeitsplätze charakterisiert, daß der Computer nicht mit anderen Rechnern vernetzt ist und somit seine Daten selbst speichert und verarbeitet. Diese Systeme beziehen ihr Datum und die Uhrzeit von einem fest, auf dem “mainboard” installierten Chip, der eine Uhrzeit und ein Datum generiert. Die Ausnahme ist eine Funkuhr in Form einer Zusatzkomponente, welche die interne Uhr ersetzen kann, da sie die Zeit über ein Funksignal von der Atomuhr erhält.


3.2.1.1 Personal Computer (PC)

Um 1980 wurden eine neue Computerart entwickelt, die in einem Gehäuse alle Komponenten für ein selbständiges Arbeiten auch ohne Netzwerk und Großrechner ermöglichte: Die PC’s ! Ein PC enthält eine Hauptplatine mit Prozessor und Speicher, ein Bussystem, auf das sich weitere Steckkarten ins System einbinden lassen und diverse Anschlüsse für Peripherie. Auf der Hauptplatine, dem “mainboard”, ist ein Computerchip integriert, der von einem Quarz getaktet, eine Zeit generiert. Dieser Chip heißt RTC ( Real Time Clock) und stammt aus dem Motorola Sortiment mit der Chipbezeichnung MC146818. Ein weiterer Chip namens CMOS-RAM ( Complementary Metal Oxide Semicoductor) speichert die Uhrzeit und das Datum sowie Einstellungsparameter des Computers, wie zum Beispiel Festplatten- und Speicherinformationen. Auf diese Register kann nun vom Bootsystem des Computer zugegriffen werden. Die autonome RTC umfaßt einen kleinen Kalender, der um Mitternacht auch das Datum entsprechend aktualisiert. Die Register im CMOS-RAM speichern allerdings das Jahr als einen zweistelligen Wert, so daß am Jahreswechsel nach 2000 der Wert von “99” auf “00” zurückspringt. Zwar existiert ein Byte im CMOS-RAM, das einen Jahrhundertwechsel signalisieren kann (“Flagbyte”), jedoch bleibt es unberührt von den Vorgängen in der eigentlichen Uhr. Es läßt sich nur durch direkte Manipulationen im CMOS-RAM verändern. Eine Möglichkeit dieses Byte zu setzten, ist der Start eines kleinen Programmes, daß in jedem PC beim Einschalten geladen wird. Es handelt sich hierbei um das auf einem Chip integrierte “Erstlade”-Betriebssystem, das BIOS ( Basic Input Output System). Das BIOS ist in den meisten Fällen ein EPROM, also ein programmier-, lösch- und wiederbeschreibbarer Chip, mit dem sich interne Einstellungen des PC’s, wie Speichergröße, angeschlossene Laufwerke und Datums-, sowie Uhreinstellungen festlegen und beeinflussen lassen. Heutige PC BIOS verfügen über erweiterte Funktionen und lassen sich noch komfortabler konfigurieren ( Flash-BIOS). Die programmierten Einstellungen im BIOS werden durch eine Batterie, die sich ebenfalls auf dem “mainboard” befindet, dauerhaft gespeichert (gepuffert). Das BIOS ermittelt beim Einschalten des PC durch Auslesen des CMOS-RAM die Uhrzeit und das Datum. Auf diese Register wird dann vom Betriebssystem und den Anwendungsprogrammen zugegriffen. Leider besitzen PC’s vor 1995 ein BIOS, dem die Funktion zum Setzten des Jahrhundertbytes fehlt. Heutige BIOS-Setups können über das Jahr 1999 hinaus datiert werden, was das aktive Setzen des Bytes im CMOS-RAM bewirkt. Marktforschungsuntersuchungen haben allerdings gezeigt, daß immer noch PC’s mit einem veraltetem BIOS verkauft werden. Da sich das Betriebssystem über BIOS-Aufrufe des Datums bedient, würde ein ungesetztes “Flagbyte” im CMOS-RAM dem Betriebssystem ein falsches Jahr vorgeben, vermutlich 1980, das “Geburtsjahr” des PC.


Die in vielen Computerzeitschriften propagierten BIOS-Updates für Flash-BIOS können durch Überspielen des BIOS-Setup den PC in die Lage versetzten, daß das BIOS das Jahrhundertbyte automatisch setzt. Hierbei wird der Microcode des BIOS um die fehlende Funktion erweitert. Ist der PC mit einem BIOS ausgestattet, daß sich nicht neu beschreiben läßt, wird der PC am 01. Januar 2000 das Jahr 1980 anzeigen. Doch auch solche älteren Systeme können problemlos ins Jahr 2000 gebracht werden. Hierzu kann das Betriebssystem verhelfen, das durch manuelle Eingabe des richtigen Datums durch den Benutzer, diese Aufgabe übernimmt. Häufig wird empfohlen, das Datum manuell auf das Jahr 2000 vorzudatieren, um die Jahr-2000-Kompatibilität zu testen. Diesen BIOS-Test sollte man nur auf unterster Betriebssystemebene durchführen. Würde man zum Beispiel diesen Test unter Windows machen, indem man dort das Datum vorstellt, kann es zu Datenverlusten in den darüberliegenden Anwendungen kommen. Einige Anwenderprogramme umgehen die Datumsroutine von Windows und greifen direkt auf das BIOS zu. Somit kann das Datum in der Anwendung richtig dargestellt sein, während das BIOS-Datum auf 1980 steht. Softwareprogramme, die den BIOS-Fehler beheben sollen und für teures Geld verkauft werden, sind in sofern nutzlos, als daß diese nur im Hintergrund geladen auf den Jahrtausendwechsel warten, um dann das CMOS-Byte automatisch zu setzen. Jeder Benutzer kann dies aber selbst manuell über sein Betriebssystem erledigen. Die Abbildung 3.2.1.1 soll die 4 Ebenen in einem PC verdeutlichen.

Ebene 4:
(Anwendungen)
Ebene 3:
(Betriebssystem)
Ebene 2:
(Firmware)
Ebene 1:
(Hardware)

Abb. 3.2.1.1: Die vier datumsrelevanten Ebenen in einem PC



3.2.1.2 Macintosh-Systeme


In Macintosh-Systemen ist, wie beim PC eine RTC auf dem “mainboard”, die durch takten eines Quarzes eine Zeit generiert. Allerdings verfügt ein Macintosh nicht über ein BIOS, über das der Rechner konfiguriert werden kann. Diese Aufgabe übernimmt das Betriebssystem, welches das Datum in einem Langwort repräsentiert. Es existiert aber ein Chip, der in seinen Registern diverse Einstellungen des Computer sichert, so zum Beispiel das letzte Ein- und Ausschalten, Speicher und Festplatteninformationen, andere Grundeinstellungen und das Datum, sowie die Uhrzeit. Das Register wurde seit der Einführung von Macintosh-Computern weitsichtig geplant und mit einer ausreichend dimensionierten Registeranzahl für das Datum versehen.

3.2.2 Computer in Netzwerken


Hauptsächlich in Unternehmen, aber auch vereinzelt in Privathaushalten werden Computer untereinander verbunden. Sie bilden dann ein Netzwerk, das unterschiedlichst geartet sein kann. Die Art der Verkabelung, deren Topologie und natürlich die eingesetzte Hardware unterscheiden die einzelnen Netzwerke voneinander. So werden vielfach PC’s als “workstations”, also als Endgeräte in einem Netzwerk eingesetzt. Solche Systeme arbeiten mit einem Hauptrechner (Server) zusammen, der als Programmlieferant dient und Speicher zur Verfügung stellt. Über die angeschlossenen “workstations” (den Clients) kann der Benutzer über das Netzwerk auf den Server zugreifen. Die Klienten verfügen in aller Regel über einen eigenen Arbeits- und Plattenspeicher, so daß eine gewisse Autonomie gewährleistet ist, jedoch die Option des Netzwerkes zum Beispiel zu Kommunikationszwecken besteht. Eine auf dem Server und den Clients installierte Software regelt den Netzverkehr.


3.2.2.1 NT-Netzwerk


Ein NT-Netzwerk ist ein Computerverbund, welcher mit Hilfe der Software Windows NT aus dem Hause Microsoft die Kommunikation zwischen den einzelnen Stationen regelt und überwacht. Da ein solches Netzwerk auf einer PC-Plattform eingesetzt wird, gelten im Prinzip dieselben Aussagen wie für PC-Workstations, die in Abschnitt 3.2.1.1 beschrieben wurden. Auch bei einem NT-Netz unterscheidet man zwischen Server und Clients. Der Server fungiert als steuernde Einheit des gesamten Netzwerks. So liest die Netzwerksoftware des Servers das aktuelle Datum und die Uhrzeit aus dem BIOS des Server-PC’s aus oder bezieht seine Informationen aus einer Funkuhr, die als Zusatzkarte installiert ist. In aller Regel gibt dann der Server die Uhrzeit- und Datumsinformation aus Gründen der Synchronisation an die angeschlossenen Klienten weiter, was zur Folge hat, daß die eingebaute RTC auf den Klienten durch die Netzwerksoftware ignoriert wird. Sollte also der Server-PC mit einem veralteten BIOS ausgestattet sein, wird der Server und damit das gesamte Netz den Jahrtausendsprung nicht automatisch schaffen. Es müßte am 01. Januar 2000 das Datum per Hand korrigiert werden.
Zum anderen läßt sich das Netzwerk über diverse Tools konfigurieren. Einige dieser Tools verfügen über Möglichkeiten, das Datum zu beeinflussen. Da einige dieser Tools, vor allem der NT-Version 3.5 und 3.51 die Datumseingabe in einem zweistelligen Format unterstützen, kann es zu Interpretationsproblemen kommen, weshalb von Microsoft “Patches” angeboten werden, die diesen Umstand beheben sollen. In Version 4.0 (mit Servicepack 3) sind keine Schwierigkeiten bekannt.


3.2.2.2 Novell-Netzwerk


Ein Novell-Netzwerk ist für die Plattformen PC und Macintosh verfügbar und kann auf verschiedenen Betriebssystemen eingesetzt werden. Auf beiden Plattformen steuert eine Netzwerksoftware namens “NetWare” den Verkehr zwischen den verbundenen Rechnern. Novell hat im Internet wichtige Anforderungen an seine Produkte formuliert, welche die Jahr-2000-Korrektheit erfüllen müssen. So soll eine Darstellung bis einschließlich des Jahres 2035 gewährleistet sein. Das Jahr 2000 soll als Schaltjahr erkannt werden, die Wochentage sollen von 1980 bis 2035 korrekt kalkuliert werden können und die Sortierung der Datensätze soll in der chronologisch richtigen Reihenfolge geschehen. Um diese Anforderungen zu erfüllen, sind zu Novell’s “NetWare”-Software “Patches” verfügbar. Die aktuelle Version 4.11 ist Jahr-2000-kompatibel. Jedoch bedürfen Produkte mit kleinerer Versionsnummer ein solches “Patch”. Bei all zu alten Versionen rät Novell zu einem Update auf die neueste Version. Novell selbst hat bereits 1996 angefangen, sich mit der Jahr-2000-Problematik zu beschäftigen und geeignete Lösungen zu finden. Es wurde recht früh herausgefunden, in welchen Modulen, bzw. Bibliotheken Änderungen durchzuführen sind. So fand man heraus, daß zurückgestellte Druckaufträge über das Netzwerk mit einem Datum nach dem 31. Dezember 1999 nicht ausführbar sind. Auch die Anzeige einer Jahresinformation über das Erstelldatum einer Datei war nur bis zum Jahr 1999 korrekt möglich. Schwerwiegender ist ein Fehler in der Datei “VNetWare.exe”, der unter einem OS/2 Betriebssystem beim Übergang von 1999 nach 2000 den Server auf das Jahr 1980 zurückfallen läßt. Bei älteren Versionen der “NetWare” kann im Zusammenspiel mit dem PC-BIOS ein ähnlicher Fall eintreten. Meist sind es jedoch fehlerhafte Darstellungen in der Anzeige von Jahreszahlen. Derzeit laufen bei Novell umfangreiche Tests auf verschiedensten Plattformen und unter diversen Betriebssystemen, die mögliche Schwächen der Softwareprodukte aufdecken sollen. Novell ist bemüht, vor dem Jahrtausendwechsel alle aktuellen “NetWare”-Produkte Jahr-2000-kompatibel zu haben.


3.2.1.2 UNIX basierte Systeme im Netzverbund


Das Betriebssystem UNIX enthält die Möglichkeit, mehrere Computer in einem Netzwerk zu verwalten. Dem System liegt dann eine Client-Server-Architektur zu Grunde. Für die Steuerung des Netzwerkes sind in UNIX diverse Tools verfügbar. Da es UNIX in aller Regel in verschiedenen Dialekten gibt, die auf die unterschiedlichen Plattformen zugeschnitten und angepaßt sind, können der Umfang und die Ausstattung der UNIX-Umgebung variieren. Die Datumsroutine auf UNIX-basierten Systemen ist, wie schon in Abschnitt 3.1.1.4 und folgenden beschrieben, eine 32bit Integerzahl, in der die Sekunden seit 1970 hochgezählt werden. Demnach würde sich ein Datumsproblem erst im Jahr 2038 ergeben, wenn die Sekundenwerte im 32bit Register keinen Platz mehr finden. UNIX selbst bezieht seine Datumsinformation von speziellen Uhren-Steckkarten, über das Internet/Intranet oder direkt von der Hardware. Eine Steckkarte könnte ein Funkuhrmodul sein, das die Uhrzeit direkt von der Atomuhr bezieht. Die zweite Möglichkeit über das Internet/Intranet beschreitet einen ähnlichen Weg. Über einen speziellen Dienst namens NTP-Demon ( Network Transport Protokoll), der in der UNIX-Umgebung installiert sein muß, kann eine Verbindung zu bestimmten Servern hergestellt werden, die mit der Atomuhr gekoppelt sind und diese Information zur Verfügung stellen. Der eigene Server fragt quasi bei dem anderen nach der aktuellen Uhrzeit und dem Datum, um sich selbst und damit auch sein gesamtes Netzwerk zu synchronisieren. Die dritte Alternative ist das Auslesen der auf der Hauptplatine der jeweiligen Plattform integrierten RTC. Hierbei muß die Hardware die Möglichkeit offen halten, eine vierstellige Jahreszahl zu speichern oder ein Flagregister zu setzen, wenn der Jahrtausendwechsel vollzogen wird. Von Seiten der Clients ist es nötig, daß ein Dienst implementiert ist, der die eigene (sofern vorhandene) RTC umgeht und Uhrzeit und Datum vom Server übernehmen. Diese Methode ist ratsam, damit die Synchronisation gewährleistet ist, die für verschiedene Prozesse vorausgesetzt wird.


3.2.3 Mainframes und Midrange


Diese Art der Computer werden in der Regel auch als Großrechner bezeichnet. Sie charakterisiert, daß die Endgeräte (Terminals) an den Arbeitsplätzen, die über ein Netzwerk mit dem Großrechner verbunden sind, von wenig Eigenintelligenz geprägt sind. Sie bestehen meist nur aus einem Bildschirm und einer Tastatur. Die gesamte Kommunikation zwischen den Klienten und dem Großrechner findet in einem Eingabe- und Ausgabedialog über das Netzwerk statt. Der Großrechner stellt die Rechnerleistung, Speicher- und Plattenplatz, Zugang zu Peripheriegeräten, sowie die Netzverbindung zur Verfügung. Meist läuft auf dem Großrechner ein fest vorgegebenes Programmpaket. Von den Klienten kann über eine Menüsteuerung ein spezielles Programm ausgewählt werden, mit dem der Anwender dann an seinem Bildschirm arbeiten kann. An einem Terminal kann also nicht eigenständig ohne die Netzwerkanbindung zum Großrechner gearbeitet werden.
Die “Mainframes” R/390, RS/6000 von IBM, sowie der “Midrange”-Recher AS/400 arbeiten mit speziellen Betriebssystemen. Die R/390 beispielsweise arbeitet mit den Betriebssystemen OS/390, VM, VSE und VMS. Die AS/400 nur mit dem Betriebssystem OS/400. Diese Betriebssysteme beinhalten einen sogenannten “microcode”, der die Schnittstelle zwischen Betriebssystem und der sehr komplexen Hardware darstellt. Der “microcode” ist vergleichbar mit einem PC-BIOS, wenn auch merklich vielschichtiger. Da alle diese Großrechner über fest eingebaute Uhren verfügen, welche die Zeit unwillkürlich weiterzählen, liegt es einzig und allein am Betriebssystem, die von der Hardware über den “microcode” bereitgestellten Datumsinformationen richtig zu interpretieren und darzustellen.


3.3 Datenbanken


Datenbanken sind ein Hauptbestandteil vieler Anwendungen. Sie werden von Programmen als Speichermöglichkeit von Daten eingesetzt. So haben sich diverse Softwarehersteller auf die Programmierung und Verwaltung von großen Datenbanken spezialisiert. Professionelle Datenbankhersteller, wie Oracle, Sybase, Informix oder MS SQL Server bieten für diese Anwendungsprogramme eine Datenbankumgebung, die es erlaubt, über diverse Schnittstellen andere, kleinere Datenbanken in einer großen Datenbank zu verwalten. Abbildung 3.3. soll dies verdeutlichen. Diese großen Datenbanken sind von je her schon auf die Speicherung von vierstelligen Jahreszahlen in einem Datum ausgelegt und verfügen über mindestens einen Variablentyp “Datum”. Der Wertebereich einer Datenbank, die vierstellige Jahreszahlen speichert, liegt zum Beispiel bei Sybase von 1753 bis 9999. Probleme können dennoch auftreten, wenn es darum geht, ein Datum mit nur zweistelliger Jahreszahl als nicht konform zu erkennen, richtig zu interpretieren und schließlich in der Datenbank zu speichern. Da auf eine Datenbank in aller Regel nur mit einem entsprechenden Anwendungsprogramm (auch front-end genannt) zugegriffen werden kann, sind es gerade diese Applikationen, welche ein Datum nur sechsstellig verarbeiten und versuchen, ein solches Feld in der Datenbank abzulegen. Die Aufgabe der Datenbank ist es nun, in geeigneter Weise dieses Datum typgerecht aufzubereiten, bevor es gespeichert wird. Vielfach wird in einem solchen Fall ein Zeitfenster (siehe Abschnitt 4.2.1.) benutzt. Das bedeutet, daß um eine Jahreszahl ein Wertebereich von 50 Jahren vor und zurück definiert wird, um das zweistellige Jahr einem Jahrhundert zuordnen zu können.
Informix speichert die Jahreszahl in einem Datum vom Typ “date” oder “datetime” vierstellig. Werden der Datenbank zweistellige Werte angeboten, erlauben die Administrationstools der Datenbank Einstellungen vorzunehmen, um auch diese Werte richtig zu interpretieren und in der Datenbank abzulegen. Die Umgebungsvariable “dbcentury” läßt sich mit einem Wert belegen, der entscheidend für die Interpretation einer zweistelligen Jahreszahl ist. Es lassen sich Werte wie past/future/closest/present” einstellen. Gibt ein Anwender beispielsweise die Jahreszahl “02” im aktuellen Jahr 1998 unter der Einstellung “closest” ein, wird das Datum als “2002” gespeichert, weil es näher an “2002”, als an “1902” liegt.
Microsoft SQL Server speichert ein Datum in Form eines 6 Byte Wertes codiert ab. Dieser Wert enthält sowohl Datum, als auch Uhrzeit, wenn er dem speziellen Datumstyp entspricht. Um das Datum richtig zu interpretieren, müssen wiederum die frond-ends in der Lage sein, das Datum entsprechend aufzubereiten und in der achtstelligen Schreibweise darzustellen. Die Konvertierung des Datums übernimmt die Datenbank.
Aus der Tatsache, daß die Anwenderprogramme die Daten im richtigen Format zur Verfügung stellen müssen, vertreten die Datenbankhersteller die Meinung, daß die Hersteller der Software, für die Jahr-2000-Kompatibilität verantwortlich sind. Des weiteren setzen alle Datenbanken auf ein Betriebssystem und auf eine Systemplattform auf, dessen Jahr-2000-Kompatibilität ebenfalls gewährleistet sein muß. Aus diesen Gründen geben die Datenbankhersteller keine Garantie, daß alle Anwendungsdaten, die in der Datenbank abgelegt sind, nach dem 01. Januar 2000 richtig repräsentiert werden.
Da auch die Datenbanken weiterentwickelt werden, existieren auch hier verschiedene Versionen, die sich in Umfang und Ausstattung von den Vorgängerversionen unterscheiden. Ältere Versionen können gegebenenfalls Probleme mit den Schnittstellen zu den Applikationen haben, die nicht Jahr-2000-konform arbeiten. Leider bemühen sich die Datenbankhersteller nicht, diese alten Schnittstellen anzupassen, sondern verweisen auf ein Update. Allgemein wird von den Datenbankherstellern die Auffassung vertreten, daß ein Update auf die jeweils neuste Version einer Datenbank der sicherste Weg ist, den Jahrtausendsprung ohne Probleme zu überstehen.




Hauptdatenbank (H)




Anwendungs-
datenbanken

(DB1), (DB2), (DB3,)



























Abb. 3.3. : Datenbankmodell mit weiteren, kleineren Anwendungsdatenbanken


3.4 Verwandte Problematiken


In diesem Abschnitt werden Systeme beschrieben, die indirekt ein Datumsproblem haben. So soll am Beispiel von Nicht-Computersystemen aufgezeigt werden, daß auch hier auf Grund des Datums in festcodierten Computerchips ein Problem besteht und zum anderen Komponenten genannt werden, die schon vor dem Jahr 2000 ein Datumsproblem bekommen werden.


3.4.1 GPS


Die Abkürzung GPS steht für global positioning system und stellt einen Verbund aus Satelliten im Weltraum dar, der es ermöglicht, auf jedem Standort der Welt seine Position zu bestimmen. Das System wird vorwiegend im Schiffs- und Luftverkehr zur Navigation und Standortbestimmung eingesetzt, ist aber neuerdings auch in modern ausgestatteten Personenkraftwagen zu finden. Das System besteht aus 3 Komponenten: Die Weltraumkomponente, also den Satelliten, den Bodenstationen und den portablen Geräten, den Empfängern. Es befinden sich circa zwei Dutzend Satelliten in sechs verschiedenen Umlaufbahnen am Himmel, die kontinuierlich Navigationssignale auf die Erde funken. Die sechs Überwachungsstationen mit ihren vier Hauptantennen auf der Erde steuern und überwachen die Umlaufbahn der Satelliten, indem ständig Signale zwischen Erde und Satelliten ausgetauscht werden. Die GPS-Empfänger haben die Größe eines Taschenbuchs und erlauben eine genaue Standortbestimmung durch eine Dreieckspeilung der Satelliten.
Was hat dieses System nun aber mit dem Jahr 2000 zu tun? Das GPS-System arbeitet unter anderem mit dem Tagesdatum. Die eingesetzte Software in den Bodenstationen arbeitet täglich mit Programmen, die 1960 erstellt wurden und zweistellige Jahreszahlen im Datum verwenden. Es müssen also die entsprechenden Programme überarbeitet und eine vierstellige Lösung gefunden werden, damit im Jahr 2000 das aktuelle Jahr richtig interpretiert wird. Während es sich in den Bodenstationen um Software handelt, die umgeschrieben werden kann, stellt sich in den Satelliten und den Benutzerendgeräten ein Problem. Hier sind die datumverarbeitenden Komponenten hardwarecodiert und nur durch einen Austausch der Computerchips, sofern dies möglich ist, kompatibel zu machen. Gerade die im Orbit befindlichen Satelliten lassen sich nicht so ohne weiteres erreichen, um die Chips auszutauschen.
Eine zweite Frage ist, warum das Datum in den Receivern ein Problem ist ? Das Datum ist als serielles Datum, also im julianischen Format, in einem 10bit Register in Form von Sekunden seit dem 06. Januar 1980 gespeichert und wird seit dem kontinuierlich fortgeschrieben. Dies entspricht einem Anfangswert von 2,444,244.500 (julianisierte Form). Das Problem dieser Speicherung liegt in dem maximal speicherbaren Wert. Dieser liegt bei exakt 1024 Wochen. Rechnerisch hieße dies (2,444,244.5 + 7168) = 2,451,412.5 . Dies bedeutet, daß Receiver mit Basisdatum 1980 am 22. August 1999, also 132 Tage vor dem Jahr 2000, einen Überlauf des Registers haben und bei Null, sprich dem 06. Januar 1980 wieder zu zählen anfangen. Die Folge könnte eine falsche Standortbestimmung auf Grund eines inkorrekten Datums sein. Moderne Endgeräte speichern neben dem Basisdatum das aktuelle Datum des letzten Kontakts mit den Satelliten und führen ihre Berechnungen mit diesem ermittelten Datum aus. Jedoch gibt es noch viele Modelle, die mit dem Basisdatum 1980 rechnen. Hier ist das Problem nur durch einen Austausch der PROMS ( programmable read only memories), die teils gesockelt, teils fest verlötet sind, zu bewerkstelligen. Andere Receiver erlauben, das Datum durch einen “Reset” zu manipulieren. Diese Möglichkeit wurde in der Vergangenheit schon des öfteren angewendet, um Sekunden, die auf Grund von Gangungenauigkeiten auftraten, zu überspringen.
Die technische Umsetzung zur Lösung des Problems ist einfach, jedoch wird die logistische Koordinierung einigen Aufwand verursachen. GPS-Besitzer sollten sich an den Hersteller ihres Receivers wenden und dort erfragen, ob das Gerät den Datumsüberlauf mit macht, denn testen läßt sich dies nicht ohne weiteres.


3.4.2 Techn. Geräte mit Datumsfunktionen


Nicht nur Computer und die darauf installierte Software haben ein Jahr-2000-Problem. Viele technische Geräte unseres täglichen Lebens arbeiten mit Computerchips in denen ein fest eingebautes Programm immer und immer wieder abläuft. Gemeint sind hier Fernsehgeräte, Videorecorder, Waschmaschinen, Klimaanlagen, Mikrowellen, Fahrstühle und Sicherheitssysteme, um nur einige Beispiele zu nennen. Einige dieser Chips haben eine eingebaute Uhr mit Datumsfunktion, um spezielle Aufgaben zu erfüllen. So lassen sich Videorecorder auf ein zukünftiges Datum programmieren, um eine Fernsehsendung aufzuzeichnen. Ebenso verfügen moderne Sicherheitssysteme und Fahrstühle über eine Datumsfunktion, die es erlauben, den Zutritt zu einem Gebäude zu gewähren bzw. nur an Werktagen zu funktionieren. Eine fehlerhafte Implementation solcher Datums- und Uhrenchips kann am 01. Januar 2000 fatale Folgen haben. Sollte die Jahreszahl in diesen Chips zweistellig implementiert sein, so würden einige Geräte annehmen, daß es sich bei dem Wert “00” um das Jahr 1900 handelt. Denkbar wäre, daß ein Geschäftshaus mit automatischem Türmechanismus, der datumsgesteuert arbeitet, am Sonnabend, den 01.01.2000 um 8 Uhr die Türen öffnet, da fälschlich angenommen wird, es handele sich um den 01.01.1900, einem Montag. Eine mißglückte Videoaufzeichnung mag dagegen noch zu verschmerzen sein. Aber auch in unseren Verkehrsmitteln, wie Autos und Flugzeugen tickt eine Uhr. Einige Flugunternehmen stellen bereits Überlegungen an, zum Jahrtausendwechsel den Flugverkehr kurzfristig zu unterbrechen, um festzustellen, ob die Flugzeuge mit der Datumsumstellung ein Problem haben werden.
Die führenden Vertreiber von Kreditkarten VISA und Euro/Mastercard hatten Schwierigkeiten mit der Akzeptanz von Karten, die eine Gültigkeit bis ins Jahr 2000 haben. Solche Karten werden seit Oktober 1997 an Kunden ausgeliefert. So wurden im Vorfeld umfangreiche Tests mit 200.000 Karten durchgeführt. Im Jahr 1996 lag die Erkennungsquote bei 98%, Ende 1997 bei 99,9%. Die Ursachen für das Zurückweisen einer Karte sind in älteren Lesegeräten zu suchen, die tatsächlich ein Jahr-2000-Problem haben. Diese Geräte sollen mittlerweile ausgetauscht worden sein. Nach Aussagen der Hersteller wurde bereits 1994 in einem 3 Jahre Projekt mit der Umstellung begonnen. Vertragspartner wurden angewiesen, ihrer Geräte bis zu einem bestimmten Datum umzustellen, anderenfalls würden Strafen verhängt werden.
Ein noch größeres Augenmerk sollte auf alle Systeme gerichtet werden, die menschliches Leben erhalten und schützen. Fehler in medizinischen Geräten, wie sie in Krankenhäusern zur Überwachung der Patienten eingesetzt werden, müssen ausgeschlossen werden. Aber auch die sensiblen Prozesse eines Atomkraftwerks oder die Steueranlagen von Nuklearraketen müssen den Jahrtausendwechsel problemlos überstehen. Meist ist diese Elektronik von spezialisierten Firmen hergestellt worden, die mit ihren Gerätschaften keiner einheitlichen Norm folgen. Es muß also generell sichergestellt sein, daß auch ältere Geräte mit dem Datum entsprechend sensibel umgehen und im Jahr 2000 keine Fehlfunktion haben, die Menschenleben gefährden.

[Inhaltsverzeichnis]


Kapitel 4


4.1 Strategien und Lösungsansätze


Während Privatanwender mit verhältnismäßig geringem Aufwand eine Kompatibilität Ihrer Hard- und Software erreichen können, hängt im wirtschaftlichen Bereich die Jahr-2000-Umstellung von weit aus mehr Faktoren ab, weshalb sich speziell in diesem Sektor ein größerer Handlungsbedarf ergibt. Für die im vorherigem Kapitel beschriebenen Probleme und Ursachen des Jahr-2000-Problems sollen deshalb in diesem Kapitel Lösungsansätze und Strategien zur Lösungsfindung für die Geschäftswelt aufgezeigt werden.

Das Jahr-2000-Problem hat ein paar Besonderheiten, die es von anderen Problemen grundsätzlich unterscheidet. Das Problem läßt sich auf gar keinen Fall verschieben. Die deadline liegt beim 01.01.2000 ! In Betrieben mit EDV, wird man das Problem nicht ignorieren können, da der Verzicht einer Umstellung Umsatzeinbußen, bis hin zur Existenzgefährdung nach sich ziehen kann. Da sehr viele Wirtschaftsunternehmen ein Jahr-2000-Problem haben werden, kann es zu einer Ressourcenknappheit kommen, nicht zuletzt deshalb, weil die Umstellung parallel zum Tagesgeschäft erledigt werden muß. Die Firmen, die eine Umstellung ihrer EDV vornehmen müssen, haben einen hohen Aufwand zu betreiben, da sämtliche EDV auf Kompatibilität geprüft werden muß und besonders die Testphasen sehr zeit- und kostenintensiv sind. Allerdings bedarf es der eigentlichen Umstellung eines relativ geringen Fach-know-hows. Diese Tatsache erlaubt die Überlegung einer Auslagerung von Umstellungsarbeiten in Niedriglohnländer, um Zeit und Geld zu sparen. Generell sollte geklärt werden, ob Teile der Umstellung durch professionelle Anbieter durchgeführt werden sollten. Zumindest der Einsatz von Hilfsmitteln in Form von Softwaretools ist für mittlere und größere Unternehmen ratsam. Auch das Firmenmanagement wird beim Jahr-2000-Problem besonders gefordert sein, denn nur eine durchdachte Projektplanung, -koordinierung und -verfolgung garantieren eine erfolgreiche Umstellung. Aus dem Jahr-2000-Problem läßt sich ein Zusatznutzen ziehen, nämlich der Lerneffekt und die Erfahrung für weitere, zukünftige Umstellungsprozesse, wie den EURO !

Grundsätzlich sollte also jedes Unternehmen prüfen, ob im eigenen Betrieb ein Jahr-2000-Problem vorliegt. Dies erreicht man durch eine gründliche Analyse der EDV-Infrastruktur. Die Art und Ausgestaltung einzelner Maßnahmen, sowie die Entscheidung für eine bestimmte Strategie, hängen zum einen davon ab, in welchem Zustand sich die EDV-Struktur im Moment befindet (Ist-Zustand) und zum anderen welche Ziele ein Unternehmen mit dem Jahr-2000-Projekt verfolgt (Soll-Zustand). Eine Ausnahme bilden in diesem Zusammenhang diejenigen Unternehmen, deren EDV in allen eingesetzten Programmen bereits vierstellige Jahreszahlen verarbeiten oder von Anfang an vierziffrig ausgelegt waren. Gemeint sind hierbei Firmen, die das Jahr-2000-Problem rechtzeitig erkannt und aus diesem Grund Ihre EDV frühzeitig mit der entsprechenden Weitsicht geplant oder verändert haben. Es besteht also prinzipiell kein direkter Handlungsbedarf. Dennoch sollten diese Betriebe umfassend prüfen, ob wirkliche alle Hard- und Softwarekomponenten kompatibel sind.. Eine große Gefahr besteht z.B. im Datenaustausch, EDI ( “Electronic Data Interchage”), mit anderen Unternehmen, die ein anderes, inkompatibles Datumsformat verarbeiten.

In den meisten Fällen jedoch haben die Unternehmen ein Jahr-2000-Problem. Die Ursachen sind meist in der seit Jahrzehnten im Einsatz befindlichen Software zu suchen, die nur ein zweistelliges Jahresformat unterstützen. Vielfach sind aber auch ganz andere Gründe für die jetzt auftretende Problematik verantwortlich, so z.B. die Tatsache, daß über die Jahre andere Geschäftsinteressen verfolgt wurden, die eine Aktualisierung der EDV verhinderten. Ebenso denkbar ist, daß viele Unternehmen erst einmal abwarten und auf eine Universallösung aus den U.S.A. hoffen, die in der Jahr-2000-Thematik eine Art Vorreiterstellung einnehmen. Solch eine “Silver Bullet” wird es nicht geben, so daß Eigeninitiative gefordert ist. Um also eine geeignete Lösungsstrategie zu finden, sollte das Unternehmen seine eigenen Zielsetzungen definieren. Mögliche Ziele bei einer Jahr-2000-Umstellung können sein:

  1. Das Jahr-2000-Problem soll nur für die kritischen Prozesse im Unternehmen gelöst werden, welche den Fortbestand des Unternehmens gefährden.
  2. Das Jahr-2000-Problem soll vollständig gelöst werden, d.h. es soll ein Zustand erreicht werden, der genau dieselbe Funktionalität betrieblicher Prozesse gewährleistet, wie vor dem Auftreten des Jahr-2000-Problems.
  3. Das Jahr-2000-Problem soll vollständig gelöst werden. Darüber hinaus sollen weitere, langfristige Verbesserungen der EDV-Struktur vorgenommen werden.

Unabhängig der Zielsetzung, die angestrebt wird, ist die Vorgehensweise prinzipiell dieselbe. Die einzelnen Arbeitsphasen lassen sich grob in 3 Punkten zusammenfassen:

1. Analyse, 2. Umstellung, 3. Test


Um eine Vorstellung über den Arbeitsaufwand dieser 3 Phasen zu bekommen, stellt Abbildung 4.1 den prozentualen Anteil der einzelnen Phasen dar.

Abb. 4.1 Aufwandsarten in Umstellunsprojekten

4.1.1. Vorarbeiten für ein Jahr-2000-Projekt.


Bevor mit dem ersten Schritt, der Analyse, begonnen werden kann, sollte die Jahr-2000-Umstellung in Form eines Projekts formuliert werden. Hierzu ist es dringend notwendig, beim Firmenmanagement die Notwendigkeit einer Umstellung deutlich zu machen. Es muß in der Managementebene das nötige Bewußtsein geschaffen werden, daß im schlimmsten Fall die Firmenexistenz auf dem Spiel steht. Ferner sollte das Management den Jahr-2000-Teams eine gewisse Rückendeckung geben. Im Vorwege sollte deshalb detailliert geplant werden, wie die Umstellung vorzogen werden soll, denn das Jahr-2000-Projekt kann unter Umständen über die Hälfte der Ressourcen einer Firma beanspruchen. Außerdem muß das Problem während des laufenden Firmengeschäfts parallel bewältigt werden.

Tabelle 4.1.1: Beispiel-Planungsübersicht eines Jahr-2000-Projekts


Das Projekt sollte folgende wichtige Punkte umfassen:


Nach Abschluß dieser Projekt-Planungs-Phase, die eindeutig auf Managementebene, jedoch mit Hilfe der Jahr-2000-Projektteams, geschehen muß, können die Umstellungsverantwortlichen mit der eigentlichen Arbeit beginnen. Jedoch sollte auch während der Umstellungsphase das Management aktiv, in Form von “überwachender Tätigkeit” immer den Verlauf des Projekts verfolgen und sich dabei strikt an den Zeitplan halten, um gegebenenfalls bei Zeitüberschreitungen eingreifen zu können und Gegenmaßnahmen einzuleiten. Ein Beispiel eines solchen Projektplans wird in Abbildung 4.1.1 dargestellt.


4.1.2 Die EDV-Bestandsaufnahme


Bei der Bestandsaufnahme der EDV sollte jedes Programm, das in der Firma existiert, auf seine Wichtigkeit und seinen Nutzen untersucht werden. Schon eine gründliche Ermittlung der derzeit verwendeten Software kann den eigentlichen Handlungsbedarf deutlich verkürzen. So werden mit großer Wahrscheinlichkeit “Programmleichen” entdeckt werden, die zum heutigen Zeitpunkt gar nicht mehr im Einsatz sind. Gemeint sind hierbei alte Programmversionen, die längst durch ein “update” erneuert sind und Programme, die durch Neuanschaffungen ersetzt, jedoch auf Grund von mangelnder EDV-Pflege nie aussortiert und gelöscht wurden. Ferner sollte ermittelt werden, ob und bei wie vielen Mitarbeitern jedes einzelne Programm in Gebrauch ist. Hierbei könnte sich herausstellen, daß einer von 300 Mitarbeitern einziger Programmnutzer ist und dieses eventuell auch nur einmal im Jahr einsetzt. Ein solches Programm ist sicherlich entbehrlich oder ersetzbar. Jedoch spätestens nach Abschluß der Bestandsaufnahme sollte entschieden werden, auf welche Weise die Umstellung der EDV erfolgen soll. Denkbar wäre ein Ersetzen der gesamten Programme oder Teilen davon durch Standardsoftware. Die Alternative ist das Konvertieren der Software. Diese Methode wird dann bevorzugt, wenn die Individalsoftware so sehr auf das Unternehmen zugeschnitten ist, daß ein Ersetzten dieser Programme einen unbefriedigenden Kompromiß darstellen würde. Hierzu sollte in dieser Projektphase ermittelt werden, in welchen Programmiersprachen die Software geschrieben ist und ob Dokumentationen zu den Programmen existieren. Wählt man allerdings den Weg der Standardsoftware, so hat dies den Vorteil, daß vom Erfahrungsschatz der großen Softwarehäuser profitiert werden kann, deren Produkte meist schon Jahr-2000-kompatibel sind. Die möglichen Entscheidungen sollten das Management und die Projekteams gemeinsam treffen.

Im weiteren wird der Fall betrachtet, daß die Unternehmenssoftware konvertiert werden soll, um eine Jahr-2000-Kompatibilität zu erlangen.


4.1.3 Einteilen von Subsystemen


Es ist oft schwierig, das Jahr-2000-Problem als ganzes zu analysieren und zu bewerten. Bei großen und mittelständigen Unternehmen ist es daher ratsam, die einzelnen Programme, die umgestellt werden müssen, in weniger komplexe Untersuchungsbereiche, bzw. Funktionsblöcke, sogenannte Subsysteme, zu gliedern. Diese Gliederung sollte individuell und nach optimalen Kriterien der Firma angepaßt sein. Mögliche Kriterien der Funktionseinheiten können sein: Vertrieb, Einkauf, etc., aber auch Gruppen von Programmen, die einer Sprache angehören oder die einen bestimmten Geschäftsprozeß verwirklichen. Die einzelnen Subsysteme werden so überschaubarer und helfen bei der Definition eines Pilotprojekt, das im nächsten Abschnitt beschrieben wird. Die Projektteams sollten in dieser Phase den Subsystemen Prioritäten zuordnen, da einige computergestütze Geschäftsprozesse eine wichtigere Bedeutung haben, als anderen. Diese Zuordnung hängt ebenfalls stark von den individuellen Gegebenheiten des Unternehmens ab. Die Bildung von Prioritäten entspricht jedoch weitgehend der Bedeutung der Subsysteme für die Unterstützung, bzw. Aufrechterhaltung des Geschäftszwecks eines Unternehmens. So hat zum Beispiel ein computergestützes Logistikzentrum für eine Spedition eine höhere Bedeutung, als für einen Industriebetrieb, da die Kernkompetenz des Speditionsunternehmers in der Logistik liegt. Der Industriebetrieb kann die Distribution seiner Produkte in der Regel ohne große Probleme für kurze Zeit an Fremdfirmen vergeben, sofern dies nicht ohnehin schon der Fall ist.


4.1.4 Bildung eines Pilotprojekts und Impact-Analyse


Da in vielen Fällen die EDV-Infrastruktur eines Unternehmens sehr komplex ist, sollte man ein Pilotprojekt definieren, in dem erst einmal ein kleiner Teil des Gesamtsystems untersucht, konvertiert und getestet wird. Das Unternehmen sollte in dieser Projektphase überlegen, eventuell vorhandene Großrechnerprogramme, wenn möglich, auf eine PC-Umgebung zu portieren. Dieses downsizing hat den Vorteil, daß die Programmkomponenten komplett aus dem laufenden Großrechnerbetrieb entkoppelt werden und in dieser Umgebung leichter analysierbar sind. Ein weiterer Grund ist die Verfügbarkeit von Analysetools externer Anbieter in diesem Sektor. Für das Pilotprojekt bietet es sich an, ein vorher definiertes Subsystem mit geringer Priorität zu verwenden. Um einen möglichst hohen Erfahrungswert aus dem Pilotprojekt zu gewinnen, sollte das Subsystem aus mehreren Modulen bestehen. Es lassen sich hierbei sowohl die Wechselwirkungen der einzelnen Module untereinander, als auch das gesamte Verhalten des Subsystems vor, während und nach der Umstellung beobachten. Mögliche Fehlerquellen lassen sich schneller aufspüren und helfen, diese bei Umstellung der verbleibenden Software zu vermeiden. Im Rahmen des Pilotprojekts wird mit Hilfe der Impact-Analyse der Programmcode untersucht. Der Begriff Impact-Analyse wäre am Besten mit Wirkungs- oder Konsequenzen-Analyse zu übersetzten. Diese Form der Analyse untersucht also jede einzelne Programmzeile auf Stellen, die Datumsfelder enthält, bzw. verarbeitet. Eine erste Entscheidung sollte bezüglich des Einsatzes von Analyse-Tools getroffen werden. Diese können den Zeitaufwand extrem verkürzen. Allerdings sollte man sich darüber im Klaren sein, daß auch das beste Tool nie alle Programmstellen finden wird. Gründe für das Scheitern dieser Tools sind zum einen die Namengebung der Variablen und Felder, die vom Programmierer willkürlich gewählt sein können, zum anderen, daß diese Tools kaum Programmlogik erkennen und verfolgen können.

Zwei einfache Beispiele sollen dies verdeutlichen:

...
...
if ( datum == ‘99’)
then wert := datum
else zahl := datum
endif;
...
...

x , y : integer;
new-field , datafield : string;
...
...
new-field = substring( datafield, x, y)
...
...
(Beispiel 1) (Beispiel 2)

Im ersten Beispiel wird vermutlich ein Softwaretool auf Grund der Variablennamens “datum” auf ein mögliches Fehlerfeld schließen. Jedoch würden die Variablen “wert” und “zahl” nicht in die Liste des fehlerbehafteten Codes aufgenommen werden. Das Tool übersieht, daß einer dieser Variablen auf Grund der if-Abfrage der selbe Wert wie der Variablen “datum” zugewiesen wird. Im zweiten Beispiel wird ein Datumswert in der Variablen “datafield” als Zeichenkette (String) gespeichert. Mit Hilfe der Funktion “substring” wird im Programm ein Teil des Datums (zum Beispiel das Jahr) extrahiert. Die Variable “x” gibt an, ab welcher Stelle der neue Teil beginnen soll und “y” beschreibt die Anzahl der Zeichen, die gelesen werden. Auch in diesem Fall würde ein Analysetool zwar die Variable “datafield möglicherweise als fehlerbehaftetes Feld erkennen, jedoch die Variablen “x” und “y” nicht gemäß der Umstellungsstrategie korrigieren können.
Somit ist es unabdingbar, den Programmcode per Hand durchzugehen, um wirklich alle Fehlerstellen aufzuspüren. Selbst ein einziger Fehler kann Folgefehler verursachen, die erst später in anderen Modulen einen sichtbaren Schaden produzieren. Mittlerweile existieren jedoch Tools, die eine sehr hohe Erkennungsrate haben und Anfänge von Logik zeigen.
Das Pilotprojekt bietet also als weiteren Vorteil, das eingesetzte Tool mit der zu konvertierenden Software zu prüfen. Es werden Fragen aufgeworfen, die sich nur durch den Einsatz dieses Tools herausstellen werden. Werden alle Programmzeilen untersucht? Bringt der nachfolgende Test ein schlechtes Resultat, so daß Nachkonvertierungen von Hand nötig werden? Bei all zu schlechten Resultaten ist es ratsam, weitere Tools anderer Hersteller auszuprobieren. Nach erfolgreicher Konvertierung sollte das Ergebnis getestet werden. Hierzu muß eine Testumgebung geschaffen werden, die das Subsystem, unabhängig der anderen Systeme testet. Eventuell wird es nötig sein Hilfsprogramme zu implementieren, welche die anderen Systeme simulieren oder Eingabeschnittstellen bieten. Diese Programme werden unter dem Oberbegriff bridges (Brücken) zusammengefaßt. Außerdem müssen Testwerte generiert werden, die das Subsystem verarbeiten muß und Ausgabemöglichkeiten geschaffen werden, die das Ergebnis in Form von Reports oder dumps dokumentieren. Sollten die Ergebnisse nicht zufriedenstellend sein, muß ein anderer Lösungsweg gefunden werden. Eine Möglichkeit ist das Hinzuziehen von Fremdfirmen, die sich auf die Umstellung des Jahr-2000-Problems spezialisiert haben oder der Einsatz anderer Tools. Im schlechtesten Fall muß eine Neueinteilung der Subsysteme erfolgen, die Bestandsaufnahme korrigiert oder die Umstellungsstrategie als Ganzes überdacht werden.
Auf der Basis der Ergebnisse der Situationsanalyse und des Pilotprojekts, kann für die anderen Subsysteme eine Teilstrategie abgeleitet werden. Die Teilstrategien werden wiederum zu einer Gesamtstrategie zusammengefaßt, die unter Berücksichtigung des Ist- und Sollzustands eine für das Unternehmen optimale Lösung darstellen soll.


4.1.5 Die Konvertierung und Implementierung


Hat das Unternehmen die geeignete Strategie entwickelt, kann mit deren Umsetzung begonnen werden. Je nach Vorgehensweise werden Programme bzw. Subsysteme von der Jahr-2000-Problematik bereinigt oder durch neue ersetzt. Eine Bereinigung der Softwarekomponenten kann nur durch eine Konvertierung der Programme, also einer Re-implementierung vollzogen werden. Grundsätzlich gelten hier die gleichen Regeln wie beim Pilotprojekt. Vor der Konvertierung ist jedoch zu beachten, daß die einzelnen Subsysteme in ihrer aktuellsten Version eingefroren werden, damit sich nicht nach einer Konvertierung herausstellt, daß das Modul zwischenzeitlich auf Grund von Weiterentwicklungen verändert wurde. Nun können die einzelnen Subsysteme konvertiert werden. Da in den meisten Fällen die Rechnerkapazitäten der Firmen nicht ausreichen werden, um zusätzlich zur täglich eingesetzten Software auch noch die komplett konvertierte Software zu speichern, muß schrittweise vorgegangen werden. So wird jedes Modul und jedes Subsystem einzeln umgestellt. Konvertierte Programmteile sollten im Anschluß in die Testphase gehen und nach erfolgreichem Durchlauf in den vorhandenen Softwarepool re-integriert werden. Dies bedarf, wie schon im Pilotprojekt, der zusätzlichen Implementation von bridges. Nur so kann der Übergang von alten Softwareteilen zu bereits konvertierten gewährleistet werden. Solche bridges können wie folgt implementiert sein:


Sind alle Subsysteme konvertiert, sollte ein Gesamttest diese Projektphase abschließen.


4.1.6 Testphase

Zum einen durchlaufen alle konvertierten Module und Subsysteme einen Funktionstest, indem ermittelt wird, ob ein Datum richtig verarbeitet wird, das heißt, Jahr-2000-kompatibel ist. Jedes Modul sollte einen isolierten Test auf separaten Testrechnern im offline-Betrieb mit zuvor generierten Testdaten unterzogen werden. Es sollten kritische Datumswerte aus den Jahren 1999, 2000, 2001 und höher gewählt werden. Um die Schaltjahrsproblematik zu testen, sollte das Datum 29.02.2000 und 01.03.2000 in den Testdaten nicht fehlen. Sind auch diese Tests erfolgreich verlaufen, darf ein Gesamttest aller Komponenten nicht fehlen. Erst hier wird sich zeigen, ob die Umstellung als solche erfolgreich war und ob das Jahr-2000-Problem vollständig gelöst wurde. Es muß ebenfalls untersucht werden, ob sich durch die Modifikation mögliche Folgefehler ergeben haben. Dazu sind zahlreiche Simulationen von möglicherweise auftretenden Situationen notwendig. Die folgende Checkliste enthält einige Fragen, die nach erfolgreichem Test alle mit “Ja” beantwortet werden sollten:

(zum Beispiel: Datenbankfelder, Benutzeroberflächen, Dateien und Auswertungen)

Als letztes sollte der elektronische Datenaustausch mit Fremdfirmen getestet werden, vorausgesetzt natürlich, daß deren verwendetes Datumsformat übereinstimmt.


4.1.7 Anpassung und Feinregulierung (Abschluß des Projekts)


In der letzten Phase wird schließlich eine Feinregulierung vorgenommen. Je nach Ausmaß eines Jahr-2000-Projekts wurden mehr oder weniger große Veränderungen in der EDV-Infrastruktur vorgenommen. Dies macht unter Umständen eine Anpassung der “neuen” EDV an die betrieblichen Prozesse bzw. eine Anpassung betrieblicher Prozesse an die neue EDV notwendig. Nicht zu vergessen sind die Anwender der Software, die nach einer Jahr-2000-Umstellung ein völlig neues, ihnen fremdes Produkt oder ein bekanntes, aber dennoch in Masken und Reports verändertes System vorfinden.


4.2 Möglichkeiten zur Problemlösung

Für die Lösung des Jahr-2000-Problems gibt es grundsätzlich 3 Strategien:





Da die Replace-Strategie relativ einfach, bis auf gewisse Anpassungen in der Endphase zu realisieren ist, soll im folgenden primär die Betrachtung auf die Rework-Strategie gelenkt werden. Ferner läßt sich das Outsourcing als eine mögliche Option der Rework-Strategie auffassen und geht somit in dieser auf. In der Praxis wird man sich nicht ausschließlich auf eine Strategie konzentrieren, sondern sich mehr oder weniger ausgeprägt in Richtung Rework und Replace bewegen.
Die Replace-Strategie beschreibt das Ersetzen der vorhandenen Software durch Neuerwerb von Standardsoftware oder einen kompletten Austausch der Jahr-2000-gefährdeten EDV durch neue, eigenentwickelte Programme. Meist wird diese Strategie bevorzugt dann eingesetzt, wenn in naher Zukunft eine Umstrukturierung des EDV-Pools geplant ist. Da es in der Natur des Menschen liegt, daß Vorhandenes von vornherein als “besser” zu bewerten ist als mögliche Neuerungen, ziehen viele Unternehmen eine grundsätzliche Richtungsänderung gar nicht erst in Erwägung. Auch die Individualität von Programmen einzelner Unternehmenszweige spricht gegen das vollständige Ersetzen der gesamten EDV. Branchenlösungen entsprechen fast nie 100 % den geforderten Ansprüchen. Eine Übersicht der Vor- und Nachteile von Standardsoftware gegenüber Individualsoftware stellt Tabelle 4.1 dar.

Die Rework-Strategie wird bei der Lösung des Jahr-2000-Problems in der Regel bevorzugt, nicht zuletzt deshalb, weil die bestehenden Programme und Datenbanken in Ihrer derzeitigen Form erhalten bleiben und das Unternehmen weiterhin von deren Stärken profitieren kann. Auch die Feinregulierung nach einer Re-Implementierung wird kostengünstiger ausfallen, als ein Neuerwerb. Allerdings werden auf der anderen Seite auch alle Schwächen der EDV-Anwendungen beibehalten. Sollen diese mit der Jahr-2000-Umstellung bereinigt werden, so können die Aufwendungen dafür unter Umständen sehr hoch sein. Unter wirtschaftlichen Aspekten betrachtet, stellt die Rework-Strategie in aller Regel keinen Mehrwert für das Unternehmen dar. Da die Aufwendungen der Umstellung sowieso anfallen, sollte überdacht werden, ob parallel zur Lösung des Jahr-2000-Problems weitere Ziele, zum Beispiel Verbesserungen der Programme, verfolgt werden sollten, die auch zu einem Mehrwert führen.

Vorteile Standardsoftware
(Nachteile Individualsoftware) 		Nachteile Standardsoftware
(Vorteile Individualsoftware)
  • Kostenvorteile: Fremdbezug ist kostengünstiger als Eigenentwicklung. Eigenentwicklungen sind schwer kalkulierbar.
  • Zeitvorteile: Entwicklungszeiten im eigenen Hause entfallen, Fremdsoftware erlaubt schnellere Umstellung auf neuere Anwendungen.
  • Qualitätsvorteile: Standardsoftware ermöglicht die Nutzung von Methoden und Verfahren, die mit betriebsinternem know-how meist nicht verwirklicht werden können.
  • Kapazitätsvorteile: Vermeiden von Personalengpässen, da für die Eigenentwicklung kein neues Personal erforderlich wird.
  • Umstellungsvorteile: Wenn Fremdsoftware bereits in der Praxis erprobt ist, sind auch die meisten Fehler behoben, so daß die meisten Umstellungs- und Startschwierigkeiten bekannt und damit kalkulierbar werden.
  • Zukunftssicherheit: Flexible Standardsoftware erlaubt auch eine einfache Anpassungen an neue organisatorische Anforderungen. Wenn ein Hersteller Weiterentwicklung und Aktualisierung betreibt, wird das Risiko veralteter und ineffizienter Anwendungssysteme für den Benutzer verringert.
  • Anpassungsprobleme: Mangelnde Übereinstimmung zwischen geforderten Funktionen (Anforderungsprofil) und den in der Software enthaltenen Funktionen (Leistungsprofil) kann einen hohen Anpassungsaufwand erfordern und eine Anpassung des organisatorischen Ablaufs im Betrieb an die Software-Lösung zur Folge haben.
  • Ineffizienz des Einsatzes: Standardpakete haben oft einen höheren Hauptspeicherbedarf, enthalten nicht benötigte und dadurch nicht ausprobierte Module und weisen oft ein ungünstigeres Laufzeitverhalten auf, als “maßgeschneiderte Eigenentwicklungen”.
  • Mangelnde Transparenz: Unzureichende Dokumentation sowie restriktive Informations-politik von Softwareanbietern können zu einer Abhängigkeit vom Softwarelieferanten führen, ganz besonders bei Änderungs- und Umstellungsarbeiten.
  • Eingeschränkte Benutzerrechte: Programmnutzung ist meist an bestimmte Hardware-Ausstattung gebunden. Üblich ist lediglich die Übergabe des Maschinenprogrammes, so daß keinen eigenen Änderungen mehr möglich sind.
Tabelle 4.2 : Standard- vs. Individualsoftware

4.2.1 Lösungsvarianten


Grundsätzlich haben sich 2 Lösungsvarianten bei der Rework-Strategie herauskristallisiert. Zum einen ist die “Zwei-Ziffern-Lösung” zu nennen, die auch als logische Methode bezeichnet wird und mit einer Fenstertechnik arbeitet, zum anderen die “Vier-Ziffern-Lösung”, auch Datenmethode genannt, die neben der Änderung am Sourecode auch alle Datensätze, z.B. in Datenbanken, bereinigt. Bei der Datenmethode vergrößern sich die Daten auf vierstellige Jahreszahlen und die Programme, die diese verarbeiten werden dementsprechend angepaßt. Diese Methode stellt eine vollständige Lösung dar. Bei der logischen Methode verbleiben die Daten in ihrer ursprüglichen Form erhalten, während den Anwendungen eine Logik implementiert wird, die das Jahrhundert interpretiert. Welche Methode schließlich angewandt wird, bleibt dem Unternehmen überlassen. Die Wahl der Methode muß nach gründlicher betriebs- und gesamtwirtschaftlicher Analyse getroffen werden. Denkbar sind auch Mischformen aus beiden. Diese mögen beispielsweise die gespeicherten Daten auf vierstellige Jahreszahlen ändern, jedoch zweistellige Jahreszahlen auf Bildschirmen und Berichten anzeigen und akzeptieren.


4.2.2 Die logische Methode, die Zwei-Ziffern-Lösung


Bei dieser Methode bleiben die Datumsfelder in den Programmen in ihrer derzeitigen Form erhalten. Es werden lediglich Algorithmen implementiert, die aus der Jahresangabe die Jahrhundertangabe ableiten. Diese Ableitung kann allerdings nur funktionieren, wenn eine bestimmte Jahreszahl als Grenzwert zwischen dem 20. und 21. Jahrhundert definiert wird. Es bietet sich zum Beispiel an, die Jahreszahl 2000 als Grenze festzulegen. Dies hat zur Folge, daß sich die Jahreszahlen 00-50 auf die Jahre 2000 bis 2050 beziehen, während die Zahlen 51-99 die Jahre 1951 bis 1999 beschreiben. Es ist ein Zeitfenster entstanden, welches exakt 100 Jahre (00-99) abdeckt. Dies Fenster kann statisch oder dynamisch implementiert werden. Ist es fest vorgegeben, wie im obigen Fall, wird man im Jahr 2051 erneut den Programmtext überarbeiten müssen. Im anderen Fall des dynamischen Zeitfensters wandert das Fenster mit dem fortschreitenden Jahr mit. Dies bedeutet, daß, um beim Beispiel zu bleiben, im kommenden Jahr das Fenster den Bereich 1952 bis 2051 repräsentiert.
Der Einsatz der zweistelligen Methode ist sinnvoll, wenn die Daten hauptsächlich innerhalb der Organisation erstellt und verbraucht werden und deren Geltungsbereich und Gültigkeit kurz sind. Auch in dem Fall, wenn Programme bald auslaufen oder ersetzt werden, jedoch nicht vor dem Jahr 2000, kann diese Methode als “provisorische” Lösung mit Logik und ohne Datenänderung in Betracht gezogen werden. Der Vorteil bei der Modifikation der Programme liegt im geringeren Aufwand, da nur der Sourcecode, nicht aber die Datenbanken oder Ein- bzw. Ausgabemasken geändert werden müssen. Einige Berater der Industrie behaupten, daß der Kosten- und Zeitaufwand für Projekte dieser Art geringer ausfallen würde, als eine zusätzliche Konvertierung der Daten auf vier Stellen. Allerdings ist der zukünftige Wartungsaufwand unter Umständen höher und die Tatsache, daß das Zeitfenster an seine obere Grenze stößt, bedingt eine erneute Umprogrammierung der Software.
Gegen die logische Methode spricht, daß die Programmieränderungen schwieriger sind, da den Programmen eine Logik zu implementieren ist, die individuell auf jeden Programmbereich zugeschnitten sein muß. Auch der Test solcher Programme wird komplizierter ausfallen und somit den Zeit- und Kostenaufwand erhöhen. Hinzu kommt auch, daß mit Sicherheit die Zahl der Verarbeitungszyklen bei der Abarbeitung dieser Programme steigen wird, da die zweistellige Jahreszahl erst durch die Logik richtig interpretiert werden muß. Ein erhöhter Ressourcenverbrauch, sowie eine geringere Arbeitsgeschwindigkeit könnten die Folge sein. Wird mit dynamischer Fenstertechnik gearbeitet, mag es in einigen Fällen sinnvoll sein, verschiedenen Programmen unterschiedliche Fenster mit differierenden Grenzen zu implementieren. Der Verwaltungsaufwand steigt erneut. Statische Fenster hingegen hinterlassen oft logische Zeitbomben in den Programmen, nicht zuletzt, weil Programmierer schlecht im Dokumentieren sind und nicht frühzeitig vor dem Erreichen der oberen Grenze warnen. Der Einsatz der logische Methode ist in speziellen Fällen sehr schwer oder überhaupt nicht anwendbar. Eine Institution, wie zum Beispiel ein Einwohnermeldeamt, wird mit dieser Technik das Jahr-2000-Problem kaum lösen können. Im Amt werden Personendatensätze mit Geburtsdaten, die den Zeitraum von 100 Jahren übersteigen können, verwaltet. Es müßte eine logische Folge von Abfragen programmiert werden, die zusätzlich zum Alter einer Person auch noch weitere Parameter prüft, zum Beispiel, ob eine Sozialversicherungsnummer existiert, um dann entscheiden zu können, daß es sich um einen Menschen reiferen Alters handelt. Auf Grund des definierte Zeitfenster von 100 Jahren, sollte so ein Problem mit der vierstelligen Variante gelöst werden.


4.2.3 Die Datenmethode, die Vier-Ziffern-Lösung


Alle Variablen und Felder in den Phasen Eingabe, Verarbeitung und Ausgabe, sowie daraus abgeleitete Variablen, die ein Datum mit zweistelliger Jahreszahl repräsentieren, werden von zwei auf vier Stellen erweitert. Ferner müssen auch Datenfelder in Datenbanken auf allen Speichermedien, so zum Beispiel auch Magnetbändern, in ein Datumsformat gebracht werden, daß eine vierstellige Jahreszahl enthält. Diese Methode ist mit Sicherheit als die sauberste Art zur “Bereinigung” des Jahr-2000-Problems zu sehen, die auch am leichtesten zu verstehen und zu verwalten ist. Richtig ausgeführt kann sie sowohl den nationalen, als auch den internationalen Normen angepaßt werden, und sie wird wahrscheinlich sicherstellen, daß die Daten mit anderen Organisationen ausgetauscht werden können. Wenn die Änderungen einmal abgeschlossen und getestet sind, sollte die zukünftige Wartung einfach und unzweideutig sein.
Als Nachteil ist vor allem der zusätzliche Speicherbedarf zu nennen und die Kompatibilität mit anderen (eigenen oder fremden) Programmen. Sollen alle Datenbestände bereinigt werden, müssen nicht nur die im täglichen Zugriff stehenden Plattendaten erweitert werden, sondern auch bereits archiviertes Backupmaterial. Der Speicherbedarf kann sich durch eine vierstellige Jahresrepräsentation erhöhen, muß es aber nicht unweigerlich. Codiert man das vorhandene Datumsformat TTMMJJ in geeigneter Form, zum Beispiel TTTFJJ, so behält man ein sechsstellige Datumsformat bei. Die Felder “TTT” repräsentieren hierbei die Tage eines Jahres zwischen 1 und 365, aus denen sich durch ein Berechnungsmodul der Monat ableiten läßt. Das Feld “F” stellt ein sogenanntes flagbyte dar, daß durch seinen Wert (0 oder 1) signalisiert, ob der folgende Wert “JJ” des Jahres im 20. oder 21. Jahrhundert liegt. In diesem Fall wird auch von einem “komprimierten” Datum gesprochen. Diese Lösung mag auf den ersten Blick die kostspieligere der beiden sein. Man sollte jedoch die zukünftigen Wartungskosten der Programme nicht außer acht lassen, die eindeutig für die Datenmethode sprechen.
Dennoch ist mit keiner der beiden Methoden sichergestellt, daß der Datenaustausch mit Drittfirmen reibungslos verläuft. Hier wird es zwangsläufig Brückenlösungen geben müssen, da nicht vorhersehbar ist, nach welcher Methode das jeweilige Unternehmen umstellt. Von der selben Problematik ist das generelle Problem der international unterschiedlichen Datumsformate TTMMJJJJ (europäisch) und MMTTJJJJ (nordamerikanisch).
Auf die Frage, ob Masken, Reports und Berichte auch auf vierstellige Jahreszahlen erweitert werden sollen, liegt die Entscheidung bei der Art des Unternehmens. Generell wird der Leser eines Berichts mit einer zweistelligen Interpretation des Jahres besser zurecht kommen, während bei rechtlichen und finanziellen Transaktionen keine Zweideutigkeit herrschen darf.


4.3 Kriterien einer Strategieselektion


Welche Strategie ist die beste? Diese Frage läßt sich nicht pauschal für alle Unternehmen beantworten. Sie ist vielmehr von bestimmten Faktoren, wie dem Ist-Zustand des EDV-Pools und anderen abhängig. Um die für das Unternehmen geeignetste Strategie zu ermitteln, soll dieser Abschnitt einzelne Faktoren aufführen, die als Entscheidungshilfe zwischen verschiedenen Lösungen dienen sollen. Die Faktoren beschreiben die Aufwendungen einer Rework-Strategie. Je höher die Aufwendungen sind, desto eher sollte ein Unternehmen das Ersetzen ( Replacement) der alten Programme in Erwägung ziehen. Der angestrebte Soll-Zustand (das Ziel der Jahr-2000-Umstellung) sollte auf keinen Fall außer Acht gelassen werden und in die Betrachtung mit einfließen.


4.3.1 Vorhandensein einer Dokumentation


Soll das Jahr-2000-Problem durch eine Rework-Strategie behoben werden, so müssen alle Datumsfelder in einem Programm Zeile für Zeile identifiziert, analysiert und schließlich modifiziert werden. Die Identifikation ist um so problemloser, je höher die Qualität der Dokumentation über die implementierten Programme ist, vorausgesetzt, daß eine solche existiert. Eine Dokumentation kann in diesem Zusammenhang recht mannigfaltig ausfallen. Es sollte eine Information über die Anzahl der eingesetzten Programme und deren Häufigkeit der Nutzung vorliegen, aber auch eine genaue Beschreibung jedes einzelnen Programms selbst. Diese Dokumentation kann elektronisch in Form einer Liste oder Datenbank, aber auch in Papierform zur Verfügung stehen. Je vollständiger die Software Inventare sind, um so einfacher läßt sich eine Rework-Strategie umsetzten. Der Umkehrschluß aus dieser Folgerung ist, daß bei Fehlen wichtiger Dokumentation zur eingesetzten Software eher die Replace-Strategie in Betracht gezogen werden sollte.


4.3.2 Mischung von Programmiersprachen


Oftmals setzt ein Unternehmen Programme unterschiedlicher Programmiersprachen ein. Nicht nur einzelne Programme oder Programmgruppen sind in verschiedenen Sprachen geschrieben, auch ein Programm kann aus mehren Sprachen konzipiert sein. Beispielsweise ist eine Mischung aus den Sprachen COBOL und SQL oder C und Assembler nicht selten. Diese Tatsache erschwert die Analyse solcher Programme erheblich, nicht zuletzt deshalb, weil hilfreiche Analysetools meist nur “einsprachig” ausgelegt sind und dann Handarbeit nötig machen. Es gilt also: Je höher die Anzahl der verwendeten Sprachen in einem Programm ist, desto höher sind die Aufwendungen für eine Rework-Strategie.


4.3.3 Source-Code


Anwendungsprogramme werden in aller Regel nicht direkt in Maschinensprache konzipiert, sondern in den unterschiedlichsten Programmiersprachen. Ein entsprechendes Programm, ein Compiler oder Interpreter, übersetzt die für die Programmiersprache spezifische Terminologie und Logik in die für den Computer verständliche Maschinensprache. Fast alle Programme, die seit Jahren ohne Veränderung im Einsatz sind, wurden damals in Maschinencode übersetzt. Es stellt sich deshalb die Frage, ob der Sourcecode, also der Ursprungscode, zu betroffenen Programmen noch vorhanden ist. Weiter stellt sich die Frage, ob dieser nach einer erfolgreichen Analyse an Hand des Quellcodes überhaupt noch übersetzt werden kann, da möglicherweise die benötigten Compiler in der erforderlichen Version nicht mehr vorhanden oder in der derzeitigen Systemumgebung nicht eingesetzt werden können. Sollte sich also herausstellen, daß zu einem betroffenen Programm oder Subsystem kein oder ein nur teilweise vorhandener Code zur Verfügung steht, so kann eine Rework-Strategie nahezu ausgeschlossen werden. Es existieren zwar einzelne Tools, die auch Maschinencode in eine Art Sourcecode re-compilieren können, jedoch ist die Übersetzung von geringer Qualität und deren Nutzen beschränkt verwertbar. Das Fehlen von Sourcecode wird ein Unternehmen zum Ersetzten ( Replacement) des entsprechenden Programmes zwingen.


4.3.3 Eingesetze Programmiersprache


Nach einer Schätzung, befinden sich weltweit circa 500 Programmiersprachen im Einsatz. Je nachdem, mit welcher Programmiersprache ein Programm konzipiert wurde, ergeben sich tendentiell unterschiedliche Höhen von Aufwendungen. Ist man sich über die Programmiersprache sicher in der die eigene Software programmiert wurde, wird man bei einer Rework-Strategie nicht umhin kommen, entsprechende Analysetool einzusetzen und / oder einen Solution-Provider zu konsultieren. Auf Grund der Programmierlogik bieten einige Sprachen günstigere Möglichkeiten, den Code zu analysieren und zu modifizieren. Am Beispiel der Programmiersprache COBOL wird deutlich, daß das Angebot an Tools und Drittfirmen, die Lösungshilfe anbieten, größer ist, als alle restlichen Programmiersprachen zusammen. Die sich daraus ergebende Essenz ist, daß die Verfügbarkeit von Tools die Entscheidung zu Gunsten einer Strategie stark beeinflussen kann.


4.3.4 Branche


Auch die Branche in der sich ein Unternehmen bewegt, ist entscheidend für die Strategie und die Aufwendungen zur Lösung eines Jahr-2000-Problems. So ist einerseits die Größe der Firma und deren Software-Pool, andererseits die Sensibilität der Daten einflußgebend auf die Kosten einer Umstellung. Handelt es sich um Finanz- und Personendaten, lebenserhaltende Systeme oder die Steuerung komplexer Prozesse, ist Sorgfalt angesagt. Daten dieser Art benötigen eine genauere Bearbeitung als “Alltagsdaten”. Wird mit der “Daten-Methode” die Komplettlösung gewählt, und ist beabsichtigt die Daten in Niedriglohnländern konvertieren zu lassen, so sollte der Sicherheitsaspekt beachtet werden. Ferner unterliegen Regelungsdaten strengeren Richtlinien, die mehrfache Tests unumgänglich machen. Diese und andere Aspekte sollten bei der Wahl der Strategie berücksichtigt werden.


4.4 Werkzeuge


Im nordamerikanischen Raum haben sich mittlerweile diverse Firmen auf Strategien und Komplettlösungen für das Jahr-2000-Problem spezialisiert. Diese reichen von einfachen Softwaretools, die zur Analyse von Sourcecode verschiedenster Programmiersprachen eingesetzt werden können und nicht kompatible Programmsegmente untersuchen, über korrigierende Tools, die automatisch auch die Re-Programmierung übernehmen, bis hin zu Komplettlösungen, welche die vollständige Planung des Projektes übernehmen und deren Durchführung, inklusive aller Umstellung vornehmen. Die angebotenen Tools lassen sich in 5 Hauptgruppen einteilen, von denen viele gleich mehrere Bereiche abdecken und im Paket verkauft werden. Die Gruppen unterstützen die folgenden Projekphasen:








Die Tabelle 4.4 soll einen Überblick der verschiedenen Dienstanbieter und deren Tools geben.

Anbieter
Bestands-
aufnahme
Impact-
analyse
Anwen-
dungs-
upgrade
Datums-
migration
Validie-
rung und
Test
ADPAC
x
x
x

BCD-AS400
x



Carleton Corp.



x
Compuware


x
x
CSC
x
x

David R. Black

x
x
x
DBStar, Inc.



x
Eleventh Hour S/W


x

Forecross

x
x
Formal Systems
x
x
x

Gladstone


x
x
Globe Software

x


INTERSOLVE
x
x


ISOGON



x
Micro Focus
x
x
x

Quintic Systems


x
x
SEEC, Inc.
x
x


Softlab
x



TransCentury Data


x

VIASOFT
x
x

x
MSP
x


Milan Data Services

x


Millennium Dynamics

x
x
x
Miller-Fairchild


x
Peritus
x
x

Software Emancipation
x
x


Source Recovery


x

Sterling Software

x
x

Trans Technology

x
x
x
x
Tabelle 4.4: Zusammenstellung von Werkzeuganbietern
Quelle: “Das Jahr-2000-Problem”,V. Gruhn & S. Chavan, Addison Wesley, 1997



4.5 Kosten


Eine brisante Frage, die nicht nur firmenintern von Belang ist, sondern auch volkswirtschaftlich interessant ist, stellt sich mit den zu erwartenden Kosten für die Jahr-2000-Umstellung. Derzeit sind nur Schätzungen aus den USA verfügbar, die dazu noch recht vage sind. So wird als Maßeinheit für eine Kalkulation die Einheit LoC ( Line of Code) verwendet. Diese Einheit stellt die Anzahl der Programmierzeilen eines Programmes oder eines gesamten Softwareportfolios von einem Unternehmen dar. Die Verwendung dieser Maßeinheit ist aus verschiedenen Gründen problematisch. Es existiert keine allgemein anerkannte Definition, was unter LoC zu verstehen ist. So ist nicht ersichtlich, ob in diesem Zusammenhang die physikalischen Programmzeilen, die Anzahl logischer Befehle oder eine Mischung aus beiden gemeint ist. Eine genaue Definition wäre angebracht, da beispielsweise der Unterschied zwischen physikalischen Linien und logischen Befehlen in einem COBOL-Programm bis zu 300% betragen können. Hinzu kommt noch, daß es weltweit unzählige, völlig unterschiedlich konzipierte Programmiersprachen gibt. Man kann von circa 500 verschiedenen, eingesetzten Sprachen ausgehen. Die Struktur und Terminologie dieser Sprachen weichen teilweise enorm voneinander ab, so daß sich damit eine unterschiedlich hohe Komplexität und damit Kostenschätzung ergeben würde. Eine mehrzeilige SQL-Abfrage könnte beispielsweise einer einzeiligen Ausgabe in der Programmiersprache C gleichgesetzt werden. Bei visuellen Sprachen verliert dies Maß völlig an Bedeutung. Dennoch basieren die Angaben aus den USA auf der Einheit LoC. Eine Übersicht, gegliedert nach Quelle, Jahr, Region und Kosten zeigt Tabelle 4.5. Vielfach wird auch als grobe Richtung der Preis für eine LoC angegeben. Auch hier schwankt der Wert zwischen 0,8 bis 1,2 US$. Beispielrechnungen der Gartner Group kalkulieren für ein mittelständisches Unternehmen mit 8000 Programmen Aufwendungen zwischen 450-600 US$ pro Programm, so daß man auf eine Gesamtsumme von 3.6 bis 4.2 Mio. US$ käme.
An den Zahlen erkennt man, daß sich die tatsächlichen Kosten schwer bestimmen lassen. Praxisbeispiele zeigen aber, daß die Kosten für ein Unternehmen immens sein können.


Quelle
Jahr
Region
Kosten in Mrd.
Peter de Jager
1993
weltweit
50 US$
C. Jones
1995
USA
50-75 US$
ParaTechnology
1995
USA
90 US$
Gartner Group
1995
Deutschland
40-60 DM
C. Jones
1996
USA
126 US$
Gartner Group
1996
weltweit
300-600 US$
Gartner Group
1996
weltweit
400-600 US$
Gartner Group
1996
weltweit
1000 US$
L.A. Kappelmann
1996
weltweit
1500 US$
Tabelle 4.5 Kostenschätzung Übersicht

4.6 Rechtliche Aspekte


Werden die Jahr-2000-Programmfehler nicht rechtzeitig beseitigt, können die dadurch verursachten Personen- und Sachschäden angesichts der Bedeutung, welche die elektronische Datenverarbeitung inzwischen für alle Bereiche, nicht nur des Wirtschaftslebens gewonnen hat, unabsehbar sein. Zahlreiche Unternehmen arbeiten an Jahr-2000-Projekten zur Umstellung ihrer Software. Jedoch wird es auch Betriebe geben, denen das Problem nicht einmal bekannt ist, geschweige denn, daß bereits Maßnahmen zur Abhilfe eingeleitet worden wären. Viele Unternehmen verschicken indes Serienbriefe mit Jahr-2000-Erklärungen an ihre Produktlieferanten, um sich abzusichern. Es stellt sich deshalb die Frage, ob Hersteller und Verkäufer von fehlerbehafteten Programmen zur Gewährleistung oder zum Schadensersatz verpflichtet werden können. Oder wird auf Grund des teilweise fehlenden Problembewußtseins und der unter Umständen hohen Fehlerbeseitigungskosten der Hersteller verpflichtet sein, die fehlerhafte Software zurückzurufen? Diese und weitere Fragen werden in diesem Abschnitt geklärt.


Zusammenfassend läßt sich feststellen, daß Gewährleistungsansprüche nur denkbar sind, wenn in Zukunft noch Computerprogramme ausgeliefert werden, die nach der Jahrtausendwende das Datum nicht korrekt verarbeiten können und deren Gewährleistungsfrist von 6 Monaten noch nicht abgelaufen ist. Eine Haftung des Herstellers nach den Grundsätzen der Produkthaftung kommt dann in Frage, wenn bei gewerblicher Nutzung der Software ein Personenschaden entsteht. Vermögensverluste und Sachschäden sind hiervon ausgenommen. Die aus §823 I BGB folgernden Verkehrssicherungs- und Produktbeobachtungspflichten gebieten, daß Hesteller von Computerprogrammen mit fehlerbehafteten Code, die Nutzer vor möglichen Gefahren warnen müssen - falls diese nicht zu erreichen sind, sogar öffentlich. Besteht darüber hinaus eine Gefahr für Leib und Leben unbeteiligter Dritter, so ist der Hersteller zum Rückruf der Programme verpflichtet.
Um sicher über die Jahrtausendwende zu kommen, sollte vom Anwender eine vertragliche Absicherung erfolgen oder eine schriftliche Erklärung des Herstellers oder Händlers eingefordert werden. Dies gilt auch für den Erwerb neuer Software und Hardware. Ob ein Händler einen solchen Vertrag unterschreibt, ist jedoch abzuwarten. Der Händler selbst sollte sich deshalb auch gegenüber dem Hersteller vertraglich absichern. Bei Drittfirmen, die bei einer Jahr-2000-Umstellung helfen, kann bei Mißlingen der Konvertierung kein Schadensanspruch geltend gemacht werden, da es sich laut Gesetz um ein einmaliges Ereignis handelt, daß solche Firmen aus der Pflicht nimmt. Es bleibt also abzuwarten, bis die ersten Prozesse um das Jahr-2000-Problem geführt sind, um sich gegebenenfalls auf Musterprozeßurteile berufen zu können. Denn vorbeugend wird man kaum Recht bekommen, geschweige denn einen Anspruch auf Ersatz haben.

[Inhaltsverzeichnis]


Kapitel 5


5.1 Kommen die Lösungen rechtzeitig ?


Die in den vorherigen Kapiteln beschriebenen Probleme und die aufgezeigten Lösungsmöglichkeiten mögen den Anschein erwecken, daß das Jahr-2000-Problem relativ schnell in den Griff zu bekommen sei. Es verwundert deshalb nicht, daß viele Unternehmen erst einmal abwarten, bis die “Universallösung” verfügbar ist, die alle Probleme in einem Arbeitsgang lösen wird. Diese Einstellung ist jedoch grundweg falsch, da zum einen kein Unternehmen eine “Universallösung”, häufig auch “Silver Bullet” genannt, bieten kann, da die eingesetzte Software zu individuell ist und zum anderen die Zeit drängt. Das Jahr 2000 ist nicht aufschiebbar, die “deadline” steht fest. Die USA hat das Problem rechtzeitig erkannt und meldet, daß bereits über die Hälfte aller Unternehmen das Problem im Griff haben, die andere Hälfte zumindest konkrete Lösungsstrategien entwickelt hat. In Deutschland verhält sich die Lage anders. Zwar informierte bereits im August 1996 das britische Wirtschafts- und Technologieministerium seine Kollegen aus den anderen EU-Staaten über die Tragweite des Jahr-2000-Problems, jedoch herrscht in den deutschsprachigen Ländern bislang eine erschreckende Passivität. Weder die Regierungen, noch sonstige Vermittlungsstellen äußern sich öffentlich zum Jahr-2000-Problem, im Gegensatz zur Presse, die in einigen wenigen Artikeln auf das Problem eingeht. Große Einrichtungen, vornehmlich Banken, Versicherungen und Behörden, haben immerhin schon mit einer Umstellungen ihrer Software begonnen oder zum Teil schon abgeschlossen, jedoch sind vielen klein- und mittelständischen Unternehmen das Ausmaß und die Risiken des Problems nicht bewußt. Gerade Unternehmen, die in der Zulieferer-Branche tätig sind und externen Datenaustausch betreiben, sollten für das Jahr 2000 gewappnet sein. Eine verschlafene Umstellung kann rechtliche Konsequenzen haben. Viele Indikatoren sprechen dafür, daß Kontinentaleuropa gegenüber den USA bei der Lösung des Jahr-2000-Problems im Rückstand ist. In den USA gibt es sowohl auf Bundesebene als auch in den einzelnen Bundesstaaten weitreichende Initiativen zur Problemlösung. Ein etwas extremes Beispiel mag die Anstrengungen verdeutlichen: Der US-Bundesstaat Nebraska hat eine zusätzliche Zigarettenabgabe von allen Rauchern zur Finanzierung der Datumsumstellung eingeführt.
Eine Umfrage zur Jahr-2000-Umstellung vom Marktforschungsinstitut Spikes Cavell in 840 europäischen Unternehmen zeigte deutliche Managementdefizite auf. In 623 Interviews mit IT-Leitern und 217 Interviews mit Leitern von Fachabteilungen ergaben sich folgende interessante Ergebnisse:


Die Studie verdeutlicht, daß das Problem im Groben verstanden wurde, aber ein rascher Handlungsbedarf von seiten des Managements nicht besteht.
Ein anderes Beispiel aus den USA soll verdeutlichen, wie komplex die Lösung des Problems sein kann und welche Rolle der Zeitfaktor spielt. Die Great American Insurance gibt unter anderem Bonds mit einer Laufzeit von 8 Jahren aus. Deshalb stieß man dort bereits 1986 auf das Problem mit der Jahrtausendwende. Konkret begonnen wurde das Projekt jedoch erst 1992. Ein angesetztes Pilotprojekt ergab, daß die Korrekturen 53 Mannjahre erfordern würden. Vor allem der zeitliche Aufwand für die Testphase wird häufig stark unterschätzt.
Festzuhalten bleibt: Das Jahr-2000-Problem ist klar definiert. Die Zeit bis zum Jahrtausendwechsel ist kurz. Auf dem Softwaremarkt existieren diverse Tools und Lösungsstrategien externer Dienstanbieter. Nur leider sind sich einige Unternehmen nicht der Konsequenzen bewußt, die eine Nicht-Umstellung zur Folge hat. So wird sich am 01. Januar 2000 zeigen, welche Unternehmen zukunftsgerichtet geplant haben und am Neujahrstag die Arbeit fortführen können, die sie am Sylvesterabend beendet haben.


5.1 Die Einführung des EURO und das Jahr-2000-Problem


Das nächste große Projekt, das in einem Unternehmen mit EDV geplant werden sollte, ist die Umstellung der Betriebssoftware auf die neue europäische Währung, den EURO. Die Gartner Group hat bereits eine Kostenschätzung für eine weltweite EURO-Umstellung abgegeben. Diese liegt bei U$ 100 Mrd. Dollar. So wird das Problem einer Umstellung in erster Linie die Banken und Sparkassen betreffen und zum Handeln bewegen, da diese Institute direkt mit Geld arbeiten. In diesen Unternehmen muß die finanzverarbeitende Software auf die neue Währung angepaßt werden, die Geldausgabeautomaten und Kontoauszugsdrucker auf den EURO umgestellt und die Systemverbindungen zu den Kunden angeglichen werden. Jedoch wird jedes Unternehmen, das verkauft und Gehälter an Angestellte zahlt, früher oder später auch eine geeignete Software-Lösung finden müssen. Die Einführung des EURO ist stufenweise zwischen 1999 und 2002 geplant. Zeitiges Handeln sichert auch hier, wie bei der Jahr-2000-Umstellung, die Marktposition des Unternehmen und bietet die besten Chancen, rechtzeitig das Ziel zu erreichen. Einige Stimmen aus den USA hoffen allerdings, daß sich die Einführung des EURO verzögert, damit das Jahr-2000-Projekt vollständig abgeschlossen werden kann und genügend Ressourcen zur Verfügung stehen, um das Projekt EURO anzugehen. Das Jahrtausendproblem hat in den USA immer noch die höhere Priorität. Viele Unternehmen in den USA warten erst einmal ab, ob und wann genau der EURO eingeführt wird. Einig ist man sich jedoch in einem Punkt: Eine gemeinsame Umstellung von EURO und dem Datum sollte nicht angestrebt werden. Zum einen sind die Ressourcen überaus knapp. Dies betrifft nicht nur die Spezialisten in den Projektteams, sondern auch Rechnerkapazität, Zeit und Geld. Zum anderen wird es schwer möglich sein, zwei gleichgeartete Projekte parallel laufen zu lassen. Viele EDV-Techniker würden in beiden Projekten eingesetzt, was ein hohes Maß an Koordinierung und Übersicht erfordert. Aber auch die Projektleitenden auf Managementebene, welche die Planung und Überwachung der Projekte innehaben, werden Schwierigkeiten mit der Realisierung haben. Eine gemeinsame Umstellung würde schon an der Organisation des Projekts und dessen Komplexität scheitern. Die Vorgehensweise einer EURO-Umstellung ist prinzipiell mit der des Jahr-2000-Problems gleichzusetzen, allerdings betrifft es diesmal andere Variablenfelder als bei der Jahrtausendumstellung. Auch hierbei wird viel Handarbeit von Nöten sein, da es keine “Universallösung” geben wird.
Zusammenfassend läßt sich festhalten, daß Unternehmen mit einem EURO-Problem abwarten sollten, wie sich die Einführung des EURO gestaltet. Man sollte über die politischen Aktivitäten, welche die Umstellung betreffen, informiert sein und nebenbei für sein Unternehmen eine Strategie planen, die zum geeigneten Zeitpunkt als Projekt umgesetzt werden kann. Unternehmen, die bereits eine Jahr-2000-Anpassung hinter sich haben, sollten aus diesem Projekt wichtige Regeln ableiten und bei der EURO-Umstellung verwerten, so daß Fehler im Vorfeld vermieden werden.

[Inhaltsverzeichnis]


Kapitel 6


Literaturverzeichnis und Quellenangaben


Bücher:



Internet: [2]





Quellen aus Zeitschriften:



Sonstige Quellen:




[Inhaltsverzeichnis]


Anhang:


A1 Suchworte


Diese Liste enthält mögliche (englische) Variablen-, Konstanten- und Feldnamen, die bei einer Codeanalyse als mögliche Suchworte in Frage kommen könnten. Die Bezeichnungen könnten auf Grund ihres Namens ein mögliches, gegebenenfalls fehlerbehaftetes , Datumsfeld repräsentieren, das untersucht werden sollte, ob hier eine zweistellige Jahreszahleninterpretation vorliegt.

after, asof, as_of, before, begin, cal, calendar, ccyy, ccyymmdd, cen, century, clndr, cur, curr, current, cymd, date, day, days, ddmmyy, dob, dt, dte, eff, effective, end, finish, first, fiscal,from, frm, fy, fye, greg, gregorian, horizon, jul, julian, last, leap, mdy, mmddyy, mmddyyyy, mo, modayr, mon, month, mos, mth, mm/dd/yy, m/d/y, m_d_y, post, roman, start, stop, sysdate, sysdte, through, thur, today, week, weeks, wk, wkly, wks, year, years, yr, yrs, yy, yyddd, ymd, yymmdd, yyyymmdd, yymmm, 00/00/00, 12/3199, 31/12/99, 19, 199, 1900, 1999, 2000


A2 Magische Nummern


Diese Liste enthält eine Aufstellung von Zahlen, die in der Jahr-2000-Problematik bedeutungsvoll sein könnten. Diese Zahlen können mögliche Datumswerte repräsentieren, die in Programmen bei der Implementierung schon fest vorgegeben sind, so genannte “hardcoded numbers” (fest programmierte Nummern), häufig auch als “Magische zahlen” bezeichnet. Diese Nummern können das System zu einer bestimmten Handlung veranlassen, beispielsweise bei Eingabe des Wertes 99 als Jahr, wird der Datensatz für endlosen Betrieb freigeschaltet.

9/9/99, 99/99/99, 1/1/1, 1/1/11, 6/9/69, 6/7/89,1/23/45, 6/6/66, 7/7/77, 8/8/88, 13/31/99

Natürlich sind noch verschiedene andere Kombinationen denkbar.
[1] Hermann Hollerith (1860-1929): Erfinder einer elektro-mechanischen Zähl- und Sortiermaschine für Lochkarten.
[2] Alle Quellen aus der World Wide Web (WWW) basieren auf Abfragen zwischen Juli 1997 und März 1998. Diese Quellen sind in physikalischer Form vorhanden und können eingesehen werden.

[Inhaltsverzeichnis]
[AGN-Webseiten zum Jahr 2000]