RE: ASCII to EBCDIC with Parity

The way this all works for clarification is:

Point of Sale device dials up to service provider using 7 bit, Even Parity, and 1 stop bit.

Service provider strips off the parity bit and send us the string in ASCII via TCP connection.

We convert to EBCDIC for processing

We convert the response back to ASCII before sending the socket.

Point of Sale terminal packets look like this:

<STX>data packet is bracketed between two bytes<ETX><LRC><NULL>

<STX> is the Start of Text byte or x'02' with parity enabled it becomes x'80'
<ETX> is the End of Text byte or x'03'
<LRC> is a longitude Redundancy Check byte and is calculated using a special formula.

Packet is null terminated but the null is not included in the packet length and therefore not sent.

I need to account for the extra bit but need an easy way to calculate / strip it and get the correct data.

I was hoping someone has done this and had a table I could use.

I may have to write a Parity routine to strip before translation and add back after translation.



Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Friday, October 28, 2016 2:02 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: ASCII to EBCDIC with Parity

On 10/28/2016 4:03 PM, Chris Bipes wrote:

I have just changed our very old communications program from X.24 to IP. I am still communicating with the same Point of Sale terminals. These terminals use a parity bit. 1200baud 7E1.

-snip-

There seems to be some issues as currently the service provider that I communicate with is stripping the parity before sending the packet to me and then adding it back when send the response back to the POS terminal.

That sounds right to me.

Parity is a configuration item in the communications adapter, not in an
application program.

I would love to get rid of the parity manipulation by them but I need a good code page conversion. What would the ASCII value be that handles ASCII with Parity? 813 is not working correctly.

By definition, the serial comms configuration includes data rate, data
bit length, parity bits, parity type. All of these things are
independent of how the data are stored in a database. CCSID and code
page are exactly the opposite; these things describe how an application
program ought to interpret the bit patterns stored in the database.

That's probably too many words to say that I don't think you have a
parity issue. At least, not between you and the vendor.