On Jan 12, 2013, at 00:26, Edward Jaffe wrote: > 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
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
