Thoroughly Modern: Resizing Application Fields Presents Big Challenges

February 10, 2020 Timothy Prickett Morgan

It sounds so simple. You need to change the size of one or more fields in one or more applications. How hard can that be? Quite time consuming and labor intensive, as it turns out, if you don’t do it right. To get a sense of the issues that companies face as they tweak the fields in their applications, we sat down with Ray Everhart, a product manager at Fresche Solutions, who knows a thing or two about this issue after many decades in the field.

Timothy Prickett Morgan: Can you tell us a little bit about your experience in the midrange industry, your current role, how you work with IBM i clients, and your technical background?

Ray Everhart: My first job in IT was supporting an IBM System/23 for a small manufacturing company. They were quickly outgrowing the old system so they ended up replacing it with a System/36 and MAPICS 2. That’s how I got my start in the IBM midrange space. I worked with that company for about ten years and then the consultant that helped us implement the System/36 and MAPICS made me an offer to come work for them.

I spent about 10 years with the consultant and supported about 75 small to medium sized businesses. These were organizations that didn’t have their own IT staff. As a result, I got to do a lot of the things for them that I used to do for just one company. I would do everything from programming to designing forms to modifications. I also learned how to use IBM i in many different industries.

When the recession hit in the 1990s, a lot of those small businesses had less of a need for those kinds of services. My career took me to Texas and I started working as a consultant for larger companies on things like R&D of new technology from IBM. I worked on high availability, a lot of systems for mission-critical applications and applications that were much higher in volume and needed to scale differently.

At that point I was working with a lot of different large companies and I was looking for a way to distinguish myself from some of the other consultants out there. I started using X-Analysis to provide that competitive edge to the other consulting companies.

It wasn’t long after that Fresche approached me, and I started working for them. Now I get to do what I was doing before but for a lot more customers. I get to help clients modernize their applications by managing the X-Analysis product and giving them the tools they need to improve their applications.

TPM: It certainly sounds like you have had a lot of experience working with IBM i shops and getting a sense of what it really means to be an IBM i developer yourself. It helps to have first-hand experience to understand the challenges development organizations face, and this has to feed back into your day job at Fresche.

Can you share a little bit about the subject of field resizing and why it can be such a challenging initiative for organizations to take on?

Ray Everhart: We see the need for field resizing all the time because a lot of companies are looking at growth, either organic or through acquisitions. When there’s growth involved, field resizing becomes an issue. Typically, if you aren’t approaching the task from an automated perspective, you’re often measuring the effort in years instead of months. As a result, many companies don’t want to undertake these projects if they don’t have to do it. They put it off as long as they possibly can, but the reality is by the time it gets to a point where it has to be dealt with, it’s often a very mammoth undertaking.

IBM i has always been about solving business problems and doing it quickly. Unfortunately, that’s led to some situations where the best engineering processes and practices weren’t always followed. After 30 or more years, some applications are long overdue for a little bit of tender loving care. In my experience, the longer the changes are delayed, the harder they are to make.

The very strength of IBM i is that it protects the customer’s investment in their software, and it doesn’t force them to re-engineer. They don’t have to rewrite their software every time a new version of the operating system comes out. To some extent that’s also its greatest weakness because there are applications that have been out there for a very long time, still running, still working, but are desperately in need of some help. When you try to complete a field resize project over that kind of code, you’re going to run into a lot of obstacles. You’re going to run into issues of technical debt where people always said, “We’ll get to that later.”

Those things always rear their head when you’re doing a resize project and you don’t want this project to consume all of your resources for a long time. There’s always a deadline involved because a resize project often indicates there’s some kind of growth within the business. Something is forcing this uncomfortable thing that you’ve been putting off, and the very same software that you’ve relied on to give you the competitive edge for growth is now unable to sustain that growth.

For example, a client that I’m working with has 92 locations and their location field will be full at 99. They need to expand to three or even four digits to support their growth. There’s a lot of pressure and that’s when design decisions that were made before come to the forefront. That’s when you start realizing that you have a lot to deal with here and need to start looking at ways to minimize the time and effort required.

TPM: How are organizations addressing field resizing today? They aren’t actually trying to do this manually, are they? Then again, maybe they are. . . .

Ray Everhart: The first point that I’d like to make is that there’s no easy button for doing a field resizing project. Each system is unique. It’s a blend of a lot of different programming styles depending on how old it is; you really never know what you’re going to encounter when you start digging into the code.

A patient programmer might be able to sit down and manually go through all of the code and uncover all of the hidden secrets and the skeletons that might be in the closet. It’s a very tedious, laborious process. If you have a project that runs as long as some of the resize projects that I’ve seen, project fatigue inevitably sets in and the programmer gets bored. That’s the perfect way to introduce mistakes into the process.

You’re going to have different challenges in every resize project. Depending on how well the application was thought through when it was written will affect how much time is taken to do the resize project once you’ve decided you have to go forward with it.

TPM: So what would you say is the best way for clients to approach a field resize project?

Ray Everhart: There are three things that you need to make this project successful. The first is application understanding. You have to be able to uncover the information that will identify the challenges you have to face. You should be able to track where this data is being passed from one program to another program as a parameter. Or maybe you’re doing some kind of a data structure subfield manipulation. I’ve recently seen code that is still using the LDA. There is still some really old code out there.

All of these different things might be lurking in your code. You need to find a way to understand what you have to deal with. You might have something like smart fields. This is a practice that came into play because programmers were hesitant to change a file.

That led to subdividing a field. You might logically say, “Well, this field really contains three values. I’m going to write my programs around it to interpret those three values that are stored in the one field.” If I have to resize that field, that is a real headache. So I need to be able to identify what those fields are, where they are. What cascading impacts are there in my code? Sometimes we have numeric data that’s stored in an alpha field and 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. The test plan is going to enable you to determine whether you’ve tested everything that you need to test. More importantly, can you narrow down your testing to only test the things that you’ve actually changed? You also need to be able to do regression testing to test your application before your change and after your change. You shouldn’t introduce any new behavior because you’re just changing the size of the fields.

The last thing that’s required to make this successful is automation. The change could be throughout your entire application and you could have hundreds or even thousands of objects that are going to need to be recompiled. The ability to do that automatically is important because you’re going to have to do it several times. You also need to be able to migrate the data from the old structure to the new structure.

There are some things that could be changed very easily and very reliably using a program to change the program. And then there are other things that you need to look at and determine what the original intent was. If you automate the parts that you can, it allows you to focus on the parts that really need your attention.

Automation also reduces the risk of human error. MEDHOST is one of our clients, whose preliminary analysis projected that only about 200 of their files would have to be changed. When they cross-referenced with our automated solution, we found 1,600 files that required changes. Can you imagine missing 1,400 files in your resizing project?

Having application understanding, a good set of test plans and automation really go together to make the project successful.

TPM: Can you share any experiences with clients who have embarked on a field resizing project? How were they successful, and what were some of the challenges they experienced along the way?

Ray Everhart: I have some positive and negative experiences to share. I’ll start with a couple good examples. This particular client had a relatively new application and had employed a data dictionary to make changes easier. They were able to use tools to automate 95 percent of the effort, which left them just 5 percent of the objects that they had to manually go in and look at.

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 an automated tool, their project estimate came down to around six months and over 90 percent reduction in cost.

Now I have a less successful example. A client used a tool to uncover what needed to change and the tool even made the changes for them. But after that they sat down to figure out what to do about testing. At this point in time, they didn’t have Code Coverage available to them. That’s a fairly recent addition to the IBM i operating system.

They didn’t know which tests they would have to run. Their safe way of approaching it was to run all of them, and as a result all of their testing was done manually. When we added it up, it would have taken about two-and-a-half years to run all of the tests after the programs were changed. That didn’t even account for any things that may have shown up during that testing.

Unfortunately, while the code changes could be automated and we could use the tool to tell us everything that needed to be tested, they didn’t have good test plans and they didn’t know what those test plans actually covered. The cost of the testing alone canceled the project.

They found a way to live with it for the time being but it will come back to them because the field that they needed to make bigger was a loan amount on a home mortgage. When the software was written 30 years ago, mortgages were a lot lower than they are now. So they’re going to have to do something if they’re going to continue to use the IBM i to manage all of these loans.

TPM: Any parting suggestions that you would offer to companies that are facing a resize project and aren’t sure where to start?

Ray Everhart: You need to know your application. You need to know how things interact. Depending on the size of your application and depending on the field, that could be a small or a significant challenge, but you need to know your application to determine that.

You also need to know what to look for: What are the areas inside of your code that are going to be problematic while you’re doing a resize project? There are some things that’ll be very simple to change. Others won’t be quick and easy. Knowing what those are upfront will help you understand the amount of scope that you have in this project and it’ll let you be better prepared for the costs associated with it.

I would also say you need to take the time to get organized. If this is a very large effort, you need to be able to complete it in smaller deliveries and break it into smaller elements so you can test it. The first changes to test are those objects that just need to recompile. You could run those through first and then you can work on the things that have to be done manually or that require more effort while the first set of applications are tested.

Finally, testing is key to a successful resize project. You need to test enough, not too much, not too little. And that’s why understanding your test plans and how they compare to the code that you’ve changed. That’s why that’s crucial because you can narrow down the amount of testing you have to do to be just right. And those would be the hints that I would give anybody who is about to start on a project like this.

TPM: Are there any resources you can share for anyone who is looking at resizing?

Ray Everhart: I led a session recently where I discussed field resizing in more detail, and introduced Fresche’s automated resizing solution. You can access it here.

Here are a couple of examples of successful field resizing projects:

Finally, I want to make sure everyone is aware that Fresche is conducting an IBM i In Business survey. We are hoping to hear from as many IBM i organizations as possible about what is driving innovation, current and future priorities, and any challenges you’re facing.

The results of this survey will be shared throughout the industry this spring and the insight gained will help all of us get a better picture of what IBM i organizations are facing today.

If you need more incentive to participate, anyone who completes the survey is eligible to receive free IBM Watson training from Fresche and COMMON membership benefits. You can participate at this link.

This content is sponsored by Fresche Solutions.

Ray Everhart is a product manager at Fresche Solutions.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search