All the code in one place (was: OVERRIDES)

>> Thanks. What if the OVERRIDE is done
>> in the RPG itself? I know,bad idea,
>> but it's been like that forever.
>
>
>Why is that a bad idea?  I think putting
>it in the same RPG where the file opens
>is the *best* way to go about it.
>
>IMHO, a well written program never relies
>on other programs to make sure it does it's
>job correctly.
-snip-
>This way, everything's right there
>in front of the programmer.  He
>doesn't need to search to find every CL
>that might do different overrides
>on a program.

I have a slightly different view of this: there is no way that a modern
application can be written with one source member.  I'm exaggerating for the
sake of impact, but conceptually, I _want_ my programmers to think big.  I
_want_ them to go out and look at the job stream before tinkering.

Not that the participants in this thread have done so, but I have heard way
too many RPG programmers refuse to use /COPY members, service programs and
DDS (esp. printer files) because "I can't see the whole thing at once."

Scott is right when he notes (indirectly) that code that operates together
should be together, and he's surely right to note that an OVRxxx in a CL
program far upstream has an effect on the downstream RPG program, but that's
the nature of overrides.  It's also the nature of activation groups - they
affect more than one program.  And that is the nature of modern
applications, I think.
  --buck