Low values and High values



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Re: low values and high values

Postby Sivaji » Thu Dec 15, 2011 5:00 pm

@BillyBobo: Thanks for the detailed explanation..
Sivaji
 
Posts: 8
Joined: Thu Dec 15, 2011 3:55 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Re: low values and high values

 

Re: low values and high values

Postby BillyBoyo » Thu Dec 15, 2011 6:00 pm

No problem. If you have any specific questions or want clarification of something, someone will probably pick it up.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: low values and high values

Postby dick scherrer » Fri Dec 16, 2011 1:34 am

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: low values and high values

Postby Nik22Dec » Wed Dec 28, 2011 12:11 pm

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
Thanks,
Nik
User avatar
Nik22Dec
 
Posts: 68
Joined: Mon Dec 26, 2011 6:38 pm
Has thanked: 2 times
Been thanked: 0 time

Re: low values and high values

Postby BillyBoyo » Wed Dec 28, 2011 2:34 pm

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
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: low values and high values

Postby Nik22Dec » Wed Dec 28, 2011 3:19 pm

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.
Thanks,
Nik
User avatar
Nik22Dec
 
Posts: 68
Joined: Mon Dec 26, 2011 6:38 pm
Has thanked: 2 times
Been thanked: 0 time

Re: low values and high values

Postby BillyBoyo » Wed Dec 28, 2011 3:59 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: low values and high values

Postby Robert Sample » Wed Dec 28, 2011 6:44 pm

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
Global moderator
 
Posts: 3367
Joined: Sat Dec 19, 2009 8:32 pm
Location: East Dubuque, Illinois
Has thanked: 1 time
Been thanked: 222 times

Re: low values and high values

Postby Nik22Dec » Thu Dec 29, 2011 11:55 am

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
Thanks,
Nik
User avatar
Nik22Dec
 
Posts: 68
Joined: Mon Dec 26, 2011 6:38 pm
Has thanked: 2 times
Been thanked: 0 time

Re: low values and high values

Postby dick scherrer » Thu Dec 29, 2011 12:27 pm

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.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

PreviousNext

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post