On Thu, 21 Apr 2011 14:25:30 +1000, Wayne Bickerdike wrote: >I guess that answers Paul's question. However, the application I'm >referring to was c. 1978. I'm sure we have many more ways to skin cats >these days except we are stuck with 255 steps and some number of DD >statements too. > The TASKLIB approch mentioned by Gerhard is pretty conventional. I was imagining coalescing multiple steps, which might have different STEPLIB requirements, into one superstep. But different TASKLIBs satisfy the requirement.
My sarcastic mention of punched cards was by analogy with the 255-step limit. They represent the same level of technology. Hardware designers were able to surpass the limitation to punched cards, but software designers appear to be unable to surpass 255. >Of course in 1978 we all thought that JCL would disappear and all jobs >would be "online". > I'd use Rexx for this if: o I could ENQ SYSDSN with WAIT in anticipation, to preclude deadlock. o I could easily invoke APF-authorized programs. Well, runing under IKJEFT?? provides most of this. (Why doesn't batch TMP provide a way to electively set RC for the step?) o I could build multi-data-set tapes starting with a nonspecific VOLSER with the power of JCL. I once did this in Rexx, scanning the TIOT (Thanks, Steve Bacher) for the volser of the first data set, and specifying that in the BPXDYN() for following data sets. (I had to persuade my sysprog te allow me to DYNALLOC tapes.) Then it dismounted, remounted, and repositioned the tape for each data set. Yuck! I want DYNALLOC RETAIN,VOL=REF. >On Thu, Apr 21, 2011 at 12:08 PM, Gerhard Postpischil wrote: >> >> By function, if not by name. I have a test task, loaded from STEPLIB. When a >> LOADLIB DD is present, it attaches the program to be tested using LOADLIB as >> a TASKLIB, providing STEPLIB functionality with a different DD. On Wed, 20 Apr 2011 23:06:44 -0400, Robert A. Rosenberg wrote: >>> >>If JOB 3 allocates a data set on YYYY in its ordinary processing, >>is the IEFBR14 step unnecessary? > >It is not. I only mentioned it due to my impression that the original >statement stated (or at least implied) a desire/need for the volume >to already be online for use by JOB3 before it started. My >intervening JOB2.5 insures that when it is started, JOB3 is able to >start running with no delay (such as the need to vary the volume >online/etc.). > So, instead of JOB3 hogging an initiator (other resources?) while it WAITs for operaton intervention, JOB2.5 WAITs for operator intervention and hogs the initiator. (But at least it doesn't hold ENQs for that time.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
