Angus: “Shinning (sic) a light” against the future of RPG?

Rational Open Access for RPG (RPGOA) has certainly become the buzz of our industry. I have discovered that when there is this amount of excitement and noise on any subject, positive or negative, the topic is always a game-changer. RPGOA is definitely that.

This morning, I discovered in my inbox, an article from IT Jungle titled RPG Open Access Is No Panacea, Say BCD and LANSA. I truly appreciate IT Jungle’s efforts at reporting all the opinions relating to RPG OA, and enjoyed reading the article. However, it seems this is going to be wonderful press for RPGOA, and not so wonderful press for BCD and LANSA.

From an IBM perspective, RPG has now an ability to converse with any user interface you choose, extending RPG far beyond the traditional 5250 green screen interface. This is an investment by IBM in the future of RPG. From the vendors writing handlers, this is “..great news for the large proportion of the IBM i Community who want to continue using RPG for the long term” and “..perhaps one of the most important IBM i-related announcements in the last decade”. Other vendors are lining up to provide handlers utilizing RPG OA, and I expect soon enough, we will see open source handlers available.

Some comments from the RPG400-L forum are: “It looks exciting – I hope I get the opportunity to use this new technology”, “I hope to get to use something like this”, “It all looks quite impressive.” Some of the concerned citizens of our community expect that with IBM charging for the RPG OA runtime, adoption will not happen – although that seems not to have dampened any enthusiasm for the product.

From a BCD and LANSA perspective, “both declined to develop products using this technology”. From the article, I read: “they both believe their technologies and methodologies are superior to the ROA path.”. That certainly sounds like they would prefer you to use their technologies and not use RPG for IBM i application development. Does this mean that they are against the future of RPG – in this case, RPG OA?

I enjoyed reading the justifications for not using RPG OA that was quoted in the article. Let’s review…

“You have to rewrite all your code to make it stateless.” This is true, but it is definitely possible to write handlers that provide stateful conversations.

“ROA cannot be applied to existing programs without having to modify them” Again, true. But this is not a change in the business logic, just a simple change of where the display I/O is pointed. Not difficult.

“depend on both a new interface from IBM and a third-party ‘handler.'”Er, yes, this is a fact. Why is it a problem? So far, IBM and third-parties working together have produced some great ideas, and the creativity of both organizations has improved many of IBM’s tools, languages and products. I would not be surprised if BCD and LANSA have worked ~with~ IBM in the past on their own tools.

“This code-invasive approach means that you have to either write a program completely from scratch, or inject pieces of new code into existing code to make it work.”Yes! And as coders DO write new programs, they will take advantage of RPG OA for a user interface of their choice – this IS the point of the exercise. Existing programs, once again, will require change. Talking about this as a showstopper is just a marketing tool. Real world RPG programmers can handle this amount of change. “Code-invasive” is a marketing term with many implications, and while it applies here, it sounds far scarier than the reality of RPG OA.“So the notion that you can plug a single command and have everything work differently is ridiculous.” No one has notioned that in any of the press I have read. This is another marketing tool.

BCD said: “We had the full take on this, on what it did, how it did it, and what the objectives were. We are both progressive companies. If we saw an opportunity here, we’d be all over it.” But, hang on, also I read this from LANSA:“If you need large sets of data, you do it from the database. You don’t write a program.” Whoa nelly! If you need large sets of data, you can embed SQL inside RPG. And with RPG OA, you are not limited to displaying only those records that will fit on a 24×80 screen. It would appear this opportunity has been missed by a mile.

Certainly, this is a competitive industry. BCD and LANSA compete directly with the vendors who support RPG OA – looksoftware and Profound Logic. It seems like this press conference was a justification of why BCD and LANSA don’t want you to code in RPG, rather than offering any valid reasons for not adopting RPG OA.

The article sets them apart from the industry, with this phrase: “with a flood of information on ROA coming from IBM and the vendors making use of it, this is a good time to hear what the other side has to say”. BCD and LANSA have now been clearly identified as “the other side”. Their products are staples in many IBM i shops, and produce modern applications for their customers. I have often supported them when choosing the “right tool for the right job”, and will continue to do so when appropriate. Yet, they have shown their colors, and it seems like they are against the future of RPG. Could this be true? I think they are going to be doing a lot more justifying.

16 Comments

You say :”….This is true, but it is definitely possible to write handlers that provide stateful conversations.” Are you quite sure of that? To make the web stateful you need a real operating system to manage sessions and multiusers and *LIBL for example. I would love that Handler technology is able to manage statefullness but I am not quite sure. This a real challenge Angus.

I believe that the solutions from looksoftware and Profound Logic have both handled the statefulness or otherwise.

Even so, since the handler can be ANY program, the state can be managed however you like. The technical solution for state maintenance is going to depend on the UI you choose, but it certainly is achievable.

Besides, who says you are replacing all your existing programs? If you write new programs, given a new architecture, you can choose stateful or not.

My point is, stateful or stateless is a moot point, and not a hurdle.

Trevor

Jon ParisApril 26th, 2010 at 2:12 pm

If you consider a 5250 program – it is already stateful. It waits for user input and the file cursors etc. are all where you left them as are the contents of the variables.

So – take such an application and direct its output to a handler instead of the underlying 5250 APIs – the program hasn’t changed – the state will still be maintained.

The hard part – and this is the challenge Look and Profound have met – is to kick off the program from the web in the first place. I don’t know the technical details behind either solution but there are at least two approaches. One is to have a “traffic cop” web program that spawns a batch job for each user and runs the OA enabled programs there. The other would be to have a 5250 emulator that interfaces to the web and does dynamic screen scraping for things like menus and native menus etc. and then uses the handler supplied data for enabled programs.

Neither is rocket science – but not something the average shop can do either. And that’s where the ISVs come in.

I think that the one with “traffic cop” is Profound. I don’t know if they have tested this operating system with a lot of users behind all day long. The second is probably Look with 5250 emulator and/or handler… Regarding stateless programs we already have CGIDEV2 for free. Well… Maybe Profound has a real native RPG solution. I hope so. But I think that to make operating system like “web program that spawns a batch job for each user” is more IBM’s skills.

You made me realize another benefit of RPGOA that I didn’t see before. You can implement RPGOA with minimal code changes vs. going the similarly named sub procedure route (i.e. EXFMT vs. NEWUI_exfmt() ). This means that there will be *some* work to convert to RPGOA, but it is seemingly much less than if a separate tool had to be adopted. And when you are talking about thousands of programs, the least amount of changes needing to be made the better.

BCD produces RPG with their WebSmart ILE product. They also have a focus on producing PHP with WebSmart PHP.

LANSA have generated RPG with their tool for a long time, although that may be changing from what I have been reading. Visual LANSA compiles C. Not sure about LANSA for the Web.

The problem BCD and LANSA have, it seems, is that if you write ~more~ RPG, then there is less need for their products. I am still not sure why they did not use RPG OA, it seems more of a marketing blunder while they posture about not being involved.

Treor

Bob MooreMay 2nd, 2010 at 2:21 pm

What a croc, using a 5250 Telnet based emulator as the conduit for access is status quo/past. “Open” is a misnoma in context, Telnet as open “path forward”??? Try open Silverlight apps on iPhone (Apple prohibited). Microsoft specific vendor tools have never been and wont ever be open, remain web problematic. You should declare your affiliations in rants like this.

The concept of RPG OA is to remove the 5250 from the equation. I think your message speaks of something else, other than RPG OA. To wit, I don’t know how to answer.

As for my affiliation, my consulting is based on the right tool for the job, not a sales pitch for one vendor over another. In fact, if you had read my post, you would have understood that when I said “I have often supported them when choosing the “right tool for the right job”, and will continue to do so when appropriate.”

Should I declare an affiliation for BCD and LANSA based on that support?

Trevor

Bob MooreMay 2nd, 2010 at 3:28 pm

Your welcome.

You know the answer, FAQ via looksoftware site;

“looksoftware believes a prerequisite for Open Access success is integrated
support for existing 5250 based applications … Given most
existing IBM i applications are 5250 based, new RPG OA code needs to
work with 5250 applications to provide the business user a single,
consistent, seamless User Experience.”

This does not smell like 5250 removal to me.

I read the post, hence comments. Affilliations, you and I know that answer as well.

As I see it, every ‘modernization’ vendor supports existing 5250 application. If you don’t have source, if you don’t want to invade your code, if you have some reason to keep your application intact as part of your modernization strategy, then you are going to need to support the huge population of 5250 applications.

Whether you are scraping the 5250 from telnet, whether you are scraping the 5250 from the webfacing APIs, whether you are using RPG OA to deliver the existing 5250 to a new interface, there is going to be 5250 in your present, and most likely in your future.

I noticed that this paragraph from the looksoftware site does not mention telnet, but you did. I don’t see the connection.

Trevor

Bob MooreMay 2nd, 2010 at 7:10 pm

You dont see Telnet connection? Most commonly used protocol, including looksoftware client, whether or not intervening server used. “Blending of RPG OA code with existing traditional 5250” in this case uses client software?

KensterMay 3rd, 2010 at 1:00 pm

Does Bob work for BCD or LANSA?

GaryTMay 3rd, 2010 at 3:27 pm

Bob, We (RPG developers) have been begging IBM for a solution to provide easy to learn browser-based RPG programming for many years now. If you look at the combination of RPGOA and ProfoundUI you will see the use of the RPG 5250 programming methodology (EXFMT, etc.) with a replacement for DDS screens, that replacement being browser pages. I think you’ll be surprised if you just take a few minutes to look at their implementation. My affiliation, by the way, is that I’m a customer of Profound Logic and our shop has been successfully writing browser-based applications using RPGsp for several years. Take a close look at ProfoundUI and you’ll see that the 5250 screens are gone. The implementation takes advantage of the ease of programming we have come to love about RPG + DDS. It sets you apart from learning HTML and all that goes with it. While this may not be the “perfect” solution, what is? This is likely as close as we will ever come to a native GUI for the i. And Profound Logic will continue to improve the feature set of this product, just like any software vendor. So far, I’m loving this product and its potential.