MVSFORUMS.com

rasprasads · Posted: Sat May 31, 2003 11:06 am Post subject: SEARCH ALL - Clarification

I have a Cobol table as :

Glenn · Beginner Joined: 23 Mar 2003 Posts: 56 Topics: 3

SEARCH is a sequential search, which is the same as the perform you mention you are doing. Your sample data indicates multiple items in field-1 so this disqualifies using SEARCH ALL, if you want to guarantee you find all field-1 items.

As long as you use an index in your perform statement, using search probably won't be much better. If you have a function in your program which could be replaced with SEARCH, then it would be good for other factors to replace that code with SEARCH.

rasprasads · Posted: Sun Jun 01, 2003 9:31 am Post subject:

Thanks Glenn.
OK. I now understand that SEARCH will not do anything better than perform. But is there any way to make this in SEARCH ALL because the job currently execution takes a very long CPU time and it is necessary to do some improvement. I know SEARCH all does not allow dupliactes, but still is there any other way around.....
_________________
Rasprasad S

Glenn · Beginner Joined: 23 Mar 2003 Posts: 56 Topics: 3

As long as you are using SEARCH (like I said, for other reasons it's good to use it instead of a perform), you should be fine on that area. Even with the perform you should be fine as long as you are using an index on this table.

Likely though you're looking in the wrong spot if you already have this table indexed.

Bithead · Posted: Mon Jun 02, 2003 9:02 am Post subject:

I have seen significant payback by converting a SEARCH to a SEARCH ALL but you have to have a large table. Try combing FIELD-1 and FIELD-2. If that cannot be done, try a REDEFINES with a second table and combine them there.

The performance of a SEARCH can be improved by using an index (preferred) or by making the subscript COMP or COMP-3.

RonB · Posted: Mon Jun 02, 2003 4:51 pm Post subject:

While BUILDING the table, append a "counter" to the FIELD-1value when storing the table element, just to make it unique. Restart the "counter" at 1 as each NEW FIELD-1value is encountered. Then, when searching, you can do a SEARCH ALL on FIELD-1value1 ( note the '1' appended to Field-1value ) - this will accomplish two things: 1) it will fail if FIELD-1value is not found; 2) if FIELD-1value IS found, the index will be positioned at the FIRST occurrence of the value.

Ron
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

rasprasads · Posted: Tue Jun 03, 2003 9:49 am Post subject:

RonB

I exactly have implemented your solution.
But have not tested it yet. Doing a SEARCH ALL will definitely reduce the CPU time. Right ?

Thanks for all the help
_________________
Rasprasad S

RonB · Posted: Tue Jun 03, 2003 2:09 pm Post subject:

Rasprasad,
In my experience, the most time-consuming thing about using internal table is the use of non-computational subscripts. Since the machine always uses binary arithmetic to determine the offsets to table elements when using subscripts, the use of non-computational subscripts can often result in huge overhead for cpu usage in doing format conversions alone. The use of an INDEXED BY clause does not even permit the specification of a PICTURE clause for the index ( Indexes are always computational in format ). That alone is often of enough significance to make it worthwhile to switch to INDEXED BY and SEARCH ALL when that is feasable.
If you were already using COMP subscripts, or your table was SMALL, or the number of table look-ups was SMALL, then you may not see much of a difference; BUT, if you were NOT using COMP subscripts, or your table was LARGE, or the number of table look-ups was LARGE, then you should see a definite improvement.
It's heartening to see that some folks, like you, are still interested in knowing the alternatives available to them to accomplish a task, and in knowing when to use which alternative, and why.
Good luck.

Ron
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

rasprasads · Posted: Wed Jun 04, 2003 2:46 am Post subject:

RonB,

Thanks a lot for the useful info.

But i have one more doubt. If i use a comp field as subscript and do a sequential search (or perform) will it give the same performance improvement as using a search all ?
_________________
Rasprasad S

Bithead · Posted: Wed Jun 04, 2003 9:03 am Post subject:

Depends on the size of the table. If it is large, then no. The maximum number of "hits" on a SEARCH ALL is about 16.

rasprasads · Posted: Wed Jun 04, 2003 11:26 am Post subject:

Thanks Bithead.

I really hate to ask questions one after the other but could not resist doing so...

My friend says we can go for a VSAM file instead of the internal tables. I think it will actually make the scenario worse as the reads will make the performance go down. Am i correct ? Internal tables are better than VSAM files in any case. Right ?
_________________
Rasprasad S

Bithead · Posted: Wed Jun 04, 2003 11:35 am Post subject:

Internal SORTED tables are better than VSAM if the table is large and you need to reference it a lot. Internal tables are better if the table is small. If you are doing a lot of adding and deleting or the internal table is large but cannot be sorted, then VSAM is probably better.

Large internal tables can also cause memory problems.