I've been having a bit of a think on this one. My conclusion is that this is not possible and you should adopt another design to do what you want. However, there is a sneaky way which MIGHT assist, but at your own peril!
Before I get onto that, though?
If you are running outside of the MVS environment and want some transactional (in the 2phase commit sense) recoverability to work between a CICS transaction and the outside, then you are going to have to ensure that the syncpoint managers (aka the resource recovery managers) can talk to themselves and decide who is going to do what. In the CICS world this was done with LU6.2 communications with CICS being the controlling entity.
Outside of the IBM environment, this transactional coordination is handled within the EJB world by protocols that are part of the RPC-nature of EJB accesses. Again, the RRMs are in communication with each other and there is, in effect, a strict 2phase commit flow going on over the wire to ensure that the client environments' recoverable resources and the EJBs recoverable resources are coordinated in the required transactional fashion.
So the first thing to say is that if you can arrange things to work in the EJB environment, you may get what you want.
An alternative would be to send the TCP/IP flow into a CICS transaction gateway and get it to issue the equivalent of the XC LINK. Transactional facilities are available from the CTG to the CICS application whether it's a host CTG or a workstation CTG. This would mean rewriting the issuing application not to use a TCP/IP flow but issue a CICS client request instead. You may also need to get into compensation actions (what to do in the client if the CIS bit works but the rest of the client fails).
The general problem with a TCP/IP flow is that it is not transactional. In this case I mean that a UnitOfWord Id does not flow along the wire. Naturally, this does not stop you from sending a UoW Id that has been obtained from a RRM and sent as part of your flow. However, in order to make things work properly the RRMs have to be in communication and you would have to implement a strict 2phase commit protocol.
Now, if you look at the EXCI protocol definitions in the External Interfaces book, you will observe that there is the possibility of specifying the UoW Id for the request and CICS will use that to talk to the MVS RRM. So, if the request is originating in MVS and the originator is transactional, you can use the UoW Id for the transactional client by specifying it in the EXCI request. All the MVS activity will be transactional and so either all succeed or none does. However, you say that you want to use TCP/IP, so this design is not what you want.
So, in conclusion, you can only get close to what you want to do but not actually get there.
I guess you are going to end up with a function running inside MVS (including CICS) that is transactional and another function outside of MVS that is also transactional but the two UnitsOfWork are distinct and not joined up. This means you are going to have to code up both ends of the flow in some sort of hand-driven SL(1) mechanism. Also, you are going to have to make a decision about which end syncpoints (commits) first and what happens in the other end it abends. This is compensation logic.
CICS Technical Strategist -- CICS expert at Search390.com
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .VO7aaqqaAFk.0@/search390>discussion forums.
This was first published in April 2003