topic Re: Can't find description for RMS$_ACC in Operating System - OpenVMS

Can't find description for RMS$_ACC

Dmitriy_21 — Thu, 13 Jan 2022 09:32:21 GMT

Hello

I am getting status code 114690 when calling sys$open, which seems to correspond to RMS$_ACC.

I can't find any information on this message.

Anyone can point where I learn more about this error?

All documentation I have has no reference of this error.

Thanks

Re: Can't find description for RMS$_ACC

Steven Schweda — Thu, 13 Jan 2022 05:50:15 GMT

> I am getting status code 114690 when calling sys$open, which seems to
> correspond to RMS$_ACC.

VMS version, architecture? Around here:

ITS $ tcpip show vers

HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5
on an HP rx2600 (1.50GHz/6.0MB) running OpenVMS V8.4-2L3

ITS $ exit 114690
%RMS-E-ACC, ACP file access failed
-NONAME-W-NOMSG, Message number 00000000

ITS $ help /mess %RMS-E-ACC
[...]
ACC, ACP file access failed

Facility: RMS, OpenVMS Record Management Services

Explanation: An error occurred during an attempt to open a file. This
message is associated with a status code returned from a file
system ACP QIO request made by the RMS file system.

User Action: The status value (STV) field of the FAB contains a system
status code that provides more information about the
condition. Take action based on this status code.

Looks to me like a general access/open failure. Have you looked at
the fab$l_stv in the FAB after this operation?

Re: Can't find description for RMS$_ACC

Steven Schweda — Fri, 14 Jan 2022 23:42:23 GMT

Barely relevant but possibly interesting?:

After I read the help text which suggested looking at fab$l_stv to
get an I/O status value, I looked at some old UnZip code to see if/how
we were using it. It all made sense -- many places where sys$whatever()
returned a bad status, and then the relevant fab$l_stv was used to add
information to the error message. And then I noticed this statement
(in [.vms]vms.c:check_for_newer()), unchanged for decades:

sys$dassgn(fab.fab$l_stv);

which made very little sense to me.

After too much reading, I discovered that $OPEN with
fab$v_ufo/FAB$M_UFO set (as it was here) does not set fab$w_ifi, but
does return the I/O channel in fab$l_stv (not a completion status value
in the usual sense).

So, that apparent nonsense code actually did make sense. Of course,
it was followed immediately by this:

sys$close(&fab); /* be sure file is closed and RMS knows about it */

If anyone had ever checked the status from that, he might have
noticed what I did:

ITS $ exit %x00018564
%RMS-F-IFI, invalid internal file identifier (IFI) value

When I think of all the nanoseconds that were wasted over all those
years...

Moral: Sometimes it can pay (at least a little) to check the status
of a function which can't possibly fail. If nothing else, it can be
educational.

Re: Can't find description for RMS$_ACC

Hein_vdHeuvel_d — Sat, 15 Jan 2022 15:36:30 GMT

Good story Steve.. Indeed all those nanoseconds wasted and not to foget the 50 bytes of wasted program code all over the world.

Indeed, after a SUCCESFUL open with UFO set the STV will have a channel, not a lower level status.

There will be NO RMS structures created. As per RMS ref manual: "If you set the
FAB$V_UFO option with the Open or Create service, the channel needs only to
be deassigned when you finish with the file."

grins,

Hein.

Re: Can't find description for RMS$_ACC

Dmitriy_21 — Wed, 19 Jan 2022 18:09:24 GMT

Steven,

I follow your advice to get the value of the STV when an error is reported.

The result is:

l_sts=0x1c002, l_stv=0x820

If I correctly identify the 0x820 code, it is SS$_BADFILEVER. And since I don't have access to the system where the error was reported, I assume the specific version of the file was purged/rotated and will try to confirm this.

Thank you for your help.

Dmitriy

Re: Can't find description for RMS$_ACC

Steven Schweda — Wed, 19 Jan 2022 18:45:59 GMT

> [...] I assume the specific version of the file was purged/rotated and
> will try to confirm this.

SS$_BADFILEVER does not mean that you specified a version which does
not exist; it means that you specified (explicitly or implicitly) a
version which is not legal. Again, HELP /MESSAGE is your friend:

$ help /mess /faci = SYSTEM BADFILEVER

BADFILEVER, bad file version number

Facility: SYSTEM, System Services

Explanation: The file version number in a file specification is greater
than 32767 or contains nonnumeric characters. Or, the file
system may have attempted to create a file with a version
higher than 32767 through defaulting rules.

User Action: Check for a programming error. Verify that existing file
versions are less than 32767. Rename if necessary.

> [...] since I don't have access to the system where the error was
> reported, [...]

The program which reported the error could/should also report what it
was doing (that is, the file spec given to sys$open()) when it got the
error status(es). Perhaps it tried to open "fred.dat;50000" or
"fred.dat;xyz". Perhaps it tried to open+create "fred.dat" when
"fred.dat;32767" already existed. (Which would not be unusual.)

Re: Can't find description for RMS$_ACC

Hein_vdHeuvel_d — Wed, 19 Jan 2022 19:30:52 GMT

>> If I correctly identify the 0x820 code, it is SS$_BADFILEVER.

Correct.

>> And since I don't have access to the system where the error was reported

That's pretty lame.

>> I assume the specific version of the file was purged/rotated and will try to confirm this.

Why would you assume that? Don't you think the system would have returned FNF = File not found if the file could not be found.

Using $ EXIT %x820, as shown earlier indicates " BADFILEVER, bad file version number"

That's what it means. The program provided a bad file version ( > 32767 ? or a piece of string instead of a number?)

For further help consider using HELP /MESS BADFILEVER as earlier indicated.

hth,

Hein