#364 VMS Open Previous DB file error

Program (402)

In order to get this to run properly under VMS, In
menu.c, the following changes were added to
WriteNEditDB and ReadNEditDB respectfully ( diff -u
output ) -- see uploaded file.


  • Nobody/Anonymous

    diff -u menu.c menuFixed.c

  • roymac

    roymac - 2004-04-11

    Logged In: YES

    It should also be noted that this has not been tested with a
    Unix platform - only VMS 7.3

  • Eddy De Greef

    Eddy De Greef - 2004-06-23
    • labels: --> Program
    • milestone: --> release
  • Eddy De Greef

    Eddy De Greef - 2004-06-23

    Logged In: YES

    Your fix for writing the history file appears flawed to me.
    When a file is opened in "r+" mode and the new contents is
    shorter than the old one, there will be some trailing
    garbage in the file when it is closed. At least, that's what
    happens on Unix.

    For instance, suppose that the history file contains this line:

    If you reopen the file in r+ mode, and insert a new entry
    like this

    the net result will be a file containing this:

    Isn't there a way to force file truncation on VMS?
    Would "w+" work?

  • roymac

    roymac - 2004-06-23

    Logged In: YES

    The conditional compilation statements should ensure that
    this fix is not used under unix - it should appear unchanged
    under unix, however, this was not tested. It would be no
    surprise if the "r+" did not work under unix.

    The code has been used daily since the fix - successfully.

    The following from the DEC C run-time library manual for
    OpenVMS might be useful:
    "r+" opens an existing file for read update access. It is
    opened for reading, positioned first at the beginning-of-file,
    but writing is also allowed.
    See fopen:

    Contrast this with:
    r+ open text file for update (reading and writing)
    Tru64 UNIX Compaq C Language Reference Manual

  • Eddy De Greef

    Eddy De Greef - 2004-06-24

    Logged In: YES

    It's not the behaviour on Unix that I'm afraid of; I know
    it's compiled conditionally. Unix positions the file point
    at the beginning also, BTW.

    What I'm saying is that if the behaviour on VMS is the same
    as on Unix, the file is not truncated, and this can result
    in trailing garbage. This trailing garbage can eventually
    show up as junk entries in the Open Previous menu (which you
    may never have noticed, if they ever showed up at all).

    VMS appears to have ftruncate(), so we can use that to force
    truncation. So I would write the VMS part as follows:

    if ((fp = fopen(fullName, "w")) == NULL)
    #ifdef VMS
    if ((fp = fopen(fullName, "r+")) == NULL)
    if (ftruncate(fullName, 0) != 0)

    Do you see any problem with that?

  • Eddy De Greef

    Eddy De Greef - 2004-06-28
    • assigned_to: nobody --> edg
    • status: open --> closed-fixed
  • Eddy De Greef

    Eddy De Greef - 2004-06-28

    Logged In: YES

    Summary of private communication with roymac:
    he confirmed that his suggested fix resulted in trailing
    garbage in the history file, as I suspected. Adding an
    ftruncate() call solved the problem. The fix is now in CVS.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks