Some weird behaviour accessing RMS file

[Willem Grooters]

Given the file and processing in the attached file, I find a weird behaviour I fail to understand.
When running the sequence as shown, for some keys I find morer than one record, even where SEARCH reveals there is only one. It doesn't matter what environment is used. It will happen in DCL or in our (Dibol) development environment.
ANALYZE/RMS doesn't reveal any error.
This behaviour is gone after CONVERT, but all of a sudden, it does reappear, but it can not be predeteremined what keys will be involved, or how many. Again, CONVERT solves the problem.
My impression is that something is messed up in the secondary index but I couldn't find out what.

Who can explain what's going on and how to prevent this?

Willem

[Ian Miller. · Accepted solution]

it may be worth looking at the file with Hein's rms tools from
http://h71000.www7.hp.com/freeware/freeware60/rms_tools/

may tell you something.

Sometimes ANAL/RMS/INTERACTIVE and wandering around the file structure may help you understand the problem. I've found it helpful on occation.

[Bojan Nemec]

Willem,

Looking at yours FDL I see that the definition of the secondary index is not properly defined. If RMS is working ok this will not be an issue but you newer knows.

Key 0 is a subset of key 1. For key 0 you have: CHANGES no and DUPLICATES no. For key 1: CHANGES yes and DUPLICATES yes which is not possible.

I dont know if this is a reason for yours problems, but if it is, this is an RMS bug.

Bojan

[Jan van den Ende]

Willem,

Reading Bojan, (and knowing what "PLOT" is :-) ), I conclude that you have a fixed series of plots, which are eigther in status "V", or not; and you want to display the plots in status "V", excluding all other statusses. Correct?
I think I will have to agree with Bojan, key1 should be NOduplicates (but changes YES of course).
Btw, kind of strange way to define the alternate key as a primary with one variable character IN FRONT. Histeric/historic reasons probably?

Cheers.

Have one on me.

jpe

[Bojan Nemec]

Jan,

You are right. I missed the possibility to change only the first character. For such implementations (when you have 2 states and need to read fast only records with one state) you can use null keys. This reduce some testing when reading the file.

Bojan

[Willem Grooters]

Thanks to Hein's marvelous program some light at least - see first part of attachement.
All the records that have > 1 in the "dups" column (?) give problems. Given the known output from the program, I guess if there is more than 1 'duplicate', but less than 48, a second 'valid' record will show op, and a third if 48 or higher. This is consistent with the output.

Give this knowledge, I tried to find the cause using ANA/RMS/INTER once again. The thing I found, on V1200 for instance, were three references to this data with a valid pointer (one where "deleted" flag set, and two without any flag set). See second part of attachement.

I'm still waiting for info on the running environment where this happened, but does anyone has some idea how this could happen?

[Willem Grooters]

STUPID system. Had to retry (Server unvailable, filter too slow) and so attachement is missing. Sorry for that.

Bojan, Jan,
Right. It's a kind of plotting: state-based. hence, there is some logic in the way keys were set up.
The primary key names a unit. All units are known, no data is added to the file by THIS program. We use it to extract particular data on that unit that is not related to it's state.
The secondary key is used to extract unit data based on it's state. To get all units in a certain state, this argument is of higher significance that the unit number - and therefore it is set in front of the number.
If the state changes, this key will change and be written back. That may well introduce the problem here, since references are deleted and added.

[Willem Grooters]

Additional info:
This particular program can be used simultaniously by about 8 people, spread over three nodes in a cluster, but working on the same files.
Is it imaginable that this could lead to some issues in synchronization for this particular file (lots of updates)?

Willem

[Jan van den Ende]

Willem,

multi-user access from multiple nodes _MAY_ influence the performance (forced to wait), but should _NOT_ influence the integity of the data!!

Cheers

Have one on me

jpe

[faris_3]

Hi,

Do you use some special options
like read regardless of lock ?

Otherwise this seems like a bug.
You should open a call with your local
CSC if all rating 1 patches are applied.