What’s Happening In IBM i App Dev?

January 14, 2013 Dan Burger

Green screens scare the daylights (actually not my first choice of words) out of me. Like great white sharks and vampire bats, they have their place in the world. But I don’t want to go to that place. Most people would probably agree with me about the sharks and the bats. There are many RPG and COBOL programmers, however, who are perfectly comfortable in a green-screen world. What in the name of modern application development are they thinking?

There is a reason people use the term computer science rather than computer history. IT is an ongoing endeavor. You have probably heard that time stands still for no one. It’s not even debatable. Ask Bob Cozzi, the Jack Sparrow of the RPG seas. He will tell you green screens are the number one cause of lost market share for the later day IBM midrange computing platform.

I’m good with that.

But it begs this question: Why isn’t more being done to leave the green screen behind?

The number of green-screen applications that still exist is amazing. You can readily find them in all types of businesses. And if you are looking for them, you can find plenty of end users who aren’t happy to be staring at one of those monolithic code-opatumuses. Not that all green screens are nightmarishly large, but they do exist and they really do scare the daylights (or something similar) out of me.

All the IBM i technical conferences are loaded with application modernization sessions, and those presentations are among the most popular. Last week, COMMON hosted its first virtual conference. One of the sessions was called What’s happening in the world of Application Development on IBM i. Tim Rowe, the IBM i business architect for application development, was the speaker. Rowe and I talked on the phone last week.

“The short answer to what’s happening in the world of application development on IBM i is modernization,” Rowe volunteered. “I try to help companies understand what is available and that when it comes to modernization, it doesn’t need to happen overnight.”

It is not uncommon for the IBM i customers that Rowe works with to be surprised when they discover features on their machines that have been unknown and unused. The tooling is one example.

“There are people who have never done anything with modern tooling,” Rowe says. “And there are some who tried it years ago, didn’t have a satisfactory experience, and are surprised to see what the tools have become.”

Although Rowe is most familiar with the development tools and compilers from Rational, the development tools from IBM i vendors such as ASNA, BCD, LANSA, looksoftware, Profound Logic, Zend Technologies, and others are being successfully used as well.

Even when developers are not substantially changing any code, Rowe says that just switching from green-screen development tools to modern tooling gets them moving in the right direction. (You have to use a graphical interface to appreciate one, presumably.) That is a first step in changing the equation by upgrading skills using modern development tools that that will eventually be used to develop new code and maintain existing code.

“Modern tooling leads to modern coding techniques and allows developers to reach beyond RPG- or COBOL-centric programming,” Rowe says. “You can’t move to a modern user interface using the old tooling. So tooling is a first step. But it’s not just about the tooling. That’s one aspect. It also includes end user experiences. It’s about how you display your content to your customers. Does the green screen still make the best display for the end users or do you need to think about moving to Web or mobile.”

Rowe is a proponent of giving companies options. He appreciates that IBM i shops can accomplish application modernization by taking many paths, which include IBM’s preferred methods as well as those of the third-party vendors.

“I am IBM i-centric and Rational is a portion of that,” he says, “but I am focused on what’s going on from the perspective of the operating system. The goal is the successful development and running of applications. One thing we don’t do is tell the customer what to do. Every customer has a different situation, but much of decision making comes down to skills, abilities, resources, money, and time. All those factors can have an influence on the direction companies take.”

Some people might argue that RPG is a dying language, but Rowe isn’t one of them. He will swear that RPG is here to stay, refers to it as a modern business language, and points to interoperability with other languages like XML and SQL. His enthusiasm, however, does not include the belief that all things should be done in RPG.

“There’s no single language for everything. Even the Java programmers are understanding that you don’t use Java for everything,” Rowe says. “I tell IBM i shops to keep portions of the applications in the languages where it makes the most sense. PHP may be right to do certain things with the UI, maybe Java, maybe something else. You are not going to do Web UI development in RPG and you are not going to do record-level access from PHP.”

PHP in the IBM i ecosystem has been successful from Rowe’s point of view. It continues to gain momentum, especially with companies that have lately made their move into application modernization. There are also PHP options being offered by some of the third-party application development companies, which indicates those ISVs see PHP momentum happening.

“I think the advent of PHP has had a far greater impact in many ways than anything else, even Java, has done,” RPG and IBM i advocate, author, instructor, and innovator Jon Paris told IT Jungle in July 2012. “There is an incredible amount of good, free information out there–not to mention the books, online classes, and so on. That is a rather different story than for the free RPG offerings in the same arena. It is also possible to hire young experienced programmers and to get help mentoring existing staff to bring them up to speed.”

“It works well for a ton of stuff,” Rowe says of PHP, “but it is not going to fit the bill for everybody. There are companies that have other skill sets.”

There are hundreds of thousands of IBM i customers and over the years they demonstrated a “go your own way” attitude that’s resulted in a lot of right answers. There have been successes and failures for a lot of different reasons. I have heard from many sources that many developers in the i community are stuck in their old-fashioned ways and that is one of the reasons the application modernization process is more difficult in some instance compared to others. Of course, IBM is not blameless in this discussion. It could have offered a modern user interface for RPG years ago and pushed developers in that direction, but it did not. But the point is not to talk about what could have or should have been. The point is to make decisions on where to go from here.

As Rowe says, “You can stand and argue until you are blue in the face about which path is better, and I wouldn’t disagree with any of the arguments. But customers are bumping into the reality that they can’t continue to live on their 5250 and the modern UI is being called for. They are being forced to change.”