Re: Granularity of Modules. -- RPG400-L


On 03/01/2006, at 10:32 AM, Mike Pantzopoulos - (H/O) wrote:

I have been having a major problem with the granularity (ie. size) of
modules. Please consider the following:

*       Several sources I have read imply that a module should consist
of a single sub-procedure.

Absolute bollocks! When RPG IV was first released it had an artificialrestriction of 1 procedure per module. They corrected this (let's begenerous) oversight by VRM320/VRM360 hence the use of the termsub-procedure to indicate multiple procedures.

I group related functions in a single service program. I may choose touse one or more modules in that service program and I will probablyhave more than one procedure in each module. For example:


        DTS.SRVPGM
                DATE.MODULE
                        getDate
                        getDateTomorrow
                        getDateYesterday
                TIME.MODULE
                        getTime
                TS.MODULE
                        getTimeStamp

*       Creating a program or service program then binds (by
copy/reference) so that a program could conceivably simply consist of
source code which provides the framework for invoking numerous snippets
of code via the individual sub-procedures.

If you put ALL your business logic in service programs then yes youcould do this. The main line of each program would consist of nothingbut procedure calls to service program functions (and possibly internalprocedures).

However it is more likely that the program-specific code is kept in theprogram source and only truly common functions (i.e., used by more thanone program or service program) are put in service programs. The *PGMmain line would call internal procedures (in the same module or anothermodule bound by copy) and external procedures in service programs. Forexample:


        NEWPOLICY.PGM
                POLICY_LGC.MODULE
                        business logic related to handling a new policy
                POLICY_DB.MODULE

database I/O related to handling a new policy (could be in a serviceprogram)

                POLICY_PNL.MODULE
                        screen handling related to a new policy
                DTS.SRVPGM
                        common date/time/timestamp stuff
                plus any other common service programs you need

*       As an old FORTRAN programmer, I'm happy with the concept of
linking like this. In essence, writing very small single focusfunctions
and then linking them through a binding step.


Same old same old.

*       There is nothing to stop a module from containing numerous
sub-procedures, both local to the module and EXPORTed.

True. Some level of relationship or cohesion should be used to decidewhich procedure goes in which service program.


        o No EXPORT specified then private to this MODULE

o EXPORT specified but not in BNDSRC then protected (i.e., private tothis service program)

        o EXPORT specified and in BNDSRC then public

*       I can live with the idea of more than one sub-procedure in a
module as long as they are only used locally, but I'm having trouble
with the idea of modules with more than one sub-procedure. The compiler
allows this to occur and to my mind it must be very difficult tracking
the relationship between programs, modules, and sub-procedures.

No more difficult than dealing with 50 squillion copy members ala RPGII and III. As long as you use a sensible method of grouping relatedprocedures in a service program you only have to worry about whichmodules are bound to which service program plus which modules are boundto which programs (should never be the same) and which service programsare bound to which other service programs or programs.

If you specify the modules on the CRTSRVPGM and CRTPGM commands and usebinding directories to manage the service programs then you shouldn'trun into too many management problems. Buy and use a decent changemanagement tool that understands this stuff to make it easier.

All your developers need worry about is which procedure they want touse. A properly set-up development environment will handle most of thebinding for them automatically. They don't have to concern themselveswith where that procedure exists.

*       My other beef with the module/sub-procedure relationship is the
size of the name - if the sub-procedure name can be 15 and the source
member name is 10, then we immediately have an issue. I am then faced
with having to have a naming standard which encodes the sub-procedure
name, or have to restrict my sub-procedure names to 10 characters.

Procedure names can be 4096 characters long so immediately you have aproblem if you attempt to name the source member the same as theprocedure. You would only do this IF you decided on a shop standard ofone procedure per module but that would be a truly lame standard. Namethe source member something generic. In the above examples that wouldbe DATE, TIME, TS. Name the procedure within the source somethingdescriptive. From the above examples that would be getDate,getDateTomorrow, getDateYesterday. Use business terms for the names ofbusiness-specific modules (e.g., POLICY, CUSTOMER, ITEM, WAREHOUSE,etc.) and put related code in these modules.

If you are concerned about name collisions or are just anal then supplya prefix to each procedure name. Others on this list have suggestedusing the module name as the prefix and if you do choose to specifyprocedure prefixes then this is as good as any. Thus our exampleprocedure names would be DATE_GetDate, DATE_GetDateTomorrow,DATE_GetDateYesterday, POLICY_New, POLICY_Suspend, POLICY_Delete, etc.

Personally, I hate prefixes unless you can incorporate the prefix inthe name proper (i.e., POLICY_Delete is OK but DATE_GetDate sucks) soeven if I used them in a module (to avoid export collision) I wouldremove them via a suitable prototype and let my consumer decide whetherthey wanted to use the ugly prefix or not. For example:

         /if defined(USE_UGLY_PREFIX)
        D DATE_GetDate          PR                              D
         /else
        D getDate                       PR                              D       
EXTPROC(DATE_GetDate)
         /endif

Do other ILE developers restrict themselves to a single sub-procedurein
their modules?


No way! It's a dumb idea.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------