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

Part I: What's possible in the realm of sockets when communicating with CICS?

I have a general question about what is possible in the realm of sockets when communicating with a CICS mainfr...

ame.

We have a piece of middleware software that collects and consolidates data from various sources and then passes that data on to various external systems such as ODBC databases, etc. We have provided a generic XML protocol over a TCP/IP socket connection to allow flexible connections to any backend host computers. The problem we are now hitting is a client who claims our topology/protocol isn't possible for them to handle in their environment.

Here is our system in a nutshell: We open a socket connection to the remote port and send what amounts to a logon message. Assuming we receive a favorable response we then send data messages up, each of which has a response that can contain error information or possible result from the remote processing. If a specified amount of idle time elapses between these data messages, we send a kind of keep-alive message that again has a response. Finally, when the overall processing is complete send the equivalent of a logoff message.

A few additional details: Because our software has no guarantee of how fast the host program will process any individual data message, we support a small fixed number of simultaneous connections so that long-running tasks won't totally block other shorter-running ones. The volume of these data messages varies from many-per-second to periods where minutes (or even perhaps hours) can go by without any new data. This approach works fine for the likes of a Java program running on a Unix box, but does it really present such a problem in the CICS world?

The following is a three-part expert response.

This is an interesting question -- and many thanks for appending a detailed description so that I can understand what is going on. You have obviously read the CICS TCP/IP Socket Interface reference book provided by TCP/IP for MVS.

The quick answer is: Yes -- but you will have to be careful.

You should construct a Listener program and then two service programs/transactions. The listener program merely LISTEN()s upon the relevant socket waiting for an initial contact from the remote client. As soon as it receives a flow, then it should do a GIVESOCKET() put the socket id into Startdata and XC START the first service transaction.

INITAPI() ; SOCKET() ; BIND; LISTEN()

Loop: GETCLIENTID() ; SELECT() ; ACCEPT() ; GIVESOCKET() ; XC START TRAN(S1) FROM() ; SELECT() ; CLOSE() ; reloop

The first service transaction should receive and police the initial XML encoded flow (containing the sign-on info). You don't need to bother waiting around or managing volumes at this stage, because your protocol dictates that the initial flow will always of fixed format. Thus, if this looks correct, you can start the second service transaction, which does all the work under the security identity passed in on that initial flow. I'm assuming that this security verification is correct in the code.

INITAPI() ; XC RETRIEVE ; TAKESOCKET() ; RECV(Peek) ; RECV() ; valid initial flow ; GIVESOCKET() ;

Extract the XML security identity, validate it, maybe SEND() the response and decide what next service transaction is to do the work.

XC START TRAN(S2) FROM() USERID() ; SELECT() ; CLOSE() ; XC RETURN

Here you have to be slightly careful in that you have a big enough area available to receive the flow, which is why the RECV(PEEK) is around. If the initial logon-equivalent message is of fixed length, then that's an easy RECV(). If the maximum length is known, but the flow can be variable, then you are going to read a portion of the next message as well as the userid one. Thus, you will have to pass the initial bit of the second message alond with the SocketId in the Startdata for the second transaction (and fixup). However, your protocol may be such that this request does not flow until a security OK has flowed back to the client, in which case all this buffering stuff is irrelevant.

This S1 transaction is always started by the listener and as it is not doing anything terribly long lasting, should not cause any capacity problems.

For part II, pease click to continue.

This was last published in December 2002

Dig Deeper on IBM system z and mainframe systems

PRO+

Content

Find more PRO+ content and other member only offers, here.

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.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

SearchServerVirtualization

SearchCloudComputing

Close