On 21/03/2008, at 4:46 AM, Alan Campin wrote:

I guess my question is, why do people continue to use multiple source

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

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.

Simon Coulter.
FlyByNight Software OS/400, i5/OS Technical Specialists

Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
ASCII Ribbon campaign against HTML E-Mail / \

This thread ...


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

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