几天前遇到一个比较怪异的问题，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.
