× 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: "John Taylor" <jtaylor@xxxxxxxxxxxx>
  • Date: Wed, 18 Jul 2001 11:57:56 -0600


>
> 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 guess we're both weird. :) I'm choosing *NEW over named AG's more often
than not nowadays. The main argument against *new is that creating an AG is
an expensive process, therefore should be avoided. This difference was
noticable back in V3R2, so I designed most of my applications to use named
AG's. Now at V4R5, with a RISC box, I find the difference in startup times
is inperceptible for an interactive application. Of course, there are other
advantages to named AG's, in the area of application partitioning, but there
might be a 1/2 dozen people on this list who would actually know how to
partition an application that way.

For newbies - stick with *new. You'll never get confused by AG's that don't
get reclaimed, and you won't accidentally create two applications running in
the same named AG that were not designed to do so.


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

Here's a simple example:

      *---------------------------------------------------------
      * Module 1 - define variables exported to other modules
      *----------------------------------------------------------
     D CurConu             S                      Export Like( $ConuN )
     D CurCoName       S             30A   Export


      *----------------------------------------------------------
      * Module 2 - import variables declared in another module
      *----------------------------------------------------------
     D CurConu             S                      Import Like( $ConuN )
     D CurCoName       S             30A   Import


I've used them, albeit sparingly. In general, I wouldn't recommend them for
anyone new to ILE. They're worse than global variables (when used
incorrectly), because the imports are scatterred across different source
members.


-john

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

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.