Was there something in Cobol intrinsically making it susceptible to Y2K issues?

Question

I know that a lot of Y2K efforts/scare was somehow centered on COBOL, deservedly or not. (heck, I saw minor Y2K bug in a Perl scripts that broke 1/1/2000)

What I'm interested in, was there something specific to COBOL as a language which made it susceptible to Y2K issues?

That is, as opposed to merely the age of most programs written in it and subsequent need to skimp on memory/disk usage driven by old hardware and the fact that nobody anticipated those programs to survive for 30 years?

I'm perfectly happy if the answer is "nothing specific to COBOL other than age" - merely curious, knowing nothing about COBOL.

Answer 1

Yes and No. In COBOL you had to declare variables such that you actually had to say how many digits there were in a number i.e., YEAR PIC 99 declared the variable YEAR such that it could only hold two decimal digits. So yes, it was easier to make that mistake than in C were you would have int or short or char as the year and still have plenty of room for years greater than 99. Of course that doesn't protect you from printfing 19%d in C and still having the problem in your output, or making other internal calculations based on thinking the year would be less than or equal to 99.

Answer 2

It was 80% about storage capacity, pure and simple.

People don't realize that the capacity of their laptop hard drive today would have cost millions in 1980. You think saving two bytes is silly? Not when you have a 100,000 customer records and a hard drive the size of a refrigerator held 20 megabytes and required a special room to keep cool.

Answer 3

It seemed to be more a problem of people not knowing how long their code would be used, so they chose to use 2 digit years.

So, nothing specific to COBOL, it is just that COBOL programs tend to be critical and old so they were more likely to be affected.

Answer 4

Was there something in Cobol intrinsically making it susceptible to Y2K issues?

Programmers¹. And the systems where COBOL programs run².

---

_{1: They didn't design forward looking 30 years. I can't blame them really. If I had memory constraints, between squeezing 2 bytes per date and making it work 30 years latter, most likely I would make the same decision.}

2: The systems could have had the same problem if the hardware stored the year in two digits.

Answer 5

Fascinating question. What is the Y2K problem, in essence? It's the problem of not defining your universe sufficiently. There was no serious attempt to model all dates, because space was more important (and the apps would be replaced by then). So in Cobol at every level, that's important: to be efficient and not overdeclare the memory you need, both at the store and at the program level.

Where efficiency is important, we commit Y2Kish errors... We do this every time we store a date in the DB without a timezone. So modern storage is definitely subject to Y2Kish errors, because we try to be efficient with space used (though I bet it's over-optimizing in many cases, especially at the enterprise overdo-everything level).

On the other hand, we avoid Y2Kish errors on the application level because every time you work with, say, a Date (in Java, let's say) it always carries around a ton of baggage (like timezone). Why? Because Date (and many other concepts) are now part of the OS, so the OS-making smart dudes try to model a full-blown concept of date. Since we rely on their concept of date, we can't screw it up... and it's modular and replaceable!

Newer languages with built-in datatypes (and facilities) for many things like date, as well as huge memory to play with, help avoid a lot of potential Y2Kish problems.

Answer 6

It was two part. 1- the age/longevity of Cobol software, and 2- the 80 character limit of data records.

First- Most software of that age used only 2 digit numbers for year storage, since no one figured their software would last that long! COBOL had been adopted by the banking industry, who are notorious for never throwing away code. Most other software WAS thrown away, while the banks didn't!

Secondly, COBOL was constrained to 80 characters per record of data (due to the size of punch cards!), developers were at an even greater pressure to limit the size of fields. Because they figured "year 2000 won't be here till I'm long and retired!" the 2 characters of saved data were huge!

Answer 7

It was much more related to storing the year in data items that could only hold values from 0 to 99 (two characters, or two decimal digits, or a single byte). That and calculations that made similar assumptions about year values.

It was hardly a Cobol-specific thing. Lots of programs were impacted.

Answer 8

There were some things about COBOL that aggravated the situation.

• it's old, so less use of library code, more homegrown everything
• it's old, so pre-internet, pre-social-networking, more NIH, fewer frameworks, more custom stuff
• it's old, so, less abstract, more likely to have open-coded solutions
• it's old, so, go back far enough and saving 2 bytes might have, sort of, been important
• it's old, so, so it predates SQL. Legacy operating software even had indexed record-oriented disk files to make rolling-your-own-database-in-every-program a little bit easier.
• "printf" format strings and data type declaration were the same thing, everything had n digits

I've seen giant Fortran programs with no actual subroutines. Really, one 3,000-line main program, not a single non-library subroutine, that was it. I suppose this might have happened in the COBOL world, so now you have to read every line to find the date handling.

Answer 9

COBOL never came with any standard date handling library.

So everyone coded their own solution.

Some solutions were very bad vis-a-vis the millennium. Most of those bad solutions did not matter as the applications did not live 40+ years. The not-so tiny minority of bad solutions cause the well-known Y2K problem in the business world.

(Some solutions were better. I know of COBOL systems coded in the 1950s with a date format good until 2027 -- must have seemed forever at the time; and I designed systems in the 1970s that are good until 2079).

However, had COBOL had a standard date type....

03 ORDER-DATE     PIC DATE.

....Industry wide solutions would have been available at the compiler level, cutting the complexity of any remediation needed.

Moral: use languages with standard libraries.

Answer 10

COBOL 85 (the 1985 standard) and earlier versions didn't have any way to obtain the current century**, which was one factor intrinsic to COBOL that discouraged the use of 4-digit years even after 2 bytes extra storage space was no longer an issue.

** Specific implementations may have had non standard extensions for this purpose.

Answer 11

The only intrinsic issue with Cobol was it's original (late 1960s) standard statement for retrieving the current system date, which was:

ACCEPT todays-date FROM DATE

This returned a 6-digit number with the date in YYMMDD format.

However, even this was not necessarily a problem as we wrote code in the 90's using this statement which just checked if the year portion was less than 70 and assumed that the date was 20YY, which would have made it a Y2K070 problem. :-)

The standard was extended later (COBOL-85, I think) so you could ask for the date in different formats, like:

ACCEPT todays-date FROM CENTURY-DATE

Which gave you an 8-digit number with the date as CCYYMMDD.

As you, and others have pointed out, many other computer programming languages allowed for 'lossy' representation of dates/years.

Answer 12

The problem was really about memory and storage constraints in the late 70s early 80s.

When your quarter of a million bucks computer had 128K and 4 disks totalling about 6 megabytes you could either ask your management for another quarter mill for a 256K machine with 12 meg of disk storage or be very very efficient about space.

So all sorts of space saving tricks were usered. My favourite was to store YYMMDD date as 991231 in a packed decimal field x'9912310C' then knock of the last byte and store it as '991231'. So instead of 6 bytes you only took up 3 bytes.

Other tricks included some hokey Hooky type encodeing for prices -- code 12 -> $19.99.