一次定義幾百個GDG的正確方法

Question

我的網站中的一個做法是，當一個批循環開始時，我們分配新一代所有將在整個運行中使用的GDG，然後運行任何程序。

這意味着我們現在已經有了在我們的流程甚至開始之前分配超過500個文件的場景。我一直致力於試圖讓這個大規模循環更有效率。我不知道自己該走的路，這些配置：

• 運行1個巨大IDCAMS一步，使所有的新版本的一次（當前功能）
• 向下打破分配到多個IDCAMS的步驟，只分配文件的一部分

背靠背多次調用IDCAMS是否有太多頭腦？

我有一個預感，將這些分解成更小的步驟可以提高整體性能，但我並沒有真正明確的方法來測試它。我們的測試環境並不是一個真正的運行指標的好地方，因爲我們的工作通常在JES中以低優先級結束，所以我們得到很多反彈，所以經過的時間並不是真正發生實際情況的真實指示，因爲這些是IDCAMS分配，無論如何CPU數據總是很低。

TLDR;有誰知道哪個更高效，或者我怎麼能找到哪個更高效？

Answer 1

事實上，定義幾百個數據集並不是最適合現代z/OS系統的應用程序。每個分配都通過可預測的系統服務順序 - 目錄功能，分配功能，安全性，SMF日誌記錄等等 - 雖然確實存在細微的差異，但無論您如何做，每個分配都需要相當的時間。作爲一個經驗法則，典型的新文件分配在現代平均調整大型機上不應超過100毫秒。如果分配500個數據集花費的時間可能超過一分鐘，那麼您可能會遇到與使用IDCAMS無關的問題。

舉一個例子，你的工作可能會陷入一個低優先級的類中，一旦它消耗了一定的資源，就會耗盡資源......在這種情況下，它可能只是等待而不是被調度（一個簡單的計算的CPU時間除以經過時間會告訴你這是否是問題）。如果這是你的問題，那麼「欺騙」的一種常見方式是在JCL中定義GDG而不是通過IDCAMS ......你的JCL分配發生在批處理啓動器的優先級上，這通常比作業步驟本身更高。請記住，這意味着錯誤會導致JCL錯誤，而不是您可能從IDCAMS中的錯誤中獲得的非零返回代碼。

您可能還想檢查您的GDG基本定義 - 保留大量世代往往會減慢速度......也許您可以想出一個更好的方案來存儲更少的總代數。

要做的一件事就是確保你的系統程序員已經做好了正確調整事情的工作，尤其是目錄環境......有很多控制緩存，緩衝等參數，並且有適當的調整目錄是必不可少的，如果你想要好的表現this IBM document.有很多很好的信息大多數任務需要特殊授權，所以這可能是您自己無法處理的。

如果您實際上爲新數據集分配磁盤空間，那麼您還需要確保分配參數良好。例如，如果您將大量數據集放在同一個磁盤捲上，這將是一件壞事。分配會在卷級進行很多序列化，這意味着您可以將數據集分佈在多個磁盤捲上的次數越多，爭用的可能性就越小。您可以使用RMF之類的工具（或者您的網站可能擁有的任何供應商產品）來監控入隊延遲等 - 這通常是緩慢分配性能的罪魁禍首。

這是一個迭代過程，如果您真的想要有條不紊，請創建一個測試作業，分配一堆GDG文件並收集其上的性能統計信息。不同的分配參數和系統設置會爲您提供不同的吞吐量，您將想要回歸最佳組合而不是猜測。無論您經過多少時間，您都可以獲得CPU和I/O的服務單元計數，這些是確定最佳工作方式的最佳指南。

一旦您確信系統已正確調整且沒有不必要的延遲，下一個選擇就是您是否希望通過並行等技術更好地利用CPU利用率。你所做的主要是I/O綁定的工作，所以假設你的系統調整的很好，將你的單個作業分成多個作業，並擁有一部分文件將使用更多的處理器資源，但從運行時間觀點看法。最好的情況是當你用完處理器引擎，或者當你驅動目錄或磁盤到高利用率時。

只要您的站點允許它們並行運行（即具有足夠的批處理啓動器等等），只需將您的分配分配到多個作業中就可以實現並行的簡單路徑。如果你這樣做，並且所花費的時間並不比完成一項大型工作更好，那麼現在是時候深入研究爭論所在，正如我上面所解釋的那樣。

如果您需要一點冒險，並行執行大量分配的一個很好的方法是使用UNIX Services shell以及類似BPXWDYN而不是IDCAMS（確保將GDGNT標誌指定爲BPXWDYN）。如果正確完成，你可以編寫一個shell腳本來啓動任意數量的子進程，每個子進程都執行你的分配子集。正確配置，這具有在一個大地址空間中運行的優點，而不是需要多個地址空間才能實現並行性的批處理作業。