Pure Sequential; Searching A Pure Sequential File - IBM 1130 User Manual

Pure Sequential
In a purely sequential disk data file, your records
are placed on the disk in some logical order, with
no attempt to organize them or to keep track of
where they are placed.
If
a certain record is de-
sired, the disk is searched sequentially until that
record is found.
Searching a Pure Sequential File
Searching a pure sequential file is simple, but
finding any particular record may be time-consuming
in the case of large files. (If you are processing
only a small number of records, however, the effect
on the overall running time may be slight.)
If
you
have a file of 1000 records, you can search for the
item with key KEYXX, using the following FORTRAN
statements:
DO 14 NREC=l, 1000
READ (NFILE'NREC) KEY
IF (KEY -KEYXX) 14, 77, 14
14 CONTINUE
77 KEYXX has been found at record NREC.
KEY is the control key on the disk record, and
KEYXX is the key you are searching for.
If
KEYXX is the 608th item, you will read, check, and
get "no hit" on 607 items before reaching the 608th.
A better way to search such a file is obvious: read
every nth record until you pass the key being sought,
then back up one record at a time until you find
KEYXX.
DO 14 NREC=l, 1000, NTH
IREC = NREC
8 READ (NFILE'IREC) KEY
IF (KEY-KEYXX) 14, 77, 66
66 IREC = IREC-1
GO TO 8
14 CONTINUE
77 KEYXX has been found at record IREC.
If n is 20, you will read and check 32 records
(1, 21, 41, 61, ..... 601, 621) until you have
passed the desired item (KEYXX, the 608th). Then
13 more records in the backing-up portion of the
search (620, 619, 618, ..... 609, 608) must be
read. Here, the "skip" search has reduced your
disk reads from 608 to 45, with a concurrent drop
in processing time.
Section Subsections Page
85 10
I
10 01
A further improvement can be made if you search
first in large increments (say 100), then, when you
pass the desired item, back up with a smaller in-
crement (say 20) and, after passing the desired
item the second time, switch to an increment of 1.
Again, looking for the 608th item, the search will
be - 1, 101, 201, 301, 401, 501, 601, 701, 681,
661, 641, 621, 601, 602, 603, 604, 605, 606, 607,
608, which involves 20 disk reads.
All the methods shown above, however, have one
disadvantage: because they start at record number
1, the disk arm must move back to that record
each time. A more elegant search technique would
involve starting from wherever you found the last
record, rather than from the beginning of the file.
This assumes that the disk arm is still positioned
over the last record, but it will not be so pos itioned
if you have meanwhile used LOCAL or SOCAL sub-
routines or accessed a record in another file on the
same disk. This technique, therefore, is often
impractical.
Another technique involves the method of halving,
sometimes called a binary search. Suppose you
have a file of 1000 records and you want to find the
record whose key is KEYXX. First, halve the file
size to obtain 500, and check the 500th record.
If
you do not find KEYXX there, halve the 500 to obtain
250 and, if the 500th record KEY was higher than
KEYXX, check 500-250 or 250 next; if it was lower,
check 500+250 or 750 next. The increment next
becomes 125, then 63 (62. 5 rounded upward), then
32 (31. 5 rounded upward), etc. Using the previous
example (KEYXX is the 608th item), your search
pattern would have been:
500 first try
low, so +250
750 second try
high, so
-125
625 third try
high, so - 63
562
fourth try
low, so
+ 32
594 fifth try
low, so
+ 16
610 sixth try
high, so 8
602 seventh try
low, so + 4
606 eighth try
low, so
+ 2
hit 608
ninth try
a sequence of only nine disk reads.