× 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: Activation Groups and Threadsafe
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Wed, 18 Jul 2001 10:16:14 -0700
  • Organization: Pacer International

What are Activation Groups...

I can't think of any mechanism in any other programming language
or platform that is like Activation Groups, so you have to start
thinking outside the box.

Most applications don't need to use activation groups, nor do most
shops, such as in my shop, so they just aren't used.

So what are they there for?  One of the biggest effects of activation
groups I've seen, and the biggest gotcha, is with overrides.

Okay, say you have an application that uses a certain database file,
and you want to do an override on this database file.  So you do the
override, then realize that some other called program is now opening
up your overridden file but you really want to open the original file.
You have a bit of a quandary, and what you would probably wind up doing
is a kluge by creating a CL that does an override, calling the other
program, then setting the override back or some such nonsense.

Enter Activation Groups.  You compile your main program in one activation
group, and the other called program in another activation group.  Now
you can specify on your override which activation group it is to apply
to, and so the two different programs will be opening up two different
database files with the same name, one using the override and one not.

As I said, in most cases you don't need to use activation groups per se
so go with the default activation group.

Activation groups have their places, and is a method of grouping programs,
service programs, etc.. together for like behavior.  I'm not sure of
all the benefits of Activation Groups, but I know they're out there.

HTH,

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

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

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.