Cobol Contrarian
Papé Group Inc., a capital equipment dealership operating in seven states, is bucking several trends. All its application software is custom-developed, and all of it is Cobol. But even so, the Eugene, Ore.-based company says finding programmers with Cobol skills isn’t all that important.
Shaun Swift, Papé’s director of information systems, says custom systems provide a better fit for the company’s needs than commercial software packages because they can be enhanced and modified more quickly. And he says his hardware and software environment — Cobol 85 running on a Hewlett-Packard NonStop system — is more reliable, stable and secure than the more popular Windows alternatives.
The average age of his six Cobol programmers is about 50, Swift says, but he doesn’t worry about losing them to retirement because “Cobol is an easily learned language.”
Of recruiting, Swift says, “Sure, I’d like to find someone who knows Cobol, what I’d really like to find is someone who understands business processes. ... And I’d like to find somebody that has actually developed systems; those people are getting hard to find.” What often passes for a software developer today is someone who knows how to install and tune packages, he complains.
Although Swift says knowledge of business processes and software engineering principles trump Cobol skills when he’s recruiting, other IT managers count on programmers’ interest in application content to get them to swallow the Cobol pill. For example, Walker says, “I have one Cobol programmer who just loves working on the criminal application because of how interesting it is — you are helping take bad people off the street.”
Ursula Morrissey has been a Cobol programmer at the Connecticut Judicial Branch for 20 years, and she admits wanting to try newer technologies. But she doesn’t make a fuss about it. “I’m really needed right where I am,” she explains. And, perhaps more important, Morrissey says, “I really like working on the criminal application, learning about the law and how the courts function.”
Still, she adds, “if we ceased to program in Cobol, I probably would not be searching the ads for a Cobol programming job.”
Dan Colford, director of IS services and support at Katun Corp. in Minneapolis, says he doesn’t have trouble finding people with Cobol skills. He says it’s harder to find people with experience in VisualAge Generator, a Cobol-like development tool from IBM that Katun uses extensively.
Asked if it’s hard to motivate people to work on the company’s Cobol-based inventory management, order-processing and financial systems, Colford says, “With any IT person, the motivation is learning new things, and keeping them stimulated is part of my job as a manager. There is some concern that they are getting stagnant, and there is some merit to that.”
The solution is to simply ask these programmers to continue with Cobol while promising to let them get involved with new things in some reasonable amount of time, Colford says. For example, Katun will replace all of its Cobol with an ERP package from IFS North America Inc. in Chicago within 18 months, and Colford is letting his Cobol coders delve into the IFS software now.
For years, pundits have said that the way to avoid the headaches of maintaining Cobol — and mainframes, green screens and other legacy paraphernalia — is to replace them. But that hasn’t happened, even in the massive Y2k remediation effort.
Indeed, Cobol promises to be around for many more years, challenging the IT managers who must support it. “A lot of people have said they were going to get rid of the mainframe, but that hasn’t happened,” says Mark Washik, a consultant at Schneider Electric SA in Palatine, Ill. “And for us, all that code is working. There’s no sense in rewriting it.”