« More mainframe, less Prozac | The Mainframe Blog Home | Intro to MF Redbook »
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/OMerde. 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 multitaskingComplete 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/370Curious, 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 solutionOkay, 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 systemYou 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 |
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834521c8469e200e5507dd8dc8834
Listed below are links to weblogs that reference Slashdotting mainframe culture: "if it ain't water cooled its just a terminal":
Comments
This http://ask.slashdot.org/comments.pl?sid=156246&cid=13099876
response is one of the better ones. Need to turn that into business value for today's SOA business managers.
Posted by: Harry Alton | Jul 31, 2006 5:39:27 PM
Classic - should change his name to pig ignorant.
Posted by: Peter Armstrong | Aug 2, 2006 12:17:28 PM
Similar to "if it ain't water cooled", one fellow I know always says "I'm not interested in any computer I can lift."
Ross
Posted by: Ross Patterson | Aug 7, 2006 2:12:08 PM
that is indeed a classic Ross. Porky pies-lies, eh peter?
Posted by: James Governor | Aug 30, 2006 3:57:56 AM
A) If they didn't have a cross-reference, that was their own frik'in fault.
B) > "I've ended up writing fairly efficient program.". How does he know? Maybe operations (etc.) didn't like it because they were looking at the RMF reports.
C) COBOL and BAL, eh? OS/360 shipped with an ALGOL compiler, for crisakes! (I still have the manuals). PL/1 wasn't to far in the future.
D) *Water* cooling? Amdahl boxes were always air-cooled, and IBM dumped water cooling years ago because there wasn't that much heat to get rid if. I've been laughing myself silly over the need for these vast blade server farms to be water-cooled 'cuz there eat so much juice and put out so much heat!
E) Delivering something with the reliability of the average small-box app (or Windows) would be a career-ending move in the mainframe world.
Posted by: Bill McLaughlin | Aug 30, 2006 9:38:09 PM
While the original article showed an arrogant attitude (or at least not lacking in self praise) the comment that MVS was basically a batch system may actually be correct if you discount the transactional and online services provided by the subsystems. However, even if you accept that definition MVS now is a transaction system.
The transactional primitives of loggers, recoverable units of work etc. have now been built into the base of MVS. APPC support followed by RRS provide interfaces for 2-phase commit. These can coordinate work across multiple systems (e.g. IMS, CICS, WebSphere etc.) and provide 2-phase commit protocols to supporting systems on other platforms.
Seems to me many "modern" operating systems still lack such functionality and rely on middleware to provide this.
z/OS supports online subsystems, independent batch systems AND integrated transactional support.
The assertion that the MVS dispatcher was deficient is laughable. The richness of the MVS dispatcher has always been its strength . It has continually been enhanced to its current tight integration via WLM between SLA's, multiple subsystems and the hardware (PR/SM weights with IRD, Disk I/O priority and network). And with the virtualisation engine WLM is a full participant with e-WLM to provide heterogeneous enterprise wide scheduling.
Given the symptoms described either the customer did not correctly setup scheduling rules or did not enforce job classes and this job was inappropriately run in the wrong class.
When we start to discuss the issue of I/O, anyone with a semblance of knowledge of I/O systems knows that the strength of the 360 architecture was its isolation of I/O execution from program execution. Not only does this increase security but it also reduces interruption to drivers to manage I/O activities. Because of this the original 360 design point was that I/O was asynchronous to program execution. This was provided within the operating system. The application would be placed in a wait and another task dispatched. However, the assembler macros for system services supported both LOGICALLY synchronous and asynchronous operation.
The area where the I/O could become synchronous was on the channel. For selector channels (as opposed to byte or block multiplexor channels) only one operation could be active on a single channel at one time. By the time S370 came out selector channels had been replaced by block multiplexor channels and multiple concurrent block channel programs could be active on the same channel.
As has been the case since the beginning of computing the speed of computation increased faster than the speed of I/O. This meant the time for a channel to accept [as opposed to execute] a channel program did not improve at the same rate as the processor speed. This meant the processor could wait for the channel to accept the channel program [in a similar way a processor today may wait for data to move from memory to the cache]. The SIO instruction was replaced bt the SIOF instruction. This assumed all SIO's were successful. If the channel start actually failed an interrupt would notify IOS which would take corrective actions.
The net of this is I/O in S360 has multiple layers of asynchronous execution, the ability to overlap I/O and application within the application, start the I/O operation with the subsystem and execute the I/O in the subsystem without consuming processor cycles.
Posted by: John Crooks | Sep 22, 2006 12:45:20 AM
