I definitely don't like the name QCPYSRC!!  Yuck!  There are a few reasons:

1) It starts with Q.  In my opinion, only IBM should create objects that start with Q.

2) Its inconsistent... all of your other files have the language name in them (CL, RPG, RPGLE) but this one has "CPY" which language is CPY?    Do you put all copy books for all programming languages in it?   Or, have you decided you'll never use anything aside from RPGLE?

3) Why not a less ambiguous name like RPGLECPY, or RPGLEINC?  Are you worried that people won't know it's a source file?

4) Considering this to be "modern" is really a stretch.  Yeah, in the mid-90's when this stuff was new, it became a popular technique.  Today, you'd be much better off using IFS, it's a million times more flexible, and works much better with software like git, (or svn if you don't like git), file transfer software, etc.   You'll need to store all the code for most other languages (Ruby, PHP, Python, Java, Node.js, HTML, CSS, JavaScript, etc) in the IFS, anyway, as source members won't be an option.  If you're going to go through the pain of changing things, anyway, this would be a better alternative.   (But a headache to change if you have a lot of infrastructure built around src-pfs)


On 10/27/2018 3:39 PM, Booth Martin wrote:
I am having to rethink an old habit and realizing times change, perhaps I should, too?

I stopped using QCLSRC, QRPGSRC, QRPGLESSRC, etc a very long time ago; I prefer all related source grouped together in a recognizable naming pattern.  Easy to see and easy to police.

I am seeing discussion about the necessity of using QCPYSRC as a PF-SRC file.  Is that a universally held practice in RPG-World? Is this a compelling reason to revert back to 1980s practices?

This thread ...


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

This mailing list archive is Copyright 1997-2020 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].