Re: Computerworld lists obsolete job titles

On 12/4/14 10:40 AM, Monnier, Gary wrote:

Without a problem or don't have a choice?

I'm not against SQL. I'm not against file I/O . I'm not against
Non-SQL databases and their data access methods. As always, you use
what is best for a given situation or, what you have available.

I do take exception to SQL being termed "modern" and you must go to
SQL-based databases to "modernize". I've stated it many many times:
Get away from the terms "modern" and "modernize" when you really mean
decouple your database from your user interface.

What he said.

SQL does quite a number of things extremely well.

DB2/400-native RLA does quite a number of things extremely well.

There are some things that either one will do extremely well.

There are other things that one does extremely well, while the other is extremely sucky, and requires massively complex code to accomplish. And that goes both ways. In our CRM product, I took something that was massively difficult, not very flexible, and required extremely comlicated code with multiple logicals, and simplified it greatly by doing it with calls to OPNQRYF. Then I took that, and re-implemented it in SQL, and ended up with something several orders of magnitude simpler, more flexible, and more reliable. On the other hand, I also wrote a JDBC interface to allow our QuestView product to access other databases (both other boxes and other-than-DB2/400). And that turned out to require immensely complex code, including extensions to JDBCR4 to front-end methods it had never needed to front-end before, and it will probably never be as good as RLA for the things RLA does best.

And you don't need a primary file to benefit from giving your code a ride on The Cycle: as I said, if you slave LR to, say, F3 and F12, it becomes a ready-made event-loop for an interactive terminal-based program.

(And I think I may have done one program, in 20 years, where level breaks were worth learning how to use on a very rudimentary level. And I've never done anything that looked like it could benefit from a secondary file.)

--
JHHL