What is Mainframe Culture? 691
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?"
simple to explain (Score:2, Informative)
Unix programmers have to seperate the program into 60 different modules that all do their own thing and are called by a main program that uses all the modules to attempt to make the task work, they AVOID gui like it is walking death.
Mainfraime programmers will take weeks to decide how to start the project, endless flowcharts, argumetns about the architecture and finally when code is written it willtake months on end to test it well beyond reason before they let you even see it run.
good luck
Typical Spolsky (Score:1, Informative)
But this isn't always considered good, examples:
BSD::useradd
linux::mke2fs
linux::rp
linux::wget
linux::proz
In fact, in other chapters Raymond talks about the 7/10ths of a second rule. That says that the most time your program should be quiet, usually, is 7/10ths of a second. It makes sense, especially on the command line and slightly less in the gui, because that's about how much time the most impatient people can't stand to wait. And it's about how long it takes people to think "teh omg it's teh uberlox0red."
I've read Joel's book by the way; and he seems to contradict himself a lot with many great insights. In fact, he's a very smart guy with amazing insight; it's connecting it into a final conclusion and removing the thoughts that were just wrong that he's terrible at.
In other words: Provide your own conclusion for Joel's ideas; his conclusion is almost invariably based on an incomplete set of facts.
The difference between Unix and Windows cultures are many, and the technical differences show up. In fact, Joel talks about that in his book (which is just his blog on paper). But of course, here he says they're technically the same (sure, if you only look at kernel level things and gloss over higher stuff at such a distance that a dog looks like a cat).
By the way, this is so old it's in his book!
Re:Interoperability (Score:2, Informative)
A couple of comments (Score:1, Informative)
MF world is very different.
Dataspaces are shared by default - and are often owned by the application type rather than a user. And space is measured very differently (often blocks rather than kbytes).
Not that this bothers the MF. Their job is to write a script (it's closer to a script than a program) to rip thus dataspace A, do something, and print the results to B.
Tools? Provided by the OS. And more study is needed to master than unix tools (imo).
If you think about data structures (or classes) you're in a different world the MF. They think about records (rows in that dataset).
Ever write a sort routine? Know the difference between bubble-sort and quick-sort? The average MF doesn't. He calls the system level command SORT and he's done.
And don't get me started on EBCDIC
Re:Everything Old Is Old Again (Score:3, Informative)
Lack of documentation is what irks me most about the PC world.
Now don't IEFBR14 reading Slashdot right after work so much ;)
The Tao of Programmers (Score:5, Informative)
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.
Differences that I have seen over the years (Score:3, Informative)
while Unix ppl are CS/EE. Differences between CS, CIS, and EE.
For any given project,
For the CSers mostly on Unix, for the same project
EE are interesting.
So how do you manage them?
CISers; Lousy design/code, but good report with customers. Politicians.
CSers; great design/code, lousy time-lines/documents. Lousy with Custmer support
EEers; great time-lines, lousy code design, but will code around the issues. Long term maintence is bad. Professional with customer (like mainframers)
Re:my 2 cents (Score:5, Informative)
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
Mainframe culture (Score:5, Informative)
- 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.
Re:Everything Old Is Old Again (Score:3, Informative)
Re:The Difference (Score:4, Informative)
No, the whole point of an operating system is to provide a stable programming target and perform resource management.
Two good sources (Score:3, Informative)
The first is a great article [perl.com] about what the differences between mainframe programers and Unixy programmers. The second is a book [amazon.com] designed to teach mainframers to operate in a Unix environment. The article is definitely worth a look for anyone interested in this topic.
Mainframe hacks (Score:1, Informative)
Versioning was a lot easier on mainframes. You just applied the updates when and where you wanted them. Merging something from a branch to the main trunk in CVS is a nightmare if you didn't get the tags just right or forget to put tags in to begin with.
Mainframe programmers generally never get root privileges so they learned how to get along without it. Windows programmers are on the other extreme. They can't do anything without root. Unix is somewhere in the middle.
Mainframes have something called system programmers which is something like a unix admin but different. It's the same in the sense that what they did required special privileges. Mainframes always had much better security and much more scheduling and resource control than unix. Unix still looks like a toy in that regard.
Re:a few observations (Score:2, Informative)
Re:The Difference (Score:5, Informative)
Re:Whoops! (Score:3, Informative)
Re:The Difference (Score:2, Informative)
And as always linux is ahead of the curve overall then windows (in the kernal) at all times. and runs on more system.
Correct me if I'm wrong, but the Linux kernel was funneled until fairly recently (like 2.4 or something), was it not? OS X was dual funneled until 10.4, IIRC. As far as I'm aware, NT has never had any kind of funnels, and the kernel has always (back at 1993, or whenever it was that 3.1 came out) been reentrant and SMP-capable. Could you perhaps be a bit more specific than "sucked ass at it"?
Oh, and it's not really important, but NT was originally intended (and designed) to support up to 32 processors, although I've not heard of any NT machines with more than 8.
Re:Simple (Score:3, Informative)
Now as far as security, I'd say mainframe security is 99% security by obscurity. The mainframe programmers I know are hopelessly naive about network security policy, basic things a Windows or Unix admin would know from working in a hostile environment like the Internet. You know, things like password policy, IP networking, etc.
Re:Simple (Score:3, Informative)
And the System Programmers and Operations Managers who buy packages like Fastpath and Harbor NSM.
If applications themselves are stable, it's probably a result of COBOL being a straighforward procedural language without all the trickiness of C pointers.
Thank $DEITY I'm not the only person to think so...
Now as far as security, I'd say mainframe security is 99% security by obscurity. The mainframe programmers I know are hopelessly naive about network security policy, basic things a Windows or Unix admin would know from working in a hostile environment like the Internet. You know, things like password policy, IP networking, etc.
How many black hats can get into a mainframe, anyway, and know the mainframe utilities?
Difference in terminal users expectations (Score:2, Informative)
When the screen was ready, all the page was transmitted to the computer. This scheme allowed to have sometimes 8000 terminals and over on a 8MB (yes!) machine.
Incidentally, terminals did have lowercase letters and dead keys for national languages from 1978 on with the 3278 line. This was not hard to implement : just an extended ROM to display the characters on the 3278, and a slight change in microcode to handle the dead keys on the 3274 or 3174 control unit.
Why you need to wash your hands (Score:4, Informative)
http://www.straightdope.com/classics/a4_220.html [straightdope.com]
Keep washing those hands, kids!
Re:Cats (Score:3, Informative)
Heh. When I 1st used VMS, it was after being an MS-DOS user for a few years, and seperately, an MS-DOS & DOS/VSE progammer for a couple of years.
I thought I had died & gone to heaven! The interactivity of MS-DOS & the richness of the m/f all wrapped into one perfect package.
The most annoying things about VMS - to a UNIX geek - are
Unix was very strange to me, with it's cryptic commands and *ix could definitely learn a thing or 20 from the VMS command-line parser, like only having to type in a maximum of 4 characters for each command and option, even when it's a long command like DIRECTORY.
But bash & grep have grown on me and DCL is really showing it's age.
Re:Mainframe culture (Score:1, Informative)
Each instruction runs on two CPUs sharing the same die. When the CPUs disagree, the die/module is flagged as faulty and the OS re-schedules the task on a new CPU pair.
Since all CPUs come in pairs, it doesn't matter which execution unit failed: both get replaced.