[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

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

2223.0. "OA$USER_QM and group services" by BERN02::MUELLERS (Stefan A. M�ller DTN 761-4864) Sun Feb 07 1993 09:09

    Hi,
    
    Preparing a course I came accross the nice feature allowing users to
    perform queue management which has another nice feature: it supports
    groups.
    
    I played around a little bit and found a behaviour I find it's worth to
    write a note about.
    
    First, I authorized a user to manage all queues. Because groups are
    supported I called the menu for maintaining groups and added a few
    members. This approach is easier than selection a user enter ASQ, enter
    the queue name, evtually press GOLD M and a least AMQ. All added members 
    have received the group identifier but - and that's the problem - they 
    did not receive OA$USER_QM.
    
    The same happens if one deletes a MNQ$.... group from the group
    services menu with the difference that all identifers belonging to
    group will be removed from the UAF entry but the OA$USER_QM remains.
    And I suppose the only way to remove it - if you'll ever be aware of the
    existing of OA$USER_QM on an account you won't have it - is to do it 
    by hand.
    
    I just want to ask if it should really work this way round or if it is 
    something like an error in design.
    
    
    Stefan

T.R Title User Personal
Name Date Lines

2223.1 GS access was intended... IOSG::TYLDESLEY Mon Feb 08 1993 10:39 39

T.R	Title	User	Personal Name	Date	Lines
2223.1	GS access was intended...	IOSG::TYLDESLEY		`Mon Feb 08 1993 10:39`	39
	Hello Stefan, From the outset I designed QMA, not so much to support groups, more to be based upon them. QMA was a way of authorizing users in ALL-IN-1, and I wanted to be able to do it to groups rather than single users (reduced number of identifiers, easier maintenance, etc.) A consequence of this was that queue management groups are normal groups in that you can view and (providing you are the group controller) you can manipulate them from Group Services in the normal way. This is OK, I believe, because people can view them from there if they want. The benefit I got from this was that all the identifier granting and maintenance was done by GS, and I didn't have to re-invent it. Remember also, that what you are doing, would not be possible by an unprivileged user - only the Manager can create MNG$ groups (OA$_G idents) - this is prevented in the groups code. So, we are left with the problem of the OA$USER_QM identifier. Well, you are right here, that this is a bit untidy, that it is left lying around, IF you are Manager, and IF you delete the group from Group Services rather than from QMA. We should perhaps try to do something about that, and indeed we have been thinking about ways of tidying up/maintaining identifiers in general (V3.0 makes much more use of them). But, a bit of history here. At first we intended the queue administrator simply to be a special form of administrator. The QMA forms were going to be put in OA$LIB:ADMIN. But since being an admin brought a lot of other (unnecessary) stuff with it, OA$USER_QM was introduced fairly late on, to give otherwise unprivileged users access to the queue management forms, which are in the special form library OA$LIB:UQM. I don't believe that it gives users any other special privs, so the consequences of leaving it on the account are not that great. One last small point from your note; you say about using GOLD M and then AMQ. AMQ can be typed direct from the index, as you probably know. Thanks for your interest. Regards DaveT

  Hello Stefan,

  From the outset I designed QMA, not so much to support groups, more to 
  be based upon them. QMA was a way of authorizing users in ALL-IN-1, and 
  I wanted to be able to do it to groups rather than single users (reduced 
  number of identifiers, easier maintenance, etc.) A consequence of this was 
  that queue management groups are normal groups in that you can view and 
  (providing you are the group controller) you can manipulate them from 
  Group Services in the normal way. This is OK, I believe, because people 
  can view them from there if they want. The benefit I got from this was 
  that all the identifier granting and maintenance was done by GS, and I 
  didn't have to re-invent it.
  
  Remember also, that what you are doing, would not be possible by an 
  unprivileged user - only the Manager can create MNG$ groups (OA$_G idents)
  - this is prevented in the groups code.

  So, we are left with the problem of the OA$USER_QM identifier. Well, you 
  are right here, that this is a bit untidy, that it is left lying around, 
  IF you are Manager, and IF you delete the group from Group Services rather 
  than from QMA. We should perhaps try to do something about that, and indeed
  we have been thinking about ways of tidying up/maintaining identifiers in
  general (V3.0 makes much more use of them).

  But, a bit of history here. At first we intended the queue administrator 
  simply to be a special form of administrator. The QMA forms were going to
  be put in OA$LIB:ADMIN. But since being an admin brought a lot of other 
  (unnecessary) stuff with it, OA$USER_QM was introduced fairly late on, to 
  give otherwise unprivileged users access to the queue management forms,
  which are in the special form library OA$LIB:UQM. I don't believe that it 
  gives users any other special privs, so the consequences of leaving it on
  the account are not that great.

  One last small point from your note; you say about using GOLD M and then
  AMQ. AMQ can be typed direct from the index, as you probably know.

  Thanks for your interest.
  Regards
  DaveT