Process Quota Assignments

[Rick Dyson]

I seem to recall that depending on the type of process (i.e., INTERACTIVE, DETACHED, SUBPROCESS, etc.) created that different rules apply as to what System Process Quotas are assigned to the process. That is, the UAF values for the USERNAME that the process is running under are not always used. I believe that when the UAF values are not used, the PQL_* values are used.

I am trying to locate documentation on that but can't seem to locate where I read it in the past.

Interactive seems to use UAF, but Detatched and/or Subprocesses seem to NOT use the UAF values.

My emperical testing seems to indicate that the PQL_M* values are being assigned to my processes in question even though I would have assumed it would have been the PQL_D* values. (Default vs. Minimum).

Anyone out there know the answer or where to look?

Thanks,
Rick

[Willem Grooters]

IIRC, Detached processes use the PQL_ parameters.
Subprocess quota are partly shared with it's main process, some are taken from SYSUAF (if not DETACHED). That means that a subprocess will have the quota as in SYSUAF or SYSGEN, minus the quota already used by the main program.

I guess this is covered in the System managers manual, or in the performance guide (or both)

Willem

[Rick Dyson]

So, I suspect the proper way to get the Detatched ones setup is to use qualifiers to set the values when it is run...

However, it is a vendor app that I am trying to tune and I am not sure I can... They appear to be all callable API from their one or two EXEs.

Ah, but WHERE in those manuals... :) I spent a couple hours this morning looking and trying to search this ITRC site for simialr topics with no luck so far...

Thanks! Good to hear some confirmation on the detached. That was my working view, too.

[John Gillings · Accepted solution]

Rick,

The rules really are the same for all processes, but in practice it doesn't always look that way. Here's how it works.

ALL processes come down to a call to $CREPRC. If you want to fully understand how quotas work, read the System Services Reference Manual entry for $CREPRC.

A quick description... The "Quota" parameter to $CREPRC is a structure called a PQL (Process Quota List). This is a self describing structure which contains tagged values describing quotas.

[aside - since it's an array of 5 byte objects (yes, FIVE!) if you're writing code that called $CREPRC, make absolutely certain you've got the alignment right! Most compilers will "helpfully" realign the fields and cause you processes to get very odd sets of quotas!]

Since the PQL is self describing, it can be incomplete. So, the first thing $CREPRC does is populate a complete PQL. Any items not found in the supplied PQL are filled in from the PQL_D* SYSGEN parameters.

Next step is the resulting PQL is maximised against the PQL_M* values (ie: any resulting quota value less than the corresponding PQL_M* parameter is raised to the minimum value).

Now that you have that background, the behaviour of different process types becomes much simpler to understand...

For any process created using the UAF (Interactive, Batch, Network), a PQL is provided from the UAF entry. Have a look at a UAF record, and you'll find a complete PQL embedded in it. The code just points the quota argument to the start of the PQL in the UAF record buffer! Since the PQL is always fully populated, the PQL_D* parameters never get involved for this type of process.

A process started with RUN has a PQL constructed from the quota qualifiers. So, any that are missing will be filled in from PQL_D* values. (and then maximised with PQL_M*).

Subprocesses are a bit more complex, since they're constrained by quotas of the parent. There is also the issue of pooled and deductible quotas, see $CREPRC for more detail.

Some recommendations:

If you start a detached process with the RUN command, always use a COMPLETE set of quotas. Cut and paste a command from any of the procedures in SYS$STARTUP that start processes. That way there are no surprises when you move the program to another node. (I've seen so many cases where detached processes were invisibly dependent on site specific PQL_D* values, and failed when moved to another node. Can be very tricky to diagnose!)

Be careful with PQL_M* parameters, remember that it's a MINIMUM value for ALL processes.

If you're having trouble with detached processes, try using a BATCH job.

Write some procedures that just dump out SHOW PROCESS/QUOTA or F$GETJPI values and experiment to make sure you understand where your quotas are coming from.

[Wim Van den Wyngaert]

You can decrease the working set quotas with "set work". And as long as the process is not stuck, you can in/de-crease them with AMDS. May be there is a tools on the internet to change them on the command prompt too.

Wim

[Ian Miller.]

"May be there is a tools on the internet to change them on the command prompt too."
- there is this (but for old versions of VAX/VMS only)
http://vms.process.com/scripts/fileserv/fileserv.com?ESET

AMDS is what I use currently for changing process quotas.

[Rick Dyson]

More than enough to keep me learning!