RE: Activation groups for beginners

comments inline:

> -----Original Message-----
> From: Buck Calabro [SMTP:Buck.Calabro@commsoft.net]
> Sent: Wednesday, March 20, 2002 10:12 AM
> To:   rpg400-l@midrange.com
> Subject:      RE: Activation groups for beginners
>
> Nelson Smith wrote:
>
> >Now, I've got to find the best
> >solution to fix the 500 or so
> >driver CL's.
>
> I don't think you can address only the CL programs...
>
> >1.)  I can't remove the Rclrsc without
> >     restructuring the many programs that
> >     depend on it to close them down.
>
> Remember that RCLRSC won't close down ILE programs unless they were
> compiled
> DFTACTGRP(*YES), so the action you think is happening may in fact not be
> occurring. [Smith, Nelson]   The problem that Barbara pointed out was that
> files, etc, did get closed but the service programs themselves did not. So
> second calls to procedures thought the files were still open.
>
> >2.)  I can't recompile the CL's without
> >     a through investigation of the
> >     override scopes, etc., throughout
> >     the entire job.
>
> Recompile them to make them ILE? [Smith, Nelson]   This is certainly the
> long-term solution, but when trying this before without analyzing the
> overrides, etc, we would suddenly have programs down the line blowing up
> due to scoping problems.  This option will require time in a shop that
> always has other higher-priority projects.  (If it ain't currently blowing
> up, it won't get much attention.)
>
> >3.)  I can see no justification for having
> >     the RclActGrp in the driver CL's
> >     at all, can you?
>
> Certainly not RCLACTGRP *ELIGIBLE, but why did they get put there in the
> first place?   [Smith, Nelson]  A misunderstanding on the part of a vendor
> who included it in his templates, which were then propagated throughout
> the system over the years. The problem didn't surface until I brought in a
> lot of service programs and maintenance programmers starting using some of
> the procedures in older systems.
>
>  I think this is the key to how to address the situation.  If
> it's a simple misunderstanding of how AGs work, then perhaps you really
> want
> to put every ILE program in *NEW except the service programs, which should
> be *CALLER.  Then the AGs would clean themselves up:
>
> CL *DAG
>   RPG *NEW (AG0001)
>     SRVPGM *CALLER (AG0001)
>   seton LR
>   /* AG0001 is gone */
> Endpgm
>
        [Smith, Nelson]  I think the overhead of *NEW would kill us since
there are so many programs called by the driver CL's.  Also, we would get
into the same scoping problems as I mentioned above the same as if we just
recompiled the CL's as ILE.  It's still going to require a good bit of
analysis up front.

        [Smith, Nelson]
> If you really aren't sharing, then perhaps the client programs should be
> in
> a single AG instead of *NEW, but this doesn't sound like your scenario
> because the CLs are doing RCLRSC to close things down.  Does this mean
> your
> RPG programs return without LR? [Smith, Nelson]   Yes. And they are a
> mixture of OPM RPGIII's and converted RPGIV's compiled to run in *CALLER.
>
> >My plan now is to remove the RclActGrp from
> >the CL's, but leave the service programs in
> >their own activation group.  I think this
> >should solve the immediate problems.
>
> Difficult to say, but reading between the lines makes me think you have
> RPG
> programs that don't set LR on and currently (OPM version) rely on RCLRSC
> to
> do the cleanup.  I'd be leery of a design where ILE client programs run in
> *CALLER if that means they will run in *DAG.  You can't ever really close
> them properly because RCLRSC has no effect on them.  [Smith, Nelson]
> Agreed. Unfortunately, there is no design. Just a slow progression toward
> the new, mostly by maintenance programmers having to deal with a lot of
> old baggage. The few entirely new systems, designed from scratch, don't
> suffer these problems, of course.  For the time being, anyway, we have to
> fight the fires as they occur.   I think making the
> clients *NEW fits your scenario closest, but like I said, I'm reading
> between the lines and guessing.
>   --buck
> _______________________________________________
> 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.
************************************************************************************************************************************************************************************************************