Re: Activation Group closes unexpectedly

Performance testing is not really needed if you take the time to understand what is happening. It is the overhead of collapsing and creating Run Units (which also causes files to get closed) that is the issue. Once you understand how to _safely_ mix OPM and ILE COBOL performance should not be an issue.

If you don't learn how to manage this properly then performance may be the least of your worries!


Jon

On Aug 14, 2020, at 10:02 PM, Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:

Thanks Jon, for now we are redeploying it back as OPM. Will do thorough
performance testing before changing.

On Fri, Aug 14, 2020 at 7:01 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

You need to understand why it is happening.

Mixing ILE and OPM COBOL is a risky business (as you have discovered) if
you don't understand the potential problems.

Simply put OPM and ILE COBOLL do not share a Run Unit.

The scope of the OPM run unit is from the first OPM COBOL program in the
stack to the last one and encompasses any and all OPM programs (no matter
what language) in between.

The scope of the IL:E COBOL run unit is thew Activation group. That means
that running them as *CALLER is rarely a good idea. They are not designed
to do that and should really run in a named AG.

That said - what you have probably done by switching the OPM program to
ILE is to change which program is at the root of the Run Unit in QILE. I'm
guessing it is this program that is now the anchor in the Run Unit. You may
be able to fix the problem by changing the program to use the CONTINUE RUN
UNIT option on the EXIT PROGRAM. That should fix it - but you really need
to understand what you are doing here. You (i.e. your company) have
apparently been living dangerously for a while. It is time to engineer this
thing properly.

This part of the docs shows a variety of scenarios and shows the effect of
various options.
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzase/cblrtnexmp.htm
<
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzase/cblrtnexmp.htm

Hope this helps.


Jon

P.S. We should move this discussion to the COBOL list if you need to
discuss further or David will shout at us!

On Aug 14, 2020, at 5:44 PM, Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:

Hi,
We have a batch job where the initial program is an OPM Cobol program,
which calls a variety of OPM and ILE programs. Some of the ILE programs

use

*CALLER AG whereas some use QILE AG.
The batch job environment was 'stable', meaning looking at the job, it
would have only 2 Activation Groups - DFTACTGRP and QILE. As none of the
programs is 'closing', the number of open files would be a constant.
Yesterday, one of Cobol OPM programs was changed to CBLLE with QILE AG,

and

now the QILE group keeps on closing and recreating (the AG number keeps

on

incrementing), which also leads to files closing and reopening, which has
given a HUGE performance hit.
Any ideas why this could be happening? Do we need to go back to OPM or
changing the AG to *CALLER might work? The program is called from the
initial OPM program.
I know we need to do major overhaul on the AG, but I am looking for a

quick

solution.
TIA
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com