HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

RMS-F-BUG error

 
SOLVED
Go to solution
Mitchell Glassman
Occasional Visitor

RMS-F-BUG error

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.
8 REPLIES
Martin P.J. Zinser
Honored Contributor
Solution

Re: RMS-F-BUG error

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
Honored Contributor

Re: RMS-F-BUG error

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.
A crucible of informative mistakes
Antoniov.
Honored Contributor

Re: RMS-F-BUG error

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
Antonio Maria Vigliotti
Martin P.J. Zinser
Honored Contributor

Re: RMS-F-BUG error

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
Frequent Advisor

Re: RMS-F-BUG error

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
Occasional Visitor

Re: RMS-F-BUG error

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
Honored Contributor

Re: RMS-F-BUG error

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.
VMS SAN mechanic
Hein van den Heuvel
Honored Contributor

Re: RMS-F-BUG error



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.