Subject: Why do people set up their batch submission defaults to run
multiple batch jobs at the same time?
Ummm... maybe because since the System/3 model 15D the IBM midrange family
has understood that multiprocessing is a good thing?
I admit that it can be nice not to have to wait for another user to
notice his or her locked-up compilation job, but what if you've got two
batch-by-design jobs that could get into a fight with each other if
I wrote a command, years ago, called RUNALONE. It takes two parameters: the
(qualified) name of a data area; and the amount of time (max, seconds) to
wait. The command will create said data area if it doesn't exist, and then
will attempt to lock it. If it cannot obtain a *SHRNUP lock within the
requested time, it sends an escape message to its caller.
Now, if you have a batch job that you need to not run with other like jobs,
you can do
RUNALONE DTAARA(SYSCTL/SPECIAL1) MAXWAIT(600)
(for example) to ensure that no other job that locks the same object runs
concurrently. (Yeah, I know that RUNALONE is a misnomer.)
But frankly if your application cannot get along with other applications or
with itself, that's its fault, not the fault of a system administrator who
tried to tune for performance.
A quick look didn't reveal that program/command, but if anyone wants it I'd
be happy to write it again...
On a side note: "wait for another user to notice his or her locked-up
compilation job" - say, what? I don't think I've ever had a compilation
"lock up." Besides, jobs such as program compilations (if that's what this
is) should allow concurrence. Why in the world not? Are you saying that
you have only one job queue, and everything gets submitted to that?
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
What is a friend? A single soul dwelling in two bodies.
-- Aristotle
midrange.com
