Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!DOMINOES.UUCP!SBAILEY
From: SBAILEY@DOMINOES.UUCP.UUCP
Newsgroups: mod.computers.vax
Subject: RE: REMACP and MAXBUF
Message-ID: <8702100505.AA01665@ucbvax.Berkeley.EDU>
Date: Mon, 9-Feb-87 17:58:00 EST
Article-I.D.: ucbvax.8702100505.AA01665
Posted: Mon Feb  9 17:58:00 1987
Date-Received: Wed, 11-Feb-87 05:45:35 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23
Approved: info-vax@sri-kl.arpa

Art Stine writes:
>i thought i might as well ...
>... extend MAXBUF out past 50K. Weeelllll...
>After doing this, REMACP won't start up... it doesn't give
>any error, but just sort of never quite gets going... even
>when forced to write accounting, it doesn't terminate with any
>error, just terminates... now, i reduced MAXBUF down to 49603
>(49604 didn't work) and REMACP will start up all nice and happy...
 
Weeellll...  It turns out to be a known problem.  I was talking to DEC CSC
the other day about a marginally related problem (watch what REMACP does if
you have a RT logical defined when you try to start DECnet :-) and the
first thing they asked me was "what is MAXBUF set to?"  Apparently, "large"
values for MAXBUF cause REMACP to bomb out.  Why exactly, I don't know, but
DEC told me not to run with this parameter set higher than 8192 bytes.
 
Further research is left as an exercise for the student...
 
 
Scott Bailey                        SBAILEY%DOMINOES.UUCP@ENGVAX.UUCP
VAX Systems Manager         or try: SBAILEY.ESGSDWCO.XEROX.COM
Xerox Corp. RE/GSD/WCO       Xerox: sbailey:ES GSD/WCO:Xerox
El Segundo, CA               Phone: (213) 333-5441