Almost everything here is incorrect. You do not loose positioned
updates
when using RLA, everything is positioned. You loose set based
operations.
using SQL for data retrieving and writing with RLA you would have to
reposition and so loose direct positioned update (update... where
current
of...)
Really? I don't think anyone here is advocating that. I heard use the
best tool for the job, this is most definitely not the best tool for any
job I can think of.
No, it has nothing to do with RLA, it has everything to do with the
high
cost of disk space when most RLA applications were first written, and
momentum. Back in the early days, it was far too expensive to journal
everything, so commitment control was not common. Even in
applications
that used SQL back then. Had nothing to do with capability.
about 20 years ago, I was working for a bank in germany and we
journaled
everything - and we did not have any problems! And reading posts in this
mailing list, you will find very often: use commit(*NONE)...
Ok, you make my point. Capability is not part of the issue. I would
expect a bank to use commitment control, anyway since the accuracy of the
transaction is far more important that the cost of the hardware. If your
bank didn't use commitment control they were just plain foolish, or maybe
the cost of doubling the journal space was just too great. Not sure what
the reason for your bank was, but it certainly wasn't capability because
they had the capability.
And transaction handling is no
different between SQL and RLA.
Never heard of set transaction or isolation clause?
Yes I have. Those pieces are optional, and just add complexity to the
issue. Are you arguing for the simplicity of SQL commitment control, or
that it has some extra functionality. You started out arguing that
commitment control was easier with SQL, then start talking about things
that complicate the issue. Now if you have a situation where you need
more than one isolation level within a single job, or you need fine
grained control over the transaction to the point of where the first one
begins, then these options will help you. I have never come across a
situation like this, your mileage may vary of course. I have also never
come across a case where I needed to segregate commit boundaries using
separate activation groups, though in this case RLA works just as well as
SQL, but I consider both of these cases outliers where you use the best
tool for the job.
If you are using level checks properly, then this is a non-issue.
Level check and SQL created tables are a nightmare, its only a kind of
signature over the SQL statement and moving data from one DS to another
DS,
or overlay could corrupt data and rla tries to bring this to database
without field level checking.
Not it's not. As far as the RPG is concerned, the level check works the
same for DDS or DDL created tables. This is like saying that using data
structures is a nightmare. Now if you are using DML, the level checks
aren't necessary because the fields are moved individually into the
individual fields in the target data structure. Maybe this is what you
are refereing to. But, RPG is a high level language. If you declare
things properly, the data structures and level checks protect you from
database changes when using RLA by not allowing the program to run when
something is out of sync. If you choose to override that behavior, you
are on your own. Even in SQL once you get the row into a data structure,
RPG allows you to move it to another data structure or unstructured
character field without any sort of field level checking. So if you are
saying that you can write bad code in any language, you won't get any
argument from me.
midrange.com
