Re: Activation Groups and Threadsafe -- RPG400-L


On Mon, 16 Jul 2001 FKolmann@netscape.net wrote:

> I checked the archives on Activation Groups and although some
> things are explained I still don't understand.
> I checked the archives on Threadsafe and  some questions come
> to mind.
> Long, long, ago when I was but a boy I wrote a MRT program
> on a S38. (MRT = multi requesting terminal).  It worked fine
> but it was a bit of a monster, keeping  track of each users state
> resetting variables etc, etc, etc.
> I quickly came to a conclusion that SRT and the way the S38
> managed jobs was the greatest thing since sliced bread was
> invented and was thankful that, MRTs I will never have to 
> endure again.
> Then along came activation groups.

What do MRT's have to do with activation groups? 

Do you understand the concept of a 'call stack'?  Each time a program
is called by another program, it creates a new stack level.  Each time
a program ends, it's taken off the end of the stack.

So if a CL program called 'DSPINVCL' calls an RPG program called 'DSPINVR'
and the RPG program DSPINVR calls another RPG program called 'DETAILSR'
you might have a call stack that looks like this:

             1      QCMD
             2      LOGINCL
             3      MENUPGM
             4      DSPINVCL
             5      DSPINVR 
             6      DETAILSR

An activation group is a way of "grouping together" entries on the call
stack.   That's _ALL_ it is, very simple.

             1      QCMD
             2      LOGINCL
             3      MENUPGM
             4      DSPINVCL  ----+
             5      DSPINVR       + Activation group "DSPINV"
             6      DETAILSR  ----+
             
Now, you can scope overrides, ODP's and export variables to be shared
between all of the programs in the "DSPINV" group.   You can, furthermore,
force the DSPINV group to end, which will unload all three programs in
it from memory.

That's all an activation group is.   It has nothing whatsoever to do
with threads or MRTs.  (I hated MRTs too, by the way)

> What exactly are AGs for.  I know I can scope file overrides
> within AGs, but to what end.  A long time ago I wrote programs
> that used 'shared file opens' to minimise ODPs and PAG sizes
> and I had to be careful that my file cursor was explicitly positioned
> for every IO (or sometimes very sneakily I used the position of
> the cursor as input for the next program,  confused the heck out
> of the contractors)  but I came to the conclusion that what I was doing
> was complexity for my own egos sake and I could do the same job
> using simple programs that opened ODPs as needed.  OK so the
> machine needed to do a bit more work, but no one noticed the difference
> and the programs were much simpler.

No argument there.  The only nice thing about MRTs was the ability to
share data across the different 'requestors' that were running the 
program...   but, of course, there are other ways to do that today.

> Am I now supposed to go back to the dark ages of the MRT.
> Is that what activation groups are about.  Do you seriously expect
> me to break my job up into multiple sub-jobs (AGs), when I can
> simply invoke another job.

That's not what an activation group does.

> Do AGs address the issue of having thousands upon thousands of jobs
> all the same and then allow all these similar jobs to live within 
> only ONE job, that now has thousands upon thousands of AGs.
> What sort of application needs such a thing.
> Does anyone have examples where they use AGs in a production
> environment where they could NOT have done the same job
> using SRT type programs and the usual AS400 JOB setup.

This is more along the lines of what 'threads' do, not what activation
groups do.  They allow you to have the computer switch between many
concurrent tasks.

> 
> What are threads, I assume it is like the MRT I wrote where I had
> to keep each users data separate.  I understand JAVA uses threads,
> is that because JAVA does not use the AS400 job structure and
> so has to reinvent the AS400 wheel. 
> (I am guessing, I am ignorant in JAVA)

Actually, I'd venture to say that threads are the exact opposite of a
MRT.   With a MRT, you have one program that's handling multiple users.
With threads you have multiple procedures (i.e. subprocedures or
'sub-programs') running at the same time, usually servicing only one
user.

This isn't useful for a traditional accounting, order entry, or inventory
fulfillment package.  If that's what you're writing, don't worry about
threads.  Don't use them.

However, let's say you're writing a computer game.   Moving around the
screen are lots of little 'people'.   Each person moves his legs when he
walks, he makes decisions about which way he's going to go.  Sometimes
he stops and says 'hi' when he sees another person.

In addition, there are monsters walking about the screen.   They're
looking for the the people.   When they find people, they chase them,
and eat them.   They also animate.   Their mouths move, their feet
move, etc.

How would you program this?   Sure, you could do one action for one
person, then do an action for the next person, then do an action for
a monster, then do an action for another person, etc...   but your
code would be constantly switching between each of the 'tasks' that 
needs to be done, and that makes for hard-to-follow code.

Wouldn't it be easier to write the code for each person that walks
about the screen as a separate procedure, and have the system handle
the switching between them?

That's what threads do.

Let's say you wanted to write a web server.   You want to handle up to
200 people accessing this web server at the same time.   Each web browser
can be downloading up to 20 different objects (either html documents,
or pictures, or running scripts) all at the same time.   

You could, as above, continually switch between every single user that
is connected to you.   Send 50 bytes to connection one, then send 50
bytes to connection 2, then read 50 bytes from connection 3, and so
on for up to 4000 simultaneous connections.   This is very complicated
code.   If something goes wrong during just ONE of these connections,
causing the program to crash, all of the connections also crash.

You could submit a new job for every connection.   Granted, this would
work -- but it would require a system capable of running 4000 simulatenous
active jobs!  and each time someone connected, they'd have to wait for
a new job to be submitted and take control of the connection... while the
job is being submitted, no other users could connect.   This WOULD work,
however...

Threads are a lot more 'lightweight' than jobs.  A new thread uses a lot
less memory than a job, and requires a lot less time for the system to
set up.   Therefore, if the AS/400 only supported 'full jobs', it would
not be able to compete with systems that support threads, for the 
purposes of a writing web server.

> 
> Where is the simplicity of the AS400 going where I could 
> write a program and have as many users call it as they want and
> the computer keeps everything in its place, now I am supposed 
> to be able to stick things within AGs (named or otherwise).

Are you suggesting that IBM might be taking this ability away?  I
find that very hard to believe.

> Now I have to consider whether a command is Threadsafe or
> not.  I notice that DSPFFD is not threadsafe.  What does this mean,
> am I now able to get a file description in one job then somehow
> change the file (would you ever do this) on the fly and then use
> DSPFFD in another job the gets back the old file layout. 
> How can a DSPFFD give back corrupt data threadsafe or not
> if the file layout has not changed.

Unless you're writing multi-threaded applications (which it doesn't
sound like you ever will) you don't need to worry about whether a
command is threadsafe...

> Is ILE and AGs and Threads simply a way of redoing what the 
> AS400 has already  done but in a fashion that is compatible with
> the UNIX / C world.  If so then I pray that I retire before all
> this comes to pass.

No other platform that I've ever worked on, (including Windows, and
including UNIX) has anything quite like activation groups.  I don't
think IBM introduced them to 'be like Unix'.

For certain types of programming (especially games and other animated
things) threads make life a lot easier.   If all you've ever written
is simple accounting software, then the odds are pretty good that 
you'll never need to use threads.   In that case, don't worry about
them.  But, PLEASE, don't petition IBM to cripple the AS/400 just because 
you're afraid of them.

Some of us DO write different types of applications.


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