Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS System Manager's Manual


Previous Contents Index

26.4.4 Restricting Access to the Vector Processor by Using ACLs (VAX Only)

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.

Use the DCL command SET SECURITY/ACL in the following format to establish access control entries (ACEs) on a vector capability:

SET SECURITY /CLASS=CAPABILITY /ACL=(ace[,...]) VECTOR 

The following DCL command displays the ACL on the vector capability:


$ SHOW SECURITY /CLASS=CAPABILITY VECTOR

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.

26.4.5 Obtaining Information About a Vector Processing System (VAX Only)

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:

26.4.5.1 DCL Lexical Functions F$GETJPI and F$GETSYI (VAX Only)

The DCL lexical function F$GETJPI accepts the following items and returns the corresponding information regarding the vector status of a specified process:
Item Return Type Information Returned
FAST_VP_SWITCH Integer Number of times this process has issued a vector instruction that resulted in an inactive vector processor being enabled without the expense of a vector context switch
SLOW_VP_SWITCH Integer Number of times this process has issued a vector instruction that resulted in an inactive vector processor being enabled with a full vector context switch
VP_CONSUMER Boolean Flag indicating whether the process is a vector consumer
VP_CPUTIM Integer Total amount of time the process has accumulated as a vector consumer

The DCL lexical function F$GETSYI accepts the following items and returns the corresponding information regarding the status of the vector processing system:
Item Return Type Information Returned
VECTOR_EMULATOR Integer Flag indicating the presence of the VAX Vector Instruction Emulation facility (VVIEF) in the system
VP_MASK Integer Mask indicating which processors in the system have vector coprocessor
VP_NUMBER Integer Number of vector processors in the system

Refer to the OpenVMS DCL Dictionary for additional information about the DCL lexicals F$GETJPI and F$GETSYI.

26.4.5.2 SHOW CPU/FULL Command (VAX Only)

The SHOW CPU/FULL command lists the capabilities of the specified CPU. Issue this command to determine the presence of the vector capability in the system prior to executing a STOP/CPU command.

Refer to the OpenVMS DCL Dictionary for additional information about the SHOW CPU command.

26.4.5.3 SHOW PROCESS and LOGOUT/FULL Commands (VAX Only)

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.

26.4.6 Loading the VAX Vector Instruction Emulation Facility (VVIEF) (VAX Only)

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.

You can determine the presence or absence of VVIEF in a system by issuing the following DCL commands:


$ X = F$GETSYI("VECTOR_EMULATOR")
$ SHOW SYMBOL X
X = 1   Hex = 00000001  Octal = 0000000001

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 26.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.


Appendix A
Files--11 Disk Structure

This appendix explains disk terminology and disk concepts. It also describes reserved files, points out those files used by the Analyze/Disk_Structure utility (ANALYZE/DISK_STRUCTURE), and compares Files-11 On-Disk Structure (ODS) Level 1 with Files-11 ODS Levels 2 and 5.

A.1 Disk Concepts

This section defines terms related to both the physical and the logical organization of disks.

A.1.1 Logical Organization of a Disk

The smallest addressable unit of information on a disk is a block. Files--11 On-Disk Structures define a block to consist of 512 8-bit bytes. Blocks can be treated as units for transfer between a Files-11 disk volume and memory. Files--11 ODS, however, views a disk as an array of blocks, and is generally not concerned with individual blocks.

Blocks are logically grouped into clusters, which are the basic units by which disk space is allocated. You determine the number of blocks in a cluster when a given disk, known as a volume, is first prepared for use (initialized). Cluster sizes vary for different media types. The smaller cluster sizes in the range are usually more practical. In general, a disk with a relatively small number of blocks is given a smaller cluster size, while larger disks are given larger cluster sizes to minimize the overhead for disk space allocation.

Contiguous clusters allocated to a particular file are called extents. An extent can contain all or part of a file. If enough contiguous area is available on the disk, the entire file is allocated as a single extent. Sometimes, however, not enough contiguous area is available to hold the entire file, or, when you create a file initially, you might not want to reserve the entire required amount of space. When the file is eventually extended, it is unlikely that the adjacent clusters will still be unallocated. If the adjacent clusters are already allocated to another file, the extension does not occur contiguously.

If a file is divided into two or more parts, each part is an extent. Thus, a file can consist of multiple extents located in separate areas on the disk, as shown in Figure A-1. Note that the file extensions are done automatically.

Figure A-1 File Extents


A.1.2 Physical Organization of a Disk

The smallest unit discernible to the Files-11 structure is the sector; for most Files-11 disks, a sector is equivalent to a block, which is 512 bytes. Other basic terms related to disks are track and cylinder. A track is the collection of sectors (or blocks, on Files-11 structures) at a single radius on one recording surface of a disk. It is accessible to a given read/write head position on the disk device. A cylinder consists of all tracks at the same radius on all recording surfaces of a disk.

Because access to any of the blocks in a given cylinder does not require any movement of the disk's read/write heads, it is generally advantageous to keep related data blocks in the same cylinder. For this reason, when choosing a cluster size for a large-capacity disk, you should usually select a cluster size that divides evenly into the cylinder size.

Figure A-2 is a graphic representation of disk tracks and cylinders.

Figure A-2 Tracks and Cylinders


A.2 Files--11 Structure

The Files-11 structure creates a set of nondeletable reserved files when a volume or volume set is initialized. These files control the organization of a Files-11 disk. A Files-11 structure resides on a volume, which is a physical medium such as a disk pack. A Files-11 volume is an ordered set of 512-byte blocks. The blocks are numbered consecutively from 0 to n--1; the value of n--1 is the size of the disk in blocks.

A.2.1 File Identification (FID)

Each file on a Files-11 disk is identified by a unique, system-assigned file identification (FID) and can have a user-assigned alphanumeric name. The primary function of a Files-11 directory is to associate the user-assigned alphanumeric name of each file with the unique FID of the file. This association ensures that files present on a volume are retrievable by name.

The FID of a file consists of a set of three numbers. The first is the file number (NUM). The file system uses this number as an offset into the index file (reserved file INDEXF.SYS), which stores information for all files on a volume.

The second part of the FID is the file sequence number (SEQ), which represents the number of times a particular file number has been used. File numbers are allocated and deallocated as files are created and deleted. As a result, the file number alone cannot uniquely identify the file. By incrementing the sequence number each time a file number is used, the file system ensures that each file has a unique identification in INDEXF.SYS.

The third number in the FID is the relative volume number (RVN). This number indicates the volume (of a volume set) on which the file resides (ODS--2 only). If the volume set consists of a single volume, the RVN of all files on that volume is 1.

A.2.2 ODS Directory Hierarchies

The Files-11 ODS--2 structure is a multilevel directory hierarchy. The top level of the directory structure is the master file directory (MFD). The MFD of a volume is always named [000000]. The MFD contains all top-level directories, including itself, and reserved files.

A directory is a file that contains other files. A file contained in a directory can also be a directory and contain other files. By nesting directories, users can construct directory hierarchies up to nine levels deep (including the master file directory).

In a volume set, the MFD for all of the user directories on the volume set is located on relative volume 1. The entries of this MFD point to directories located on any volume in the set. These directories in turn point to files and subdirectories on any volume in the set. The MFD of any remaining volume in the set includes only the names of the reserved files for that volume.

On VAX systems, the Files-11 ODS--1 structure supports a two-level directory hierarchy. Each user identification code (UIC) is associated with a user file directory (UFD). Each UFD is included in the MFD of the volume.

A.3 Reserved Files

This section describes the reserved files that Files--11 uses. Note that all reserved files have constant FIDs.

This section also points out the files ANALYZE/DISK_STRUCTURE uses. ANALYZE/DISK_STRUCTURE makes an in-memory copy of what these files should look like and compares it with the current version. The utility reports and repairs (if you specify the /REPAIR qualifier) any discrepancies found during these comparisons.

Table A-1 shows the reserved files used by Files--11 Levels 1, 2, and 5, and files used by ANALYZE/DISK_STRUCTURE.

Table A-1 Reserved Files
Reserved File File Name +Structure Level 1 Structure
Levels 2 and 5
ANALYZE/
DISK_STRUCTURE
Index file INDEXF.SYS;1 X X X
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
Continuation file CONTIN.SYS;1   X  
Backup log file BACKUP.SYS;1   X  
Pending bad block BADLOG.SYS;1   X  
Quota file QUOTA.SYS     X
Volume security profile SECURITY.SYS   X  


+VAX specific

A.3.1 Index File, INDEXF.SYS

Every Files--11 volume has an index file, which is created when the volume is initialized. (You cannot use a disk as a Files-11 disk until it has been initialized with the INITIALIZE command.)

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.

Table A-2 Contents of Files--11 Index File
Term Definition
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.

A.3.1.1 Boot Block

Block 0 on a system disk is the boot block. It contains the location and size of the primary bootstrap image, which is used to boot the system. Certain processors, in order to boot, must read this boot block to obtain the location of the bootstrap image. For more details, see Section 4.7.

A.3.1.2 Home Block

The home block is normally the next block after the boot block; it identifies the disk as a Files-11 volume. If for some reason the home block cannot be read (physically unusable), an alternative block will be selected for use as the home block. This block provides specific information about the volume and default values for files on the volume. Items in the home block include the following ones:

Files-11 volumes contain several copies of the home block to ensure against accidental destruction of this information and the consequent loss of access to files on the volume.


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6017PRO_103.HTML