Conference iosg::all-in-1_v30

    Hi,
    
    I do not recommend that you use this as is. 
    
    The FOR PARTITION loop will be extremely slow on a large system. It
    could be improved dramatically by using the OWNER secondary key. but
    ...
    
    It would be better to allow for the case where many users share a VMS
    account by making the FOR loop be
     
     GET #NAME = "[" OA$PROFIL_USER "]"\
     FOR PARTITION WITH .%KEY = #NAME DO\
    
    Cheers
    
    Stuart

    Hi Stuart, 
    
    Thanks for improving the code. I did think about using the #NAME
    approach, but went the other way, probably due to my bad eyes (private
    joke between SM and myself). 
    
    At least DEC specialists can look good if they see the code on a
    customer site.  All you have to do is say, casually, "I know a way to
    improve that lookup", or mention something about using the OWNER
    secondary key.
    
    Now a question, PARTITION has three keys. UNIQUE_NAME is 0, OWNER is 1 
    (or 2), what's the third?  LANGUAGE? UID?
    
    Thanks, Tony

	Not that it will make a lot of difference, but the FOR PARTITION...
does not require the DO OA$NULL.  Any FOR loop will still set OA$SEL_COUNT,
even if there is no DO clause.  Example:

	FOR PROFIL

will set OA$SEL_COUNT to the number of entries in PROFILE.DAT.

	However, that wasn't my main point.  I was thinking that to avoid the
problem Tony mentioned about "locking up" accounts when you haven't set User
Flag 8 for all of them, you might want to make the check in the XOP code
conditional -- in other words, *IF* User Flag 8 is not null, *THEN* do the
check.  In this manner, you could use the flag *only* for those you wanted to
limit; all others would operate normally (i.e., standard V3.0).

	F

        R.e .2

        The third key to PARTITION is DRAWER_IUID.


        Catrin.

    Re. 4
    
    Thanks for the information.
    
    Re. 3
    
    I don't like leaving FOR loops without anything to do. It just seems
    odd. That's why I leave the DO OA$NULL at the end of a FOR.  You are,
    of course, quite correct to point out that OA$SEL_COUNT is filled
    whether or not the OA$NULL is included.  In fact, I could have
    dispensed with the #FC_DRW_NO symbol totally and just used OA$SEL_COUNT
    throughout the code if I had wanted to, but I guess I just like
    misusing a few extra bytes of memory...
    
    Nice idea to check in named data whether or not the user is "afflicted"
    with a drawer limit.
    
    Tony

    
    One other thing to keep in mind, running the partition file will only
    account for drawers stored locally. Once the dist share option is 
    available users will be able to create a drawer in any partition (node)
    in the world that they have access to. This drawer will not be stored
    in the local partition file, it will be stored in the partition file
    that is on the system that physically contains the drawer.
    
    Don't know if you want to count these drawers since they will not take
    up disk space on the local system, but they are still a drawer owned
    and created by a user.
    
    --Bob
    

    Hi Tony!
    
    	Without running the code you gave in .0 I can't tell if this
    	is the same as the code you gave out at DECUS. At DECUS a few
    	people had tried it and it didn't work correctly when you
    	deleted a drawer. If you were at the limit, deleted a drawer,
    	then tried the create again, it would fail....at least that's
    	what they told me...
    
    Regards,
    Paul

    Paul,

    I believe that you saw the effect of the few user accounts (like all
    but ONE) which had a blank UFLAG field.  The effect on those users was
    that they would be told that they were limited to the current number of
    drawers.  As they deleted their drawers (in the ALL-IN-1 sense) this
    number would go down causing some confusion which is typical of systems
    on which Tony has done magic.  ;')

    Did your glasses survive the trip back?

    Stay mellow,
    don

    It's basically the same code (with the Maurice addition). Don's point
    about allowing users to have some drawers in the first place sorts
    things out....  Goes to prove that you shouldn't move code into the
    live area unless you've tested it first... (from an unprivileged user
    account)
    
    Tony

    
    Just some input from a customer regarding this implementation.  It
    only addresses checking for the drawer limit that is set when a user
    attempts to create a drawer from the FC menu, but does not impose
    the same checking from the Create option on the FC Index
    (FC$IDR$INDEX).  
    
    This is seen as an important limitation.  anyone else run into this
    concern?  If so, is there any addition to this implementation to
    impose the same limitation from the index?
    
    Thanks in advance,
    
    Faith Donohue
    
    

Faith - it sounds like you have 2 choices:  write some new named data
script code similar to the FC menu version which works from the Index, or
possibly remove the option altogether from the Index and put something like

display Option not available from the Index.  Please use the FC menu instead.

in place of the existing code.  If you go with the latter,  keep the old
code in place but just hide it by placing double tildes around the option
name, ie,

;;opt;;     becomes    ;;~~opt~~;;

you get the idea.

	Al

    faith,
    
    according to some top-secret info there is some sort of code in the PFR to
    do this though whether it is based on Tony's best-seller I don't know.
    You may want to take a look on one of our nodes and see how it's done
    there.
    
    regards,
                      
    Andrew.D.wicks