This is a little off-topic, but I don't know who else might have the
answer.
I've posted this same query to bit.listserv.cics-l, but it's a pretty slow
group, and I don't have high hopes.
Here goes:
We're getting into the 21st century, here, and I'm tasked with writing a
TCP
child server for CICS. No one in the company has ever done anything like
this - no place I've ever worked has ever done anything like this. And
I'm
having a problem.
We are using the enhanced listener under CICSTS13, and have set PEEKDATA
to
YES, so the listener output passed on the START contains no message
information. Between the client and I, we have established a convention
that the first two bytes of the message contains the length of the
remaining
data. The client is a non-IBM machine, and is doing the ASCII to EBCDIC
conversion before sending the message.
I successfully retrieve the listener output, and successfully perform
TAKESOCKET. Then I try to read two bytes from the socket (using the READ
socket request in a loop until the two bytes are received) to get the
message length. This read takes four minutes to complete. The read loop
for the rest of the message takes under a second.
The four minutes is not acceptible. Should I be using RECV with the PEEK
flag set instead of my READ? Or should I use READV? I've pretty much
eliminated the READV, because the message length tells me how much storage
I
need to acquire for the rest of the data.
Anyone got any ideas?
Jimbo
|
