🚀 go-pugleaf

    We have just moved from an old VAX 11/780 (with 4 Megabytes of old main
    memory) to a VAX 8500 (with 16 Megabytes of main memory)....  [W]e [would]
    like to increase some of the SYSUAF-parameters, so users may profit....
    
    We usually have 30 - 35 simultaneous users (in our university environment
    editing, compiling FORTRAN, linking, running Fortran programs, TeX and
    LEX =another text processing software, Kermit)
    
    Here follows our current entry of DEFAULT in SYSUAF :
    
       Username: DEFAULT                          Owner:
    
       Maxjobs:         0  Fillm:        20  Bytlm:        25000
       Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
       Maxdetach:       0  BIOlm:        18  JTquota:       1024
       Prclm:           2  DIOlm:        18  WSdef:          250
       Prio:            4  ASTlm:        24  WSquo:          500
       Queprio:         0  TQElm:        10  WSextent:      1000
       CPU:    0 00:30:00  Enqlm:        30  Pgflquo:      10000

Most of your limits are not at all unreasonable.  I would suggest only a
couple of changes:

	Prclm:	Increase considerably; I run with 10.  This will NOT result
		in any massive increase in the number of processes on your
		system since most of the important quotas are pooled among
		all subprocesses of a job, so will provide a limit when
		significant real resources become scarce.  A limit of 2 is
		annoying since it doesn't let you run easily with a "kept
		editor" - you need room for a "spare" subprocess for things
		like quicky SPAWN's out of MAIL or debugging process dumps.

	Fillm:	I run with a limit of 30, but now that I think of it I may
		raise that.  This quota in and of itself is very cheap; any
		attempt to abuse it will quickly result in the abuser running
		out of BIO quota or other "real" stuff.

	WSxxx:	These are the obvious ones to change.  I'd certainly increase
		WSquo - what you have now is more or less the result of making
		a "worst case" estimate:  35 users, 16 meg of memory, divide
		and let each get 1/2 meg.  But in fact if you really get all
		35 users actually DOING anything at once your system will
		slow to a crawl.  I'd try something on the order 1024 for
		WSQuo.  (Why 1024 rather than 1000?  I don't know, a habit
		I've picked up from others around me; makes it easier to
		convert from pages to meg, actually.  But then try and explain
		why typical values for Bytlm are things like 10240.)

		WSExtent is pretty cheap - you might as well let people make
		full use of all that memory at times the system is lightly
		loaded.  I'd increase that substantially - to perhaps 4-5000.
		(Note that this make make little real difference for your job
		mix.  For certain kinds of usage - particularly those that
		often move back and forth from only one or two jobs doing
		anything to a whole load wanting memory - it may slow down
		responsiveness a bit.)

		WSDef could be increased a bit, but I doubt it would make any
		difference you'd see.

Make sure your SYSGEN parameters are appropriate for the amount for memory you
have.  In particular, try to have enough process slots (BALSETCNT) to avoid
swapping during all but peak loads.  (A value of about 70-80 should do it,
less (50?) if people never use kept editors.)
							-- Jerry
-------