Re: RLA & SQL was (Re: SQL database object names longer than 10 charactersand mixedcase?)

Hi Paul,

The proper use of RLA (as opposed to the traditional use of RLA) means
that the RLA should be encapsulated. Therefore, if the underlying data
changes, then only one module in the whole application needs to be
re-compiled. It all comes down to the design.

that would be my recommendation: if you are using diffrent technologies, one of them should be encapsualted, so that nobody has to deal with both. But in this case it would have drawbacks and I wouldn't do so. You would loose the ability for positioned updates, which are much faster than searched updates, because the need no repositioning and if you need read stability with following updates, the update modules are useless, they won't get the record locks, they need. In my opinion transaction handling gets rather complicated.

I don't like being in the position where my application will be "a
little bit slower, or needs a little bit more hardware ressources" just
because of a programming style decision. And when there is little or no
difference between RLA and SQL access speeds for a single row being
returned, I will gladly drop RLA.

this would be an argument, if you would really need the microseconds of speed, or if your ressources are used at 100%. In my experience I often found the opposite condition, the ressources where not fully used and the application could not benefit of the free ressources. SQL can use more ressources, if its used properly. high granularity of statements (multiple rows touched by one statement) with parallel database feature, does a lot of parallelisation.

Your description of commitment control is all true - but it is smoke :-)
You can meet all the commitment control requirements with RLA - it is
just a bit more work.

agreed, its possible (nearly nothing is impossible, its always a question of effort), but I never saw commit used with RLA, ist even rarely used with SQL, thow its rather easy to use with SQL; thats one point, where the RPG community is far away from state of the art and it has something to do with RLA!?

You said "Using two concurrent technologies to do the same, (DDS and
DDL, or SQL and RLA) complicates application developments and the
readability of code is worse, then concentrating on one of the
technologies, so there is a decision to make between SQL and the native
interfaces". I'm sorry, I really don't see how the readability of code
is worse.

Same thing with mixing up RPG and Java, a programmer who has to do maintenance in a programm using SQL and RLA has to have knowledge with both technologies. Encapsulation (as you mentioned before) would help, but the problem is not gone, if you are searching for bugs (caused by lock contention for example).

You said "RLA transfers binary huddle between the database and the
application with higher risc of data corruption." How?

Data Structures are untyped storage description (I call this binary huddle, since I've written ArdGate) . If a datastructure doesn't match the record format, you would transfer every nonsens to or from the database, using SQL the compiler will do more checking for you and at runtime the database will do more checking at column level, even if you would use Datastructures in your programm. (BTW: IBM claims that DDL Tables would be faster than DDS Tables and they claim a single database operation would be faster with SQL than with RLA - in my opinion and experience both are marketing, SQL is a little bit slower in real world and needs a little bit more ressources - you don't get anything for nothing!!!!!!!)

Dieter

Regards

Paul Tuohy
ComCon
www.comconadvisor.com
www.systemideveloper.com





dieter.bender@xxxxxxxxxxxx wrote:

thats a flame? its hot air only, without arguments! You are throwing around
words like nonsens, hammer and nails, blah blah - all indicators for the
lack of arguments, not worth to respond to.
For those who are reading this thread and might be interested in the
contents (not for hot air pilots!):

Record Level Access is outdated, since SQL came up to AS/400, its good old
ISAM (index sequential access method) and SQL supports the relational
approach. Tieing the application to the database happens by navigating thru
the datatabase by moving key fields from one table to fields of another
table to make a chain operation to read another table - its not the problem
altering the scale of fields. Proper database design is always a picture of
your business world at that time you designed your database and as time goes
by, your business changes and the data model needs changes to follow the
changes of your business and therefore you should decouple database and
application, as far as it is possible.

SQL is a strongly typed language, each assignment, each comparisation
between your host language and the SQL layer and each transfer of data
between the database and the SQL interface is checked of type compatibility.
RLA transfers binary huddle between the database and the application with
higher risc of data corruption.

All default settings of SQL are prepared for using commitment controll and
it's by far more easy to use commitment controll and you should use this,
it's state of the art and data corruption, caused by not using commit blames
the programmer, who didn't use it. updating data in normalized databases
needs transaction controll anyway - and this would not work without commit.
Applications running 24 hours a day, seven days a week need transaction
controll, because there is no offline window for producing consistent
reports.

Using two concurrent technologies to do the same, (DDS and DDL, or SQL and
RLA) complicates application developments and the readability of code is
worse, then concentrating on one of the technologies, so there is a decision
to make between SQL and the native interfaces and I recommended and
recommend SQL even thow it might be a little bit slower, or needs a little
bit more hardware ressources (and in my experience, its slower and sucks
some ressources!).

Finally, moving from DDS and RLA to SQL is a step in the direction of the
mainstream of application development and could save your knowledge, if
there will happen a move from AS/400 to another system (could happen, I've
seen this sometimes last 20 years and nobody moving from something else to
as400 since 10 years).

Dieter
--------------------------------------------------
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Sent: Monday, November 01, 2010 12:33 AM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: SQL database object names longer than 10 characters and
mixedcase?

On 10/31/2010 5:23 PM, Bruce Hoffman wrote:

Opposing view...

First, the obvious and probably not under dispute... ALL changes,
improvements, performance, advances are made only in SQL. Define all
tables in SQL DDL. IBM stated this more than a decade ago. This can be
done now, and does not require changing applications.

This is the only part of your post that actually has a basis in fact. I
agree, and have said this for a long time as well. DDL is (almost) a
superset of DDS and with better performance. Just make sure you use a
source file to create your tables and have that source under the same
version control as your programs. But your data definition approach has
exactly zero to do with your data access technology, and there is where
we differ really, really quickly.

Continued use of RLA for I/O, ties your database interminably to the
past and makes moving forward with your database no better than any
other time in the past since you are at the mercy of the format level
identifier. You are tied to the physical representation of your tables
and this is one of the reasons that people still see IBM i OS as "old
and outdated". It's also one of the tenants of Relational Technology...
separate your applications from the physical representation of the data.

Nonsense. In the first place, you shouldn't be making regular changes
to your database; ALTER TABLE is no substitute for good database
design. But let's assume that your design skills are so poor that your
database suffers for it and you have to change it regularly. Then at
least have the common sense to wrap your physicals in logicals and get
over your bad self. Hey look, ma! No format level identifier
problems! (That is, of course, unless you've designed your database SO
badly that you regularly have to change the attributes of your EXISTING
data fields even after they've gone into production. If that's the case
then you probably should consider broadening your employment horizons.)

As for the "old and outdated" bullpuckey, I assume you're telling
everyone to dump RPG as a development language as well, since it's old
and outdated. I haven't seen you advocating that Bruce, am I wrong?

While IBM i OS RLA applications call for recompilations every time we
make a change to the database, the Oracle, MySQL and SQL Server people
have already altered their tables and are accommodating requests for
change while we wait for a good time to take the machine "down" and
recompile the world.

More blah blah. Use logicals. Change the physical using CHGPF.
Everybody's happy. I can't believe it's 2010 and we're still having
this argument.

Additionally, you can't use index-only access from RLA. You can't take
advantage of EVIs. You don't have as much control over what fields are
actually retrieved and or updated by your applications.

Yeah, okay, a second valid point. But you see, unlike you I recommend
taking advantage of the incredible strengths and versatility of the IBM
i and use each technique as appropriate. I use SQL all the time, and I
also use RLA.

Just because you like the big shiny hammer of SQL doesn't make every
programming problem a nail, Bruce.

Use the right tool for the right job.

Save the database, save the world!

Joe

P.S. Dieter? *That's* a flame. You didn't even get a warm breeze...
<smile>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.