The Y2010 bug

[andrewducker]

Next time someone says that the Y2K bug was a load of rubbish, point them at this example of what happens when people don't test their software/hardware before rolling over a minor date change.

Comments

[bracknellexile.livejournal.com]

It's hit more than German cards. I seem to recall the Aussies got bitten too, as well as some US mobile networks (SMS datestamps IIRC) and things such as anti-virus updates and spam filters from some software companies.

Opinion seems to be it's likely down to code writing 10 into what it thinks is a decimal field when it's actually hex and the system thinking it's 2016. Thus the banks thought it was 2016 and therefore the bank cards had already expired and were rejected.

[bracknellexile.livejournal.com]

More details here.

[momentsmusicaux.livejournal.com]

How does the change from 2009 to 2010 make them fall over, given they're already on 4-figure years to handle the change to 2000?

[andrewducker]

If I told you that it thought it was 2016 would that be enough of a clue?

[momentsmusicaux.livejournal.com]

Oh god, they stored 2009 in a variable that thought it was hexadecimal? HOW?????

[momentsmusicaux.livejournal.com]

What language even lets you DO that these days?? Were they programming on a BBC model B or something?

[andrewducker]

COBOL.

It's a bank, so I suspect it was two systems sharing data and specifying the format incompletely.

http://www.3480-3590-data-conversion.com/article-cobol-comp.html
If one is storing it as text (i.e. a two digit field with a number in each) and the other is expecting it in a binary format then there's scope for endless fun.

[momentsmusicaux.livejournal.com]

HA HA HA.

But yes. Write tests! as they say.

Apparently, "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

I hate PHP slightly less today :)

[andrewducker]

COBOL is fine for doing what it was originally designed to do (read in some text, manipulate it in a simple way, spit out some text, repeat for 100,000 policyholders). It's no good when it comes to very complex things (for values of "complex" that existed in the 1970s).

[momentsmusicaux.livejournal.com]

And for text manipulation there's perl now!

[andrewducker]

Horribly inefficient for our purposes, wouldn't fit into the toolchain, and is probably a massive pain to get running under Z/OS.

[momentsmusicaux.livejournal.com]

I've no idea how it compares to cobol, but perl is geared towards processing huge amounts of text and fast. It's what biologists use to process massive amounts of experiment data like genomes or stuff, somewhat unexpectedly.

For toolchains, it can be run as one-line commands rather nicely.

Your setup is just weird! ;)

[andrewducker]

It's a standard one for a financial company :-> They pretty much all use mainframes. And they don't have command lines. They're too old-fashioned for that :->

And I know that Perl is fast - but, largely due to its simplicity, COBOL is ridiculously fast when processing text. It's designed to run very close to the metal - and remap bits of memory to extract different bits of text out of structured flat files.

[momentsmusicaux.livejournal.com]

Wow.

I'll admit, this is wholly outside my experience. But: no command line? Gah!?! Do you edit the inodes with magnets too? ;)

[andrewducker]

There are running apps that can be used to control things - these tend to be text based and look somewhat like this:


Or you write a job and then submit it to be processed.
http://en.wikipedia.org/wiki/Job_Control_Language

//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01   EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=OLDFILE,DISP=SHR
//SYSUT2   DD DSN=NEWFILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(40,5),RLSE),
//            DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN    DD DUMMY

will copy OLDFILE to NEWFILE And yes, it is defining how much space to allocate there. In cylinders.

I am rather glad I don't do work in COBOL any more. :->

[momentsmusicaux.livejournal.com]

ARGH MY EYES!!!

I'd ask why the hell are people still using this old crap, but... *sigh*

[andrewducker]

Because the throughput you get on a mainframe is faster than on any other system. And they have ridiculously high uptimes. And it's still running code written in the 1970s. Some of which is written in Assembler.

You'll be glad to hear that the modern bits of the system are being written in DB2, Java and C# :->