top of page
検索

RPGだけ調べても移行できない：CL・DDS・DBの依存関係から移行範囲を決める

izwxinc
5 時間前
読了時間: 7分

RPGのソースを解析し、画面と帳票を一覧にすれば、移行範囲を把握できるでしょうか。IBM iの業務システムでは、それだけでは不足する場合があります。

CLは、どのプログラムを、どの順序で、どのファイルに対して実行するかを制御します。論理ファイルは対象レコードを絞り込み、トリガーはデータ更新をきっかけに別の処理を起動します。こうした構造では、一つのRPGを移しても、業務全体を移したことにはなりません。

現行調査の対象は、プログラムの本数だけでなく、業務の入口、処理の呼び出し、データの読み書き、運用上の実行条件まで広げる必要があります。

表面のコードだけでなく、実行とデータを支える依存関係までたどります。
表面のコードだけでなく、実行とデータを支える依存関係までたどります。

「請求処理」という名前のプログラムだけでは、請求業務は分からない


仮の例として、月次請求の処理を考えます。スケジューラーからCLが起動し、CLが実行対象のライブラリーやファイルを設定したうえで、複数のRPGを呼び出す構成です。


RPGは、論理ファイルを使って未請求の取引を読み、物理ファイルを更新します。その更新を契機にトリガーが履歴を記録し、後続の処理が請求書を出力して、外部システムへデータを渡します。


このとき、請求金額の計算部分だけを新しい言語へ移しても、次のような機能が抜ける可能性があります。


  • 未請求データだけを対象にする条件

  • 会社や処理月に応じてファイルを切り替える仕組み

  • 履歴の記録、処理済み状態の更新、再実行の判定

  • 帳票の出力条件と、外部への送信順序


移行対象は、名前に「請求」と付くプログラムの集合ではなく、請求という業務結果を成立させる処理とデータの集合として捉えます。


RPG・CL・DDS・DBを、役割ごとに横断する


調査対象

主に確認すること

移行で抜けやすい点

RPG・コピーソース

計算、分岐、ファイル入出力、呼び出し、共通定義

共通ソース、実行時に変わる呼び出し先、暗黙の前提

CL

起動順序、パラメーター、エラー処理、環境設定

OVRDBF、ライブラリーリスト、再実行の制御

DDS

レコード形式、項目、キー、選択・除外、画面・帳票の定義

データ選別や入出力の意味が定義側にあること

物理ファイル・論理ファイル

データの格納先、参照関係、アクセス経路、メンバー

同名ファイルの区別、共有データ、読み出し順序

SQLオブジェクト・トリガー

テーブル、ビュー、ルーチン、制約、更新を契機とする処理

プログラムから明示的に呼ばれない処理

ILEの構成要素

モジュール、サービスプログラム、バインドの関係

公開プロシージャの変更が呼び出し側へ与える影響

ジョブ・周辺連携

スケジュール、実行ユーザー、キュー、帳票・ファイル転送

プログラムの外にある起動条件と業務のつながり

データエリア、データキュー、作業用ライブラリー、一時ファイルなども、実際に使われていれば調査の対象です。すべてを同じ深さで調べるのではなく、重要業務との関係から優先順位を付けます。


依存関係は、三つの向きから見る


最初は、起動元から下流へたどります。メニュー、スケジューラー、外部要求を入口に、呼び出す処理、更新するデータ、出力・送信先を追います。これは、業務がどう成立しているかを知るための調査です。


次に、データから利用者へ逆向きにたどります。あるファイルを変更する場合、どのプログラム、帳票、問い合わせ、外部連携が影響を受けるかを調べます。RPGの呼び出し関係だけを見ていると、複数の業務が同じファイルを直接更新する関係を見落とします。


最後に、運用の時間軸を重ねます。同じデータでも、日中、夜間、月末、年度末で利用する処理が変わる場合があります。直近の実行ログに現れないことだけを理由に、年次処理や障害復旧用の機能を不要と判定しないようにします。


この三つを重ねると、機能単位では独立して見えた業務が、共有データや実行順序で結び付いていることが分かります。


標準コマンドは有効だが、一つで全体は分からない


IBM iには、参照やファイル間の関係を確認するためのコマンドがあります。結果を資産台帳に取り込み、ソース解析や稼働実態と組み合わせて使います。


手段

得られる情報

補うべき調査

DSPPGMREF

プログラムが参照するファイルやプログラムなど

作成・更新時の参照情報と、実行時の対象が一致するか

DSPDBR

物理・論理ファイルなどのデータ共有や依存関係

どの業務が何の目的で利用するか

DSPFDのトリガー情報

ファイルに関連付いたトリガー

トリガー内の処理、連鎖する更新、実行条件

DSPSRVPGMなど

サービスプログラムの公開情報など

呼び出し側、バインド、互換性への影響

ソースとジョブの調査

パラメーター、環境設定、処理順、稼働の証跡

未観測の月次・年次・障害時処理

DSPPGMREFで得られるのは、オブジェクトの作成・更新時点の参照情報です。IBMは、移動やオーバーライドなどにより、記録された名前・ライブラリーと実際の対象が異なる場合があることを説明しています。したがって、取得結果をそのまま「本番で参照する全対象」と見なすことはできません。


ファイルの関係にはDSPDBR、登録されたトリガーにはDSPFDのTYPE(*TRG)などを使えます。ただし、それぞれのコマンドで分かるのは異なる範囲です。必要な権限と対象リリースの仕様を確認し、取得できなかった情報も記録します。


サービスプログラムについては、公開プロシージャと呼び出し側を併せて把握します。IBMの資料では、DSPSRVPGMによる公開情報の確認方法も説明されています。


動的な参照と、定義側のルールを見落とさない


ソースを静的に読むだけでは、参照先が確定しない場合があります。変数で指定する呼び出し先、ライブラリーリストによる名前解決、実行時に組み立てるSQL、ファイルのオーバーライドなどがその例です。


OVRDBFは、プログラムが使うファイルやその属性を変更するためのコマンドです。ソースに書かれたファイル名だけを見て実際のデータの所在を判断すると、会社別・処理別に切り替えられた参照先を見落とす可能性があります。


また、論理ファイルには、レコードの選択・除外条件が定義されている場合があります。RPGに条件式が見当たらなくても、読み込む対象を定義側で制御している可能性があるということです。別のDBやSQLへ移す際は、その意味を引き継ぐ必要があります。

IBM「DDSの選択・除外フィールド」(https://www.ibm.com/docs/en/i/7.4.0?topic=28-selectomit-field-name)


同名オブジェクトが別ライブラリーにある場合は、名前だけで同一と判断しません。ライブラリー、オブジェクト種別、必要ならメンバーまで識別し、本番オブジェクトと対応するソース、コンパイル条件を照合します。「ソースはあるが本番と一致しているか分からない」状態も、独立した調査課題です。


調査結果を、移行単位とテストへ変換する


依存関係図を作るだけでは、移行計画は決まりません。分かった関係を使って、次の判断を行います。


  1. 同時に移す必要がある処理をまとめる。同じ取引を一体で確定する処理や、密接に依存する更新は、分割の可否を慎重に検討します。

  2. 境界に残る関係を設計する。 新旧で共有するデータについて、更新責任、連携方式、エラー時の復旧を決めます。

  3. 代表的な業務経路をテストにする。 入口から帳票・外部連携まで、途中状態と例外を含めて検証します。

  4. 廃止候補の根拠を確認する。静的な未参照、一定期間の未実行、業務責任者の確認を組み合わせます。


テストでは、正常な計算結果だけでなく、対象レコードの選び方、更新順、ロック待ち、途中失敗、再実行後の履歴まで確認します。移行単位に含まれない周辺機能への影響も、受入条件に含めます。


調査台帳には、関係の「有・無」だけでなく、確認方法と確度を残します。静的に確認できた関係、稼働ログで観測した関係、担当者が説明した関係、未確認の候補を区別すると、移行判定に使いやすくなります。


移行範囲は、動かせる単位で合意する


RPGの本数や行数は、作業量を把握するための材料です。しかし、それだけでは、連携、データ変換、運用変更、テストの難しさを評価できません。少数のプログラムでも、共有ファイルや多数の外部連携に依存していれば、影響範囲は広くなります。


株式会社Managetechが現行調査で重視するのは、資産を列挙することと、業務として動く範囲を明らかにすることをつなげる視点です。呼び出し、データ、実行条件を横断して確認し、どこまで移せば業務が成立するか、何が旧環境に残るかを説明できる状態を目指します。


移行の見積もりを固める前に、重要な業務を一つ選び、起動元から更新データ、帳票、外部連携までたどってみてください。その調査で見つかる依存関係から、必要な移行範囲と検証すべきリスクが具体的に見えてきます。

 
 
 

コメント

©2026 by Managetech inc.

bottom of page