MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » June 1999

RE: Communication question


  • Subject: RE: Communication question
  • From: Ken Slaugh <ken.slaugh@xxxxxxxxxx>
  • Date: Thu, 3 Jun 1999 19:48:13 -0700

fixed

Nina
        I hope this helps, if not call me at (707) 795-1512. I know
async real well.

The Async protocols that should be involved with this interface should
also allow for some type of handshaking. I have been able to simply read
data before but most of the time a byte response has to be sent back
before the 'sending' computer will send any more data. Since you
originally stated that these records would be coming at a rate of one a
minute the AS/400 should not fill any 'buffers'. This did happened to me
about 10 years ago. Once on the Sys/36 I attempted to capture the
continuous RS-232 data from a scale head. It constantly sent data
regardless of the weight. About four times a day a user space on the
midrange would consume all the memory and IPL was the only solution.

If what GM is saying is true and no handshaking is done, your solution
may be simple and the best you can do (read the last paragraph). You'll
need to you establish a few facts.

The baud rate is _______, hopefully not 300 and more like 56000
The number of data bits is ____ 8 or ____ 7, you may guess 8
The number of stops bits is ____ 1 or ____ 2, you may guess 1
The type of parity ____ None or ____ Even or ____ Odd, get this wrong
and garbage will result

If I had to do this I'd have GM call my PC and send the data. I'd
capture what I could and analyze it. I'd try hyper terminal that came
with Windows to start with. I'd keep changing available settings trying
to get something of value. Other programs like Crosstalk and ProComm do
a better job at this especially the old DOS based ones.

Once the bit patterns are established I'd start breaking down the data
into records and/or fields as needed. Since the AS/400 can do the EBCDIC
to ASCII automatically, I'd try to let it do it (if block checking is
required this is not an option). My RPG program would acquire the
device/controller/line, wait on a data queue attached to the ICF file.
Once it received a record through the comm buffer I'd forward it to a
different RPG program via a call or most likely another data queue.

This type of interface is UNSTABLE. The information received this way
will be prone to corruption. No block checking will result in SCRAMBLED
data bits resulting loss of valid information. The data transmitted in
this method could never be certified.

Ken Slaugh
Senior Programmer/System Analyst
AS/400 Professional Network Administrator/MSE
Specialist - Client Access/400
Chouinard & Myhre, Inc.

> -----Original Message-----
> From: nina jones [SMTP:ddi@datadesigninc.com]
> Sent: Thursday, June 03, 1999 5:27 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Communication question
> 
> 
> interesting responses!  thanks!
> 
> i wish i had more info on what was producing the data, but from what i
> hear the guy at gm has been less that responsive.
> 
> the info i got from them said it was 'flex data output'.  does that
> ring
> any bells, or is that a gm term?  what happens is that when the car
> gets
> off the painting line, a transaction is sent to the customer to order
> the bumpers.  
> 
> the gm said it was a straight serial connection, so what's the big
> deal??  i did some t-spec type stuff years ago, but that was batch
> bysinc.  this is ascii, a whole different deal.  
> 
> the list of stuff says they need 'data circuit equipment, with a build
> in modem, a dial up modem (i think for backup), a multiplexor, a v.35
> cable, and an rj45 straight thru 8 conductor cable.    
> 
> to complicate things, i'll be in atlanta next week.  so i'll have to
> hand it off to willie, my other programmer.  we'll discuss some of the
> options tomorrow, and get with the client to see what they want to do.
> 
> nj
> 
> p.s.  eat a toad?  gross!
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact