| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
Hi,
I have a customer who is having a problem with the FILE$ dsab.
He is getting an access violation when he runs a script with the following
lines of code in it. He gets the access violation from privileged and
non-privileged accounts.
get #file = "USER103:[A1SHRCAB.SF_A1]ACCESS.DAT"
.if file$.acl[#file] eqs "" then -
.GOTO continue
If he uses the OA$MSG_TRAP function before running the script he gets the
following error:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=7FE7c200,
PC=00347AFC, PSL=0BC00004
%OA-W-INVGET, Symbol "file$.acl[#file]" not found
He has told us that using other FILE$ fields works fine such as:
file$.create_date[#file]
file$.modify_date[#file]
file$.protection[#file]
file$.uic[#file]
We were not able to recreate it on any of our V3.0 systems but we were able to
dial in and found that the file (USER103:[A1SHRCAB.SF_A1]ACCESS.DAT) had
87 ACLs on it. He tried it on another file that had one ACL and that worked
fine, no access violation.
So now we think that 87 ACLs might have a lot to do with the problem but can't
say for sure.
Does anyone know if having that many ACLs on a file will cause the Access
Violation when using file$.acl[#file]? We put 37 ACLs on a file but still
couldn't recreate the problem. Is there a limit for ACLs?
Thank you for your help.
Kathy
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2924.1 | Working . . . | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Fri Jun 25 1993 18:43 | 7 |
There was a VMS bug with ACLs, such that it gave us the ACLs back in
bigger (or smaller!) blocks than we put them on. This was fixed in
ACL$ and the ACL function, perhaps we forgot in FILE$.
I'll ask someone to look at this.
Graham
| |||||
| 2924.2 | Tried ACL$ ? | HERO::MORPH::Benoy | Smoke me a kipper I'll be back for breakfast | Mon Jun 28 1993 14:56 | 9 |
RE .0 Have you tried reading this file using ACL$, if you get a similar result I would imagine that there might be a problem with VMS. FILE$ uses the $format_acl system service to process the data and anything that ends up as longer than 512 bytes is lost off the end of the buffer and not returned. -Paul | |||||
| 2924.3 | FILE$ or VMS? | AIMTEC::BUTLER_T | Mon Jun 28 1993 17:04 | 6 | |
Re: .1,.2
Thanks! As soon as I can get into the customers system I will check
VMS and FILE$ to see which is in error.
Tim (subbing for Kathy)
| |||||
| 2924.4 | Investigations reveal... | IOSG::CHINNICK | gone walkabout | Mon Jul 19 1993 13:05 | 13 |
I now have an SPR on this problem and just for completeness, here
are the findings:
The FILE$ data-set has a bug in it where the file ACL is more then 512
bytes. It can cause ACCVIO's or just return garbage. An ACL length of
512 bytes equates to a maximum of 39 ACE's. In certain rare cases, you
might find that it works but returns only a portion of the ACL.
The ACL$ data-set uses different code and logic and does not suffer
from the problem. Therefore I recommend ACL$ as a workaround.
Paul.
| |||||