RE: Interactive vs. Batch

I've let this thread go in two directions at once, mostly because I can't
help but jump on the Interactive Feature soapbox.  My initial technical
questions were about tuning the system for jobs initiated from other
interfaces.  What I saw with the Lawson interface was that a client that ran
the same work as a terminal session was being configured as a batch job.
Web and client-server interfaces blur the lines between interactive work and
batch work.

Terminals originally ran in an interactive subsystem with their own classes,
priorities and memory pools so that would have dedicated resources.  The
principle was that work done from the terminal would have short bursts of
activity -- data entry, or enough database lookup and calculation to fill a
single inquiry screen.  The users' jobs would pause as the users read the
screen or moved to the next data entry item.  They were given a higher
priority so that could get processing on demand regardless of the batch jobs
that were running.

Do these principles apply in the web, database server, application server
world?  The Lawson GUI example may not be the best one, since it was written
purely to replace the 5250 session.

Still, if you've written a web form to do payroll time-card entry, or
account status lookup shouldn't it be tuned to an "interactive" priority, to
give it the response it needs when running against a data mining process or
a long running report?  Or is there something else in new application
architecture to cover this?

-----Original Message-----
From: Nathan M. Andelin
To: MIDRANGE-L@midrange.com
Sent: 4/20/01 10:31 AM
Subject: Re: Interactive vs. Batch

Jim,

It seems to me that IBM found it necessary to price client-server work
differently than traditional 5250 work.  From that point forward the
term
"interactive" took on new meaning.

Prior to client-server architecture, Interactive vs. Batch had much to
do
with work management (job priority, dedicated memory pools, maximum # of
active jobs, etc.).  Default system configurations allocated more system
resources to interactive work.

Now, in contrast, Web and other client-server jobs need the highest
priority, the most memory, etc.  The term interactive has taken on the
more
narrow meaning of a job that uses IBM's Workstation Manager.  Any CPU
used
by those jobs is subject to the "interactive feature" limits placed on
the
machine.

Nathan.


> From: Jim Damato <jdamato@dollargeneral.com>
> Subject: RE: Interactive vs. Batch
>
> Actually Steve, the Lawson GUI was what stirred up all of this for me.
> After purchasing hundreds of thousands of dollars worth of Interactive
> Feature we discovered that the Lawson GUI didn't use interactive CPW.
(We
> bought one of the first models to use Interactive Feature, and at the
time
> we, Lawson, IBM, and our business partner did not understand how to
size
for
> the cards.)  The GUI starts a sockets connection which is mapped to a
Lawson
> server program through a TCP/IP service table entry.  Each connection
> launches a server job on the AS/400 in a batch subsystem.  Lawson's
green
> screen presentation runs one presentation program with one display
file.
> All inquiry programs, prompts, entry, etc. operate through calls to
> application programs (RPG) which pass screen formatting information
back
to
> the presentation program.  The GUI's server job accomplishes the same
thing
> by calling the same application programs and passing the formatting
> information to the client.  The same formatting information is mapped
on
the
> green screen into fields and function keys, and mapped on the client
into
> form elements, pull downs, and buttons.
>
> Lawson took pride in explaining that their client was thin (it was
> positively obese from the installation and support side, but that's
another
> story) and that it required very little client processing resources.
I
> became confused as to why the same user actions and functions could be
> accomplished through a TCP/IP sockets connection and a batch job, and
yet
> required a small fortune in extra hardware to run them interactively
on a
> terminal or emulator.  This led to a two-year quest to get someone at
IBM
to
> admit that Interactive Feature was software licensing and that there
was
no
> productive technology on the cards (boy, you should have heard John
Sears'
> uncomfortable dodge when I asked him about it.)
>
> Nathan's web reference nails down IBM's definition very well, though
the
> definition still evades the whole truth.  "iSeries 400 or AS/400
Advanced
> Servers and AS/400e servers are intended for use primarily in
client/server
> or other non-interactive work environments. 5250-based interactive
work
can
> be run on these servers with limitations."  Just add the word
"contrived"
in
> front of the word "limitations."
>
> While we still had users thrashing between 5250 and the Lawson GUI I
notice
> that the GUI did not perform as well, so I changed the Lawson server
> subsystems, job descriptions, and classes to run GUI jobs at an
interactive
> level, and within the interactive pool.  This brought GUI job
performance
up
> to an interactive level.
>
> In the client-server, web-based, n-tier, whatever whatever, non-5250
> interface environment, do these issues come into play?  Are data
mining or
> SQL-reporting tool interfaces configured to batch-oriented work
management
> parameters, while inquiry, lookup, and data entry forms invoke a more
> interactive-type job?
>
> Interactive vs. Batch used to describe types of work being done on the
> system.  The terms have been co-opted to define a pricing structure.
In
the
> process do you think we've dumbed-down system tuning for these
different
> types of work, are the concepts still applied, or are they moot with
the
> newer interfaces?


+---
| 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
+---