- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Some weird behaviour accessing RMS file
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
тАО10-20-2004 08:22 PM
тАО10-20-2004 08:22 PM
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
OpenVMS Developer & System Manager
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 08:42 PM
тАО10-20-2004 08:42 PM
Solutionhttp://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.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 09:18 PM
тАО10-20-2004 09:18 PM
Re: Some weird behaviour accessing RMS file
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 09:34 PM
тАО10-20-2004 09:34 PM
Re: Some weird behaviour accessing RMS file
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 09:56 PM
тАО10-20-2004 09:56 PM
Re: Some weird behaviour accessing RMS file
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 10:49 PM
тАО10-20-2004 10:49 PM
Re: Some weird behaviour accessing RMS file
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?
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 11:14 PM
тАО10-20-2004 11:14 PM
Re: Some weird behaviour accessing RMS file
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 11:24 PM
тАО10-20-2004 11:24 PM
Re: Some weird behaviour accessing RMS file
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
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 11:37 PM
тАО10-20-2004 11:37 PM
Re: Some weird behaviour accessing RMS file
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-20-2004 11:41 PM
тАО10-20-2004 11:41 PM
Re: Some weird behaviour accessing RMS file
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.