7 ms·
Basically it very difficult, because no one truly no one understands the whole business logic implemented in Cobol. Take life insurance. You have contracts runn
by MichaelRazum 5y ago
Basically it very difficult, because no one truly no one understands the whole business logic implemented in Cobol. Take life insurance. You have contracts running for decades. You just don’t want to break something. There are no tests and so on. So if you would start from scratch you would be faster. So it’s just very very expensive with a lot of downside risks and little upsides.
- chasil 5y agoEven if you understand your business logic with extreme clarity, if you don't know how the math is implemented, then your migration will fail. Too many people learn this specific COBOL fact the hard way. https://medium.com/the-technical-archaeologist/is-cobol-holding-you-hostage-with-math-5498c0eb428b https://medium.com/the-technical-archaeologist/is-cobol-hold...
- mrjin 5y agoOh well, isn't understanding how data types represented one of the first a few thing to begin with a programming language?
- lokedhs 5y agoExcept in COBOL, data types are decimal, which means that whatever datatypes you choose to use in a modern language will not work the same as they do in COBOL. Also consider that the COBOL datatypes are directly represented in the underlying storage, so whatever format you decide to represent a value in in the code is the same format that will be used for external communication. If you want to retain compatibility with COBOL, you're probably going to need a COBOL-compatible numeric library in whatever language you're using. at least if you want to just reimplement the original code.
- chasil 5y agoWhat this article is trying to tell you is that COBOL uses fixed-point arithmetic, often BCD. It was standardized two decades before ieee-754, that we now take for granted. The math is wildly different.