×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Your RecvAscii should loop over recv() until you have a complete message. All the parts may not make it across the network at the same time, so your receiver must be patient.
Do you have some sort of EndOfRecord that you can watch for? Simplest approach here is to receive one byte at a time, append it to your "receive buffer" while watching for your end of record character...
Hth,
-Eric DeLong
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Versfelt, Charles
Sent: Wednesday, March 02, 2011 8:53 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Sockets program adding characters?
Hi,
Thanks for the earlier help on my Sockets program. I have now successfully made it through a connect() and sent their CONNECT API command in Ascii, received (and converted back to Ebcdic) the OK reply from their server.
Now I'm attempting to send another API (their RATE API) and I'm not getting a valid reply. The debug log on the server seems to show characters getting appended to the beginning my request. I'm also getting an error that the response is truncated, but right now I'm not getting any valid response because of those appended characters. (A third error having to do with the timezone I'm assuming isn't a problem to be concerned about.)
I'm using a procedure called SendAscii (from one of the sample programs) and RecvAscii (I created that one).
SendAscii converts to Ascii and Sends. RecvAscii recieves Ascii data and converts to Ebcdic.
The code for these is below.
I call the procedure as follows, where s = my socket and ReqData = the data for my API.
SendAscii(s: %trimr(ReqData));
The data for the API is this, and was contained in variable ReqData
The specific errors I'm questioning are these. Especially the weird characters in front of 0000000151RATE|
02/Mar/2011:09:17:15:609 -0500;4364;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;Reponse was bigger than the message size used for request message. Truncated. Please try to use bigger message length protocol. Full response is getting logged..
02/Mar/2011:09:17:15:609 -0500;4364;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;ERRCODE|001000011|ERRMSG|Validation of message failed : ðððððððððóÖÒO0000000151RATE|
In case it helps, below is a larger snippet of the debug log from the server. The 0000000003OK| is the reply back from the CONNECT API, sent using my SendAscii and reply received using RecvAscii.
02/Mar/2011:09:16:38:828 -0500;4364;0;DICom.cpp;InOutProc;INFO;Message Read;CONNECT|CLIENTTYPE|10|CLIENTID|E0007825019-1|
02/Mar/2011:09:16:38:843 -0500;4364;0;DICom.cpp;InOutProc;INFO;Reply Write;0000000003OK|
02/Mar/2011:09:17:15:593 -0500;4364;0;DICom.cpp;InOutProc;INFO;Length Of Incoming Message;
02/Mar/2011:09:17:15:593 -0500;4364;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:09:17:15:609 -0500;4364;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:09:17:15:609 -0500;4364;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;Reponse was bigger than the message size used for request message. Truncated. Please try to use bigger message length protocol. Full response is getting logged..
02/Mar/2011:09:17:15:609 -0500;4364;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;ERRCODE|001000011|ERRMSG|Validation of message failed : ðððððððððóÖÒO0000000151RATE|
02/Mar/2011:09:17:15:609 -0500;4364;0;DICom.cpp;InOutProc;INFO;Reply Write;0
02/Mar/2011:09:17:15:703 -0500;4364;0;DICom.cpp;InOutProc;INFO;Length Of Incoming Message;
02/Mar/2011:09:17:15:703 -0500;4364;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:09:17:15:718 -0500;4364;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
Here's where I send the API:
s = @psock;
SendAscii(s: %trimr(ReqData));
if s <= 0;
@preturn = 'RATE002';
@prtnmsg = 'RATE Send Request Failed.';
joblog('RATE Request failed during send!');
return;
endif;
Here's SendAscii and RecvAscii:
*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
* This converts data to ASCII and then sends it.
*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P SendAscii B
d SendAscii pi 10I 0
d sock 10I 0 value
d data 1024A value
*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
* This recieves data and converts from ASCII to EBCDIC.
*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P RecvAscii B
d RecvAscii pi 10I 0
d sock 10I 0 value
d data 1024A value
d RecLen s 10I 0
d RspBufAdr s *
d RspBufLen s 10I 0
D reply s 10I 0
D errornum s like(errno)
// and translate the ASCII to EBCDIC
// ---------------------------------------------------
// Recv() API parameters
// int - Socket descriptor
// char - address of the input buffer area
// int - buffer area length
// int - flags (not used here)
RspBufAdr = %addr(data);
RspBufLen = %size(data);
RecLen = recv(s: RspBufAdr : RspBufLen : 0);
errornum = errno;
If (RecLen < 1);
data = 'ERR: No Reply. ';
return -1;
Endif;
// Translate: QDCXLATE API parameters
// Length of data being converted Input Packed(5,0)
// Conversion data I/O Char(*)
// ASCII In, EBCDIC Out
// SBCS conversion table name Input Char(10)
Translate(RecLen : data : 'QTCPEBC' );
Monitor;
On-Error;
data = 'ERR: Trans Fail';
return -1;
EndMon;
Sockdata = Data;
return send(sock: %addr(data): RecLen: 0 );
/End-Free
P E
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
