I don't know if it is a general "problem" or only one around here (due perhaps to ignorance), but in most cases, a programmer cannot _easily_ add an "ad hoc" series of jobs to our CA7 system and schedule them. Not to mention that the programmers don't generally have that level of knowledge any way. I am not very JES3 literate, but I've heard that it solves this problem with DJC (Dependent Job Control). And, of course, not letting a job into an initiator when it would cause a "JOB WAITING FOR DATA SETS" message.
On Wed, May 1, 2013 at 8:44 AM, Joel C. Ewing <[email protected]> wrote: > Right. It's just not aesthetically pleasing to tie up a finite resource > before you can effectively use it. Murphy's Law and its Corollaries > suggest that if you adopt this as a customary and acceptable job design > practice, one "hung in wait" initiator this month will become ten hung > initiators several months down the road. > > The many complications involved in solving job dependency problems and job > scheduling problems is precisely why installations license job schedulers > and job restart managers (CA-7/11, ZEKE/ZEBB, and others) in a z/OS > environment. Isn't the real requirement usually much more complicated than > "job B must not proceed until job A completes"? Isn't it more likely that > you don't want job B to proceed until job A completes without a bad > condition code or an ABEND? About the only way you can easily do that > level of job dependency without a job scheduler is to have conditionally > executed steps at the end of one job submit the following job, and somehow > make the appropriate person aware of any failure in the process. > Joel C. Ewing > > On 05/01/2013 07:38 AM, Charles Mills wrote: > >> I am NOT a shop sysprog so take this with a grain of salt but my >> *impression* is that the number of initiators, and the classes served, is >> a >> decision based on the "tuning" of various factors. The decision process >> includes the assumption that a job runs for some moderate amount of time, >> consuming CPU and I/O as it goes. When you have a job that "sits there >> forever" you upset those assumptions. >> >> It's not that an "idle" job consumes some sort of precious commodity like >> memory or CPU cycles; it's that it constitutes a "mis-application" (if you >> will) of a member of a finite set. >> >> Charles >> >> -----Original Message----- >> From: IBM Mainframe Discussion List >> [mailto:[email protected].**EDU<[email protected]>] >> On >> Behalf Of R.S. >> Sent: Wednesday, May 01, 2013 7:53 AM >> To: [email protected] >> Subject: Re: Check whether job still running >> >> JOB2 will sit there and waste an initiator >>> until JOB1 (which is long running) ends. >>> >> What a waste! >> Hmm... what is the waste? >> How much does it costs? I'm serious: what real resources are wasted? CPU >> cycles? Memory? >> >> ... >> > > > -- > Joel C. Ewing, Bentonville, AR [email protected] > > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
