幸塚 和久, 2026-10-26 03:08 午後
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明細ごとに改ページする。 |
帳票の出力形式と文字コードの変換方針を決める。 |
