Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!FURILO.DEC.COM!blinn
From: blinn@FURILO.DEC.COM (Dr. Tom @ MRO3-3 pole T14, 297-5562)
Newsgroups: mod.computers.vax
Subject: Re: Solved VMS <--> TOPS-20 DECnet
Message-ID: <8608100154.AA08869@decwrl.DEC.COM>
Date: Sun, 10-Aug-86 00:48:00 EDT
Article-I.D.: decwrl.8608100154.AA08869
Posted: Sun Aug 10 00:48:00 1986
Date-Received: Sun, 10-Aug-86 11:54:59 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 15
Approved: info-vax@sri-kl.arpa

The restriction on maximum address to 255 when the remote node is a
TOPS-20 system being front-ended by a DN20 is a restriction caused by the
software in the DN20.  If you check out your generation of the DN20
software, I bet you'll find that you set that limitation (probably by
default) when you built the software.  I'm not sure you can set it any
larger than 255 at the DN20 end (but you're welcome to try).  This should
be documented.  If it's not, submit an SPR.  But don't expect the DN20
software to get changed -- just the documentation. 

Are you sure you really hadn't changed ANY software at the VAX end just
before this problem surfaced, including the DECnet parameters? 

In stating that "no software changed", it's important to remember that a
change to the parameter tables for parameter driven software (like
DECnet) is equivalent to changing the software.