How to Get Out from Under an Obsolete Legacy Technology

[Guest.Visitor]

How to Get Out from Under an Obsolete Legacy Technology

Hi Duncan, 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. A Java servlet or a JSP writes to an output stream to generate the response. How is that any different from RPG writing to standard output? And CGIDEV2 only re-reads a given HTML file off the IFS if the file date/time has changed. Otherwise, it's cached in memory in the service program for subsequent responses. How would you make that faster? Also, there is parsing code involved for substituting variable values in at placeholders in the static HTML that potentially slows things down. This is all done in memory. That won't be the bottleneck. The bottleneck will be any database I/O from DASD. My comparisons of performance were related to calling an RPG program from either a PHP script or a CGI program. Are you using the PHP i5_connect function to call RPG on the back-end? This gets to my point on authentication. What general purpose user id and password do you connect with? If that user id becomes disabled, does your i5_connect fail? With CGI, the jobs are already running, ready to handle requests, no connection needed. 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 I thought your PHP called RPG on the back-end? Like this... Browser --> HTTP Server --> PHP Engine --> PHP --> RPG I'm still wondering why we need the PHP middle man in that equation. The only answer I can come up with is if you need the PHP on a separate LPAR. (RPG could use DDM Data queues from a different LPAR I guess, but that's probably a stretch). 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. What is a robust security solution? Just use SSL? Thanks. Chris

[R.Daugherty]

How to Get Out from Under an Obsolete Legacy Technology

Chris, the PHP would be an Apache module running in i5/OS. If PHP were running in a Linux partition then of course it would just be the Linux Apache and PHP module, but this PHP was developed for i5/OS with call interfaces to ILE programs and data queues. It runs in PASE. That may change your thoughts somewhat since it's not running in another partition. Hope that helps. rd

[Guest.Visitor]

How to Get Out from Under an Obsolete Legacy Technology

Ralph, That may change your thoughts somewhat since it's (PHP) not running in another partition. Hope that helps. PHP running under Apache can get a connection to another LPAR using the i5_connect function, just like the "AS400" class in the Java toolbox can. So yes, PHP can be in another LPAR, separate from your production databases and RPG LPAR. The point I'm making is that if your Apache server and production environment are in the same LPAR, why add the PHP layer (or a J2EE layer)? Why not just have the HTTP server pass the request directly to RPG? Chris

[Guest.Visitor]

How to Get Out from Under an Obsolete Legacy Technology

Chris, The parsing of the HTML to substitute in data values is in fact a bottleneck in RPG. Consider a typical list program. Let's say you have 100 line displayed, with 10 fields per line. That's 1,000 parses of your HTML variable to find where to substitute the data value. RPG is not good at string manipulations (lookups, etc.), so that's potentially slow, unless you write some more complex code to mitigate this (which we've done). I'm not sure I follow your point on the PHP i5_connect function, but when you ask me about more robust security, I'm talking about LDAP, iSeries user profile security, or web server - where the passwords are not easily accessed by any programmer. Some PHP authentication mechanisms simply store the password in a text file unencrypted, although you can write your own routine and use something such as MD5 to hash the passwords. SSL only handles transport of data- not authentication (but is a crucial part of a complete security implementation, nevertheless).

[R.Daugherty]

How to Get Out from Under an Obsolete Legacy Technology

I wasn't saying PHP couldn't connect from another LPAR, I was saying (as you understood) that the PHP developed by Zend for the iseries runs in i5/OS. It is all native and no connections from other LPARs that was being touted in the article. Why? For the same reason Joe touts a JSP layer. An HTTP function rich layer to handle web page processing, where traditionally getting data for a web page was more a matter of a few SQL statements than any kind of computing that rises to the level of an RPG program. More like a screen loading subroutine. But the thinking has been substitute a web page for a 5250 screen, and otherwise carry on. So that calls for not just doing the work of a web page in the HTTP PHP or JSP handler, but calling portions of existing code to do the work to leverage it. I know of many functions that this is good for in serving a wide business customer base, supply chain type stuff, but that's an intermediate audience. It is neither the general public, which requires consumer designed pages and processing, nor internal application processing, which in my opinion require high speed data rich 5250 session screens. So those are three types of apps and there are yet more, for example, business intelligence type apps with a rich desktop interface for intensive data analysis. But when serving web pages, the HTTP helper function libraries of a PHP are the purpose, same as with JSP. What you end up with is an easier but slower HTTP processing with PHP, and much more powerful and faster HTTP processing with Java servlets and JSP, but the question would be, do I really need these helper functions, and if I did, why wouldn't they be better and faster in RPG and/or C++. So I agree with all your points, Chris, and in general this has always been driven by IBM trying to push us to their Websphere web server product. Other OS'es are not as web page limited, but then again, if you're IBM, and all you have is a hammer, then everything is a nail. rd

[R.Daugherty]

How to Get Out from Under an Obsolete Legacy Technology

Having said this, I just want to say how impressed I've been with the last two announcements from IBM as reported by the other site. The iseries senior product manager talking about a potential 80,000 VOIP solution sell under i5/OS talked up the iseries like I haven't seen in print before. You couldn't ask for better, clearer sales talk about the iseries and i5/OS. And today, the new extremely impressive starter editions of the iseries, good licensing conditions for Client Access, and disk prices cut in half, I have to say, someone in iseries land is listening and they have acted. I'll look forward to the analysis of this news coming soon I can imagine. rd

[T.Grove]

How to Get Out from Under an Obsolete Legacy Technology

Os, What you said was my exact point, also. Yeah, WEB IS COOL. Yeah, EVERYTHING SHOULD BE BROWSER BASED I've heard it all before. As for the iSeries, it doesn't matter that it will DO the job, but whether management is willing to modernize, or in the case of a package, purchase a modernized version. All the debate on this thread of PHP vs RPG-CGI vs Java is pointless in an environment where it will never happen. A majority of AS400 shops use packages. That means that a majority of shops will NOT go to Web based paradigm until forced to do so by their vendor. Even then, the almighty bottom line will dictate whether they migrate to the vendor's Web offering or not. As you stated, iSeries shops will continue to pull data from the As400 until it becomes nothing more than an overpriced file server, which they will then migrate off of because it is a "Legacy" box. IBM needs to get off its "Websphere will save us" mantra, and focus on marketing the machine AND packages. I haven't dug into the latest SMB pricing change that was just announced, but I'm hoping it makes the iSeries cost competetive with Windows/Linux servers. Bottom line: For you Pro's writing about how the Web will save the iSeries, and that we developers are holding it back by not learning Websphere and web enabling all programs at our sites: Developers are constrained by Management and Packages. WE cannot make this change without THEM. PS: We developers DO want to learn and modernize the applications, but contend with "If it ain't broke, don't fix it". Additionally, we cannot Web enable just our new development and force our users to jump back and forth betwen web and green screen for the same application, our managers will not allow that.

[J.Pluta]

How to Get Out from Under an Obsolete Legacy Technology

New is not always better. Especially when it's not new. Stateless programming harkens back to the NEP-MRT days of the System/3. It is inherently inferior from a pure performance standpoint, and I'll giev you the simplest example (you can extrapolate to any number of other cases). Let's take one of the most fundamental business activities: paging through an ad-hoc list. Back in the day we might create the list with OPNQRYF, nowadays we use SQL, but the idea is the same. The user gives us some arbitrary selection criteria, and we build a list and present the first page to them. For the initial request, stateless and stateful architectures are pretty much equivalent. There's a bit of a delay as the index is built and then the first page of data is displayed. Now the user request the next page of data. At this point, the stateful architecture simply reads the next page records from its ODP (be it an OPNQRYF or an SQL cursor). The response time is nearly instantaneous. However, the stateles architecture has to rebuild the data path, starting at the first record of the second page. Since you can't store an open data path using the session function of modern web application development environments, you have to actually build a new data path from scratch. There's no way aroud this dilemma. I could go on, but I hope that this is enough to explain why stateful sessions outperform stateless ones. This is not to say there is no use for stateless programming! Extremely high-volume anonymous web sites need stateless architectures. But to say that stateless sessions are technically superior is simply wrong. Joe

[J.Pluta]

How to Get Out from Under an Obsolete Legacy Technology

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? At some point you need to generate dynamic HTML. Depending on your design model, this may involve actually generating the entire INPUT tag for a field, for example, or putting a SPAN around a literal. For this, OO is absolutely fantastic. The superclass takes care of the basic INPUT tag, while the subclass pokes in values like the length, name and value of the field. It's actually quite cool! Scott Klement, Jef Sutherland, Jon Paris, Susan Ganter, Paul Touhy, Bob Cozzi, Giovanni Perotti, etc all preach it loudly. Let's see... you've forgotten Brad Stone and Nathan Andelin. And let's review this carefully. Bob doesn't recommend RPG-CGI, he recommends his tools. Giovanni recommends his tools, which are not compatible with Bob's. Brad recommends his tools, which are not compatible with anybody else's. Nathan recommends his infrastructure, which is unique. There's a bit of a pattern there. Jon and Susan (well, mostly Jon ) are not so much pro-CGI as anti-JSP. Jon pure and simply hates Java. I don't know Scott's personal opinion, butif I were as talented and knowledgeable as Scott at RPG and sockets communication, I'd probably look at JSPs as an unnecssary overhead, too . I haven't heard anything from Jef lately, nor have I ever heard Paul's comments on the subject, so I'll take your word that they are RPG-CGI advocates. That's a pretty impressive lot, I do admit. However, here's the rub: that list of people isn't really growing. Not that each of them doesn't have a perfectly sound reason for their position: you'll find good people disagreeing all the time. That's in fact the hallmark of a vibrant community, as opposed to groups that flock to the latest shiny new toy. But when the number of people advocating a given architectural approach becomes stagnant or begins to dwindle, you have to be very careful that the architecture is the best fit. Again, I'm not saying RPG-CGI isn't a good fit for you and for others. I'm just saying that, in my opinion, RPG-CGI has a smaller chance of being the best fit for most people. Joe

[J.Pluta]

How to Get Out from Under an Obsolete Legacy Technology

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. Actually, I was talking about WebSphere Application Server itself, which was free up until version 3.5. Then came version 4, which was suddenly a for-fee product. The unbundling of WDSC is just another aspect of the same bizarre policy of trying to charge iSeries client more money. EGL has been unbundled already, and we're waiting to see what else IBM decides to charge for. Joe

[Guest.Visitor]

How to Get Out from Under an Obsolete Legacy Technology

Hi, TAGrove, You make some really good points here, especially with regards to jumping back and forth from green screen to web. However, here's some other considerations: 1. Packages will eventually move to the web. 2. With IBM's current hardware pricing model, companies can save substantial hardware dollars by moving to web-based apps- no interactive tax. 3. Web based apps are important for many reasons, including making apps more widely available, more productive for users, and providing more valuable (ie understandable and actionable) information 4. IBM has very much abandoned the "Websphere will save us" mantra- at least in Rochester. There was an internal struggle between the System i group and the Websphere group in IBM (which is not platform specific), and due to the very low adoption rate of Websphere, Rochester has won that battle. Hence the alliance with Zend. 5. IBM's new hardware announcements should address the SMB marketplace and make the system more competitive. It's interesting to note that, for the first time I can remember, IBM is actually comparing the System i to Windows-based solutions - with prices side by side. 6. I agree totally that management needs to see the value of web apps so developers can move forward too. My article is in the iTechnology Manager segment of mcpressonline for this reason- the target audience is managers. Let's hope they are reading! Duncan

[Guest.Visitor]

How to Get Out from Under an Obsolete Legacy Technology

TG, I second your remarks, and would like to add that in a shop like ours where ALL of those technologies are in use, you tend to get pigeon-holed into technology areas. Your workload will increase greatly if you are any good at all & unless you forcibly break the (pigeon-hole) mold, you can easily get stuck w/high workload, low family time, & very low or non-existent personal development time. (Just witness my own struggle to get time to work on .NET & C#!) Our shop is nearly 100% custom & yet we have the same ROI issues. d (WI)

[nandelin]

How to Get Out from Under an Obsolete Legacy Technology

It's nice for Joe Pluta to mention my name among the honorables mentioned above. I can't wholeheartedly endorse the CGI interface. On the other hand I've stopped pointing out it's weaknesses because I finally concluded that the I5 CGI interface generally performs better, and in many cases scales better than comparable J2EE interfaces. So more power to those who may want to use CGI. The Web interface I designed is geared toward ILE developers, but it has its own message architecture, and uses data queues to establish communication between threads in the I5 HTTP server and ILE-based application servers, as an alternative to the I5 CGI interface. In the past I would elaborate on the advantages of this approach, but lately I've been developing Web applications for the K-12 education market rather than promoting my own Web interfaces and tools. I appreciate Duncan's well written article. I gather now that we'll be seeing PHP scripts generated in a future version of Websmart. I don't agree that the native runtime environment or ILE languages are obsolete. I'm just as committed to the I5 native runtime environment and languages as I've ever been. It also seems odd that Duncan would complain about RPG being proprietary. Websmart incorporates a fairly robust, albeit proprietary language too. I appreciated the reference to SugarCRM as an example of a commercial grade PHP application. I've begun writing a CRM application in RPG for my own use, and SugarCRM offers a good reference point. This is an after-hours endeavor, but maybe in few months I'll be able to demo and ILE based CRM solution. Nathan M. Andelin

[JonFParis]

How to Get Out from Under an Obsolete Legacy Technology

> Jon and Susan (well, mostly Jon ) are not so much pro-CGI as anti-JSP. Jon pure and simply hates Java.

Pardon? No I don't Joe and I have NEVER said that - EVER. I quite like Java for many tasks BUT I am honest about the fact that it has a number of "features" that annoy the hell out of me and tend to make me use it a lot less than I might otherwise do. I am also honest in admitting that I find it does not map well to my thought process. Better than Smalltalk but ... I feel that many RPGers are in the same boat as me. We find it hard to get our heads around OO and Java after years of procedural programming. I think I've said to you before that I _really_ do wish that someone such as yourself would write a "Procedural Java" text book - I'd buy the damn thing for sure. The quote that I use in my presentations on PHP is an accurate statement of how I feel about the two languages. "I felt more at home after three weeks with PHP than I do after 3+ years of Java". Jon P.

[JonFParis]

How to Get Out from Under an Obsolete Legacy Technology

"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." Au contraire. First of all it _is_ optimized and does _not_ call the API until such time as you write the special section *FINI. Up until that point all section writes are buffered. Secondly, you can write multiple sections in a single call to the WrtSection API. There are various other optimizations - but this is the part that directly addresses your comment. Jon P.