Apologies, but, I was under the impression that the forum is meant for the like-minded people to sit & DISCUSS different approaches/opinions which is clearly not the case. I have got no issues in accpeting that I am a beginner as compared to most of the guys sitting here. But, the intent to post solutions or examples was only to caveat others from commiting the same mistakes. Disappointed!!!BillyBoyo wrote:Try two effects.
Firstly use HIGH-VALUES not LOW-VALUES to initialise the table. You'll find it "works".
Better without bothering to initialise, use OCCURS DEPENDING ON, so that the table has a length.
As a test, do two small programs with each solution and do some sort of timing test (do the SEARCH ALL lots of times). Compare.
Thanks so much Billy. That did work for me. I have stumbled upon the solution on a forum only. Really Appreciate!!!
Thanks & Regards,
Firstly, Robert has helped you to get to the solution as well. You were just plain using the SEARCH ALL incorrectly. Because of the low-values, your table is not in key-sequence, so the binary-search of SEARCH ALL cannot possibly work.
It is not a problem that you get no error of any sort to indicate this. The point of the SEARCH ALL is to do a job (looking up a table) quickly. If it were to also check the the table was in sequence, it would use its usefulness*.
If you want to really mess things up, have a table, initialised with low-values, which has one-more-than-half-the-entries amount of data (so, 20 in the occurs, 11 pieces of data). Then test your program.
Is it working now? (This is not a solution, it is an "exercise"). Please try it, Nik, and let us know.
We do discuss things, but we don't discuss the incorrect use of a particular statement in a particular language. I was looking at a MOVE statement the other day and I failed to get any Bananas out of it. I looked in the manual and discovered my expectations were unrealistic (no fruit-related options at all, not even a vegetable possibility). There was nothing left to "discuss" with anyone. This is another way of making one of Robert's points.
When posting something, read it through a few times, pretending you don't know anything about what is being asked, and that can help you see the shortcomings. Correct and submit.
* I fear that someday IBM will decide that the SEARCH ALL as it is causes too many problems when used incorrectly. Like INITIALIZE (for those unable to correctly initialise tables), SSRANGE (for those who can't test for limits correctly) and NUMPROC(NOPFD) (for those who can't get data to conform to PICtures for numerics) SEARCH ALL will be changed to do a sequence check each time it is referenced.