× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Now that I have the SEARCH ALL thing down, I'm wondering; since the search
is being done in memory, which is faster, the binary search via memory, or
the DASD start/read action?  

-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx
[mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Richard Casey
Sent: Monday, November 28, 2005 1:24 PM
To: COBOL Programming on the iSeries/AS400
Subject: RE: [COBOL400-L] SEARCH all problems

Glad I could help. I've been bitten by that problem before, so I knew just
where to scratch! I normally "MOVE HIGH-VALUES TO table" even if I'm not
going to use a binary search. It provides a handy "marker" for the logical
end of the table. Here is an example using your table definition.

PERFORM VARYING ws-price-rec FROM +1 BY +1
  UNTIL inv-code (ws-price-rec) = HIGH-VALUES
       < do something with table entry >
END-PERFORM

Have fun!
Richard


-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx
[mailto:cobol400-l-bounces@xxxxxxxxxxxx]On Behalf Of Daniel Mielke
Sent: Monday, November 28, 2005 1:13 PM
To: 'COBOL Programming on the iSeries/AS400'
Subject: RE: [COBOL400-L] SEARCH all problems


Thanks Richard!

That makes total sense and corrects the problem.  My assumption was that the
"table" ended where my sorted data ended and I didn't pay attention to the
finer details of the Cobol Reference example.

Thanks again.

-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx
[mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Richard Casey
Sent: Friday, November 25, 2005 8:17 PM
To: COBOL Programming on the iSeries/AS400
Subject: RE: [COBOL400-L] SEARCH all problems

Daniel,

Do a

        MOVE HIGH-VALUES TO PRICE-TABLE

before you load your inventory data in.

SEARCH ALL requires the contents of the table (the ENTIRE contents!) to be
in ascending order, otherwise "the results of any SEARCH ALL statement will
be unpredictable." (quote from manual!).

Unless you specifically initialize the table, the unused entries contain
spaces (hex 40) which are less than numbers (hex F0-F9). That makes the
table out of order, and confuses the SEARCH ALL.

Hope this helps!
Richard


-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx
[mailto:cobol400-l-bounces@xxxxxxxxxxxx]On Behalf Of Daniel Mielke
Sent: Friday, November 25, 2005 5:42 PM
To: 'COBOL Programming on the iSeries/AS400'
Subject: [COBOL400-L] SEARCH all problems




Hi all,

Why can't I get my "search all" to work?  This is driving me nuts!



01  PRICE-TABLE.

    05 prices occurs 1500 times

       ascending key is inv-code

       indexed by ws-price-rec.

       10 inv-code          pic x(5).

       10 unit-price        pic 9(7)v9(4).





move "005  " to hold-me.

SEARCH all prices

   at end

      display hold-me " not found"

   when inv-code (ws-price-rec) = hold-me

        move unit-price of PRICES (ws-price-rec)

          to current-unit-price

        move "N" to eor-UNIT-PRICE.



display

        " price$"

        current-unit-price.

PRICES                         06ED90  CHAR(16)      DIMENSION(1500)
                               06ED90    (1)         '0001 00000106538'
                               06EDA0    (2)         '0002 00000109909'
                               06EDB0    (3)         '0003 00000108581'
                               06EDC0    (4)         '0004 00000121800'
                               06EDD0    (5)         '0005 00000113959'
                               06EDE0    (6)         '0006 00000135300'
                               06EDF0    (7)         '0007 00000091994'
                               06EE00    (8)         '0008 00000106900'
                               06EE10    (9)         '001  00000052100'
                               06EE20    (10)        '002  00000049490'
                               06EE30    (11)        '003  00000042310'
                               06EE40    (12)        '004  00000041450'
                               06EE50    (13)        '005  00000026410'
                               06EE60    (14)        '006  00000025010'
                               06EE70    (15)        '007  00000028200'

Daniel Mielke

Business Systems Analyst



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.