Oi! Adam! Good Luck with your exams!
Let's face it, you're smart enough and I need you over here in 6 months, so you'd better bloody well pass them...
At 4:00 today I happened to check the public bulletin board for the IS department, where I found an announcement that the server I (along with my whole department) use to store files on had contracted the Nimda virus. We were instructed to disconnect from the server at once and run an anti-virus tool.
I immediately started the anti-virus tool, informed a few others that something was up and turned back to save my files. At which point someone obviously decided the smart thing to do was to cut everyone off from the server without letting them save first. At which point two word documents and a program I'd been working on all vanished from in front of my eyes, as did Lotus Notes.
Having ascertained that the server wasn't going to let us back in and that I had, indeed, lost about an hours work, I decided to go home.
Hopefully, tomorrow I'll be able to get back to where I was fairly easily.
A 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.