Detached Process Working Set Quota unexpected value?

[Mark_Corcoran]

I've been looking at duplicating functionality from one detached process to another, to replace the existing not-fit-for-purpose functionality.

With that new functionality comes some additional memory requirements, so I wanted to determine how much leeway there is between the current memory footprint of the process and the additional requirements.

[The detached processes of the application are all created by one process which specifies default values for all of the process quotas (and for some processes, specifies different values for some of the defaults).

I needed to determine whether or not the creating process might new to specify new quota values and also whether or not existing SYSGEN parameters were sufficient]

I found that for some of the parameters, the resulting process ended up with values that are "derived" from the PQL_MWS* SYSGEN parameters because the values specified during $CREPRC are smaller.

I say derived, because the values have an additional 4 pages added to them.

The SYSGEN parameter PQL_MWSQUOTA is set to 1024 and PQL_MWSEXTENT is set to 28700.

For the detached process in question, WSQUOTA and WSEXTENT are requested to be 25000.

Using F$GETJPI or SDA to show the resulting process quotas, indicates that WSQUOTA is set to 25004, and WSEXTENT is set to 28704.

Compiling the Pascal code with the /MACHINE_CODE qualifier shows that the requested values are indeed being set by the compiler.

I compared this with a process with is an executable derived solely from C source code.

Unlike the other executable which is $CREPRCed from another process, this one started up by a command procedure which creates a temporary command file then RUN /DETACH SYS$SYSTEM:LOGINOUT.EXE /INPUT=temporary_command_file /WORKING_SET=2048 /MAXIMUM_WORKING_SET=20480

The resulting process has a WSQUOTA of 20484 and a WSEXTENT of 28704.

The account under which the process runs has a WSQUO of 18000 in the UAF - I'm not sure how the 20484 value is being derived, but the WSEXTENT is clearly coming from PQL_MWSEXTENT + 4.

On the other hand, a plain-vanilla interactive process under my own account has WSQUOTA of 1024 and WSEXTENT of 28700.

In the UAF, my WSQUO is 512 and my WSEXTENT is 1024;  PQL_MWSQUOTA is 1024 (hence the WSQUOTA of 1024) and as the PQL_MWSEXTENT is 28700, hence the WSEXTENT of 28700 - not 28704.

I've never previously noticed this difference for detached processes (and it's not just our application - a quick check shows UCX processes (this is OpenVMS/VAX v6.2 under CharonVAX, with UCX v4.2 ECO 4), IPCACP, ERRFMT, OPCOM, AUDIT_SERVER, JOB_CONTROL, QUEUE_MANAGER, SECURITY_SERVER, NETACP, EVL, REMACP  all with a WSEXTENT of 28704.

Network processes (UCX$FTPC_* inbound FTP connections, SERVER_xxxx for FAL connections) and batch jobs don't have the extra 4 pages.

I can't see anything in the system services manual or the IDS book that suggests there is different behaviour for detached processes.

Is there some hitherto-unknown-to-me frig factor involved in determining the WSEXTENT and WSQUOTA for detached processes?

It's not causing a problem, I'm just curious as to the explanation.