RE: Socket Programming - HL7 Data to Win2k server

On Tue, 9 Dec 2003, Gerald P. Kern wrote:
>
> I agree. I can't seem to get the vendor to tell me what they want to recieve
> at their end.

If they refuse to, then use the sniffer approach that I suggested in the
last message.

> Am I correct in interpretting your example that the x'0b' is sent by
> itself (untranslated) and then the translated data is sent?

Correct...  my thought was that the vendor actually wants to receive x'0b'
and x'0d' and x'0a' rather than whatever you get when you translate an
EBCDIC x'0b' to ASCII.


> In my program I am putting the x'0b' and the start of the field, then
> concatenating the data and the x'0d0a', and then translating that entire
> string to ascii which is what gets sent to the server.

Well, actually in the code you showed me, you had x'0d25' (not x'0d0a')
though, after the EBCDIC to ASCII translation, it should become x'0d0a'.
But, I don't see the point of translating them...  Why use extra CPU
cycles translating x'0d25' to x'0d0a' when you can just send x'0d0a' in
the first place?

And, I have no idea (without looking, anyway) what x'0b' gets translated
to when it becomes ASCII.   I assumed that the vendor actually wanted
x'0b', rather than whatever it translates to.


> Also, when I do the write, I do get a response that tells me how many bytes
> were sent, then the program waits for a reply (where it sits and waits at
> the read statement).

Yeah, that's fine.  I just used callp instead of eval x = send (blah blah)
because I was lazy when I replied to you.   You should, of course, be
checking the return values not ignoring them like I did.

I was just trying to show you the technique of translating SOME of the
data to ASCII without translating it all..

> Thanks for the reply.

You bet.