RMS-F-BUG error

[Mitchell Glassman]

I recently upgraded a customers system from 7.1 to 7.3-1. An application that used to run fine now runs for a while (several days), but then exits with the following message in its log file "%RMS-F-BUG, fatal RMS condition (FFFFFFC0), process deleted". After this happens, the program cannot run successfully again until the Alpha is rebooted.

Anyone know how to find out what this error means. I've looked all through the support web pages but cannot find anything about it. In the past there were some similar bugs for which there are patches available, but not with this newer version.

My next step will be to submit a problem report to HP, but I thought I'd try here first.

Thanks for any help or ideas.

[Martin P.J. Zinser · Accepted solution]

Hello,

as for 7.3-1 and RMS first thing is to check if you are up on patches (UPD1 and RMS4 come to mind immediatly). Else it is known that timing changes in 7.3-1 exposed latent bugs in a number of applications. You actually might need to check your application. As for "a reboot" cures it, that might point into the direction of a cache issue. Can you pinpoint a particular file causing the trouble?

Greetings, Martin

[John Gillings]

Mitchell,

RMS-F-BUG is a non fatal bugcheck. There should be an error log entry that may give more information, or you could set the SYSGEN parameter BUGCHECKFATAL to force the system to crash when the condition is encountered. This is really the only way to get deeper diagnosis.

BUGCHECKFATAL is dynamic, so:

$ MCR SYSGEN
SYSGEN> USE ACTIVE
SYSGEN> SET BUGCHECKFATAL 1
SYSGEN> WRITE ACTIVE
SYSGEN> EXIT

Now repeat the action that generates the bugcheck. *YOUR* *SYSTEM* *WILL* *CRASH* so make sure you don't do it while anything important is happening. Also make sure you have a valid dump file.

As Martin has suggested, the latest UPDATE and RMS patches would be a good first step, but there are none that match this particular footprint.

That said, Condition code FFFFFFC0 decodes to "FTL$_BADGBH, Bad Global Section Header" The value in R0 will give more information.

If you're aware of any specific global sections that your application uses, they might be a place to start looking, but, by definition, this isn't a common or garden coding bug. There would need to be some privileged code hacking around in exec structures.

[Antoniov.]

Hi Mitchell,
Martin & John say the right way to solve; also when you upgrade OS you shoul tune system parameter (with @AUTOGEN); some values, sometimes need change.

Bye
Antoniov

[Martin P.J. Zinser]

I think Johns clue is very good. If you have a problem with a global section in memory this explains why a reboot makes the problem go away
(which it rather would not if you had a corrupted file on disk). If you can identify the section involved you might be able to delete it and get your application running without the reboot.

[Jeffrey Goodwin]

We received this error on long running applications after upgrading to V7.3-1. We received a new RMS image to correct it. I suspect that the fix has been implemented in VMS731_RMS-V0400. It is not in VMS731_RMS-V0200.

-Jeff

[Mitchell Glassman]

I just wanted to say thanks very much to everyone who tried to help with this problem. I did apply the two patches suggested, the vms update and the RMS patch, and after running the same programs again for some time, they have not crashed again. Problem solved!

Thank again!

[Mike Naime]

Did you re-link your applications (executables) against the new version of VMS?

When we do VMS upgrades, our DBA's re-link Oracle as an SOP.

[Hein van den Heuvel]

John> If you're aware of any specific global sections that your application uses, they might be a place to start looking, but, by definition, this isn't a common or garden coding bug.


Don't just think 'global sections', think: Files with RMS Global buffers enabled.
There was a problem. To solve it, apply the RMS patch kit. As a workaround, you could diable RMS global buffers for the file active at the time of the crash. Best I recall from lunchtime conversation this proabbly also involved STOP/ID to trigger.


Antoniov> also when you upgrade OS you shoul tune system parameter (with @AUTOGEN); some values, sometimes need change.

That migth be useful. But it will NOT solve a system/process crash as reported here. VMS, and its core components, do NOT crash if it is mis-tuned. It will fail gracefully (or at least as graceful as the circumstnaces allow) this IMHO makes VMS the superior OS it is.

Mike Naime> Did you re-link your applications (executables) against the new version of VMS? When we do VMS upgrades, our DBA's re-link Oracle as an SOP.

It's more productive to play a game of solitaire, and less risky to your production environment. This makes NO SENSE. Only when upgrading from VMS 3.7 to 4.0 (give or take a version) did they a relink ever make any difference. This is VMS after all.
Actaully, I don';t really recall tehe exact versiona nd circumstances. It's a more than a decade ago, and it involved a minor performance enhancements, getting a direct versus indirect lingage or some such. Again, your system / process would not crash. And I' sure it was well documented at the time.

Folks blindly relinking are ill informed.

Good luck you all.
Hein.