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

Hi

His world is no more idealized than (for instance) Rob's. I deal with a lot
of legacy software so I know where you are coming from; plenty of people
won't or can't upgrade.

I didn't read Lukas' reply as dismissing the idea of additional job queues,
rather I took it that he was commenting on the software design primarily
because the OP was making a comment about their own program being run
incorrectly. It seems reasonable to me to suggest to the creator of the
program that the solution lies with designing it in such a way so as to
prevent the problem.

Regards
Evan Harris


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of sjl
Sent: Friday, 7 May 2010 12:31 p.m.
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Why do people set up their batch submission defaults torun
multiple batch jobs at the same time?

Evan -

Lukas may be right, but /again/, in my opinion he seems to live in a very
idealized world. 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.

Designing a framework that prevents a particular program from running when a

potentially conflicting job is running is fraught with potential problems.

All I know is that when I worked in a MAPICS shop, we had a /bunch/ of DFU's

to update the system control file and other files to keep MAPICS from
telling us that we needed to restore all of the files because a job bombed.

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

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.

...or make them fix the resulting problems and they won't do it again.

- sjl