|
> Thanks for laying that out, Buck! For the little I know about > procedures, this would seem to be a good way to get the feet > wet, but nothing more Yes, absolutely right. > I have not yet seen any responses (if there are any) to my post > yesterday, but wouldn't one want to move quickly to > service programs as opposed to coding inline sub-procs? That's my view. Some prefer the intermediate step of bind by copy. > I have a thing or two against using /COPY. No version control. > Library / File names get changed, will all the programs that use > /COPYs get modified to reflect this? Don't specify a library name in the /copy; use the library list! :-) > Given the choice of using /COPY or including the procedure > source in the main program's source member, I'd > always take the latter. /COPY reduces the maintenance burden by keeping the source physically in one place. When you make a change to that /COPY member you do need to go re-compile all the programs using it. And that is not fun, but Pathfinder or Abstract/Probe or other cross reference tool will help automate that. FNDSTRPDM can help too. With the source physically located in several dozen programs, not only do I get to re-compile, but I need to physically edit each program first, and automating THAT is darned nigh impossible. >But given the choice between that and service programs, I > think I'd always (usually?) take service programs. Agreed again. With service programs, the source code is in one physical place and so is the object code! Making a change is as easy as editing the source, re-creating the *SRVPGM and deploying the *SRVPGM. Unless you needed to change the interface (say, add a new parameter to a procedure call) you don't even have to know what programs use that *SRVPGM! It doesn't get much simpler than that for me. No holy war. Good thread! --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.