IBM i のウンチクを語ろう：その117
－ IBM Bobベータ版に触ってみた -2 －
皆さん、こんにちは。前回はBobがライブラリ・ファイル・システム内にあるRPGⅢソース・プログラムに直接アクセスできるようになるところまで進みました。このコラムを読んでくださっている方々の間では、新規のアプリケーション開発よりも、既存アプリケーションをどのようにして保守・改修するべきかという点、言い換えるとモダナイゼーション（現代化）の方が差し迫った課題ではないでしょうか。実は開発部門も、新規プロジェクトよりもモダナイゼーションの方を重視する姿勢を示していたことを憶えています。そこで今回は読み取れるようになったプログラムを対象に、「アプリケーション編」として、Bobを活かした分析・変換にチャレンジしたいと思います。
アプリケーション編
アクセスできたRPGⅢプログラムAOP140のBobによる説明は以下（一部省略）のとおりです。プロンプトとして私が入力したのは、「AOP140を説明してください」という極めてシンプルなものでした。私自身はこの妥当性を評価することはできませんが、いきなりソースコードを読み込むよりは、かなり作業を効率化できるのではないかと思います。
QEOL/AOP140 RPGプログラムの説明
プログラム概要
AOP140は、出荷伝票入力システムのRPG IIIプログラムです。画面(WORKSTN)を使用して、商品の出荷情報を入力・表示する対話型プログラムです。
主要機能
1. 画面定義 (FAOP140S)
- ワークステーションファイル(WORKSTN)を使用
- 画面フォーマット: PANEL01
2. データ構造
マスタデータ配列 (各5要素)
- BMAS: 品番マスタ (6桁)
- MMAS: 品名マスタ (20桁)
- TMAS: 単価マスタ (6桁、数値)
- SMAS: 数量マスタ (6桁、数値)
- KMAS: 金額マスタ (7桁、数値)
（データ構造以下省略）
3．初期設定
- 伝票番号: '00010'
- 得意先: 青木商事（株）
- 種類: 'ｿｳﾑﾌﾞ' (総務部)
- 摘要: '緊急'
- 合計金額: 14,500円
4. 主要処理フロー
メインループ (DO *HIVAL)
1．画面表示 (EXFMT PANEL01)
- F3キー(*IN03)または確定(*IN30)で終了
2. 入力チェック
- 得意先コード検証 (*IN41)
- 種類コード検証 (*IN42)
- 摘要検証 (*IN43: '緊急'または'ｷﾝｷｭｳ'のみ許可)
3. 明細行処理 (5行分ループ)
各行について:
- 品番がマスタと一致する場合
- 品名、単価をマスタから設定
- IN5フラグ = '0' (変更なし)
- 品番が不一致の場合
- 品名、単価をクリア
- IN5フラグ = '1' (変更あり)
- 数量がマスタと一致する場合
- IN6フラグ = '0' (変更なし)
- 数量が不一致の場合
- IN6フラグ = '1' (変更あり)
- 金額計算
- 変更がない場合(IN5='0' AND IN6='0')のみマスタ金額を設定
（以下、メインループの「4. 合計金額計算」と「5. 確定判定」は省略）
5. テストデータ
プログラムには以下のテストデータが含まれています:
| 品番 | 品名 | 単価 | 数量 | 金額 |
|---|---|---|---|---|
| 100100 | ノート（A4） | 100円 | 10個 | 1,000円 |
| 100200 | バインダー（小） | 300円 | 20個 | 6,000円 |
| 100300 | 鉛筆（HB） | 100円 | 15個 | 1,500円 |
| 100400 | ボールペン（黒） | 200円 | 30個 | 6,000円 |
合計: 14,500円
プログラムの特徴
- RPG III形式の固定形式コード
- 配列を使用した5行の明細処理
- マスタデータとの照合機能
- 変更検知機能
- リアルタイム入力チェック
- IBM著作権表示 (1988年)
使用目的
事務用品などの出荷伝票を入力し、マスタデータと照合しながら金額計算を行う業務システムの一部として機能します。
ここでRPGⅢアプリケーションを保守するための人材が不足していると想定して、次のように素朴な疑問を投げ掛けてみます。
| 私 | CとかPythonしか知らない若手プログラマにとって、このプログラムを理解するのは難しいです。保守性を高めるために変換できればと思うのですが、どの言語をターゲットにするのが良いですか。 |
元のプログラムがRPGⅢで記述されていることを考慮すると、開発部門が常々主張しているのはフリーフォームRPGとSQLの組み合わせであるはずなのですが、必ずしもIBM i に特化していないBobの回答は期待とは異なるものでした。現行RPGⅢプログラムからの変換であることをあまり考慮せず、若手プログラマにとって受け入れられやすい言語であることを最も重視したのでしょう。だからと言って回答の冒頭に「RPGⅢプログラムの現代化」とあるので、前提を忘れたわけではないようです。Bobはアプリケーション開発におけるAIパートナーではありますが、ITの方針策定についての相談相手になるには、もう少し「研鑽」を積んでもらいたいと思った次第です。
| Bob | 若手プログラマーの保守性を考慮した場合の最適な変換先言語について提案いたします。 |
RPGⅢプログラムの現代化- 推奨言語の提案
推奨順位と理由
1位: Python（最推奨）
メリット
・学習コストが最も低い - C/Python経験者なら即座に理解可能
・可読性が高い - インデントベースで構造が明確
・豊富なフレームワーク - Flask/Django/FastAPIで簡単にWeb化
・データ処理に強い - pandas, numpy等でマスタデータ処理が容易
・クロスプラットフォーム - Windows/Linux/Mac対応
・保守性が高い - コードが短く、テストも書きやすい
変換イメージ
# RPGのDOループ → Pythonのfor文
for i, item in enumerate(items):
if item["hinban"] == master[i]["hinban"]:
item["kingaku"] = item["tanka"] * item["suryo"]
（以降のソースコード省略）適用シナリオ
・Webアプリ化: Flask + HTML/CSS/JavaScriptで画面作成
・REST API化: FastAPIでマイクロサービス化
・バッチ処理: スクリプトとして実行
（以下2位: TypeScript + Noode.js、3位: Java（Spring Boot）、4位: Go言語について同様の説明が続く）
具体的な推奨プラン
短期的アプローチ（3-6ヶ月）:
Python + Flask + SQLite
・最も早く移行可能
・若手が即座に理解・保守できる
・プロトタイプとして動作確認
中長期的アプローチ（6-12ヶ月）:
・TypeScript + React + Node.js + PostgreSQL
・モダンなWebアプリケーション
・フロントエンド/バックエンド分離
・スケーラブルな設計
エンタープライズアプローチ (12ヶ月以上):
Java (Spring Boot) + React + Oracle/PostgreSQL
・大規模システム向け
・既存のIBM i システムとの連携
・長期保守を見据えた設計
| 項目 | Python | TypeScript | Java | Go |
|---|---|---|---|---|
| 学習コスト | ★★★★★ | ★★★★ | ★★★ | ★★★★ |
| 開発速度 | ★★★★★ | ★★★★ | ★★★ | ★★★★ |
| 保守性 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ |
| 実行速度 | ★★★ | ★★★★ | ★★★★★ | ★★★★★ |
| Web開発 | ★★★★★ | ★★★★★ | ★★★★ | ★★★ |
| IBM i連携 | ★★★ | ★★★ | ★★★★★ | ★★★ |
最終推奨
ベストチョイス：Python + Flask/FastAPI
理由：
1．若手の即戦力化 - C/Python経験者なら1週間で理解可能
2．開発効率 - RPGの1/3〜1/5のコード量で実装可能
3．段階的移行 - 画面単位で少しずつ移行できる
4．将来性 - AI/機械学習への拡張も容易
次のステップ: AOP140プログラムをPythonに変換したサンプルコードを作成しましょうか？
・Flask版 (Webアプリ)
・FastAPI版 (REST API)
・コンソール版 (バッチ処理)
どれがご希望ですか？
星取表の星の数とかその理由など詳細まではわかりませんが、ここに挙げられた各言語の評価としては、概ね妥当なところなのかもしれません。特に学習コスト、新たに学ぶ上でのハードルが低いこと、という観点ではPythonが最も優れると評価されているのは理解できます。私が講師を務めたことのある大学のIT系学部では、最初に学生に教えるプログラム言語はPythonだと聞いたことがありますし、Tiobeサイトによると、数多あるプログラム言語の中でPythonはダントツの人気を誇っています。私自身も手軽に使えそうな言語だな、という印象を持っています。
RPGの最大の特徴の一つであるアプリケーション資産の継承性が失われたり、パフォーマンスが劣化するリスクに直面したりする可能性はありますが、ここは敢えて定石と実用性を度外視してPythonに変換するようBobに依頼してみます。フリーフォームRPGへと変換するのが王道ではありますが、技術的に本当に実現可能なのか試してみたいというのが最大の理由です。そしてBobが提示した選択肢の中では、変換後プログラムにシンプルさを求めたいので、バッチ処理を想定することにします。
| 私 | バッチ処理を前提とする Python に変換してください |
| Bob | バッチ処理を前提としたPythonプログラムに変換いたします。 IBM Bobは新しいファイルを作成したい: C:\Users\masakatsu.yasui\Desktop\AOP140.py |
以下に生成されたPythonプログラムの冒頭部を添付します。
import sys
from dataclasses import dataclass
from typing import List, Optional
import json
@dataclass
class Item:
"""商品明細データクラス"""
hinban: str = "" # 品番 (6桁)
hinmei: str = "" # 品名 (20桁)
tanka: int = 0 # 単価 (6桁)
suryo: int = 0 # 数量 (6桁)
kingaku: int = 0 # 金額 (7桁)
in5: str = "0" # 品番・品名・単価変更フラグ
in6: str = "0" # 数量変更フラグ
（以降マスターデータクラス、伝票データクラスは省略）
class AOP140Processor:
"""AOP140バッチ処理クラス"""
def __init__(self):
"""初期化"""
# マスタデータの初期化 (RPGのBMAS, MMAS, TMAS, SMAS, KMAS相当)
self.master_data: List[MasterItem] = [
MasterItem("100100", "ノート （Ａ４）", 100, 10, 1000),
MasterItem("100200", "バインダー （小）", 300, 20, 6000),
MasterItem("100300", "鉛筆 （ＨＢ）", 100, 15, 1500),
MasterItem("100400", "ボールペン （黒）", 200, 30, 6000),
MasterItem("", "", 0, 0, 0), # 5行目は空
]
（以降省略）私は何も指示しませんでしたが、Bobは生成したプログラムを自主的に見直し、エラーを修正したいと申し出ます。プログラムを作りっぱなしにしないのは良い心掛けですね。
| Bob | 型エラーを修正します。 IBM Bobはこのファイルを編集したい: C:\Users\masakatsu.yasui\Desktop\AOP140.py |
Bobは、以下のように修正箇所と修正前後のプログラム部分を提示してくれますので、必要であればその妥当性を事前に確認することができます。
<<<<<<< SEARCH
:start_line: 44
-------
@dataclass
class DenpyoData:
"""伝票データクラス"""
banmas: str = "00010" # 伝票番号
tokmas: str = "青木商事（株）" # 得意先
shumas: str = "ｿｳﾑﾌﾞ" # 種類
tekmas: str = "緊急" # 摘要
gokmas: int = 14500 # 合計金額
items: List[Item] = None # 明細行(5行)
def __post_init__(self):
if self.items is None:
self.items = [Item() for _ in range(5)]
=======
@dataclass
class DenpyoData:
"""伝票データクラス"""
banmas: str = "00010" # 伝票番号
tokmas: str = "青木商事（株）" # 得意先
shumas: str = "ｿｳﾑﾌﾞ" # 種類
tekmas: str = "緊急" # 摘要
gokmas: int = 14500 # 合計金額
items: Optional[List[Item]] = None # 明細行(5行)
def __post_init__(self):
if self.items is None:
self.items = [Item() for _ in range(5)]
>>>>>>> REPLACEさらにBobから型チェックの問題を修正したいという申し出がありました。型アサーションを追加するとは何を意味するのか理解できていませんが、自分で調べて理解するのに時間を投じるよりも、Bobに委ねてしまった方が早いのは間違いありません。先の場合と同様に、Bobは修正箇所と修正前後のプログラム部分を示しながら、プログラムを編集する許可を求めてきますので、そのまま先に進むことにします。
| Bob | 型チェックの問題を修正します。 __post_init__で必ず初期化されるため、型アサーションを追加します。 IBM Bobはこのファイルを編集したい: C:\Users\masakatsu.yasui\Desktop\AOP140.py |
生成AIによる生産性向上は必ずしも良いことばかりではなく、人がノウハウを習得する機会を放棄することにもつながるようです。入社したての新人が早く仕事を仕上げるために、すぐに何でも先輩社員に聞いてしまうのに似ています。先輩社員と違って、同じ質問を何度繰り返したところで生成AIは怒らないし、自力で考えなさいと突き放すこともありません。私の場合はPythonのプログラミングをこれから生業にする可能性は限りなくゼロに近いので、Bobに依存するので問題無いでしょう。これからPythonプログラマとして自立しようとしている方は、一旦は自力で考えてみて、その後にBobと答え合わせするのが良いのではないかと思います。
蛇足ですが、後で型アサーションとは何なのかを調べてみました。データ型を推定する機能が備わっているTypeScriptなどのプログラム言語において、推定される型を上書きする機能なのだそうです。厳密には違いますが、機能的にはC言語のキャストに近い印象です。プログラムのエラー防止に役立ちそうです。
| Bob | 型エラーが解消されました。次に、使用方法を説明するREADMEファイルを作成します。 IBM Bobは新しいファイルを作成したい: C:\Users\masakatsu.yasui\Desktop\README_AOP140.md |
何もBobに依頼していないのですが、新たなプログラムを生成したら自主的にドキュメントを生成する、という姿勢には感心しますね。
どのようなドキュメントが生成されたのか、全体行数は330に及ぶので、ここではその一部のみを抜粋します。ちなみにドキュメントの形式はマークダウン、ファイルの拡張子は「md」です。実際の文書の見栄えは、以下とは少々異なることをご了承ください。
| Bob | 概要 IBM i (AS/400) のRPG IIIプログラム `AOP140` をPythonに変換したバッチ処理プログラムです。 出荷伝票の入力・検証・金額計算を行います。 |
| RPG要素 | Python要素 | 説明 |
| `FAOP140S CF E WORKSTN` | `AOP140Processor` クラス | メイン処理クラス |
| `BMAS, MMAS, TMAS, | `master_data: | マスタデータ配列 |
| SMAS, KMAS` | List[MasterItem]` | |
| `HINB, HINM, TANK, SURY, KING` | `Item` データクラス | 明細行データ |
| `DS` (データ構造) | `@dataclass` | データクラスで表現 |
| `DO *HIVAL` | `process()` メソッド | メインループ |
| `EXFMT PANEL01` | `process(input_data)` | 入力データ処理 |
| `*IN03, *IN30, *IN41-43` | `in30, in41-43` フラグ | 制御フラグ |
| `XFOOT` | `sum()` 関数 | 配列の合計 |
（以下、必要な環境などを省略）
処理ロジック
1. 入力検証
- 得意先コード: 伝票番号と一致する必要がある
- 種類コード: "ｿｳﾑﾌﾞ"固定
- 摘要: "緊急"または"ｷﾝｷｭｳ"のみ許可
2. 明細行処理（各行について）
-1. 品番チェック
- マスタと一致 → 品名・単価をマスタから取得、`in5="0"`
- マスタと不一致 → 品名・単価をクリア、`in5="1"`
-2. 数量チェック
- マスタと一致 → `in6="0"`
- マスタと不一致 → `in6="1"`
-3. 金額計算
- `in5="0"` かつ `in6="0"` の場合のみマスタ金額を設定
- それ以外は金額=0
3. 合計金額計算
- 全明細行で変更がない場合（`in5`と`in6`が全て"0"）
→ 合計金額 = 14,500円（マスタ合計）
- 変更がある場合
→ 合計金額 = 0
4. 確定判定
以下の条件をすべて満たす場合のみ確定可能：
- 得意先エラーなし (`in41=False`)
- 種類エラーなし (`in42=False`)
- 摘要エラーなし (`in43=False`)
- 品番・単価変更なし (全行で`in5="0"`)
- 数量変更なし (全行で`in6="0"`)
（途中省略）
| 項目 | RPGⅢ | Python |
| 配列 | 固定長配列 | リスト（可変長） |
| データ型 | 固定長文字列、パック10進数 | str, int（可変長） |
| 制御構造 | `DO`, `IF`, `GOTO` | `for`, `if`, 関数 |
| 画面制御 | EXFMT` (画面フォーマット) | 辞書による入出力 |
| エラー処理 | インジケータ (`*IN41`) | ブール変数 (`self.in41`) |
| データ構造 | `DS` (Data Structure) | `@dataclass` |
| ファイルI/O | `F仕様書` | 関数引数/戻り値 |
（以下「カスタマイズ方法」などは省略）
引き続きBobはテストを実施する旨を申し出ます。
| Bob | プログラムが正しく動作するか実行してテストします。 コマンド実行: C:\Users\masakatsu.yasui\AppData\Local\Microsoft\WindowsApps\python.exe aop140.py |
実行中に文字化けが生じてしまったようです。生成されたユニコード文字がWindowsのコードページ932、すなわちシフトJISでは処理できないといったメッセージが出ていました。（'cp932' codec can't encode character '\u2713'）上記同様に、Bobは修正箇所を提示しながら再度プログラムを修正し、実行します。
| Bob | Windowsのコンソールでユニコード文字（✓）が表示できないエラーが発生しました。修正します。 IBM Bobはこのファイルを編集したい： C:/Users/masakatsu.yasui/Desktop/aop140.py 再度プログラムを実行します。 コマンド実行： C:\Users\masakatsu.yasui\AppData\Local\Microsoft\WindowsApps\python.exe aop140.py |
プログラム実行結果が表示されますが、日本語は相変わらず文字化けしています。ただBobは今度はUTF-8というユニコード形式で文字情報を受け取れば問題無いと判断しました。出力内容を確認するために、一旦output.txtファイルに吐き出す手順を追加しています。
| Bob | 素晴らしい！プログラムが正常に実行されました。 日本語が文字化けしていますが、これはWindowsコンソールのエンコーディングの問題です。 プログラムのロジックは完全に動作しています。UTF-8で正しく表示されるように、出力をファイルにリダイレクトして確認してみます。 コマンド実行： C:\Users\masakatsu.yasui\AppData\Local\Microsoft\WindowsApps\python.exe aop140.py > output.txt 2>&1 && type output.txt プログラムは正常に動作しています！実行結果を分析して、テスト結果のサマリーを作成します。 |
成功裏に実行できたものとして、Bobは3つのテストケースを示した上でその判定理由を出力します。根拠無く「素晴らしい！」と言っているわけではないということですね。
AOP140 Pythonプログラム実行成功！
実行結果サマリー
プログラムは完全に正常動作しました。3つのテストケースすべてが期待通りの結果を出力しています。
テストケース実行結果
テストケース1:正常系（マスタデータと完全一致）
ステータス： success
合計金額： 14,500円
確定： [OK] 確定可能
詳細
・全5行の品番・数量がマスタと完全一致
・変更フラグ: すべて "0" (変更なし)
・エラー: なし
・金額計算: 正確に合計14,500円
（以下「テストケース2:数量変更あり」、「テストケース3:品番不一致」と続く）
| 項目 | 結果 | 詳細 |
| プログラム起動 | ✔ | エラーなく起動 |
| マスタデータ読込 | ✔ | 5行のマスタデータ正常読込 |
| 入力検証 | ✔ | 得意先・種類・摘要の検証動作 |
| 品番照合 | ✔ | マスタとの照合正常動作 |
| 数量照合 | ✔ | マスタとの照合正常動作 |
| 変更検知 | ✔ | in5 / in6フラグ正常動作 |
| 金額計算 | ✔ | 変更なし時のみ金額設定 |
| 合計計算 | ✔ | 変更有無による分岐正常 |
| 確定判定 | ✔ | エラー・変更の総合判定正常 |
| JSON出力 | ✔ | 構造化データ正常出力 |
RPGⅢをPythonに変換するに際して、Bobは何がポイントになったのかを解説してくれます。
RPG → Python 変換の成功ポイント
1. ロジックの完全再現
RPGの複雑な条件分岐をPythonで正確に再現
・DO/IF/ANDEQなどの制御構造を適切に変換
・インジケータ(*IN41-43, *IN30-31)をブール変数で実装
2. データ構造の最適化
・固定長配列 → Pythonのリスト
・データ構造(DS) → dataclass
・5要素の配列処理を正確に実装
3. エラーハンドリング
・3種類の入力検証（得意先・種類・摘要）
・品番・数量の変更検知
・確定可否の総合判定
4. 出力の多様性
・表形式の見やすい出力
・JSON形式でのデータ出力
・エラーメッセージの明確な表示
実行時の注意点
文字化けについて:
Windowsコンソール(CP932)でUTF-8の日本語が文字化けしていますが、これは表示の問題のみで、プログラムのロジックは完全に正常動作しています。
解決方法:
1．PowerShellで実行: chcp 65001 でUTF-8に変更後実行
2．VSCodeターミナル: UTF-8対応のターミナルで実行
3．ファイル出力: python aop140.py > result.txt でファイルに保存し、UTF-8対応エディタで開く
4．プログラムから利用: 他のPythonプログラムからimportして使用（推奨）
プログラムを作って終わりではなく、さらにその先の改善案に言及しているのは感心しますね。ちなみに実際に確認したところ、日本語環境における文字コードは、Windowsコマンド・プロンプトでもPowerShellでもディフォルトはコードページ932（シフトJIS）であり、chcp 65001コマンドを入力することでコードページ65001（UTF-8）に変更することができました。ですので上記解決策1.は、PowerShellだけでなく通常のコマンド・プロンプト画面でも良いのかもしれません。
次のステップ
プログラムは完全に動作しているので、以下の拡張が可能です:
1．Web API化: FastAPIでREST APIとして公開
2．データベース連携: SQLiteやPostgreSQLと連携
3．GUI化: Tkinterで画面インターフェース追加
4．バッチ処理: CSVファイルから一括処理
5．ログ機能: 処理履歴の記録
最後にＢｏｂは変換作業のサマリを出力して終わります。本番環境で使用できる品質とのことですが、その前に最低でも人の手でテストは実施しておくべきなのだと思います。
結論
・RPG IIIプログラムのPython変換は完全成功
・すべてのテストケースが正常動作
・若手プログラマーが理解・保守できる構造
・実用レベルのバッチ処理プログラムとして使用可能
プログラムは本番環境で使用できる品質です！
Bobと私の一連のやり取りを見ればわかりますように、プログラマではない私が主体的だったのはBobに実施して欲しいことを伝えるところまでであり、その先はBobが説明することの意味を理解せずに、言われるままに作業を進めておりました。スキルが無くてもプログラミングを行えるというのは驚異的ではありますが、だからと言って実用に耐えうる品質の完成品になっているかと問われれば、手放しで「そうだ」とは言い切れない、が答えだと思います。特に基幹業務システムにおいては万が一のことがあってはいけないので、十分な用心深さを必要とするはずです。
さて、Pythonへの変換は実験的なものなので、王道とでも呼ぶべきフリーフォームRPGへの変換をBobに依頼しました。先ほど同様に変換作業を終えると、あわせて変換内容を説明するドキュメントを生成してくれます。430行近くにもおよぶ分量があるので、以下に章立てのみを紹介します。
変換前後の比較 ～ ファイルサイズ
・元のRPG III: 約150行（固定形式）
・フリーフォームRPG IV: 267行（コメント・空行含む）
・可読性: 大幅に向上
主な変換内容
1. ヘッダー仕様書（H仕様書）：変換前後のソースコードを示しながら説明
（途中省略）
5. 計算仕様書（C仕様書）→ 処理ロジック
5.1. 初期化処理
5.2. DOループ
5.3. IF文
5.4. 複合条件
5.5. FORループ
5.6. 配列操作（XFOOT）
（途中省略）
| RPGⅢ | フリーフォームRPGⅣ | 説明 |
| `H仕様書` | `**FREE` + コメント | ヘッダー |
| `F仕様書` | `Dcl-F` | ファイル宣言 |
| `E仕様書` | `Dcl-S ... Dim()` | 配列宣言 |
| `I仕様書 DS` | `Dcl-DS ... End-DS` | データ構造 |
| `C仕様書` | 処理文 | 計算処理 |
| `Z-ADD` | `Clear` または `=` | 初期化 |
| `MOVE` | `=` | 代入 |
| `MOVEL` | `=` | 左詰め代入 |
| `DO *HIVAL` | `Dow *On` | 無限ループ |
| `DO n m` | `For I = n To m` | カウンタループ |
| `IFEQ` | `=` | 等しい |
| `IFNE` | `<>` | 等しくない |
| `ANDEQ` | `And ... =` | かつ等しい |
| `OREQ` | `Or ... =` | または等しい |
| `SETON` | `*InXX = *On` | インジケータON |
| `SETOF` | `*InXX = *Off` | インジケータOFF |
| `EXFMT` | `ExFmt` | 画面入出力 |
| `RETRN` | `Return` | 復帰 |
| `END` | `EndIf/EndDo/EndFor` | 終了 |
| `*IN03` | `*In03` | インジケータ |
| `'1'` | `*On` | ON定数 |
| `'0'` | `*Off` | OFF定数 |
| `*BLANK` | `*Blank` | 空白定数 |
| `*HIVAL` | `*HiVal` | 最大値 |
| `配列,I` | `配列(I)` | 配列添字 |
| `XFOOT` | ループで集計 | 配列合計 |
PythonよりもFF RPGの方がRPGⅢに近いためか、変換対応表はかなり精緻になっているような印象です。あらゆる観点が網羅されているのかどうかはわかりませんが、これそのものが変換にあたっての考慮点一覧を示すドキュメントとして使えそうですね。言語仕様が大きく異なるPythonだと、変換表が少々大雑把なものになるのは致し方ないかもしれません。
BobはRPGⅢからPythonへの変換を行うと、自らテストを行ってエラーを解消するだけでなく、ドキュメントを生成し、改善案まで提示してくれました。フリーフォームRPGへの変換においては、「AOP140 RPG/400 → フリーフォームRPG IV 変換ガイド」と「AOP140.RPGLE 改良提案レポート」の二つの文書を同時に生成しました。これら文書を読むだけでもRPG刷新のためのスキル向上に役立ちそうです。残念ながら私にはソース・プログラムと対比しながら読み解くことはできませんが、BobがIBM i アプリケーション、特にRPGプログラムの要員不足対策の決定打になる可能性を感じます。
Bobがいてくれるのであれば、言語の仕様そのものよりも、むしろその位置付けの方が重要になってくるのではないでしょうか。資産継承性を維持できる、パフォーマンスに優れている、アプリケーションが安定稼働する、といったRPGの優位性をあらためて見直したいと感じた次第です。
ではまた
