The term FUD (fear, uncertainty, doubt) was created to describe IBM's tactics and IBM is doing it again
The other day we commented on COBOL at IBM and cited this slopfarm article about "Slob Thomas", which is what many insiders still call Rob Thomas or "RT" (they also make fun of how he presents himself). Yesterday someone quoted "From his linkedin post" the following: "AI has sparked a new round of conversation about COBOL, with tools emerging that claim to translate legacy code and, with it, solve the modernization challenge. It is worth being precise about what that means and what it does not."
The response was: "This framing understates the reality. The modernization challenge was never about translating COBOL syntax—it’s about risk, economics, institutional knowledge, and business logic embedded over decades. AI didn’t suddenly “spark” this conversation; enterprises have been trying automated translation, wrappers, and re-platforming since the 1990s, with mixed results at best."
Hours ago someone called what RT said "FUD", providing the following lengthy explanation:
This is typical IBM FUD (fear, uncertainty, doubt.)He does tip his hand a little bit in the last sentence. It is absolutely true that customers have been trying to re-platform since the 1990s. And they have been doing so for very good reasons. The most important reason is that the pricing model is very beneficial to IBM and very costly to the customer. The great idea of IBM pricing has always been to make IBM's revenue as high as possible while not actually driving customers to "bite the bullet" and invest heavily in re-platforming. In addition to the financial reasons, there are technical reasons to re-platform. Despite what IBM tells you, this really is a geriatric system that shares little with modern hardware and software practices. Operating this system requires personnel with bizarrely recondite knowledge. It is very difficult to entice anyone born in this century to pursue the fine buggy whip skills required for this platform when they could master modern automotive driving.
The FUD presented in the post held a certain currency for many of the years since the 1990s. One of the reasons for that is that the COBOL language itself does encourage a very inscrutable encoding of the "business logic" mentioned in the post. There are a number of reasons for this. Probably the most important reason is the famously unconstrained control flow in COBOL programs. So many "perform" and "goto" statements would, today, be function or procedure calls but the nature of these calls is often obscured to even skilled human software developers. The fifty or sixty year old concept of BCD (Binary Coded Decimal) to do simple integer arithmetic is problematic because there are so many possible bit patterns that are not legal and also not diagnosed anywhere along the way. Also, the somewhat addictive (to a COBOL programmer) EXEC THIS and EXEC THAT in a COBOL program means that a single source file actually has several programs (a COBOL program and a THIS program and a THAT program.)
Let us ignore the IBM claim that this new AI initiative is about simply "translating legacy code." Concomitant with this claim is IBM's Elysian dream that the translated code will continue to run on the platform (and attract giant revenues for IBM.) Suppose that modern AI can clarify actual control flow logic (including logic that would normally be procedure/function calls) and meaningful integer arithmetic. Also, suppose that modern AI can separate SQL logic from COBOL logic. Now we are close to actually being able to abstract out business logic, Furthermore, we can determine which programming concepts are fundamental to all programs in the enterprise and which programs might be eligible to be re-platformed one at a time.
The recent news about AI processing COBOL code doesn't at heart have all that much to do with COBOL. But it is a likely (or at least possible) path to practical re-platforming. And, apparently, even IBM recognizes that this is a threat.
Nowadays it's common to say "FUD" about Microsoft (or in relation to its tactics), but the practice seems to have been inherited from IBM, along with lots of other things including the silent layoffs. █
