Conference iosg::all-in-1_v30

    Ann,
    
    Old version of MUA_DEL_ACCOUNT??? Just guessing since this appears to
    be the same system that you were having trouble with MUA_CREATE on in
    a later note in this conference.
    
    Regards,
    
    Andrew.D.Wicks

    Hi Ann (again!)
    
    The com file looks OK for a V2.4 system. The error you are seeing is
    not a specific one due to an expected condition, but is picked up from  
    the general     $ on warning then goto invalid_condition
    at the start of mua_del_account.com.
    
    At the point of failure, the code is trying to open the file which
    contains the list of users to be deleted (e.g. those selected from the
    index of accounts under MUA). It has passed safely through the section
    which says:
    
    $       if debug then wso "data_loc = ''data_location'"
    $       if f$search(data_location) .eqs. "" then goto no_user_info
    $       open/read/share del 'data_location'
    
    data_location contains the filename of the list of user(s) to be
    deleted. This is created using the form MUA$UTILITY in both the single
    and multiple delete user condition. It would appear from your log that 
    this file is being found, and is being opened correctly (no warnings or 
    errors - though I'm surprised that the open doesn't have a /error
    qualifier).
    
    Then, when it tries to read something from the file (logical name del)
    it complains about the logical name! This is a bit puzzling.
    
    To help us a bit more, could you ask the customer to do a couple of
    things: e.g. 1) check that the manager account running this procedure has
    the correct privileges, and can create logicals and create files in
    oa$data_share  2) $set verify  from just under the part which says:
    $ ! First - generate the filespec and location
    
    ...and then set it off again after the read operation. Please post the
    results here.
    
    Lastly, I note that this part of mua_del_account has been changed in
    V3.0, so this suggests to me that there was possibly a bug in this area
    that has been fixed, and I have forgotten about.
    
    Hope this helps.
    DaveT

    re .1	Nice try Andrew, but its a totally different system
    
    re .2	i was able to create logicals and files in oa$data_share
    		i set proc/priv to ALL
    		i set the set verify
    		i tried to delete a user - here's the log...
    
    $ xfer_read_error:
    $ !
    $ ! if we have a problem here then forget it
    $ !
    $       goto get_next_account
    $ get_next_account:
    $       warning_flag = 0
    $       read/end_of_file=operation_complete del rec_buffer
    %DCL-W-UNDFIL, file has not been opened by DCL - check logical name
    $ invalid_condition:
    $       set noon
    $       if f$trnlm("xfer") .nes. "" then close xfer
    $       failure_reason = "OA$_MUA_BCH_FAILED_ERROR_CONDX"
    .
    .
    .
    $       if f$trnlm("ok_log") .nes. "" then close ok_log
    $       if f$search(success_log) .nes. "" then -
                    delete/nolog/noconfirm sys$login:del_success0507.wrk;
    $       if f$trnlm("fail_log") .nes. "" then close ok_log
    %DCL-W-UNDFIL, file has not been opened by DCL - check logical name
    $       if f$search(failure_log) .nes. "" then -
                    delete/nolog/noconfirm sys$login:del_failure0507.wrk;
    %DELETE-W-FILNOTDEL, error deleting
    APPL$DISK:[ALLIN1]DEL_FAILURE0507.WRK;1
    -RMS-E-FLK, file currently locked by another user
    $ !
    $       temp_files = "sys$login:*0507.*"
    $       if f$search(temp_files ) .nes. "" then -
                    delete/log/noconfirm sys$login:*0507.*;
    %DELETE-W-FILNOTDEL, error deleting
    APPL$DISK:[ALLIN1]DEL_FAILURE0507.WRK;1
    -RMS-E-FLK, file currently locked by another user
    $ !
    $       save_ver = f$verify(save_ver)
    $ 	    exit

Reposted without name of unannounced future product
in directory spec (:==:)
    
                <<< IOSG::LIB0:[NOTES$LIBRARY]ALL-IN-1.NOTE;3 >>>
                     -< ALL-IN-1 (tm) Support Conference >-
================================================================================
Note 1669.4                  Error deleting account                       4 of 4
IOSG::TYLDESLEY                                      19 lines  30-OCT-1992 16:12
                                -< Working... >-
--------------------------------------------------------------------------------
    Hi,
    
    Hope this gets us a bit further. What your new piece of log showed was
    that this was not the standard pass through the get_next_account label.
    Just above it shows that it passed there from the /error switch on 
    
    $       open/read/write/share/error=xfer_read_error -
                             xfer oa$data_share:transfer.dat
    
    Can you check the transfer area on your system? On mine it looks like:
    
    Directory A1SOURCES:[ALLIN1.DEV_DATA.DATA_SHARE]
    
    TRANSFER.DAT;3
                                                   
    Perhaps delete user is unable to find/open this file?
    
    Cheers,
    daveT

    well, seems we MIGHT have found the problem - i cannot find the file
    TRANSFER.DAT !
    
    i copied a TRANSFER.DAT file from another system onto this one and was
    able to delete an account successfully.
    
    Thanks fro helpoing to locate the problem ! 	Ann

    another question on deleting users:
    
    is it written anywhere that you cannot delete an account that has
    unread mail messages?  1 of my administrators was trying to delete a
    user that had unread mail, adminstrator deleted the unread mail and
    then was able to delete the account.
    
    but we can't find any reference to this in any documentation.  i looked
    quickly in DSN, but didn't see anything there either.
    	ann
    

Err, isn't there a note earlier in this conference about problems in V3.0 when
deleting accounts with unread mail?  Something to do with a bad label in one
of the scripts / command files.

Or maybe that was another delete user problem... :-)

Scott

Ann,
Is this still a V2.4 system as your base note suggests?
If it is, then the following bit of code should handle the unread mail:
...
$ pending_key = "MAIL " + user_key
$       open/read/write/share pdg oa$data:pending.dat
$ pending_loop:
$       read/delete/key="''pending_key'" -
                /end_of_file=pdg_eof/error=pdg_eof pdg pdg_record
$       goto pending_loop
...
I also (like Scott) seem to recall some problem with unread mail, but
can't remember it exactly.
Cheers,
DaveT

    yes, this is a 2.4 system.
    
    i thought i had seen/heard something on this, but wasn't sure.
    
    so what you're saying is that even if a user has unread mail, there
    should be no problem in deleting the account?  right?
    
    that's the way i thought it was....
    
    	thanks - ann

    Yes - there should be no problem. I think that the problem we
    remembered was on V2.4 Transfer not Delete. You should be OK 
    deleting, even if the user has unread mail.
    
    Cheers,
    DaveT