[Vim-vms] Record format and attributes problems in VIM on VMS

[Arpadffy Zoltan]

Frank,

you have shown that you have deep competence in VMS programming.
Hope you are willing to help us one more time with burning problem in VMS
system.

Vim uses block, binary write on C level (without sys$ calls), but sometimes
it has a very strange behaviour.
Actually this bug is thought to be solved somewhere in 6.0.x version, but I
got a new error report that I could verify that bug still exists and
requires competent and fast solution - because Vim will loose its
reliability.

Problem description:
RMS files can have different record format and attributes and a reliable
text editor should handle it equally safe. But seems for some reason
fab$c_var variable record format with fab$m_cr attribute is handled on
different way. We used a dirty solution of per line writing to solve this
anomaly, but recently one Vim user pointed out that   

If you read comments in FILEIO.C around line 3670 

#ifdef VMS
        /*
         * On VMS there is a problem: newlines get added when writing blocks
         * at a time. Fix it by writing a line at a time.
         * This is much slower!
         * Explanation: Vim can not handle, so far, variable record format.
         * With $analize/rms filename you can get the rms file structure,
and
         * if the Record format filed is variable, CR will be added after
         * every written buffer.  In other cases it works without this fix.
         * From other side read is about 5 times slower for "variable record
         * format" files.
         */

....you can see that I made an attempt to filter out fab$c_var , but after
this error report I made a hot fix by adding FAB$M_CR filter as well:

TOR_ZAY $ diff structs.h
************
File USRDSK:<ZAY.WORK.VIM62-181.SRC>STRUCTS.H;2
  898       char        b_fab_rfm;      /* Record format    */
  899       char        b_fab_rat;      /* Record attribute */
  900   #endif
******
File USRDSK:<ZAY.WORK.VIM62-181.SRC>STRUCTS.H;1
  898       char        b_fab_rfm;      /* Record format */
  899   #endif
************

 $ diff FILEIO.C;3 FILEIO.C;1
************
File USRDSK:<ZAY.WORK.VIM62-181.SRC>FILEIO.C;3
  454               curbuf->b_fab_rat = st.st_fab_rat;
  455   #endif
******
File USRDSK:<ZAY.WORK.VIM62-181.SRC>FILEIO.C;1
  454   #endif
************
************
File USRDSK:<ZAY.WORK.VIM62-181.SRC>FILEIO.C;3
 3674           if (buf->b_fab_rfm == FAB$C_VAR || buf->b_fab_rat ==
FAB$M_CR )
 3675           {
******
File USRDSK:<ZAY.WORK.VIM62-181.SRC>FILEIO.C;1
 3673           if (buf->b_fab_rfm == FAB$C_VAR)
 3674           {
************

Please note this is not delivered as a patch, and I (in the name of Vim
users community on VMS) would prefer to have a professional solution for
this problem and to have it well done. Therefore I ask competent HP
programmers to help us out.

RMS structures that I have detected problem are :   (below you can find
output from ANAL/RMS )

        File Organization: sequential
        Record Format: variable
        Record Attributes:  carriage-return
        Maximum Record Size: 0

These files get an CR after each record in block write

from other side:

        File Organization: sequential
        Record Format: stream
        Record Attributes:  carriage-return
        Maximum Record Size: 0

these files get a CR in per line write

Problem is easily reproduced:
1. take a longer textual file. Good example is a file filled with same
chars, 500 rows x 100 chars
2. set RMS file attributes
3. invoke vim filename
4. just :wq!  exit
5. run diff filename

result will be that files differ even if they should not and the difference
is an CR after each RMS record.

It is possible to try with different combinations in line
if (buf->b_fab_rfm == FAB$C_VAR || buf->b_fab_rat == FAB$M_CR )

... to see how it behaves... or ,that would be the best, to give a final
professional solution.

Thank you very much in advance.

Best regards, 
Z