Yes really. We do not talk with the service provider that answers the phone. But they pass us the raw data, in 7 Bit Even parity format. We actually communication over ICFF with their Network Interface Processor which is a Linux system. The line is an X25 line over a X21BISV35 port with 8 channels. This is what I had to convert to TCP/IP. I am going to build the table as you suggested and give it a try.
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 9:18 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: ASCII to EBCDIC with Parity
On 10/31/2016 10:25 AM, Chris Bipes wrote:
Our OLD ICFF program took care of the Parity.
Are you sure? Unless the old ICF program was really low level (ie
talking directly to the RS-232 cable going to the modem) the parity is
dealt with outside of the program, in the comms configuration. Here's a
sample:
CRTLINASC LIND(VENDOR) RSRCNAME(LIN011)
INTERFACE(*RS232V24) CNN(*SWTPP)
BITSCHAR(7) PARITY(*EVEN) STOPBITS(1)
DUPLEX(*FULL) ECHO(*NONE) LINESPEED(1200)
The RPG program does not know, nor care whether the line is using 7E1 or
8N1, or whether it's 1200 or 54600 baud.
Has anyone built a table for XLATE with 7 bit E parity ASCII characters?
The last time I did that I was bit-banging a serial transfer with a PIC
microcontroller. That algorithm is simple-ish.
For outbound ASCII characters:
1) Strip off the high order bit
2) Shift the bits left one position.
3) Count the 'on' bits. If there are an odd number of 'on' bits, make
the low order bit 'on', otherwise, make it 'off'. Even parity means
that the 'on' bit count is even.
4) Send 8 bits (7 data plus one parity).
5) If the far end has a parity error, be prepared to re-send the last
character.
For inbound ASCII characters:
1) Receive 8 bits (7 data plus one parity).
2) Save the low order bit.
3) Shift the bits right one position, 'losing' the current LSB.
4) Put a 0 in the high order bit (to make an 8 bit character again).
5) Count the 'on' bits. If there are an odd number of 'on' bits, the
saved parity bit needs to be a 1, otherwise it needs to be a 0.
6) If there's a parity mis-match, command the far end to repeat the last
character.
The EBCDIC-ASCII translation is as usual between 037 and 813.
What I think you're asking for is a premade table of ASCII characters
with most of this algorithm applied. The missing piece would be the
calculation, testing, and re-transmitting part.
The table is easy enough to generate.
0000 0000 NUL becomes 0000 0000
0000 0001 SOH becomes 0000 0011
0000 0010 STX becomes 0000 0101
0000 0011 ETX becomes 0000 0110
... shift left, make LSB 1 to make the '1' count an even number. If I
had to do this with a lookup table, I'd use two tables: one to go EBCDIC
to bone stock ASCII and another to schlep the parity in there. Here's a
REXX procedure to generate that second table.
do decimal = 0 to 255
hex = d2x(decimal, 2)
originaleight = x2b(hex)
/* barrel shift left */
seven = right(originaleight, 7)
/* how many bits are on? */
bitson = 0
do i = 1 to 7
bit = substr(seven, i, 1)
if bit = '1' then bitson = bitson + 1
end
/* adjust parity as needed */
parity = bitson // 2
neweight = seven || parity
/* show the old and new side by side */
say originaleight neweight b2x(originaleight) b2x(neweight)
end
midrange.com
