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

[Alan Campin <alan0307d@xxxxxxxxx>]

Anything that is exported from a service program I do this to and I use
either one of these schemes.

For service program XVERRH, for example.

ERRH_Throw


or

XVERRH_Throw

Either way, each exported procedure has a unique name.


I don't do this for procedures inside of a module. I clearly know that a
procedure is inside the modules that I have all with same prefix and naming
correctly makes it pretty clear where is is.

ProcessScreen01
WriteSubfile10

etc.




On Thu, Feb 7, 2013 at 9:23 AM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

> Hi, Alan:
>
> Personally, I would take it one step further, and suggest requiring
> naming all procedures with a "prefix" of the MODULE name (for modules
> that are bound into a single program), or the target SRVPGM name.  So,
> for example, you might have the following procedures:
>
>      PERSONNEL_Add_Employee
>      PERSONNEL_Remove_Employee
>      PERSONNEL_Update_Employee_Details
>
> and so on, whether implemented as one *MODULE or several, bound into a
> *SRVPGM named "PERSONNEL".
>
> With this type of "naming convention" there is no need for tools or
> searching -- you know right away from the name where it is found.
>
> What do you think?
>
> Thanks,
>
> Mark S. Waterbury
>
>  > On 2/7/2013 11:17 AM, Alan Campin wrote:
> > I see this going on all over the place and it is the biggest No, No I can
> > think of. Putting the same module into multiple programs or service
> > programs is a disaster. I routinely bind a CLLE driver to a RPGLE module
> > and many casees RPGLE to CLLE to perform specific functions I want to
> > perform but they have the same naming.
> >
> > The other big No, No I keep see is people naming modules with a different
> > name for each module.
> >
> > I use a system like
> >
> > XVERRH  Top Level
> > XVERRH_PR
> > XVERRH_B
> > XVERRH_M01
> > XVERRH_M02
> > XVERRH_M03
> >
> > but I keep seeing stuff like
> >
> > DS8924RP - Module One
> > DS8925RP - Module Two
> > DS8926RP - Module three
> >
> > Bound up to make say DS8927RP or something like it. What is bundled with
> > wha?. What a nightmare.
> >
> >
> >
> >
> >
> > On Thu, Feb 7, 2013 at 9:05 AM, Mark S Waterbury <
> > mark.s.waterbury@xxxxxxxxxxxxx> 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.
>
> --
> 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.