topic Re: fatal RMS condition in Operating System - OpenVMS

fatal RMS condition

mustafa_12 — Thu, 16 Nov 2006 06:16:49 GMT

Hello,

In my operator.log, I have a lot of lines containing the phrase in the subject. That is:

%RMS-F-BUG, fatal RMS condition (FFFFFFE5), process deleted

What is that? What is going on the system? If there is a serious condition, how can I fix it?

Regards...

Re: fatal RMS condition

Robert Gezelter — Thu, 16 Nov 2006 06:36:26 GMT

mustafa,

First, I would want to verify that they are actual values from RMS, and not just a program that happens to return a -27 in the return code register (R0 on VAX/ALPHA). It would be helpful if you included the log output. Also, I would recommend checking the accounting log to ensure that a process was deleted at this time.

If the problem is real (no program is exiting with a completion status of -27, and the actual process deletion corresponds to a problem with RMS), then you should:

- isolate the failure so that you can reproduce it at will
- minimize what is needed to reproduce the problem.
- then open a support call with HP

- Bob Gezelter, http://www.rlgsc.com

Re: fatal RMS condition

Hein van den Heuvel — Thu, 16 Nov 2006 08:50:13 GMT

Mustafa,

That's an RMS bugcheck and normally you have no direct control over it. It is not a bad setup, or bad tuning. More like bad luck.

What OpenVMS version? What Platform? All the most recent patches applied?

You may be able to influence it, for example by converting (indexed) files.

The actually code is -27 = FTL$_NOLCLBUF = "Should have found a local buffer."

You might try more local buffer, but that woudl only indirectly adderss the issue.
RMS _should_ have enough buffers always, thus it became a fatal message when it thought there were not enough.
SET RMS/BUF/IND=20 ?

What changed recently
Is it always the same program?
Always the same file(s)?

>> First, I would want to verify that they are actual values from RMS, and not just a program that happens to return a -27 in the return code register (R0 on VAX/ALPHA).

If it is in Operator.log, then it is for real.
Also, the FFFFFFE5 is a sub-code, not the R0 code.

>> I would recommend checking the accounting log to ensure that a process was deleted at this time.

Right it should correspond with a process end.

More importantly, there should be an errorlog entry with details (other registers).

>>> - isolate the failure so that you can reproduce it at will

If you can, then you may want to wait for a quiet time, change BUGCHECKFATAL to 1 with SYSGEN adn reproduce. Now a full crashdump will be caused.

- minimize what is needed to reproduce the problem.

Great advice.. but not easy.

- then open a support call with HP

After verifying you are reasonably up to date.

Regards,
Hein van den Heuvel
HvdH Performance Consulting.

Re: fatal RMS condition

John Abbott_2 — Thu, 16 Nov 2006 08:50:35 GMT

mustafa,

translate/analyze/diagnose your errorlog file, you should get lots of info including the pid + prcnam which might help isolate the problem and enable you to reproduce it.

Regards
John.

Re: fatal RMS condition

Hein van den Heuvel — Thu, 16 Nov 2006 09:25:48 GMT

I checked my notes, and the last time I see an RMS NOLCLBUF problem was in 1990 (before I joined RMS engineering :-), but that was OpenVMS 5.5-ish on VAX.

On the end user side, also check out lock stuff like ENQLM settings and usage.
RMS sometimes looks for a free(able) local buffer, not for the buffer itself, but to use the lock associated with the buffer.

Hein.