I have a general question about what is possible in the realm of sockets when communicating with a CICS mainfr...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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.
Dig Deeper on IBM system z and mainframe systems
Related Q&A from Robert Crawford
For better mainframe capacity planning, how do I convert CPU hours to MIPS? And is there a way to calculate the relationship between MIPS and MSUs?continue reading
I have two years of experience in mainframe technology, currently working as a mainframe developer. I want to change to Java technology.continue reading
I want to replicate DB2 from the mainframe to an AIX box since it's cheaper and the copy can be used for testing. Is this possible?continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.