41–50 of 139 posts
> 5 billion lines of new COBOL code are written every year. Are you sure about that? Sounds like rather a lot.
One thing I don’t understand with these very old languages is that I thought the reason they are still around is because of some programs written in the 70s to early 90s are still around and needs to be maintained. But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that e…
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that expensive that no one wants to rewrite them in a modern language? You would be utterly shocked. I did some COBOL work for a bank. Most of the new code they write is in C++. However, COBOL was still a huge part of t…
One thing I don’t understand with these very old languages is that I thought the reason they are still around is because of some programs written in the 70s to early 90s are still around and needs to be maintained. But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that e…
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that expensive that no one wants to rewrite them in a modern language? You would be utterly shocked. I did some COBOL work for a bank. Most of the new code they write is in C++. However, COBOL was still a huge part of t…
Sounds like jumping from the frying pan into the fire.
I have regualr talks with people who were using COBOL a while ago. There are things were cobol is good : 1/ COBOL run in closed environments. This allows these to be rock solid. (no such thing as a dependency nightmare). You don’t have such a thing as different version of Java on your testing and production environment. 2/ COBOL forces you to mix concerns : DB access, file I/O, business logic. This is sometimes usefu…
I don’t think COBOL does force you to mix concerns. You could create sub modules / services which you call from a main program to do things like file writing or database reading. Java doesn’t also say you have to separate concerns. You could easily write a single method which mixes business logic and IO (file and DB) When writing a batch program you need a balance between understanding it, making it efficient and rel…
Sure, I was talking from inside my own enterprise-context where Java actually means Java + Spring + a few other things that force you to separate concerns (for the better imho, although it doesn't help with code navigation)
>>> The thing that has always let COBOL down for me is the lack of automated testing.
True.
I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any pro…
You can do that in assembly too
Earlier quoted context omitted.
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that expensive that no one wants to rewrite them in a modern language? You would be utterly shocked. I did some COBOL work for a bank. Most of the new code they write is in C++. However, COBOL was still a huge part of t…
Cobol programmers are starting to get few nowadays, and finding people that actually want to be trained in it is not that easy. Plus you dont just need programmers, but z/OS engineers, DB2 DBAs, MQ specialists, etc. And that's before you even start talking about the nice cheque you're writing for IBM every month. It does add up.
Earlier quoted context omitted.
Cobol programmers are starting to get few nowadays, and finding people that actually want to be trained in it is not that easy. Plus you dont just need programmers, but z/OS engineers, DB2 DBAs, MQ specialists, etc. And that's before you even start talking about the nice cheque you're writing for IBM every month. It does add up.
It is still cheaper than porting to the language du jour, like changing plane engines in mid-flight, while ensuring that the new system meets 100% of the existing requirements.
Earlier quoted context omitted.
It is still cheaper than porting to the language du jour, like changing plane engines in mid-flight, while ensuring that the new system meets 100% of the existing requirements.
There are alternatives, but i'm biased. See my other comment. One of the biggest hurdle we have is that the clients dont usually have many tests in place. Testing and validating a full batch night for example (ie 6 hours of intense batch work) is quite complicated.
What do you think about the .NET and JVM Cobol compilers?
They seem to be a way to move that code into new systems with no rewrites as well.
Earlier quoted context omitted.
> But how complex can these programs be? Surely anything written before 1992-ish can’t involve that much code just because of the limitation of the machines they were designed to run on. What makes it that expensive that no one wants to rewrite them in a modern language? You would be utterly shocked. I did some COBOL work for a bank. Most of the new code they write is in C++. However, COBOL was still a huge part of t…
Cobol programmers are starting to get few nowadays, and finding people that actually want to be trained in it is not that easy. Plus you dont just need programmers, but z/OS engineers, DB2 DBAs, MQ specialists, etc. And that's before you even start talking about the nice cheque you're writing for IBM every month. It does add up.
Also, I've yet to see such businesses opt for the safest porting approach. Build a transaction replication system, then a component of the ported system. Inbound transactions are replicated and dispatched to the legacy and the component of the ported system simultaneously. Build scaffolding to monitor key transaction metrics. Compare output and performance results. Let that "bake" for a year or two. Rinse and repeat with the next component (many such ported components can be developed in parallel, etc.), and so on, until the ported system reaches feature parity with the legacy system, then let the completed version "burn in" for 2-3 of the longest periodic process lifecycles. For example, if the the longest periodic process the application supports is once every 7 years, then you burn in for up to 21 years, comparing during the entire duration.
By the time you "throw the switch" to the ported system, you have a very high certainty that it will work just as well if not better than the legacy system. Extremely low-risk, but extremely expensive, and considered extremely impractical. And with how business-critical some of these systems are, pretty much any risk mitigation short of this will get nixed by senior management.
This doesn't even begin to get into other factors, like changing regulatory and business environment as you are porting (so you're porting and modifying for new requirements simultaneously), such a project can easily be targeted for the cutting block for just the cost savings to make someone in Finance look good, internal political issues, developer churn over such a long period, developers on the legacy system withholding key implementation or even business requirements information, that information simply not being available, binary-only parts of legacy, etc.