Granted, production job schedulers are not a good fit if this is a one
time job sequence from an application programmer or from some other user
who would rightly lack update access to or full understanding of
production control. If it is a frequently used job sequence and the
user only needs to control when it is initiated and perhaps supply data
to the jobs, then there are reasonable ways to put the jobs under a job
scheduler and production control and give the application person a way
to supply data and initiate the job sequence.
If this level of job control is a persistent need by application
programmers or other users for one-time job sequences, I would create
canned JCL examples and/or PROCs and documentation showing how to
submit "next job" JCL from a user-supplied data set or PDS member from
within another job, with examples of how to use IF-THEN-ELSE JCL to
conditionally fire the next job and send a message to the user if that
were skipped. As long as you steer clear from trying to use in-stream
JCL data to supply the next job JCL (which quickly becomes confusing as
to which JCL goes with which job) and instead get the JCL from a data
set, this is not a complicated process to document, and would seem to be
a far simpler, more efficient, and safer solution than relying on data
set enqueues or tying to ascertain the status of one job from another.
This potentially means that a follow-up job may end up further down in
the input queue than if submitted at the same time as the first job, but
I suspect other users of the system would consider that "more fair" if
they were competing for the same initiators.
JC Ewing
On 05/01/2013 09:43 AM, Farley, Peter x23353 wrote:
Not just your shop, John. Access to actually create or modify a job schedule
here is restricted to operations personnel. IMHO, a real production scheduler
is usually way overkill for a programmer wanting to set up a few ad-hoc job
sequences, not to mention that (in my experience) companies don't usually
bother to teach programmers how to use production schedulers anyway.
The comment earlier in this discussion (or the other similar thread) about
changing the DUPEJOB setting for JES2 to allow duplicate-named jobs to execute
simultaneously would be entirely counter-productive here, since submitting your
series of 10 compile and link jobs (all with the same job name) would entirely
flood the few initiators permitted for this purpose, locking out all the other
hundreds of programmers from that scarce resource. One duplicate at a time
measures out a very scarce resource in the fairest manner, or at least in *a*
fair manner.
Still, it would be nice to have the JES3 job networking capability. Not likely
to go JES3 here though.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of John McKown
Sent: Wednesday, May 01, 2013 10:05 AM
To: [email protected]
Subject: Re: Check whether job still running
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.
...
--
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
