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では、数値項目に次のような指定が出てきます。

以下はキーワードの書き方を示す断片で、コンパイル可能なDDS全体ではありません。対象が表示装置・印刷装置・データベースのどれかで指定条件が異なります。桁数・小数点・負数・ゼロの出力を、承認された検証環境の定義で確認してください。

EDTCDE(J)
EDTCDE(K $)
EDTWRD('    $0. ')

上の断片はフィールド名やDDSの位置指定を省略しています。EDTCDE の2行は編集コード、EDTWRD の1行は編集語の記述例です。同じ項目へ3行をまとめて指定するものではありません。保守では、まずフィールド名、桁数、小数桁、位置、編集指定を横並びで見ます。

保守で見るポイント

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

EDTCDEを疑う場面

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

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

EDTWRDを疑う場面

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

EDTWRD は柔軟ですが、保守では変更影響を丁寧に確認したい指定です。空白の数、0 の位置、記号の位置が表示結果に影響します。見た目だけで判断せず、ゼロ、1円、マイナス、最大桁、小数あり/なしのテストデータで確認した方が安全です。 DBファイル側の編集指定を表示ファイルへ引き継ぐには、R指定で既存フィールドを参照します。表示側で長さ・データ型・小数桁を指定すると、参照元の編集指定は引き継がれず、表示側で再指定が必要です。DB定義にEDTWRDがあるだけで、すべての画面へ自動適用されるわけではありません。

表示確認用のテスト表

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

調査の進め方

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

  1. 実データの値を確認する
  2. DDSのフィールド桁数と小数桁を見る
  3. EDTCDE または EDTWRD の有無を見る
  4. DB定義側に編集指定がないか確認する
  5. 承認された検証環境で、実際に使用する定義と依存関係を確認して再コンパイルし、変更前後の実表示を比較する。本番を調査目的で再コンパイルしない

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

関連して見る記事

参考

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

スポンサーリンク