On 8/18/2015 2:55 PM, Dan wrote:
The question I know I'm going to be asked: What are the pros/cons of
service programs vs. non-service programs?
Or...
What is the advantage of ...
d WrapText2 pr 12288 Varying RtnParm
d UnfText 8192 Varying Const Options(*VarSize)
d LineLen 5 0 Const
d LineBreak1 10 Varying Const Options(*NoPass)
d LineBreak2 10 Varying Const Options(*NoPass)
NotesArrayDS = WrapText2( %trimr( c_SPdetl) : 80 : '~' : '|' );
vs.
C call 'WRAPTEXT2'
C parm LongString 12288
C parm LineLength 5 0
C parm Tilde 1
C parm Vbar 1
C parm ReturnArray
Decent names for sub-procedures is an underappreciated benefit. The
example here uses a name WRAPTEXT2, which is almost demanded by the 10
character limit on object (program) names. That name doesn't inspire
much confidence that I know what it's supposed to do without inspecting
the source code. Sub-procedures can be given descriptive names, with
verbs and nouns, names which make sense without having to inspect the
code. Names like tokeniseText, findDelimitersInText and so on.
Architecturally, programs /can/ more or less be used in lieu of
sub-procedures in the method described. *Can* is a very different thing
than *do*. We *could have* been writing hundreds of tiny utility
programs since the System/38 days, but did we? As a community, the
general answer is no, we did not. We tend to think of 'program' as a
pretty good sized thing, and that thinking colours our approach to
architecture.
Sub-procedures are much lighter weight than programs, both in our minds,
and on the system. It doesn't bother me at all that I have several
hundred sub-procedures to do things like isCustomerCreditworthy, which
formerly was a subroutine that got /COPYd into the programs needing it.
For perceived runtime performance reasons. How many similar crimes
have I personally committed in the name of perceived performance?
The lighter weight is something I find liberating. Once my brain was
freed from the notion of few, heavy programs, I began to design code
that was more function-driven instead of lumping roughly similar code
together because it (mostly) used the same files. How would WRAPTEXT2
look if we supplied a callback sub-procedure to implement the business
function that NotesArrayDS gets fed to?
I've become fond of making code more function-like, more like
if custHasBackorders(cust);
listCustomerBackorders(cust: %paddr(fillBackOrders));
endif;
or
if custHasBackorders(cust);
sendCustomerStatusEmail(cust);
endif;
and less like
call chkbkord
parm
parm
parm
if bkordflg = '1';
call prcbkord
endif;
but I admit this is a matter of style. Although, if you were writing
these business blocks as a program, would you be tempted to make one
pass through the order file to see if customer x has backorders and then
make another pass through the order file to list the backordered items
out in order to do something with them? Or would you be tempted to
combine the business functions of 'are there backorders' with 'email the
customer about the backorders' and 'try to fill the backorders'?
Something to think about, especially when the rules for filling
backorders change and I, er, I mean you have to find all the backorder
code scattered everywhere and change it all.
Deployment may not be an issue for you, with a CM tool available, but I
have to deploy by hand. As I refactor functions out of monolithic code
blocks, I put them as sub-procedures into a few service programs. If I
had to put them into programs, there'd be dozens of them that I'd have
to keep track of and deploy together. Security, auditing, backup and
restore are all issues with more program objects, whereas adding another
sub-procedure to an existing service program doesn't affect any of those
items (on my system).
midrange.com
