Meine Erfahrung bei der Mainframe-Modernisierung für eine große US-Bank (Bhasheer Lepakshi)

Hintergrund zur Mainframe-Modernisierung:

      Nachdem die Computerrevolution im Banken-, Versicherungs- und anderen wichtigen Sektoren begonnen hatte, war Mainframe eine der größten Revolutionen, um Daten sicherer zu speichern und zu verwalten. Auch heute noch pflegen viele große Banken und Versicherungen das Mainframe-System.

      Im Laufe der Zeit kamen technologisch so viele Veränderungen, und die Welt wurde digitaler, und Benutzer/Kunden möchten innerhalb von Sekundenbruchteilen auf Daten zugreifen und keine Zeit haben, sich auf traditionelle Weise des Bankings und anderer Dienstleistungen zu begeben. Banken und andere Branchen sind also gezwungen, sich auf den digitalen Weg zu begeben.

 In dieser digitalen, schnellen Welt wird es schwierig, auf Daten von Legacy-Systemen wie Mainframe zuzugreifen, um Kunden schnelle Dienste anzubieten, daher suchen Kunden nach Modernisierung.

Wichtige Initiativen für die Mainframe-Modernisierung sind:

1. Re-Engineering: Disruptive Transformation zu digitalen Plattformen wie Cloud und Micro Services
2. Re-Hosting: Umplattformierung qualifizierter Anwendungen auf eine verteilte Plattform unter Beibehaltung der Legacy-Architektur und des Codes
3. In-Place-Modernisierung: Nutzen Sie die Modernisierungsfunktionen von System z und System I mit der richtigen Mischung aus Legacy
4. Ersetzen: Ersetzen Sie die Anwendung durch ein geeignetes COTS-Produkt, nachdem Sie eine gründliche Anpassungsanalyse durchgeführt haben

Dieser Blog beschreibt das Re-Engineering-Szenario. In diesem Szenario müssen wir die Geschäftsregeln aus Legacy-Code extrahieren, der vom Forward Engineering-Team als Anforderungsdokument verwendet wird:

Wie konvertiert man den Mainframe-Code in Geschäftsregeln?

1. Vorlagenvorbereitung:

     Wann immer wir mit einer Legacy-Konvertierung beginnen, besteht die erste größte Herausforderung darin, die vorhandene Geschäftslogik zu verstehen und in das richtige Format zu bringen, das das Forward Engineering-Team verstehen und mit seinem Codierungsweg entwickeln kann.

Die Vorlage ist der Schlüssel zum Zusammenstellen der Geschäftsregeln. Wenn die Vorlage das Folgende beschreiben kann, wäre dies hilfreich:

1. Stellenzusammenfassung (JCL-Zusammenfassung), die Folgendes beschreiben sollte –
   1. Job-Funktionalität / Beschreibung
   2. Im Auftrag verwendete Dateien (Lesen/Schreiben)
   3. Verwendete DB2-Tabellen (programmweise)
   4. Planungsinformationen
   5. Auftragsablauf (wahrscheinlich Baumstruktur)
   6. Anleitung zum Neustart
2. Geschäftsregeln – es sollte die Regeln beschreiben, die mit der spezifischen Funktion aus dem spezifischen Programm verbunden sind
3. Datensatz-Layout – Datensatz-Layout/Dateistrukturen, die im Programm verwendet werden
4. Feldzuordnung – Es sollte entweder in Bild- oder Tabellenform beschreiben, wie die Quelle-zu-Ziel-Zuordnung in der Geschäftslogik/dem Geschäftsprogramm erfolgt

   2. Schreiben der Geschäftsregeln:

     Analysieren Sie den Code und verstehen Sie den logischen Ablauf des Programms. Versuchen Sie nicht, jeden Absatz als Regel zu schreiben. Falls erforderlich, müssen wir die Absätze möglicherweise kombinieren, um die Geschäftslogik/Regel auf logische Weise darzustellen.

Folgendes muss beim Schreiben der Geschäftsregeln berücksichtigt werden:

• Ordnen Sie jede Transaktion und jeden Job einer Geschäftsfunktion zu   
• Sobald die Regeln erfasst sind, ordnen Sie sie Ebene 4, Ebene 3, Ebene 2, Ebene 1 und Ebene 0 zu. Level-0 ist das höchste und es ist eine Kombination der Levels 1 bis 4, um die Funktion zu erreichen (Beispiel: Kunden-Onboarding wird Level-0 sein).
• Überschriften, Unterüberschriften – Überschriften und Unterüberschriften sind sehr entscheidend beim Schreiben der Geschäftsregeln, z Ablauf oder Logik, indem Sie die Überschrift und Unterüberschriften sehen.
• Temporäre Variablen/Arbeitsspeichervariablen – Stellen Sie sicher, dass Sie die Referenz für jede Temp-Variable angeben, erwähnen Sie die Regelnummer, wo wir diese Variable verwenden oder darauf verweisen werden 
• IF-Bedingungen und EVALUATE-Anweisungen – Im alten Programmierstil für IF-Bedingungen würde END-IF nicht erwähnt, also achten Sie darauf, das END-IF zu erwähnen und die Farben im Falle von verschachtelten IFs zu verwenden. Unterteilen Sie jede Bedingung in eine bestimmte Regel.
• PERFORM-Loops – Erwähnen Sie deutlich, wann der Loop beginnt und wann er endet
• ARRAYS/Tabellen – Erwähnen Sie alle Deklarationen im Fall von Arrays/Tabellen und der zugehörigen Verwendung für eine bestimmte Funktion.
• Datenbank - Beim Schreiben von datenbankbezogener Logik sollten Sie den DECLARE CURSOR und alle anderen SQL-Anweisungen besser als Regel schreiben und die Referenz angeben, wo immer Sie darauf verweisen müssen. Erwähnen Sie die Bedeutung von SQLCODE, während Sie die Logik in Business Rule hinzufügen.
• Fehlerbehandlung - Stellen Sie sicher, dass die Fehlerbehandlung zusammen mit den DISPLAY-Anweisungen ordnungsgemäß dokumentiert ist.
• Gemeinsame Routinen – Gemeinsame Routineregeln können in einem gemeinsamen Blatt oder Dokument platziert werden, sodass das Forward Engineering-Team sie einmal erstellen und verwenden kann.

Geschäftsregeln dem Forward Engineering Team präsentieren:

       Die größte Herausforderung besteht darin, wie effektiv Sie dem Forward Engineering-Team die Logik erklären können. Wenn Sie einen technischen BA bekommen, der sich mit dem System auskennt, haben Sie Glück! Damit Sie die Logik erklären können und BA versteht und Anwendungsfälle aufzeigen kann.

Der bessere Weg von der Mainframe-Seite ist es, ein Flussdiagramm mit sehr hohem Fluss auf Jobebene zu erstellen. Damit es für das Forward Engineering-Team einfach ist, den gesamten Ablauf zu verdauen, und für die Mainframe-Leute, den Ablauf auch zu erklären.

Stellen Sie sicher, dass Sie dem BA- und Forward-Engineering-Team die gesamte Logik erklären. Und wenn Low-Level-Design auf Forward-Engineering-Seite erstellt würde, dann in ihrer eigenen Arbeitsweise. Es wäre nützlich für das Team.

Konvertieren von Regeln in Java:

      Bei der Umstellung von Mainframe COBOL auf Java sollte man den Unterschied zwischen COBOL und Java verstehen. Erstens ist COBOL eine prozedurale Sprache und hätte die Schritte der Reihe nach definiert. Während Java eine objektorientierte Sprache ist, die OOPs-Konzepten folgt.

Berücksichtigen Sie die Arten von Anwendungen, die für COBOL gut geeignet sind. Der Begriff COBOL ist ein Akronym für Common Business Oriented Language. Die Sprache wurde entwickelt, um Geschäftsfunktionen wie Berichterstellung, Zahlenverarbeitung und Datenverarbeitung zu unterstützen. Dies bedeutet nicht, dass COBOL keine anderen Verarbeitungsarten durchführen kann; es kann. Nur dass einige Arten von Programmen besser mit einer anderen Sprache entwickelt werden können.

    Java ist eine objektorientierte Programmiersprache, die für Mehrzweck-Computing geeignet ist, mit dem zusätzlichen Vorteil, dass sie auf mehrere Hardwareplattformen portierbar ist. Die Möglichkeit, dasselbe Programm auf verschiedenen Computern auszuführen (sofern eine Java Virtual Machine für die Plattform verfügbar ist), ist einer der Gründe dafür, dass Java heute eine der beliebtesten Sprachen für neue Entwicklungen ist.

Die folgenden Überlegungen müssen von der Java-Seite durchgeführt werden, um COBOL-Code zu konvertieren:

1. Verstehen Sie die Java-Codierungsstandards gemäß der Client-Umgebung
2. Der Unterschied zwischen COBOL- und Java-Datentypen
3. Äquivalente Funktionen zwischen COBOL und Java.
4. Welche Datenbankverbindung soll in Java im Falle von Legacy-Datenbankaufrufen (entweder JPA oder JDBC) verwendet werden?
5. Gibt es eine Abfrageoptimierung, die für die DB-Abfragen durchgeführt werden kann?
6. Gibt es Parallelläufe (zwischen den Schritten) die möglich sind?
7. Können wir Chunking-Logik für DML-Operationen implementieren?
8. Alle gängigen Routinen/Dienste müssen erstellt und wiederverwendet werden

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
• Quelle: https://www.finextra.com/blogposting/23602/my-experience-on-mainframe-modernization-for-major-us-bank?utm_medium=rssfinextra&utm_source=finextrablogs