Re: Re[2]: Question using jdbc/jt400

On 8/30/07, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

You seem to be missing the fundamentals of the situation, Carl. Let me
explain the business requirements. Please show us the exact code that would
be executed in response to the following user requests:

1. Show the first ten records of the customer file in alpha sequence. This
is the load of the work with customers program, and is done by the following
ISAM instructions: OPEN, READ (x10).

2. Position to the first ten records of that file starting with the first
record starting with "G". This is the standard "position to" feature that
the user would request. It is executed by SETLL, READ (x10).

3. Give me the PRIOR ten records. This is accomplished by READP (x20)
followed by READ (x10).

Your inability to believe that a _simple_ inquiry program can't be
written without record level access has me speechless.
You seem to be suggesting that all the PostgreSql, Oracle, MS Sql, and
even MySQL users in the world are unable to efficiently query there
customer data? You had better tell them, quick!

At no point is more than three times the page size ever read. In most
cases, there are exactly ten reads. No indices need to be rebuilt. Please,
show us how to do this without three different result sets. Because it's
clear one of us is just plain wrong here, and I'm pretty sure it's not me.

Any implementation of your trivial request will simply be criticized
based on your rules, which change and grow with every post.

Also, even _if_ you needed to use two queries, what is the big deal?
I've worked on web applications backed by MySQL where each page
request would make several dozen queries and consistently provide
subsecond response times.

Oh wow! You've used MySQL! On thousands of records, I bet! Sorry for the
sarcasm, but try scaling to a file with 100 million records and then tell me
how your response time goes.

This is good, I specifically chose MySQL for the example because I
could tell you would not challenge that MySQL could do something DB2
couldn't, and the only point was to debunk your inane requirement that
no more than one record set/query be used.
You're sarcasm only confirms my belief that you are not interested in
discussing, but rather just proving your point. By the way, are we
talking scalability/performance now?

You seem to be leaning towards a RPG vs SQL discussion, which is like
comparing apples and orangutans.

And yet, you were willing to compare the two, and even to say that
SETGT/READP is a workaround ("arose from the inability to dynamically sort
records").

Yes, my observation was/is that the RPG Idiom of SETGT/READP has no
place in SQL, Not that record level access has no business in RPG.
Please read that last sentence again... now please go back and read my
original post again. All better now?

FWIW, I concede that RPG record level
access is more efficient, and provides nice granular access vs. SQL,

Which makes ISAM more appropriate for certain classes of business
problems...

I also maintain that SQL has many strengths over RPG records level
access.

...and SQL more appropriate for others. That's all.

A discussion about RPG vs. Java would be... unproductive, I
imagine.

It depends on your goal. If your goal is to constructively identify the
situations where RPG is best suited and the situations where Java is best
suite, then it would by quite productive. If the idea is to try to prove
Java is better than RPG, then I imagine you'd be disappointed. I use Java
and RPG every day, just as I use SQL and indexed access. I understand the
strengths and the weaknesses, and I have both in my arsenal. I believe in
the right tool for the job.

But that's just me.

My goal was clear, not to start a Java/RPG comparison. Period. I
consider myself quite proficient in both.

What you consider a "fundamental lack in SQL" I think is nicely
handled by a record set or record cache, as I've demonstrated above.
At the _most_ basic, SQL simply selects data, and it is the
programmers responsibility to use that data. Languages with good SQL
support simplify this process, as is the case with Java and
java.sql.ResultSet, for example.

It is not. Again, please work out the simple example. Position a cursor at
three points in a view by key. IT CAN'T BE DONE. Yes, you can position by
what is in effect relative record within the view, but that doesn't work on
million records files. Again, please write the code for the example above
and then get back to us.

I think we've gone a bit of topic...and I've refrained from asking any
questions in this post. If you feel that there is something that needs
clarifying, let's start another thread or feel free to contact me
directly

You may not have asked questions, but you've continued to make inaccurate
statements. And you've implied in earlier posts that "record level random
access may not be needed", a point which is flatly wrong.

Joe

I've already agreed long ago that (native) record level access is more
efficient. That is not the question at hand. I certainly regret
encouraging your diatribe about how SQL is "fundamentally flawed" for
not having record level access (which it does).

I said it before, but now I've really lost all interest in this
thread, and regret having encouraged you. I didn't intend to start an
argument, and don't intend to continue it. Please go back and read my
original post, maybe you'll find it a little less offensive now that
you've had a chance to vent.

Besides, It has become increasingly clear to me that you are only
interested in championing RPG/record level access.

Have fun with that.
Carl.

P.S. I'm still laughing at the part where you suggest that a simple
paging, customer inquiry program can't be written without record level
access, priceless...