RE: RCLACTGRP Issue

["Raikov, Lo" <Lo.Raikov@xxxxxxxxx>]

I was not the person who posted the original question, but I would like to
explain why I too am worried about RCLACTGRP scenarion and where RCLRSC
comes into play.

First, a bit of recap. Our application has the structure:

Program A (DAG) calls program B (*caller) calls service program C (named
activation group)

All programs return control without setting LR. Program A does RCLRSC now
and again.

All this works just fine until the named activation group is reclaimed.
After that, the first call from program B to program C kills the process.

We don't reclaim the activation group in the application - it was just an
experiment to prove the point. The real situation is different. We're trying
to use our application in the ODBC/JDBC scenario:

ODBC request invokes Program A calls Program B calls program C

SQL server job is initialised and our programs run in it. But when the ODBC
connection is closed, the server job does not end - it is cleaned up and
stays in the pool. I have no idea how it is cleaned up, but I suspect that
activation groups are reclamed. When another ODBC request is serviced by the
same job, it fails. And I don't see how it can be otherwise unless IBM have
a way of reclaiming DAG as part of the connection cleanup process. Whatever
the structure of the cleanup process, the job becomes unusable after the
first request.

Lo



-----Original Message-----
From: Smith, Nelson
To: 'midrange-l@midrange.com'
Sent: 25.10.02 6:28
Subject: RE: RCLACTGRP Issue

To expand on what Ken has said...

Your RCLACTGRP is ending the service program and freeing up that memory.
However, Program B is still active and still has the pointer to the
procedure which is now non-existant.  Hence, the pointer error.  Program
B
resolved a pointer to the procedure on start up.  As Ken said, just
leave
the service program active and you should be ok.  If you must rclactgrp
for
some other reason, you will  need to also force program B to shut down
at
that time so that on it's next start up it would resolve to the
procedure's
new address.

> -----Original Message-----
> From: Ken Sims [SMTP:mr2087@ke9nr.net]
> Sent: Thursday, October 24, 2002 11:36 AM
> To:   midrange-l@midrange.com
> Subject:      Re: RCLACTGRP Issue
>
> Hi Esther -
>
> >We are experiencing job abnormal ends when we use the RCLACTGRP(name)
> >command and then try to use  service programs that have been
reclaimed.
>   ...
> >If we use the RCLACTGRP(name) command the next time we try to use the
> >service program the job ends abnormally.
>
> RCLACTGRP is an accident waiting to happen and this is a good example
of
> it.
>
> Why are you using RCLACTGRP at all?  If you are using named activation
> groups, why not just leaving the activation group active?
>
> I'll take issue with Eric's comments about *CALLER programs running in
the
> default activation group yielding "unpredictable results".  I have a
> number
> of *CALLER programs that run in the default activation group and that
use
> *CALLER service programs which are also running in the default
activation
> group and I don't have problems.  The results are only
"unpredicatable" if
> you don't understand how activation groups, *CALLER, and service
programs
> really work.
>
> Ken
> Opinions expressed are my own and do not necessarily represent the
views
> of
> my employer or anyone in their right mind.
>
> _______________________________________________
> 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.


************************************************************************
************************************************************************
************************************************************
This message originates from Lincare Holdings Inc. It contains
information which may be 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.
************************************************************************
************************************************************************
************************************************************

_______________________________________________
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.