11–20 of 118 posts
The vast majority of COBOL in production runs on IBM mainframes in conjunction with JCL (Job Control Language). If you are looking to offload COBOL from a mainframe to a cheaper platform JCL is a must. I love that this project exists but it’s only one half of a solution to migration off of a mainframe.
I’m unfamiliar with JCL, but from a quick search it sounds like most scripts don’t use much of the language. Still, I’d bet that most of the JCL functionality is used if you look at a decent-sized collection of scripts. How much of the full JCL do you think would be necessary to reimplement in order to get, say, 30% of the existing scripts to work?
If you're lucky the database will be one of IBM's SQL databases. If you're unlucky it will be something like IMS.
>>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…
I get that many of these legacy applications are some of the most battle-tested things in existence, and do what they do very well. I've seen them in action personally. However I'm also under the impression that COBOL is just not that amazing compared with modern alternatives: It's not easy to write, or maintain, and (as far as I understand) the things that make it 'fast' have more to do with the platform than COBOL itself.
I'd love to know more about why someone would choose COBOL today, if anyone can fill me in.
>>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…
>>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…
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…
The vast majority of COBOL in production runs on IBM mainframes in conjunction with JCL (Job Control Language). If you are looking to offload COBOL from a mainframe to a cheaper platform JCL is a must. I love that this project exists but it’s only one half of a solution to migration off of a mainframe.
>>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…
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…
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 COBOL compiler, which we used to write ACMS applications.
https://en.m.wikipedia.org/wiki/OpenVMS
We continue to produce new COBOL code for both.
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…
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…
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"?
Hiring people with experience of the respective OS is more difficult.
>>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…
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…