Hallo,
weiss jemand näheres um was für ein Problem es sich handelt,
dass es so tiefgreifende Konsequenzen gibt.
Was für ein Fehler ist das?
Was ist am Jahr 2010 anders als an 2001, 2002…?
Grüße
Hallo Sebastian,
das Jahrzehnt hat gewechselt 09 ->10.
Wenn man bedenkt was für ein Aufstand um den Jahrhundertwechsel
durchgeführt wurde (auch ich war Jahr 2000 Beauftragter in meiner
Firma).
Gruß Wolfgang
Was ist am Jahr 2010 anders als an 2001, 2002…?
An 2010 ist nicht so viel anders, aber an der 10. Wenn ich die Zahlen 0 - 9 hexadezimal lese, ändert sich ihr Wert gegenüber der dezimalen Interpretation nicht. Die 10 hex entspricht aber der 16 dezimal - und im Jahre 2016 dürfte die Gültigkeit der meisten im Umlauf befindlichen Karten längst ausgelaufen sein.
Dass dieser Fehler für das Kreditkartenproblem in D verantwortlich ist, halte ich aber für unwahrscheinlich. In Australien hat er zu Problemen geführt, allerdings war der Fehler dort nicht in den Karten, sondern in der Software der Terminals implementiert.
Ein weiterer Unterschied ist der Stellenüberlauf. Ich halte es für durchaus denkbar, dass auf den Chips für die Speicherung des Jahres nur eine Stelle vorgesehen ist und Jahrzehnt bzw. Jahrtausend per Logik - die erst bei einem Überlauf versagt hat - zugesteuert werden.
Eine dritte Möglichkeit ist, dass es sich gar nicht um einen Jahres-, sondern um einen Monatsbug handelt. Die betroffenen Karten sind noch recht neu, möglicherweise versagt die Software bei einem als 0 dargestellten Monat (in der IT werden die Monate oft von 0 bis 11 dargestellt). Einen vergleichbaren Bug habe ich im vergangenen Oktober erlebt. Um den Monat zweistellig darzustellen, muss bei einem Monat
Hallo,
auf eine konkrete Aussage wird man wohl noch etwas warten müssen. Aber neben den schon genannten Punkte sollte man nicht vergessen, dass 2000 diverse Y2K-Probleme erst einmal provisiorisch gelöst worden sind, indem man die erste Dekade einfach ein Jahrhundert weiter definiert hat, und dann vorhatte - was in 10 Jahren ja eigentlich kein Problem gewesen wäre - das Problem später richtig zu lösen, bzw. man davon ausging, dass der ganze uralte Kram bis dahin ohnehin endlich abgelöst sein würde. Aber wie es so passiert: Wenn der Druck erstmal raus ist, … und was so alles an alter Software immer noch im Einsatz ist.
Gruß vom Wiz
Wie bei UFO-Sichtungen
Glaubst Du wirklich, dass auf Kreditkarten-Chips Betriebssysteme laufen, die deutlich vor 2000 entstanden sind?
Außerdem gibt es in den Medien jede Menge Meldungen, die über Software-Fehler in unterschiedlichen Zusammenhängen berichten.
Wahrscheinlich verhält es sich wie bei UFO-Sichtungen: Kaum steht’s in einer großen Tageszeitung, sehe gleich ganz viele Menschen UFOs. 
Ciao, Allesquatsch
Glaubst Du wirklich, dass auf Kreditkarten-Chips
Betriebssysteme laufen, die deutlich vor 2000 entstanden sind?
Banken- und Unternehmenssoftware enthält nach wie vor vielfach Teile, die sehr sehr deutlich vor 2000 entstanden sind. Genau das waren die Produkte, für die im Jahr 2000 der GAU befürchtet wurde, nicht Betriebssysteme. Die lassen sich von Datumsfehlern kaum beeindrucken, Betriebssysteme rechnen nicht mit Geburtstagen und Vertragsabschlussdaten.
Außerdem gibt es in den Medien jede Menge Meldungen, die über
Software-Fehler in unterschiedlichen Zusammenhängen berichten.
Es gibt in der Tat eine Reihe von Produkten, die zum ersten Januar bös auf Grund gelaufen sind. Die Fehler sind dabei durchaus unterschiedlicher Natur. Zertifikate, die zum ersten Januar ausgelaufen sind, stellen sicher keinen typischen Jahr-2010-Fehler dar, wohl z. B. aber Datumsprüfungen wie in Spamassassin, die die ersten drei Stellen des Jahres auf die Zeichenfolge 200 vergleichen.
Gruß
1 Like
Streicht den Bänkern ihre Boni!
Banken- und Unternehmenssoftware enthält nach wie vor vielfach
Teile, die sehr sehr deutlich vor 2000 entstanden sind. Genau
das waren die Produkte, für die im Jahr 2000 der GAU
befürchtet wurde, nicht Betriebssysteme. Die lassen sich von
Datumsfehlern kaum beeindrucken, Betriebssysteme rechnen nicht
mit Geburtstagen und Vertragsabschlussdaten.
Der Fehler liegt aber nicht bei irgendwelchen alten COBOL Programmen sondern einer (übrigens nicht ganz neuen) Chipversion, die auf den Karten verbaut ist, neben dem älteren, nicht so sicheren Magnetstreifen. Und das auf dem Chip befindliche System zur Verifikation von Echtheit und PIN rechnet falsch, wenn es ein Datum >= 2010 verarbeitet.
Es handelt sich wohl doch um einen Fehler der Systemsoftware, nämlich das des Seccos5-Chips des Herstellers Gemalto.
http://de.wikipedia.org/wiki/EMV_(Kartenzahlungsverk…
Es ist nur die Notlösung, dass die Banken jetzt Geldautomaten updaten, um wieder die alte Magnetstreifen-Methode zu nutzen, wenn betreffender Chip auf der Karte ist. Schließlich lassen sich Geldautomaten und POS-Systeme in Handel und Tankstellen schneller patchen als hunderttausende Zahlungskarten tauschen.
Erfahrungsgemäß sind Meldungen, die in Massenmedien (also nicht in der Fachpresse) zu Computerproblemen verbreitet werden, leider auf dem Niveau von Wissenschaftssendungen bei RTL2.
Schließlich will man heute üblicherweise die Herzen der Menschen erreichen und nicht ihr Hirn. Wen interessieren schließlich technische Zusammenhänge. Vorhandene Ressentiments und Ängste bedienen macht mehr Quote.
Ciao, Allesquatsch
2 Like
Hallo,
und glaubst Du, dass der aktuelle Softwarestand der Karten plötzlich vor ein paar Monaten frisch bitweise codiert aus dem Himmel gefallen ist? Solche Projekte werden doch nicht von „0“ aus dem Boden gestampft, sondern nutzen vorhandene Bibliotheken, Entwicklungssysteme, Schnittstellendefinitionen, … die selbst wiederum auf andere vorhandene Komponenten zugreifen, …
Ich hab ja schon so ein paar Tage bei den großen IT-Dienstleistern des Bankengewerbes hinter mir, und was man da so an „Altlasten“ zu sehen bekommt, die zigfach über irgendwelche verschlungenen Pfade noch in x aktuellen Anwendungsszenarien von Bedeutung sind, … Da kann man nur froh sein, dass solche Dinge nicht häufiger passieren.
Gruß vom Wiz
und glaubst Du, dass der aktuelle Softwarestand der Karten
plötzlich vor ein paar Monaten frisch bitweise codiert aus dem
Himmel gefallen ist?
Nein, natürlich nicht. Und mir ist es bewusst, dass auch solche Fälle auftreten. Aber ich pflege mich bei konkreten Vorfällen nicht auf meinen Glauben zu verlassen, auch wenn sich damit vielleicht ein widerspruchsfreies Weltbild ergäbe.
Ich ziehe es vor verfügbare Fakten heranzuziehen und insbesondere solche Quellen zu hinterfragen, bei denen erfahrungsgemäß nur geringe fachliche Kompetenz vorhanden ist.
Ich schätze deshalb jene Information als vertrauenswürdig ein, dass das Problem an einer bestimmten Chipreihe eines einzelnen Herstellers mit dem Kartenbetriebssystem SECCOS-5.
Andere Karten, die einen Chipsatz von Giesecke & Devrient enthalten oder das Kartenbetriebssystem SECCOS-6, sind nicht betroffen.
Daraus schließe ich, dass der Fehler NICHT in einer Bankapplikation liegt, NICHT in der Firmware von Kassensystemen des Handels, sondern in der Implementierung des Kartenbetriebssystem SECCOS-5 des Herstellers GEMACO.
Ich bin mir absolut sicher, dass in solchen Betriebssystemen KEINE COBOL-Sourcen wiederverwendet wurden.
Ciao, Allesquatsch
Bevor ich diesen Artikel gelesen habe, war es für mich ein Rätsel, wie man mit einem einigermaßen vernünftigen Algorithmus einen Jahr-2010-Fehler programmieren kann. Jetzt kann ich mir das vorstellen. Auch die Idee, es könne sich in Wirklichkeit um einen Monat-Januar-Fehler handeln, erscheint mir plausibel. Ich las, dass die Programmierer, die diesen Fehler produziert haben, unter einem unzumutbaren Zeitdruck arbeiten. Wenn das zutrifft, ist der Schadenersatz, den das verantwortliche Unternehmen leisten muss, sehr begrüßenswert. Vielleicht begreifen jetzt die zuständigen Führungskräfte, was man in der Qualitätssicherung unter dem „Preis der Abweichung“ versteht. Wenn künftig die Programmierung der Kreditkarten-Software zumindest den einfachsten Qualitäts-Standards genügen sollte, wäre mir das lieber, als für eine EC-Karten-Panne eine Entschädigung von meiner Bank zu erhalten.