That is very true - there is a lot of cobol out there.
Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2F...
back
2 comments
And .NET as well.
http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n...
It can even target Azure deployments!
Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?
What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.
Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm.
It was a bank, and transactions were processed through a pipeline.
Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into another always-active system.
The Cobol processes basically munged, pulled and pushed to database/s, and then killed itself.
In this case, I could see warm-up time being a huge issue, though a switch into another language might bring a change in architecture to threading and the like which would remove that problem, but I can't see a bank changing architectures easily.
From my limited exposure, several financial companies connected with the bank had similar processes. Something like Java or C running a server, Cobol when numbers need serious crunching, and then back into another server application.
(Incidentally, both the server processes were Fortran, if that's interesting to anybody).
I think I understand what you're saying but cobol runs in an environment that is optimised for cobol, and I'd expect where this were to be java you would have a similar arrangement in place. For a trivial example of what I'm talking about check out nailgun [0]
Yes, a change to Java would require a large architecture change. Notably from mainframes to something a little bit more familiar to most people.
But when Cobol works, is blisteringly fast, and they can afford to hire and train people to work with it, I don't see the benefits of Java, at all. Especially not at the enormous costs of a major architecture re-work in systems that are live 24/7, and downtime is counted in milliseconds.
Having to work around the JVM is just icing on the cake.
would require a large architecture change
No, it wouldn't. Java is already used on a broad scale for this kind of thing. The ways in which it needs to be tuned for this kind of thing are in widespread use.