[Info-vax] mmap on VMS - (was: Anyone interested in another public access system)

[Bob Eager]

On Mon, 13 Apr 2009 00:20:58 UTC, "John E. Malmberg" 
<wb8tyw at qsl.network> wrote:

> Bob Eager wrote:
> > On Sun, 12 Apr 2009 22:13:57 UTC, Michael Kraemer <M.Kraemer at gsi.de> 
> > wrote:
> > 
> >> Bob Koehler schrieb:
> >>> In article <grqqh7$ore$03$1 at news.t-online.com>, Michael Kraemer <M.Kraemer at gsi.de> writes:
> >>>
> >>>> if performance is an issue, on Unix I'd use mmap() services in such cases.
> >>>>
> >>>
> >>>    Thanks you for making my point!  It seems that the lack of current
> >>>    emacs ports to systems like VMS is because someone decided to mmap()
> >>>    the files and do the record stuff themselves.  Shooting everyone
> >>>    else in the foot!
> >>>
> >> I don't see why this would make your point.
> >> mmap() (or equivalent) services should be available
> >> on all systems with native support for an MMU,
> >> which includes Unix, WNT and possibly also VMS.
> > 
> > Yes, easy enough in VMS; I've done it many times. RMS $OPEN with FOP=UFO
> > in the FAB. Then use $CRMPSC.
> 
> mmap() on a program written for for UNIX only works on VMS files that 
> are the same in memory as on disk, like stream and binary formats.

First, I was merely making the point that such services *are* available 
on VMS. Whether they would make it easy to port a particular program is 
a separate issue.

> Most text files on VMS are variable record format with implied carriage 
> control.

I am aware of that, after 26 years of VMS...!

> So mmap() can not be used to for a partial update of those type of text 
> files.

I doubt if UNIX programs do that either...it would imply that the 
replacement text is the same size as the original. My experience of 
editors doing memory mapping is that they build data structures 
describing parts of the file, as encountered, in the form of cells that 
describe records or sets of records - whether those records have a 
delimiter such as a newline character, or a record header, is fairly 
immaterial. New material is kept in a separate memory area and linked 
in. When the edit is complete, the whole file is copied (new cells and 
old) to a new version of the file. This technique tends to be sparing on
page faults except at the point when the edit is completed.

> Coming up with a mmap() that can work on all VMS file types in a way 
> that Unix programs expect, and have it efficient is not an easy thing to 
> do.

I agree....but in practice I suspect that a slightly lower level 
approach in the ported program might work.
-- 
Bob Eager