# DAIMNT3J 移行設計書（バッチ設計書） 確認事項

| 項目 | 内容 |
|---|---|
| 対象資料 | バッチ設計書_DAIMNT3J_管理台帳作成.xlsx（表紙／改版履歴／バッチ概要／処理フロー／データフロー） |
| 突合せ基準 | JCL DAIMNT3J（原本）、DAIMNT3J_JOB仕様書.md、各プログラム仕様書（KS41000P／KS41010P／KS41020P／KS41030P／KS60350P／ND53500P） |
| 作成日 | 2026-10-26 |
| 関連資料 | 誤りの指摘は「DAIMNT3J_移行設計書_レビュー指摘.md」 |

## 凡例

| 区分 | 意味 |
|---|---|
| 【漏れ】 | 記述することになっている項目が、記載されていないもの |
| 【要確認A】 | 処理に必要な記載が欠けているもの（【漏れ】を除く） |
| 【要確認B】 | 処理結果は変わらないが、書き方に合っていないもの |
| 【要確認C】 | 移行に伴う意図的な変更の可能性があるもの、または前提が読み取れないもの |
| 【確認事項D】 | 軽微なもの（名称の誤記・表記ゆれ、使用テーブルの R/W の区分など）。対応は任意 |

- 現行のステップ番号（STEPn）は DAIMNT3J_JOB仕様書.md の通番（JCL の実行ステップを上から数えた番号）です。
- 指摘番号は「シート番号-連番」で、レビュー指摘（誤り）と通し番号です（シート番号：2＝改版履歴、3＝バッチ概要、4＝処理フロー、5＝データフロー）。

## 件数

| シート | 漏れ | 要確認A | 要確認B | 要確認C | 確認事項D | 計 |
|---|---:|---:|---:|---:|---:|---:|
| 改版履歴 | 0 | 0 | 0 | 0 | 1 | 1 |
| バッチ概要 | 0 | 0 | 0 | 2 | 2 | 4 |
| 処理フロー | 0 | 2 | 0 | 2 | 1 | 5 |
| データフロー | 0 | 1 | 2 | 3 | 1 | 7 |
| **合計** | **0** | **3** | **2** | **7** | **5** | **17** |

---

## 改版履歴

| No | 区分 | セル | 指摘内容 | 対応案 |
|---|---|---|---|---|
| 2-1 | 【確認事項D】 | AH1（機能名） | 機能名が「管理台帳作成」だけで、このジョブで行うＰＯＳメートの締日照合リストとエコデリバー用顧客アップロードデータの作成が名前から読み取れない。表紙・各シートのヘッダーもこのセルを参照する。 | 処理内容に合う名前にする（例：管理台帳作成・エコデリバー顧客データ作成）。 |

## バッチ概要

| No | 区分 | セル | 指摘内容 | 対応案 |
|---|---|---|---|---|
| 3-3 | 【要確認C】 | AS9〜AY9（DAIMNT3J_0090TD） | ＰＯＳメートマスター締日アンマッチリストがテーブル（TD）になっている。現行は帳票（SYSOUT=I、FA／165、ASA 制御文字付き）を直接出力している（JCL STEP19）。 | 帳票をどこで（日次処理のどのジョブで）出力するのかを書く。 |
| 3-4 | 【要確認C】 | AS5〜AS8（0010TD〜0080TD） | 管理台帳の中間データは、現行では可変長（委託料情報（１）がある顧客は 1500 バイト、ない顧客は 1200 バイト）。テーブルにしたときの「委託料情報なし」の表し方（NULL か空白か）が読み取れない。後続の KS43010（管理台帳更新）がこれを見て管理台帳のレコード長を変えるのかも分からない。 | 委託料情報の有無の表し方と、管理台帳への反映方法を書く。 |
| 3-5 | 【確認事項D】 | AY5〜AY8（論理名） | 0010TD・0030TD・0060TD・0080TD の論理名がすべて「管理台帳」で区別できない。 | 「管理台帳（店所情報付加前）」「管理台帳（住所情報付加前）」のように、どの段階のデータかが分かる名前にする。 |
| 3-6 | 【確認事項D】 | BN5〜BN8（R/W） | 0010TD〜0080TD がすべて「W」になっている。いずれも前のステップで書いて次のステップで読む中間データ。 | テーブルごとに R・W を見直す。 |

## 処理フロー

| No | 区分 | セル | 指摘内容 | 対応案 |
|---|---|---|---|---|
| 4-2 | 【要確認A】 | ステップ定義 全体 | ソート（現行 STEP2・6・10・14）がステップとして書かれておらず、どこで並べ替えるかが分からない。データフローにキーの注記だけがある。 | ORDER BY に置き換えるなら、どのステップのどの読み込み SQL で並べ替えるかを処理欄に書く。 |
| 4-3 | 【要確認A】 | ステップ定義 全体 | 中間データの削除（現行 STEP3・5・7・9・11・13・15・18 の事後削除、STEP20・22 の事前削除）に当たる処理が無い。現行は中間データが残っていると次回の作成で割振りエラーになるため、必ず削除している。 | 中間テーブル（0010TD〜0080TD、ND53500TD）を実行前にクリアするのか、実行後に削除するのかを決めて書く。 |
| 4-4 | 【要確認C】 | STEP0050（KS43010 管理台帳更新） | 現行に無いプログラムで、現行の「登録顧客コード順のソート → 管理台帳の削除・再定義 → 全件ロード（REPRO）」（STEP14〜17）に当たる。名前が「更新」で、全件を入れ替えるのか差分で更新するのかが読み取れない。差分の場合、顧客マスターから消えた顧客が管理台帳に残る。 | 全件入替えであることを処理欄に書く。差分更新にするなら、削除された顧客の扱いを書く。 |
| 4-5 | 【要確認C】 | U3、AK3 | クラス「R」・メッセージクラス「P」が JCL（CLASS=B、MSGCLASS=Q）と違う。 | Java 側の実行区分として意図的に変えたなら問題なし。 |
| 4-6 | 【確認事項D】 | U9（STEP0040 ステップ概要） | KS41030 のステップ概要が「住所情報の付加」で、STEP0030（KS41020）と同じ。KS41030 は請求先が所在地と異なる顧客の住所・郵便番号を請求先のもので上書きする処理。 | 「請求先住所情報の付加」にする。 |

## データフロー

| No | 区分 | セル | 指摘内容 | 対応案 |
|---|---|---|---|---|
| 5-4 | 【要確認A】 | 日次処理へ（図形 id=49・50、id=59・60） | 0090TD（締日アンマッチリスト）と ND53500TD（エコデリバー用顧客アップロードデータ）の行き先が「日次処理へ」だけで、どのジョブ・ステップが受け取るかが書かれていない。現行はどちらも本ジョブの中で出力（帳票・DB2 ロード）まで行っている。 | 受け取るジョブ名・ステップを書く（レビュー指摘 4-1、確認事項 3-3 と合わせる）。 |
| 5-5 | 【要確認B】 | コネクタ 全体 | 25本のコネクタに矢印が無く、入力と出力の区別が読み取れない。 | 入力は「ファイル → プログラム」、出力は「プログラム → ファイル」の矢印にする。 |
| 5-6 | 【要確認B】 | コネクタ 全体 | 25本のコネクタがどれも図形に接続されておらず（始点・終点とも未接続）、図形を動かすと線がずれる。 | 図形に接続し直す。 |
| 5-7 | 【要確認C】 | STEP0060 の入力ソート（図形 id=40） | 「POSQVKEY 昇順, POSFAXKB 昇順」のソートが追加されている。現行はソートせず、ＰＯＳメート・ＦＡＸサービス（VSAM）をキー順に読んでいる（JCL STEP19）。 | VSAM のキー順と同じ並びであることを確認する。違う場合は帳票の明細順が変わる。 |
| 5-8 | 【要確認C】 | ＰＯＳメイトマスタ VKPFSEQ（図形 id=42） | 現行の入力は VK32.SSPOSFAX.DTMASTER（DD 名 INFILE、ＰＯＳメート・ＦＡＸサービス）で、VKPFSEQ という名前は現行に無い。 | 同じデータであることを確認し、現行のデータセットとの対応を書く。 |
| 5-9 | 【要確認C】 | 顧客名前マスター更新データ DAIMNT3J_ND53500JD_INP（図形 id=54） | 現行は別ジョブが作る BACK.MASTMENT.DCUSTOM（顧客名前マスター更新データ）を読んでいる。新システムでこのテーブルをどのジョブが作るのかが読み取れない。 | 作成元のジョブを書く。 |
| 5-10 | 【確認事項D】 | 図形 id=42、id=41・48 | 「ＰＯＳメイトマスタ」と「ＰＯＳメートマスター」の表記がそろっていない。 | 表記を統一する。 |

---

# 参考：Java 化で現行の挙動を踏襲するか確認が必要な事項

| No | 現行の挙動 | 確認事項 |
|---|---|---|
| 6-1 | KS41000 は、請求・精算書ＮＯ．が 0 の顧客に「登録顧客コード＋'00000'」の12桁を補完する。 | 引き継ぐかを決める（KS41000P 仕様書 4.2 項番2.2）。 |
| 6-2 | KS41010 は SQLCODE が 0 かどうかしか見ず、DB2 エラーでも「店所情報なし」として正常終了する。 | エラー時に処理を止めるかを決める（KS41010P 仕様書 8章）。 |
| 6-3 | KS41020・KS41030 は住所名称３を切り捨てる（カナ 60→47 バイト、漢字 全角30→18文字）。漢字の前後にシフトコード（SO／SI）を付け直す。 | 桁数を引き継ぐか、新システムで全桁持つかを決める。 |
| 6-4 | KS41030 は住所ＤＢ２に該当がないとき、データ区分を初期化せず直前の顧客の値（1／2）が残る。 | 不具合として直す（0 にする）かを決める（KS41030P 仕様書 8章）。 |
| 6-5 | KS60350 は管理台帳に無い荷主を出力しない。ＰＯＳ側は請求締日の1件目だけ、管理台帳側は本締の締日だけを比べる。明細2行目の締日欄は本締でない欄をクリアせず、前の明細の締日が残る。 | 照合条件を引き継ぐか、締日欄のクリアを直すかを決める（KS60350P 仕様書 8章）。 |
| 6-6 | ND53500 は管理台帳の読込エラー（該当なし以外も含む）でも、その顧客を出力しないだけで正常終了する。出力条件は「請求・精算区分＝1 かつ 登録顧客コード＜8800000」。 | エラー時の扱いと出力条件を引き継ぐかを決める（ND53500P 仕様書 8章）。 |
| 6-7 | KS41000・KS41020・KS41030 は異常時に STOP で終わり、リターンコードを設定しない。JOB は COND=(9,LT) で後続を止める前提。 | 新システムでの異常終了の判定方法（終了コード）を決める。 |
| 6-8 | 管理台帳は削除・再定義してから全件ロードするため、その間は管理台帳を使えない。 | オンラインとの排他（停止時間）を新システムでどう扱うかを決める。 |
| 6-9 | ソートは EBCDIC の順（数字が英字より後）。 | ORDER BY の照合順序を合わせるかを決める。 |
| 6-10 | 帳票（締日アンマッチリスト）は ASA 制御文字・SO／SI 付きの全角文字を使い、18明細ごとに改ページする。 | 帳票の出力形式と文字コードの変換方針を決める。 |