Mainframes and COBOL
Sep. 2nd, 2003 08:55 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrewduckerA few days ago I was talking to Ami about our respective computing careers. He told me that he's happily coding away in Java and asked me what I used. When I told him that I worked in COBOL he recoiled in horror. This is a fairly common response, and I get a similar one when I mention that I work on mainframes, as if both should have been consigned to the dustbin of history a long time ago.
When it comes to mainframes this attitude is entirely unjustified. After all, a mainframe is just a very big computer, and large computers are always going to be in demand for dealing with masses of data. But mainframes aren't just scaled up PCs, they use architectures designed for incredible scalability and resilience. Not only can they pretend to be multiple computers at once, so that if you crash one instance the others carry on running. Not that it's easy to crash them - individual chips can have multiple pathways through them, with the results compared afterwards to make sure that physical problems aren't causing errors, error checking technologies are built in at the lowest levels and the operating systems are designed to cope with almost any eventuality. There's a story of an IBM mainframe that had it's hard drive accidentally disconnected. This wasn't any hard drive, it was the one containing the swap file. The machine happily carried on, putting any applications that wanted something stored on the disk into a Wait state until it was available. Eventually someone noticed, plugged the disk back in and everything continued running. Try doing that on your PC, if you don't want the hard drive any more (or the motherboard, for that matter). Mainframe's are perfect for applications where vast throughput, redundancy and uptime are needed, and that's going to be the case more and more as time goes on.
COBOL, on the other hand, is a little tricky to justify. It's an ancient language (1960!) designed for very different times, when programs came on punch cards and didn't need to do much more than move simple data from one place to another. Surely by now it's time to get rid of it entirely? If it wasn't for the cost that would be incurred in rewriting 2,000,000 lines of legacy code we'd have thrown it out in favour of something more recent. Well, yes, probably. Except that COBOL's advantage is that it's an ancient language that's perfect for writing simple programs that move data from one place to another. For instance, in going through 5,000,000 records on a customer database and producing the output files for their statements. When it comes to simple formatting of data and movements of information from one place to another, COBOL is incredibly efficient. Think of it as Perl, only compiled (and without lots of the overhead of Perl, because it's so simple).
However, as I discovered today, COBOL isn't necessarily going to be the future. We're currently getting an OS upgrade on the servers at work which would get Java running on them. We're going to be experimenting with Java on some upcoming projects and if it works out then we're going to start doing new development work in it. COBOL may well end up being legacy after all. Or it might turn out that for small data manipulation systems COBOL is as fast as you can get and there'll be a place for it after all.
When it comes to mainframes this attitude is entirely unjustified. After all, a mainframe is just a very big computer, and large computers are always going to be in demand for dealing with masses of data. But mainframes aren't just scaled up PCs, they use architectures designed for incredible scalability and resilience. Not only can they pretend to be multiple computers at once, so that if you crash one instance the others carry on running. Not that it's easy to crash them - individual chips can have multiple pathways through them, with the results compared afterwards to make sure that physical problems aren't causing errors, error checking technologies are built in at the lowest levels and the operating systems are designed to cope with almost any eventuality. There's a story of an IBM mainframe that had it's hard drive accidentally disconnected. This wasn't any hard drive, it was the one containing the swap file. The machine happily carried on, putting any applications that wanted something stored on the disk into a Wait state until it was available. Eventually someone noticed, plugged the disk back in and everything continued running. Try doing that on your PC, if you don't want the hard drive any more (or the motherboard, for that matter). Mainframe's are perfect for applications where vast throughput, redundancy and uptime are needed, and that's going to be the case more and more as time goes on.
COBOL, on the other hand, is a little tricky to justify. It's an ancient language (1960!) designed for very different times, when programs came on punch cards and didn't need to do much more than move simple data from one place to another. Surely by now it's time to get rid of it entirely? If it wasn't for the cost that would be incurred in rewriting 2,000,000 lines of legacy code we'd have thrown it out in favour of something more recent. Well, yes, probably. Except that COBOL's advantage is that it's an ancient language that's perfect for writing simple programs that move data from one place to another. For instance, in going through 5,000,000 records on a customer database and producing the output files for their statements. When it comes to simple formatting of data and movements of information from one place to another, COBOL is incredibly efficient. Think of it as Perl, only compiled (and without lots of the overhead of Perl, because it's so simple).
However, as I discovered today, COBOL isn't necessarily going to be the future. We're currently getting an OS upgrade on the servers at work which would get Java running on them. We're going to be experimenting with Java on some upcoming projects and if it works out then we're going to start doing new development work in it. COBOL may well end up being legacy after all. Or it might turn out that for small data manipulation systems COBOL is as fast as you can get and there'll be a place for it after all.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: mainframe
Date: 2003-09-02 02:03 pm (UTC)no subject
Date: 2003-09-02 03:30 pm (UTC)On the other hand, I'm a member of the "We can eliminate COBOL in our lifetimes!" club.
no subject
Date: 2003-09-02 07:01 pm (UTC)or to remember that F11 is the key that scrolls the page to the right, and F10 scrolls to the left, and that to get to the very bottom, type "M" and hit F8... ergh.
no subject
Date: 2003-09-03 12:18 am (UTC)no subject
Date: 2003-09-02 08:17 pm (UTC)no subject
Date: 2003-09-03 12:19 am (UTC)COBOL is, and always has been, just about the best, simplest tool for throwing data around.
I recall a Uni assignment in 4th year where I took a fraction of the time to do it as severybpdy else, because I employed an initial data processing stage (in COBOL) which simplified the actual program (In what, I can't recall). I don't think anybody else ont eh course had either done COBOL or if they had, they didn't think of rearranging the data to make the program logic easier. 1 up for COBOL (and 1 up for me, I suppose).
Just think what Ami is going to say about my programming 'career' :-)
no subject
Date: 2003-09-03 12:22 am (UTC)88-levels are something I could so have done with in other places.
no subject
Date: 2003-09-03 04:45 am (UTC)Why didn't they go the whole hog and make 'em 99-levels?
no subject
Date: 2003-09-04 12:48 pm (UTC)Only there was no one to tell who both knew Earthsea and knew COBOL.
no subject
Date: 2003-09-04 02:34 pm (UTC)I re-read the Earthsea trilogy recently, and keep meaning to grab the other books i nthe series.