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

[Alan Campin <alan0307d@xxxxxxxxx>]

No, part of the pwoer of ILE is having multiple modules and being able to
bind together different languages into a single program or service program
object. In RPG III world you would have something like

AR0001CL - CL Driver
AR0001AR - Mianline
AR0001C2 - CL function
AR0001C3 - CL function

Now you have four objects to distribute.

In the ILE world I distribute one object, AR0001.

AR0001_M01
AR0001_M02
AR0001_M03
AR0001_M04

The other thing I can do is create multiple procedures to perform specific
functions for a CLLE. The CL can just call using CALLPRC. Very handy.


The most important point is to name all the modules with the same 6 digit
prefix so it clearly shows that everything is part of the one top level
object.  If you use a single source file then you can see all the pieces at
one time.



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

> Mark
>
> I misread, I think - I was seeing it as one module per executable object
> - so I think we actually agree, which is a good thing, eh?
>
> Vern
>
> On 2/7/2013 10:05 AM, Mark S Waterbury wrote:
> > Vern:
> >
> > Your example below does not violate my suggestion, of binding a given
> > *MODULE into one place (a single *PGM or *SRVPGM).  I said nothing about
> > any given *PGM or *SRVPGM being composed of one or more *MODULEs. =-O
> >
> > Let;s say your CLLE *MODULE is named CLLE1, and your RPGLE *MODULE is
> > named RPGLE1 ... what I am saying is that you should almost never "bind
> > by copy" either one of those two modules into more than one *PGM or
> > *SRVPGM.  I did not say that you should avoid binding both of them
> > together into a single *PGM or *SRVPGM.
> >
> > The issue I was speaking to is "maintenance" -- if you bind the same
> > *MODULE into many *PGMs and/or multiple *SRVPGMs, then any time you have
> > to "fix" code in that *MODULE, you must "hunt down" every place it is
> > bound into, and replace it, either using UPDPGM or UPDSRVPGM, or using
> > CRTPGM or CRTSRVPGM to recreate from all of the component *MODULEs
> > (assuming you keep them around.)
> >
> > Hope that helps,
> >
> > Mark S. Waterbury
> >
> >   > On 2/7/2013 10:50 AM, Vernon Hamberg 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.