Umschreiben von IBM Assembler + COBOL in C ++

Ich arbeite als Vermieter / Manager für eine Autovermietung, die auf einem Mietsystem läuft, das 1972 geschrieben wurde. Ich entschied, dass es vielleicht Zeit für ein Update war. Hier ist ein kurzes Beispiel für den Wahnsinn, mit dem wir uns täglich aus diesem Programm beschäftigen müssen:

Ein Vermieter muss sich daran erinnern, dass für das Drucken auf einem Bildschirm im Feld ACT "MXC" verwendet wird (alles basiert auf Funktionscodes), was verblüffend für "Maximale Anzeige auf einem Vertrag" steht, während für ein anderes PR (für PRint) in erforderlich ist Das Feld AKTION, aber mehrere Bildschirme verwenden ein Y im Feld PT (für PRINT). Ein weiterer Bildschirm verwendet ein Y im Feld PRT (für PRINT). Bei einem weiteren Bildschirm muss der Benutzer die Eingabetaste drücken (nicht jedoch die Eingabetaste neben dem Feld Buchstaben, da dies ein neues Zeilenzeichen ist, muss es die Eingabe auf dem Nummernblock sein) und dann F8, ein anderer, aber verwandter Bildschirm erfordert einfach F8, einige Bildschirme haben ein Feld mit der Bezeichnung PRT, das für PRinT sein sollte, aber das Feld tatsächlich Es wird nichts unternommen und der Druckvorgang wird automatisch ausgeführt, nachdem mehrere Eingabeaufforderungen durchlaufen wurden. Auf weiteren Bildschirmen befindet sich ein Feld mit der Bezeichnung PRINT Y / N.Die Standardeinstellung lautet Y für Vorgänge, bei denen ein anderer Standort bereits Papierkram liefert, und N für Vorgänge, bei denen ein anderer Händler Papierkram benötigt.

Ich entschied, dass ich einen besseren Job als diesen machen könnte, also machte ich mich daran, die Person in der Firma zu kontaktieren, die die Entscheidung treffen würde, dies zu aktualisieren. Irgendwann komme ich zum VP of IT, der für dieses Programm verantwortlich ist. Ich bekomme ein bisschen Informationen von ihm und erfahre, dass mein Autovermieter sein Vermietungsprogramm in IBM Mainframe Assembler mit ein wenig COBOL geschrieben hat. Er sagt, dass derzeit keine Stellen offen sind, aber das sollte ich Schicken Sie ihm trotzdem meinen Lebenslauf per E-Mail (falls sich etwas öffnet).

Das führt mich zu meinen Fragen.

Das erste ist technisch. Mit dem Gedanken, die Wartbarkeit in Zukunft zu verbessern, ist es mein Gedanke, sie in einer höheren Sprache als der Assemblersprache neu zu schreiben. Mein Erfahrungsbereich liegt in C ++, das ist für mich die naheliegende Wahl. Das Unternehmen braucht dringend eine einfachere Möglichkeit, das Programm zu aktualisieren, da ich kürzlich einen Artikel gelesen habe, in dem der Mann, mit dem ich gesprochen habe, mit den Worten zitiert wird, das Team habe hart gearbeitet, und sie sind stolz darauf, bekannt zu geben, dass das Programm jetzt Unterstützung für 5 hat -stellige Ortscodes (anstelle von 4) und 8-stellige Autonummern (anstelle von 7). Kurz gesagt, meine Philosophie zu Updates, auch in solchen Situationen, stimmt mit der von Joel überein: http://www.joelonsoftware.com/articles/fog0000000069.html. Neuschreibungen sollten inkrementell sein, anstatt alles, was es zuvor gab, wegzuwerfen und neu anfangen.

Gibt es eine einfache Möglichkeit, IBM Assembly in C ++ zu integrieren, und wenn ja, wie soll ich das tun? Das Schlüsselwort asm ist mir vage bekannt, aber ich weiß nicht, ob es das Beste ist, das zu verwenden oder etwas anderes zu tun. Ist ein solcher Plan nicht gut beraten? Ich mache den größten Teil meiner Arbeit unter Linux mit g ++ und GNU make, daher sind Antworten darauf willkommen, aber definitiv nicht erforderlich (da ich keine Ahnung habe, welche Art von Build-System sie haben, aber ich vermute, dass es fast keine gibt).

Die zweite Frage ist politischer. Wie soll ich dieses Unternehmen davon überzeugen, dass es den Wechsel vornehmen muss? Die theoretischen Kosteneinsparungen sind enorm (meiner Schätzung nach verschwendet das Unternehmen etwa eine Million Dollar pro Jahr, nur um zu lernen, wie man mit dem Programm interagiert), aber meine vorgeschlagenen Änderungen würden wahrscheinlich die Gesamtkosten senken Aktuelle Programmierer haben keine Arbeit, sollten sie in Kraft treten, so gibt es einen großen strukturellen Widerstand gegen Veränderungen.

edit: Ich sollte erklären, warum es für mich die beste Lösung ist, das zu ändern, was das Unternehmen bereits hat. Ich bin immer noch offen für andere Vorschläge, da dies jedoch ein Monster eines Programms ist. Ich hatte noch nie zuvor einen Programmierjob. Bitte korrigieren Sie mich bei einer falschen Analyse.

Zunächst gibt es die Standardlösung.

Nach meinen Gesprächen mit einigen mittelständischen Managern über diese Art von Dingen ist eines der Hauptprobleme beim Umstieg auf ein neues System die große Anzahl loyaler Mitarbeiter, die seit Jahrzehnten im Unternehmen sind und mit dem System inzwischen vertraut sind . Wenn ich in der Lage bin, das, was wir haben, zu ändern, könnte ich die aktuelle Schnittstelle in einer Art "Kompatibilitätsmodus" beibehalten. Benutzer müssen sich bereits anmelden, um das aktuelle System zu verwenden, sodass ich die Möglichkeit hinzufügen kann, eine Einstellung zu aktivieren, wenn Benutzer sich zum ersten Mal anmelden (nachdem ich diese Änderung vorgenommen habe), wobei sie die Option haben, eine der beiden Optionen zu verwenden "klassische" Schnittstelle oder die "neue" Schnittstelle. Es gibt keine Möglichkeit, eine Standardlösung zu finden, die dies ermöglicht.

Mein Unternehmen besitzt auch die von uns verwendete Software. Wir lizenzieren es nicht. Das bedeutet, dass das Management, mit dem ich gerade spreche, die gleichen Personen sind, die mich tatsächlich zu einer Änderung ermächtigen könnten. Bei einer Lösung eines Drittanbieters müsste ich zusätzlich zu den Rechten, die für das Unternehmen, das das von uns verwendete Produkt entwickelt hat, erforderlich sind, die Genehmigung meines Unternehmens einholen, was eine zusätzliche Hürde darstellt. Dies würde auch erfordern, das Unternehmen zu überzeugen, "sein" Produkt aufzugeben und ein anderes Produkt zu nehmen. Dies scheint eine größere Hürde zu sein, als zu versuchen, das, was wir haben, zu aktualisieren, aber ich könnte in diesem Punkt durchaus falsch liegen.

Schließlich möchte ich in die Zukunft blicken und nicht nur die Benutzeroberfläche verbessern und ein paar Fehler beheben. Nachdem ich diese "dringenden" Probleme aktualisiert hatte, hoffte ich, die grundlegende Funktionsweise des Unternehmens in Bezug auf Technologie zu aktualisieren. Nachdem ich ein bis zwei Jahre mit diesen Themen verbracht hatte, war mein Plan, zum Management zurückzukehren und dramatischere Änderungen vorzuschlagen. Es gibt viele Möglichkeiten, die das Unternehmen durch Technologien, die es derzeit einfach nicht nutzt, grundlegend verbessern könnte. Zum Beispiel funktioniert jede Region so ziemlich auf die gleiche Weise. Der lokale Großflughafen ist der zentrale Knotenpunkt für die Verteilung von Autos. Sie werden in erster Linie nach Bedarf gesendet. Der Flughafen wird jedoch als Basis für alle Operationen verwendet. Sie schicken zwei Leute in einem Auto zu mir, um ein Auto von uns abzuholen, das wir nicht brauchen. Dann kehren Sie mit dem Auto zum Flughafen zurück, mit dem Sie gekommen sind, plus dem, was Sie zurücknehmen (wir sind 32 Meilen vom Flughafen entfernt). Dann werden sie mit zwei Autos zu dem Ort kommen, der 5 Meilen von uns entfernt ist, um eines von ihnen abzustellen, und dann mit ihrem anderen Auto zum Flughafen zurückkehren. Sie tun dies auch dann, wenn das Auto, das wir zurückgeschickt haben, dasselbe Auto ist, das sie in unserer Nähe benötigen. Ich bin jetzt seit ungefähr zwei Jahren in der Firma und es scheint, als ob sie nur in den extremsten Notfällen von Autoknappheit davon abweichen (also ungefähr dreimal je). Ich würde die 4 Leute, die in jeder Region arbeiten, durch ein automatisiertes Planungssystem ersetzen, das festlegt, welche Autos wohin fahren, und versuchen, den Weg zu finden, der die geringste Zeit + Kilometer + Fahrer benötigt, um alle Autos dort abzuliefern, wo sie sein müssen Beispiel für die höheren Korrekturen, die ich hoffe, eines Tages hinzuzufügen.

Bevor ich dies alles vorschlage, halte ich es jedoch für hilfreich, sich durch kleinere Aufgaben wie das Aktualisieren der Benutzeroberfläche einen Überblick über das Unternehmen und die Codebasis zu verschaffen. Lösungen wie Outsourcing oder auf andere Weise würden diese Möglichkeit aufheben.

Ich beschränke mich auf die technische Front ...

Ich schlage vor, Sie bestimmen zunächst die Umgebung, in der die Anwendung ausgeführt wird. "Mainframe" kann verschiedene Bedeutungen haben, je nach Alter der Anwendung kann es sich um CICS oder IMS handeln . Es ist auch möglich, dass die ursprünglichen Autoren ihre eigene gestartete Aufgabe geschrieben haben.

Abhängig davon, wo die Anwendung ausgeführt wird, werden wahrscheinlich APIs für diese Umgebung verwendet. CICS verwendet jetzt eine Schnittstelle, die sich deutlich von den früheren unterscheidet. Ich kann nicht für IMS sprechen. Wenn es sich bei der Anwendung um eine eigene gestartete Aufgabe handelt, verfügt sie möglicherweise über eine eigene interne API. Ich verbringe etwa sieben Jahre damit, ein solches Biest zu unterstützen, das im selben Zeitalter geschrieben wurde.

Etwas anderes zu betrachten, da das Alter der Anwendung ist, dass der Assembler mit dem Sie C ++ schon vor der Existenz integrieren Language Environment (LE). Sofern der Assembler nicht so aktualisiert wurde, dass er LE-konform ist, treten einige Probleme auf, da C und C ++ LE-konform sind und ihre Aufrufer und Anrufer ebenfalls konform sein müssen.

Ein weiterer zu berücksichtigender Punkt: Wenn diese Anwendung auf einem moribund Großrechner ausgeführt wird, möchten Sie möglicherweise eine Integration in eine Anwendung versuchen, die auf nicht unterstützter Hardware und Software ausgeführt wird. Dies ist nicht unähnlich dem Versuch, eine 1989 geschriebene Anwendung zu integrieren, die unter DOS 4.01 auf der Originalhardware ausgeführt wird.

Du springst mit der Waffe. Aus Ihrer Beschreibung geht hervor, dass Sie die aktuelle technische Umgebung nicht vollständig verstanden haben (welches Betriebssystem genau, wo und wie werden die Daten gespeichert, gibt es Schnittstellen zu anderen Systemen usw.). Aber noch wichtiger: Ein seriöser Plan sollte Alternativen zu einem teilweisen oder vollständigen Inhouse-Rewrite der Software in Betracht ziehen, nämlich Standard-Software, Outsourcing des Rewrites, Software as a Service usw.

Wie auch immer das Unternehmen letztendlich vorgeht, es muss zunächst gründlich analysiert werden, was die Software heute tut und welche Anforderungen an die neue Lösung gestellt werden.

Warum bieten Sie diese Analyse nicht an?

Ich bin überrascht, dass Sie eine so höfliche Antwort erhalten haben!

Schauen wir uns das aus ihrer Sicht an.

Sie verwalten erfolgreich ein dreißig Jahre altes System mit wahrscheinlich hunderttausenden Codezeilen und sind Schnittstellen zu vielleicht zwanzig anderen Systemen, die Geschäftsprozesse verkörpern, die sich über vierzig Jahre entwickelt haben.

Sie sind wahrscheinlich / hoffentlich Experten auf ihrem Gebiet und würden C ++ als Rückschritt von IBMs "High Level Assembler Language" betrachten, um ihm den vollständigen Titel zu geben. IBMs Assembler-Sprache ist extrem leistungsfähig und die "MACRO" -Sprache ist die beste Implementierung einer Vorverarbeitungs- / Vorlagensprache, die es je gab.

Es wird einen Vorschlag geben, das System etwa alle fünf Jahre seit seiner ersten Implementierung zu ersetzen. Einige wären nach einer Durchführbarkeitsstudie abgelehnt worden, einige wären bis zur Entwurfsphase vorgedrungen, bevor sie ihr Budget verloren haben, einige haben sich möglicherweise sogar in die Code- und Testphase eingearbeitet, bevor sie auf Leistungsprobleme stießen und eingemacht wurden.

C ++ würde einfach nicht helfen. In der Umgebung, in der die Anwendung ausgeführt wird, gibt es keine Grafikbibliothek. (Es gibt eine 3270-Grafikbibliothek, aber es ist unwahrscheinlich, dass sie in C ++ unterstützt wird, da sie von niemandem verwendet wird. Es gibt eine vollständige "X" -Clientbibliothek, aber Sie müssen sich in einer anderen Umgebung befinden, um sie zu verwenden.)

Sie haben eine Benutzeroberfläche, die alles andere als perfekt ist, die aber bekannt und schnell ist. Ein erfahrener Bediener füllt ein Formular mithilfe eines grünen Bildschirms etwa dreimal schneller aus als mit einer entsprechenden grafischen Benutzeroberfläche. Außerdem können sie auf den Kunden achten, während sie den Typ berühren.

Die Bildschirmbediener benötigen Schulungen für jede von ihnen verwendete Benutzeroberfläche. Die Umschulung aller Mitarbeiter für die Verwendung einer neuen und unbekannten Benutzeroberfläche wäre ein enormer Kostenfaktor im Vergleich zur Schulung der neuen Mitarbeiter für das alte, weltweite System.

Ich hatte vor einigen Jahren ein ähnliches Problem bei BellSouth. Ich habe einfach COBOL-Code geschrieben, um Assembler-Sprachprogramme Byte für Byte zu scannen, die Opcodes und Operanden zu trennen, Verzweigungsanweisungen in Go-to-Anweisungen zu konvertieren und Vergleichsanweisungen in IFs zu konvertieren. Dieses Programm konvertierte DC-Anweisungen in den entsprechenden COBOL Data Division-Code und konvertierte Züge, Zaps usw. nach Bedarf.

Nachdem das erledigt war, schrieb ich ein zweites Programm, um IFs und GOTOs in IF-THENs umzuwandeln, mit Bewegungen und dergleichen in den Zeilen zwischen diesen Clustern (das war eigentlich gar nicht so schwer - das Geheimnis ist, die IFs und einzufügen ELSEs, wenn Sie den Pidgin-Cobol der ersten Phase erneut von hinten nach vorne lesen).

IF-THEN-ELSER suchte nach Situationen, in denen ein GOTO-Verweis in unmittelbarer Nähe eines Etiketts gefunden wurde, der sicher gelöscht werden konnte (Verringerung der Anzahl der Verweise um 1). Sie führen dieses IF-THEN-ELSER-Programm iterativ aus (dh, Sie führen es immer wieder aus und halten nur dann an, wenn Ihr letzter Durchgang keine Möglichkeit mehr bietet, Änderungen vorzunehmen). Der größte Teil der kritischen Arbeit wird von diesem Wenn-Dann-Andersen geleistet, dessen COBOL-Produkt von einem erfahrenen, kompetenten Assembler-Programmierer (nämlich mir) sorgfältig überprüft und überprüft werden muss. Meiner Erfahrung nach konnte mein "Wenn-Dann-Anders" mehr als 90 Prozent der GO TOs aus den ursprünglichen Verzweigungsanweisungen eliminieren.

Ich nehme an, dass es möglich ist, von diesem Punkt an mit einer einfachen Konvertierung in C (oder C ++) - Sprachen fortzufahren, mit denen ich auch vertraut bin. Unsere bevorzugte Zielsprache bei BellSouth war jedoch COBOL / II. In Situationen, in denen ein verbleibendes Label über mehrere GO TO-Referenzen verfügt, ist die Komplexität stets gering (diese Situationen werden häufig von COBOL PERFORMs behandelt, können jedoch manchmal einfach durch OR- und AND-Konstrukte dargestellt werden).

Ich finde es schön, Code in COBOL / II mit eleganter Blockstruktur zu produzieren, mit EVALUATEs (Case-Konstrukten) und 88 Level-Bedingungsnamen. Das Hinzufügen dieser letzten Feinheiten führte zu einem weiteren Programmpaar, das sich bei COBOL-Programmen als nützlich erwies, die nicht aus von Assembler konvertierten Programmen stammten.

Ich weiß nicht, ob das hilft.

Wie andere oben kommentiert haben, müssen Sie diesen Prozess mit Sorgfalt durchführen. Es ist hilfreich, über 10-12 Jahre Assembler-Codiererfahrung zu verfügen, um Ihre Entscheidungsprozesse zu beeinflussen. Wir, die diese Erfahrung haben, sind schwer zu finden.

Als letzte Anmerkung: Wir haben damals nur in Assembler geschrieben, weil die Compiler für die Hochsprachen umständlichen, ineffizienten Objektcode erzeugten. Die heutigen "optimierenden" COBOL-Compiler haben nicht die gleichen schlechten Gewohnheiten. ----------

Joels Rat ist im Allgemeinen gut, aber in diesem Fall ist eine vollständige Neufassung überfällig. Idealerweise eine Umschreibung mit einer Streitaxt, da es sich hier um ein Monster handelt.

Ich bin mir nicht sicher, was ich genau hinzufügen soll, da Sie selbst bereits ein ziemlich gutes Argument für diese Neufassung vorgebracht haben. Meine einzige Empfehlung wäre, C ++ komplett zu überspringen und direkt zu einem Webinterface für das Mietsystem zu wechseln, da dies wahrscheinlich noch einfacher für die Schulung der Mitarbeiter ist und Ihnen viel Arbeit auf der Benutzeroberfläche erspart (und auch Arbeit macht) Es ist viel einfacher, neues Blut in das Projekt zu bekommen oder das Ganze einfach auszulagern.

Was die vorhandenen COBOL-Programmierer betrifft, so können sie möglicherweise bei der Dokumentation des vorhandenen Systems und beim Migrationsprozess helfen.

Was den technischen Aspekt betrifft, hängt vieles von der Qualität - der Modularität - des Assembler-Codes ab. Einige Programmierer wussten, wie wichtig es ist, Module mit bestimmten, eingeschränkten Funktionen und einer übersichtlichen, einfach parametrisierten Schnittstelle unter Verwendung von Standardkonventionen für die Verknüpfung von IBM-Subroutinen zu erstellen. Die große Mehrheit neigte jedoch dazu, monolithische Monstrositäten zu erzeugen.

Mit dem ersteren ist die Wiederverwendung möglich, und es sollte nicht so schwer sein, den "Klebstoff" zwischen C ++ und Assembler herauszufinden, vorausgesetzt, Ihre Assembler-Module verwenden standardmäßige (oder zumindest konsistente) Aufrufsequenzen. Aller Wahrscheinlichkeit nach wird der Assembler-Code jedoch ein Durcheinander sein. Obwohl es möglich war , strukturierte Assembler zu schreiben, taten dies nur sehr wenige, und es wird nahezu unmöglich sein, ein "Design" zu erkennen, von dem aus mit dem Umschreiben begonnen werden kann.

Auf der anderen Seite ist der Assembler 360/370 im Vergleich zu den heutigen Mikroprozessoren ziemlich leistungsfähig und viel einfacher, und C wird manchmal als "High-Level-Assembler" bezeichnet. Ich arbeitete für ein DBMS-Unternehmen, dessen Produkt vollständig aus 370 Assemblern bestand, und unser Hauptarchitekt glaubte, dass es möglich sein könnte, den Assembler-Code maschinell in C zu übersetzen (für zukünftige Portabilität). Ich bin skeptisch, aber der Punkt ist, dass der Abstand nicht so groß ist, wie Sie vielleicht denken.

Weiß nicht, ob dies hilfreich ist. Wie gesagt, ich denke, es hängt stark von der Qualität und Größe des Originalcodes ab.

Ich kann nicht sagen, ob es sich um einen Witz handelt oder nicht - in Ihrer Firma wird ernsthaft Code ausgeführt, der ursprünglich vor 39 Jahren geschrieben wurde? Wenn es auf einem System / 360 läuft, müssen Sie g ++ aus dem Quellcode kompilieren ...

Ehrlich gesagt, würde ich nicht einmal darüber nachdenken, irgendeinen der alten Codes zu verwenden. Sie müssen einen neuen Ansatz wählen, sich hinsetzen und darüber nachdenken, was in das Design einfließen muss, und dies von Grund auf tun. Ja, es wird einiges an Planung erfordern, aber ich glaube nicht, dass Joel sagen würde, dass dies ein Fall für inkrementelle Änderungen ist.

Um das Unternehmen davon zu überzeugen, dass Sie wechseln müssen, müssen Sie auf bestimmte Gründe hinweisen , die die Effizienz verbessern, zu niedrigeren Kosten führen und / oder zeigen, dass das, was Sie jetzt verwenden, dem Endergebnis im Moment einen gewissen Schaden zufügt.

Ein weiterer Kommentar - ich stelle mir vor, dass andere Autovermieter sich im 21. Jahrhundert dem Rest von uns angeschlossen haben. Ich würde ein bisschen rekonstruieren, um zu sehen, wie sie es machen (webbasiert, wie ich mir vorstellen kann), und es möglicherweise nach einem dieser Systeme modellieren (dh das Rad nicht neu erfinden).

Viel Glück!

Theoretisch sollte es nicht schwierig sein, das obere Management davon zu überzeugen, das alte System zu ersetzen, wenn Sie zeigen können, dass es ihnen Megabucks erspart. Und das wird es. Es wird immer schwieriger, Programmierer zu finden, die dieses System warten, und diese Programmierer werden immer teurer. Es geht nicht um "Wenn", sondern um "Wann". Es muss wirklich aktualisiert werden.

Die Frage ist jedoch, ob Sie sie nicht nur davon überzeugen können, dass eine Aktualisierung erforderlich ist (und sie wissen das wahrscheinlich sowieso), sondern dass es sich um ein firmeninternes Projekt handeln sollte. Vor allem, wenn das Team nur Sie ist. Sehr oft wird ein derart großer Ersatz ausgelagert. Möglicherweise steht sogar eine Standard-Software zur Verfügung. Diese Optionen müssen untersucht werden, und Ihre Manager werden darauf bestehen, dass dies geschieht, wenn sie vernünftig sind.

Was die Aufgabe betrifft, wenn Sie es tun würden, glaube ich tatsächlich, dass ein Bulldoze-Rewrite in diesem Fall angebracht sein könnte. Joels Argument gilt nicht in jedem Fall. Allerdings konnte ich es nicht wirklich wissen, ohne es zu sehen.

1. Eine inkrementelle Änderung kommt nicht in Frage.

2. Es ist wahrscheinlich, dass eine Standardlösung verfügbar ist. Es gibt viele Autovermietungen.

3. Wenn Sie es als letzten Ausweg neu schreiben müssen, überlegen Sie zunächst, wie das neue System funktionieren wird.
   Nachdem Sie die Funktionen und Schnittstellen ermittelt haben, können Sie die Entwicklungstools auswählen, die am besten zu den Anforderungen (und Ihren Fähigkeiten) passen.

Eine Strategie, um den Stress für Endbenutzer zu minimieren, besteht darin, zunächst die alte hässliche Benutzeroberfläche zu emulieren, die den Benutzern bekannt ist, und dann nach und nach Funktionen für die Benutzeroberfläche hinzuzufügen und sie auf einer modernen Benutzeroberfläche zu entwöhnen.

Wahrscheinlich möchten Sie nicht dasselbe Dateiformat beibehalten, sodass nach dem Wechsel kein Zurück mehr möglich ist.