Re: RPG - I'm not dead yet! -- RPG400-L

This simply isn't an argument you're going to win, Alan. RLA, also known as ISAM access, is a database access technique that is simply a better tool for certain operations than SQL. Those operations happen to include the operations most needed by data-driven business rules.

Unless you use some form of externalizing the I/O (which no one would ever
use) in 3 words
"data base independence". The cost of hard wiring the database into an
application are tremendous.

No, they are not. There are actually huge benefits to an integrated database, which can lead to reduced programming time and thus reduced development costs. For example, I don't have to specify every field that I want in every I/O access I write. That in itself is a time saver of monumental proprotions (not to mention a great way to avoid typographic errors).

The whole point of SQL is to have a logical view
of the that is different than the physical view. We are writing new
applications using Java. The database is changing constantly. Could you
imagine how difficult that would be if you used RLA and had to recompile
every bloody program in the system every time we added a new field to the
database?

"The database is changing constantly". During initial development the database may change a bit, but once the application reaches production frequent major database changes are a sure sign that the initial design was flawed. In any event, a database change is a fairly limited impact. No database file is used in "every bloody program" and in most cases database files are used in very limited subsets of the system.

If, on the other hand, you do have a file that is central to many programs in your system, it's probably a good idea to have designed that one properly so that you don't have to change it all the time.

Every time we talk about using SQL, people are always worried that SQL is
slower. For a hundred millionth of second isn't it worth it to have far, far
simpler development? Our current system has kludge on kludge on kludge
trying to get around that the database is frozen. Making the smallest change
is prohibited because nobody want to recompile 10,000 programs.

A hundred millionth of a second is 10 nanoseconds. Database access is traditionally measured in milliseconds, not nanoseconds or microseconds. And fetches for SQL records are typically orders of magnitude slower than ISAM retrieval. I've proven this repeatedly.

We worry about a few hundred millionth of second (real or imagined) and
spend hundreds of thousands of dollars and maybe millions trying to get
around the database being hardwired into the program. I can give you example
after example in my current system or other systems I have worked on where
there are incredibly complex solutions to problems to huge amounts of time
and cost that could have simply been done adding a field to the data base or
resizing something.

Adding a field is a simple mass recompile. Measured in hours at most, unless you have a horribly underpowered machine. But I also have to point out once again that regular database changes point to a severe lack of upfront design.

We run a hundred trigger programs firing every time a change is made in 100
tables in our system and all 100% SQL and I have not seen one iota of
performance difference in our system because of SQL. The cost of not using
SQL are so high that any speed difference is completely unimportant.

Since you talk about how you have to recompile every program for a database change and you measure access in nanoseconds, I am skeptical of your other claims. But given the fact that it takes you weeks to write a kludge for a database change, then I can see that perhaps you do have design issues - issues that are only masked by the ability to add fields intemperately. BTW, in a SOX shop, the paperwork required to add a database field usually takes longer than the recompile required to implement it.

I could go on and on about how much simpler it is to develop using SQL but I
really don't have the time. The bottom line is that other languages and
system using SQL and people on the AS/400 keep using RLA. Where do you
figure the jobs are going to be? They simply add a new field to a table and
they are done and we spend weeks writing some kludge to get around changing
the database. Where are companies going to spend their dollars? If we look
around at the job market I think we already have our answer.

Actually, in a modern IBM i shop we use both SQL and RLA. We use Java and RPG. Some people even use PHP. But we use the right tool for the right job. People who are stuck in the SQL pigeonhole lose that ability.

Joe