as part of a "mini-mainframe" package, one that would give users the simplicity of distributed systems. Here's what some of you had to say about the article.
Past failures spell doom
There isn't any market motive for IBM to do this. Do you remember OS2? It was a powerful multi-task operating system that had many of the features just being introduced into Windumbs. The market would not respond.
Scaling up to traditional mainframes and other points
Good thought, but with some serious points needing to be brought up:
- Today's 64-bit multi-core x86 CPUs on a server motherboard that supports really serious memory (256 GB 'real,' with huge swap file potential to at least 2 TB) should be able to handle most everything (except the channels that 'Big Iron' is known for). Of course, the motherboard might also want to be capable of, say, 64 network connections plus external storage, etc. Why not support multiple CPU chipsets, also, along with multi-core?
- The best niche to 'open' the market would be a configuration capable of JES/CICS with DB2, IMS, and VSAM and COBOLII compiler, and of course assembler and linker -- sell it for SOFTWARE DEVELOPMENT and unit to 'light' system testing. Today it is difficult to find a course on COBOL in the USA (not so hard in India). Possibly include software component software, like Endevor or Panvalet, also.
- z/OS' ability to 'push hardware to the wall' (run at essentially 100% without crashing) relies on being able to 'tune' the system (establish workload priorities in extreme detail) for what's running -- some system tools will also be required to allow such tuning, especially for multi-core thread handling. Thus, it can also be used to train systems programmers as well.
- CICS can drive HTML interfaces, so all the machine should need to be able to 'display' would be VTAM, TSO, and CICS (perhaps something 'like' TPX, also). Windows emulation, done 'perfectly,' would be grossly inefficient and unstable compared to JUST z/OS.
- When the idea of 'distributed mainframe code development' catches on, many customers would want to scale up (and software should be capable) perhaps even to a 'traditional' mainframe.
IBM with similar systems already in place?
Just read the "Running z/OS on x86..." piece.
IBM has exactly such a system that is currently available only to Independent Software Vendors (ISVs) called zPDT. (System Z Personal Development Tool).
I read the article with some interest as this is an area in which I have been active for some years. IBM already has a 'mini-mainframe,' albeit only for developers with the zPDT product (I co-authored the original Redbooks), and there have been other players in the market who have already provided such a solution. Fundamental Software, Inc. has their FLEX-ES product, which, when running the ADCD, performed basically everything that the article talked about. Some years back, there was also the UMX product and now there is TurboHercules. There are numerous articles discussing all of these systems.
The "mini-mainframe" will remain a dream
You won't get many arguments from like-minded peers. There isn't a real sysprog out there who wouldn't jump at the chance to have a personal mainframe. Many of us just have to make do with Hercules and MVS 3.8J. While many of us have expressed exactly your sentiments to various strata in IBM, there are some realities that keep IBM from doing what we all wish they would.
- IBM already has systems targeted to the SMB space, namely iSeries, pSeries and xSeries blade centers. They went through an extremely trying period where the "gloves came off" and iSeries and zSeries sales teams competed with each other to put their respective hardware systems in SMBs. Things actually got pretty nasty on more than one account.
- IBM doesn't like small customers to have mainframes. It's a dirty secret, but it's true. Unless you are a large federal customer, a megabank or an insurance company, IBM will not deal with you directly. You are assigned to a "business partner." Like all middlemen, all a "business partner" really does is boost the price so they cover their margin and profits and submit an order you could have done yourself, often with much greater accuracy.
- From the small customer's perspective, z/OS is mammoth operating system. Whether you have a system that runs 150 CICS regions, 25 DB2 instances, and processes thousands of batch jobs each night, or you have a couple of TSO users manually entering data and churning through it with a handful of COBOL programs, z/OS is still the same size. It takes a certain amount of administrative overhead regardless of how much stuff runs on it. There's no way to get below the minimum requirements.
- Software vendors suck. It's incredibly obvious that the independent software vendors, especially the large, monolithic ones, are killing the golden goose. Here's a real example: Let's say you have a 95 MSU z9 that runs 3 production LPARs. One LPAR runs 70% of the box capacity, another runs 25% and the last runs 5%. The LPARs do not run sysplex or share data in any way. They evolved over a few decades on different machines -- now they are consolidated on one box to realize economies of scale.
Add to this that you are running sub-capacity and overall you are softcapped at 75 MSUs. You manage your resources very well, so you never go over the rolling 4-hour average and your company saves over $10K per month in IBM software license charges.
On the 5% LPAR, you have a critical piece of vendor software. When it was running on a very small separate CEC, you paid a relatively small license charge. Unfortunately, the ISV does not do LPAR pricing, so when you give them the new box's serial number, they charge you for the full 95 MSU charge AND they want to charge you over $300k just for the privilege of running it on a different machine!
Here's the gravy...they decide you're taking food out of their mouths, so they "calculate" the technology dividend between your z9 and the corresponding z990 and decide your machine actually runs at 123 MSUs, not 95. For that, they want to charge you an additional $250K just because they deserve it AND they want to increase your annual maintenance charge from $6K to $75K. And all of this happened without you realizing a single iota of net benefit.
I'm a second generation IBMer. My dad worked for them for 36 years. I've worked with mainframes now for 25 years and have done just about every role there is. I've been an operator, a developer, a CICS sysprog, a DB2 DBA, a security specialist, and spent 13 years as a consultant in various capacities. Currently, I manage a team of sysprogs for a Fortune 200 manufacturing company. I am also the technical lead, so I'm still a working manager.
IBM isn't going to push z/OS down to the small business space and they are going to do anything they can to keep from cutting the throats of their other platforms that are targeted to SMBs.
Those of us who truly enjoy mainframe technology will just have to be content with Hercules and MVS 3.8J.
So "mini" obstacles for the mini-mainframe...
Not a bad article…just some thoughts from an "old" systems programmer. Yes, it would be nice to have a "mini-mainframe," but there are some "small" problems. Even today, the toy hardware is not on the level of, let's say, 158, maybe not even on level 165, so working on all (well, almost) hardware since the late 60s, we, the industry, have a long way to go in catching up to what we enjoyed in those 360/370 (real) mainframe systems.
Once we get a "mini-mainframe" to the level of 158 (the base, 1 MIPS!) supporting 2000+ IMS/CISC/TSO users for a huge insurance company, having (at last!) 16MB memory (wow!), under 1 second response time(!!), around 60 (insurance!) transactions/second, databases for 4.5 million customers, about 100K screens, 18K online applications (full global insurance is interesting), etc., then we can start talking. And this was at the end of the 70s!
Anyhow, I would love to see a mini-mainframe. Because of data dictionaries, catalogs, good software/configuration management, built-in security, dynamic configuration, well-educated (and platform-trained) developers and operations, memory protection, pipeline recovery, and so on, it was so easy -- it will not happen (IMHO). Why not? There would be no money for vendors/manufacturers. You ever wonder why IBM has tried to kill VM for about 40 years or so? No money, especially in hardware, which (still?) is in the minds of some!
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at email@example.com.