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