Conference iosg::all-in-1_v30

    Hello Chele,
    As a start, you could have a look through the discussions we had
    earlier with Sunil - 2385.5 and onwards. It really isn't a good idea 
    to create your VMS a/cs outside ALL-IN-1, for ALL-IN-1 to use, because
    the UIC allocation history file that ALL-IN-1 keeps is not updated,
    and the site could re-use a UIC, and possibly allow a user access to 
    drawers where s/he shouldn't be (V3.0).
    Cheers                                
    DaveT

Hiya,

Is the preference for unique UICs actually documented somewhere?
I need a bit of paper to place delicately beneath the customer's proboscis.

Chele

    Hi.
    Well, there is a brief reference on page 25 (3rd para) ALL-IN-1 
    Information Update, August 1992. I haven't got my bookreader access
    at the moment, so I can't check any further - sorry. If I could,
    I'd have a look in the docn for shared drawers, and also, if I had a
    copy (;-), I'd look in TR's book on Managing and Programming V3.0.
    Cheers
    DaveT

Here's the first half of the Information Update article that Dave mentioned:
    
    ALL-IN-1 Version 3.0 includes a UIC Allocation file, which provides a
    simple way to keep a check of which UIC groups and member numbers have
    been allocated to your users. Together with improved data entry forms
    for user details, improved account templates, and improved logging of
    the Create User process, this has helped to improve the process of
    creating user accounts.

    Another improvement introduced in ALL-IN-1 Version 3.0 is the UAI$
    DSAB, which allows much simpler reading of, and writing to, the system
    user authorization file, SYSUAF.DAT. This, in turn, has allowed much of
    the account creation process to be moved to the script OA$LIB:SM_
    CR_USER_DETAILS.SCP. This script uses the new MAKE_UIC function to read
    through SYSUAF.DAT, identify the next available UIC in a particular UIC
    group, and allocate this UIC number to the new VMS account record in
    SYSUAF.DAT.

    Finding a UIC in this way involves a risk that UICs from deleted
    accounts may inadvertently be reused. If this happens, the new user may
    have access, through access control list entries, to files and
    directories of the previous user. This is no different from using
    Authorize to create VMS accounts - the risk of reusing a UIC number is
    just the same.

    To help avoid this problem, the Create User process in ALL-IN-1 Version
    3.0 includes a mechanism to prevent the reuse of UICs that ALL-IN-1 has
    granted in the past. This mechanism uses the UIC Allocation file,
    OA$DATA:SM_ UIC_ALLOCATION.DAT, which is mapped by the entry form
    SM$UIC$ALLOCATION in OA$LIB:MANAGER. Each time the MAKE_UIC function
    is used to create an entry in SYSUAF.DAT, it adds an entry to the UIC
    Allocation file. This entry has a value that is one greater than the
    UIC member number allocated to the new user account. For example, if an
    ALL-IN-1 user account VASQUEZ is created with a UIC value of [320,155],
    the MAKE_UIC function adds a new record for group number 320 in the UIC
    Allocation file. This new record has a value of 156.

    The next time an ALL-IN-1 user account is created, the script
    SM_CR_USER_DETAILS.SCP uses this value from the UIC Allocation file as
    the start-member parameter of the MAKE_UIC function. Thus, if an
    ALL-IN-1 account has used a UIC member number in the specified group,
    and the account has since been deleted, ALL-IN-1 has a record of this
    usage and does not reallocate the same UIC member number.

    If, since the last update of the UIC Allocation file for the specified
    UIC group, a higher member number has been added to SYSUAF.DAT (for
    example, through the use of the Authorize Utility), MAKE_UIC ignores
    the value of the start-member parameter and uses a value of one greater
    than the number in SYSUAF.DAT. If, on the other hand, the value of
    start-member is greater than the highest existing UIC member number
    within the specified group, MAKE_UIC uses this value as the member
    number of the new user. Provided that the integrity of the UIC
    Allocation file has been maintained, this ensures that ALL-IN-1 cannot
    reuse any UIC that it has previously used.

    In some ways, the UIC Allocation file is more effective in maintaining
    security than using the Authorize Utility to add users and keeping an
    informal check of which UICs you have used. In fact, some ALL-IN-1
    sites use the ALL-IN-1 Create User process simply as an easy means of
    creating VMS accounts, even when the user does not intend using
    ALL-IN-1.