re. Access Groups and Threads -- RPG400-L

Hi Scott,
Thank you for your clear explanations.
As a backgound I have only recently used 
RPGIV more capably and I want to try to 
explore the wider implications of ILE.
Let me say that having used RPGIV and then
having to maintain some RPGIII code it feels
like coding with one hand being tied behind ones
back. (ie RPGIII is very limiting)
I only used MRTs as an example because that is 
something I understand.  I learn best if I start
with something I know.
If I gave the impression that Activation Groups
and Threads are bad or that I fear them then I
must beg your pardon as I did not mean so.
I have only used this forum to expose my 
ignorance and to try to learn from those more
knowledgable.
For the knowledge you share I am grateful.
Does this forum also act as a petition to IBM, then
it has a hidden adgenda, I mean only to petition
learned programmers to try to enhance my understanding.
As for IBM making things more difficult, I make no 
assumptions, after all we now have JAVA.
Threads I will leave aside because as you imply I will most
likely never code a game or a web server.

Still I think that my ignorance is only exceeded by
my stupidity in  that  even with your clear and simple
explanation of Activation Groups I can see no 
application for them.  Being able to scope file
overrides to a part of the call stack is what I now 
understand to be a function of AGs.
Why would one want to do this.

I believe I know file overrides, even the ILE version
scoped to JOB or AG level,  but in recent years I 
have tended to avoid their use.
Admittedly  I have  used Overrides recently for an 
FTP application and for another application that
needed to switch across libraries where each library
carried data for a specific country.  Still I am at a loss
how I could have exploited AGs in these applications.

You mention EXPORT variables.  I admit that even though
I have written procedures I have not explored EXPORT
variables.  I am not sure that I even understand the 
EXPORT variable concept. Any explanation is appreciated.

If I inadvertently step on any metaphoric toes please
excuse me as I blunder about asking silly questions.

Frank Kolmann




>Date: Tue, 17 Jul 2001 11:28:54 -0500 (CDT)
>From: Scott Klement <klemscot@klements.com>
>Subject: Re: Activation Groups and  Threadsafe

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



__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.com/
+---
| 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
+---