NEIL@KSUVM.BITNET (Neil Erdwien) (04/06/88)
Has anyone considered making SLIP work on an IBM system? In particular, most IBM systems will only handle 7-bit ASCII. When I last looked at SLIP it assumed an 8-bit channel. IBM reads must be terminated by a carriage return also. There might also be full/half duplex compatibility problems. Neil Erdwien Kansas State University
Mills@UDEL.EDU (04/06/88)
Neil, Ouch. I can't believe "most" IBM systems are that bad. Twenty years ago (really) I designed this fool thing called the Data Concentrator, which used a PDP8 (!) and interfaced directly to a System/360-67 Multiplexor Channel. We had a lot of fun at U Michigan hooking the thing up to a wonderful brew of hokey terminals, which were the smallest thing just larger than a Turing Machine that was potentially useful. While the PDP8 system was retired only a few years ago, its successors are yet clanking away at Michigan, where that crew has gotten rather good at making the things. My point is that maybe you should be looking beyond IBM and, furthermore, lots of other good souls have beaten the dumb-ASCII curse with that approach. It was once worse. You had to end the line with <CR><LF><XOFF>. Dave
bzs@BU-CS.BU.EDU (Barry Shein) (04/06/88)
>Has anyone considered making SLIP work on an IBM system? In particular, >most IBM systems will only handle 7-bit ASCII. When I last looked at >SLIP it assumed an 8-bit channel. IBM reads must be terminated by a >carriage return also. There might also be full/half duplex >compatibility problems. > >Neil Erdwien >Kansas State University Gee, took a minute to figure out if this was referring to a PC or what. My guess is you're referring to a 370 architecture mainframe running a line to a 3705 or equivalent. I've never done SLIP but I did write a serial link of my own design once a few years ago between a 4.2 Unix (probably 4.1 back then) system here and a 3705 which transferred jobs for printing or batch execution. Basically I found the only way to deal with the 3705 was to write a layer which passed the packets as discrete ascii lines of text (I just translated to hex ascii, prepending each line with a checksum and byte count) and lock-stepped out the packets (send/ack/send/ack etc., just like a card reader.) The half-duplex nature of the interface presents some interesting problems. Actually, it's more like quarter-duplex, it won't even listen unless it wants to (you have to lock-step on a prompt from it, usually a dot in column one.) If you talk before it's expecting you to it throws away the characters and then demands a carraige return to assure it you won't do that again (at which point you are free to start the error cycle all over again.) It's not ideal (hah!) but it can be done, once I got it working it worked pretty much unnoticed, but there were a lot of heuristics in there (did we just get a "!:" oops, it's angry! send a <CR> and back off for a bit waiting for a "<CR><LF>."). You also might want to see if there's a mode buried in there that was used for downloading from a KSR33 paper tape which did flow control (used ^S/^Q to express it's distaste for your data.) Or get a network interface... -Barry Shein, Boston University
CSYSMAS@OAC.UCLA.EDU (Michael Stein) (04/06/88)
> >Has anyone considered making SLIP work on an IBM system? In particular, > >most IBM systems will only handle 7-bit ASCII. When I last looked at > >SLIP it assumed an 8-bit channel. IBM reads must be terminated by a > >carriage return also. There might also be full/half duplex > >compatibility problems. Likely the "near future" best way to do this is to run SLIP to a PC which sits on a local LAN. (Who's using your PC when your not there?)