dave@lsuc.UUCP.UUCP (06/16/86)
In article <1118@fritz.UUCP> zemon@fritz.UUCP (Art Zemon) writes: > >Seriously, folks, I've got three incoming phone lines operating >with 2400/1200/300 baud modems and a couple of dozen people >around the country calling up throughout the day. Other people >in the company have horrendous long distance phone bills. The short answer is, if you do a little work, you can make X.25 work for you. But your users will lose a bit of functionality on those lines. >Now I don't know anything much about X.25 networks (Telenet, >Compuserve, Timenet(?)), but it seems that one of these might be >the answers to my bean counters' prayers. Is this true? In Canada, we use Datapac. This machine (lsuc) presently has 12 lines connected to Datapac, and they're used regularly. The equivalent U.S. networks are GTE's Telenet, Tymnet (pronounced Timenet) and a new one I don't know much about, AutoNet. I'll confine my comments to Datapac because that's what we have here. Datapac has public dial nodes in dozens of cities across Canada. If you're set up to accept reverse-charge calls (as we are), the user need do nothing but call a local number and request (from his terminal) your X.25 address. (Gateways between Canada and the U.S. exist, by the way.) For users who will be running up a lot of connect time and/or data transmission, you can get hardwired lines which come out cheaper than using the public-dial nodes for enough usage. >And what do you use for a PAD? Should I buy one from the >network vendor? Or buy the Micom product to fit inside my Micro >600? Why is the Micom product so much less expensive than the >one that a Compuserve salesperson mentioned a couple of years >ago when I chatted with him? Dunno. We have a Micom standalone PAD (12 channels) and it's acceptable. >And why don't I know anything about any of this? This is like >trying to buy fine wine when all you've drunk all your life is >Orange Crush! It's not so fine once you try to actually use it... because of the network turnaround delays and the fact that paying for single-character packets would be hideously expensive, you have to set it up so that you only transmit a packet at the end of each line. You see, the network charges you per packet (in our case, typically 50 cents or $1 per thousand packets, plus connect time charges), and you can get up to 256 (128 in some networks) characters into a packet. The result is that you have to muck around with UNIX a bit, including turning off local echo and instructing the remote PAD (with X.29) to turn echo on and off as you need it. And you end up with a system that works reasonably well but doesn't permit full-screen editing and other cbreak-requiring programs to work. From the UNIX end, you set up the PAD to transmit a packet only when it's full or when there's a time delay of (say) 1/4 second. That way you minimize packet costs while not making response too bad for the users. We have staff in Ottawa and London, Ontario using the system every day, and students from across the province connecting to us. Once you set everything up, it works fine. If anyone wants more specifics on what you have to set up, I can dig out an article a posted a year or so back. Incidentally, our costs work out to about $3/hour (Canadian), on average. That's based on roughly 1,000 packets/hour. Dave Sherman The Law Society of Upper Canada Toronto (416) 947-3466 -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave