幾天前遇到一個比較怪異的問題，5個ACCESS DB的程序依次提交運行，最後一個程序總是 fail掉，報錯信息是DSNE100I DB2 V91B NOT OPERATIONAL, RETRY COUNT IS ZERO。看起來很像達到了DB2最大連接數，再過來的連接就不響應了。。。但是才5個thread而已，大牛們正在解決...等待
處理這個問題之前，需要明白幾個概念：
JES:Job entry subsystem.The program or task that maintains a spool environment, and through which programs and operators access that environment.
JES2:One of two job entry subsystem avaliable for MVS systems.Originally based on the Houston Automatic Spooling Priority system(HASP).
Initiator：A system routine that loads a job into an address space. The number of active initiators is an indicatior of the number of batch programs that can run concurrently on a system
現在看着這個問題就很簡單，主機平臺的程序都是通過JOB提交運行，那麼processing這個JOB的時候需要Initiator來處理，如果系統上的Initiator數量不夠，那麼一種情況就是等待Initiator，另一種情況就是利用其他LPAR上的Initiator。上述情況就是BJ22和BJ21共享一個JES2，那麼BJ22這個LPAR上Initiator數量達不到當前並行處理的需要時，就會利用BJ21上的Initiator，但是BJ21上並沒有V91B這個DB2 Subsystem，那麼返回DSNE100I DB2 V91B NOT OPERATIONAL, RETRY COUNT IS ZERO就太正常了。
那怎麼才能讓自己的JOB無論何時都只用自己LPAR的Initiator，而避免上述情況呢？
在JOBCARD下面加上這個參數/*JOBPARM SYSAFF=LPARname，這樣job就只會等待指定LPAR的Initiator了。如果LPAR上的Initiator資源不夠，需要系統管理員start 一些新的Initiator。命令爲$s.
