|
View previous topic :: View next topic
|
| Author |
Message |
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
In a Cobol program, I am loading a sorted file that has around 100000 records first into an array defined for "search" and then an array defined for "search all". Then I am reading a file and searching a key record into both defined array separately. However, after searching the record into array defined for "search all" is giving around 1 % less records as compare to the array defined for "search". Other records are same. I think this should not happen and in both the cases I should get same file.
Please advice. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Do you initialize the "SEARCH ALL" file? If so, what do you initialize it to? How many table entries are there and how many are loaded from the file?
The COBOL SEARCH ALL verb mandates the table be sorted into ascending sequence. If your table is larger than the number of entries you loaded from the file, you must set the remaining entries to some value larger than the highest key value loaded (typically HIGH-VALUES is used) or the SEARCH ALL verb may not always return the correct results. |
|
| Back to top |
|
|
Ronald Burr
Active User
Joined: 22 Oct 2009
Posts: 293
Location: U.S.A.
|
|
|
|
| Actually, the table being referenced by a 'SEARCH ALL' can be in either ASCENDING KEY or DESCENDING KEY sequence. If ASCENDING KEY sequence, unused entries are typically filled with HIGH-VALUES, as Robert indicated. If DESCENDING KEY sequence, the unused entries are typically filled with LOW-VALUES. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Pankaj,
what is the data layout definition of your two COBOL internal tables?
you are correct, results from both 'tables' should be the same.
in fact, the processing time should be less for the SEARCH ALL (binary search) than for the SEARCH.
might as well provide your code for both 'searches'.
you have something wrong, otherwise the results would be the same. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Ronald, you're right -- I forgot about the descending key feature and I definitely should have mentioned it. |
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
Pankaj,
Are you saying that the total number of occurrences of the "search all" table is about 1% less than the total number of occurrences of the "search" table? Or are you saying that you get fewer "hits" during the SEARCH ALL than during the SEARCH? Please clarify. Also, please answer the questions by the dinosauer and Robert. |
|
| Back to top |
|
|
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
| Robert Sample wrote: |
Do you initialize the "SEARCH ALL" file? If so, what do you initialize it to? How many table entries are there and how many are loaded from the file?
The COBOL SEARCH ALL verb mandates the table be sorted into ascending sequence. If your table is larger than the number of entries you loaded from the file, you must set the remaining entries to some value larger than the highest key value loaded (typically HIGH-VALUES is used) or the SEARCH ALL verb may not always return the correct results. |
Yes, with SEARCH ALL verb, I am using sorted input file.
Can you please explain bit more this HIGH-VALUES thing. |
|
| Back to top |
|
|
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
| Terry Heinze wrote: |
Pankaj,
Are you saying that the total number of occurrences of the "search all" table is about 1% less than the total number of occurrences of the "search" table? Or are you saying that you get fewer "hits" during the SEARCH ALL than during the SEARCH? Please clarify. Also, please answer the questions by the dinosauer and Robert. |
Hi Terry,
I was saying that I got fewer "hits" during the SEARCH ALL than during the SEARCH.
Thanks |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Before loading the entries into the SEARCH ALL table, you need to move HIGH-VALUES to the entire array so that the "unused entries" at the end are in sequence. |
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
| As requested, we need to see the definitions of the tables, the code that loads them and the code that searches them. Please use BBCode (see FAQ). |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
ppandey07,
if you would use an ODO (occurs depending on)- both your SEARCH instructions would execute faster
- you would not need to know all this esoteric stuff about initializing tables, etc...
Suggest you read the COBOL Application Programmers manual about COBOL internal tables;
which you obviously not done. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| delete by poster. |
|
| Back to top |
|
|
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
| Terry Heinze wrote: |
| As requested, we need to see the definitions of the tables, the code that loads them and the code that searches them. Please use BBCode (see FAQ). |
The way I am defining my table for "seach all" is :
< 01 WS-CES-TABLE.
05 WS-CES OCCURS 99999 TIMES ASCENDING KEY IS WS-CES-SORT-KEY
INDEXED BY CESX.
10 WS-CES-SORT-KEY.
15 WS-CES-POLICY PIC X(06).
15 WS-EMPLOY-ID PIC X(9).
15 WS-CES-FIRST-NAME PIC X(10).
15 WS-CES-BIRTH-DATE PIC 9(08).
15 WS-CES-RELATIONSHIP PIC X(02).
10 WS-CES-MED-PRISEC-IND PIC X(01).
10 WS-CES-START-DATE PIC X(08).
10 WS-CES-STOP-DATE PIC X(08). >
and I am using the "search all" verb as
<SEARCH ALL WS-CES
AT END
CONTINUE
WHEN WS-CES-SORT-KEY (CESX) = WS-COB2-SORT-KEY
PERFORM VARYING WS-SUB FROM 1 BY 1
UNTIL WS-SUB > COB2-LINE-COUNT
EVALUATE TRUE
WHEN
in evaluate checking few condtions and WS-COB2-SORT-KEY is the key field from file >
Can you please adivise if there is anything wrong. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Can you please adivise if there is anything wrong. |
Where's your code that verifies the table is loaded in ascending sequence by WS-CES-SORT-KEY? Where do you verify that you do not have any duplicates in WS-CES-SORT-KEY in the table? From the COBOL Language Reference manual:
| Quote: |
The results of a SEARCH ALL operation are predictable only when:
* The data in the table is ordered in ASCENDING KEY or DESCENDING KEY order
* The contents of the ASCENDING or DESCENDING keys specified in the WHEN clause provide a unique table reference. |
|
|
| Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008
Posts: 1249
Location: Richfield, MN, USA
|
|
|
|
| I asked for 5 things and to use BBCode. You have provided only 2 of the 5 and didn't use BBCode. You can't expect much help when you don't provide the information requested. |
|
| Back to top |
|
|
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
| Robert Sample wrote: |
| Quote: |
| Can you please adivise if there is anything wrong. |
Where's your code that verifies the table is loaded in ascending sequence by WS-CES-SORT-KEY? Where do you verify that you do not have any duplicates in WS-CES-SORT-KEY in the table? From the COBOL Language Reference manual:
| Quote: |
The results of a SEARCH ALL operation are predictable only when:
* The data in the table is ordered in ASCENDING KEY or DESCENDING KEY order
* The contents of the ASCENDING or DESCENDING keys specified in the WHEN clause provide a unique table reference. |
|
Hi all,
Thank you all!!! its working fine now... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Good to hear it is working 
What was the problem and what fixed it?
The answer may help someone with a similar problem one day.
d |
|
| Back to top |
|
|
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
| dick scherrer wrote: |
Good to hear it is working
What was the problem and what fixed it?
The answer may help someone with a similar problem one day.
d |
The input file that I was loading into table( defined with "search all") had some duplicate records. Thats why, I was getting small difference in output records.
Thanks all once again for your tips  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Thanks for posting the solution
d |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Keep in mind that your WS table is around 5MB.
I imagine you've defined it this large because of the unknown number of records on the file?
So (for example), if you only use 10% of this table, then you'd be wasting 4.5MB 
Is this a VSAM (KSDS/ESDS) or sequential (Non-VSAM) flat-file?
Bill |
|
| Back to top |
|
|
ppandey07
New User
Joined: 27 Nov 2008
Posts: 51
Location: Delhi, India
|
|
|
|
| Bill O'Boyle wrote: |
Keep in mind that your WS table is around 5MB.
I imagine you've defined it this large because of the unknown number of records on the file?
So (for example), if you only use 10% of this table, then you'd be wasting 4.5MB
Is this a VSAM (KSDS/ESDS) or sequential (Non-VSAM) flat-file?
Bill |
This is sequential (Non-VSAM) flat-file. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
If you can inform the COBOL program of the number of records on the file, then you can define the ARRAY to LINKAGE and then use LE Callable Service routine 'CEEGTST' to obtain the correct amount of storage needed for the ARRAY.
You can define the ARRAY as a true ODO (Occurs Depending On) with the DEPENDING ON being a Binary-Fullword defined just above the actual ARRAY definition, within the "01" definition.
Example -
| Code: |
01 LS-ARRAY-REC.
03 LS-ARRAY-NBR-RECS PIC S9(09) BINARY.
03 LS-ARRAY OCCURS 1 TO 99999 TIMES
DEPENDING ON LS-ARRAY-NBR-RECS
INDEXED BY X-LS-AR, X-LS-AR-MAX
PIC X(52).
|
So, for example, if the number of file-records was 100, the amount of dynamic-storage needed would be (Record-Length * Number-of-Records) + LENGTH OF LS-ARRAY-NBR-RECS.
Bill |
|
| Back to top |
|
|
|
|
