Friday, September 4, 2009

How much RPG code is Relevant?

Stuart started an excellent post on the value of a company's inventory of RPG. In my life before I went to work for IBM, I was CTO for a major insurance company who developed most of their systems in-house. We had a legacy of RPG code dating back over 40 years beginning with an IBM System III and RPG-II.

While we had some excellent RPG programmers over the years we also had many that were not so excellent and wrote code that worked but was quite frankly not very maintainable. This code would read like an English language conversation, had incredible amounts of redundant IO -- yes the same record read each time an edit, validation, or field was changed on a single screen.

The screen handling IO was embedded with business logic to the point that it was virtually impossible to segregate business logic form 5250 IO from Database access. In other words, spaghetti code.

As a company moves toward modern UI's and services like Web 2.0 and Web Services, it would be incredibly desirable to leverage existing business logic in existing RPG code. Extracting viable bits of code into reusable components can be a daunting task making a total rewrite of the application a better choice for many CIO's.

Databorough's X-Analysis offers some hope and tools to facilitate harvesting of business rules into reusable components (ILE modules, procedures, or at least subroutines). It also provides via its English Language psuedo code a way to facilitate a straight rewrite of code if that's the route you choose in the same or different language.

BTW, don't blame the programmers totally for the code you are stuck with. Much of the code you see in your shop are based on IBM examples from REDBOOKS or other "experts" BOOKS leveraging changing positions on performance over the years.

At one time you wanted your code totally sequential and in-line with no subroutines to optimize how the CPU would process your code.

Some of you may be stuck with code generated by 4GL's that is virtually unreadable. Quite often the code was generated using a 4GL vendors tools and your programmers then had to manually modify the code to add functionality that the 4GL did not provide. Once this was done you had code that could no longer be maintained by the 4GL tools. These programs have hundreds of lines of redundant unnecessary code.

The best solution are tools that can analyze and help you identify what is relevant and what is not.

What about RPG II code? I know that in my previous life a huge number of my RPG Programs were written in RPG II. Depending on your business requirements it may be worthwhile to first move your old RPG II or OPM RPG III code to ILE before doing anything else.

If you still have programmers writting in the old RPG II style you have some major skills problems to deal with as well as the code.

Databorough's tools are not a silver bullet, but they can definitely help you understand what you have and form a modernization strategy based on facts and provide CIO's with a means of managing a modernization project in an objective manner that minimizes risk.

No comments:

Post a Comment