Browse Prior Art Database

Multiple ID Field Sector Format

IP.com Disclosure Number: IPCOM000047101D
Original Publication Date: 1983-Sep-01
Included in the Prior Art Database: 2005-Feb-07
Document File: 2 page(s) / 66K

Publishing Venue

IBM

Related People

Peterson, RA: AUTHOR [+3]

Abstract

Direct access storage devices (DASDs) with fixed block architecture (FBA) formats divide the storage space into small blocks of fixed length usually called sectors. Each sector contains an ID field and a data field. The recording surface can be defective in either the ID field or the data field. The ID and data fields are schematically illustrated by line A of Fig. 1. Heretofore, when the defect occurred in the ID field within a sector, the ID was again written in the data field displaced 64 bytes from the normal ID location, as represented by line B of Fig. 1. If there were a defect within this field, the ID would be written in the data field offset by 256 bytes, as represented by line C of Fig. 1.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 59% of the total text.

Page 1 of 2

Multiple ID Field Sector Format

Direct access storage devices (DASDs) with fixed block architecture (FBA) formats divide the storage space into small blocks of fixed length usually called sectors. Each sector contains an ID field and a data field. The recording surface can be defective in either the ID field or the data field. The ID and data fields are schematically illustrated by line A of Fig. 1. Heretofore, when the defect occurred in the ID field within a sector, the ID was again written in the data field displaced 64 bytes from the normal ID location, as represented by line B of Fig. 1. If there were a defect within this field, the ID would be written in the data field offset by 256 bytes, as represented by line C of Fig. 1. That arrangement requires that the ID be read a multiple number of times with separate read ID commands, as illustrated by the flow diagram in Fig. 2. For example, the first command would be a read ID command. A check would be made to determine if the command was a read ID displaced command, as indicated by block 10. Since the command is a read ID command, the ID would be read, as indicated by block 15. Block 20 would determine if the cyclic redundancy check (CRC) was good. If the CRC was not good, a read ID displaced command would be issued and this time block 10 would detect that the command is a read ID displaced command, whereby block 25 would introduce a wait of 64 bytes before the ID would be read by block 15. If the CRC was still...