RE: re. Access Groups and Threads -- RPG400-L

<snip begin>
This way you don't have to worry about switching overrides or settings when
a user wants to work with different areas of your logical grouping. So now
if you want a user to be able to maintain files in different divisions, you
just switch activation groups based on need.
</snip end>

So how do I go about setting up an activation group (I tried WRKACTGRP)?  I
am curious as to how much you can specify in them.  In my situation we have
multiple companies on the same AS/400 and they utilize different libraries
for their data but use the same named files, so this might be a concept that
we want to look into.

Aaron Bartell

-----Original Message-----
From: Chris Rehm [mailto:javadisciple@earthlink.net]
Sent: Wednesday, July 18, 2001 9:47 AM
To: RPG400-L@midrange.com
Subject: Re: re. Access Groups and Threads


I hope I can contribute something in this discussion. I was reading it and I
thought I could clarify some things a little bit.

First, although you have set aside threads, I'd like to clear up a little
with them. Threads allow you to physically separate the processing of
different aspects of your program. While the examples given were to show
some cases where using threads might be of great use, there are others.
For instance, if you allowed a user to select some options on a report
generation screen and you wanted to be able to go out and generate that
report while the user was selecting other options. On  a 400 we tend to
submit those jobs. Using threads though, you submit the job and it runs
within the same program, but since it is running in a different thread it
doesn't take the CPU focus away from the user any more than all the other
jobs running on the AS/400 would.
In Java, when the report got done generating you might enable the "Display
Report" button so the user could click it if they wished.
The reason, I think, it isn't easy to think of ways that threads can be
useful is that as AS/400 programmers we have been trained to think of
solving problems without using separate threads.

Activation Groups allow you to logically separate the processing of
different aspects of your program. If your users is dealing with files that
may have been created by different vendors or maybe for different division
identities within your company, there might be different sets of overrides
and different file groups you want to deal with at each different time. But
if you are writing code to deal with multiple areas of this environment, you
might want to separate different parts of your application into the
activation groups that deal with logically defined areas in your
environment.



Neither really has anything to do with MRTs. MRTs were a way of writing
programs to deal with multiple users in a single thread. Back in the day of
MRTs, the hardware didn't really support the number of users and the
physical response we use now. As you recall, use of MRTs let us free up lots
of memory on our System 34s by running all the users inside of one job (or
thread). This was still done for some time during the 36 days, but that is
the era it faded.

Chris Rehm
javadisciple@earthlink.net
If you believe that the best technology wins the
marketplace, you haven't been paying attention.


----- Original Message -----
From: <FKolmann@netscape.net>
To: <rpg400-l@midrange.com>
Sent: Wednesday, July 18, 2001 5:04 AM
Subject: re. Access Groups and Threads


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


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