RE: Green screen - it's time is over

Galls me, a little, to have to say I agree with Joe...  LOL...!

I don't know enough SQL to judge it's effectiveness.  And the conventional
wisdom is that Industry Standard approaches are the best approaches...

I do not agree, at all...  Sure, you CAN do anything you want to accomplish
using SQL.  But I've yet to see a decent argument in favor of using SQL for
RLA.  If you know SQL like the back of your hand, it may appear to be clean
code.  SQL looks like some weird aboration if you don't know it like the
back of your hand though.  And the fact is:  everyone on the 400 knows DDS
and RPG (or it's "evil twin" Cobol) like the back of their hand, or at least
sufficiently.  They're simply a more general solution.  They handle sets
fine, and they handle RLA fine, too.

It's not only the performance issues, although I think those are sufficient
to weigh against SQL for RLA.  I've never seen an advantage to going through
some extreme coding hoops, soley in order to come up with an Industry
Standard approach to solve a problem.  Square peg.. to me, anyway.

I've read enough posts on the argument of SQL vs. OPNQRYF.  To me it comes
down to Industry Standard vs. non-Industry Standard, and what your skill-set
is.  With the emphasis being that the "right" solution usually involves
people defending the techniques they know best.


===> Most everyone on the 400 has some skill-set in CL, RPG/CBL and DDS.
That wins the day, for me.  However, what I'm seeing is that there is a new
generation that understands very little about CL/RPG/DDS, and they are being
catered to.  I believe it's because IBM uses focus groups to do the market
research on what the Community wants/needs and is willing to pay for.  Based
on the results, I don't view that as a very effective way of determining
these very highly technical issues.  So CPF and RPG appear to be going in
the direction that the system programmers prefer, rather than what the
market needs.  These systems programmers, not un-coincidently, have the
least understanding of CL/RPG/DDS and what it is like using these tools to
write applicates that provide BUSINESS SOLUTIONS.

There are simply TOO MANY alternative ways of solving coding problems, IMV.
So, if all other things are equal, I look for coding techniques that are
general enough to solve the most wide array of problems.  To me, anyway,
that would be CL, RPG and DDS.  But these days, when it is almost as easy to
gen a new language as it is to write an 80/80 list, we have an extreme
multitude of language possibitities to choose from.  Those who know
PERL/LISP/SMALLTALK/APPLETALK/OO/FRONTIER/VB/C/C#/Java/yada/yada/yada would
have you believe that I'm afraid of learning new techniques, and that's the
sole reason I prefer CL/RPG/DDS.  When I visited the News/400 forums last
year, though, I found that the same people cheerleading me on to learn
something new, would then ask a question so basic that it showed they knew
very little about the fundamentals in programming in ANY language.  This
proves the flaw in concentrating on learning new things, and not seeking a
balance between that, and learning a few things EXTREMELY WELL...  Anyone
who's been in the business for any length of time, knows what I'm talking
about.  Very few who haven't been in the business that long understand this
point.  And they are the systems programmer who are now designing the 400
architecture, IMV.

Many, if not all, systems programmers are fundamentally clueless when it
comes to the subject of writing business solutions.  The reverse, however,
is not true at all.  Joe is but one of many clear examples of proof positive
of that statement.

A compiler is a specialized form of a business system.  The fact that there
is a wide schism, and there are still many folks who use RPGIII-style (and
saw a post that RPGII is still used), indicates a fundamental problem in the
language.  It's true that some people will resist change, at all cost, and
the compiler-developers can't address the lowest-common-denominator of
coders.  Compiler-developers can't change human nature...

However, the compiler-developers can bridge the gap.  I'm fully aware that
the attempt was made, and IMV, made successfully.  But the market indicates
otherwise.  It is not sufficiently easy to get from RPGIII to ILE, or it
would have happened by now.  The situation is exacerbated, not improved on,
by the new free-form RPG, IMHO.  The argument that if you don't like the
current RPG, you can still code in RPGIII, has been over-used, according to
my view.  I am not looking to go back to RPGIII, but don't buy into the
current direction of RPG either.  Because, in many respects, it is NOT AS
EFFECTIVE as RPGIII.  Not because I'm not interested in learning new things,
as is commonly (and I think somewhat arrogantly) presumed.


That summarizes my prior two posts.  The IC is just an example of an
/extremely disrespectful/ attitude towards the customer-base that uses the
product.  But it a symptom of the same phenomenon, to me anyway.  IBM not
recognizing the needs of the customer-base.  All companies have the same
problem.. any many do much worse than IBM and go out of business.


I'm sure I gave the impression I'm against having alternatives to
CL/RPG/DDS.  Not at all...  But I'm not buying the argument that it's too
difficult, or costs too much, to support this as an effective methodology.
I think the methodology is getting ignored because it's mis-perceived as
being ineffective.  I think the CL/RPG/DDS alternative is getting
short-changed, and that's why we're seeing so few enhancements in the area.

Joe, Nathan, I, and a very small minority of people in the Community, see
that IBM is not making these kinds of enhancements.  So we, in different
fashions and using different methodologies, aim to show this is possible by
way of example.


jt

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Joe Pluta
> Sent: Tuesday, November 13, 2001 11:39 AM
> To: midrange-l@midrange.com
> Subject: RE: Green screen - it's time is over
>
>
> I have less problem with SQL than with ODBC, Dave.  If your SQL is
> encapsulated in a way that your client doesn't use table or column names
> (basically, if you don't have raw SQL statements in your client
> application), then I'm okay with it, to a degree.  I still find SQL to
> perform significantly worse than RLA for non-set-based database updates
> (that is, when you're updating a small number of records, as in
> transaction
> processing).
>
> SQL is fine on the host for ad hoc queries and set-based updates (like
> month-end rollovers and the like).  As long as the details of the SQL
> statement are hidden from the client, I have no problem.
>
> SQL is inappropriate for transaction updates - RLA performance is simply
> superior.  Don't believe it?  Run a few tests.  I've published results
> regularly that show that RLA is still at least 50% faster than SQL for
> typical database updates and inserts.
>
> ODBC, no matter what the application, goes against every possible tenet of
> distributed processing.  It is slow, and it ties your host
> database to your
> client code.  You cannot change even the names of your columns (much less
> the physical layout and location of your data) without updating
> your client
> code.  This is absolutely unacceptable.
>
> Does that answer your question?
>
> Joe Pluta
> www.plutabrothers.com
>
>
> > -----Original Message-----
> > From: David Bulog
> >
> > Joe,
> > Im lost here,whats wrong with business rules in SQL? I would
> like to drill
> > down deep to the nitty gritty of what you dont like aboubt SQL.
> > BTW I thought IBM invented SQL in the first place
> > Thanks in advance
> > Dave
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>