Slashdot Mirror
What is Mainframe Culture?
An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"
Comment removed based on user account deletion
"What do we all need to know to get along in each other's worlds?""
You could try exchanging porno links to one another, that seems to be the way nerds bond. Just a thought.
..Punchcards, ENIAC tattoos and nipple piercings that look and spin like tape reels.
Starsucks
Unix and mainframe programmers are more likely to know multiple systems, out of necessity, and consequently have a more general understanding of the commonalities of all computer systems. Windows-only programmers are more likely to know The Microsoft Way, and only The Microsoft Way. They're less likely to know standard terms, and will only know Microsoft's replacement terms. At least in my experience (and these are tendencies with plenty of exceptions).
The main difference is one of resources. The mainframe folk utilize a shared resource: the Mainframe System. You may have parallel hardware, but from their point of view it's a single system. There's no ability to install a quick machine to use as a test server. Sure you can have test CICS regions or test OS partitions, but if you bring the hardware down you bring the datacenter to a screetching panic. Worse, you can piss off the operators and have 0.00001%CPU for the rest of your tenure. This keeps a certian unspoken level of panic about. Don't worry if you notice it bubble up when one of your coders fucks up. The panic symptoms will pass as it goes back down to it's normal level. It won't go away though. ;-)
Which brings me to scheduling. Remember that production=batch and batch knows no sleep. When code goes to production, it's just as bad for the stress level as a major version release of other software or a website launch. Unfortunately for the MF coder it happens a lot more often. Having to talk to your operators when you can't even see straight (from sleep or other things) takes something that is unique to this kind of coder. On-call programming takes talent and some craziness. If you can find where that is for each of them, you will realate to them well.
One last thing: make your coders work in operations for at least a week. They will have a better understanding of the hardware end and productivity will go up. There's a reason that the best coders are in the computer room a lot.
US Democracy:The best person for the job (among These pre-selected choices...)
Windows programmers don't know how to program without a GUI.
Linux programmers don't know how to program with a GUI.
Mainframe programmers wonder what a GUI is.
end humor transmission.
I am scientifically inaccurate.
The length of the beard?
Mainframers know that you cannot reboot a machine willy nilly, since someone may be running a simulation that takes 6 months to complete, he may be in month 5.5 now and on first name basis with the guy that normally signs your pay cheque...
Oh well, what the hell...
Unix programmers like their code like the old legos. Each piece might be a different size or shape, but the bottom of one snaps onto the top of another and the ordering and number of pieces used is left as an excercise for the reader. With experience, anything can be built with the pieces, and yet each piece is simple and easy to understand.
Windows is like the new lego sets. You get specialized premolded parts suitable for one specific task, plus two or three additional add-on pieces that give the illusion of being fully configurable for any task. You can build anything you want with the new legos, as long as you only want to build what is on the cover of the package.
Yeah, that's it in a nutshell.
... I have plenty of karma to burn, and this looks to have been posted to start a huge flame war. Why fight fate?
1. Windows is teh bestest, like EVER!
2. Unix is ok, you get good at typing...
3. Linux stole from SCO!
I will now invite retorts. (ducks)
HA! I just wasted some of your bandwidth with a frivolous sig!
Story @ 11 ...and 11:15, 12:15, and next Wednesday at 3:00. All worded slightly differently, of course. ;P
1. Windows programmer: There are two sub-phyla of Windows programmer:
A) Fanatic Windows programmer: Refuses to use any software not made by Microsoft or an approved Microsoft partner; openly mocks Linux, unix, Firefox, and you when you suggest any of the three; programs exactly the way Microsoft tells him to in MSDN articles, and is deeply distrustful of any different approaches; loves IE and is laden with spyware and viruses, but refuses to admit it, saying things like "it's the hardware; I need a new machine".
B) Normal Windows programmer: Uses Windows because it's what everyone else has (and he wants to sell them things); uses Firefox and generally avoids IE; understands that Windows is limited and imperfect, but finds it useful for some subset of tasks; is interested in Linux but vaguely irritated by Linux fanatics calling him a sell-out. Secretly wants to eat spicy Schezuan with the Linux geeks, but not that fanatic with the blue hair (she's too freaky);
2. Linux (2 sub-phyla):
A) Fanatic Linux user: despises Windows users, seeing them as the zombie hordes following Bill Gates, his Satan; throws things at Windows users when they're within range, shouting "Shoo! Shoo! Get back on your short bus and go home!"; compiles everything from scratch to install, because otherwise he'll feel unworthy; generally only uses "Free" software, eschewing anything even remotely non-free, which seriously limits him. Secretly feels betrayed by the moderate Linux users, wants to eat Schezuan with them but knows that Windows guy will be there, so goes for pizza instead.
B) Normal Linux user: Uses Linux because he doesn't have to worry about spyware and viruses (much) and can simply use and enjoy his machine without having to put up with a lot of annoyances; is intrigued by Windows but dislikes the Windows fanatics, who make fun of him (he suspects they live in a town with lead water pipes, and forgives them in pity); he generally doesn't care what other people use as long as his Slackware instance is running well; he occasionally uses Knoppix to rescue one of his Windows-using coworkers when their registry gets corrupted; Secretly enjoys the look they give him after he recovers all their data, it makes him feel Wizardly. LOVES Schezuan food.
3. Mainframe users: Aren't sure what all this "Linux" and "Windows" nonsense is about, and suspect it's a fad the kids are following; Are very fond of their new VT-100 terminal (2400 baud! Kick ass!); Are starting to suspect they might be in for some trouble -- they've had to page all their data off disk to tape a THIRD time this month, how can their disks keep getting full? They're 40MB!!! SOMETHING funny's going on... Are secretly nervous about the boss and that young intern kid and the new box they've been setting up in the corner; those two keep giving us significant looks, what IS that, some kind of new networking thing? Bill over in tech support said it had "blades" in it...; and they still laugh about how "Emacs Makes A Computer Slow". Ha ha ha! Snort!
Farewell! It's been a fine buncha years!
When a mainframe becomes loaded with spyware, you do not throw it in the dumpster!
[ ] Unix
[ ] Mainframe
[ ] Windows
beard #2
[ ] Unix
[ ] Mainframe
[ ] Windows
beard #3
[ ] Unix
[ ] Mainframe
[ ] Windows
I've also had the opportunity to train mainframers in shops where MVS platforms were displaced by *nix based platforms. So, here is a subject that, no doubt, I can speak about:
The major factors/differences:
First, most of the mainframer programmer contingent has been moved offshore or is being done by NIV programmers. Really not much of a career path here, but OTOH, a great deal of critical systems (charge card processing, airline reservations, utility company systems) are still coded in MVS COBOL/DB2 (or IMS, a hierarchical mainframe database platform for IBM MVS). To convert these systems means you need to be able to understand these systems, and please don't give me a business analyst -- the days of their expertise are long gone, and the metamorphisis of systems over time means business knowledge is embedded in the code.
Mainframers don't get GREP. I've tried so many ways to impart this wonderful tool, but all I get back is puzzled stares and bewilderment, for anything more complex than what could be accomplished with a non-regex, or simple wildcard search.
Globals. This is something that put me aback 6-7 years ago, when I made the leap into Unix programming, and traded C/REXX/CLIST for C/Perl/etc... COBOL is structured into divisions and all your data declarations are laid out and globally accessible. Though many COBOL systems are quite complex, with a "program" actually being a driver for a whole hierarchy of 20-40 sub-programs, and the necessity to restart at a given point in processing can make things quite complex.
Approvals, checkoffs, signoffs, and procedures. They're largely absent in the Unix (and most webdev work) world, but mainframers have grown accustomed to reams of authorization and approvals for even simple changes. Lead times of a week or more, along with VP signoff, QA signoff, user group signoff, fellow developer signoff, etc.... Even getting a downstream system to agree to test changes may take a formal request process and budgetary allocation of thousands of dollars. This is probably the biggest divide, and future schisms will be prevalent, as data center leadership trys to impose this kind of checks and balances on developers not accustomed to these obstacles. IBMs trouble and difficulty in the web server world offer a prime example -- business being told that it'll take 3-4 months to get a server online, and folks who know better just can't understand that.
Lack of user tools. A big part of what I did as a mainframer was building tools, using BTS and File-Aid to allow developers and testers to create their own test bed and automate the test process. On Unix side, the tools come with the OS, and awk, Perl, and all the other CLI goodies make automating testing a snap.
File in/File out vs. piping. Mainframers have a tendency to see everything as file-in/file-out. In a way so do *nix coders, but a seasoned *nix programmers sees the tools all being able to feed eachother. Rather than step1 filein fileout, step 2 sort filein, out fileout, step 3 filein, reportout, etc...
On the age thing, most of the really skilled mainframers now, like myself, do Unix or migrated to Java. Others are awaiting retirement, or head over to six sigma teams, business analyst roles, or seek refuge in management, escaping the axe that clears the way for the offshore coder.
Paper over softcopy. Got to have that printed listing, and the sticky notes (and before that, paper clips). I still remember a senior manager telling me when I first broke in how his appraisal of a programmer was how many fingers he needed to act as placeholders when he perused a program listing.
AZspot
First, I am not your typical Mainframe admin / programmer, as I am 27 and a relitave expert on mainframe constructs like JES, JCL, SMF, SMS, and RACF. From my 5 years of experience working in the mainframe operations group I've noticed the following differences and similarities from Linux (I'm a home user) and Windows (my work laptop):
- The mainframe is highly structured in it's change management procedures. This is an artifact of how long mainframes have been around. The procedures support the mainframe's goal of 24x7x365 uptime.
- Due to the high level of structure, there are usually at least 3 groups (often times many more depending on the size of the orginization) that are responsible for the mainframe: System programmers, Operators, and Application programmers. Each fills a very specific role in the operation of a mainframe system.
System programmers are typically responsible for the health of the operating system, and installing new system wide applications from vendors. The nearest match for system programmers is a Unix admin or windows admin.
Operators provide the 24x7x365 support aspect, making sure that the hardware is healthy, jobs are running, and important business applications remain available or come up on schedule. Operators may also be responsible for the scheduling package, and security. Again in the Unix world, this is equivalent to the system administrator. The operator position originated because mainframes at one time required people to run around and physically mount tapes and disk drives, and to spite automation that takes care of these tasks, the position remains.
The final group, application programmers, are what are most frequently though of when talking about a mainframe. They tend to work in languages like COBOL, CICS, DB2 stored procedures, and on occasion Asembly. Their role is to produce the online and batch applications that process the transactions that make the company money. App deveopers on the MF tend to be very carefull about testing code to ensure the proper result because first it could hurt the bottom line, but mroe importantly the operations group won't let it run in production with out assurances that it will run smoothly.
- Mainframes have been built from the begining for reliability, availability. scaleability, and performance. IBM accomplished this by virtualizing everything. This virtualization allowed IBM to have duplicate pieces of hardware internally double checking each other. For example, every instruction is run thru two physical CPU's at the same time, and if the result is different, the diagnostic code kicks in, disable the CPU that's incorrect, and calls IBM to replace it. This method of RASP is very different from what you see in the windows and unix world where multiple machines are load balanced with geographic redundancy, and if 1 box fails, the others pick it up.
- Operationally, in a windows or Unix/Linux world if you need to run sumething you just run it. In the mainframe context you submit it in a job to JES. JES (Job Execution Stream) is a resource manager that manages all the mainframe resources for executing jobs and tasks. The biggest difference is that on a mainframe yor job or task may not start running immediately if resources are not available, unlike Unix or Windows where it will start taking time away from already running tasks.
- Development on the mainframe is usually given very low priority for resources, in order to ensure that the production onlines and batch get everything that they need. Where Linux and Unix have 40 levels of priority (20 to -20) The mainframe has virtually unlimited priorities, because the system programmer jugles CPU, DASD (disk to the uninitiated), tape, and resource wait information to determine the real time priority of a particular task using relitavely sophisticated algorithms to do so. Because of this the system can be tuned very specifically to give the most resources to the tasks which earn the company the most money.
I am a *nix padawan, but, crocky technology asside, I'm frequently impressed by my Mainframe elders, their ability to deploy code to Production environments that works *the first time* nearly every time, and their ability to communictate technical changes necessary to fix broken code in the middle of the night in the 0.1% of cases where they failed to get it working first time.
Key values that I have picked up from my masters, and which should be inherrited by both *nix and PC/Mac enclaves are focused around Engineering principles. Mainframe guru's program like a civil engineer builds a bridge. No shortcuts are taken unless it can be proven that it is safe to do so. Testing is carried out in stages and test results must be submitted with the change request before a program migrates to Production. If a program must "abend" (Abnormal End) then it should do so noisily and with as much information as possible. If it finishes cleanly, little information is needed other than this fact.
These closely follow the advice Raymond has encoded in his book, but there is probably much more that your Mainframe gurus know that you should cherrish and extend to your newer team members.
Forget about the religious wars, the technology changes and the "focus" of your programmers on users or other programmers. Get the real truth from your Mainframe masters who have seen it all pass before them but have learned the hard way how to make a stable computer environment that stays up, even on cruddy mainframe technology. If their attitudes were adopted by people fluent in today's fantastic systems, all people would benefit.
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
I even worked with two Mac guys with beards
No, no... those are called "goatees".
No sig
The Windows admin washed his hands, then pulled out twelve paper towels and thoroughly dried both hands up to the wrists in two seconds flat.
The Unix admin took out one paper towel and very carefully, using every bit of dry towel, dried his hands perfectly in under one minute.
The Mainframe admin breezed through without stopping to wash his hands at all.
"Somewhere along the line" he said, "we learned not to piss on our fingers..."
Do not mock my vision of impractical footwear
Later that afternoon, the Mainframe admin got a horrific case of E.Coli poisoning from the handle of the urinal.
No, I don't trust in god. He'll have to pay up front, like everybody else.
I'm a mainframe sysprog but I've coded on Unix & Windows. I'm also rather young (33) for a mainframe sysprog. Here are the differences.
The first difference is the difference of work running on a system. Unix & Windows development typically takes place on dedicated machines. The changes are then applied to a separate production machine. On a mainframe development & production are often the same LPAR (Logical Partition) or the same physical box. Because of this development gets the low priority. If you run out of juice on a Unix/Windows box you either get a bigger one or you cluster them together. In the mainframe you either redesign it to run more efficiently or you start shelling out $$$ for a bigger machine. Normally your only choice is the redesign.
Software on a mainframe is horribly expensive and the faster the machine the more it usually costs. This is an old way of spreading the pain of software development. The big guys pay more because their machines are faster but the smaller guys get to pay less. Imagine if MicroSoft decided to charge a lot less for Office if you ran it on a P5 instead of the newest processor? Some software on Windows is licensed by the CPU, but I've never heard of the speed of the CPU being a factor. Do you think you'd get that fancy new PC if the software would cost 10x as much?
On a mainframe software development is a slow process with lots of checks along the way. Nobody just "slams in a change" unless they are either 100% sure it will work and it fixes a critical problem that is impacting business, or they want to be fired. Banks frown heavily on downtime. Unix & Windows systems seem to be more tolerant of this (with the odd exception being email - how email became the most important application is beyond me).
Once you develop, debug, and get a mainframe program running you can usually forget about it. There are programs running on mainframes today that haven't changed in 30 years. That is a pretty good return on investment. I've dealt with both and it seems to boil down to "pay me now or pay me later". Installing stuff on a mainframe take a lot of up front work but if you do it correctly you can expect it to work well when you are done. Windows programs are easier to install and develop but you have the constant reboot issues, memory leaks, and just plain annoying mysteries to deal with.
Mainframes (in my opinion) have far far far superior system diagnostic tools. If a program is running slow I can determine if it is CPU, disk, database contention, or any other resource shortage. This is mainly because there is so much running on any given mainframe that system diagnostic tools need to be very good. The tools on Unix and Windows are good but they don't need to be as complete because the environments are far less complex.
Program debugging tools on a mainframe can be awful. Interactive debuggers are the exception, not the norm. They tend to take up CPU which drive up software costs which the finance department hates. I've seen good interactive debuggers but they suck CPU and make the finance department hate you.
Batch controls on a mainframe are far superior to Unix or Windows. This is mainly because the mainframe started life as a batch system. Once you understand and master JCL it is really a good system. Batch on Unix and especially Windows is more of an after thought. You can run batch, but the tools to monitor failures, schedule dependencies, and validate results are not as good.
A programmer must know how a program is going to run on a mainframe long before you run it. You need to know how much disk, CPU, and memory you need and how man lines of output you are going to use. If you exceed this by too much your program will be automatically canceled. This is because you are not the only one using the system and if you exceeded what you said you needed your program could have a problem. That can be painful but it stops program loops if done properly.
The "just reb