RE: ASCII to EBCDIC with Parity

We have always verified the LRC and built the packet with the STX ETX. The vendor says they do not look at the packet. All they do is upon answering, send the ENQ to trigger the POS device to send the data. Our OLD ICFF program took care of the Parity. Guess I will have to resurrect the translations that was done in that program. (Written in RPG II initially, translated to RPGIV years ago, and with all the BITON BITOFF very ugly.) Was also an external call.

Has anyone built a table for XLATE with 7 bit E parity ASCII characters?


Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: Monday, October 31, 2016 7:08 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: ASCII to EBCDIC with Parity

On 10/28/2016 5:35 PM, Chris Bipes wrote:

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.

That sounds right.

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.

The crucial thing here is that YOU are not sending anything to the POS,
your vendor is.
This means that YOU do not need to worry about STX, ETX, LRC, baud rate,
parity -- your vendor does.

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.

Your vendor should be getting regular, plain old ASCII from you.
Your vendor should be doing the buffering, parity, baud, framing with
the data they receive from you.

Is the vendor asking you to preformat the packets so they look exactly
like the POS wants? I think that's... unusual.