91–100 of 118 posts
>>Get those punch cards back out! I get that's (probably!) a joke, but it misrepresents COBOL as something completely stuck in the 70s. And, y'know, it isn't exactly the fanciest language in the world, but we still have several programmers on our project and they're spitting out new code every day of their life, no punchcards:). (And it's not on a mainframe either - it's running primarily on AIX, with some of Windows…
"Compliance-wise, it passed 97% of COBOL 85 conformance tests, a success rate not yet achieved by proprietary vendors, Sobisch boasted." Thinking about that if you step back is amazing, to think a standard written in 1985 (I was doing COBOL back then into the 90s) has yet, even today not had any of the big names/players meet full compliance nearly 40 years later. I'd love to read more about that aspect
It appears everyone only strives with good enough, fine tunes with bug reports for lesser known features and that is about it.
Earlier quoted context omitted.
We actually rely upon two different operating environments for COBOL that do not originate from IBM. The first is OS2200. Our final major application on this platform was complete by 1970, and links COBOL into assembler that accesses the hierarchical DMS database. The first SMP port of UNIX was to this hardware: https://en.m.wikipedia.org/wiki/OS_2200 The second is VMS, specifically the VAX variety. VMS bundled a COB…
Is your org considering transitioning to OpenVMS on x86?
Earlier quoted context omitted.
not the COBOL language, but the IBM mainframes have five nines of availability, duplication of every component, how swappable everything from power supplies to CPU and RAM. Can get to more than five nines if used parallel sysplex, but the big iron is incredibly reliable. This is the reason why all banks, airlines, and other old-school businesses have been running mainframes and cannot ever migrate off of them. this s…
And yet my bank very regularly goes down for (scheduled) technical maintenance. Most mom-and-pop stores running Wordpress on shared PHP hosting are more reliable than that.
Earlier quoted context omitted.
We actually rely upon two different operating environments for COBOL that do not originate from IBM. The first is OS2200. Our final major application on this platform was complete by 1970, and links COBOL into assembler that accesses the hierarchical DMS database. The first SMP port of UNIX was to this hardware: https://en.m.wikipedia.org/wiki/OS_2200 The second is VMS, specifically the VAX variety. VMS bundled a COB…
Are you able to find COBOL programmers to hire, or is it like Rust where a lot of jobs are "know C++ and we'll train you"?
Earlier quoted context omitted.
I've spent some time working in finance, so I've actually worked with COBOL developers personally in multiple different roles. In all those cases they were maintaining legacy applications that ran on IBM mainframes. Why would a company choose to use COBOL if they weren't restricted to what ran on IBM's mainframe infrastructure? Serious question, not an attack. I get that many of these legacy applications are some of…
I understand that old programs are extremely stable, but I don't understand why they are relevant . The world changes so much, why are these programs still useful?
But I guess you can try to change that if you want.
Earlier quoted context omitted.
lol… this comment just makes me remember that how likely you are to die is determined by an estimate of what a company can get away with by an actuary.
And your comment just made me wonder if the two recent Boeing crashes actually mean the IBM hardware is even *more* reliable
Earlier quoted context omitted.
I've worked at organisations which have mainframe applications that have been running for almost 50 years. One of the funnier reasons I've heard about why these '100k lines of COBOL' programs never get rewritten is that no one really knows the full extent of what they do, and even if they do know the full extent of what they do, no one really knows the full extent of why . The business requirements that these program…
It is a 100% true anecdote at any number of businesses. It's philosophically enlightening in a way and related to an increasingly profound adage of "Purpose of the system is what it does" (which can be applied to IT and political and social and school and other systems through various lenses). There are any number of systems out there which are "self documenting" in a weirder sense that what they do is what the rules…
Working in healthcare/insurance right now and I can tell it's a very similar tangle of rules about which insurance plan covers what. The mess that's US healthcare ties up at least a trillion dollars a year in servicing its complexities. While it pays my bills, it pains me that a country can self-inflict such penalties just to not have some sort of government provided universal healthcare system.
Earlier quoted context omitted.
I understand that old programs are extremely stable, but I don't understand why they are relevant . The world changes so much, why are these programs still useful?
The world changes little-by-little, not all at once. Let's say your application (100k LoC of Cobol) handles payroll. Your government introduces some new rules about how paternity leave should be handled. You have two options, rewrite the 100K lines into Java and add the new rule, or just add the new rule in the Cobol app. The latter is cheaper, at least in the long term, so that's what you do. Now you have 101k lines…
OTOH, you now have a more complicated and, perhaps, more brittle business-critical application you need to tend to.