Jahr 2000


Darüber wird ja viel diskutiert: Massenkollaps usw. Gerne wird es ja auch Y2K - Problem genannt (Year 2 Kilo, in der EDV also Jahr 2048).

Was ist denn da so schlimm? Muß ein neues Betriebssystem her? Darf ich mir ALLE meine Programm-Quellcodes noch einmal reinziehen? Hier die drei Fälle, die mir ganz spontan einfallen:

1) Das Wochentagsproblem:

Aufgrund widriger Umstände, so mit Schaltjahr oder doch nicht? Also alle 4 Jahre sind's ja, aber die hunderter nicht, dafür die tausender aber wieder doch?!
Also aufgrund dessen kann es zu einer falschen Wochentagsangabe des Betriebssystems kommen. Fatal z.B. in folgendem Programm, daß bei uns in der Firma die automatische Datensicherung steuert:

(Für outsider: Der Befehl date liefert im Unix Datum und Uhrzeit der Betriebssystem-Uhr zurück, z.B. Di Dez 22 22:17:38 MET 1998
Berücksichtigt werden Zeitzonen nd Umgebungsvariablen sowie optionale Parameter. Iin DOS geht das mit date und time üblicherweise etwas krückenhaft.)

proto=/tmp/protokolldatei
liste=/tmp/sicherungsliste
tag=`date|cut -c 1-2`
echo "Tag ist $tag" >> $proto
echo "Es sind noch angemeldet: \n" >> $proto
finger >> $proto
echo "" >> $proto
echo $liste > $liste # Namen der Listendatei selbst in Liste aufnehmen
cd /

echo "Menge in home :">> $proto
du -s home >>$proto
find home -print >> $liste
echo "">> $proto

if [ "$tag" = "Mo" -o "$tag" = "Mi" -o "$tag" = "Fr" ]; then
echo "Menge in u0 :">> $proto
du -s u0 >>$proto
find u0 -print >> $liste
fi

if [ "$tag" = "Di" -o "$tag" = "Do" ]; then
echo "Menge in u1 :">> $proto
du -s u1 >>$proto
find u1 -print >> $liste
fi
Jetzt folgen cpio-Befehle, Bandauswurf, Protokolldruck usw.

Wie wir leicht sehen, wird Montag, Mittwoch und Freitag das eine Dateisystem (u0) gesichert, Dienstag und Donnerstag das andere (u1) und "home" jeden dieser Tage.Samstag und Sonntag passiert nichts, es ist ja auch keiner da zum Cassettenwechseln. Kommt nun aufgrund der Unwissenheit des Betriebssystems statt "Fr" ein "Sa" zurück, so wird Freitag nicht gesichert. Analog könnten woanders die berühmten Fahrstühle steckenbleiben, Ampeln ausgeschaltet sein usw.

Abhilfe: Betriebssystem- bzw. BIOS-Update.

2) Das Zeitdifferenzproblem:

Aufgrund falscher Angaben des Betriebssystems (wie vor beschrieben) oder laxer Programmierung (wie unten von mir bisher auch immer praktiziert), erfolgen falsche oder gar keine Mahnungen, werden Greise in den Kindergarten eingeladen oder Kinder erhalten Präsente vom Bürgermeister zu ihrem 105. Geburtstag.

(Für Outsider: In Pascal wird das Datum über Betriebssystemfunktionsaufrufe geholt, z.B. für DOS auf folgende Weise, die nicht ganz so elegant ist, wie date, oder?)

In der folgende Funktion wir das Jahr 2000 in der globaen 1-Byte-Variablen JJ als 100 abgespeichert. Cool, nicht? Viele Programmierer hätten die ersten beiden Stellen des Jahres abgehackt und dann eine Null bekommen. Murks! Warum umrechnen? Für Zahlen größer 255 braucht man 2 Bytes, reine Platzbverschwendung. Mein Verfahren funktioniert bis 2125 und dann kann ich immer noch das "Basisjahr" (unten 1900) verändern:

Procedure GETDATE; { Holt das Datum aus MS-DOS Register }
Type Regpack = Record ax,bx,cx,dx,bp,si,di,ds,es,flags: Integer End;
Var Recpack: Regpack;
Begin
Recpack.ax := $2a shl 8;
MsDos(recpack);
With Recpack Do
Begin JJ:= cx-1900; MM:=dx shr 8; TT:=dx mod 256 End;
End;)

In der folgenden Funktion wird nun eine Zeitdifferenz berechnet, indem zuerst aus dem Tagesdatum (TT,MM,JJ) und aus dem zu prüfenden Datum absolute Zahlen berechnet werden. Jeder kann man sich leicht ausmalen, das alles von der Funktion Int(M*0.4 + 2.7) zur Schaltjahreskorrektur abhängt. Ich selber habe noch nicht einmal geprüft, ob die noch funktioniert. Das nenne ich laxe Programmierung.

Function DELTA(T,M,J: Byte): Integer; { Berechnet Differenz heute - T/M/J }
Function DT(T,M,J: Byte): Real;
Var H: Real;
Begin
M:= M-1;
H:= T + M*31 + (J-88)*365;
If M>1 Then H:= H - Int(M*0.4 + 2.7);
DT:=H
End;
Begin
DELTA:= Trunc(DT(TT,MM,JJ)-DT(T,M,J))
End;

Lösungen: Betriebssystem überprüfen, Zeitdifferenz-Berechnungsroutinen überprüfen.

3) Das Geizkragen-Problem

Früher wollten Programmierer NOCH MEHR Platz sparen und mißbrauchten z.B. auf die Jahreszahl "00" oder "99" als "Merker". Sollten z.B. Datensätze als erledigt betrachtet werden, so war es unzweckmäßig, sie gleich zu löschen. Vielfach bekamen sie nur einen "Merker". Beim Start eines Reorganisationsprogrammes wurden die so markierten Datensätze dann endgültig entfernt. Alles klar?
Cool, wie klein manche Datenbanken dann schon im Jahr 1999 sein werden!

Abhilfe: Schnellstens Reorg-Routine überprüfen und sich einen anderen Merker suchen. Vielleicht das Jahr 10 ? :-)


Die USA z.B. nehmen das Problem sehr ernst. Sie sind zwar zuversichtlich, selber fast alle Computer umgestellt zu bekommen, haben aber Angst vor unabsehbaren Ereignissen, wenn diese umgestellten aufgrund der weltweiten Vernetzung mit irgendwelchen nicht umgestellten zusammentreffen.

Es gibt noch ein viertes Problem! Es ist nur indirekt ein Y2K-Prob. Und es haben nur Chefs, der da meinen, wenn alle Jahr 2000 Probleme gelöst sind, in ein Auftragstief zu fallen, weil alle Kunden sich neu ausgestattet haben und "satt" sind. Aber wie wir aus Erfahrung wissen, werden uns Hersteller und Programmiere weiterhin schöne Problemchen bereiten, an denen wir zu knacken haben!