Problem solve Get help with specific problems with your technologies, process and projects.

Trying to issue the equivalent of an XC LINK PROGRAM() COMMAREA() to CICS

Our company uses a middleware product called EDA/CICS as an interface between Microsoft Windows and CICS on the mainframe (Transaction Server 1.3). Management wants to eliminate the middleware and replace it with native CICS facilities. I've been investigating various solutions but it appears that most of them deal with accessing CICS from a Web browser. I'm hoping to replace the middleware with TCP/IP functions but we don't need access from a browser, we'll access CICS from Windows ACCESS running Visual Basic on the front end. We have CICS COBOL programs that handle the mainframe side but need an interface to connect Windows on the PC to the mainframe without discarding all the VB code we've written on the front end.

I think that SOAP and the CICS Transaction Gateway are two potential solutions for us. However, CTG is an optional product that we must purchase. Since the company is interested in reducing middleware costs, that option won't work.

Do you think using SOAP is feasible for our application? No XML or Java is used, only VB Version 4 programs. Ideally we'd like to retain all our VB programs and just replace the middleware functions. That way the rewrite requirements would be minimized, etc.

Also, do you know if we can use ECI with the CICS Universal Client as a solution? I'm somewhat confused on how we would do that. The IBM documents on both seems to be difficult.

From your description, I think you just want to issue the equivalent of an XC LINK PROGRAM() COMMAREA() to CICS, send some parameters in the Commarea and getting the response back. The Transactional boundary (UOW) is at the CICS edge. In other words, you want to do the CICS stuff in a UnitOfWork that is only applicable to CICS. If the VB application subsequently fails, then you will have to initiate some sort of compensation action is CICS to clear things up (always assuming that the CICSy activity is updating CICS Recoverable resources).

I don't know what the interface to EDA/CICS looks like. Your design decision will have to consider where a structure turns into variables and at what point you want this to happen.

As you say, you have several options available:

1. Using the Transaction Gateway but you don't want to pay for it, so that's out
2. Using EJB access, not interested
3. Using the CICS Universal Client, a possibility
4. Using SOAP/XML, a possibility

If you go down the UC route, then you will have to install it on all of the workstations that want to issue a CICS request. This will probably mean installing it as a Windows service. Have a look at some of my recent articles in Xephon's CICS Update about configuration for best access into CICS (these talk about the CTG but the architectural arrangements remain the same). This approach has the benefit that a Commarea is used for access and CodePage translation is done for you at the CICS end. You MUST ensure that you get security correct.

The XML/SOAP route is a new function for CICS -- the Inbound SOAP support in the SupportPac is available for CTS 1.3 and CTS 2.2, so there should not be a CICS dependency to trouble you. In this case, you do not have anything special installed on the client workstations so you just shove a request out on a TCP/IP socket using HTTP to CICS. This flow is XML/SOAP encoded. In this case, the parameters, and the returned results will be in Key=Value format and so require more processing to create/access that is the Commarea case. This is not necessarily a disadvantage in the VB environment as you want to end up with VB variable not a VB structure. Again, you are going to have to be carefully about security.

I think I would be very inclined to investigate the XML/SOAP route as your first task. Implementation of this technique does not need the UC installed on the workstations and once you have got the coding technique worked out, then this would be easily extendable for your VB applications to use other SOAP-provided services. As the results from in a Key=Value format, it should be quite easy to find a particular Key, extract the Value and plunk it into a VB variable. I'm sure there must be guidance about doing this in the VB documentation or Web site.

One word or caution though. As you are -- essentially -- going to have a private XML/SOAP protocol implemented, you can take short cuts in the coding as you are in control of everything. XML/SOAP purists would think that this short cutting is a bad idea. Additionally, most of the XML documentation talks about parsing the XML envelope using Java (because that's the environment with which these articles are most familiar) ?- do not be side tracked -- VB can quite happily do the job in YOUR environment.

Robert Harris
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.

Dig Deeper on IBM system z and mainframe systems

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.