RE: Interactive vs. Batch (was Did IBM finally roll out SAA with Webs phere?)

Our Authorization is a real time transaction processing system.  It is base
on data queues.  There can be multiple occurrences of the SERVER jobs,
(running as batch jobs), waiting for entries in the data queue.  These jobs
run in a dedicated subsystem with dedicated memory and a run priority of 15.
There time slice varies from system to system according to the processor
speed.  They are truly batch jobs with interactive processing configuration.
We have several queue based interfaces which include interactive sessions,
X.25 ICF communications, TCP/IP Sockets and NT based remote data queues
which interface with our IIS web servers.

Christopher K. Bipes    mailto:ChrisB@Cross-Check.com
Operation & Network Mgr mailto:Chris_Bipes@Yahoo.com
CrossCheck, Inc.        http://www.cross-check.com
6119 State Farm Drive   Phone: 707 586-0551 x 1102
Rohnert Park CA  94928  Fax: 707 586-1884



-----Original Message-----
From: Jim Damato [mailto:jdamato@dollargeneral.com]
Sent: Thursday, April 19, 2001 8:16 AM
To: 'MIDRANGE-L@midrange.com'
Subject: Interactive vs. Batch (was Did IBM finally roll out SAA with
Webs phere?)


I've always thought that a job is a job is a job and that Interactive vs.
Batch was a much more arbitrary distinction these days.  The Interactive
interfaces (5250, Telnet, etc.) route jobs to Interactive subsystems, but I
always thought that AS/400 work management was the true factor in defining
interactive or batch job characteristics (priority, memory, time slice,
etc.).  The server models and then Interactive Feature cards seemed to
support this point of view since all the "feature cards" really do is place
inhibitors in the OS to restrict resources from jobs deemed interactive.

I always thought that if someone found a way to write a custom 5250 emulator
that used a different interface to invoke client-server type "batch jobs" we
could all get around Interactive Feature pricing.  Lawson's GUI already
practically does this.

Some of the questions and points on this list in the past weeks make me
think I've missed the boat in a big way.

Is there more to it than this?  I've never understood why all client-server
(or external interface) applications were deemed as "batch".  It seems to me
that if you've developed web apps that behave like batch jobs, performing
long streams of i/o or processing they should be batch tuned.  If you
develop web apps or client-server functions to replace traditional online
work (data entry, detail lookup) shouldn't the support jobs be tuned to
interactive-type parameters -- given better priorities, and exclusive pools
so that the bursts of OLTP type activity can grab the CPU from longer
running processes?

Am I wrong on any of this?  Is there a better way of looking at Interactive
vs. Batch?


-----Original Message-----
From: Nathan M. Andelin [mailto:nathanma@haaga.com]
Sent: Wednesday, April 18, 2001 11:22 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Did IBM finally roll out SAA with Websphere?


> From: "Bob Cozzi \(RPGIV\)" <cozzi@RPGIV.COM>

> Take the Webfacing tool, a very good idea. About 2 years ago
> it would have been gold! But it is still something to consider using.
> But here is the issue with webfacing. Webfacing runs applications
> as Interactive Apps. Not batch, so the line we've been fed to move
> off of Interactive and into better performing Client/Server apps
> (which use batch) doesn't seem to apply here.

We need to remember that part of the Webfacing solution runs under batch(the
part that runs under Websphere).  That begs the question, of the total CPU
time, how much is batch vs. interactive.  My estimate is that a "Webfaced"
app will use 30 times more CPU, and only 5% of that will be interactive.
Anybody have a better estimate?

Nathan.


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---