Conference iosg::all-in-1_v30

    Bruce.
    I have been through the delete log you provided, line by line. All
    seems perfectly normal; it is a single account deletion of user MORROW
    by the ALL-IN-1 Manager. I can find no reference to deletion of
    A1$SCRIPT in this log. The fact that it ended abruptly on the line:
    get oa$function="do " cli$script_file 
    suggests to me that the manager did panic and kill the job.
    
    I would suggest that since the Manager was doing single deletions, then
    he/she did not notice that the account in the context block had changed,
    and after failing on one attempt tried again, but this time tried to
    delete A1$SCRIPT. This is not difficult to replicate, and in fact,
    it is easy to do on our development system here, because A1$SCRIPT
    is the first account in the Profile. If you take an old account you
    don't want, and delete its profile entry only (DP), then you'll find
    that the context block switches to the top account ("First account
    selected"). Invariably, this is A1$SCRIPT.
    
    I can help avoid this in the future, by ensuring that A1$SCRIPT is one
    of the delete-protected accounts. Otherwise, I think this one is
    probably down to user error.
    
    DaveT                           
    

    re 4.
    
    >he/she did not notice that the account in the context block had changed
    
    Today I deleted A1$SCRIPT on my test system by accident.
    I had deleted user JOS by doing MUA D DA, but after having pressed
    return, I found out that I had forgotten to answer Y to delete his VMS
    account too.
    JOS was still in the context block (!) so I typed DA again and Y to
    delete the VMS account, and saw the message
    "The account A1$SCRIPT will be deleted"    -  !!!
    
    With my ALL-IN-1 experience this was foolish. 
    At the moment I pressed Return I knew that a wrong account would be
    deleted, because JOS was not longer in PROFILE.DAT and ALL-IN-1 would
    have had to make another account the current one. 
    
    This is just to tell how a deletion of A1$SCRIPT can happen by
    accident. As long as the overlay form SM$DELETE$MENU is present, the
    context block in the underlying form SM$MUA does not get updated.
    
    Form SM$DEL ought to include a name for the account the user is about
    to delete. Look at this screen image:
    
                             Maintain User Accounts


         SEL  Select                   Account:  ELIN2

         C    Create
         E    Edit
         D    Delete                       QMA  Queue management authorization

                             Delete Account Options

         Delete (if present):

           Mail Directory:   Y

           VMS account:      N

           Shared drawers:   Y

         Enter options and press RETURN
         to submit account deletion batch job

    
    ---
    After having deleted account ELIN2, 
    DA  Delete account  has been selected again.
    It is not possible to see which account will be deleted.
    (In this case A1$SCRIPT).
    
    Elin

    
    I think it is a mistake (a bug) that the user gets returned to
    SM$DELETE$MENU after having deleted an account, because it is not possible
    to select a new account while form SM$DELETE$MENU (with the DA and DP
    options) is present. If option DA gets selected again, A1$SCRIPT will
    automatically be deleted.
    
    
    I will suggest the following changes:
    
    1. Protect A1$SCRIPT from deletion.
    
    2. Display name of account to be deleted in form SM$DEL.
    
    3. After an account deletion, MUA D DA, return to form SM$MUA instead of
       form SM$DELETE$MENU
    
    Elin
    
    PS. Should I write an SPR?