Hacker News Reader

Comment by cwbriscoe | Hacker News Reader

Started my career doing Y2K stuff in 1998 and I still touch COBOL here and there today. I have a 10,000 line CICS program that runs every 30 seconds that I wrote in 2010. It has never failed since.

View on HN

I don't understand these "never failed" comments. Without further context, it's meaningless. If I write a python script and never change anything in its environtment or inputs, it won't fail either. That's not specific to cobol.

I imagine the backwards compatibility story of COBOL is a little better than Python's

COBOL changes very slowly, once in a decade or two. Python does not offer support of a release for more than 3 years and a half [1].

[1] https://en.wikipedia.org/wiki/History_of_Python

But a compute instance or bare metal computer that never needs a new release wont have to deal with that in python either

Its only new builds on someone else’s computer that have this modern issue

I could believe there are legacy installations happily humming away on Python 2.7 without issue.

Several years ago I briefly worked at a major telecommunications provider with services across the southern United States that ran Python 2.4 on their production provisioning servers. Worked just fine.

The difference being that the COBOL is still supported after a decade.

ActiveState still offers a supported Python 2.7 version across all major platforms for those who need it (https://www.activestate.com/products/python/python-2-7/), so that's 14 years and counting.

If enough stuff needs it, people will keep it running. Java 8 will probably be in the same boat eventually if/when Oracle finally drops support.

I am not even sure what support is needed at this point. The interpreter is what it is. You know there are no new libraries to integrate.

I guess deploying it on a newer OS which might make it challenging to install unless it is a freshly compiled build?

Patches for security issues, most notably.

If you're actually patching your python installs, that is by no means certain.

I don’t think those mainframes running COBOL are getting patched either.

They absolutely are. Modern COBOL (even 25 year old COBOL) isn't running on ancient System360/370/390s or something, it's running on modern z/OS mainframes.

Yup, Z/OS even has an AIX subsystem these days. I have had to use it for some java decryption software and to use it to do some ebcdic to ascii conversion.

They are patched up regularly. The COBOL code itself maybe not, but the runtimes?

You are correct, the OS is patched regularly but that doesn't require a recompile for the COBOL code, the OS ABI is stable and unchanging for legacy code. I have programs still running that hasn't been recompiled since 2005 (maybe earlier that is just what I noticed recently). When they upgrade hardware, they can do it per LPAR. They just shift the workloads over to other LPARS while they are upgrading another. Pretty much zero downtime.

Yep. CICS, IMS, etc. all get updates along with z/OS itself, yet I had once plugged in an user exit written and compiled before 64bit z/OS existed and it just worked.

I understand the context to be that COBOL, as a DSL for batch processing, declares its .data and .bss segments, or the equivalents on host systems, statically in the DATA DIVISION and usually doesn't dynamically allocate memory. This, coupled with CPU, memory, and I/O bandwidth reservation from a job scheduler on an exclusive hot-swappable partition on a host (z/OS aka MVS) plus USVs, redundant disks/disk ports, and networks makes "never fail" much more a consequence and primary objective of mainframe architectures where COBOL workloads are usually run.

If the python script has external dependencies… lol.

That's what I liked about developing Oracle stored procedures activated by cron jobs. Ran for 5 years, no maintenance needed.

That seems like a low barrier of expectations. I can think of several DB's that would run exactly like that.

Reply on news.ycombinator.com