| Title: | DECDTM-VMS |
| Notice: | DECdtm Conference. 260.* for docs & kits. Digital Confidential |
| Moderator: | MOVIES::PLAYFORD |
| Created: | Fri Aug 12 1988 |
| Last Modified: | Fri May 30 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 353 |
| Total number of notes: | 1278 |
We had a strange problem at a customers site a few days ago.
They have an application that is using 'recover unit journaling' and
there are several RMS files participating in the transaction.
Now they have always the same error when they open one of the files invoked
they get the same error messages from OPCOM.
%%%%%%%%%%% OPCOM 17-APR-1997 10:55:50.05 %%%%%%%%%%%
Message from user FIELD on AGBVR2
%RMSREC-F-OPRSERVER, error occurred during detached recovery unit recovery;
process ID (PID) 00011463
%%%%%%%%%%% OPCOM 17-APR-1997 10:55:50.06 %%%%%%%%%%%
Message from user FIELD on AGBVR2
-RMSREC-F-FILE, file DISK$USER2:[IMPCON.MTRD3]WIPS.IMP;3
%%%%%%%%%%% OPCOM 17-APR-1997 10:55:50.06 %%%%%%%%%%%
Message from user FIELD on AGBVR2
-RMSREC-F-INVDDTM, error occurred processing prepare record
%%%%%%%%%%% OPCOM 17-APR-1997 10:55:50.07 %%%%%%%%%%%
Message from user FIELD on AGBVR2
-SYSTEM-F-NOSUCHPART, specified participant not found
%%%%%%%%%%% OPCOM 17-APR-1997 10:55:50.07 %%%%%%%%%%%
Message from user FIELD on AGBVR2
-SYSTEM-W-DEVOFFLINE, device is not in configuration or not available
I couldn't find anything that could explain the DEVOFFLINE. Via LMCP I found
a active transaction for that day that was COMMITTED because the the problems
started around that time I advised them to delete the journal-file.
Record number 3 (00000003), 64 (0040) bytes
Transaction state (2): COMMITTED
Transaction ID: B2ABC8AF-B6D7-11D0-8CCB-414742565232 (17-APR-1997 04:04:32.55)
DECdtm Services Log Format V1.1
Type ( 3): LOCAL RM Log ID: 037100C0-0029-0003-7C23-000000000000
Name (22): "RMS$USER2.......*.D..."
(0000 0144162A 00000000 00000032 52455355 24534D52)
The disk with label 'RMS$USERS2' was online.
We saved the journal-file and the transaction-log. Any idea where to look next.
Thanks in advance,
Jaak
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 352.1 | MOVIES::POTTER | http://www.vmse.edo.dec.com/~potter/ | Fri Apr 25 1997 11:39 | 7 | |
Jaak, I think this is more of an RMS-Journaling issue than DECdtm - have you asked the RMS folk? regards, //alan | |||||
| 352.2 | RMS Note 3025 | BACHUS::LEEN | Jaak Leen, TP/IM Support Belgium 856-8738 | Mon Apr 28 1997 15:17 | 0 |
| 352.3 | Answer from the RMS notesfile | 54958::LEEN | Jaak Leen, TP/IM Support Belgium 856-8738 | Wed Apr 30 1997 16:15 | 38 |
We got the messages mentioned in .0 whe we did a 'dir/full' of a file that
participated in the transaction.
Regards,
Jaak
<<< VMSZOO::DISK$NOTES:[NOTES$LIBRARY]RMS_OPENVMS.NOTE;1 >>>
-< RMS asks, 'R U Journaled?' >-
================================================================================
Note 3025.1 Error while trying to recover 1 of 1
STAR::TSPEER 26 lines 29-APR-1997 09:15
--------------------------------------------------------------------------------
Jaak,
RMS is failing detached recovery because one of its calls to DECdtm
is failing -- RMS simply passes on this error. I strongly suspect
that the DECdtm call is $GETDTI, which RMS uses during recovery to
request that DECdtm return the global status (committed or aborted) of
a transaction in which RMS was a resource manager. NOSUCHPART from
DECdtm means that for some reason DECdtm fails to recognize RMS as
having been involved in the transaction. While there could be
numerous theoretical reasons for this failure, including a bad $GETDTI
call from RMS, the fact that this appears to be specific to certain
files involved in a specific transaction makes me wonder whether
DECdtm is having trouble accessing its log information for the data it
must return in the $GETDTI call. Could DEVOFFLINE be referring to the
device where the DECdtm transaction log was located? Does *any*
attempt to access the affected file(s) -- e.g. a simple DCL OPEN --
cause the same error? Is only one file involved, or do all files
involved in the transaction exhibit the same behavior?
Before bouncing this entirely back on the DECdtm people, you might
check the file SYS$MANAGER:RMSREC$SERVER_ERROR.LOG, which is
created/appended to whenever detached RMS recovery encounters a fatal
recovery error. There is a (slim) chance it may contain additional
information.
Tom Speer
| |||||
| 352.4 | MOVIES::POTTER | http://www.vmse.edo.dec.com/~potter/ | Wed May 07 1997 10:21 | 3 | |
Taken to note 3025 in VMSZOO::RMS_OPENVMS //atp | |||||