read by which index? - cobol

Now I'm extremely glad I said "Thanks" to all of you. I have mostly used NE
a little in the past few years for my own hobby projects. I very recently
was given the opportunity to make a little money to add to my social
security - Whew!

My Net Express was running on an old laptop that was about to expire, and
Pete helped me get MicroFocus to allow me to move it to a newer laptop FOR
FREE. He has helped me on previous occasions - a special thank you to Pete.

And I'm always astonished how my queries in this and other news groups
expand in so many (sometimes unrelated) directions.

<docdwarf@panix.com> wrote in message news:gdq6ob$7hf$1@reader1.panix.com...
> In article <6mbcpoFftgouU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>
>>
>><docdwarf@panix.com> wrote in message
>>news:gdpp1f$dv4$1@reader1.panix.com...
>>> In article <6mav50Fftd0jU1@mid.individual.net>,
>>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>>>
>>>>
>>>>"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>>>>news:cJSLk.124904$KY3.40003@fe02.news.easynews.com...
>>>>> If your ACCESS Is SEQUENTIAL, then you need to use the START (with the
>>>>> KEY
>>>>> IS phrase) and then a bunch of READ NEXT statements.
>>>>>
>>>>> If your ACCESS IS DYNAMIC or RANDOM, then you should just use the READ
>>>>> statement and use the KEY IS phrase (as mentioned below).
>>>>
>>>>And what if the Alternate has duplicates? :-)
>>>
>>> I believe that one is notified of this by the value of the field
>>> specified
>>> in FILE STATUS clause, Mr Dashwood... did you know that?
>>
>>Yes, Mr Dwarf I was well aware of that. :-)
>
> Then why bother to ask?

Because that had a bearing on finding the actual record required. I wasn't
asking about how one detects if there are duplicate keys, or if a record
which ios part of a duplicate set has been returned.

You simply misinterpreted my question.

READ ... KEY IS returns a record. The point is that it may not be the
required record. Hence my question.



>
>>Unfortunately, the contents of this field are updated AFTER access has
>>occurred so it doesn't help in any way to ensure that I get the specific
>>record (out of all the duplicates) that I actually want.
>
> Mr Dashwood, you did not ask anything about getting any particular record,
> you asked about 'what if the Alternate has duplicates?'. If your question
> had concerned data, and how to get to them, you might have thought to ask
> about those.

I did. You simply didn't make the connection. The clue was in READ... KEY
IS.
>
> (for those who aren't familiar with it... there is an Olde Joke about a
> fellow in a balloon asking something of someone on the ground; the oldest
> version I can find uses an 'Information Technology Worker' as the grounded
> one but the version I was taught had him as a Programmer. See
> <http://groups.google.com/group/alt.legend.atlantis/msg/b7ea3e01773a5ba1?dmode=source>)
>

Unfortunately showing its age now... (like many of us...)

It was amusing the first time you referenced it, subsequent references have
become less so.

Pete.
--
"I used to write COBOL...now I can do anything."

"Paul H" <NoSpamphobergNoSpam@att.net> wrote in message
news:4900cde3$0$5470$bbae4d71@news.suddenlink.net...
> Now I'm extremely glad I said "Thanks" to all of you. I have mostly used
> NE
> a little in the past few years for my own hobby projects. I very recently
> was given the opportunity to make a little money to add to my social
> security - Whew!
>
> My Net Express was running on an old laptop that was about to expire, and
> Pete helped me get MicroFocus to allow me to move it to a newer laptop FOR
> FREE. He has helped me on previous occasions - a special thank you to
> Pete.
>

Thank you for the acknowledgement, Paul. It isn't required, and I was glad
to help, but it is still nice to have.

I agree with Michael and Jimmy that many people come here and get helped
and, once their problem is solved, they see no need to acknowledge the help
they received.

Apart from it being bad manners, it really doesn't help other people if the
solution that was finally adopted isn't made known.

For myself, I am part of Michael's Boomer generation and had the same values
instilled in me that he also had. "Giving is good".

I believe it is summed up in the old saw: "Virtue is its own reward."

Sounds so Victorian in this day and age... :-)

When people are under pressure they can often only see the problem. When the
problem is solved, they simply don't think about the assistance they
received, or the fact that other people might have the same problem and
could be helped by their experience.

My IT career has been good to me and I see helping people here as part of
giving something back.

But most importantly, the exchanges here are fun and that alone makes it
worth the effort.

Pete.
--
"I used to write COBOL...now I can do anything."

<previous thread contents snipped>

In the case of alternate keys with duplicates, then what do you do?

Option 1:
If you know your records and when you do and don't have duplicates, it is
POSSIBLE that the information you want from records with alternate duplicate
keys is always the same in all such records. In such cases, then you can get it
from whichever record you have retried from the first READ ... KEYS IS
statement.

Option 2:
If the information you want from records with duplicate alternates keys is NOT
the same in all such records, then the question arises as to HOW "you" know
which is the correct record. With an '02 conforming compiler or with many (not
all) '85 Standard compilers - as an extension - you can use a "split key". If
some combination of keys is guaranteed to get you the correct record, then that
is why you should do (if split keys are available).

Option 3:
If records with duplicate alternate keys do not all contain the desired
information and the way to tell which record you want is NOT also a key, then
you should:
A) do a READ ... KEY IS statement for the alternate key in question. This is
GUARANTEED (in a standard conforming implementation) to get the "first" record
with such a match. If will (as mentioned elsewhere) give you a status code
indicating that there ARE other records with that key.
B) You should then do READ NEXTs against the file to obtain (in order) all the
remaining records with that same alternate key. You will then need to "look
for" the data that tells your program that you have retried the correct record.

Option 4:
If you have no way to determine which of multiple records with the same
alternate record key actually contains the data that you are looking for, then
you need to either redefine your specification or your file. Results are
unpredictable and highly likely to yield bad data.

--
Bill Klein
wmklein <at> ix.netcom.com

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:9XdMk.631402$J72.474438@fe05.news.easynews.com...
> <previous thread contents snipped>
>
> In the case of alternate keys with duplicates, then what do you do?
>
> Option 1:
> If you know your records and when you do and don't have duplicates, it is
> POSSIBLE that the information you want from records with alternate
> duplicate keys is always the same in all such records. In such cases,
> then you can get it from whichever record you have retried from the first
> READ ... KEYS IS statement.
>
> Option 2:
> If the information you want from records with duplicate alternates keys
> is NOT the same in all such records, then the question arises as to HOW
> "you" know which is the correct record. With an '02 conforming compiler
> or with many (not all) '85 Standard compilers - as an extension - you can
> use a "split key". If some combination of keys is guaranteed to get you
> the correct record, then that is why you should do (if split keys are
> available).
>
> Option 3:
> If records with duplicate alternate keys do not all contain the desired
> information and the way to tell which record you want is NOT also a key,
> then you should:
> A) do a READ ... KEY IS statement for the alternate key in question. This
> is GUARANTEED (in a standard conforming implementation) to get the "first"
> record with such a match. If will (as mentioned elsewhere) give you a
> status code indicating that there ARE other records with that key.
> B) You should then do READ NEXTs against the file to obtain (in order) all
> the remaining records with that same alternate key. You will then need to
> "look for" the data that tells your program that you have retried the
> correct record.
>
> Option 4:
> If you have no way to determine which of multiple records with the same
> alternate record key actually contains the data that you are looking for,
> then you need to either redefine your specification or your file. Results
> are unpredictable and highly likely to yield bad data.
>

Yes, I think that just about covers it.

For me, the simple principles are:

1. Use a direct read if you possibly can and there is not likely to be
further searching.
2. Use START...READ NEXT in all other cases.

(This applies to both primary and alternate keys of reference.)

I take your point that using a direct read in place of START will guarantee
the first record in the duplicate set where START MAY not. (I've never had a
case where it didn't. but I bow to your knowledge of the standards.)

The reason I said the conversation is surreal is because it is like being in
the 1960s... I would never do ANY of this in this day and age...:-)
(Assuming one had a choice of course...)

Pete.
--
"I used to write COBOL...now I can do anything."

In article <6mcdk1Fg2idfU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:gdq6ob$7hf$1@reader1.panix.com...
>> In article <6mbcpoFftgouU1@mid.individual.net>,
>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>>
>>>
>>><docdwarf@panix.com> wrote in message
>>>news:gdpp1f$dv4$1@reader1.panix.com...
>>>> In article <6mav50Fftd0jU1@mid.individual.net>,
>>>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>>>>
>>>>>
>>>>>"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
>>>>>news:cJSLk.124904$KY3.40003@fe02.news.easynews.com...
>>>>>> If your ACCESS Is SEQUENTIAL, then you need to use the START (with the
>>>>>> KEY
>>>>>> IS phrase) and then a bunch of READ NEXT statements.
>>>>>>
>>>>>> If your ACCESS IS DYNAMIC or RANDOM, then you should just use the READ
>>>>>> statement and use the KEY IS phrase (as mentioned below).
>>>>>
>>>>>And what if the Alternate has duplicates? :-)
>>>>
>>>> I believe that one is notified of this by the value of the field
>>>> specified
>>>> in FILE STATUS clause, Mr Dashwood... did you know that?
>>>
>>>Yes, Mr Dwarf I was well aware of that. :-)
>>
>> Then why bother to ask?
>
>Because that had a bearing on finding the actual record required. I wasn't
>asking about how one detects if there are duplicate keys, or if a record
>which ios part of a duplicate set has been returned.

Mr Dashwood, you asked 'what if the Alternate has duplicates?' and you
received a succinct, precise and accurate answer. That it did not meet
your expectations might speak more about your expectations and ability to
express them than about the question and the answer... look to Self,
first, and all that.

>
>You simply misinterpreted my question.

It is considered, in some circles, impolite to point, Mr Dashwood. Your
question was answered succinctly, precisely and accurately... 'Yew want
more?'.

>
>READ ... KEY IS returns a record.

This is correct under only certain conditions, Mr Dashwood; to say 'This
lock requires a key' is not the same as 'this lock requires *this* key',
as those who have encountered a FILE STATUS of 23 might have noticed.

>The point is that it may not be the required record. Hence my question.

'The point' might be seen differently from different sides, Mr Dashwood...
hence the value of precision in asking. If a question can return a
response which is both precise and accurate and yet be 'wrong'... what
needs to be modified, the method of asking or the method of answering?

>>
>>>Unfortunately, the contents of this field are updated AFTER access has
>>>occurred so it doesn't help in any way to ensure that I get the specific
>>>record (out of all the duplicates) that I actually want.
>>
>> Mr Dashwood, you did not ask anything about getting any particular record,
>> you asked about 'what if the Alternate has duplicates?'. If your question
>> had concerned data, and how to get to them, you might have thought to ask
>> about those.
>
>I did. You simply didn't make the connection.

It is considered, in some circles, impolite to point, Mr Dashwood; your
question received a succinct, precise and accurate answer.

>The clue was in READ... KEY
>IS.

This is most mysterious, Mr Dashwood, and in matters of data processing
mystery can lead to... curious places. Does a clue exist where it is left
or where it is found?

>>
>> (for those who aren't familiar with it... there is an Olde Joke about a
>> fellow in a balloon asking something of someone on the ground; the oldest
>> version I can find uses an 'Information Technology Worker' as the grounded
>> one but the version I was taught had him as a Programmer. See
>>
><http://groups.google.com/group/alt.legend.atlantis/msg/b7ea3e01773a5ba1?dmode=source>)
>>
>
>Unfortunately showing its age now... (like many of us...)

Getting older usually beats the alternative, Mr Dashwood... as the Olde
Saying has it, 'Everyone wants to go to Heaven but nobody wants to die'.

DD

In article <9XdMk.631402$J72.474438@fe05.news.easynews.com>,
William M. Klein <wmklein@nospam.netcom.com> wrote:
><previous thread contents snipped>
>
>In the case of alternate keys with duplicates, then what do you do?
>
>Option 1:

[snip]

>Option 4:

Well put, Mr Klein... in short, 'know your data and find out what your
user wants'. As a classic example:

Marketing wants two lists of email addresses for their campaign, one a
list of customers who have placed an order for (product) in the past year
and another of email addresses of customers who have NOT placed an order
of any kind in the past year.

The Customer Master File is a VSAM KSDS which has a Primary Key of CUST-ID
and contains the email address; the Order File (another KSDS) has an
Alternate Key of CUST-ID + PROD-NO + TIMESTAMP, where TIMESTAMP =
(9999999999999999 - CCYYMMDDHHMNSSHN) (so that the most recent orders
'float to the top').

DD

In article <6mdf3jFg8j7lU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>The reason I said the conversation is surreal is because it is like being in
>the 1960s... I would never do ANY of this in this day and age...:-)
>(Assuming one had a choice of course...)

If everyone did as you did, Mr Dashwood, then your skills would be just
plain and ordinary... that everyone doesn't encourages striving for
excellence (or the ever-popular 'Oooooohhhhh... *don't* tell *me* that
'you can't do that'!')

Children whootle and tootle and chime on bells and whistles and the sound
disappears with the wind... Haydn (or maybe Leopold Mozart) writes the Toy
Symphony and it endures and gives delight for centuries.

DD

<docdwarf@panix.com> wrote in message news:gdsgop$i7h$2@reader1.panix.com...
> In article <6mdf3jFg8j7lU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>>The reason I said the conversation is surreal is because it is like being
>>in
>>the 1960s... I would never do ANY of this in this day and age...:-)
>>(Assuming one had a choice of course...)
>
> If everyone did as you did, Mr Dashwood, then your skills would be just
> plain and ordinary...

Yes, I consider them so. I don't have any skill that anyone else could not
(fairly easily) acquire.

> that everyone doesn't encourages striving for
> excellence (or the ever-popular 'Oooooohhhhh... *don't* tell *me* that
> 'you can't do that'!')

Not sure about that. I strive for excellence irrespective of what other
people do. I shouldn't think others strive for excellence in an effort to
keep up with me... :-)

My observation was not intended to be judgemental or offensive. I know there
are people who have little choice in these matters (I said as much...). It
is a simple matter of perspective. I actually HAD conversations about this
in the 60s and to find them being repeated now is just... well...surreal.
Dame Edna would say "spooky..."
>
> Children whootle and tootle and chime on bells and whistles and the sound
> disappears with the wind... Haydn (or maybe Leopold Mozart) writes the Toy
> Symphony and it endures and gives delight for centuries.

Angerer gets my vote on that. He'd be really annoyed if he didn't... :-)

Pete.
--
"I used to write COBOL...now I can do anything."