IBM Mainframe Forum

@BillyBobo: Thanks for the detailed explanation..

No problem. If you have any specific questions or want clarification of something, someone will probably pick it up.

Hello,

just want to know the exact scenario(usage) or when i can go for a low/high value to a field or when i can go for a initialize a variable using zeroes and spaces..

You have presented a "solution" in search of a "requirement"

The use of low- or hi-values is situation dependent. Unless one is working with something that already uses these, there might be no "need" to use either.

BillyBoyo wrote:If there is a table that you want to use SEARCH on, it can be useful to initialise the tabel to high-values so that you will know when you have reached the end of the data in the table. I'd use high-values so that if someone changes to a SEARCH ALL the initialise does not need to change even if the person making the change does not make the table variable-length with OCCURS DEPENDING ON.

To add to what Billy has said, in a situation where in the array(using occurs) has been initialised by low-values & search all is used, the search all will only check the first element & will finish the search irrespective of the element being present in the array or not.

Also, conceptually, the cursor before fetching the first row & after fetching the last row from the DB2 Table contains low-values & high-values respectively.

Thanks & Regards,
Nikhil

Nik22Dec wrote:[...]in a situation where in the array(using occurs) has been initialised by low-values & search all is used, the search all will only check the first element & will finish the search irrespective of the element being present in the array or not.
[..]

I don't understand this at all.

1. Whatever value the table has been initialised to, if actual data has been put in the table, the initial value for that element no longer exists.
2. If, with SEARCH ALL, a table-entry with low-values is revealed while the SEARCH ALL is progressing, the SEARCH ALL would know that the only possible location for an entry would be "higher" than the low-value entry found. In no way would it just give up looking.
3. If a (correct for the SEARCH ALL to work) table which is to be SEARCH ALLed contains low-values as valid data, it could only appear as the first entry.
4. As far as I know, SEARCH ALL does not start by checking the first entry of a table. SEARCH ALL does a "binary search" and its first check is going to be the middle of the table. If you'd like to generate the pseudo-assembler and show us that this is now different, please feel free.

BillyBoyo wrote:

Nik22Dec wrote:[...]in a situation where in the array(using occurs) has been initialised by low-values & search all is used, the search all will only check the first element & will finish the search irrespective of the element being present in the array or not.
[..]

I don't understand this at all.

1. Whatever value the table has been initialised to, if actual data has been put in the table, the initial value for that element no longer exists.
2. If, with SEARCH ALL, a table-entry with low-values is revealed while the SEARCH ALL is progressing, the SEARCH ALL would know that the only possible location for an entry would be "higher" than the low-value entry found. In no way would it just give up looking.
3. If a (correct for the SEARCH ALL to work) table which is to be SEARCH ALLed contains low-values as valid data, it could only appear as the first entry.
4. As far as I know, SEARCH ALL does not start by checking the first entry of a table. SEARCH ALL does a "binary search" and its first check is going to be the middle of the table. If you'd like to generate the pseudo-assembler and show us that this is now different, please feel free.

Sorry, if I could not explain myself clearly. I was talking about a scenario wherein, the table of say 200 elements has been initialised by low values and then, the data has been moved in the first 10 occurences only. In that case, SEARCH All will fail to search the value but, the SEARCH ALL will get completed without any errors.

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.

Sorry, if I could not explain myself clearly. I was talking about a scenario wherein, the table of say 200 elements has been initialised by low values and then, the data has been moved in the first 10 occurences only. In that case, SEARCH All will fail to search the value but, the SEARCH ALL will get completed without any errors

Well, of course not. If you violate the requirements for SEARCH ALL, then who knows what you will get? And initializing a 200-element table to LOW-VALUES, loading values into the first 10 elements, then attempting to use SEARCH ALL definitely violates the requirements laid out in the COBOL Language Reference manual. SEARCH ALL requires the table to be in ASCENDING SEQUENCE -- and placing LOW-VALUES after data records violates that requirement. There are many, many ways we could put out examples of things that do not work -- the idea here is to provide examples that do work.

Nik22Dec, your suggestion is completely and totally WRONG and if that is the type of advice you give beginners and students, you'd be better off becoming a beginner and student yourself. There is an expectation on this forum that if you offer advice about COBOL that you at least know enough COBOL to give valid advice, and so far you have proved that is not the case for yourself.

Robert Sample wrote:

Sorry, if I could not explain myself clearly. I was talking about a scenario wherein, the table of say 200 elements has been initialised by low values and then, the data has been moved in the first 10 occurences only. In that case, SEARCH All will fail to search the value but, the SEARCH ALL will get completed without any errors

Well, of course not. If you violate the requirements for SEARCH ALL, then who knows what you will get? And initializing a 200-element table to LOW-VALUES, loading values into the first 10 elements, then attempting to use SEARCH ALL definitely violates the requirements laid out in the COBOL Language Reference manual. SEARCH ALL requires the table to be in ASCENDING SEQUENCE -- and placing LOW-VALUES after data records violates that requirement. There are many, many ways we could put out examples of things that do not work -- the idea here is to provide examples that do work.

Nik22Dec, your suggestion is completely and totally WRONG and if that is the type of advice you give beginners and students, you'd be better off becoming a beginner and student yourself. There is an expectation on this forum that if you offer advice about COBOL that you at least know enough COBOL to give valid advice, and so far you have proved that is not the case for yourself.

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,
Nik

Hello,

But, the intent to post solutions or examples was only to caveat others from commiting the same mistakes. Disappointed!!!

Don't be - it can take a while to adjust to a new environment.

It is far better to post "solutions" that are tested and working. Posting things that cannot work should be avoided. If you are in a discussion group at some training facility and the group wants to talk about things that have caused them problems, great. These are best avoided on a forum where there is no common background and language between most of the participants.