Discussion:
RMS - Wish list
(too old to reply)
Greg Tinkler
2021-10-15 06:19:14 UTC
Permalink
As a follow on from my previous post

UDF
files you can sequentially get/put, but you cannot access using RFA.
This would be useful, yup there is no defined record but the buffer size is all that is needed. 'record' locking is based on RFA so shared access should not be a problem.

As previously mentioned, SYS$READB(rab) and SYS$WRITEB(rab) would also be useful, NB based on RFA so again shared access should work. NB RMS underneath would as it does today, coordinate the block access to ensure the latest block is used when accessed.

I assume the SSIO is focused on UDF files?

gt
Stephen Hoffman
2021-10-15 15:39:07 UTC
Permalink
Post by Greg Tinkler
As a follow on from my previous post
UDF
files you can sequentially get/put, but you cannot access using RFA.
This would be useful, yup there is no defined record but the buffer
size is all that is needed. 'record' locking is based on RFA so shared
access should not be a problem.
You're asking for what a stream file provides. You've yet to free
yourself from a need for emulated-punched-cards abstractions, though.
Post by Greg Tinkler
As previously mentioned, SYS$READB(rab) and SYS$WRITEB(rab) would also
be useful, NB based on RFA so again shared access should work. NB RMS
underneath would as it does today, coordinate the block access to
ensure the latest block is used when accessed.
I assume the SSIO is focused on UDF files?
SSIO seeks to avoid the latent file corruptions that arise with sharing
stream files within the current implementation of C and RMS:

One of the few presentations on this topic:
http://de.openvms.org/TUD2012/opensource_and_unix_portability.pdf
--
Pure Personal Opinion | HoffmanLabs LLC
Hein RMS van den Heuvel
2021-10-15 16:01:19 UTC
Permalink
Post by Stephen Hoffman
Post by Greg Tinkler
As a follow on from my previous post
UDF
files you can sequentially get/put, but you cannot access using RFA.
This would be useful, yup there is no defined record but the buffer
size is all that is needed. 'record' locking is based on RFA so shared
access should not be a problem.
You're asking for what a stream file provides.
Noop.
At least not for stream files in RMS terms, accessed through RMS.
For access to stream files through RMS you cannot just specify a size.
RMS will hunt for terminators as per specific stream attribute.

Hein.
Dave Froble
2021-10-15 19:24:57 UTC
Permalink
Post by Hein RMS van den Heuvel
Post by Stephen Hoffman
Post by Greg Tinkler
As a follow on from my previous post
UDF
files you can sequentially get/put, but you cannot access using RFA.
This would be useful, yup there is no defined record but the buffer
size is all that is needed. 'record' locking is based on RFA so shared
access should not be a problem.
You're asking for what a stream file provides.
Noop.
At least not for stream files in RMS terms, accessed through RMS.
For access to stream files through RMS you cannot just specify a size.
RMS will hunt for terminators as per specific stream attribute.
Hein.
Correct. Attempting to lock some data of unknown size is rather interesting.
Which is why the starting address and the size would be needed for a lock. Or,
starting byte number and ending byte number.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-10-15 20:08:20 UTC
Permalink
Post by Hein RMS van den Heuvel
Post by Stephen Hoffman
You're asking for what a stream file provides.
Noop.
At least not for stream files in RMS terms, accessed through RMS.
For access to stream files through RMS you cannot just specify a size.
RMS will hunt for terminators as per specific stream attribute.
Through the C calls. Which are mostly-kinda-sorta successful at
expunging the punched-card abstraction that RMS so adores.
--
Pure Personal Opinion | HoffmanLabs LLC
Greg Tinkler
2021-10-16 03:01:44 UTC
Permalink
re $GET, sorry yup you are correct you can use $GET to get an arbitrary range of yes from a UDF file, but you cannot you $UPDATE.
%RMS-F-CUR, no current record (operation not preceded by $GET/$FIND), even if you do a $FIND or $GET before.
FYI $PUT is good to append to the file.

So I see this inconsistency as a bug...

re stream file, interesting thought stream/meme...
Originally the term was probably from using punched tapes, remember them. What we now focus on is addressable data, call it a record, or an object or a what ever but it is not stream. In fact even punched cards are more stream than record based, at least that is my memory of them.

Even the example given for SSIO was a block of bytes, i.e. a record, needing to be updated somewhere on a disk block(s). That is NOT stream access.
Post by Stephen Hoffman
SSIO seeks to avoid the latent file corruptions that arise with sharing
Yes, it is the CRTL implementation, not RMS. RMS has its limitations hence the wish list.

And to add the wish list,
A higher level lock API for RMS so we can change the file lock, record lock, block/buffer lock on the fly. Needs some documentation on the resource named used by RMS.
DCL support to read/write a byte range in a file, aka UDF files.
Add timeout to the PIPE driver, should have it anyway.
Remove <> as a directory limiter, unless quoted, so we can have pipeless pipes.
Add resource name spaces to System locks so RMS etc can have its own area, and not have to waste x bytes with a prefix to the resource name. NB the is space in the lock block to do this!
And can we please get VMS to be 64 based as the default before we need to make 128 bit based...
Sorry the last one is something I have argued with the VMS group for a long time, well a long time ago, pre-alpha release.
NB I do like the sign extended pointers...

All good thoughts and ideas.
gt
Craig A. Berry
2021-10-16 16:40:42 UTC
Permalink
Post by Greg Tinkler
Even the example given for SSIO was a block of bytes, i.e. a record,
needing to be updated somewhere on a disk block(s). That is NOT
stream access.
Oh yes it is. It's about updating a chunk with arbitrary beginning and
ending bytes anywhere in the data stream at run time. A record has
pre-determined beginning and ending bytes. Using a record-oriented
system for shared updates to arbitrary pieces of a data stream just
isn't going to go well, as has been exhaustively explained already.
Please give it up.
Stephen Hoffman
2021-10-16 17:38:52 UTC
Permalink
Post by Greg Tinkler
re $GET, sorry yup you are correct you can use $GET to get an arbitrary
range of yes from a UDF file, but you cannot you $UPDATE.
%RMS-F-CUR, no current record (operation not preceded by $GET/$FIND),
even if you do a $FIND or $GET before.
FYI $PUT is good to append to the file.
So I see this inconsistency as a bug...
re stream file, interesting thought stream/meme... Originally the term
was probably from using punched tapes, remember them. What we now
focus on is addressable data, call it a record, or an object or a what
ever but it is not stream. In fact even punched cards are more stream
than record based, at least that is my memory of them.
Even the example given for SSIO was a block of bytes, i.e. a record,
needing to be updated somewhere on a disk block(s). That is NOT stream
access.
You're not going to abstract a stream through a punched-card database
and back to a stream, and have a reasonable and workable solution.

No one would ever demand to have a stream of data routed through a
SQLite database and back to a stream of data.

But here we are.

The XQP, yes, that can and does get to play here, as the user data
managed by XQP is not tied to the punched-card constructs.

Want stream access? RMS isn't involved. At all. Best case, stream
access blocks new RMS access, and an RMS open blocks any stream access
attempts.
Post by Greg Tinkler
Post by Stephen Hoffman
SSIO seeks to avoid the latent file corruptions that arise with sharing
stream files within the current implementation of C and RMS:Yes, it is
the CRTL implementation, not RMS. RMS has its limitations hence the
wish list.
And to add the wish list,A higher level lock API for RMS so we can
change the file lock, record lock, block/buffer lock on the fly. Needs
some documentation on the resource named used by RMS.
Support for directly accessing RMS locking is unlikely.
Post by Greg Tinkler
DCL support to read/write a byte range in a file, aka UDF files.
The current DCL 32-bit integer limits gets you tiny files when
specifying byte addresses in files.

Yeah, somebody is going to suggest block and byte references. Fun times, that.

The lack of 64-bit support in DCL will also soon collide with the
64-bit LBN work underway at VSI, too.
Post by Greg Tinkler
Add timeout to the PIPE driver, should have it anyway.
I'd like COPY /SFTP and ilk, and the ability to open SSL/TLS-protected
connections akin to what DCL has had with DECnet for aeons. With that,
I care rather less about local pipes.
Post by Greg Tinkler
Remove <> as a directory limiter, unless quoted, so we can have pipeless pipes.
Angle brackets for directory delimiters isn't going away with the
prevalence of ODS-2 and ODS-5 file system. What an extension to those
or replacement file system might bring?
Post by Greg Tinkler
Add resource name spaces to System locks so RMS etc can have its own
area, and not have to waste x bytes with a prefix to the resource name.
NB the is space in the lock block to do this!
RMS internals are RMS internals.

Wasting a few bytes with a file or logical or resource name prefix is
traditional on OpenVMS, too; app-specific namespaces, not so much.
Post by Greg Tinkler
And can we please get VMS to be 64 based as the default before we need
to make 128 bit based...
OpenVMS has barely gotten to 64 bits, and not at all cleanly. Issues
involving the 65th (virtual or physical) addressing bit aren't even in
the realm of discussion for any mainstream operating systems.

Getting DCL to 64 bits would be nice, and "NuDCL", "DCL2", and
modifications to DCL have been discussed before. Wholesale replacement
is a whole lot easier. PowerShell, bash, and zsh have all been
suggested, as have some others.
Post by Greg Tinkler
Sorry the last one is something I have argued with the VMS group for a
long time, well a long time ago, pre-alpha release.
NB I do like the sign extended pointers...
By all appearances, VSI is understaffed for the port and related work,
and for what they have on their schedule after the V9.2-1 production
release. Not that adding staff at this juncture would likely
appreciably speed the release of the port.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-10-16 22:49:41 UTC
Permalink
Post by Stephen Hoffman
And to add the wish list,A higher level lock API for RMS so we can change the file lock, record lock, block/buffer lock on the fly. Needs some documentation on the resource named used by RMS.
Support for directly accessing RMS locking is unlikely.
Well, that's a no-brainer, because RMS DOES NOT HAVE ANY LOCKING!

RMS is a client using the services of the DLM to do locking. It is not part of RMS.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-10-17 19:58:00 UTC
Permalink
Post by Greg Tinkler
re $GET, sorry yup you are correct you can use $GET to get an arbitrary range of yes from a UDF file, but you cannot you $UPDATE.
%RMS-F-CUR, no current record (operation not preceded by $GET/$FIND), even if you do a $FIND or $GET before.
FYI $PUT is good to append to the file.
So I see this inconsistency as a bug...
re stream file, interesting thought stream/meme...
Originally the term was probably from using punched tapes, remember them. What we now focus on is addressable data, call it a record, or an object or a what ever but it is not stream. In fact even punched cards are more stream than record based, at least that is my memory of them.
Even the example given for SSIO was a block of bytes, i.e. a record, needing to be updated somewhere on a disk block(s). That is NOT stream access.
As Craig as already pointed out, that is not correct.

You are obviously one of those VMS people who are unwilling to
accept that the part of VMS they care about (RMS on your case)
is somehow limited to the usage models that were in use when
their part of VMS was designed.

You are coming across as no different to those out of touch people
who like to go around claiming that VMS is the most secure
operating system on the planet and utterly ignore any evidence
to the contrary.

Likewise, you are also utterly ignoring the evidence that RMS is
NOT the solution for the new SSIO requirements.

Times change and requirements change. RMS was designed in an
era when records were the unit of access. RMS can still be used
when records are the unit of access, but different requirements
outside of this require different solutions.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Greg Tinkler
2021-10-18 00:41:11 UTC
Permalink
<snip>
Post by Simon Clubley
Even the example given for SSIO was a block of bytes, i.e. a record, needing to be updated somewhere on a disk block(s). That is NOT stream access.
As Craig as already pointed out, that is not correct.
Look at "Open Source and UNIX portability" page 10 - 12, "Example victim program", "Block I/O: Lost update problem"
Post by Simon Clubley
You are obviously one of those VMS people who are unwilling to
accept that the part of VMS they care about (RMS on your case)
is somehow limited to the usage models that were in use when
their part of VMS was designed.
You are coming across as no different to those out of touch people
who like to go around claiming that VMS is the most secure
operating system on the planet and utterly ignore any evidence
to the contrary.
Please Simon, as I stated before we need to agree to disagree. And no I don't need to justify who I am any more than you do.
Post by Simon Clubley
Likewise, you are also utterly ignoring the evidence that RMS is
NOT the solution for the new SSIO requirements.
Strong words. Please see above.
Post by Simon Clubley
Times change and requirements change. RMS was designed in an
era when records were the unit of access. RMS can still be used
when records are the unit of access, but different requirements
outside of this require different solutions.
I agree RMS was designed a long time ago and needs updating. NB this is why DBMS/Rdb where created 40 years ago. Such a big loss when they were sold for niks. (10c on th $)
It is also probably why VSI wants to port PostgresSQL.

That said, what was also raised was the engineering issues VSI are having with SSIO, so my suggestion such as it is, that for a LOT less engineering effort RMS could be cleaned up solve the issues mentioned in the "Open Source and UNIX portability" document. With benefit to all RMS users.
NB The CRTL was also written decades ago so needs some clean up.

gt downunder
Vitaly Pustovetov
2021-10-18 10:47:34 UTC
Permalink
That said, what was also raised was the engineering issues VSI are having with SSIO, so my suggestion such as it is, that for a LOT less engineering effort RMS >could be cleaned up solve the issues mentioned in the "Open Source and UNIX portability" document. With benefit to all RMS users.
I don't know exactly why the decision was made not to fix the RMS, but to add SSIO to the XFC. But I guess it was due to the fact that RMS is very complex and written in Macro&BLISS. And XFC is simple and written in C.
Greg Tinkler
2021-10-19 05:26:35 UTC
Permalink
Post by Greg Tinkler
re $GET, sorry yup you are correct you can use $GET to get an arbitrary range of yes from a UDF file, but you cannot you $UPDATE.
%RMS-F-CUR, no current record (operation not preceded by $GET/$FIND), even if you do a $FIND or $GET before.
Hmm, $update just works for me - with the same size as the $get.
Tested on EISNER, AlphaServer DS20 500 MHz OpenVMS V8.4-2L2.
https://drive.google.com/file/d/1_5Vi1qRjh--4_HiuuTPJQ6KVE3v5O7rQ/view?usp=sharing
Hein.
Thanks for that Hein
It turns out $find() does not work, but $get() does. I can only assume because $get has a 'record length by way of the usz, whereas $find does not.

Anyway, as a result it really does raise the question as to way SSIO is needed when RMS clearly can do the job. Yes I have written the code, and done some testing, but was just a proof of concept. If I can do that in under 2 weeks...

PS sys$modify() got a pointer to some doco? Very useful.

gt
Greg Tinkler
2021-10-19 06:22:27 UTC
Permalink
I meant to add, effectively Hein's sample code solves the issue SSIO talked about, very nicely.

Another wish, get DCL to default to VAR not VFC files, or possibly STMLF. I'm sure 40years ago there was a good reason for VFC but now not so much.
NB this includes OPEN/WRITE x x.x and PIPE ... > x.x, possibly batch log files as well.

gt
Lawrence D’Oliveiro
2021-10-19 23:28:26 UTC
Permalink
Another wish, get DCL to default to VAR not VFC files, or possibly STMLF. I'm sure 40years
ago there was a good reason for VFC but now not so much.
The likely reason being this was the (only?) way to represent FORTRAN carriage control.
Arne Vajhøj
2021-10-19 23:50:34 UTC
Permalink
Post by Lawrence D’Oliveiro
Another wish, get DCL to default to VAR not VFC files, or possibly STMLF. I'm sure 40years
ago there was a good reason for VFC but now not so much.
The likely reason being this was the (only?) way to represent FORTRAN carriage control.
????

The question was about DCL not Fortran.

And Fortran carriage control is not RFM=VFC but RAT=FTN and actual
control in first data byte (and default for Fortran text files
is RFM=VAR).

Arne
Hein RMS van den Heuvel
2021-10-20 03:09:54 UTC
Permalink
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Another wish, get DCL to default to VAR not VFC files, or possibly STMLF. I'm sure 40years
ago there was a good reason for VFC but now not so much.
The likely reason being this was the (only?) way to represent FORTRAN carriage control.
????
The question was about DCL not Fortran.
And Fortran carriage control is not RFM=VFC but RAT=FTN and actual
control in first data byte (and default for Fortran text files
is RFM=VAR).
Arne
Arne, you got this one all wrong.
It is about DCL first and Fortran is secondary.
DCL's VFC is a superset. Cobol, Fortran and regular files are a subset.
The whole point is that DCL VFC output files can handle Fortran style output.
If you submit a batch job with in there DEFINE/USER FOR0xx SYS$OUTPUT before your RUN <FORTRAN_PROGRAM>
DCL/RMS will 'eat' the 1H' ' space or whatever and generate newlines - or not - as required.
And whether the next program in the log is Cobol or Basic it'll faithfully capture that output in the same VFC log.

Hein
Dave Froble
2021-10-20 03:17:30 UTC
Permalink
Post by Hein RMS van den Heuvel
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Another wish, get DCL to default to VAR not VFC files, or possibly STMLF. I'm sure 40years
ago there was a good reason for VFC but now not so much.
The likely reason being this was the (only?) way to represent FORTRAN carriage control.
????
The question was about DCL not Fortran.
And Fortran carriage control is not RFM=VFC but RAT=FTN and actual
control in first data byte (and default for Fortran text files
is RFM=VAR).
Arne
Arne, you got this one all wrong.
It is about DCL first and Fortran is secondary.
DCL's VFC is a superset. Cobol, Fortran and regular files are a subset.
The whole point is that DCL VFC output files can handle Fortran style output.
If you submit a batch job with in there DEFINE/USER FOR0xx SYS$OUTPUT before your RUN <FORTRAN_PROGRAM>
DCL/RMS will 'eat' the 1H' ' space or whatever and generate newlines - or not - as required.
And whether the next program in the log is Cobol or Basic it'll faithfully capture that output in the same VFC log.
Hein
Looking back, VAX/VMS was originally aimed at scientific computing and Fortran.

So things supporting that sure isn't a surprise.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-10-20 13:24:28 UTC
Permalink
Post by Hein RMS van den Heuvel
Post by Arne Vajhøj
Post by Lawrence D’Oliveiro
Another wish, get DCL to default to VAR not VFC files, or possibly STMLF. I'm sure 40years
ago there was a good reason for VFC but now not so much.
The likely reason being this was the (only?) way to represent FORTRAN carriage control.
????
The question was about DCL not Fortran.
And Fortran carriage control is not RFM=VFC but RAT=FTN and actual
control in first data byte (and default for Fortran text files
is RFM=VAR).
Arne, you got this one all wrong.
That happens.
Post by Hein RMS van den Heuvel
It is about DCL first and Fortran is secondary.
That was what I started noting.

The question was about DCL switching from RFM=VFC to RFM=VAR.

And I saw that as a DCL question not a Fortran question.

Especially since Fortran by default use RFM=VAR. And the Fortran
magic is in RAT not RFM.
Post by Hein RMS van den Heuvel
DCL's VFC is a superset. Cobol, Fortran and regular files are a subset.
Not sure what that really means.

Fortran by default use VAR.
Post by Hein RMS van den Heuvel
The whole point is that DCL VFC output files can handle Fortran style output.
If you submit a batch job with in there DEFINE/USER FOR0xx SYS$OUTPUT before your RUN <FORTRAN_PROGRAM>
DCL/RMS will 'eat' the 1H' ' space or whatever and generate newlines - or not - as required.
Interesting - I did not know that.

But would that feature break if the log file was VAR instead of VFC?

Arne

V***@SendSpamHere.ORG
2021-10-19 11:52:06 UTC
Permalink
Post by Greg Tinkler
Post by Greg Tinkler
re $GET, sorry yup you are correct you can use $GET to get an arbitrary range of yes from a UDF file, but you cannot you $UPDATE.
%RMS-F-CUR, no current record (operation not preceded by $GET/$FIND), even if you do a $FIND or $GET before.
Hmm, $update just works for me - with the same size as the $get.
Tested on EISNER, AlphaServer DS20 500 MHz OpenVMS V8.4-2L2.
https://drive.google.com/file/d/1_5Vi1qRjh--4_HiuuTPJQ6KVE3v5O7rQ/view?usp=sharing
Hein.
Thanks for that Hein
It turns out $find() does not work, but $get() does. I can only assume because $get has a 'record length by way of the usz, whereas $find does not.
Anyway, as a result it really does raise the question as to way SSIO is needed when RMS clearly can do the job. Yes I have written the code, and done some testing, but was just a proof of concept. If I can do that in under 2 weeks...
PS sys$modify() got a pointer to some doco? Very useful.
I thought that $MODIFY had been documented in the past. I just pulled the V4
RMS manual and it's not in there. Perhaps, it was V3 but those are packed in
boxes in storage. Regardless, about the only place you may find the $MODIFY
documented today would be in the source listings. There are only a handful of
things $MODIFY can do and you can find their codes in $RMEDEF. Modifying the
record format, as Hein has in his example, is one such function of $MODIFY.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
Hein RMS van den Heuvel
2021-10-19 13:52:55 UTC
Permalink
PS sys$modify() got a pointer to some doco? Very useful.
Not that I know. There are not many options.
As Brian indicates - RMEDEF is about all you need.

The only known usage in the system that I am aware of is in the linker/debugger image area.
The image itself in the exe file is 512 bytes fixed length - no length word, no round up.
The debugger symbol table is like an object file - variable length - inside the same image.
It's my understanding SYS$MODIFY is used to make the switch.
Post by Greg Tinkler
Another wish, get DCL to default to VAR not VFC files,
Yeah, not big fan of VFC myself. supposedly they are a superset of of the all the RAT functionality.
I think it was mostly done to support COBOL constructs like 'AFTER ADVANCING x LINES' in a device independent fashion. Fortran also perhaps.
Anyway, I skip OPEN/WRITE and use CREATE/FDL="NL:" xxx.dat + OPEN/APPEN xxx xxx.dat
That way I can optionally control allocation, extent and the likes.
Examples:
$ cre/fdl="record; form stream_lf"
$ cre/fdl="file; alloc 1234; record; form stream_lf" tmp.tmp
Btw... FDL as a string instead of file was one to fun things I decided to do while at RMS engineering back in the early 90's - (yikes, that's 30 years ago now!) - like it?

Hein
Chris Townley
2021-10-19 14:01:50 UTC
Permalink
On 19/10/2021 14:52, Hein RMS van den Heuvel wrote:
<snip>
Post by Hein RMS van den Heuvel
$ cre/fdl="record; form stream_lf"
$ cre/fdl="file; alloc 1234; record; form stream_lf" tmp.tmp
Btw... FDL as a string instead of file was one to fun things I decided to do while at RMS engineering back in the early 90's - (yikes, that's 30 years ago now!) - like it?
Hein
I wish I had known that! I used to create an FDL first, then create from
that and delete the FDL, although I did have a few standard FDLs around
that I could use.
--
Chris
hb
2021-10-19 15:06:26 UTC
Permalink
Post by Hein RMS van den Heuvel
The only known usage in the system that I am aware of is in the linker/debugger image area.
The image itself in the exe file is 512 bytes fixed length - no length word, no round up.
The debugger symbol table is like an object file - variable length - inside the same image.
It's my understanding SYS$MODIFY is used to make the switch.
VAX and Alpha.
David Jones
2021-10-19 17:08:29 UTC
Permalink
Post by hb
Post by Hein RMS van den Heuvel
The only known usage in the system that I am aware of is in the linker/debugger image area.
The image itself in the exe file is 512 bytes fixed length - no length word, no round up.
The debugger symbol table is like an object file - variable length - inside the same image.
It's my understanding SYS$MODIFY is used to make the switch.
VAX and Alpha.
Here's an excerpt from RMS0MODFY.MAR's comments:

; Implicit Inputs:
;
; The contents of the fab and possible related user interface
; blocks.
; The esc bit is set in fop indicating that the caller desires
; to execute one of the 'escape sequences', otherwise known as
; 'back doors' or 'kludges', that is, ways of tricking rms into
; thinking that the situation is other than rms's current view of it.
; These will, hopefully, remain few in number. Implementing these
; as a service is necessary due to the requirement for exec mode
; privileges and additionally gives us a handle on the extent of the
; cancer. Improper use of an escape sequence can blow rms out of the
; water.
Dave Froble
2021-10-15 19:21:20 UTC
Permalink
RMS only locks the RFA (the first byte so to speak) and will NOT do byte-range locking which would be desirable for full shared UDF support.
I never considered this. I guess it makes sense, since RMS knows about the records in
a file, so locking the first byte would (inside RMS) then lock the entire record.

Even today I learn something I didn't previously know.

:-)

My DAS database locks blocks, by using the block number, so I guess it's the same thing.
Just never looked at how RMS does locking.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Loading...