Date: Tue, 21 Mar 2000 07:42:38 +0930
Reply-To: CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender: CICS List <CICS-L@LISTSERV.UGA.EDU>
From: Gary LLOYD <glloyd@ADELAIDEBANK.COM.AU>
Subject: Re: Sockets
Content-Type: text/plain
Many thanks for your very useful response.
Regards,
Gary
Sender: -------------------------------------------
Gary Lloyd - Adelaide Bank
Tel. +61 8 8300-6235
Fax +61 8 8300-6219
Mob 0419-826-763
Email glloyd@adelaidebank.com.au
Internet www.adelaidebank.com.au
--------------------------------------------------------
>>> Jean-Christian Chevalier <Jean-Christian.Chevalier@DATASPHERE.CH> Friday, 17 March 2000 19:16:03 >>>
Gary,
> We are looking to implement a socket application between CICS and an
application on another platform (Stratus). We envisage it working as
follows:
>
> - Stratus requests a 'logon' to CICS.
> - CICS listener binds socket and passes it to a CICS transaction (RFF1) to
manage. The socket is to be kept open while the Stratus is logged on (days,
weeks?).
> - Presumably RFF1 sits waiting on a Receive.
> - Stratus sends up a message request for service, RFF1 starts a background
transaction (RFF2) to process the request.
> - RFF2 finishes and then somehow taps RFF1 on the shoulder to say there is
a message to go back to the Stratus.
> - RFF1 picks up the message (Temp Storage, TDQ?) and sends it back to
Stratus.
>
> The input and output processes need to be asynchronous, i.e. the Stratus
could send up two or more messages in a row before it receives responses for
the messages, and the responses may not be sent to the Stratus in the order
they were received. Sends and receives can also be interleaved, i.e. send a
message either way as soon as there is one to send.
This means that the Stratus must store a "message identifier" in each
message it sends to CICS and your CICS application must give this same
message identifier back to the Stratus in the answer. In this way the
Stratus will be able to put the answers in the right sequence.
One big difference between LU 6.2 and TCP/IP sockets: When you use stream
sockets, you could get two messages in one read, or only a part of a
message. So the Stratus should store the message length at the beginning of
each message, so your CICS application can first read just the length and
then, knowing the message length, read the complete message at once (and
only one message).
> My questions are:
>
> 1) When transaction RFF1 is started, does it have to remain active to keep
the socket open? Could it save the socket/conversation info somewhere (TS)
so that when RFF2 has finished processing, RFF2 either sends the response
via the socket itself or starts another transaction to send the reponse.
Yes, the transaction needs to remain active to keep the socket open. The
socket can be passed to another transaction, with GIVESOCKET and TAKESOCKET.
However the socket must be kept by an active transaction in order to stay
open.
Furthermore, if you would be storing the socket info somewhere and then
terminating RFF1, it means that a message sent by the Stratus during the
time RFF2 does its processing wouldn't be processed immediately, but would
be delayed until RFF2 (or whoever else) would take the socket back.
> 2) If the RFF1 is terminated as in point 1, when the Stratus sends up the
next message, how would RFF1 be started again, because the message would not
go through the listener given that the socket is already established.
If the RFF1 is terminated, then the Stratus will probably get some type of
error when sending its next message, as the socket would be closed on the
mainframe side. The message could also be lost. What is sure is that no
transaction would be started in your CICS. The only way to have a
transaction started via TCP/IP in CICS is to already have a transaction
listening on a port in CICS. This means that the Stratus needs to do a
CONNECT and then this listener can act on the connection and dispatch the
message received.
> 3) If the above process cannot work and, therefore, RFF1 needs to remain
active to keep the socket open, how would it handle two asyncronous process,
one being waiting for an input message from the Stratus and the second being
waiting for a 'tap' to say there is a message to be sent back?
You could use the SELECTEX command which lets a transaction wait on one or
more sockets and on an ECB and on a timer. This means that RFF1 could wait
on the socket used with the Stratus and on an ECB which would be posted by
RFF2 when it needs to send the answer back to the Stratus. This way you
avoid having your transaction looping to see if it has something to do.
The manual explaining all this is the IBM OS/390 eNetwork Communications
Server IP CICS Sockets Guide - SC31-8518.
> Many thanks in advance.
>
> Gary
>
> Sender: -------------------------------------------
> Gary Lloyd - Adelaide Bank
> Tel. +61 8 8300-6235
> Fax +61 8 8300-6219
> Mob 0419-826-763
> Email glloyd@adelaidebank.com.au
> Internet www.adelaidebank.com.au
> --------------------------------------------------------
>
Jean-Christian Chevalier
DATASPHERE S.A.
jcc@datasphere.ch
