On 21/03/2008, at 4:46 AM, Alan Campin wrote:
I guess my question is, why do people continue to use multiple source
files?
Probably habit--same reason they continued to use 6-digit dates for
far too long.
I have always used a separate source file for utilities (was UTIL_S38
and now still named UTIL_400). I also use separate source files per
application (or utility depending on my needs).
I stopped using the IBM QxxxSRC files long ago (although I do
sometimes let ADM use those defaults because it is easier when
creating a new part).
What gets me is user-created source files beginning with a Q. That's
for IBM stuff. Why do you have QSRCF? Why do others have QPROTO,
QPFSRC or some such rubbish?
The other thing I don't understand is NUMBERED objects. What the hell
is program XYZ9934? Sure, you can wrote-learn what the common ones do
but we have an object-based system. Give things proper names! Decent
abbreviation standards can give meaningful names for most objects.
Variations on logical files or reports may need a numeric suffix but
surely these are the exception.
I tried to get our shop to a single source files and other programmers
had a canary. We have to have multiple source files because that is
the
way it has always been done! Drives me crazy because I have to look
through all kinds of source files trying to figure out where the
source
is.
Although I used to put all related OPM code in the same source file
(all RPG, CL, DDS, UIM, etc. for one application/utility) I still use
separate source files for different parts of an ILE application/utility.
Code (RPG, CBL, CL, C, DDS, UIM, etc.) all goes in a single source file.
Binder language I think should be separate because they define the
public interface. They don't need to be with the "private" code. I
tend to use the default QSRVSRC for this
Prototypes should be separate because they are used by consumers of
the interface. The consumer should have no business wondering about
HOW the function is implemented, only WHAT the prototype needs. By
separating the "interface' from the "implementation" using different
files there is (perhaps) less temptation to peek at the source.
I use RPGLEINC, CBLLEINC, H (only for tradition) etc. source files
for prototypes and, obviously, I separate them by language type.
The only issue that I know of is if people name source members by the
same name, a practice I strongly disagree with.
That's one of the advantages of an object-based system. The object
type distinguishes between names. Other platforms have to add the
"type" to the name or via an extension. Thus we can indicate a
relationship between objects by using the same name for them. Of
course, this only works for simple applications (one program == one
display file)
I've seen systems that have DAY_JOBQ, CTL_DTAARA, NIGHT_SBS etc.
objects which is simply stupid. You wouldn't stick PGM in each
program name so why put it on other objects?
Other than way back on the System 38 somewhere an IBM programmer
decided
to use separate source files for different kinds of source, is
there any
reason to continue to use multiple source files?
I see no reason to continue to use the IBM-supplied source files
given tools like PDM and the various client IDEs sort out the file
name for you.
However, some separation by application/utility seems necessary
because there is a finite limit on the number of members allowed in a
source file (32,767) and this can be reached quicker than one might
think. Also, list processing is slower as the members in the list
increase.
Putting all related code in a single source file can make global
searching easier--especially with PDM. You can always filter the
source type to include just the type in which you're interested.
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
