RPG and DB2: The Future Is Now

[vladi]

RPG and DB2: The Future Is Now

Really, there is no problem to learn RPG, especially since V5r2, when it became standard procedural language. And, if your applications based on iSeries, of course RPG is language of choice for server side processing. One point that I disagree with Joe it's about SQL. I think that SQL is the best database tool (not for all programming problems, but for database ones). When I say "SQL", I mean not only SQL statements, but also embedded SQL and SQL control statements, that both are ANSI standard of SQL (by the way, example from Joe's article normally should be written in SQL in the same manner as in RPG, using embedded SQL or by using control statements, that include "if" statement). There are a lot of things that belong to server-side processing that very hard and sometimes almost impossible to do with native I/O. It includes dynamic SQL, but not only. It takes about month to become quite knowledgeable in SQL. I strongly believe that any serious iSeries programmer must know and must use SQL. But... I think the problems with SQL on iSeries is not performance as is (IMHO, in most cases performance of single record access is not the issue, especially when using N-tier architecture with some kind of stored procedures, and in multi-record processing SQL usually the winner, may be after some hours of tuning :-) ). One of the problem is very bad RPG compiler support for embedded SQL statements. While that problem may be aesthetic issue only, the biggest one is a lot of critical bugs in SQL engine - fully spectrum from poor performance till wrong query results. In our shop we using SQL very extensive, and in my bad experience I had "bugged" statements that a little bit complicated than "select * ...". It's really nightmare - to understand what's wrong with your statement, to find PTF that should fix that, to do IPL, and after all that to see that some other program that usually took minutes to processing now takes days! RPG with native I/O always predictable, so in mission critical applications on iSeries, by now, it may be more clever to use it. But I still believe, that one day DB2 on iSeries will became really strong and well performed, so I continue to use SQL. I apologize for my bad English. Vladimir.

[J.Pluta]

RPG and DB2: The Future Is Now

Your English is fine, Vladimir! My question is this: since we already have all the control statements we need in RPG (along with great support for procedures and service programs), then why use the SQL control statements? I have seen SQL statements with embedded CASE statements and that sort of thing, and to me they are almost impossible to read. And you can't put a breakpoint in the middle of an SQL statement, so it's very, very difficult to debug a logic problem. So, look at it from a business perspective. If the syntax for a tool is hard to write, hard to read, hard to maintain and hard to debug, unless it performs a lot better than native I/O, then it doesn't seem like a good business decision to use that tool. Use the right tool for the right job, and there is no better tool than RPG for writing business logic. Joe

[vladi]

RPG and DB2: The Future Is Now

Joe, thank you for compliment, so I continue... :-) From my opinion modern business so complicated and so depends from computers that it's not easy to decide what part of program development belongs to business logic and what not. Some kind of reports may be no less important than data entry program, and more complicated. GUI that supports business work flow in right way may be no less important than data integrity checking. Of course, SQL is nothing about GUI, and, as you write, RPG shouldn't be. So I want to relate to, lets say, "database processing", as a whole. And from that perspective, SQL (embedded in RPG, SQL stored procedures, SQL functions, UDF, interactive SQL utility) gives the incredible power for iSeries programmers. If the syntax for a tool is hard to write? I don't think so. Syntax clear enough and millions of programmers use it. If the syntax for a tool is hard to read? It seems funny, but sometimes may be more clear than RPG. Let's compare: RPG from your article: Chain ITEM IIM; WorkGL = IGLOVR; If (WorkGL = *blanks); Chain IMCLAS IIC; WorkGL = ICGL; Endif; SQL procedure: declare v_item ...; declare v_iglovr...; declare v_imclas...; declare v_icgl...; declare v_workgl...; ... select iglovr, imclas into v_iglovr, v_imclas from iim where item = v_item; set v_workgl = v_iglovr; if v_workgl = ' ' then select icgl into v_icgl from iic where imclas = v_imclas; set v_workgl = v_icgl; end if; SQL embedded: c/exec sql c+ select iglovr, imclas into :v_iglovr, :v_imclas from iim where c+ item = :v_item c/end-exec c/free v_workgl = v_iglovr; if v_workgl = *blanks; /end-free c/exec sql c+ select icgl into :v_icgl from iic where imclas = :v_imclas c/end-exec c/free v_workgl = v_icgl; endif; (Embedded code looks ugly, because of bad design of preprocessing directives in RPG compiler, not because of SQL) So, ok, there are a little bit more declarations in SQL, but... Is ICGL variable in pure RPG receiving its value from IIC table? May be from IIM? May be it some program declared variable at all, and gets value anywhere in previous code? To solve that problem you use naming convention. So I am, but it's doesn't required, it's absolutely clear what happens here: select icgl into v_icgl from iic where imclas = v_imclas; or c+ select icgl into :v_icgl from iic where imclas = :v_imclas Hard to maintain? Of course, there are enough places where performance is critical, and I absolutely agree with you that single-row processing in RPG perform better, and to be honest, things like in previous example I usually code in pure RPG, too. But what if you add new field to one of the tables? You should recompile all your programs that use that table, or override LVLCHK value, that's bad practice. With SQL you have nothing to do. May be in cases where performance in not "so" critical (remote called programs, for example), from that point SQL looks better? One more important thing, that relates to debugging too. Let's say you have to read/update/delete/write output to another table from some table/tables by some conditions - usual task, usual business logic, isn't it? How you do it in SQL? Lets say, we need to read from table - so we have one, may be complicated, statement, probably embedded in RPG, like that: select ... from ... where ... = .. and ... < .. or ... in(..)... In pure RPG may be you have typed less characters, but in SQL you have all "data base read logic" in one place and in one statement, that usually helps to understand better program's logic at all. More than that, you just can copy and paste sql statement into your favorite interactive SQL utility (strsql or Navigator) and can see query result without "strdbg". And even more - there are minor syntax differences between "select" and mentioned before "updateable" statements, and with minimal effort you can change your, say, "delete" to "select" and to see thouse records just before you will destroy them forever :-). That kind of "debugging" is very hard to do in pure RPG. In our shop (retail company) we have ratio about 80:20 between any kinds of reports/queries/batch processing programs and single-record oriented data entry programs, so if we take a look at that 80% area, just think, what efforts you will need to write in RPG that absolutely trivial sql statement: select a.item, b.price from items as a, prices as b where a.item = b.item and a.category = 100 order by b.price Just understand me right. I don't try to say, that RPG is bad and all of us must replace "chain" to "fetch" right now. What I feel, that for many of iSeries programmers RPG is the only development tool (and part of them think that best of the best, of course, either RPG 0 , without those unusable and heavy understandable procedures, service programs, free styles, but with wonderful 99 indicators and so well performed operator "move"). And what I try to say: yes, be very careful with SQL, spend time to understand SQL well - it too much powerful and when wrong used it may kill your server, it "bugged" yet, but use it, because for many jobs it is the right tool on iSeries, and one day it will be the language of choice for data processing on iSeries. Thanks, Vladimir.

[MCWebsite.Staff]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
** This thread discusses the Content article: RPG and DB2: The Future Is Now **
0

[avrahamn@coop.co.il]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
The reason is that You can become knowledgeble in RPG within 4-6 months/ This is not the case in JAVA an neither in SQL. As soon as many young colledge Graduates will see haw easy it is to program in RPG they will switch to RPG. That happened also with COBOL Programmers on AS400 that many of them switched to RPG. and that was on old RPGIII. now with RPG4, RPG has al the advantages from a business logic productivity point of view. IBM just needs to add native GUI to the RPG language. and I believe they will do it. They have in the passed so much improved the language' and they could continue to improve.

[dacust]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
You are right, cdr5000. IBM and RPG will die. Reminds me of back in the 80's, people relatively new to the marketplace said IBM was dying and RPG was dead. It'd all be PC's networked because they were faster, better, cheaper and more effecient. So, yes, the 400 and RPG will die. And they will probably continue to die for yet another 20 years or so....

[David Abramowitz]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
Interesting points are made about SQL in this article. For many years one of the selling points about all HLLs on the iseries is that the single level store allows you to refer to database by name, bypassing the use of SQL. The ability to read, write, update, delete and otherwise manipulate the RDBMS, and do it directly, without the need to use SQL if you don't want to, is IMO a uniquely positive aspect of the box. I say the box, because unlike other OSs where the RDBMS is an add-on over the OS, the RDBMS on the iseries actually lies far closer to the hardware, and below the OS. This creates an efficiency, and a level of integration which AFAIK is unmatched by any other server. Dave

[DarrylHadfield]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
Look at implementation numbers for the iSeries, as compared to the cheap commodity of X86 boxes. Industry is rapidly dropping larger, specialized, more expensive boxes for the commodity computing platforms that provide a better result on the bottom line. Would you spent half a million dollars to upgrade an 820 to an extra processor, and RAM and disk increases, or would you spent a quarter of that cost to buy a handful of x86 machines? Consider also the tremendous lack of marketing support IBM gives to its iSeries line. Look at how long it's taken Sun to head down the tubes - but when's the last time you saw or heard of any of their high-end hardware in a major deal? Be brutally honest. Given the cost, a large number of businesses are dropping x86 boxes into their enterprise, with Linux - running JDBC/MySQL for database serving. Unless you work for a technology company, odds are good that it's a sales or operations person in the CEO slot - and he or she won't be looking at the "best" solution, they'll be looking at the best bang for their buck. Sadly, our iSeries doesn't seem to have that reputation anymore.[*]shrug* I suppose we'll see what happens in another 20 years...

[dacust]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
Yes, the X86 boxes are filling their niche. Many companies that went to all X86 boxes have since moved back. NOT moved back to only a big mini, but to a combination. My company has 45+ iSeries, 150-200 X86 servers and just now, 4 x86 Linux servers. And 1000's of desktops. The main enterprise data still all resides on the iSeries. I'm not saying I know for a fact the 400 and RPG will be around for x number of years. I'm learning Java. As far as that goes, I'm learning 6 Sigma as a fallback in case IT goes South altogether. I'm only saying I have heard all this "foo is dead" stuff before. And almots every time the prediction has been wrong. At the very least, very wrong in how quick it would happen. The iSeries (and 400/36/34) sadly NEVER had the reputation that the X86 boxes have now. But IMO it's because never before have there been so many people in IT that only know their one little area, and so, easily get prejudiced to one way of life. I have about another 15 before I retire. I won't be surprised if I can finish my career out doing RPG. But I'm not betting the farm on that. I'm learning other skills. Not just for job security, but because I LIKE learning new things. BTW, Linux World voted the iSeries the "Best Linux Server". I think I have that right, last year or the year before? I think we'll see more integration. We'll see the iSeries used for what it's good for and the X86 Windoze and X86 Linux boxes used for their strong points. In that vein, I don't understand people wanting IBM to provide a native GUI interface for the 400. Why? Let the GUI boxes do that. Let the iSeries to the database work. It's what it was designed for. -dan

[J.Pluta]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
Imagine yourself just out of college and planning to show the world how things should REALLY work. Would you honestly choose AS/400 RPG for that? Absolutely! With a JSP Model II front end for the web, and mabye a .NET interface for thick client interface. What you're missing here, CD, is the fact that today's development isn't about any one language, it's about picking the best of breed for each tier in your multi-tier environment. I can run JSP Model II front ends to an RPG back end that provide sophisticated back end business logic with response times measured in milliseconds. And the beauty of this architecture is that RPG outperforms other approaches by such a wide margin that I can concentrate on really powerful business rules - rules that will make my end user more productive than any VB or JDBC solution. Not only that, development time is fast and easy. With the combination of STRSRVJOB and STRDBG on the iSeries, I can easily inspect a running job to see what it is doing, check variables, even change them on the fly - that's nearly impossible in most otehr environments. AS/400 RPG is an old-timer's platform. Uh huh. So was the S/3, and the S/34, and the S/38. Unix was going to wipe it out, PCs were going to wipe it out, now it's server farms. The point that all the doomsayers miss is the fact that it's still easier to write complex business logic in RPG than in any other language. The reason all those desty machines are still out there is because nobody has written a VB or Java equivalent. Why not? Because it's REALLY, REALLY hard. I'll be ready to retire RPG and the iSeries the first time some hotshot prognosticator has written a finite forward scheduling engine in VB (or whatever the language flavor of the month is). Joe

[J.Pluta]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
While I agree that RPG is a great language, I don't think they need a GUI. User interfaces change so quickly that what we really need is the ability to isolate business logic from UI. I think tiered architectures do that, and I think our colleges should be teaching tiered architectures. But from that standpoint, the iSeries is an incredible machine for teaching programming! You can run Linux in one partition and OS/400 is another. You can use the OS/400 partition to learn business logic as well as running your JSP Model II browser interface. You can use the Linux partition to learn about open source software and write graphical X-Windows interfaces. Combine that with a network of PCs so you can write .NET thick-client programs (as well as WDSC) and you've got a complete development environment. Joe

[J.Pluta]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
RPG is falling out of favor with newer programmers because IBM has chosen to neglect it. You two have two basic choices to evoke programs: Green screen or called procedure. Or, you can actually use a modern tiered architecture where the business logic is written in RPG and communicates with whatever application and UI layers you want via messaging. As I've said before, this architecture provides response times nearly as fast as a green screen, but in a browser. And the interface looks great. RPG may be falling out of favor with some programmers because there are few code generators. You actually have to program - you have to think about your design ahead of time, create your application in a coherent manner, then write and test the individual pieces, all before seeing the application work. There is no instant gratification of running a wizard and seeing a web page. But once you get a framework in place, RPG can be every bit as productive as any other environment. Getting data into a user application such as Excel or Access, or hiring departmental specialists who are experts in both IT and engineering or QA or marketing is the future. Even further will be powerful applications that redefine the concept of the query, but are simple enough for the departmental tech to produce. And here is where we have a serious disconnect. Queries like this are fine, and they're the high-paid glamor children of the industry. They're sort of like the quarterback on a football team - everybody knows his name. But he wouldn't have a very long career if it wasn't for the offensive line that blocks for him. And that's where a lot of real programming gets done: down in the trenches. You talk about queries, but someone has to get that data INTO the system. Someone has to apply logic to validate it, logic to post it, logic to distribute it. And the great majority of that logic is STILL written in RPG. And my guess is that when companies try to rewrite that logic in some other language, for every one that is successful, one is not.

[J.Pluta]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
I gotta admit, CD, I have no idea what you're talking about. But I'll try to answer your points as best I can. First, JSP Model II talking messages to an ILE RPG back end is neither obsolete or fringe. And tiered architectures are hardly cutting edge, although they seem to catch lots of college-educated programmers by surprise (I don't understand this phenomenon). Let's take the smallest shop: the one-man iSeries shop. The best scenario for this guy's boss is to identify the business processes he wants to expose, and then let the IT guy write a message interface for them. The IT guy then rewrites the green screen interface for those that need it, while they contract a guy to write the JSP Model II interface (which is very simple). Then, the business decision is whether or not the IT guy wants to learn this technology or the boss needs to hire an HTML/JSP guy. Either way, the system is up and running far faster than any other scenario, with the exception of a screen scraper. Or should this employer spread the risk and hire a team of programmers and analysts, each to handld one major aspect of the design and development. Well, if you can afford three programmers, you're pretty much done. One guy handles the UI, the other guy handles the RPG. The guy in the middle is the "message admnistrator", who functions roughly as a DBA, only for the message flows. If I needed multiple non-green screen UIs (JSP and .NET, for instance), I'd probably want one for each interface. Doesn't seem like a lot to me. The future will belong to the software development companies that can put massive power in the hands of the occasional developer. I can think of nothing more frightening than massive power in the hands of an occasional developer. Joe

[J.Pluta]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
I read it perfectly. Let me be clear: Queries, no matter how complex, are only a small part of any application suite, and they are the easiest to automate and prettify. Hence the large number of packages that generate pretty queries. It doesn't take a lot of work to pick fields out of a field list and then display them in columns. And while queries get more complex than that, they have a limit because they shouldn't have a lot of business logic; if they do, that's a bad design philosophy because those business rules should be encapsulated and made available to others in the company. The part that gets shoved under the carpet is the incredibly difficult code that has to do with entering, validating, posting and distributing the data prior to all those pretty queries. Back in the day, we had 100 series programs, which were master file maintenance. These were always given to newbies. Then we had 200 and 300 series programs, which were reports and inquiries. You graduated from maintenance to reports and inquiries. (The only reason queries were higher than reports was that you usually had to write subfiles.) Only after you were seasoned in those areas did you get to write the 500 and 600 series programs, which were data entry and posting programs. These programs, while smaller in number than the 100, 200 and 300 series programs, usually had more logic in one program than in any ten of the others (literally: we're talking 30,000 lines compared to 3000). And while that sort of monolithic program is being replaced (hopefully by tiered architectures of the type I've been talking about for so long), the metrics aren't invalid. It takes a LOT more work to write an order entry program than it does to write an order inquiry, no matter how complex the query. And the tools that are best for one are not necessarily well suited for the other. Joe

[Guest.Visitor]

RPG and DB2: The Future Is Now

** This thread discusses the article: RPG and DB2: The Future Is Now **
cdr5000 said: "Imagine yourself just out of college and planning to show the world how things should REALLY work. Would you honestly choose AS/400 RPG for that?" I haven't seen any "just out of college" type on a S/38, AS/400, iSeries, i5 in over 20 years. Why would one expect it to start suddenly happening now? chuck Opinions expressed are not necessarily those of my employer.