Sounds like a c++ class called PERSONNEL with a bunch of methods. )
On 2/7/2013 5:23 PM, Mark S Waterbury wrote:
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:
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?
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
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 <
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.
On 2/7/2013 9:36 AM, Mark S Waterbury wrote:
Maintenance will be easier if you avoid binding *MODULEs into more than
one place (one *PGM or one *SRVPGM only).
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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives