Document revision date: 15 July 2002

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:

1. Compute an uncorrected medium address using the following dimensions:
   Number of sectors per track = 26
   Number of tracks per cylinder = 1
   Number of cylinders per disk = 77
2. Correct the computed address for interleaving and track-to-track skew (in that order) as shown in the following Compaq Fortran for OpenVMS statements. ISECT is the sector address and ICYL is the cylinder address computed in Step 1.
   Interleaving: ITEMP = ISECT*2
   IF (ISECT .GT. 12) ITEMP = ITEMP-25
   ISECT = ITEMP
   Skew:
   ISECT = ISECT+(6*ICYL)
   ISECT = MOD (ISECT, 26)
   
3. Set the sector number in the range of 1 through 26 as required by the hardware:

   ISECT = ISECT+1

4. Adjust the cylinder number to cylinder 1 (cylinder 0 is not used):

   ICYL = ICYL+1

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:

• Media format---Describes the structure of sectors on a disk and the algorithms for replacing bad blocks
• Drive-to-controller interconnect---Describes the connection between a drive and its controller
• Controller-to-host communications---Describes how hosts request controllers to transfer data

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:

• DSA disks contain no bad blocks. The hardware and the disk class driver (DUDRIVER) function to ensure a logically contiguous range of good blocks. If any block in the user area of the disk develops a defective area, all further access to that block is revectored to a spare good block. Consequently, it is never necessary to run the Bad Block Locator utility (BAD) on DSA disks. There is no manufacturer's bad block list and the file BADBLK.SYS is empty. (The Verify utility, which is invoked by the ANALYZE /DISK_STRUCTURE /READ_CHECK command, can be used to check the integrity of newly received disks.) See Section 2.2.11.1 for more information about bad block replacement for DSA disks.
• Insert a WAIT statement in your SYSTARTUP_V5.COM file on VAX systems, or your SYSTARTUP_VMS.COM file on Alpha systems, prior to the first MOUNT statement for a DSA disk. The wait period should be about 2 to 4 seconds for the UDA50 and about 30 seconds for the HSC50. The wait time is controller-dependent and can be as much as several minutes if the controller is offline or otherwise inoperative. If this wait is omitted, the MOUNT request may fail with a "no such device" status.
• The DUDRIVER and the DSA device controllers allow multiple, concurrently outstanding QIO requests. The order in which these requests complete might not be in the order in which they were issued.
• All DSA disks can be dual-ported, but only one HSC/UDA controller can control a disk at a time (see Section 2.2.3).
• In many cases, you can attach a DSA disk to its controller on a running system and then use it without manual intervention.
• DSA disks and the DUDRIVER do not accept physical QIO data transfers or seek operations.

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 read

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

2.2.12 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:

• ERRFMT messages show that the disk is write-locked.
• The disk enters mount verification and hangs.
• DCL command SHOW DEVICE output shows that the disk is write-locked.
• Error messages occur from programs and utilities attempting to write to the disk.

If the disk becomes write-locked, you should use the following procedure:

1. Shut down the system.
2. Use standalone BACKUP to create a full backup of the disk.
3. Format the disk with the disk formatter.
4. Restore the disk from the backup using standalone BACKUP. Note that any files with sectors flagged with a forced error may be corrupted and may need to be restored from a previous backup.

If errors occurring during replacement operations persist, call Compaq Customer Services.

2.2.13 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:

• Static and dynamic bad block replacement (BBR)
• Error correction code (ECC)
• Reexecution of read or write operations within the SCSI drive
• Reexecution of read or write operations by the SCSI disk class driver

All SCSI disks supplied by Compaq 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.

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

Table 2-1 lists the SCSI audio commands supported by the SCSI disk class driver.

Table 2-1 SCSI Disk Class Driver Audio Commands

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.

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 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 Section 2.2.14.2).

p2

Size of the 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. Table 2-2 defines the fields that appear in an AUCB; these fields are shown in Figure 2-3. See SYS$EXAMPLES:CDROM_AUDIO.C for a code example that shows how an AUCB is defined in the C programming language.

Figure 2-3 Audio Control Block (AUCB)

Table 2-2 Contents of AUCB

Field	Use
Audio Function Code	Numeric or symbolic code representing the audio function desired by the application program. (See Table 2-1.) 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 Code1 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. Figure 2-4 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. Figure 2-4 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 Code1 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 Table 2-3 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 Figure 2-4.

Figure 2-4 Output Channel Selection and Volume Settings for CD-ROM Ports as Used by the SET_VOLUME Function

	privacy and legal statement
6136PRO_007.HTML