|
Again strictly my opinion and may not be the best practise, but I think of *SRVPGM as *LIB. Yes, an OS/400 library object. I put all my payroll specific procedures in one service program. I put all my utility procedures (like number to words, centre text, trig functions) in utility service programs. I segregate them according to function. I am highly likely to need date handling and text manipulation in the same mainline, so all those functions are in a single SP. I only rarely need sockets functions, so they live in their own SP. It's a convenience thing more than anything else. This all matches OPM behaviour pretty closely. Separate library for each application and a single library (or small number of them) for cross application needs. No scheme will be perfect. Sometimes a P/R procedure is just the thing for some G/L program. Since I have but one single binding directory that holds all service programs, the compiler goes out and binds the right service program for me. I see less maintenance rather than more. As for 'one module, one service program,' I say that it depends entirely on the application. Often, it makes sense to have global status variables, buffers and so on. If I put all my procedures in a single module, then all have access to those variables. But sometimes I need more localised 'global' storage, and then I put those procedures in their own module. But more often than not, one module per service program works just fine. --buck
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.