[Info-vax] Indexed file read question

[Jan-Erik Söderholm]

Den 2020-11-18 kl. 18:40, skrev Dave Froble:
> On 11/18/2020 11:35 AM, abrsvc wrote:
>> On Wednesday, 18 November 2020 at 11:20:54 UTC-5, Stephen Hoffman wrote:
>>> On 2020-11-18 15:23:13 +0000, abrsvc said:
>>>
>>>> Situation: Indexed file with 2 keys, the first key no duplicates,
>>>> second key no duplicates. For clarity, the first key is a record
>>>> number and the second key is one of 4 values: A,B,L or blank.
>>> With only four records possible, why is this even a file? Which
>>> implies there *are* duplicates on the secondary?
>>>
>>>
>>> -- 
>>> Pure Personal Opinion | HoffmanLabs LLC
>>
>> I have over simplified the situation just to provide a context for the 
>> question.  This is just one of many questionable practices wihtin this 
>> code system.
>> More time is spent opening and closing files with singular records than 
>> anything else.  I am not in a position to change this, I am just trying 
>> to assist with understanding how the current system works.
>>
>> Update:  There are duplicates for the second key.
>>
> 
> Ok, then there can be but one record for each unique primary key.
> 
> Each record can have a secondary key of A, B, L, or blank.
> 
> That's it.
> 

And if you read by the first key, you will get one specific record.
If you read by the second key, you will get *any* record having
that second key value, no matter what your read before, right?

I think the root question was if RMS keeps a file position between the
two, so that the second read depends on the first, in some way. Like
"the first record after the record read in the first read", or similar.

But, I do not follow the logic fully anyway... :-)