On Fri, 2003-10-24 at 15:11, G Armour wrote:
> 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?  (Or will some poor sap discover years down the road that /COPY
> LIB/FILE(MEMBER) is no longer, and good luck finding it.)  Given the choice 
> of using
> /COPY or including the procedure source in the main program's source member, 
> I'd
> always take the latter.  But given the choice between that and service 
> programs, I
> think I'd always (usually?) take service programs.  My thing against /COPY is 
> just
> opinion only, based on my experience.  No holy war please.

No holy war, just a few comments from a /COPY fan.  
:-)

The problems you mention with using them is completely valid.  In order
to use them successfully you must observe some rules, like not changing
libraries, names, deleting members, etc.  Yes, a rogue coder could
ignore your rules and create a potential problem, but that is true for
just about everything: he could randomly delete source members from your
main application as well, how would you deal with that?

On the positive side, assume you have a procedure that is called from
several hundred programs.  Each one of those programs needs the
prototype for the procedure, and so without /COPY they each have their
own source.  Now you need to make a change to the prototype: do you find
all of the members and update them on the spot?  Do you update them as
you go, understanding that it may be years before some of the code gets
updated?  And if so, do you have a policy in place to verify each and
every prototype every time you change a source member?  What if there
are fifty procedures, in order to be complete you would need to verify
all fifty prototypes.

With a /COPY, at least you are always retrieving the up to date
prototype(s).  Can this get screwed up too?  Of course, but at some
point we have to stop worrying ourselves to death over the what ifs and
move forward.

Just some thoughts,

Joel
http://www.rpgnext.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.