Chapter 17. Migrating Legacy Data

Let me lay out a frightening little scenario for you: It's 3 p.m. on a Friday afternoon, and most of the IT department is “working from home” already. You're about to join them when your manager rushes in and begins babbling incoherently about batch processes, missing data, and Web interfaces, and, most ominously, the word COBOL is thrown in there somewhere. This is ominous because you know that the only guy who actually knows COBOL is laid up in the hospital from a jousting-related accident he suffered at his last Society for Creative Anachronisms festival.

Unless you're already a COBOL/mainframe programmer (which I'm definitely not), your brain will tend to automatically shut down whenever someone says the “C” word around you. But the fact remains that most of the really critical business systems running today are written in COBOL and running on a mainframe. Learning the bare-bones techniques to gain access to the data from these applications can only help you when you get that unexpected “there goes the weekend” visit from your boss.

Technologies Used:

• XSLT

• COBOL

The COBOL programming language has picked up a very bad reputation among the younger, PC-grown crop of programmers. I should know, because I'm one of them. And I used to get in there and make wisecracks with the best of them. But at one point in my career I was forced to actually stop and learn the language, and I came to a startling conclusion: COBOL is not that bad.

Now, it's not the language I would choose to write a new operating system in, and I would rather get a job weighing hibernating grizzly bears than try to write a GUI application in COBOL. But for doing batch processes, generating nice-looking character-based reports, or generally expressing business rules in a clear and readable fashion, COBOL is as good a language as any (and better than most).