RE: external subprocedures setting on LR: performance impact?

["Mike Haston ** Data" <MHaston@xxxxxxx>]

At COMMON a while ago they told us that a procedure *should* do one task.  I'm 
finally getting to practice some of this.  This isn't complex business logic, 
but it's how I've done a few things ... and it could be applied to more complex 
logic, they just don't let me touch that stuff!


#dayOfWeek() will return a number between 1-7

#dayName() is pretty much just an array of day names that is indexed by 
#dayOfWeek(), so it's only c spec line is:    
  return    %trim( day( #dayOfWeek ( inputDate )));

#getPrvWkEnd() returns the previous Saturday.

#getPrvWkStart() uses #getPrvWkEnd to determine that weeks beginning or Sunday:
  return    #getPrvWkEnd( inputDate ) - %days( 6 );
              
Same goes with some UPC functions I have.  A UPC is basically the Vendor# and 
SKU slammed together with a Number Sys digit out front and a trailing check 
digit.  So I have three function that work together.  
  #getNbrSys() gets me that first digit solely.  
  #getCheckDigit() returns the trailing check digit.  
  #getUPC() just puts it all together with a data structure, 
    but it's basically:  #getNbrSys() + Vendor# + SKU + #getCheckDigit(); 


They're all very simple routines that do solely one thing, which at times is 
pretty small.  Bucks #setDate() is pretty clever and gets you thinking about 
how to break things down to a simple, yet useful level.



-----Original Message-----
From: Buck Calabro [mailto:Buck.Calabro@xxxxxxxxxxxx]
Sent: Wednesday, April 09, 2003 2:47 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: external subprocedures setting on LR: performance impact?


Dan wrote:

>Since QA testing is a significant undertaking in this 
>shop, anytime we can plug in discrete modules into a 
>new application, or modify one module in an application 
>that uses several modules, makes for easier and faster
>testing.  Does that adequately answer your "foot in mouth" 
>argument, Buck? <g>  

No, my foot might still be firmly lodged.  My point is that my view of
procedures is that they are small: tiny, even.  A proc fits on one
page/display.  They're easy to understand at a glance.  Programs are more
complex, they are built up from my procedure-BIFs, and take time to
comprehend.

You can substitute the word 'program' or 'procedure' for your use of the
word 'module' above and have the same effect.  In fact, programs may be a
better fit for you if you are using bind by copy instead of service
programs, but that borders on a lecture, I guess.
  --buck