RE: Procedure names vs. production support

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> Option 2 was to name the procedure the same as the source member.  In 
> our case, today, that would result in a source member name like SP4531M 
> and a call statement like SP4531M(PARM1 :PARM2).

Why even use service programs if you're going to do that?  You may as well 
stick with programs, you're not getting any of the benefits of srvpgms.

Plus, that procedure name is meaningless.

IMHO, this "procedure per member" approach leads to people writing large, 
monolithic programs.  It encourages you to write long, complicated 
procedures instead of many small ones.

How are you going to write a module that contains all of the business 
logic for an order inquiry program, but none of the display logic, if you 
can't break it up into individually callable routines?

Take my ORDINQ example for instance.  How could you have one routine that 
starts the logic (ORDINQ_open) and another that reads the database files 
in sequence (ORDINQ_read) if you don't have the ability to put them both 
in the same module?

You'll end up sharing data via files, or user spaces, or exported 
variables.  Then, because your variable scope isn't limited, and your 
interface isn't cleanly defined, you'll end up havign to re-test 
everything whenever you make any change.

The problem is your current rule of having to re-test everything is based 
on the way things were done with monolithic programming.  And that rule is 
FORCING you to continue to use monolithic programming techniques.  One bad 
decision begets another.

If you MUST limit yourself to one procedure per module, you could at least 
tack on a descriptive name to the end of the procedure.  Something instead 
of calling the procedure SP1234M, call it something like 
SP1345M_CheckForWorgles().  Then you'll know what it does, and you'll 
still be able to trace it back to which source member it's in