|
I agree. In our shop we do the one module to one service program way with potentially many sub procs in each module. Not that we think multiple modules in a service program is bad, it has just worked out this way for us so far. It really comes down to having somebody oversee all development and then make sure all related modules get bound together in a appropriately named service program. How would it work if you were binding many modules in one service program and you only needed to change one module in a service program? Would you use the update service program command, create the entire service program over? This is where one module to one service program benefits my shop I think. We have to distribute our software to our remote companies once a month (at least) and if we bundled many modules in one service program we might be sending unchanged code. Just some thoughts, Aaron Bartell -----Original Message----- From: Pete Clifford (ariadne software) [mailto:pete@xxxxxxxxxxxxxxxxxxxxx] Sent: Wednesday, October 15, 2003 11:18 AM To: RPG programming on the AS400 / iSeries Subject: Re: Function Opinion Yes, good question. I can see that one module per service program might have some justification, but I'd interpreted this as one function=subprocedure per service program, i.e. a single procedure export, which makes no sense at all to me. Pete
As an Amazon Associate we earn from qualifying purchases.
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.