|
[SNIP]
You shouldn't simply be replacing RPG I/O opcodes with calls to a procedure. You're not really gaining much by doing that.Instead, look at the business logic behind the use of the logicals. PARTMASTER_LookupUsingCustomerPartNumber() PARTMASTER_GetAlphabeticalList() PARTMASTER_GetNextPartByVendor() ORDERHEADER_GetNextOrderToProcess()
[SNIP]That's exactly what I was trying to say with my comment about not "echoing" the RPG opcodes, but providing a "Business Model".
As has been pointed out, you can achive a situation where you can add fields to the end of a record without recompiling programs without putting the logic in service programs. Adding an extra call to the service program just to eventually do a CHAIN and return the same results really doesn't buy you anything.
It complicates your programs and program maintenance, decreases performance, and really doesn't buy you anything.
I'm a huge fan of service programs, and I use them every day, but using them to simply echo an RPG opcode doesn't make sense. You need to add some value to the equasion, you need it to provide something that RPG's native I-O does not, or it won't help you much.
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.
midrange.com
