Forgot your password?
typodupeerror
Operating Systems Software Unix Windows

What is Mainframe Culture? 691

Posted by Cliff
from the finding-common-ground dept.
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?"
This discussion has been archived. No new comments can be posted.

What is Mainframe Culture?

Comments Filter:
  • Simple (Score:5, Funny)

    by cloudkj (685320) on Monday July 18, 2005 @07:54PM (#13099343)
    What are the differences between Windows, Unix, and mainframe programmers?

    The latter groups of people are not afraid of the color blue.
  • An idea... (Score:5, Funny)

    by Anonymous Coward on Monday July 18, 2005 @07:55PM (#13099345)
    "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.
    • by cratermoon (765155) on Monday July 18, 2005 @08:16PM (#13099534) Homepage
      Only if you know where all the lineprinter porn resides!
    • by TiggertheMad (556308) on Monday July 18, 2005 @08:27PM (#13099610) Homepage Journal
      You could try exchanging porno links to one another, that seems to be the way nerds bond. Just a thought.

      You are sooooo right, and if you handn't posted as an AC, I would have sent you this sweet link, called goatse.cx, to cement our friendship.
  • My guess... (Score:5, Funny)

    by ShaniaTwain (197446) on Monday July 18, 2005 @07:56PM (#13099353) Homepage
    ..Punchcards, ENIAC tattoos and nipple piercings that look and spin like tape reels.
  • Cats (Score:4, Interesting)

    by infonography (566403) on Monday July 18, 2005 @07:57PM (#13099366) Homepage
    Herding Cats. Some are big, some are small, some aren't cats at all.
  • by Sebastopol (189276) on Monday July 18, 2005 @07:57PM (#13099368) Homepage
    "Giant Fucking Flamewar on /.: Story @ 11"

  • by JeiFuRi (888436) on Monday July 18, 2005 @07:58PM (#13099374)
    The thing that's really preserved the mainframe over the past couple of years has not been performance; it hasn't been throughput, because those things turn out to be terrible. It's been the set of operational practices that have been codified around it. Mainframe culture and rigorous "change control," contrasts with the PC server culture of "whiz kids" who never learned the basic operational rules necessary to avoid costly mistakes.
    • by ScentCone (795499) on Monday July 18, 2005 @08:01PM (#13099409)
      Why, in my day, we used stone punch cards we had to mine ourselves from the limestone quarry! Planning ahead made a lot of sense back then. Tell that to kids today, and they don't believe you!

      Seriously, I think the real problem is management addicted to immediate change in production systems. This started when it was web content, and now they expect back-office stuff to change just as quickly.
      • by twiddlingbits (707452) on Monday July 18, 2005 @10:30PM (#13100362)
        You had PUNCH CARDS? We wrote all our code in HARDWARE! We had to go to the iron ore mines, fight off the dragons, endure the bitter code, dig out our the iron ore, dig out the coal, build a fire, smelt the ore, and cast the little magnets in our core memory, find some lodestone, magnetize each core, then wire them together with the South end at the Top to be a Zero and the North to be a one. :)
    • You got it. Unix shops are learning lessons now the hard way that mainframe shops learned the hard way 40 years ago, and they're evolving the same answers.
      • You got that right... for years we had a VS1-MVS-XA-ESA-OS/390-z/OS environment with a parallel VM/370-VM/SP-VM/ESA environment for doing development. Our change control was simple, our sources were based on 80-byte records, etc. Our online environments were CICS and a few home-grown DMS/CMS applications, batch was predominantly PL/I with ISAM (and later VSAM) files. Then we brought in a DBMS with a 4GL and built-in TP monitor. (Model 204). Life was still pretty good, although we started writing REXX applic
    • I agree (Score:3, Interesting)

      by DogDude (805747)
      I didn't get into the industry until 10 years ago, and I was amazed at this difference between the windows kids and the mainframe guys. I was a Windows/Oracle developer, but luckily I learned good practices from old MVS/greenscreen guys who taught me things that hold true no matter what kind of computer platform you're working with. I'm blown away to see some of the stupid things that new programmers/admins do. Blown away.
      • Re:I agree (Score:4, Interesting)

        by spectecjr (31235) on Monday July 18, 2005 @09:45PM (#13100117) Homepage
        I didn't get into the industry until 10 years ago, and I was amazed at this difference between the windows kids and the mainframe guys. I was a Windows/Oracle developer, but luckily I learned good practices from old MVS/greenscreen guys who taught me things that hold true no matter what kind of computer platform you're working with. I'm blown away to see some of the stupid things that new programmers/admins do. Blown away

        I feel the same way whenever I look at the SMTP spec, the MIME spec, the SMTP email format spec, pretty much any on-the-wire specs actually...

        At the very least people could prefix strings they're transmitting with the # of bytes in them, so that memory access is efficient.

        Look at HTML - all ASCII. ASN.1 was invented so that you didn't have to use all ASCII for this kind of data (look at the SNMP spec if you want more details). But does anyone use it for the on-the-wire format? No.

        Unixheads seem to claim that it's perfectly admirable to hack around the ASCII format for everything because it makes it easier to debug, whereas all I see is wasted entropy and bandwidth.

        Anyway...
        • Re:I agree (Score:4, Insightful)

          by blane.bramble (133160) on Tuesday July 19, 2005 @06:07AM (#13101896) Homepage

          Unixheads seem to claim that it's perfectly admirable to hack around the ASCII format for everything because it makes it easier to debug, whereas all I see is wasted entropy and bandwidth.

          Wait until you have to troubleshoot issues with SMTP, POP3 and the like, then you will absolutely love the fact you can simply fire up telnet, connect to a server and manually test things by typing the protocol handshakes in. Not only are they all ASCII, they are easy to remember and make lots of sense.

          Take it from this SysAdmin/Programmer, you'll never want to go back to a binary protocol again.

    • Mainframe culture and rigorous "change control,"

      The best example of this is Documentation. From operator logs to the big IBM books - here you will find everything. Something named ICKDSF messing with your process? Go into the computer room or grab an IBM CD and look it up. Why did your process crash last night? Look at the operator log and find out it had to be killed because of a tape problem.

      Lack of documentation is what irks me most about the PC world.

      Now don't IEFBR14 reading Slashdot right after

    • I beg to differ. We have some pretty kickass pSeries machines and they don't come close to what our old Multiprise could turn out. Got to drop some students for non-payment? 2,000 to 4,000 records dropped in 20 min on mainframe vs 3-4 hours on the big UNIX Box. Mainframe systems EXCEL at I/O. They SUCK when they try and do computational heavy tasks. The mainframe we bought in 2000 did not even have floating point processors and it still performed better then our current solution. Mainframes DO kick
  • Faith Machine (Score:5, Insightful)

    by Doc Ruby (173196) on Monday July 18, 2005 @07:59PM (#13099384) Homepage Journal
    This "anonymous poster" has been managing mainframers for five years, is a Unix nerd, and doesn't already know how the three cultures are different? Or are they just a Windows troll, stoking the flames of the OS holy wars?
  • One difference (Score:5, Insightful)

    by Prof. Pi (199260) on Monday July 18, 2005 @07:59PM (#13099386)

    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).

    • Re:One difference (Score:4, Interesting)

      by BrynM (217883) * on Monday July 18, 2005 @08:11PM (#13099499) Homepage Journal
      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.
      You know, this is something that I have taken for granted for years. Thanks for making this point. Having done big iron, desktop and server programming has given me a definite edge in the past and I couldn't put my finger on it until your comment. The period I spent integrating some Alpha NT boxen to an S390 system (showing my age a little) really taught me a lot of versatility.
  • The difference (Score:5, Insightful)

    by Jeffrey Baker (6191) on Monday July 18, 2005 @08:00PM (#13099391)
    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?

    The difference is one programs Windows, one Unix, and one mainframes. As a fifth-year geek, you should take the rantings of Joel, ESR, and any other pointless windbag and send them to the bit bucket.

  • Good question. (Score:5, Insightful)

    by BrynM (217883) * on Monday July 18, 2005 @08:00PM (#13099395) Homepage Journal
    I'm a bit rusty on the mainframe side, but I'll give this a stab.

    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.

    • Unfortunately for the MF coder it happens a lot more often.

      I'm curious as to which definition of MF you're using...

    • Re:Good question. (Score:4, Interesting)

      by Knetzar (698216) on Monday July 18, 2005 @08:44PM (#13099710)
      As a windows programmer turned unix programmer turned unix operations support who just recently started working with mainframe operations, I would like to say your post seems to be right on. In addition in the mainframe world CPU utilization is everything. If your CPU is not above 90% utilization, then something is wrong. This is different then the Unix world where capacity planning is done so that expected peak CPU utilization is anywhere from 40-80%.
  • by pikine (771084) on Monday July 18, 2005 @08:02PM (#13099419) Journal
    For Unix devs:

    1. Learn to CamlCase your API, variable names, etc.
    2. Turn all '-' or '--' into '/' in command line arguments.
    3. Use 'dir' instead of 'ls -l'

    For Windows devs:

    1. Learn to lowercase all your API, variable names, etc.
    2. Turn all '/' into '-' or '--' in command line arguments.
    3. Use 'ls -l' instead of 'dir'
  • A summary: (Score:5, Funny)

    by millennial (830897) on Monday July 18, 2005 @08:03PM (#13099422) Journal
    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.
    • by Tackhead (54550) on Monday July 18, 2005 @09:26PM (#13099994)
      > 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.

      Corollary for end users - and yes, my Dad's first email message to me was indeed sent in all caps:

      MAINFRAME USERS THINK THAT USING ALL CAPS WHEN SENDING MEMOS IS PERFECTLY NORMAL
      Linux users think that using all caps in email is YELLING.
      windows users dont no how 2 use nething but there im proggy

  • by billstewart (78916) on Monday July 18, 2005 @08:03PM (#13099431) Journal
    Hey, I was a TSO wizard back in ~1980, but fortunately I haven't had to use that stuff in ages :-) However, you'll find that mainframe programmers mostly look like Sid in Userfriendly.org - either grey hair or no hair. Mainframe programmers, like Unix and Windows programmers, range from the old wizard who can answer really arcane questions about JCL syntax from memory to some Cobol drone who went to trade school, like the Visual Basic trade school drones of today.

    The reasons mainframes are interesting, to the extent that they are, is that they can handle very large databases with very high reliability, which is not the same as being fast (though some of IBM's newer mainframe products are also quite fast.) That means there's a heavy emphasis on building and following processes for deployment and operations so that things won't break, ever, at all, even when the backup system's down for maintenance, and on building processes to feed data in and out of this rather hostile box so every bit gets bashed like it's supposed to. The programming environments have gotten better, but you're looking at a level of flexibility like Debian's Oldest-and-most-stable releases, not like Debian sid.

  • by Sponge Bath (413667) on Monday July 18, 2005 @08:04PM (#13099440)
    What are the differences between Windows, Unix, and mainframe programmers?

    The length of the beard?

  • by HermanAB (661181) on Monday July 18, 2005 @08:06PM (#13099454)
    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...
    • Reboot away (Score:3, Funny)

      by apankrat (314147)
      Simulation result will still be 42
    • Re:Don't reboot (Score:3, Interesting)

      by Detritus (11846)
      That's assuming that you have access to the machine. I've run jobs on mainframes that I've never seen. I'd just drop off the job at the service desk and pick it up the next day. The mainframe was in a restricted area, where users and programmers were not allowed without an escort and a good reason to be there.
  • simple (Score:3, Funny)

    by b17bmbr (608864) on Monday July 18, 2005 @08:06PM (#13099461)
    windows programmers have to learn completely new shit every two years. unix programmers keep programming the same shit year after year.

    laugh. it's a joke.
  • On the difference (Score:5, Insightful)

    by Tsiangkun (746511) on Monday July 18, 2005 @08:07PM (#13099465) Homepage
    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.
  • Programming in COBOL (Score:5, Interesting)

    by cratermoon (765155) on Monday July 18, 2005 @08:09PM (#13099479) Homepage
    I've never actually written any COBOL myself, but here's what I've learned from trying to teach Java to former mainframe developers.
    • COBOL is actually remarkably like wordy assembly language
    • The typical mainframe programmer, being steeped in COBOL, will think of everything in "records".
    • Mainframes are case-preserving but case-insentive. Like DOS, a token can be any mixture of case an it will work. Thus, a mainframer might wonder why 'PRINTF' doesn't work for 'printf'.
    • On the same topic, a mainframer will assume that something like the Java type 'Account' and the variable 'account' actually don't distinguish anything, and will be confused when the compiler refuses to assign to a type.
    • MOVE CORRESPONDING is COBOL's big hammer. It will take all the values of the elements of one record and copy them to the "corresponding" fields of another record. There is nothing like type-checking for this. This will cause mainframers to be confused about why you can't assign a linked list to an array and have it "just work".
    • Not that mainframers will grasp "linked list" or "array". Actually, they won't really get any of what we call the standard data structures and algorithms learned in the first year of any CS program.
    • COBOL programs have no scoping rules. EVERYTHING is global. Thus, a mainframe programmer won't understand why an assignment way over in some little function in another library to a variable called "date" won't affect the "date" value in the code everywhere.
  • M/F is just a job (Score:5, Interesting)

    by ThePolkapunk (826529) on Monday July 18, 2005 @08:10PM (#13099480) Homepage
    As a *nix programmer forced into the mainframe world, I'd have to say that m/f programmers do not look at computers as a hobby or thing of interest. To them, programming and computers are just what they do to get paid. To the m/fers, a computer is just a tool that they have to use to do their job. They take no joy or pleasure in programming, it's just what they do.

    On the other side of the coin, I think that *nix and Windows programmers tend to enjoy what they do. To them, programming is not just their job, it's enjoyable.

    Honestly, I don't blame them. M/F sucks. As soon as you get your first compile error because your command isn't in the right column, or have JCL spit out a bunch of random nonsense because you didn't allocate the correct blocksize for your file you'll hate your job too.
    • by symbolic (11752)
      or have JCL spit out a bunch of random nonsense because you didn't allocate the correct blocksize for your file you'll hate your job too.

      That's all it takes to hate your job? Ever get an error compiling a C++ app using templates, or a highly abstracted java class with an error generated somewhere, causing a problem somewhere else? These don't exactly put the joy *into* programming.
  • by SuperKendall (25149) * on Monday July 18, 2005 @08:14PM (#13099521)
    From the article:

    *Unix Programmers* don't like GUIs much, except as lipstick painted cleanly on top of textual programs, and they don't like binary file formats. This is because a textual interface is easier to program against than, say, a GUI interface, which is almost impossible to program against unless some other provisions are made, like a built-in scripting language.

    I would disagree with this assesment, instead I would say people who prefer textual interfaces do so beacuse they often offer a much denser display of information. You can get a lot of information packed into text that may be quite spread out in a GUI.

    Also I would say that people eventually come to favor programs with scripting interfaces.

    It seems to me that as users grow more sophisticated eventually all users become programmers in at least a specific domain, or at least desire to. All users grow used to a tool, and after a while they start wanting more dense an informative displays.

    Just look at PhotoShop, probably one of the longest running commercial applcations (i'm sure there are others that elude me but it's just a really good example). Does that even follow any kind of UI guideline? No it does not; there are so many users that have used it for so long, that they demand a richer and more complex interface. Over time they demanded plugins and then of course scriptability (through actions).

    Yes Windows was a way to bring many people into computers that could not have come through UNIX. But in the long run users grow into wanting more flexible uses of the computer and they start leaning towards the "UNIX Way" and looking for apps that are pluggable and scriptable.

  • by AtariAmarok (451306) on Monday July 18, 2005 @08:15PM (#13099526)
    Just look at the tools in the trunk of their cars. The Linux and Windoze guys will have a few screwdrivers rolling around there. The mainframe guys have blowtorches.
  • by GoofyBoy (44399) on Monday July 18, 2005 @08:18PM (#13099550) Journal
    Where the control-key modifier is in Unix, the Enter/Return (one of these) is in Mainframes, is the wavey flag is in Windows.
  • a few observations (Score:4, Interesting)

    by porky_pig_jr (129948) on Monday July 18, 2005 @08:21PM (#13099566)
    I was working with IBM MVS (batch oriented) and VM (interactive) for quite a while. At that time the main choice was between COBOL and Assembly Language (BAL/370). COBOL provided some basic routines, but do to something interesting (like asynch I/O, your own memory management, etc) you had to use BAL.

    The following example might be interesting, not sure if helpful. On batch system you have many jobs executing concurrently. MVS (at that time) didn't have anything like preemptive multitasking. COBOL didn't have asynch I/O either, so when it issues I/O it just goes into a wait state, so another task is scheduled. So the bottom line was that your program won't be very efficient (e.g., won't be overlapping I/O and CPU activites), but that would create a nice (from MVS perspective) mix of jobs. Some are doing I/O, some are doing CPU, so MVS can accomodate many concurrent tasks.

    Well, at that time I was budding assembly language programmer and even took a course at university where we had to write our own operating system, entirely in BAL/370, including the Initial Program Loader (boot, if you wish). I was working at the same time, and there was a problem at my job. They (John Hancock Insurance) had hundreds and hundreds of COBOL programs, and nothing like cross-referencing dictionary, like which program modifies some common record fields. So when something unexpected happened, they had to search through the source code, to find all the instances of such references and that was taking something like 5-6 hours. I've learned asynch I/O at school and how to overlap I/O and CPU activites, and I've ended up writing fairly efficient program. Program was reading large chunks of disk data into several buffers. As soon as the first buffer was full, that event was detected, and the program starts parsing that buffer for some keywords --- while continuing reading the tracks into other buffers. (it was a circular list of buffers). After some trials I got the execution time down to less than 20 minutes. Everyone in my area was happy.

    Everyone except mainframe operators. I've been told they HATED my program to its guts. The problem was that the program didn't behave nice as far as 'good mix' is concerned. It grabbed the resources and hold them for a long time because it went to the wait state only occasionally. But that was a great help for production problems, so they had to let it run.

    That was many years ago. I don't know if MVS got changed so to introduce preemptive multitasking. At that time it was a strictly batch-oriented system. All I/O was executed in a separate subsystems (channels). To run something interactive (like CICS) wasn't trivial at all. The best strategy was to dedicate entire mainframe to such task. Mixing CICS and batch jobs int the same machine was suboptimal solution. Of course, MVS scheduler got improved since, to provide better balancing between batch and interactive tasks, and yet, as I understand, MVS fundamentally remains batch operating system.
    • That story takes me back.

      My first day as an operator, they had me printing on the old Xerox 9790. I was happily typing jobs into the queue via JES2 with $pprt2. The whole system froze about a 15 minutes in. Panic ensued, but nobody - especially me - knew what happened. They sent me to lunch while systems, the HSM guys and the operators tried to figure it out.

      When I got back everything was fine and there was a big "$P" on my locker. I flubbed a key and typed in $P which is the command to halt JES2 (yes, sys

      • Hmm, we were doing Spice simulations on a Sperry-Univac - friend of mine forgot to add a maximum pages command to limit the printouts in case of an error and read his stack of punch cards, then waited and waited and waited.

        Eventually, he ran it again and was just about to run for the third time, when the elevator door opened and in rolled a trolley full of paper from the high speed printer in the basement...
  • Mainframe guys don't reboot their system. Unix guys reboot the system occasionally. Windows guys reboot their machine several times a week.
    • by antispam_ben (591349) on Monday July 18, 2005 @10:36PM (#13100386) Journal
      Mainframe guys don't reboot their system.

      They don't call it reboot, they call it a "re-IPL" [Initial Program Load] and depending on the machine it takes up to 30+ people, each with specialized knowledge about a specific part of the process. [you can mod me funny, but THIS IS NOT A JOKE]

      Unix guys reboot the system occasionally.

      Only because of a hardware upgrade, and only because the technician convinces them it REALLY DOES need to be turned off to add more RAM or a (non-hot-swap) disk drive.

      Windows guys reboot their machine several times a week.

      "Several" in this context is a number greater than ten. A boot often lasts through the day, but not always. But I remember the 3.1 days (it shudda been called "three point one over six point two two"), it was boot-in-the-morning and reboot-after-lunch, as well as many other times.
  • by DynaSoar (714234) * on Monday July 18, 2005 @08:31PM (#13099631) Journal
    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.
  • by crazyphilman (609923) on Monday July 18, 2005 @08:35PM (#13099649) Journal
    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!

  • by rewt66 (738525) on Monday July 18, 2005 @08:39PM (#13099684)
    When a mainframe becomes loaded with spyware, you do not throw it in the dumpster!
  • Ask (Score:3, Funny)

    by kevin_conaway (585204) on Monday July 18, 2005 @08:43PM (#13099705) Homepage
    Ask your team, also known as the entire mainframe community
  • by WindBourne (631190) on Monday July 18, 2005 @08:44PM (#13099714) Journal
    First note that Windows/Mainframers tend to be CISers,

    while Unix ppl are CS/EE. Differences between CS, CIS, and EE.
    For any given project,
    • Project will take 1 year with 40 ppl working on it.
    • After 1 year, it will take another year, if they double the team, otherwise cancel the project.
    • At the end of 2 years, the program will run in length 1 day - 1 week (just a relative time).
    • a number of bugs will be found, of which, by hiring more ppl, these bugs will only take another 1-2 years to iron out.
    • Every line of code will be documented, but many of them will be incorrect, such asi += 5; // call sub routine a()
    • In addition, somebody will have attempted to use hungarian notation but most will not match the code.
    • For the CISers on the mainframe, there is more of a mind set that the system can not be allowed to be down for any reason.
    • For the CISers on the windows boxes, the mindset will be that if the users want 24x7 uptime, then they need to talk to the system admins/operators, or the maintence coders.

    For the CSers mostly on Unix, for the same project
    • It will take 3 ppl exactly 1 month.
    • At the end of one month, it will be just another month. repeated for about 3 more months (grand total of 4 times).
    • At the end, of this, it will run in under 1 minute of time (relative to the above).
    • However, just before the end of the 1 minute, it will crash.
    • Upon your complaining, they will say to write a bug report about it. Of course, when you do, they announce that they will get to it, when they have completed their current 1 month project (see above for timeline).
    • The docs will be few, but will be accurate. But spartan is very much the word until a documenter is hired.
    • The code will be the cleanist and with fewest bugs, but all bugs will be wicked hard to find.

    EE are interesting.
    • after studying the situation for several months, They will tell you that it will take 15 ppl 4 months. Upon the 4th month, at the stroke of midnight, they will deliver the code.
    • It will run in about 10 min. - 1 hour of time. There will be some minor bugs.
    • If you read it will be sloppy. In addition, several sections will have been moved to horrible designed assembler (or possibly even a hardware solution). That allows them to get around bad designs.
    • There will be reams of docs. It will be very accurate, but it will go into a 5 paragraph description of why a i += 1was used in placed of a ++i ( SHORT ANSWER; becuase ++ was a shortcut on the old PDP7 and was only used for pointers, whereas the += conveys the sense of a non-pointer).
    • When you want to file a bug report, it will cost you money to file it. Then the actual bug fix will cost more than the original code, but slightly less than having somebody else do it.

    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)
  • by gvc (167165) on Monday July 18, 2005 @08:50PM (#13099752)
    I've done a lot of mainframe development and a lot of Unix/Linux development; scarcely any Windows.

    The main difference I see between mainframe development and *ix development culture is respect. With the mainframe you have to book time days in advance and work in the wee hours to make any changes. And you make damned sure that, when you're done, things work as they should.

    With *ix development, things are laissez-faire. You send out a message a few hours/days/minutes in advance of some monumental change. Then you blame the users when they can't sign on to their system in the morning. Quote some recently-adopted standards if they argue.

    Of course, I'm speaking of the early days of *ix. These systems are more and more critical, and the admins are trying to learn respect. But they're playing catch-up. There's nothing like the fear of taking down a $500/minute system to make you careful.

    Windows development follows a similar pattern. The whole culture is so "personal computer" based that the concept of a year's continuous uptime is foreign.
  • by dhuff (42785) on Monday July 18, 2005 @09:01PM (#13099833)
    I worked around some mainframe programmers for several years at a major bank, and they strike me as being much more like older Unix geeks than anything else, with some important differences:

    • They're probably much more politically conservative
    • They may wear much more conservative clothing, incl. stuff like neckties, but it'll still be grubby and ill-fitting
    • They probably drive a midsize, American sedan like a Ford or GM product
    • They generally have poor health habits, but lean more towards the old fashioned vices like coffee (from the office coffeemaker, not Starbucks) and cigarettes - diet is also poor
    • They obsess over uptime and reliability way more than Windows or even Unix geeks
    • They most likely don't have the typical geek interests like Star Trek, computer games or reading Slashdot :)


    But I bet you'll notice a core psychology that's pretty familiar to most geeks...
  • by Naum (166466) on Monday July 18, 2005 @09:02PM (#13099853) Homepage Journal
    Dating back to Burroughs machines and managers who didn't know how to use a text editor, preferring to use punched cards and "punched card emulation", but yet they could do a randomizer calculation without a calculator in their head within a second or two.

    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.

  • Mainframe culture (Score:5, Informative)

    by asdef (261823) on Monday July 18, 2005 @09:07PM (#13099876)
    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.
  • by toby (759) * on Monday July 18, 2005 @09:17PM (#13099933) Homepage Journal
    One of the strangest (and scariest) things I've observed have been old "mainframe" guys who've embraced "The Micro$oft Way" when it clearly goes against every principle enshrined in the old days. You know, old-fashioned ideas like efficiency, reliability, availability.

    You'd think they'd run from Windoze as fast as they can. But no -- perhaps because of some vague VMS gene still running around in 'doze -- they occasionally take to it like babes to the teat.

    These guys do exist. I've heard one recently defend VSS as a reasonable source code control system -- when Micro$oft themselves won't touch it, and the following remark has been attributed [wadhome.org] to a M$ employee:

    "Visual SourceSafe? It would be safer to print out all your code, run it through a shredder, and set it on fire." -Fitz

    Another one of these mainframer-turned-M$-nut dudes tried to explain to me that M$ is "redesigning the internet to use binary protocols" because "text formats obviously don't work" and are "breaking everything". He also believes Apple should be annihilated because they stand in the way of a total monoculture -- and he sees monoculture as necessary to achieve our "Star Trek future". The fact that he foresees a smoothly running galaxy running Windoze Everywhere is just plain amusing.

    Buddy, if the future is like Star Trek, I don't want any damn part of it. Diversity is Life.

  • by sinewalker (686056) on Monday July 18, 2005 @09:52PM (#13100158) Homepage
    Appart from the obvious religious stuff about GUI (or lack of) and user-centred interfaces (or lack of), the biggest difference, and the biggest advantage that Mainframe brings is it's culture of process and change control. It is something you should strive to let your Mainframe masters pass on to the *nix/windoze padawans before they die of old age.

    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.

  • Two good sources (Score:3, Informative)

    by jbolden (176878) on Monday July 18, 2005 @10:28PM (#13100353) Homepage
    Thought I'd mention two sources for this that I think are worthwhile.

    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.
  • by GomezAdams (679726) on Monday July 18, 2005 @11:09PM (#13100531)
    Most of the mainframers that I have worked with are nine to fivers and many didn't have a PC at home or do much more than check emails when they do. They don't code routines at home to expand their work capabilities and many think that if it doesn't weigh 6 tonne and need 10 keepers and an air conditioning plant, you can't call it a computer. Most depend on the fact that their arcane skills aren't taught any more and that's all the job security they need.
  • The difference IMHO (Score:5, Interesting)

    by FJ (18034) on Tuesday July 19, 2005 @03:44AM (#13101580)
    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
  • by Ann Elk (668880) on Tuesday July 19, 2005 @03:29PM (#13106217)

    Years ago, I worked with a grizzled old mainframe veteran. Let's call him Dan. Earlier in his career, Dan ran the datacenters at American Express and FedEx. Dan knew big iron.

    One day, a few of us were ooh-ing and ahh-ing over the latest whiz-bang quad-Alpha box. Dan just laughed, shook his head, and said:

    If it ain't water-cooled, it's just a terminal.

What is wanted is not the will to believe, but the will to find out, which is the exact opposite. -- Bertrand Russell, "Skeptical Essays", 1928

Working...