Re: Why do people set up their batch submission defaults torun multiple batch jobs at the same time?

On Fri, May 7, 2010 at 02:30, sjl <sjl_abc@xxxxxxxxxxx> wrote:

Lukas may be right, but /again/, in my opinion he seems to live in a very
idealized world.

For us, the IBM i is a strategic platform, not a legacy system that we
have to keep running until it finally gets replaced by SAP running on
Intel.

(I work for an ISV that develops an ERP software running on the IBM i)

In this particular instance, it sounded to me like James developed a
new piece of software that exhibited this behaviour - and I think
that's poor design.

ÂNot everyone can afford to continually upgrade their
system to the latest and greatest, but that is always seems to be /his/
solution when somebody reports a problem and they are back-level on the
hardware or O/S.

Keeping a system on current, supported hard- and software has always
been the right way to go to achieve reliability. It is that way when i
work on Windows systems, when i work on Linux systems, and when i work
on IBM i systems. You can't submit a PMR when you're still on V5R3.
And there's always something that needs fixing.

Designing a framework that prevents a particular program from running when a
potentially conflicting job is running is fraught with potential problems.

Not really. Some of our customers have internally developed, self-made
programs with such issues. I usually write a CL wrapper around them
that locks a file, and bombs when it can't. Problem workarounded, no
developer needed. The long-term solution is of course to have the
program looked over and fixed by one of our developers, or make sure
that the customers developers is up to speed on how create his
programs.

In most cases with legacy software [particularly in these lean times], it is

See - this is probably the main difference. I deal with customers that
have decided to run their business on this platform, keep running it
on that platform for the foreseeable future. They upgrade their
machines, their software (both IBM i and of course our ERP package).
We have some hardware-only customers where we just maintain their IBM
i, running legacy software that nobody fully understands anymore.
They're a different kind of customer, but they're a minority.

much simpler [and much cheaper] to know which jobs that need to run
single-threaded and make sure that they get submitted to a single-threaded
job queue and slap the hands of people who are moving jobs around.

You can do that too. It's just as much a workaround as a CL wrapper.