Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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

 
allin-in-one
Frequent Advisor

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

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.

 

 

 

12 REPLIES
Steven Schweda
Honored Contributor

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

> 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
Frequent Advisor

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

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
Honored Contributor

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

> 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
Honored Contributor

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

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

A crucible of informative mistakes
Hein van den Heuvel
Honored Contributor

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

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
Honored Contributor

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

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
Honored Contributor

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

>>> 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
Frequent Advisor

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

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
Honored Contributor

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

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.

Steven Schweda
Honored Contributor

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

> The problem is with files having variable length records.
> Hancled them seperately did resolve the problem.

   I'm always open greater wisdom, but I would have thought that a
scheme which handles the general case properly would not require any
separate, special handling for the var-len case.

   As I said almost a year ago:

>    Again, Info-ZIP Zip and UnZip may have $QIO code which works.  If Zip
> ("zip -V") and UnZip can reproduce your file correctly, then you may be
> able to learn something from those (open-source) programs.  If Zip and
> UnZip fail to reproduce your file correctly, then the Info-ZIP folks
> would be interested in a useful bug report (that is, a bug report
> (unlike this one) which includes enough information to allow debugging
> -- ideally, a small test case).

   My memory is bad, but I don't remember Zip or UnZip doing anything
special for var-len record-format files (when preserving VMS file
attributes).  If that's true, and those programs don't have any trouble
with such files, then that would suggest (to me, at least) that making
var-len a special case is not required (and perhaps unwise).

   I'm still waiting for a bug report which demonstrates a Zip or UnZip
bug similar to the ones reported for this "a backup application".

Hein van den Heuvel
Honored Contributor

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

Mr All-In-One, I'm pretty sure this was NOT an issue with supporting basic variable length files (VAR), but rather a problem supporting v variable length records WITH FIXED CONTROL (VFC).

 

Steven, 

I'm pleased to report that  Zip 3.0 (July 5th 2008) and UnZip 6.00 of 20 April 2009 handle these special, non-obvious files just fine. It kinda has to support 'spool' file or batch job logs ( Record format:      VFC, 2 byte header, maximum 0 bytes, longest 68 bytes; Record attributes: Print file carriage control; ). It does take special coding provisioning RAB$L_RHB and looking at (read) or setting (write) FAB$B_FSZ

Hein.

$ conv/fdl="record; format vfc; control 4" tt: tmp.tmp/fixed
aap hello
nootcruel
miesworld
 Exit
$ type tmp.tmp ! Fixed header agnostic
hello
cruel
world
$ conv/fix/fdl=" " tmp.tmp tt:  ! Fixed header aware, going to a non-VFC target
aap hello
nootcruel
miesworld
$ zip -"V" tmp tmp.tmp
  adding: TMP.TMP (stored 0%)
$ unzip tmp
Archive:  SYS$SYSDEVICE:[HEIN]tmp.zip;1
new version of TMP.TMP? [y]es, [n]o, [A]ll, [N]one, [r]ename: r
new name: unzipped.tmp
 extracting: SYS$SYSDEVICE:[HEIN]unzipped.tmp;
$ type unzipped.tmp
hello
cruel
world
$ conv/fix/fdl=" " unzipped.tmp tt:
aap hello
nootcruel
miesworld

 

 

H.Becker
Honored Contributor

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

>>> the ODS2.MEM document that AG wrote

That's what I had in mind. On a freeware cd (v50/ods2/) it is named "ods2.doc". However, the paragraph (6.1) "File Attributes" is not in my copy of Kirby's book. There is some info on index files in the decus library: "decus/vax85a/morse/rmsisam.tlk". And then there is the "A Brief Overview of RMS-11 Internals", which pre-dates RMS-32 (no streamlf/cr) but still may help to understand some of the internal data strutures.