You know you're old when you prefer the green, boring 5250 screen, to a sharp up-to-date Web interface. You may...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
even fall into that category of loving the green screen and knowing it still is the fastest way to get around a system. Many times, "back in the day," I could be several screens ahead in my typing than I was on the actual screen in front of me (I had the commands and keystrokes buffered waiting for the system to catch up). Those days are long gone, before the internet, before email, before Lotus Domino and WebSphere. Back when all we had was a green screen, a dot matrix printer, Office Vision, and DOS. Ah sometimes I long for the good-old-day of DP (well not really, but I do miss it sometimes).
Screen scrapers vs real System i modernization
There was a time when I knew plenty about green to graphic user interface (GUI) conversion, and over time I haven't thought much about it. If you attend COMMON you will still see plenty of companies offering many types of green screen application converters. Most of them do what you want as far as taking a green screen, looking at something at the DDS level or the screen level and then transforming it to a nice graphical GUI. Most would call this "screen scraping" and then again most of the companies that do this would argue that it's not. Screen scraping plays with what the screen offers, and doesn't change anything at the database or file level.
The problem was, and still is, that you have to have an interactive workload and the application is on the system that you want to "modernize." So you write your application in RPG or C, make screens for that application, and then feed it to an application modernization toolkit and convert it and make it pretty for final deployment. All of this, so that the person in your company can have a nice windowed application with your company logo in it! This all seems like a bit of a waste to me, but plenty of companies are looking at tools from Seagull Software, LANSA and others to do this. The down side is two-fold, the delivery time is longer and most tools require you have a 5250 session on the user's PC (hidden from view). Nothing really changes: You just put lipstick on a pig. I think this problem needs to be looked at differently.
Thinking outside of the (Power running i) box
So, we take a step back and look around the entire IT space and start to think outside the box that is now labeled POWER running my i. What would UNIX or Linux people do with the problem? Where would they turn? How are they going to solve this problem? Are they going to have a green-to-GUI company come in and take all the screens and put it out on the Web? Nope.
For years the Linux and UNIX users have had the same problem we over in the i area have had. Nasty ugly green screens that no user will ever admire the way we do. The answer, of course, is in the very tool you are using to view this article. A browser. So, solve the problem with Web applications.
You might be wondering why IBM didn't go the same route on the i as they did AIX. Well, they did, they offered the users an HTTP server with a DB2 backend but most companies who were very i centric failed to see this as a workable option. The other problem is that companies like LANSA and Seagull were selling something that looked easy. Anyone with an RPG based application could port it or convert it to look all fancy. We only later found out that their technology is a "one off" solution and can't be ported, moved or tinkered with without the expense of dealing with the company you purchased it from. While I do think that all the companies in the i space offer really well-built solutions, it depends on what you are looking for.
Run native Web applications on i
IBM is now on board with doing things on the i for the Web, even if that Web is internal to your company. The i can now run PHP, Apache and MySQL on it natively -- and it's supported! Your biggest hurdle is getting the data and applications that you have invested years and millions in to the new Web tool.
This very complex problem is very easy to solve. Keep your data where it belongs, on the i in the most well built DB2 database on earth (IMHO). Then write a Web front-end with PHP. Delivery is smart and fast and doesn't depend on the 5250 session. Hit the i at the database/ODBC level.
While I am not going to tell you to stay away from other products, I am going to recommend that you to find the best product for the future. Think of how to tackle this problem with smarts -- not just look for a quick fix solution. There are many more skilled PHP developers who are not afraid of any OS than there are specialized kit developers. Take a look around and make sure you really find a tool that is going to work five or ten years down the road and I think you will find PHP and ZEND are going to be there for the long haul.
ABOUT THE AUTHOR: David Vasta is the Lotus Notes Administration Team Lead over North America at Atlas Copco. He has 17 years of data center and System i experience working in companies such as IBM, REAL and Cingular. He blogs regularly at System I blogger