Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

How to Get Out from Under an Obsolete Legacy Technology

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to Get Out from Under an Obsolete Legacy Technology

    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.

  • #2
    How to Get Out from Under an Obsolete Legacy Technology

    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.

    Comment


    • #3
      How to Get Out from Under an Obsolete Legacy Technology

      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

      Comment


      • #4
        How to Get Out from Under an Obsolete Legacy Technology

        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.

        Comment


        • #5
          How to Get Out from Under an Obsolete Legacy Technology

          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

          Comment


          • #6
            How to Get Out from Under an Obsolete Legacy Technology

            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

            Comment


            • #7
              How to Get Out from Under an Obsolete Legacy Technology

              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

              Comment


              • #8
                How to Get Out from Under an Obsolete Legacy Technology

                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

                Comment


                • #9
                  How to Get Out from Under an Obsolete Legacy Technology

                  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

                  Comment


                  • #10
                    How to Get Out from Under an Obsolete Legacy Technology

                    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.

                    Comment


                    • #11
                      How to Get Out from Under an Obsolete Legacy Technology

                      Hi Duncan, CGI programming on the iSeries has great advantages if you have a good development tool to write it in. CGIDEV2 is a CGI-based set of functions that is available for free, but the old adage "you get what you pay for" definitely applies here. These have limited functionality, have poor optimization for performance, and require manual coding in RPG. What functionality is missing? It's pretty simple really. The RPG CGI controller gets the form values and feeds those to the business model through a CALLP or dedicated data queues for that session. Then it generates the HTML response using templates (designed by the Web UI guru). You said poor optimization for performance and then later say PHP is just as fast as RPG CGI. How is PHP performance optimized? RPG is compiled and can stay resident in memory with INLR=*OFF in a named activation group. Then it's as fast as a subroutine call. I can't see how PHP will ever be faster since PHP is interpreted. This: Browser --> HTTP Server --> PHP Engine --> PHP --> RPG Model Versuses this: Browser --> HTTP Server --> RPG Controller - RPG Model Do I have the PHP architecture correct? And with CGI, the initial calls to the RPG Model programs can be done at IPL time (to open files), so no delay for the first user. My other concern with using PHP and Java is that the connection (on a separate LPAR anyway) is done with a specific user id and password. What happens if someone types that user id incorrectly on a sign on screen? Does your web app go down when that connection profile is disabled? How would a user determine that ID? Maybe it was the sender in an SNDDST email done on the backend. Or they guessed it to be WEBCGI1 etc. Do you make that connection user id something hard to guess then like P9DFFD33UQ ? It just seems to me that the user id needs to be as guarded as the password. With CGI, once the initial jobs are running an IPL time, only IT can bring it down, not a user. Thanks for the good article. Chris

                      Comment


                      • #12
                        How to Get Out from Under an Obsolete Legacy Technology

                        You said poor optimization for performance and then later say PHP is just as fast as RPG CGI. I could not find where he said that, Chris. It would be extraordinary to say such a thing. Here is a link to language benchmarks. http://shootout.alioth.debian.org/gp4/ I chose a test having more to do with our typical programming, that being indexed integer based access timings. Given RPG-CGI will have speeds similar to C, here are some language benchmarks for the indexed access test. Other test results were similar: compiled languages C 6 C++ 10 Compiled Basic 13 Java 15 C# Mono 19 Fortran 22.4 start of script languages Python 658 Perl 892 PHP 1147 object oriented script Ruby 1791 Javascript timed out end quote Now, Zend does offer a PHP compiler caching addon to their Apache PHP interpreter module, which is what we would require to do actual work in a business environment. That's why they give the interpreter away for free and sell the compile cacher, along with other enterprise level capabilities for PHP (well, actually it's open source so they gave the port away for free, and a port to i5/OS PASE is really just about IBM telling them how to compile their AIX version for i5/OS, plus adding calls for dataqs and ILE programs, still kudos to Zend for their work). Here's a quote from IT Jungle: http://www.itjungle.com/fhs/fhs080106-story01.html Zend's PHP Offering Expands Options for iSeries Developers by Alex Woodie August 1, 2006 (quote) Later this year, Zend will roll out additional offerings targeted at iSeries ISVs, systems integrators, and resellers. These products will include Zend Platform for i5/OS, a for-fee product that provides a high-performance deployment engine that includes things like clustering, code acceleration, monitoring, and management tools. Zend Guard for i5/OS, meanwhile, will assist those who want to distribute iSeries PHP programs, but who want to protect their intellectual property. The ship date for these products has not yet been nailed down. end quote So speeds could probably be raised in the Java to C# Mono range with Zend's caching product, assuming not a great deal of different activity such as serious business software which would require large amounts of code to be stored in memory. Of course this is computer science 101, something which apparently goes out the window as people get giddy headed saying things like "PHP... cool". Yes, users just love slow cool screens when they're trying to do something more intensive than blogging on their MySpace page. rd

                        Comment


                        • #13
                          How to Get Out from Under an Obsolete Legacy Technology

                          Now having got the numbers out of the way, here are my thoughts on PHP. It would be very convenient for me if I could do my personal programming in PHP. My web site (a forums board) runs on it, and it wouldn't cost me any more to add as many web pages and php programs as I could write. Everything else requires a dedicated server (except shared ASP and a tiny number of shared JSP hosts), so I looked long and hard if I could do stuff beyond content management, in other words, beyond handling simple store and retrieve transactions with little to no complex logic. But the sad fact is that it's analogous to my first computer, a TRS-80. Interpreter Basic was there, it was easy, and it was slow. That's like PHP on all these millions of web sites. It's easy because it's there, and it's slow because it's easy, just interpret source text like a Basic interpreter. Web page sent out, forget everything and start on next web page. Look at the PHP source for these simple ubiquitous content management PHP software modules and you won't see much. Not a whole lot of computation. The gimmick is that if there's any computation to do, they say you can write it in C and call it. That's how they excuse the slow performance. Also, while you're taking a look at the snippets of PHP that pass for programs, you will not see anything simple about them. The scam offered up by PHP proponents is that PHP is easy because you don't have to declare variables. In other words, sort of super move programming, where you don't have to even have a spec line for the variables involved, much less care whether it's zoned or character. But we Z-ADD to packed, and in PHP you wouldn't even make that distinction, just like we now eval. Oops, there I go again, making RPG easy. But take a look at PHP code and if you really think it looks simpler than RPG, then take a shot at it. It's just amazing how far these "oh you don't have to say a variable is numeric" people will stretch that into "PHP is easy". I mean, if you find saying A is numeric is hard does it really matter? So believe me, I'm not too happy about having to go from cheap and easy PHP to my own dedicated hosted PC server to do anything significant, and I'm sure most other people aren't either. That's why there's 35 million or whatever PHP sites. It's not hard to figure out. Neither was the equivalent, interpreter Basic, back in the day. rd

                          Comment


                          • #14
                            How to Get Out from Under an Obsolete Legacy Technology

                            Hi, Chris, CGIDEV2 is not optimized for best performance because it requires you to call the APIs to 'standard out' and to CGI output repeatedly, unless you write lots of code to cache your calls. Also, it uses IFS files to read the HTML. Also, there is parsing code involved for substituting variable values in at placeholders in the static HTML that potentially slows things down. There are better ways of optimizing this code, too. So when I talk about RPG CGI, I'm talking about fully optimized RPG code. My comparisons of performance were related to calling an RPG program from either a PHP script or a CGI program. I was concerned that switching back and forth from the PASE environment to the native environment would result in performance issues, but it doesn't seem to. At this point I'm not sure of the full impact of the fact that PHP is interpreted. As Ralph has pointed out, Zend does have a just-in-time compiler option on other platforms, where code is essentially compiled and cached as pages are called. Your models are sort of the way I envision things, although you can just as easily have this: Browser --> HTTP Server --> PHP Engine --> PHP and Browser --> HTTP Server --> RPG program In other words, either your PHP script or your RPG CGI program can encapsulate all the required server side execution logic. For new applications, this is much more likely to be the case. I'm not sure about your comments regarding authentication. In our product we provide several methods of logging on to a web app, including using the iSeries user profile and password in a custom web page, in addition to security via Apache config statements. I don't see why a PHP program could not also call these APIs, even if the APIs have to be wrapped in an RPG container. This would provide you the same capability. PHP also has its own native authentication functionality that allows you to reference a hidden password file and allow login via HTML pages, although that's not the most robust security solution.

                            Comment


                            • #15
                              How to Get Out from Under an Obsolete Legacy Technology

                              Who deemed the traditional programming environment on the iSeries as obsolete legacy technology? In the case where I am employed, only a fool would advocate trying to move off the current paradigm. Why? 'Costs too much. So long as we're able to pump boatloads of transactions through our systems and produce the output needed for the decision makers, I don't ever see the company spending a dime on upgrading our apps for the sole purpose of "modernization". I do see a slow evolution off of the platform altogether though. More of our web apps are querying the iSeries to obtain data only, and my guess is, once that number reaches critical mass, then an effort will be made to move all the data off the iSeries. Then we'll unplug the box and move on. The cost to throw it all away will be the cheapest route. Still, the article is pretty much right on. It's a moot point however---there is nothing that can save the iSeries long term. The constant drum-beating of the buzzwords, Obsolete Legacy Technology, has already killed the platform.

                              Comment

                              Working...
                              X