RE: RCLACTGRP Issue

["DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>]

Esther,

I think your major problem lies in the *Caller attribute on Program B.
*Caller programs activating into the DAG (Default Activation Group) has
always been actively discouraged due to "Unpredictable Results".  This
scenario has been covered in detail on numerous occasions, and generally the
solution comes down to setting a design standard.  I generally try to make
programs (called from the menu) as actgrp(*new).  This gets you around most
of your problems because, once your program terminates with LR, the
activation group is destroyed. It's a little like an automatic RCLRSC.

I didn't see where you're trying to do the RCLRSC.  If in Program A, it's
probably ok to leave it there.  Otherwise, it's probably not needed. Try
making Program B ACTGRP(*NEW) and see if it behaves.

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-898-7863 or ext. 1863



> -----Original Message-----
> From: Raikov, Lo [mailto:Lo.Raikov@MISYS.COM]
> Sent: Thursday, October 24, 2002 7:12 AM
> To: midrange-l@midrange.com
> Subject: RCLACTGRP Issue
>
>
> We are experiencing job abnormal ends when we use the RCLACTGRP(name)
> command and then try to use  service programs that have been
> reclaimed.
>
> This appears to be related to the way we are creating our programs.
>
> We have an ILE program compiled with *CALLER that binds to a
> service program
> in a named activation group.  We run the *CALLER programs
> from a program
> that is created in the default activation group.  This means
> that we have
> ILE programs running in the default activation group that
> call bound service
> program procedures.  If we use the RCLACTGRP(name) command
> the next time we
> try to use the service program the job ends abnormally.
>
> For example:
>
> Program A (compiled to use *DEFAULT)
>       calls
> Program B (compiled to use *CALLER)
>       calls procedure
> Service Program C (compiled to use NAME1)
>
> RCLACTGRP(NAME1)
>
>       call
> Program B
>       calls procedure
> JOB ABNORMAL END
>
> If I try to add RCLRSC before RCLACTGRP(name) the I get the following
> messages
>
>       Activation group ACTGRP2 deleted.
>
>       Activation group QLGLOCAL deleted.
>
>       2 activation groups deleted.
>
>       Tried to refer to all or part of an object that no
> longer exists.
>
>       Pointer not set for location referenced.
>
>       Unexpected user error occurred in QLEDAGE.
>
>       Function check. CEE9902 unmonitored by QLEAWI at statement
> 0000001446,
>         instruction X'0000'.
>
>       CEE9902 received by procedure CALLRTOSC2. (C D I R)
>
>
>       with ignore the next time I try the job ends abnormally.
>       with cancel the next time I try the process is cancelled.
>
> If I try to add RCLSRC after RCLACTGRP(name) the job does not
> end but the
> process is cancelled with the same messages.
>
>
> We have taken these compilation options because our old OPM
> software (that
> was automatically converted to ILE) was dependent on RCLRSC.
> These RCLRSC
> commands are riddled throughout the system and are in very
> key locations.
> If we ran our ILE programs in the default activation group
> RCLRSC would
> still have the desired affect.
>
> We also wanted to put some heavily used logic into the system
> so service
> programs seemed a good idea.  By compiling almost all our
> programs with
> *CALLER and running them in the default activation group we
> could have the
> best of both worlds.  *CALLER also allows us the option to
> move to named
> activation groups when we can sort out the RCLRSC issues.
>
> Is there anything we can do to correct this job abnormal end
> behaviour?  Is
> this just a loop hole with the compilation / binding process?  If this
> behaviour is not to be allowed, at the very least IBM should
> have stopped
> the ILE program running in the default activation group the
> first time it
> tried to use procedures in a service program.
>
> Thanks in advance,
>
> Esther
> _______________________________________________
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>