Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

SEARCH ALL problem

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 1:38 am    Post subject: SEARCH ALL problem
Reply with quote

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
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 2:27 am    Post subject:
Reply with quote

Is your table in sequence?
Back to top
View user's profile Send private message
ridgewalker58

New User


Joined: 26 Sep 2008
Posts: 51
Location: New York

PostPosted: Thu May 05, 2011 2:34 am    Post subject:
Reply with quote

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
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 2:45 am    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 3:52 am    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu May 05, 2011 4:44 am    Post subject:
Reply with quote

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
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 642
Location: Whitby, ON, Canada

PostPosted: Thu May 05, 2011 6:24 pm    Post subject:
Reply with quote

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
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 6:39 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 6:57 pm    Post subject: Reply to: SEARCH ALL problem
Reply with quote

I'm still not so sure. Would you like to post the relevant definition and code?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Thu May 05, 2011 7:09 pm    Post subject: Reply to: SEARCH ALL problem
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 8:13 pm    Post subject: Re: SEARCH ALL problem
Reply with quote

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
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 8:33 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 9:03 pm    Post subject:
Reply with quote

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
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 9:30 pm    Post subject:
Reply with quote

Thanks Bill. I modified the array as an indexed array and there was significance improvment in run time.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 9:47 pm    Post subject: Reply to: SEARCH ALL problem
Reply with quote

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
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 9:57 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 10:11 pm    Post subject:
Reply with quote

Now I'm confused again. What do you mean by "indexed array"?
Back to top
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu May 05, 2011 10:58 pm    Post subject:
Reply with quote

oops again wrong terminology.
I wanted to refer to array in which we use "DEPENDING ON".
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu May 05, 2011 10:59 pm    Post subject:
Reply with quote

OK. Sounds good.

Good luck with the rest!
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri May 06, 2011 12:08 am    Post subject:
Reply with quote

Enterprise cobol does not allow (as COBOL-II does not allow)
subscripts in a SEARCH ALL.

a SEARCH ALL requires an
  1. INDEXED BY .. phrase
  2. ASCENDING/DESCENDING phrase


the TS's first comment was subscripts.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Problem in writing Output file vickey_dw COBOL Programming 5 Mon Nov 14, 2016 11:14 pm
No new posts Problem in Running Query via JCL vickey_dw DB2 3 Tue Oct 18, 2016 11:11 pm
No new posts DB2 Streaming Batch Processing Problem Manshadi DB2 4 Sat Sep 24, 2016 12:14 pm
No new posts Problem with GETMAIN command amitc23 CICS 6 Thu Sep 01, 2016 1:01 pm
No new posts TXT2PDF problem - printing @ in PDF vipul65 All Other Mainframe Topics 9 Thu Aug 25, 2016 12:48 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us