One problem seemed universal. Each programmer had his own set of
sub-procedures... Each sub-procedure was just enough different that when it
came time to use an existing sub-procedure, it was almost just right, but
not quite.
I'm sure that the RPG compiler team puts quite a bit of thought into
use-cases before they decide to write new %bifs(), which are intended to
extend the RPG language. If you're interested in writing functions and
sub-procedures intended as RPG frameworks (i.e. intended to supplement the
RPG language), you too should use a disciplined approach. Scott Klement's
open-source for RPG service programs offer good examples. You must consider
the needs and interests of service program consumers (other developers).
Actually, it behooves developers to use a disciplined approach when writing
database and application specific service programs, to ensure that the
service programs and the functions / sub-procedures contained therein are
properly scoped and provide appropriate interfaces. Make it a goal to
entice other developers to use them. Give other developers reasons for
using your service programs.
For example, some shops promote the idea of having a single service program
and a common interface for performing DB I/O with appropriate error
handling for each DB table and logical file. Use a naming convention to
associate the DB I/O service program with the DB object. If the table name
is say SSTU100, the name of it's associated service program might be
SSTU100IO.