IBM Mainframe Forum

Hi All,

I am trying to do a SEARCH ALL in a COBOL program, but I am getting a not found condition even when the data is present. The data populated into USER-TABLE varies for each run. The table can have anywhere from 5 to 500 records. I am now testing with 6 records. When the table size is specified as 500, I am getting ‘not found’ for all the 6 rows. When the table size is reduced to 10, data is found for all rows except the last row. I replaced the ‘SEARCH ALL’ with a search (array size 500) for the same data and got the correct result. I displayed the values in the table as they are populated and it is in the sorted order on the key. Can you please have a look at the below code and help me to correct the issue?

Table definition



Initializing the table. Done before table is populated with values

Search in the program

Hello,

Are you certain the array/table data is in sequence when it is read and stored into array/table?

Suggest you initialize the entire table to high-values (x'FF's) before beginning to store anything.

Have you displayed the 6 entries in the table before starting the processing?

Either of the points Dick makes could be true and you could get exactly the results you describe.

I've never done a SEARCH/SEARCH ALL with the key defined like that. I'd always put the elements together into one key. Habit I suppose.

If you want to set the whole thing to high-values, you can do a MOVE of HIGH-VALUES to the highest group-level, rather than the loop. Maybe 1500- does not get executed?

Your "max" value is a DISPLAY numeric, much better as a BINARY/COMP.

As you load entries into the table, always check for the order.

You could consider OCCURS DEPENDING ON for the table, if your site allows. The size of the table can then be established (if you code it correctly) by what elements it contains. This reduces a couple of iterations in 6 vs 500.

To use binary search, that is Search All, the table must be specified with the Key Is varname, which seem to be missing. The rows inserted must be sorted in Ascending or Descending order, as you specify in the table declaration.
You could, I say should, specify the Depending On numvar. Set this variable to the actual number of rows inserted. This value sets the "logical" size of the table, an the unused entries will never be searched (the difference between Occurs number and Depending On numvar). This value could not exceed the physical number of entries, or you get an runtime-error, which is detected by specifying the SSRANGE compiler option.
I dont understand the idea with moving high-value(s) to the table, and should be ignored.
Also note that the Search All can only use the key, and nothing but the key, when searching. If you have other requirements, you must use the sequential search, Search, but you can still use the Depending On-clause.

The "KEY IS" is assumed for the ASCENDING.

The high-values (or any other value higher than the highest possible key) is so that the SEARCH ALL will work with a fixed-length table. Some sites do not allow OCCURS DEPENDING ON.

Thank you everyone for your replies
I changed the table from fixed length to 'OCCURS DEPENDING ON' and now the SEARCH ALL is working fine.

Thanks again..

OK, if tested, that means your table was in sequence before the SEARCH ALL, so your 1500- was somehow failing.

I think you need to resolve the actual problem, rather that just moving on with what we already knew should work. Problem with ignoring what went wrong is 1) you don't know to avoid/recognise it next time and 2) something else may also not be being done along with the initialisation and 3) it may be a "symptom" of a different problem, that will raise an ugly head later.

For instance, if you are initialising correctly and something else is messing up your table instead of doing what it should be doing, now your SEARCH will work but the other bit you don't even know is wrong. You've ignored the symptom.

Anyway, I guess you'll not be back until the next problem to read this...

Hello,

OK, if tested, that means your table was in sequence before the SEARCH ALL, so your 1500- was somehow failing.

I suspect the problem with the "not found" values was because the table beyond the used entries was not properly initialized.