× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.