× 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.



Ah - the first 10 characters are not an integer data-type, they are a 10-digit number, which can be held in a 4-byte integer variable. That was lending some confusion in this conversation, as I briefly read it.

HTH
Vern

On 3/2/2011 2:11 PM, Versfelt, Charles wrote:

Thanks for the replies...

The first 10 characters for all their API requests and replies are the total characters. I agree that seems like an unusual number for a byte count, but those are the specs, the vendor's requirements. What I'm sending is an alphabetic string in a variable, of which the first 10 characters happen to be the total.

I have a field called ReqData, 1024 A

The data contained is as follows:

0000000151RATE|CARRIER|PURL|SERICE|AIR|AUDIT_USER|PCL|SFCUSTNUM|0001234567|PKGCNT|1|TERMS|S|S2COUNTRYID|CA|S2CITY|CALGARY|S2STATE|AB|S2PCODE|T2A7W6|WEIGHT|1.00|

I should be receiving back a reply that looks like this

0000001064TRANSTYPE|RATE|ERRCODE|000000000|ERRMSG||S2MAILZONE||SHIPDATE|20071211|
FREIGHT|169.95|CALCFREIGHT|199.96|HAZCHG|0.00|COSCHG|0.00|DECVALCHG|0.00|SATDLVYCHG|
0.00|SATPICKCHG|0.00|..................

Instead it's just sending back 00000000 and when I look on the server, the debug log I provided.

When I do this:

SendAscii(s: ReqData);

Inside my SendAscii procedure, ReqData goes into data, also 1024A

That procedure does this:

len = %len(%trimr(data));
Translate ( len: data: 'QTCPASC' );
return send(sock: %addr(data): len: 0 );

Before the Translate, data is = the entire string above.

It does the translate... Then the send... After the send, the error.
The message in the log:

02/Mar/2011:14:42:31:906 -0500;6124;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;ERRCODE|001000011|ERRMSG|Validation of message failed : ðððððððððóÖÒO0000000151RATE|

The e-mail is turning the characters into question marks so let me change them to O's so you can get an idea what this really looks like

02/Mar/2011:14:42:31:906 -0500;6124;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;ERRCODE|001000011|ERRMSG|Validation of message failed : ooooooooooOOO0000000151RATE|

Where the first nine o's look like an o with a little squiggle over it, the last o looks like an o with an accent,
The first capital O has two dots over it, the next capital O has an accent over it, and the last capital O is a regular capital O.

It seems to be happening when sent, or the server is giving me an erroneous message.
In debug, at the point of the len in the following...

len = %len(%trimr(data));
Translate ( len: data: 'QTCPASC' );
return send(sock: %addr(data): len: 0 );

At the point immediately prior to the Translate,

data = 0000000151RATE|CARRIER|PURL|SERICE|AIR|AUDIT_USER|PCL|SFCUSTNUM|0001234567|PKGCNT|1|TERMS|S|S2COUNTRYID|CA|S2CITY|CALGARY|S2STATE|AB|S2PCODE|T2A7W6|WEIGHT|1.00|

I even tried this, to make sure nothing weird was happening during the Translate:

(datax is defined same as data)

Translate ( len: data: 'QTCPASC' );
datax = data;
Translate ( len: datax: 'QTCPEBC' );

Translating it to Ascii and then back to Ebsdic

Datax STILL equals
0000000151RATE|CARRIER|PURL|SERICE|AIR|AUDIT_USER|PCL|SFCUSTNUM|0001234567|PKGCNT|1|TERMS|S|S2COUNTRYID|CA|S2CITY|CALGARY|S2STATE|AB|S2PCODE|T2A7W6|WEIGHT|1.00|

Obviously the translation is working fine.

The very next step,

return send(sock: %addr(data): len: 0 );

Is where the server is giving me the message with the goofy O characters before my string.

Thanks,
Charlie

02/Mar/2011:14:42:28:578 -0500;6124;0;DICom.cpp;InOutProc;INFO;Length Of Incoming Message;0000000045
02/Mar/2011:14:42:28:593 -0500;6124;0;DICom.cpp;InOutProc;INFO;Message Read;CONNECT|CLIENTTYPE|10|CLIENTID|E0007825019-1|
02/Mar/2011:14:42:28:609 -0500;6124;0;DICom.cpp;InOutProc;INFO;Reply Write;0000000003OK|
02/Mar/2011:14:42:31:890 -0500;6124;0;DICom.cpp;InOutProc;INFO;Length Of Incoming Message;
02/Mar/2011:14:42:31:890 -0500;6124;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:14:42:31:906 -0500;6124;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:14:42:31:906 -0500;6124;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:14:42:31:906 -0500;6124;9;DICom.cpp;InOutProc;INFO;Server could not send data on the socket;ERRCODE|001000011|ERRMSG|Validation of message failed : ðððððððððóÖÒO0000000151RATE|
02/Mar/2011:14:42:31:906 -0500;6124;0;DICom.cpp;InOutProc;INFO;Reply Write;0
02/Mar/2011:14:42:32:000 -0500;6124;0;DICom.cpp;InOutProc;INFO;Length Of Incoming Message;
02/Mar/2011:14:42:32:000 -0500;6124;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:14:42:32:015 -0500;6124;0;dcTimeZoneInfoWindows.cpp;getDCLocalTime;ERRO;TimeZone;Timezone information is not properly configured for DC# 0. Using server timezone as DC timezone.
02/Mar/2011:14:42:32:015 -0500;6124;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..


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.