DALOCK & 7.10.G1

[Chris Sharman]

>Chris, I'd have to look into the code history and documentation, but I
>suspect it was just an error, since the structure hasn't been changed in 6
>years.  We just upgraded to a new version of the C compiler, and it seems to
>be extremely less forgiving than the older ones about a variety of sizing
>problems. 

Fair enough: I'd appreciate a doc fix or a code fix sometime - currently the
field offsets are somewhat nebulous - clearly they're not what they were.

>I think DALOCK was written before resource-driven access was common, if
>available, and it would have used GROUPs as the general application
>boundaries.  Upgrading to ACL-based locking (which I think is what your are
>asking for?) would involve investigation as to how much work would be
>required, and would be an enhancement request.  

Yes, $set_resource_domain is relatively recent.
I'm still mystified by the requirement/use of SYSLCK priv though, and disturbed
by the notion that all this Powerhouse synchronisation is so much baloney if
your users are partitioned into several groups: what is the locking supposed to
do ?

$set_resource_domain allows you to specify a domain for use with $enq[w].
Fettling the security on that domain would be outside the purview of
Powerhouse, although I suppose the appropriate "$ set security..." command
could be issued at installation (although a lock would have to exist first).
Perhaps the [COGNOS] UIC group could be used ?
The difference would be that system locks require SYSLCK privilege, whereas
access to group domains would be controllable via ACLs etc, removing the need
for privilege.

I guess the inevitable answer is that it isn't particularly broken (although I
suspect a test would prove there is no synchronisation across groups).

>Just out of curiosity --- for all those lurking on this list who are VMS
>users -- how many of you are using ACL-based access for disc resources
>and/or privilege access with your PowerHouse applications???

Yes, to a limited extent.
I'd like to be able to set up a screen so that some users can maintain a file,
and others can just view, lookup, etc: presently if I want to do this in Quick
I have to give everyone write access to the file at the DCL level.
Alternatively I can install Quick with SYSPRV, and have it subvert VMS security
with its own, which I'm not really comfortable with.
I'd prefer it to honour VMS security, and if it finds a user has only read
access, then the screen should work, but prevent use of the ACCEPT verb.
Maybe it could allow use of SUBSYSTEM security so that I can allow Fred to read
and write a file, but only from Powerhouse: that's similar to the SYSPRV option
currently implemented, but more trustworthy & familiar to the average VMS
system manager.

______________________________________________________________________
Chris Sharman			Chris.Sharman@CCAgroup.co.uk
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.