×
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.
On 16/11/2004, at 2:06 PM, Alan C wrote:
A separate service program per procedure is too much, but you refer to
maybe keeping each procedure in a separate source member.
That's what I said. I wouldn't have a single procedure per service
program. I'd group related procedures into a collection of service
programs according to some method that made sense. For example:
STRING things
MATH things
FILE I/O things
Accounts Receivable things
Accounts Payable things
General Ledger things
CUSTMAST file things (consumes FILE I/O things)
ITEMMAST file things (consumes FILE I/O things)
etc.
I wouldn't separate individual procedures into separate source members
either but I can see a case for doing so.
This sounds like at compile time you put them together with /COPY for
the compile?
No way! /COPY is a crock. Marginally useful in the "olden days", also
known as "the before time", but still requires all code that references
the copy-code to be recompiled when the copy-code changes.
Bind by Reference is better. Build a service program containing the
common code (this is bind by copy) and bind the service program to the
consuming programs and service programs (this is bind by reference).
See the ILE Concepts manual for detailed information.
Done properly, service program code can be updated and enhanced without
requiring the consumers to be recompiled.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software AS/400 Technical Specialists
http://www.flybynight.com.au/
Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\
Fax: +61 3 9419 0175 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
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
