On 1/11/2013 1:32 PM, Mark Zelden wrote:
I'm not in love with BPXWDYN as much as you - only because I haven't
used it that much, but I'll keep that in mind if / when I have to make
any major updates. All the random DD code predates BPXWDYN
and of course what works in one of my execs is easily cut/pasted
into another one. :-)
We re-engineered all of our TSO/E logon execs to use BPXWDYN instead of ALLOCATE
a while back. This was needed to get around the hard-wired DYNAMNBR=100 limit
for z/OS UNIX forked procedures. (I mentioned this restriction and solution in a
SHARE Bit Bucket session -- perhaps Atlanta.)
Just this week I discovered a _major_ drawback to BPXWDYN. If OMVS is not up,
BPXWDYN will issue the following message and then WAIT for OMVS to initialize:
BPXP022E ONE OR MORE JOBS ARE WAITING FOR UNIX SYSTEM SERVICES AVAILABILITY.
OMVS would not come up on one of our images this week because ZFS wouldn't come
up because of some missing toleration APARs/PTFs on the back-level systems in
the sysplex. Using TSO/E ALLOCATE I can logon to TSO/E on the "problem" image,
use ISPF, submit jobs, etc. even while OMVS is down. Using BPXWDYN the TSO/E
session just hangs dead. :(
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
