RE: Computerworld lists obsolete job titles

"I’ve taught RPG to many Java/C++/.Net/etc. programmers and most of them
embrace record I/O as being simpler -"

Sorry to be so long in responding to your responses to may statement
concerning SQL.

1. Concerning simpler. I just don't get that.

Are you telling me that if you told a Java Programmer that you had an I/O
method that reads the entire record into the program and that if you wanted
to make the smallest change to a table they would have to recompile every
single program in the system that used that table and index that would be
simpler? I have spent thirty years watching programmers create extension
table or extension extension tables because nobody wants to recompile the
entire world or filling up the record with junk fields or using some other
field not intended to be used for that just to avoid recompiling the entire
system. The number advantage of SQL is data base independence.

It might be easier to load a print or display file during coding but it
sure isn't doing maintenance. The hours and hours I spent trying to figure
how a field got populated. I always name fields in a display or print
uniquely and move explicitly so I know where they got loaded.

That you had an I/O method that discourages normalization. I know that you
can but when you use the system as System 36 with a file system it sure
doesn't encourage it. SQL encourages normalization.How many times have I
asked a programmer why they designed a table this and heard "Well, I don't
want to have to chain in a bunch of different records so I just put it in
one record" More than I can count.

It is simpler to have a I/O method that encourages using code to implement
logic instead of letting the database do the work? I am always astounded
the amount of work people do. Read record in, check some field to see if it
the record you want, then reading another table and check to see if that
has the record you want, etc when you could have done the whole job in one
SQL statement that let the database do the work and, of course, creating
dozens of field select logicals over a table.

My point to all of this is that file I/O might be quicker to code, and I
question that, to write the code but it sure isn't to maintain it.

I can sit down almost anytime and write SQL that has a fraction of the code
I would have generated using file I/O and simpler to understand. The only
thing that is a real pain can be null's in updates and that is simply
because IBM has refused to make SQL native for RPG. The number thing RPG
needs is tight integration with SQL but why would IBM do that if the
programmers are all using the system as a big System 36? Remember that
statistic a few years ago that fewer than 10% of iSeries programmers even
knew the iSeries has a relational database.

When you start looking at costs associated with maintenance, lack of
normalized databases and business logic being put into code rather than the
databases, the costs of file I/O are huge.