× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: re. Access Groups and Threads
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Wed, 18 Jul 2001 11:16:58 -0500 (CDT)



On Wed, 18 Jul 2001 FKolmann@netscape.net wrote:

> Hi Scott,
>
> 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.

Your original message (but not the message I'm replying to) seemed to
imply that these extra capabilities were a step backwards...

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

No, this forum doesn't act as a 'petition' to IBM, but there are IBMers
who read it, and if you got a lot of people agreeing with you, I could
see them taking this into account when doing future development.

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

Well... lets say you're a software company who releases your programs
to thousands of users all over the world.   You put all of your files
and programs in one library. 

The user is able to add your library to their library list, and then
run a command to invoke your software.   The first thing your software
does is issue overrides so that your programs will always access the
files in the correct library.

Under the OPM model, how could you prevent the user from issuing another
override that took precedence over yours?    If the user happened to have
another file on his system with the same name as yours, how could you
prevent your override from affecting the other programs running on the
system?

Now, just to make things more complicated, let's say your distributed
software was able to call an 'exit program' that the user defines.  
Now, the exit program will be running at a later call stack level than
your own software does.   How can you make sure that your overrides won't
affect it?   Especially if you want to make sure you don't modify the
library list?  

The same is even MORE true if you're doing something that necessitates
the use of shared ODP's.   (Opnqryf jumps to mind)  You certainly don't
want an exit program that you call to be able to change the position in
a file that your software has left off at.

So... that's an example of where scoping overrides to an activation group
makes sense.  I have to admit that I don't do things like this very often.

Usually, I use activation groups to force my service programs to end when
the program that called them ends...   not for overrides...  consequently,
I generally start a program with ACTGRP(*NEW), and have everything that it
calls use ACTGRP(*CALLER).  But I'm weird in that respect, most people 
will tell you not to use ACTGRP(*NEW).

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

As with all things, there are times when it makes sense to scope
things to an AG, and times when it doesn't.  If you don't find a
need to exploit them, you're probably working in the area where
it doesn't make sense.

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

My opinion is that exporting variables to the activation group isn't a 
very good idea.   But then, I'm really not a big fan of global variables
in general.

I've never actually done any activation group 'data item exports', so 
perhaps someone else on the list can provide an example.   I just
mentioned them because I know that they exist (they're mentioned in the
DSPPGM and DSPSRVPGM commands)

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

One of these days, I should invest in some metaphoric steel-toe
boots :)



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.