Conference iosg::all-in-1_v30

    Hi,
    
    What the customer is probably seeing on V2.4 is a check in 
    oa$lib:mua_del_account.com to see if this account is one of 
    several under a group directory. The symbol cli$grp_flag is 
    set in oa$lib:sm_check_group_dir.scp - the comments on this
    script explain why. If grp_flag is set, then a warning is
    logged with text OA$_SA_SHARED_DIR_WARNING, which translates 
    to "Warning - shared directory - directory not deleted".
    Could you investigate the delete log and see if this is the
    case, please?
    
    On V3.0 this logic is changed and more reliance is placed on 
    the Delete_from field. In fact, I notice that the same symbol
    brings up the warning - "VMS account is shared by ALL-IN-1 accounts"
    on V3.0 - which is a subtly different thing!
    
    Cheers,
    DaveT

    G'day Dave,
    
    >What the customer is probably seeing on V2.4 is a check in 
    >oa$lib:mua_del_account.com to see if this account is one of 
    >several under a group directory. The symbol cli$grp_flag is 
    >set in oa$lib:sm_check_group_dir.scp - the comments on this
    >script explain why. If grp_flag is set, then a warning is
    >logged with text OA$_SA_SHARED_DIR_WARNING, which translates 
    >to "Warning - shared directory - directory not deleted".
    >Could you investigate the delete log and see if this is the
    >case, please?
    
    Yes you are correct about the grp_flag being set to 1.  However I have
    been told that they do not share their VMS Accounts and ALL-IN-1
    accounts.  That's why I have been at a loss to explain why they have got
    this message.  The VMS account name was ADMIN8 and the ALL-IN-1
    username was HOLOHAN PETER.  The directory specification was
    USER$DISK7:[ADMIN8.A1] the UIC and file protection were correct.
    
    Thanks
    
    Sunil
         

    Hi Sunil,
    
    Sorry, but I can't help you much more without actually getting onto 
    their system. It seems that their set-up is such that
    sm_check_group_dir is returning 1 for the group flag and the only
    way to see why this is, is to put trace on this script on their site.
    Is this possible? The script does some rather awkward parsing of
    directories and devices, and their exact values passed are important 
    to see (this is all gone in V3.0). I have tried to mimic the behaviour
    here, but without knowing ~exactly~ what is held in each of the cli$
    symbols passed to the script, I'm not able to reproduce the problem. 
    
    Cheers,       
    DaveT

    Hi Dave,
    
    I am enclosing a logfile maybe you might see something obvious that I
    may have missed.
    
    The customer wants to know if they can safely delete the directory
    ADMIN8.DIR, that's all they are worried about.  My thoughts about this
    are that they can if it's not being shared by anyone.  The fact that
    the UIC is numeric means that they can use that uic again.
    
    Do you or anyone else have anything to add to or question my
    assumptions ?
    
    Thanks
    
    Sunil

NOTE from Moderator - Log file removed. See author of this note for full log.

>>  The customer wants to know if they can safely delete the directory
>>  ADMIN8.DIR, that's all they are worried about.
===
Hi Sunil,
Obviously, they will have to decide this themselves, based on their own checks
for shared use of this account. Are there any other files left in 
[000000.ADMIN] - particularly .DIR files - this is what the SM_CHECK_GROUP_DIR
script is looking for i.e. the top-level directory of another user account? 

The log shows that:
	. the UAF entry is removed
	. the Profile entry for Peter Holohan is removed
	. the ALL-IN-1 subdirectory is emptied and deleted
	. there are no other ALL-IN-1 accounts sharing this default directory

Then when it finally comes to delete the top-level directory [ADMIN8] it finds
grp_flag set and passes mua_del_vms param 7 = '1' i.e. don't delete the 
directory.
...
$ ! Remove the users VMS account
$ !
$ del_vms:
$ !
$	if grp_flag .eq. 1 
$	then 
$ 	account_failure="<OA$_SA_SHARED_DIR_WARNING>"
$	GOSUB log_warning
$ log_warning:
$ !
...
$ !
$	@oa$lib:MUA_DEL_VMS -
	ADMIN8 "HOLOHAN PETER" USER$DISK7:[ADMIN8.A1] USER$DISK7: -
	 [ADMIN8] [160,13244] 1
...
$ !
$ ! OA$LIB_SHARE:MUA_DEL_VMS.COM	V2.3	
$ !
...
$ !
$ !Parameters:
$ !
$	shared_dir    = P7   ! 1 - > do not delete VMS directory	

...
$ 	if success_count .eq. 0 then goto failure_message
$ failure_message:
$ !
$	if (failure_count + warning_count) .eq. 0  then goto issue_message
$	write blp " "
$	write blp " "
$	write blp "<&TAB 5><OA$_MUA_BCH_DEL_FAILURE>"
$	write blp " "
$ !
==============================

I think personally that sm_check_group_dir is returning an incorrect
value, because this certainly doesn't look like a group dir e.g.

			[000000.ADMIN8]
			      |
			      |
       +---------+------------+-----------+-----------+
       |         |            |           |           |
    USER1     USER2         USER3       USER4       USER5

If it can be confirmed that this is not the case, then they can go ahead and
delete the (empty) directory.

Hope this helps,
DaveT
    p.s. you may want to delete and re-enter the previous reply without the
    log (save disk space) before the ALL-IN-1 Support Conference Police 
    return from holiday ;-). (P.C. Pye will be back next week)

    As Dave suggested in .-1, I've now removed all of the log file from .4.
    
    Please don't post big log files directly in the conference, but
    pointers to W:R versions on *your* node, since I have enough trouble
    finding space for this conference as it is!
    
    Graham (aka PC Pye :-) )