Convert/Fdl "RMS-F-MRS, invalid maximum record size"

[STEVE WATTS_2]

I am attempting to convert a sequential file to an indexed file using an FDL that was first created using "ANAL/RMS/FDL" and then modified by increasing the record size to 2500. Although this size is well within the bounds of allowable values, I get this error when I attempt to run "CONVERT/FDL=XYZ"...


%CONV-F-OPENOUT, error opening XYZ.DAT as output
-RMS-F-MRS, invalid maximum record size

I would be very grateful if any old fellow VMS geezers could shed some light.

Steve

Running VAX 7000-620 (360) OpenVMS V6.2

[Hein van den Heuvel]

Please check : $help/mess/fac=rms mrs
Second page. 3rd explanation

RMS indexed file records are stored in BUCKETS, and must fit in those buckets.

Apperently the BUCKET SIZE, as specified in the AREA 0 is less than 5 in your case.

For a 2500 byte record that bucketsize needs to be at least 5 to make it work. (5*512 - 15 - 11 )

Note though that from a performance perspective you typically want to store several records in a data bucket.

This may already be the case, thanks to RECORD COMPRESSION, but a bucket size of 4 (or less) suggests either a very smart design, or a willy nilly acceptingof defaults. Given the question today...

You may want to consider an RMS tuning review for this application if there is any concern about its performance.

Regards,
Hein van den Heuvel ( at gmail dot com )
Hvdh Performance Consulting

(note, the AREA number for which to change teh bucket size is typically 0 but it really is the DATA AREA number for KEY 0 )

[STEVE WATTS_2]

HELP/MESS s does not work on this system, hence the question on the forum. Is there anywhere else you can find that info?

Thanks for the reply, I will tweaking some FDL attributes.

Steve

[STEVE WATTS_2]

BUCKET = 5 did the trick.

Thank very much.

Steve

[Robert Gezelter]

Steve,

I would agree with Hein that a more global review would be a good choice.

It is quite possible that other problems, either fatal as in this case, or performance related can be encountered by simply changing parameters without an understanding of the totality of the situation.

- Bob Gezelter, http://www.rlgsc.com

[Jim_McKinney]

> HELP/MESS s does not work on this system

Perhaps the HELP verb has been re-defined? Does "SHOW SYMBOL HELP" reveal anything? What happens when it "does not work"? If you get output like "Message number xxxxxxxx" then you've been bitten by a a bug in the v6.2 SYS$HELP:MSGHLP$ENGLISH.EXE which can be cured by replacing that file with the same one from v6.1.

[Hein van den Heuvel]

>> HELP/MESS s does not work on this system

It uses sys$system:MSGHLP$MAIN.EXE
What was the problem/error with it?

Anyway, maybe for future problems you can just go to an other, more recent, OpenVMS system and try it there? There are several OpenVMS out there in the open, happy to take guests.


>> BUCKET = 5 did the trick

It made it work. It probably was far from optimal. Do an ANALYZE/RMS/FDL on the original, or new, file and specifically check the DEPTH line. Attach results to a future reply, if suggestion are needed.

You can also simple REMOVE, or comment out, that line with BUCKET. RMS will make is just big enough.
As you grow the records, you may also want to grow the ALLOCATION and EXTENT

Typically an EDIT/FDL/NOINTERACTIVE, porvided with reasonable ANAL/RMS/FDL output will do a reasonable job (gigo) adjusting sizes.

Enjoy!
Hein.

[STEVE WATTS_2]

The HELP/MESS brings back this nonsense:-

Message number 05FD801B
Message number 05FD8033
Message number 05FD801B
Message number 05FD8043
Message number 05FD801B
Message number 05FD8053
Message number 05FD8013

So looks like the bug Jim eluded to?

I don't think performance will much of an issue, the file only contains 5000 records. This file is our client master, and was originally designed by a company I worked for back in the late 80's, and over the years a succession of programmers have tagged on additional fields.

[Jim_McKinney]

Regarding HELP/MESSAGE see

http://groups.google.com/group/comp.os.vms/browse_frm/thread/187710d104a3a48e/