6. RPG固定形式と取り違え防止 — IBM i最良手順 2026-07-22

現場で一番効いた気づき： 表示上 CHAINRECFMT01 / WRITESCR02 のように命令と対象がくっついて見えるのは、「予約語が優先されて動く」のではなく、固定形式の列位置で別欄に置かれているだけ。現行資産は RPG III 列（Opcode 28–32）が多い。RPG IV 列だけ見ると 0件になる。実装の主経路は tools/rpg_io_parse.py。

列位置早見（実装と一致）

欄	RPG III（1始まり）	RPG IV
Form Type	6	6
Factor1	18–27	12–25
Opcode	28–32	26–35
Factor2	33–42	36–49

ファイル名 vs レコード様式

命令	Factor2に来やすいもの	CRUD寄せ先
CHAIN/READ/SETLL…	ファイル名 or 様式	ファイル（DDS突合）
WRITE/UPDAT/DELET	レコード様式	所属ファイルへ正規化
EXFMT	DSPF様式	画面（CRUD図では除外）

やってはいけないこと： ソースの空白圧縮・タブ化・一般フォーマッタ整形 / F仕様の IF/UF だけで CONFIRMED / HTMLやOCRだけを正本 / EXCEPT を無条件に DB CREATE 扱い。

実践キュレーション全文（2026-07-22）

正本: documents/IBM_i_解析_取り間違いやすい記法_キュレーション_20260722.md

IBM i / RPG・CL 解析で取り間違いやすい記法（実践キュレーション）

版: 2026-07-22
目的: IBM i 移行解析の静的解析（機能調査レポート・CRUD 昇格）で、命令・対象名・CRUD を誤検出しやすい記法を具体化する
前提: 成果物フォーマット（機能調査レポート MD/HTML）は変更しない。解析器・根拠付けを厚くする
参照元:

- 社内キュレーション IBM_i_AS400_詳細解析_情報収集手順書_v1.1.md（§6.1.1 ほか）

- IBM Documentation: DSPPGMREF / QWHDRPPR（WHFUSG）

- IBM ILE RPG Reference（C-spec 列位置）

- Midware RPG IV C-specs / MC Press（WRITE/UPDATE はレコード様式）

- midrange.com RPG400-L（FILE vs FORMAT）

- 現行 SRC 実例（SRC\**\*.RPG）

1. 最重要: 「CHAIN○○」は予約語優先ではない

現象（現行 SRC 実例）

表示上は空白が無く見える。

C           SSCODE    CHAINRECFMT01               11
C                     EXFMTSCR01
C                     WRITESCR02
C                     SETLLFILE01                99

正しい解釈

固定形式（RPG IV）では 列位置 が構文である。

欄	RPG IV 列（1始まり）	0始まり index
Form Type	6	5
Factor 1	12–25	11:25
Opcode(+ext)	26–35	25:35
Factor 2	36–49	35:49
Result	50–63	49:63
Resulting indicators	71–76	70:76

CHAINRECFMT01 は「CHAIN という予約語が隣接識別子を食った」のではなく、

Opcode 欄 = CHAIN
Factor2 欄 = RECFMT01

が隣接して 表示上つながって見える ことが多い。

解析器への実践ルール

第一優先: Form Type=C の行は列スライスで Opcode / Factor2 を取る（空白正規表現に依存しない）。
第二: OP_GLUED（CHAIN+識別子）はフォールバック。誤爆しやすい（CHAIN を含む長い名前等）。
空白圧縮・タブ化・行頭 trim したコピーは解析対象にしない。
HTML/証跡に載せる引用は white-space: pre / コードフェンスで原文保持。

自由形式との違い

chain CustomerNo CustomerF;   // OK
chainCustomerNo CustomerF;    // 通常は1トークン扱いかエラー
chain(e)CustomerNo CustomerF; // 括弧で区切れる場合あり（可読性は悪い）

/FREE 行では列パーサを使わず、字句解析する。

2. ファイル名 vs レコード様式（CRUD 誤りの本丸）

事実（外部記述ファイル）

命令	Factor2 / オペランドに来やすいもの
CHAIN / READ / READE / SETLL / SETGT	ファイル名またはレコード様式
WRITE / UPDATE(UPDAT) / DELETE(DELET)	原則レコード様式名（ファイル名ではない）
EXFMT	レコード様式（DSPF）
EXCEPT	O-spec の例外名（帳票・部分出力）。DB 直書きと誤認しやすい

現行資産での典型

F仕様: FFA011L01IF ... DISK
DDS: レコード FA011R / LF メンバ FA011L01
C仕様: WRITE FA011R または WRITEFA011R（見た目連結）

→ 証跡の「対象」が FA011L01IF（F仕様のファイル名）なのに、命令側は FA011R だけ、という 名前不一致 が PARTIAL の主因。

解析器への実践ルール

DDS / DSPFFD から (ファイル名, レコード様式, PFILE) の対応表を必ず持つ（現行 load_lf_dds を強化）。
WRITE/UPDAT/DELET は Factor2 がレコード様式でも、所属ファイルへ CRUD を寄せる。
EXCEPT は PRTF/O-spec か DB かを分け、DB の C と決め打ちしない。
DSPPGMREF の WHRFNM（レコード様式）と WHFNAM/WHSNAM を突合する。

3. F仕様の罠（宣言だけ ≠ CRUD）

よくある誤判定

F仕様の見え方	やりがち	正しい扱い
`... IP ... DISK`	CONFIRMED READ	宣言のみ → PARTIAL（操作命令待ち）
`... UF ... DISK`	CONFIRMED UPDATE	同上。更新可能宣言であり UPDATE 行が必要
`... O ... DISK`	CONFIRMED CREATE	WRITE/EXCEPT 行が必要
WORKSTN / DSPF	DISK と同じ CRUD	画面。EXFMT/WRITE 様式単位
`RENAME(rec:alias)`	様式名不一致で見逃し	別名表を作る
`PREFIX` / `EXTFILE` / `EXTMBR`	静的名で確定	実行時名は UNRESOLVED/推定

現行方針「F仕様だけでは CONFIRMED にしない」は正しい。維持する。

4. 命令の略称・別名（検索漏れ）

ソースに出やすい	正規化先	CRUD めやす
UPDAT	UPDATE	U
DELET	DELETE	D
BITOF / LOKUP（RPG III 残滓・変換途中）	BITOFF / LOOKUP	I/O ではないことが多い
READE / READP / READPE	READ 系	R
WRITE + EXFMT	画面系	R/C（DSPF）

\bUPDATE\b だけだと UPDAT を落とす。現行 OP_PAT は両方あるが、列パーサ側の Opcode 正規化表も同じ集合にする。

5. 結果標識・条件付き I/O（行を捨てない）

C  N60                WRITESCR02                  61
C           SSCODE    CHAINRECFMT01               11

左の条件標識（N60 等）があっても I/O 行である。
右の結果標識（11, 61, 99）は「ヒット/エラー」であり、命令自体の否定ではない。
コメント列（7）が * の行だけスキップ。

解析時に「標識付き行を雑に除外」すると CRUD が薄くなる。

6. CL・オーバーライド（ソース名 ≠ 実行時実体）

OVRDBF FILE(ORDERPF) TOFILE(LIB/REALPF) MBR(MBR01)
CALL PGM(ORD001)
DLTOVR FILE(ORDERPF)

静的に見える名	実行時
ORDERPF	REALPF / 別メンバの可能性

機能調査の⑤・証跡は 静的根拠 を正としつつ、OVRDBF/OPNQRYF/CRTPF QTEMP はメモに残す。
DSPPGMREF は コンパイル時参照。OVRDBF 後の実体は出ない。

7. DSPPGMREF（WHFUSG）の使い方 — 精度を上げる最短ルート

現行 OBJ情報/プログラム参照情報(DSPPGMREF).csv に既にある。

WHFUSG（ビット合成）

値	意味	CRUD への寄せ方（めやす）
1	Input	R
2	Output	C
3	I/O	R+C
4	Update	U
5	I+U	R+U
6	O+U	C+U
7	I/O/U	R+C+U
8	Unspecified	確定に使わない（CREATE/DROP 等も）
0	N/A	使わない
9–15	上記+Unspecified	下位ビットだけ採用し 8 は無視

主要列: WHPNAM(PGM), WHFNAM/WHSNAM(参照名), WHLNAM, WHRFNM(様式), WHFUSG, WHOBJT。

推奨突合（成果物フォーマットは変えず）

証跡の PARTIAL（F仕様のみ）に対し、同一 PGM×同一ファイル系で WHFUSG∈{1..7} があれば

- 昇格はしない（Bob ルール: SRC 行番号必須のまま）

- ただしメモ／含意に「DSPPGMREF: WHFUSG=5 → コンパイル時は I+U」を追記し、確認先を明示。

SRC で WRITE 様式 を検出したら、DSPPGMREF の WHRFNM でファイルへ正規化して CONFIRMED。
⑤の CRUD マトリクスは「SRC確定 ∪（明示ラベル付きで）PGMREF推定」を内部集計してもよいが、表の判定列は現行どおり SRC 優先。

8. COBOL・SQL・その他の取り違え

記法	注意
`READ ZS-STM INVALID ...`	ファイル名にハイフン。RPG 用正規表現だと落ちる
`OPEN INPUT ZS` / SELECT 名	内部名と SELECT 名の対応が必要
embedded SQL `INSERT INTO`	DSPPGMREF に出ても WHFUSG=8 になりうる。SQL ソース精読が必要
QRYDFN / RUNQRY	CALL ツリーに出ない。CL 逆引き必須（現行ツールあり）
`CALL` 変数 / `CALLP` 式	静的閉包に出ない → UNRESOLVED

9. 列パーサ疑似コード（実装指針）

OPS = {
    "CHAIN": "R", "READ": "R", "READE": "R", "READP": "R", "READPE": "R",
    "SETLL": "R", "SETGT": "R", "EXFMT": "R",
    "WRITE": "C", "EXCEPT": "C",
    "UPDAT": "U", "UPDATE": "U",
    "DELET": "D", "DELETE": "D",
}

def parse_fixed_c_spec(line: str) -> dict | None:
    # 注意: タブ展開禁止。短行は右側を空白パディングしてからスライス
    if len(line) < 6 or line[5].upper() != "C":
        return None
    if len(line) > 6 and line[6] == "*":
        return None
    padded = line.ljust(80)
    op = padded[25:35].strip().upper()
    # opcode extender: CHAIN(E) 等 → 括弧除去
    op = re.sub(r"\(.*\)$", "", op)
    if op not in OPS:
        return None
    return {
        "factor1": padded[11:25].strip().upper(),
        "op": op,
        "factor2": padded[35:49].strip().upper(),
        "result": padded[49:63].strip().upper(),
        "crud": OPS[op],
    }

自由形式・CL・COBOL は別パーサ。固定形式に \bCHAIN\s+(\w+) だけ頼らない。

10. チェックリスト（解析バッチ投入前）

[ ] SRC が固定長・空白保持か（CP932、タブ無し）
[ ] C仕様を列パーサで読んでいるか
[ ] WRITE/UPDAT/DELET をレコード様式→ファイルに正規化しているか
[ ] F仕様のみを CONFIRMED にしていないか
[ ] DSPPGMREF WHFUSG / WHRFNM を突合しているか
[ ] OVRDBF / EXTFILE / RENAME をメモまたは UNRESOLVED に残しているか
[ ] 条件標識付き I/O 行を落としていないか
[ ] UPDAT/DELET 略称を拾っているか

11. 出典（一次情報）

IBM Docs — Displaying objects used by programs (DSPPGMREF usage codes)
IBM Support — QADSPPGM / QWHDRPPR field list（WHFUSG 説明）
IBM ILE RPG Reference — Calculation specification column layout
Midware — RPG IV C-specs（Opcode 26–35, Factor2 36–49）
MC Press — Using Keys and Output Opcodes in /Free（WRITE/UPDATE は record format）
社内手順書 v1.1 §6.1.1（空白連結の誤解の否定）

12. 現行実装との対応（要約）

項目	現状	推奨
`OP_GLUED`	あり（有効）	列パーサを主、GLUED は副
F仕様のみ PARTIAL	正しい	維持
DDS 突合	一部	WRITE 様式→ファイル必須化
DSPPGMREF	取得済・レポートに薄い	WHFUSG/WHRFNM を昇格判定の補助＋メモに常時
業務意味	機能一覧・メニュー・画面ワイヤー	データ系（PFILE）単位の業務ラベルを用語集と接続

手順書 v1.1 から抜粋 — §6.1.1 固定形式の空白

正本: documents/IBM_i_AS400_詳細解析_情報収集手順書_v1.1.md

6.1.1 固定形式RPGにおける命令コードと空白の扱い

固定形式RPGでは、CHAIN、READ、WRITE、UPDATE、EXSR等が「予約語として周囲の文字より優先的に認識される」ため動作するわけではない。

コンパイラーは、行内の列位置を基準として、各部分を別の欄として読み取る。

概念的には次のように分かれている。

仕様タイプ | 条件標識 | 演算項目1 | 命令コード | 演算項目2 | 結果フィールド | 結果標識

例えば、等幅フォント上では次のように見えるコードがある。

C     CUSTOMERNO    CHAIN     CUSTOMERF

これは空白文字を単なる区切りとして解釈しているのではなく、CUSTOMERNO、CHAIN、CUSTOMERFが、それぞれ所定の列範囲に置かれているため認識される。

したがって、画面表示、HTML変換、PDF変換、OCR、CSV化等によって空白が詰まり、次のように見えたとしても、

CUSTOMERNOCHAINCUSTOMERF

元のソース上で各文字が正しい列に存在していれば、コンパイル時には別々の欄として解釈される。

この場合の正しい理解は次のとおりである。

> 「書き方として不適切だが、予約語が優先されて動く」のではない。

> 「固定形式の列定義に従った正常な記述であり、表示上は空白が少なく見えることがある」。

自由形式RPGとの違い

自由形式RPGでは、列位置ではなく、空白、括弧、演算子、セミコロン等による字句の区切りが重要になる。

chain CustomerNo CustomerF;

次のように命令コードと識別子を連結すると、通常はCHAIN命令とCustomerNoには分解されない。

chainCustomerNo CustomerF;

これはchainCustomerNoという一つの識別子として扱われるか、構文エラーになる可能性がある。

括弧が字句の境界になる次の記述は解析できる場合がある。

chain(e)CustomerNo CustomerF;

ただし、可読性と保守性のため、次のように空白を入れる。

chain(e) CustomerNo CustomerF;

固定形式か自由形式かを判断する目安

判定項目	固定形式	自由形式
仕様タイプ	行頭付近の`H`、`F`、`D`、`I`、`C`、`O`、`P`	`ctl-opt`、`dcl-f`、`dcl-s`等
列位置	構文上の意味を持つ	原則として意味を持たない
文末	セミコロンを使用しない旧形式が中心	セミコロンが必要
命令位置	命令コード欄に配置	行内の任意位置
空白圧縮	ソース破壊につながる	トークン境界を保てば影響が小さい
自動整形	原則禁止、専用パーサーが必要	RPG対応フォーマッターなら可能

AI・変換ツールへ渡す際の必須ルール

固定形式RPGを解析、変換、検索、AI投入する場合は、次を守る。

元ソースの1行を固定長のまま保存する。
行頭からの列番号を保持する。
タブ文字へ変換しない。
連続空白を1文字へ圧縮しない。
行頭・行末の空白を自動削除しない。
比例フォント表示だけを根拠に構文を判断しない。
OCR結果だけで解析を確定しない。
HTMLではwhite-space: preまたはpre-wrapを使用する。
Markdownではコードフェンス内に原文を保持する。
CSV化する場合も、元行、列開始位置、列終了位置を別途保持する。
自由形式へ変換する場合、変換前後をコンパイルし、外部記述、標識、命令拡張子を比較する。
元ソースと「人間向けに整形した表示用ソース」を別ファイルとして管理する。

推奨する固定形式の構造化データ

{
  "sourceLineNumber": 245,
  "rawLine": "C     CUSTOMERNO    CHAIN     CUSTOMERF",
  "specificationType": "C",
  "factor1": "CUSTOMERNO",
  "operationCode": "CHAIN",
  "factor2": "CUSTOMERF",
  "resultField": "",
  "resultIndicators": [],
  "parserMode": "FIXED_FORMAT",
  "columnLayoutVersion": "RPG_IV"
}

rawLineは整形せず、抽出した原文をそのまま保存する。

列ずれを疑う条件

次の場合は、ソースの破損または変換ミスを疑う。

命令コードが命令欄から1文字以上ずれている。
固定形式なのにタブが含まれる。
ソース物理ファイルからコピー後、先頭空白が消えている。
HTMLやメールから再取得したソースで空白数が変わっている。
OCRで0とO、1とI、標識欄が誤認されている。
日本語コメントを含む行でバイト位置と文字位置が混同されている。
CCSID変換後に全角空白が混入している。
シーケンス番号欄や変更日欄がソース本文へ連結されている。

列ずれが疑われる場合は、ソース物理ファイルの元メンバー、コンパイルリスト、SEUまたはRDi上の列ルーラーを基準に再確認する。

手順書 v1.1 から抜粋 — §6.7 ネイティブI/O

6.7 ネイティブI/O

抽出対象：

CHAIN
SETLL
SETGT
READE
READPE
READ
READP
WRITE
UPDATE
DELETE
EXCEPT
OPEN
CLOSE
UNLOCK
FEOD

各命令について記録する。

対象ファイル
対象レコード様式
キー値
キー項目順
部分キーか完全キーか
昇順／降順
検索開始位置
ループ条件
%FOUND
%EOF
%EQUAL
%ERROR
レコードロック
例外拡張子(E)
結果インジケーター
更新対象項目
コミットメント制御

例

setll (CustomerNo) CustL1;
reade (CustomerNo) CustL1;
dow not %eof(CustL1);
   // 処理
   reade (CustomerNo) CustL1;
enddo;

このコードを解析するときは、次が必要になる。

CustL1の実体。
LFのキー順。
複合キーのどこまで指定しているか。
SELECT/OMIT条件。
アクセスパスの昇降順。
レコード様式名。
オーバーライドの有無。
ジョブのライブラリー・リスト。
ロック待ち時間。
読取後の更新有無。

← 5. プロンプト全文 — Codex査読 7. CRUD図・テーブル定義書・HTML →