IBM i

IBM i (Photo credit: Wikipedia)

I work every day on a mixed code bag, including code written in the 1980s in one of the oldest known programming languages. Really out-dated stuff, what’s known as RPG-II. It was designed for the IBM System/34 and was the main coding language used on the IBM System/36 as well.

HP and Wang made their own RPG compilers to offer a way to pull customers away from IBM, but they apparently mostly quit trying after IBM brought out the System/38 and then the AS/400, the business system that blew DEC’s rival system and HP’s special ‘midrange’ into history. We who have worked on these IBM midrange systems -IBM now calls it “midmarket”– never could understand why everybody didn’t want to go out immediately and move their business to the most stable and secure-able system available so we always blamed IBM for hiding it and hiding their advertising budget from it, presumably to protect their lucrative mainframe business.

I”ve been through major upgrades and conversions of software from one base to another.

But at a lower level than that, I’ve considered different factors relating to program changes. The code base that’s so old for example, could benefit from a major overhaul and conversion to a more modern code base that could cut down drastically on both code change costs (in hours) and reduce the program halts that haunt ancient code bases that have gone through patches, fixes, more patches, enhancements and modifications over longer than the lifetime of the younger developers among us.

Programmers are generally attracted to “refactoring” old code, but it’s a bad word to CIO’s and managers who imagine all the kinks that occur with implementing changes and new code.

But we can minimize the pain of damages. I’ve thought of some things that make life easier to code changers and projects in general.

(1) Gosh, guys, get a good code analyzer! They’re around, and yes, the IBM i world has them too. Maybe especially. On the IBM i, for example, there are some that drill down into your code and claim to come close to extracting your business rules, identifying unused “orphan” code, and even maybe suggesting possible improvements. They exist even for COBOL code, but believe that these are not quite as thorough or detailed as the ones for RPG, understandable, but they’re more than nothing.

(2) We can minimize the disruption of changes.

We can make changes by steps, unless it’s a major difference in business rules, no way around that. But for changes that fall short of that, you don’t have to change all the menus and programs at once, change them a bit at a time. That saves money and nerves for the users and provides a proving ground for the changes, and helps dampen user complaints, which usually come from users who get comfortable, often with good reason, doing their jobs a certain way and have a hard time with the new stuff.

Y2K is an example. The best change-overs were either completely invisible, or moved smoothly into four-digit years. That project was so good the world scratched their heads and wondered what the fuss was about, and they thought maybe we had pulled a big scam on them. There was even a line on one of the Star Trek shows (or was it a movie) where an predecessor to Captain Jane wondered aloud whether there was really a problem.

Of course we coders know we saved their behinds!

Advertisements