Code Quality on IBM i (aka AS/400 or AS400)

Monitor the health of your RPG or COBOL application

Eliminate technical debt

What causes technical debt on IBM i?

Many legacy IBM i applications are burdened by areas of code that are over-complex or monolithic and difficult to maintain. At the same time, areas of ‘dead code’ – sometimes as much as 30% of a code base in volume – occupy valuable developer time and add to overall complexity of the system. These ‘hotspots’ generate unnecessary technical debt that can negatively impact the long-term viability of software and drain the revenue of your business.

Over time, neglected applications become brittle, making them increasingly more expensive to support. In turn, enhancements become cost prohibitive, creating a vicious cycle.

How to recognize brittle code?

IBM i business applications have proven so secure and reliable over the years that they are often considered too valuable or too risky to replace. Yet their RPG or COBOL code may have been maintained by multiple developers over 20-30 years, escalating the risk of technical debt.

Common characteristics include:

Monolithic programs in older RPG variants (2, 3 or 400)
Use of ‘fixed format’ RPG, unfamiliar to a new generation of developers
Bugs that have been there for years, in code that is ‘too important to touch’
Dead Code: Up to 40% of your application never executed
Over-complex code preventing the move to a Web services architecture
Little or no documentation

In addition, security vulnerabilities can creep into source code as IBM i database logic is exposed to external applications and devices.

Consequences of technical debt

If coding defects reach production, they can cause costly downtime and damage the reputation of your business. Unaddressed technical debt can impact an IBM i organization in multiple ways: