Gregg’s podcast runs for 5:22:

Click to play

//

Gregg Willhoit:

Customers are able to take advantage of the zIIP beyond DB2 worry-free using DataDirect Shadow because when we built our TCO, our zIIP offload in Shadow version 7.1, we did so with IBM’s help and guidance. We signed the required paperwork in order to be able to use the zIIP API, and we followed the agreement to the letter. I have, and always will maintain, that IBM can at anytime look at our code. We’ve offered that from the very beginning, and they know this, and we believe in full disclosure, and we know that we are a 100% supported and approved user of the zIIP. We’ve got a lot of support from IBM, from Bob Rogers and Mark Anzani in this area, and hopefully we will continue to get that. They’ve been extremely, extremely helpful to us.

What we did in Progress DataDirect Shadow – and you can read about these exploits in various articles and presentations I’ve done – is we took a very holistic approach in Shadow. We decided to offload all of Shadow, or to make all of Shadow zIIP eligible. Workloads can be offloaded if there’s a zIIP available and the appropriate configuration statements are there to allow that. So we eliminated, we eschewed all SVCs, we wrote our own timer dies, we used all sorts of different services, changed our services to be able to execute in the enclave SRB mode, wrote our own when there was no z/OS equivalent of the service to be able to execute in the enclave SRB mode, so we completely changed the DNA of our product to do this. But the benefit was, because of all the workloads that run in our architecture, they all benefit. I like to call it “the rising tide floats all boats” kind of architecture. So when we did this, web services, our web services products benefited, our SQL engines, SQL to non-relational products benefited, our advance products benefited, and so on and so forth. It was a very good decision to do it this way, it’s worked out quite well for us.

One of the things that is maybe more unique about our workload than many, possibly other ISVs is that we are a transaction manager. We do things similar to what IMS or CICS does. But we don’t replace IMS, we don’t replace CICS. We work in conjunction with them, but we are in the middle of the business unit of the transaction that’s running in a high volume and high CPU consumption type of scenario. Because doing web services or non SQL to non-relational is extremely computationally intensive. And what we’re able to do with our offload to the zIIP is to expose mainframe assets, both old and new, to standards-based API’s, or languages, in a very, very, very effective and compelling way in terms of performance and total cost of ownership. We’re offloading all of the web services work to the zIIP, basically 99.9% of all of that is offloaded to the zIIP. Same with the events, and then same with our SQL to non-relational, it’s a very compelling story. There’s no need to move your web services off the mainframe to use appliances, to use any off the mainframe implementations for web services support. You can execute the web service on the mainframe in a coherent memory, against the backend, against IMS or CICS, and all that web services work is offloaded, is made zIIP eligible. So it’s a very, very, very significant story. Same thing with our SQL support to non-relational, that also can be quite computationally intensive. In the past, folks had moved the data, they’ve replicated it to non-mainframe platforms, and we don’t believe that’s a very cost effective approach, especially, in this day and age characterized by the need for more agile computing and where timeliness and currency meaning so much more – especially with what’s going on with regulation and compliance and those kinds of things today.

We believe that you should leave the data on the mainframe. If you want to, use standards-based API’s to access that data, for data mining, for business analytics – leave the data there on the mainframe, and simply do all the heavy lifting, the SQL transformations from relational to non-relational and so on, on the zIIP. It’s extremely compelling, you don’t have these other platforms to manage, you’re on the System z, you’re in a coherent memory, you don’t have to go TCP/IP back and forth, and the data is current. I mean it’s just a really, really, compelling story for us.

Gregg Willhoit:

Click to play

play_blip_movie_3120871();
I was very fortunate to be able to present at CMG twice, and the second presentation, of course, as you mentioned, Mike, was titled, ‘Keeping it Legal.’ The presentation is available to anybody who wants to take a look at it. Basically what the intent was, was to discuss the current issues with regard to zIIP offload, what was approved, what’s not approved, and to make it a very interactive discussion. Everybody in the room contributed, we learned some interesting facts from some of the attendees, things were going from a contractual or licensing perspective, as far as the zIIP goes.

In general, I came away with a couple of thoughts from that, that folks were very pro-IBM in terms of their support of IBM and what we would call approved or intended zIIP offload situation. Folks understood what IBM was trying to do, in terms of when they built and offered the specialty engines. They were intended for new workloads, and there are just very sound financial and business reasons why they were intended for new workloads. It’s nutty to think that anybody could be in business and all of a sudden sell everything that they’re doing for free, I mean, it’s just bizarre to even think that that’s a possibility.

You know, IBM spends billions and billions of dollars building world class, world class operating systems and subsystems. They support the user community as well. They support the IFC group beyond anything I’ve ever seen. And all that costs money, to deliver a world-class operating system like System z that most of the critical data in the world exists in or on — it costs a lot of money to do this. So, the thought that IBM could all of a sudden say, ‘Hey, everything’s for free,’ I mean, come on. That’s like only a concept that Bernie Madoff could love. And what I mean by that is, ‘Hey, you know, I didn’t build the application, I didn’t build the operating system, I didn’t hire the people, the buildings, I have none of the infrastructure, but somehow, what I think I’ll do, is I’ll just find a way to use all that and offer it to somebody for free, and I’ll take all the money.’ I think that most System z customers understand that IBM and ISVs needed a way to offer TCO, but in a controlled fashion. And the best way to do that was with new workloads. And what I mean by controlled is, we’re all in business, right? We’re all in business, and we’re not going to be in business if all of a sudden, the software that we’re offering isn’t chargeable. It’s a ridiculous paradigm and in the end, the customer takes the hit. There’s no free lunch. You know, there just isn’t.

So, we spoke a lot about that, and I’m not speaking about any specific product out there, I’m only speaking about the concept of what the specialty engines were intended for, why they were intended for that, and how they were controlled in terms of their use, and how doing something where those controls are completely eliminated, in the end is not beneficial to anyone other than possibly one particular entity who may be doing this kind of work, that is offloading other company’s code.

I feel very strongly that what IBM did with regard to TCO and the zIIP was very beneficial, and the zAAP, and the IFL is extremely beneficial to customers, and also it allows ISVs to offer a product with a strong TCO advantage. It allows us, in particular, Progress DataDirect, to compete with other integration products that aren’t as computationally intensive. We just are, it’s not because we don’t know how to write code, believe me we do, it’s just that we are in the middle of millions and billions of transactions a day, and you’re going to consume CPU’s, especially if your workload is computationally intensive, and there’s no way to get around the fact that going web services or SQL to non-relational transforms, it’s computationally intensive. And so, what the zIIP allowed us to do was to offer the customer an alternative, to be able to run those computationally intensive workloads on the zIIP, in a coherent memory, on the best operating system in the world, with the greatest controls and management tools there, co-located, it clearly brings a significant benefit to the customer.

Now, what are we going to do if all that stuff, all that software, is all of a sudden brought into question, because there’s another solution out there which says we’ll offload everything. Not just our own code, but we’ll offload everything. So, we discussed that in the presentation, you know, we got some customer input as to what they thought. The appropriate thing to do was, with regard to zIIP offloading. The majority supported IBM’s position, which was quite pleasing for me to see.

As you can tell, it’s kind of a subject that I feel quite strongly about. I feel that the zIIP clearly gave us the opportunity to give something of significant benefit to the customer base. Yet now, in this past year, there’s been a significant amount of confusion, the signal to noise ratio in the market is not good, there’s a lot of noise, the signal’s being lost. And by the signal I mean, appropriate approved zIIP offload. Things are slowing down because people are just unsure what to do, so people are not getting the benefit that they should be getting from the zIIP.

And we discussed that, and basically, in the end, I think a couple messages came out of that discussion. One of them was customers wish that, perhaps, maybe IBM could be a bit more, straightforward on which company’s zIIP offload is approved or not approved using some sort of certification letter. I heard that from several customers, they really would like to know that. And then the other one was they would like to know and have published somewhere the generosity factor of each customer’s products. For example, our generosity factor is 100%. Basically, in our product, what is zIIP qualified, is zIIP eligible, and the generosity factor basically can be thought of as zIIP qualified divided by zIIP eligible times 100. And which basically means that of the work that you execute in enclave SRB mode, zIIP qualified, how much of that do you make eligible for offload? And customers want transparency in that, and I think that’s a great idea, and I’ve been thinking about working to get something on our website which allows other companies to put up their various generosity factor numbers, however, as you might imagine, that’s somewhat difficult to do, because some companies might consider it to be sensitive. Although, it’s quite simple for any customer to determine the generosity factor of each product once they’ve installed it, so why not make it accessible prior to them installing it?

Anyway, that’s it for the CMG presentation. To conclude, I felt that the customer base was very behind IBM, very behind approved zIIP offload, and very much for transparency and openness with regard to who is offloading to the zIIP in a certified manner as well as what their generosity factor is.

I have two sessions. In both my exhibitor presentation and vendor training session I’ll examine the differences between proven methods for zIIP utilization and those that fail to meet IBM’s customer agreement for authorized use. Attendees are certain to walk away with clarity and actionable advice to use immediately with their measurement, quantitative analysis and forecasting activities.

My sessions will examine the use of mainframe middleware products, including the DataDirect Shadow platform, that allow processing associated with SOA integration, events and data queries to be diverted from the mainframe General Purpose Processor (GPP) to the low-cost specialty processors. My focus will be on how cutting-edge mainframe middleware products move computationally intensive workloads to the zIIP and zAAP specialty engine, allowing organizations to effectively manage MIPS capacity usage, defer upgrades and dramatically lower mainframe TCO.

I hope to see you at the CMG! If you can’t make it and want more information on how the DataDirect Shadow platform unlocks the zIIP engine to run additional workloads beyond DB2, we’d love to hear from you.

The podcast lasts for 3:27 and you may listen to the podcast here: http://blogs.datadirect.com/media/TrevorEddolls_Shadow7.2.1.mp3

Trevor Eddolls:

Well, I mean, my first thoughts were that it’s a good thing for IMS users, so one of the things they put in the product announcement was that the latest release allows workloads for IMS databases and CICS files to be diverted from the GPP to the zIIP specialty engine, vector specialty engines again, which makes it good for IMS users. I mean, the other thing is that this latest version of Shadow really sort of stresses the importance of SOA, and why, you know, the fact that mainframe users need to expose their applications, it gives a very nice way, a very easy way for mainframers to do that, and to modernize their applications. And when you think about it, it’s quite important to modernize, because what you can do — you can actually create mash-ups. These are things where you take maybe data from your mainframe, which you made available, and you mix it with data maybe from the internet, and you produce like a completely new web page, a completely new design, a completely new application, which is a mixture of different things, and by using SOA you can do that. Your end user is seeing something that’s really up to date, really modern, and very attractive for them.

Going back to the product, though, the very fact that you’re moving stuff to the specialty engine means that you’re saving on MIPS use, which means that you’re going to be saving on the cost of running the processor, and anything that makes mainframes more affordable has got to be a good thing. One of the features I particularly like is the Shadow Studio. As I mentioned earlier, it’s sort of very hard to use a mainframe cold, the way we used to use it back in the ‘70s and ‘80s. The fact that you’ve got these kind of visual studios make it quite easy to select components, to link components using the software development kit. It’s great, and the Shadow Studio actually does that. And when you produce your application, of course, that’s good, but what you need to do is to make sure it’s scalable. Scalability is really important. The fact that one thing runs might be OK, but the fact that you want to run it lots of times and maybe lots of things going on concurrently makes scalability very important, and one of the good things of other Shadow products is the fact it does that.

So just in summary, just to sort of look at the whole thing, what you’ve got is actually a very comprehensive piece of software, something that can do a whole lot of stuff for the end user in a way that can start to save you money. So it gets my recommendation.

You may listen to the podcast here: http://blogs.datadirect.com/media/GreggWillhoit_Shadow7.2.1.mp3

Gregg Willhoit:

Shadow 7.2.1 is an exciting release for us with Progress DataDirect and Shadow, the mainframe product. We’re really excited about 7.2.1 as it gives us a completely new product with regard to mainframe data access, and that is ANSI 92 SQL support for non-mainframe data. I’ll be talking a lot about that at System z. We’re really, really proud of this particular feature. What we did in 7.2.1 for the SQL access is we basically eliminated the need for data replication in many cases. And what I mean by that is by offloading all of the SQL analysis, the data transformation joins, any of the more esoteric SQL functions to the zIIP, as well as all of the network I/O, we’ve basically eliminated the need for data replication in many cases. Shadow in this case has kind of taken what it did in 7.1, the Shadow release 7.1, and applied that entire zIIP offload and enclave SRB strategy to SQL access, and it’s really paying dividends. It actually turns out that complex SQL is even more computationally expensive than XML parsing in most cases, particularly when you’re getting into large amounts of data that is involved in joins. We’re seeing incredible amounts of offload, 99% type offload, so we’re really, really happy.

If you’re interested in SQL access, or even just a zIIP offload story, we have an article coming up in October in zJournal, basically talking about “From SQL to SOAP: The zIIP As a Fungible Virtual Mainframe Appliance,” which basically talks a little more detail about what we’ve done, why we did it, but we truly believe in the mainframe, in System z as the penultimate platform there is for computing, especially business computing, and with the specialty engines, not only the zIIP but of course the IFL and the zAAP, that it presents a very compelling story from a TCO perspective. And heretofore, quite honestly SQL accessed the non-relational mainframe data — so I’m talking, I’m not talking about DB2 – I’m talking about SQL access to VSAM or SQL to IMS, there are some tools that do this. However, they’re quite expensive to use in most cases.

So what most customers have done is they’ve replicated. They’ve gone through the pain of replicating, offloading that data to a non-z/OS from non-z/OS hardware, running applications under different operating systems with different management and maintenance requirements, and we’ve eliminated the need for that because it’s just as cheap — actually, I think it’s less expensive to leave that data on the mainframe, and again, use the zIIP as a fungible virtual appliance and provide for ANSI standard SQL access to that critical mainframe data. So we’re excited about 7.2 from the perspective that we truly believe that this brings about a paradigm shift in terms of SQL access on the mainframe and how people will look at it in the future. I think we’re helping at least make a strong case for keeping the data on the mainframe. That’s where it belongs.

In 7.2.1, beyond the outstanding new SQL access that we’ve provided, we’ve done a lot of things to enhance our web services component, particularly in the performance area, and we’re really pleased with what we’re seeing there. We’re seeing much, much greater transaction throughput, as well as less CPU usage. We’ve optimized both the parsing, marshaling/unmarshaling of the inbound and outbound XML and done some interesting things there, and the results — and the initial customer results are really, really quite impressive. We’re really happy with our improved XML and our zServices support for 7.2.1. And with zEvents, we’ve done some really neat stuff there, particularly with regard to the CICS 4.1 and supporting not only 4.1 but 4.1 and the new events facility within CICS, so that’s really exciting.

You may listen to the podcast here: http://blogs.datadirect.com/media/Shadow_7.2.1_Release_BI.mp3

Jeff Overton:

Business intelligence or BI is an area that we’re seeing a lot of traction in the marketplace. Again, organizations are looking for one single source for the truth. They’re looking at how they can achieve the dashboards that they’re looking for to help them identify what’s going on in their business, both from an internal and an external perspective. But Shadow can help with business intelligence initiatives in a number of different ways. One way is if the organization is looking at low-latency data where they need the ability to provide real-time operational data, very quickly and that mainframe data resides in the mainframe, the ability to access it in one place provides significant advantages. And as we talked about before, the ability to do so through ANSI SQL92 expands the pool of available business intelligence solutions that can be used.

So, in one scenario business intelligence can benefit from 7.2 with our enhanced support for ANSI SQL92 access to mainframe data. Now, there are also real reasons why business intelligence initiatives may be using distributed data warehouses or operational warehouses, and, in that case, Shadow’s capabilities for Change Data Capture (CDC), what we call our Shadow z/Events products, can be a significant benefit. Why? Because with Shadow z/Events, it’s a noninvasive way to specify the data change events that we want to capture. And that can span whether it be Adabas or VSAM or DB2 or IDMS or even IMS DB. And so you can capture the events that occur in these critical data environments on the mainframe, and not only can you capture them but with persistence, to make sure all the changes are captured regardless of what’s going on, you then have the ability to inspect those change data capture events, look at them for context, enrich them if necessary, and then transform them into an XML representation, and then publish those out so that you can then load this into your operational data warehouse, or pass it onto some other downstream process that utilizes this data.

So, there are a number of key ways in which we can support business intelligence. Again, direct SQL access to relational and non-relational data on the mainframe, particularly attractive when you’re dealing with business intelligence initiatives that have low-latency and perhaps higher-volume requirements. And then the ability to capture mainframe change data events and propagate those out to a distributed environment.

You may listen to the podcast here: http://blogs.datadirect.com/media/Shadow_7.2.1_Release_ISVs.mp3

Jeff Overton:
So, ISVs, or independent software vendors, produce a significant number of the tools and applications that are in use in organizations today. Some of those have been developed — or most of those have been developed using standard-based access so that they can expand the reach of their products, which in DataDirect Shadow Release 7.2, independent software vendors can now expand the use of their products to include either additional mainframe data sources, such as IMS DB and CICS-VSAM or open up their product to now use the mainframe. And to an independent software vendor what this means is it increases their opportunity for customers to use their product. So, expanded use of their products in an organization for potentially new customers that they can now help with their products. So, independent software vendors should look at this as a new opportunity and unique way to help expand their market by improving a customer’s ability to access the data in their mainframe in a very cost-effective manner.

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.

You may listen to the podcast here: http://blogs.datadirect.com/media/Shadow_7.2.1_Release_NewFeatures.mp3

Jeff Overton:

Actually, there’s many new capabilities and enhancements in this release. I guess the best way of kind of starting this discussion is really the way in which we took or the approach in which we took for the development of these capabilities and enhancements was really focused again on our core goal which is to simplify the integration process to the mainframe by expanding the use cases where the mainframe can participate. And, fundamentally, the lowering the cost of mainframe integration. So, reducing complexity and the lowering the total cost of ownership is really the way in which we looked at all of the enhancements and capabilities that we’ve introduced in Shadow 7.2. With that being said, you can kind of look at these or you can group these enhancement capabilities really into five functional categories. So let’s just kind of look at them real quickly one at a time.

First off is we’ve made significant new set of capabilities for integration to mainframe data by providing ANSI SQL92 access to both IMS databases and VSAM data under the control of CICS. And while ANSI SQL92 has been around for quite some time, what’s very unique about our offering is the ability to couple the interoperability benefits of ANSI SQL92 with the unique architecture that we have that can help reduce the operational costs associated with ANSI SQL92 access to non-relational data. So what I mean there is that when you are providing ANSI SQL92 access, you’re really helping expand the pool of developers who can participate in mainframe integration. You’re expanding the pool for the toolkits available to use for access to the mainframe. So that helps reduce the costs on the development side. But when it comes to the runtime side, providing relational access to something that is not relational is, or can be, processor intensive. However, with the Shadow implementation, we’re able to move up to 99 percent of that Shadow-specific processing that’s required to provide the ANSI SQL capabilities to this non-relational data. Move it off the general purpose processor (GPP) onto the zIIP specialty engine where it can run at a much higher speed, can run, also, at a very high capacity, as well as not be counted against the capacity of the mainframe. So there is significant new ground that can be used or broken here by using ANSI SQL92 access to CICS VSAM as well as IMS DB.

We talked about one of the five categories of the new enhancement to 7.2. The second one is the support for mainframe SOA. We’ve had rich support for exposing mainframe programs as service providers for quite some time, as well as allowing those mainframe programs to participate as requester programs. So we’ve expanded the support for these requester programs by enabling not only COBOL programs to make Web services calls, but now PL/1 or even Natural programs. And in addition, we’ve enhanced our API because we know that these types of programs can run in high-transaction environments, such as IMS/TM, and in these environments the latency that can be introduced for the time between when a Web service call is made by a program and when the request is received is really arbitrary. It really depends on a number of factors outside of the control of the program and even the mainframe. It could be making a call to a Web service that’s heavily loaded — perhaps in a partner environment — or not even available. And so that latency time is unpredictable. In certain environments such as IMS, that can adversely affect the other programs that are running within that region. And in this release what we’ve done is we’ve enabled these programs to make the Web services call in an asynchronous fashion. And what that means is they can make the call, and then they can go off and do other work and come back and check to see if the web service call has been processed and received. And they can pick up those results and continue processing with those Web service results. And again, the benefit here is that it helps improve the performance overall in that environment by not having this program blocked and wait for the Web service request.

So the third area then is really the ability to support the newer capabilities introduced in IBM DB2 for z/OS version 9.1. And in that version of DB2, IBM has introduced some additional data types, VAR-binary, indigenous data types as well as the core for SQL based data procedures. I’m happy to say in Shadow 7.2. we support those new data types and support for SQL server procedures.

The fourth area of enhancement is around our Event Driven Architecture (EDA) when IMS DB is involved. And, our event-service capabilities, something we call Shadow z/Events, allows mainframe data systems to have their changes captured in a noninvasive way. Those changes can then be evaluated for context, enriched, and then published out so that they can be used in applications such as change data capture used to support an off mainframe operational data warehouse, or even to drive other SOA events. And so in this case what we’ve done is we’ve gone ahead and put in support for really 24×7 assured capture of IMS events, so this is a way that customers can now expand the use of event capture capabilities for IMS to make sure when they’re in a high availability environment where those events need to be captured 24×7, we can provide that assured capture capability.

And, finally, really, the fifth area is about the installation and the maintenance of the Shadow software. We realized that systems programmers are under more pressure than ever, and the ability to manage their software portfolio in a consistent manner is an important capability to them. It helps simplify their tasks. It helps improve the quality of their software products or the software experience that the developers and the overall organization receives from their software investment. So, in Shadow 7.2., we’ve enhanced our installation and maintenance capabilities to now leverage the SMP/E or system Modification Program Extended, which is an IBM software program for installing maintaining software on the new z/OS operating system.

So that’s, again, the five key areas of enhancements. The support for additional data sources and enhanced ANSI SQL access, support for mainframe setup through Web service requester program, so COBOL, PL/1, Natural programs, are now supported as well as asynchronous Web services calls, support for new features introduced in DB2 9.1, support for 24×7 capture of IMS Events, and finally installation and maintenance improvement with SMP/E. So that’s a quick overview of the major components of 7.2.

You may listen to the podcast here: http://blogs.datadirect.com/media/Shadow_7.2.1_Release_ProductOverview.mp3

Jeff Overton:

DataDirect’s Shadow, at its fundamental core, is middleware for the mainframe. It’s middleware that provides bi-directional integration with mainframes. And when we talk about mainframes, we’re specifically referring to IBM System z hardware running the IBM z/OS operating system. So, in those environments, DataDirect Shadow enables developers, whether they’re using Java or .NET to use a single, unified and consistent approach for integration with the mainframe. And that integration with the mainframe can really span or does span the three primary integration points, which are business logic or SOA programs. So it will be Cobol or PL/1 or Natural or some other language. But it can also integrate with application logic, and, as you’re aware of, applications in the mainframe have a rather lengthy lifetime, so those may be applications where the business logic, the data access logic, and the screen logic were fully intertwined. So it’s a monolithic structure, and the only true way of integrating to that data is through the screens. So we provide support for that as well. And then, finally, data, and whether that data is relational or non-relational, we support both.

Shadow Architecture:

Now, integration with these assets is done using standards. All standards based, whether it be developing web services, whether it be doing web services orchestration, whether it be using SQL to access not just data but also business logic. So the ability for SQL programmers to treat business logic as a stored procedure. Also support for real-time events, which can serve as a very nice complement for services-oriented architecture (SOA), or it can even be used to support change-data capture capability. And finally web presentation. So in those environments where perhaps you have existing DB2 applications that need a quick refresh so that they can be simpler for newer workers to use, rather than having to use PF Keys and old green screen. Those applications can be now presented through the Web.

So, overall, this approach allows an organization to use this single unified approach to mainframe integration, whether they’re doing one of those types of integration, let’s say web services, or more than one, such as web services, data access using SQL, and an event. And the value here is that by doing it in such a manner, we reduce the complexity of the integration process to the mainframe. And, because we’re using standards based interfaces, we’re enabling those organizations to leverage the ubiquitous development skills that are out there in their Java and .NET teams, as well as the tools with they use. So being able to leverage those skills and the tools helps reduce the time to develop and deploy these applications that integrate with the mainframe. And ultimately, what that means is it helps reduce the development costs. Now, once it’s in production, the benefits don’t stop.

DataDirect Shadow has been written from the ground up for integration with the mainframe. And it implements a unique architecture that exploits IBM System z features, such as specialty engines. And these specialty engines, enable you to bind work, work that meets specific criteria, to be moved from a general purpose processor to the specialty engine, such as a systems integration information processor or zIIP specialty engine. The benefit to an organization there is that zIIP specialty engines have a significant capacity capability. They run at an unrestricted speed and, furthermore, the work that’s run on them is not counted toward the capacity of the mainframe, which is typically used to license both software, hardware, and support. So the benefit here is that once in production, you get the ongoing savings of running with integration processing done by Shadow as much as — up to 99 percent of it in fact — on the zIIP specialty engine, which can result in a much lower total cost of ownership, not only for the process leveraging the mainframe, but really for the entire mainframe.

So that’s just a quick description of the DataDirect Shadow Product.