Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
It occasionally happens, but what this is more likely to do is facilitate moving legacy COBOL code off of a more expensive platform. IE, we have a ton of AS400 applications written in COBOL. The people that wrote them are long gone (some are long dead). We have current COBOL programmers but a lot of aspects of those old programs are basically mysteries. They work, and when it works you try not to mess with it.
Being able to move the code over to a Linux x86 box though would potentially save the org a ton
We have current COBOL programmers but a lot of aspects of those old programs are basically mysteries.
When I read stuff like this I have assume its because nobody is really trying very hard if that is the case. COBOL makes it hard to do anything mysterious for the most part; with the exception of business rules themselves.
I then have to ask how come nobody knows those business rules. Sadly I have walked into lots of orgs where things like their quoting tools are filled with logic nobody understands. "We charge this much because the tool says so" At that point the problem isnt that you are still on COBOL or VB5 or whateber its your business people don't even understand their own models - That is a problem of grossly incompetent management and no computer magic will solve it.
It is called 'reality'. Things change, sometimes very quickly, and nobody knows the future. How many systems do you suppose had changes quickly added because of the pandemic? Even if they were all properly documented, how would that help? Say 10 years go past, and someone is looking at the code. There is all this 'emergency economic shutdown' stuff in there. If you were to ask someone what the current business logic is, would they include that? Probably not, but it is there. So what do you do with i
Answer - YES you rip it out because if you don't know what it does exactly how would you decide if its appropriate to use it the 'next time'?
You can't reverse engineer and understand what its doing now in relative calm but you are going to do that during some future crisis?
Competent management might not know how a software system implements the business plan but they should know what the plan is. Someone should have the rules captured some place, if for no other reason than if they don't they have no way t
It may not be possible to remove old rules. Sometimes, data from the past gets corrected and things need to be recomputed on the basis of the rules in place at the time.
A COBOL program peppered with a few unstructured GO TOs can be marvelously mysterious, especially when written either in haste or with a job security bias. Then there are those who profit purposefully making it more mysterious still:https://www.redversconsulting.com/cloaking_device.php [redversconsulting.com]
On the other hand a well written COBOL program should be straightforward easy to maintain, and that isn't necessarily true for other languages.
In the realm of scientific observation, luck is granted only to those who are
prepared.
- Louis Pasteur
Finally the wait is over! (Score:1)
I waited for decades, decades to finally be able to work with COBOL on Raspberry Pi ... oh wait.
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
Re: (Score:2)
Seriously in the current market why would anyone half decent at coding would start working on COBOL projects?
It occasionally happens, but what this is more likely to do is facilitate moving legacy COBOL code off of a more expensive platform. IE, we have a ton of AS400 applications written in COBOL. The people that wrote them are long gone (some are long dead). We have current COBOL programmers but a lot of aspects of those old programs are basically mysteries. They work, and when it works you try not to mess with it.
Being able to move the code over to a Linux x86 box though would potentially save the org a ton
Re:Finally the wait is over! (Score:3)
We have current COBOL programmers but a lot of aspects of those old programs are basically mysteries.
When I read stuff like this I have assume its because nobody is really trying very hard if that is the case. COBOL makes it hard to do anything mysterious for the most part; with the exception of business rules themselves.
I then have to ask how come nobody knows those business rules. Sadly I have walked into lots of orgs where things like their quoting tools are filled with logic nobody understands. "We charge this much because the tool says so" At that point the problem isnt that you are still on COBOL or VB5 or whateber its your business people don't even understand their own models - That is a problem of grossly incompetent management and no computer magic will solve it.
Re: (Score:2)
It is called 'reality'. Things change, sometimes very quickly, and nobody knows the future. How many systems do you suppose had changes quickly added because of the pandemic? Even if they were all properly documented, how would that help? Say 10 years go past, and someone is looking at the code. There is all this 'emergency economic shutdown' stuff in there. If you were to ask someone what the current business logic is, would they include that? Probably not, but it is there. So what do you do with i
Re: (Score:2)
Answer - YES you rip it out because if you don't know what it does exactly how would you decide if its appropriate to use it the 'next time'?
You can't reverse engineer and understand what its doing now in relative calm but you are going to do that during some future crisis?
Competent management might not know how a software system implements the business plan but they should know what the plan is. Someone should have the rules captured some place, if for no other reason than if they don't they have no way t
Re: (Score:1)
It may not be possible to remove old rules. Sometimes, data from the past gets corrected and things need to be recomputed on the basis of the rules in place at the time.
Re: (Score:2)