DALOCK & 7.10.G1

[Hamilton, Allison]

I will look at the documentation and compare it with the code this weekend,
and send you an updated version, hopefully next week.  I think you mentioned
that you had been talking with Customer Support about this.  It would be
extremely helpful if you would ask them to log a bug against your call so
that I can keep track of the problem and resolution.Thanks!

I once knew why the SYSLCK was there, but it's been so long...  It may have
to do with sharing screen global sections across the system for QUICK.  But
that doesn't explain QTP, so that probably isn't it.

Allison Hamilton

> ----------
> From: 	Chris Sharman[SMTP:Chris.Sharman@ccagroup.co.uk]
> Sent: 	Thursday, October 22, 1998 10:02 AM
> To: 	Allison.Hamilton@cognos.com
> Cc: 	Chris.Sharman@ccagroup.co.uk; powerh-l@lists.swau.edu
> Subject: 	RE: DALOCK & 7.10.G1
> 
> >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.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.