Can't find description for RMS$_ACC

[Dmitriy_21]

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

[Steven Schweda · Accepted solution]

> 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?

[Steven Schweda]

   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.

[Hein_vdHeuvel_d]

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.

[Dmitriy_21]

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 

[Steven Schweda]

> [...] 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.)

[Hein_vdHeuvel_d]

>> 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