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

[Charles Wilt <charles.wilt@xxxxxxxxx>]

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.