A few thoughts on how to mix the new with the old
At the end of March, IBM announced some enhancements to the venerable programming language, COBOL. http://www-03.ibm.com/press/us/en/pressrelease/41095.wss
I know, you are thinking that a COBOL announcement is the equivalent of flogging what no longer needs to be flogged, but before we write this off as irrelevant, note that the announcement provides a couple of nuggets about COBOL in the market.
One nugget: “Today, nearly 15 percent of all new enterprise application functionality is written in COBOL.” It’s a surprising statistic that tells us that COBOL isn’t completely over. The other (something we probably know): “ … more than 200 billion lines of COBOL code being used across industries …” This portends that COBOL cannot possibly go away anytime soon. What else is interesting is the way IBM is evolving this language, and how they are talking about it.
The benefit of one COBOL update is obvious; the compiled code runs faster. But a couple of the other items seem almost unrelated to the world of mainframes. My attention was drawn especially to these two COBOL updates: 1) added support for Java 7 and 2) improvements to XML control with an updated parser. Putting enhancements in COBOL to better control Java, and specifically XML, on a mainframe is telling.
Obviously we have been able to run Java and handle XML on Big Iron for a while, and indeed IBM is working to make it a better experience when you do so. But handling the high-overhead activities like XML parsing, even if managed to special lower-cost processors, seems overly complex. In most of the Attachmate Verastream work I have seen over the last several years, we focus on keeping the mainframe-specific logic in COBOL unadulterated on the mainframe. But for XML and Java, we append to the COBOL code using a services approach. That way, the additive services, Java or heavy XML manipulations, can be placed external to the host as desired. This approach saves in mainframe processing needs and more important, it keeps the Java and XML manipulations separate from the COBOL logic.
This result is significant because it means the services approach will decrease our dependence on a COBOL language that will become more costly to maintain over time. A well planned services strategy not only allows you to decide where services are run, but also allows you to manage how much logic is controlled by what technologies. You ultimately get critical control over platforms and languages.
Are you extending your COBOL applications in a way that gives you this level of flexibility?
{ 0 comments }
