In this podcast Jeff Overton, the Shadow Product Marketing Manager from Progress DataDirect, explains how Shadow 7.2.1 impacts customers who rely on or integrate with legacy data on the mainframe. This podcast runs for 5:35.
You may listen to the podcast here: http://blogs.datadirect.com/media/Shadow_7.2.1_Release_LegacyData.mp3
Jeff Overton:
Well, I introduced the capability or this new capability in the previous question. I think it’s a good area where we can dive into a little bit more detail. But, fundamentally, IMS DB and VSAM are not easily accessible through a relational model. You have to provide some way of abstracting the data from a non-relational model, whether it be hierarchical like IMS DB or other data sources that use different types of data structures. Essentially, that’s what we do. We have native interfaces that access the underlying data, and then a relational model that we can set on top of that through a data-mapping facility that essentially exposes that data and those underlying IMS segments or those VSAM files as virtual tables to a developer. Complete with full metadata and ANSI SQL92 support. The goal here is that we want to make it as easy and as seamless to access data on the mainframe as it is to access data in Oracle or Microsoft SQL server. And with this release in 7.2., we can now do that with core support to IMS DB and VSAM.
Now, again, ANSI SQL92 has been around for quite sometime, but what’s unique about this implementation again is not only that interoperability that it provides and the ability to drive down development costs through the use of ubiquitous development skills and tools, but just as important is the ongoing operational costs associated with providing SQL access to something that is not SQL by nature. It can be expensive in terms of CPU processing. However, DataDirect Shadow is the only product on the market that couples with usability or interoperability benefits of ANSI SQL92 with the ability to offload up to 99 percent of that specific SQL access processing by Shadow to a zIIP specialty engine. And the benefit here is that you can have a dramatic shift in costs so that whether than having all of that SQL processing done by the integration product performed on the GPP, it’s moved off of the GPP to the zIIP, which means you’ve removed some of the capacity that you typically place on your GPP and you’ve moved it over to the zIIP specialty engine. That frees up work on your general purpose processor for other work that can’t be moved to the zIIP. Ultimately, that helps the organization control or better manage their MIPS growth which helps then manage the costs of their mainframe software, hardware, and support costs.
Moving it over to the zIIP specialty engine can provide a significant cost benefit. It can also result in a significant performance improvement relative to products that only can leverage the general purpose processor. Why? Because those zIIP specialty engines are not speed restricted, so they run at full speed all the time. Whereas, depending on how your environment is licensed, you may have a processor that you cannot run at that same speed. So there is both performance and certainly cost benefits for using a solution that can move that processing off of the GPP, onto the zIIP, and provide the interoperability benefits of SQL92.
Now, one thing I want to point out there is that with this capability, it actually can provide an organization an opportunity to rethink how they use this non-relational data. And what I mean by that is that the cost of integrating with this non-relational data has been an issue in some organizations. Why? Because as the issue we talked about with general purpose processor capacity and the price -- and the cost of running all this work on those -- if you can move up to 99 percent of that processing over to the zIIP specialty engine, it gives you or opens up new avenues for using that data. So, where before, in certain use cases organizations would perform an ETL, an Extract, Transform and Load of the data off the mainframe into a distributed database, whether it be a warehouse or something else, that then they could allow access to. Why? Because they were concerned about the cost of doing so. There are costs associated with developing that ETL process. There is cost associated with acquiring and maintaining the distributed warehouse. With our implementation now, you can rethink that approach and say, ‘you know what, if I can leave the data in place, I can reduce or eliminate the latency associated with replicating it off the mainframe, whether it be through a change data capture or through an ETL process. So, for data that has a low latency and a no latency requirement, accessing it on the mainframe can provide significant advantages. You can reduce the complexity because now you’ve reduced the requirement of the ETL to maintain a parallel environment and all of the associated infrastructure and personnel costs associated with it.
So it really allows you to give the organization more options for how they’re going to use mainframe data. So I think that, again, is a little bit more depth of what the ANSI SQL92 support with Shadow, combined with our zIIP specialty engine support can bring to an organization.