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?"
Windows programmers work from the assumption that their job is to protect users from the machine.
Mainframe programmers work from the assumption that their job is to protect the machine from users.
Unix programmers work from the assumption that they're the users and the only protection they or anyone else needs is knowing enough about what they're doing. They also work from the assumption that "enough" means "as much as I know", no matter how much or little they know.
2/3 of Macintosh programmers think the same as Windows programmers. The other guy doesn't think about it.
I'm still an Apple II programmer. I still think it's a good idea, and necessary, for everyone to be able to program down to bare metal, because it's only for showing off what you can do since everyone is going to do their own programming anyway. At this point I believe that the only way I'll ever see any Apple II op code coming from anybody else would be if that's what they decode from the SETI signals.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
Unix is process-centric. Windows is thread-centric. This is also an artifact of GUI programming. For example the GUI should never stall by processing a request. Instead it should fork off a thread
:-)
This has nothing to do with GUI programming and everything to do with the cost of creating a process on NT. People began abusing threads because it was so painful to use processes.
Most unix apps don't use threading. This is not for lack of threading or knowledge of how to use threads. It's simply that processes are as cheap as threads and offer more protection.
Nearly all Windows development involves a GUI. This is usually done with an event-driven API. On the other hand, many Unix geeks probably never program in the event-driven paradigm.
Long before Windows existed, X-Windows had a callback, event driven mechanism for GUI programming. This resulted in considerably better performance than the message mechanism used in Win16 (which was carried over to Win32).
The reason for using messages in Win16 was simple--there was no real multitasking. Context switches didn't exist so there was no difference in having a process handle events it cared about verses every possible event (with a standard default handler).
The problem with most Windows developers is that they don't understand the history of Windows. They pick up things like "event-driven paradigm" as if it was some great innovation that makes their lives easier. That my friend, is the power of marketing
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.
Isn't the whole point of an operating system to allow programmers to make that assumption?
No, the whole point of an operating system is to provide a stable programming target and perform resource management.
Unisys sells 32 CPU windows boxes, HP sells up to 128 CPU Superdomes capable of running Windows 2003 Datacenter edition, and there's probably some others I'm not aware of. Since quite a few companies have high end systems using Itanium 2 processor's there's very little reason not to support windows server, it just might sell some more units =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
http://www.straightdope.com/classics/a4_220.html
Keep washing those hands, kids!