RE: Interactive vs. Batch -- MIDRANGE-L

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?



-----Original Message-----
From: Steve Richter [mailto:srichter@AutoCoder.com]
Sent: Thursday, April 19, 2001 12:23 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Interactive vs. Batch (was Did IBM finally roll out SAA
with Websphere?)


jim,

I have never seen a technical article on this subject. Have any been
written?

Did you say the Lawsons gui does run as batch, ungoverned?

My guess is that an interactive job is any job that opens a dspf. All
display file io runs thru system data mgmt pgms such as QWSGET. My guess is
that once a job runs code in one of these pgms ( the open dspf pgm ? ), the
os sets the switch that slows the job down.

These data mgmt pgms are called using the MI CALLX cmd. Operand 1 is a
system pointer to the pgm to call.  This sysp is set in a non ile rpg pgm by
copying the sysp contained in a fixed location in the SEPT ( system entry
point table ). I would guess that ile pgms do the same thing, but alas you
cannot dump the mi code of an ile pgm to find out. The mi code looks
something like this:
        Dcl SpcPtr  pSept  BasPco  Pos(zzz) ;
        Dcl Ptr  Sept(9999) Bas(pSept) ;
        Dcl Sysptr pDmPgm ;
        CpyBwp  pDmPgm, Sept(xxx) ;   xxx = entry nbr of sys pgm to write
dspf rcdfmt
        CallX  pDmPgm, ...

The actual entry nbrs into the sept are provided by data mgmt when the file
( dbf, icf, dspf, ... ) is opened. ( use this entry nbr when you write a rcd
to a sfl, use this other one when you chain to a database file, ... )

The design concept is similar to the way software interupt vectors are used
on a pc to call out dos system functions.

Theoretically, you can hook the sept just like the software vectors are
hooked on a pc. I can explain my untested theory on how a job could be
permanently hooked without affecting other jobs on the system if anyone
wants to know.

Hooking the sept would allow user written data mgmt pgms to be called by the
rpg pgm instead of the system pgms. This would be useless if the pgm user is
using a twinax attached terminal. The hook pgm would have to know how to
write to a twinax device and that is top secret ibm confidential. ( unless
someone in the know spills the beans by posting the secrets in an anonymous
way on a mail list like this one )

But if you are sending that display data stream down to a network attached
pc, that might be a doable way to bypass the interactive job governor.

This is my recollection of what I learned years ago about how the system
works. I am not 100 pct sure on the details. I welcome any additions and
corrections.


Steve

-----Original Message-----
From: Jim Damato <jdamato@dollargeneral.com>
To: 'MIDRANGE-L@midrange.com' <MIDRANGE-L@midrange.com>
Date: Thursday, April 19, 2001 11:35 AM
Subject: Interactive vs. Batch (was Did IBM finally roll out SAA with
Websphere?)


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