From: Jan Vorbrueggen [jan@fsnif.neuroinformatik.ruhr-uni-bochum.de]
Sent: Tuesday, January 04, 2000 6:41 AM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: RMS (Record Manager System): 16- or more bits ?

"Bill Todd" <billtodd@foo.mv.com> writes:

> RMS block I/O is not the same as direct use of QIO (the same distinction I
> drew in responding to Larry, which you may not have seen), and does
> effectively support record locking for block-aligned user-structured records
> (i.e., it locks the block range associated with a record if you read at that
> granularity - which is admittedly awkward to know beforehand unless you just
> read the first record block and then as many additional blocks as its size
> indicates are needed, or just read in a bunch of blocks assuming that if you
> lock a bit more than necessary for a short time the impact won't be a
> problem).
> A file created and populated using RMS block I/O and undefined record format
> should not present undue problems to other parts of VMS, save that
> record-oriented utilities won't be able to process it in record-oriented
> fashion.  Since the records are larger than most such utilities expect
> anyway, the negative impact should be minimal, and functions like
> backup/restore should still work just fine:  are there other specific
> problems you had in mind?

This doesn't work. The records aren't neccessarily large - think a very usual
Fortran application which writes a small record containing the dimensions of
its data arrays, and then dumps them one by one as a single record each. That
first record might be in the 4-40 bytes range, and the following ones can be
anything from a few bytes to a few MB/GB/TB/PB/EB/.... So, in a number of
cases I might still expect to use DUMP/RECORD, for instance, or expect record
locking to really work on the record level and not be block-aligned, block-
multiple byte-range locking, as I understand you RMS can do for block I/O.
Also, Fortran wants to check that the data requested by the program is no
larger than the data contained in the next record in the file.

The comment regarding BACKUP was that, given an RMS-supported file format
with 32 (or 64) bit record lenghts, it could actually use such a format on
a sequential device (such as a DLT) and a disk interchangibly. Currently,
you can even copy a BACKUP saveset created with /BLOCK>32k from tape to
disk.

> Since I'm not familiar with the 'back pointer' mechanism you mentioned on
> Unix, I'd be grateful for a brief explanation should you have time.

It's really very simple: Instead of only pre-pending the record length 
to the record as it is written to disk, you also post-pend it. This makes
implementation of Fortran's BACKSPACE (required by the language standard 
since times immemorial) trivial. Ask Steve Lionel how long it took the
VMS Fortran team to get BACKSPACE to work properly and somewhat efficiently
in the usual case...(hint: re-reading the whole file from the beginning is
a standard-conforming, but not very viable solution).

	Jan