Re: Performance - RPG vs Cobol

Yes and No.

ILE and OPM are different to begin with.

But the major difference comes in the fact that COBOL's normal default behaviour is to kill the run unit when the program that caused it to come into existence exits.

So COBOL1 -> RPG1 -> COBOL2 = basically no problem.

RPG1 -> COBOL1 -> RPG2 = potential problem as the run unit will be destroyed and subsequently recreated every time that COBOL1 returns to RPG1. The normal "cure" for this is to use a COBOL stub before the RPG1. SO the sequence becomes:

COBOLSTUB -> RPG1 -> COBOL1 -> RPG2 = no run unit destruction until RPG1 returns to caller - and you'd want it to happen then anyway.

ILE makes it more complicated because ILE COBOL run unit is based on Activation Group. So RPG can be isolated from the impact of COBOL run unit or incorporated as required. There are also ways of exiting the COBOL while preserving the run unit - but it all gets rather complex.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On May 31, 2017, at 9:08 AM, Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx> wrote:

Isn't creating the COBOL run unit a one time thing for the job? Just make sure there is a COBOL program early in the stack.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----Paul Roy <paul.roy@xxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Paul Roy <paul.roy@xxxxxxx>
Date: 05/31/2017 09:02AM
Subject: Re: Performance - RPG vs Cobol


I you regenerate the full application, this is not an issue but .
There is a possible performance issue if you mix RPG and COBOL.
Calling RPG from a COBOL program has no overhead whilst if you call a
COBOL program from RPG there is a big overhead in creating the COBOL run
unit !


Paul




From: Rob Berendt <rob@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 31/05/2017 14:11
Subject: Re: Performance - RPG vs Cobol
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



I would not think there would be a performance difference.

That being said however, there are some interesting defaults...
For example, an RPG Input Primary file has some interesting record
blocking which I've found to be a performance boost. Sure, you can tailor

your blocking factor in other files but I was talking about defaults here.

Just look at the compiler messages on an Input Primary file about
blocking.

However, since their generator supports both RPG and COBOL what are the
odds they are using Input Primary files?

Defaults are important when the gods forbid you to modify generated code.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Vinay Gavankar <vinaygav@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/30/2017 07:02 PM
Subject: Performance - RPG vs Cobol
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Hi,

I was wondering whether there is a performance difference between RPG and
Cobol code trying to execute the same functionality which is I/O heavy
(rather than calculations).

I realize that a lot might depend on how the actual code is written, but
is
there a general guideline?

My client uses Synon 2E (which allows you to generate OPM/ILE RPG/Cobol
source), and there are some programs which are currently OPM Cobol. We are
planning on regenerating them as ILE and we have a choice of doing either
RPG or Cobol. Is there any particular reason that we should choose one
over
the other?

The plan is to change all the programs in the job stream to ILE just to
keep them in the same Activation Group.

These are common modules which are being called from a various RPG/Cobol
programs.

The programs accept a bunch of parameters. Are there any pitfalls if we
convert to ILE RPG in accepting the parameters?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD