🚀 go-pugleaf

In article <01GRDFI4HY2A8WVZBS@MONMOUTH-etdl1.Army.MIL>, "Brian J. Schenkenberger, VAXman" writes:
>>Under VMS 5.5-2 the maximum value for wsmax is 400000 pages.
>>[...]
>>he can't have more than 400000 pages im memory.
>>
>>I'm sure some higher Version of VMS will raise this limit eventually,
>>but 400000 seems a rather arbitrary value, so i guess this could be
>>increased somehow.
>>
>>Has anybody done this ?
>>Any ideas / pointers how to do it ?
>
> I've never done this but... I can offer you a quick method to change
> the value.
>
> The value for WSMAX is stored at the symbolic address SGN$GL_MAXWSCNT.
> You can change this value WHILE THE SYSTEM IS RUNNING with DELTA.  How?
> Lookup the address of SGN$GL_MAXWSCNT in SYS.MAP.  Then, enter DELTA.
>
> $ RUN SYS$SHARE:DELTA
> 1:m <cr>
> 00000001 <cr>
> 00010001:<address of SGN$GL_MAXWSCNT>/<return-curr-value> <your-new-value>
> EXIT                                                       (hex of course)
> $
>
>>Caveats ? :-)
>
> This above will change the value.  Its implications if you increase it
> above the current limits? I know not!  I just LOWERed my system's WSMAX
> by 16 with the above and have had no problems.
>
> If you have a system you can crash... try it out and let us know.

Certainly an interesting technique, but I'm real sure that making things bigger
this way is certainly going to crash the system.  Off the top of my head I'm
not sure where this number is used to allocate parts of several significant
process data structures.  If this number were variable it would be a dynamic
sysgen parameter.

A possible approach to running with a larger value is:

Boot the system conversationally:

	>>> B/R5:1


Now disable Value range checking and select a larger value:

	SYSBOOT> DISABLE CHECKS
	SYSBOOT> SET WSMAX 524287
	SYSBOOT> EXIT

I did this once to exceed the maximum numbers for SRPCOUNT and SRPCOUNTV.

Note: I've chosen the above number (524287) since it definately is
representable in the same number of bits as the current max of 400000.
Going to larger values may affect other data structures which I can't
remember offhand.

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com