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

Arpadffy Zoltan zoltan.arpadffy at essnet.se
Fri Aug 13 09:15:21 CEST 2004


Hello,

I got tired of fear that I can not trust to my favourite text editor - probably some of you share this feeling with me.

As you all know, Vim sometimes for certain RMS record formats added an extra CR if it does not contain one at the end of the record.
It is not acceptable an this error severity could be classified as MAJOR or better FATAL.

We, waited for HP's support and Fran Ries who kindly offered his help - but the patch has never arrived.

I haven't had any other solution but to make a deeper investigation, test and come to current patch that seems works good for all RMS record types (that have been tested).
Seems, problem lies deep in C RTL and we can do just work-a-round. Actually it is not a problem, but a natural RMS record handling that requires certain terminator from some structures. If terminator does not exits it adds one at the end of maximum record size length block.

Vim on VMS between 5.6 and 5.7 moved over from line to block write that caused this odd behaviour. Block write is much faster, but particular record formats needs to be handled on slower per line method. 

As I am (being a security specialist) not an expert in file handling on RMS level from C, had a hope that somebody will fix this in professional way.
Therefore it took so long.

Anyhow, now it is done and it passed all my tests.

Actually it did it earlier as well, but then I find jet another FAB/RAT combination that failed - therefore I am a bit sceptic to release this patch officially with all announces and fireworks before I am absolutely sure that we finally solved the problem.

Therefore I would kindly ask you: if you have some file that you have experienced anomaly described above.
Please send either the file or the ana/rms <filename> output to zoli (at) polarhome.com in order to test.

Thank you in advance.

BTW I find a minor bug that expanded environment variables when it was not attended. Typical example is to edit file SYS$COMMON:[SYSLIB]filename when 
 $ sh log common
   "COMMON" = "DISK$HSG_1:[COMMON]" (LNM$SYSTEM_TABLE)

Vim will try to edit file SYSDISK$HSG_1:[COMMON][SYSLIB]filename that does not exist, because $COMMON should not be expanded here as a logical.
:) this bug is corrected as well.

The third problem is what I noticed during work is that escape handling is a bit strange with current low level character input. It does not consume resources as earlier, but the side effect is that sometimes happenens the following:
Please note: GUI mode is not affected here.

Edit the file in insert mode an attempt to search - you will probably press an <esc> and a /. What Vim does sometimes is that it accepts all characters but does not display immediately the "/" sign at the bottom just after first search character - even if it works correct I would like to have shown the "/" sign immediately after I pressed "/". It should be possible to escape from sys$qiow in vms_read, but I haven't had time to read the documentation jet. Maybe some of you already did?

If we succeed with this patch Vim on VMS would be VMS specific bug free.

Regards, 
Z




More information about the Vim-vms mailing list