|
<Sorry if this is a re-post. I never got it, but my e-mail messes up from time to time. This was written while Janet's post came in asking: "It keeps making me wonder why we can't raise our arguments up to a more relevant level!" Don't know if this helps much, in that regard...;-> <DANGER, DANGER Will Robinson...! Long post incoming...! ;-> 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. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.