Look up Key for a file is 124 bytes. The key is populated partially. In such a case is READ more efficient or HISTOGRAM more efficient.
To do what???
There is only one scenario that comes to mind where the functionality of READ and HISTOGRAM actually overlaps. You can use READ (1) or HISTOGRAM (or FIND NUMBER) to ascertain if a value exists on a file. Since both HISTOGRAM and FIND NUMBER deal with the entire string of ISNs for a value (to populate *NUMBER), it is possible that a READ might outperform them if there are likely to be many ISNs for a given value.
Otherwise, FIND NUMBER and HISTOGRAM would tend to be more efficient.
What do you mean by “populated partially”, and what functionality are you interested in comparing?
steve
Thanks Steve.
I am populating first 24 bytes of the lookup key (total length 124 bytes). Then I use a HISTOGRAM to retrieve record. The fetched record is used for further processing (No updations).
There is only one record for a key (24 bytes).
I also tried the same with READ, it works fine. Is there any performance related issue - Memory or time using READ and HISTOGRAM.
The file contains only few thousand (s) records.
Bhargavi said:
Then I use a HISTOGRAM to retrieve record. The fetched record is used for further processing (No updations).
No you don’t!!! HISTOGRAM does not read records!! HISTOGRAM only retrieves values of the field being HISTOGRAM’ed; it does not read any other field values.
steve
The file contains records of different formats. Lookup key (total length is 124 bytes) is built with first 24 bytes. Once the record is fetched, the remaining part of the key itself is used as data for further processing.
In this situation which method is best suggested - READ/ HISTOGRAM.
Hy there,
it is a long time ago, but i thought an Histogram invokes a ‘L9’ to Adabas and an find number invokes a ‘S1’. So Histogram only needs to read the inverted lists of the Database while Find number also writes the ISN-List to the Work Area. Correct me if this is not so. So i think a historgram is a little bit faster.
Greetings
Sascha Wiegandt
Hi Bhargavi;
I know you probably think you have explained your problem adequately to get answers. Actually, there is a ton of information missing. So, I will guess at some of the background and go from there.
I will assume there is a 24 byte field that uniquely identifies a record. The other 100 bytes is “data”. You will be getting a 24 byte value from “somewhere” (maybe the user types it in? a bad idea, too many characters; use a selection box), either via INPUT, or a work file (?).
You must then do two things. First, you must test whether there is a record with the specified 24 characters. Second, if there is such a record, you must “process” the record, which involves other data from the record.
Lets assume that most of the time the record exists. HISTOGRAM does not read records. So, if you used HISTOGRAM to determine existence, you would still have to do a READ. Hence, you might as well start with a READ.
If the record does not exist most of the time, you should probably redesign your system; something is wrong.
I realize I might not be interpreting the problem correctly. For example, assume that the 124 byte field is a descriptor all by itself. You might want to do a HISTOGRAM on such a field using STARTING FROM the 24 byte value. Now you would get a 124 character value, and, if you require no other data from the record, you would have everything you need without doing a READ.
You mentioned the file was only several thousand records. If the file will not be growing in size, it probably doesn’t matter too much which way you go. However, I would use the READ if I needed data other than the 124 byte field, and HISTOGRAM if I only need the 124 byte field and it is a descriptor.
steve
Is it possible to see the ddm for this file. From the sounds of it, you have a field that is A124 and a subdescriptor of A24 on this field. That being the case, a histogram will only bring back the first 24 bytes that are contained in the subdescriptor, it will know nothing of the last 100 bytes. So if you need the last 100 bytes, you will have to find on the record.