Re: Communications Project

Jeffrey,

Nope, no PC. We use a serial-to-Ethernet converter from Intelligent
Instrumentation. It's about the size of a modem. It has either 2 or 4
serial ports and an RJ45 Ethernet connection. You plug the serial device
into one of the serial ports and connect the RJ45 to the Ethernet LAN.
At Nina's customer we connected a DSU/CSU to the serial port. On the
other end of the 56kb circuit was GM's assembly line system. Our
software on the AS/400 initializes the converter and configures it, and
then communicates over the network with it. 

There are lots of advantages to this approach: You have full visibility
on the AS/400 as to the status of the converter so if it goes off-line
or loses power we can notify the operator. We can also automatically
recover the connection, reconfigure the converter, and restart the
session when the device comes back on line. That's important if the
device is a half a mile out in the warehouse. And you don't have those
nasty serial cable problems with distance and reliability. And it's
network routable, etc. Really a great device. We've tried a lot of
different solutions for serial connections and I like this one the best.

I'm trying hard to find some new definitions of toad....

Patrick

Jeffrey Silberberg wrote:
> 
> Hum,
> 
>         I missed something, IP in the link ??, hardware ??, I thought you
> were going to make this work with only AS/400 communications support in the
> link.  Sounds like you have a PC in a box using IP to talk with the AS/400,
> Right !  So you have done what many first suggested here which is put a PC
> between GM and the Customer, and use a peer process, APPC, IP, something
> other than ASYNC,  to make the final connection.
> 
>         I think the toad needs to be well done...
> 
>         JMS....  <g>
> 
> -----Original Message-----
> From: Patrick Townsend <townsend@patownsend.com>
> To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
> Cc: nina jones <ddi@datadesigninc.com>
> Date: Thursday, June 24, 1999 8:25 PM
> Subject: Re: Communications Project
> 
> >
> >That sound is toad sizzling on the BBQ...
> >
> >It took a little longer than five days, but we are up and running now.
> >Here's the play-by-play for anyone who's interested:
> >
> >TUE 6-15: We got the go ahead from Nina to ship her customer
> >          the software and hardware today. She is going to be on
> >          site on Thursday and will get it installed. The
> >          PC technician there wants to load the IP address on
> >          the serial interface unit, so we give him
> >          instructions on how to do it. We would normally do
> >          this before we ship the unit, but he doesn't have
> >          an IP address for it and wants to do it himself.
> >          It's easy - I'm not expecting any delays because
> >          of this. The bets around here are split evenly on
> >          my having to eat toad. But I'm confident, what could
> >          go wrong?
> >
> >THU 6-17: The customer gets the software, it gets installed on
> >          the AS/400, the hardware gets an IP address, we can
> >          ping it from the AS/400. The serial unit gets
> >          connected to the DSU/CSU and the link is up to
> >          GM. By the end of the day things are looking
> >          goooood. I smell victory. I'm starting to gloat.
> >          I am not going to have to eat toad. Tomorrow I'm
> >          expecting to capture GM Sequencing transactions
> >          and wrap it up.
> >
> >FRI 6-18: Argh... We are getting data from GM but it is
> >          garbage. Just strings of binary data. I fiddle
> >          with the configuration on the AS/400 thinking
> >          the set up isn't right. Calls to the customer
> >          to verify the serial connection parameters.
> >          The PC technician hooks up a PC and sees garbarge,
> >          too! Now I'm sure there is a set up issue on the
> >          GM side. More calls to GM. They've got their side
> >          set up for EBCDIC data. That's a new one! Weird,
> >          but we should be able to handle it. I make changes
> >          in our configuration and now we are starting
> >          to get some meaningful data, but it is chopped
> >          up. We aren't getting complete transactions. Will
> >          try again on Monday.
> >
> >MON 6-21: Fresh, ready to go at this again. We continue
> >          to receive partial records. We re-check the
> >          serial parameters with GM again. They insist
> >          8N1, 19200, Xon/Xoff. More fiddling, calls
> >          to our hardware supplier. No answers. Those
> >          who bet I would eat toad are smiling again.
> >          At the end of the day we decide to ask GM to
> >          use ASCII data instead of EBCDIC. My thought
> >          is that they might be sending control codes
> >          in the data stream that cause problems. We'll
> >          go at this again on Tuesday.
> >
> >TUE 6-22: GM switches to ASCII data. We change our
> >          configuration on the AS/400 to match. Restart
> >          the environment. We are getting data, but it
> >          is still garbage. But it is interesting garbage
> >          this time. Hex shows strings like B0B3B6. Hmmm,
> >          this looks like ASCII numbers with even parity.
> >          Or 7-bit data with a stop bit. Very curious.
> >          If you turn the high bit off of the charcters you
> >          get 303336. Real numbers! Hope is rekindled. Now I
> >          am convinced that the connection is not what
> >          we thought. More calls to GM.
> >
> >WED 6-23: Lost day for us. We get involved in a rescue
> >          for another customer. But GM reports that the
> >          serial parameters are not what they told us!
> >          This is good news! GM changes the interface and
> >          we start getting complete transactions in our
> >          log. But Nina reports that the data is not going
> >          to our inbound data queue. This should be easy
> >          to figure out. The rescue is successful, but
> >          we lose a day.
> >
> >THU 6-24: Yes, our C program is not writing the data to
> >          the queue correctly. The problem is only in our
> >          one-way receive module. Easy fix. Migrate the
> >          code and Voila! Complete sequencing transactions
> >          arrive in the file. Success! Great sigh of relief
> >          at the customer site as they have to pass a
> >          test with GM on Saturday. Nina's breathing again,
> >          too.
> >
> >If you start counting on Thursday when the software arrived and got
> >installed, it took 6 days to get everything working. One more than the 5
> >days I bet. But things are looking good and the customer is happy. We
> >all realize that we would have been up and running on Friday if the link
> >had been defined correctly. And it's been great working with Nina. Her
> >customer is lucky to have her on their team!
> >
> >What kind of sauce do you put on toad....?
> >
> >Patrick
> >--
> >IBM AS/400 communications, FTP automation, and network security
> >software and consulting services.
> >
> >http://www.patownsend.com
> >
> >Jeffrey Silberberg wrote:
> >>
> >>     Well, is it done or roast T........
> >>
> >>         JMS...
> >>
> >> +---
> >> | 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
> >+---

-- 
IBM AS/400 communications, FTP automation, and network security
software and consulting services.

http://www.patownsend.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
+---