In this Q&A Rick discusses ways in which companies can protect their mission critical data even as they connect their networks with outside partners.

WebSphere Journal: Rick, what do you do over at IBM?
Rick Thomas: I'm the program director for the CICS Tools Marketing within the Application Integration Middleware division.

WJ: I understand that you have a pretty interesting new tool where you can get CICS and WebSphere to interoperate, which has been really hard for a lot of people. Tell me about it?
RT: This new tool is CICS Business Event Publisher. It's actually now in its second release with some interesting new capabilities. The Business Event Publisher is a tool that allows CICS to drive business processing in a mixed workload environment that includes CICS, IMS, WebSphere, WebSphere J2EE, WebSphere MQ and WBI Message Broker.

WJ: A lot of our readers are Java programmers, obviously, but not all of them are experienced with CICS. Who uses CICS today? How big a product is it? It's having its 35th anniversary.
RT: Yes, it is. We just celebrated our 35th anniversary of CICS. CICS is used by 10,000 customers worldwide and it is still the primary engine for business transactions everyday around the world. It's used in all the finance industries, insurance, retail, distribution for all purposes in all walks of life.

WJ: So that's something that's been sitting back there for a long time but a lot of people haven't migrated off it yet?
RT: That's right, and all indications are that they are not going to migrate. In fact, what they are going to do is revalidate the value of their CICS assets in mixed Web environments that include WebSphere with J2EE applications on one side and CICS applications on another.

WJ: What is the most important problem that this tool solves?
RT: The Business Event Publisher allows CICS to be in the driver's seat in business processes. Today, it is very common for customers to write WebSphere applications that drive CICS transactions.

 
Rick Thomas - Program Director for the CICS Tools Marketing

They make a customer information request, operate on it in some way, and then submit an update of that customer information. That's an environment where CICS is acting as a partner with WebSphere, but the transaction is driven by WebSphere. The Business Event Publisher allows CICS essentially to be aware of actions that occur within CICS and know where to drive outbound business processes based on that. With the Business Event Publisher, CICS now gets to query WebSphere or a WebSphere database or another information database for customer information, get that information, operate on it, and send a response or an update outbound. Business Event Publisher actually allows CICS to have a more direct outbound business process-driving capability.

WJ: Very cool. I understand that you have a new tool to make it easier to migrate from VSAM, the database for CICS, over to DB2. Tell me about that?
RT: It's called the CICS VSAM Transparency Product. This is a product that we brought to market with our eye on supporting a critical mixed workload environment between WebSphere and CICS. Specifically, VSAM Transparency allows customers to migrate their mission-critical data from VSAM into a DB2 database.

WJ: That should be very helpful for a lot of people.
RT: It's pretty helpful for all those WebSphere J2EE application developers who are trying to access that same pool of legacy data.

WJ: That makes sense. There is a lot of that out there.
RT: What you're trying to do, if you are the customer, is enable the WebSphere application developer to access that data without causing the CICS programmer to rewrite all of his or her existing CICS applications. If you were to simply move all of your VSAM data into DB2, the customer would have to rewrite some or all of their CICS applications. The VSAM Transparency product allows CICS to run as if thinking that its data is still in VSAM and allows the WebSphere applications to run against the new DB2 database. Then everybody's happy and it allows customers to deploy interesting new WebSphere applications at a fraction of what would otherwise be a very expensive migration.

WJ: Finally, I'm not an expert on CICS, as everyone knows, but I understand that you have solved a significant problem with VSAM copying. Can you explain that?
RT: Yes. There are obviously CICS systems programmers who have been copying the VSAM data for as long as there has been CICS - 35 years. The problem is that most of the products in the marketplace today have required them to take CICS offline prior to doing these kinds of copies. We have come out with a tool called CICS VSAM Copy that operates uniquely with a copy while open for update function. The copy while open for update function means that CICS does not have to be taken offline to do the copy. Taking CICS offline affects WebSphere when you're using WebSphere as a front end to CICS. So in any environment where you have a WebSphere and CICS mixed workload application, customers will find this copy function to be extremely valuable. It means CICS will no longer have to be taken offline, which means the WebSphere application will no longer have to be taken offline.

WJ: Is there anything that you want to wrap up with?
RT: I'd just like to remind you and all your readers that this is still a growing environment. There are more CICS transactions every year than there were in previous years and it's been this way for 35 years. Likewise, we're now celebrating the 10th anniversary of MQ. So customers are continuing to see significant investment in both CICS and MQ environments.

On top of that, customers are now seeing the obvious value of their WebSphere Application Server as a platform for new J2EE applications. With CICS, WebSphere MQ, and WebSphere Application Server, you have a very powerful ecosystem in which to run business-critical applications. I think that the new CICS tools we are announcing now go a long way to further enable customers to take advantage of this significant CICS investment, and their investment in the new WebSphere Application Server.