Re: Can you take module binding to far?

[Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>]

"Being that there isn't any reason to access the detail data without
the header information..."

Perhaps true today.  Perhaps true tomorrow, perhaps not.

How many items of item X have been shipped this month?  Don't need 
header information for that.  What items have been placed on back order
this month?  Don't need header information for that.  

Initially designing an application with ILE concepts does take longer for
the first X programs than writing them without ILE and reusing modules.  At
a certain point, it becomes faster to write new programs since you already
have all the modules in place, and it seems like you are just linking different
modules together in different combinations like building blocks.  When you 
can do this with no module changes and few lines of program code, I would think
that would be the optimal level of linking (separating logic into separate
subprocedures).

When you find yourself modifying subprocedures when you try to create a new
program because it is lacking, you usually haven't broken it down far enough,
and can redesign it then.

If you find yourself scratching your head looking for the little itty bitty
procedures to create a program, you have gone too far.

There comes a point when it just feels right and you feel like you are no 
longer programming in language X but in some arbitrary 4th generation language
you created with your subprocedures.

There comes a point when you have to make a major change to the database design
then realize all you have to do is change 2 modules and recompile and all is 
fine,
then you are there.

Getting there can be a pain, but it is well worth the investment, IMO.

The big question to ask is, what will be gained by breaking this subprocedure 
into
2 subprocedures?  Are we ever going to call this subprocedure from more than one
program?  No?  Stick it in the program source.  Yes?  Stick it in your service
program.  

What you are concerned with, I think, is the point of diminishing returns.  When
no matter how much time you spend working on your library, it's not going to 
save
you anything or give you anything in the long run.  That is a different point 
for
different applications, I think.  The bigger the application, the later the 
point
of diminishing returns is reached.

Just my opinions and observations.

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

Jade Richtsmeier wrote:
> 
> Greetings -
> 
> We are trying to implement ILE concepts along with modularization.  My
> question is, when have you taken binding do far?
> 
> Here's what we have:
> 
> PgmA contains the following modules:
> PgmA = RPG entry point program
> PgmAc = CL program to start commitment control
> PgmAs1 = subfile server in order number sequence
> PgmAs2 = subfile server in customer name sequence
> PgmAs3 = subfile server in customer number sequence
> PgmB = Flat panel maintenance for the order header
> PgmBedt = Editing server program for order header
> PgmC = Order detail subfile
> PgmCs1 = subfile server for order detail
> PgmD = Flat panel maintenance for order detail
> PgmDedt = Editing server for order detail
> 
> Beings that there isn't any reason to access the detail data without the
> header information, where do you draw the line at binding modules into one
> program?  Is there a rule of thumb for the number of modules bound into one
> program?
> 
> Any info would be appreciated.
> 
> TIA,
> Jade Richtsmeier
> Analyst/Programmer
> MN Counties Information Systems
> Grand Rapids, MN
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---