Umschreiben von IBM Assembler + COBOL in C ++

13

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.

David Stone
quelle
3
Schauen Sie sich den Hercules-Emulator an - das Kernbetriebssystem eines IBM-Großrechners enthält eine Menge Magie, die emuliert werden muss.
Yann Ramin
Ich würde mir ehrlich "von Anfang an wiederholen" ansehen (schlechter C64-Witz). Im Ernst, überprüfen Sie die technischen Daten und finden Sie heraus, wie Sie eine neue GUI selbst erstellen können. Solange die Datenbankschnittstelle dieselbe ist und dies viel Zeit und Recherche erfordert, sind Sie goldrichtig - und in der Schlange, um eine Menge Geld zu verdienen :)
8
Wenn das aktuelle System tatsächlich funktioniert , müssen Sie einen sehr guten Grund dafür haben, sich für den Kunden auszuzahlen. Außerdem werden Sie höchstwahrscheinlich den Arbeitsaufwand für die Reproduktion des aktuellen Systems stark unterschätzen - denken Sie nur, Sie müssen das aktuelle System zuerst vollständig verstehen -, was Ihre Neufassung noch teurer macht als Ihre ursprüngliche Schätzung. Dies soll Sie nicht entmutigen, sondern nur sicherstellen, dass Sie tatsächlich wissen, für welche Herkulesaufgabe Sie sich möglicherweise anmelden, BEVOR Sie nicht zurücktreten können. Machen Sie Ihre Arbeit außerdem inkrementell - mit anderen Worten, bleiben Sie vorerst auf dem Mainframe.
Es ist meine Angst, dass es sehr schwierig sein könnte, das System zu emulieren, weshalb ich nach einer Möglichkeit gesucht habe, kleine, modulare Änderungen vorzunehmen, anstatt bei Null anzufangen.
David Stone
@ David Stone Ich war mal in einem Projekt, wir haben das "Wählen der neuen oder der alten Schnittstelle" Ding gemacht. Es ging SCHNELL in die Entwicklungshölle - der Code war eng mit der Benutzeroberfläche verbunden, und schnell tauchte if (m_newInterface)überall auf der Codebasis Spaghetti-Code auf. Das Entkoppeln und Umgestalten dauerte lange genug, bis die meisten Benutzer bereits auf die neue Benutzeroberfläche migriert waren (denken Sie an mehrere Jahre).
Vitor Py

Antworten:

4

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.

cschneid
quelle
Die Anwendung könnte sogar TPF verwenden , was eine Konvertierung extrem erschwert.
Gilbert Le Blanc
13

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?

Codo
quelle
7
+1 Dies ist die einzige Antwort, die eine vollständige Analyse der vorhandenen Anwendungs- und Unternehmensanforderungen vorschlägt, bevor eine technische Lösung vorgeschlagen wird. Erinnert mich an den alten Witz: Du fängst an zu programmieren - ich werde herausfinden, was sie wollen.
Das ist ein guter Punkt, und ich brauche definitiv mehr Informationen, bevor ich mich dazu verpflichten würde, diese Arbeit zu tun. Ein Teil des Problems ist, dass ich herumgefragt habe und erst als ich zu einem Vizepräsidenten der Firma durchkam, fand ich jemanden, der wirklich irgendwelche Details kannte. Ich habe mehrere Büros angerufen, einschließlich des technischen Supports, und keines von ihnen konnte mir Einzelheiten darüber mitteilen, in welcher Programmiersprache das Programm geschrieben wurde. Ich habe jedoch einige Gründe, eine Standardlösung zu verwerfen, in der ich die Bearbeitung vornehmen werde meine ursprüngliche Frage.
David Stone
7

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.

James Anderson
quelle
4

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. ----------

Mark Mondt
quelle
2

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.


quelle
2
+1: Dies ist kein Job für C ++
6502
2
@ 6502: Warum nicht? Die Expertise des OP liegt in C ++. Herauszufinden, wie man mit einem alten System umgeht, ist schon schlimm genug. Eine andere Sprache zu lernen wird nicht helfen. Ein kompetenter Programmierer, der Werkzeuge einsetzt, die der Programmierer beherrscht, wird in der Lage sein, es unabhängig von der Sprache viel besser zu machen als das alte System.
In silico
1
@In silico: Meiner Meinung nach würden Sie bei einem relativ großen Projekt dieser Größe Zeit sparen, indem Sie eine geeignetere Sprache wie z. B. Python lernen als C ++. Angenommen, Python wäre nicht vorhanden, für ein ausreichend großes Projekt dieser Art würde es sich lohnen, IMO Ihr eigenes Python in C ++ zu schreiben und es damit zu codieren, anstatt das Ganze in C ++ zu machen. C ++ ist eine sehr schöne Sprache, und ihre Stärke ist, dass sie von vornherein keinen Platz unter C ++ und über Assembler lassen soll. Völlig sinnlos hier. Würden Sie vorschlagen, alles mit FPGAs zu schreiben, wenn dies das Fachgebiet des Posters wäre?
6502
3
@ 6502: Ich bin anderer Meinung. Mit der richtigen, modernen Technik, gut gestalteten Bibliotheken und der Kompetenz in der Sprache sind all diese Themen irrelevant. (Das gilt natürlich für jede Sprache.) Und die Leute haben in C ++ umfangreiche Systeme und Software entwickelt, die einwandfrei funktionieren und anscheinend kein Problem mit der Verwendung von C ++ haben. Nur weil Sie C ++ für diesen Job nicht verwenden würden, heißt das nicht, dass andere nicht in der Lage wären, es zu verwenden und es gut zu nutzen. Das muss das OP entscheiden. Ich bin mir sicher, dass Sie in anderen Sprachen sehr produktiv sind und auf jeden Fall weitermachen.
In silico
1
In silico: Natürlich kann theoretisch alles mit allem implementiert werden (einschließlich brainf k). Dies bedeutet nicht, dass alle Werkzeuge gleichwertig sind. Ich denke, dass für eine Geschäftsanwendung mit Code, der einfach zu schreiben und zu lesen ist (auch von nicht-technischen Leuten), viel wichtiger ist als reine Rechengeschwindigkeit. Auch so etwas wie undefiniertes Verhalten ist ein viel zu hoher Preis für die nicht benötigte Nähe zum Metall. Wenn für Sie C ++ eine gute Wahl für die Geschäftslogik eine Dateneingabeanwendung ist, dann frage ich mich, ob es für Sie ** irgendetwas gibt, für das C ++ eine schlechte Wahl ist ...
6502
2

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.

Kerl
quelle
1

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!

Chris Gregg
quelle
5
Es ist nicht ungewöhnlich, dass Großrechnersysteme Codebasen verwenden, die in den 60er oder 70er Jahren gestartet wurden. IBM hält ihre zSeries-Mainframes und das Betriebssystem abwärtskompatibel zur 360, nur weil dies so ist. Das Geschäftsmodell eines Autovermieters (oder einer Bank oder eines Versicherungsunternehmens) hat sich seitdem nicht wesentlich geändert. Sie können zwar ein Webinterface hinzufügen, aber was hat sich an der Art und Weise, wie Sie die Autos in der Datenbank speichern, geändert?
Bo Persson
zOS verfügt über einen systemeigenen C ++ - Compiler mit Vorprozessoren für CICS und DB2. Es besteht also keine Notwendigkeit für g ++.
James Anderson
5
Zweitens ist es für große Unternehmen durchaus üblich, 30 Jahre alten Mainframe-Code zu verwenden. Es ist im Allgemeinen zuverlässig, performant und macht den Job. Es neigt auch dazu, sehr schlecht dokumentiert zu sein.
James Anderson
3
@ Chris, warum sollte 39 Jahre alter Code nicht ausgeführt werden? Wird es mit 30 abgestanden? 20? Kampferprobter Produktionscode kann alt sein, aber trotzdem perfekt funktionieren. Jede Rewrite muss auf das gleiche Niveau wie das alte Programm erhalten , bevor es hat jeden Nutzen für die eine Zahlung Ihrer Gebühren.
1
@ Chris, sehr wenig ist schneller als eine gut geschriebene "Green Screen" -Anwendung, und ich weiß das aus eigener Erfahrung als Java-Typ in einem Cobol-Shop. Ich glaube ehrlich, Sie alle unterschätzen aufrichtig den Arbeitsaufwand, der erforderlich ist, um einen ähnlichen Antrag zu stellen. Auch Code rosten nicht. Nur alt zu sein, ist kein Grund genug, das Problem zu beheben.
0

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.

Igby Largeman
quelle
0
  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.

Michael J
quelle
1
Wenn Sie dies nicht schrittweise tun, schlägt das Projekt höchstwahrscheinlich fehl.