Conference iosg::all-in-1_v30

    Presumably global buffering SYSUAF would only be worth doing enough to
    get the index into global buffers, since the individual user's records
    would still need to be read from disc. I await a performance expert to
    contradict me!
    
    Also, I think this has been discussed before, perhaps in a previous
    version of the conference. (See note 2.* for directories and pointers)
    
    Graham

    
    
       I don't know why Send accesses SYSUAF but an I/O trace shows a fair 
       number of I/Os to SYSUAF and to RIGHTLISTS.DAT. This is likely to have 
       an impact on performance.
    
       To judge whether global buffers would be effective, look at how many 
       users have these files open at a busy period. You can do this by $SHOW 
       DEVICE/NOSYSTEM/FILES SYS$SYSTEM. If there are more than three or so 
       users with these files open then global buffers are probably worth it. 
       Put enough global buffers on to cover the index buckets and a few data 
       buckets.
    
       					Mark
    
       

    
    	I just took a look at the code and I can't see the SYSUAF access
    	at the moment. There's a check_access that doesn't seem to get
    	executed normally.
    
    	What version of ALL-IN-1? V3.0?	Is the drawer shared?
    	Is the sender the owner of the drawer?
    
    Regards,
    Paul

    re .3,
    
    It has nothing to do with drawers since the customer is at v2.4.
    
    Access to SYSUAF is done by all supported versions of ALL-IN-1  - no I
    don't know why though I suspect it's in the File Cabinet code as
    opposed to the Mail Code but unfortunately it would need someone
    to run up the code in Debug to see what kicked off the access.
    
    Regards,
    
    Andrew.D.Wicks

    
    Paul,
    
    The SYSUAF and the RIGHTSLIS are accessed right before the file is
    deleted from the users [.MSG] directory. Would ALL-IN-1 have to verify
    that it can delete the file from the user's directory? It should not
    have to do this since it is a privileged image. Unless you have any
    other ideas, it looks like DEBUG will have to be used.
    
    Any ideas?
    
    thanks,
    Sam

    Although we are a privileged image, we only turn the privileges on just
    for the time we *know* we need them. But I'm sure *you* knew that
    already Sam!
    
    Perhaps it's not us explicitly, but we tell RMS to delete the file and
    it does the "deletability" check on our behalf?
    
    Someone will give in and look at the code soon!
    
    Graham

    Bingo! .-2 jogged my aged memory.
    
    I'm almost certain that we do a $CHECK_ACCESS in the delete code (added
    in about v2.3 to fix an obscure security bug).
    
    When the cluster which holds our source files comes back up, I'll check
    the code.
    
    Dave.

    RE: .-1
    
    Our source code cluster is now up, and I was right - we added a
    $CHECK_ACCESS in v2.3 to fix a security bug. It only does the
    $CHECK_ACCESS if the file to be deleted is _NOT_ in the shared area
    (there are other checks for shared area files). Obviously, this is the
    case for files in [.MSG]
    
    Note that this is also _only_ _done_ if the user is running with SYSPRV
    turned on (the bug concerned the Janitor being spoofed into deleting
    files which it shouldn't). This can be seen by doing the following:
    
    $SET PROC/PRIV=CMK
    $SET WATCH FILE/CLASS=MAJOR
    $SET PROC/PRIV=NOCMK 
    $SHOW PROC/PRIV ! Check that you don't have SYSPRV etc
    $ALLI
    
    ...
    EM
    C
    ...
    S
    
    You won't see the accesses to SYSUAF and RIGHTSLIST.
    
    If, however, you repeat this test with SYSPRV turned on, you will see
    them (just before the Delete of ZRFDSHGDFV.whatever)
    
    Dave.