Many techies are wary of mainframes because of the myths and mystique surrounding them. There are three main myths about mainframes:
1 They are hugely powerful.
2 They are very complicated.
3 They are ultra reliable.
None of these is actually true, let’s have a look at each of them and see what the facts are.
Firstly mainframes are not all that powerful; their clock rates are actually quite low because they have to propagate the clock over a long distance rather than just across a chip. They achieve much of their performance from smart pipeline and parallelism but like any parallel system this implies particular workloads. This workload type is the key to mainframe performance, given the right sort of load they do perform really well. This “typical” mainframe load is basically running OLTP type programs against simple hierarchical databases with text only output to a 80x36 text display. Mainframes have been set up to handle this load really efficiently which is where they get their reputation for performance. Give them a complex VB type application or even a complex database application and they struggle, in fact they can be a lot worse than a Windows Server.
Mainframes are very complicated from a hardware point of view but from a software perspective they are much the same as any other system. The operating system, languages etc are much the same as a Windows system. There are two main areas of difference however and these are in the connectivity and the middleware running on the mainframe. Whilst these are different they are not actually more complex, it’s just the terminology is different, in fact as pointed out at Life as a Reformed Mainframe Programmer in the .Net World MTS and CICS are very similar. I will write up a mainframe 101 to explain mainframe comms and middleware in MS speak to show this.
Mainframes are made up of lots of parts and connections and so are inherently much less reliable than a Windows server. Of course in real life the key thing needed to provide reliability is operations and maintenance not hardware or software and that’s what mainframe shops are great at. If you take a system (Windows or mainframe) and put it in a sealed environment with rigorous fault, error, upgrade and maintenance regimes and a static, well understood workload then you will get similar reliability. If you abuse the system in any way then the reliability will tumble. I have a really fun story about sex in a mainframe causing reliability problems that I have been told that I can’t publish so you will have to imaging the details!
Microsoft had a marketing campaign around reliability and five nines a few years ago which really annoyed me. It implied that if you used Windows then you would get five nines which is of course silly. Most downtime is caused by poor operational procedures rather than the software.
YES! Somebody else voices my opinions on mainframe reliability. The same can be said of any system that continuously performs a limited set of functionality (most unix servers, etc.)
I disagree with your statements regarding mainframes. It has so many wrong assumptions that I strongly suggest to pick up a book or visit data centers.
First of alle you can't compare processor clock rates, this sounds like an absolute n00b trying to say something sensible about a computer, its like kicking the tire of a car and saying something about how fast it can go.
"Mainframes have been set up to handle this load really efficiently which is where they get their reputation for performance. Give them a complex VB type application or even a complex database application and they struggle, in fact they can be a lot worse than a Windows Server"
This is complete BS. I don't use a Ferrari to plow a field, you should use a system for what it is meant to do.
"Mainframes are made up of lots of parts and connections and so are inherently much less reliable than a Windows server."
Again total BS, the components used in a Mainframe are of a higher quality and make you will ever find in your Windows-box (thus the price), besides the whole architecte of the Mainframe is aimed at continious operations, which goed beyond a dual power supply, cpu and memory for most Windows servers
I could go one based on the wrong assumptions in your article but will leave some of it for you to find out :)
Please do a proper Mainframe 101 before starting to write one.
Thanks for your opinion Greetz, I agree that clock rate etc is a poor indicator of relative performance and so I wasn’t doing so in my blog, I was just pointing out some of the issues with architecting large systems.
I totally agree that you don’t use a Ferrari to plow a field, that is exactly the point of my statement, mainframes are set up for specific loads, not vb etc.
The argument about component quality vs component numbers is a very old one and there is a lot of statistical data around this. It depends a lot on the number of connections and there are a LOT of connections in a mainframe.
I started working on mainframes and mainframe subsystems design for IBM in 1972, first on the hardware and then on the software side of things. I have run major datacenters in IBM and was in R&D for IBM for 20 years both in development and Research and have numerous patents, publications and awards from IBM for my mainframe work.
Thank you for your advice about how I can improve my knowledge, I am always prepared to learn new things however I feel that reading a book or visiting a datacenter is unlikely to teach me much more that the 20+ years of real hands on mainframe experience I already have.
I am suprised that, considering you experience, you make such statements without proper backing.
"Give them a complex VB type application or even a complex database application and they struggle, in fact they can be a lot worse than a Windows Server."
I do have to come across the first VB application on a Windows Server running the same magnitude of applications/data on a mainframe and serving the same amount of connections.
And truly what is "complex", handeling TB of data is no issue considering some of the systems I have managed as is running vast collections of conccurrent applications serving 100.000+ connections over dispersed locations in the world --- this is an actual situation within a large bank.
Let aside the security provided by RACF
My point, backup your statements before jumping to conclusions. Good luck with your Mainframe 101.
ps: I have knowledge and experience within the financial domain, covering most of the development and deployment lifecycle of applications on several platforms, ranging from Mainframe (IBM, HDS, etc), mid-range (AS/400, Unix, etc) and Windows Servers in various configurations (Wolfpacks).
Long time since I heard of HDS!
I meant UI based apps such as VB. I think you would agree that running a heavily UI based VB type app with multiple frames, boxes, pulldowns etc is not the sort of load a mainframe likes.
Whilst I have never run VB on a Mainframe (!) I did a lot of 3270 work and indeed designed a terminal (8775) which did in head field validation for exactly this reason. I also struggled with the poor TCPIP providers for many years and even SP's in DB2 (and dont much like either!).
My point is exactly the same as yours, mainframes are tuned for very high numbers of SNA connections coming in over VTAM to a multi region CICS system and running huge numbers of transactions, not for the sort of widly varying loads windows boxes see.
It truly depends on your definition of complex; large throughput loads is one definition, very variable loads are another.
Sorry, I have never been a fan of RACF so you wont convince me on that point!
I'm suprised you put UNIX and AS/400 in with mainframes, hardly the same :)
"I'm suprised you put UNIX and AS/400 in with mainframes, hardly the same :)"
I had put them together as we have postioned them as midrange computers within our organisation (about 350 AS400, 400+ RS6000 and about 300 HP-UX), the mainframe environment consists of Tandem, IBM and HDS systems.
Do you have an idea when you will have finished your Mainframe 101.
I do think we are talking about the same; yes, indeed a mainframe will not suffice within a very rich GUI environment.
In my view mainframe will shift from the business layer to database back-end layer, most of the software we develop nowadays accesses the mainframe only for data operations. Much of the business logic is handled in the middleware and whereas presentation is concerned, it depends on the requirements of the end-user, thin client and/or web-based.
The 101 is just intended to put some of the mainframe terms in windows speak, eg CICS provides the same functionality as MTS, VTAM as IIS.. any yes I realise these are gross generalisations but just to get a rough understanding. Hopefully a couple of weeks.
I agree about the use of mainframes for data access but in general I recommend leaving CICS is place rather than going straight to the database and using it for locking and stored proc type functionality. Mainframes as straight DB servers worry me, it comes back to what they are good at, very high througput transactional loads. I wouldnt want to get too far from that.
What is your feeling about using them as straight DB servers?
There three scenario's, which I can see unfolding regarding mainframes:
1) Mainframe as straight database server
2) Mainframe as web server
3) Mainframe as database/web server
1) Mainframes are actually performing this task already, the fact that we strip the presentation layer and move the business logic (COBOL, PL/1) to another physical machine, will utilize the full potential and resources for database access. The use of a TP monitor as CICS/IMS is absolutely imperative to maintain scalability troughout. This a VERY LIKELY scenario.
2) Your comment?
3) Your comment?
Totally agree about 1 provided CICS stays in there
With 2and 3 I am not sure. Mainframes are tuned for SNA and I spent years trying to get decent performance with TCPIP. I think there was a problem with the buffer sizes in VTAM but I could never get it to perform. Of course this was a long time ago and so maybe IBM have fixed the problem and got TCPIP to perform. If not then I dont see how you can get a web server to perform very well on a mainframe as a web server is very tightly coupled to TCPIP.
Love to try it and see, sort of thing I would go down to the labs and try when I was in IBM, alas Microsoft dont have a spare mainframe lying about, or at least wouldnt admit to it if they did!
I do see IBM gearing up to implement TCPIP on mainframes through the use of of OS/390 and Linux. IBM has made some major improvements in OS/390 concerning TCPIP performance, don't know though what is considered decent performance :)
Greetings, going to bed, its late overhere :)
Thanks for the link. Totally totally agree in wrapping CICS as a web service, it is the way to go, I think you may have to have the web part of it hosted off the mainframe but it is the obvious way to go.
IBM has been saying for ever that they have fixed TCPIP performance, I am just dubious. I think there is something deep in the architecture of VTAM that causes problems. Anyway I think you are just better putting the Web server on windows, thats what it's good at.
The whole area of services and the mainframe is really interesting. I went and saw a customer who had made all their mainframe functionality into services and it worked really well.