主要な米国銀行のメインフレームのモダナイゼーションに関する私の経験

メインフレームのモダナイゼーションの背景:

銀行、保険、およびその他の主要なセクターでコンピューター革命が始まった後、メインフレームは、より安全な方法でデータを保存および管理するための最大の革命の 1 つです。 現在でも多くの大手銀行や保険会社がメインフレーム システムを維持しています。

時が経つにつれて、技術的に非常に多くの変化が起こり、世界はよりデジタルになり、ユーザー/顧客は数秒以内にデータにアクセスしたいと考えており、銀行やその他のサービスの従来の方法に移行する時間はありません. そのため、銀行やその他の業界はデジタル化への移行を余儀なくされています。

このデジタル ファストの世界では、メインフレームなどのレガシー システムからデータにアクセスすることは、顧客に高速なサービスを提供することが難しくなるため、クライアントはモダナイゼーションを求めています。

メインフレームのモダナイゼーションのために従うべき主なイニシアチブは次のとおりです。

  1. リエンジニアリング: クラウドやマイクロ サービスなどのデジタル プラットフォームへの破壊的な変革
  2. 再ホスティング: 資格のあるアプリケーションを、レガシー アーキテクチャとコードを保持する分散プラットフォームに再プラットフォーム化
  3. インプレースのモダナイゼーション: System z および System I のモダナイゼーション機能をレガシーに適切に組み合わせて活用
  4. 交換: 徹底的な適合分析を行った後、アプリケーションを適切な COTS 製品に交換します

このブログでは、リエンジニアリングのシナリオについて説明します。 このシナリオでは、フォワード エンジニアリング チームが要件ドキュメントとして使用するレガシー コードからビジネス ルールを抽出する必要があります。

メインフレーム コードをビジネス ルールに変換する方法

1. テンプレートの準備:

レガシー変換を開始するときはいつでも、最初の最大の課題は、既存のビジネス ロジックを理解し、それをフォワード エンジニアリング チームが理解してコーディング方法を思いつくことができる適切な形式にすることです。

テンプレートは、ビジネス ルールをまとめるための鍵となります。テンプレートが以下の内容を説明できる場合、それは役に立ちます。

  1. 以下を説明する必要があるジョブの概要 (JCL の概要) –
    1. 仕事の機能/説明
    2. ジョブで使用されるファイル (読み取り/書き込み)
    3. 使用される DB2 テーブル (プログラムごと)
    4. スケジュール情報
    5. ジョブフロー(おそらくツリー構造)
    6. 再開命令
  2. ビジネス ルール – 特定のプログラムの特定の機能に関連付けられたルールを説明する必要があります。
  3. レコード レイアウト – プログラムで使用されるレコード レイアウト/ファイル構造
  4. フィールド マッピング – ビジネス ロジック/プログラムでソースからターゲットへのマッピングがどのように行われたかを図または表形式で説明する必要があります。

2. ビジネスルールを書く:

コードを分析し、プログラムの論理フローを理解します。 各段落をルールとして記述しようとしないでください。必要に応じて、段落を組み合わせて、ビジネス ロジック/ルールを論理的な方法で作成する必要があります。

ビジネス ルールを作成する際には、以下の点を考慮する必要があります。

  • すべてのトランザクションとジョブをビジネス機能にマップする
  • ルールを取得したら、それらをレベル 4、レベル 3、レベル 2、レベル 1、およびレベル 0 にマップします。 レベル 0 が最も高く、レベル 1 から 4 の組み合わせで機能を実現します (例: 顧客のオンボーディングはレベル 0 になります)。
  • 見出し、小見出し – 見出しと小見出しは、ex のビジネス ルールを作成する際に非常に重要です。一般に、処理段落はコア ロジックを処理するために存在し、このセクション / 段落の下のすべての機能は小見出しとして表示され、全体を理解することができます。見出しと小見出しを見て、流れや論理を理解する。
  • 一時変数/作業領域変数 – Temp 変数の参照を必ず指定し、この変数を使用または参照するルール番号を記載してください。
  • IF 条件と EVALUATE ステートメント – IF 条件の古いプログラミング スタイルでは END-IF は言及されないため、必ず END-IF を言及し、ネストされた IF の場合は色を使用してください。 各条件を特定のルールに分割します。
  • PERFORM ループ – ループの開始時と終了時にループについて明確に言及する
  • 配列/テーブル – Arrays/Table の場合のすべての宣言と、それに関連する特定の関数の使用方法について言及します。
  • データベース- データベース関連のロジックを作成するときは、DECLARE CURSOR およびその他の SQL ステートメントをルールとして記述し、参照が必要な場所に参照を与えることをお勧めします。 ビジネス ルールにロジックを追加する際に、SQLCODE の意味を説明します。
  • エラー処理 – エラー処理が DISPLAY ステートメントと共に適切に文書化されていることを確認してください。
  • 一般的なルーチン – 共通ルーチン ルールは 1 つの共通シートまたはドキュメントに配置できるため、フォワード エンジニアリング チームはそれらを 1 回作成して使用できます。

フォワード エンジニアリング チームへのビジネス ルールの提示:

主な課題は、フォワード エンジニアリング チームにロジックをどれだけ効果的に説明できるかです。システムに関する知識を持っているテクニカル BA を取得できれば、幸運です! あなたがロジックを説明できれば、BA は理解してユースケースを思いつくことができます。

メインフレーム側からのより良い方法は、ジョブ レベルの非常に高レベルなフローを含むフロー ダイアグラムを作成することです。 フォワード エンジニアリング チームがフロー全体を理解しやすく、メインフレーム担当者がフローについて簡単に説明できるようにします。

すべてのロジックを BA とフォワード エンジニアリング チームに説明してください。 そして、低レベルの設計がフォワードエンジニアリング側で作成される場合は、独自の作業方法で。 それはチームにとって有益だろう。

ルールを Java に変換する:

メインフレーム COBOL を Java に変換するときは、COBOL と Java の違いを理解する必要があります。 まず、COBOL は手続き型言語であり、手順を順番に定義します。 一方、Java は OOP の概念に従うオブジェクト指向言語です。

COBOL に適したアプリケーションのタイプを検討してください。 COBOL という用語は、Common Business Oriented Language の頭字語です。 この言語は、レポート、数値計算、データ処理などのビジネス機能をサポートするように設計されています。 これは、COBOL が他のタイプの処理を実行できないという意味ではありません。 できる。 一部の種類のプログラムは、別の言語を使用してより適切に開発できる可能性があります。

Java は、多目的コンピューティングに適したオブジェクト指向プログラミング言語であり、複数のハードウェア プラットフォーム間で移植できるという追加の利点があります。 異なるコンピューターで同じプログラムを実行できる機能 (Java 仮想マシンがプラットフォームで利用可能な場合) は、Java が今日の新しい開発で最も人気のある言語の 1 つであることの理由の 1 つです。

COBOL コードを変換するために Java 側から実行する必要がある以下の考慮事項:

  1. クライアント環境ごとの Java コーディング標準を理解する
  2. COBOL と Java のデータ型の違い
  3. COBOL と Java の同等の機能。
  4. レガシーデータベース呼び出し (JPA または JDBC) の場合に Java で使用されるデータベース接続は?
  5. DB クエリに対して実行できるクエリの最適化はありますか?
  6. 可能な並列実行 (ステップ間) はありますか?
  7. DML 操作にチャンキング ロジックを実装できますか?
  8. 一般的なルーチン/サービスは、それらを作成して再利用する必要があります

.

Leave a Comment

Your email address will not be published. Required fields are marked *