Operating System - OpenVMS
1748092 Members
5766 Online
108758 Solutions
New Discussion

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

 
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.