Conference iosg::all-in-1_v30

4036.0. "CHECK_ACCESS for shared drawer exits user from A1" by ZUR01::KURTH (Peter Kurth @RLE, R�mlang (Switzerland)) Thu Mar 31 1994 15:03

	Hello

	OpenVMS V5.5-1
	ALL-IN-1 IOS Server for VMS V3.0A (MUPA) BL61A 16-Dec-1993 (no TLC)

	User enters WP and is exited from ALL-IN-1 immediatelly. It turned
	out, that the user had selected a shared drawer. In summary, on
	every shared drawer, some operations do not work. This happens
	from a normal user and also from the ALL-IN-1 Manager.

	The problem can be located around the function CHECK_ACCESS (e.g. in
	MGT MFC MD R):

	CHECK_ACCESS , #fc_access_file, "C", #fc_permission

	When executing this function, the user is immediatelly exited from
	ALL-IN-1. The trace shows:
![FUNC]   Function = CHECK_ACCESS, Cmd line = , #fc_access_file, "C", #fc_permis
!               sion
![SYMBOL] Symbol = , Value =
![SYMBOL] Symbol = #fc_access_file, Value = DISK2:[ABLAGE.ALLIN1]access.dat
![SYMBOL] Symbol = "C", Value = C

	A certain amount of users is connected to the FC (appr. 20 users)
	and can work in shared drawers. Users, which are new logged in,
	are not able to access shared drawers. It seems, that a certain
	limit has been reached.

	The server has been tuned:
	  "OAFC$SERVER_ASTLM" = "1104"
	  "OAFC$SERVER_BIOLM" = "336"
	  "OAFC$SERVER_BYTLM" = "552000"
	  "OAFC$SERVER_DIOLM" = "336"
	  "OAFC$SERVER_ENQLM" = "4196"
	  "OAFC$SERVER_FILLM" = "1104"
	  "OAFC$SERVER_PGFLQUOTA" = "66000"
	  "OAFC$SERVER_WSEXTENT" = "6096"
	  "OAFC$SERVER_WSQUOTA" = "2128"

	OAFC$SERVER.LOG and OAFC$SERVER_ERROR.LOG doesn't show any error.
	OA$DATA_SHARE:NU01$SERVER73_TRACE.DAT also has no errors.

	Stopping and starting the FCS does not cure the problem. After a 
	reboot, the problem is gone for a while, but happens again.

	Any ideas?

	Thanks and regards, Peter

	I escalated this problem to Munich, but currently no brilliant ideas
	exist what the solution could be. Unfortuntally, I cannot reproduce
	the problem at the moment.

	Just one more little question:

	Does the function CHECK_ACCESS involve the File Cabinet Server? 
	Will a session be created? (so is this really a FCS problem?)

	Regards, Peter

    Hi,
    
    No - CHECK_ACCESS does not invoke the File Cabinet Server. What is does
    is get the ACL from the file, DISK2:[ABLAGE.ALLIN1]access.dat in your
    case, and then calls the $CHKPRO system service to see if the user
    has the requested access. 
    
    I've no idea why it failed. Try doing a $dir/sec from VMS to see if
    that shows any errors.
    
    Cheers
    
    Stuart