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.
Windows programmers program as fast as possible to maximize profit ignoring the reprecussions of bad programming while Unix programmers take pride in their product.
..Punchcards, ENIAC tattoos and nipple piercings that look and spin like tape reels.
Starsucks
Or maybe beards?
Herding Cats. Some are big, some are small, some aren't cats at all.
Sorry about the writing. Robot fingers, you know? Cliff Steele in DOOM PATROL #23
"Giant Fucking Flamewar on /.: Story @ 11"
https://www.accountkiller.com/removal-requested
What do you all need to know to get along in each other's worlds?
1. Windows bad
2. Unix good
3. Linux better
This is Slashdot, what kind of response did you think he was going to get?
The preceding message was based on actual events. Only the names, locations and events have been changed.
The difference is single threaded and multi threaded...Unix programmers know that they have to assume that they could be walking over someone else's session info.
Windows programmers always seem to assume they are alone in the computing ether.
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.
Dupes and 404 errors!
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?
--
make install -not war
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).
windows developers half ass everything. they curl up in a ball and cry if they cant use an IDE to do everything.
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
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.
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...)
It's a lot of great insights into something the author wasn't saying. He rips the idea that a program should output well formatted parsible text and be generous with what it accepts as a general rule and pretends it's seen as an absolute rule.m #provides a lot of pretty output options
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!
Coral:
Joey On Software
Eric S. Raymond
Art of Unix Programming, The
Culture discussion (Unix/Windows)
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. - Edsger Dijkstra That said, mainframe/cobol programmers are just second grade grammar teachers posing as computer programmers
www.notesmax.com
can easily program for all of those systems.
So there is no difference. There programmers and non-programmers. Some non-programemrs don't program at all, others pretend they do. Programmers will quickly adapt to any operating system. One of those groups has a future, and the other one does not.
The AACS key is NOT 0xF606EEFD628B1CA427BEA93A9CA9773F
This is *so* true of my UNIX brethren.
While windows programmers arguably have better tools with which to develop, the UNIX users rely on "just get it done and tell me if there are issues".
The most important quality IMO is to create an environment with HIGH interoperability. Let your Windows users do what they do, while giving your UNIX and mainframe users have their world like they want it.
You mix it all together and have a nice product.
The one thing I, as a microcomputer (not neccessarily limited to Windows, just forced there by the market) programmer have never understood: The propensity of mainframe programmers to output huge numbers of columns of text for import/export files. At the state agency that I currently am contracting at, I've seen 200-300 columns of data in basically position delimited flat file format, which gets imported into 20-30 tables of relational data. I never understood this until I RTFA'd- and now I understand- they're going for least common denominator probably due to the huge amounts of storage available on a mainframe.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
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'
I once had a signature.
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.
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?"
/usr/bin/ and X11 never really caught on. If you don't know the answer to why Linux's giant wardrobe computiting mentality is not compatible with life for 99% of people then what is the point.
The fact that you even have to ask shows that you haven't a clue. Linux and other hardcore Unix users will die wondering what it was all about and why things like command lines,
Windows: best-balanced
Unix: smarter
Linux: uglier
Mainframe: older
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
The length of the beard?
Mainframe Programmers are RETAAAAADED!
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...
Mainframe programmers are non-creative, repetitive programmers. They don't know how to do anything new. It is tha same rehshed, crappy stuffy code, over and over again. All they know are flat files and copybooks. Best thing to do is to unplug the mainframe. At least it will help stave off global warming.
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.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
My past experience was that you tend to think in terms of queues; you (physically) queue up for the keypunch, submit your job to a queue, and go find the appropriate print queue the data came back off from. The other experience has always been (Unicos, VM/XA or VM/CMS systems) that the software environment is antiquated to the point where you're encouraged to do as much off-line as possible. Get in, do work, get out.
The computer, therefore, is a far more abstract, remote, and non-interactive object. I remember what an unpleasant change moving from an 11/785 running VMS to a 3090/VF running VM/CMS. The programming tools were arcane, the OS didn't even have subdirectories (it did have minidisks; i.e. your own virtual pile of floppy disks), and the editors definitely underwhelming. On the other hand, like a VAX/VMS system, the queueing system was an integral part of the OS, so it worked smoothly, as opposed to the unix solutions that are bolted on the side as an after thought. Sun Grid Engine and LSF are pretty close to the old VAX queues, but still not quite as well integrated.
This, of course, is not entirely fair, as large VMS systems were used like mainframes, but still had good tools and a friendly user environment. In the end, think of it generally as a tightly-regulated, non-interactive environment. It's the kind of environment for utter reliability, where it's primarily computers talking to other computers.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
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.
Crispin
Here... Go ahead, Slashdot my File Farmer account. Got it for free.
EvilCON - Made Famous by
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.
Dear diary: Today I stuffed some dolls full of dead rats I put in the blender.
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 don't respond to AC's.
Not even the mainframe peeps seem to get this right!
rgds
With all the talk about dupes going around, I thought we should pat the editors on the back and proudly proclaim: This story is most decidedly not a dupe! It's the first story in hours that isn't, but... If we praise good story selection, they just might learn...
Windows Programmers are from Omicron Persei 7, as *nix users are from Omicron Persei 9?
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
- You can link them together.
- You have access to hundreds or thousands of commands in one window. No wending your way through endless menus and submenus.
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.
Don't blame Durga. I voted for Centauri.
HA HA You Suck At Teh Manager!!onei!
I don't keep a lid on my coffee so when I walk around I look busy -me
That is not the best assumption, as the Windows app is likely to be running alongside Bonzi Buddie and at least 7,000 pieces of malware and virii.
Don't blame Durga. I voted for Centauri.
Where the control-key modifier is in Unix, the Enter/Return (one of these) is in Mainframes, is the wavey flag is in Windows.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
How do you post something from December 14, 2003, and get away with calling it news for nerds?
No existe.
If you can understand the other side, the label doesn't fit in the first place. The label is an indication of narrowmindedness all in itself. My $.02.
So, rather than asking how to get along, be openminded enough about different ways of thinking (or not) and the world will sort itself out.
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.
Mainframe guys don't reboot their system. Unix guys reboot the system occasionally. Windows guys reboot their machine several times a week.
Mainframers are a sad lot, stuck with all those tools that actually work, and consistently.
... 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!
if you're from Windows or Unix you think of systems as I have this much data space, I write these programs, I execute this, etc.
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
So, basically, to summarize his blog entry...
linux for nerds, windows for dumbasses
Not to say it's was a bad article, it's a good read, but I couldn't find any new insights into this over-discussed topic.
If he had a clue, he wouldn't be asking now would he?
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.
HA! I just wasted some of your bandwidth with a frivolous sig!
The mainframe programmer is the one with the necktie.
When I see a troll like this, I just hit PF4. Now where did I put my apl keyboard...
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
is the stuff that grows at the bottom of your mainframe after you spill a Coke in there.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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!
Think Magicians. Windows people are like Doug Henning. *NIX people are like Penn and Teller.
/Sigh.
/sigh).
Our shop switched from a mainframe to a unix environment a few years ago or so, and none of them have made the jump.
A list of key differences:
1) Most mainframe folks are ready to retire, or would have retired if they could keep their health benefits. Ask for as much or as little as you want and expect to get far less than you require.
2) See #1. Most of these people checked out of the professional thinking business a few years ago. Spell out exactly what you need, because they've cashed in all the creativity that God has alloted them.
3) They're usually on time. No, I don't mean projects -- they usually have a good set of excuses about how some policy or "miscellaneous barrier" is holding them back. But they typically show up on time -- just don't expect them to stay after. Ever. (I have my own family obligations and I almost always leave at my regularly scheduled hours -- unless one of the old MF'ers have left a hot potatoe for me).
4) Watch your a$$. These people have years of experience honing their craft of making it Someone Elses Problem -- and they can confuses younger managers easily with their ancient jedi mind tricks. Learn to have a strong will and force them to keep their boring stories about "how things used to be" to themselves (Sure those stories are useful to hear once, but the 10th time? The 100th?
5) Training. LOL. ROFL. LMAO. What you and I typically call the daily activity of "learning", to these people is an opportunity for a vacation. Good luck trying to teach them yourself. They don't want to be taught. They want to go to Florida or San Antonio or somewhere to get away from their wife/husband -- if they somehow pick up something along the way, great, but you don't expect them to worry about it, do you? That's management's problem!
Wow, didn't really expect this to turn into a massive flameout -- but I believe what I've written is pretty accurate, at least with every signle "MFer" I've been forced to work with.
Look, it's not about what system you're got some comfort level with -- it's about identity. Either you're a fucking knowledge worker, and it doesn't matter what system is thrown at you because you'll work to figure it out, or you're someone who sits around collecting a paycheck and waiting to get downsized or a retirement buyout.
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. And more Unix programs are written for consoles
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
Unix has the philosophy of making small, indepedent programs that may communicate via simple means like stdin/stdout. How often to you make small console programs in Windows? Windows programs communicate with one another via the Windows message-passing pump
People still often use plain ole' C in Unix. Nearly every Windows developer I know uses at least C++ if not C# or VB.
Unix programmers are more likely to use standalone tools like vim/emacs/ddd/etc. Windows programmers are more likely to use an IDE like Microsoft Visual Studio.
Unix programmers are more likely to use lots of homemade tools out of Python and Perl. Of course Perl and Python are available on Windows, but it isn't as widespread.
Windows: C#, VBA
Unix: C, Perl
Mainframe: COBOL, PL/1
When a mainframe becomes loaded with spyware, you do not throw it in the dumpster!
Ask your team, also known as the entire mainframe community
What are the differences between Windows, Unix, and mainframe programmers?
Windows programmers live in Redmond, Unix programmers live in California or Texas, and mainframe programmers live off unemployment checks.
OK, I'm just a bitter former unix programmer.
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)
I prefer the "u" in honour as it seems to be missing these days.
When the micro became big in the mid 80's, I began to use applications instead. Load the data into a database. Write it to a binary, that some other application could use. Let the other application crunch it. If I was luck I would have some scripting within the applications to work with, but often not between. In the end the data was in some weird binary file that I could do nothing with, other than in the application. If another application could read it, that would be great. Otherwise it was a dead end. Now some of this was caused by the GUI, but it actually started before.
It has taken me some time to get back to the utility mindset. The fact that applications will write data as XML and parser utility are widely avaiable helps.
So I would think that windows programmer would write applications directly, whereas other coders would write or otherwise cobble together utilities, which would then be gathered under a suitable GUI to complete a specific task. It is something I have seen in the MS Visual studio world. There are dependencies between objects that make no sense and are not neccesary. The widegets, and data, and controllers, and everything just get mashed together. It can lead to really weird bugs.
The last thing i wrote, I tried to start from the GUI, and couldn't make it work. So then I wrote some utilities, packaged them as objects, and pretty soon has some really neat general utilities. Now I could repackage them and write a gui to make an application, but I don't really have the time right now.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I grew up using Mac OS and now am the youngest, by far, in our datacenter to be an MVS DB2 DBA. My 25th birthday is coming in a few months :P
I studied CE in school and the move to 'old school' has been an interesting change. Working for 2 1/2 years now.
Windows PC: Crashed again, reset reboot.
Mainframe: Post a sign in public place and send e-mail that reads "The system will be taken down the Saturday after next at 2:30am and one hour, If this crates a problem for you pease contact xxxx."
Linux: Just download the latest RPM and instal it
Mainframe: Another notice "The Change Control Board will meet Thurs at 1:00pn to discuse proposed changes and upgrades to installed software to be made after the next quarter. Transition plans for approved changes will be preented at the folowing months meeting"
Simulation result will still be 42
3.243F6A8885A308D313
Yeah Im guilty of taking one of these jobs down.. The guy was a total dick, and if the simulation is that involved, here is an idea, SAVE YOUR STATE time to time. Besides power failures do happen ;)
As a lowly student intern working in UF's instructional computing department to put myself through school, back in the early 80's, I was looking up something for my boss in his files when I ran across a badly faded memeographed copy of 'Real Programmers Don't Eat Quiche'... this was a place where mainframe programmers roved the halls, and the piece perfectly documents the type. If you want to become familiar with the culture, you could do worse than reading it, lovingly preserved at Real Programmers (http://www.codeproject.com/scrapbook/realprog.asp )
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.
pundits suck
I found this through wikipedia : VM and the VM Community: Past, Present, and Future (direct pdf link). The author's homepage also contains some other interesting material (ZORK for CMS (!))
[ ] Unix
[ ] Mainframe
[ ] Windows
beard #2
[ ] Unix
[ ] Mainframe
[ ] Windows
beard #3
[ ] Unix
[ ] Mainframe
[ ] Windows
From: "packrat"
Date: 18 Jul 17:31 (PDT)
To: oclug@lists.oclug.on.ca
Subject: Re: [oclug] Linux Users [and evolution]
If these seem like goofy ideas... remember, I'm an average user and I know what I want.
yah. entertainment, net and work stations, right? we are now looking for the magic hook, the killer app that MS CAN'T steal. (hard effort there. i think they're paying out 4 billion a year for stolen ideas (lawsuits) now.
and it's a 'two steps forward and one back' (ala the current crop of intel.prop decesions) process.
corperate formula would be along the lines of..
(rant mode on)
necessary, easy, fun.
simple, conveient, reliable.
friendly, smart and intelligent.
ya don't need to know the process of generating that nifty up there. another pragmatic analyis of an existencial situation... (with the dimensional count being outta wack with current nuke-physics. tough beans, eh? I have issues with them over that.) seriously.
outlawinbg MS is prop'ly a faster way.
pat http://mywebpage.netscape.com/Patr44PDonovan
packrat ; writer-informer. http://packrat.comicgenesis.com http://www.youtube.com/area163 https://www.smashwords.com/
How about some examples?
I've always been interested in doing things the "right way", but the only place you can get that, it seems, is, well, if you happen to be working with other people that practice these methods.
http://www.simotime.com/utldat02.htm
Linux/Unix and Windows folks are not all that different. During the dot com boom, there was a disproportionate number of entry-level types in the Windows world, simply because it has better market share and thus many used it in non-professional ways and made the transition from whatever they were doing previously to IT. Today, things are much more balanced.
;)
As for distributed systems people and mainframers, this can be like trying to mix oil with water. I dont want to give any ill willed impression by that statement as it is not mean to be a troll comment. The fact is that they two platforms are in many ways opposites and thus those who work on them tend to have opposing ideaologies. Without going into this too deep, I think from a high level it is accurate to say that distributed systems people see technology vertically. They see hardware as commodity. Adding more memory or faster CPU's is a legitimate solution to many resource constraint issues. The mainframers see things horizontally. Since a CPU in the mainframe can cost more than many typical American's houses, it is not an option to just add another CPU to solve a resource constraint.
It also does not help that distributed systems people and mainframe people speak totally different languages. It's not that they dont share the same terminology, it's that the definitions for those fundamental terms are different. This can cause a lot of confusion and misunderstandings.
There is also the common issue that Unix people are used to seeing themselves as far more knowledgeable than the typical distributed systems person (i.e. Windows). Mainframers often wonder what the rest of the industry is doing because they mastered computing 40 years ago. And then the Windows guys/gals simply think the Unix and Mainframe guys need to get out more often.
But I bet you'll notice a core psychology that's pretty familiar to most geeks...
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
How do I open jpegs on mainframe?
Transmission content is courtesy by a Windows programmer
who read a book about Unix programmers.
Insightful, how about idiotic. What can you program in Unix that you can't in Windows. In Windows you have C and C++ just like Unix. Java, Perl they are all there as well. Now the platforms may be different but largerly they are more similar than not from a progammers ability to make a program perform a required task.
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.
How is Linux "better"?
Those who don't understand UNIX are condemned to re-invent it......
Typical UNIX systems aren't quite as "mainframe" as a z-series. There are a few that are close but not many. Windows is a joke in comparison. Although MS has conned some people in to buy windows clusters to run big SQL Servers with mainframesque performance expectations. Culturally, Windows seems to be "good enough" and focused on non-thought from the end user. None of that is bad, it's put computers in most of the homes in this country that wouldn't be there is we were using DOS still. Easy to use is better than 100% uptime in that world.
The UNIX world tends to take it a little closer, more than one person usually uses a UNIX machine (not any more but that's how it was) you have to build stuff to stay up. I think this culture has started to seriously erode though, you'll see new world Linux and BSD "admins" rebooting all the time, acting like they own the whole machine. You've got me on why as many people trust MySQL as do, I have to assume that they are mostly "new" UNIX people because there are more reliable alternatives, I don't think MySQL is good UNIX culture.
The mainframe world tends to take it to the extreme. Get your hands on a big IBM box and it's not too hard to get someone to notice you because you're just burning cycles. I was trying to locate very large prime numbers to see how fast that bad boy really was when they caught me. People take care of those machines, they stay up and if you do something to screw it all up (which isn't always easy but there are things that will draw their attention,) you might not get to play much longer on them. Generally when you buy one, you've got a purpose and when it's doing things other than that purpose, you're wasting money.
Because of the concern for reliability, the code seems to reflect that. At times it can be simple to a fault. The older UNIX guys tend to do this the most, they scoff at threads, they scoff at C++ instead of C, they like to write really tight stuff that doesn't do too many things. Complex code? No worries, we'll just string a bunch of these simple pieces together; eventually someone sees how absurd it is to require 90 libraries to compile and run your little app and they do something to clean it up, or not and then they start static linking.. The mainframe world is a little more concerned with performance, they seem to grok it better and know when things are too simple. In some extreme cases they swing to the other side all together, earlier MF OSes were completely designed around database transactions but generally that's not the case. The windows world is harder to generalize because there are so damn many coders, there tend to be experiments though and different "schools of thought" like "threads make everything better" The most general rule in the windows world is that regardless of whether or not the code is clean and fast, you make it look fast.
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 to a M$ employee:
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.
you had me at #!
You, sir, are an awesome troll.
You even sound like you're sincere, which is great, since it means that you've truly honed your skills.
I wish to one day be as good a troll as you are.
I doff my hat to you.
-TrollKin
After reading a lot of these kinds of essays, I can't help but feel that there is this huge sea of dark matter in user-space full of grandmothers using personal computers. In the old days, scientists had only discovered Aunt Gertrude, but now it seems there's also Aunt Marge, and I think I also read about Aunt Molly and Aunt Philly and OH MY GOD! THIS ISN'T A COOKBOOK! IT'S AN INVASION!
Like this?
The truth about Scientology, Xenu, and you: Operation Clambake
If we're going to flame, let's flame GoBots Vs. Transformers or Micro-nauts vs GI Joe. This "main-frame culture" stuff sounds rather scary and really adult, and not the pay-per-view kind of adult, I mean the really boring adult. Like bragaboutmynewridingmower-adult. Let's get this back on the Gandalf vs. Raistlin stuff or perhaps Skeletor vs. Racer X. Hurry! Before my job is out sourced and I have to move back in with Mom-n-Boyfriend.
Often the zeal for a platform reaches almost religous intensity. If everybody involved simply keeps their eye on desired capability vice which platform is their favorite it is easier to get along. I think most of us prefer *nix because the level of control is far superior and thus far has been more stable too. Windows is simply less customizable (if that's a word) and thus at times a bit less interesting. Focus on the customer and the capability the customer wants/needs is the cure for the conflict.
> 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
Hey, you asked.
I've fallen off your lawn, and I can't get up.
...this book.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
C is a fantastic language for developing operating system kernels. It excels in that department, as it allows for code to be written extremely close to the hardware. But that's no surprise, considering it's origin. As long as things don't get too big, then everything is usually okay.
In the mainframe world of software that cannot fail, then C is just not an option. The aforementioned benefits leave it far too vulnerable to coding mistakes. When you get programs that are millions upon millions of lines long, then C just doesn't cut it any longer. Indeed, that is why languages such as COBOL and especially Rexx are so prevalent in the mainframe world.
A language like Rexx allows most non-systems tasks to be performed very easily and efficiently, but with a far greater level of safety and security. It is interesting to note that the OORexx is bringing Rexx to the Linux, BSD and Unix masses. Indeed, even today we are seeing Java take a far greater enterprise role.
Cyric Zndovzny at your service.
The reference to Joel's article is a little silly, because Joel has obviously just skimmed the Raymond book without thinking things through... particularly his strange assumption that making inter-program communiction textual for other programmers is somehow limiting to users, or that you require access to the source code to debug an API interraction. The point of the textual interraction is that, even without the source code (in a closed-source, Windows world) you can still debug an API if the data flow is human readable...
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
I am a Professional Services Project Manager for a vendor, and have dealt with both sides of the house. Both sides of the house are usually separated - and have completely different outlooks on life. Example: Large retailer. In the South. Mainframe people on one floor, that are locked down, ITIL to the MAX, change resistent, and risk-averse. On another floor... Open systems people that are more like outlaws, gaming the change control procedures, etc. to "get things done". Don't get me wrong - I love working with both of the groups; It is just fascinating seeing the difference in the approach to the job. P.S., I have worked with WIN flavors, Linux, and am a z/OS capacity planner / performance measurement person. I would really like to see an open systems vs. z/OS benchmark that was realistic.
My wife doesn't listen to me either...
THEY CATCH ON PRETTY QUICK AS LONG AS YOU COMMUNICATE (INCLUDING SPEECH) IN ALL CAPS AND DON'T BRING UP NEW-FANGLED BUZZWORDS LIKE "ODBC" AND "WORLD WIDE WEB".
Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's like yelling!
Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's like yelling!
(If only the green screens would give this error...)
Nope, you're instructed by your clueless and cheap-ass PHB to move it to the loading dock so it can be moved to off-site storage (i.e. the loading dock ... see "cheap-ass" reference, above.) Your glorious leader has purchased a new machine from the company with best salespeople (i.e. short skirts, cleavage, and heels.)
... ever. You might tip it over by backing into it with a forklift, though.
Besides, you don't throw a mainframe computer
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
And mainframe guys were copying 40MB files around long before you were born ;)
Yeah, but that was tape-to-tape...
Tag lost or not installed.
I am the admistrator of a small but growing development SAN at my job that deals primarily with open system storage and servers. Ive been getting more and more requests lately for MF/zOS access to the SAN so they can test against the various arrays we have. Whats the best way to get a grip on how the MF world lives compared to the intel/x86/unix world? Namely things like LCU's and 3990 Mod types?
Thanks
Thought I'd mention two sources for this that I think are worthwhile.
The first is a great article about what the differences between mainframe programers and Unixy programmers. The second is a book designed to teach mainframers to operate in a Unix environment. The article is definitely worth a look for anyone interested in this topic.
...are aware of the intrinsic I/O between CPU, HD and peripherals. It is well published in the manuals anyway. PC programmers (generally) have no idea how data and at what rate are moved between peripherals. Thus they have little control over the inner workings of the language the program in. They are forced to work in sculpted interfaces provided by the Windows world.
Mainframe on the other hand, have no interfaces and if any, it's a TEXT (EBCDIC) world. Mainframe is a no-frill world and strictly a business proposition. In a word - strictly no nonsense for you to hack with.
Wow, what a post! I typed the whole thing into teco and it played the Star Spangled Banner on my DECwriter III !
MAN SHOOTS ROVER!
If you're running online transactions rather than batch and have an application which can spike at various times due to unforeseen events (e.g., bad weather), you probably want to keep your peak CPU at a lower level than a batch-only system.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Notice that all throughout the comments there are references to mainframe programmers, Unix programmers, and Windows programmers.
... the pain!
Where are the Mac programmer references?
Oh that's right... there aren't any mac programmers! I think they wonder when the horrible pain is going to stop.... OS 9 -> OS X -> 10.1 10.2 10.3 10.4 -> OS X86
When I have a few thousand source modules to search through for various things, I'd rather use a tool like @CULL to create a pre-processed search database and a tool like IACULL or FINDREF to search for keywords. Much faster. Think cscope on steroids. :-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Not quite addressing the question, but perhaps others will find this interesting. This is a webpage I wrote six years ago about doing factorials (also prime numbers on micros, but scroll down about halfway for factorials), and what a difference a couple of decades made in the availability of computing power:r y.html
http://www.mindspring.com/~benbradley/number_theo
Tag lost or not installed.
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.
"As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers."
/.er gonna?
Buddy, if you don't know by know, then how the heck is any
It's a strange world.
What a human would call "memory" they call "storage".
What a human would call "disk" they call "DASD".
They think it reasonable to pay about 10X as much for the same hardware.
And they're all about 5'6", kinda chubby and nice guys. Usually with beards. I think they're clones.
Alas, they are an endangered species, living mainly at banks and other financial institutions.
Mainframe programmers can and often do have at least some level of understanding of every aspect of the computer system, and have mastered several ancient but useful computing languages.
Unix programmers can and often do have some understanding of every aspect of the Operating System, and have mastered several current and useful computing languages.
Windows programmers can and often do have some understanding of every Microsoft product and have mastered several GUI-based integrated development environments.
I have done a variety of programming environments and every one of them thinks they sit at the feet of God. Or Gawd. Or Dog.
My attitude is that "You go to your church, I'll go to mine."
Programming is cool whereever you do it. Got that?
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.
Too lazy to create a sig...
Without resorting to Google just yet, I'm curious how JCL compares to OCL I used on the System/34.
We had two of 'em at my high school in NM. I had fun programming RPG-II, COBOL, and working down to OCL and making menus on these beasts. I think I still have my library dump on 8" floppy, though it's probably useless these days -- it has been 15 years, after all.
I would say:
#1 - Mainframe
#2 - Unix (RMS)
#3 - Windows -- is that who I think it is?
Zhrodague.net - I do projects and stuff too.
I believe that Douglas Adams had the right idea. We need to put the Windows Programmers and the Phone Sanitizers on the first rocket to another planet. Then they can get the planet ready for the rest of us. I would hate to move to a new planet and not have Windows programs and clean phones at my disposal.
We'll be right behind you in the next rocket!!
"Meaningless!, Meaningless!" says the Teacher. "Utterly meaningless!"
Where I work there is an AS400 group. We often work together on projects where I put some "AS400" content on the web. Here are some of the things I had to get used to.
A "Database Table" is to a Windows programmer as a "File" is to an AS400 programmer.
A "File containing code" is to a windows programmer as an "Object" is to an AS400 programmer.
A "Database" is to a windows programmer as a "Library" is to an AS400 programmer.
They don't realize that their "Files" reside in a IBM DB2 database. Some of them still think the data is in huge text files!
Also, the 400 guys where I work don't even use SQL. So I'll write a SQL report for them and they'll come in and say something like, "I know you're going to kill me for this, but can you rearrange these columns." I don't know how the heck they are writing their reports that makes the columns a major pain to rearrange, but whatever!
The funny thing about their terminology is that all of their apps actually run off of a DB2 database. But there are a couple of them that look at me like I've got a third eyeball when I say something like, "Just hit the database and grab the account number from the Account table." They don't even have any idea what a database is. Just crazy.
morse translation:
- oooo o ooo oo --o = thesig
"UNIX programs tend to solve general problems rather than special cases."
Brian K. & Rob P.
Mainframer: They would never fire me or lay me off. Nobody could ever figure out this twisted logic that has evolved over the past 20 years. Besides, nothing ever happens fast on a mainframe, with all this change control implemented they would be afraid to put a new guy in these shoes. Pay me.
Unix hacker: My god, there are a million and one ways to attack this problem, but it would take a miracle to have someone ever figure out how it is implemented in this latest update routine. I have so many IPC and shared memory calls between threads nobody could possibly understand this stuff. Pay me.
Windows programmer: I follow all the rules (yea, right) and once I finish my latest fling of code its straight into production. Blue screen, yea? So what, thats Micky soft's, not my problem.Call support! I did what the book says so don't bother me Ok? Oh, you want this to actually DO something? Pay me.
See, they are actually all the same!
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
...but I won't. Rother I'll explain why you have no clue.
Insightful, how about idiotic. What can you program in Unix that you can't in Windows.
That wasn't the point the original poster was trying to make. The point is HOW you program in Un*x vs Windows. Nobody will argue that you can do anything you want with either platform. However, a great many people would argue that the "UNIX way" is FAR mor elegant.
In Windows you have C and C++ just like Unix. Java, Perl they are all there as well.
This statement really demonstrates your inability to comprehend the differences. To extend the "building toys" analogy, C/C++, Java, Perl et al are NOT the pieces, they are the plastic/wood/metal with which the pieces are made. You could make lego bricks out of the latest space-age carbon fibre composites, but they would be useless if the "bumps and holes" on each brick were different sizes and wouldn't lock together.
Now the platforms may be different but largerly they are more similar than not from a progammers ability to make a program perform a required task.
There I'd really have to disagree with you. There are things that Un*x style architectures do easily that are arduous to perform in the Windows environment. Similarly, there are things Windows excels at. IPC was really much more refined under UN*X--some might say Windows works with threads so well because it has to since its IPC abilities have historically sucked--really in UN*X it is much easier to get various components to play nicely with each other yet keep their resources separate and protected. OTOH, there are reasons Windows-based games are so far ahead besides simple market share--graphics interfaces are one of those "funny shaped blocks" in Windows that is very well suited to its task.
Really that Lego analogy is very apt indeed. UN*X is very uniform in how it works, just like a bucket of classic Lego bricks. You have a library of pipes, sockets, shared memory etc. that is very standard across all programs that extends all the way to the user interface (you can pipe all manner of programs input and output together right on the command line to a degree not yet seen in production releases of Windows). Once you get the hang of the UN*X Way you can snap these blocks together esily to suit your needs.
For all the "object orientedness" of Windows, there is not that level of uniformity in interfacing to make those reusabel objects work together. Instead, you have an overly complex framework in the form of DDE/OLE1/OLE2/COM/DCOM that was largely designed to accomodate disjointed, inconsistent interfaces between various components/applications. This is something like the "licensed from the movie" Technics sets with all the little odd-sized rods/axles, funny-shaped blocks, special wheels and so on. There many little sets where the pieces fit together very nicely in a few commonly required configurations, but when the time comes where you want to make your own creation not in the instruction booklet you become frustrated with the useless pieces. For many kids, the six or so really cool things you can build are good enough, for the 10% "most geeky" kids it would bore you quickly.
I can't say I really know for sure what a "mainframe toy" would be--mainframes don't seem like fun at all. I think "mainframers" may have forgotten what childhood was like, or perhaps hatched from a pod fully grown, who knows. I do not have a lot of exposure to that philospohy/culture. If I HAD to pick a toy that was most mainframe-like I might say Mecanno, because like UN*X they are fery uniform in structure, however you have tediously fiddle with those little screws to put anything together, just like a mainframe--you have your "special screwdrivers" (arcane knowledge) and have to follow tedious processes to get things done. Or, perhaps it is like building a birdhous with popsicle sticks, where you have to tediously glue the pieces together with Elmers glue, wait for it to dry bef
What would eric raymond know about the art of programming? The retarded little cripple can't code for shit, and he tries to put himself in the same basket as Knuth? raymond isn't even RMS' dangleberry, let alone the dogshit on Knuth's front lawn.
Interesting I should find this article on slashdot tonight. I met a mainframe programmer at a dinner I went to. She said she used to make a lot more money and her opportunities are much more tight then they used to be. I thought it was cool that she was still employed
Windows/PC users fix problems by rebooting until it goes away.
Mainframe users fix problems by going away.
*grin*
Seriously, imagine a one-player game on a console, where you turn it on, play a while, turn it off, and when you come back you start over, or perhaps start at the last level you finished. That's a PC.
Now imagine a multi-user game where lots of people connect and disconnect all the time, some of them keep playing while they're offline, others don't. The world itself is always there, and there are very few "resets". That's a mainframe.
On a PC, programming tends to be sloppy because it's generally assumed (at least in the world of application development) that it won't run for more than 8 hours a day, and that the PC itself will probably reboot every day. So, a small memory leak, or a resource that gets "lost" is not going to be a major disaster. Even data corruption is likely to only affect a handful of workers and their local files.
On a mainframe, if memory somehow gets lost, it stays lost for months or years at a time. A faulty driver can destroy the entire company data-store (hope you make backups!). But because of this, most software is checked with a bit more care.
I hated the VAX/VMS cluster we had when I was in college.. but after 10 years of dealing with the hardware annoyances of PC's, and the software incompatibilities of linux, and general unreliability of windows... I think I'd rather be back typing those big long DCL commands. At least that thing never crashed, and was totally predictable (more users == slower; in a nice linear fashion).
A Windows programmer bangs and bangs away throwing all kinds of code (much of it provided by the IDE) at the problem until it is declared by Fiat to be solved (usually it isn't. Solved, that is.)
A mainframe programmer comes in early, carefully considers the problem, evaluates the business need, and spends weeks coding in RPG or COBOL to solve it, and stays late every night, and carefully updates the site log to add the new program. Once solved, it's solved! (It had better be!) Oh, and they have these nifty pocket protectors...
A Unix programmer comes in late, kicks off his shoes, yawns, scratches, reads the email for the project out line, pounds out some code before lunch, takes a two hour lunch, leaves early, and right before he goes sends the email back saying "Check this and see if it's what you want, to be sent sometime after midnight.
Those are the chief differences between programmer types... Oh, yeah, none of the above can stand the others. The Unix admin is the hardest to tell, but check with the others to see if they are getting all their email, and you'll know, you'll know...
Truthfully, though, a PC programmer normally has a small outlook on the problem. If it's a large process, he may think in terms of server/client, EG: lots of clients pinging a server with results for colation. A mainframe programmer looks at a problem monolithically, EG: it's all done in one place. A Unix programmer tends to think in distributed/monolithic terms... parts are done with child processes/offloaded to other cpus, with the final results on one machine.
Of them all, I'd say that Unix programmers gennerally get huge multi-threaded projects done the best, mainframe programmers are great for business intelligence programs, and PC programmers are great for games and pretty pictures on the screen... You might say, call a Unix programmer to solve a problem, a mainframe programmer to report how it was solved, and a PC programmer for the PHB eyecandy/dumb salesclot interfaces.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
In NT4 and earlier, those systems weren't there (WSH came out around Option Pack 2, right? It's been a while). However, up until recently, the majority of Windows Network systems were NT 4.0. The W2K+ Scripting environment is quite impressive (I've been doing my first Windows work in a while recently, although mostly Excel/VBA programming, but played with the scripting capability for fun), and it has come a long way.
When I worked a decent sized MS Partner, the MS Way was "point-and-click." They were going to do a 10,000 user migration by hand, because that was the MS Way. I grabbed the NT 4 Resource Kit and whipped up some Batch scripts to do the parsing, and the Windows guys were amazed.
Windows has some very intelligent scripting, buts its somewhat hidden because the NT 4 Days, which weren't short, but caused a problem. Older PC guys knew Batch scripting, which kinda disappeared in the NT 4 days because the tools weren't readily available (buried in the Resource Kit meant that you couldn't count on them being on the machine). The newer object-oriented programing method is cool (and absolutely preferable to parsing text streams, which as you said depends on an unchanging text output from a program, which is very constraining), but you need a new generation of Windows Geeks.
Unfortunately, hacking on Windows is about as "cool" as a Mac was 10 years ago, so your computer geeks just aren't learning it. This doesn't change the fact that good admins are critical, but there is a perception problem. Just like Novell became perceived "dead" because nobody saw it because the machines didn't crash.
The WMI/AppleScript approach (as in, thick self contained apps that are callable) is perfectly legitimate.
The other problem you have here is what happened to the MCSE in the late NT 4.0 days. When I was just finishing my MCSE, all the MCSE study guides were coming out... teaching to the test, and MS didn't upgrade the tests fast enough. Stuff that took me weeks reading the NT 4 Resource Guide was available in a condensed 4 hour book. Combine that with the MCSE Courses, that taught to the test, and the whole industry get messed up. People hired cheap "paper" MCSEs, and people got used to Admins not being able to program. Finding a Windows Admin that truly gets it is rare, because there is too much dependance on unknowledgable paper-admins, so people assume all Windows Admins suck.
Alex
For the guy who says MVS didn't have preemptive multitasking, that the only interesting languages were Cobol and BAL, and that Cobol didn't have asynch I/O, you're batting 1000 . . . wrong.
MVS had an extremely elegant preemptive multitasking scheduler (based on what IBM had learned from TSO). It gave managers and operators extremely fine-grained (actually, too fine grained) control over priorities. And it managed to schedule interactive users at the same time.
As for languages, it's obvious you never really investigated the situation: you forgot PL/I, which laid the system pretty much wide open (and had the trapdoors required to exit to the brief BAL interfaces required to get into supervisor state). It could be done with Cobol as well, but it was a bit more difficult.
Cobol I/O was asynch by default (buffered to the extent you specified in the JCL). It's just that the programmer never had to issue starts and waits--that was all done by the access methods.
Clearly, the problem here is that you really didn't know that much about the system you were using. Typical problem in the financial segment of the mainframe world. Those of us who could see beyond the job stream to run that night knew about all sorts of neato keeno stuff (like how the Fortran H compiler did its optimization, and how to use the interactive PL/I checkout compiler, and how to do all kinds of system programming without the nuisance of BAL [yes, if you know how the compiler works, you don't get hit with nasty inefficiencies], and how to reduce the run times of Cobol programs by an order of magnitude by changing one compile-time parameter). Please, you were in a rotten job. Doesn't mean that the equipment and software you were working with was as bad (and VM was quite some interesting system, if you understood what was going on; disaster if you didn't).
An old mainframe programmer who also writes Unix code in more languages than C and C++.
Um, yes.
Mainframe programmers (used to) write their code with the philosophy that it was intended to last indefinitely, and that they could possibly spend their entire careers maintaining and evolving a piece of software. They also tend to think that nobody else will ever be touching the innards of "their baby", as mainframe programmers tend to "keep to their own turf" and don't want anything to do with anybody else's programming project, nor do they want their peers poking around in their stuff either.
Unix programmers write their code to be as efficient, clever-witted and esoteric as they can possibly get it. They know that there will be a certain number of their peers reviewing their work, and they want to impress their peers with the output of their brains. In every group of unix programmers, there exists a pecking order and a constant desire to impress one's peers and thus increment themselves one more notch up the ladder of that pecking order. This instills into unix programmers the philosophy that the code they write should be portable across many *nixes and will also naturally be passed on down to some new junior programmer that comes along, once that newbie proves he has acquired the chops to grok the code. For some odd reason, many unix programmers tend identify just a little too disturbingly close to the Jedi Order from the Star Wars movies. Either that are they are often too deep into that medieval wizards and dragons fantasy crap. Worse yet are those who do both, and have no real life outside of their hobbies or computers. When not at work, you'll find them in their mothers' basements.
Windows programmers write their code with the intent to hurriedly slap together something that sorta kinda works under most sets of circumstances, but has plenty enough eye candy to wow the typical customer who only is smart enough to see GUI-skin deep. Often the software is deliberately written to just to "grease a squeaky wheel" for solving a short term need, and the only long-range planning ever done is to see how many times you can get the customer to repeatedly re-purchase the whole nine yards every 18 months. Also, Windows programmers have a penchant for writing code that only they can understand... to help bolster their own job security since their position will be outsourced in a heartbeat if the company can get away with it. Everything in the Windows world seems centered around a cultural core of pure temporariness. Both the code and the programmer are 100% disposeable. And come to think of it, all too often so is the employer (any typical ISV company) themselves. Windows software companies come and go like thunderstorms in Oklahoma.
Unix and mainframe programmers are more likely to assume that Windows programmers do not know multiple systems and as such will act condescending towards them causing the Windows programmer to kick their ass.
If I have ever seen a thread designed to ignite a Troll War, this is it. I have been debating whether or not the moderators really do this sort of thing and just got my proof.
Everyone knows the real difference between Windows programmers and Unix programmers is volume labels. One group uses them and the other relies on other means. An analogy: 2 kids enter the kitchen and one dies from drinking a bottle with a big Mr. Yuck sticker on it. One kid knew what it meant, the other one thought green means lime taste.
Know what I mean?
M
Those trying to integrate and make good GUIs on Linux are the distros. Some are quite good and they are getting better.
Joel is judging the GUI people at the distros after a book about programming philosophy!
The argument is so stupid that you really wonder if he is honest.
Also, consider when Joel wrote this:
He doesn't even mention that anyone which sells a lot of new word processors on Windows will get his oxygen supply cut off like Netscape. There are many well documented examples.Karma: Excellent (My Karma? I wish...:-( )
2.625374126407571e+17? what's the signifigance of that?
"The Unix programming culture holds in high esteem programs which can be called from the command line, which take arguments that control every aspect of their behavior, and the output of which can be captured as regularly-formatted, machine readable plain text. Such programs are valued because they can easily be incorporated into other programs or larger software systems by programmers."
If your idea of programming is piping one command line utility to another or writing scripts to manipulate existing GUIs.
Whether I'm writing a Windows application or a UNIX application I don't feel the need to make a detour through an existing program. I use code libraries or components for reuse, not entire programs.
Not only good content, but well written.
Karma: Excellent (My Karma? I wish...:-( )
??? (n/t)
I don't know why you were labled troll and not "funny", but I would have phrased it that "Given an infinite amount of time, all systems become UNIX - OS'es or Applications.
Mine's not funny at all but it's a shorter form of what I was trying to say.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is all very true. It is frustrating to me that today, many things don't work, or only work sometimes, or only work on some machines and that it is considered "normal" or "acceptable". Especially irritating are functions involving plain text. I can understand a few kinks if I am trying to watch a movie on my computer. But if I just want to pass a string of text and get a simple, but crucial result, I am often disapointed.
On four legs I was a mainframe programmer, on two a Unix Programmer, now that I am ancient and over 40, on three legs I am a Windows programmer.
.NET .NET are deep monsters with so many classes no normal human can know them.
Here is my quick take on the three lifestyles and some random observances.
Mainframe programming: Company/Intranet
Suit and Tie, dress shoes.
Languages: ALC, COBOL, Rexx (The Best)
Editted with XEDIT, ROSCOE, or the TSO editor.
Shells: VM/TSO/Roscoe
For me, the mainframe was best for collaboration (A bunch of people working on a big problem together.) and interacting within a large company while still being isolated/protected from the world at large. Instead of being distracted by the world you are distracted by corporate politics. It reminds me of a horse designed by a committee of blind men who are making thier opinions known by feeling different parts of an elephant.
Unix Programming: Individual/Network
Jeans, Hawiian Shirt, sandles.
C, Regina/Rexx (Rexx is best), Perl (A vile programming language)
Editted with vi (An editor that goes well with Perl, tied with edlin for the worst editor ever)
Shells: BSH, CSH
Best environment for people who do not want distractions. Best place to create your own little world and live in it. The OS most favored by people who either did experience the 60's or wish they had you can tell because when you go to the UNIX conventions everyone looks like Jesus and I had a beard too when I did it this is a run-on sentence I know. Living in unix means your fingers will hurt and you will need to think of everything as a long string of characters because its all going to be one thing at a time and if you make a mistake and enter rm / -r you are screwed because there is no undelete in unix and no trash can and there is nobody to do your backups for you but you.
PC/Windows/Mac: Society/Internet
MS Visual Basic, Regina/Rexx, HTML, Kedit/Kexx, Access/VBA, SQL,
jeans or shorts or underwear, and t-shirt or noshirt, barefoot or tennis shoes
Edited with Kedit (The best editor ever.) or the MS editor that comes with the language and pops up all the possible commands and values and properties automagically when you type making programming less of a memorization problem. JAVA and
Shells: DOS/none/or whatever program has the focus
The most connected to the world with the most distractions. The best for communicating and the most prone to viruses. Most opportunity and potential for success or failing on your face. The least safe and the most free. A dichotomy at once while still growing.
-- Each tock of the Planck clock is a new world and here we are still life. --
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.
Urine's generally sterile. It's cross-contamination you have to worry about.
I have worked with all systems but started on m/f. The two most pervasive differences to me are data structures using fixed-length fields (m/f) vs those using delimiters (non m/f) and decimal arithmetic (m/f packed binary-coded-decimal) vs non-m/f alternatives (integer,float,double). I tend to prefer the fixed-length fields for readability and predictability, even though it can be "wasteful" of once-precious resources. I miss the decimal math for business-oriented apps but use integer cents displayed as 2 decimal dollar floats. Passing data between these two worlds always has to deal with these differences. Occasionally the computational differences are an issue that can be mitigated, but not eliminated.
It's interesting that this shows up now with the ads for the "Oracle Grid" running on TV. It's a cluster. Big freaking deal.
My favorite part is near the end where it says about the mainframe "When a mainframe dies, the server dies." The only problem there is that MAINFRAMES DON'T DIE! Everything is redundant, ECC'd, hot-swappable, etc.
I've never worked on mainframes, but I've worked on AS/400s. We were able to kill one, but it was because of a mislabeled patch tape from IBM.
What matters most to managers or clients when deploying new systems these days seems to be "time to market", and the only consent to quality is that the IT dept/company follows check-list processes like CMMI or ISO9000 which do not address the real issues and put too much into the Process rather than the Result. Also, when the system breaks, it's typically at the expense of the IT company that built it, or was stupid enough to agree to use the off-the-shelf product in the first place, so there is nothing to drive a change of behaviour from the clients.
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
In Soviet Russia, mainframe windows unix.
Oh yeah.
Mainframe guys thinks everything on the computer is secure. The hardware is bulletproof after all.
Windows guys thinks that security is impossible, since every machine is spyware infected. So they do not even bother writing secure code.
Mainframe guys think, that because they know assembler language, they are way superior to the rest of us.
Mainframe guys tries to keep things secret and mysterious. Or we might find out they are easily replaced.
Mainframe guys knows that they company can't get rid of the mainframe before they are dead.
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.
Signature omitted in order to save space. Thanks for your understanding.
Lots of programmers have their own string code. For example, postfix has vstring. In the spirit of C, such arbitrary things aren't built in to the language.
Have you used C++? It has a standard string class which solves these problems and is much smoother to use than the various C libraries.
I was of the vintage that started my CS degree using punched cards and ended it with Unix and Windows. What I learned from coding on the MVS system is that the programmer should batch up as much of the request as possible because each user gets only a tiny slice of the processor's attention, and it is a Good Thing to do let the client side have responsibility for some state information. Later when I started to learn to program on the web I was able to reuse most of that orientation to patch together stateless web pages into a coherent application workflow. I guess that is why I still write my webpages in text editor and never ever use an "integrated development environment" for web coding ... I guess I just don't like to have the physical processes hidden away from my analysis process.
Next we will be discussing outsourced programming culture vs in house programming culture.
Chris ,
Php Programmers.
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
I was part of an intake of graduates being trained in mainframe programming two years ago. There's always a need for new coders...
My Journal
http://www.straightdope.com/classics/a4_220.html
Keep washing those hands, kids!
In soviet Russia, mainframe programmers say:
"East or West, COBOL is best!"
Try Mono/C#
Meanwhile, back in The Real World...
It has all the good features of Java, plus some of the good features of C++ like pointers and access to unmanaged code.
And it has the disadvantage that it's constantly playing catch-up with Microsoft, and essentially has to do what they want to do, because it's unlikely to ever become important enough in its own right to do what it wants (without losing its raison d'etre).
And that's assuming it *can* implement the new features fast enough to be useful; as I said, we're playing the MS game, and MS like to add new features to get people to buy.
We haven't even got into the whole legality issue; although MS probably claim their standards are open, you'll probably find exactly *how* open they are if someone ever comes close to producing a C# clone to rival MS's; if this is ever a possibility, they'll be sued into the ground on one of a million basises, because that's the nature of the beast.
Of course (getting conspiratorial here), MS might tolerate and even covertly support Mono in the early stages because (a) It's a good way to split support/programming skill in the open-source community, and (b) If Mono gains sufficient ground, and people start using it for serious projects, then.... whoops! MS decide to sue Mono users on some ethically dubious but legally-sound basis because Mono infringes [whatever], effectively killing the project in a worthwhile form, and leaving all those Mono projects stranded.
So... choice; do you (a) Rewrite the whole thing from scratch using a different "open" environment (taking lots more money and time which you don't have), or (b) accept MS's "kind" offer to move to a paid "legal" implementation of C#/.Net (theirs) *plus* they won't sue you....
No-brainer; in the real world, people will go with (b) and be severely pissed off with "open source", rightly or wrongly. And Microsoft have another large customer.
As far as I'm concerned, the "must copy MS" requirement on its own is bad enough. It limits the flexibility of Mono; it dooms it to always being one step behind, and opens up the possibility of MS deviously introducing certain features solely to make it hard for the developers of Mono to copy them (forcing them to take up their time and resources in order to remain compatible).
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
Like this you mean?
From the article:
[..] there is a core value in the Unix culture, which Raymond calls "Silence is Golden," that a program that has done exactly what you told it to do successfully should provide no output whatsoever. [..] By contrast, in the Windows culture, you're programming for Aunt Marge, and Aunt Marge might be justified in observing that a program that produces no output because it succeeded cannot be distinguished from a program that produced no output because it failed badly [..]
Aunt Marge is right. It is a golden rule in Windows that programs that failed badly will usually produce no output whatsoever. Therefore open your task manager and try to kill it if it produces no sign of live.
A corollary of this golden rule is that the badly failed program will usually not respond to the kill event either. This is i.a. because for many years most Microsoft example programs included with Visual C++ did not properly check for being killed. Microsoft culture does not accept failure, and does not waste useful time programming meaningful feedback messages.
Hercules and have hours of fun
At least in the large bank where I work.
On the mainframe a healthy balance between rigorous procedures and practicality has been reached. On the big UNIX machines they are trying to push through the same kind of rigorousness, but without consideration for practicalities, resulting in a disasterous situation.
On the mainframe, the developers can have direct access to data of their "own" application, that is the one they have to provide 3rd level support for. On UNIX, such access is impossible, firewalls are everywhere and you need 10 signatures to make a production change. In short it doesn't work but for the most trivial appliacations.
What ? You have HANDLES on your urinals ???
What planet do you live on ?
I am a Unix sysadmin and also admin an application that sends data to a mainframe. I cannot get over the lack of error handling on the mainframe side concerning input data. From my experience, Unix applications are designed to gracefully handle errors, frequently by discarding the input data and writing an error message to a log; sending an email message /page is optional. From what I see of the mainframe world, if the input isn't available when the mainframe wants it or the mainframe doesn't like the data for some reason the mainframe pukes, frequently rewinding the virtual input, process, and output tapes and starting over. If a 500,000 line data file has one field with 21 characters when the mainframe is looking for 20 characters, ignore the bad line and report the error - don't have a hissy fit and reject the entire file.
we see CASE tool technicians masquerading as software engineers.
.NET or Java programmer abhors CASE tools as much as a UNIX guy.
I can guarantee you that a talented
I see this at work all the time with the "new generation" of IS/IT types rolling through the door who couldn't code a b-tree save to save their lives and rely on prebuilt everythings to give the illusion that they do something "difficult".
Why would I build something from scratch , so far removed from my real intent (to build an order management system)?
To counter your experience, I've seen plenty of UNIX folks that wrote server programs system that leaked memory and crashed often, and didn't really perform that well, all in the name of "it's better if I write it my way". I"ve also seen plenty of Java folks do the same, though this time in the name of "I can't be bothered to research what I'm re-using, whether a library or an RDBMS". Ignorance has many faces.
-Stu
Well, Java runs great on the mainframe, UNIX, and Windows. Your mainframe guys will probably love the fact that they don't have to bang out COBOL code any more, and they will be learning a "newer" language. Then "if" you migrate to any other platform, you will be able to use that code again.
:-)
The last time I looked, IBM took all the JAVA commands and compiled them on the mainframe, so the performance was excellent, granted they didn't have any of the AWT/Swing stuff working
The more I learn about science, the more my faith in God increases.
In mainframe culture the success criteria cluster around finely hones change control, getting a finite sized chunk of code to work, and work cleanly, fast, first time with known bells and whistles and no more.
Unix success criteria cluster around getting it done somewhat quickly, build it light so you can change it on the fly, include lots of function stubs for unimplemented functions you MIGHT need later on, don't worry about reusability or longevity and make it run good enough.
Each approach has its advantages and disadvantages but each is disasterous for the other. If you try to run with mainframe mindset in the Unix world you'll fall too far behind. Conversely if you approach mainframes with Unix success criteria you will never get anything done at all.
There doesn't seem to be many comments that are focused on reality (although one about cat herding got moderated to a +4 interesting) but here is some perspective for those who have not lived through it all;
Mainframes where designed when UIs were not an issue, but cost was. In order to process 1000s of payroll checks for the least amount of money, performance was #1 priority and you will find most of the mainframes designs centered around that. For instance, multiple busses - the original IBM mainframes had more parallel IO than today's PCs designed 40 years later (and no, not because today's PCs are faster, its because today's PCs are made cheaper). They increased performance by adding multiple paths to the same devices - sometimes up to 8 physical paths. Today's PCs? They string 8 disks on the same cable. Dumb, slow. The mainframe OS was written with performance in mind. Heck, half of the OS was dedicated to handling print spooling - since there was only one slow printer most of the time. Unfortunately it is some of the most disgusting monolithic designed on the fly code ever created, but it performs well.
Then came the terminal - 2 approaches; The interactive approach (*nix) and the high performance approach (CICS mainframe). Again cost and performance was #1 priority for mainframes and not an issue for *nix. Mainframes terminal 'transactions' are all pre-defined, the files pre-opened and the screen layout pre-written. The results was you could handle a 1000 terminal call center with ease. The most Unix terminals you could run on similar cost hardware with similar transactions was about 16. Again, different purpose, one was for performance, and one was for flexibility.
Then came the PC - The GUI (eventually) became the #1 priority. Prices were cheap, relative speed was fast, so it all gets bloated up without true regard to performance. It sure does look nice, but it is about as efficient as using sand for motor oil.
I have had many discussions with those who are responsible for Windows and Unix internal OS design as far as performance goes, and it clear that they just don't really get the big picture. Sure they know their little version of it, like LRU paging algorithms - but talk to any one of them about capacity planning and how it relates to resource consumption and resource management and you get blank stares. Talk to them about hierarchical storage management and you get "huh?". When the performance GURU at (insert OS software company here) says "when CPU busy exceeds X then you need a faster processor" you know he hasn't a clue what he is talking about. The definition of performance is that you achieve more than X percent utilitization or you aren't tuning you system correctly. The things that were done on the mainframe 20 years ago to increase performance and lower costs will slowly make its way into the PC environment, as the PC crowd realizes that cost is again an issue.
But for now, it is a different world, one where cost is not the issue (or at least not really taken seriously) ($5m for a mainframe v. $500 for a PC). Why would anyone think that they should "get along"?
slashdot troll = you make a compelling argument I do not like the implications of.
Good post; one nitpick. Anytime you have a post of the form 'A is [blank], B is ![blank]' you've probably given short shrift to the B side. It assumes the question is true-false.
I would say that *nix/Windows are not so much 'not-process-centered' as small-task centered.
Processes, in this case, would have a fairly directed, machine-based goal. Since there is a goal, there has to be a reason for doing it, a risk analysis, and fallback planning. Even if this is done only in the head of the mainframe programmer.
Tasks are small, lightweight, and less critical. You can toss a task out there as an experiment. In Windows or in *nix, you can run something to see what happens, even if you aren't sure what it will do. You can code up things just to test an idea.
This means that you can experiment a lot on *nix and Windows.
In Windows, this is usually seen by programmers running something in the Visual Studio IDE, or in VB Classic. In *nix, this is usually done in a shell script or Perl script.
I think in the mainframe world, these experiments are mostly done in the mind of the programmer; maybe with a whiteboard.
Interesting post; I tend to agree with your conclusions.
Ah, IEFBR14. The original proof that even IBM couldn't write a one line program without having a bug in it.
:)
Its only purpose is to return control to register 14 (BR 14), which contains the instruction to pass control back to the mainframe; so IEFBR14 did, in effect, nothing. (Also how it got it's name, for obvious reasons.) However, it sometimes passed back a nonzero return code so they had to add another two bytes to the program; an SR 15,15 to zero out the condition code register.
The SAS-L archives has one programmer's recollection. I heard the story years ago but never found the cross reference; it was always passed down from sysprog to sysprog as part of our oral tradition.
Mit der Dummheit kämpfen Götter selbst vergebens.
What can you program in Unix that you can't in Windows.
A secure system. One that is not readily affected by outside hacks including virii, spyware, malware...
A reliable system. One that does not crash unless the power fails and the back up power fails. And then it will start up and recover all by itself.
A scary system - one that takes your bodgy typo ridden command and eats it, performs it, exactly as typed not as intended, and doesn't tell you what it did.
A customizable system. Of course when building user interfaces for end users, you can program for the typos. In fact you can even tailor your own user interface to catch your most frequent typos or most dangerous ones and not quietly execute them as written.
I've worked in all three environments, I'm old, I've got grey hair, but I will never have a beard.
-- it must be true, it's on the internet.
Mainframe programmers by definition, must have a larger pool of knowledge on computing and network architecture.
As their knowledge increases thought their Happiness decreases!. I even made a graph!
happines | \
knowldedge ------
"I make a lot of graphs" Lisa Simpson.
- these are not the droids you are looking for -
Raymond invents an amusing story to illustrate this which will ring true to anyone who has ever used a library in binary form.
Unfortunately, I can't tell you how many Open Source libraries I've thrown away after trying to use them for the exact same reasons. They APIs aren't documented (if at all), the APIs don't work like they are described, the APIs don't work like it seems they should, the APIs just don't work, or the APIs are just way overly complicated to use for what I/we need done. So what if I can debug through the source, maybe it gets me to the point of throwing away the OSS library faster because I can see that it is useless, but the end result is the same.
You can also chalk up the GPL to some of it. I've found libraries that seemed OK but were GPL'd and software we write doesn't have GPL'd source in it, thus forcing me/us to reinvent the wheel.
Neither model is perfect and programming never will be the utopian ideal of being able to always reuse everyone else's code. Sometimes others' code just isn't written to fit the way someone else thinks so it seems unnecessarily complicated and/or contrived.
What ? You have HANDLES on your urinals ???
What planet do you live on ?
I work on a space station you insensitive clod.
#!/
1. To stress a mainframe system takes an expert. They are called either systems programmers or more likely DBAs. (Most recent case, I stressed a Mainframe to 100% myself for about 4.5 hours during the July 4th holiday)
2. Mainframe = What do you mean, change the OS? Unix = Change the OS on the fly right here. Windows = What's an OS?
3. Mainframe = production WILL run, whatever it takes. Unix = oh, it will run, 8 to 5. Windows, re-boot and try again.
4. Editors = Mainframe = SPSF - nothing special, just edits what you see. Unix - VI - Virtually impossible - arcane syntax (the most user hostile editor ever written). Windows - Word - We'll do it for you, even if you meant something else.
Oh, I've done IT for 24 years, a degree is CS, programmed everything from OS/8 to DOS, to UNIX, to MVS, to VM, to Windows, to OS/2, to Palm, stopping off for about 7 or 8 DBMSes along the way.
On the mainframe, a programmer must have the concerns of system resources and getting it right the first time. Jobs for mainframe are scheduled to optimize system usage and consistantly run at a set capicity designated in planning. This said the worst thing that happens to a mainframe programmer is an abend (a job that fails and requires interaction, often causing other jobs to get backed up). Loss of system time means a significant loss of money in the mainframe world. That directly affects the process they must take to submit and run jobs. If they are coding JCL or COBOL, their code must be reviewed and run on a test mainframe if possible. It must be exact which takes a certain kind of programmer to get it right. As a suggestion in handling mainframe programmers, it is important to improve upon the stress that comes from deadlines and being right the first time. Most mainframe programmers I know are over stressed, over worked and need the support and coaching from their manager that will make their lives a little better. Be cautious of resource usage and allocations though and make sure they have a procedure for implemtation that is strictly followed. As a manager over mainframe teams, you should be strict with procedures, but don't hold it over your employees heads. They have a hard enough job to be constantly docking them in their reviews because of not quite getting it 100% every time. After all there are not as many mainframe programmers as they used to be, so keep the ones doing a good job. UNIX programmers on the other hand depend on what their designation is. System level coders usually have attitude to cope with and you have to take that in stride. On the System Engineers level, you have to also manage resources and allocations. It is important for them to worry about a balanced system performance and ensuring that a poorly written application can be dealt with, not causing pain to the other applications since it is a multi-user system. Proper tuning will handle this. On the application programmers side, the most important thing is to make sure the "big picture" gets taken care of. You need an architectural layout and design of your applications that will fit into the business model over all. The right people need to be consulted to ensure your programmers are not writing a peice of code that doesn't fit well. Code reviews and some level of strictness are required, but not to the level of a mainframe programmer. In UNIX you can recover and risk far less losses with application downtime than on the mainframe. Restarting applications here is not as costly. On the Windows side, it's about interaction and getting the product moving quickly. Windows programmers are either concerned about the tightness of the application or the features it provides. To properly write and deploy a Windows application, strict QA must be implemented and some minimal level of profiling must be done. The important factor is user perception in this case. You want the end user to see it run fast and have tons of features. It will have bugs and the bugs are not looked at interactively due to it running on a user system. You people need to be geared towards debugging problems with the minimal interaction available. This requires that your coders know their code in and out. You want to develop and culture that ability and make sure you keep track of bugs for improvements. Overall, people are people, but the stress levels of a mainframe coder are for getting it exact and right to prevent downtime and backing up jobs. For UNIX engineers and applications programmers, it's in stability of the system and proper interaction with the system and business architectures that is stressful. With Windows programmers it's in the end users perspective and timeline to release to market that is the most stressful. Realizing those things, you can appropriately develop a plan to help manage and cope with the managerial needs of your people. Keep in mind, if you are a resource and career manager, make sure you keep your people
root 10956 5164 0 Oct 22 - 0:23 sendmail: rejecting connections: load average: 70 (isn't sendmail just too kind)
As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers.
:)
So you have been managing a group for five years, and have no idea what makes them tick? Sounds like you're definitely management material
A computer without Microsoft is like ice cream without ketchup.
It scales to mainframe class performance, runs AIX and/or Linux in a partition, and can host and manage Windows servers all in one box. Truly amazing.
The unix way:
The Windows way:
Boy, I remember when that joke was about soldiers and Marines.
stripShow - Where WordPress meets webcomics
The significance is 17 digits which isn't quite enough.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
That was no beard, that was his wife!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
It's called a AM pocket radio and a very special stack of punch cards, you insensitive clod!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Ok, I have been at this working professionally with computers from 1988 on. I have worked on Prime, IBM Big Iron (VM/CMS), IBM Little Iron (RS6000), Unisys (Sperry and Burroughs), SUN, Windows, Unix and Linux.
The biggest cultural different is priorities. All the big mainframe shops I have worked at the goal was to keep thing running smoothly and be home by 5:00. All the PC shops (Unix and Windows) the goal seemed to be get it done fast but stay all night.
There is also a stronger separation of the programmer from the app. With the PC almost every user is responsible for programming (call it automation or whatever). Even the accountants are expected to write lots and lots of excel macros. In the mainframe world the goal is to just let the user enter the data and give her/him the answer.
There is also a stronger idea of operations; in the mainframe world there are programmers, system administrators, operators and users. Each with there assigned roles. In the PC world there are system administrators, power users and users, with the lines blurring at the edges.
These are just my general observations, and of course there are exceptions to every rule.
Mainframe guys (we are talking IBM type mainframes, aka big iron) are still in shock and awe over the mainframe's big data pipes (mainframes have channeled I/O and therefore can move a lot of data fast), structure and stability of the software. Why they will make such bold statements as "a mainframe NEVER goes down." and "You cannot break into a mainframe, it is way more secure than anything else." The truth is that they do go down and it isn't that hard to do. Just mention filling up a dataset, something any user can do. They also get broken into (duh!). Mainframe users deal with something called JCL (job control language) and they think it is wonderful, best thing since sliced bread. Mainframes also deal with data as fixed records - usually. Most of them still use a language called COBOL or PL/I. Some die hards may still use assembler. Mainframe users also have the illusion that they have more control than they do, they have to specify everything.
Unix users know they have the best OS around. In fact Unix runs on mainframe style hardware. Your unix box may run on a S/390 mainframe. So you have to virtualize the machine wisely to take advantage of the impressive capability of that machine. While the CPU's may not be impressive, the I/O is. Again - big data I/O pipes via channeled I/O. Unix machines think of everything as a file. Well most everything and if you keep that in mind you will be ahead of most people. Languages galore. Unix has been extended so much from the original it can do anything. It is also very, very stable. So stable the phone company has used it for decades. I have machines out there I haven't seen in years. Still running. Just update it remotely.
Windows users - they think they have the best OS and everything else is trash. Sometimes they make silly statements like "everyone is using it" and "they have most of the market" to justify it is somehow the best. It is plagued with security holes throughout. The languages available are varied - some are common and others try to lock you into Microsoft. Most of these guys are not that smart, unfortunately (paper certified, recently a little girl got certified as a Microsoft professional). Microsoft tries to do everything for them so they think they are much better than they really are. As a result a lot of windows programs are poorly written. Sometimes I'm amazed at just how little these "professionals" know. Then there is the famous Blue Screen Of Death (BSOD). Windows users will try to gloss over or trivialize any problem with the OS. Sometimes they will even attack you saying you "should learn something new."
Dealing with these three groups can be very challenging. The mainframe group should realize that even IBM and the other mainframe companies are moving to Unix based or Linux OS machines. It is just a matter of time. They should migrate and start using Linux/Unix. Most Unix guys are eager to help them make the transition. The Windows guys are usually too limited to work with. They will often say "Unix is too hard." As if they would know, they haven't even tried it. The best thing is to insist that they learn more of it. Send them to courses and such. Most see just how bad Windows is and switch. For those that don't I recommend you fire them. Let them be someone else's problem.
Joel writes in his review:
/usr/bin` at a *nix command prompt.
"The very fact that the Unix world is so full of self-righteous cultural superiority, "advocacy," and slashdot-karma-whoring sectarianism while the Windows world is more practical ("yeah, whatever, I just need to make a living here") stems from a culture that feels itself under siege, unable to break out of the server closet and hobbyist market and onto the mainstream desktop."
I think there is Idealism and Pragmatism in both cultures.
MS Windows people are economic idealists ("How do I maximize my wealth?") and computing pragmatists ("I'm not out to change the world, I just want to code for a living.")
*nix people are economic pragmatists ("Can I afford something marginally more satisfying and nutritious than Ramen to eat?") and computing idealists ("How can I maximize efficiency, stability and flexibility in my code?")
It's a question of what you're interested in forcing down the throats of others.
The MS Windows people are, fundamentally, interested in forcing a rigid "thru-line" mentality on their users to minimize the cost of development and maximize profit. This is, to my mind, best represented by the "Wizard".
The *nix people are, fundamentally, interested in foisting upon the world a huge box of tiny puzzle pieces (and the facilities to make your own, should the provided pieces not suit you) which all fit together to make just about any picture you might want to make, but requires that you learn how the pices fit together. This is becomes clear when a user types `ls
In either case, you have to become familiar with the local paradigm.
Joel derides the choice available in *nix. Fine. Enjoy your narrow, shallow MS Windows experience, Joel.
I used to love programming back in the "8-bit Home Computer" days... Then it became impractical to keep on using my tired old Atari 800XL... 5.25" Floppies became harder to find... I wanted to do things that took more than 64K of RAM... So I started with PCs... MS-DOS for starters, then MS-Windows... My interest in doing New Things faded quickly, because my options were so narrow, shallow, oapque and expensive. I trudged through MS Windows for years... doing things and being productive, but bever really loving it. Since stumbling across *nix (GNU/Linux, specifically), my love of computing has returned. My interest in problem-solving has flourished.
What's the difference between UNIX and Windows? Windows people are chained to a bench in the hold of a galleon, pulling their oars to the beat of a burly and unforgiving drummer.
UNIX people are SCUBA divers.
I'm a windows/Linux coder who has been forced more and more to work in an as400/RPG/CL environment. Honestly It has been hard for me to let go of OO, to just accept that 50% of the meaning of every line of code is IMPLIED, and to give up on having any kind of useful GUI tools. Not to mention giving up on having an editor where you can USE your mouse. (websphere SORTA works...)
;-)
It's really a whole different universe over in mainframe land, and frankly its just not where I wanna be.
Honestly I'm pretty convinced the RPG language has a personal hatred for me, and all I can do now is hate it back, and get a better job
for my part, when the mainframe way is run right, it can be efficient and slick, but without those rigid change controls, and with businesses pushing more and more for shorter devel times and more frequent changes, (at my company at least) we are rapidly finding the RPG/as400 platform unfit to our needs. The damn thing is just too hard to change and maintain...
sometimes, i wonder if i'm the only conservative on teh intarweb. ah well, back to mah hogs and warmongerin'....
The Computer History Museum had an event celebrating 40 years of System/360. Someone fessed up to being part of the JCL team, saying they weren't careful because they were in a hurry, and were sure it was an interim product, that something better would replace it.
The clearance system sounds logical. It is not. It is completely arbitrary. -- John Bolton
> a great many people would argue that the "UNIX way" is FAR more elegant.
This is one area where I feel the *nix techies are out of touch with a large part of the overall community.
I would absolutely agree that at its -best-, the Unix way -is- far more elegant. The problem is that only a very small minority of what is coded for modern *nix platforms is -really- coded "the Unix way." Most of it is coded as poorly as most of what is coded for Windows.
> UN*X is very uniform in how it works, just like a bucket of classic Lego bricks.
Not so much. I agree that it -used- to be. Unfortunately, a lot of what is coded for *nix now is just about like the poorly written Windows stuff. It requires 'X.1.1' version of 'Y' library.
"Oh, don't get version X.1.2; it not only won't work with X.1.0, but X.1.2 broke the hack we used in it. But you can download version X.1.1. No, X.1.1 is not available for download as a binary, you need to compile it. It's easy, just download this older version of gcc (newer version won't work), then edit the Perl script that builds the makefile. You need to change all the nonstandard paths to what's appropriate for your system. Oh, and you'll need to download the right version of these 17 libraries, too. That's it!" *
My point is not "*nix sucks, Windows rulez!" It's that the perception that *nix is this nifty, consistent, beautifully designed lego set is only true for a small subset of a typical *nix installation. Once you get past that subset, a lot of the differences disappear, and *nix developers run into the same crap as on Windows.
> Instead, you have an overly complex framework in the form of DDE/OLE1/OLE2/COM/DCOM that was
>largely designed to accommodate disjointed, inconsistent interfaces between various components/applications.
True. The only big advantage I see is that the COM object interfaces act as namespaces, and COM simplifies linkage. Every stupid thing being in the C/C++ global namespace is about as big an annoyance on *nix as Windows.
--------------
* as stupid as that sounds, it's real. I ran into this a month or so ago. Almost verbatim, except it wasn't a conversation. This data was mined from FAQs and forums, one error message at a time.
In mainframe culture, that's called "best practices." :-)
The length of the penis?
...you can google for your own links or use your imagination... I'm at the office.
penis #1
[ ] Unix
[ ] Mainframe
[ ] Windows
penis #2
[ ] Unix
[ ] Mainframe
[ ] Windows
penis #3
[ ] Unix
[ ] Mainframe
[ ] Windows
that urine is normally sterile, while your taliwhacker (point to the movie buff) is anything but. SO just the holding of it makes your hands dirty. IOW, the mainframer gets it wrong; again. But they think that they are doing the right thing and will fight your for it right after trying to force you to shake hands with them.
I prefer the "u" in honour as it seems to be missing these days.
The Mainframe's impact on Java is in the Java Message Service. JMS evolved from commercial MQ products that talk to the mainframe, but is now message queueing readibly accessible as open source.
http://www.linuxforums.org/forum/topic-40000.html
That's right, Bob. Listen to your friend, a person who makes more money than you is better than you, and therefore beyond criticism. This is called the Worthington Law [which reads "More Money = Better Than"] and it's used to gauge the value of human worth. Carl Espick, economist, and editor of Value Magazine. LINK
Be careful! Bears shouldn't consume large furry dogs.
Well done :)
3.243F6A8885A308D313
The Linus admin washed his hand before he pissed; no telling what those windows guys caught in their Email. It's just a matter of what's more important!
Apocalypse Cancelled, Sorry, No Ticket Refunds
So you are saying that someone took a shit, wiped it with their fingers, then went out and flushed a urinal just for fun?
To manage such a project takes a proliferate understanding of each culture. I don't profess to understand the windows bunch, other than there seems to be a reliance on GUI. When it comes to nuts and bolts: Mainframe world has lots of compiled languages (Cobol, JCL, etc.) These compiled languages are routinely "improved"?upon using assembly. So most Mainframers I know, are very nuts and bolts type people, who dig deeper than is required, so that if something goes wrong, they are prepared to fix it,and are by nature of the beast forced to follow more bureaucratic guidelines. This means, coding, and testing on paper, and forced "TEST" beds. More strict adherence to "best" programming practices, with only a couple of runs needed usually for debugging. Also, it is necessary to be more willing to share info with co-workers, lest your list be the same name as someone else's and you accidentally overwrite there's with yours. There is more of a "team" mentality in the Mainframe world because of the way a mainframe is designed to run.
Mainframes require load libraries for just about everything. Each job, has to have a complete list of files in the main library.
Unix: uses a hierarchal filesystem, in which direct references can be made to the filesystem because the way the OS libraries are set up.
This allows a more interactive approach to the programming debugging process. This also makes it easier to make use of private copies of things, and less likely to "interfere" with a coworkers project. While "open source" promotes sharing of ideas, most Unix people still want to do as much as possible on their own to get credit for their hard work. While sharing of information is crucial here, it is not as required as it is in a mainframe world, so the unix person is not as disciplined in this area. He is more disciplined in follow up though as he is used to having the time to debug on the fly. This often though leads to longer project times, as the design phase is largely neglected by many (not all) unix people. I know, I'm one of them.
My take on windows people: Concepts of design are restricted to what Microsoft tells them is the way to do things, and is already available as a pre-made programming module. Sharing of information is not vital, because it's ok to overwrite someone else's copy and it's the other persons fault if there program doesn't work when you overwrite their dll.
Windows programmers I work with use the SEP field a lot. (Somebody Else's Problem). If the scope of the original project did not include the new feature request, or it doesn't already exist as an easily addable module, then it can't be done. MicroSoft's mantra is "don't share anything, unless a profit can be made only by us."
True, there are lots of people out there who fit all 3 categories, 2 of the categories, and groups not covered. And these are stereotypes. But if you understand these stereo types, you can understand what kind of things to expect when trying to manage a diverse group as a single coherent team.
Best scenario for a group project: Let the mainframer's specify final data format, and work with Unix Gurus on protocols.
Unix gurus should define protocol and data exchange formats.
Windows people should define UI.They are closer to the end users needs.
Together they should work on how to piece it all together.
Unix guys can be used to translate necessary info from mainframe talk to PC talk and back, since unix takes lots of cues from both worlds.
The filesystem in Windows, is a strange beast. At best it is a flat representation of something that should be hierarchal. This also describes the programming mindset. Not because that is how the people work naturally, but because how they are forced to think to make the problem fit the platform.
"Brrr, it's a titty bit nipple out(BLUSH) err, I mean a little bit nippy out."--ME walking w/ some coeds on a cold day.
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:
What a load of hoo-ha.
If anything, a gui allows more controls and greater information density, nevermind grouping and context control MUCH easier than any of these ascii kludges.
Is there any reason we couldn't use guis as a tier and script our backends? not really although it isn't the MS Way.
But to somehow take that to mean that ascii ui's are good? gah! even if MS thinks I want buttons that are made of candy for some &^$&ing reason,
At least at that time. If your program in a tight loop and doesn't do any concurrent I/O, it will continue runing forever. That's why every job on MVS had some implied CPU time limit. Once the job has exceeded that limit, the whole thing is cancelled.
and I know something about MVS internals, probably more than you'll evern now.
TSO? It's a hack. It has never been succesfully integrated into MVS. I've worked enough with TSO, by the way. TSO, as any interactive task, does lots of things dynamically, and this intefers with the whole spirit of MVS which attempts to preallocate resources before the job is scheduled for execution. TSO is nominally interactive system, but try to do to any extensive work on that.
Oh well, going through the rest of your messages, let me explain you something. I've been working as Mainframe application programmer for a couple of years (mostly BAL/370, even if you believe there is no such thing), then for about 5 years as a systems programmer on MVS/XA, MVS/ESA, and VM/XA and VM/ESA, did some installation, configuration, performance and tuning, then switched to mostly VTAM and SNA for a couple of years, and then drifted to TCP/IP. I know MVS and VM internals quite well.
You, on the other hand, is mostly full of it.
It is true that MVS is not conjusive to play or experiment, though I do know of some old-timers who went to a lot of trouble to build themselves a sandbox. While it's no trouble to set up a JCL card and submit some job to JES (if you have some templates handy!), and there are some pretty powerful scripting/pattern crunching tools, like REXX, the pipe metaphore is missing so it's difficult to build "bottom-up" like a Lego set, as someone else pointed out.
So yes, there is another difference in Mainframe culture...
cheers.
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
Windows: clickity-click lickity-split
*nix: tapity-tap lickity-split
Mainframe: ZZZZZZZ zzzzzzz.....
> Later that afternoon, the Mainframe admin got a horrific case of E.Coli poisoning from the handle of the urinal.
Mainframers don't flush, they have hardware to handle it for them...
I have worked in mainframe shops so full of hacks you have to watch your fingers lest they get chopped off.
> 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.
Not entirely. Most Windows developers aren't interested in other platforms, and get all their information from Microsoft documentation. This limits their exposure to the context that would allow them to see what MS created and what they didn't.
Worse yet, many Windows developers have never read the actual documentation, but only the "study guides" for various certifications. So while developers who actually -read- Microsoft's COM documentation would have been aware of other sources like the Object Management Group's DCE specifications, and how they were used in Microsoft's design of COM, most haven't.
Add to that the fact that most have never worked outside of Windows, and you have people with a very limited world view. They can parrot back a few things, but they don't have the broader experience to make use of a lot of the data.