Wie kann man ohne Dokumentation transformieren?
Nun, es gibt sie doch, die zu 100% verlässliche Programmdokumentation: es ist der hexadezimale Objektcode, den Njema als ultimative Information nutzt.
Nur der Objektcode bestimmt die Logik und den Ablauf eines Programms. Wenn man also in der Lage ist, ihn zu nutzen, wird das erzeugte Cobol Programm immer das genaue logische Abbild des Assemblerprogramms sein.
Njema benötigt daher als Input alle mit HLASM bzw. ASSEMBH erzeugten voll expandierten Umwandlungslisten.
Warum Cobol als Zielsprache?
Cobol wurde in einer Zeit entwickelt als Mainframe Programme nur in Autocoder und Assembler geschrieben werden konnten. Um die Produktivität der Programmierer zu erhöhen, wurde Cobol entwickelt und zwar so, dass sich die Assembler-Programmierer auch schnell in der neuen Sprache zurecht fanden.
Als Folge davon ist Cobol eine Art „Assembler in Verkleidung„. Es ist in seinem Aufbau und seiner Wirkungsweise sehr nahe am Denkmuster des Assemblers. Daher liegt es technisch sehr nahe, in einem ersten Schritt auf Cobol zu gehen. Von dort kann man dann leicht ebenso vollautomatisch zu anderen Sprachen weitergehen.
Wir zeigen anhand eines Demoprogramms, wie aus einem Assembler Programm automatisiert Cobol und zwei davon abgeleitete Java-Varianten entstehen.
Dank der integrierten Refactoring Algorithmen ist jedes erzeugte Cobol gut strukturiert und leicht lesbar. Somit kann es sofort an die reguläre Programmwartung übergeben werden.
Methodik
Für den Projekterfolg ist es jedoch unerlässlich, im Voraus alle Details jeder einzelnen Zeile des Anwendungscodes zu kennen.
- Deshalb untersucht das Njema Assessment alle aufgerufenen System- und Benutzermakros, Codierkonventionen, sowie Tricks und Angewohnheiten der Programmierer.
- Es analysiert die Registernutzung, erkennt selbst-modifizierenden Code und speichert alles in die Njema Metadata Datenbank.
- Njema erstellt auch ein vollständiges Inventar aller Datenfelder, ihrer Eigenschaften und ihrer Beziehung zueinander.
- Da die Metadaten aller Entitäten verfügbar sind, wenn ein einzelnes Objekt transformiert wird, können viele Regeln, z.B. für das Re-Engineering, mit Blick auf alle anderen Statements aller anderen Entitäten arbeiten.
- Auf den Metadaten basierend wird eine projektspezifische Transformation Engine aufgebaut, indem Hunderte von Transformationsregeln aus dem Njema Rule Repository ausgewählt werden.
- Diese Engine transformiert alle Assembler Programme in einem einzigen Durchlauf.
In jedem Lauf werden neue Möglichkeiten zur Erhöhung des Automationsgrads aufgezeigt, die danach zur Transformation Engine hinzugefügt werden. - Situationen, die selten oder nur ein einziges Mal auftreten, werden durch singuläre, projektspezifische Regeln behandelt.
- Nach dem letzten Lauf hat die Transformation Engine gelernt, wie sie die gesamte Assembleranwendung in funktional identisches Cobol umwandeln kann: 100% automatisch.
Monitoring
Gerade große Assemblerprojekte müssen sorgfältig kontrolliert und gesteuert werden. Daher ist die Transformation Engine in einen Monitoring Prozess eingebunden.
Vollautomation der Assembler Transformation
Eine komplette Automatisierung hat eine Reihe von Vorteilen, sie …
- bringt Ruhe in das Projekt
- verringert das Fehlerrisiko dramatisch
- erlaubt eine gute Vorhersage von Dauer, Aufwand und Kosten
- verkürzt die Projektlaufzeit signifikant
- macht das Projekt unabhängig von der regulären Programmwartung
- eliminiert menschliche Fehler, die bei großen Projekten sonst unvermeidlich sind
- erlaubt es, die Transformation ohne Aufwand beliebig oft zu wiederholen
- ermöglicht es, innerhalb von wenigen Stunden eine vollständige Transformation und den finalen Integrationstest durchzuführen, bevor die Anwendung als Cobol-Inkarnation in Produktion gehen kann.
Welche Plattformen sind unterstützt?
Die Njema Assembler Transformation ist für z/OS, TPF, VSE und BS2000 verfügbar.