プロジェクト

全般

プロフィール

レビュー指摘 #11948 » KS60780_詳細設計書.md

[参考資料]現行ソース解析資料AI生成版 - 幸塚 和久, 2026-10-15 04:30 午後

 

KS60780 詳細設計書

項目 内容
プログラムID KS60780(ソース名 KS60780P)
プログラム名 請求明細ヘッダーと顧客集約コードのマッチング
言語 PL/I(OPTIONS(MAIN))。パターン PPB0010P(ファイルのIO・SINGLE)
業務ID NSSQNN50(ソースの +DC GYOM)
起動JOB DAISEQ4J ステップ No.22・No.23(同じプログラムを2回実行)
作成日 2026/10/13(2.4・6.6 に No.22/No.23 の違いを追記)
作成方法 ソースコードからのリバース作成

前提

  • INCLUDE の SQALLHED は、添付ソースを展開して解析した(付録A)。
  • 対応表(TRFILE)のレコード(18バイト)はソース内で定義されており、KS60750P・KS60760P の出力と同じ形式である。
  • 外部手続きの CALL はなく、ブラックボックス(BB)として扱う部分はない。
  • 帳票は出力しない。入出力のイメージを6章に示す(値は架空。KS60750・KS60760 設計書の例の続き)。
  • ★印は、ソースから読み取れる潜在的な問題点または注意点を示す。

1. 概要

1.1 機能

ソース先頭のコメント:「請求明細ヘッダーデータと顧客集約コードデータをマッチングする。マッチングしたデータのみ出力」

  1. 請求明細の見出しデータ(INFILE。KS60770P の出力を請求先番号順に並べたもの)と、郵送集約の対応表(TRFILE。KS60760P の出力を荷主コード順に並べたもの)を、荷主コード7桁で突き合わせる(マッチング)。
  2. 一致した見出しデータについて、
    • データID(SDTADTID)を、代表なら 00、代表に集約される荷主(配下)なら 99 に書き換える。
    • 区分(SDTASPA1、11バイト)を、集約代表コード7桁+代表扱い店4桁に書き換える。
  3. 本締(SDTAKARI=1)のものだけを OUTFILE に書く。仮締は件数だけ数えて出力しない。
  4. 終了時に出力件数・仮締件数を表示する。

1.2 処理概要図

 KS60770P → SORT3(請求先番号順)               KS60760P → SORT2(荷主コード順)
          │                                                │
          ▼                                                ▼
 WORK0090(見出しデータ) ──▶ INFILE ─┐   ┌─ TRFILE ◀── WORK0060(優先印刷マスターに有る:No.22)
                                      ▼   ▼             WORK0080(優先印刷マスターに無い:No.23)
                                    KS60780P
                                       │ 一致&本締のみ。データID・区分を書き換え
                                       ▼
                         OUTFILE ──▶ WORK0100(No.22:事業所用)/WORK0110(No.23:エコデリバー用)
                                       ▼
                         No.24・26 SORT4(代表扱い店・集約代表・SDTACKTT 順)→ No.25・27 KS60790P(配信帳票)

1.3 2回の実行の違い

実行 INFILE TRFILE OUTFILE 後続
No.22 WORK0090 WORK0060(KS60760P の OUTFIL1:優先印刷マスターに有る荷主) WORK0100 SORT4 → WORK0120 → KS60790P 事業所用配信(ライター KS607902)
No.23 WORK0090(同じ) WORK0080(KS60760P の OUTFIL2:優先印刷マスターに無い荷主) WORK0110 SORT4 → WORK0130 → KS60790P エコデリバー用配信(ライター KS607901)
  • プログラムは同じで、突き合わせる対応表だけが違う。同じ見出しデータから「事業所用」と「エコデリバー用」の2本の集約データを作る。
  • 2回の実行の違いの詳細は 2.4、出力結果の比較は 6.6 を参照。

2. 外部インターフェース

2.1 ファイル一覧

DD名 編成/属性(DCL) 入出力 内容 読込/書出領域
INFILE RECORD INPUT(順次・可変長) 入力 請求明細の見出しデータ(請求額≠0、請求先番号順) INAREA CHAR(560) VAR(SQALLHED)
TRFILE RECORD INPUT(順次) 入力 郵送集約の対応表(荷主コード順) TRAREA(18バイト)
OUTFILE RECORD OUTPUT(順次・可変長) 出力 一致した見出しデータ(書き換え後) INAREA

2.2 JCL との対応

DD名 No.22 No.23 属性
INFILE TEMP.KS60750J.WORK0090 同左 VB。作成:No.21 SORT3(KS60770P の出力を 19,8,PD で並替え)
TRFILE TEMP.KS60750J.WORK0060 TEMP.KS60750J.WORK0080 FB 18。作成:No.19/No.20 SORT2(KS60760P の出力を 1,7 で並替え)
OUTFILE TEMP.KS60750J.WORK0100 TEMP.KS60750J.WORK0110 (NEW,KEEP,DELETE)、RECFM=VB、BLKSIZE=12000、SPACE=(CYL,(300,100),RLSE)、DASD09
  • JCL に SYSPRINT の DD がない。DISPLAY のメッセージはジョブログに出る。

2.3 入出力ファイルの違い

観点 INFILE TRFILE OUTFILE
中身 全店所の見出しデータ(請求額≠0) 郵送集約される荷主と、その代表 両方にある荷主の見出しデータ(本締のみ)
レコード SQALLHED 560バイト 荷主7+集約代表7+代表扱い店4(18バイト) SQALLHED 560バイト(2項目を書き換え)
並び 請求先番号(荷主+枝番)順 荷主コード順 INFILE の順(後で SORT4 で並べ替え)
1荷主あたりの件数 枝番の数だけ(複数あり得る) 通常1件 1件まで(5.2 の★)
データID(33~34バイト) 00(見出し) - 00=代表/99=配下
区分(22~32バイト) 元の区分(見出しは通常空白) - 集約代表コード+代表扱い店

2.4 JCL 上の2回の実行(No.22/No.23)の違い

(1) JCL の比較

DD名 No.22 No.23 違い
INFILE DSN=TEMP.KS60750J.WORK0090 DSN=TEMP.KS60750J.WORK0090 同じ(同じ見出しデータを2回読む)
TRFILE DSN=TEMP.KS60750J.WORK0060 DSN=TEMP.KS60750J.WORK0080 対応表が違う
OUTFILE DSN=TEMP.KS60750J.WORK0100 DSN=TEMP.KS60750J.WORK0110 出力先が違う(属性は同じ VB/BLKSIZE=12000)
  • EXEC 文・プログラムは同じ(EXEC PGM=KS60780P)。PARM もない。プログラムの動きは、TRFILE の中身だけで変わる。

(2) TRFILE(対応表)の違い

観点 No.22 の TRFILE(WORK0060) No.23 の TRFILE(WORK0080)
作成の流れ KS60760P の OUTFIL1(WORK0030)→ No.19 SORT2(1,7) KS60760P の OUTFIL2(WORK0040)→ No.20 SORT2(1,7)
中身 優先印刷マスターに有る荷主 優先印刷マスターに無い荷主
意味(推定) 事業所で印刷・発送する顧客(KS60152P の「事業所送付用」と同じ区分) エコデリバー(郵送サービス)で発送する顧客(KS60152P の「インフォコム」と同じ区分)
代表の扱い 代表自身が優先印刷マスターに有れば、代表のレコードもここに入る 代表自身が無ければここに入る。荷主コード空白の代表レコードも入る
同じ荷主が両方に入るか 入らない(同じ荷主は、どちらのレコードでも同じマスター検索結果になるため、必ず同じファイルに入る) ←

(3) 出力と後続処理の違い

観点 No.22 → WORK0100 No.23 → WORK0110
出力される見出し 優先印刷マスターに有る荷主の見出し(本締・請求額≠0) 優先印刷マスターに無い荷主の見出し(同左)
並べ替え No.24 SORT4 → WORK0120 No.26 SORT4 → WORK0130(キーは同じ)
配信帳票 No.25 KS60790P(JCL コメント「事業所用配信」)、SYSOUT=(E,KS607902,99) No.27 KS60790P(「エコデリバー用配信」)、SYSOUT=(E,KS607901,99)
メッセージ OUTPUT COUNT/KARI JIME は No.22 の分だけ No.23 の分だけ

(4) 2回の実行を合わせて見たときの関係

  1. 1つの見出しは、多くても片方にしか出ない:TRFILE の2本に同じ荷主が入らないため、ある荷主の見出しは No.22 か No.23 のどちらか一方にだけ出力される(どちらにも一致しなければ出ない)。
  2. 件数の関係:No.22 と No.23 の(OUTPUT COUNT+KARI JIME)の合計は、「郵送集約の対象になっている荷主のうち、請求額≠0 の見出しがある荷主の数」になる(1対1マッチングのため、荷主1件につき1件)。
  3. グループが2本に分かれる:振分けは荷主ごとに行われるため、同じ集約代表のグループ(代表+配下)が、事業所用とエコデリバー用に分かれることがある。このとき、それぞれの配信帳票は、そのグループの一部の荷主だけで作られる(6.6)。
  4. 代表のいないグループ:代表が反対側のファイルに入った場合、そちらの出力には配下(データID 99)だけが並ぶ。区分には集約代表コードが入っているので、代表が誰かは分かるが、代表の見出し(00)は無い。
  5. INFILE は共通:同じ WORK0090 を2回読むだけで、No.22 の結果が No.23 に影響することはない。どちらか一方だけを再実行しても、もう一方の結果は変わらない。

3. データ定義

3.1 入力エリア

名称 属性 内容
INAREA CHAR(560) VAR INFILE の読込域。書き換えて OUTFILE に書く
INARA DEF INAREA:DUMMYA BIN(15)+SQALLHED 見出しデータとして参照・更新
TRAREA TRKOCD CHAR(7)+TRDAIH CHAR(7)+TRTNCD PIC'(4)9' TRFILE の読込域(荷主・集約代表・代表扱い店)

参照・更新する見出しデータの項目:

項目 位置 長さ 属性 用途
SDTASQNO 15 7 FIXED DEC(13) 荷主コードの取出し(2~8桁目)
SDTASPA1 22 11 CHAR(11) 更新:TRDAIH ∥ TRTNCD
SDTADTID 33 2 PIC'(2)9' 更新:00 または 99
SDTAKARI 35 1 PIC'(1)9' 1=本締なら出力

3.2 ワークエリア

名称 属性 初期値 内容
BREAKI CHAR(7) 空白 INFILE 側の比較キー(荷主コード)。終了で HIGH(7)
BREAKT CHAR(7) 空白 TRFILE 側の比較キー(TRKOCD)。終了で HIGH(7)
SEQNO/SEQNO_DF PIC'(13)9' 0 請求先番号13桁と、その分解(SEQ_NICD=荷主7桁)
OCNT FIXED DEC(9) 0 出力件数
KCNT FIXED DEC(9) 0 一致したが仮締のため出力しなかった件数
EOF_SW、OUT_SW、II、ICNT、CCNT - - 未使用

4. 処理フロー

開始
 ├─ ON ENDFILE(INFILE) → BREAKI=HIGH(7)、ON ENDFILE(TRFILE) → BREAKT=HIGH(7)
 ├─ OPEN INFILE、TRFILE、OUTFILE
 ├─ INFILE、TRFILE をそれぞれ1件読む
 ├─ DO WHILE(BREAKI∥BREAKT ≠ HIGH(14):どちらかが終わっていない間)
 │     SEQNO ← SDTASQNO
 │     BREAKI ← SEQ_NICD(INFILE が終わっていなければ)
 │     BREAKT ← TRKOCD(TRFILE が終わっていなければ)
 │     SELECT
 │       BREAKI = BREAKT → 【一致】
 │            TRDAIH=TRKOCD なら SDTADTID←00(代表)、違えば 99(配下)
 │            SDTASPA1 ← TRDAIH ∥ TRTNCD
 │            SDTAKARI=1 なら OUTFILE に WRITE、OCNT+1/それ以外 KCNT+1
 │            INFILE と TRFILE を両方とも1件読む
 │       BREAKI < BREAKT → INFILE を1件読む(対応表にない見出しは捨てる)
 │       BREAKI > BREAKT → TRFILE を1件読む(見出しのない対応表は捨てる)
 │  END
 ├─ DISPLAY 出力件数・仮締件数
 ├─ CLOSE INFILE、TRFILE、OUTFILE
終了

5. 処理詳細

5.1 マッチングのキー

ファイル キー 並び
INFILE SDTASQNO(パック13桁)を数字13桁にした2~8桁目=荷主コード7桁 請求先番号順(SORT3)=荷主コード順
TRFILE TRKOCD(荷主コード7桁) 荷主コード順(SORT2)
  • 文字どうしの比較(EBCDIC)。数字だけなら数値順と同じになる。
  • 片方のファイルが終わると、そのキーを HIGH(7)(X'FF'×7)にして、もう一方を読み進める。両方が HIGH になったら終了する。

5.2 一致したときの処理

手順 内容
1 TRDAIH(集約代表)=TRKOCD(荷主)なら SDTADTID ← 00(代表自身)、異なれば SDTADTID ← 99(代表に集約される荷主)
2 SDTASPA1 ← TRDAIH ∥ TRTNCD(集約代表コード7桁+代表扱い店4桁=11バイト)
3 SDTAKARI=1(本締)なら WRITE FILE(OUTFILE) FROM(INAREA)、OCNT+1。それ以外(仮締)は KCNT+1 で出力しない
4 INFILE と TRFILE を両方1件ずつ読み進める
  • 書き換えた区分(22~32バイト目)とデータID(33~34バイト目)は、後続の SORT4(33,4,CH,A,26,7,CH,A,51,4,CH,A:データの 29~32=代表扱い店、22~28=集約代表、47~50=SDTACKTT)のキーになる。つまり出力は、後で「代表扱い店 → 集約代表 → SDTACKTT」の順に並べ替えられ、代表ごとにまとまる。
  • ★ 一致したら両方を読み進める(1対1のマッチング)。同じ荷主に見出しデータが複数(枝番違いの請求先)ある場合、2件目以降は、次の対応表のキーより小さいため「対応表にない」と判定されて捨てられる(6.3 の例)。
  • ★ 同じく、TRFILE に同じ荷主が2件ある場合(ある荷主が、別の代表の配下であり、かつ自分も代表になっている等)、2件目は捨てられる。
  • ★ 仮締の見出しは、一致しても出力されない(件数は KCNT に数える)。

5.3 一致しなかったときの処理

条件 意味 処理
BREAKI < BREAKT 見出しデータの荷主が対応表にない(郵送集約の対象外) INFILE を読み進める(出力しない)
BREAKI > BREAKT 対応表の荷主に見出しデータがない(今回の請求がない、請求額0 等) TRFILE を読み進める
  • KS60760P が作った「荷主コード空白の代表のレコード」(KS60760 設計書 8章 No.3)は、空白が数字より小さいため、ここで読み捨てられる。

5.4 終了処理

  1. 次の2行を DISPLAY する。
    • <<< OUTPUT COUNT = ∥ OCNT
    • <<< KARI JIME = ∥ KCNT(一致したが仮締だった件数)
  2. 3ファイルを CLOSE する。
  • 入力件数は表示しない(ICNT は宣言のみ)。

6. 入出力イメージ

KS60750・KS60760 設計書の例の続き。

6.1 入力

INFILE(WORK0090:見出しデータ、請求先番号順)

No 請求先番号 本締/仮締 備考
1 0010083-00000 本締 代表 0010083
2 1209320-00000 本締 0010083 の配下
3 1234567-00001 本締 7654321 の配下
4 1234567-00002 本締 同じ荷主の別の請求先
5 3456789-00000 本締 集約なし
6 4567890-00000 本締 集約代表が空白(KS60750 の★)
7 5678901-00000 仮締 7654321 の配下
8 7654321-00000 本締 代表 7654321

TRFILE

No.22(WORK0060:優先印刷マスターに有る)   No.23(WORK0080:優先印刷マスターに無い)
----+----1----+---                          ----+----1----+---
001008300100831001                                        0000
123456776543211002                          120932000100831001
                                            4567890       0000
                                            567890176543211002
                                            765432176543211002

6.2 No.22(TRFILE=WORK0060)の処理

順 INFILE TRFILE 判定 処理
1 0010083 0010083 一致・代表 DTID←00、区分←'00100831001'、本締 → 出力
2 1209320 1234567 IN<TR INFILE を読む
3 1234567(-00001) 1234567 一致・配下 DTID←99、区分←'76543211002'、本締 → 出力
4 1234567(-00002) (終了) IN<HIGH ★ INFILE を読む(捨てられる)
5~8 3456789~7654321 (終了) IN<HIGH INFILE を読む

出力(WORK0100):0010083-00000(00)、1234567-00001(99)。メッセージ:OUTPUT COUNT=2、KARI JIME=0。

6.3 No.23(TRFILE=WORK0080)の処理

順 INFILE TRFILE 判定 処理
1 0010083 (空白) IN>TR TRFILE を読む(空白の代表レコードを捨てる)
2 0010083 1209320 IN<TR INFILE を読む
3 1209320 1209320 一致・配下 DTID←99、区分←'00100831001' → 出力
4 1234567(-00001) 4567890 IN<TR INFILE を読む
5 1234567(-00002) 4567890 IN<TR INFILE を読む
6 3456789 4567890 IN<TR INFILE を読む
7 4567890 4567890 一致・配下 DTID←99、区分←' 0000'(代表が空白) → 出力 ★
8 5678901 5678901 一致・配下 仮締 → 出力しない、KCNT+1
9 7654321 7654321 一致・代表 DTID←00、区分←'76543211002' → 出力

出力(WORK0110):1209320-00000(99)、4567890-00000(99、代表空白)、7654321-00000(00)。メッセージ:OUTPUT COUNT=3、KARI JIME=1。

  • 代表 0010083 は No.22(事業所用)、配下 1209320 は No.23(エコデリバー用)に出る。代表 7654321 は No.23、配下 1234567 は No.22 に出る(KS60760 設計書 8章 No.1 の結果)。
  • ★ 1234567-00002 はどちらにも出ない(5.2)。

6.4 出力レコードの書き換えイメージ(1234567-00001、先頭50バイト)

書き換え前(INFILE)

     1 ----+----1----+----2----+----3----+----4----+----5
  文字 1001          ..ッ[...           001026092609300030
  ZONE FFFF4444444444135700144444444444FFFFFFFFFFFFFFFFFF
  NUMR 10010000000000246000C00000000000001026092609300030

書き換え後(OUTFILE、No.22)

     1 ----+----1----+----2----+----3----+----4----+----5
  文字 1001          ..ッ[...76543211002991026092609300030
  ZONE FFFF44444444441357001FFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  NUMR 10010000000000246000C76543211002991026092609300030
  • 22~32バイト目(区分)が空白から「7654321」+「1002」に、33~34バイト目(データID)が「00」から「99」に変わる。それ以外のバイトは変わらない。

6.5 メッセージ(ジョブログ)

No.22                                   No.23
<<< OUTPUT COUNT =            2         <<< OUTPUT COUNT =            3
<<< KARI JIME    =            0         <<< KARI JIME    =            1

6.6 No.22 と No.23 の出力の比較(例の全荷主)

荷主(請求先) 集約代表 優先印刷マスター No.22(事業所用 WORK0100) No.23(エコデリバー用 WORK0110) 備考
0010083-00000 0010083(自分) 有る ○ 代表(00) -
1209320-00000 0010083 無い - ○ 配下(99) 代表 0010083 と別の帳票になる
1234567-00001 7654321 有る ○ 配下(99) - 代表 7654321 と別の帳票になる
1234567-00002 7654321 有る × - ★ 1対1マッチングで捨てられる
3456789-00000 (集約なし) - - - 対応表にないため出ない
4567890-00000 (空白) 無い - ○ 配下(99) ★ 代表が空白
5678901-00000 7654321 無い - ×(仮締) KARI JIME に数える
7654321-00000 7654321(自分) 無い - ○ 代表(00)

集約代表ごとに見ると:

集約代表 No.22(事業所用)に出るもの No.23(エコデリバー用)に出るもの
0010083 代表 0010083 だけ 配下 1209320 だけ(代表なし)
7654321 配下 1234567 だけ(代表なし) 代表 7654321 だけ(配下 5678901 は仮締で出ない)
(空白) - 配下 4567890(代表なし)
  • このように、1つの集約グループが2本の帳票に分かれ、どちらの帳票でもグループ全体がそろわないことがある。業務上それでよいか(代表と配下は常に同じ区分で登録される運用か)は、優先印刷マスターと顧客法人管理マスターの登録ルールの確認が必要。

7. 異常処理

事象 検出 処理
INFILE の終了 ENDFILE 条件 BREAKI=HIGH(7)。TRFILE だけを読み進める
TRFILE の終了 ENDFILE 条件 BREAKT=HIGH(7)。INFILE だけを読み進める
両方の終了 ループ条件 ループを終える(正常)
どちらかが0件 ENDFILE 条件 出力0件で正常終了
SDTASQNO が不正なパック10進 データ例外(0C7) ON 定義なし → 異常終了
その他 - ON ERROR の定義なし → PL/I 標準のエラー処理
リターンコード - 設定なし(正常時は 0)

8. 留意事項(★)

  1. 1対1のマッチング:同じ荷主の枝番違いの見出しデータは、最初の1件しか出力されない。2件目以降は、エラーやメッセージもなく捨てられる(5.2、6.3)。
  2. 対応表の重複:TRFILE に同じ荷主が2件あると、2件目は捨てられる。
  3. 代表と配下が別ファイルに分かれる:No.22 と No.23 は荷主ごとに振り分けた対応表を使うため、代表と配下が事業所用(WORK0100)とエコデリバー用(WORK0110)に分かれることがある。後続の KS60790P で、代表のいないグループ(配下だけ)ができる(2.4、6.6)。
  4. 代表の見出しがない場合:代表の請求額が0(KS60770P で除外)、仮締、または代表が別ファイルに入った場合、出力には配下(99)しか残らない。
  5. 集約代表が空白の配下:区分が「空白7桁+0000」のレコードが出力される(KS60750 設計書 8章 No.1 の影響)。
  6. 仮締は出力しない:一致しても出力せず、件数(KARI JIME)だけを表示する。
  7. 元の区分を上書きする:SDTASPA1(元は区分)を集約代表+代表扱い店で上書きするため、元の区分の値は失われる。見出しデータの区分は通常空白なので影響は小さいと考えられる。
  8. SORT4 で代表が先頭に来る保証がない:SORT4 のキーにデータID(00/99)が含まれないため、同じ代表・同じ店の中では、代表(00)が配下(99)より前に来るとは限らない(後続の KS60790P が代表を先頭と前提していれば問題になる。要確認)。
  9. 入力件数を表示しない、SYSPRINT の DD がない(ジョブログに出る)。
  10. 未使用の変数:EOF_SW、OUT_SW、II、ICNT、CCNT。

9. 未使用項目

項目 内容
SQALLHED の SDTASQNO、SDTASPA1、SDTADTID、SDTAKARI 以外 参照なし(出力にはそのまま含まれる)
EOF_SW、OUT_SW、II、ICNT、CCNT、SEQ_ZERO、SEQ_SQNO 宣言のみ
BUILTIN の ADDR、SUBSTR、LOW、LENGTH、STRING、VERIFY、UNSPEC 宣言のみ(HIGH は使用)

付録A SQALLHED(見出し、データID 00、560バイト)

LV 項目名 属性 繰返し 位置 長さ 本PGでの使用
02 SDTASHTN PIC'(4)9' 1 4
02 SDTAKKKK CHAR(10) 5 10
02 SDTASQNO FIXED DEC(13) 15 7 請求先番号:荷主コード(2~8桁目)で突合せ
02 SDTASPA1 CHAR(11) 22 11 ★ 集約代表コード7桁+代表扱い店4桁で上書き
02 SDTADTID PIC'(2)9' 33 2 ★ 00(代表)/99(配下)で上書き
02 SDTAKARI PIC'(1)9' 35 1 1(本締)のみ出力
02 SDTADPKB PIC'(1)9' 36 1
02 SDTAYYMM PIC'(4)9' 37 4
02 SDTAHYMD PIC'(6)9' 41 6
02 SDTACKTT PIC'(4)9' 47 4
02 SDTAKIKN (集団項目) 51 12
03  SDTAKYMD PIC'(6)9' 51 6
03  SDTASYMD PIC'(6)9' 57 6
02 SDTASQN1 CHAR(8) 63 8
02 SDTASQNI CHAR(64) 71 64
02 SDTASQN2 CHAR(5) 135 5
02 SDTASQNM CHAR(36) 140 36
02 SDTAPKEI PIC'(1)9' 176 1
02 SDTAPKBN CHAR(1) 177 1
02 SDTAHYOG (集団項目) 178 20
03  SDTANNNO PIC'(1)9' 20 178 1×20=20
02 SDTABIKB PIC'(1)9' 198 1
02 SDTAZKIN PIC'(1)9' 199 1
02 SDTAZKI1 PIC'(1)9' 200 1
02 SDTAJIKB PIC'(1)9' 201 1
02 SDTABBKB PIC'(1)9' 202 1
02 SDTAHHTN PIC'(4)9' 203 4
02 SDTASPAC CHAR(14) 207 14
02 SDTAHEAD (集団項目) 221 340
03  SDTAMTTO (集団項目) 221 30
04   SDTAUNTI FIXED DEC(9) 221 5
04   SDTARYOK FIXED DEC(9) 226 5
04   SDTATTAX FIXED DEC(9) 231 5
04   SDTAHOKR FIXED DEC(9) 236 5
04   SDTAAAAA FIXED DEC(9) 241 5
04   SDTAATAX FIXED DEC(9) 246 5
03  SDTAYUNN CHAR(7) 251 7
03  SDTAYUNO PIC'(5)9' 258 5
03  SDTAJKAN (集団項目) 263 124
04   SDTAJKA1 CHAR(34) 263 34
04   SDTAJKA2 CHAR(38) 297 38
04   SDTAJKA3 CHAR(52) 335 52
03  SDTAJKNA (集団項目) 387 129
04   SDTAJKN1 CHAR(32) 387 32
04   SDTAJKN2 CHAR(47) 419 47
04   SDTAJKN3 CHAR(50) 466 50
03  SDTADTEL CHAR(12) 516 12
03  SDTABANK FIXED DEC(7) 528 4
03  SDTAKONO PIC'(1)9' 532 1
03  SDTAKOBA FIXED DEC(9) 533 5
03  SDTABAN1 FIXED DEC(7) 538 4
03  SDTAKON1 PIC'(1)9' 542 1
03  SDTAKOB1 FIXED DEC(9) 543 5
03  SDTATKB3 PIC'(1)9' 548 1
03  SDTATENK FIXED DEC(9) 549 5
03  SDTASPA2 CHAR(7) 554 7
  • SDTACKTT(47~50バイト目、PIC 4桁)は本PGでは参照しないが、後続の SORT4 の第3キーになる。KS60790P がこの値を店名取得ルーチン(LSS0051)に渡していることから、扱い店の店所コードと考えられる(KS60790 設計書 9章 No.12。当初の「締日関連」の推定を訂正)。
(1-1/2)