-RMS-F-PLV, unsupported prolog version

[vmskostoff]

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.

[sms]

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]
?

[abrsvc]

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

[hein]

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.

[vmskostoff]

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.

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
$>

[hein]

Ok, that explains for PLV error versus PLG.
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

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

[vmskostoff]

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

[abrsvc]

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