§H. 反論への先回り¶
想定される反論 4 件と回答。
反論 1: Change Tracker のような公式ツールがあるなら、本ツールを作る必要はないのでは?¶
回答
Change Tracker は priced feature + STC 常駐 + RACF プロファイル設計を要し、想定組織 (利用者単独〜5 人未満) では現実的に導入できない。
本ツールは Change Tracker の代替ではなく、Change Tracker を導入できない現場のための別製品である (§E-2 本ツールの位置づけ を参照)。
反論 2: Git 等の既存 SCM を運用資材にも適用すれば良いのでは?¶
回答
アプリ部門の SCM を運用資材まで拡張する案 (§G T8) は別検討事項である。
本資料は運用資材領域限定の検討であり、SCM 全面導入は本資料の射程外。SCM 拡張案は別途比較検討する余地がある。
反論 3: z/OS 側に何か置けば、もっと機能を実現できるのでは?¶
回答
本ツールは SSOT ① で「z/OS 側に常駐プログラム・データセット・追加ライセンスを置かない」を前提としている。
これは Change Tracker を導入できない現場の制約 (z/OS 設置物への運用工数・ライセンス費用を許容できない) を反映した設計判断であり、前提を緩めることは別検討資料の対象。
反論 4: PCOMM 経由の取得は時間がかかるのでは?¶
回答
§F T28 (大規模ファイル性能) で試作実測の課題として明示済み。
数千メンバ・数 MB 超では分割取得で対応する設計とする。標準的な運用資材 (数十〜数百メンバ規模) では PCOMM 標準速度で実用範囲と試算。
次ページ → §I 用語集