Slashdotting mainframe culture: "if it ain't water cooled its just a terminal"
Its fun reading a recent post on slashdot if only to see the complete balls spoken about mainframe by people that position themselves as experts. The post is about the differences between Windows, Unix and.. mainframe cultures. Ignore the first 60% or so, which is low signal to noise, and head on down to the more interesting discussion.
I particularly like this exchange:
PorkyPig says: "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."
Here is the takedown, sadly by anonymous coward:
"This post was so full of hooey I don't know where to begin.
MVS (batch oriented)
Have you never heard of TSO? CICS? IMS/DC?COBOL provided some basic routines, but do to something interesting (like asynch I/O
Merde. The access methods (I/O services provided by the operating system) have ~always~ supported multiple buffers, chained scheduling and other goodies. MVS and IBM big iron in general is really really good at I/O overlap.MVS (at that time) didn't have anything like preemptive multitasking
Complete rubbish. MVS has a variety of dispatching algorithms including time-slicing, MTTW, task/address space priority, and others. The preemptive dispatcher goes all the way back to MVS's predecessor twice removed, OS/360 -- comfortably older than you likely are, Porky.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
Curious, since there was no such thing as "BAL/370". There was a BAL -- "Basic Assembly Language" (no macros) for BPS, one of the first early monitors for S/360.All I/O was executed in a separate subsystems (channels)
You idiot! Of COURSE all I/O is executed outboard, in the channels. That's why the m/f systems are so good at it.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
Okay, I've figured it out. You took a summer internship at an insurance company, and you augmented your l33t Apple skillz with some 370 assembly language. The workaday COBOL guys lionized you and you became quite full of yourself. The insurance company was running storage constrained, or was running their channels above 80% utilization (post-XA) and response time was an issue -- and you naively assumed that the MVS dispatcher was somehow at fault.as I understand, MVS fundamentally remains batch operating system
You understand nothing.
But the post I like most is poorly scored. What's odd about mainframe programmers, differences I have seen over the years?
Upon the 4th month, at the stroke of midnight, they will deliver the code.
It's funny to say, but terrifyingly true. I've gotten to the point this seems normal.
Although my boss is growing more and more grey hair these days.
Yes- delivering code on time. How weird is that? I have at least one great conversation with Microsoft, where the person I was talking to said "that is impossible. no company would guarantee a six monthly set of requirements delivered to the market, as per the plan... "
Well no company except IBM perhaps, and don't get me started on the "we delayed it for reliablity reasons excuse". If IBM used that one it never would have got 360 to market, let alone any new function.
For my final word on the subject I turn to sinewalker, who makes a great point that people using other computing environments should respect, and learn from, their "elders". Of course such commentary is not exactly slashdot fodder, but he makes some great points (its all about change management):
Apart from the obvious religious stuff about GUI (or lack of) and user-centred interfaces (or lack of), the biggest difference, and the biggest advantage that Mainframe brings is it's culture of process and change control. It is something you should strive to let your Mainframe masters pass on to the *nix/windoze padawans before they die of old age.
I am a *nix padawan, but, crocky technology asside, I'm frequently impressed by my Mainframe elders, their ability to deploy code to Production environments that works *the first time* nearly every time, and their ability to communictate technical changes necessary to fix broken code in the middle of the night in the 0.1% of cases where they failed to get it working first time.
Key values that I have picked up from my masters, and which should be inherrited by both *nix and PC/Mac enclaves are focused around Engineering principles. Mainframe guru's program like a civil engineer builds a bridge. No shortcuts are taken unless it can be proven that it is safe to do so. Testing is carried out in stages and test results must be submitted with the change request before a program migrates to Production. If a program must "abend" (Abnormal End) then it should do so noisily and with as much information as possible. If it finishes cleanly, little information is needed other than this fact.
These closely follow the advice Raymond has encoded in his book, but there is probably much more that your Mainframe gurus know that you should cherish 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.
So that's you guys. "Cruddy mainframe technology" though - any takers? If you feel like educating any of the slashdot newbs with your l33t skills head on over to slashdot. And remember kids- "if it ain't water cooled its just a terminal"
|by James Governor||July 31, 2006 |
Permalink | Comments (8) | TrackBack (0)
More mainframe, less Prozac
Some tongue-pierced punk hacked into my alma mater’s computer system and now has my contact info, my social security number, and worse, my midterm grade in macroeconomics. I’m slowly working my way through the five stages of hacker-victim grief: Denial, anger, depression, hunger and acceptance. (I’m not sure if hunger is one of them, but I’m writing this just before lunch).
When I first read the confirmation letter from the university, I was consumed by the fear of the perp scampering through Willowbrook Mall with a credit card issued in MY name, racking up five-figure bills at Sears Roebuck, Lane Bryant, maybe the Piercing Pagoda. I was pretty upset with my university’s management. All these depressing thoughts filled my head: Why me? Will this permanently ruin my credit? Wonder what they’re serving for lunch today in the cafeteria?
But then, I had a moment of compassion. Can you image the anguish that the university president experienced when he got the news? How he must have struggled with a team of maybe dozens of people to draft the email informing the students, faculty, and alumni (the donor base)? What will this cost in legal fees, PR agency fees, in lost tuition and lost donations? I can’t begin to guess what the total is, but I’m sure it would easily pay for a mainframe.
The LA Times reported Wednesday that this year in the US more than 800,000 people at colleges and universities have had sensitive information exposed in more than 30 security failures. When I consider this trend, and the fact that only the System z mainframe has earned the EAL5 security rating, (see Computerwire: "IBM Gets High Security Marks for Mainframe" ) I wonder why don't more schools run on big iron.
As the "vic" in this story, it will be very difficult for me to donate any more money to my school unless I know those funds will help pay for a mainframe. Since my school allowed this crook to assume my identity, then maybe they should allow him to assume my student loan debt.
|by Timothy Sipples||July 28, 2006 |
Permalink | Comments (0) | TrackBack (0)
History Just Made
Speaking of history being made, I'm curious: now that the zIIP and its associated DB2 updates are shipping, how do you, my fellow blog readers, like this new mainframe processor? Are you enjoying your zIIP?
|by Timothy Sipples||July 22, 2006 |
Permalink | Comments (4) | TrackBack (0)
Hurricane prep checklist: Flashlight, batteries, mainframe
An article in Enterprise Networks and Servers shares lessons learned from Katrina and why the mainframe is essential.
|by Timothy Sipples||July 8, 2006 |
Permalink | Comments (0) | TrackBack (0)
online gaming on the mainframe
Just another typical mainframe customer, except it's not a bank, but an online infotainment company. And not a large corporation, but a company with only 50 employees. In Brazil. Linking thousands of concurrent users across the globe via Linux on the mainframe.
Read more about Hoplon in BusinessWeek Online
|by Timothy Sipples||July 7, 2006 |
Permalink | Comments (1) | TrackBack (0)
More alive than England in the World Cup
For those of you who don't follow football (or think it involves a pointy ball and lots of padding) a thing called the World Cup is going on in Germany at present and England got knocked out at the weekend. This, of course, has brought many people to sadness / hangovers or whatever. I don't follow football, so I was dead happy on Saturday evening to be out on the golf-course, because it was empty!!!
So what's better than the England football team? Well, the mainframe of course. Look at this link, and this pretty picture (many thanks to Mark from Arcati for the latter):
|by pwarmstrong||July 3, 2006 |
Permalink | Comments (1) | TrackBack (0)
The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.