AS400のRPG保守で最初に見るポイント｜言語の特徴と読み方を解説

RPGは、AS400（IBM i）の業務プログラムで広く使われてきたプログラミング言語です。販売管理、在庫管理、生産管理、請求処理など、会社の基幹業務を動かす処理に多く使われています。

名前だけ見るとゲーム制作のRPGと混同しそうですが、AS400でいうRPGは「Report Program Generator」に由来する業務処理向け言語です。現在はRPG IVやフリーフォームRPGとして、昔より読みやすい書き方もできます。

RPGでできること

• データベースファイルの読込、追加、更新、削除
• 受注、出荷、在庫、請求などの業務ロジック実装
• 帳票やスプール出力
• 画面ファイルを使った5250画面処理
• CLや他のRPGプログラムとの連携

RPGの特徴

1. ファイル処理に強い

RPGは、DB2上の物理ファイルや論理ファイルを直接扱う処理と相性が良い言語です。キーを指定して CHAIN、順番に読む READ、同一キーで読む READE、更新する UPDATE など、業務データを扱う命令が多く使われます。

2. 固定形式のソースが多い

古いRPGは桁位置に意味がある固定形式で書かれています。最初は読みづらく感じますが、F仕様、D仕様、C仕様の役割を覚えると、どこにファイル定義があり、どこに変数があり、どこに処理があるかを追いやすくなります。

3. 最近はフリーフォームも使える

新しいRPGでは、**free から始まるフリーフォーム記述が使えます。C言語やJavaScriptのように、比較的自然な書き方で処理を書けるため、新規開発や改修ではフリーフォーム化する現場もあります。

保守でよく見る命令

RPGを読むときの順番

1. F仕様で使用ファイルを確認する
2. *ENTRY PLISTで入力パラメータを確認する
3. 最初に実行されるメイン処理を探す
4. EXSRとCALLを追い、処理の流れを整理する
5. WRITE、UPDATE、DELETEがある箇所を重点的に見る

RPGを読むには、AS400のファイルやライブラリの考え方も必要です。あわせてAS400のライブラリの記事も確認しておくと、ソースやオブジェクトの場所を理解しやすくなります。

まとめ

RPGは古い言語と思われがちですが、AS400の基幹業務では今も重要です。保守では、命令の細かい文法だけでなく、どのファイルを読み、どの条件で更新し、どの外部プログラムへ渡しているかを見ることが大切です。

RPGを読むときの実務メモ

RPGは最初に文法だけを覚えようとすると難しく感じます。保守では、画面や帳票で起きている現象から、どのファイルを読み、どの条件で分岐し、どこで更新しているかを追うことが大切です。

• 入力ファイル、出力ファイル、更新ファイルを先に確認する
• キー項目と検索条件をメモする
• エラー時はジョブログとメッセージIDを先に見る
• 古い固定形式のソースでは桁位置と命令コードに注意する

よくある質問

RPGは古い言語なので覚えなくてもよいですか？

新規開発だけを見ると触れる機会は少ないかもしれませんが、AS400の既存資産を保守する現場では今でも重要です。最低限、ファイル処理、条件分岐、サブルーチン、エラー処理の読み方は押さえておくと調査が進めやすくなります。

このサイトの運営方針は、このサイトについて にまとめています。

私がRPGを分かりやすいと感じた理由

私がAS400 / IBM i のRPGを学んだ時に分かりやすいと感じたのは、RPGだけではありません。DDSで定義する物理ファイル、論理ファイルも含めて、全体として理解しやすいと感じました。

これは言葉だけで説明するのが少し難しいところです。C言語、VB、RPGなど、いくつかの言語を触ってみると違いが分かりやすいと思います。私の場合は、C言語やVBも触りましたが、やはりRPGが一番分かりやすかったです。

AS400の業務システムでは、プログラムだけを見ても全体像はつかめません。DDSでファイルがどう定義されているか、RPGでそのファイルをどう読んでいるか、CLからどの順番で呼ばれているか。ここがつながって見えると、保守はかなりやりやすくなります。

RPG初心者が最初につまずきやすいところ

RPGそのものより、最初につまずきやすいのは、あの独特のレトロなエディターでプログラム開発するところかもしれません。今どきの開発環境に慣れている人ほど、最初は古く見えると思います。

ただ、これは慣れます。最初は見た目で拒否反応が出ても、F仕様、D仕様、C仕様、サブルーチン、ファイル定義の関係が見えてくると、少しずつ読めるようになります。見た目が古いことと、保守しにくいことは同じではありません。

RPG保守で最初に見るところ

RPG保守で最初に見るところを一つ挙げるなら、私はまずF仕様を見ます。どのファイルを使っているのか、入力なのか更新なのか、どのライブラリーやファイル定義と関係しているのかを確認します。

ただし、F仕様だけを見ればよいわけではありません。結局は全体を見ます。ファイル定義、変数、配列、サブルーチン、CALL関係、CLからの呼び出し、前後処理まで確認して、初めて安全に修正できます。

販売管理システムでは、RPGは一部だけではなく、ほとんど全部に関わります。受注、出荷、在庫、売上、請求、帳票、バッチ処理など、基幹処理の中心にRPGがある現場も多いです。

RPG修正で怖いのは配列数の見落とし

RPGの修正で危ないと思う作業の一つが、配列の扱いです。よくあるのが、配列の定義数が少なすぎて、いつか配列数を超えるデータが入った時にプログラムがアベンドするパターンです。

* 例: 想定件数より配列定義が少ない
D ARR             S             10A   DIM(100)

* 101件目以降が来た時にどうなるかを考える

開発時のテストデータでは100件以内だったとしても、本番ではそれを超えることがあります。特に販売管理では、店舗数、明細数、出荷件数、請求明細など、データ量が増える要素はいくらでもあります。

配列を修正する時は、単に定義数を増やせば終わりではありません。どこでカウントしているか、上限チェックがあるか、超えた時にどう処理するか、テストデータで上限超過を確認したか。そこまで見る必要があります。

RPG保守ではF仕様書だけで終わらせない

RPG保守で最初に見る場所を聞かれたら、私はまずF仕様書を見ます。ただし、そこで終わりではありません。ファイルの定義、処理順、配列、外部サブルーチン、CLからの呼び出しまで、結局は全体を見ることになります。

販売管理システムでは、RPGは受注、出荷、在庫、売上、請求など、ほぼ全体に関わります。小さな修正でも、後続処理や帳票、外部連携に影響することがあります。

RPGは書き方がシンプルで読みやすい面がありますが、業務の流れを知らないと安全に直せません。プログラムだけでなく、何の業務を支えているかを理解することが大事です。