HP OpenVMS Systems Documentation
OpenVMS System Manager's Manual
188.8.131.52 Adjusting System Resources and Process Quotas (VAX Only)
Systems in which several vector consumers are active simultaneously may experience increased paging activity as processes share the available memory. To reduce process paging, you may need to use the Authorize utility (AUTHORIZE) to adjust the working set limits and quotas of the processes running vectorized applications. (Refer to the AUTHORIZE section of the OpenVMS System Management Utilities Reference Manual for additional information.) An increase of the process maximum working set size (system parameter WSMAX) may also be necessary. Additionally, a vectorized application may use the Lock Pages in Working Set system service ($LKWSET) to enhance its own performance.
The system allots to each vector consumer 8KB of system nonpaged dynamic memory in which the operating system stores vector context information. Depending upon how many vector consumers may be active in the system simultaneously, you may need to adjust the system parameter NPAGEDYN. The DCL command SHOW MEMORY/POOL/FULL displays the current size of nonpaged pool in bytes.
To obtain optimal performance of a VAX vector processing system, you should take some care in setting up generic batch queues that avoid saturating the system's vector resources. If a queue contains more active vectorized batch jobs than vector-present processors in the system, a significant portion of the processing time will be spent on vector context switches.
The recommended means for dispatching vectorized batch jobs to a VAX
vector processing system is to set up a separate queue (for instance,
VECTOR_BATCH) with a job limit equal to the number of vector-present
processors in the system. When submitting vectorized batch jobs, users
should be encouraged to submit them to this generic vector-processing
As a vector consumer, a process must be scheduled only on a vector-present processor. If the image the process is executing issues only scalar instructions for a period of time, and it must share the scalar-vector processor pair with other vector consumers, its inability to run on an available scalar processor could hamper its performance and the overall performance of the system.
By default, the operating system assumes that if a vector consumer has not issued a vector instruction for a certain period of time, it is unlikely that it will issue a vector instruction in the near future. The system relinquishes this process's need for the vector capability, classifying it as a marginal vector consumer.
In an asymmetric vector-processing configuration, detection of marginal vector consumers achieves the following desirable effects:
Use the VECTOR_MARGIN system parameter to establish the interval of time at which the system checks the status of all vector consumers. The VECTOR_MARGIN parameter accepts an integer value between 1 and FFFFFFFF16. This value represents a number of consecutive process quanta (as determined by the system parameter QUANTUM). If the process has not issued any vector instructions in the specified number of quanta, the system declares it a marginal vector consumer.
The default value of the VECTOR_MARGIN parameter is 20010.
A vector capability is a software abstract by which the operating system makes the services of the vector processor available to users. You can restrict the use of the vector processor to users holding a particular identifier by associating an access control list (ACL) with the vector capability object.
For example, a university might limit use of the vector processor to faculty and students in an image processing course, or a service bureau might charge users for access to the vector capability, time spent on the vector processor, or both.
Note that the ACL is on the vector capability, not on the use of any or all vector-present processors in the system. The operating system will still schedule processes without permission to use the vector capability on a vector-present processor. However, these processors will be able to use only the scalar CPU component of the processor, and cannot execute vector instructions. Likewise, because the ACL is on the vector capability and not on a vector-present processor, you cannot establish an ACL to force long-running jobs to a specific processor.
For additional information about the SET SECURITY and SHOW SECURITY
commands, refer to the OpenVMS DCL Dictionary.
You can obtain information about the status of the vector processing system and the use of the system by individual processes through various means, including:
Refer to the OpenVMS DCL Dictionary for additional information about the DCL
lexicals F$GETJPI and F$GETSYI.
Refer to the OpenVMS DCL Dictionary for additional information about the SHOW
If the target process has accrued any time as a vector consumer scheduled on a vector-present processor, the DCL commands SHOW PROCESS and LOGOUT/FULL display the elapsed vector CPU time and the charged vector CPU time, respectively.
To accumulate vector CPU time, a process must be a vector consumer (that is, require the system vector capability) and be scheduled on a vector-present processor. The operating system still charges the vector consumer vector CPU time, even if, when scheduled on the vector-present processor, it does not actually use the vector CPU. Note that, because scalar consumers and marginal vector consumers do not use the vector CPU, they do not accrue vector CPU time, even when scheduled on a vector-present processor.
Refer to the OpenVMS DCL Dictionary for additional information about the SHOW
PROCESS and LOGOUT commands.
The VAX Vector Instruction Emulation Facility (VVIEF) is a standard operating system feature that allows vectorized applications to be written and debugged in a VAX system in which vector processors are not available. VVIEF is intended strictly as a program development tool, and not as a run-time replacement for vector hardware. Vectorizing applications to run under VVIEF offers no performance benefit; vectorized applications running under VVIEF will execute more slowly than their scalar counterparts.
To cause the system to load VVIEF at the next system boot and at each subsequent system boot, invoke the command procedure SYS$UPDATE:VVIEF$INSTAL.COM. To unload VVIEF, invoke the command procedure SYS$UPDATE:VVIEF$DEINSTAL.COM and reboot the system.
A return value of 1 indicates the presence of VVIEF; a value of 0 indicates its absence.
Note that, although VVIEF may be loaded into the system, in the presence of vector support code, it remains inactive. Although it is possible to prevent the loading of vector processing support code in a vector-present system (see Section 28.4.1) and activate VVIEF, there are few benefits. Should the only vector-present processor in the system fail, the execution of preempted vectorized applications will not resume under VVIEF.
|Reserved File||File Name||+Structure Level 1||Structure
Levels 2 and 5
|Storage bitmap file||BITMAP.SYS;1||X||X||X|
|Bad block file||BADBLK.SYS;1||X||X|
|Master file directory||000000.DIR;1||X||X||X|
|Core image file||CORIMG.SYS;1||X||X|
|Volume set list file||VOLSET.SYS;1||X||X|
|Backup log file||BACKUP.SYS;1||X|
|Pending bad block||BADLOG.SYS;1||X|
|Volume security profile||SECURITY.SYS||X|
INDEXF.SYS is a large, extendable file made up of several sections. These sections provide the operating system with the information necessary to identify a Files-11 volume, initially access that volume, and locate all the files on that volume (including INDEXF.SYS itself).
Table A-2 shows the information that is in INDEXF.SYS. After the table are additional explanations of boot block, home block, and file headers.
|Boot block||Virtual block 1 of the index file. The boot (or bootstrap) block is almost always mapped to the logical block 0 of the volume. If the volume is a system volume, the boot block contains a boot program that loads the operating system into memory. If the volume is not a system volume, the boot block contains a program that displays the message that the volume is not the system device but a device that contains users' files only.|
|Home block||Establishes the specific identity of the volume, providing such information as the volume name and protection, the maximum number of files allowed on the volume, and the volume ownership information. The home block is virtual block number 2 of the index file.|
|Backup home block||A copy of the home block; permits the volume to be used even if the primary home block is destroyed.|
|Backup index file header||Permits data on the volume to be recovered if the index file header is corrupted; occupies virtual blocks v * 3 + 1 through v * 4, where v is the volume cluster factor.|
|Index file bitmap||Controls the allocation of file headers and thus the number of files on the volume; contains a bit for each file header allowed on the volume. If the value of a bit for a given file header is 0, a file can be created with this file header. If the value is 1, the file header is already in use.|
|File headers||Make up the bulk of the index file; contain all the information needed for gaining access to the file. Each file header describes one file on the volume. A file header contains information such as the owner UIC, protection code, creation date and time, and access control lists (ACLs); it also contains a list of extents that make up the file, describing where the file is logically located on the volume. Note that a file header can also be an extension header.|
|Alternate index file header||Permits recovery of data on the volume if the primary index file header becomes damaged.|