How to Get Out from Under an Obsolete Legacy Technology

[J.Pluta]

Although I'm still not 100% certain whether you consider RPG a good language or a bad one, I'm happy to see you agree that separation of UI and business logic makes sense (at least I think you're saying that). I disagree on your assessment of Java, of course. I consider Java to be an outstanding web enabling language, since it embodies basically all the things RPG lacks in that regard: it's OO capablities make it eminently suitable to handle the strict syntax of HTML, while it's platform independence allows you to mvoe your UI from one System i to another or even to another platform as your infrastructure requirements might dictate. But whether you like or hate JSP, we agree that platform independence for your UI is impossible using the RPG-CGI approach. Of course, very few people are actually promoting RPG-CGI anymore. And while we agree that RPG isn't well suited for modern web interfaces, you seem to still be willing to consider RPG for back end business logic. That's good, because frankly short of COBOL and RPG, there aren't any good back end business languages. You point out the data capabilities of RPG; fixed decimal precision is an absolute requirement for businesses and it's just bizarre that most so-called "modern" languages don't support it natively. Add in the requirement for simple indexed access and the COBOL/RPG procedural design is still the best in the business. To this day I challenge anyone to sit down and write an MRP explosion in any other language. I am a little hesitant to jump on the PHP bandwagon; I worry about any language that has a normal version and a "hardened" version . Seriously, though, I have two real issues with PHP. The first is that while there are a ton of "web applications" written for PHP--lightweight applications such as content management systems and customer relationship management systems--there are very few industrial-strength business applications written in PHP. That's no surprise; it's simply too much to ask for interpreted scripting languages to perform as well as compiled procedural languages like COBOL and RPG. But as long as you leave the business back end stuff to legacy languages, I think you can use PHP for the front end (at least until some other shiny new toy comes along--me, I'll stick with JSP). More worrisome to me, though, is the business model. How does Zend plan to make money? While Zend Core is currently free on the System i, IBM's recent policy of "unbundling" seems tailor made for Zend. Get lots of people using PHP, and then in VxRy, "deprecate" the free version. Us WebSphere folks have seen that particular game more that once. I don't know if that will happen, but I don't see anybody at IBM swearing that it won't... So while your article seems to be imply that RPG is obsolete, from what I can see just about every option you outline, short of rewriting everything in Java, seems to require RPG as a back end. And that's good, because that's the architecture many of us think is the best. Joe Pluta P.S. WDSC works great on any machine with a 2GHz processor and 1GB of RAM, as long as you have a decent disk drive. Most laptops these days have 5400RPM drives which are capable of running WDSC but are not recommended. If you're going to use a laptop as your primary development device, you need to invest in 7200RPM drives, which is the absolute minimum for any desktop machine.

[T.Grove]

Duncan, You laid out the various scenarios very well. I really appreciated the article. My issue, and I suspect many others' as well, is that our hands are tied. We, the iSeries/As400 community, have often used packages instead of home-grown applications. We then modify the packages to fit our business models and functional differences. This gives us a competitive advantage. Our hands are tied by the fact that we cannot re-write the vendor's application into a web interface for them. If they have a web interface product, we are then stymied by management not moving from the green screen applictaion to the Web one. Further, our hands are tied by not being trained on this new technology. Management will not send us to be trained on new technology that is not in use, nor will they risk new technology when their development staff cannot support it. Classic Catch-22. So, That begs the question on how we can break this cycle, and finally move to the future. IBM making the iSeries capable of having a GUI/Web interface as part of the operating system, and having built in web support for its development languages would be huge. Just my catch-22 cents worth.

[J.Pluta]

IBM already has a web development language. They call it EGL. EGL is really the focus on the future web development for all platforms. It's not bad, either -- it uses JSF (JavaServer Faces) and it's quite powerul. The problem is that IBM is trying to charge System i developers for the tool, which leads directly back to the Catch-22 we all see. Joe

[belgorodskym]

From my experience it was the object concept that was hard to comprehend. A community college course was the solution. After that the transition was quite easy and enjoyable too.

[Guest.Visitor]

Joe, I did indicate that RPG is not a good language for new web development. However, since most iSeries shops have a ton of legacy code written in RPG, it still makes sense for them to leverage it for backend business processes rather than try to rewrite in Java. So I'm not saying RPG is a great modern language- just that, for practical reasons, it makes sense to use keep the good stuff (business logic) and replace the green-screen with something better. I disagree with your observations about PHP. There are many industrial-strength applications, such as SugarCRM, that are written in PHP. The fact that Yahoo! uses it continues to be a strong case for its scaleability. I'll avoid the Java discussion- we've been down that road before. Duncan

[Guest.Visitor]

I agree with you, but I don't think IBM is going to make it happen, partly because it's not really technically possible. For example, the idea of adding native web support to RPG - that's only one piece of the problem. The major issue is in the differences between how true web apps are coded versus green-screen- stateless versus stateful programming. I'll be talking about that in an upcoming article. I think PHP may be the answer, here, because I think you are more likely to be able to get management to train you on it. This will probably not address your point about vendor's software, though. Many vendors have taken very different approaches to getting their stuff to the web, including web-facing, although I suspect that's being replaced with 'true' web programming now. So you might have to learn a different technology for each vendor- that is indeed a problem. Duncan

[J.Pluta]

Well, since SugarCRM is basically just a contact relationship management system, I don't consider it an industrial-strength business application. It's a desktop application, much like any other PIM tool. Don't get me wrong; I like SugarCRM, I happen to use it myself. But there's nothing in SugarCRM that even approaches the complexity of a enterprise-level price lookup, much less a business application like order entry or shop floor control. Are you suggesting that new business application development be done in a scripting language such as PHP? Because your reservations about Java pale in comparison to my reservations about using scripting languages for anything requiring heavyweight data driven business logic. The fact that Yahoo uses PHP really doesn't carry a lot of weight, since Yahoo is priamrily a web service provider: mail, search, that sort of thing. PHP is great for that, but I wouldn't write an MRP generation in PHP. In fact, to my knowledge, nobody has ever done such a thing. Joe

[J.Pluta]

Well, I guess that depends on your ideas about business applications. Some people insist that stateless architectures must be used for everything, but that's simply not the case. You can see my Wednesday article for that discussion, but the idea of getting rid of stateful architectures is a huge step backward to the days of NEP-MRT programming. Sure, it's a reasonable idea in the world of anonymous websites like Google, but once you're talking about authenticated sessions, it's a complete waste of resources to go stateless. Once you get past the premise that all architectures must be stateless, it's quite easy to develop applications that use a persistent application controller that in turn calls server-encapsulated business logic. And of course, even if you do need to have a stateless architecture, there's nothing stopping you from encapsulating all your business logic in called servers. Even though stateless architecture adds a lot of unnecessary overhead, it's not impossible. But we were doing that at SSA in the early 90s; heck, we did in the 80s at Navistar (nee International Harvester) on the System/38! Joe

[Guest.Visitor]

Hi Joe, How's the weather in the windy city? I consider Java to be an outstanding web enabling language, since it embodies basically all the things RPG lacks in that regard: it's OO capablities make it eminently suitable to handle the strict syntax of HTML, while it's platform independence allows you to move your UI from one System i to another or even to another platform as your infrastructure requirements might dictate. OO makes HTML syntax eaiser? To do what? Code it? That's done with an IDE like WDSC. What does OO have to do with HTML? But whether you like or hate JSP, we agree that platform independence for your UI is impossible using the RPG-CGI approach. True. But what is your company is committed to the System i5 and RPG long term? What's wrong with using RPG CGI on the same LPAR as your production business model? Of course, very few people are actually promoting RPG-CGI anymore. Scott Klement, Jef Sutherland, Jon Paris, Susan Ganter, Paul Touhy, Bob Cozzi, Giovanni Perotti, etc all preach it loudly. To this day I challenge anyone to sit down and write an MRP explosion in any other language (RPG). Excellent. I have two real issues with PHP... I have a few too, but I'm a PHP green horn. I've read about PHP and don't see support for name spaces (packages). What if I want to call my function print()? Or if I call my function RingerPrint() and then the PHP 6 has this nice new function with the same name? And, PHP seems to commingle the busniess model in with the HTML. This doesn't allow for the separation of this programming tasks to separate individuals (web UI person and business programmer). What about UNICODE support? Is it thread-safe? I don't know, just asking. While Zend Core is currently free on the System i, IBM's recent policy of "unbundling" seems tailor made for Zend. Get lots of people using PHP, and then in VxRy, "deprecate" the free version. Us WebSphere folks have seen that particular game more that once. Which parts of Websphere became chargeable? How much $? (IE: CODE Screen designer in version 7 of WDSC). That's a good argument but I can't reference it if I don't know the specifics. Thanks. Chris

[Guest.Visitor]

Joe, Perhaps I didn't make myself clear. I agree that robust, secure commercial web applications must maintain state somehow. One of the options is your suggestion of a persistent application controller, something like sending and receiving data queue entries- which involves a potential server bottleneck, proprietary code, and another point of failure. Another is to use session functions available in most modern web application development environments, which is what we do in WebSmart. The latter solution, which is technically superior IMHO requires stateless programming in any environment - ASP, ColdFusion, PHP, ILE-CGI, Java servlets - compared to the stateful program design of green-screen apps.