Re: How to Find what module a procedure is located in

Hi Charles

My post was probably a little confusing as to what I think. The question of benefit was rhetorical - I actually continued to speak of using multiple modules as a good thing.

Nonetheless, the emphasis you give is important, so thanks for that.

Cheers - and 11 more days to full employment!

But who's counting?

Vern

On 2/7/2013 12:01 PM, Charles Wilt wrote:

Vern,

My .02...

If you never have more than 1 *MODULE per service program, you lose out on
the ability to have protected procedures.

Instead, you're left with only private or public.

Charles


On Thu, Feb 7, 2013 at 10:50 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>wrote:

I've heard this recommendation a couple times in these threads. It seems
to go against one of the principle "benefits" of ILE - that one can
combine modules in different languages.

One question is, how much benefit IS that? I find at least one situation
to be beneficial, as described here -

We often have a front-end CL that sets up the environment, then calls an
RPG program to do the work.

I think it's a good idea to change the call to a CALLPRC, make the RPG
into a module, same with the CL, and link the 2 together - one program
object instead of two, for what it's worth.

Now that adds its own complexity to things, in my experience. Here is
where a change management app is helpful.

To add to the idea, the RPG module can have multiple procedures, and the
CL can call them as needed - instead of calling several separate
programs, again reducing the number of program objects.

Just an idea - that a CL driver program can make calls into a linked
module instead of separate programs.

FWIW
Vern

On 2/7/2013 9:36 AM, Mark S Waterbury wrote:

-snip-

Maintenance will be easier if you avoid binding *MODULEs into more than
one place (one *PGM or one *SRVPGM only).

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