AS400のEDTCDEとEDTWRDとは？DDSの編集コード・編集語を表で整理

2026.06.30

AS400 / IBM i の画面ファイルや印刷ファイルを保守していると、DDSの数値項目に EDTCDE や EDTWRD が指定されていることがあります。どちらも数値を見やすく表示するための指定ですが、役割を混同すると、金額の桁区切り、ゼロ表示、日付風の表示、帳票の位置合わせで迷いやすくなります。

この記事では、EDTCDE と EDTWRD の違いを、現場で確認しやすい表で整理します。全コードを最初から覚えようとするより、まず「どちらで表示を作っているか」「DB定義側から来ているのか」「画面ファイル・帳票ファイル側で上書きしているのか」を見るのが大事です。

EDTCDEとEDTWRDの違い

項目EDTCDEEDTWRD
意味編集コード。IBM i 側で用意された編集パターンを指定する編集語。自分で表示パターンを文字列として作る
向いている用途金額、数量、日付風の数値など、一般的な編集表示固定文言や通貨記号、特殊な桁位置を含む独自表示
読み方EDTCDE(J)、EDTCDE(K $) のようにコードを見るEDTWRD(' $0. ') のように括弧内の並びを見る
注意点コードだけでなく桁数・小数桁・通貨記号指定も合わせて見る空白、0、記号の位置がそのまま表示崩れに関係する
同時指定同じフィールドに EDTCDE と EDTWRD を同時に指定しない。どちらで編集しているかを切り分ける

DDSでの指定例

たとえば、表示ファイルや印刷ファイルのDDSでは、数値項目に次のような指定が出てきます。

00010A            PRICE          5  2   1 10EDTCDE(J)
00020A            SALES          7  2   2 10EDTCDE(K $)
00030A            TOTAL          7  2   3 10EDTWRD('    $0. ')

この例では、PRICE と SALES は編集コードで表示し、TOTAL は編集語で表示パターンを作っています。保守では、まずフィールド名、桁数、小数桁、位置、編集指定を横並びで見ます。

保守で見るポイント

見る場所確認することよくある原因
DDSのフィールド定義数値桁数、小数桁、EDTCDE / EDTWRD の有無桁数変更後に編集指定が古いまま
DBファイルの定義物理ファイル側に編集指定があるか画面側で指定していないのに表示が編集される
表示ファイル画面上の位置と入力/出力属性表示位置が狭く、金額が詰まる
印刷ファイル帳票幅、改ページ、罫線、金額欄桁あふれ、通貨記号、マイナス表記で位置がずれる
実行結果ゼロ、マイナス、小数、最大桁のサンプル通常データでは気づかず、月末や締め処理で崩れる

EDTCDEを疑う場面

  • 金額のカンマ、ゼロ、マイナス表示が想定と違う
  • 同じ数値項目なのに、画面と帳票で表示形式が違う
  • DBの数値は正しいが、画面表示だけ違和感がある
  • 日付のように見える数値項目で、区切り文字や並びが合わない

EDTCDE は標準的な編集で済む時に使われやすい指定です。IBMのDDS仕様でも、一般的な編集要件の多くは EDTCDE で対応し、不足する場合に EDTWRD を使う考え方です。

EDTWRDを疑う場面

  • 帳票で金額の前に固定の記号や文字を出している
  • 標準の編集コードでは表現しにくい独自フォーマットがある
  • 空白の数や記号の位置で帳票の見た目を合わせている
  • 古い帳票で、見た目を崩さないために手作りの編集語が残っている

EDTWRD は柔軟ですが、保守では変更影響を丁寧に確認したい指定です。空白の数、0 の位置、記号の位置が表示結果に影響します。見た目だけで判断せず、ゼロ、1円、マイナス、最大桁、小数あり/なしのテストデータで確認した方が安全です。

表示確認用のテスト表

テスト値確認したいこと見るポイント
0ゼロを表示するか、空白になるかゼロ抑制の有無
1最小値が右寄せで出るか先頭空白と桁位置
1234.56小数点と桁区切りが合うか小数桁、カンマ、表示幅
-1234.56マイナス表記が崩れないか符号、CR/DB表記、欄外はみ出し
最大桁帳票や画面であふれないか桁数変更時の事故防止

調査の進め方

表示がおかしい時は、まずプログラムロジックから見る前に、次の順番で確認すると切り分けやすいです。

  1. 実データの値を確認する
  2. DDSのフィールド桁数と小数桁を見る
  3. EDTCDE または EDTWRD の有無を見る
  4. DB定義側に編集指定がないか確認する
  5. 画面ファイル・印刷ファイルを再コンパイルして実表示を確認する

特に帳票は、実データが正しくても「見た目が違う」だけでも利用部門から確認依頼につながることがあります。締め日、請求書、出荷指示、在庫表、売上一覧のような帳票では、編集指定の変更前後でサンプル出力を残しておくと安心です。

関連して見る記事

参考

公式資料で細かい指定を確認しつつ、実際の保守ではコンパイル後の画面・帳票・テストデータで表示を確認するのが安全です。古いDDSでは、見た目を合わせるための指定が長年残っていることもあります。

EDTCDEとEDTWRDは「見た目の仕様」として残す

EDTCDEやEDTWRDは、数値を画面や帳票でどう見せるかを決める指定です。計算結果そのものではなく、カンマ、ゼロ抑止、符号、少数、通貨記号などの表示ルールに関わるため、帳票修正や画面改修では「値が違う」のか「見せ方が違う」のかを分けて確認します。

観点確認することよくある見落とし
EDTCDE定型の編集コードで表示しているかゼロ抑止や符号表示の違いを値の不一致と誤解する
EDTWRD独自の編集語で表示しているか帳票固有の見た目ルールを引き継ぎ忘れる
帳票印字桁、カンマ、小数点、符号桁あふれや位置ずれをテストで見落とす
引き継ぎ仕様書に表示例を残すコードだけ残して、利用者の見え方が伝わらない

若手へ教える場合は、DDSやRPGの指定だけでなく、実際の表示例を並べて説明すると理解が早くなります。帳票や画面の見た目を直す作業では、計算ロジック、編集指定、出力先の3つを分けて確認するのが安全です。

スポンサーリンク