Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Gregg Willhoit asks for an independently moderated consortium to set the record straight on zIIP offload percentage capabilities by middleware vendors.
The podcast lasts for 3:07
To listen to the podcast, click the following link: http://blogs.datadirect.com/media/GreggWilhoit_May26_Challenge.mp3
Currently in the market there are quickly becoming claims of the ability to offload various amounts of processing to the zIIP or other specialty engines. What’s your thought about there being some sort of competitive challenge or some sort of independent body to judge just that, the ability of vendors to do what they say they can do?
This day in age there’s a lot of noise out there with regards to zIIP offload performance and the like for mainframe middleware products. And this has caused me to think, how we can eliminate the signals, or improve the signal to noise ratio for the user community? And when I started thinking about this I started thinking about the TPC, the Transaction Processing Performance Council, and what they attempted to achieve through the formation of such a council with regards to creating repeatable, fair, monitored, moderated benchmarks for various databases.
The TPC consists of many different highly thought of vendors. One of the benefits of TPC benchmarks is that it’s a level playing field for which vendor’s products can be tested with regard to throughput efficiency, and then those numbers can then be published. I think the need is there for the mainframe middleware integration market. There’s many vendors touting percentage zIIP offload, there’s many vendors touting throughput capabilities with regards to web services to the various databases – both relational and non-relational databases on the mainframe – as well as SQL access to relational and non-relational data on the mainframe. I think we would go a long way towards clearing up just what vendors do what, in terms of transaction throughput for web services to CICS, and web services to IMS, and web services to Adabas, and what have you; as well as SQL to the same data sources. If we had a consortium – a group – that the mainframe middleware vendors could belong to, and we had a set of benchmarks – a set of load tests – with agreed upon backends, agreed upon interfaces if you will, and just a complete moderated and standards based approach to measuring.
I think it’s time to set the record straight. I think by bringing to light the relative performance characteristics and zIIP offload percentage as throughput to the public for mainframe middleware in highly monitored and standards based approach – much like the TPC group does - not only will the user group benefit, but I think the individual vendors will also benefit. They’ll be able to see where they need to improve their products and what not. But the main goal, of course, is to provide a clear idea or a clear picture of exactly how well each mainframe middleware product performs, and how much zIIP offload it delivers.
View all posts from Gregg Willhoit on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.