-RMS-F-PLV, unsupported prolog version
-
Topic author - Active Contributor
- Posts: 39
- Joined: Fri Jun 28, 2019 10:29 am
- Reputation: 0
- Location: Gary, Indiana
- Status: Offline
-RMS-F-PLV, unsupported prolog version
I have come across a few RMS files that:
1. will not allow me to copy from one system (alpha) to another (Itanium)
when previously this was standard practice
2. cannot put into a saveset
and generates the following error:
-RMS-F-PLV, unsupported prolog version
RMS files are on a DS-25 AlphaServer
OS version: OpenVMS V7.3-1
Are these RMS files repairable?
What steps should I take?
CONVERT/RECLAIM does not work.
1. will not allow me to copy from one system (alpha) to another (Itanium)
when previously this was standard practice
2. cannot put into a saveset
and generates the following error:
-RMS-F-PLV, unsupported prolog version
RMS files are on a DS-25 AlphaServer
OS version: OpenVMS V7.3-1
Are these RMS files repairable?
What steps should I take?
CONVERT/RECLAIM does not work.
Re: -RMS-F-PLV, unsupported prolog version
Code: Select all
> CONVERT/RECLAIM does not work.
As usual, showing what you actually did (actual commands) and what
actually happened when you did it (actual behavior, error messages)
might be more helpful than a vague description of what does _not_
happen.
I know nothing, but taking a hint from a different part of
HELP /MESS PLV
what about CONVERT /PROLOG [= 3]
?
Re: -RMS-F-PLV, unsupported prolog version
Let start by taking a look at the file as it exists now.
Try the following and post the output here:
DIR/FUL filename (let's see what RMS sees)
Dump/block=(start:0,end:1) filename (This too may shed some light).
Dan
Try the following and post the output here:
DIR/FUL filename (let's see what RMS sees)
Dump/block=(start:0,end:1) filename (This too may shed some light).
Dan
Re: -RMS-F-PLV, unsupported prolog version
Hmm, it's actually hard to reproduce -RMS-F-PLV under OpenVMS 8.4
A simple bad Prolog version in the prolog field for an indexed file almost always causes -RMS-F-PLG
Notably using $COPY, $OPEN, $CONV
Under OpenVMS 8.4 BACKUP copies without warning and puts it in a saveset without warning.
So please show us the EXACT commands and (extracts from) DIR/FULL for all files and directories involved.
Also, you indicated multiple files, That's odd. What do they have in common? A disk? A Directory? A producing application? A creation date? Maybe there is some large scale (disk) corruption?
As per Dan, let's try to understand what is out there.
Start DIRECTORY/FULL.
It should show a line like : File organization: Indexed, Prolog: 3, Using 3 keys
If the prolog is bad, that will just show: File organization: Indexed
Next, if it is bad, check with DUMP /BLOCK=COUNT=1 [WIDTH=80]
The Prologue is at offset 116 = %x74 and should be 3
1 and 2 are other valid values.
Perhaps more importantly and easier to spot, that byte should be surrounded by binary zeros.
If you see text of seemingly random data, then something overwrote the file contents and there is nothing much you can do other then restore from backup (or that other system).
The detailed definitions of that first block can be found in: libr/extr=$plvdef sys$library:lib.mlb /out=plvdef.mar
If the value is NOT 1,2 or 3, and I tried 0 and 0x41 then simply opening the file ($OPEN xxx <filename>) and other commands under OpenVMS 8.4 will give:
-RMS-F-PLG, error detected in file's prolog (reconstruct file)
Hein.
A simple bad Prolog version in the prolog field for an indexed file almost always causes -RMS-F-PLG
Notably using $COPY, $OPEN, $CONV
Under OpenVMS 8.4 BACKUP copies without warning and puts it in a saveset without warning.
So please show us the EXACT commands and (extracts from) DIR/FULL for all files and directories involved.
Also, you indicated multiple files, That's odd. What do they have in common? A disk? A Directory? A producing application? A creation date? Maybe there is some large scale (disk) corruption?
As per Dan, let's try to understand what is out there.
Start DIRECTORY/FULL.
It should show a line like : File organization: Indexed, Prolog: 3, Using 3 keys
If the prolog is bad, that will just show: File organization: Indexed
Next, if it is bad, check with DUMP /BLOCK=COUNT=1 [WIDTH=80]
The Prologue is at offset 116 = %x74 and should be 3
1 and 2 are other valid values.
Perhaps more importantly and easier to spot, that byte should be surrounded by binary zeros.
If you see text of seemingly random data, then something overwrote the file contents and there is nothing much you can do other then restore from backup (or that other system).
The detailed definitions of that first block can be found in: libr/extr=$plvdef sys$library:lib.mlb /out=plvdef.mar
If the value is NOT 1,2 or 3, and I tried 0 and 0x41 then simply opening the file ($OPEN xxx <filename>) and other commands under OpenVMS 8.4 will give:
-RMS-F-PLG, error detected in file's prolog (reconstruct file)
Hein.
-
Topic author - Active Contributor
- Posts: 39
- Joined: Fri Jun 28, 2019 10:29 am
- Reputation: 0
- Location: Gary, Indiana
- Status: Offline
Re: -RMS-F-PLV, unsupported prolog version
Greetings.
Thanks for responding to my post.
Clarification:
The error occurred on the Alpha (OpenVMS V7.3-1) during COPY to Itanium (OpenVMS V8.4)
and
The error occurred on the Alpha (OpenVMS V7.3-1) during an attempt to create a SAVESET.
Theory:
Again during a COPY of multiple files from Alpha (OpenVMS V7.3-1) to Itanium (OpenVMS V8.4)
the following error was encountered on Itanium:
SYSTEM-W-IDXFILEFULL, index file is full
Because of this error and attempting to COPY multiple files at the time, it is believe these files were
corrupted.
Thanks for responding to my post.
Clarification:
The error occurred on the Alpha (OpenVMS V7.3-1) during COPY to Itanium (OpenVMS V8.4)
and
The error occurred on the Alpha (OpenVMS V7.3-1) during an attempt to create a SAVESET.
Theory:
Again during a COPY of multiple files from Alpha (OpenVMS V7.3-1) to Itanium (OpenVMS V8.4)
the following error was encountered on Itanium:
SYSTEM-W-IDXFILEFULL, index file is full
Because of this error and attempting to COPY multiple files at the time, it is believe these files were
corrupted.
Code: Select all
$> dir /full CHX_2021080222163900_W26204.DAT;1
Directory DATA$DISK1:[PRODQ.CHX.DATA]
CHX_2021080222163900_W26204.DAT;1 File ID: (45248,885,0)
Size: 137/137 Owner: [PROD,PRODUCTION]
Created: 2-AUG-2021 22:16:39.82
Revised: 2-AUG-2021 22:16:39.82 (0)
Expires: <None specified>
Backup: <No backup recorded>
Effective: <None specified>
Recording: <None specified>
Accessed: <None specified>
Attributes: <None specified>
Modified: <None specified>
Linkcount: 1
File organization: Indexed
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 137, Extend: 63, Maximum bucket size: 63, Global buffer count: 0, No version limit Contiguous best try
Record format: Variable length, maximum 0 bytes, longest 0 bytes
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RWED, World:
Access Cntrl List: None
Client attributes: None
Total of 1 file, 137/137 blocks.
$> dump CHX_2021080222163900_W26204.DAT;1 /block=count=1/width=80
Dump of file DATA$DISK1:[PRODQ.CHX.DATA]CHX_202108022 on 5-JUL-2023 10:59:40.86
2163900_W26204.DAT;1
File ID (45248,885,0) End of file block 137 / Allocated 137
Virtual block number 1 (00000001), 512 (0200) bytes
00000000 00000000 00000000 00000000 ................ 000000
00000000 00000000 00000000 00000000 ................ 000010
00000000 00000000 00000000 00000000 ................ 000020
00000000 00000000 00000000 00000000 ................ 000030
00000000 00000000 00000000 00000000 ................ 000040
00000000 00000000 00000000 00000000 ................ 000050
00000000 00000000 00000000 00000000 ................ 000060
00000000 00000000 00000000 00000000 ................ 000070
00000000 00000000 00000000 00000000 ................ 000080
00000000 00000000 00000000 00000000 ................ 000090
00000000 00000000 00000000 00000000 ................ 0000A0
00000000 00000000 00000000 00000000 ................ 0000B0
00000000 00000000 00000000 00000000 ................ 0000C0
00000000 00000000 00000000 00000000 ................ 0000D0
00000000 00000000 00000000 00000000 ................ 0000E0
00000000 00000000 00000000 00000000 ................ 0000F0
00000000 00000000 00000000 00000000 ................ 000100
00000000 00000000 00000000 00000000 ................ 000110
00000000 00000000 00000000 00000000 ................ 000120
00000000 00000000 00000000 00000000 ................ 000130
00000000 00000000 00000000 00000000 ................ 000140
00000000 00000000 00000000 00000000 ................ 000150
00000000 00000000 00000000 00000000 ................ 000160
00000000 00000000 00000000 00000000 ................ 000170
00000000 00000000 00000000 00000000 ................ 000180
00000000 00000000 00000000 00000000 ................ 000190
00000000 00000000 00000000 00000000 ................ 0001A0
00000000 00000000 00000000 00000000 ................ 0001B0
00000000 00000000 00000000 00000000 ................ 0001C0
00000000 00000000 00000000 00000000 ................ 0001D0
00000000 00000000 00000000 00000000 ................ 0001E0
00000000 00000000 00000000 00000000 ................ 0001F0
$>
Re: -RMS-F-PLV, unsupported prolog version
Ok, that explains for PLV error versus PLG.
I can reproduce this under 8.4-2 using:
Regardless, you are Fu*(&ed - as you surely realize after seeing all those zeros.
The "SYSTEM-W-IDXFILEFULL, index file is full" looks like a warning but was fatal.
It's somewhat special that the file was created at all.
I suspect it is supposed to be relatively large and the target volume was fragmented.
In such case it can perhaps create the first header, but doesn't have the space for lots of extension headers to hold pointer to all the fragments needed to fulfill the desired allocation.
I could see this happen to multiple large files, each taking one more header from the INDEXF.SYS before failing to extend.
Anyway - you'll have to get back to your backups or real source data - pre copy.
And be sure to check (and fix) those disk for excessive fragmentation.
Good luck,
Hein
I can reproduce this under 8.4-2 using:
Code: Select all
$ copy nl: tmp.idx/allo=137
$ set file/end tmp.idx
$ dump/bloc=count=1 tmp.idx ! Shows EOF 138 (cluster rounding) an all zeros for data (High Water Marking)
$ set file/attr=(org=idx, bks=63) tmp.idx
$ dire/full tmp.idx ! File organization: Indexed ... Maximum bucket size: 63,
$ open x tmp.idx
%DCL-E-OPENIN, error opening DSA3:[DECUSERVE_USER.HEUVEL_H]TMP.IDX;1 as input
-RMS-F-PLV, unsupported prolog version
The "SYSTEM-W-IDXFILEFULL, index file is full" looks like a warning but was fatal.
It's somewhat special that the file was created at all.
I suspect it is supposed to be relatively large and the target volume was fragmented.
In such case it can perhaps create the first header, but doesn't have the space for lots of extension headers to hold pointer to all the fragments needed to fulfill the desired allocation.
I could see this happen to multiple large files, each taking one more header from the INDEXF.SYS before failing to extend.
Anyway - you'll have to get back to your backups or real source data - pre copy.
And be sure to check (and fix) those disk for excessive fragmentation.
Good luck,
Hein
-
Topic author - Active Contributor
- Posts: 39
- Joined: Fri Jun 28, 2019 10:29 am
- Reputation: 0
- Location: Gary, Indiana
- Status: Offline
Re: -RMS-F-PLV, unsupported prolog version
Hein,
Thanks for the reply and clarifying the inevitable.
Just for further clarification:
.DAT file was created, successfully on Alpha.
.DAT was being COPIED to Itanium for back up purposes.
*** So it seems the fatal event occurred during the COPY event from Alpha to Itanium because of the fragmented
state of the Itanium volume.
Thanks again for your assistance at clarifying and analysis.
Vince
Thanks for the reply and clarifying the inevitable.
Just for further clarification:
.DAT file was created, successfully on Alpha.
.DAT was being COPIED to Itanium for back up purposes.
*** So it seems the fatal event occurred during the COPY event from Alpha to Itanium because of the fragmented
state of the Itanium volume.
Thanks again for your assistance at clarifying and analysis.
Vince
Re: -RMS-F-PLV, unsupported prolog version
It sounds like the Alpha still has the uncorrupted file. Also, the disk on the itanium system is either too small or has a large cluster size and limited file counts. Rather than using copy, try using backup to create a saveset. This may allow some compression and result in a smaller file or at least one that has fewer extents. Too little information about either system to make any more suggestions.
Dan
Dan