re. Access Groups and Threads

Thank You Chris,  much appreciated.
(Comments inline)

>Date: Wed, 18 Jul 2001 07:47:00 -0700
>From: "Chris Rehm" <javadisciple@earthlink.net>
>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.

I can see where you are coming from.  The concept of tightly linked 
submitted jobs I can sure exploit.  I use data queues and files with
a never ending wait that invoke background processes and I can see how 
these concepts and threads are logically linked. So AS/400 programmers
are not so procedural, that they cannot cope with (logically) parrallel
processes.

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

I hear what you say but I have no idea how to ' just switch activation groups 
based on need.'  How is this coded, how are the groups named, how do I
do the switch.  The only way I can see is to have a driver program that
calls specific CLLE programs compiled with named AGs that then
call RPGILE pgms that are compile with *CALLER AG, but then 
this is not so flexible, ad I still need the overrides in the CLLE.
With a system of hundreds if not thousands of files this can be 
a headache.

Frank Kolmann













Your favorite stores, helpful shopping tools and great gift ideas. Experience 
the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail 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
+---