RE: Activation Groups 102, the plot thickens.... -- RPG400-L

Scott,

I agree that *CALLER would be preferable, but when the preponderance of
existing programs are still running in OPM, *CALLER just does not work.
Strange things occur and I get phone calls in the night. Due to the number
of override problems, etc, I cannot safely use *CALLER without carefully
tracing through every single job that might use the service programs. Since
the service programs have no way of knowing who will call them, we had to
put them in their own AG.

I was trying to, at least on new programming,  create clean job streams.
The *NEW idea is great for driver type programs and that is what I use
there.

My real problem is where I have two programs being used in the same
activation group and the second program gets physically moved to a different
library while it is active in the job stream.  Program A is a trigger shell
program that makes a call to Program B for the actual trigger functions.
For efficiency, neither program sets on LR.  When my change management
system promotes  changes to Program B, it physically moves the object out to
an archive library and moves a new copy of Program B into the original
production library. On a subsequent call from Program A to B, of course, B
is not at the same physical location that it was when Program A was
initialized.  I trying to find a workaround that would reside in Program A,
that would determine (before the call to program B) if B's location is still
valid, and if not, seton LR without calling program B.  The problem with
this, of course, is that the file change that fired the trigger (Program A)
would be lost.  Hence, I was looking for a method to close down program B
(or it's activation group) and reinitialize it while still in Program A.  I
hope that's not too confusing.  I'm even having trouble following it.


> -----Original Message-----
> From: Scott Mildenberger [SMTP:Smildenber@Washcorp.com]
> Sent: Wednesday, May 08, 2002 11:57 AM
> To:   'rpg400-l@midrange.com'
> Subject:      RE: Activation Groups 102, the plot thickens....
>
> Nelson,
>
> First I will mention that I believe all service programs should run in
> activation group *CALLER so that they are in the same activation group as
> the program using them.  Second, to answer your question, a service
> program
> is activated the first time it is accessed from a program.  When you call
> your program again (after just rclactgrp B) it does not reactivate the
> service program because it still has references to it from before.
> Unfortunately, those references are no longer valid because you have
> reclaimed them with the rclactgrp B.  When you also reclaim activation
> group
> A then the next time the program is called it reinitializes which means it
> also goes through the service program activation which starts everything
> up
> correctly.  If you always want activation group A reclaimed when the
> program
> ends then you should have the program run in *NEW activation group, the
> system will create a new activation group every time it runs and destroy
> it
> automatically when the program runs.  Note that this can be bad for a
> program that is called repeatedly (due to creating/destroying activation
> groups) but in the case where you want to make sure the activation group
> goes away it works great.  If you also put the service program in *CALLER
> then when the program ends both the program and service program will be
> cleaned up which is what I think you are trying to accomplish.
>
> Scott Mildenberger
>
>
> > -----Original Message-----
> > From: Smith, Nelson [mailto:NSmith@lincare.com]
> > Sent: Wednesday, May 08, 2002 9:44 AM
> > To: rpg400-l@midrange.com
> > Subject: Activation Groups 102, the plot thickens....
> >
> >
> > I'm calling a program that runs in activation group A which calls a
> > procedure in a service program in activation group B.  I end
> > the program,
> > and then, I do a rclactgrp B and activation group B deletes
> > ok.   I'm still
> > in the same interactive workstation session and I call the
> > original program
> > again.  I get kicked off the interactive session with a:
> >
> >  MCH3402 - A system object is destroyed or has header damage.
> >  This is most
> > commonly caused by deleting a program that is active in the
> > program stack.
> > It may also be caused by deleting the event handlers,
> > external exception
> > handlers, or the program to which the job was routed.
> >
> > When I follow the same steps, but also do a rclactgrp A, I
> > get no error and
> > apparently the next call to the original program activates
> > both activation
> > groups normally.
> >
> > I don't understand why, when leaving activation group A active in the
> > interactive session's program stack,  the second call to the original
> > program doesn't just reinitialize activation group B as soon
> > as it starts
> > up.   Does this mean  that to do proper cleanup, I would have
> > to always
> > reclaim all activation groups back to, and including, the
> > original calling
> > program's activation group?  I was trying to put the cleanup
> > routines at the
> > end of the initial program in activation group A, but I can't
> > do a rclactgrp
> > to A, itself, because I'm still in it at that point in time.
> >
> > Nelson Smith
> > nsmith@lincare.com
> > ncsmith@tampabay.rr.com
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************