- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Problem with an index file on VMS
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2007 09:04 PM
тАО08-05-2007 09:04 PM
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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2007 09:50 PM
тАО08-05-2007 09:50 PM
Re: Problem with an index file on VMS
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2007 11:24 PM
тАО08-05-2007 11:24 PM
Re: Problem with an index file on VMS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-05-2007 11:41 PM
тАО08-05-2007 11:41 PM
Re: Problem with an index file on VMS
How did you read the file ?
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2007 12:27 AM
тАО08-06-2007 12:27 AM
Re: Problem with an index file on VMS
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2007 12:29 AM
тАО08-06-2007 12:29 AM
Re: Problem with an index file on VMS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2007 12:36 AM
тАО08-06-2007 12:36 AM
Re: Problem with an index file on VMS
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2007 12:39 AM
тАО08-06-2007 12:39 AM
Re: Problem with an index file on VMS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2007 12:57 AM
тАО08-06-2007 12:57 AM
Re: Problem with an index file on VMS
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2007 01:51 AM
тАО08-06-2007 01:51 AM
Re: Problem with an index file on VMS
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 )