Cobol - Cobol Linear search Vs Perfrom Until

Author

Cobol Linear search Vs Perfrom Until

Aru

2004-07-16, 3:55 pm

Does Cobol linear search provides better performance against Perform
Until
My isssue is -
I have a cobol program which was changed from Binary search to to
Perform Until to handle and process muliple occurances of search key.
This is a requirement that I will have multiple occurances for the
search key.

After the change my program performance deteriorate, which is, very
well expected, but the magnitude is 12 to 13 times more. Earlier, I
had my data processed in 10 CPU minutes and now it takes about 130 CPU
minutes.

Any suggestion. Please help

Thanks
Aru

Glenn Someone

2004-07-16, 3:55 pm

How many table entries are there? I would say the Binary search was
there likely for a very good reason. Is this data sorted now? I
assume it was before this programming change? If so, you would likely
find all your other occurrences in close proximity to the one that the
binary search finds. I would use that in writing this instead of
going to an infinitely worse algorithm. Unfortunately, it's not too
hard to find cases where people make poor logical choices in changing
programs - nothing surprising really since most people hired by
business in my experience seems to not have the proper training in
program design.

COBOL linear search is no different than PERFORM UNTIL performance
wise. The same thing basically happens. My suggestion is to undo the
damage of this change and then write something that will find all your
occurrences.

On 16 Jul 2004 09:27:53 -0700, arundj@mailcity.com (Aru) wrote:

>Does Cobol linear search provides better performance against Perform
>Until
>My isssue is -
>I have a cobol program which was changed from Binary search to to
>Perform Until to handle and process muliple occurances of search key.
>This is a requirement that I will have multiple occurances for the
>search key.
>
>After the change my program performance deteriorate, which is, very
>well expected, but the magnitude is 12 to 13 times more. Earlier, I
>had my data processed in 10 CPU minutes and now it takes about 130 CPU
>minutes.
>
>Any suggestion. Please help
>
>Thanks
>Aru

Frederico Fonseca

2004-07-16, 3:55 pm

On 16 Jul 2004 09:27:53 -0700, arundj@mailcity.com (Aru) wrote:

>Does Cobol linear search provides better performance against Perform
>Until
>My isssue is -
>I have a cobol program which was changed from Binary search to to
>Perform Until to handle and process muliple occurances of search key.
>This is a requirement that I will have multiple occurances for the
>search key.
>
>After the change my program performance deteriorate, which is, very
>well expected, but the magnitude is 12 to 13 times more. Earlier, I
>had my data processed in 10 CPU minutes and now it takes about 130 CPU
>minutes.
I don't know which is faster, but I think it will depend on the
compiler vendor/version.

So for a suggestion
For the times I had duplicate keys on a table what I have done is a
combination of binary search as a first step, and then a perform
varying by -1 to get the first occurrence.
e.g.

(I had the binary search coded manually, but I think the search all
will also work).
search all
when blabla
set found to true.
end search

if found
perform varying index from index by -1
until index < 1
or var(index) not = search-key
continue
end-perform
index now contains the first occurrence of search-key
end-if

In some cases I would also do a perform varying +1 to get the last
occurrence.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

docdwarf@panix.com

2004-07-16, 3:55 pm

In article <9c9fdae5.0407160827.7b64a9b7@posting.google.com>,
Aru <arundj@mailcity.com> wrote:
>Does Cobol linear search provides better performance against Perform
>Until

Not in my experience, no; from what I have seen their performances (on an
IBM mainframe platform) are about the same.

>My isssue is -
>I have a cobol program which was changed from Binary search to to
>Perform Until to handle and process muliple occurances of search key.
>This is a requirement that I will have multiple occurances for the
>search key.

Gah... this sounds like a classic 'all ya gotta do it' solution, something
that someone tossed off without any idea of what is going on during
processing.

>
>After the change my program performance deteriorate, which is, very
>well expected, but the magnitude is 12 to 13 times more. Earlier, I
>had my data processed in 10 CPU minutes and now it takes about 130 CPU
>minutes.
>
>Any suggestion. Please help

First suggestion... take up a hoby to keep you occupied during the
now-longer run times... knitting or painting, perhaps.

Second suggestion... when you have multiple occurrences of a key in the
table there has to be something to tell you whether to take the first or
the second or the third; restructure the table to include this unique
identified in the index and go back to a SEARCH ALL.

Third suggestion... break up the table. The first version of it will
contain all the unique keys, the second will contain only the duplicate
key entries. SEARCH ALL against the first, SEARCH/PERFORM UNTIL against
the second. (This method is based on the assumption that there will be an
overwhelmingly larger number of unique entries in the first table; for
example, the first table has 40,000 unique entries, out of which 3,000 or
so have, say, five duplicates each. SEARCH ALL will satisfy 37,000
possibilities and the remainder will have to go against the second table;
you'll need to add a flag to the first to tell the code whether a SEARCH
against the second is needed.)

DD

docdwarf@panix.com

2004-07-16, 3:55 pm

In article <3e1gf0pop10e6hn7tikg90ocvd9jopvd7h@4ax.com>,
Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:

[snip]

>search all
>when blabla
> set found to true.
>end search
>
>if found
> perform varying index from index by -1
> until index < 1
> or var(index) not = search-key
> continue
> end-perform
> index now contains the first occurrence of search-key
>end-if
>
>In some cases I would also do a perform varying +1 to get the last
>occurrence.

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. If your search returned the
first occurrence of the key then -1 would bring you into another key's
data and if the search returned the last a +1 would do the same; it seems
to me that you'd have to do both -1 and +1 to get the full range... and
all this p

ing and poking about, above and below, makes me...
uncomfortable.

But hey... what's a programmer's comfort when compared to the simplicity
of an 'all ya gotta do is' solution?

DD

Chuck Stevens

2004-07-16, 3:55 pm

<docdwarf@panix.com> wrote in message news:cd95fu$8vk$1@panix5.panix.com...

> 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.

It makes me even more uncomfortable. It may be true in some implementations
that a SEARCH ALL will give you one of the duplicates in the table, but the
COBOL standard goes to some pains not to require *any* particular result,
and I would certainly argue against expecting such a result in general.

The results of a SEARCH ALL are preictable *only when* the data matches the
KEY clause and there are no duplicates. If either of these criteria is not
met, *all bets are off* in terms of where you land in the table when you get
a WHEN hit, and whether or not you get a WHEN hit on a table entry that is
present (whether the particular key is a duplicate or not).

-Chuck Stevens

Frederico Fonseca

2004-07-16, 3:55 pm

On 16 Jul 2004 14:06:54 -0400, docdwarf@panix.com wrote:

>In article <3e1gf0pop10e6hn7tikg90ocvd9jopvd7h@4ax.com>,
>Frederico Fonseca <real-email-in-msg-spam@email.com> wrote:
>
>[snip]
>
>
>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. If your search returned the
>first occurrence of the key then -1 would bring you into another key's
>data and if the search returned the last a +1 would do the same; it seems
>to me that you'd have to do both -1 and +1 to get the full range... and
>all this p

ing and poking about, above and below, makes me...
>uncomfortable.
DD,

as I mentioned on my post
-----
(I had the binary search coded manually, but I think the search all
will also work).
----

I start using this on tables that had over 30000 entries, and as they
had duplicates I was using a binary search (manually coded), and then
two performs afterwards to get the lower and upper range.
Never tried the Search All on this case so I'm not sure if it does.

And the real code catters for change of key, and holds the correct
index.

I have also use the same construct on some VB programs on arrays with
100000+ entries. Works very well.

>
>But hey... what's a programmer's comfort when compared to the simplicity
>of an 'all ya gotta do is' solution?
>
>DD

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

JerryMouse

2004-07-16, 8:55 pm

Aru wrote:
> Does Cobol linear search provides better performance against Perform
> Until
> My isssue is -
> I have a cobol program which was changed from Binary search to to
> Perform Until to handle and process muliple occurances of search key.
> This is a requirement that I will have multiple occurances for the
> search key.
>
> After the change my program performance deteriorate, which is, very
> well expected, but the magnitude is 12 to 13 times more. Earlier, I
> had my data processed in 10 CPU minutes and now it takes about 130 CPU
> minutes.

How big is the table you're searching, how many times are you searching it?

Unless the table is HUGE (tens of thousands of entries) or you're searching
it millions of times, it could be there's another flaw in the program. To
increment an index and do a compare takes nanoseconds; millions of them is
measured in a few seconds, not a hundred minutes.

A SEARCH on a 1000-item table does about 10 compares plus attendant
computations. A SEARCH ALL (or PERFORM UNTIL) does, on average, 500. The
time difference between 10 and 500 is negligible.

Glenn Someone

2004-07-16, 8:55 pm

Why should it? It's breaking some mold you were taught is it not?
Unfortunately, people that have heard stuff like this are people that
will take this binary search and then recode it into a sequential one
when more understanding and thought is required than just reciting a
rote statement heard once upon a time in a classroom.

If it helps to put your mind at ease, please study what a binary
search does. The only requirement of a binary search to make it
perform successfully is that the data are sorted. Only requirement.
If you have duplicate data, it will locate the first key item
encountered by the algorithm. Yes the particular ordered key item you
arrive upon is unpredictable, but that doesn't make the algorithm
unusable. This is all that is being asked of the search in this case.
The only expectation out of the binary search is to locate A key item.
Nothing more. Then it is the programmer's job to locate all the
entries, which should be a very simple task.

It is unfortunate that people carry these silly "truisms" around that
were only devised to make the lives of programming instructors easier
(I could catalog a ton of them). In fact, I've heard the arguments in
the quote dozens of times. However, it is a wiser venture to learn
the mechanics of all these things. Unfortunately for instructors,
though, it doesn't make their job easier so they use these "truisms".
Unfortunately for their students, though, it enables them to not learn
everything they need to know and closes off their minds to learning
more.

Yes the position you arrive upon is unpredictable, but that doesn't
make the algorithm unpredictable. It also doesn't justify throwing
out the baby with the bath water and scrapping a superior algorithm
for one that is not.

On Fri, 16 Jul 2004 11:55:29 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

><docdwarf@panix.com> wrote in message news:cd95fu$8vk$1@panix5.panix.com...
>
>
>It makes me even more uncomfortable. It may be true in some implementations
>that a SEARCH ALL will give you one of the duplicates in the table, but the
>COBOL standard goes to some pains not to require *any* particular result,
>and I would certainly argue against expecting such a result in general.
>
>The results of a SEARCH ALL are preictable *only when* the data matches the
>KEY clause and there are no duplicates. If either of these criteria is not
>met, *all bets are off* in terms of where you land in the table when you get
>a WHEN hit, and whether or not you get a WHEN hit on a table entry that is
>present (whether the particular key is a duplicate or not).
>
> -Chuck Stevens

Frederico Fonseca

2004-07-16, 8:55 pm

On Fri, 16 Jul 2004 16:28:08 -0500, "JerryMouse" <nospam@bisusa.com>
wrote:

>Aru wrote:
>
>How big is the table you're searching, how many times are you searching it?
>
>Unless the table is HUGE (tens of thousands of entries) or you're searching
>it millions of times, it could be there's another flaw in the program. To
>increment an index and do a compare takes nanoseconds; millions of them is
>measured in a few seconds, not a hundred minutes.
>
>A SEARCH on a 1000-item table does about 10 compares plus attendant
>computations. A SEARCH ALL (or PERFORM UNTIL) does, on average, 500. The
>time difference between 10 and 500 is negligible.

I think you meant
A SEARCH ALL on a 1000-item table does about 10 compares plus
attendant computations. A SEARCH (or PERFORM UNTIL) does, on average,
500. The time difference between 10 and 500 is negligible.
>

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

William M. Klein

2004-07-16, 8:55 pm

"Glenn Someone" < dontspamme@whydoyouneedmyaddressspammers
.com> wrote in message
news:rkhgf01hkvc8amalakdl0p1ba7o2u878eq@
4ax.com...
> Why should it? <snip>
> Yes the position you arrive upon is unpredictable, but that doesn't
> make the algorithm unpredictable. It also doesn't justify throwing
> out the baby with the bath water and scrapping a superior algorithm
> for one that is not.
>

Glenn,
Maybe I am misunderstanding you, but ...

If one codes a SEARCH ALL against a table that may or may not find the table
enttry that you want (i.e. it might be the first of duplicates, the second of
duplicates, or a random entry that doesn't even match any of the duplicate
entries), then I can't imagine what USE that would be.

A Standard conforming compiler *need not* even find one of the "duplicate"
entries when a SEARCH ALL is done - against a table with multiple entries with
the same key. The Standard (current and past) is pretty clear (as stated by
Chuck earlier) that if there are multiple table entries with the same key value,
then "results are unpredictable".

I don't think this is a case of throwing the baby out with the bathwater - but
rather is a case of avoiding throwing a baby into the middle of an olympic size
pool <G>.

--
Bill Klein
wmklein <at> ix.netcom.com

Glenn Someone

2004-07-16, 8:55 pm

I think you

the two. SEARCH is a serial search, while SEARCH
ALL is the binary one.

In Big O notation (algorithms are almost always measured by their
worst case, never their average or best), the serial search is O(n),
while binary search is O(log n) (log base 2).

Big O of the serial search of 1000 table elements = 1000
Big O of the binary search of 1000 table elements = 10

Essentially the moment we reach the 11th element (21st if I am
generous on calculating midpoints) on a serial search, the binary
search does it. If we go into multiple searches, the choice is
obvious.

"It seems that the excuse that the CPU is fast enough, or the problem
will be upgraded out of seems all too common." There's no purpose or
logical point to using a markedly inferior algorithm because of fears
of not heeding the truisms heard in the classroom.

On Fri, 16 Jul 2004 16:28:08 -0500, "JerryMouse" <nospam@bisusa.com>
wrote:

>A SEARCH on a 1000-item table does about 10 compares plus attendant
>computations. A SEARCH ALL (or PERFORM UNTIL) does, on average, 500. The
>time difference between 10 and 500 is negligible.
>

Chuck Stevens

2004-07-16, 8:55 pm

Unfortunately, I don't have time to respond at length, and I'm going to be
out-of-pocket for the next w

.

What I was addressing was SEARCH ALL. SEARCH ALL does whatever the
applicable COBOL standard says it's supposed to do and, like it or not, the
applicable COBOL standards require that the data that's the target of SEARCH
ALL be in order and that it contain no duplicates, and additionally state
that the results are undefined if these rules aren't followed.

I know of implementations that give you an arbitrary duplicate, others that
give you the first, but the COBOL standard doesn't require any
implementation to do either one, or to do anything particular in the event
of an ordering problem.

I do know what a "binary search" does. My point is that SEARCH ALL is not a
synonym for that, the rules for SEARCH ALL are strict, and the results of
SEARCH ALL are undefined in standard COBOL if the rules about how the data
must be ordered aren't followed.

-Chuck Stevens.

"Glenn Someone" < dontspamme@whydoyouneedmyaddressspammers
.com> wrote in
message news:rkhgf01hkvc8amalakdl0p1ba7o2u878eq@
4ax.com...[color=darkred]
> Why should it? It's breaking some mold you were taught is it not?
> Unfortunately, people that have heard stuff like this are people that
> will take this binary search and then recode it into a sequential one
> when more understanding and thought is required than just reciting a
> rote statement heard once upon a time in a classroom.
>
> If it helps to put your mind at ease, please study what a binary
> search does. The only requirement of a binary search to make it
> perform successfully is that the data are sorted. Only requirement.
> If you have duplicate data, it will locate the first key item
> encountered by the algorithm. Yes the particular ordered key item you
> arrive upon is unpredictable, but that doesn't make the algorithm
> unusable. This is all that is being asked of the search in this case.
> The only expectation out of the binary search is to locate A key item.
> Nothing more. Then it is the programmer's job to locate all the
> entries, which should be a very simple task.
>
> It is unfortunate that people carry these silly "truisms" around that
> were only devised to make the lives of programming instructors easier
> (I could catalog a ton of them). In fact, I've heard the arguments in
> the quote dozens of times. However, it is a wiser venture to learn
> the mechanics of all these things. Unfortunately for instructors,
> though, it doesn't make their job easier so they use these "truisms".
> Unfortunately for their students, though, it enables them to not learn
> everything they need to know and closes off their minds to learning
> more.
>
> Yes the position you arrive upon is unpredictable, but that doesn't
> make the algorithm unpredictable. It also doesn't justify throwing
> out the baby with the bath water and scrapping a superior algorithm
> for one that is not.
>
> On Fri, 16 Jul 2004 11:55:29 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
news:cd95fu$8vk$1@panix5.panix.com...[color=darkred]
a[color=darkred]
implementations[color=darkred]
the[color=darkred]
the[color=darkred]
not[color=darkred]
get[color=darkred]
is[color=darkred]

Glenn Someone

2004-07-16, 8:55 pm

You likely are misunderstanding me.

If the SEARCH ALL doesn't perform as expected, then that isn't the
fault of the programmer who expects a binary search and does not get
one. One of the many failures of the "COBOL standard" if the
hard-wired verbs defined in the standard do not perform in a
consistent manner across all platforms. If I notice a verb is
inconsistent, I stop using it and code its equivalent.

I tend to ignore using SEARCH and INSPECT for this very reason.
Examples of failures out of many failures of the standard.

Educate yourselves and know what is going on for yourself and don't
listen to this regurgitated stuff.

On Fri, 16 Jul 2004 22:03:00 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Glenn,
> Maybe I am misunderstanding you, but ...
>
>A Standard conforming compiler *need not* even find one of the "duplicate"
>entries when a SEARCH ALL is done - against a table with multiple entries with
>the same key.

Michael Mattias

2004-07-16, 8:55 pm

A real simple way to speed up a linear search.....

Sort the table to bve serached
When table-value(sub) > target
exit linear search with notfound

-
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com

"JerryMouse" <nospam@bisusa.com> wrote in message
news:DpKdnaTDdY311WXdRVn-sA@giganews.com...[color=darkred]
> Aru wrote:

Michael Mattias

2004-07-16, 8:55 pm

A real simple way to speed up a linear search.....

Sort the table to bve serached
When table-value(sub) > target
exit linear search with notfound

(No you don't want to use the SEARCH verb to do this, because that will look
at all the entries even when there is no longer a possibility the item will
be found)

Alternately in your case...

Do your binary search (SEARCH ALL) on your sorted table... when you get a
hit, decrease your index in a loop to find where "target" values start in
table, then scan though them in forward direction until you find the one you
want or the key changes; that is, let SEARCH ALL get you "on the correct
block" and then walk from house to house.

-
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com

"JerryMouse" <nospam@bisusa.com> wrote in message
news:DpKdnaTDdY311WXdRVn-sA@giganews.com...[color=darkred]
> Aru wrote:

Don Leahy

2004-07-16, 8:55 pm

One possibility is to add an arbitrary field (a sequence number, say) to the
key to make it unique. Then you can go back to using SEARCH ALL.

HTH

William M. Klein

2004-07-16, 8:55 pm

SEARCH ALL is *well defined* and portable and predictable *IF* you follow the
well documented rules.

If you have a table that has "unique" key values, then using SEARCH ALL will
*find* the expected entry and branch to AT END if there is no match.

Although SEARCH ALL is definitely NOT defined as a "binary search" (and is not
implemented as such in all current or past COBOL compilers), it is documented as
"non-sequential" - and I have never (personally) heard of an implementation
where it is not as fast or faster than a linear search - especially for "large"
tables (where "large" means that for the compilers algorithm, the "expected
hit" is at or before where it would be on a linear search).

You can avoid using SEARCH ALL (or even SEARCH) and INSPECT if you don't have
the time to learn and understand the WELL documented rules, but I certainly
would not recommend that to others.

Learn when the Standard COBOL statements are and are not well-defined, then use
the "best statement" for the programming task ahead of you (is my personal
suggestion).

--
Bill Klein
wmklein <at> ix.netcom.com
"Glenn Someone" < dontspamme@whydoyouneedmyaddressspammers
.com> wrote in message
news:h2mgf09ve2b9rgk3hk460krjla9427g99s@
4ax.com...[color=darkred]
> You likely are misunderstanding me.
>
> If the SEARCH ALL doesn't perform as expected, then that isn't the
> fault of the programmer who expects a binary search and does not get
> one. One of the many failures of the "COBOL standard" if the
> hard-wired verbs defined in the standard do not perform in a
> consistent manner across all platforms. If I notice a verb is
> inconsistent, I stop using it and code its equivalent.
>
> I tend to ignore using SEARCH and INSPECT for this very reason.
> Examples of failures out of many failures of the standard.
>
> Educate yourselves and know what is going on for yourself and don't
> listen to this regurgitated stuff.
>
> On Fri, 16 Jul 2004 22:03:00 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
with[color=darkred]

Richard

2004-07-16, 8:55 pm

docdwarf@panix.com wrote

> so have, say, five duplicates each. SEARCH ALL will satisfy 37,000
> possibilities and the remainder will have to go against the second table;
> you'll need to add a flag to the first to tell the code whether a SEARCH
> against the second is needed.)

A 'flag' such as a number that is zero or the subscript of the chained
entries in the second table perhaps ?

Warren Simmons

2004-07-17, 3:55 am

William M. Klein wrote:

>SEARCH ALL is *well defined* and portable and predictable *IF* you follow the
>well documented rules.
>
>If you have a table that has "unique" key values, then using SEARCH ALL will
>*find* the expected entry and branch to AT END if there is no match.
>
>Although SEARCH ALL is definitely NOT defined as a "binary search" (and is not
>implemented as such in all current or past COBOL compilers), it is documented as
>"non-sequential" - and I have never (personally) heard of an implementation
>where it is not as fast or faster than a linear search - especially for "large"
>tables (where "large" means that for the compilers algorithm, the "expected
>hit" is at or before where it would be on a linear search).
>
>You can avoid using SEARCH ALL (or even SEARCH) and INSPECT if you don't have
>the time to learn and understand the WELL documented rules, but I certainly
>would not recommend that to others.
>
>Learn when the Standard COBOL statements are and are not well-defined, then use
>the "best statement" for the programming task ahead of you (is my personal
>suggestion).
>
>
>
When I was a pup, one of the things I was charged with was conducting
the scheduling of purchased training aids for COBOL. Among those
I recall, way back then, that the vendor of the aids had made a case
for each type of search, and gave the plus and minus of each.

At that time, our COBOL programmers, had not begun to use the various
methods of sorting in COBOL. Their hardware, file sizes, and other
opportunities were such little time was disputing what they had been
taught, or debating how best. Management was most interested in
getting the job done with the tools at hand, and with the best knowhow
we could by and use. We did. The only difference between then and now,
as I see it, is the size of files, the speed of computers, and the
uneven training
provided.

If what I have learned reading this newsgroup for the last several years is
any measure, Mr. Klein is right 99/100 of the time, and when he is not
he admits it.

However, this thread has introduced to me some methods that I had
not been aware of, and it has been a refreshing thread.

Thank you , all.

Warren Simmons

Glenn Someone

2004-07-17, 3:55 am

Mr. Mattias gets it. Unfortunately most here would be "very
uncomfortable" with it.

But one important caveat. It's never a good thing performance wise to
sort a table just to be able to perform a binary search, unless the
payback for doing it is significant. While the binary search beats
the pants off the sequential search, sorting the data can and will
negate that benefit and then some, unless you do perform 1000's of
searches.

And incidentally, we did have tables when I was working which were
searched once for every transaction record. While the tables were 150
units in size, it still benefitted us greatly to use binary searching.

On Fri, 16 Jul 2004 22:46:40 GMT, "Michael Mattias"
<michael.mattias@gte.net> wrote:

>Sort the table to bve serached

>Do your binary search (SEARCH ALL) on your sorted table... when you get a
>hit, decrease your index in a loop to find where "target" values start in
>table, then scan though them in forward direction until you find the one you
>want or the key changes; that is, let SEARCH ALL get you "on the correct
>block" and then walk from house to house.
>
>-
>Michael Mattias
>Tal Systems, Inc.
>Racine WI
>mmattias@talsystems.com

Glenn Someone

2004-07-17, 3:55 am

Just some general thoughts:

1) On both suggestions, it would have been a hard sell in my
experience to change any table, but very hard to change the tables in
these manners. One must remember sometimes that in changing a table
it requires recompilation and retesting of not just that program but
every program that uses that table, and that management can often be
hard pressed to agree to changes that can often be deemed unjustified
(in an economic - time sense). The main point I'm thinking is that it
would be very hard to justify these changes if they were presented -
I've had two bosses that would reject both of these suggestions as
"waste of labour resources" (or whatever nifty manager speak you want
to attach to them).

2) The third suggestion is pretty convoluted, IMO. Would this be
really possible or reasonable in all cases? Personally, I know I
would flunk this option as a code reviewer (for about three different
reasons I can think of off the top of my head).

On 16 Jul 2004 13:57:58 -0400, docdwarf@panix.com wrote:

>Second suggestion... when you have multiple occurrences of a key in the
>table there has to be something to tell you whether to take the first or
>the second or the third; restructure the table to include this unique
>identified in the index and go back to a SEARCH ALL.
>
>Third suggestion... break up the table. The first version of it will
>contain all the unique keys, the second will contain only the duplicate
>key entries. SEARCH ALL against the first, SEARCH/PERFORM UNTIL against
>the second. (This method is based on the assumption that there will be an
>overwhelmingly larger number of unique entries in the first table; for
>example, the first table has 40,000 unique entries, out of which 3,000 or
>so have, say, five duplicates each. SEARCH ALL will satisfy 37,000
>possibilities and the remainder will have to go against the second table;
>you'll need to add a flag to the first to tell the code whether a SEARCH
>against the second is needed.)
>
>DD

JerryMouse

2004-07-17, 3:55 am

Glenn Someone wrote:
> I think you

the two. SEARCH is a serial search, while SEARCH
> ALL is the binary one.

I had it right - my fingers screwed up. Your rendition is closer to the
truth:

SEARCH = serial search
SEARCH ALL = non-serial search (but not necessarily binary)

>
> In Big O notation (algorithms are almost always measured by their
> worst case, never their average or best), the serial search is O(n),
> while binary search is O(log n) (log base 2).
>
> Big O of the serial search of 1000 table elements = 1000
> Big O of the binary search of 1000 table elements = 10
>
> Essentially the moment we reach the 11th element (21st if I am
> generous on calculating midpoints) on a serial search, the binary
> search does it. If we go into multiple searches, the choice is
> obvious.
>
> "It seems that the excuse that the CPU is fast enough, or the problem
> will be upgraded out of seems all too common." There's no purpose or
> logical point to using a markedly inferior algorithm because of fears
> of not heeding the truisms heard in the classroom.
>

No, it's not obvious. The original poster said they converted a binary
search to a PERFORM ... UNTIL. My position is that, in most applications, it
doesn't matter whether it's a SEARCH, SEARCH ALL, PERFORM ... UNTIL, or a
banana. The time difference is almost immeasurably small.

Observations on this thread have wandered all over the SEARCH terrain. Some
observations on the observations:

1. "A SEARCH ALL on a table with duplicate fields generates unpredictable
results." Well, how unpredictable? 2 + 2 = 7 is closer to the truth than 2 +
2 = purple. Will the verb always return one of the duplicates? Or will it
sometimes return change for a dollar? If the verb always returns one of the
duplicates, that might be good enough (Do I have ANYBODY named "Jones" in
the database?).

2. "Sort the table then you can use SEARCH ALL" If I were going to sort
the data why couldn't I be looking for what I wanted in the first place?
Unless I sort the table once and use the sorted, resulting table over and
over.

And one new observation:

For a humongous table, write the table as an ISAM file and check the file.
This, in many cases, will be faster. Here's why: For a HUGE table that won't
fit in memory, the OS will do bags and bags of memory paging, especially for
a binary sort. For an ISAM file the OS will probably do ONE I/O operation
(because the OS cleverly kept the key file in memory).

Anyway, I still suggest the original problem (10 minutes of CPU time vs. 140
minutes) is probably not the result of changing the lookup method.

Glenn Someone

2004-07-17, 3:55 am

IF...that's the point. The rules are not set out clearly by the
standard and are inconsistent across compilers and platforms. That
much has been stated within this thread.

And that's funny. Every book and instructor I've heard and read has
stated that SEARCH ALL = binary search. Care to enlighten us on what
the exact method is used if it is not the binary search? If it is the
binary search, then the standard is flawed because the binary search
does NOT require all table keys to be unique.

And I'm the type of programmer to avoid as any headaches as possible.
In my experience, SEARCH and INSPECT are both pure headache generators
for two reasons: 1) They are not well defined and consistent across
platforms. and 2) They are hard-wired procedures and one must accept
and program around the actions one interprets them to perform, no
matter how cryptic they are, if one chooses to use them.

With INSPECT I would go to reason 3) The results of the statement are
not 100% predictable in any event. By this I mean if I were to
produce a number of questions listing INSPECT statements and data
types, and asking for results of the INSPECT statement, most people
could not answer all of them correctly. In fact, I've found when I've
used rudimentary INSPECT statements, I've had to educate every person
that came in contact with that program about it.

I think all programs should be simple, elegant, and fast.

On Fri, 16 Jul 2004 23:14:02 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>SEARCH ALL is *well defined* and portable and predictable *IF* you follow the
>well documented rules.
>
>If you have a table that has "unique" key values, then using SEARCH ALL will
>*find* the expected entry and branch to AT END if there is no match.
>
>Although SEARCH ALL is definitely NOT defined as a "binary search" (and is not
>implemented as such in all current or past COBOL compilers)

>You can avoid using SEARCH ALL (or even SEARCH) and INSPECT if you don't have
>the time to learn and understand the WELL documented rules, but I certainly
>would not recommend that to others.
>
>Learn when the Standard COBOL statements are and are not well-defined, then use
>the "best statement" for the programming task ahead of you (is my personal
>suggestion).

William M. Klein

2004-07-17, 3:55 am

I don't know of anyone (whom I necessarily believe) who has stated in this
thread that the results are unpredictable for a table with sorted, non-duplicate
keys, in a CURRENTLY supported compiler. There may (or may not) have been some
in the past with problems. There may be people who haven't tried it recently -
because they ONCE heard there was a problem.

As far as the definition of SEARCH ALL, any implementor's definition may well
use the term "binary search" and for that implementation, it probably
(certainly?) is.

However, there have been vendors (and I think - but am not certain - that there
still are) who use "random sampling" and hashing routines for SEARCH ALL. Given
some information (that may or may not be provided by external or internal
information), such a routine might well be significantly FASTER than a binary
search - again for some tables.

As far as,

" With INSPECT I would go to reason 3) The results of the statement are not
100% predictable in any event. By this I mean if I were to produce a number of
questions listing INSPECT statements and data types, and asking for results of
the INSPECT statement, most people could not answer all of them correctly."

goes, it certainly sounds like you have worked where insufficient training was
available. If you are a contractor, this may be WHY those sites need
contractors.

I will certainly be happy to admit that when I have tried doing a VERY complex
INSPECT statement, I have (on occasion) needed to run some tests to make certain
that it was doing what I wanted it to do. However, I (personally) have never
seen an INSPECT statement that worked correctly on one currently supported
compiler NOT work correctly on another - unless one of the two had a compiler
bug - that the vendor was willing to fix.

--
Bill Klein
wmklein <at> ix.netcom.com
"Glenn Someone" < dontspamme@whydoyouneedmyaddressspammers
.com> wrote in message
news:v66hf09jf5f6c4q8u5li7hnnolfh3i05c5@
4ax.com...[color=darkred]
> IF...that's the point. The rules are not set out clearly by the
> standard and are inconsistent across compilers and platforms. That
> much has been stated within this thread.
>
> And that's funny. Every book and instructor I've heard and read has
> stated that SEARCH ALL = binary search. Care to enlighten us on what
> the exact method is used if it is not the binary search? If it is the
> binary search, then the standard is flawed because the binary search
> does NOT require all table keys to be unique.
>
> And I'm the type of programmer to avoid as any headaches as possible.
> In my experience, SEARCH and INSPECT are both pure headache generators
> for two reasons: 1) They are not well defined and consistent across
> platforms. and 2) They are hard-wired procedures and one must accept
> and program around the actions one interprets them to perform, no
> matter how cryptic they are, if one chooses to use them.
>
> With INSPECT I would go to reason 3) The results of the statement are
> not 100% predictable in any event. By this I mean if I were to
> produce a number of questions listing INSPECT statements and data
> types, and asking for results of the INSPECT statement, most people
> could not answer all of them correctly. In fact, I've found when I've
> used rudimentary INSPECT statements, I've had to educate every person
> that came in contact with that program about it.
>
> I think all programs should be simple, elegant, and fast.
>
> On Fri, 16 Jul 2004 23:14:02 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
not[color=darkred]
>
use[color=darkred]

Arnold Trembley

2004-07-17, 3:55 am

Aru wrote:

> Does Cobol linear search provides better performance against Perform
> Until

No, it does not.

> My isssue is -
> I have a cobol program which was changed from Binary search to to
> Perform Until to handle and process muliple occurances of search key.
> This is a requirement that I will have multiple occurances for the
> search key.
>
> After the change my program performance deteriorate, which is, very
> well expected, but the magnitude is 12 to 13 times more. Earlier, I
> had my data processed in 10 CPU minutes and now it takes about 130 CPU
> minutes.
>
> Any suggestion. Please help
>
> Thanks
> Aru

You might try a Google advanced newsgroup search for "The DocDwarf
Runtime Performance Challenge" which was discussed in comp.lang.cobol
in April of 2000.

I had a similar problem with runtime. The solution I built was to
force the table with duplicate keys to be in ascending sequence.
During program initialization, an "index" table was built that
contained ONLY the unique keys, plus the subscript into the original,
larger table pointing to the FIRST occurrence of each key.

This allowed the index table to be searched using SEARCH ALL (which is
a binary search on IBM Mainframe COBOL). Then the larger table with
duplicate keys was processed, starting with the first matching key and
terminating at the next non-matching key. In my case, this reduced
the CPU utilization by 93% and reduced the wall-clock runtime from 10
hours down to 2 hours. The program typically read a file of 20
million records and searched a 2000 entry table for each record.

Linear table searches can be a real performance killer in large batch
applications. Recently, I optimized a program that read a large file
of customer account records. The file was in sequence by account
number. For each record, a linear table search was performed against
a 60,000 entry table to look up "owner" information by account range.
The account ranges (from/thru with no overlaps) were also in sequence
by beginning account range.

The program ran for 30 minutes and used a lot of CPU. The
optimization was simply to check to see if the last found entry would
work for the current account number. That allowed the linear table
search to be completely bypassed in most cases.

If the last table entry found did not match the current account, the
new search started with the last found entry (not the beginning of the
table), and terminated if the search key (beginning account range) was
greater than the current account number. That reduced the number of
search iterations from 60,000 to a handful. The optimized program
runs in five minutes versus 30 minutes for the original version, and
the CPU chargeback savings amount to over $100,000 per year.

You might find some other ideas on improving COBOL runtime performance
here:
http://home.att.net/~arnold.trembley/cob-rte.htm

I hope that helps.

--
http://arnold.trembley.home.att.net/

Michael Mattias

2004-07-17, 8:55 am

"Glenn Someone" < dontspamme@whydoyouneedmyaddressspammers
.com> wrote in
message news:cr4hf0pvffrpbcjaqesblqubkvgm9mtdql@
4ax.com...
> But one important caveat. It's never a good thing performance wise to
> sort a table just to be able to perform a binary search, unless the
> payback for doing it is significant. While the binary search beats
> the pants off the sequential search, sorting the data can and will
> negate that benefit and then some, unless you do perform 1000's of
> searches.

In this particular case, it certainly appears worth the effort..

The OP said his change from SEARCH ALL to SEARCH had resulted in a
twelvefold increase in run time (a number which, frankly, causes me to doubt
the quality of either the change in implementation or the measurement
technique... although asked, I can't find the number of table items
involved, so it's possible).

I have often said, and published the same thoughts, that performance tuning
is ALWAYS about specific cases... there is no "silver bullet" which solves
all performance problems...

Except... there is one technique which ALWAYS produces the best results:
applied imagination.

--
Michael Mattias
Tal Systems, Inc.
Racine WI
mmattias@talsystems.com

docdwarf@panix.com

2004-07-17, 3:55 pm

In article <j7bKc.37741$eH1.18121384@newssvr28.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
><docdwarf@panix.com> wrote in message news:cdbd70$38j$1@panix5.panix.com...
>you
>
>No sense of adventure?

Not when it comes to code that's to be implemented into Prod, no.

>You've been doing what you've been doing too long.

.... and my particular parts of systems have been... boringly stable for a
goodly bit of time, as well. Wonderful world that has such coincidences
in it, neh?

DD

Robert Wagner

2004-07-17, 3:55 pm

docdwarf@panix.com wrote:

>How about this for a 'truism' to make things easier:
>
>'Do not implement into Prod any code which cannot be debugged by a typical
>2-year programmer at 2:am.'

My goal is programs that DON'T blow up and require debugging at 2 am .. programs
that detect exceptions and handle them gracefully. I do it by _raising_ the bar
of programmer skill rather than lowering it.

Glenn Someone

2004-07-17, 3:55 pm

On 17 Jul 2004 09:53:48 -0400, docdwarf@panix.com wrote:

> and all this p

ing and poking about,
>above and below, makes me... uncomfortable.'

It really shouldn't. The way I see it is that a program design is
getting introduced that is making you uncomfortable because it's
something different than what you've already encountered. If everyone
had this attitude, computer science wouldn't be developing and moving
its way forward and we'd still be in the Grace Murray Hopper days of
punch cards.

>This is not a mold, this is not a truism, this is, I would say, something
>that I would not like to inflict on another programmer - no matter *what*
>level of experience - at a 2:am fix.

Is that the assumption? Because it's something you've never seen, you
assume it would blow up and not work. Have you ever heard of good
sound testing? Like I said study what the binary search does (if
SEARCH ALL doesn't cut it, provide a binary search, it's not that hard
to code yourself!), and then you might get a little bit of ease out of
it.

>I don't understand this... my suggestions, in a previous posting, did not
>include changing a binary search into a sequential one.

Let me add to that..."Or add unnecessary data or variables.".

>
>I am not sure I understand this. If you have a table with keys:
>
>(row 1) AAA
>(row 2) AAA
>(row 3) BBB
>(row 4) BBB
>(row 5) BBB
>(row 6) CCC
>(row 7) CCC
>
>... are you saying that given a key of AAA a binary search will always
>return the (row 1) occurrence of AAA, that given a key of CCC you will
>always return (row 6) CCC? This would seem to contradict Mr Steven's
>assertion about the Standard.

No. This is showing you don't have a conception of what a binary
search is. Searching for BBB will return row 4 from a properly coded
binary search, AAA row 2, CCC row 6. Then finding the first entry
involves your sequential search option (using PERFORM UNTIL). I
wouldn't personally go up and down from the spot discovered, because
of that simplicity argument (I'd go find the first one and then
process all records accordingly).

>I would say that it is less fortunate when one takes a tool designed for a
>particular task and attempts to use it for a different task. A SEARCH ALL
>is designed to return an unique entry from a range of uniquely ordered
>keys; what it is being asked to do, here, is return... an entry, in no
>predictable sequence, from a series of possibly duplicated keys. That it
>can be done is not being argued... just like it is not argued that one can
>use a torque-wrench as a hammer to drive nails.

I can't help that. As said in another post, that is one of my pet
peeves of SEARCH and INSPECT. The behavior is hard wired and both
verbs are useless if 1) they do not perform consistent actions across
platforms. and 2) you have to do something that is not consistent with
those hard-wired actions.

>'Do not implement into Prod any code which cannot be debugged by a typical
>2-year programmer at 2:am.'

I find most people can understand the concept of a binary search if
they see one. In fact, most people use that concept when they play a
number guessing game when they've thought about it ("I'm thinking of a
number between 1 and 100. What is it?"). Let's just say in my
experience, INSPECT fits this category of "can not be debugged by a
typical 2 year programmer at 2 am" much more better than a fully coded
out binary search. You might rethink using INSPECT statements in your
code if you're so inclined about this process.

>This does not appear to make sense. If the algorithm is designed to
>return a particular row in a series of ordered and unique keys and the
>algorithm now returns an unpredictable row in a series of ordered and
>non-unique keys then how is it predictable?

That's the point we're trying to agree upon. The binary search <>
SEARCH ALL, evidently, so that's not what is being advocated
necessarily. Binary search doesn't return the first occurrence in
the table of a duplicate value, but it will return A value quite
predictably. That is all that is being asked of it, and it will do
that job perfectly.

>It justifies careful design... and re-design when the system changes to a
>point where the original design is no longer applicable. In the original
>instance the system was designed to use a binary search against a large
>table of ordered and unique keys; my guess is that some corner-office
>idiot said 'All ya gotta do is make duplicate entries in the table, that
>can't be too hard'... and the rest is as is seen here.

It's not. But yes, a good example of poor program design if I ever
seen one - someone just going off of what was heard in class "don't
use binary search on a table with duplicates", and the rest is
history. The not-understanding programmer changes the SEARCH ALL to
SEARCH and we get the corresponding speed decrease as noted by the OP.

Glenn Someone

2004-07-17, 3:55 pm

The "random sampling" routines I understand. Hashing? Isn't that
more for devising a direct index access relationship to the key
itself, and not a searching method? As a quick & simple example for
those that may not know, ordering the months from 1 to 12 in a table
is a simple example of hashing. How is this used to perform a search
in a table that might, in other situations, need a hash key calculated
for a direct access? I have my guess (program calculates hash keys
for all items in table into a hash table correlating to the main
table, program calcuates hash key for search entry, program looks at
hash table for key entry - convoluted, but it would do the job), but I
wouldn't mind hearing your take on it. Is that what the "hashing
routines" are doing?

On Sat, 17 Jul 2004 03:39:46 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>However, there have been vendors (and I think - but am not certain - that there
>still are) who use "random sampling" and hashing routines for SEARCH ALL.

William M. Klein

2004-07-17, 3:55 pm

"Glenn Someone" < dontspamme@whydoyouneedmyaddressspammers
.com> wrote in message
news:gfpif0dqvhebfioqekqfupfcsmu21ada6s@
4ax.com...
> On 17 Jul 2004 09:53:48 -0400, docdwarf@panix.com wrote:
>
<snip>
>
> That's the point we're trying to agree upon. The binary search <>
> SEARCH ALL, evidently, so that's not what is being advocated
> necessarily. Binary search doesn't return the first occurrence in
> the table of a duplicate value, but it will return A value quite
> predictably. That is all that is being asked of it, and it will do
> that job perfectly.
>

Glenn,
What you say may (or may not) be true of a "well designed and implemented"
hand-coded binary search. It is *NOT* true of the STANDARD conforming SEARCH
ALL.

A "SEARCH ALL" against a table with duplicate keys is TOTALLY UNDEFINED; it is
specified so any of the following are fully conforming:

A) It returns the last/first/middle occurrence that matches (possibly randomly
between the 3)
B) It returns a random entry where the key doesn't even match
C) It branches to the AT END condition

SEARCH ALL is an incredibly valuable and PRECICTABLE *AND* PORTABLE tool when
used against a table whose keys are all in the correct "ascending" (or
"descending") order and for which there are no duplicates. To avoid using it
for such cases is (in my opinion) silly. (Which does NOT mean that one should
use SEARCH ALL for a small table where a simple SEARCH may be faster.)

SEARCH ALL should be "avoided like the plague" for tables where one cannot
"predict" whether the keys are unique and in correct order. (It may or may not
get "close" to the desired entry.)

If you have a programer who can't understand this relatively SIMPLE distinction,
then you are right they should not be using SEARCH ALL - but I certainly
wouldn't trust any "hand-coded" search they created either.

--
Bill Klein
wmklein <at> ix.netcom.com

docdwarf@panix.com

2004-07-17, 8:55 pm

In article <40f963cb.509423765@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>My goal is programs that DON'T blow up and require debugging at 2 am ..
>programs that detect exceptions and handle them gracefully.

That goal seems in no wise contradicted by the foregoing ''truism' to make
things easier'.

>I do it by
>_raising_ the bar of programmer skill rather than lowering it.

Dear me, Mr Wagner... do you believe that there's only one way to skin a
cat, as well?

DD

Michael Mattias

2004-07-17, 8:55 pm

<docdwarf@panix.com> wrote in message news:cdc5a4$qjn$1@panix5.panix.com...
> Dear me, Mr Wagner... do you believe that there's only one way to skin a
> cat, as well?

Considering your post earlier this very day...

">Do your binary search (SEARCH ALL) on your sorted table... when you get a
>hit, decrease your index in a loop to find where "target" values start in
>table, then scan though them in forward direction until you find the one
you
>want or the key changes; that is, let SEARCH ALL get you "on the correct
>block" and then walk from house to house.

This is the 'p

ing and poking, above and below' which makes me...
uncomfortable."

.....isn't this the pot calling the kettle black?

MCM

LX-i

2004-07-17, 8:55 pm

Glenn Someone wrote:

Man, your top-posting is killing me... but more to the point...

> And I'm the type of programmer to avoid as any headaches as possible.
> In my experience, SEARCH and INSPECT are both pure headache generators
> for two reasons: 1) They are not well defined and consistent across
> platforms. and 2) They are hard-wired procedures and one must accept
> and program around the actions one interprets them to perform, no
> matter how cryptic they are, if one chooses to use them.
>
> With INSPECT I would go to reason 3) The results of the statement are
> not 100% predictable in any event. By this I mean if I were to
> produce a number of questions listing INSPECT statements and data
> types, and asking for results of the INSPECT statement, most people
> could not answer all of them correctly. In fact, I've found when I've
> used rudimentary INSPECT statements, I've had to educate every person
> that came in contact with that program about it.

I'd be interested to see that quiz posted here. Folks who care enough
to take the time to educate themselves about the behavior of certain
verbs shouldn't be penalized for their increased knowledge. In fact,
isn't that why oftentimes "experience" is preferable to excessive
amounts of "education"?

Personally, I think INSPECT's hands are tied because the REPLACING
targets have to be of the same size (at least that's how it is on the
compiler I use daily). I'd like it to behave more like the VB "Replace"
verb, where I could replace x"31" by "" and shrink up the rest of the
data, or replace ">" with ">" and have the data expand. Instead, I
had to write my own looping algorithm for that - no big deal. Once it
was written, it was done. :)

> I think all programs should be simple, elegant, and fast.

At time, only two of those may be available...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-07-17, 8:55 pm

In article <gfpif0dqvhebfioqekqfupfcsmu21ada6s@4ax.com>,
Glenn Someone < dontspamme@whydoyouneedmyaddressspammers
.com> wrote:
>On 17 Jul 2004 09:53:48 -0400, docdwarf@panix.com wrote:
>
>
>It really shouldn't.

No, it really should... see how easy it is to counter an unsupported
assertion with another unsupported assertion?

>The way I see it is that a program design is
>getting introduced that is making you uncomfortable because it's
>something different than what you've already encountered.

How interesting... the way I 'feel' it is that the program design that is
attempting to be introduced is said, clearly and unambiguously, by the
Standard to have a result which is 'unpredictable'. I find that there's
enough unpredictability which gets encountered as is, without implementing
that against which the Standard warns.

>If everyone
>had this attitude, computer science wouldn't be developing and moving
>its way forward and we'd still be in the Grace Murray Hopper days of
>punch cards.

If everyone had the attitude that it is a Good Thing to use the language
in a way which the Standard declares to be unpredictable then there might
be more 2:am suppoprt calls. See what happens when one plays 'what if'
instead of 'what is'?

'What is' appears to be that you desire to implement code which, by the
Standard, returns results which are unpredictable while doing that (and
the subsequent p

ing and poking about to enhance predictability) is
something which makes me uncomfortable.

>
>
>Is that the assumption? Because it's something you've never seen, you
>assume it would blow up and not work.

No. The Standard which states the results returned by using SEARCH ALL in
this manner are 'unpredictable'. I would not like to inflict a usage
which the Standard says is unpredictable in a situation which might be
encountered by another programmer - no matter *what* level of experience -
at 2:am.

>Have you ever heard of good
>sound testing?

I have... and I've heard of bugs that have remained hidden in code for
years... and I've not only heard of them, I've been called upon to fix
them, as well; it seems that our experiences are different.

>Like I said study what the binary search does (if
>SEARCH ALL doesn't cut it, provide a binary search, it's not that hard
>to code yourself!), and then you might get a little bit of ease out of
>it.

I've studied a small bit... enough to learn that the Standard clearly
calls the results returned from this use of SEARCH ALL to be
unpredictable.

>
>
>Let me add to that..."Or add unnecessary data or variables.".

Let me respond to that: 'Necessity is in the mind of the beholder'. If
data or variable added preclude the use of a construct in a manner which
the Standard warns as being 'unpredictable' then they might be, by a
definition, necessary.

>
>
>No. This is showing you don't have a conception of what a binary
>search is. Searching for BBB will return row 4 from a properly coded
>binary search, AAA row 2, CCC row 6.

Leaving my conceptions and your knowledge of them aside... I find it
interesting that you see the need to change the grounds of your argument
from a SEARCH ALL to 'a properly coded binary search'. Please be so kind
as to post the code, compiler and OS which you used to generate this
assertion so that it might be independently verified.

[snip]

>
>
>I can't help that.

You can't help using a torque-wrench to drive nails? I find it is rather
easy; I simply pick up a hammer instead of a torque-wrench.

>As said in another post, that is one of my pet
>peeves of SEARCH and INSPECT. The behavior is hard wired and both
>verbs are useless if 1) they do not perform consistent actions across
>platforms. and 2) you have to do something that is not consistent with
>those hard-wired actions.

I've worked in shops where SEARCH was prohibited... not because of
cross-platform inconsistencies but because of the inability of a manager
to understand how it works. I've worked in shops where INSPECT and
STRING/UNSTRING were prohibited... but that was because the manager was
afraid a batch subroutine would be suddenly appropriated for use in an
online (CICS) region.

Please be so kind as to document use, compiler and platforms where you
have encountered results which were inconsistent across platforms; if it
occurred more than two decades back you might be indulging in the behavior
of 'old truisms' for which you deride others.

>
>
>I find most people can understand the concept of a binary search if
>they see one. In fact, most people use that concept when they play a
>number guessing game when they've thought about it ("I'm thinking of a
>number between 1 and 100. What is it?"). Let's just say in my
>experience, INSPECT fits this category of "can not be debugged by a
>typical 2 year programmer at 2 am" much more better than a fully coded
>out binary search. You might rethink using INSPECT statements in your
>code if you're so inclined about this process.

Our experiences, once again, seem to be different... but if I wanted only
agreement I would talk only with my mirror.

>
>
>That's the point we're trying to agree upon. The binary search <>
>SEARCH ALL, evidently, so that's not what is being advocated
>necessarily. Binary search doesn't return the first occurrence in
>the table of a duplicate value, but it will return A value quite
>predictably. That is all that is being asked of it, and it will do
>that job perfectly.

Now I think I am starting to get the point... are you suggesting, then,
that the coder change the SEARCH ALL to a roll-your-own binary search?

>
>
>It's not. But yes, a good example of poor program design if I ever
>seen one - someone just going off of what was heard in class "don't
>use binary search on a table with duplicates", and the rest is
>history. The not-understanding programmer changes the SEARCH ALL to
>SEARCH and we get the corresponding speed decrease as noted by the OP.

I have never heard in any class 'don't use binary search on a table with
duplicates'; I *have* been taught 'SEARCH ALL will return unpredictable
results when used against a table which contains duplicate keys'... so
perhaps, once again, our experiences are different.

DD

LX-i

2004-07-17, 8:55 pm

Glenn Someone wrote:

> On 17 Jul 2004 09:53:48 -0400, docdwarf@panix.com wrote:
>
>
>
>
> It really shouldn't. The way I see it is that a program design is
> getting introduced that is making you uncomfortable because it's
> something different than what you've already encountered. If everyone
> had this attitude, computer science wouldn't be developing and moving
> its way forward and we'd still be in the Grace Murray Hopper days of
> punch cards.

Both Mr. Stevens and Mr. Klein have stated that the results are
undefined when you do a binary search on a table with duplicate keys.
Do you understand what "undefined" means, in the context of the COBOL
standard? With one vendor, they may code it to find the first in
sequence that matches. Another may choose to look at blocks, and if
they happen to find one that matches, they'll return it, even if it's 3
of 7 with the same key. It's entirely possible that a third vendor
could interpret the same condition as "I can't uniquely satisfy this
search, so I'm going to throw "at end"." What does that do to your
p

-and-poke strategy?

You claim to want the most stable, portable code, but in this case,
you're relying on undefined functionality to give you an acceptable
solution. THAT is what makes some folks here "uncomfortable" with it.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-07-17, 8:55 pm

In article <UUgKc.38366$eH1.18190126@newssvr28.news.prodigy.com>,
Michael Mattias <michael.mattias@gte.net> wrote:
><docdwarf@panix.com> wrote in message news:cdc5a4$qjn$1@panix5.panix.com...
>
>Considering your post earlier this very day...
>
>">Do your binary search (SEARCH ALL) on your sorted table... when you get a
>you
>
>This is the 'p

ing and poking, above and below' which makes me...
>uncomfortable."
>
>
>....isn't this the pot calling the kettle black?

Mr Mattias, I believe what you quoted is a statement about what makes me
comfortable... no more, no less. I do not understand how that can be
interpreted as a statement of the number of methods available or the
superiority of one method over another... just what makes me
uncomfortable.

Might you how you see another possibility than this?

DD

docdwarf@panix.com

2004-07-17, 8:55 pm

In article <10fj7m72rqirp58@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>Glenn Someone wrote:
>
>
>Both Mr. Stevens and Mr. Klein have stated that the results are
>undefined when you do a binary search on a table with duplicate keys.

A correction, Mr Summers: Mr Stevens and Mr Klein have pointed out that
the Standard reports the results of a SEARCH ALL against a table with
duplicate keys is unpredictable. While a SEARCH ALL *may* be implemented
by a vendor as a binary search... what I think is trying to be pointed out
is that there are other binary searches (hand-rolled ones) which are not
SEARCH ALL and which, therefore, might have... less unpredictability.

DD

LX-i

2004-07-17, 8:55 pm

docdwarf@panix.com wrote:

> In article <10fj7m72rqirp58@corp.supernews.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
>
> A correction, Mr Summers: Mr Stevens and Mr Klein have pointed out that
> the Standard reports the results of a SEARCH ALL against a table with
> duplicate keys is unpredictable. While a SEARCH ALL *may* be implemented
> by a vendor as a binary search... what I think is trying to be pointed out
> is that there are other binary searches (hand-rolled ones) which are not
> SEARCH ALL and which, therefore, might have... less unpredictability.

My mistake - thanks for the correction. :) (My point remains the same,
although it seems to be an echo of earlier messages... Maybe repetition
will aid in understanding.)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Richard

2004-07-17, 8:55 pm

robert.deletethis@wagner.net (Robert Wagner) wrote

> My goal is programs that DON'T blow up and require debugging at 2 am .. programs
> that detect exceptions and handle them gracefully. I do it by _raising_ the bar
> of programmer skill rather than lowering it.

Then don't use undocumented and unsupported features, or in ways that
are disallowed by the documentation.

Richard

2004-07-17, 8:55 pm

Glenn Someone < dontspamme@whydoyouneedmyaddressspammers
.com> wrote

> Is that the assumption? Because it's something you've never seen, you
> assume it would blow up and not work.

The problem is not that it will 'blow up and not work', the problem is
that the results are not defined and may be different in the next
version, or from some other change.

> Have you ever heard of good sound testing?

Testing only provides results in the environments tested. If the
environment changes then undefined results may change.

> Like I said study what the binary search does (if
> SEARCH ALL doesn't cut it, provide a binary search, it's not that hard
> to code yourself!), and then you might get a little bit of ease out of
> it.

But that is not necessary. Adding a sequence is trivial, either at the
time the table is created or by a single serial pass to do this.

[color=darkred]
> No. This is showing you don't have a conception of what a binary
> search is. Searching for BBB will return row 4 from a properly coded
> binary search, AAA row 2, CCC row 6. Then finding the first entry
> involves your sequential search option (using PERFORM UNTIL). I
> wouldn't personally go up and down from the spot discovered, because
> of that simplicity argument (I'd go find the first one and then
> process all records accordingly).

Adding the sequence and then SEARCH ALL '<key> 0' gives a reliable,
portable, _defined_ result of the first entry for <key> without having
to do your own search coding, or grubby -1, +1 shuffling.

docdwarf@panix.com

2004-07-17, 8:55 pm

In article <10fjbuq3irc2j6a@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:

[snip]

>(... Maybe repetition
>will aid in understanding.)

Oh, I *cannot* resist...

.... I'm not sure that made sense, might you said it again?

DD

Robert Wagner

2004-07-18, 3:55 am

Xref: kermit comp.lang.cobol:91697

LX-i <lxi0007@netscape.net> wrote:

>Personally, I think INSPECT's hands are tied because the REPLACING
>targets have to be of the same size (at least that's how it is on the
>compiler I use daily). I'd like it to behave more like the VB "Replace"
>verb, where I could replace x"31" by "" and shrink up the rest of the
>data, or replace ">" with ">" and have the data expand. Instead, I
>had to write my own looping algorithm for that - no big deal. Once it
>was written, it was done. :)

You coulda done it with one line of code by thinking outside the box:

EXEC SQL SELECT REPLACE (:my-string, '>', '>') INTO :my-string FROM DUAL
END-EXEC.

Robert Wagner

2004-07-18, 3:55 am

docdwarf@panix.com wrote:

>In article <40f963cb.509423765@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:

>
>Dear me, Mr Wagner... do you believe that there's only one way to skin a
>cat, as well?

There are artful ways and a plethora of clumsy ways.

Robert Wagner

2004-07-18, 3:55 am

riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
programs[color=darkred]
bar[color=darkred]
>
>Then don't use undocumented and unsupported features, or in ways that
>are disallowed by the documentation.

The machine is agnostic about standards and documentation. People worry about
such things.

I've worked in traditional shops, where programmers had carte blanche, and I've
worked in shops HEAVILY CONTROLLED with methodologies such as CMM Level 5 and
ISO-9000, which require LOTS of QA testing, lock-downs, oversight, code review,
Change Management, etc. The latter are designed to protect us from human
fallibility. Does it work? Are there fewer program bugs when formal
development/testing methodologies are employed? In my observation, the number of
bugs is about the same. The millions of dollars big companies spend to overcome
human nature is wasted. My beauty-oriented approach, on the other hand, DOES
reduce program bugs .. to nearly zero. My supporting evidence is the experience
of companies where it was deployed.

A notable exception is the aviation industry .. computers that fly airplanes,
where 'certification' methodologies were first developed and from which copied
by other industries. It really works in that domain, but at expense so huge that
other industries are unwilling to pay the price.

There are glitches even there. A 747 flying Australian day-tourists over
Antarctica flew into a mountain due to a reported 'program bug'. It was actually
pilot misunderstanding correction of a data error -- the pilot was flying the
plane VFR at the time -- but 'the system' failed.

Glenn Someone

2004-07-18, 3:55 am

Exactly. IMO, what I've seen expressed in this thread are human
nature issues and not coding, performance, or reliability issues.

On Sun, 18 Jul 2004 03:37:41 GMT, robert.deletethis@wagner.net (Robert
Wagner) wrote:

>The machine is agnostic about standards and documentation. People worry about
>such things.

Frederico Fonseca

2004-07-18, 8:55 am

On Sun, 18 Jul 2004 03:37:38 GMT, robert.deletethis@wagner.net (Robert
Wagner) wrote:

>LX-i <lxi0007@netscape.net> wrote:
>
>
>You coulda done it with one line of code by thinking outside the box:
>
>EXEC SQL SELECT REPLACE (:my-string, '>', '>') INTO :my-string FROM DUAL
>END-EXEC.
Pretty, but not portable. This implies that the compiler used allows
for ESQL. Not all do.

There is at lease one that does not support without third party tools,
and even like that it needs a preprocessor from whatever DB they have
available (which at this stage are Oracle, SYBASE, DB2 and ADABAS. SQL
server does not have it, neither does MySQL.).

The above code also implies a connection to a DB, which may not be
required throughout the application, so the overhead of adding just
for a "conversion" would void any speed/functionality gained by this.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Robert Wagner

2004-07-18, 8:55 am

Glenn Someone < dontspamme@whydoyouneedmyaddressspammers
.com> wrote:

>Exactly. IMO, what I've seen expressed in this thread are human
>nature issues and not coding, performance, or reliability issues.

Bad programmers think they are addressing the machine, telling it to do this and
that. Good programmers picture their readership as humans who will have to
understand the code.

docdwarf@panix.com

2004-07-18, 3:55 pm

In article <40f9ebb7.544224468@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>LX-i <lxi0007@netscape.net> wrote:
>
>
>You coulda done it with one line of code by thinking outside the box:
>
>EXEC SQL SELECT REPLACE (:my-string, '>', '>') INTO :my-string FROM DUAL
>END-EXEC.

Mr Wagner, and how might this have been done at a site where Oracle (or a
similar database) is not installed?

DD

docdwarf@panix.com

2004-07-18, 3:55 pm

In article <40f9ecb9.544482110@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>
>There are artful ways and a plethora of clumsy ways.

So more than one way exists, Mr Wagner. Now... these terms, 'artful' and
'clumsy', seem to modified or affected by personal views, experiences or
backgrounds; after all, one cannot say 'this contains (n) units of art' in
the same manner as 'this contains (n) degrees Fahrenheit'.

Might it be, then, Mr Wagner, that these ways contain not as much 'art' as
much as 'what I like and the rules I have coded into the program which I
call The Beautifier'?

DD

docdwarf@panix.com

2004-07-18, 3:55 pm

In article <40fa6dde.577548960@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>Glenn Someone < dontspamme@whydoyouneedmyaddressspammers
.com> wrote:
>
>
>Bad programmers think they are addressing the machine, telling it to do this and
>that. Good programmers picture their readership as humans who will have to
>understand the code.

Mr Wagner, in that a computer is *not* human what you are saying here is
that 'good programmers generate a Noble Lie'... how very Platonic of you!

DD

Joe Zitzelberger

2004-07-18, 3:55 pm

The original problem was a SEARCH ALL of a table with a unique key.
Somehow, maintenance and/or enhancements to the system had started
generating tables with a non-unique key.

Two equal keys should, in an sane and normal world, be equal. The act
of being a key allows us to know that it does not matter which
associated data one finds when using said key. If this is not the case,
then some field that provides uniqueness has been left out of the key.

It is possible that this field is not part of the actual data, but part
of the runtime situtation -- e.g. that the missing data item is a
sequence appended to the key representing the instance of a specific
'unique' key.

Glenn Someone

2004-07-18, 3:55 pm

Agreed. Simple and elegant is what ultimately matters, and that often
translates into fast too. The machine knows nothing, you always
address human factors. Even performance is based on a desire for
speed (i.e. not waiting around for my work to get done), or money
(when billed for CPU hours).

Usually my most paramount concern is the next person that comes along
in understanding the code. Simple and elegant helps again. This
means doing the work with the best algorithm and the shortest path,
and the fewest variables. Less code, and less variables means it is
easier to understand, and means less of those 2am callouts people are
fretting about (hey I don't like it either!). In my experience,
however, most people just get the job done and move on (and I have
stories about that one). And yes, my programming methodology creates
friction - as no doubt seen in this thread.

Unfortunately, I will admit I've produced two programs that completely
fall into the "not understandable" path. While still simple and
elegant, it seems the learning curve for the required algorithm (and
there were no alternatives) in these two programs was high enough that
subsequent maintenance programmers could not understand it.
Unfortunately it couldn't be helped. I really couldn't think of a
solution to get past this particular human factor.

On Sun, 18 Jul 2004 12:35:08 GMT, robert.deletethis@wagner.net (Robert
Wagner) wrote:

>Bad programmers think they are addressing the machine, telling it to do this and
>that. Good programmers picture their readership as humans who will have to
>understand the code.

Robert Wagner

2004-07-18, 3:55 pm

Glenn Someone < dontspamme@whydoyouneedmyaddressspammers
.com> wrote:

>Unfortunately, I will admit I've produced two programs that completely
>fall into the "not understandable" path. While still simple and
>elegant, it seems the learning curve for the required algorithm (and
>there were no alternatives) in these two programs was high enough that
>subsequent maintenance programmers could not understand it.
>Unfortunately it couldn't be helped. I really couldn't think of a
>solution to get past this particular human factor.

When in situation, I've used two approaches, alone or in combination:

1. Decompose the algorithm into simpler callable functions.

2. Include a document several pages long explaining the algorithm in detail.
Perhaps use 'footnote references' that refer back to the document.

The Sorts and Trees demos I posted here a month ago are examples of both.

Robert Wagner

2004-07-18, 3:55 pm

docdwarf@panix.com wrote:

>In article <40f9ecb9.544482110@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:

>
>So more than one way exists, Mr Wagner. Now... these terms, 'artful' and
>'clumsy', seem to modified or affected by personal views, experiences or
>backgrounds; after all, one cannot say 'this contains (n) units of art' in
>the same manner as 'this contains (n) degrees Fahrenheit'.

Tell movie and restaurant critics that their star systems are meaningless.

Tell professors of art, music, etc. that their grades are self-indulgence.

Tell auditioners that their judgment is just personal preference.

Tell award committees such as Oscar, Pulitzer, Grammy, etc. that their prizes
mean little to the consumer community.

>Might it be, then, Mr Wagner, that these ways contain not as much 'art' as
>much as 'what I like and the rules I have coded into the program which I
>call The Beautifier'?

"Great innovators and original thinkers and artists attract the wrath of
mediocrities as lightning rods draw the flashes." -- Theodor Reik

"People who are unable to motivate themselves must be content with mediocrity,
no matter how impressive their other talents." -- Andrew Carnegie

Robert Wagner

2004-07-18, 3:55 pm

docdwarf@panix.com wrote:

>In article <40f9ebb7.544224468@news.optonline.net>,
>Robert Wagner <robert.deletethis@wagner.net> wrote:

>
>Mr Wagner, and how might this have been done at a site where Oracle (or a
>similar database) is not installed?

file section.
fd string-file.
01 string-record pic x(80).
fd byte-file.
01 byte-record pic x(1).

working-storage section.
01 p pic 9(2).
linkage section.
01 my-string pic x(80).

procedure division using my-string.
open output string-file
write string-record from my-string
close string-file
open input byte-file
move 1 to p
perform until p > length(my-string)
read byte-file
if byte-record = '>'
string '>' into my-string with pointer p
else
string byte-record into my-string with pointer p
end-if
end-perform
close byte-file
goback.

JerryMouse

2004-07-18, 3:55 pm

docdwarf@panix.com wrote:
>
> Mr Wagner, and how might this have been done at a site where Oracle
> (or a similar database) is not installed?

Here's another way - shamelessly copied from, um, somewhere:

000001 IDENTIFICATION DIVISION.
000002 PROGRAM-ID. STRTOOL.
000003*=================================
================================
000004* NAME: STRTOOL.
000005*
000006* PURPOSE: Manipulate strings
000007*
000008*
000009* USAGE: CALL 'STINSERT' USING LINK-STRING LINK-SLEN
000010* LINK-INSERT LINK-ILEN LINK-LOC
000011*
000012* LINK-STRING X(nnn) String needing insert
000013* LINK-SLEN S9(7)C5 Length of string
000014* LINK-INSERT X(nnn) String to insert
000015* LINK-ILEN S9(7)C5 Length of insert string
000016* LINK-LOC S9(7)C5 Start byte in STRING to
000017* place INSERT

000038 DATA DIVISION.
000039 FILE SECTION.
000040
000041
000042 WORKING-STORAGE SECTION.
000043
000044 01 BEG PIC S9(4) COMP-5.
000045 01 I PIC S9(7) COMP-5.
000046 01 J PIC S9(7) COMP-5.
000047 01 K PIC S9(7) COMP-5.
000049
000050 LINKAGE SECTION.
000051 01 LINK-STRING.
000052 02 FILLER OCCURS 1 TO 10000 DEPENDING ON LINK-SLEN PIC X.
000053 01 LINK-SLEN PIC S9(5) COMP-5.
000054 01 LINK-INSERT.
000055 02 FILLER OCCURS 1 TO 10000 DEPENDING ON LINK-ILEN PIC X.
000056 01 LINK-ILEN PIC S9(5) COMP-5.
000057 01 LINK-LOC PIC S9(5) COMP-5.
000058
000059 PROCEDURE DIVISION.
000060
000061
000062 P100-SINSERT.
000063 ENTRY 'STINSERT' USING
LINK-STRING
LINK-SLEN
LINK-INSERT
LINK-ILEN LINK-LOC.
000065 IF LINK-ILEN > LINK-SLEN
000066 OR LINK-ILEN < 1
000067 GO TO P999-QUIT.
000068
000069 COMPUTE BEG = LINK-SLEN - LINK-ILEN.
000070 IF BEG < 1 OR > LINK-SLEN
000071 GO TO P999-QUIT.
000072 MOVE LINK-SLEN TO J.
000073 PERFORM VARYING I FROM BEG BY -1 UNTIL I < LINK-LOC
000074 MOVE LINK-STRING(I:1) TO LINK-STRING(J:1)
000075 SUBTRACT 1 FROM J
000076 IF J < 1
000077 MOVE 1 TO J
000078 END-IF
000079 END-PERFORM.
000080 MOVE LINK-INSERT(1:LINK-ILEN) TO
000081 LINK-STRING(LINK-LOC:LINK-ILEN).
000082 GO TO P999-QUIT.
000083
000084
000085
000086 P999-QUIT.
000087 GOBACK.

Richard

2004-07-18, 8:55 pm

robert.deletethis@wagner.net (Robert Wagner) wrote

> There are glitches even there. A 747 flying Australian day-tourists over
> Antarctica flew into a mountain due to a reported 'program bug'.

It wasn't a 747.
It wasn't Australian.

> It was actually
> pilot misunderstanding correction of a data error -- the pilot was flying the
> plane VFR at the time -- but 'the system' failed.

It wasn't a 'pilot misunderstanding', it was a data entry error:

""Unknown to them two of the coordinates had been changed earlier that
morning, and when entered into the computer, changed the flight path
of the aircraft 45 kilometres to the east.""

My sister was actually booked on that flight, but cancelled when she
couldn't afford the extra to get a local flight to the departure
point.

docdwarf@panix.com

2004-07-18, 8:55 pm

In article <40faabca.593402782@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>
>file section.
>fd string-file.
>01 string-record pic x(80).
>fd byte-file.
>01 byte-record pic x(1).
>
>working-storage section.
>01 p pic 9(2).
>linkage section.
>01 my-string pic x(80).
>
>procedure division using my-string.
> open output string-file
> write string-record from my-string
> close string-file
> open input byte-file
> move 1 to p
> perform until p > length(my-string)
> read byte-file
> if byte-record = '>'
> string '>' into my-string with pointer p
> else
> string byte-record into my-string with pointer p
> end-if
> end-perform
> close byte-file
> goback.

Hmmmm... looks like a bit more than one line of code. Curious how
'thinking outside the box' to a one-line solution required an entirely
different product to be installed, neh?

DD

docdwarf@panix.com

2004-07-18, 8:55 pm

In article <Gc-dnSRLm4_MK2fdRVn-uA@giganews.com>,
JerryMouse <nospam@bisusa.com> wrote:
>docdwarf@panix.com wrote:
>
>Here's another way - shamelessly copied from, um, somewhere:
>

A bit more than one line of code, as well... gosh-darn those boxes you
have to think outside that don't have Oracle installed there, I guess.

DD

docdwarf@panix.com

2004-07-18, 8:55 pm

In article <40faa81f.592463469@news.optonline.net>,
Robert Wagner <robert.deletethis@wagner.net> wrote:
>docdwarf@panix.com wrote:
>
>
>
>Tell movie and restaurant critics that their star systems are meaningless.

When they start posting to comp.lang.cobol about 'this contains (n) units
of art' I just might, Mr Wagner; until then your citing their behavior in
justification of your own seems to be yet another Brooklyn Bridge defense.

>
>Tell professors of art, music, etc. that their grades are self-indulgence.

See abov and re-read the bit about a 'Brooklyn Bridge defense'.

>
>Tell auditioners that their judgment is just personal preference.

See above etc.

>
>Tell award committees such as Oscar, Pulitzer, Grammy, etc. that their prizes
>mean little to the consumer community.

See above etc.

>
>
>"Great innovators and original thinkers and artists attract the wrath of
>mediocrities as lightning rods draw the flashes." -- Theodor Reik

Mr Wagner, I am not trying to address the work of 'great innovators and
original thinkers and artists', I am attempting to address the assertions
that you have made in this forum. Lightning is attracted by hilltops,
trees and other items which do not have what many would call 'any
measurable intelligence.'

>
>"People who are unable to motivate themselves must be content with mediocrity,
>no matter how impressive their other talents." -- Andrew Carnegie

'The fine line between genius and insanity is more often cited by those
closer to the latter than the former.' - Anonymous (author of *many*
profound quotes)

DD

LX-i

2004-07-18, 8:55 pm

Robert Wagner wrote:

> LX-i <lxi0007@netscape.net> wrote:
>
>
>
>
> You coulda done it with one line of code by thinking outside the box:
>
> EXEC SQL SELECT REPLACE (:my-string, '>', '>') INTO :my-string FROM DUAL
> END-EXEC.

Interesting - I may have to give that a shot. :)

--
~~~~~~~~~~~~~~~~~