DAISEQ4J Java移行バッチ設計書 レビュー指摘一覧【第2版】¶

項目	内容
対象資料	DAISEQ4J Java移行バッチ設計書（Excel：表紙／改版履歴／バッチ概要／処理フロー／データフロー）
突合せ基準	JCL（DAISEQ4J）原本、DAISEQ4J 詳細設計書（JOBフロー）【第2版】、各プログラム詳細設計書
作成日	2026-10-13
版	第2版（JCL原本との再突合せ結果を反映）

凡例¶

区分	意味
【誤り】	JCL・ソースと明確に食い違うもの
【漏れ】	記載が欠落しているもの
【要確認】	Java化に伴う意図的な変更の可能性があるもの

JCLのステップ番号は、コメント行（//*で始まる行）を除いた実行ステップを、上から順に数えた番号です（JOBフロー詳細設計書と同じ番号）。

重要指摘（優先対応）¶

影響が大きいのは次の5点です。

1. 処理フロー STEP0010 で、入力の 0510 を最初に削除している（No.2-3）。このままでは処理対象が0件になります。
2. データフローのKS60790の出力先の取り違え（No.4-11）
3. 処理フローのJOB名（No.2-1）
4. KS60790の入力ソート（SORT4）のキー（No.4-10）
5. 共通データソート（No.5）のキー（No.4-7）

指摘件数サマリ¶

シート	【誤り】	【漏れ】	【要確認】	計
改版履歴	0	0	1	1
処理フロー	3	3	4	10
バッチ概要	2	3	1	6
データフロー	7	11	3	21
合計	12	17	9	38

---

1. 改版履歴シート¶

No	区分	指摘内容	正しい内容・対応案
1-1	【要確認】	機能名（AH1）が「請求書　請求明細ＦＴＰ」になっている。本JOBにFTP処理は無い。表紙・各シートのヘッダーもこのセルを参照しているため、全シートに波及する。	JCLの見出しは「請求・精算書の処理（４）請求明細データ処理　通常日用」。中身は請求書・請求一覧の帳票作成とCSV作成なので、機能名をそれに合わせる。

---

2. 処理フローシート¶

2.1 ヘッダー部¶

No	区分	指摘内容	正しい内容・対応案
2-1	【誤り】	JOB名（E3）が DAIMNT3J になっている（別JOBからの流用残りと思われる）。機能ID（U1）は DAISEQ4J で、シート内でも食い違っている。	DAISEQ4J
2-2	【要確認】	クラス（U3）「R」とメッセージクラス（AK3）「P」がJCLと異なる。	JCLは CLASS=B / MSGCLASS=Q（ほかに REGION=6144K、COND=(9,LT)、PERFORM=1）。Java側の実行区分として意図的に変えたのであれば問題なし。

2.2 ステップ定義¶

No	区分	指摘内容	正しい内容・対応案
2-3	【誤り・重大】	STEP0010 が「全送り状データワークテーブル（DAISEQ1J_0510TD）」を最初に削除している。0510 は STEP0020（KS60130）の入力で、別JOB（DAISEQ1J）が作成するデータ。先に削除すると処理対象が0件になる。	JCLの事前削除（No.1）は 0600・0610・0620・0630・0631・0632・0641 だけで、0510 を消すのはJOBの最後（No.33、「ＤＡＳＤ３０圧迫のため」）だけ。STEP0010 から 0510 を外す（STEP0210 で削除しているのは正しい）。
2-4	【誤り】	STEP0010 の処理欄で「全送状ワークデータ」が2回重複している。	0610 の1回に直す。JCLの 0620 を 0610 に統合したために重複した可能性がある（2-8参照）。
2-5	【漏れ】	ソート（JCL No.2、No.5、No.16 SORT1、No.19・20 SORT2、No.21 SORT3、No.24・26 SORT4）がステップとして書かれていない。キーはデータフローに注記されているが、処理フローからは並べ替えが行われる場所が分からない。	ORDER BY に置き換えるなら、どのステップのどの読み込みSQLで並べ替えるかを処理欄に明記する（キーの誤りは 4.2 で指摘）。
2-6	【漏れ】	CSVファイルの事前削除（JCL No.28、SCRATCH SEAD.DAISEQ4J.CSV）に当たる処理が無い。KS60630 の CSVFILE は DISP=(NEW,…) なので、JCLでは前回のCSVを消してから作り直している。	前回のCSVが残っているときの扱い（上書きか、削除してから作成か）を STEP0200 または独立したステップで定義する。
2-7	【漏れ】	MVSCMD（JCL No.30・31：F AUTO1,ASVQ803 と F AUTO1,ASVQ808）が無い。JCLのコメントは「HOLD ｶｲｼﾞｮ SQV803,SQV808」で、後続のジョブのHOLDを解除している。	Java側のジョブスケジューラで後続ジョブの起動条件として置き換えるのか、廃止するのかを決めて記載する（設計者の吹き出し「AUTOのHOLD解除は不要か？」の答えは4.5を参照）。
2-8	【要確認】	JCLの 0620（No.5 でソートした後の共通データ）が 0610 に統合されている。JCLでは KS60144（1回目）、KS60135、KS60770 の3プログラムが 0620 を読む。	統合自体は可。この3プログラムの読み込みSQLで、No.5 と同じ並び順（4-7）を保証することを明記する。
2-9	【要確認】	STEP0210 が最後に 0610 を削除している。	JCLの最終削除（No.32）は 0600・0610・0630・0631・0632・0635 で、0620 は削除していない。そのため、正常終了の後でも No.7 以降からやり直せる。この設計では 0620 に当たるデータが残らないため、その再実行性が失われる。0620 を他のJOBが参照していないかを含めて、運用要件として確認する。
2-10	【要確認】	STEP0140（0100TD の削除）と STEP0160（0110TD の削除）が、JCLに無い。どちらも STEP0100 で削除済みのため、通常は重複処理になる。	KS60780 から再実行するための意図的な追加であれば問題なし。その場合は、目的（再実行時のクリア）を処理欄に書く。

---

3. バッチ概要シート（使用テーブル）¶

No	区分	指摘内容	正しい内容・対応案
3-1	【誤り】	DAISEQ1J_0510TD が「W」になっている。	本JOBでは入力として読んだ後に削除するだけ（作成は DAISEQ1J）。「R」（削除を区別するなら R＋D）。
3-2	【誤り】	すべてのテーブルが「W」で、読み込みと書き込みが区別されていない。	例えば 0610 はJOB内で書いてから読むので R/W、0635 は KS60144 が W で KS60151 が R、など。各テーブルの区分を見直す。
3-3	【要確認】	DAISEQ4J_0152TD「帳票出力中間テーブル」が処理フローにもデータフローにも出てこない。	不要なら削除する。KS60151 や KS60152 の帳票出力で使う中間テーブルであれば、使用ステップを追記する。
3-4	【漏れ】	参照マスターが一覧に無い。	RDTENS（VKTENMS の置き換え）、VKCHINM、VKSYUPR、VKSEQSK、VETENCD、VKBANKM、MDMIKAN、VKCORPO、VKKANBS、VKKONAM、それに ALTFILE／TRYFILE（ADG.ALTLIB の各メンバー）を追記する。
3-5	【漏れ】	KS60750J 系のソート結果に当たるテーブル（0020、0060、0080、0090、0120、0130）と、DAISEQ4J の 0620 に当たるものが無い。	ORDER BY で置き換えて不要にするなら、その旨を記載する。
3-6	【漏れ】	出力CSV（SEAD.DAISEQ4J.CSV）が使用ファイルとして記載されていない。帳票の出力先（ライター名 KS601511／12、KS601521〜23、KS607901／02）も無い。	出力ファイル・出力帳票として追記する。

---

4. データフローシート¶

4.1 ボックスの名称¶

No	区分	指摘内容	正しい内容・対応案
4-1	【誤り】	KS60750 のボックス名が「新請求書電子帳票出力（エコデリバー）[KS60750]」になっている（KS60152 の名前をコピーしたものと思われる）。処理フローの STEP0110 とも食い違っている。	「顧客法人管理マスター　郵送依頼店セット顧客出力」（JCLのコメントと同じ）
4-2	【誤り】	0110 のボックス名が「請求明細ヘッダーワークデータ1」になっている。0100 と同じ名前で、バッチ概要（「…ワークデータ2」）とも食い違っている。	「…ワークデータ2」
4-3	【要確認】	0700 の「ECOデリバリー版」という表記が、ほかの箇所の「エコデリバー」と揃っていない（バッチ概要も同じ）。	表記を統一する。
4-4	【漏れ】	CSVFILE のボックスに出力先が書かれていない。	SEAD.DAISEQ4J.CSV（またはJava側の出力パス）
4-5	【要確認】	店所マスターの名前が統一されていない。KS60144・KS60790 では「店所基本情報ＤＢ２ RDTENS」だが、KS60151・KS60152 の周りだけ「DDP店所マスター VKTENMS」になっている。	どちらもJCLでは同じ VKAD.CENTENMS.DTMASTER。Java側の参照先を RDTENS に統一するのであれば、ボックスも RDTENS にそろえる。

4.2 ソートキー¶

4-7 【誤り】共通データソート（JCL No.5、0610→0620、四角形 id=4）のキー¶

JCL：SORT FIELDS=(5,21,CH,A,37,1,CH,A,26,11,CH,A,38,1,CH,A,39,2,Y2P,A,40,3,PD0,A,43,7,CH,A)

順	Excelのキー	正しいキー（JCL No.5）	データ部の位置
1	顧客名 [SDTAKKKK]	配信店 SDTASHTN（4）＋予備 SDTAKKKK（10）＋請求先番号 SDTASQNO（7）	1〜21
2	請求精算書ＮＯ [SDTASQNO]	データID（SDTADTID）の十の位	33
3	データID [SDTADTID]	区分 SDTASPA1（明細では SDTBPSEQ）	22〜32
4	仮本締区分 [SDTAKARI]	データID（SDTADTID）の一の位	34
5	デパート区分 [SDTADPKB]	明細の年月日 SDTBYYMD の年（Y2P）	35〜36
6	年月分 [SDTAYYMM]	同じ年月日の月日（PD0）	36〜38
7	発行年月日 [SDTAHYMD]	元着区分＋送り状番号 SDTBMOCH・SDTBOKRN	39〜45

データ部の位置は、可変長レコード（VB）のRDW（4バイト）を除いた位置です（JCLの指定位置から4を引いた値）。

Excelの問題点は次のとおりです。

• 先頭キーの SDTASHTN（配信店）が抜けている。
• SDTAKKKK は「顧客名」ではなく予備項目。
• DTID を十の位と一の位に分け、その間に区分を挟むという特殊な並び順が反映されていない。
• KARI・DPKB・YYMM・HYMD は見出しレコード（ID 00）の項目名。明細レコードでは同じ位置に年月日・送り状番号が入っており、キーの意味が違う。この並び順は KS60144 の印刷順（請求先 → 区分 → 日付 → 送り状）の前提なので、誤ると帳票の並びが変わる。

4-8 【漏れ】SORT1（JCL No.16、0010→0020、SORT FIELDS=(8,7,CH,A)）の注記が無い¶

0010 から KS60760 に直接つながっている。KS60760 は集約代表コード（固定長レコードの8〜14桁目）の順に並んだ入力を前提にしているので、「集約代表コード 昇順」の注記を追加する。

4-9 【誤り】SORT3（JCL No.21、0050→0090、四角形 id=26）のキー¶

項目	Excelのキー	正しいキー
キー	顧客コード [OUTKOCD] 昇順	請求先番号 SDTASQNO 昇順（SORT FIELDS=(19,8,PD,A)）
データ部の位置	－	15〜22（SDTASQNO は 15〜21。22 は区分 SDTASPA1 の先頭バイト）

キーが1バイト長いのは、現行JCLの特性です。Javaで ORDER BY SDTASQNO にすれば実害はありませんが、移行設計書に注記しておくのが望ましいです。

なお、四角形 id=30（0030 の近く）と id=230（0040 の近く）の「顧客コード[OUTKOCD] 昇順」は、SORT2（No.19・20、SORT FIELDS=(1,7,CH,A)）のキーとして正しい。

4-10 【誤り】KS60790 の入力ソート（SORT4、JCL No.24・26、四角形 id=224・229）のキー¶

JCL：SORT FIELDS=(33,4,CH,A,26,7,CH,A,51,4,CH,A)

順	Excelのキー	正しいキー	データ部の位置	判定
1	請求精算書発行店 [SDTASHTN]	SDTASPA1 の後半4桁＝代表扱い店（KS60780 が設定）	29〜32	キーが誤り
2	荷主・着店コード（SDTASPA1 前半7桁）	SDTASPA1 の前半7桁＝集約代表コード（KS60780 が設定）	22〜28	位置は正しいが、意味（項目名）が誤り
3	着店コード（SDTACKTT / SDTASPA1 後半4桁）	SDTACKTT＝扱い店	47〜50	2つの項目が混在

4.3 入出力の関連（コネクタ）¶

4-11 【誤り・重大】KS60790 の出力先（帳票ライター名）の取り違え¶

経路	Excel	正しい出力先（JCL）
STEP0180（入力 0100）	KS607901	KS607902（事業所用配信）：0030 → SORT2 → 0060 → KS60780 → 0100 → SORT4 → 0120 → No.25 KS60790
STEP0190（入力 0110）	KS607902	KS607901（エコデリバー用配信）：0040 → SORT2 → 0080 → KS60780 → 0110 → SORT4 → 0130 → No.27 KS60790

このままでは、帳票の配信先が事業所用とエコデリバー用で逆になる。

4-12 【漏れ】コネクタに矢印が無い（データフロー全体）¶

コネクタ46本のどれにも矢印（矢じり）が設定されていない。そのため、マスター（入力）とワーク（出力）の区別が図から読み取れない。

• 例：KS60750 と VKCORPO、KS60760 と VKSYUPR、KS60780 と 0030・0040 は、どれも「プログラム → マスター／ワーク」の向きに線が引かれているが、実際はどれも入力。
• 入力は「ファイル → プログラム」、出力は「プログラム → ファイル」の矢印にする。

4-13 【漏れ】KS60630 の入力が無い¶

KS60630 の入力 062S（DAISEQ4J_062STD）からの線が無い。JCLの INFILE は TEMP.DAISEQ4J.WORK062S。

4-14 【誤り】どこにも接続されていないコネクタ¶

コネクタID	位置から推定した本来の接続	状態
5	0510 → KS60130（入力）	線は描かれているが、始点・終点ともに図形に接続されていない
10	KS60130 → 0610（出力）	同上
116	KS60750 → 0010（出力）	同上

このため、KS60130 の入出力と KS60750 の出力が、図の上では無いのと同じになっている。図形に接続し直す。

4.4 参照マスター・入力ファイル（プログラム別の突合せ）¶

表の列の意味は次のとおりです。

• 「接続あり」：Excelで線までつながっているもの
• 「配置のみ」：ボックスはあるが線が無いもの
• 「未記載」：Excelに無いもの

No	プログラム（JCL No.）	JCLの参照DD	接続あり	配置のみ	未記載	区分
4-15	KS60130（No.3）	VKCHINM、VKSYUPR	VKSYUPR	VKCHINM	－	【漏れ】
4-16	KS60144（No.8・No.12）	VKSEQSK、VKTENMS、VETENCD	RDTENS	－	VKSEQSK（印刷照会マスター）、VETENCD（SEAD.TENSCODE.CDMASTER）	【漏れ】
4-17	KS60151（No.9）	ALTFILE（ADG.ALTLIB(SEQPRTNC)）、VKTENMS、VKBANKM、VKSYUPR、MDMIKAN	VKSYUPR	VKTENMS、VKBANKM	ALTFILE、MDMIKAN（VKAD.MISYUKAN.DTMASTER）	【漏れ】
4-18	KS60135（No.11）	TRYFILE（ADG.ALTLIB(SEQTRYTN)）	－	－	TRYFILE	【漏れ】
4-19	KS60152（No.13）	ALTFILE、VKTENMS、VKBANKM、VKSYUPR、VKCORPO、MDMIKAN	VKCORPO	VKTENMS、VKBANKM、VKSYUPR	ALTFILE、MDMIKAN	【漏れ】
4-20	KS60790（No.25・No.27）	VKKANBS、VKTENMS、VKBANKM、VKKONAM、VKCORPO、VETENCD	RDTENS	VKBANKM、VKCORPO、VKKANBS	VKKONAM（荷主名マスター）、VETENCD	【漏れ】
4-21	KS60790（No.25・No.27）	（上と同じ）	－	VKCUSTM（顧客マスター（基本情報））	－	【要確認】JCLに無いマスター。誤記か、Java化での置き換えかを確認する。
4-22	KS60630（No.29）	VKSYUPR、VKCORPO、INFILE（062S）	VKCORPO	VKSYUPR	INFILE（4-13）	【漏れ】

KS60750（VKCORPO）と KS60760（VKSYUPR）は、JCLと一致しています（矢印が無い問題は 4-12）。

4.5 設計者の吹き出しへの回答（参考）¶

吹き出し	回答
「AUTOのHOLD解除は不要か？」	必要。JCLは KS60630 の後に MVSCMD で F AUTO1,ASVQ803 と F AUTO1,ASVQ808 を発行し、後続の SQV803・SQV808 のHOLDを解除している。Java側では、ジョブスケジューラで後続ジョブの起動条件（先行ジョブの完了など）に置き換える必要がある（2-7）。
「WORKテーブルの削除は不要か？」	必要。JCLは最後に 2 回削除している。No.32 で DAISEQ4J の 0600・0610・0630・0631・0632・0635 を削除し、その後の No.33 で DAISEQ1J.WORK0510 を削除する（コメントは「ＤＡＳＤ３０圧迫のため、DAISEQ1J.WORK0500 から再作成可能」）。処理フローの STEP0210（0610・0510・0635 の削除）が、これをJava側で過不足なく置き換えている。データフローに描かれていないだけ。ただし 0620 の扱いは 2-9 を参照。

---

5. Java化設計として決めておくべき事項（参考）¶

誤りではありませんが、移行設計の段階で「現行の挙動を再現するか、直すか」を明記しておくべき点です。

No	対象	現行の挙動	決めるべきこと
5-1	KS60780	1対1のマッチングのため、同じキーが複数あると2件目以降が突き合わされない。	現行の挙動を引き継ぐか、直すか。
5-2	KS60790	TEN_NAME_RTN が店名を先頭14文字で切っている。	現行仕様を引き継ぐかどうか。
5-3	KS60790	421件目以降の請求先は一覧に載らないが、合計には含まれる。	現行仕様を引き継ぐかどうか。
5-4	共通	明細を印刷しない請求先の判定が、プログラムごとに一貫していない。	判定をそろえるかどうか。
5-5	共通	ソートは EBCDIC の文字コード順（数字が英字より後）。	ORDER BY の照合順序を EBCDIC 順に合わせるかどうか。合わせないと、英数字が混じるキーで並び順が変わる。
5-6	共通	EBCDIC（CCSID 930）のシフトアウト・シフトイン付き全角文字や、ASA 制御文字を使っている。	文字コードの変換方針（帳票・CSV の桁ずれ防止）。

---