That's the solution
Also, back in the old days of the s36 when a lot of coding was done
You used to be able to evoke a job, which would not conflict with someone
else
... usually (many times things were based on a wsid or something unique)
You also used to be able to easily test to see if an occurrence of a job was
running
.... If Active ... and then wait or abort the job that's trying to run
Some of us left over from prehistoric times remember some of these
situations
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Harman, Roger
Sent: Thursday, May 06, 2010 4:36 PM
To: Midrange Systems Technical Discussion
Subject: RE: Why do people set up their batch submission defaults to run
multiple batch jobs at the same time?
If you have a job that truly needs to be single thread, run it out of a
single thread jobq. If not, run as many as you want either from multiple
single thread jobq's or a multi threaded.
We run JDE, Kronos, Infinium, Island Pacific, and home grown - all out of
different jobq's. No conflicts.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: Thursday, May 06, 2010 3:59 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Why do people set up their batch submission defaults to run
multiple batch jobs at the same time?
Lukas is right though.
His primary point was that if the application expects to run single threaded
it should ensure it or program against those situations where a second
instance starts.
That's not 'idealized' it's what the application has been designed to
expect.
Regards
Evan Harris
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of sjl
Sent: Friday, 7 May 2010 10:42 a.m.
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Why do people set up their batch submission defaults to run
multiple batch jobs at the same time?
Lukas -
No offense intended, but life in your idealized world is not as easy as it
is in the real world. Most AS/400 - iSeries - System i - IBM i shops are
running code that was written over 20 years ago, and have no intention of
'fixing' it to match your conception of 'right'.
- sjl
Lukas wrote:
No. Proper program logic should ensure that something like this can't
be destructive - running the same job twice should result in a "job x
is already running" message. This can be achieved by proper locking.
Forcing a single-batch job to fix problems in the application logic..
Well, it works - but it's a workaround, not a proper solution.
What can be a reason for running only a single batch job can be
performance, but this is going to be less and less of an issue...
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system. (Knotts Berry Farm - Cedar Fair L.P.)
midrange.com
