From AS400/RPG to IBMi/RPGLE
I’ve been involved in some heavy RPG modernization projects recently. Ranging from application replacements, to middleware webservice integrations to light code dusting….
I enjoy it all, just a little too much!
Forget Alcoholics Anonymous, I should attend a software modernization addicts meetings where AA = AS400 Anonymous
“Yes my name is Nick Litten and I am a RPG refactor-a-holic”Me – in my last AA meeting
A frequently asked question in project kick off meetings is “What is AS400 modernization?”
So lets look have a quick high level chat about what it is, what we should think about and how we get it moving…
How do we start our modernization project?
The driving idea behind modernizing a legacy IBM AS400 application is much more than the simple task of refactoring our old RPG and CLP codebase.
I like to think in terms of these three project design steps:
1 – Database modernization
Reviewing your DDS based database and deciding how to migrate to SQL and DDL (which is the SQL equivalent of DDS source).
SQL is more flexible than DDS, but it has a steeper learning curve. I also find it much easier to make a silly fat-fingered mistake and cock things up. With squirrels, always measure twice and cut once.
This is the stage to review your old DDS field types and decide how to upgrade them – for example, dates stored as 7,0p CYYMMDD or 5,0p 100 YEAR can be changed to native DATE FORMAT type.
What about performance implications – consider how indexes and views can present the information you need.
Stored SQL Procedures can handle small recurring chunks of business logic in a really simple and quick ways.
2 – Application Modernization
This is a much bigger step than simply uplifting old RPG3/RPG400 to RPG ILE and /FREE-FORMAT. Obviously, based on your database decisions, the size of the code refactor can range from simple refactoring (RDi does a nice job) to major rewrites if you’re moving to a true web enabled model.
Changing Original Program Model (OPM) code to an Integrated Language Environment (ILE) can involve light code refactoring, which merely upgrades old legacy code to use the new syntax but still functions the same, to heavy refactoring which means a complete rewrite and often a different way of executing.
Think about Software Change Management and how you are going to handle any code changes.
Think about how changing data layouts, and how your programs handle them. Passing parameters that have changed type from good old fashioned alpha characters is often something that bites you on the bum.
3 – Interface modernization
Is your IBM i application going to present IBM i Database information, via webservices, to a completely new web based front end?
Is your IBM i application going to continue to function with an overlayed, screen scraped, web front end?
Is your IBM i application going to be enhanced to write directly to a web-based front end hosted from the IBM i Integrated Web Server?
This list goes on and on….
Modern IDE’s (code editors like RDI) are essential for this process of design and code. The old green screen code editor, S.E.U. (Stone Age Editor) does not understand *FREE format, nor any of the modern RPG ILE syntax and %BIF’s. Don’t waste time with it, retrain and enjoy the advantages of a modern coding environment.
That’s just a snippet of the steps involved in modernization.
all quotes taken from my new book “Modernization for gray haired sandal wearing AS400 technogeeks” 🙂imaginary book title goes here