|
View previous topic :: View next topic
|
| Author |
Message |
suraaj
New User
.jpg)
Joined: 16 Apr 2009
Posts: 69
Location: Canada
|
|
|
|
Hi
I am loading a table from an external file. The table is defined using the ODO clause. The table element length is 9 and the size is 2000. The file has currently lesser records. Once the table has been loaded I am matching a file entry against the table entries to find a match using the search all. I have given a display statement at end of the search to display the last value that it tried matching both from the table as well as the file. Once I have executed that I see that the value from the file is being displayed whereas the value from the table is shown as blank. I am unable to understand this. Please help. |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| You'll have to show your definitions and code, in the Code tags please. |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| Is this a continuation of yesterday's post? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
What you have posted is pretty much useless for diagnosis of your problem. Comments and observations:
1) Using ODO in WORKING-STORAGE is not prohibited in COBOL, but the allocated size is the maximum number of entries. Hence your table size will be 2000 (elements) times 9 (bytes per element) or 18000 bytes -- period.
2) You did not post code, so we do not know if you properly initialized your table before loading it. Since you have entries not being used, you must initialize unused elements with a value greater than any value in the table, or the SEARCH ALL may give incurrect results.
3) What is the PICTURE of your table key? You stated the table element length is 9, but that just means the key could be anywhere from 1 to 9 bytes long.
4) Are the table element keys all unique or can they have duplicates? If duplicates can occur, SEARCH ALL is not guaranteed to return any particular element number (and will, in fact, return different element numbers as the number of loaded keys changes). |
|
| Back to top |
|
|
suraaj
New User
Joined: 16 Apr 2009
Posts: 69
Location: Canada
|
|
|
|
Craq Giegerich
This is a different question pertaining to the same search all that I had asked yesterday. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Make sure that the "DEPENDING ON" variable matches the number of loaded entries.
It sounds like it's set to 2000, with the unused portion of the ODO table-entries set to SPACES.
You can change it to a fix-length table (OCCURS 2000 --- NO DEPENDING ON), initialize it to HIGH-VALUES, then load the sorted-entries.
A WORKING-STORAGE ODO-Table will be allocated for the maximum length, regardless of the DEPENDING ON variable.
If you're loading the table from an external source and you know the number of entries, defining the table in LINKAGE will allow you to allocate only the storage required.
HTH.... |
|
| Back to top |
|
|
suraaj
New User
Joined: 16 Apr 2009
Posts: 69
Location: Canada
|
|
|
|
I have given the code below:
| Code: |
01 WS-TBL-NAME-TABLE.
05 WS-NAME-TABLE OCCURS 1 TO 2000 TIMES
DEPENDING ON WS-TBL-NAME-CNT
ASCENDING KEY IS WS-TBL-NAME
INDEXED BY INDX-NAME.
10 WS-TBL-NAME PIC X(09).
01 WS-INDEX PIC 9(4) VALUE ZERO.
01 WS-TABLE-MAX PIC 9(4) VALUE 2000.
77 WS-TBL-NAME-CNT PIC 9(5) COMP VALUE 0.
PERFORM UNTIL EOF-NAME-FILE-FLAG OR
NAME-TABLE-OVERFLOW
READ NAME-FILE
AT END SET EOF-NAME-FILE-FLAG TO TRUE
NOT AT END PERFORM LOAD-FILE-INTO-TABLE-PARA
END-READ
END-PERFORM.
110-LOAD-FILE-INTO-TABLE-PARA.
ADD 1 TO WS-INDEX, WS-TBL-NAME-CNT
IF WS-INDEX > WS-TABLE-MAX
SET NAME-TABLE-OVERFLOW TO TRUE
ELSE
SET WS-TBL-NAME-CNT TO INDX-NAME
MOVE NAME TO WS-TBL-NAME(INDX-NAME)
SET INDX-NAME UP BY 1
END-IF.
SEARCH ALL WS-NAME-TABLE
AT END CONTINUE
SET INDX-NAME UP BY 1
WHEN WS-TBL-NAME(INDX-NAME) = NAME
PERFORM SOME-FUNCTION
END-SEARCH.
|
|
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| IOW, your key values aren't initialized? |
|
| Back to top |
|
|
suraaj
New User
Joined: 16 Apr 2009
Posts: 69
Location: Canada
|
|
|
|
| The initialization has been done in the code. I have done the testing for matches between the file record value and table value. They work fine. My question is pertaining to the displayed output when the file record value is not found in the table and not something related to code not working. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Is NAME-FILE a VSAM file or a QSAM flat-file?
Are the records in ASCENDING order?
Do you have the ability to know the number of records in FLAT-FILE before you load the ODO table?
If so, then defining the ODO table to LINKAGE would be an advantage and you wouldn't have to worry about table-overflow because the amount of storage allocated would match the number of records, unless it exceeds 1864134. 
| Code: |
05 WS-NBR-OF-RECS PIC S9(09) COMP VALUE 9.
05 WS-CEEGTST PIC X(08) VALUE 'CEEGTST'.
05 WS-CEEGTST-HEAP PIC S9(09) COMP.
05 WS-CEEGTST-SIZE PIC S9(09) COMP.
05 WS-CEEGTST-ADDRESS POINTER.
05 WS-CEEGTST-FEEDBACK PIC X(12).
01 LS-TBL-NAME-TABLE.
05 LS-TBL-NAME-MAX PIC 9(09) COMP.
05 LS-NAME-TABLE OCCURS 1 TO 1864134 TIMES
DEPENDING ON LS-TBL-NAME-MAX
ASCENDING KEY IS LS-TBL-NAME
INDEXED BY INDX-NAME.
10 LS-TBL-NAME PIC X(09).
PROCEDURE DIVISION.
MULTIPLY LENGTH OF LS-NAME-TABLE-OCCURS (1) BY WS-NBR-OF-RECS
GIVING WS-CEEGTST-SIZE.
ADD LENGTH OF LS-TBL-NAME-MAX
TO WS-CEEGTST-SIZE.
MOVE ZERO TO WS-CEEGTST-HEAP.
*
CALL WS-CEEGTST USING WS-CEEGTST-HEAP,
WS-CEEGTST-SIZE,
WS-CEEGTST-ADDRESS,
WS-CEEGTST-FEEDBACK.
*
SET ADDRESS OF LS-TBL-NAME-TABLE TO WS-CEEGTST-ADDRESS.
MOVE WS-NBR-OF-RECS TO LS-TBL-NAME-MAX.
|
At this point, the table has been dynamically-allocated and you've allocated storage based upon the number of records (9) plus the length of the ODO variable (4). So, in this example, instead of allocating 18000 bytes (when the table is in WS, with an ODO of 2000), you've only allocated 85-bytes ((9 * 9) + 4). |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| My question is pertaining to the displayed output when the file record value is not found in the table |
I cannot decide what your problem is, but you DEFINITELY have one -- attitude, language, or something else. The code you posted does not have any "displayed output" -- so just exactly how are we supposed to figure out what the **** you are referring to? This is not psychic day!
Furthermore, if you click on the IBM Manuals link at the top of this page, find the COBOL Language Reference manual, and read 6.2.32.2.1 you will find (with emphasis added by me)
| Quote: |
| If the WHEN phrase cannot be satisfied for any setting of the index within this range, the search is unsuccessful. Control is passed to imperative-statement-1 of the AT END phrase, when specified, or to the next statement after the SEARCH statement. In either case, the final setting of the index is not predictable. |
Since the index value is not predictable, WHY DO YOU CARE WHICH VALUE IS DISPLAYED? |
|
| Back to top |
|
|
suraaj
New User
Joined: 16 Apr 2009
Posts: 69
Location: Canada
|
|
|
|
Robert,
My question is simple...what would be displayed when the table value and the file value do not match. That is the reason that I did not quote my code and also I had mentioned that I have done all the necessary initializations and coding. And I am here trying to understand the working of binary search. So irrespective of the code I am just interested in understanding why it is displaying blank value instead of any table value. Apart from this I dont have any other problems.... |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
If you display the indexed table element when the SEARCH ALL fails, YOU CANNOT PREDICT WHICH TABLE ELEMENT WILL BE DISPLAYED. This is what the manual quote I provided tells you. It is displaying a blank value ... because it is displaying a blank value; there may not be any discernable reason for that and there certainly is no way of predicting which value would be displayed.
You claim -- without providing any proof -- that you properly initialized and loaded the table. Since you are not willing to provide such proof, and the question you posed has been answered (yes, "just because" can be a valid answer at times), this topic is locked. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
| I guess I missed the memo (or this post's subtlety), but why on Earth would you need a binary-search when the table only contains 9 valid entries? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
In addition to Robert's point, which is central to your attempt to DISPLAY anything for a SEARCH ALL which does not find a key, you haven't even bothered to show the correct code:
| Quote: |
NOT AT END PERFORM LOAD-FILE-INTO-TABLE-PARA
110-LOAD-FILE-INTO-TABLE-PARA.
|
| Quote: |
| ADD 1 TO WS-INDEX, WS-TBL-NAME-CNT |
| Quote: |
IF WS-INDEX > WS-TABLE-MAX
SET NAME-TABLE-OVERFLOW TO TRUE
ELSE
SET WS-TBL-NAME-CNT TO INDX-NAME |
You show nothing to set INDX-NAME to an initial value.
| Quote: |
| MOVE NAME TO WS-TBL-NAME(INDX-NAME) |
Loading...
| Quote: |
| WHEN WS-TBL-NAME(INDX-NAME) = NAME |
Matching...
| Quote: |
AT END CONTINUE
SET INDX-NAME UP BY 1 |
This'll confuse if nothing else.
With the SEARCH ALL, the table must be indexed but SEARCH ALL itself does not use the index for searching. It is only set if there is a "hit". |
|
| Back to top |
|
|
|
|
