Live data from Hacker News

IBM COBOL for Linux on x86

www-01.ibm.com

51–60 of 112 posts

Re: IBM COBOL for Linux on x86

#51
post #7

Earlier quoted context omitted.

Well, I worked with COBOL developer team in Canadian bank a few years ago. It is absolutely alive and well in this industry.

According to my father it is alive and well in Canadian insurance as well. But he said where he worked they don't change the COBOL code much anymore, they add features by adding layers in other languages around the COBOL core.

In th Culture books by the late much lamented Iain M. Banks, one of the oldest drones began life as a house minicomputer that over time accreted many programs and uncountable layers of software, achieved sentience by the time the Culture came about some 9,000 years later.

Re: IBM COBOL for Linux on x86

#52

One of the VAX computers I rescued from disposal at the height of the Y2K impending apocolypse came with licenses (PAKs for those in the know) for DEC COBOL, DEC RDBMS, and DEC FORMS. These three applications formed the backbone of payroll processing for the company that was tossing the VAX. This machine, processed the payroll for a bit over 5,000 employees on a "clustered" machine that had a combined total of 512MB…

Can't you get all this stuff with a hobbiest license and a full media kit?

Doesn't macro32 on alpha or itanium run old VAX binaries transparently? Why keep the antiques? Even SimH seems a better option (assuming the licenses work).

http://www.openvmshobbyist.com/news.php

Re: IBM COBOL for Linux on x86

#54
post #46

Earlier quoted context omitted.

> Everyone with unmaintainable COBOL has long since migrated to really bad Java code instead. I can assure you that’s not correct, as I work in an enterprise that has plenty of unmaintainable COBOL still running, though they’ve supplemented it with lots of really bad .NET code more recently.

I too have seen lots of badly written .NET code out in the wild. However, as with most languages, that is more a measure of the quality of the developer, than the quality of the language. As a C++ developer now writing C# using .NET that new language and framework are a pleasure to work with.

> However, as with most languages, that is more a measure of the quality of the developer, than the quality of the language.

No, it’s more a measure of the quality of the development organization and process. The quality of individual developers is a factor here, but not the only one and often not the limiting one on software quality (and particularly often not on, e g., whether or not business requirements and system design are documented in a useful way to support maintenance and change analysis.)

There are lots of fairly common institutional factors at the kinds of shops that also tend to have lots of COBOL legacy code still running which also tend to result in instant-legacy code independent of platforms. They also have common in institutional patterns that tend to have platforms like Java and .NET.

This is not an indictment of Java or .NET as platforms, or of the individual developers in those environments.

Re: IBM COBOL for Linux on x86

#55

One of the VAX computers I rescued from disposal at the height of the Y2K impending apocolypse came with licenses (PAKs for those in the know) for DEC COBOL, DEC RDBMS, and DEC FORMS. These three applications formed the backbone of payroll processing for the company that was tossing the VAX. This machine, processed the payroll for a bit over 5,000 employees on a "clustered" machine that had a combined total of 512MB…

>"Unicode support is nice, and the fact that once you've compiled your application to binary it doesn't have to go over the Internet to load key parts is super nice."

Which is what I or anybody else who wants to have now anyways. I do not recall my applications "loading their key parts" from various places. Everything is local and native yet connected when needed.

Re: IBM COBOL for Linux on x86

#56
post #13

> supports one of the following operating systems Redhat and Ubuntu. Is that a common thing for software to be marked as "available for Linux" but only supported for 2 flavours? I guess it's fair, a debian and rhel base would cover "most" use cases.

Yes, there is an expectation that if there's an OS issue there's an enterprise support organization the application developer can work with.

I'm actually surprised to see Ubuntu. It's typically just RHEL and SLES with Oracle Linux occasionally thrown in.

Re: IBM COBOL for Linux on x86

#57
post #13

> supports one of the following operating systems Redhat and Ubuntu. Is that a common thing for software to be marked as "available for Linux" but only supported for 2 flavours? I guess it's fair, a debian and rhel base would cover "most" use cases.

[deleted]

Re: IBM COBOL for Linux on x86

#58
post #13

> supports one of the following operating systems Redhat and Ubuntu. Is that a common thing for software to be marked as "available for Linux" but only supported for 2 flavours? I guess it's fair, a debian and rhel base would cover "most" use cases.

If IBM had a clue the first flavor on their list would be Amazon Linux.

(yes, I know it's a RHEL derivative, but I also know some large fraction of 'developers' are oblivious to these matters, which is why no one hesitated to list 'CentOS' when that still made sense.)

Re: IBM COBOL for Linux on x86

#59

COBOL will always have a soft spot in my heart as the first programming language I learned. I did not use it much - 2 years max - but when reading COBOL it was really clear that there were some programmers who just saw code differently - in an abstract, artistic sense. It was the ultimate litmus test. COBOL is really easy to write spaghetti code with - perhaps even the default. But some of these programmers (not incl…

I worked on the IBM COBOL compiler in a past life. It's not LLVM based; the optimizer and code generator are derived from J9, the IBM JVM. I would be a bit surprised if they open-sourced it; OpenJ9 is open-sourced, but the COBOL compiler for Z is one of those rare compilers that is still being sold to paying customers.

Did I work with you!? I also worked on the COBOL backend for TR. And yeah, I'd also be HIGHLY surprised if it ever got open-sourced.

Re: IBM COBOL for Linux on x86

#60
This is pretty clearly targeted at rehosting CICS applications on Linux. No one will move batch processing without JCL support, does anyone know if they offer that for Linux? Also this appears to be commercially licensed only, so no way to download and play with it that I saw?
Post reply on HN