At 12:16 AM 3/11/00 -0500, Dan Sugalski wrote:
>At 09:39 PM 3/10/00 -0700, Eric F. Richards wrote:
>>(Pardon the delayed comments... I'm several thousand (!) emails behind
>>at the moment.)
>>
>>I finally can delurk and contribute, sort of!
>>
[...]
>>
>>Not necessary in both cases. Use SYS$READ and SYS$WRITE for block I/O
>>with the BIO (block I/O) or BRO (block and record I/O) options set in
>>the RAB. No privs needed, but you get raw disk blocks, no interpretation.
>>
>>To disable locking, play with the various flags UPI (user provided
interlock),
>>RRL (read regardless of lock), NLK (no locking) options. Naturally, my
>>manuals are in the inconviently powered-down office, and my memory is lost
>>somewhere with my youth, so you'll have to dig on these further (or ask
>>me to do so) for more specific info.
>
>Hmmm. That could be useful for stream files at least. We'd need to rewrite
>the C stdio library or provide a VMS::QIO module. (Which would, in itself,
>be nifty)
>
You could also _probably_ -- again, going from memory -- set these
in "fop=...", "rop=..." options in C open() and fopen() clauses. Also,
IIRC, using "ctx=stm" will force C read() and write() (and presumably
fread() and fwrite()) to do "block I/O" that bypasses RMS interpretation
on non-stream files.
I think I was wrong above -- BIO and BRO are FAB, not RAB options, as is
UPI. RRL is a RAB option and I think NLK is as well. Each has their
place, of course, with different ramifications...
As for a QIO interface, yep, it'd be kinda neat, but unless you _like_
doing IO$_ACPCONTROL calls, extending a file can be almost as much fun
as golf or even hitting yourself on the head with a rubber mallet.
Readonly files or files with known max size at open don't have that
problem, though.
Eric
--
Eric F. Richards
[EMAIL PROTECTED]
"The weird part is that I can feel productive even when I'm doomed."
- Dilbert
