4 ms·

What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.

by rusk 9y ago

shakna 9y ago
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).
- rusk 9y ago
  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] [0] http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/
  - shakna 9y ago
    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.
    - rusk 9y ago
      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.

What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.

by rusk 9y ago

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).

rusk 9y ago
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] [0] http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/
- shakna 9y ago
  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.
  - rusk 9y ago
    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.