🚀 go-pugleaf

> I am running layers on a 5620 with the server in another state on the
> Internet far away.  For obvious reasons, I want to use the regular
> protocol as opposed to the network protocol.  Here is the command I use
> to run layers:
> 
> alias layers='exec layers -Ddp -m 252 -f .layerc 2>>.errfile'
> 
> And, this was something I saw in the .errfile output:
> 
> 20:23:53 LAN encoding enabled
> 
> According to the manual page, the -m switch is supposed to disable the
> default network protocol and use the regular protocol.  Help?
> 
> Jack.
> -- 
> John M. Twilley             | It's only premarital sex if 
> nautilus@acm.rpi.edu        | you're going to get married.
> twilley@dewey.nusc.navy.mil |                --anonymous

You are misunderstanding the network protocol.  The 5620 does not support
the network protocol at all, only newer 730s do.

Probably what you've got turned on is the Hex encoding mode.  Look 
under Host options and turn Encoding Off.  Encoding mode can also be 
turned on with the DMDLOAD environment variable set to "hex".  Encoding
mode turns every 2 bytes into 3 bytes of data to avoid control characters.

I just posted a note to AT&T internal newsgroups that explained the network-XT
protocol a little better.  This audience might also be interested:

------------------------------------------------------------------------

> Subject: Re: A_XTPROTO and JXTPROTO
>
> 	What are the above parameters used for?  I've never seen them
> documented anywhere, but they're used in the SVR4 layers program.

They are used to turn on network-XT.  This is a mode that is used to 
the 730 over a network that already has error correction.  The 
network-XT protocol relies on the underlying network for flow control 
and error correction; it removes the sequence number and CRC checks.  

A_XTPROTO is an agent call that queries the terminal which protocol to 
use and the maximum packet size it can accept.  If the terminal 
understands the agent call (a newer 730) and it is connected to a LAN 
(TCP/IP, ISDN, or ISO) then the terminal responds that it does support 
the network-XT.  Layers than uses the JXTPROTO ioctl system call to 
tell the XT driver to use that mode. 

Whether or not network-XT is enabled, packet sizes up to 252 bytes are
utilized if the terminal supports it.  Older layers and older terminals
only supported 32 byte packet sizes.

Network-XT and the larger packet sizes are currently only supported on 
the streams-based XT driver which comes with AT&T's SVR4 (but not 
SVR4.2).  I'm hopeful that the pseudo-tty based layers will also 
support them one of these days.  

------------------------------------------------------------------------

Also, you sent me mail a week or so ago and I tried to reply but 
lachesis.acm.rpi.edu kept refusing SMTP connections.  I assume you got 
past that problem.  Here's my response anyway: 

> I wrote to comp.sys.att & comp.terminals.tty5620 in reference to my prblem.
> my machine passes all self-tests (at least there are no obvious failures.)
> but it will not run layers because it says it is not a 5620.  But, it used
> to run layers.  It just stopped one day.  Any ideas?
>
> Jack.

The "not a 5620" message usually comes because people have their parity set.
Layers (except my most recent version for suns which I haven't even
released yet) does not properly handle the 8th bit turned on when it asks
the terminal for it's id string.  Set Parity None, 8 Bits/Char in the Port
A Options.

- Dave Dykstra
  dwd@graceland.ih.att.com

In article <whn1n_r@rpi.edu> nautilus@lachesis.acm.rpi.edu (John M. Twilley) writes:
>20:23:53 LAN encoding enabled

I'm not sure about all the options to your version of "layers",
but I suspect that if the terminal itself is set up to use LAN encoding
(which has fewer information bits per octet, to avoid use of certain
"control character" bit patterns), the "layers" host program will
detect that and force LAN-encoding mode.  Check the terminal set-up.