Fourteen years ago, fresh out of the university, I got my first programming job at a large government-owned company (ahem ). After going through some sorting interviews and orientation, I found out I'm to spend the next couple of years as a Mainframe developer.
Mainframe? MAINFRAME?!? Me? With my B.Sc. and all my object-oriented, A.I., Gaming Theory etc. knowledge still fresh in my head, reduced to writing C and Assembler code on a machine that was older than me? Needless to say, my first question was "where do I sign to get out of here?"
My third question (the second being "Thank you sir, may I have another?") was "what can I learn here that would help me later in real life?". But as I found out, MF development had its own challenges, intricacies and, dare I say it? fun.
On the professional side, I learned a lot of valuable lessons about optimization and memory management - some things that people starting to learn programming today (Java or .Net) are not even exposed to (to find out more, read this): how to reuse a bit; how to use a single field to contain more than one type of data; how to minimize computation cycles (we were charged by the cycle, so anyone who came up with optimization schemes, actually could save millions of $$$ annually). What is pre-fetch and when to use it. How to write 10 lines of C code, run the optimizer and then go down to the assembler level and optimize it some more. How to work with non-relational databases. How to write C on a PC (Win 3.1), compile it for syntax, copy it to the MF, compile it again (this time via a batch file) and then link it...
And, of course, the whole batch process: you learn how not everything is instantaneous. There is a queue of jobs (although, like every queue, you can cut to the top - and we did, when we knew no one was watching ). Jobs can sometimes take a whole night. And if they fail, you come back in the morning, fix the problem - and rerun the job (teaching you to check, recheck and re-recheck your parameters the next time).
Most memorable fun-generating efforts: a help screen that can only be viewed by clicking a combination of 3 keys, where I wrote everything I actually thought about my boss - some bastard squealed and he actually saw it - 2 days after I left his department.
Or the time when we broke into our company's time management system and added time consuming entries, like "peeling an orange", or "playing backgammon".
And let's not forget the fact that we could peek at our bosses salaries and personnel records... (yes, that's what happens when you have debug admin access on the same machine of the production files. 'Nuff said ).
Now, why am I waxing nostalgic all of a sudden?
The occasion is the launch of IBM's new Mainframe, the z10. Bigger, better, faster than it's predecessors, but still a Mainframe. The amount of articles on distributed computing that predicted that by 2000 the MF would be extinct, probably equals in height to the amount of COBOL lines written in 1964 that are still with us today.
Yes, it's big, and expensive, and less agile than Unix servers, and if you buy into the paradigm you become IBM's upgrade-slave for life. That doesn't prevent banks, insurance companies, investment houses and government departments to keep buying new MFs. Why? Perhaps because they are predictable, reliable, really support hot and cold replication, and provide dependable disaster recovery.
We have been distributing our systems for years now: we went from a single fat application to a 2-tier design 9client-server), to a 3-tier design (client-business logic-database), to n-tier design (where you have diagrams on the board to remind you where are your servers and what do they do). We went from "that server in the corner" to a "server room" to a "server farm".
Along the way maintenance costs accrued: space, electricity, air condition, IT personnel. Every startup I worked at, had at least one or two servers thrown around (usually under my desk, warming my feet), because there was no more space in the "server room". Here are some more people who experience "datacenter pains".
In the last couple of years, virtualization has become the "hot" IT initiative: let's buy one strong machine, install a VM server and segment it into many "virtual machines". In other words, consolidation, instead of distribution.
Well, guess what? I just described a Mainframe .
I'm not saying I'll gladly go back to developing for the MF - I'm more of a web/.Net/open source kind of guy now, but don't knock off the old generation - it can still teach us something.
PS: I know of one particular reader, who's smiling while reading this post. We've been friends ever since I met him on that first day of being assigned to the MF team. He actually taught me some of the stuff mentioned above. Thanks man! (you know who you are).
1 comment:
MMM... Mainframe
Are you sure you didn't take a blue pill (with the letters "IBM" on it) before writing this post?
I am glad you can now see the true power of the dark side. Soon we can begin your conversion from a ".net jedi" to a "zos sith".
By the way , just to refute some malicious rumors , the death star did not explode because it was run by IBM mainframes.
The title of this post is the fi
I see you start to realize the true power of the dark side.
:-)
P.S.
I took a framing screen capture of the your post - you will never able to deny it.
Post a Comment