Summary
How do you get rid of a mainframe? Don't let it become a monster that feeds off your fears.
Advertisement
My customer would like to move their back office off the mainframes.
As the hardware became obsolete, disk images were moved to emulated machines on Solaris.
I want a mainframe staging environment for acceptance testing.
It is to be identical to production except for modified code.
Surely, management argues, this is throwing good money after bad.
Since this technology is considered obsolete, investment was halted years ago.
COBOL development is considered decidedly uncool and probably bad for your resumé.
The know-how in their organization about the applications running on the big metal is concentrated in just a few individuals who do not feel appreciated.
Yet, the mainframe remains very much at the core.
It interacts with just about every other system within the organization and with partners.
If there is a trusted computing base in their mission-critical applications, this is it.
Previous attempts to replace it have either aborted or had their scope reduced to cover only a fraction of the functionality.
The best guarantee for still being stuck with the mainframe in a decade or so is to continue this policy of disinvestment.
In order to disentangle themselves, the customer needs to take control.
They cannot do this without digging into the code again and setting up a staging environment.
Only then will they be able to migrate applications piecemeal to alternative platforms.
Writing great software requires confidence.
Not cookie confidence whipped up in a gung-ho fervour, but confidence grounded in experience and mastery of the technology you depend on.
To reach this state of grace, take note of your fears and work on dispelling them.
As Vera Peeters says:
when you are afraid of something, do it more often.
My customer's mainframe predicament calls for a complement to Vera's rule:
when you are afraid of something, make sure you understand it.
I may be learning COBOL in the coming weeks.
In the meantime, I salute that grande dame of computing, Rear Admiral Grace Murray Hopper.
She would not have signed for anything uncool.
This is a theme that comes from all directions. There are all kinds of deprecated computing environments that are falling to pieces. Many, as you note, are parts of critical systems that make or break a business. Some, are in control of things that can break the environment and life sustaining elements around them!
There is business aplenty it seems to me. But, you do have to be able to convince your customers to jump ship safely and with enough rope to get to the other side, but not hang themselves.
Too much working software is thrown out for no good reason. I've run into this situation a few times. I used to work on mainframes and superminis and I even spent a few years programming in COBOL and Fortran.
Before throwing out a working, understood, and paid for software system the company should work through the business case and the possible outcomes of a new development project. Too often legacy software is trashed or neglected because no one in the shop understands it or wants to learn it; old software is not cool.
Running in emulation is not a big deal: virtual machines for old mainframe/mini environments are often just as good as, if not better than, the original hardware. If the plan is to replace the VM running the COBOL code with a VM running the replacement Java code... you get the point.
COBOL and PL/I don't exactly go with the black leather overcoat and extreme sunglasses, but there's plenty of money to made working with those languages. And you have much less competition. Try to get a contract on some Java development project and you have 40 other radical hackers/ersatz musicians in the room. When you can keep an old COBOL program or PICK database running you may be the only candidate. And you can ask for more money than the Java dudes.
I know a lot of programmers prefer writing new code, but I prefer maintaining and enhancing old code. Refactoring is just as fun as writing new code, but it's a lot easier to keep your spirits up when you start with a system that works and depended on by users. Again, because few programmers want to do maintenance work you find the field less crowded and competition less intense.
In my experience (25+ years) I've seen a lot of new development projects fail and lots of teams blow up or fall apart, but I've never seen that kind of drama in the maintenance projects.
Another plus: old computer books are a lot cheaper than new ones. A copy of a good COBOL book will cost $15 or less at Powell's or eBay.
Instead of throwing it out and getting yourself and your team enmeshed in a new development project that (statistically) has a small chance of success, learn the old languages and start fixing that old code.
> Since this technology is considered obsolete, investment > was halted years ago.
There is no platform in the world that wont become obsolete and uncool if you dont maintain it properly. Blaming the tools they use is the standard cop-out for badly run shops.
> > Since this technology is considered obsolete, > investment > > was halted years ago. > > There is no platform in the world that wont become > obsolete and uncool if you dont maintain it properly. > Blaming the tools they use is the standard cop-out for > badly run shops.
More likely it was decided after hearing a lot of hyped buzzwords that CoBOL and mainframes were not "cool" and that all investment from that point on should be in "new technologies" so as to make the company look modern (never mind that noone outside the company sees those systems anyway).
Seen it, been there. Been handed decisions made at board level in a multinational that ALL projects from now on MUST use XML, the reason being that XML is modern and we must be modern ourselves thus we must use XML.
That was just months after I for the same company created an application to pump data from individual branch servers to the central mainframe because the client/server solution that had been in use up to that point was being replaced by one based on terminal emulation :)
And a few months after that we were creating a large Java application to replace another client/server app because they wanted platform independence (someone had heard that buzzword, never mind that there was only 1 client platform in the company to which all other applications were hardwired).
Previous Topic
