- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: RMS-E-RSA, record stream currently active
Operating System - OpenVMS
1745797
Members
3547
Online
108722
Solutions
Forums
Categories
Company
Local Language
юдл
back
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
юдл
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- 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
тАО06-30-2010 11:18 PM
тАО06-30-2010 11:18 PM
Re: RMS-E-RSA, record stream currently active
John,
I have changed my program. Since 28.06.2010 the open/close is removed (see attachment). The same error occurred at 30.06.2010
30-JUN-2010 08:30:17.87 warte auf Trigger
%PAS-F-ERRDURWRI, error during WRITELN
File "OUTPUT" Filename "SYS$OUTPUT:.;"
-RMS-E-RSA, record stream currently active
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PAS$RTL 0 00000000000301A0 FFFFFFFF855001A0
PAS$RTL 0 000000000005E161 FFFFFFFF8552E161
PAS$RTL 0 0000000000046FA1 FFFFFFFF85516FA1
PAS$RTL 0 0000000000046D30 FFFFFFFF85516D30
BSTR BSTR BSTR 590 0000000000002AD2 0000000000032AD2
BSTR 0 00000000000345B2 00000000000345B2
BSTR 0 00000000000352E2 00000000000352E2
PTHREAD$RTL THD_THREAD thdBase 244744 0000000000005BE2 FFFFFFFF84543282
PTHREAD$RTL THD_INIT pthread_main 244538 00000000000006B2 FFFFFFFF844FA6B2
0 FFFFFFFF80BA8192 FFFFFFFF80BA8192
DCL 0 000000000006BAF2 000000007AE27AF2
%TRACE-I-END, end of TRACE stack dump
Any suggestion?
I have changed my program. Since 28.06.2010 the open/close is removed (see attachment). The same error occurred at 30.06.2010
30-JUN-2010 08:30:17.87 warte auf Trigger
%PAS-F-ERRDURWRI, error during WRITELN
File "OUTPUT" Filename "SYS$OUTPUT:.;"
-RMS-E-RSA, record stream currently active
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PAS$RTL 0 00000000000301A0 FFFFFFFF855001A0
PAS$RTL 0 000000000005E161 FFFFFFFF8552E161
PAS$RTL 0 0000000000046FA1 FFFFFFFF85516FA1
PAS$RTL 0 0000000000046D30 FFFFFFFF85516D30
BSTR BSTR BSTR 590 0000000000002AD2 0000000000032AD2
BSTR 0 00000000000345B2 00000000000345B2
BSTR 0 00000000000352E2 00000000000352E2
PTHREAD$RTL THD_THREAD thdBase 244744 0000000000005BE2 FFFFFFFF84543282
PTHREAD$RTL THD_INIT pthread_main 244538 00000000000006B2 FFFFFFFF844FA6B2
0 FFFFFFFF80BA8192 FFFFFFFF80BA8192
DCL 0 000000000006BAF2 000000007AE27AF2
%TRACE-I-END, end of TRACE stack dump
Any suggestion?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2010 02:08 PM
тАО07-01-2010 02:08 PM
Re: RMS-E-RSA, record stream currently active
Klaus,
As I suggested earlier:
>Enable a process dump, or run the program
>under DEBUG. When you get an error, walk
>back through the call stack and see how it
>got there. I still suspect some form of
>recursion, perhaps involving an external
>routine.
Add /DUMP to your RUN/DETACHED command.
What does "baur$bewbckclose" do?
Looking at the code, it appears the error can only have resulted from the WriteLn of "BSTR Shutdown" at the end of the program.
I wonder if the exit handler has anything to do with it? I can't see how it would result in the error you have, but your exit handler looks a bit odd. What is lvs_stckdmp? If exitstatus is already the same as lvs_stckdmp, then it will be returned as R0, and effectively signalled anyway. I'd also prefer to see the exit status examined as the parameter to the exit handler, rather than an uplevel reference.
Simple stylistic issue, since you're always adding date and time stamps to the output, rather than repeat the same code in numerous places, I'd pull out the WriteLn calls into a routine, say "LogMsg":
PROCEDURE LogMsg(str:VARYING OF CHAR);
VAR dstr, tstr : PACKED ARRAY [1..11] OF CHAR;
BEGIN
DATE(dstr); TIME(tstr);
WriteLn(dstr,' ',tstr,str);
END;
PROCEDURE DbgMsg(str:VARYING OF CHAR);
BEGIN
IF dbgFlag
THEN
LogMsg(str)
END;
END;
Then call it like:
if sc.sc$w_phase<>sc$c_internphase then
begin
DbgMsg(' warte auf Trigger');
end;
end; {not(lvs$ifbrk)}
{schlie├Г e backup datei}
baur$bewbckclose;
LogMsg(' BSTR shutdown');
Places where you want to include decimal values are easily dealt with using concatenation and the formatting routines, like DEC:
DbgMsg(' keine Arbeit in SP='+DEC(sc.sc$w_phase));
By decluttering the program you may find it easier to spot inconsistencies. You also make it much easier to do stuff like closing and reopening the file, if that's what you really need to do, since it's all in one place. Consistency in things like message formats is enforced.
The other trick you can do by abstracting the log message function is easily switch to a different output file. Perhaps the issue is something corrupting the internal Pascal structure for OUTPUT?
As I suggested earlier:
>Enable a process dump, or run the program
>under DEBUG. When you get an error, walk
>back through the call stack and see how it
>got there. I still suspect some form of
>recursion, perhaps involving an external
>routine.
Add /DUMP to your RUN/DETACHED command.
What does "baur$bewbckclose" do?
Looking at the code, it appears the error can only have resulted from the WriteLn of "BSTR Shutdown" at the end of the program.
I wonder if the exit handler has anything to do with it? I can't see how it would result in the error you have, but your exit handler looks a bit odd. What is lvs_stckdmp? If exitstatus is already the same as lvs_stckdmp, then it will be returned as R0, and effectively signalled anyway. I'd also prefer to see the exit status examined as the parameter to the exit handler, rather than an uplevel reference.
Simple stylistic issue, since you're always adding date and time stamps to the output, rather than repeat the same code in numerous places, I'd pull out the WriteLn calls into a routine, say "LogMsg":
PROCEDURE LogMsg(str:VARYING OF CHAR);
VAR dstr, tstr : PACKED ARRAY [1..11] OF CHAR;
BEGIN
DATE(dstr); TIME(tstr);
WriteLn(dstr,' ',tstr,str);
END;
PROCEDURE DbgMsg(str:VARYING OF CHAR);
BEGIN
IF dbgFlag
THEN
LogMsg(str)
END;
END;
Then call it like:
if sc.sc$w_phase<>sc$c_internphase then
begin
DbgMsg(' warte auf Trigger');
end;
end; {not(lvs$ifbrk)}
{schlie├Г e backup datei}
baur$bewbckclose;
LogMsg(' BSTR shutdown');
Places where you want to include decimal values are easily dealt with using concatenation and the formatting routines, like DEC:
DbgMsg(' keine Arbeit in SP='+DEC(sc.sc$w_phase));
By decluttering the program you may find it easier to spot inconsistencies. You also make it much easier to do stuff like closing and reopening the file, if that's what you really need to do, since it's all in one place. Consistency in things like message formats is enforced.
The other trick you can do by abstracting the log message function is easily switch to a different output file. Perhaps the issue is something corrupting the internal Pascal structure for OUTPUT?
A crucible of informative mistakes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-01-2010 11:46 PM
тАО07-01-2010 11:46 PM
Re: RMS-E-RSA, record stream currently active
John,
thank you very much for your suggestions. I have change my program accordingly.
I have also added the /dump qualifier. I need some help to analyse the dump file. Please, can you give me some hints.
The last crash is in line 590 of bstr. This line contains the statement writeln(...,'trigger empfangen'). The problem occured during normal work of the server process bstr. Nobody has stopped the server process bstr. In my opinion the problem will not be found in the exit handler.
The Rtn. baur$bewbckclose will close a backup file of the server process bstr.
The Rtn. bstr_shutdown is the exit handler of the server process bstr. With sys$forcex() and status equal lvs__stckdmp it is possible to trigger the server process bstr. When this trigger is received the process will lib$signal(lvs__stckdmp) and I got a traceback info before bstr will stop.
thank you very much for your suggestions. I have change my program accordingly.
I have also added the /dump qualifier. I need some help to analyse the dump file. Please, can you give me some hints.
The last crash is in line 590 of bstr. This line contains the statement writeln(...,'trigger empfangen'). The problem occured during normal work of the server process bstr. Nobody has stopped the server process bstr. In my opinion the problem will not be found in the exit handler.
The Rtn. baur$bewbckclose will close a backup file of the server process bstr.
The Rtn. bstr_shutdown is the exit handler of the server process bstr. With sys$forcex() and status equal lvs__stckdmp it is possible to trigger the server process bstr. When this trigger is received the process will lib$signal(lvs__stckdmp) and I got a traceback info before bstr will stop.
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP