Conference iosg::all-in-1_v30

    Hi,
    
    I'm at DECUS on a slow line and don't have the books, but I vaguely
    remember the enabled/disabled flgag is a PARTITION field.
    
    
    Try <get partition.disabled["[username]MAIN"]
    
    
    I'm sorry but I'm not exactly sure of the field name. When you have it,
    you can use WRITE CHANGE PARTITION etc. to enable the drawer. 
    
    Can other users access the drawer OK? If so then the above is not the
    problem.
    
    Cheers
    
    STuart

Re: .1, Stuart

>    Try <get partition.disabled["[username]MAIN"]

  I will try so when I get to the customer system again, but isn't that
  what a MGT MFC MD ENA checks first? It says "Drawer is already
  enabled"

>    Can other users access the drawer OK? If so then the above is not the
>    problem.

  Yup, the drawer is common to all users, and so far I've only heard
  of this one user having the problem. Starting TeamLinks for a
  different user (or ALL-IN-1 NEWDIR to another user) gives access to
  the drawer with no problems - I can read the folder and the one
  document that is in there.

  Thanks for trying to help, do you want to give it another try? :-)

  Best regards,
  Allan

  Stuart, I will post a pointer to the trace file as soon as my
  customer gets their AES connection established. I don't want to go
  on-site just for this one user :-)

  Btw, all users lost the connection to a common drawer since we
  changed the access to it from *WORLD to *LOCAL. It turned out that
  none of the users had the identifier LOCAL. I put *WORLD back on the
  drawer and will try to find the missing LOCAL stuff somewhere. I
  don't quite understand why the users don't have the LOCAL by
  default, because I certainly do on all the systems I have access to,
  if they are running DMW/ALL-IN-1 or not doesn't matter. Strange.

  The story will continue, but take a break now ... waiting for AES
  ... waiting ... waiting ...

  Best regards,
  Allan

    FYI

>  changed the access to it from *WORLD to *LOCAL. It turned out that
>  none of the users had the identifier LOCAL. I put *WORLD back on the
>  drawer and will try to find the missing LOCAL stuff somewhere. I
>  don't quite understand why the users don't have the LOCAL by
>  default, because I certainly do on all the systems I have access to,
>  if they are running DMW/ALL-IN-1 or not doesn't matter. Strange.

    You only get the `LOCAL' identifier if you connect to a system via LAT
    or a directly connected VT.  If you `$SET HOST' to a system, VMS will
    give you `REMOTE' instead (VMS even does this if you `$SET HOST 0' from
    a session with the `LOCAL' identifier!!)

    Cheers,
        Paul.

  Re:.5, Paul

  So, only a VT user has the LOCAL identifier.

  Does this mean that I can't give all my TeamLinks users access to a
  drawer in one go, except by granting WORLD access to my drawer?

  *LOCAL translates to an ACL=(IDENTIFIER=LOCAL,ACCESS=...)
  *WORLD translates to an ACL=(IDENTIFIER=*,ACCESS=...)

  Maybe this is documented but I don't understand it.

  Best regards,
  Allan

>  So, only a VT user has the LOCAL identifier.

    Only a VT user _can_ have the LOCAL identifier (whether they have it or
    not depends on how they logged into the system.)

    In case there's any confusion, the identifiers `LOCAL', `REMOTE',
    `INTERACTIVE', `BATCH' etc. are granted to processes by VMS when you log
    into the system - they have nothing to do with ALL-IN-1.

    ALL-IN-1 does however map the `*LOCAL' group onto the `LOCAL' identifier,
    so members of the `*LOCAL' group will be those processes that VMS decided
    were local when they were created.

>  Does this mean that I can't give all my TeamLinks users access to a
>  drawer in one go, except by granting WORLD access to my drawer?

    Yes.  But you can get round this, however, by creating a group that has
    all your TeamLinks users in it, and granting that group access to your
    drawer.

    Hope this helps,
        Paul.

  Re:.7, Paul,

  thanks for the clarification on LOCAL, REMOTE etc - I did not know
  that.

  I'll ask my customer to create a TL_USERS group or similar.
  Anyone willing to offer a script to put all the users in a group? :-)

  I still don't know why oneuser can get a CAB_DRWDISABLED, but I wil
  investigate further some other day...

  Best regards,
  Allan

    Allan,
                                                                         
    >Anyone willing to offer a script to put all the users in a group? :-)
    
    You could quite simply hack out the queue management bits from 
    SM_QMA_ADD_USER.SCP and you would be left with a script to add a user 
    to group. You could then put this in a profil loop e.g.
    
 for profil with not (.direct eqs " " or .user = "@" or .user <=> ":") do -
    
    Cheers
    davet

Re: .7, Paul
    
    After having thought it over, I think that a TeamLinks user should also
    have the LOCAL rights.
    
    After all, the TeamLinks user has given his username and password in
    order to connect to the server, then why should he not have the same
    privileges as a local interactive user.
    
    I consider this a bug in the OAFC$SERVER authentication code!
    
    I'll SPR when I get to know my IPMT stuff ... :-)
    
    Best regards,
    Allan

    Re: .10

>    After having thought it over, I think that a TeamLinks user should also
>    have the LOCAL rights.

    Pragmatically, I agree.  It'll be easier to do that, than fix the problem
    at the real source - the bad choice of using something as ephemeral as
    the LOCAL identifier in the first place.

>    After all, the TeamLinks user has given his username and password in
>    order to connect to the server, then why should he not have the same
>    privileges as a local interactive user.

    They do! You're just not comparing like with like.  TeamLinks users
    connect over the network, and you'll find VT users that connect over the
    network (via $SET HOST) will have the same problems as TeamLinks users.
    Of course most VT users have a workaround, unlike TeamLinks users, which
    is why I agree in the first paragraph above.

>    I consider this a bug in the OAFC$SERVER authentication code!

    Actually you mean the authorisation code, but we don't want to start
    going down that rathole... ;-)

    Cheers,
        Paul.