ABSTINE@CLVMS.BITNET.UUCP (02/07/87)
Folks:
I am wondering if anyone might have some clues about the following:
I am running a 780 with 16M, DECnet, etc... with all this
memory, i thought i might as well take advantage of it by
expanding my non-paged pool (so that there is some 600+K free
normally) and then 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...
I haven't gone to DEC with this yet, since i thought maybe someone
has seen something like this before. Any clues?
Art Stine
Systems Programmer
Clarkson Univ.
BITNET: ABStine@CLVMSSBAILEY@DOMINOES.UUCP.UUCP (02/10/87)
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
GKN@SDSC.ARPA.UUCP (02/10/87)
From: Scott Bailey <SBAILEY@DOMINOES.UUCP> Subject: RE: REMACP and MAXBUF Date: Mon, 9 Feb 87 15:58 PDT 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. Scott Bailey Xerox Corp. RE/GSD/WCO It turns out to be a lack of page file quota. You can also exercise this problem by setting RJOBLIM to a larger number than the default (it's 32 on one of my VAXen). It was a minor pain to find because REMACP is started up /NOACCOUNTING, and it would vanish without a trace ... REMACP is sensitive to MAXBUF because at line 188 in REMINI (fiche 372 panel D15) it grabs MAXBUF, multiplies it by RJOBLIM, and uses that value to feed to $EXPREG to make buffers... A quick fix is to start REMACP up with a reasonable page file quota (the default of 8192 is pitiful). My MAXBUF is set to 32768, and I run REMACP with a paging file quota of 16384. I also took the /NOACCOUNTING switch off the run command in SYS$MANAGER:RTTLOAD so I'd have some idea why REMACP croaks if and when it does. gkn -------------------------------------- Arpa: GKN@SDSC.ARPA Bitnet: GKN@SDSC Span: SDSC::GKN (5.600) USPS: Gerard K. Newman San Diego Supercomputer Center P.O. Box 85608 San Diego, CA 92138 AT&T: 619.534.5076 -------