RE: Activation groups

Ah, yes... this makes sense, although it also presents difficulties.  As an
extreme example, think of the JVM for a job; there is one and only one and
it is started the first time you use it, and that's all you get, otherwise
the overhead of using Java would simply be unbearable.  The "large
standalone services" you mention could be of that nature.

On the other hand, the downside of the particular situation of the JVM in
OS/400 is the lack of any method to restart the JVM due to environment
changes, short of signing off the job.  But with the named AG, you can
design in initialization routines or theoretically just reclaim the AG when
reinitialization is necessary.

I will continue to think about this; I'm sure there are some areas where
this makes very good sense.  It would be even better if you could combine
multi-threading and AGs; this would allow you to do things like open a
socket and keep it alive while waiting for data.  Thanks for the intriguing
possibilities, Larry.

Joe


> From: Larry Ducie
> 
> I think a good candidate for a service program running in a named
> activation
> group is one that provides a simply but universal service. Think of a
> service program designed for easy string manipulation. It could (among
> others) have the following procedures:
> 
> toUpper(...)
> toLower(...)
> capitalize(...)
> centerText(...)
> etc...
> 
> There really isn't a good reason to have more than one invocation of this
> service program within any given job. The use of a named activation group
> ensures that we get one and only one instance.
> 
> I would not normally expect to shut this activation group down until job
> end, so there is no extra overhead involved.
> 
> It may also be necessary to mimic the singleton design pattern for
> consumption of large stand-alone services such as http client services,
> xml
> decomposition services, html creation services, etc...