RE: Interactive vs. Batch -- MIDRANGE-L

The link provided by Nathan Andelin defines the types of jobs that will be
classified as interactive:

o All 5250 sessions  
o Any green screen interface  
o Telnet or 5250 DSPT workstations  
o 5250/HTML workstation gateway 
o PCs using 5250 emulation  
o Interactive program debugging  
o PC Support/400 work station function  
o RUMBA/400 
o Screen scrapers  
o Interactive subsystems  
o Twinax printer jobs 
o BSC 3270 emulation  
o 5250 emulation  


>The interactive feature card allowed jobs deemed as interactive to run on
the system at a slower speed?

Yes, a normal "server model" AS/400 inhibits interactive jobs (robs them of
CPW) through artificial means -- a governor in the OS.  You buy back
interactive CPW through Interactive Feature cards.


> Without the interactive feature, could you telnet, client access thru the
network and signon to the system? at full speed?

No, any Telnet, 5250, 3270, or other terminal or emulator session becomes an
interactive job.


>Lawson gui runs on the pc?  No client access or telnet?  Uses tcp/ip
sockets
to connect to the as400?

True.


>The lawson gui server on the as400, it runs a job for every gui client?

Yes,  The GUI server consists of a subsystem and a server job.  When you
connect, the server job launches a batch immediate job specific to your GUI
connection.  Within the job log you can see the program calls pertaining to
your options and selections from the GUI.  If you run reports the spool
files or submitted jobs will be associated with this job.


>The gui server job on the as400, it runs the appl rpg pgms? Those rpg pgms
have display files?  The gui server job runs at full speed with? or without?
the interactive feature.

Yes and No.  The batch job is ultimately driven by an ILE C program, which
makes calls to RPG programs.  The programs do not have display files.  They
pass data and form formatting information back to the job which passes that
information through the TCP/IP connection back to the client program to be
displayed on the PC.  Interactive feature does not enter into the picture
because no terminal interface is involved.  The jobs get full speed -- full
benefit of all available CPW.


>Or you had to buy the interactive feature for you non gui terminal users?

We bought one of the very first 740 machines.  Previously IBM was selling
server and traditional models.  This was the point in time when they made
them all server models and allowed you to buy your interactivity through
different tiers of cards.  We thought that we needed interactive feature for
all jobs, terminal and GUI.  We, Lawson, our local reps, and our business
partner assumed that the Lawson GUI would require interactive feature (the
GUI is interactive in the traditional sense, not the IBM price modeling
sense).  So we have very expensive interactive feature to burn.


>If my "dspf in a job is what determines if a job gets full ( batch ) or
partial ( interactive ) cpu"  theory is wrong, what do you think is the
deciding factor?

I don't understand how it happens technically, but any terminal interface
(as listed above) invokes interactive jobs.  It's pure conjecture, but I
wonder if there's a way to write an interface that presents itself exactly
like a 5250 function without actually opening a 5250 (interactive) session.
I often wondered if Lawson's technique of launching batch immediate jobs
through a sockets connection could accomplish this.


Interactive Feature really burns me up, obviously.  The business practice
was deliberately deceptive, and I think it explains a lot of why the iSeries
loses credibility and market share against Unix and NT servers.  It reminds
me of those new home development deals in the Poconos where they scrape off
all the topsoil and trees and then sell them back to you as extras over the
base price.

Nonetheless, I had observed that the Lawson server subsystem and jobs were
configured differently than their 5250 equivalents, and I discovered that I
had to tune them accordingly.  It seems to me that the same principles have
to apply to the various types of web or client-server job workloads.



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


The 720 I work on is so fast that even with a very heavy remote user
interactive workload we never have to deal with tuning.  During the day
batch is single threaded, but even that might not be necessary.

Steve





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