Gab es etwas in Cobol eigen macht es anfällig Fragen Y2K?

StackOverflow https://stackoverflow.com/questions/1463434

  •  13-09-2019
  •  | 
  •  

Frage

Ich weiß, dass viele von Y2K Bemühungen / schrecken irgendwie auf COBOL zentriert wurde, verdientermaßen oder nicht. (Heck, ich sah kleinere Y2K-Bug in einem Perl-Skripte, die 2000.01.01 brach)

Was interessiert mich, war es etwas spezifisch für COBOL als einer Sprache, die sie anfällig gemacht Fragen Y2K?

Das heißt, im Gegensatz zu nur das Alter der meisten Programme geschrieben und daraus folgenden Notwendigkeit auf Speicher / Festplattennutzung durch alte Hardware und die Tatsache, dass niemand angetrieben knausert diese Programme erwartete für 30 Jahre zu überleben?

Ich bin vollkommen glücklich, wenn die Antwort „nichts spezifisch für COBOL anderes als das Alter“ - nur neugierig, zu wissen nichts über COBOL

.
War es hilfreich?

Lösung

Ja und Nein In COBOL Sie Variablen deklarieren mußten, so dass man mußte wirklich sagen, wie viele Stellen gibt es in einer Reihe war das heißt, erklärte YEAR PIC 99 die Variable YEAR, so dass es nur zwei Dezimalstellen halten kann. Also ja, war es einfacher, diesen Fehler als in C wurden Sie int oder short oder char als das Jahr haben würde und haben noch viel Raum für Jahre von mehr als 99. Natürlich, die dich nicht schützen printfing 19%d in C und immer noch das Problem in Ihrem Ausgang, oder machen andere interne Berechnungen auf Basis des Jahres denken wäre weniger als oder gleich 99.

Andere Tipps

Es war 80% über Speicherkapazität, rein und einfach.

Die Leute realisieren nicht, dass die Kapazität ihres Laptop heute Festplatte würde Kosten Millionen in 1980. Sie denken Speicher zwei Bytes ist albern haben? Nicht, wenn Sie haben ein 100.000 Kundendatensätze und eine Festplatte in der Größe eines Kühlschranks gehalten 20 Megabyte und benötigte einen speziellen Raum kühl zu halten.

Es schien eher ein Problem der Menschen zu sein, nicht zu wissen, wie lange ihr Code verwendet werden würde, so wählten sie 2-stellige Jahre zu verwenden.

Also, nichts spezifisch für COBOL, es ist nur so, dass COBOL-Programme sind in der Regel kritisch und alt sein, so waren sie eher betroffen sein.

  

Gab es etwas in Cobol eigen macht es anfällig Fragen Y2K?

Programmierer 1 . Und die Systeme, in denen COBOL-Programme ausführen 2 .

1: Sie haben nicht Design 30 Jahre später suchen. Ich kann sie nicht wirklich schuld. Wenn ich Speicherbeschränkungen hatte, zwischen 2 Bytes pro Tag quetschen und macht es 30 Jahre letztere arbeiten, wahrscheinlich würde ich die gleiche Entscheidung treffen.

2: Die Systeme könnten das Jahr in zwei Ziffern das gleiche Problem, wenn die Hardware gespeichert hatten.

Faszinierende Frage. Was ist das Y2K-Problem im Wesentlichen? Es ist das Problem der nicht ausreichend Ihr Universum zu definieren. Es gab keinen ernsthaften Versuch, alle Daten zu modellieren, weil der Raum wichtiger war (und die Anwendungen würden durch dann ersetzt werden). So in Cobol auf jeder Ebene, das ist wichtig. Effizient zu sein und nicht overdeclare den Speicher, den Sie benötigen, sowohl im Laden und auf Programmebene

Wo Effizienz wichtig ist, verpflichten wir Y2Kish Fehler ... Wir tun dies jedes Mal, wenn wir ein Datum in der DB speichern, ohne eine Zeitzone. So moderne Lagerung ist auf jeden Fall unterliegen Fehler Y2Kish, weil wir mit Platz effizient zu sein versuchen verwendet (obwohl ich wette, es ist in vielen Fällen über Optimierung, vor allem auf Unternehmens- overdo-alles-Ebene).

Auf der anderen Seite, vermeiden wir Y2Kish Fehler auf Anwendungsebene, weil jedes Mal, mit denen Sie arbeiten, sagen, ein Datum (in Java, sagen wir mal) es trägt immer um eine Tonne Gepäck (wie Zeitzone). Warum? Weil Datum (und viele andere Konzepte) sind nun Teil des Betriebssystemes, so dass die OS-machen intelligente Jungs versuchen, ein ausgewachsenes Konzept von Datum zu modellieren. Da wir auf ihr Konzept der Zeitpunkt verlassen, können wir es nicht vermasseln ... und es ist modular und austauschbar!

Neuere Sprachen mit vordefinierten Datentypen (und Einrichtungen) für viele Dinge wie Datum, sowie riesige Speicher mit zu spielen, zu helfen, eine Menge Potenzial Y2Kish Probleme zu vermeiden.

Es war zwei Teil. Das Alter 1- / Langlebigkeit der Cobol Software und 2- 80 die Zeichengrenze von Datensätzen.

First- Die meisten Software in diesem Alter nur 2-stellige Zahlen für das Jahr Lagerung, da niemand ihrer Software dachte, dass lange dauern würde! COBOL war von der Kreditwirtschaft verabschiedet, die berüchtigt sind für nie Code Wegwerfen. Die meisten anderen Software wurde weggeworfen, während die Banken nicht!

Zweitens wurde COBOL gezwungen zu 80 Zeichen pro Datensatz von Daten (aufgrund der Größe der Lochkarten!), Waren die Entwickler in einem noch größeren Druck, um die Größe der Felder zu begrenzen. Weil sie dachte, „Jahr 2000 wird nicht hier sein, bis ich bin lange und zog sich zurück!“ die 2 Zeichen der gespeicherten Daten waren riesig!

Es war viel mehr mit dem Jahr in Datenelementen zu speichern, die nur Werte von 0 bis 99 (zwei Zeichen oder zwei Dezimalstellen oder einem einzelnen Byte) halten konnten. Das und Berechnungen, die ähnliche Annahmen über Jahre Werten.

Es war kaum eine Cobol-spezifische Sache. Viele Programme wurden betroffen.

Es gibt einige Dinge über COBOL waren, die die Situation noch verschärft.

  • es ist alt, so dass weniger Gebrauch von Bibliothekscode, mehr homegrown alles
  • es ist alt, so Vor-Internet, Pre-Social-Networking, mehr NIH, weniger Rahmen, mehr individuelle Sachen
  • es ist alt, so, weniger abstrakt, eher offen codierten Lösungen haben
  • es ist alt, so gehen Sie zurück weit genug und 2 Byte Speicher haben könnte, eine Art, war wichtig
  • es ist alt, so, so dass es früher SQL. Legacy-Betriebssoftware hatte sogar satzorientierte Plattendateien indiziert, um rolling-your-own-Datenbank-in-allen-Programm ein wenig einfacher.
  • "printf" Format-Strings und Datentypdeklaration waren das gleiche, alles hatte n Ziffern

Ich habe keine tatsächlichen Subroutinen riesige Fortran-Programme zu sehen. Wirklich, eine 3.000-line Hauptprogramm, nicht ein einziges nicht-Bibliothek Unterprogramm, das war es. Ich nehme an, dies könnte in der COBOL-Welt passiert, so jetzt müssen Sie jede Zeile lesen Sie die Datumsverarbeitung zu finden.

COBOL kam nie mit jeder Standard-Datum Handhabung Bibliothek.

So jeder seine eigene Lösung codiert.

Einige Lösungen waren sehr schlecht vis-a-vis des Millennium. Die meisten dieser schlechten Lösungen spielte keine Rolle, da die Anwendungen nicht mehr als 40 Jahre leben hat. Die nicht so kleine Minderheit von schlechten Lösungen verursacht das bekannte Y2K-Problem in der Geschäftswelt.

(Einige Lösungen waren besser Ich kenne COBOL-Systeme codierten in den 1950er Jahren mit einem Datumsformat gut bis 2027 - für immer zu der Zeit erscheinen muß,. Und ich entworfen Systeme in den 1970er Jahren, die bis 2079 gut sind) <. / p>

Allerdings hatte COBOL ein Standard-Datum Typ hatte .... 

03 ORDER-DATE     PIC DATE.

.... Industrie weite Lösungen zur Verfügung auf der Compiler-Ebene wären, notwendig, um die Komplexität eines Sanierungs Schneiden.

Moral:. Verwendet Sprachen mit Standardbibliotheken

COBOL 85 (der 1985-Standard) und frühere Versionen haben keine Möglichkeit, das aktuelle Jahrhundert zu erhalten **, die COBOL einen Faktor Eigen war, die die Verwendung von 4-stelligen Jahren auch nach 2 Byte zusätzlicher Speicherplatz entmutigte war kein Thema mehr.

** Spezielle Implementierungen können für diesen Zweck nicht Standarderweiterungen haben.

Die einzige intrinsische Problem mit Cobol war es ursprünglich ist (Ende der 1960er Jahre) Standardanweisung für das aktuelle Systemdatum abzurufen, das war: 

ACCEPT todays-date FROM DATE

Dies ergab eine 6-stellige Nummer mit dem Datum in YYMMDD Format.

Doch auch dies war nicht unbedingt ein Problem, wie wir Code in den 90er Jahren schrieben diese Anweisung, die gerade überprüft, wenn der Jahresteil weniger als 70 und angenommen, dass das Datum 20YY war, das es ein Y2K070 Problem gemacht hätte. : -)

Der Standard wurde später erweitert (COBOL-85, glaube ich), so dass Sie für das Datum in verschiedenen Formaten fragen konnten, wie: 

ACCEPT todays-date FROM CENTURY-DATE

Was gibt Ihnen eine 8-stellige Nummer mit dem Datum als JJJJMMTT.

Wie Sie und andere haben darauf hingewiesen, viele andere Programmiersprachen erlaubt für ‚verlustbehaftete‘ Darstellung der Daten / Jahr.

Das Problem war wirklich über Speicher und Speicherbeschränkungen in den späten 70er Jahren Anfang der 80er Jahre.

Wenn Ihr Viertel Million Computer Dollar hatte 128K und 4 Festplatten in Höhe von insgesamt etwa 6 Megabyte Sie könnte entweder Ihre Management für ein weiteres Quartal Mühle für eine 256K-Maschine mit 12 mcg Plattenspeicher oder sehr sehr effizient über den Raum stellen.

So alle möglichen platzsparende Tricks wurden usered. Mein Favorit war YYMMDD Datum als 991.231 in einem gepackten Dezimalfeld x'9912310C speichern‘, dann klopfen des letzten Bytes und speichern Sie es als‚991231‘. So anstelle von 6 Bytes nur Sie nahm 3 Bytes.

Andere Tricks enthalten einige hokey Hooky Typ encodeing für Preise - Code 12 -> 19,99 $.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top