HP OpenVMS I/O User's Reference Manual |
Disk Drivers |
|
|
| |
The following sections describe these features in greater detail.
Dual-Pathed Disks ![]()
A dual-pathed
disk is a dual-ported disk that is accessible to all
the CPUs in the cluster, not just to the CPUs that are connected
physically to the disk. Dual-pathed disks can be any of the following:
The term dual-pathed refers to the two paths through which clustered CPUs can access a disk to which they are not directly connected. If one path fails, the disk is accessed over the other path. (Note that with a dual-ported MASSBUS disk, a CPU directly connected to the disk always accesses it locally.)
Dual Porting MASSBUS Disks ![]()
The MASSBUS disk
drivers, DBDRIVER and DRDRIVER, support static dual porting. Dual
porting allows two MASSBUS controllers to access the same disk drive.
Dual-Ported Disk Drives shows this configuration.
The RP05, RP06, RP07, RM03, RM05, and RM80 disk drives can be ordered,
or upgraded in the field, with the MASSBUS dual-port option.
|
Figure 2 Dual-Ported Disk Drives |
![]() |
Port Selection and Access Modes ![]()
The
port select switches, on each disk drive, select the ports from
which the drive can be accessed. A drive can be in one of the following
access modes:
| The drive is connected and responding to a request on Port A. It is closed to requests on Port B. |
| The drive is connected and responding to a request on Port B. It is closed to requests on Port A. |
| The drive is in a neutral state. It is equally available to requests on either port on a first-come, first-serve basis. |
The operational condition of the drive cannot be changed with the port select switches after the drive becomes ready. To change from one mode to another, the drive must be in a nonrotating condition. After the new mode selection has been made, the drive must be restarted.
If a drive is in the neutral state and a disk controller either reads or writes to a drive register, the drive immediately connects a port to the requesting controller. For read operations, the drive remains connected for the duration of the operation. For write operations, the drive remains connected until a release command is issued by the device driver or a 1-second timeout occurs. After the connected port is released from its controller, the drive checks the other port's request flag to determine whether there has been a request on that port. If no request is pending, the drive returns to the neutral state.
Disk Use and Restrictions ![]()
If the volume
is mounted foreign, read/write operations can be performed at both
ports provided the user maintains control of where information is
stored on the disk.
The Autoconfigure utility currently may not be able to locate the nonactive port. For example, if a dual-ported disk drive is connected and responding at Port A, the CPU attached to Port B might not be able to find Port B with the Autoconfigure utility. If this problem occurs, execute the AUTOCONFIGURE ALL/LOG command after the system is running.
Restriction on Dual-Ported Non-DSA Disks
in a Cluster ![]()
Do not use SYSGEN to AUTOCONFIGURE or CONFIGURE a dual-ported,
non-DSA disk that is already available on the system through use
of an MSCP server. Establishing a local connection to the disk when
a remote path is already known creates two uncoordinated paths to
the same disk. Use of these two paths may corrupt files and data
on any volume mounted on the drive.
| If the disk is not dual-ported or is never served by an MSCP server on the remote host, this restriction does not apply. |
If the local path to the disk is not found during the bootstrap, then the MSCP server path from the other host will be the only available access to the drive. The local path will not be found during a boot if any of the following conditions exist:
Use of the disk is still possible through the MSCP server path.
After the configuration of the disk has reached this state, it is important not to add the local path back into the system I/O database. Because the operating system does not provide an automatic method for adding this local path, the only possible way that you can add this local path is to use the System Generation utility (SYSGEN) qualifiers AUTOCONFIGURE or CONFIGURE to configure the device. SYSGEN is currently not able to detect the presence of the disk's MSCP path, and will incorrectly build a second set of data structures to describe it. Subsequent events could lead to incompatible and uncoordinated file operations, which might corrupt the volume.
To recover the local path to the disk, it is necessary to reboot the system connected to that local path.
Dual-Pathed
DSA Disks ![]()
A dual-ported DSA disk can
be failed over between the two CPUs that serve it to the cluster
under the following conditions: (1) the same disk controller letter
and allocation class are specified on both CPUs and (2) both CPUs
are running the MSCP server.
| Failure to observe these requirements can endanger data integrity. |
| A dual-ported DSA disk may not be used as a system disk. |
Dual-Porting HSC Disks ![]()
By design, HSC disks are
cluster accessible; therefore, if they are dual-ported, they are
automatically dual-pathed. CI-connected CPUs can access a dual-pathed
HSC disk by way of a path through either HSC-connected device.
For each dual-ported HSC disk, you can control failover to a specific port using the port select buttons on the front of each drive. By pressing either port select button (A or B) on a particular drive, you can cause the device failover to the specified port.
With the port select button, you can select alternate ports to balance the disk controller workload between two HSC subsystems. For example, you could set half of your disks to use port A and set the other half to use port B.
The port select buttons also allow you to fail over all the disks to an alternate port manually when you anticipate the shutdown of one of the HSC subsystems.
Dual-Pathed RF-Series Disks ![]()
In a dual-path configuration
of MicroVAX 3300/3400 CPUs or MicroVAX 3800/3900 CPUs using RF-series disks,
CPUs have concurrent access to any disk on the DSSI bus. A single
disk is accessed through two paths and can be served to all satellites
by either CPU.
If either CPU fails, satellites can access their disks through the remaining CPU. Note that failover occurs in the following situations: (1) when the DSSI bus is connected between SII integral adapters on both MicroVAX 3300/3400 CPUs or (2) when the DSSI bus is connected between the KFQSA adapters on pairs of MicroVAX 3300/3400s or pairs of MicroVAX 3800/3900s.
| The DSSI bus should not be connected between a KFQSA adapter on one CPU and an SII integral adapter on another. |
Data Check ![]()
A data check is made
after successful completion of a read or write operation and, except
for the TU58, compares the data in memory with the data on disk
to make sure they match.
Disk drivers support data checks at the following levels:
Offset recovery is performed during a data check, but error code correction (ECC) is not performed (see Error Recovery). For example, if a read operation is performed and an ECC correction is applied, the data check would fail even though the data in memory is correct. In this case, the driver returns a status code indicating that the operation was completed successfully, but the data check could not be performed because of an ECC correction.
Data checks on read operations are extremely rare, and you can either accept the data as is, treat the ECC correction as an error, or accept the data but immediately move it to another area on the disk volume.
A data check operation directed to a TU58 does not compare the data in memory with the data on tape. Instead, either a read check or a write check operation is performed (see Sections Read and Write).
Effects of a Failure During an I/O Write
Operation ![]()
The operating system ensures that when an I/O write operation
returns a successful completion status, the data is available on
the disk or tape media. Applications that must guarantee the successful
completion of a write operation can verify that the data is on the
media by specifying the data check function modifier IO$M_DATACHECK.
Note that the IO$M_DATACHECK data check function, which compares
the data in memory with the data on disk, affects performance because
the function incurs the overhead of an additional read operation
to the media.
If a system failure occurs while a multiple-block write operation is in progress, the operating system does not guarantee the successful completion of the write operation. (OpenVMS does guarantee single-block write operations to DSA drives.) When a failure interrupts a write operation, the data may be left in any one of the following conditions:
To guarantee that a write operation either finishes successfully or (in the event of failure) is redone or rolled back as if it were never started, use additional techniques to ensure data correctness and recovery. For example, using database journaling and recovery techniques allows applications to recover automatically from failures such as the following:
Overlapped Seeks ![]()
A
seek operation involves moving the disk read/write heads to a specific
place on the disk without any transfer of data. All transfer functions,
including data checks, are preceded by an implicit seek operation (except
when the seek is inhibited by the physical I/O function modifier
IO$M_INHSEEK). Seek operations can be overlapped except on
RL02, RX01, RX02, TU58 drives, MicroVAX 2000, VAXstation 2000, or
on controllers with diskettes (for example, RQDX3) when the disk
is executing I/O requests. That is, when one drive performs a seek
operation, any number of other drives can also perform seek operations.
During the seek operation, the controller is free to perform transfers on other units. Therefore, seek operations can also overlap data transfer operations. For example, at any one time, seven seeks and one data transfer could be in progress on a single controller.
This overlapping is possible because, unlike I/O transfers, seek operations do not require the controller once they are initiated. Therefore, seeks are initiated before I/O transfers and other functions that require the controller for extended periods.
All DSA controllers perform extensive seek optimization functions as part of their operation; IO$M_INHSEEK has no effect on these controllers.
Error Recovery ![]()
Error recovery in
the operating system is aimed at performing all possible operations
to complete an I/O operation successfully. Error recovery operations
fall into the following categories:
The error recovery algorithm uses a combination of these four types of error recovery operations to complete an I/O operation:
Skip Sectoring ![]()
Skip
sectoring is a bad block treatment technique implemented on R80
disk drives (the RB80 and RM80 drives). In each track of 32 sectors,
one sector is reserved for bad block replacement. Consequently,
an R80 drive has available only 31 sectors per track. The Get Device/Volume
Information ($GETDVI) system service returns this value.
You can detect bad blocks when a disk is formatted. Most formatters place these blocks in a bad block file. On an R80 drive, the first bad block encountered on a track is designated as a skip sector. This is accomplished by setting a flag in the sector header on the disk and placing the block in the skip sector file.
When a skip sector is encountered during a data transfer, it is skipped over, and all remaining blocks in the track are shifted by one physical block. For example, if block number 10 is a skip sector, and a transfer request was made beginning at block 8 for four blocks, then blocks 8, 9, 11, and 12 will be transferred. Block 10 will be skipped.
Because skip sectors are implemented at the device driver level, they are not visible to you. The device appears to have 31 contiguous sectors per track. Sector 32 is not directly addressable, although it is accessed if a skip sector is present on the track.
Logical-to-Physical
Translation (RX01 and RX02) ![]()
Logical-block-to-physical-sector
translation on RX01 and RX02 drives adheres to the standard format.
For each 512-byte logical block selected, the driver reads or writes
four 128-byte physical sectors (or two 256-byte physical sectors
if an RX02 is in double-density mode). To minimize rotational latency,
the physical sectors are interleaved. Interleaving allows the processor
time to complete a sector transfer before the next sector in the
block reaches the read/write heads. To allow for track-to-track
switch time, the next logical sector that falls on a new track is
skewed by six sectors. (There is no interleaving or skewing on read
physical block and write physical block I/O operations.) Logical
blocks are allocated starting at track 1; track 0 is not used.
The translation procedure, in more precise terms, is as follows:
ITEMP = ISECT*2
IF (ISECT .GT. 12) ITEMP = ITEMP-25
ISECT = ITEMP
ISECT = ISECT+(6*ICYL)
ISECT = MOD (ISECT, 26)
ISECT = ISECT+1ICYL = ICYL+1DIGITAL Storage Architecture (DSA) Devices ![]()
The DIGITAL
Storage Architecture (DSA) is a collection of specifications that
cover all aspects of a mass storage product. The specifications
are grouped into the following general categories:
Because the operating system supports all DSA disks, it supports all controller-to-host aspects of DSA. Some of these disks, such as the RA60, RA80, and RA81, use the standard drive-to-controller specifications. Other disks, such as the RC25, RD51, RD52, RD53, and RX50, do not. Disk systems that use the standard drive-to-controller specifications employ the same hardware connections and use the HSC50, KDA50, KDB50, and UDA50 interchangeably. Disk systems that do not use the drive-to-controller specifications provide their own internal controller, which conforms to the controller-to-host specifications.
DSA disks differ from MASSBUS and UNIBUS disks in the following ways:
Bad Block Replacement and Forced Errors for
DSA Disks ![]()
Disks that are built
according to the DSA specifications appear to be error free. Some
number of logical blocks are always capable of recording data. When
a disk is formatted, every user-addressable logical block is mapped
to a functioning portion of the actual disk surface, which is known
as a physical block. The physical block has the true data storage
capacity represented by the logical block.
Additional physical blocks are set aside to replace blocks that fail during normal disk operations. These extra physical blocks are called replacement blocks. Whenever a physical block to which a logical block is mapped begins to fail, the associated logical block is remapped (revectored) to one of the replacement blocks. The process that revectors logical blocks is called a bad block replacement operation. Bad block replacement operations use data stored in a special area of the disk called the Replacement and Caching Table (RCT).
When a drive-dependent error threshold is reached, the need for a bad block replacement operation is declared. Depending on the controller involved, the bad block replacement operation is performed either by the controller itself (as is the case with HSCs) or by the host (as is the case with UDAs). In either case, the same steps are performed. After inspecting and altering the RCT, the failing block is read and its contents are stored in a reserved section of the RCT.
The design goal of DSA disks is that this read operation proceeds without error and that the RCT copy of the data is correct (as it was originally written). The failing block is then tested with one or more data patterns. If no errors are encountered in this test, the original data is copied back to the original block and no further action is taken. If the data-pattern test fails, the logical block is revectored to a replacement block. After the block is revectored, the original data is copied back to the revectored logical block. In all these cases, the original data is preserved and the bad block replacement operation occurs without the user being aware that it happened.
However, if the original data cannot be read from the failing block, a best-attempt copy of the data is stored in the RCT and the bad block replacement operation proceeds. When the time comes to write back the original data, the best-attempt data (stored in the RCT) is written back with the forced error flag set. The forced error flag is a signal that the data read is questionable. Reading a block that contains a forced error flag causes the status SS$_FORCEDERROR to be returned. This status is displayed by the following message:
%SYSTEM-F-FORCEDERROR, forced error flagged in last sector readWriting into a block always clears the forced error flag.
Note that most utilities and DCL commands treat the forced error flag as a fatal error and terminate operation when they encounter it. However, the Backup utility (BACKUP) continues to operate in the presence of most errors, including the forced error. BACKUP continues to process the file, and the forced error flag is lost. Thus, data that was formerly marked as questionable may become correct data.
System managers (and other users of BACKUP) should assume that forced errors reported by BACKUP signal possible degradation of the data.
To determine what, if any, blocks on a given disk volume have the forced error flag set, use the ANALYZE /DISK_STRUCTURE /READ_CHECK command, which invokes the Verify utility. The Verify utility reads every logical block allocated to every file on the disk and then reports (but ignores) any forced error blocks encountered.
VAXstation 2000 and MicroVAX 2000 Disk Driver ![]()
The VAXstation
2000 and MicroVAX 2000 disk driver supports some DSA disk operation.
In particular, the driver supports block revectoring and bad block
replacement. This provides the system with a logically perfect disk
medium.
Like other DSA disks, if a serious error occurs during a replacement operation, the disk is write-locked to prevent further changes. This is done to preserve data integrity and minimize damage that could be caused by failing hardware. Unlike other DSA disks, there is no visible indication on the drive itself that the disk is write-locked. However, the following indicators help you determine that the disk has become write-protected:
If the disk becomes write-locked, you should use the following procedure:
If errors occurring during replacement operations persist, call HP Customer Services.
SCSI Disk Class Driver ![]()
The VAXstation 3100,
3520, and 3540 contain a SCSI bus that provides access to as many
as seven SCSI disks. The SCSI disk class driver controls SCSI disks
on all of the above systems. Although SCSI disks do not conform
to DSA, they do support the following error recovery features:
All SCSI disks supplied by HP implement the REASSIGN BLOCKS command, which relocates data for a specific logical block to a different physical location on the disk. The SCSI disk class driver reassigns the block in the following instances: (1) when the retry threshold is exceeded during an attempt to read or write a block of data on the disk or (2) when an irrecoverable error occurs during a write operation.
Unlike DSA, there is no forced error flag in SCSI. Blocks that produce irrecoverable errors during read operations are not reassigned in order to prevent undetected loss of user data. Instead, the SCSI disk class driver returns the SS$_PARITY status whenever a read operation results in an irrecoverable error.
Audio Extensions to the SCSI Disk Class Driver ![]()
This section describes SCSI disk class driver audio commands
and the $QIO interface by which the operating system provides audio
functionality to the SCSI disk.
SCSI Disk Class Driver Audio Commands lists the SCSI audio commands supported by the SCSI disk class driver.
| Command | Audio Function Code1 | Description |
|---|---|---|
|
Play Audio MSF
|
AUDIO_PLAY_AUDIO_MSF
(5)
|
Requests the CD-ROM to begin
an audio playback operation. The two required command arguments specify
absolute starting and ending addresses of the playback in terms
of minutes, seconds, and frame (MSF).
|
|
Play Audio Track
|
AUDIO_PLAY_AUDIO_TRACK (6)
|
Requests the CD-ROM to begin
an audio playback operation. The two required command arguments specify
the starting and ending tracks of the playback in terms of track
number and index.
|
|
Play Audio
|
AUDIO_PLAY_AUDIO
(4)
|
Requests the CD-ROM to begin
an audio playback operation. The two required command arguments specify
the starting logical block address (LBA) and the transfer count,
in blocks, of the playback.
|
|
Pause
|
AUDIO_PAUSE
(0)
|
Requests the CD-ROM to suspend
any active audio operations. In response, the CD-ROM enters the hold-track
state, muting the audio output after playing the current block.
|
|
Resume
|
AUDIO_RESUME
(1)
|
Requests the CD-ROM to resume
any active audio operations. In response, the CD-ROM exits the hold-track
state and resumes playback at the block following the last block
played.
|
|
Get Status
|
AUDIO_GET_STATUS
(9)
|
Requests from the CD-ROM
the status of the currently active playback operation, as well as
the state of the current block. The Get Status command corresponds
to the SCSI II Read Sub-channel command (READ SUBQ).
|
|
Set Volume
|
AUDIO_SET_VOLUME
(11)
|
Requests the CD-ROM to adjust
the output channel selection and volume settings for ports 0 through
3. The Set Volume command corresponds to the SCSI II Mode Select
command for the CD-ROM Audio Control Parameters page.
|
|
Get Volume
|
AUDIO_GET_VOLUME
(12)
|
Requests from the CD-ROM
the output channel selection and volume settings for ports 0 through
3. The Get Volume command corresponds to the SCSI II Mode Sense
command for the CD-ROM Audio Control Parameters page.
|
|
Prevent Removal
|
AUDIO_PREVENT_REMOVAL (2)
|
Prevents the removal of
the CD caddy from the CD-ROM drive.
|
|
Allow Removal
|
AUDIO_ALLOW_REMOVAL
(3)
|
Allows the removal of the
CD caddy from the CD-ROM drive.
|
|
Get TOC
|
AUDIO_GET_TOC (10)
|
Requests from the CD-ROM a list of each
track on the disk, including information about the audio or data
contents of each track. Applications that require a detailed knowledge
of the organization of a CD-ROM can use this function to obtain
that information. The Get TOC command corresponds to the SCSI II
Read TOC command.
|
$QIO Interface to Audio Functionality of
the SCSI Disk Class Driver ![]()
To employ the audio functions of the RRD42 CD-ROM reader,
the application program issues a call to the $QIO system service
using the following format:
status=SYS$QIO ([efn] ,[chan] ,func [,iosb] [,astadr] [,astprm] [,p1] [,p2] [,p3] [,p4] [,p5] [,p6])Arguments
[efn]
[chan]
[iosb]
[astadr]
[astprm]
These arguments apply to the $QIO system service completion, not to device interrupt actions. For an explanation of these arguments, refer to the description of the $QIO system service in the HP OpenVMS System Services Reference Manual.
func
The IO$_AUDIO function code allows the SCSI disk class driver to process SCSI audio commands.
p1
Address of an audio control block (AUCB). The $QIO system service passes a SCSI audio command and command-specific control information to the SCSI disk class driver in the AUCB structure (see Defining an Audio Control Block (AUCB)).
p2
Size of the AUCB.
Defining
an Audio Control Block (AUCB) ![]()
An application program that issues a call to the $QIO system
service that specifies the IO$_AUDIO function code in the func argument
must supply the address of an AUCB structure in the p1 argument
and its size in the p2 argument.
An AUCB defines a specific SCSI audio command and provides the SCSI disk class driver with command-specific arguments and control information. Contents of AUCB defines the fields that appear in an AUCB; these fields are shown in Audio Control Block (AUCB). See SYS$EXAMPLES:CDROM_AUDIO.C for a code example that shows how an AUCB is defined in the C programming language.
|
Figure 3 Audio Control Block (AUCB) |
![]() |
| Field | Use | |
|---|---|---|
|
Audio Function Code
|
Numeric or
symbolic code representing the audio function desired by the application program.
(See
SCSI Disk Class Driver Audio Commands.)
The application program must provide a valid audio function code
for each operation.
|
|
|
AUCB Version Number
|
Version of
the AUCB and SCSI disk class driver audio interface. For the current
version of the interface the value of this field should be 1. This
field must never contain a zero.
|
|
|
Argument 1
|
This field
is audio command-specific and contains the first argument of the
function as follows:
|
|
|
|
Audio
Function Code2
|
Field Contents
|
|
|
AUDIO_PLAY_AUDIO_MSF
(5)
|
Starting Frames|(Sec
shifted left 8 bits)|(Min shifted left 16 bits)
|
|
|
AUDIO_PLAY_AUDIO_TRACK
(6)
|
Starting (Track shifted
left 8 bits) |Index
|
|
|
AUDIO_PLAY_AUDIO
(4)
|
Starting logical block address.
|
|
|
AUDIO_GET_STATUS
(9)
|
0 if LBA format, 1 if MSF
format. Refer to the SCSI II specification for information about
these formats.
|
|
|
AUDIO_SET_VOLUME
(11)
|
Longword representing the
values to be used to determine the new output channel selection
and volume settings for CD-ROM ports 0 through 3.
Output Channel Selection and Volume Settings for CD-ROM Ports as Used by the SET_VOLUME Function shows the format of this longword. Note
that many CD-ROM drives do not support ports 2 and 3.
|
|
|
AUDIO_GET_VOLUME
(12)
|
Longword to receive the
current values determining output channel selection and volume settings
for CD-ROM ports 0 through 3.
Output Channel Selection and Volume Settings for CD-ROM Ports as Used by the SET_VOLUME Function shows the format of this longword. Note that many CD-ROM
drives do not support ports 2 and 3.
|
|
|
AUDIO_GET_TOC
(10)
|
0 if LBA format, 1 if MSF
format. Refer to the SCSI II specification for information about
these formats.
|
|
Argument 2
|
This field
is audio command-specific and contains the second argument of the
function as follows:
|
|
|
|
Audio
Function Code
|
Field Contents |
|
|
AUDIO_PLAY_AUDIO_MSF
(5)
|
Starting frames|(sec
shifted left 8 bits)|( min shifted left 16 bits)
|
|
|
AUDIO_PLAY_AUDIO_TRACK
(6)
|
Ending(track shifted left
8 bits)|index
|
|
|
AUDIO_PLAY_AUDIO
(4)
|
Transfer count in number
of contiguous blocks to be played
|
|
|
AUDIO_GET_TOC
(10)
|
Starting track
|
|
Reserved
|
Must be zero.
|
|
|
Destination Buffer
Address
|
Address of
the application program's buffer from which the status from a GET_STATUS or
GET_TOC function is returned.
|
|
|
Destination Buffer
Count
|
Size, in bytes,
of the destination buffer specified in the Destination Buffer Address
field. For the GET_STATUS function, this field must contain the
value 48 to receive complete status information. For the GET_TOC
function, this field must contain the value 804 to receive full
status. The SCSI disk class driver truncates the status data, if
the destination buffer size is smaller than the size of the data.
|
|
|
Destination Buffer Transfer
Count
|
The SCSI disk
class driver returns to this field the actual number of bytes transferred
to the buffer specified in the Destination Buffer Address field.
Before accessing data returned by the GET_TOC or GET_STATUS commands, an application program must check the contents of this field to determine precisely how many bytes were returned by the CD-ROM. The application program initializes this field to zero. |
|
|
Operating System Command Status
|
Completion
status of the SCSI audio function. This value is also returned in
the I/O status block of specified in the iosb argument
to the $QIO system service call. See
Status Codes Returned to the IOSB and AUCB by the SCSI Disk Class Driver for a description of these status codes.
The application program initializes this field to zero. |
|
|
SCSI Command Status (optional)
|
SCSI status
of the current operation. The SCSI disk class driver returns the
SCSI status byte for the SCSI audio command described by this AUCB
in the low byte of the low-order word of this field. It returns
the sense key in the low byte of the high-order word. Refer to the
SCSI specification for information regarding SCSI status and SCSI sense
keys.
The application program initializes this field to zero. |
|
|
Sense Data Buffer
Address (optional)
|
Address of
buffer to which the SCSI disk class driver returns sense data when
errors occur during audio function execution. When this field is
specified, in the event of a check condition on an Audio command,
the SCSI disk class driver automatically issues a Request Sense
command to retrieve the Sense Key/Sense Data from the target. The target
returns this data to the buffer specified in this field before the
failing $QIO audio function completes.
|
|
|
Sense Data Buffer
Count (optional)
|
Size, in bytes,
of the buffer specified in the Sense Data Buffer Address field.
During request sense processing, the target device truncates the
sense data to fit in this buffer.
|
|
|
Sense Data Buffer Transfer
Count (optional)
|
Actual number
of bytes of sense data returned to the application in the buffer
specified in the Sense Data Buffer Address field.
The application program initializes this field to zero. |
|
|
Reserved
|
Must be zero.
|
|
The output channel selection and volume settings for CD-ROM ports as used by the SET_VOLUME function appear as shown in Output Channel Selection and Volume Settings for CD-ROM Ports as Used by the SET_VOLUME Function.
Error Handling in Applications Using SCSI
Audio Functions ![]()
As indicated in
Contents of AUCB,
the AUCB provides for three levels of error status reporting:
|
Figure 4 Output Channel Selection and Volume Settings
for CD-ROM Ports as Used by the SET_VOLUME Function |
![]() |
If the CD-ROM device is currently software-enabled (that is, the volume has been mounted) and a unit attention is detected, then mount verification will be initiated by the driver. However, if the CD-ROM is not software-enabled, the event will simply be returned to the application issuing the Audio $QIO function.
Using CD-ROM to Store Both Data and Audio
Information ![]()
To make effective use of mixed data and audio CDs, an application
program requires detailed knowledge of the particular CD being played.
The application program must know which tracks include data and
which tracks include audio so it can use commands appropriate to
the different track types. Issuing an audio command on a data track
results in the command failing with a status of SS$_DRVERR.
By default, the SCSI disk class driver transfers all requests issued to a CD-ROM in blocks of 512 bytes. This byte amount is referred to as the default block size. Before attempting to issue READ operations to the CD-ROM, you must ensure that the CD-ROM has been mounted as foreign or as a Files-11 volume. The application program can then determine, by issuing a GET_TOC function, which tracks (and, therefore, which logical blocks) contain data and which contain audio information.
Programming Audio Applications ![]()
The following list contains information useful in avoiding
problems when writing code using the SCSI audio interfaces:
Application Program Example Using SCSI Audio
Capabilities (VAX only) ![]()
The file SYS$EXAMPLES:CDROM_AUDIO.C contains an example of
an application program that performs the following tasks:
1 Symbolic values for the function codes of SCSI audio commands are defined in SYS$EXAMPLES:CDVERIFY.C. Numeric values appear within parentheses in this table column.
2 For any function code not listed in this table, this field contains a zero.
( Number takes you back )
|
|