×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
wdsci-l-request@xxxxxxxxxxxx wrote:
7. Re: qrpgsrc vs qrpglesrc (Alan Campin)
This is one of my pet peeves. Why do we continue to have to use multiple
source files names?
I use a single source file QSRCF defined at 132 for all source but
continue to battle with other programmers because they have to have
QRPGSRC, QRPGLESRC, QCLSRC, QCLLESRC, QDDSSRC, QSQLSRC, etc, etc, ad
nauseam. The old familiar refrain "That's the way we always did it.".
Using WDSC mitigates this to some degree but why have all these names?
All your source types are together in one file and can be seen together.
Use a single source file and eliminate the problem.
Though it can reduce some problems, it can't eliminate them.
Further, it introduces other problems.
There's no good way to guarantee that only a _single_ source file
exists. I suppose it could be done through various command exit
points, etc.; but I can't think off the top of my head of all
potential restrictions that would need to put in place. If it can't
be guaranteed, then it gets troublesome actually to rely on it even
as a 'standard'.
Beyond reliance, it effectively makes it impossible to have two
different sources with the same name. I regularly encounter *CMDs
that have the same name as their CPPs. It's not required to have
source members named the same as the compiled objects, but it seems
fairly common. And I often create "stub" programs/modules in CL that
return "test" values or known values; and they have the same names
as any actual RPG, COBOL or C program/module that they're standing
in place of.
Now, part of the point of this is that there can be differences
between production, test and development environments. So far, I
haven't seen in this discussion an attempt to differentiate between
them.
A production environment might be restricted to a single, unified
source file. (That assumes that any source files at all are allowed
in production.) A standard to that effect is only the first step;
monitoring and enforcement are also needed. A test environment is a
little more difficult to control, but more possible and controllable
with standards than without.
But development -- that seems unlikely and even undesirable under
numerous circumstances. It seems more a matter of choice and style.
So, what environment is being discussed?
Tom Liotta
midrange.com
