Re: Cobol Linear search Vs Perfrom Until
From: Lueko Willms (l.willms_at_jpberlin.de)
Date: 07/19/04
- Next message: matteo: "Re: Cobol AS/400 BNF Help Please"
- Previous message: Lueko Willms: "Re: Layout Hell."
- In reply to: Chuck Stevens: "Re: Cobol Linear search Vs Perfrom Until"
- Next in thread: Chuck Stevens: "Re: Cobol Linear search Vs Perfrom Until"
- Reply: Chuck Stevens: "Re: Cobol Linear search Vs Perfrom Until"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 19 Jul 2004 21:25:00 GMT
. Am 16.07.04
schrieb charles.stevens@unisys.com (Chuck Stevens)
auf /COMP/LANG/COBOL
in cd98b2$27c0$1@si05.rsvl.unisys.com
ueber Re: Cobol Linear search Vs Perfrom Until
>> Hmmmmm... Mr Fonesca, this approach makes me... uncomfortable. As I
>> recall it - and my memory is, admittedly, porous - a SEARCH ALL
>> against a table with duplicate entries will return a result for a
>> duplicate key whose position is unpredictable; if you have five
>> duplicate entries the position returned could be for any of them.
CS> The results of a SEARCH ALL are preictable *only when* the data
CS> matches the KEY clause and there are no duplicates.
That means, in my understanding, that there is no way to predict
which of, say, 5 duplicate items in the sorted key are being found by
the WHEN clause.
But:
CS> If either of these criteria is not met, *all bets are off* in
CS> terms of where you land in the table when you get a WHEN hit, and
CS> whether or not you get a WHEN hit on a table entry that is present
CS> (whether the particular key is a duplicate or not).
is something I don't believe.
I am quite convinced that a SEARCH ALL on a table with a sorted KEY
will find a matching item in the table, even if there are duplicates.
It is just not predictable at all, which one of those duplicates is
being matched.
Another question is for the design of that table and that
application -- what sense does it make to search a sorted table with
duplicate keys, unless you want just to ascertain the presence or its
negation of a search item in the table; and if there is a
discriminator among those duplicate key items which the program is
supposed to find out, why not include those discriminators in the
sorting key in the first place?
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela
- Next message: matteo: "Re: Cobol AS/400 BNF Help Please"
- Previous message: Lueko Willms: "Re: Layout Hell."
- In reply to: Chuck Stevens: "Re: Cobol Linear search Vs Perfrom Until"
- Next in thread: Chuck Stevens: "Re: Cobol Linear search Vs Perfrom Until"
- Reply: Chuck Stevens: "Re: Cobol Linear search Vs Perfrom Until"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|