It didn’t even fix all the y2k bugs. Some of them were just shifted to 2020 or 2050.

Fixing the problem mean using a 4 digit year which would work until 9999. Sometimes there isn’t space in a record or it’s more work. The workaround was to basically redine 00 as 20 or 50. That way it didn’t wrap again until 2020 or 2050

I didn’t realize that’s what happened until a friend told me they had a y2k problem back in January and I read up on it.

I kept asking why they couldn't simply(!) update COBOL to accept 4 character dates. Most of the answers I got said it would be easier to rewrite everything in a modern language.

I remembered/realized something else as well.

Big companies have mostly updated the backend data to have 4 digit years. Data is an asset any more. For example, letting you manage your account online lets you find new things you want which makes them money. Convenient for us as well.

The web interface isn’t cobol but some logic still is. The cobol code still sometimes thinks of it as a 2 digit number so bugs have shown up.

I think the recent stories have been governments and utilities and such. They had less or no financial reason to modernize so they are more prone.

I hate wrap type issues.

Cobol was perfectly capable of handling as many characters in a date as you cared to put there.

The problem was that the applications were written in a time where having two more digits in every date used up way too much of fairly limited storage. Now, that problem was fixed by the people who made computers and computer storage before I ever started coding.

But the bosses were not going to to pay their staff to fix that problem 20 or more years before it was going to be a problem.

That is where the idea of of we'll have a whole new language. The application code that had been written to not waste two extra digits in every date would all have to be rewritten any way, and certainly by that time, there would a need to also change the data format as well, and then we could fix the Y2K problem without having to get some C-level boss to pay for it.

I had a nice gig for a while fixing Y2K code, because the company I worked for had hired a crowd of the youngest Cobol programmers they could hire and just told them to fix it. And they tried, but it was a system with over 5,000 lines of code, all written by programmers who hadn't had any guidance either.

Now I knew some companies who decided to go the new language route. But there were still those C-level guys who wanted to save money, so the the new application code wasn't understood by anyone who understood the old applications.

I new one company who hired some consultants to install a new system, and make it work with all the modifications they had in their old system. They were just a few days before going live, when they realize that neither the people who wrote the new system, nor the consultants ever thought about saving the data on the computer. The form was just filled out and printed.

number of legacy systems out there running COBOL programs. I knew COBOL many years ago back in the days of actual key punch machines.

On the other hand, trying to make changes to legacy systems encrusted with decades of barnacles of mediocre ad hoc mods -- good luck with that.

I began my career doing maintenance on legacy code. You quickly form opinions on the best way to do something and you learn to value simplicity of design. I agree, it shouldn't be difficult for an experienced developer to learn Cobol. The problem is there's always something sexier to work on, using the language du jour.

stuff doesn't get updated.

Barely knew COBOL in my day.

that was in 1983...

nt

I learned a bit of COBOL in 1980.

They are suffering from years of software neglect and taking low-ball bids.

Did they do the same at Y2K?

Bite me. I'm not going to fix anyone's COBOL.

geez

VSAM files?

Other stuff mentioned in ancient history books?

I do regularly although mostly on linux machines and my mac which has x11.

You might be surprised to find what still gets used and how much of it.

The details should never be visible to most programmers.

Obviously I agree with the gist of what you said. Just a different perspective.

still runs on the newest and fastest mainframes there are. The programs may be old, but they work.
And mainframes are almost never hacked.

Many of us old COBOL programmers are now retired. It would take a bit of enticement to go back to work.

That was 48 years ago. C is an essential language for many types of projects.

They'll need instructions on how to boot up a "book".

The 1980s. I learned Fortran on punch cards. We were required to take two COBOL classes. COBOL is an excellent language. Because it is rigidly organized, one knows where everything is. Because it was designed to read like English, it is easy to understand even if there is no documentation. The first two high-level languages that were widely used were Fortran and COBOL--Fortran was mostly used by the sciences and COBOL was mostly used for business, and they were both awesome for the time that they were created. They beat the hell out of having to write something in assembly language or machine code. If someone wants to create a simple business program to say, handle timecards or payroll, COBOL is great for that because the code is very understandable, and the common routines for it were written decades ago.

Sure, a lot of things have changed since the 1980s. Computers have about a million times more memory and run about 100,000 times faster. The Windows 10 computer that I am typing on right now has more computing power than a thousand computers from the 1980s. I've learned lots of other languages besides Fortran and COBOL, like RPG, BASIC, Pascal, Assembly Language, Machine Code, C, C++, C#, Java, and on and on, and I've used a hundred different types of computers. It's all writing programming code on machines, and I have been able to do a lot with whatever language that I used on whatever machine that I used.

I don't judge people for the programming language they use. I judge them on their skill at getting things done with whatever language they are using. All code compiles or interprets to machine code, and every language that is quicker to type out is harder to read by someone who did not write the code. There are always tradeoffs.

When one is a memory typist, as I am, one does not care if COBOL makes one type a few more characters, and I would rather debug a rigid language like COBOL than someone's sloppy R, Python, or Javascript code. If Mary Poppins coded, she might choose COBOL. It is the "A place for everything, and everything in its place" language, and it reads so much like English that it is easy to modify. Arithmetic, Algebra, Geometry, Calculus, and Differenitial Equations are all way older than COBOL.

Yet, people still use them to do all kinds of amazing things. COBOL allowed me to create numeric and data strings in 12 dimensions like it was a piece of cake--in the 1980s--on machines that had 1% of the power most kid's cell phones have now. It was brilliantly put together and powerful as hell, and millions of people's parents and grandparents got proper paychecks because of it. Respect the brilliance and elegance that was, and is, COBOL.

"COBOL is still very popular today in 2021. Depending on the source you’re looking at, there are still between 200 and 250 billion lines of COBOL code in production. Many large corporations, 70% in fact, still rely on COBOL for much of their mission critical work. Government, finance, insurance, automotive and banking industries are still heavy users. Roughly 43% of banking systems use COBOL and every time you swipe an ATM card, it executes COBOL code 95% of the time. There are 1.5 billion new lines of COBOL programmed each year."

I've not programmed for the past ten years, and I had no idea new COBOL code was being written. My natives are F-Level COBOL and PL1.

I forgotten almost every language I had to learn. Except for Cobol. And it's been a really long time.

Part of the problem with people who were just coming out of school right before I was pushed out, well, they understood what they had been taught

Things like the name used for a data field was meaningful. In the old systems, of course, they didn't

Had an argument once with a young bright guy, who was convinced that there could never object oriented programming on a mainframe. I eventually realized that he thought that the objects were real physical things that lived in the computer somehow. I think that I hurt him when I showed him that object oriented Cobol had been around for more than a decade