« Programmer's Block | Main | Sometimes the Simple Ways Are the Best »

July 30, 2013



I think the biggest problem when it comes to midrange modernisation is defining what that means. I personally don't think that screen scrapers or HATS or WebFacing count, but managers seem to.

As a programmer who's worked on custom in-house code for most of his life, it seems to me that a company's best interests are preserved if the modernised version is also written in-house.

My utopian vision of a fully realised modern application would have a web front end. .NET, Java, Ruby on Rails, PHP - I'm not sure it matters much. The back end would hold all the business rules: those monolithic RPG III programs we all wrote in the 1980s would be decomposed into RPG IV subprocedures.

During the transition, there would be wrappers written so that existing green screen code could access the subprocedures. 'Direct' access would avoid the overhead of setting up API calls between bits of the application whilst shielding the application from changes in business rules and database layout.

The ultimate goal would be a TCP/IP API that would allow a web user to authenticate, request data and actions of IBM i.

Bruce Guetzkow

Buck seems to have the right idea. There are a lot of great choices out there for front-ends, but the business logic can be carved-up legacy code, made into procedures & service programs.

I'm looking into using Joomla as the core, building (PHP) extensions as the application. This will allow me to mix content-management with DB2 data. It also will allow me to split access to the application from direct access to the IBM i.

Jon Paris

@Buck, @Bruce

The book will be covering all the kinds of modernization you mention BUT it will also cover screen scrappers too.

There is in my opinion very good reasons for this. I personally don't like them as a long-term solution, but we have to be realistic and recognize that not everything can be rewritten overnight. If I produce a brand new version of application X should I defer deploying it until I can rebuild all the other apps that a user of X needs? That makes no sense. Equally forcing them to flip backwards and forwards between GUI and green screen makes no sense either. A good "scraper" can provide a similar look-and-feel to my new app and introduce a few much needed enhancements like drop-don't boxes for simple choice lists that will make the app easier to use. And it can do so with relatively little effort and $.

Hope this makes sense.


Are there screen scrapers whose output is good enough to deploy 'as-is'? I'd be interested in a review of vendor solutions that look good enough that developers won't be spending time on every converted display panel to... touch them up.

Isn't everything still basically the same block mode 5250 unit record I/O that every RPG programmer is familiar with? Or am I behind the times?

Jon Paris


I think a number of ISVs (look, profound, BCD. Lansa, and others) that offer dynamic refacing tools would tell you that that certainly is an option.

As to being behind the times ... the tools have moved ahead in leaps and bounds over the years. The advent of Open Access gave them another huge push forward.

Certainly though the best results are from tweaking the UI to add capabilities. I was recently shown a "screen" that actually included data from 4 or five different 5250 screens - including two that were actually paged subfiles. The tool had basically "paged down" until all data in the subfile was available. In addition some of the entry sections of the screen had been Ajax-ised to retrieve dynamically a list of products that were typically ordered by this customer to make the entry of the product code simpler. That retrieval was done in a completely separate transaction and had no direct impact on the flow of data in the original 5250 screens.

You also need to remember that with Open Access you are not as restricted as with a "real" 5250. I don't know if any of the vendors employ this approach but ... For example with a 5250 you can only read from a record format that has been written to and is current on the device. But those rules are imposed by Workstation Data Management - with OA WDM is not involved. So that limitation does not exist. An OA app can simply sit in a read loop waiting on Ajax requests and respond to them directly by writing the appropriate record format(s). The handler takes care of formatting them to meet the device's requirements. So we are not living strictly within the block mode paradigm - even though we are using the same basic op-codes.


Now I really AM intrigued. Looking forward to this one, Jon!


Sorry to hijack the post earlier. More on topic: prior art.

I have a thumb eared copy of Paul Tuohy's 'Re-engineering RPG legacy applications' from 1999 that covers some of the chores surrounding decomposing monolithic monsters into svelte subprocedures (if you'll excuse the editorial excess) :-)

Your own RPG Sorcerer's Guide as well as Brad Stone's 2000 book 'e-RPG' have both been useful in introducing more modern concepts to the RPG programmer.

I don't think modernisation will go well without modern thinking, so all 3 of these books seem a logical jumping-off place.

Dan Devoe


Several years ago, you were part of a team involved in updating the RPG-IV Redbook.

Will this new Redbook that you're working on contain topics that were originally slated to the revised Sorcerer's Redbook?

Greg Helton

How about a Unit Test framework to support Agile & Test Driven Development

Jon Paris

@Dan This redbook will not be as deep technically as the Sorcerer's guide. But it will cover a huge (and rapidly growing) spectrum. Last I saw the outline table of contents ran to 18 pages!

The idea is basically to provide a single point to which those seeking to modernize can go for the basics and ideas on what might work for them. In addition to the basic redbook many ISVs have been invited to contribute papers that will be linked to the appropriate sections of the book.

As to the material that was supposed to go into the rework of the original guide - some of it was published as Redpapers. There were two. One on APIs ( and one on Error Handling ( Not as much as we had hoped but ...

Jon Paris

@Greg If I recall correctly there is discussion on the topic of testing.

I don't recall anything specific on Agile or Test Driven - I'm not sure they really fit the theme in some ways. Yes they are relevant to improving development process as a whole but personally I'm not convinced that Agile really fits in a maintenance environment - which is effectively what this is about. They will probably be referenced with links to information sources but not a major topic area.

One of the problems of scoping a book such as this is that it needs to provide information that is usable by a 50 developer shop without scaring the 3 person shop to death. That's a fine line to tread. Time will tell if we achieve it.

The comments to this entry are closed.