DALOCK & 7.10.G1

[Hamilton, Allison]

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. 

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.  

Allison Hamilton
P.S. ...
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???


> ----------
> From: 	Chris Sharman[SMTP:Chris.Sharman@ccagroup.co.uk]
> Sent: 	Thursday, October 22, 1998 5:07 AM
> To: 	"draco::chris"@ccagroup.co.uk
> Cc: 	Allison.Hamilton@cognos.com; Liz.Latimer@cognos.com;
> Chris.Sharman@ccagroup.co.uk; powerh-l@lists.swau.edu
> Subject: 	RE: DALOCK & 7.10.G1
> 
> >I *do* have problems with the 7.10.G1 version of DALOCK - so much so that
> I've
> >started linking using 7.10.F3 again - no word from telesupport yet.
> >DA_INIT_LOCK appears to corrupt data after the ph_lck structure in memory
> >(documented at 62 bytes). There's also no lock id, and the name appears
> to be
> >displaced down the structure. I'm not sure whether it's a
> compilation/linking
> >problem or what.
> 
> Thanks to Allison Hamilton: no problems this morning after I expanded the
> ph_lck
> structure as she suggested (to 68 bytes).
> 
> Is this expansion accidental, or is there a new structure to be documented
> ?
> Examination via the debugger showed me a lock status of %rms-s-ok_dup, no
> lock
> id, and ss$_normal return status.
> 
> >Quick & QTP are installed with SYSLCK priv - I always assumed so that
> they
> >could synchronise clusterwide. But no: the locks they take out are
> ordinary UIC
> >group-specific locks, so there's no synchronisation across UIC groups,
> which I
> >find rather disturbing.
> 
> I'm still concerned about the whole synchronisation issue though: Quick
> definitely takes group locks, so it can't be doing system-wide
> synchronisation.
> 
> It really ought to be doing system-wide locking, or (better) using
> $set_resource_domain to use a UIC-independent domain without requiring
> privilege.
> 
> DALOCK should too, which would mean calling it with appropriate
> privileges.
> I'd be unwilling to give SYSLCK to all users, or installing all the
> calling
> applications, which would mean wrapping it up in a privileged shareable
> image
> and calling the routines (at least da_init_lock) from exec mode: would
> that be
> possible ?
> ______________________________________________________________________
> 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.