HP OpenVMS Systems Documentation
OpenVMS System Manager's Manual
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.
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.
Most of the index file consists of file headers; each file header describes a portion of a file on the volume. File headers contain information such as the owner UIC, protection code, creation date and time, and access control lists (ACLs). Most importantly, the file header contains a list of extents that make up the file, describing where the file is logically located on the volume. If a file has a large number of extents, multiple file headers may be used to describe them. A file identifier number is associated with each file header.
When you create a file, you normally specify a file name to OpenVMS RMS, which assigns this name to the file on a Files--11 volume. OpenVMS RMS places the file name and file identifier associated with the newly created file into a directory, which contains an entry defining the location for each file. When you access the file, you supply the file name, which supplies a path to the file identifier through the directory entry. The file identifier, in turn, points to the location of the file header, which contains a listing of the extent or extents that locate the actual data.
Because they represent the current state of file storage on a volume, file headers are of particular interest to ANALYZE/DISK_STRUCTURE. Each file on a Files-11 disk (INDEXF.SYS included) is identified and located by a primary header (and extension headers, if required) in INDEXF.SYS.
Each fixed-length header contains both constant and variable-length data. This data is stored in one of the six areas shown in Table A-3.
A set of contiguous clusters is known as an extent. The size of an extent varies according to the number of contiguous clusters. For example, assume a file requires 1000 blocks of storage, and the file system finds a set of 800 contiguous blocks and a set of 200 contiguous blocks. The file would then be stored in two extents: one consisting of 800 blocks, the other of 200.
The primary header of a file points to the first extent of that file and to as many extents as can be stored in the map area of the primary header. When the number of extents required to contain a file exceeds the map area available in the primary header, or the ACL is too large to fit in the primary header, the file is allocated an extension header. Extension headers contain all the constant data of the primary header, as well as the variable data (in the header map area and access control list) that specifies the locations of the extents to which the extension header points.
ANALYZE/DISK_STRUCTURE confirms the validity of a file by working its
way down the list of primary and extension headers of the file. During
this process, ANALYZE/DISK_STRUCTURE checks the validity of the file
header, the chain of pointers to all extension headers, the retrieval
pointers in all headers, and the attributes of the file.
The storage bitmap file is a contiguous file that the file system uses to keep track of the available space on a volume. This file contains a storage control block (SCB), which consists of summary information intended to optimize the Files--11 space allocation, and the bitmap itself, which lists the availability of individual blocks.
The SCB contains summary information about the volume (cluster factor, volume size, blocking factor, and so forth). Each bit in the bitmap represents an allocatable cluster on the volume. If a bit is set, the corresponding cluster is available for use. If a bit is clear, the cluster is not available.
During normal operation, the operating system moves portions of the bitmap in and out of cache memory. The state of each bit in memory is altered as clusters are allocated and deallocated. BITMAP.SYS is updated when the portion of the bitmap in cache is swapped back to disk. Since a portion of the bitmap is always in cache, BITMAP.SYS never reflects the current state of allocated clusters on a disk (unless the disk is dismounted or write-locked).
One of the functions of ANALYZE/DISK_STRUCTURE is to build a current
version of BITMAP.SYS from data extracted from INDEXF.SYS, so that
BITMAP.SYS accurately reflects the status of free clusters on the disk.
The bad block file contains all the bad blocks on the volume. The
system detects bad disk blocks dynamically and prevents their reuse
once the files to which they are allocated have been deleted.
The MFD is a file that contains reserved files that control the Files-11 volume directory structure. The MFD lists the known files, in addition to any files or directories that the user enters. The master file directory is itself one of the files (000000.DIR;1) listed in the MFD.
Usually, however, the MFD is used to list the reserved files and users' file directories; users seldom enter files into the MFD, even on private volumes. In fact, on a private volume, it is most convenient for users to create a directory that has the same name as their default directory on a system disk. For an explanation of users' file directories and file specifications, refer to the OpenVMS User's Manual.
ANALYZE/DISK_STRUCTURE verifies all files contained in the directory
structure by making comparisons to INDEXF.SYS. Any file found in
INDEXF.SYS that is not traceable through the directory structure is
"lost." ANALYZE/DISK_STRUCTURE places lost files in the
top-level directory SYSLOST.DIR if you specified /REPAIR in the command.
The core image file is not used by the operating system.
ANALYZE/DISK_STRUCTURE uses VOLSET.SYS to locate each volume in the set
and confirm the attributes of each volume. Since all volume set
information is stored in VOLSET.SYS on relative volume 1,
ANALYZE/DISK_STRUCTURE ignores VOLSET.SYS on all other volumes.
The continuation file is used as the extension file identifier when a
file crosses from one volume to another volume of a loosely coupled
volume set. This file is used for all but the first volume of a
sequential disk save set.
The backup log file is reserved for future use.
The pending bad block log file contains a list of suspected bad blocks
on the volume that are not listed in the bad block file.
The quota file is a reserved file that is used by the file system to keep track of the disk usage of each UIC on a volume. If you enable disk quota checking for a volume, the records of the file QUOTA.SYS contain all the UICs on the volume. The system constantly updates QUOTA.SYS to reflect the current disk usage, the maximum allowed disk usage, and the permitted overdraft for each UIC.
During the course of its operations, ANALYZE/DISK_STRUCTURE creates a
version of QUOTA.SYS in memory that reflects the actual disk usage for
each UIC. This version is eventually compared to the disk version of
QUOTA.SYS. If ANALYZE/DISK_STRUCTURE detects any disparities in disk
usage, ANALYZE/DISK_STRUCTURE notifies you. If you invoked
ANALYZE/DISK_STRUCTURE with the /REPAIR qualifier, the disk version of
QUOTA.SYS is updated.
The volume security profile includes the volume owner UIC, the volume
system-owner-group-world (SOGW) protection mask, and the volume access
control list (ACL).
On VAX systems, for reasons of performance, reliability, and security, Files--11 ODS Level 2, a compatible superset of ODS Level 1, is the preferred disk structure on the system. At volume initialization time, Structure Level 2 is the default. (Refer to the INITIALIZE command in the OpenVMS DCL Dictionary.)
On VAX systems, specify ODS Level 1 only for volumes that must be transportable to RSX--11M, RSX--11D, RSX--11M--PLUS, and IAS systems, as these systems support only that structure level. Additionally, you might be required to handle Structure Level 1 volumes transported to OpenVMS from one of these systems.
Where Structure Level 1 volumes are in use on the system, bear in mind the limitations on them that are shown in Table A-4.
Future enhancements to OpenVMS software will be based primarily on Structure Level 5; therefore, Structure Level 1 volumes might be further restricted in the future.
Time zone rules are under control of each country, and are subject to change for political and other reasons. For up-to-date information, see the following web locations:
Table B-1 lists the time differential factors for Europe.
|Great Britain, Ireland||0:00||+1:00|
|Western European Time||0:00||+1:00|
|Middle European Time||+1:00||+2:00|
|Eastern European Time||+2:00||+3:00|
Table B-2 lists the time differential factors for North America.
Table B-3 lists the time differential factors for Central and South America.
Table B-4 lists the time differential factors for Asia.
|PRC (Mainland China)||+8:00||+9:00|
Table B-5 lists the time differential factors for the South Pacific.
|Australia/Queensland (standard time only)||+10:00||---|
|Australia/New South Wales||+10:00||+11:00|
Table B-6 lists the time differential factors for Antarctica.