× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.