🚀 go-pugleaf

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