Browse Prior Art Database

Scanning Data to Find a Key Sequence

IP.com Disclosure Number: IPCOM000042501D
Original Publication Date: 1984-May-01
Included in the Prior Art Database: 2005-Feb-03
Document File: 2 page(s) / 48K

Publishing Venue

IBM

Related People

Burns, CS: AUTHOR [+5]

Abstract

A data processor must frequently scan a real-time data stream from a disk file or other device to find a sequence of key bytes (or a higher- valued or lower-valued sequence). Normally, this requires hardware registers and a large amount of hardwired logic, since purely microcoded scans are too slow. Fig. 1 shows a fast logic 10 which uses significantly less hardware and is easier to use. When a scan command is issued, the user specifies the key value, the type of scan to be performed (high, low, equal), and certain parameters that describe where the keys are to be positioned in a 256-byte sector for comparison against the file: length of the key, the separation between the keys, the starting position for the first key, and the ending position for the last key.

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 52% of the total text.

Page 1 of 2

Scanning Data to Find a Key Sequence

A data processor must frequently scan a real-time data stream from a disk file or other device to find a sequence of key bytes (or a higher- valued or lower- valued sequence). Normally, this requires hardware registers and a large amount of hardwired logic, since purely microcoded scans are too slow. Fig. 1 shows a fast logic 10 which uses significantly less hardware and is easier to use. When a scan command is issued, the user specifies the key value, the type of scan to be performed (high, low, equal), and certain parameters that describe where the keys are to be positioned in a 256-byte sector for comparison against the file: length of the key, the separation between the keys, the starting position for the first key, and the ending position for the last key. (The user can create his own 256-byte compare file if he wishes to have variable-length keys.) From this information the file microcode creates a 256-byte compare field with the keys properly positioned in the block. The hardware then compares this block to file sectors, looking for the information requested. Assume a key value hex '01 02 03 FF FE 04 05 06', 8 bytes in length and separated by 5 bytes. The first key starts 7 bytes into the sector. The last one ends at byte 27. From the information the microcode puts two copies of the key in the buffer at the locations indicated. Since the hardware has no counters to keep track of key length and separation, it must have some indicator to specify which parts of the data block are to be compared to the file and which are to be ignored. Microcode creates this indicator for the hardware by searching through the key specified by the user to find one unique 8-bit combination that is not used in any byte of the key. This byte is called the scan delimiter and is inserted into the scan compare field between the keys, to specify areas of the file sector to be ignored during the scan. This is always possible if...