I don't know how good the echoing of CICS-L to the bit. newsgroup is
(probably non-existent), but you will get a faster response if you joined
the CICS-L listserv rather than post to the newsgroup. The listserv is
very
active.
Send the usual listserv subscribe command to the listserv server of your
choice (I don't remember where CICS-L actually lives) to join.
There's also the IBMTCP-L listserv.
Best regards,
Ray
<.> wrote in message news:c3c32$4441390d$471f9fec$7038@[EMAIL PROTECTED]
> 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
>
>
>
|
