RE: At the risk of sounding like an AS/400 rah-rah...

The original point was:

"AND we can't run production batch jobs until
our client service center goes down for the day, because of the
negative impact the batch jobs have on the service center screens."

I don't know exactly what this guy is talking about -- it could be processor
contention, DBMS contention, or record locks.  I think a well written
application can deal with record locks to allow batch updates and online
processing to coexist reasonably.  I think that a well configured database
installation can address the database contention issues.  I think that on
any system you can isolate batch processing requirements from online
processing demands.  Both DBMS and processor contention issues can often be
traced back to either poor sizing of hardware or poor configuration.

All of these issues can be dealt with through system administration,
database administration, and/or application design on any platform.  Which
platform makes it easiest by far is another matter entirely...

-Jim

-----Original Message-----
From: James Rich [mailto:james@eaerich.com]
Sent: Friday, January 17, 2003 12:56 PM
To: Midrange Systems Technical Discussion
Subject: RE: At the risk of sounding like an AS/400 rah-rah...


On Fri, 17 Jan 2003, Joe Pluta wrote:

> > Well, that batch problem is something we have on the AS/400 too.  When
we
> > run our end of day processing, no one can be logged into the
> > system because if any records are open the cycle won't run.
>
> Batch jobs colliding with online users is just a fact of data processing
> life.  The point is that on the AS/400, you can schedule jobs to be run
> unattended when nobody is on the machine.

And this ability (to schedule jobs to be run unattended when nobody is on
the machine) is not unique to the AS/400.

James Rich