IBM has announced the CICS Transaction Server for z/OS 3.1, and CICS Transaction Gateway 6.0. The CICS Tx Server 3.1 provides Web services capabilities, and the CICS Tx Gateway 6.0 provides J2EE connectivity. This shows IBM trying to extend the life of its mainframe systems.Summary
Announced last week, the CICS Transaction Server for z/OS 3.1 provides Web services capabilities, while the CICS Transaction Gateway 6.0 provides J2EE (Java 2 Platform, Enterprise Edition) connectivity. The software enables customers to more easily integrate business processes and extend existing mainframe-based applications with better Web services and integration capabilities.IBM Extends CICS for Web Services, J2EE
The 3.1 version of CICS Transaction Server is combined with the latest versions of IBM's WebSphere middleware, DB2 database and IMS (Information Management System), IBM's transactional database management system. Additionally, CICS 3.1 includes enhanced application transformation and better performance and system management.
Just wanted to get feedback on how many people here use/integrate with Mainframes. And, whats your prefered way to talk-to/integrate-with Mainframes?
I work with an application that integrates with a mainframe. This application (J2EE based) is an upgrade to an application that used to reside solely on the mainframe. We had to support all connectivity, so we needed CICS interfaces.
For the CICS work, we use sockets on the mainframe to connect to our J2EE back end. It's been somewhat problematic, so I look forward to better support for XML/HTTP from IBM soon.
There is some interesting literature out from IBM-- looks like Enterprise COBOL will soon be supporting XML fairly well. They've got SOAP-for-CICS, too, and *Biggest surprise* they say they're allowing you to write EJBs in COBOL. (I know that sounds silly, but that's what they're saying.)
Hope we hear from some others-- I'd like to know what people are doing.
Hi, I've been using the older versions of IBM's JavaGateway and then CICS Txn Gateway for integration between CICS and Java. This has performed acceptably and been pretty easy once we wrote a tool to build java classes which would format the comm areas. Have also used TCP/IP sockets for calls from the mainframe to the J2EE server with no problems, and the various Tibco products (Substation, CICS adapter) work fine for asynchronous needs. The only thing that has not worked well at all has been running Java inside CICS and trying to connect it to an external app server, the name lookups and IIOP implementation issues made that quite frustrating. So I guess the preferred way is IBMs CTG for synchronous calls into CICS, and Tibco Substation for outbound calls and asynchronous inbound calls. Of course, z/OS is not even on the horizon for me, so I can't use the latest CICS versions except for tinkering.
We've tested TCP/IP, UPD/IP (both unicast and multicast) on both Z/OS and Linux on the Z series (IBM mainframe class) and they all work surprisingly well.
(Yes, you can now cluster together a Zaurus and an IBM Z. ;-)
Cameron PurdyTangosol, Inc.Coherence
: Shared Memories for J2EE Clusters
I've been working on a project that gave a "web frontend" to a system residing on the mainframe. All business logic were kept on the mainframe. For 'C_UD' we call CICS via CICS Transaction Gateway. For 'R' we call stored procedure in db2.
For the CICS interface we used VAJ3.5 to generate some 'Record' classes that maps to COBOL structures.
For 'R', stored procedures where chosen partly for security reasons, and partly for the ability to call them from other COBOL programs on the mainframe.
So the J2EE stuff were quite simple.
Like someone, we wrote a generator that, thanks to an XML mapping, does the magic of Java<-->COMMAREA.
Then we use CICS Transaction Gateway 5.0 to call a CICS Transaction (reachable only with SNA/VTAM).
All seems quite simply, but we have a problem, transaction propagation between CICS and other resources (think at an Oracle DB). We have to manage it all by ourself (applicative rollback!!!) because seems that CTG 5.0 doesn't implements any kind of XA adapter.
Do you about any other solution ?
From IBM announcment:
CICS Transaction Gateway Version 6.0 is a Java™ 2 Platform, Enterprise Edition (J2EE) connector to CICS applications. It supports the standard J2EE Connector Architecture 1.5 specification (JCA 1.5).
Being JCA 1.5 compliant I guess it should partecipate in a XA transaction with other Resource Adapters.
I think you already have some support for your kind of scenario.
How can I make an ECI request to CICS part of a global transaction?
There are three ways of achieving this outcome depending on the application server environment and if there are any other XAResource capable resource managers participating in the global transaction:
a. When the CICS ECI resource adapter is used within WebSphere Application Server for z/OS, the RRS global transaction support provided by the CICS ECI resource adapter allows any number of ECI connections to be used in a global transaction scope.
b. If there is no XAResource capable resource manager (such as a JDBC data source) enlisted within the transaction, then an interaction with CICS can be part of the global transaction and will be committed when the EJB container commits the global transaction. This is possible because global transactions provide a one-phase optimization of the two-phase commit protocol, in which a one-phase commit flow is used by the transaction manager if there is only a single resource manager branch (that is, only a single resource) involved in the transaction. This is sometimes referred to as "only agent optimization". While this is primarily a performance optimization, it means that it is also possible to support a single one-phase commit resource manager (such as a CICS ECI Connection) in a global transaction that does not need to be prepared.
c. If an XAResource capable resource manager is enlisted within the global transaction along with a CICS ECI Connection, then usually at commit time an exception occurs within the EJB container with a message saying
An illegal attempt to enlist a one phase capable resource with existing two-phase capable resources has occurred.
This is because the EJB container cannot commit a one-phase commit resource together with two-phase commit resources in a global transaction. However, there is a solution to this in the form of the Last Participant Support (LPS) provided in WebSphere Application Server Enterprise Version 5. This allows a single one-phase commit capable resource (such as a CICS ECI Connection) to participate in a global transaction with any number of two-phase commit capable resource managers.
The LPS function is enabled for a given EJB component via an extended deployment descriptor (XDD). The application assembly tool provides a tab for WebSphere Application Server Enterprise on which there is an Accept heuristic hazard checkbox. Applications deployed with this box checked may use LPS. WebSphere Studio Application Developer Integration Edition provides an Extended Services tab on the J2EE Application Deployment Descriptor editor, on which there is a Last participant support checkbox (see Figure 9).
What I read here is something I was wondering.
The fact is that the article is about WebSphere for z/OS, and this reinforce my thesis about the problem in the communication channel.
When I make an ECI call with CTG, the CICS commit the transaction at the EXIT of the program it launches, if for example something bad happen on the SNA/VTAM or in Oracle side, nothing can rollback the transaction.
Instead, if the transaction is all on the mainframe, the EJB can run in the LUW of the CICS and make a simil global transaction.
Do you agree with this ?
Now I read the article, and is like I thougth !!!!
XA is not a real thing !!!!
"Out of these possible options, the only protocol that supports two-phase commit transactional coordination for ECI flows is the External CICS Interface (EXCI). This is an interface provided by CICS TS for z/OS, and provides transactional support in conjunction with MVS™ Resource Recovery Services (RRS), when the CICS Transaction Gateway and the target CICS region are in the same MVS image. This support, together with the CICS Transaction Gateway local mode (a form of local bindings), provides two-phase commit global transaction support when running in local mode within WebSphere Application Server for z/OS. In all other circumstances, a one-phase commit connection has to be used, and so the CICS Transaction Gateway has to be considered a local transaction capable resource manager."
I've read the article too and you are right...
CICS ECI RA (not zOS) doesn't implement XAResource Interface.
I don't know if something is changed in CTG V6.0.
Only a comment on hyour previous statement:
When I make an ECI call with CTG, the CICS commit the transaction at the EXIT of the program it launches...
I've no experience on CTG but I've checked with a friend of mine and using CTG with TCP/IP on AIX/NT the transaction is commited on the WAS side, not on the host.
Host guy told me that he cannot commit on the Host side but is responsability of the client.
my last append with some news.
Maybe they are useful for you.
1. My friends are using Extended Unit of Work (DPL) and, as describe in the article, the control is WAS side.
2. Last Partecipant Support-LPS in WAS 5 EE mentioned in the article (capability to coordinate two-phase and one-phase commit resources) will be available in WAS 6 Base in few weeks.
As for Figure 3 of the article this should be your scenario.
Luca,my last append with some news. Maybe they are useful for you.1. My friends are using Extended Unit of Work (DPL) and, as describe in the article, the control is WAS side.2. Last Partecipant Support-LPS in WAS 5 EE mentioned in the article (capability to coordinate two-phase and one-phase commit resources) will be available in WAS 6 Base in few weeks.As for Figure 3 of the article this should be your scenario.Ciao D.
Very interesting, I will sure check because we have some problem with distributed transactions.
But I want to mention a test we did:
1) Launched a CICS Transaction that update a record on DB2
2) Killed CTG on my PC
3) I had a rollback on the J2EE side, but when I check on the mainframe, the row is UPDATED !!!!
Do you think the problem can be that I we use ECI with SNA/VTAM ? Or do you think the ECI call I make is not enlisted in a DPL ?
Thank you very much.
I'm not a CTG expert but I guess the following:
- using Extended Unit of Work (ECI_EXTEND I think) you have no choice, Host program cannot commit (it's forbidden). You have to commit WAS side.
- I guess your are using ECI_NO_EXTEND. It isn't a matter of SNA vs TCPIP, I think.
- Have you ever worked in Verona?
- Have you ever programmed on Atari?
If the answers are yes:
1. I think we met in the past several times...
2. Bring my regards to Diego
If the answers are no... forget it.
Well, I use ECI_EXTENDED, but you gave me many things to check and I will do it, may be I can solve my problem.
Anyway...I worked 2 years in Verona !!!!
We currently communicate to our mainframes by several technologies from direct sockets to MQ Series and now CTG. All these various technologies have their advantages as well as their disadvantages. For example, we have seen the best performance with pure Java sockets, however, we still have to manually handle conversion from the UNICODE world to the EBCIDIC world and have no guaranteed message delivery mechanism to the mainframe. In the financial services area this is a hude negative as we have thousands upon thousands of transaction that need to update to the mainframe. MQ Series boasts supporting guaranteed message delivery and reasonable performance. But assumes a considerable licensing cost to deploy queue managers on the mainframe. We have actually had to deploy multiple MQ Series servers on our AIX machines and connect to the mainframe queues managers via server to server messaging channels. This significantly exhibited performance improvements over client to server channels. However, our preference has been to use CTG as this has demonstrated the best performance and scalability options for our architecture and performs any of the necessary character conversions. The downside is that we do not have guaranteed message deliver. But this is a small cost to pay for the performance gain. And if we need a transaction to support guaranteed message delivery we can either use JMS in the application tier or MQ on the backend. Our mainframe application is primarily an off the shelf product we leverage and the manaage DB2 transactions within COBOL programs. This allows us to support both MQ Series connections and JCA connections. I do believe the current version of CTG does not support distributed transactions. Another thing to note is that the installation and documentation for CTG wasn't exactly at the caliber I would have expected from a commercial product, but rumor has it IBM has packaged the new version quite well. Hope this helps.
Hi, Ronald Burke,
First of all, sorry for the bad english and the poor knowledge in mainframe area.
What you wrote is very interesting to us. We are right now trying to win our first challenge in Java-CICS intercommunication. We work with WSAD-IE, WebSphere App. Server 5.1 running on Linux over Intel and z/OS, CICS TS 2.2, z/OS 1.3 and DB2 v5.0. We are trying to implement a small Web Application that will call a session stateless EJB, and this will call a CICS Transactionm using a ECI resource adapter and CTG 5.0. We're using the COMMAREA and JavaBeans conversion.
We have a assynchronous processing. See the scenario: One CICS transaction in our region (A), starts remotely another CICS transaction (B) in another enterprise (other city). When the transaction B finishes, he calls another transaction (C) in our region returning the results waited. This worked fine in old 3270 based screens. There, they worked with the Terminal-ID, I think.
But how to do this in a synchronous call of a Web App? We don't have MQ Series installed in our mainframe. Does exist another way to manage these assynchronous calls in the WebSphere side? Do you have a situation like that? Should it be used JMS and/or EJB-MDB? Does anybody else has some experience or hints about that?
Thanks a lot !!
Andre Luiz - 7º DF - Brasil
interesting to see that there are still some people talking about 3270 transactions. You mentioned that you don't have MQ installed. I guess for the task that you try to complete, MQ is not necessary because everything you need is implemented in CICS.
You referred to the Terminal ID. I assume that you need a kind of unique identifier. Or does that mean that you are thinking about initiating a tx in another region is a problem?
If I (as one of these old dinos from the mainframe) would have to build an scenario like you, I would simply use the same "Start Transid" command that worked in the 3270 world just without a terminal-Id. There you can pass the COMMAREA through to the dependent transaction.
Perhaps I missed the point completely but I see the Web-Application and the Transaction flow between your CICS Transactions as seperate processes that will finally work together.
Hope that helps ... if not, put me in the right direction and we find a way ...
Hi, Jochen Grotepass,
Thanks for the answer.
The task we have to do is a simple query to validate a Account Number and Client Id in another company through her CICS transactions. We built a simple Web page that calls a Session stateless EJB, and this calls a CTG via ECI, getting to our initial transaction. I don't know what is "Start Transid" and neither where this command goes. : (
Now, the problem for me is that my EJB interact with a COMMAREA at one Program/Transaction and the answer comes at another program that is called by the CICS of another company. My doubt is: Could I coordenate that process at the Java side, by using EJB-MDB/JMS? Or Should I threat this situation only at the CICS transactions and COBOL programs level? If possible, I'd rather work with this case only at the WebSphere side.
Andre Luiz - 7º DF - Brasil.
We are actually trying to do a similar thing i.e., web page(servlets) > EJB -> CICS through ECI, but I'm a bit stuck. Is it possible for you send me a pseudocode of this architecture. Would be of much help.
IONA has a complete offer for the mainframe, look athttp://www.iona.com/products/artix/welcome.htm
Artix Mainframe provides a set of tools to publish CICS and IMS transaction as webservices. It runs natively on the host and it takes advantage of the multiprotocol capabilities of Artix, for example you could use JMS, TIBCO RV or MQ series to send SOAP request (or just XML documents) to the mainframe. The documentation for ARTIX MF is accessible at http://www.iona.com/support/docs/artix/mainframe/2.0/index.xml
I am implementing the same architecture EJB->CTG->CICS, and I would like to know or if anyone can point me to the tight documentation to get this thing started.
Thanks for your help.
I mean the "right" documentation ;)