Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.unix.ultrix
Subject: Re: SLIP over a DECserver and LAT from ULTRIX
Keywords: ultrix,slip,decserver,lat
Message-ID: <6467@cbmvax.UUCP>
Date: 31 Mar 89 01:00:00 GMT
References: <88360@felix.UUCP> <6425@cbmvax.UUCP> <1400@blake.acs.washington.edu>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 29

In article <1400@blake.acs.washington.edu> mtsu@blake.acs.washington.edu (Montana State) writes:
> 
> Are the IOCTL()'s that allow you to make a connection to a remote LAT port
> documented anywhere??  Obviously lpd uses them, but I don't see any 
> how-to's anywhere.

NO!  This is the big gripe, that DEC has chosen not to document or provide
access to the same facilities that sytem programs like lcp and lpd use,
limiting your ability to upgrade/replace these programs with ones that
you feel to be better in some way.

As of 3.0, there is at least a new feature in lcp that allows you to
attach a server/port specification to a LAT pseudo terminal so that
when you open the terminal in the "normal" fashion, LAT will initiate
the reverse-LAT link.  While still not providing the interface apparently
used by lpd, this does seem to proivde the support needed for most
reverse-LAT connections, i.e. printers, slave terminals or (hopefully)
uucp connections.

I haven't gotten around to installing 3.0 yet, so I don't know how well
this works.  I'm also hot to try the LAT/telnet gateway program, since
since this will reduce the pain of being stuck with DECServers in an
environment where we keep adding more and more non-DEC, TCP only
network hosts.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)