|
HP OpenVMS Systemsask the wizard |
|
The Question is: I have created a min install disk from AXPVMS$PCSI_INSTALL_MIN.COM for use on a DS20E VMS 7.2-1 system (as per 1075 ask the wizard). When booting from a "normal" disk everything is fine. When an image of that same disk is backed up into an LD disk and b urned as a CD-ROM, the following error occurs during boot and the system is hung: "%SYSTEM-I-MOUNTVER SABKUP$DQA0: has been write-locked. Mount verification in progress" It seems obvious that the CD version is write locked - what can/should be done to circumvent (as you have suggested this CD method in the past as a viable stand-alone boot method?) Thanks The Answer is :
OpenVMS System Disks and CD and DVD Recording
© Copyright 1976, 2004 Hewlett-Packard Development
Company, L.P.
Neither HP nor any of its subsidiaries shall be
liable for technical or editorial errors or
omissions contained herein. The information
in this document is provided "as is" without
warranty of any kind and is subject to change
without notice. The warranties for HP products
are set forth in the express limited warranty
statements accompanying such products. Nothing
herein should be construed as constituting an
additional warranty.
Document Abstract
This document describes CD and DVD recording, and
ways to generate bootable media for use with the
OpenVMS Alpha and OpenVMS I64 operating systems.
This document does not discuss specific recording
tools, though a recording tool is assumed available
and is required when recording optical media.
There are presently no DVD recording devices that
have native support within OpenVMS. There are
recording packages for OpenVMS, please see the
OpenVMS Frequently Asked Questions (FAQ) for
related materials and recording information.
http://www.hp.com/go/openvms/faq
No information contained here should be construed
as a statement of support by HP.
__________________________________________________________
1.1 CD and DVD Technology Introduction
The two core technology platforms are Compact Disk
(CD) and Digital Versatile Disk (DVD), and there are
various formulations of each of these technologies.
This section will provide a general overview of the
technologies.
_____________________________
1.1.1 Compact Disk (CD) Technologies
CD was first available as a pressed media, known as
CD-ROM. The recording medium of CD-ROM is physically
pressed into a series of pits, encoding the desired
data onto the medium. A red laser is then used to read
the signals produced by reflections from the patterns
of pits.
CD then evolved into recordable technologies, including
a write-once technology known as CD-R and a rewritable
format known as CD-RW. These differed from classic CD-
ROM as they are produced by writing a pattern onto
a photochemical layer on special disks, typically
using the same laser used to read the disk, albiet
at higher power. The results of the recording process
are intended to optically duplicate the appearance of
pressed media.
Recording typically starts at the inside of the disk
nearest the hub, and spirals outward toward the edge of
the optical medium.
Older CD-ROM drives may not be able to read CD-R or
CD-RW media.
Capacities on CD media are sometimes given in bytes and
sometimes in minutes. The former assumes data, and the
latter assumes audio storage.
Each CD disk can hold upwards of 600 or 700 megabytes
and potentially more, depending on the particular
drive and the particular recording medium. CDs
with capacities of 600 megabytes are recordable and
transportable across the widest variety of devices,
though 700 MB is also widely compatible.
Reading and writing of CD media occurs at pre-set
speeds, with the original and classic recording speed
of 150 kilobytes per second and subsequently known as
1X CD recording. Drives are commonly available that
record at speeds far faster than this, with the three
broad ranges of recording speed being broken down into
the original and classic speed range, the High Speed
range (4X to 24X), and the Ultra-Speed range (10X and
up).
Most current drives now operate at variable speeds,
depending on various factors including as the position
of the data on the disk and even potentially on
the error rates detected as the medium is read. The
drive peak speeds are usually cited in the marketing
materials, and the actual speeds can be lower.
The central factor in a successful CD recording process
involves choosing a speed that is supported by the
particular medium in use, by the drive, and by the host
system. Faster recording requires the photochemical
change to occur sufficiently quickly when each pit
is written, and support in the drive itself for the
particular recording speed, and the ability of the
host to stream data out to the device. Additional
information on recording speeds is available in
Section 1.1.5.
There are other CD recording formats and variants,
though these other variants are now in comparatively
limited or otherwise specialized use.
The majority of recent CD devices on IDE/ATAPI, SCSI
and USB buses support the Multimedia Commands (MMC)
command interface.
_____________________________
1.1.2 Digital Versatile Disk (DVD) Technologies
Like CD, DVD was first available as a pressed media,
known as DVD-ROM. Like CD, a red laser is then used to
read the signals produced by the reflections from the
patterns of pits.
DVD then evolved into multiple recordable technologies,
including three general families of recording
technologies. Like CD, both write-once and rewritable
formats are available. Unlike CD, there are variants
of each. The write-once formats are known as DVD-R and
DVD+R, and the rewritable formats as DVD-RW, DVD+RW,
and DVD-RAM.
DVD-R and DVD-RW (collectively known here as DVD-R/RW)
use relatively similar command sets, while DVD+R and
DVD+RW (collectively DVD+R/RW) use a different command
set and provide slightly different capabilities.
DVD-R/RW initially targeted video recording, while
DVD+R/RW initially targeted the requirements of digital
data recording. The DVD-RAM format was targeted at
environments with somewhat higher read-write cycles[2].
Like CD-R/RW recording, the results of the recording
process are intended to optically duplicate the
appearance of pressed media.
Each of the formats requires specific and appropriate
recording media.
HP has traditionally targeted the DVD+R and DVD+RW
technologies, though current HP DVD drives support
DVD+R, DVD+RW, DVD-R and DVD-RW formats, as well as
DL (Double Layer, Dual Layer) recording capabilities.
Drives that support CD-R/RW, DVD-R/RW and DVD+R/RW
recording are now common in the market, and there
are drives which can additionally read and record the
DVD-RAM format.
Unlike CD recording, traditional DVD-ROM media can be
recorded in two layers, with adjustments made to the
focus of the laser used to read the pits of each layer.
This increases the recording capacity of one side of
the DVD medium from 4.7 GB to approximately 9.4 GB.
DVD Dual-Layer (DL) recording is a relatively recent
innovation, and allows recording two layers of data on
a single side of the recording medium.
Newer technologies target the use of a blue laser
to read and write data, allowing for much higher
densities.
Paralleling CD-R/RW recording, older DVD-ROM drives may
not be able to read recorded DVD media, and there can
be incompatibilities seen across various combinations
of drives, drive types and media types. You will
want to test compatibility, you will want to ensure
current drive firmware, and you will want to ensure
the older drives are replaced. Newer media formats
and newer media recording speeds can require firmware
updates with older drives; in specific notable cases,
attempted use of newer media can damage or destroy
a down-revision drive, and can damage or destroy the
media.
Various DVD drives can feature commodity-level hardware
pricing, and the entire drive is usually considered the
replaceable unit. Do expect to replace your DVD drive,
whether to move to a faster speed, to add new format
support, or to effect a repair.
Like CD recording, there are other DVD recording
formats and variants.
_____________________________
1.1.3 Media Care and Handling
The recording substrate for all CD and DVD media is
generally located very close to the side of the disk
medium with the label, and comparatively far from what
is often considered to be the recording surface. The
recording layer can be physically or chemically damaged
by the label, by removal of the label, by the use of
ballpoint pen or similar marker, or even by the use of
specific and incompatible inks or dyes.
Environmental and physical factors such as mishandling,
thermal extremes, moisture, exposure to direct
sunlight, and scratches can also all lead to
accellerated media degradation and to media failure.
Rotational imbalances caused by defects in the medium
or by unbalanced or misapplied labels can also cause
serious problems, and potentially even catastrophic
failures.
Catastrophic failures can also potentially damage the
drive or the drive optics.
_____________________________
1.1.4 Device Firmware and Device Damage
There are cases where drive firmware has been found
incompatible with (usually) newer media types or
newer media speeds, and this has led to compatibility
problems, to media failures, and occasionally even
to conditions that resulted in physical damage to the
recording drive.
Always ensure that the device firmware is the most
current available version, and that it is compatible
with the recording medium in use.
If you are moving to faster media or to newer formats,
always ensure the device in use is compatible with the
speed and the media, particularly with DVD media.
_____________________________
1.1.5 Recording Media and Recording Speeds
CD-R/RW recording and rewriting is sensitive to the
recording speeds permitted by the drive and to the
maximum recording speed permitted by the recording
medium.
This tool defaults to the maximum CD-R/RW recording
speed permitted by the drive, and must assume that
the CD-R/RW recording medium loaded has a sufficient
speed rating for that default recording speed. It is
possible to exceed the rated CD recording speed or
to otherwise have inappropriate CD recording media
loaded, and this can and often will lead to recording
problems or recording failures. Most commonly, this
will result in write errors and in recording failures;
in incomplete, erroneous or partially recorded media.
Use of under-rated CD recording media is not
recommended.
If you must use the lower-speed CD recording media,
the use of the /SPEED qualifier is often required for
successful completion of the recording process; you
may be required to select a recording speed below the
rated speed of the CD drive itself, and specifically
a recording speed that is compatible both with the CD
drive and with the CD recording media loaded in the
drive.
Unlike CD-R/RW, the permissible recording speed for
DVD+R/RW media is encoded directly onto the disk blank
when the media is manufactured, and this tool will
honor that speed. It is expected that a DVD+R/RW drive
loaded with lower-speed media will record at the lower
speed; at the speed appropriate for the media.
__________________________________________________________
1.2 General Preparation and Recording Instructions
LD Assumed
This description assumes the use of LD. Other
similar logical disk tools can also be used, as
can -- if your chosen recording tool supports
it -- an appropriately-sized physical disk
device. An RZ29 series disk, for instance,
provides a capacity of 8,380,080 blocks, and
can thus potentially be used as a mastering
device for DVD recording operations.
Each time the OpenVMS Alpha system is bootstrapped,
start LD manually or in your SYS$MANAGER:SYSTARTUP_
VMS.COM procedure:
$ @SYS$STARTUP:LD$STARTUP.COM
Create and initially configure the LD logical disk file
(partition file). This step is needed only once:
$ ld create [/log] [/size=XXX] [/contiguous] filespec.dsk
XFC and LD
There exist particular configuration requirements
with the combination of LD and the OpenVMS XFC
file cache. Please refer to Section 1.3.1 for
additional details and for the necessary cache-
related commands.
It is expected that this requirement will be
removed in a future release of LD and/or XFC.
With DVD+R and CD-R/RW media recording, the size of
the input determines the data recorded to the media.
In particular, you can select the media size to be
generated by correctly sizing the input data source.
With DVD+RW recording, the output device is always
the same size; it is always the maximum capacity of
the disk. On the classic Single-Layer (SL) DVD+RW
media, this is always 4.7GB. With HP DVD+RW media,
the observed size of such media is 9,180,416 blocks.
Accordingly, you will want to size your input
appropriately, or you will want to use the OpenVMS
Alpha V7.3-2 (and later) Dynamic Volume Expansion (DVE)
feature.
Enable the volume for DVE, and size the limit for at
least the 4.7 GB capacity of the DVD+RW target. Double-
Layer (DL) recording devices and media are expected to
require a larger limiting value, obviously.
Each time the system is bootstrapped, connect the LD
device to the target logical disk file:
$ ld connect filespec.dsk LDA1: -
[/tracks=XXX] [/sectors=XXX] [/cylinders=XXX]
You may want to the pick the tracks, sectors and
cylinders values to match the output geometry, and
you will want to assume CHKSCB errors may arise when
ANALYZE/DISK_STRUCTURE is used in cases where the
geometries do not match.
These particular CHKSCB geometry-related messages
reported by ANALYZE/DISK_STRUCTURE are entirely benign,
are commonly and widely seen on existing recorded
optical media used with OpenVMS. These messages can
safely be ignored. An example of the messages typical
of an analysis of a recorded volume follows:
$ analyze/disk dqa1:
Analyze/Disk_Structure for _VMS$DQA1: started on
dd-mmm-yyyy hh:mm:ss.cc
%ANALDISK-W-CHKSCB, invalid storage control block, RVN 1
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
$
SYS$LDDRIVER, SYS$DKDRIVER and SYS$DQDRIVER do not
currently implement consistent geometry-related
synthesis; the drivers calculate different pseudo-
geometries for the same input device maximum block
count. (Note that the disk geometry values are entirely
synthetic constructs on most (all?) recent storage
devices, whether magnetic disk or optical media.
Save for some messages generated within analysis
and reporting tools, the values are also entirely
inconsequential. Again, these messages can safely be
ignored.)
Here is the SYS$DQDRIVER geometry from a typical 600 MB
CD-R/RW DQcu:-type disk device:
Total blocks: 1200000 Sectors per track: 33
Total cylinders: 1102 Tracks per cylinder: 33
Here is the SYS$DKDRIVER geometry (yes, the drivers
can disagree in the synthesis) from a typical 600 MB
CD-R/RW DKcu:-type disk device:
Total blocks 1200008 Sectors per track 4
Total cylinders 37501 Tracks per cylinder 8
For each master to be created, initialize and populate
the master volume:
$ INITIALIZE /SYSTEM [/ERASE] -
[/CLUSTER=n] [/GPT] [/...] -
LDA1: volumelabel
$ MOUNT LDA1: volumelabel
$ !... populate the target volume as required
$ DISMOUNT LDA1:
You will want to consider the use of INITIALIZE/ERASE,
and particularly if there is the potential for
sensitive data stored on the underlying disk device.
Without the disk erasure during initialization, the
contents of (uninitialized or otherwise unerased)
blocks underneath the logical disk file can be
replicated out onto the target media.
If working to create OpenVMS I64 system disks, you will
generally want to select the /GPT option to create the
necessary GPT-related files within the created disk
volume structure. INITIALIZE/GPT is the default for the
OpenVMS I64 initializations, though it must currently
be explicitly selected when initializing volumes on
OpenVMS Alpha and OpenVMS VAX platforms; volumes that
are intended for later use bootstrapping on OpenVMS I64
platforms.
Additionally, the cluster factor may be best chosen
as a multiple of four (4) if the target volume is a
system disk, as this causes the proper alignment of
the core bootstrap files. For related information,
please see INITIALIZE/CLUSTER and see section 1.2.1.2.
To record the contents of the master volume to the
CD-R/RW or DVD+R/RW SCSI or ATAPI device, please
review the command(s) associated with your chosen
recording tool. If you are using a recording device
on another operating system platform, you will want
to use the binary or raw recording mode of the tool,
after having performed an FTP binary transfer of the
LD partition file to the target platform (if not
recording on OpenVMS).
The typical recording operation requires the selection
of what most recording tools refer to as a raw, binary,
or image transfer (to perform a block-by-block recording
of the contents of the LD partition file out onto the
medium), the Disk-at-Once (DAO) recording selection
is common, and the output recording format is usually
ISO Mode 1 data using 2048 byte blocking. Consult
the documentation for the particular chosen recording
tool for additional details and required syntax.
_____________________________
1.2.1 Creating Bootable OpenVMS Media
This section contains information on creating bootable
OpenVMS media, and is not specifically related to the
chosen recording utility.
To create bootable media, there are a variety of ways
to transfer hp OpenVMS operating system files files
onto the target media. This section will describe the
use of certain tools provided with hp OpenVMS, as well
as specific considerations related to bootstrapping
optical media.
_____________________________
1.2.1.1 Write-locked Bootable Media
If you are using SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM
or SYS$SYSTEM:I64VMS$PCSI_INSTALL_MIN.COM to create
bootable OpenVMS environment, remember to mark the the
target medium as being write-locked; remember to set
the WLKSYSDSK system parameter in the LD master copy to
1.
The following assumes the target device for the
mastering is LDA1:, and assumes [SYSE], the default
system root for AXPVMS$PCSI_INSTALL_MIN or
I64VMS$PCSI_INSTALL_MIN operations:
$ run sys$system:sysman
SYSMAN> parameters use lda1:[syse.sysexe]alphavmssys.par
SYSMAN> parameters show wlksysdsk
SYSMAN> parameters set wlksysdsk 1
SYSMAN> parameters write lda1:[syse.sysexe]alphavmssys.par
SYSMAN>
$ run sys$system:sysman
SYSMAN> parameters use lda1:[syse.sysexe]ia64vmssys.par
SYSMAN> parameters show wlksysdsk
SYSMAN> parameters set wlksysdsk 1
SYSMAN> parameters write lda1:[syse.sysexe]ia64vmssys.par
SYSMAN>
Failure to establish the correct write-lock setting and
failure to set up the proper system root can lead to
bootstrap problems when booting the OpenVMS operating
system from CD or DVD media.
_____________________________
1.2.1.2 The Bootblock Structures
If not invoked within the tools utilized to transfer
the hp OpenVMS files onto the target logical disk, you
must also directly invoke the SET BOOTBLOCK utility
(or run SYS$SETBOOT.EXE directly) to write the I64
EFI console bootstrap structures specific to OpenVMS
I64 onto the disk, or you must invoke the hp OpenVMS
WRITEBOOT utility to write OpenVMS VAX or OpenVMS Alpha
bootstrap structures.
OpenVMS I64 bootstraps requires one additional key
consideration, the target sector size for the medium.
With magnetic disk bootstraps, the sector size is
always 512 bytes. With optical media, the sector size
is typically 2048 bytes.
When selecting the bootstrap structures to write to
an OpenVMS I64 system disk using the SET BOOTBLOCK
utility, the default is to write 512-byte structures.
The use of 2048-byte sector structures must be manually
selected when writing to the logical disk; when writing
to a logical disk that will eventually master optical
media.
The sector size selection has no effect on any other
structures nor on any other disk data written to
the disk, nor any effects on the running hp OpenVMS
environment once OpenVMS has bootstrapped; all disks
will present the appearance of 512-byte blocks once
OpenVMS has bootstrapped. This 2048-byte sector
size selection only affects the I64 EFI bootstrap
structures, and is only required when mastering for
OpenVMS I64 optical media bootstraps.
An example of selecting the larger block size with SET
BOOTBLOCK follows:
SET BOOTBLOCK/BLOCK_SIZE=2048/PRESERVE=SIGNATURE ddcu:
The INITIALIZE[/ERASE][/GPT]/CLUSTER=4 command -- or
another multiple of four (4) -- will properly align the
two core bootstrap files (SYS$LOADABLE_IMAGES:SYS$EFI.SYS
and SYS$MAINTENANCE:SYS$DIAGNOSTICS.SYS) as required by
SET BOOTBLOCK. These are the only two files that must
be aligned to the 2048-byte sector boundary.
_____________________________
1.2.1.3 Generating a System Disk Master
Use LD CREATE ddcu:[dir]partition.DSK/SIZE=size to
create the partition, set the caching attributes
on the file to disable XFC caching, then issue LD
CONNECT ddcu:[dir]partition.DSK LDcu: to connect
the LD device, full initialization of the volume
including erasure of the master partition, then use
SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM on OpenVMS
Alpha, SYS$SYSTEM:I64VMS$PCSI_INSTALL_MIN.COM on
OpenVMS I64, or BACKUP/IMAGE or otherwise to load the
logical disk partition with the contents of a system
disk. MOUNT and then configure the volume contents as
required for the application, including modifying the
WLKSYSDSK system parameter as discussed earlier, then
(if the target is OpenVMS I64) use the DCL command
SET BOOTBLOCK/BLOCK_SIZE=2048/IA64 LDcu: to write
the bootblock appropriate for a 2048-byte block device,
DISMOUNT the device, then use the prefered recording
tool to transfer LDcu: to DQcu:; to transfer the
contents to the target recording device.
If the target is OpenVMS Alpha, use WRITEBOOT.EXE in
place of SET BOOTBLOCK or SYS$SETBOOT.EXE.
If you have the OpenVMS I64 cross-tools tools kit
installed and are generating a system disk for use
with OpenVMS I64, use of INITIALIZE/ERASE/GPT/CLUSTER
is recommended. The direct invocation of the image
SYS$SETBOOT.EXE (which triggers a prompting mode, akin
to that of WRITEBOOT) or the use of the associated DCL
command SET BOOTBLOCK command is also recommended.
(SET BOOTBLOCK/SYS$SETBOOT.EXE applies to OpenVMS I64,
and WRITEBOOT applies to OpenVMS VAX and OpenVMS Alpha.)
When creating an OpenVMS Alpha system disk within the
partition, the following is the general sequence:
$ LD CREATE ddcu:[dir]partition.DSK/SIZE=size
$ SET FILE /CACHING_ATTRIBUTE=NO_CACHING -
ddcu:[dir]partition.DSK
$ LD CONNECT ddcu:[dir]partition.DSK LDcu:
$ INITIALIZE[/ERASE][...] LDcu: vollab
$ @SYS$SYSTEM:AXPVMS$PCSI_INSTALL_MIN.COM
$! or BACKUP/IMAGE ddcu: LDcu:
$ MOUNT LDcu: vollab
$ run sys$system:sysman
SYSMAN> parameters use ldcu:[syse.sysexe]alphavmssys.par
SYSMAN> parameters set wlksysdsk 1
SYSMAN> parameters write ldcu:[syse.sysexe]alphavmssys.par
SYSMAN> exit
$ RUN SYS$SYSTEM:WRITEBOOT
$ DISMOUNT LDcu:
$ [prefered DVD recording tool]
When creating an OpenVMS I64 system disk in the disk
partition, the following is the general sequence:
$ LD CREATE ddcu:[dir]partition.DSK/SIZE=size
$ SET FILE /CACHING_ATTRIBUTE=NO_CACHING -
ddcu:[dir]partition.DSK
$ LD CONNECT ddcu:[dir]partition.DSK LDcu:
$ INITIALIZE[/ERASE][/GPT][/CLUSTER=n][...] LDcu: vollab
$ @SYS$SYSTEM:I64VMS$PCSI_INSTALL_MIN.COM
$! or BACKUP/IMAGE ddcu: LDcu:
$ MOUNT LDcu: vollab
$ run sys$system:sysman
SYSMAN> parameters use ldcu:[syse.sysexe]ia64vmssys.par
SYSMAN> parameters set wlksysdsk 1
SYSMAN> parameters write ldcu:[syse.sysexe]ia64vmssys.par
SYSMAN> exit
$ SET BOOTBLOCK/BLOCK_SIZE=2048/IA64 LDcu:
$ DISMOUNT LDcu:
$ [prefered DVD recording tool]
_____________________________
1.2.1.4 The Bootstrap Root
If the selected system root for the bootable medium
is [SYSE], remember that the associated SRM console
bootstrap command is:
>>> BOOT -FLAGS E,0
If you want the default bootstrap to be SYS0, which is
the common setting for bootstraps from various devices,
please remember to create the root in [SYS0] using the
available AXPVMS$PCSI_INSTALL_MIN command syntax, or
remember to add an alias using a DCL command similar to
the following:
$ SET FILE/ENTER=LDA1:[000000]SYS0.DIR -
LDA1:[000000]SYSE.DIR
_____________________________
1.2.1.5 The Core Utilities
For information on AXPVMS$PCSI_INSTALL_MIN, on SYSMAN,
on the WLKSYSDSK system parameter, on SET FILE/ENTER,
on the SRM console, on WRITEBOOT and on SET BOOTBLOCK,
and other related materials, please see the hp OpenVMS
documentation.
_____________________________
1.3 LD Logical Disk Driver
This description assumes LD (latent in V7.3-1 and later,
though the command verb must be manually loaded into
DCLTABLES, or the LD command verb can be loaded into
DCLTABLES using the LD731 kit found on OpenVMS Freeware
V6.0) has been configured and started. The LD command
verb and related portions of the interface are expected
to be available by default in OpenVMS V8.2 and later.
LD provides a pseudo disk, sometimes known as an
emulated or file-based or loop disk, and the user
interface is comprised of a LD utility and its
associated DCL command verb, and a device driver known
as SYS$LDDRIVER. LD provides the mechanism by which the
master copy of the media can be created. (Other similar
pseudo disk packages can potentially be used, there are
no specific requirements for LD and SYS$LDDRIVER. Other
pseudo disk packages have not been tested.)
Do not configure LD devices larger than four gigabytes
(GB) prior to the version of SYS$LDDRIVER integrated in
OpenVMS Alpha V7.3-1; older kits and older versions have
a four GB addressing limit. If you are using the version
of LD shipped with V7.3-1 or are using a later OpenVMS
release, this note and this restriction does not apply.
If you are using an LD06* or an older VMSINSTAL kit,
please upgrade before working with larger disks.
_____________________________
1.3.1 XFC and LD
When creating and initially configuring the LD logical
disk file (partition file) as discussed in Section 1.2,
you will want to use the following command sequence:
$ ld create [/log] [/size=XXX] [/contiguous] filespec.dsk
$ SET FILE /CACHING_ATTRIBUTE=NO_CACHING filespec.dsk
Note that only the LD logical disk file (a backing
partition file) should have XFC file caching disabled.
Files that are not logical disk files and that are not
accessed via the LD device should have XFC caching left
enabled.
A correction to the operations and communications
between LD and XFC is expected. Once available, the
logical disk file can be left with XFC caching enabled.
Change the XFC cache settings on the logical disk file
once. Having or altering the settings to enable XFC
caching can lead to data inconsistencies between the
LD contents and the XFC cache contents of the logical
disk file, and to errant or unexpected recorded media
contents, and is not recommended.
When reading from an input file, XFC caching should
be enabled. When transfering data from an input LDcu:
device, caching should be disabled on the LD logical
disk file (partition file).
It is strongly recommended that the XFC caching setting
be toggled exactly once on any particular file, and
subsequently left unchanged for current and future
operations on the specified file. Repeatedly toggling
the XFC caching setting is not recommended, and
can result in corrupted file data and/or corrupted
recordings.
_____________________________
1.3.2 IDE/ATAPI Bus Interface
If you have an Acer or other DMA-capable IDE interface,
the version of SYS$DQDRIVER shipped with V7.3-2 will
not permit the formatting nor the reformatting of
rewritable media, and is expected to mishandle the
formatting (FORMAT_UNIT) request. The CMD649 on OpenVMS
I64, and the Cypress and the Intel PIIXE IDE interfaces
on both OpenVMS I64 and OpenVMS Alpha are expected to
permit the (re)formatting operation to succeed. The
Acer is not expected to permit reformatting operations.
Table 1-1 contains various of the AlphaServer and
AlphaStation IDE controller hardware identification
values.
________________________________________________________________
Table 1-1 IDE/ATAPI Controllers
_______________________________________________________
Device_Name_______Device_ID_________Format_OK?_________
Acer 0x522910B9 No
CMD649 0x06491095 Yes
Cypress 0xC6931080 Yes
_________Intel_PIIXE_______0x76018086________Yes________________
The ANALYZE/SYSTEM (SDA) command CLUE CONFIG can also
potentially be used to identify the particular IDE
controller in use. Look for the identification of the
controller associated with the DQcu: devices. These
values are also directly visible from the SRM console.
In SYS$DQDRIVER version X-48 and related versions
(including the driver version shipping with OpenVMS
Alpha V7.3-2), the error is the omission of the FORMAT_
UNIT command code (0x04) from within the following
SYS$DQDRIVER.C device driver code:
if ( (packet [0] == 0x0A) || (packet [0] == 0x2A) ||
(packet [0] == 0xAA) || (packet [0] == 0x55) )
data_dir = TRUE;
The following are the packet command codes that should
set the data_dir variable to TRUE:
WRITE_6 (0x0a), WRITE_10 (0x2a), WRITE_12 (0xaa),
WRITE_VERIFY_10 (0x2e), MODE_SELECT_10 (0x55),
FORMAT_UNIT (0x04), RESERVE_TRACK (0x53),
SEND_DVD_STRUCT (0xbf), SEND_KEY (0xa3),
SEND_OPC_INFO (0x54), and WRITE_BUFFER (0x3b).
The FORMAT_UNIT packet command code is used to
initialize and to reformat RW-type rewritable media.
The FORMAT_UNIT packet command is not otherwise used,
nor used with other recordable media types.
The underlying SYS$DQDRIVER issue might be corrected
in an unspecified future version of SYS$DQDRIVER. No
schedule and no plans for the correction have been
announced, and the code change is not present within
the OpenVMS V8.2 source code pool, as of 06-Aug-2004.
The change is not present in the OpenVMS E8.2 field
test release.
|