On 08/05/2010, at 12:57 AM, hr@xxxxxxxxxxxx wrote:
I know this is not directly the subject, but I have always
wondered why people has different sourcefiles for different
source types.
Me too. Other than in my very early days on S/38, or where forced to
do so by some shops stupid standard, I have never used the IBM default
source files for anything. Simple tools and utilities all go in the
same UTIL_OS400 source file. More complex things have their own source
file and everything for that group goes in the one source file with a
suitable naming convention. RPG, C, COBOL, PL/1, CL, UIM, DDS, CMD,
etc. all in the same file. Makes development so much easier than
flipping between different files. (When forced to use separate files I
would set up group jobs with one for each source file and "flip" that
way.)
The only separation I do is for include files which are in separate
files (one per language thus H for C, RPGLEINC, for RPGLE, CBLINC for
COBOL) and this is primarily because they are cross-group items. For
that reason they also go in a different library structure. This also
allows a hierarchy of includes so they can change with each release
(e.g., library names are: FINC.M370, FINC.M420, FINC.M440, FINC.M510,
etc.)
I have only two sourcefiles a QDDSSRC to DB2 definitions
and a QSRC for the rest
Why separate these things? What's so different about DDS that it
cannot also go in your primary source file? And why name your source
file with a Q? I notice that happens a lot and I've never understood
it. Fine to use QCLSRC, QDDSSRC, QCMDSRC, etc. simply to avoid having
to retype the file name on the various compiler commands but if you're
going to bother creating your own source names then why use a prefix
that indicates it is an IBM object?
and all source is grouped by a
4-8 character prefix and the sourcefiles resides in the
same lib as the objects they correspond.
I always keep source separate from the objects simply because the
objects are what gets shipped and the source stays private. Note that
"shipped" in this case could mean a program product but also might
mean what is promoted to production. I've never seen the need for
source on a production system unless that is your only system and even
then I've never seen the need for it to be in a general "production"
library.
In the old days before source debug having source on a production
machine was pointless. With source debug support I'd rather use *LIST
if I need to debug a production application.
Of course, you still need to have a tiered source storage system with
"production" source, "test" source, "development" source but although
both objects and source may share the classification of "production"
they don't have to be on the same machine nor in the same libraries.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
