From Newsgroup: comp.os.vms

I'm an operator for a public access OpenVMS V7.3 system running on a
VAXstation 4000-60.

After a recent reboot, the executable for our local bulletin board
system (Owner: SYSTEM, Protection: System:RWED, Owner:RWED, Group:RE,
World:RE) started giving terminating with the error "%RMS-E-PRV,
insufficient privilge or file protection violation" after calling
sys$create to open one of two files: the first is owned by SYSTEM with protection the same as the executable, the second owned by the user
running the program with protection System:RWED, Owner:RWED, Group:RE, World:(none).

The program worked without error before the reboot. What kind of things
might cause a problem like this to suddenly appear?
--
David Meyer
Takarazuka, Japan
papa@sdf.org
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <877bnuvpcb.fsf@localhost>, David Meyer <papa@sdf.org> wrote:

I'm an operator for a public access OpenVMS V7.3 system running on a >VAXstation 4000-60.

After a recent reboot, the executable for our local bulletin board
system (Owner: SYSTEM, Protection: System:RWED, Owner:RWED, Group:RE, >World:RE) started giving terminating with the error "%RMS-E-PRV,
insufficient privilge or file protection violation" after calling
sys$create to open one of two files: the first is owned by SYSTEM with >protection the same as the executable, the second owned by the user
running the program with protection System:RWED, Owner:RWED, Group:RE, >World:(none).

The program worked without error before the reboot. What kind of things
might cause a problem like this to suddenly appear?

Hmm, what are the protections on the containing directory?

`SYS$CREATE` creates or opens a file, but that will also create
a new version of the file (e.g., `foo.dat;n+1`).

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 19/06/2026 10:19 pm, Dan Cross wrote:

In article <877bnuvpcb.fsf@localhost>, David Meyer <papa@sdf.org> wrote:

I'm an operator for a public access OpenVMS V7.3 system running on a
VAXstation 4000-60.

After a recent reboot, the executable for our local bulletin board
system (Owner: SYSTEM, Protection: System:RWED, Owner:RWED, Group:RE,
World:RE) started giving terminating with the error "%RMS-E-PRV,
insufficient privilge or file protection violation" after calling
sys$create to open one of two files: the first is owned by SYSTEM with
protection the same as the executable, the second owned by the user
running the program with protection System:RWED, Owner:RWED, Group:RE,
World:(none).

The program worked without error before the reboot. What kind of things
might cause a problem like this to suddenly appear?

Hmm, what are the protections on the containing directory?

`SYS$CREATE` creates or opens a file, but that will also create
a new version of the file (e.g., `foo.dat;n+1`).

- Dan C.

Perhaps the VMS file version limit has been reached?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-06-19 09:42:12 +0000, David Meyer said:

What kind of things might cause a problem like this to suddenly appear?

Enable file access failures in security auditing, and see which file is failing and why.

Use SET AUDIT/ENABLE=(stuff) to enable either privilege failures, /DISABLE=(stuff) to shut it off after testing, and then ANALYZE/AUDIT/SINCE=JustBeforeNOPRIV to see what gers logged.

Details are in the OpenVMS docs.

Alternatively, the sneaky way is to borrow the undocumented XQP
debugging, though this uses CMEXEC or CMKRNL. SET WATCH is issued prior
to starting the executable, and the XQP activity will be shown,
including the filenames and the (hexadecimal) error codes.

Borrowing some text written long ago by a very silly, silly person:

{{{
The undocumented and unsupported command SET WATCH/CLASS=ALL FILE -- which
also requires CMKRNL or CMEXEC privilege -- is the most common approach.
Use the command SET WATCH/CLASS=NONE FILE to turn the (copious) XQP output
off.

Available SET WATCH /CLASS keywords can include the following:
ALL, NONE, MAJOR_FUNCTION, CONTROL_FUNCTION, ATTRIBUTES,
DIRECTORY_OPERATIONS, DUMP, QUOTA_OPERATIONS and PROTECTION.
}}}


Here, probably SET WATCH /CLASS=MAJOR FILE to enable, and after the app
fails use the qualifier /CLASS=NONE to disable.

And FILE here is a keyword FILE, not a filename. Literally the four
characters FILE.

Output from SET WATCH is chatty, and it'll be chatty for everything
until SET WATCH /CLASS=NONE FILE is involved.

And for completeness, make sure the file version isn't ;32767. Because
if it is, a new-version create will fail because of the version limit.
--
Pure Personal Opinion | HoffmanLabs LLC

--- Synchronet 3.22a-Linux NewsLink 1.2