MVSFORUMS.com

[psmadhusudhan]

I am having a EMPL table with OCCURS 99 times and ASCNEDING KEY EMPL-ID and INDEXED BY REC-CNT.

Initially in my cobol program I am loading this table reading File 1. File 1 is having 3 records with EMPL-ID's 1,2,3 respectively for each record. So 3 occurences get filled in the EMPL table in ascending order of EMPL-ID.

After this I am searching the EMPL table on EMPL-ID say for example EMPL-ID = 3 using SEARCH ALL. But the equality condition is not satisfying and AT END condition is getting executed.

I would like to know is there any limitaion on SEARCH ALL that all the occurences of table need to be filled completely and there should not be empty occurences. Or is there any other way using SEARCH ALL to get the desired result.
_________________
Thanks
Madhu Sudhan

[dbzTHEdinosauer]

if you would bother to read the programmers application guide and the programmers reference,
or even searched the board
before bothering us with your question on the basics of SEARCH ALL,
you would have found that yes,
if you have a fixed length table,
all items need to be appropriately populated.

it is just as quick to use a SEARCH
or
just PERFORM incrementing the INDEX UNTIL find or end of items maintained by a counter of actual items in the table.

than using a SEARCH ALL with less than 128 items ,
especially a fixed length table that is not completely populated.
A SEARCH ALL performs best with a properly populated ODO table.
_________________
Dick Brenholtz
American living in Varel, Germany

[psmadhusudhan]

Thanks Dick for your reply
_________________
Thanks
Madhu Sudhan

[kolusu]

psmadhusudhan,

You need to initialize the table to HIGH-VALUES for SEARCH ALL to work properly. when initializing an array to be used in a binary or sequential search for which the data is known to be in ascending sequence, the unused portion of the array must be initialized to high values to get a binary search to function properly. A sequential search will work without this, but it can be made more efficient when a "not found" condition is being executed by exiting the search when the array key is > the search key.

Kolusu

[RonB]

[dbzTHEdinosauer]

there is a point where the binary search will use less machine time than the serial search.

a binary search only out-performs in the sense that there are less comparisions.

both do an increment of displacement
both do a compare (for end of search)
both do a compare of the item.

but binary search has to continually:

• maintain the current high and low item
• do a divide of existing range based on the high and low
• calculate the displacement

i have seen literature in the 80's that suggested 50 totals items, and other that suggested 126 (128?)
which is the break even point where the binary search is actually faster.

I will find a link to document that has based my understanding.
_________________
Dick Brenholtz
American living in Varel, Germany

[haatvedt]

I had a situation where we loaded a large VSAM file into memory to be searched by online CICS application. We encountered problems trying to emulate the VSAM START verb using COBOL SEARCH ALL verb when the key does not exist in the array. To get around this we had to write our own BINARY SEARCH in COBOL.

The array which we are searching contains about 240,000 entries.

We found that the hand coded BINARY SEARCH was significantly more efficient in terms of cpu usage than the COBOL "SEARCH ALL" verb.

The code was modeled after KNUTH's binary search, see this link

http://www.z390.org/contest/p21/P21DW1.TXT

the key to maximizing the performance of the code below was to use PIC S9(8) COMP for all the binary fields. This avoids the check for binary overflow in the generated code. Also we used the compiler option TRUNC(OPT) to avoid the code generated to check for truncation.

Note --> the IF statement after the PERFORM loop is to check for a "not found" condition. To emulate the VSAM START command we need to position the INDEX to the first row which is >= the search key.

[dbzTHEdinosauer]

as a follow-up to this discussion.

disregard my reference to 126 - I can not support this figure.
though thru observation over the last few decades,
i usually find that if there are less than 50 items,
I do a perform varying,
more than 50 items, I do a binary search.

as far as psmadhusudhan problem.
I understand the need to have a potential 100 item-table.
but it should always be ODO.
as even the book says,
with less than 4 items a binary search is not the best.

to force a binary search on a 100 item fixed length table
when there are only actually 3 active items,
IMUO,
is not among the best coding practices.
_________________
Dick Brenholtz
American living in Varel, Germany

[Terry_Heinze]

Although I realize that there is a trade off point at which a binary search will/will not outperform a serial search, I've often coded a binary search regardless of the current number of occurrences knowing that 9 times out of 10, the table size will eventually exceed that trade off value. And I almost always use the ODO clause since the table size I've loaded are usually not known until execute time.
_________________
....Terry