OpenVMS System Manager's Manual

Updated: 11 December 1998

OpenVMS System Manager's Manual

Contents

Index

6.9.3 Understanding Network Proxy Accounts

A network proxy account allows users on a remote node in a network to access data by way of a local account on your system. Proxy accounts are useful when you want to grant one or more users on a remote node access to specific files, but you do not want to give them a private account on your system. Very often, system managers set up proxy accounts as restricted. You establish and control proxy accounts with the Authorize utility (AUTHORIZE).

With proxy accounts, you can authorize one or more users on a remote node to enter DCL commands that access data from a particular account on your system. Proxy accounts allow remote users to access specific local data (for example, type and print files) without having to log in to your system or use an access control string. Remote users assume the same file access rights as the local account and also receive the default privileges of the local account. The following sections explain the procedures for setting up proxy accounts.

To properly maintain proxy database consistency across all members of a mixed-version OpenVMS Cluster system, you must perform all proxy modifications from either of the following systems:

A VAX Version 6.1 (or later) system
An Alpha Version 6.2 (or later) system

This restriction ensures that the NET$PROXY.DAT database is updated with correct proxy information.

For more information about proxy accounts, see the OpenVMS Guide to System Security.

6.9.4 Creating Network Proxy Authorization Files

A proxy account permits an authorized user from a remote node to log in to a local node, as if the user owned an account on the local node. Proxy accounts are created and maintained using the Authorize utility (AUTHORIZE). See the OpenVMS System Management Utilities Reference Manual for more information about the Authorize utility.

On OpenVMS systems, the following information is stored in two proxy authorization files, NETPROXY.DAT and NET$PROXY.DAT:

On systems running DECnet for OpenVMS, both NETPROXY.DAT and NET$PROXY.DAT contain proxy information stored using DECnet VAX node names.

On systems running DECnet-Plus:

NET$PROXY.DAT contains proxy information stored using DECnet-Plus full names.
NETPROXY.DAT contains proxy information stored using DECnet-Plus node synonyms.

Note

Deleting either NETPROXY.DAT or NET$PROXY.DAT will result in incorrect functioning of proxy access on systems running DECnet for OpenVMS Phase IV. Also, many applications such as ALL-IN-1 rely on NETPROXY.DAT.

The SYSUAF.DAT file, on your local system, must associate proxy accounts with user accounts. You will probably want to create a "standard access" account in the UAF for proxy accounts. For example, you could create an account named REMOTE_MKT with limited privileges, which allows access to certain data files on your local system.

Suppose you have a group of users on your local system who prepare marketing reports and who rely on input from users on other systems. You would assign the REMOTE_MKT account in SYSUAF.DAT the same group number and default privileges you assign to the local marketing group. In this way, the remote contributors could access any data files that are "owned" by users in your marketing group and that are not protected from group access.

How to Perform This Task

Use the AUTHORIZE command CREATE/PROXY to create and initialize network proxy authorization files:

UAF> CREATE/PROXY

6.9.5 Adding Proxy Accounts

Create a proxy account by adding entries to the network proxy authorization file; these entries equate one or more users on a remote node to users on your home node.

How to Perform This Task

The command syntax for adding a proxy account is as follows:

ADD/PROXY node::remote-user local-user/DEFAULT [,...]

You can allow remote users access to up to 16 total local accounts: 1 default proxy account and 15 alternate proxy accounts. Use the /DEFAULT qualifier to specify the default proxy account.

Examples

The following command adds a user proxy account:

UAF> ADD/PROXY HAL::WALTER REMOTE_MKT/DEFAULT,PROXY2,PROXY3

Assume that you have created three accounts named REMOTE_MKT, PROXY2, and PROXY3 on your home node. The entry in this example permits the user WALTER on remote node HAL to access data by way of the REMOTE_MKT account on your home node. WALTER can access any data from his node that REMOTE_MKT can access locally. To access data through either PROXY2 or PROXY3, WALTER must specify the desired proxy account in the access control string of the DCL command used to perform network file operations.

Caution

Because the remote user receives the same privileges as the local user, do not set up proxy accounts associated with local accounts that have special privilege. Granting remote users such access powers poses a threat to the security of your system.

You can specify remote users by user name or, for remote systems that do not recognize the user name syntax, by UIC. The following example allows the user associated with the UIC [360,54] on remote node RSTS32 proxy access to the GENERIC account on the local node:
UAF> ADD/PROXY RSTS32::[360,54] GENERIC/DEFAULT
A number of your users might have accounts on a remote node and require ready access to their local files. You can create a network proxy authorization file record that grants access to each of them, provided the user name on your system is the same as the user name on the remote node. The following form of the ADD/PROXY command adds such a record:
UAF> ADD/PROXY HAL::* */DEFAULT
This command authorizes any user on the remote node HAL to access any account with the same user name on your system.
Similarly, you might want to permit this sort of access for just one user:
UAF> ADD/PROXY HAL::BARBARA */DEFAULT

On systems running DECnet-Plus, the system adds network proxies to the network proxy authorization file NET$PROXY.DAT using DECnet-Plus full names. For example:

UAF> ADD/PROXY RUBY::DELAPORT DELAPORT/DEFAULT,SYSTEM %UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to DELAPORT added %UAF-I-NAFADDMSG, proxy from OMNI:.US.RUBY::DELAPORT to SYSTEM added

This example adds proxy access from RUBY::DELAPORT to the local accounts DELAPORT (the default) and SYSTEM.
The system additionally stores node synonyms in NETPROXY.DAT for use by DECnet for OpenVMS and for backward compatibility for layered products.

6.9.6 Removing Proxy Accounts

To remove proxy accounts, use the AUTHORIZE command REMOVE/PROXY; for example:

UAF> REMOVE/PROXY RUBY::DELAPORT SYSTEM

This command removes proxy access from RUBY::DELAPORT to the local SYSTEM account.

6.9.7 Displaying Proxy Accounts

To display proxy accounts, use the AUTHORIZE command SHOW/PROXY. This command displays only the first 255 characters of the node name, although the command can handle a maximum of 1024 characters.

The following examples assume that proxy access from RUBY::DELAPORT to the local account DELAPORT has been added to the network proxy authorization file as the default. (The second example shows the DECnet-Plus equivalent of RUBY::DELAPORT.)

Examples

On systems running DECnet for OpenVMS, the system displays the following type of information:
UAF> SHOW/PROXY *::*
RUBY::DELAPORT DELAPORT (D)
(D) indicates that DELAPORT is the default proxy.
On systems running DECnet-Plus, the system displays information in full names format:
UAF> SHOW/PROXY *::*
OMNI:.US.RUBY::DELAPORT DELAPORT (D)
(D) indicates that DELAPORT is the default proxy.
You can display information in the old format NETPROXY.DAT database by using the /OLD qualifier with the SHOW/PROXY command; for example:
UAF> SHOW/PROXY/OLD *::*

6.9.8 Controlling Proxy Logins

Whenever a proxy login request occurs, the system verifies that proxy access on the participating nodes is enabled. (By default, both incoming and outgoing proxy access is enabled for each node.)

On systems running DECnet for OpenVMS, you can change proxy access or disable it totally by using the Network Control Program (NCP). The DECnet for OpenVMS Networking Manual describes how to use NCP to control proxy access.

On systems running DECnet-Plus software, you can change proxy access by using the Network Control Language utility (NCL). The DECnet-Plus Network Control Language Reference manual describes how to use NCL.

6.10 Managing Mail

When managing user accounts, you might have to manage a user's mail account. For example, you may want to perform the following tasks:

Change a user's mail profile; for example, change a user name or specify a default print queue for the account
Set a forwarding address for a user who has moved to another location
Disable a user's account from receiving mail
Customize a user's mail environment by setting flags in a user's UAF record

The following sections explain how to perform all of these tasks.

6.10.1 Modifying a User Record

All users can modify and display information about their own records using various SET and SHOW commands available within Mail. These commands access SYS$SYSTEM:VMSMAIL_PROFILE.DATA, which is a single-key indexed sequential file containing information for each user.

With SYSPRV, you can modify the records of other users. Table 6-7 lists the fields in the user profile record and the MAIL command you can use to modify those fields.

Table 6-7 Mail User Profile Record
Field Command

Username --------

Forwarding address SET FORWARD

Personal name SET PERSONAL_NAME

Editor name SET EDITOR

Copy SEND/REPLY flags SET COPY_SELF

Autopurge flag SET AUTO_PURGE

Mail file subdirectory name SET MAIL_DIRECTORY

New mail count READ/NEW

Default queue SET QUEUE

Default form SET FORM

Carbon copy enabled SET CC_PROMPT

**Table 6-7 Mail User Profile Record**
Field	Command
Username	--------
Forwarding address	SET FORWARD
Personal name	SET PERSONAL_NAME
Editor name	SET EDITOR
Copy SEND/REPLY flags	SET COPY_SELF
Autopurge flag	SET AUTO_PURGE
Mail file subdirectory name	SET MAIL_DIRECTORY
New mail count	READ/NEW
Default queue	SET QUEUE
Default form	SET FORM
Carbon copy enabled	SET CC_PROMPT

You can arrange mail forwarding for users without accounts on the system by using the command SET FORWARD/USER=user.

6.10.2 Removing a User Record

Typically, once you have deleted a user's record in the UAF, you will also want to remove that user's information from the user profile database. You can remove a record from the user profile database with the REMOVE command.

6.10.3 AUTHORIZE Flags and Mail

Certain flags set in a user's UAF record can affect the user's Mail environment. You can set the appropriate flags in a user account by specifying the following flags with the /FLAGS qualifiers using AUTHORIZE:

Flag Meaning

[NO]DISNEWMAIL Enables or disables the display of the new mail count when the user logs in to the system.

[NO]DISMAIL Allows or restricts the receipt of new mail.

Flag	Meaning
[NO]DISNEWMAIL	Enables or disables the display of the new mail count when the user logs in to the system.
[NO]DISMAIL	Allows or restricts the receipt of new mail.

6.11 Managing System Resources

This section contains detailed descriptions of the resource control attributes you can assign to a user process when creating a record in the UAF.

6.11.1 Understanding Pages and Pagelets

VAX and Alpha systems allocate and deallocate memory for processes in units called pages. A page on a VAX system is 512 bytes. On Alpha systems, the page size will be one of four values: 8KB (8192 bytes), 16KB, 32KB, or 64KB. A particular Alpha system will implement only one of the four page sizes and the initial set of machines use an 8KB page.

In most cases, Alpha systems present to users, and accept from users, units of memory in a 512-byte quantity called a pagelet. Thus, one pagelet is the same size as one VAX page. Also, on an Alpha 8KB computer, 16 pagelets equal 1 Alpha page. The following conversion table shows the relationship between pages, pagelets, and bytes:

One Alpha pagelet = one VAX page = 512 bytes One Alpha page = 16 Alpha pagelets = 16 VAX pages = 8192 bytes

Authorize utility commands, parameters, and default values are identical. However, the default values for process quotas related to memory use might be inappropriate for some Alpha system users.

See A Comparison of System Management on OpenVMS AXP and OpenVMS VAX for more information about Alpha system management. (This manual has been archived but is available in PostScript and DECW$BOOK (Bookreader) formats on the OpenVMS Documentation CD-ROM. A printed book can be ordered through DECdirect (800-354-4825).)

6.11.2 Setting Limits on System Resources

Each system user is limited in the consumption of such resources as system memory, volatile (pagefile) disk space, number of processes, and I/O requests. You set limits when you create an account for the user with the Authorize utility.

Limits control the way in which a process shares its allotment of a resource with the subprocesses it creates. In addition to restricting the number of processes that a single user or account has at any given time, the system uses four types of limits for sharing resources. Table 6-1 describes these limits.

When you create an account, you assign values to the limits shown in Table 6-8. These limits are described in the following sections. Usually, you simply assign the default values for these limits. However, see the OpenVMS Performance Management for a discussion of how to evaluate and adjust the limits in the context of performance optimization strategies.

Table 6-8 summarizes each of these limits, the value supplied in the UAF record for the SYSTEM and DEFAULT accounts, and the type of limit.

Table 6-8 Limits and Suggested Values for SYSTEM and DEFAULT Accounts
Limit VAX SYSTEM Value VAX DEFAULT Value Alpha SYSTEM Value Alpha DEFAULT Value Type¹ Description

ASTlm 50 0 250 250 N AST queue limit

BIOlm 40 40 150 150 N Buffered I/O count limit

Bytlm 32768 32768 64000 64000 P Buffered I/O byte count limit

CPU 0 0 0 0 D CPU time limit (0 = no limit)

DIOlm 40 40 150 150 N Direct I/O count limit

Enqlm 300 200 2000 2000 P Enqueue quota

Fillm 300 300 100 100 P Open file limit

JTquota 4096 4096 4096 4096 P Initial byte quota for jobwide logical name table

Maxacctjobs 0 0 0 0 S Maximum active processes for a single account (0 = no limit)

Maxdetach 0 0 0 0 S Maximum detached processes for a single user name (0 = no limit)

Maxjobs 0 0 0 0 S Maximum active processes for a single user name (0 = no limit)

Pgflquo 20480 pages 32768 pages 50000 pagelets 50000 pagelets P Page file limit

Prclm 10 2 10 8 P Subprocess creation limit

TQElm 30 40 20 10 P Timer queue entry limit

WSdef ² 256 pages 256 pages 2000 pagelets 2000 pagelets N Default working set size

WSextent ² 40960 pages 1024 pages 16384 pagelets 16384 pagelets N Working set extent

WSquo ² 512 pages 512 pages 4000 pagelets 4000 pagelets N Working set quota

**Table 6-8 Limits and Suggested Values for SYSTEM and DEFAULT Accounts**
Limit	VAX SYSTEM Value	VAX DEFAULT Value	Alpha SYSTEM Value	Alpha DEFAULT Value	Type¹	Description
ASTlm	50	0	250	250	N	AST queue limit
BIOlm	40	40	150	150	N	Buffered I/O count limit
Bytlm	32768	32768	64000	64000	P	Buffered I/O byte count limit
CPU	0	0	0	0	D	CPU time limit (0 = no limit)
DIOlm	40	40	150	150	N	Direct I/O count limit
Enqlm	300	200	2000	2000	P	Enqueue quota
Fillm	300	300	100	100	P	Open file limit
JTquota	4096	4096	4096	4096	P	Initial byte quota for jobwide logical name table
Maxacctjobs	0	0	0	0	S	Maximum active processes for a single account (0 = no limit)
Maxdetach	0	0	0	0	S	Maximum detached processes for a single user name (0 = no limit)
Maxjobs	0	0	0	0	S	Maximum active processes for a single user name (0 = no limit)
Pgflquo	20480 pages	32768 pages	50000 pagelets	50000 pagelets	P	Page file limit
Prclm	10	2	10	8	P	Subprocess creation limit
TQElm	30	40	20	10	P	Timer queue entry limit
WSdef ²	256 pages	256 pages	2000 pagelets	2000 pagelets	N	Default working set size
WSextent ²	40960 pages	1024 pages	16384 pagelets	16384 pagelets	N	Working set extent
WSquo ²	512 pages	512 pages	4000 pagelets	4000 pagelets	N	Working set quota

¹D=deductible, N=nondeductible, P=pooled, S=systemwide
²For this limit, LOGINOUT uses the larger value of the AUTHORIZE quota for this account or the corresponding system parameter PQL_MWSDEF, PQL_MWSEXTENT, or PQL_MWSQUO.

Table 6-9 shows the names and descriptions of the SYSTEM and DEFAULT accounts whose values are listed in Table 6-8. The /EXPIRATION qualifier is also described in Table 6-9.

Table 6-9 Descriptions of SYSTEM and DEFAULT Accounts
Account Description

AST Queue Limit (ASTlm) Limits the sum of the following amounts:

The number of asynchronous system trap (AST) requests that a user's process can have outstanding at one time
The number of scheduled wakeup requests that a user's process can have outstanding at one time

This limit affects all system services that accept an AST address as an argument, and the Schedule Wakeup ($SCHDWK) system service.
If the deferred write option (DFW) is enabled, the number of ASTs used per file is equal to 1, plus the number of record streams, plus the multibuffer count. Otherwise, the number is 1 plus the number of record streams.

Buffered I/O Count Limit (BIOlm) Limits the number of outstanding buffered I/O operations permitted for a user's process.
In a buffered I/O operation, the data transfer takes place from an intermediate buffer in the system pool, not from a process-specified buffer. Buffered operations for a user process include terminal I/O, file system and network I/O, card reader input, and unspooled printer output. During a buffered I/O operation, the pages containing the process-specified buffer need not be locked in memory.

Buffered I/O Byte Count Limit (Bytlm) Limits the amount of buffer space that a user's process can use.
This buffer space is used for buffered I/O operations and for the creation of temporary mailboxes. It also limits the number of mapping windows the user can create as segmented (or cathedral) windows. Cathedral windows are primarily useful for reducing the overhead required to read large files.

CPU Time Limit (CPU) Limits the amount of CPU time that a user's process can use per session.
The time must be specified in abbreviated delta format hh:mm:ss.cc.
CPU is a deductible limit with a suggested typical value of 0 (no limit) but the value applies only to this instance or to other instances of the user's processes. CPU is not cumulative across separate sessions or batch jobs.

Direct I/O Count Limit (DIOlm) Limits the number of outstanding direct I/O operations permitted to a user's process.
In a direct I/O operation, the data transfer takes place directly from a process-specified buffer. Direct I/O operations for a user process typically include disk and tape I/O. The pages containing this buffer are locked in memory by the operating system during the direct I/O operation.
DIOlm is a nondeductible limit.

Enqueue Quota (Enqlm) Limits the number of locks a process (and its subprocesses) can own. OpenVMS Record Management Services (RMS) uses the Lock Management facility to synchronize shared file access, global buffers, and record locks. Because RMS removes one lock for every shared file, local buffer, global buffer section, and outstanding record lock, users who expect to perform large amounts of RMS file sharing should have Enqlm set to a large value.
If your process performs extensive RMS file sharing without sufficient enqueue quota, you could receive the SS$_EXENQLM error message. Furthermore, if your system performs extensive RMS file sharing and the value of the LOCKIDTBL system parameter is too low, you could receive the SS$_NOLOCKID error message. Note that whenever you increase the value of LOCKIDTBL, you might have to increase the value of the RESHASHTBL system parameter. (See the OpenVMS System Management Utilities Reference Manual.)
For shared files, the value of Enqlm should represent the number of files open as shared multiplied by the number of locks per process per file.

If you use the default multibuffer counts, estimate the number of locks as 4 for indexed sequential files and 3 for relative files.
If you use a value other than the default value for the multibuffer counts, estimate the number of locks per process per file as 1 per file, plus the multibuffer count for that file, plus the number of records locked, which is usually one.

Prior to OpenVMS Version 7.1, the limit for Enqlm was 32767. Setting Enqlm to this former maximum value automatically scales Enqlm internally to the architectural maximum value. Thus, in effect, the process has an unlimited enqueue quota but does not need the privilege to ignore quotas.
Use the DCL command SHOW RMS_DEFAULT to display the default multibuffer counts.
Enqlm is a pooled limit.

Expiration Date and Time (EXPIRATION) Qualifier that specifies the expiration date and time of the account. The /NOEXPIRATION qualifier removes the expiration date on the account or resets the expiration time for expired accounts. The /EXPIRATION qualifier does not affect the expiration of passwords.

Open File Limit (Fillm) Limits the number of files that a user's process can have open at one time. This limit includes the number of network logical links that can be active at the same time.
Fillm is a pooled limit. Note that each open file also requires at least 96 bytes of Bytlm.

Job Table Quota (JTquota) Specifies the initial byte quota with which the jobwide logical name table is to be created.
JTquota is a pooled quota.

Maximum Account Jobs Limit (Maxacctjobs) Specifies the maximum number of batch, interactive, and detached processes that might be active at one time for all users of a single account.
Maxacctjobs is a systemwide limit.

Maximum Detached Processes Limit (Maxdetach) Specifies the maximum number of detached processes with the cited user name that can be active at one time. MAXDETACH can also be used to control the number of virtual terminals a user can have. To prevent the user from creating detached processes, specify the keyword NONE. By default, a user has a value of 0, which represents an unlimited number.
Maxdetach is a systemwide limit.

Maximum Process Jobs Limit (Maxjobs) Specifies the maximum number of interactive, batch, and detached processes that can be active at one time for the cited user name.
Maxjobs is a systemwide limit.

Page File Limit (Pgflquo) Limits the number of pages that the user's process can use in the system page file. The page file provides temporary disk storage for pages forced out of memory by a memory management operation. Pgflquo limits the total virtual address space that can be created using the Create Virtual Address Space ($CRETVA) or Expand Program/Control Region ($EXPREG) system services.
Pgflquo is a pooled limit.

Subprocess Creation Limit (Prclm) Limits the number of subprocesses a user's process can create.
The process created when a user logs in to the system can in turn create subprocesses. These subprocesses are all accountable to the user and share the resources allotted to the initial process.
Prclm is a pooled limit.

Timer Queue Entry Limit (TQElm) Limits either of the following amounts:

The number of entries that a user's process can have in the timer queue
The number of temporary common event flag clusters that a user's process can have

This limit does not govern the creation of permanent event flag clusters.
Timer queue entries are used in time-dependent scheduling; common event flags are used in synchronizing activities among groups of cooperating processes.
TQElm is a pooled limit.

Default Working Set Size (WSdef) Sets the initial working set size limit for a user's process.
WSdef is a nondeductible limit. If the value specified exceeds the value of WSquo, the lesser value is used.

Working Set Extent (WSextent) Specifies the maximum size to which a user's physical memory usage can grow, independent of the system load. This enlargement of the physical memory for a user is accomplished by the Adjust Working Set Limit ($ADJWSL) system service, and is normally done for the user by the operating system in response to heavy page faulting by the user.
WSextent is a nondeductible quota. This value should always be greater than or equal to WSquo. The value is controlled by the system parameter WSMAX. Note that PQL_MWSEXTENT will overwrite the account's value for WSextent if PQL_MWSEXTENT is larger than WSextent.

Working Set Quota (WSquo) Specifies the working set quota. This is the maximum amount of physical memory a user process can lock into its working set. It also represents the maximum amount of swap space that the system reserves for this process and the maximum amount of physical memory that the system allows the process to consume if the systemwide memory demand is significant. This parameter guarantees the user that the number of physical pages specified will be available. The maximum value of WSquo is 64K pages.
WSquo is a nondeductible quota. This value should be greater than or equal to WSdef. The value is capped by the system parameter WSMAX.

**Table 6-9 Descriptions of SYSTEM and DEFAULT Accounts**
Account	Description
AST Queue Limit (ASTlm)	Limits the sum of the following amounts: The number of asynchronous system trap (AST) requests that a user's process can have outstanding at one time The number of scheduled wakeup requests that a user's process can have outstanding at one time This limit affects all system services that accept an AST address as an argument, and the Schedule Wakeup ($SCHDWK) system service. If the deferred write option (DFW) is enabled, the number of ASTs used per file is equal to 1, plus the number of record streams, plus the multibuffer count. Otherwise, the number is 1 plus the number of record streams.
Buffered I/O Count Limit (BIOlm)	Limits the number of outstanding buffered I/O operations permitted for a user's process. In a buffered I/O operation, the data transfer takes place from an intermediate buffer in the system pool, not from a process-specified buffer. Buffered operations for a user process include terminal I/O, file system and network I/O, card reader input, and unspooled printer output. During a buffered I/O operation, the pages containing the process-specified buffer need not be locked in memory.
Buffered I/O Byte Count Limit (Bytlm)	Limits the amount of buffer space that a user's process can use. This buffer space is used for buffered I/O operations and for the creation of temporary mailboxes. It also limits the number of mapping windows the user can create as segmented (or cathedral) windows. Cathedral windows are primarily useful for reducing the overhead required to read large files.
CPU Time Limit (CPU)	Limits the amount of CPU time that a user's process can use per session. The time must be specified in abbreviated delta format hh:mm:ss.cc. CPU is a deductible limit with a suggested typical value of 0 (no limit) but the value applies only to this instance or to other instances of the user's processes. CPU is not cumulative across separate sessions or batch jobs.
Direct I/O Count Limit (DIOlm)	Limits the number of outstanding direct I/O operations permitted to a user's process. In a direct I/O operation, the data transfer takes place directly from a process-specified buffer. Direct I/O operations for a user process typically include disk and tape I/O. The pages containing this buffer are locked in memory by the operating system during the direct I/O operation. DIOlm is a nondeductible limit.
Enqueue Quota (Enqlm)	Limits the number of locks a process (and its subprocesses) can own. OpenVMS Record Management Services (RMS) uses the Lock Management facility to synchronize shared file access, global buffers, and record locks. Because RMS removes one lock for every shared file, local buffer, global buffer section, and outstanding record lock, users who expect to perform large amounts of RMS file sharing should have Enqlm set to a large value. If your process performs extensive RMS file sharing without sufficient enqueue quota, you could receive the SS$_EXENQLM error message. Furthermore, if your system performs extensive RMS file sharing and the value of the LOCKIDTBL system parameter is too low, you could receive the SS$_NOLOCKID error message. Note that whenever you increase the value of LOCKIDTBL, you might have to increase the value of the RESHASHTBL system parameter. (See the OpenVMS System Management Utilities Reference Manual.) For shared files, the value of Enqlm should represent the number of files open as shared multiplied by the number of locks per process per file. If you use the default multibuffer counts, estimate the number of locks as 4 for indexed sequential files and 3 for relative files. If you use a value other than the default value for the multibuffer counts, estimate the number of locks per process per file as 1 per file, plus the multibuffer count for that file, plus the number of records locked, which is usually one. Prior to OpenVMS Version 7.1, the limit for Enqlm was 32767. Setting Enqlm to this former maximum value automatically scales Enqlm internally to the architectural maximum value. Thus, in effect, the process has an unlimited enqueue quota but does not need the privilege to ignore quotas. Use the DCL command SHOW RMS_DEFAULT to display the default multibuffer counts. Enqlm is a pooled limit.
Expiration Date and Time (EXPIRATION)	Qualifier that specifies the expiration date and time of the account. The /NOEXPIRATION qualifier removes the expiration date on the account or resets the expiration time for expired accounts. The /EXPIRATION qualifier does not affect the expiration of passwords.
Open File Limit (Fillm)	Limits the number of files that a user's process can have open at one time. This limit includes the number of network logical links that can be active at the same time. Fillm is a pooled limit. Note that each open file also requires at least 96 bytes of Bytlm.
Job Table Quota (JTquota)	Specifies the initial byte quota with which the jobwide logical name table is to be created. JTquota is a pooled quota.
Maximum Account Jobs Limit (Maxacctjobs)	Specifies the maximum number of batch, interactive, and detached processes that might be active at one time for all users of a single account. Maxacctjobs is a systemwide limit.
Maximum Detached Processes Limit (Maxdetach)	Specifies the maximum number of detached processes with the cited user name that can be active at one time. MAXDETACH can also be used to control the number of virtual terminals a user can have. To prevent the user from creating detached processes, specify the keyword NONE. By default, a user has a value of 0, which represents an unlimited number. Maxdetach is a systemwide limit.
Maximum Process Jobs Limit (Maxjobs)	Specifies the maximum number of interactive, batch, and detached processes that can be active at one time for the cited user name. Maxjobs is a systemwide limit.
Page File Limit (Pgflquo)	Limits the number of pages that the user's process can use in the system page file. The page file provides temporary disk storage for pages forced out of memory by a memory management operation. Pgflquo limits the total virtual address space that can be created using the Create Virtual Address Space ($CRETVA) or Expand Program/Control Region ($EXPREG) system services. Pgflquo is a pooled limit.
Subprocess Creation Limit (Prclm)	Limits the number of subprocesses a user's process can create. The process created when a user logs in to the system can in turn create subprocesses. These subprocesses are all accountable to the user and share the resources allotted to the initial process. Prclm is a pooled limit.
Timer Queue Entry Limit (TQElm)	Limits either of the following amounts: The number of entries that a user's process can have in the timer queue The number of temporary common event flag clusters that a user's process can have This limit does not govern the creation of permanent event flag clusters. Timer queue entries are used in time-dependent scheduling; common event flags are used in synchronizing activities among groups of cooperating processes. TQElm is a pooled limit.
Default Working Set Size (WSdef)	Sets the initial working set size limit for a user's process. WSdef is a nondeductible limit. If the value specified exceeds the value of WSquo, the lesser value is used.
Working Set Extent (WSextent)	Specifies the maximum size to which a user's physical memory usage can grow, independent of the system load. This enlargement of the physical memory for a user is accomplished by the Adjust Working Set Limit ($ADJWSL) system service, and is normally done for the user by the operating system in response to heavy page faulting by the user. WSextent is a nondeductible quota. This value should always be greater than or equal to WSquo. The value is controlled by the system parameter WSMAX. Note that PQL_MWSEXTENT will overwrite the account's value for WSextent if PQL_MWSEXTENT is larger than WSextent.
Working Set Quota (WSquo)	Specifies the working set quota. This is the maximum amount of physical memory a user process can lock into its working set. It also represents the maximum amount of swap space that the system reserves for this process and the maximum amount of physical memory that the system allows the process to consume if the systemwide memory demand is significant. This parameter guarantees the user that the number of physical pages specified will be available. The maximum value of WSquo is 64K pages. WSquo is a nondeductible quota. This value should be greater than or equal to WSdef. The value is capped by the system parameter WSMAX.

Contents

Index

Legal

 
6017PRO_023.HTML