Quotas: PQL_* versus AUTHORIZE

[Jack Trachtman]

A little education please:

Interactive/Batch/Network processes use the Quota/Limit settings in AUTHORIZE. CRE$PROC and "RUN" processes use either explicit or PQL_* quotas/limits.

Why don't all processes use the AUTHORIZE values? Why was VMS designed to support a non-AUTHORIZE quota/limit assignment method?

TIA

[Jess Goodman]

The PQL_M* system parameters are MINIMUM values. They are used if the SYSUAF values are smaller. This allows you to install an application that, for example, needs higher TQELM quotas without having to use Authorize and modify the SYSUAF account of each account that will be using the application.

The MIN values also allow you to raise everybody's quotas when they are logging in to a bigger, faster node you have added to the cluster and sill use the smaller SYSUAF values when users log into older, amaller nodes (without having to maintain multiple SYSUAFs).

The PQL_D* system parameters are DEFAULT values and they only apply to processes that are created without reading SYSUAF. They applies to many processes started at boot time and any processes created with the RUN command using either /DETACHED or /UIC= without /AUTHORIZE.

This is useful if you want to specify a few specific quotas that a application needs on the RUN command line and use system defaults for the rest. Processes RUN this way have less start-up overhead.

Constant SYSUAF access from process creation can be a big resource contention issue in some clusters.

Note that if the /AUTHORIZE qualifer is used with RUN then all the process quotas are read from SYSUAF and any quotas specified on the RUN command line are ignored.

[John Gillings]

Jack,

As with most OpenVMS things, there is a cascade of default values, generally ordered from specific to general.

All processes are ultimately created through the $CREPRC service. One of the parameters is a rather ugly data structure called a PQL (Process Quota List). It's a self describing, null terminated list of tag+value for each of the process quotas. Thus the PQL passed to $CREPRC may be incomplete (or even null).

Notionally, $CREPRC scans the PQL passed to it. Any "holes" are filled in from SYSGEN PQL_D* (D for DEFAULT) parameters, resulting in a complete PQL. Each entry is then compared against the corresponding PQL_M* (M for MINIMUM) parameter, low values are increased to the minimum. The result is the list of quotas which the process will be created with. (There's a bit more logic involved, comparing resulting quotas against process limits, but that's a different story).

Thus, a program which explicitly calls $CREPRC can choose to specify a PQL or not, thereby accepting the default or minimum system wide defaults. The RUN process DCL commands builds the PQL from qualifiers, so any missing qualifier will default the SYSGEN PQL_D*'s. Note that the creating process' quotas are NOT involved!

One part of the UAF record is a fully populated PQL. When a process is created through the UAF (network, batch, interactive) the UAF PQL is passed to $CREPRC. So, when a UAF process is created, PQL_D* parameters are not used, but the PQL_M*'s still apply, possibly boosting the UAF value to the system wide minimum.

So, if you want to enforce UAF quotas, set all your PQL_M*'s to 0 (I'm not necessarily recommending that, but you could choose to do so).

On the other hand, it's very handy to be able to set (say) PQL_MSEXTENT = WSMAX to eliminate the now largely unnecessary limiting of working set extents per user or process. For several other quotas, it may make more sense to impose a single system wide value, rather than trying to work out an appropriate value for each user - for example PGFLQUOTA.

This becomes especially useful in a cluster with a shared UAF and multiple nodes of differing sizes and resource availability. UAF quotas can be set appropriate to the smallest node, with PQL_M*'s used to increase quotas on the larger systems.

Does this help you make sense of the method of the madness in OpenVMS design?

[Wim Van den Wyngaert]

Some notes for starting processes with loginout.exe.

1) If you run a process detached, it's actualy running under the user that started it (did the run), even if you specify /uic=WIM and this is the UIC of user WIM (and could also be of user MARC that has the same uic but different quotas).

2) if you specify /auth, /uic is ignored (without message)

3) /detach means /uic=current_user_uic and /uic and /quotas are ignored

4) /auth is only valid if /detach is specified

This all to say that you must verify what you exactly received in all cases. IMO this could have been implemented a lot cleaner.

Wim

[Jack Trachtman]

thanks all for the clarification - insight into inner workings is always useful.

But - I feel that my major question hasn't been answered explicitly:

"Why don't all processes *always* use the AUTHORIZE values (in SYSUAF.DAT), but with possible overrides?"

[John Gillings · Accepted solution]

Jack,

>Why don't all processes *always* use the
>AUTHORIZE values (in SYSUAF.DAT), but with
>possible overrides?"

Sorry, I thought I answered exactly that question! OK, I'll try again.

Not all processes are started through the UAF. Any process started via a direct $CREPRC or the RUN process command bypasses the UAF (though you can use /AUTHORIZE to request the UAF be used). See documentation for $CREPRC. Also consider that there are processes which are started early in STARTUP before the UAF is available, even before a filesystem exists.

Note that the provision of a UIC does not uniquely determine a UAF entry. There can be multiple usernames sharing the same UIC (though it's not recommended). There is no option to specify a username to $CREPRC.

So, there are entire classes of processes where the UAF isn't involved or even considered at process creation time. Why was OpenVMS designed that way? There may be an answer in some historic design notes, but if they exist, they're no longer relevant. That's just the way OpenVMS was implemented. This late in the game, don't expect anyone to rush out and change it! To policy of upwards compatibility would prevent it from being considered anyway.

Think of the UAF as a store for a "canned" description of process that MAY be used to start a process. It also contains information to authenticate a user, BUT it's not REQUIRED to start a process.

Perhaps you're thinking you say to OpenVMS "Create me a process", which results in the OS looking in the UAF to figure out how. In fact it's the exact opposite. You can say to OpenVMS "Log me into an interactive process". The OS looks in the UAF to authenticate you, and then says "$CREPRC, make a process that looks like this UAF record describes".

Splitting up the considerations of creating a process from authentication and quota management makes the process object more flexible. Processes may be "heavyweight" with a CLI and all the extra baggage that goes with an interactive process, or they can be a "naked" detached process running an image directly. I can start a process with precisely the quotas and privileges I want, without having to create a UAF entry for that specific purpose. We can also implement mechanisms like quota & UAF overrides on batch queues (ie: read UAF, read queue specification and derive the properties to pass to $CREPRC). On the other hand, I need to understand the mechanics of creating processes and how the quotas are determined in order to make sure that all processes receive the quotas they need.

If OpenVMS were being designed today, I suspect the UAF would be a more complex (and cleaner!) data structure. There would probably be a heirarchy of quota value defaults. For each user we could probably define a value per cluster, per node and per process mode (note that LDAP directories can do exactly that!) might also see a different set of quotas, and different units, as the resource concerns have changed considerably over the past few decades. But, I'd still expect a similar model for process creation in terms of propagation of quotas. We could still obtain the PQL profile from the UAF, or specify them at the time the process is created.

[John Gillings]

Jack,
On the other hand, I could just hit you with the universal parent type answer...

Why? BECAUSE!

Live with it! ;-)

[Jack Trachtman]

John,

Extreme thanks for taking the time to create such a long response - I know how time consuming that can be!

From all of the responses, I'm much clearer about the options in process creations, but I think John's final reply is the one I'll just "live with"!