×
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.
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
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.
midrange.com
