Heute veröffentlichen wir den zweiten Teil der Übersetzung von Material über Mathematik, über COBOL und warum diese Sprache noch lebt.
→
Der erste TeilMüller- und COBOL-Rezidivrate
Schauen wir uns an, wie COBOL mit der Müller-Wiederholungsrelation umgeht. Hier ist ein COBOL-Programm, das die von uns untersuchte Wiederholungsbeziehung implementiert.
IDENTIFICATION DIVISION. PROGRAM-ID. muller. AUTHOR. Marianne Bellotti. DATA DIVISION. WORKING-STORAGE SECTION. 01 X1 PIC 9(3)V9(15) VALUE 4.25. 01 X2 PIC 9(3)V9(15) VALUE 4. 01 N PIC 9(2) VALUE 20. 01 Y PIC 9(3)V9(15) VALUE ZEROS. 01 I PIC 9(2) VALUES ZEROS. PROCEDURE DIVISION. PERFORM N TIMES ADD 1 TO I DIVIDE X2 INTO 1500 GIVING Y SUBTRACT Y FROM 815 GIVING Y DIVIDE X1 INTO Y MOVE X1 TO X2 SUBTRACT Y FROM 108 GIVING X1 DISPLAY I'|'X1 END-PERFORM. STOP RUN.
Wenn Sie zum ersten Mal ein in COBOL geschriebenes Programm sehen, klären wir einige Dinge sofort. Erstens handelt es sich um die sogenannte „freie Form“ COBOL, die 2002 eingeführt wurde, um COBOL näher an die Struktur moderner Sprachen heranzuführen. Traditionell hat COBOL-Code eine feste Breite, wenn bestimmte Entitäten in bestimmten Spalten platziert werden. Die Idee, Code in Form einer Struktur zu betrachten, in der Zeilen und Spalten hervorgehoben sind, mag seltsam erscheinen, aber eine solche Codestruktur sollte die Formatierung von Lochkarten simulieren. In den Tagen von COBOL wurden Programme auf diese Weise erstellt. Eine Lochkarte hat 80 Spalten - bestimmte Spalten gelten für bestimmte Daten. Der gleiche Ansatz ist für COBOL traditionell.
Das Wichtigste in diesem Code, was vielleicht am meisten Aufmerksamkeit erregt, ist, wie Variablen hier deklariert werden:
01 X2 PIC 9(3)V9(15) VALUE 4.
Der Code
01 am Zeilenanfang wird als Ebenennummer bezeichnet. Er sagt COBOL, dass wir eine neue Variable deklarieren. Mit COBOL können Sie Variablen binden oder gruppieren (ein klassisches Beispiel ist eine Adresse, die die Namen der Straße, der Stadt und des Landes als separate Variablen enthalten kann). In diesem Fall wird die Ebenennummer wichtig.
X2 ist der Name der Variablen - alles ist ziemlich einfach. Am Ende gibt es eine Konstruktion, die den Anfangswert der Variablen festlegt, die wie "
VALUE 4. " aussieht. Der Punkt am Ende ist kein Tippfehler. Dies ist eine Möglichkeit, Zeilen in COBOL zu beenden.
Jetzt müssen wir nur noch überlegen, was sich in der Mitte der Linie befindet - die Konstruktion von
PIC 9(3)V9(15) .
PIC ist ein Operator zum Beschreiben eines Zeichendatentyps. Es können alphanumerische Werte gespeichert werden. Es können sogar Dezimalzahlen gespeichert werden. COBOL ist eine Sprache mit strenger statischer Typisierung und einer ungewöhnlichen Eigenschaft: Die meisten COBOL-Typen sind viel flexibler als Typen in anderen Sprachen. Außerdem müssen Sie beim Deklarieren von Variablen angeben, aus wie vielen Zeichen sie bestehen können. In unserem Fall ist dies die Zahl in Klammern. Die Konstruktion von
PIC 9(3) bedeutet, dass eine Variable drei Zeichen speichern kann, die Zahlen sind (angezeigt durch die Zahl
9 ).
Infolgedessen sollte die Konstruktion
9(3)V9(15) wie folgt gelesen werden: „3 Stellen, gefolgt von einem Dezimalpunkt (v), gefolgt von weiteren 15 Stellen.“
Hier sind die Ergebnisse dieses Programms:
01|004.470588235294118 02|004.644736842105272 03|004.770538243626253 04|004.855700712593068 05|004.910847499165008 06|004.945537405797454 07|004.966962615594416 08|004.980046382396752 09|004.987993122733704 10|004.993044417666328 11|005.001145954388894 12|005.107165361144283 13|007.147823677868234 14|035.069409660592417 15|090.744337001124836 16|099.490073035205414 17|099.974374743980031 18|099.998718461941870 19|099.999935923870551 20|099.999996796239314
Dies geschah mit Zahlen mit 15 Dezimalstellen. Wenn wir die Eigenschaften der Variablen
X1 ,
X2 und
Y in
PIC9(3)V9(25) , können wir
PIC9(3)V9(25) :
01|004.4705882352941176470588236 02|004.6447368421052631578947385 03|004.7705382436260623229462114 04|004.8557007125890736342050246 05|004.9108474990827932004556769 06|004.9455374041239167250872200 07|004.9669625817627006050563544 08|004.9800457013556312889833307 09|004.9879794484783948244551363 10|004.9927702880621195047924520 11|004.9956558915076636302013455 12|004.9973912684019537143684268 13|004.9984339443572195941803341 14|004.9990600802214771851068183 15|004.9994361021888778909361376 16|004.9996648253090127504521620 17|004.9998629291504492286728625 18|005.0011987392925953357360627 19|005.0263326115282889612747162 20|005.5253038494467588243232985
Unterschiedliche Mainframes bieten unterschiedliche Obergrenzen für COBOL-Datentypen. Bei IBM (zumindest - in meinem Fall) sind es 18 Ziffern. MicroFocus hat 38 Stellen.
Wie viel kostet Genauigkeit?
Alles, worüber wir gerade gesprochen haben, soll zeigen, dass COBOL Berechnungen nicht besser durchführt als andere, häufigere Programmiersprachen. Aufgrund von Einschränkungen bei der Größe von Festkommazahlen kann COBOL Sprachen unterlegen sein, die dem Entwickler mehr Kontrolle über das Geschehen geben.
Es gibt jedoch eine Funktion. Tatsache ist, dass Python (und Java) keine integrierte Unterstützung für Festkommazahlen bietet. Und in COBOL ist diese Unterstützung.
Um Festpunktberechnungen in Python durchzuführen, musste ich das
Decimal importieren. Wenn Sie jemals mit einem Projekt gearbeitet haben, das eine ganze Reihe von Importbefehlen enthält, sollten Sie sich bewusst sein, dass jeder dieser Befehle einen bestimmten „Preis“ hat. In Sprachen wie Java (diese Sprache wird normalerweise von denjenigen in Betracht gezogen, die COBOL loswerden wollen) kann der "Preis" einer geeigneten Bibliothek erheblich
höher sein . Dies ist in der Tat eher eine Frage, ob die „Kosten“ für den Import von Bibliotheken in Ihrem Projekt eine Rolle spielen. Für viele Programmierer ist das Nachdenken über die Auswirkungen von Importbefehlen auf die Leistung der Höhepunkt einer vorzeitigen Optimierung.
COBOL-Programmierer arbeiten jedoch normalerweise an Systemen, die Millionen und möglicherweise Milliarden von Vorgängen pro Sekunde verarbeiten müssen, und zwar genau und zuverlässig. Und leider ist es sehr schwierig, für ein solches Szenario ein überzeugendes Argument für COBOL oder dagegen zu liefern, da dies tatsächlich ein Bereich mit unzähligen Variationen ist. Ist die in COBOL integrierte Festpunktunterstützung ein entscheidender Faktor bei der Auswahl einer Sprache zur Lösung solcher Probleme? Oder können die entsprechenden Probleme durch Auswahl der richtigen Kombination aus Prozessor, Speicher und Betriebssystem gelöst werden? Oder müssen Sie, um Probleme mit schnellen, genauen und zuverlässigen Berechnungen zu lösen, auf "Tanzen mit einem Tamburin" zurückgreifen? Vielleicht - wir werden das Denken einschränken? Wir werden sie darauf reduzieren, eine Antwort auf eine Frage wie "Was ist besser - COBOL oder Java, wenn Sie dieselbe Hardware verwenden?" Zu finden. Trotzdem wird es für uns schwierig sein zu bewerten, wie sich die Mängel der einzelnen Sprachen auf die Leistung auswirken, wenn das System beginnt, die oben genannten Milliarden Operationen pro Sekunde auszuführen. Daher können wir nur sagen, dass dasselbe COBOL und Java nur sehr unterschiedliche Sprachen sind.
Hier ist, was sie hier darüber schreiben und die Leistung von Java-Code untersuchen, der aus COBOL-Code übersetzt wurde.
COBOL ist eine kompilierte Sprache, die einen Stapel verwendet, der Zeiger und Verknüpfungen unterstützt. Die Typkonvertierung belastet das System während der Programmausführung nicht. Während der Programmausführung finden keine Planungs- oder Typkonvertierungen statt. Java-Code hingegen wird in einer virtuellen Maschine ausgeführt. Es verwendet eine Reihe und unterstützt keine Joins. Die Typkonvertierung belastet das System während der Programmausführung. Java verwendet zur Laufzeit den dynamischen Versand und die Typinferenz. Obwohl es möglich ist, den Umfang der Verwendung dieser Funktionen zu minimieren, führt dies normalerweise dazu, dass der Code mehr oder weniger "anders" ist als gewöhnlicher Java-Code. Wenn sie die Ergebnisse der Übersetzung von Java-Code aus COBOL untersuchen, beschweren sie sich normalerweise, dass der Code nicht lesbar ist und nicht unterstützt wird. Dies negiert die meisten Ziele des Wechsels von COBOL zu Java.
Bevor Sie sich entscheiden, diese Überlegungen mit dem Satz "Ja, aber es ist Java, und Java ist auch kein Geschenk" beiseite zu schieben, denken Sie daran: Die meisten modernen Programmiersprachen bieten absolut keine integrierte Unterstützung für Festkommaberechnungen. (Ich denke, es wäre richtiger zu sagen, dass keine der modernen Sprachen dies unterstützt, aber ich kann dies nicht zuverlässig überprüfen.) Natürlich können Sie eine andere Sprache wählen, die ihre eigenen Vor- und Nachteile hat, aber wenn Genauigkeit in den Berechnungen erforderlich ist Wenn Sie der Meinung sind, dass ein kleiner Leistungsverlust beim Importieren einer Bibliothek, die solche Berechnungen implementiert, Sie verletzen kann, haben Sie die einzige Option - COBOL.
Deshalb ist die sogenannte „Modernisierung“ so komplex: Sie hängt von vielen Faktoren ab. Einige Unternehmen werden konkrete Ergebnisse aus Investitionen in die Änderung der Softwareplattform erhalten, während andere feststellen werden, dass sie etwas Wichtiges verloren haben, als Gegenleistung für „Verbesserungen“, die sich tatsächlich nicht wesentlich verbessern. Wenn ein Unternehmen ein großes Finanzinstitut ist, das Millionen von Transaktionen pro Sekunde verarbeitet und eine dezimale Genauigkeit der Berechnungen benötigt, ist es in der Tat billiger, Spezialisten für die Arbeit mit COBOL auszubilden, als Ressourcen und Produktivität für die Migration in eine populärere Sprache zu zahlen. Popularität ist schließlich nur vorübergehend.
Zusammenfassung
Wenn Sie darüber sprechen, warum so viele Organisationen COBOL noch verwenden, müssen Sie verstehen, dass sich die Aufgabe der Verarbeitung der Programme von der Aufgabe der Erstellung von Programmen unterscheidet. Die Programmierer, die die Lösung erstellt haben, hatten den Vorteil ihrer schrittweisen Implementierung. Anwendungen bemühen sich normalerweise, den Grenzen der von ihren Technologien unterstützten Funktionen so nahe wie möglich zu kommen. Das Dilemma bei der Migration von COBOL besteht nicht darin, von einer Sprache in eine andere zu wechseln. Dies ist die Aufgabe, von einem Paradigma zum anderen zu wechseln. Die Grenzen von Java oder Python unter Linux stimmen überhaupt nicht mit den Grenzen von COBOL auf dem Mainframe überein. In einigen Fällen können COBOL-Anwendungen das, was moderne Sprachen nicht können. In solchen Fällen wird sich die Verwendung von COBOL auf einem modernen Mainframe tatsächlich als billigere, produktivere und genauere Lösung herausstellen.
Liebe Leser! Denken Sie, dass COBOL wirklich eine Sprache ist, die sich in manchen Situationen als wirklich besser herausstellt als modernere Sprachen?
