ANALYZE/RMS/CHECK returning "Record not long enough to accommodate fixed control header.&am

[allin-in-one]

Hi,

We have a backup/restore application, after restoring the backuped file running the command ANALYZE/RMS/CHECK returning "Record not long enough to accommodate fixed control header."

Ccoollected output from command DUMP/ALL on the file before backup and after the restore.

There is no difference in the output from DUMP/ALL.

Running the CONVERT on the restored file fixing this issue.

We are using sys$qio for the backup and restore.

Please let me know how to address this issue programetically.

[Steven Schweda]

> Please let me know how to address this issue programetically.

   The people in your audience (like me) with weak psychic powers have
no idea what your code does, and we also can't see the "before" and
"after" file data (and, especially, the meta-data).  Just as before:

      http://community.hpe.com/t5/x/x/m-p/6690511

[allin-in-one]

My appologies for not providing file data.

due to confidentiality of data I couldn't proviide file data.

Please let me know if you need any specific information.

Thank you

[Steven Schweda]

> Please let me know if you need any specific information.

   Yes, "any specific information" might be helpful.  Perhaps the same
as was requested last time (http://community.hpe.com/t5/x/x/m-p/6690511)
would be a good start.  For example:

> [...]
> 4 - What makes you believe that the file attributes are the same?
> Please do DIR/FULL on both files and post that.
> [...]
> 5 - Please do DUMP/BLOCK=(COUNT:0)/HEADER on both files and post that
> This will provide even more attributes than the DIR/FULL.
> [...]


> due to confidentiality of data I couldn't proviide file data.

   And if you provide no information of any kind, then what do you
expect to get from anyone here?

[John Gillings]

I'm curious to know why you're not using the built in BACKUP utility? Why reinvent a perfectly good wheel?

[Hein van den Heuvel]

Steven,... Nice catch on the prior equally sillytopic.

Nameless, shameless, all-in-one dude,

I suspect this issue is due to the the qio-file-mangler-backup-tool not supporting with Variable Length with Fixed Control files. See RMS REF Manual, looking for VFC, FSZ, FHB. And check HELP CONVERT FILE /FIXED_CONTROL

Why was $ ANALYZE run against this file? Was there an application error on the using the file? Is the backup tool so unreliable that it's operations need to be checked? Is running ANALYZE on the original file succesful?

If the source is clean, than why do you not work this issue with the folks that support the backup application? They corrupted the file they are the only ones that can stop that from happening.

>> due to confidentiality of data I couldn't proviide file data.

Nobody here cares about the actual data, nobody here want to see you data. All we care about is the META DATA, that's all ANALYZE/RMS cares about. It does not look at the bytes.

>> Please let me know if you need any specific information.

Ah, now you are talking something reasonable.

- We need the exact commands used, notably that 'CONVERT' which supposedly fixed it.

- We need the exact error message, not an approximation. Best I can tell the message should have had some leading stars and VBN number to start with.

- We need a DIR/FUL output, notably the lines with : File organization;  Record format; Record attributes;

- We need DUMP/HEAD/BLOCK=COUNT=1 output, specifically the " VAX-11 RMS attributes" section.

- We need you to check that the CONVERT really fixed it, or just managed to hide the problem. Convert just dumped all record after the bad one/

- AFTER you op obtained the RFM/FSZ for original input file, and compared with the restored file, do this 'trick

$ set file/attr=rfm=var tmp.tmp
$ pipe dump/wid=80/rec tmp.tmp | search sys$pipe rfa

Here is how I can recreate the message:

$ create tmp.tmp
aap hello
nootworld
bad
vuurgoodbye
$ set file/att=(rfm=vfc,fsz=4) tmp.tmp
$ analyze/rms/check tmp.tmp

: 

*** VBN 1: Record not long enough to accommodate fixed control header.

:

'fix' ... dropping record #4

$ convert tmp.tmp tt:/fixed
hello
world
$ convert tmp.tmp tt:/fixed/fdl=nl:
aap hello
nootworld

$

Cheers,

Hein

[Hoff]

Whether this problem is an error in the backup client code itself, or — more likely, for this case — a problem with how the backup client code manages the RMS metadata, or with the handling of locking and related coordination?  That'll involve digging into the source code for the backup client.  If the file data has been xxd'd or DUMP'd and the source and recovered file on-disk data has been found to be identical, then differences within the RMS metadata are the likely trigger.

Since that source code access is probably not going to happen...

One of the best available resources is Kirby McCoy's VMS File System Internals book — that's a little dated and entirely predates ODS-5, but its contents are still applicable to how ODS-2 and ODS-5 and the XQP work on OpenVMS.   Or generate some small reproducers — standalone code, outside of what's in the client — that can be posted here in the forum.

Whether the expectations of the backup server associated with this backup client are compatible with piping the OpenVMS BACKUP utility output or BACKUP callable interface output is something that the vendor would have to decide — though the folks at VSI might eventually be interested in making callable BACKUP more flexible, if it's not already capable of dealing with this case.   Or HPE / VSI might be willing to license the associated source code.

The other obvious option is to work directly with somebody that can be vetted to view the source code, and that can provide assistance beyond what's reasonably feasible in a discussion forum, and where source code that can reproduce the issue isn't easily available for posting.

FWIW and based on previous postings, I suspect that this is a bug in a commercial backup client for OpenVMS, and I'd further suspect that the OP is supporting the particular client.  I'll refrain from naming the vendor and the backup client that I suspect is involved.

[H.Becker]

>>> One of the best available resources is Kirby McCoy's VMS File System Internals book — that's a little dated and entirely predates ODS-5, but its contents are still applicable to how ODS-2 and ODS-5 and the XQP work on OpenVMS.

I doubt that this book helps, here. As I understand the error message and Hein's example, this is related to RMS and not related to the file system. The book only mentions FH2$W_RECATTR without explaining the bits: "This area is used by the record manager ...".  $FATDEF describes the bits, it is in SYS$LIBRARY.LIB.MLB and friends. Also, there was a text document on the net, describing RMS internals, but I don't remember the URL nor the name. 

[allin-in-one]

Thank you all for your suggestions. It helped me alot in finding the root cause of the problem.

The problem is with files having variable length records.

Hancled them seperately did resolve the problem.

Thank you.

[Hoff]

re: VFSI: It's the available overview, and it describes the locking.

There's another?  Interesting.  The only RMS internals document I can recall was the ODS2.MEM document that AG wrote, and Kirby's book covers that material.  The Files and Applications Manual in the doc set and the IDSM are the other available resources here.  Davis' clustering internal manual is a little further afield.