And that is your justification for using RLA.? They both read records?
The SQE uses all of the operations listed in my last post - not just the
"read". The problem with these SQL vs. RLA debates is that some proponents
have taken a position that it must be one or the other. SQL and RLA are not
mutually exclusive. Why debate as if they were?
They both have pros and cons. They both have valid use cases.
Not all use cases need a complex runtime environment like the one provided
by the SQE. They don't need the overhead. They don't need the additional
memory that is required. They call it an "engine" for a reason. There are a
lot of moving parts. It wields a lot of power. It makes a lot of decisions
for you.
What if all you want to do is check whether a record exists? If that were
the case, then the SQE would be overkill.
The pathetic thing about these debates is the implication that if one
speaks in favor of RLA, then they're not progressive. Sad, very sad.
There's something very elegant, streamlined, and efficient about binding a
record buffer to an I/O operation (whether read, write, or update). That
doesn't mean the record buffer must map to a physical file. It could map to
a logical file.
I should admit to having some heartburn myself about the RLA implementation
in RPG - the idea that you must hard-code a file name in a program. I
prefer an RPG wrapper around the RLA functions that are exported from the
QC2IO service program. But that's another topic.
midrange.com
