|
View previous topic :: View next topic
|
| Author |
Message |
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
Hi All,
When I am executing below lines of code it is going in if portion.
| Quote: |
IF COMPANY-CODE (INDEX) EQUAL COMPANY-CODE-3
AND POLICY-NUMBER (INDEX) EQUAL
POLICY-NUMBER-10
DISPLAY 'RAHUL'
else
Display 'error'
END-IF |
but when the same condition for same index are in search all it is not working.
| Quote: |
SEARCH ALL DETAIL-RECORD-AREA
WHEN
COMPANY-CODE (INDEX)
= COMPANY-CODE-3
AND
POLICY-NUMBER (INDEX)
= POLICY-NUMBER-10
DISPLAY 'RAHUL-1'
PERFORM 10000-UPDATE
THRU 10000
END-SEARCH. |
Please let me know the reason for this.
Thanks. |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Is your table in sequence? |
|
| Back to top |
|
|
ridgewalker58
New User
Joined: 26 Sep 2008
Posts: 51
Location: New York
|
|
|
|
You haven't stated how your table is described
1. Do you have an OCCURS DEPENDING ON clause
2. Is it loaded in ASCENDING sequence by COMPANY-CODE and
POLICY-NUMBER
3. If the table doesn't have an OCCURS DEPENDING ON clause -- is it fully loaded or has it been CORRECTLY initialized |
|
| Back to top |
|
|
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
I got it.I defined a static table array. So by default it was having low values.THerefore the table was not in sorted order so SEARCH-ALL.
THanks Bill. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| rgupta71 wrote: |
I got it.I defined a static table array. So by default it was having low values.THerefore the table was not in sorted order so SEARCH-ALL.
THanks Bill. |
OK, I'm glad it is working. I have to say, after "I got it" I can't understand what you are saying. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| I defined a static table array |
Click on the Manuals link at the top of this page, find the COBOL Language Reference manual, and study it -- for weeks if needed -- until you stop making such insane statements as this. There is no such thing in COBOL as a "static table array". In fact, I searched the entire manual for static and got back
| Quote: |
6 topics have matches for: static
1. COBOL class definition structure, 2.2
2. INVOKE statement, 6.2.22
3. Glossary, GLOSSARY
4. Method overriding (for instance methods), 3.1.5.2.2
5. INDEXED BY phrase, 5.3.11.3
6. Data division overview, 5.1 |
NONE of which refer to tables -- or arrays -- as such. The term "static" refers to memory in this manual -- and only to memory.
| Quote: |
| So by default it was having low values. |
Wrong again. There is NO default value for memory in z/OS COBOL. Some sites, maybe many sites, have set a site parameter to initialize memory to LOW-VALUES, but there is no default to do this -- only site standards. |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| Robert Sample wrote: |
| Wrong again. There is NO default value for memory in z/OS COBOL. Some sites, maybe many sites, have set a site parameter to initialize memory to LOW-VALUES, but there is no default to do this -- only site standards. |
I'd like to second your warning. I have debugged many problems where the programmer made unwarranted assumptions about the state of uninitialized storage. I even saw a case where the Cobol code generated by the DB2 SQL Coprocessor fell into this trap; a trap that was only sprung when the program was promoted into a production IMS region. |
|
| Back to top |
|
|
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
Thanks everyone for correcting my terminology.
I was having one table which was a subscripted array.So, if I was having 1 entry in the table all other were having low values.Therefore it was not working.I initialized it with high values and it was working. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| I'm still not so sure. Would you like to post the relevant definition and code? |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
For an "ODO" array, the SEARCH ALL should work as advertised, providing the "ODO" high-bound is properly set. However, for a "FIXED" array, where not all entries have been populated, the entire array needs to be initialized to HIGH-VALUES, followed by initialization/loading of each entry.
Not to beat on a dead horse, but the array needs to be populated in ASCENDING or DESCENDING order.
Bill |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| rgupta71 wrote: |
[...]
SEARCH ALL DETAIL-RECORD-AREA
WHEN
COMPANY-CODE (INDEX)
= COMPANY-CODE-3
AND
POLICY-NUMBER (INDEX)
= POLICY-NUMBER-10
DISPLAY 'RAHUL-1'
PERFORM 10000-UPDATE
THRU 10000
END-SEARCH. |
Going back to your original, you have nothing in here for "not found". INDEX is a "reserved word", so maybe this is not your actual code and you have something already.
If you use a plain OCCURS, with table initialised to HIGH-VALUES, you'll do a couple of irrelevant searches (or the SEARCH will) depending on how empty your table is. With Occurs Depending On, only the "active" part of the table will be searched.
It can be nice to check the previous key to see if it is the same as the current key, then you don't need the search at all for that time. |
|
| Back to top |
|
|
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
You are right thats not the actual code.Its the pseudo code of what I was doing
The problem in using occurs depending on is that how will I know how many rows are returned when I declared the cursor. Using count is not allowed.
Array will have uniques entries but not the DB2 table. So this doesn't apply
| Quote: |
| It can be nice to check the previous key to see if it is the same as the current key, then you don't need the search at all for that time. |
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| rgupta71 wrote: |
You are right thats not the actual code.Its the pseudo code of what I was doing
The problem in using occurs depending on is that how will I know how many rows are returned when I declared the cursor. Using count is not allowed.
Array will have uniques entries but not the DB2 table. So this doesn't apply
| Quote: |
| It can be nice to check the previous key to see if it is the same as the current key, then you don't need the search at all for that time. |
|
You have a Cobol table. You are loading that table, with unique keys, in sequence. At some point you finish loading the Cobol table. Then you know how many entries are in the table. And that (or a copy of it) can be your Occurs Depending On. It doesn't matter where the data is coming from. If you are worried about how much stuff DB2 will give back to you, that is the same problem with an ordinary table as with ODO. In the case of SEARCH ALL, the only use of the ODO is to tell the SEARCH how many entries there are.
The DB2 entries aren't unique, you say? No big surprise. How does that connect with checking whether you've already searched the Cobol table for that key? Keys 1, 2, 3 in Cobol table, DB2 comes back with 2, 1, 3, 3, 2, 3, 1, 1, 1, 1, 3, 2, 4, 99, 0, 1, 1, 1. Saves 6 searches out of 19, if you check.
| Code: |
if NOT table-key-same-as-last
do table-key-search
end-if
if table-key-found /* for most recent key actually searched */
do table-key-found-processing
else
do key-not-in-table-processing
end-if
|
|
|
| Back to top |
|
|
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
| Thanks Bill. I modified the array as an indexed array and there was significance improvment in run time. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
No problem, thanks.
You mean Occurs Depending On, I assume?
Now you've got it, test it well.
I've had a "significant improvement in performance" reported to me that turned out to be accidently avoiding the main part of the processing :-) |
|
| Back to top |
|
|
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
Actually that array was defined as OCCURS 100000 times so it used to search for 10000 entries even though the entries in the table were 5.
Using indexed array we reduced the search which were not needed. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Now I'm confused again. What do you mean by "indexed array"? |
|
| Back to top |
|
|
rgupta71
Active User
Joined: 21 Jun 2009
Posts: 160
Location: Indore
|
|
|
|
oops again wrong terminology.
I wanted to refer to array in which we use "DEPENDING ON". |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
OK. Sounds good.
Good luck with the rest! |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Enterprise cobol does not allow (as COBOL-II does not allow)
subscripts in a SEARCH ALL.
a SEARCH ALL requires an - INDEXED BY .. phrase
- ASCENDING/DESCENDING phrase
the TS's first comment was subscripts. |
|
| Back to top |
|
|
|
|
