AS/400刷新はRPG廃止と同じではない：既存資産の近代化と全面移行を比較する
AS/400の刷新を検討すると、「RPGを別の言語へ書き換える」という話から始まることがあります。しかし、保守の難しさの原因が、言語そのものにあるとは限りません。巨大なプログラム、分かりにくいデータ定義、複雑な呼び出し関係、再現できないテストやビルドが、変更を難しくしている可能性もあります。
刷新の選択肢には、既存環境を改善する方法と、別の基盤へ移す方法があります。どちらが適切かは、現在の問題と、将来の運用方針によって変わります。
本記事では、現在もAS/400という呼び方が使われる業務環境を含め、IBM iとそのRPG資産を対象に考えます。実際の対応では、稼働しているOS、RPGの世代、コンパイラー、適用済みの更新を確認します。
最初に、刷新したい対象を分ける
「AS/400を刷新する」という一言には、性質の異なる課題が含まれます。画面操作を改善したいのか、機能追加を速くしたいのか、保守要員を確保したいのか、基盤を統一したいのかを、切り分けて考える必要があります。
課題 | 既存環境で検討できる改善 | 別言語・別基盤への移行で検討すること |
ソースが読みにくい | フリーフォーマット化、命名・構造の整理 | 変換後コードの理解しやすさと保守方法 |
変更の影響が広い | 業務処理の分離、ILEによるモジュール化、テスト整備 | アプリ構造とデータ更新責任の再設計 |
DB処理が複雑・遅い | アクセス方法、索引、SQL、処理単位の見直し | データ変換、SQL方言、ロック、処理性能 |
画面・外部連携を改善したい | 業務機能のインターフェース化、画面と処理の分離 | 認証、API、画面、バッチを含む再構築 |
基盤・運用を統一したい | IBM iを維持する価値と運用負担を再評価 | 基盤移行に伴う互換性、運用、復旧の再設計 |
これらの方法は、どちらか一方を選ぶものとは限りません。既存処理を整理してから一部を移す、外部連携だけを先に整えるなど、段階的な組み合わせも考えられます。ただし、段階ごとに改善する課題と、残る課題を明示することが必要です。
フリーフォーマット化は、コードを読みやすくする入口
RPGには、従来の桁位置に依存する記述だけでなく、フリーフォーマットの記述もあります。IBMの資料では、先頭行の**FREEによって完全フリーフォーマットのソースを指定する方式が説明されています。固定形式の記述やコピーソースの扱いには条件があるため、資産の世代と記法を確認して進めます。
IBM「Fully free-form statements」(https://www.ibm.com/docs/en/i/7.5.0?topic=statements-fully-free-form)
書式を整理すれば、制御構造やデータ定義を読み取りやすくできます。しかし、同じプログラムに画面制御、計算、ファイル更新が混在しているなら、その構造上の問題は残ります。フリーフォーマット化と、責務の分離は別の作業です。
また、RPGの世代が異なる資産に対して、単に先頭行を書き換えるだけで対応できるわけではありません。変換が必要な部分、固定形式が残る部分、コンパイル条件、呼び出し元との互換性を調べます。
着手時には、処理結果を比較できるテストデータを用意し、まず振る舞いを変えずに書式を変更します。その後に構造を改善すれば、不一致が起きたときに原因を絞り込みやすくなります。
ILEによるモジュール化では、境界の設計が重要
ILEでは、モジュールやサービスプログラムを使って、処理を構成できます。サービスプログラムは、他のILEオブジェクトから利用する公開プロシージャなどを提供し、インターフェースの互換性を管理する仕組みを持ちます。
IBM「Service Program」(https://www.ibm.com/docs/en/i/7.5.0?topic=concepts-service-program)
ここで大切なのは、長いプログラムを機械的に分割することではありません。料金計算、受注検証、在庫更新など、意味のある業務単位を定め、入力・出力・エラー・更新責任を明確にすることです。
仮の例として、複数の画面がそれぞれ値引き計算を持っている場合を考えます。共通の計算処理を切り出すなら、適用日、契約条件、丸め方、例外の扱いをインターフェースに含めます。「顧客番号と金額だけ渡せばよい」と決めてしまうと、呼び出し元に暗黙的に含まれていた前提条件が抜け落ちる可能性があります。
公開インターフェースの変更、バインドの関係、活動化グループ、共有状態の有無も確認します。モジュール化によって変更範囲を限定できるようにするには、呼び出し側への影響を管理する必要があります。
DBアクセスの改善は、SQL化そのものを目的にしない
DBアクセスの見直しでは、RPGの処理だけでなく、物理ファイル、論理ファイル、DDS、索引、ロック、コミットの単位まで確認します。SQLで表現すると分かりやすい処理もあれば、現行のレコードアクセスを維持した方が変更範囲を抑えられる場合もあります。
IBMのモダナイゼーション資料も、画面・プログラム・データベースを含めた複数の改善方法を扱っています。DB改善を言語変更から切り離して検討するための参考になります。
IBM Redbooks「Modernizing IBM i Applications」(https://www.redbooks.ibm.com/redbooks/pdfs/sg248185.pdf)
注意したいのは、論理ファイルが持つ選択条件や読み出し順序を、単なるデータの格納形式と見なしてしまうことです。アクセス方法を変えれば、対象レコード、処理順、重複の扱い、更新競合の発生条件が変わる可能性があります。
性能の評価も、SQLへ書き換えたかどうかではなく、実データ量と実行条件に基づいて行います。対象処理の所要時間、読み取り量、待ち時間、他の業務への影響を測り、実行計画を確認します。IBMにはSQLの実行方法を可視化するVisual Explainなどの機能があります。
IBM「Visual Explain」(https://www.ibm.com/docs/en/i/7.4?topic=tools-visual-explain)
DDSからSQL DDLへの移行と、プログラムのDBアクセス方式の変更も、同じ作業ではありません。既存プログラムとの互換性を検証し、変更単位を分けて進めます。
別言語へ移す場合は、実行環境の意味も移す
別言語への移行が適しているのは、将来の開発体制、全社の基盤方針、連携要件などから、移行先に明確な価値がある場合です。ただし、言語を変えることと、基盤を変えることは分けて判断します。
検証対象は、構文の変換だけではありません。小数の精度と丸め、文字コード、ソート順、日付の扱い、ファイルのメンバー、ジョブの実行条件、権限、ロックやトランザクションの意味まで確認します。画面から呼ばれる処理が動いても、夜間バッチや障害時の再実行が同じように動くとは限りません。
自動変換を使う場合も、移行後のコードで代表的な業務変更を実際に試してみることが重要です。専用ランタイムが必要か、デバッグできるか、元ソースとの二重管理が発生するか、担当者が自力で変更できるかを評価します。
移行先の一般的な技術者を採用できても、固有の業務知識まで自動的に補えるわけではありません。業務ルール、テスト、運用手順の継承を、言語移行と同じ計画に含めます。
既存環境を残す場合も、改善の完了条件を置く
既存資産の活用は、問題の先送りにも、現実的な近代化にもなり得ます。その違いは、何を改善するかと、改善をどう確認するかにあります。
たとえば、対象機能の影響調査を短時間で行える、共通処理の変更をテストで検証できる、ソースから同じ成果物を再作成できる、業務担当者が例外ルールを説明できる、といった到達点を設定します。Gitなどによる変更管理やビルド手順の整備も、この到達点を支える要素になります。
一方、別基盤への全面移行でも、旧環境を廃止できる条件、データの正本、運用責任を決めなければ、複雑さが二つの環境に分散するだけになりかねません。
株式会社Managetechが重視するのは、RPGを残すか廃止するかを先に結論づけず、業務・アプリ構造・DB・運用のどこに問題があるかを見極めることです。既存環境を改善する価値と、別基盤へ移す価値を同じ条件で比較し、検証結果に基づいて範囲を決めます。
AS/400刷新の検討では、まず「今後も生かしたい業務資産」と「現在の変更を難しくしている要因」を分けて整理してみてください。そこから、全面移行を含む適切な選択肢が見えてきます。
コメント