There are some fundamental parts in almost all IBM i modernization projects:
- Reengineer the database (DB2 for i)
- Refactor the code (RPG or COBOL)
- Improve the user interface (DDS or panels)
Of course, the details of these three components are what makes modernization discussions so interesting.
How far you should go, where you start, what you choose – all open to interpretation. But one idea is important no matter what direction you choose – clean up before you move up!
An important step before you modernize is to take a good look at your code base. Do you have code that’s so old the indicators are blinking on and off like a neon sign? Where the code serves a business need that’s long gone? Code that requires manual effort (like direct file manipulation) to achieve the business purpose? Programs where the source and object are strangers?
Follow some simple rules:
Clean up business rules and logic. Ensure that the business rules you’re modernizing actually fit your current needs. Make sure the logic is correct – calculations, data movement, data entry. Don’t modernize code that’s inaccurate. You may need to change the code before you modernize the code.
Don’t modernize bad code. This is a great time to remove those manual steps from an existing application. Stay away from modernizing applications that need multiple places of entry of the same information. Fix problems that blow up in the middle of the night before you modernize – don’t take those problems with you.
Match object and source. Know where the objects and the source reside. If you don’t have corresponding object and source, stop the process until you determine the discrepancy. If you don’t have source, find it – you won’t be able to modernize it anyway. If you don’t have object, you probably don’t need to modernize the source – you’re not using it.
Remove unused code, both object and source. No need to modernize anything that isn’t being used. Take a close look at your code base – there may be a fair amount of deadwood in the mix. Applications have a tendency to ‘pile up’ unless they are actively archived and removed.
Establish a ‘code freeze’, where no new changes are added to the application. Unless it’s a dire emergency (production down), part of the code cleanup means not introducing anything more to clean up. You need to be careful of course – you’re still running a business.
Take a look at job scheduler entries, whether it’s the IBM i Advanced Job Scheduler (AJS), the standard scheduler, or a third-party product. Are you running scheduled jobs that don’t really accomplish anything? Perhaps accessing data that’s not being used, or sending files to somewhere that’s no longer important?
Along the lines of scheduled jobs, take a look at your interactive menu options. Are all the options being used? Are some options just sitting there, not being selected? You can examine the object to determine the last time used. You may also want to interview the users to identify the options they really use. Don’t modernize unused options.
An automation approach to code cleanup can be valuable. Consider the time spent in simply identifying the objects without source and the source without objects. How will you perform this matching? Getting a list of all the objects is fairly simple; just use a DSPOBJD of all the objects in a library. Oh, make sure you have all the libraries. And then filter out the non-source objects. Then get all the source involved. Match it by name? Sure, but what about multiple members with the same name? And which member is associated with the object? The issues may seem simple, but they’re involved.
You may wish to engage with an IBM i modernization company such as Fresche Solutions. Our X-Analysis product can do this heavy lifting for you. Automated documentation and inventory analysis can relieve you from the low-level tasks and allow you to focus on the bigger IBM i modernization picture.
X-Analysis can assist you in identifying the complex relationships between programs and files. In addition, dividing your code base into Application Areas can help localize code that isn’t being used.
Modernization is not an easy process. Don’t make it any harder – take the time to examine your code and clean it up. Time spent in the beginning of the project can save days and weeks on the end of the project. Investigate automation to help with some of the processes. Limited resources, limited time – make the best of both.
