Re: ARGH!!! (was file open with LR) -- RPG400-L

Buck wrote:

Hi Booth!

Joe, doesn't one lose the value of reusable code
if you can not depend upon it?

Great question!  I have strong feelings on this matter so indulge me for a
moment.  I don't think that the Grail is 'reusable code,' but rather
reusable LOGIC.  Business logic.  Reusing code (especially entire programs)
can lead to scenarios like the one Brad has struggled with.  Without a
complete understanding of the intended architecture of an entire application
(which is all the programs in it), I would be very ill at ease simply
calling individual programs from that application.  I am NOT saying that
this is what Brad did, but I'm trying to make the point that an application
grew according to some design: even if that design was never discussed.
Programmers made decisions and implemented them in code.  Overrides here, no
LR there.

I'm really obsessive about this, because I see more than a few programmers
who look only at a subroutine and think they understand what it is doing.
But they have not looked at the cross reference: does file I/O modify
variables?  Indicators?  Is there a data structure somewhere?  Program
calls?  And that's just in the RPG program.  There's probably a whole job
stream, replete with overrides in CL, OPNQRYF or FMTDTA, CPYF, calls to
other programs before and after this one - you name it.  And that's just
this job.  The database files are updated by other processes; the
information has a life span (transaction file data is good until committed
at EOM or whatever.)  When those files are purged of old records can make a
world of difference to understanding why THIS run came out different from
the one last night.

Reusing code is a step toward the goal of reusing logic, but until we write
code in a way that makes the logic reusable and independent of the rest of
the code, we are going to have to do some work to get at it.  That's what I
think, anyway.

First, there's not a single application program in use that doesn't depend on the behavior of some code that the application developer has never seen or has no control over. That's even true for the vast majority of systems programmers too. There is always some part of the programs we write that was written by someone else. And so already we absolutely need to deal with the issue of code reuse - we shouldn't have to understand how every single bit of an application works.

With respect to the problem Brad was struggling with, the main problem was that there was insufficient separation between the various pieces of the application (within the business logic), with two different modules accessing one file. In this case, a better app design would have just one module accessing the one file. Alternatively, if you're not completely sure what happens in a particular layer of an app, isolate it by putting it into it's own activation group. Or as a general principle, keep files open for just as long as you need them.

I agree that the OS/400 programming community has some, no, a lot of catching up to do with respect to code reuse. I think the main problem is that vast legacy of code that was written without reuse in mind. This may seem like an extreme position, but sometimes I think the best thing a shop can do is just throw out all that legacy stuff, and re-code everything from scratch. :-\

Cheers! Hans