IBM i (AS/400, iSeries) business-critical applications have been running for decades and desperately need help as companies grow and business needs evolve. Waiting means running into technical debt where IT departments say, “We’ll get to that later.”
We regularly see the need for database field resizing as businesses expand organically or via acquisitions. Field resizing is often a long-term project, taking years to complete if done manually. Because of this, companies avoid tackling it until they have no other choice.
Why Database Field Resizing is Challenging for IBM i Organizations
In many cases, there’s a deadline involved with a resize project because it’s related to growth within the business. Suddenly the same software that you’ve relied on to give you the competitive edge is unable to sustain that growth.
At face value, resizing fields within RPG applications seems straight-forward. The reality is that it can be a complex process that can lead to all sorts of issues. When you manually complete a field resizing project across applications that have been built and managed for decades (often by multiple programmers), you’re going to run into obstacles and introduce human error.
A project of this magnitude could grind operations to a halt.
How Are Organizations Addressing IBM i Field Resizing?
A client that I worked with had 92 locations and their location field would be full at 99. They needed to expand to three or four digits to support their growth, all while managing the daily aspects of the application. That’s why it’s important to look at ways to minimize the time and effort required.
There’s no easy button for completing a field resizing project. IBM i applications are often a blend of different programming styles, and you don’t always know what you’re going to encounter when you start digging into the code.
Even the most patient programmer might sit down and manually review the code, uncovering the hidden secrets and skeletons in the closet. It’s a tedious, laborious process. However, project fatigue inevitably sets in, and the programmer gets bored. That’s the perfect way to introduce mistakes.
The Best Way to Approach a Field Resizing Project
There are three things that you need to make a field resizing project successful. The first is application understanding. You must uncover the information that identifies the challenges you might face. You should be able to track where this data is being passed from one program to another program as a parameter. You might have something like smart fields. This is a practice that came into play because programmers were hesitant to change a file.
That leads to subdividing a field. You might logically say, “This field contains three values. I’m going to write my programs around it to interpret those three values that are stored in the one field.” It’s a headache to resize that field.
You need to identify what those fields are and where they are, as well as any cascading impacts in your code? You might have numeric data that’s stored in an alpha field that might not match the data that’s stored in another field because it happens to be numeric.
The second thing you need is a comprehensive set of test plans. Your test plan is going to enable you to determine whether you’ve tested everything that you need to test. Can you narrow your testing down to only test the things that you’ve actually changed? Regression testing is another consideration because you shouldn’t introduce any new behavior.
The third key to success is automation. When you make a change, it could require you to recompile hundreds or even thousands of objects throughout your entire application. Automating the process will help you do this efficiently while reducing risk and the number of human hours required. Automation allows you to focus on the parts that truly need attention.
Successful Field Resizing Projects
MEDHOST’s preliminary analysis projected that only 200 files would have to be changed. When they cross-referenced with our automated solution, X-Analysis, we found 1,600 files that required changes. Can you imagine missing 1,400 files in your resizing project?
“Based on the magnitude and depth of the project, I can’t imagine the amount of human hours that would have been required to match what X-Resize can do in just hours—without bringing in the potential for human error. It’s really quite amazing.”
Cliff Dowell – Senior Software Engineer, MEDHOST
Another client had a relatively new application and had employed a data dictionary to make changes easier. They were able to use X-Analysis to automate 95 percent of the effort, which left them only 5 percent of the manual effort.
New Penn is a North American shipping company that wanted to expand their customer number field to support growth. Their original project estimate for a manual undertaking came in at 13 to 14 person-years and over $1 million. When they compared that to the time and effort involved with using X-Analysis, their project estimate came down to around six months and a 90 percent reduction in cost.
Tips for IBM i Field Resizing
You need to know your application. You need to know how things interact. Depending on the size of your application and the field, the change could be small or significant.
You also need to know what to look for. What are the areas inside of your code that are going to be problematic when you’re completing a resize project? Knowing what they are will help you understand the scope and will help you prepare in terms of cost and effort.
Get organized. If this is a large effort, I would suggest completing it in smaller deliveries by breaking it into smaller elements for quicker testing. The first changes to test are the objects that just need to recompile. You could run them first, then work on the items that require manual effort.
Finally, testing is key to a successful resize project. You need to test enough – not too much, not too little. That’s why I advise that you take the time to understand your test plans and how they compare to the code that you’ve changed so you can reduce the amount of testing you have to do.
Learn More
My colleagues Robert Arce and Stephen Flaherty hosted an educational session where they discussed field resizing in more detail and introduced Fresche’s automated resizing solution, X-Resize. You can view it here.
