A small mainframe software tool developer called Neon Enterprise Software has opened up a can of worms - and quite possibly several cans of Big Blue whoop-ass - by launching a new tool that will allow customers to shift a larger percentage of their workloads from standard (and expensive) mainframe engines to the cheaper …
The 'specialy engines' in a Z are just normal CPs with restrictions on them in microcode so they can only run certain workloads. So I've always looked on them as just a sales tactic rather than a hardware aspect.... In that case they should be able to run any code just as any other CP with the proper hacking of microcode or low level instruction modification. I don't see this as a software innovation by this company - its a hack of IBMs OS - but then again the sales method that is zIIP,zAAP, IFL is to allow cheaper workloads to be ran on the mainframe (Strategic like Linux) or push certain IBM software on the mainframe (zAAP = Websphere, zIIP = DB2) so IBM will not want this to continue thats for sure. They'll probably buy the company and mothball the product....
Buy the company to bury the product?
That would probably cause a couple of lawsuits and would further cause decay of the mainframe.
You tell the customer ... well yes while you're paying $2000.00 to run your software, with a known change in microcode, you would only be paying $2.00 to run your software ... (Prices made up...)
What you've done is outed IBM's price gouging practices along with a realization that you can run your app on midrange (Unix) systems that are far cheaper and more resilient than the mainframe. (Hint: You try replicating your mainframe data center and then see how much it would cost...)
Oracle and Microsoft have been attacking IBM's profit center. IBM won't release the numbers, but if you listen to the street, there are some major projects under way. Only one thing. Neither Microsoft nor RAC scale efficiently. The only saving grace is that the majority of these mainframe apps would port and scream on hardware than now fits in to a 'pizza' box or two.
Fail because IBM's business practices are eroding the trust people had and their current business practices as a whole are killing the company from the inside. It just goes to show you the greed and mismanagement that will kill the company, all in the name of almighty profit.
Assuming you're not trolling...
"further cause decay of the mainframe."
The Linux stuff reinvigorated the boxes. That said, it may only have stabilized the market and now it's relatively static, but it's not decaying. Go look at the LINUX-390 list to see how many people are using this stuff and what they use it for.
"You tell the customer ... well yes while you're paying $2000.00 to run your software, with a known change in microcode, you would only be paying $2.00 to run your software ... (Prices made up...) What you've done is outed IBM's price gouging practices"
Known situation. Anyone who's worked with these boxes long enough knows where the limitations are, how its done and why. This is nothing new.
"more resilient than the mainframe."
This is just utter rubbish. No, don't argue, it is. IBM's boxes and OSes these days - as for the last 15 years or so - are vastly more reliable, have better throughput, handle the workload better, are better "built" (i.e. not so many hardware problems, hiccups, handle dumbos pulling out disks from RAID arrays etc. etc. etc.) far better than any of the SUN, HP/Compaq, Apple or even Cobalt/Rackserve stuff I've seen over the last 10 years.
(Aside: a lot is made of the ability these days of x86 solutions to be able to migrate virtual machines and/or workloads to other boxes when one fails. IBM's VM system was doing this in the 1980s. I believe that the code was eventually removed because no-one used it because the boxes are so reliable - unlike the x86 based hardware I've had the misfortune to have to run datacenters with.)
" (Hint: You try replicating your mainframe data center and then see how much it would cost...)"
Cost is not resiliency. The cost model for these two situations is known; the variations thereupon which may or may not take into account hardware failures, throughput etc. etc. etc. are also known. Furthermore, you don't necessarily replicate your Data Center. You ensure that your systems can be brought up elsewhere and most of the DR places I come across utilize zVM for that sort of thing.
What you want in one situation isn't necessarily what you want in another. It mostly depends on your business model. For example, one place I worked at spent ages trying to convince a shop to set up multiple managed Solaris & Windows systems. That was their chosen solution for the customer - they called it their "premium" solution. Another shop punted a zVM system and multiple Linux instances to the same customer. Vastly reduced cost, easier managability, less people needed, data center backup and DR easily sorted. I told the account manager where I worked that he couldn't win. I knew he couldn't win because I'd done all the preparatory work (at a third company) that let the other shop bid so low. Guess who won?
"Neither Microsoft nor RAC scale efficiently."
From my experience also not...
"The only saving grace is that the majority of these mainframe apps would port and scream on hardware than now fits in to a 'pizza' box or two."
A lot of the mainframe boxes are not exactly big. The entire workload of the German subsid of the company I worked for fit into 30% of a mainframe running zVM. Said mainframe was 4ft x 6 ft x 12 ft. And that was 10 years ago. Furthermore, the "majority of these apps" wouldn't "scream" as they're built for throughput and not intensive CPU usage. As such, IBM's mainframes are a couple of classes ahead of anything else.
"Fail because IBM's business practices are eroding the trust people had and their current business practices as a whole are killing the company from the inside. It just goes to show you the greed and mismanagement that will kill the company, all in the name of almighty profit."
A lot of us would agree with this. But then this has been the business model since the 1980s so this is also nothing new.
TPM,. there's also a couple of aspects of zIIPS zAAPs and IFLs that you missed.
1) They run at full engine speed. So unless you're one of IBMs very large customers, then the chances are your z10 et al will probably be configured with reduced speed engines. So switching work to Specialities not only saves money, but will probably increase capacity of your machine..
2) You only pay once for them .. so when you upgrade to the latest shiny z(whatever) with a different colour strip on the door they stay with you and get transferred to the new box at no cost.. but.. the new box will have faster engines.. so you get "free" upgrade
Well those rules apply for the moment... as you say things are likely to change.
ps SRB = Service Request Block
@AC Dodgy Hack?
Yes the the Speciality engines are normal CPs, but they don't have any restrictions on them in microcode to restrict workload. (ok so there is one instruction that is different.. but that's only used by the OS not application code). It's the OS that prevents/controls work running on them. But yes I agree they are (were??) a sales tactic.. If you were to write your own OS, then you could happily use them.
As for microcode hack.. I don't think so.. have you tried to load/change z microcode from a zOS system?? Its probably not a OS hack either - changing the zOS dispatcher is not the sort of thing you want to be hacking around as an ISV... but there is no need.. as the bloke from Neon said, the dispatcher just assigns the work .. the hard bit is creating the SRB environment.. (if that's what they do). And doing that is smart software.