Modernization is one way to enhance the value of an application, but reducing back-end maintenance expense is a close second.

The trend toward modernization of RPG legacy systems is in full swing largely because companies realize it makes more sense economically to upgrade the front-ends of these applications than it does to rewrite or replace them. What you don't hear much about, however, is the job of maintaining the back-end of these programs that may have been written 20 years ago.

Today, there are few if any large-scale RPG development projects being undertaken, and the generation of programmers who produced many of the solutions running the nation's businesses on the IBM midrange platform has retired, is thinking about it, or is getting serious about acquiring PHP or EGL skills to keep going 'til their fingers are so arthritic that they simply can't punch the keys on their keyboards. Stop feeling sorry for yourself; my dad was an architect and worked full-time until he was 95. He said he wanted to set an example for me. Thanks, Dad.

The interesting challenge for tomorrow's RPG programmers will be how they handle stepping into the middle of an enormous RPG program and figuring out what it is and how to maintain it. I can just imagine the exchange between a new, young programmer, who probably learned three to five languages in college, and his IT department manager: "What do you mean this isn't like anything you've ever seen before? Of course it isn't! It's proprietary! That's what proprietary means! That's what you went to school for, kid. Can you do the job or not?" Could get ugly. Just how long does it take a manager who doesn't know RPG to figure out that a programmer doesn't know what he/she is doing and is imparting defect after defect into a working program?

There will be jobs for RPG programmers coming out of school tomorrow, but they may not be the kinds of creative jobs that kids could be looking after they start developing in Java or other more-modern cross-platform languages. The RPG jobs that will be waiting for these youth will be challenging in a different way. They will be asked to maintain and enhance legacy systems at large organizations intent on preserving and extending their investment in complex systems that have served the companies well for some 20 years. They also will be helping their employers move on to other applications--and other platforms--where appropriate and when affordable.

One of the beauties of the IBM i and Power Systems is that the platform has allowed companies to preserve their investments in software and run the same applications today that they could when they owned a System/38. This has had its benefits, but it also has had its drawbacks in that there hasn't been a compelling reason to rewrite and upgrade the software. In the case of a very large application, it could cost a company millions to discard or rewrite its working RPG solutions.

So RPG applications will be around for quite some time, and there will be a need for programmers to maintain them as there is a need for COBOL programmers to maintain mainframe applications. So given that program maintenance will be a focus of companies as we go forward, does it make sense to relegate back-end maintenance to the status of an unwanted orphan? Or should we begin to elevate the position of maintenance programmer to a higher status than he or she has been afforded in the past? And if we decide this position is more important than previously considered (after all, the total operation of the company might depend on this person), then shouldn't we also have formal training, certifications, appropriate tools, and a commensurate salary  to go along with this professional discipline?

I sat down at COMMON with one of the IBM midrange platform's leading authorities on application maintenance, Steve Kilner. Steve is a low-key guy who writes well and has studied and thought about software maintenance for quite some time. His company, vLegaci, focuses on providing maintenance support to firms that are challenged by the requirements of maintaining legacy RPG systems. He offers training, consulting, and outsourcing and has developed a tool called Codelyzer, an RPG code analysis tool that helps RPG developers understand and analyze large and complex programs, especially ones with which they are unfamiliar. In some ways, it is similar to Databorough's X-Analysis cross-reference tool, though it's focused more on individual programs rather than the entire system.  According to Steve, Codelyzer can significantly reduce the time it takes to analyze code and can greatly help reduce maintenance defects. It analyzes compile listings by downloading them either to a PC-accessible folder or directly into the outqueue by using the free "Direct Connect" iSeries component. Codelyzer has been tested on V5R1 through V5R4. To use the Direct Connect feature, you will have to be running Client Access V5R3 or later. The tool can handle ILE RPG, free-format RPG, and SQL RPG, and a trial copy can be obtained by joining the Codelyzer beta program to which you sign up online through the vLegaci Web site.

Typical uses of Steve's tool including the following:

• Analyzing large or unfamiliar RPG programs that need maintenance work
• Researching reported bugs for production support
• Researching programs to estimate requested enhancements
• Analyzing programs to extract and document business rules
• Developing a systematic approach to IT's maintenance work (prospective changes and their impact can be reviewed by management prior to implementation, or even an impact analysis process can be put in place)

There are a number of maintenance activities overall, but the four major ones, according to Steve, are the following:

1. Corrective maintenance, in which you correct discovered problems
2. Adaptive maintenance, in which you keep software functioning in a changing environment
3. Perfective maintenance, in which you improve performance or maintainability
4. Preventive maintenance, in which you correct latent faults before they show up

These activities are done in the context of a software application that is likely changing regularly in order to ensure its usefulness; the average rate of change is about 7 percent a year. The problem is that, as software changes, it becomes increasingly complex--unless, of course, you take steps to prevent that. Maintaining software presupposes that the developer knows what changes to make and how to make them. It may not be surprising to those in the business that up to 60 percent of a maintenance developer's time is spent just trying to understand the program. Once you have a technical understanding of the program, you still should do an impact analysis to avoid adding new defects. Follow this with repeated regression testing to make sure you didn't break something in the course of making it better. Preserving a system's maintainability is the final technical issue a maintenance developer must consider in preserving system value.

Using methods on legacy system maintenance that were designed for new system development just doesn't work, says Steve, and he has taken up the challenge to develop a management system designed specifically for legacy system support and maintenance. Interestingly, he packaged it and offers it to customers remotely as "Legacy Application Support," or LAS.

 Steve is coming out with a new service to be announced in about a week. It is similar to LAS, but instead of being a complete outsourcing of the support and maintenance function like LAS is, it's more of a recession-response business targeted at companies that have had to let go of their maintenance support programmers. He is calling it RPG (Programming) As A Service, or RPGAAS, and the URL is www.rpgaas.com. The address takes you to a subsection of the vLegaci Web site. The new RPGAAS site was up and running this week but still under development prior to its formal launch.

The recession and the economy in general have changed the way business is being conducted, and, as in the recession of 1991, it is shaping up as a strong motivator of change. We wish Steve Kilner well in his new venture, and we think he may be in the right place at the right time with the right idea.