The World Depends on 60-Year-Old Code No One Knows Anymore
ฝัง
- เผยแพร่เมื่อ 3 ก.ค. 2024
- (Or hardly anyone knows)
Believe it or not, a 60-year-old programming
language, COBOL, still powers major systems like banking and insurance. To be honest, it’s pretty bada**
#softwarengineering #developers #coding
Timeline
00:00 Introduction
00:24 How COBOL came about
02:25 What made COBOL good?
03:28 and COBOL is still ALIVE today
04:35 how has COBOL survived?
06:37 Who actually works on COBOL now?
08:26 So what next for COBOL? - วิทยาศาสตร์และเทคโนโลยี
![อาจารย์ยอด : พระเตะผี [ผี]](http://i.ytimg.com/vi/zusDOIFasaE/mqdefault.jpg)
I can program Cobol, but never put it on my resume, because they might make me program Cobol
So how does one get experience working on mainframes and COBOL?
is it that bad??
I hear you! I did a lot FORTRAN along the way, and managers made fun of it when I put that on my resume.
the main problem with working in COBOL is the working environment. Banks are not known for a casual work environment. There seems to be an entire ecosystem of programmers in that sector that mostly don't interact with the rest of us. I bump into it once in a while but it's like a entirely different programming world
@@myhandlehasbeenmishandled I've been told that's after a full internship in Hellco ULC.
I can still program COBOL. Stop making me feel old.
I’m the same… and I’m not even 50!
That makes two of us. Though I am old.
Me to
Sounds like you can earn a lot of money then.
Me too
I was a Cobol programmer once - not by choice though but a colleague resigned and made the big mistake of mentioning that I knew it on my CV and my boss remembered that.
It is not the language really but IBM mainframes that makes it live so long - IBM developed several families of mainframes starting with the S/360 family and they all are compatible with each other.
From custom CPUs to PowerPC's of the Z series today can in emulation mode and boot the OS and programs written in the 1960's.
The US tax system is written in a combination of IBM mainframe assembler and for Cobol running on a mainframe from 1960.
Today they still doing your tax returns using it on a modern IBM mainframe but the same code.
The same code, another more powerful machine. The most effecient way to upgrade. In the industrial environment the cpu’s inside also the small contollers are all the time ‘old-fasioned’ due stability and minor bugs inside.
I mean if it works, it works. Not everything has to be rewritten in rust
@@moonasha Rust, some great ideas, but makes me want to gouge out my own eyes.
@@johnridout6540 👍👍Same!
As people say, "If it's not broken, don't fix it" or something like that (there are minor variations out there)
I’m 66 and a retired COBOL programmer. AI should be able to update it now except for COBOL spaghetti code with non-standard magnetic tape processing and hidden calls to special routines. Yes it’s still there unchanged and untouched for 50 years. It sits there waiting to trap some naive AI or person attempting to update it.
AI, you said? Don't give us nasty ideas here, such as telling ChatGPT or some other AI chat bot to make a simple COBOL "Hello world!" program! 😂
Ai couldn't even help me write a simple component test in JavaScript, I doubt it can rewrite entire software
it's still hard for AI to create a program of a memory game without spitting errors every 2 lines
I`m not a programmer, but I imagine such an undertaking would be like opening a compressed can of worms...
LLMs will never be able to write effective programs for the simple reason that it is incapable of reasoning about the "code" -- tokens, really -- that it spits out. It is doing a statistical inference on a copus of code already written by human beings.
Think about that for a moment. There is no dynamic reasoning in statistics. None.
I am always amazed that anyone expects LLMs to do better. They are good for a very limited domain of things. But anything truly creative and constrained by logic and reason? No.
*Grace Hopper* developed the first compiler A-0 in 1952 and the first human readable computer language FLOW-MATIC in 1955. She is also referred to as "Grandma COBOL". Grace Hopper is my all time programming hero ♥️
Also known as "Amazing Grace".
Ah, the amazing grace
I watched one of her live lectures while I was serving in the Navy back in the '70s and '80s. Also, Adm. Hopper was one of the few people who would standup to Adm. Rickover. She wouldn't take any of his shit. 😆 Very interesting person. The quickest way to get on her bad side was to say, "That's the way we've always done it."
That person (Hopper) is my hero as well and I don’t much like her to be depicted as.. Mary….
She was fantastic, but the first compiler was not A-0. There is a discussion of the priority of her presentation, or if Autocode was running before she published. In any case outside of USA and political guide discussion A-0 is not considered the first actual implementation of a Compiler. This does not make her less important, after all, Lorentz found the transformations that bear his name before Einstein did, and I have zero evidence that Hopper had any idea of Autocode, in fact we know she published first.
I have been coding in COBOL for 42 years - still going. And I can code in IBM Assembler.
What is your educational background or training that got you that job? Are you like an engineer?
The amazing part of the COBOL is the number of years. If by IBM assembler you mean Mainframes that is spectacular in it's own right.
Have been coding since 1969 all on IBM equipment. I programmed 407 accounting machines (plugboard wiring) then 1401, 360, 370, 4300 series, 3090, s/390, series-1
Wrote for BPS, TOS, DOS (and its variants such as VS VSE, VSE/SP, etc) V/M, OS (and its variants MVS, MVS/XA, etc)
Been writing in assembly since 1970. Converted COBOL code from DOS to MVS. Even recreated COBOL code from core dumps because the original COBOL source was lost.
I am sorry for people that never experienced hands-on with a mainframe. Its is truly an experience. I can do things in 16k of memory that NO other language can do. I wrote a COMPLETE accounting system (A/P, A/R, G/L, PAYROLL, INVOICING) in 32k (including the operating system)
I even got COBOL to dynamically call another COBOL program. Something IBM said was impossible. As of 2012 that interface that i wrote in in 1981 was still running!
To me, there is IBM mainframe then the rest of the other machines
Nobody has mentioned FORTRAN, although that was more the realm of science folks ... and what about FORTH, who remembers that one?
Bei mir genau dasselbe. Ich kernte ab 1981 in der Berufsausbildung an einer IBM3033 unter OS/VS 2 COBOL und Assembler und hatte seither praktisch mit keiner anderen Programmiersprache zu tun.@@jaimeduncan6167
Bei mir genau dasselbe. Ich lernte ab 1981 in der Berufsausbildung an einer IBM3033 unter OS/VS 2 COBOL und Assembler und hatte seither praktisch mit keiner anderen Programmiersprache zu tun.
Exactly the same for me. I learnt COBOL and Assembler Language on an IBM3033 under OS/VS 2 during my vocational training in 1981 and have had practically no contact with any other programming language since then.
Normally any discussion of COBOL mentions Grace Hopper, one of the inventors of the language. There is anecdotal evidence she was also involved with the use of the term "bug" and "debugging". I learned COBOL in 1980 and used it for most of my career.
The term 'bug' was already used in engineering, even Edison used it. Her instance is the first _actual_ living bug that caused an error, and that's why she wrote that journal note. IIRC that journal page is still being preserved.
@@timradde4328 It was a moth, as I recall from what I've read. I wouldn't be surprised if the story has been distorted and different versions can be found in the literature.
It was a moth. Computer memory at the time consisted of a grid of wires with a donut shaped magnet at each intersection. The polarity of the magnet could be reversed so that the bit could be flipped on or off. A moth flew into this wire grid and shorted out a section of it causing a "memory fault."
@@DrunkenUFOPilot Actually, Hopper's meticulously-kept notebook has a page with the actual moth that documents the event. The notebook is in the Smithsonian, so no embellishment.
Actually, that’s also a bit of a myth. Rear Adm. Hopper did not invent COBOL. She was for a brief time on the CODASYL committee, but really not for very long. Some of the syntax of COBOL is based on Flowmatic which she did design.
COBOL was “old” when I was in college. The biggest issue with cobol systems is how a set of programs will share files. So knowing the language is only the first step. Understanding the dependencies and interactions is the bulk of the problem.
Could you please elaborate through a rudimentary example?
Yeah, I was going to say, I've seen textbooks on it in public libraries. It doesn't really look that hard to learn. Like I could probably learn it in a few weeks.
@@xenopholis47 some people I worked with spent over a year trying to reverse engineer 200 cobol programs used for credit card settlements. There were so Marty reading and wtiting to the same files under different circumstances that they were never sure they got all the interactions.
@@michaellatta yes exactly - VSAM / seq datasets, and not just the COBOL but also JCL (& what disposition each job has the files open under), and anything else the JCL is doing to the data outside COBOL.. (and that's just batch :)
@@johnlacey155there are different operating systems hence different JCL
Also, in 1959 the department of defense probably owned 99% of all the computers in the world. So if they didn’t do it, nobody would.
Wellllllll not quite 99%... remember, the IRS was also using it (and that was true for most of the Western world). But sure, they would have owned the overwhelming majority of all computers.
Maybe 99% of computers in the USA - the UK government and banks had plenty too, even Universities had them by then.
Also, the DoD has huge administrative functions, between payroll, facility maintenance, etc. The lifeblood of the DoD is money.
COBOL is clear and straight-forward. The staying power of the code is mostly due to inertia. It epitomizes the maxim "if it ain't broke, don't fix it".
Isn't it slower than molasses though?
@@SahilP2648 that's why you run it on superfast mainframes 😀
Also: "if it _is_ broken, nobody knows how to fix it, so, it's better not to touch it" (the very definition of programmer's inertia).
@@GwynethLlewelyn or you can just decide to use a better language and convert all the code. Generative AI would be able to help a lot in this.
@@SahilP2648 well, yes, you can do that - if you have a few hundreds of lines of code. But these COBOL behemoths that run banks and insurance companies and whatnot have _millions_ of lines of code. Let's assume that you'd get a generative AI to convert all the code. Would you, as the bank's CIO, trust that brand-new, AI-generated code to replace the old & faithful _mostly_ working code which has been around for half a century - and risk dooming the bank to absolute collapse if nothing works?
Also, who would test & evaluate that code? Other generative AIs? :) You see where the problem is: at some point, you'll have to trust AI providers with your entire business logic, and hope they come up with a "better" solution (in the sense of using brand-new, latest-generation programming languages with extra bells and whistles)
Someone on this very long comment thread pointed out the obvious: you could, for instance, split the code in its modules (all hundreds of thousands of them!), and go through each one of them separately: get a module, convert it to some other modern language using generative AI, thoroughly test the result, deploy it, then move on to the next module - wash, rinse, repeat, until every single line of code has been fully converted. But that's essentially "rewriting the whole code from scratch" without the _main_ advantage that comes from actually rewriting the code, which is to rethink some of the old things that aren't probably not necessary or that can be done more efficiently thanks to contemporary technology, methodologies, and innovations.
How long would _that_ take?
How much would it _cost_? (even assuming a "free" generative AI which would not only convert the code but also provide test suites at each step, for each module, also for free)
And if something goes wrong in that million-line-code-conversion... something which escaped even the best of the best generative AIs and error-checking AIs... who is going to be able to "fix" things?
Generative AIs are not yet the magic wand that turns a multi-million-dollar, high-risk project into something that can be done next-to-free and take a few hours...
"If it is not broken don't fix" is the rule.
just replace it
@@tms2566 🤣
@@tms2566There's WAY too much of it to replace all in one go.
The problem is that the law changes, accounting requirements change, new payment systems are needed, new features are needed, on some level it's ALWAYS broken against current requirements.
@@dlbiggins COBOL code is regularly updated to match new regulation, the language itself has also had several new specs since the 50s, the latest one being from 2023.
75, Unisys Cobol programmer for 30 years (with IBM before hand) and still working with it. I have learned C# and Python, which can do things COBOL cannot. But COBOL is easy and reliable.
I got back into programming with the run-up to Y2K, working in two shops making the conversions. We made a lot of money making program conversions but _I expect to really clean up when _*_Y3K_*_ comes around._
and really rake in the cash when we approach Y10K
y2k38 is an actual thing that will happen, better get started
@@meep.472 mostly embedded systems require to be updated hardware wise to support 64-bit memory. Like your router for example. Otherwise, any modern-day PC is going to be fine (way before 2038).
You mean 2048? 2^11? How could this possibly be an issue at this point?
@@keith77mn77 lmao no. All devices use a standard called Unix time which started in 1970 as an integer value increasing once every second. This is a 32 bit value which is set to overflow in 2038, so if any device uses unix time and is not updated to 64 bit by that point it's gonna think it's 1970 again and that can create a lot of issues.
An important point is that Cobol uses decimal fixed point arithmetic while all popular languages use binary floating point numbers. Financial people get really upset when the cents don't match exactly what they expect.
The joys of binary coded decimal on the SNAP (program and memory) dumps as well.
Double doesn't have the floating-point precision issue when dealing with math functions afaik
not even quad (128 bit) binary floating point will give you the same results as decimal math. Note that in both cases the results are wrong, just wrong in different ways. The financial industry likes to be wrong in the same way as their old decimal calculators. A few years back the C standard added an option for decimal floating point and several different processors are adding them as well.
Idk, in Russia we had not banks before 1991. We have the biggest fully online bank in the world and it was found only in 2006. So, we are lucky to kot have any COBOL code for banks. And somehow we haven't problems with incorrect counting of our cents.
I don't think that is the real point.
@@paulinchannel3104 I mean Russians are smart. There's a way to remove the floating point errors by doing more operations per transaction, so they most likely must have done that.
I'm not from IT but worked at a bank with product management. It's true that the codebase is mostly a black box for most of the employees, and they need to be extra careful with systems updates because any change could stop other processes that relied on it. There's no documentation, and developers most familiar with particular systems are the ones who worked on it longer. It's even weirder that development is outsourced. I assume that the company holding all the knowledge about the systems can name their price. There are stories like the one developer that knew a system left for another job, and was begged to come for a visit from time to time to help fix something.
But on the other hand, a few years ago the accounting system was rebuilt from scratch in SAP. It took 5 years until it was completely switched and the first few months were absolute chaos. A few millions in unreconciled entries were just forgotten about, probably because they just gave up trying to figure them out.
Rewriting an old system might just be too complex, and companies will only do it, if think, if not doing so gets them in legal trouble.
From Cobol to SAP, Wow. Talking about from the frying pan into the fire. It takes about 5 years to write Hello world in SAP, so no surprise there.
But don't go for Python or JavaScript for large critical systems. You can't create quality with testing, you can only improve existing quality with testing. Stick to proven languages with type safety and memory safety like C#, Java or Rust nowadays. (I know, SAP uses Java, that's not the point)
@@mennovanlavieren3885 SAP looks complicated to develop for. But they nailed the corporate pitch (governance, compliance yada yada).
Imagine what you could buy with $800,000 in 1959
Approx 115 houses in the burbs at 7k each 👀😢
COBOL is really easy to understand. Nobody wants to learn it only because it is so damn boring. But I am sure with enough financial incentive many people will make an exception and learn it to make bank.
Standard COBOL is easy, old COBOL from 1970’s and earlier can be a dystopian nightmare.
@@raybod1775 not really.
It's boring because it is only for... business. Not exciting for most young programmers who prefer the latest hype and I don't blame them.
@@raybod1775so the problem is not cobol but the spaguetti legacy code. PHP, java or python can be a monstruocity in wrong hands...
@@raybod1775Das gilt für COBOL vor 1968 und undisziplinierte Programmierer. Es ist auf jeden Fall ein gut handhabbares und wirklich mächtiges Werkzeug im Zusammenhang mit Massendaten.
This applies to COBOL before 1968 and undisciplined programmers. In any case, it is an easy-to-use and really powerful tool in connection with mass data.
Grandma COBOL is a legend. And her first documentation of a computer bug.
This is not quite true - it was a common term by the time she discovered that "bug" - the joke was that the bug was caused by an actual bug. Not that the term bug was derived from this occurrence.
@@zoeherriot Thomas Edison also found a 'bug' -- a squashed insect in a telephone relay which prevented it from working properly. He wasn't the person who invented the first debugging hardware, however -- that would go to whomever invented the first insect screen. That said, we all remember Adm. Hopper's bug.
@@zoeherriotQuite correct, we know that it was a common term because of how she described it: "First actual case of bug being found."
It was the first actual case of a computer bug (error) being caused by a literal bug (insect).
Why would she write that unless errors were already called bugs?
Also heard the Turing machine, Colossus, crashed when a moth shorted out two valves, another anecdotal/legendary beginnings on the term "bug" - that was the 40s before the USA had even built a programmable electronic computer.
@@wolf5370 I've heard that, not sure how apocryphal it is.
Btw, probably want to avoid calling anything "the turing machine", as "Turing Machine" is a specific important concept in computer science.
One of the biggest benefits of using COBOL is that it does EXACT decimal arithmetic (i.e., not floating point double precision) , which is a huge advantage in financial systems. You can write highly structured code that is really easy to read - almost self documenting. But it's not at all suitable for web development, which is a huge disbenefit for most developers.
Floats should never be used for financial calculations. If necessary, should a language not provide fixed decimal arithmetic types, a whole number type can be utilised instead. Though a little extra work would be needed to display the correct values.
@@stewartkingsley Floats can be used, but not binary floats. Binary floats can't even represent 10 cents properly. IBM Machines of the Power and Z series have had 128 bit decimal floating point hardware for more than 16 years!!!. The precision is more than enough for any practical use.
One drawback to that is you need to make sure that the PIC allows for enough digits. If, for example, you are expecting a number that is 10,000 or more and you have a PIC 9(4) then your variable will roll over unexpectedly. I have accidentally created some infinite loops that way (and wasted a whole box of green bar paper...)
@@myofficegoes65 Yeah I had days like that in my early career 🤣🤣
The insurance company I used to work for relied on COBOL for the backend to its web based customer and employee facing portal. COBOL also handled all the batch processing of creating documents and renewals.
I just passed my COBOL uni exam today
Congratulations, I got COBOL at uni because of the Y2K (yes I am that old) I hated it but it was pretty easy. If you go into mainframes the cool part is going to be the toolset.
If python is supposed to be the alternative ... well, I guess COBOL will stay here for a while longer then
Every newly popular language has been slated to replace COBOL: VB, Java, etc. The problem (or better said the advantage) is that the current COBOL programs are very stable and it's hard to take a risk on something new when what you have works fine. For batch processes (which are used extensively in bank transactions and the clearing of stocks/bond transactions), it's hard to find a language that performs better than COBOL and is still comprehensible. I wouldn't write a website in it, but for what it does well, I wouldn't replace it.
@@alexaneals8194 The amount of security issue that we'll have if it's on Python is gonna fun x)
Perplexed also forget that cobol standard is still being updated. As a result, it is easier to bring features that prove to be useful to cobol than rewriting everything to a different language just because it supports a new paradigm (the same thing applies to c, c++, Ada or whatever language that supposedly will be replaced)
🤣
COBOL was the primary language of my college days. I spent a number of years working in it, even on desktop applications. Of course no discussion about COBOL is complete without mention of its mother, Admiral Grace Hopper. A true giant in history.
At 3:19, your Python does not match the COBOL. You don't print the first_number before adding to it.
🤣
Didn’t take long to find the COBOL programmer 🫡🫡🫡
@@codingwithdee Another one here. No need to worry, many of us can PERFORM SAVE_THE_WORD when needed.
It would have been more informative to translate and compare trivial Cobol code doing exact decimal arithmetic into Python. 🙂
Can someone explain this to me? The statements seem to be in the same order. Is there a difference in what "ADD 20 TO FIRST-NUMBER" followed by "DISPLAY FIRST-NUMBER" does in Cobol vs. the Python += and then print()?
@@The_1ntern3t The output in COBOL:
Here is the first Number
8
Let's add 20 to that number.
28
Create a second variable
30
The result is:
58
The output in Python:
here is the first number.
Let's add 20 to that number.
28
create a second number.
30
the result is: 58
Most companies I work with are still developing COBOL today. Many of the mainframe systems have developed to support newer technologies, like Web Services, using regular COBOL. The code is compiled so well it is hard to compete with it on the mainframe where every MIP counts. Also these companies have the same code that was written decades ago and it still runs today without a recompile. Third party libraries for COBOL are nearly inexistent. Those trying to change to Java and use third party libraries usually have to recompile once in awhile to allow a newer version of the framework with bug and security fixes. To me that is the wrong direction and the throughput is hard to beat on the mainframe.
Correct, my company has lots of COBOL programmers still and it's far from "old" code. We're running on the newest zOS, current mainframes, most recent version of DB2, etc. We have web interfaces, APIs and everything you'd expect from a current application. While most of our new applications are Java now we're still writing some new COBOL applications for the stuff that absolutely can not ever go down.
As a retired mainframe programmer the server world seemed pretty unorganized and hard to maintain. Lots of folks chasing issues that were just handled by centralized operators.
I'm 54 and have been a Java dev ever since Java came around. I also to have some OS390 experience from my early days (PL/1, JCL). I do wonder sometimes if I should learn COBOL so I can spend the rest of my career maintaining old, boring (but important) COBOL programs... possibly getting a better pay than now, and having a less stressful job than now - and not having to chase every new tech trend every few months anymore - which does get harder when you get older.
I was thinking this too :) Am I too old to change? LOL
you probably should! If you are even asking this question, the way you did, then yes you should! Much respect to you!
Until they decide to do tech refresh
@@Krisdomain "They" would have replaced their decades old COBOL stuff a long time ago if they could. There are reasons this code is still running.
@@bellissimo4520 agreed, even large banks don't have that much spare change, let alone technical capability
You can’t really compare COBOL with “modern” languages like Python, C, etc. COBOL was made for transaction processing in an age where users had forms-based terminals and the typical mainframe had hundreds and even thousands of terminals. COBOL may be old but for transaction processing tasks, it’s still the most appropriate.
If my memory still serve me well, COBOL is the first language that have native currency data type. Back then others language (Fortran) was for scientific. Floating point can't cut it when it come to money.
This takes me back! This was one of the first languages I had to learn! Since I never worked in a financial institution, the language faded away in my memory! COBOL is still used today and follows the old adage, "If it ain't broke, don't fix it!" I heard a few years ago, that COBOL Programmers could earn excellent wages for their knowledge of the language since, there are so few out there.
Hurrah for COBOL!! I was a COBOL programmer for years 😀
me too, but now I am a python programmer 🙂
I am retired now but dealt with COBOL for over 40 years along with other languages. If you have good logical thinking COBOL can be your best friend. Even now IBM COBOL can be object-oriented, if that is what you desire. I found structured COBOL programming more to my liking.
We're not all dead yet. Just because COBOL is old, and those of us who know it are perhaps older; We are still among you. As an aside, I wrote the algorithms that secure your banking pins on the smartcard in C. So those will last a bit longer.
COBOL is still the language of choice for business and financial software on an IBM host.
Analyse dumps after an abnormal end (ABEND) and you can resume where processing stopped last time (with some JCL script adaptaion).
Essentials of COBOL are easy to learn. I once taught two newbies the basics in 4 weeks and could focus on designing that automated test algorithm for database access routines, the newbies programmed it.
On another occasion I was forced to do complex backtracking AI in COBOL 74 so it could run on an AS400. Granted, I would have preferred C++ but it worked in COBOL 74, too, with vast arrays.
Fun fact, modern COBOL has been a hybrid object-oriented language for decades now but nobody uses it that way.
Heck, even local variables in sections (sub routines to normies) is not used in most cases. Why, I don't know.
I know someone who has been coding cobol the last 40 years. Finding a job has never been an issue, especially now so much legacy code written in cobol.
One thing missed in this discussion is that COBOL is designed for business. Other programming languages are designed for science. The difference is that in COBOL, if you want something like up to 1000 dollars, in COBOL you declare it as "PICTURE 999.99". There you go. You want to print a number with commas and three decimal points and a dollar sign? "PICTURE $999,999,999.999"
Look at "DECIMAL" type in SQL servers and notice it isn't integers or floats.
Also, all the non-portable stuff in COBOL was in one section: the environment division. You ported COBOL by modifying some lines there, and you didn't have to touch the rest. It held things like "which file is the 'payroll' file" and "where do you want the compiled code stored."
And the smart programmers abstracted this to use wrapper JCL to fix up @use names to map the real file system files to the logical files defined in the COBOL program.
Nonsense. Just look at what most businesses are using. It's not lame languages like Cobol.
COBOL is not difficult to learn. It's just that it is very limited, so to achieve certain things, you need to write a lot of code. COBOL is most suitable for record processing - read some record (like a credit card transaction) from one of the many input cards, do something with it (like increase saldo here and decrease there). Once you know PERFORM UNTIL and format records, you've 50% there :)
Control breaks was one of the most enduring lessons I got from COBOL. Such a simple and useful concept that if poorly implemented can create havoc.
Fun fact: COBOL-D did not have the perform clause. It was all goto's
@@rty1955 :-)
Exactly, same goes for all "mainframe languages", they are just very feature poor, so you always need to "reinvent the wheel", there are very few libraries compared to modern languages, meaning everything becomes tedious to do.
@@youtubebob123 except Fortran. There's math libraries out there where they write a C-wrapper, instead of porting the lib itself.
It was written in the days when people were trying to make computing as simple as possible. The idea was that since it was basically a constrained form of English, even managers would be able to write their own simple queries and so on. Then people brought out things like Easytrieve for manager's reports and eventually they realised managers couldn't learn to program under any circumstances.
I can remember programming schools where they would take in anyone who passed an aptitude test and tech them COBOL in three months and guarantee them a job.
One of the great things about COBOL is the arbitrary precision of numbers, especially in decimal - you could accurately represent numbers like 18 digits and a decimal point and 10 digits ... which made things like financial calculations work so much better than trying to lever them into a LONG or a FLOAT.
Some of the new languages have retreated from the concept of easy and some of the new features of C# and Java are probably only usable by people with degrees in software engineering.
Probably not even by them (points at self)
Cobol is still used for a reason, there is nothing to match it in efficiency and speed in many important fields. And Cobol do support graphical user interfaces... Simply build a Cobol backend application with an API layer, and call it from a front-end, receive a response and present the data in any way you desire :). When you login to one of the larger banks and perform a transaction for example, several real-time Cobol modules will be running/executed on a mainframe somewhere, and data then sent and presented to you via browser/app... I work as a Cobol/Mainframe developer...
I was born in 1960 and started my IT career in 1984 as a Cobol programmer for a bank. Today I program with Python (but no longer for a bank). Can only confirm everything you said. The smartest thing I've heard about COBOL in recent years.
You really got a knack for choosing your languages, haha.
I won't touch Python even if my career depends on it, its so bad...its 10 steps back.
@@TheEVEInspiration a pity so few people agree with you. There is something mystical about Python. I have yet to understand what exactly makes it so popular. Perhaps that's the whole point, really: nobody asks and everybody just assume that there _is_ a reason for its popularity...
I believe that Konrad Zuse is credited with creating the first programmatic language (in the 1940's), and had envisaged/designed what we would now call a compiler for it. This work precedes everyone. And there were probably others, who didn't get their name up in lights. Both ALGOL and FORTRAN existed prior to COBOL, so it's not true to say that a major jump occurred between machine code/assembler and COBOL. Both of these languages were used in a business context, especially ALGOL, and many would say they were better suited even for business use. Also COMTRAN existed prior to COBOL, and there are probably other languages. COBOL was and is great, but it didn't solve the problem of getting away from assembler, it was actually a standardisation exercise. Also I would be surprised if the CODASYL group was formed on the basis of influence from any single individual. I'm not sure that ALGOL and FORTRAN were even the first 3GLs - it appears that these were the first of the widely accepted / implemented 3GLs though. One of our lecturers at uni swore on the bible that it was better to code business apps in assembler, and that it was all a matter of structuring re-usable modules/macros efficiently. I don't agree, but I understood what he was saying.
ALGOL -> Pascal -> C -> C++/Objective-C/C++/Java -> gazillions of programming languages vaguely inspired by it (JavaScript is an obvious one, Go as well, I'd add Rust to the bunch, and - allegedly, according to some obscure sources - even Python!). So... if you learn ALGOL, you learn the basics of pretty much every other general-purpose programming language available today.
If you learn FORTRAN - you've learned FORTRAN 🙂 That's pretty much "it".
Then you have LISP, also from the late 1950s, and still widely used under some of its incarnations.
And, well, COBOL, which is just... COBOL.
@@GwynethLlewelyn wow - nicely done! Yes ALGOL doesn't get the recognition it deserves, as per the lineage you've outlined. Crazy when you think about it really? I believe the ISA for Burroughs large systems, starting with the B5000, was engineered to support ALGOL compilation. And not to mention that MCP itself, the Burroughs OS, was written in ALGOL. (This is the same MCP from the Tron movies). Amazing to think these machines were so far ahead, not to mention that they looked like something from a sci-fi movie. ALGOL was big in the Data General world also (significant in their own right, and in the history of Apple), I managed to purchase a physical ALGOL manual for AOS/VS a number of years ago.
Surprisingly I met a COBOL programmer last year who was in his 30s.
Fascinating, captain. Thanks!
People tend to demonise languages, and honestly I cannot see the point. If you know enough, create your own, if not just pick the one that best suits you.
At the end of the day, it’s only a tool that we have available, and there are many other tools in the toolbox. Each one is made for a purpose, and one thing I learned is that there is no point in me bitchin at the tool or whoever made it.
Great video! its not COBOL that's difficult but the complexity of the technology surrounding it. And i think saying COBOL is close to Python is a bad idea because we all know python programmers don't want to go deep in understanding how certain things work🤣
I programmed in Cobol for 15 years. I started programing on paper tape and punch cards back in the day. Cobol is a simple language to learn and maintain, that is why its still running 60 years later.
I dont know how i got suggested this channel; but the concept of the video is so good i subscribed
When I was in college in the late 70's - early 80's COBOL was on the way out but it was still big. Everyone still took the courses on COBOL programming but even the instructors would say we likely would never program in COBOL. I think they'd be surprised to find out just how many apps written in it are still around and kicking. And I agree with the video that COBOL itself isn't that hard to learn it's all the environmental things you need to know to work with those old systems. If I never hear another word about JCL it'll be too soon. I never did write any COBOL code outside of school but I did have to work with JCL in setting up other applications.
There are approximately 23 million professional developers worldwide (according to the IEEE survey). So, around 5-10% of all professional developers have some level of proficiency in COBOL. and this is old data from 2020.
There are still quite a few of us COBOL programmers around. It wasn’t that long ago.
You have become one of my favorite coding channels. Well done! Keep making these great videos. 🎉
I was a COBOL programmer for the Cdn DND in the 70's and 80's. We used to have a saying "Old COBOL programmers never die. They just bomb on an 0C7. " COBOL programmers will know what that means. 😀
Memory reference error?
@@SahilP2648 Bingo.👍
In COBOL, '0C7' is an abend code, specifically indicating a data exception error. This typically occurs when there is an attempt to perform a numeric operation on non-numeric data, such as trying to move non-numeric characters to a numeric field, or performing arithmetic operations on invalid data. Common scenarios causing a '0C7' abend include:
- Incorrect data in a file or input record.
- Uninitialized variables used in arithmetic operations.
- Invalid data due to incorrect file handling or data corruption.
To resolve a '0C7' abend, you would need to identify the offending statement and correct the data or logic causing the error.
@@keith77mn77 Bravo!! You've obviously still got the manual. 😁😁😁😁😁😁
Cobol isn't that hard, but it has some quirks that you need to get familiar with.
When I was in AF Basic Training in ‘87, I passed the bypass test for tech school. It was probably 80% COBOL, which I’d never seen before, but I managed to get the highest score they’d seen in almost a year.
Really enjoyed your video - good work :)
That reminds me IBM created an "AI" specifically trained to translate COBOL code to Java
Wow I remember learning COBOL and PASCAL back in collage. I think had just finished learning punch cards just before they got phased out and C was getting popular.
COBOL was used in the Lunar Lander simulator to train astronauts to land on the moon. COBOL could perform block moves of data. So, it was used to move lunar surface maps into a limited memory computer.
I'm 63 but not a programmer by trade, electronics technician trained in the mid-80. I heard about COBOL and Fortran (Forumla-Translation) back then. In the mid-90s I met an old guy in his late 60s who was a COBOL programmer/consultant who supported a COBOL system that ran the Milwaukee Welfare system. We lived int he Chicago area.
I started my career as a Cobol programmer.
I, now, code in Python. But, I started in COBOL out of school. Good language.
Which language hurt you with the commas?
But yes, COBOL was my first language for pay, and was tremendous fun.
haha just no
8:28 it’s not the COBOL language that’s difficult. It’s changing a code base written decades ago when computers had serious limits on memory. There weren’t even dynamically sized arrays, let alone lists and hash tables. Programming in modern COBOL or Fortran, by comparison, is easy - far easier than something like C++. If one tried to replace a section of old COBOL code with Python and still live within the constraints that a 50 year old code based was designed to live in, you’d find it quite a challenge. What if I told you that you had to write a Python module but without using lists or hashes, and only using decimal arithmetic so there was no loss of precision? Oh, and your code has to simulate taking inputs from multiple tape drives and merge the results into a single input stream, then do processing at control breaks? Yeah, have fun with that! The style of programming itself was vastly different back then, and you can just shove new code with a different style into an old system without making the system even harder to maintain.
I'm half tempted to skill up on COBOL, but the shops that do it seem quite closed. The problem is that the systems that rely upon COBOL aren't just the COBOL. They are the file formats and hardware and business processes that it is embedded in. It's difficult to rewrite a bit of it to a modern language, without rewriting all of it. Otherwise there would be a cottage industry of boutique consultancies doing piecewise ports of COBOL-based systems to microservices.
I know some COBOL and its painful
No, it is not.
It is readable and for purposes like financial transactions there is hardly anything better out there.
If a COBOL program on a host crashes (ABEND) for whatever reason then the dump is available for analysis and you can resume processing from the very spot of the crash.
Try that in any other programming language.
When it really matters for a business (money!) there is nothing better than COBOL.
We are constantly fed the myth of "AI"-code generation being that great.
So let an AI translate Cobol to whatever, not to python, or bank transactions will take months.
But then suddenly we realize AI's are good for generating kitty-videos, but not for coding complex software.
AI can't code worth a dang. Yes, it can pull-up some examples from it's internet-based training, but other than that it consistently writes code that doesn't even compile.
And half will transfer any amount (or an array or any amount or a class of any amount) will go someone. Magically functions without any argument will still produce some output.
Thumbs up on that. Some company (I forget which, after 25+ years) used Lisp to analyze giant COBOL systems for Y2K issues and fix them. It wasn't "AI", because the point was determinism and explainability, not cleverness and pseudo-imagination. If there was any "AI" involved, it was symbolic logic to handle non-obvious cases, not some big plagiarism bot that says it once saw something like that the someone did for some reason.
It isn't that nobody knows it anymore. I can recite mainframe COBOL and Assembler in my sleep. But it doesn't pay to offset the workload. Too difficult to switch employers if you want to because there aren't many openings - and definitely not for a decent salary. Unless you want to be 24x7 oncall, don't go there. The code is stable, but the batch processes are set to stop if they receive what looks like questionable data - frequently from non-mainframe servers. And then you get called. Regarding documentation - the systems are deliberately not documented. The old guys were afraid they would be let go if they documented everything, so when they are ready to retire they allow someone else to shadow them and take notes a few weeks before they leave. Some of the vendor software that manages Job output is written in Fortran.
COBOL is the first language I learned in the 1970s. COBOL is just "dead simple" as you said. COBOL was the bain of the Y2K era because of the 2 digit year stored in the databases that were designed at the time. 2 digits for the year were used because it saved on storage which was extremely expensive. My COBOL professor even warned the class of the debacle and that Y2K would be a good year for COBOL developers.
And Cobol was one of the main reasons for Y2K problem. Because memory storage was limited and who needed more than two digits for a year. Then the year 2000 came and there was no one left who could rewrite those millions of lines of old Cobol code. Not to mention converting all the old data first.
Prognostications of impending Y2K doom & Armageddon never materialized. Just minor blips here & there.
Don’t blame COBOl for the cost of hw in those days; all systems were built in a similar hw-optimised way, whatever language they used
You call these things "issues" implying problems. I call it watching the evolution of programming languages.
Almost all of contemporary programming languages come from concepts established in FORTRAN (1957), LISP (1958), ALGOL (1958), COBOL (1959), Simula (1967) and Forth (1970).
Even C (1969) descends from ALGOL through B, BCPL and CPL.
And C is one of most important languages.
COBOL's big deals:
COBOL was designed to be readable by non-programmers, using English-like syntax for business applications.
COBOL introduced robust file handling capabilities, which influenced how later languages dealt with data storage and retrieval.
COBOL's precise decimal arithmetic for financial calculations was an important feature that influenced how other languages handle financial computations.
COBOL's structured approach to defining data, separating it from the procedure division, influenced how some later languages handle data declarations.
My mum had to learn COBAL in three weeks. And was in charge of the programming team, it was all done on punch cards. You even had to check the code prior to running them through the mainframe.
I have been coding in COBOL for 40 years. Enterprise COBOL is the latest version I developed software in, running on IBM compatible mainframes.
Knowing COBOL isn't enough. You need to know JCL, VSAM, DB2, DLI, CICS, IMS, etc. too.
COBOL is great. I miss the days when things were purpose-built for specific use cases, including programming languages. Seems like everything's just trying to be all things to all people now. Friends, not everything in life has to be a Swiss Army knife.
No one knows COBOL? Really?
Did it ever occur to you how, at a time when a "smart" phone that is already hopelessly obsolete after 1 or 2 years, any programming language or hardware platform manages to still be in wide spread use after 60 years? That's not something you pull off by "getting it wrong". That's something you accomplish by getting it VERY right. The problem isn't with the platform, or the language... PEBKAC.
Another point that should have been made is that most COBOL programs are much lengthier than almost every other language. A ten thousand line program would probably be only 400 lines in a modern language. The exception would be programs which use database-related intrinsics. I remember a data sorting program that would have been hundreds of lines long but was only 30 or 40 lines in COBOL. It did have its strengths!
That was truly fascinating. Thank you for putting this together! I was just starting trade school in 1984 for an Electronics career. The school also taught COBOL and FORTRAN and I would hear the programmers argue about which language was the future of software development. I was convinced at the time that computers would eventually be able to program other computers so I opted for the electronics career to repair the hardware rather than write the software to program them (woops, big mistake there). I transitioned from electronics repair to software development in the late 1990's when I learned C for industrial robotics engineering. I truly enjoyed this video!
Fortran is still being used EXTENSIVELY in engineering and science codes.
C - those were the days. Great language.
I heard that long ago people were able to make also cars which work until now, construct buildings which last until now, and so on. It's not only about software.
I learned some basic COBOL back in high school in the early 1980s, but I never got to use it in any work. Still remember the basics, though. The sample shown in the video gave some very rudimentary introduction to it but didn't mention one of its unique aspects at the time it was made: you can define screen setups such as input forms, much like you create forms in a database system. The COBOL variant I learned didn't have any GUI elements, so all interactivity had to either use a defined screen image setup or do it one value at a time just like any other language that doesn't have an ability to place the cursor at a predefined position.
Great Video! My uncle is a COBOL programmer and is approaching 70 years old. It appears the banking industry in particular is not about to change it because it is NOT broken. I think it would take a massive initiative to convert all the COBOL into some modern language (eg Python). I personally think it is not modern, but my own research indicated that COBOL could be learned and we are talking about a system that just works and has as you stated been around for a long time. Again, appreciate the video.
As an assembly coder since the late 70s, I too code Cobol .. Put it on your resume, just in case .. such as assembly, because what happens is that you get calls from e.g NASA (hint: Voyager) .. don't be shy, learn it .. why? because the entire foundation of the modern World are coded in those languages :)
COBOL natively does business math in a way modern languages do not. The data types and math operations allow for business rounding of results that match what businesses and tax codes expect. Similarly, overflow conditions are also built in. COBOL can be compiled to machine code or very efficient p-code making it extremely fast. COBOL is also very portable, with the same code running on many different operating systems. It's a good language that doesn't change. It allows a developer to become truly proficient without having to chase the latest fad in the ever-rotating array of better mousetraps (new languages) being invented.
Excellent video 😊!
I learned from another video about IBM mainframes that IBM still has a vibrant mainframe business. This is largely because financial institutions are so dedicated to mainframes. They are because of the quick response time needed for ATM and banking transactions.
For me, I worked in COBOL for a few years at a major bank. One of the interesting things I found is that checking accounts did not use relational database concepts. For example, one person could have multiple checking accounts, but each one could have slightly different names and different addresses. Think of an individual checking account, a couple's joint checking account, and a business checking account, all belonging to the same person or couple.
Du denkst an hierarchische Datenbanksysteme des IMS mit dem schrecklichen DL/I?Are you thinking of hierarchical database systems like the IMS with the terrible DL/I?
I'm an old retired computer programmer and I did a lot of COBOL programming. I loved it. The language was simple to learn, it was just all the interface routines with the OS and databases that made it complex. One of the great things about it was that it was very readable by non-programmers.
Brings back memories. My junior high school had some shiny new TRS-80 model 3s just gathering dust under their protective plastic covers so I talked them into letting me program some learning games like hangman, math quizzes, etc. I had experience in BASIC from my own Tandy Color Computer. The machines at school even had a COBOL compiler. Interesting and fairly simple language once you get used to how verbose it is. That’s also a plus for legacy code as it pretty much self documents as you code. The main problem I can see is interfacing to other apps/systems was a very dark art in those days with no concept of standard APIs or remote procedure protocols. All the interface points would be where hell breaks loose on a modern port.
I spent years writing code (and making a good income) using a language called Clarion, which was fundamentally derived from COBOL and used many of its principles - it was awesome for writing business apps and quickly creating financial systems.
That's very wierd approach on COBOL, I'd say "Pythonic". COBOL doesn't need any GUI, doesn't need any libraries and definitely doesn't need any AI. It's a legacy programming language, used to maintain legacy code. Most likely in banking area for backend, core transaction systems. Many ICBS commercialy available still have COBOL modules, but it doesn't mean that they're fully written in COBOL.
The oldest ones - yeah their gui is text based, they look mainframeish or DOS like, but it doesn't mean that modern ui, built in any modern language cannot be integrated. UI simply calls COBOL based system or its database (most likely db2). When you're making online transfer, there is almost certain that the accounting part of the transaction is in the COBOL module, yet you still can do it quite easily...
COBOL is still taught at universities. Penn State, Rutgers, USC, etc.
I grew up programming BASIC, COBOL, FORTRAN, and Pascal. My parents even volunteered 14-year-old me one day, to tutor a college kid who had a COBOL class in university. But then when I was headed to college years later, my father forbid me from majoring in computer science, and told me to never pursue a career in programming. Crazy how that turned out.
COBOL is very simple to learn, code, and maintain. COBOL-85 even allow strucutured code. What is annoying is the fact that you need to write a lot to achieve anything.
I took Cobol, Fortran, Basic, Assembly, and even a hypothetical language called Hycomp back in the early to mid-1970s while in college. Since then I have done Pascal, Forth, Java, and C+. Which is my favorite? Loved Assembly.
Cobol code is the reason why an anvil arrives in China before a transaction sent at the same time from the US. The servers use batch processing twice a day for each layer and there can be many layers, like regional intra-bank nodes, bank central processing nodes, country level inter-bank processing nodes, and international processing nodes (I may even have missed some as I'm not in finance). The anvil on the other hand can arrive within 24 hours from LA to Shenzen for example.
I've used a little COBOL in the past and I can assure you that it's not more difficult than C or Python. Most concepts can be easily mapped to C constructs.
COBOL has evolved a lot since those days, and it has OOP and some versions can do GUI. But from what I can see the ease of use remains.
Software engineering as a profession becomes more than just cross-generational. Like many human occupations, it starts having generations of professionals that "lived before". This is amazing
Yeah old COBOL programmer here. I was also a mainframe operating system administrator & data (not database, that was later) administrator, & systems performance tuning specialist. It wasn't so much about the COBOL programs themselves. It was more about the whole secure ecosystem, of which the COBOL programs were just a part. Back then, people did COBOL, or data, or operating systems, or networking, but nobody did it all except me (my possession of multiple skill sets was very unusual). Companies were actually suspicious of anyone who could cover all the bases, as I discovered making me a pariah. The challenge today is in porting all that secure ecosystem over, but nothing today is designed at every level to be secure as it was then, & like as now nobody is expert in all those levels, so its near impossible to assure top management that it is even possible. As long as that FUD persists, so will COBOL. I tried to talk multiple companies into converting to other platforms but they were all too afraid because I seemed like a space cadet.
Aye, speaking strictly for myself - I never worked on so-called mission-critical systems, where computer failure leads to loss of human lives or massive financial loss - I totally agree with your assessment. IT has created several layers which are more and more isolated from each other, some of which (like UI design) get all the attention, but *all* are necessary for getting everything to work together. There are lots of openings for so-called "full-stack developers" (even so, they're not required to understand anything about hard-core networking systems), but, in my experience, _true_ "full-stack developers" are a rarity, and the best you get is someone who can do JavaScript on the browser _and_ on the Node.js backend, does some basic (but effective!) Web design, and knows how to install Linux from a set of DVDs or USB pen drives. Quite different from the reality of the ecosystems you're talking about!
Though I learned COBOL in the late 1970s, I always avoided it because it was heavily used in low interest (as in appeal) applications like banking, insurance, taxes, etc. It shouldn't be too hard to automate the conversion of a COBOL application into something modern like C++, PHP, or Python. Probably 95% of it can be done with some simple string substitutions.
My first job out of college was COBOL programming. That was in 1982. I was living in Las Vegas, and we were developing a Race and Sports Book Package for a casino. Programmed on an NCR VRX mainframe computer. Brings back memories, I'm 68 years old.
I have friend who was a COBOL programmer for a local bank. She retired a couple years ago. It was about 10 years ago when she told me she was a COBOL programmer. I told her she had great job security.
Sorry Dee but Cobol is pretty well known schools still teach it and it is one of the cleanest coding languages thanks to decades of being refined
Thanks for bringing back some of my memories of coding with COBOL.! I recall having to rethink some going from pascal/fortran over to COBOL but, once I did I got to really appreciate it. I'm kinda excited to see that it's still in such widespread use today. And, wondering if the AI mentioned towards the end of your exposition may end up helping to evolve the language some while keeping it in line with all it's integral ways. Could be interesting. *Cheers & Thank you.!
Thanks, that was a really well made presentation :)
I have considered taking COBOL for a spin and no doubt I would pick it up in a week or so. Hard issue is incentive, what would I even use it for lol
nice overview, and hell yeah, Fortran lives up and is being maintained and updated until now
I worked for insurance companies from the 1970s. They sent me to college at what was the The College of Insurance in NYC. One of the first programming languages I learned (circa 1977) was COBOL. The other was BASIC. I never used COBOL in work, but used BASIC and variants of BASIC (Visual Basic) all the time.