Problem with an index file on VMS

[Christopher Blackburn]

Hi,
Has anyone experienced any problems with RMS index files on OpenVMS 8.1,8.3 ?
I have an index file with two indices, the first is an alphabetic key of 12 characters and the second is an alphabetic key of 9 characters.
The index file is created with an FDL file and works fine for some time but at some point the second index gets out of sync with the first. Thus if one access the file using the first index a number of records are returned and when the second index is used a different number of records is returned.
I can't tell what operation causes the index to get corrupted i.e. Insert record, Update record or Delete record. Using ANALYSE/RMS uncovers no errors in the structure of the index file but does show the difference in the two indices.

Many thanks in advance for any suggestions.

Chris.

[Wim Van den Wyngaert]

Just a guess : key values that are NULL are not returned when you read. Did you specify a null field option in the FDL ? Posting the fdl would be nice.

Wim

[Christopher Blackburn]

I have attached the FLD used to create the file. I will try to investigate if a NULL key value has caused the problem.

[Wim Van den Wyngaert]

You don't seem to have null keys. But is this the fdl that was used to create the file ? anal/rms/fdl would be more sure.

How did you read the file ?

Wim

[Hoff]

"...but does show the difference in the two indices...": Can you post up that report?

Ok; this looks to be an old application, and one that's been ported forward to OpenVMS Alpha or OpenVMS I64?

The only 8.1 around was on OpenVMS I64 during its pre-production. I'll assume this application is not running OpenVMS I64 V8.1, as there were a number of problems with that release. It was most definitely not "production quality" code.

I'll assume current ECOs for whatever version of OpenVMS this is. If not, do get there.

Is there the possibility there is a partitioned cluster operating? Anybody been "getting creative" with VOTES and/or EXPECTED_VOTES? That'll stomp on files.

Are there any disk errors being logged? That's less likely, given the re-occurrences, but flaky hardware can haunt a configuration.

How is the file being created and operated? fdl$create? CREATE/FDL? What application? Local? Has the application been reviewed for coding errors? (That written, having different record counts on two keys should not normally happen, even with a coding bug.)

I would definitely review the code used to perform the key-related processing. If something in the code or in RMS is stomping on a key, some other code might not find what it expects and mis-report. (But I'd not expect that to arise from your reported ANALYZE/RMS pass.)

My first step would be to periodically scan the two keys using external standalone software. Key scans are simple hunks of code, and you can quickly catch and flag these errors. If you do have two different record counts (and no NULL KEY setting), that points toward a nasty problem in RMS.

The posted (old?) FDL makes the file look pretty simple; there's no real oddness apparent in the FDL. And no NULL KEY there.

Hein's rms_tune_check tool from the Freeware (directory rms_tools) would be a good option, too.

And yes, ANALYZE/RMS/FDL or such, and post the FDL.

With straight text keys, you can use a couple of DCL loops to read off the keys, or a smattering of C or other language code. (Examples of both can be found on the Freeware, and in the Ask James support database, and elsewhere.)

Stephen Hoffman
HoffmanLabs LLC

[Christopher Blackburn]

Wim,

I have used ANALYSE/RMS/FDL on the file and attached the results. The original FDL file was used to create the file. On our operational system we tidy the file up every six moths by reading the records from the index file sequentially and re-writing them to a new index file created with the FDL.
Reading from the file is performed using FORTRAN READ statements with the KEYID and KEYGE arguments. Subsequent reads are performed by using a simple READ statement.

Many thanks for your time.

[Wim Van den Wyngaert]

Probably garbage in the index and your Fortran is reading good stuff only.

Here's a test.com. Execute is with p1= your file and p2=0. Then again with p2=1.

$ open/read/share x 'p1'
$ i=0
$r:
$ read/end=e/index='p2' x x_rec
$ i=i+1
$ goto r
$e:
$ write sys$output "Via index 'p2' : ''i' records"
$ close x


Wim

[Christopher Blackburn]

Hoff,

Software can be used in a cluster but has failed on a single node. The index file is only used by a single process on a single node. The index file is created from DCL with a CREATE/FDL statement but from then on it is written to and read from VMS software written in FORTRAN. You are correct the code is old and has been working on previous versions of VMS without problems. I have user ANALYZE/RMS/CHECK to check consistency of file and it looks OK.

[Christopher Blackburn]

Wim,
When I run the DCL command file on the file it returns the same number of records for index 0 and index 1. I know when I step through the code in DEBUG it reads 6 keys from key0 and 0 keys from key1.
It must be the way we are reading the key values from the file. The primary index is read from FORTRAN using a READ statement with KEYID=0 and KEYGE=' ' and the secondary index is a READ statement with KEYID=1 and KEYGE=ICHAR(0).

Many thanks for your time - Chris.

[Hein van den Heuvel]

Chris,

Focus on the code. Trust RMS in this.

The code being used is broken.
100% sure, garantueed, no ifs or buts.

The used code is not correct. it probaly never was but you had the bad luck that the problem went unnoticed.

Potential problem areas....

1) The code fails to deal with duplicates correctly. There is a large number of duplicates when reading according to key #1.

2) The alternate key, while declared as string actually contains binary data and the the resulting sort order only now comes to bite the application in the rear.

If need be, reduce the code to a bare minimum and post as a text attachment.

Good luck!
Hein van den Heuvel ( at gmail dot com )