Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Binary Search on a File

Status
Not open for further replies.

CSJedi

Programmer
Apr 3, 2001
2
0
0
US
I was wondering if there was any way that a Binary Search could be used on a file. I know that it can be used on an array but don't know about a file.
 
Hi CS,

You can't do a binary search on a file. You can read it into an array if it's small enough. Or you can create an indexed file out of it, but than you won't have to binary seach it, you can reference the record you're looking for directly.

Let me know if this helps, Jack.
 
Make the file you are trying to read in a "Bit Stream" file...with Realia Cobol, you use at the end of the file name like: COMMAND.COM

 
If your file can be organized as a relative file, you can implement a binary search
of the file by manipulating the relative record number. Doing so assumes that the
file's record sequence is intact, record 1 to record N with no missing records. The
data in the file's records must also have a sequence that is monotonic increasing so
that your program logic can determine where in the record sequence the current
record you've just read is.

HTH,

Jeff Campbell
n8wxs@arrl.net
 
Hi n8wxs,

I would guess also, that the # of recs in the file must be known.

Jack
 
Hi Jack,

If the file can be organized the way I stated with no missing records then the number of records can be determined with a WRITE record followed by a DELETE record. The WRITE will set the relative record key to the current (last) record in the file. Save the key value, DELETE this last record and now the file size is determined.

Or you could open the file and READ sequentially until EOF. :cool:

Or use the first record for housekeeping and store the record count there.

Regards,
Jeff
 
Hi N8,

You're right. Your technical point is well taken, but why you'd want to, I can't imagine. A direct read, using the RBA or RRN as, I stated, would be much more efficient.

Regards, Jack.

 
Hi Jack,

No, you're right. :cool:

An indexed file would be a better approach given CSJedi could reorganize his file to meet my requirement of monotonicity in his file's data. Sound's like primary key to me. :cool:

I've just got relative files on the brain as the current project I'm working uses them.

Regards,
Jeff
 
I am stump on a problem trying to load a table .
The record size is approx 240 ch. I have to load
approx 952 occurrences. I did this

01 crt-table.
05 crt-table-rec occurrences 952 times
accending key is court-table-code
indexed by crt-index.
05 court-table-code pic x(5).
05 court-name pic x(26).
05 court-address pic x(26).
05 court-other-data pic x(183).

set crt-idx to 1
perform until no-more-records
read court-table-file
at end
move 'yes' to no-more-records-flags
If not no-more-records
move court-table-file-court-name to
court-name (crt-idx)
move court-table-file-court-address
to court-address (crt-idx)
set crt-idx up by 1
end-if
end-perform

Thanks!




What is wrong with this. I tried to load the
table and sometimes it works and sometimes it abend
with a soc4???????
 
First thing is that you are not building a KEY. Your court-table-code is not filled in, I am surprised it ever works since this is a key field. You should put a valid value in this field.

Another thing to make sure of is that you never go over 952 occurences. You can put an IF in there to check if over 952 and end the perform otherwise you will just go beyond the end of your table.


if not no-more-records AND
ctr-idx < 953

You would probably want to do some error routine here, like display messages saying too many input records or something like that.

Also, try using a larger number that 952, try 9000 and see if that solves the problem.

Good luck.
 
Viz,

besides the obvious typo's (i hope), are you sure about those 952 records ? If not, and you read more than that, you overshoot your table end, indexing elements outside the range of it's index. I'm not completely sure, but i strongly suspect that's the cause of your S(0C4).
Build in a test on the maximum number of records to be processed to prevent this. If you signal (i.e. display) this, you'll know that you want to process more than 952 records and can consider enlarging your table.

Good luck,
Ronald.
 
One problem with the &quot;What's wrong with this code&quot; code is that there is an IF that is part of the AT END condition. Insert an END-READ before this IF and that problem will go away.
 
Huh ?!!

That response of mine belongs to a totally different thread !
David, did i mess up or did something go wrong ?

Regards,
Ronald.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top