RE: ALL I/O in single module was(ARGH!!! (was file open with LR)) -- RPG400-L

  This, by
the way, is another reason that I advocate moving ALL file I/O for a
file into a single module; it avoids some of these issues.  It sometimes
causes a little extra upfront work, but in the end it makes your life a
lot cleaner.

I've been coding RPG since '84, so I'm somewhat of a dinosaur in this regard.

I haven't been convinced (yet!) that it's better to have the file I/O in one module. With the existing code, I can look at the F specs and see what gets read and/or updated. I can scan for CALL and see any programs that might also update a file.

With procedures, the code is much more intertwined, and it doesn't seem as easy to be sure what a particular program might be doing to the database.

Some opinions are that this makes for easier maintenance. In the case of RPG, I've seen approaches of this type where the record layout is pulled into the main program via an external data structure. The procedure then reads the record from the database, loads it into the data structure, and then returns the data structure to the main program. This doesn't appear better than just having the file defined in the main program, as any change to the underlying table will surely require a recompile of both the main program and the procedure in the event that fields are added to the table or changed.

I'm trying to think of other systems where using a function to do the I/O and passing back a data structure is done. I can't think of any. For example, when I write Perl code to access a MySQL database, I generally do it as simply as possible:

my $dbh = connect();

# Get last name, first name from the table
my $sth = $dbh->prepare( "SELECT ulnam, ufnam FROM person") ;

$sth->execute;

while ($row = $sth->fetchrow_hashref) {
    # do stuff with each row
}

I don't try to write a function that returns a data structure for each record, although I suppose I could. The reason I write it this way is because it's clear and concise. I could build this as a routine that forces the user to implement a call-back to get back each row. I could somehow use a static variable or parameter to indicate whether the query should be run, and then return each row on successive calls to the function. I don't see how that's easier or better.

I don't try to write an object that returns a data structure for each record, although I suppose I could. I could have an object with a method for setting the desired database key. I could have another method for executing the query. And another for returning each row. But why? It's building a new interface that's not necessary. There is already a direct interface to the database. Why recreate it? Anyone familiar with the database can already retrieve any data in it. If you force someone to learn your object-ified way of accessing the data, it seems to me you are getting in the way of getting the job done.

If I have this code in 100 different programs, and it has to change, I think that's probably OK. The reason is - if you have to change the query to return a new field, say for example, the person's middle initial, I also have to change all of the callers to actually *do something* with that new element.

I'm not trying to rain on your parade, I am just interested in understanding what the rationale is.

Regards,
Rich