Conference iosg::all-in-1_v30

    Below is the results of research into this problem by Faith Donohue,
    thanks Faith for an exelent and timely job.
    
    As you can see the problem is potentially more dangerous than delete
    user looping. The mail below has been forwarded to engineering with a
    strong suggestion that this be fixed in a patch and there will be a
    customer readable STARS article generated from this information to get
    it to as many customers as quickly as possible (via a DSNlink FLASH).
    
    If you have any customer who this may impact then tell them about it
    before they hit the problem, but you may want to wait (a short time)
    for the STARS article which will be in a form that you can give
    directly to the customer. If you don't want to wait for the STARS
    article then please do not just give a customer a copy of the mail
    below, extract the information they need to know.
    
    Terry
    
 ------------------------------------------------------------------------------
                                        From:     Faith donohue

Subject: Research on Delete user problem v3.0

In V3.0 the Delete user procedure has two serious problems with
the new System Wide dictionaries file cabinet entries.  These
are high impact as they will be experienced by every V3.0 site 
soon after installing it.

Both problem are caused by the file cabinet entries in the folder
SYSTEM WIDE DICTIONARIES for the Corporate and Group dictionaries.
These entries appear to be created the first time that the
spell checker is initialized by a user in V3.0.

These 2 file cabinet entries do not appear to conform to the 
required standards for document entries.  They point to a
shared system wide VMS file in the OA$SYSTEM_DICTIONARIES
directory, named CORPORATE.LGP and GROUP.LGP but they are flagged
as a personal document (P) not shared and have no associated SDAF record,
therefore have no associated usage count etc..  When created
the DELETE flag is set to N, so that the user cannot delete
the entry through the standard user interface.  But, the delete
user procedure DOES attempt to delete these entries.  When
successful, it also delete the system wide shared file(s)
OA$SYSTEM_DICTIONARIES:GROUP.LGP and OA$SYSTEM_DICTIONARIES:CORPORATE.LGP
that they reference, rendering the file cabinet entries of other
users on the system to these files corrupt.  NOTE:  Not sure what the 
TRU/TRM procedure will do with these pointers when this situation occurs 
and is not detected.


PROBLEMS:

DELETE USER IN V3.0 ON ACCOUNT THAT HAS USED SPELL CHECKER IN V3.0
WHEN:

1) USER HAS NO UNREAD MAIL; DELETE USER LOOP INDEFINITELY:

(This has already been reported as a low priority to Engineering, but
it should be upgraded, as this will occur frequently)

 When a user is deleted in V3.0 that has initialized the spellchecker
in V3.0 and DOES NOT have any UNREAD mail, the delete user procedure 
goes into an infinite loop.  The procedure will never terminate normally.
The procedure submitted to the batch queue (i.e. OA$submituser_DELETE)
must manually be stopped using the DCL $DELETE/ENTRY command.

***NOTES:  If TRACE is enabled in the script procedure for troubleshooting,
depending upon how long this goes before stopping, the log file can
use up ALL free space on the device (of the ALL-IN-1 Manager account)
resulting in other potential problems.

ANALYSIS:

This occurs because the code in the MUA_DEL_CAB.SCP that attempts
(incorrectly) to handle the file cabinet entries for the SYSTEM WIDE 
DICTIONARIES file is NOT invoked UNLESS the user has UNREAD mail.

The handling of the SYSTEM WIDE DICTIONARIES file cabinet entries 
SHOULD NOT be related in any way to whether the user has UNREAD mail
or not.  Since this code is not executed, the DELETE flag of these
entries is set to N when the CAB JANITOR function is run.  This
results in an infinite loop as the entry cannot be deleted it continues
to try.

When this problem occurs, the user account (bothe VMS and ALL-IN-1)
is left intact after the delete user procedure is manually aborted 
and can be used or deleted again after workaround implemented.


2) WHEN USER HAS UNREAD MAIL; DELETE USER DELETES THE SYSTEM WIDE 
   DICTIONARIES FILES FROM THE SYSTEM

In V3.0 the first attempt to delete a user that has used the 
spellchecker in V3.0 and DOES have UNREAD mail deletes the files 
that hold the SYSTEM WIDE DICTIONARIES, OA$SYSTEM_DICTIONARIES:GROUP.LGP 
and OA$SYSTEM_DICTIONARIES:CORPORATE.LGP, from the system.

ANALYSIS:

The MUA_DEL_CAB.SCP procedure changes the DELETE flag to Y for any 
of the user documents that are currently set to Y.  The entries in
the folder SYSTEM WIDE DICTIONARIES fall into this category.  Then the
CAB JANITOR function is used to delete the entries.  Since, these entries
DO NOT adhere to the requirements for a valid document entries (i.e.
points to a system wide file, but marked as a personal document entry)
the associated files for these entries are also deleted.  The files
OA$SYSTEM_DICTIONARIES:GROUP.LGP and OA$SYSTEM_DICTIONARIES:CORPORATE.LGP
no longer exist, rendering all existing user files cabinet entries
to these files (which could potentially be all users in ALL-IN-1) corrupt.

What is the recommended way to re-create these .LGP files after this 
situation has occured?

When this situation exists, from the WP DIC menu, attempts to
manipulate either the GROUP or CORPORATE system wide dictionary result
in 'file does not exist' message.

You cannot simply change the DELETE flag to Y for these file cabinet 
entries and then attempt to use the normal file cabinet functions
because these entries do not conform to the requirements for a valid
document entry.

The affects of this situation on the proper functioning of the spellchecker
or on the running of the TRU/TRM housekeeping procedures are not known.


RECOMMENDATIONS:

This MUST be corrected and made available to ALL customers
(preferable through a patch) ASAP.  In the meantime, the
workaround below will be available through STARS.  Please notify
me if there are any better suggestions for avoiding this problem.

The permanent solution should correct the implementation of
the file cabinet entries for the SYSTEM WIDE DICTIONARIES folder to
adhere to those required for a document so that the supported file
cabinet operations can be performed properly on them.

WORKAROUND:

The following workaround has been tested and appears to correct both 
problems described above, although it is not recommended to be used as a 
permanent solution since it uses 'undocumented' functionality (i.e.DOCDB
dataset).  


  In MUA_DEL_CAB.SCP find the lines that read:

 ! Check the mail count first - if zero we need not get the unread mail
 !-
 	.if oa$mail_count eq 0 then .goto get_next_folder
 !+
 ! Locate any unread mail and set the status to READ and DELETE to Y 
 ! - but first must we must ensure that the MODIFY flag is oa$Y 
 !-
 cab get_pending "MAIL", #UNREADFOLDER
 !	
 for cab$ with .mail_status eqs oa$sts_unread do -
 get #docx = .%key\\-
 get oa$function = 'write change cab$ key=#docx, -
  mail_status=oa$sts_read,delete="Y" '\\-
 cab decrement_count "MAIL"

 !
 ! Catch any remaining documents with delete set to N
 ! since janitor fn will not delete folder if any doc has delete = y
 !
 for cab$ with .delete eqs "N" do -
 get #docx = .%key\\-
 get oa$function = 'write change cab$ key=#docx, delete="Y"'
 !
 .LABEL GET_NEXT_FOLDER
 !


  Change the above lines to read:

 ! Check the mail count first - if zero we need not get the unread mail
 !-
 !******
 ! Modification: Change .goto label in next command to correct handling
 ! of SYSTEM WIDE DICTIONARIES
 !******
 	.if oa$mail_count eq 0 then .goto next_check
 !+
 ! Locate any unread mail and set the status to READ and DELETE to Y 
 ! - but first must we must ensure that the MODIFY flag is oa$Y 
 !-
 cab get_pending "MAIL", #UNREADFOLDER
 !	
 for cab$ with .mail_status eqs oa$sts_unread do -
 get #docx = .%key\\-
 get oa$function = 'write change cab$ key=#docx, -
  mail_status=oa$sts_read,delete="Y" '\\-
 cab decrement_count "MAIL"
 !
 !*************************************
 ! Modification below: To remove entries for SYSTEM WIDE DICTIONARIES
 ! CANNOT USE WRITE DELETE CAB$ or CAB JANITOR as they delete the system files.
 !*************************************
 .label next_check
 for cab$ with .folder eqs "SYSTEM WIDE DICTIONARIES" do -
 get #docx = .folder:30 .fixer:6\\-
 get oa$function = 'write delete docdb %key=#docx'
 !  
 .LABEL GET_NEXT_FOLDER
 !
 !+


Thanks,
Faith Donohue

    Thanks, Andrew, Terry, & Faith for this information - I ran into this
    'feature' yesterday, after the Delete User batch job had run for many
    hours, looping along quite happily !!

    Onward, ever onward ...

	Ron

    Ron,
    
    Fear not you are not the first and won't be the last to hit this one
    it's already entered at No. 1 in the CSC Calls hit parade pushing out
    those perennial chart-toppers Transfer user and Archiving....
    
    Roll on the next version!
    
    Regards,           
    
    Andrew.D.Wicks 

    Hey &ndrew,

    Regarding the description of this problem, I wonder if it shouldn't be 
    refined somewhat.  The problem statement implies that this Delete User
    loop could occur on any account where someone at some point has invoked
    the Spell Checker.  I haven't found this to be the case on our cluster 
    since we have successfully deleted several acounts since we began our
    usage of ALL-IN-1 Version 3.0.  In fact, the account we had a problem
    with yesterday was that of someone who had an account that was created
    after we began exposing our users to DIAMOND.  

    Is there more to this problem than what has been described?

    POR (Pressing On, Regardless),

	Ron

    Re: .3
    
    Roll on the next version!
    
    Reminded me of the following, and couldn't get it out of my head, so
    put it here to exorcise:
    
    "Roll on, thou deep and dark blue ocean, roll."
    
    -- by an elderly Brit of some substance
    
    Greetings, Andrew
    
    

What about those people running WPS-PLUS V4 in ALL-IN-1 V2.4 who would like to  
delete accounts. I have done some testing and the effect of the problem seems
to be;

1. Account deleted has System Dictionary folder entry and no unread mail. System
Manager is mailed failure message with 'Couldn't remove file cabinet' error.
(better than looping indefinitely I suppose!)

2. Account deleted has System Dictionary folder entry and unread mail. Account
is deleted ok and system dictionary files remain intact. (only tested on one
account so far)

Is the workaround in .1 valid for ALL-IN-1 V2.4, the symptoms for the problem
are different so is the solution. Mailing the account before deletion is not a 
'professional' fix. 

Regards Aston

    
    
    
    RE: WPS V4 option and ALL-IN-1 V2.4 system experiencing similar
    problems with delete user and system dictionaries.
    
    Since it is most likely that the delete user procedure has changed
    with V3.0, I do not think that this alternative will apply.
    
    I have not verified this yet, but I don't think that the WPS V4 
    option changed anything in the delete user procedure, in which 
    case it probably has no provision in it for even trying to change a
    non-deleteable document entry in the file cab. to allow the
    procedure to delete it.  When it fails to delete this file
    cabinet entry (because it is non-deletable) it is probably
    causing the entire procedure to fail.
    
    Any comments from IOSG on this would be welcomed!
    
    No solution for the WPS V4 ALL-IN-1 V2.4 problem.
    
    Faith
    

Re .1:

Should the piece of code that sets all remaining documents to DELETE = Y 
still be invoked *after* the delete of the DOCDB entries for the system 
wide dictionaries has run? 

This piece of code is not in the workaround. It jumps from the 
docdb delete for system wide dictionaries to label GET_NEXT_FOLDER.

Thanks
Regina 

For the ALL-IN-1 V2.4 with WPS V4 option case I have modified MUA_DEL_CAB so that
everything in the file cab are marked to DELETE = "Y" including the SYSTEM 
DICTIONARIES FOLDER. 

When CAB JANITOR attempts to delete this folder it fails with;

%OA-W-CAB_NODELPRIV, User TEST
does not have delete access to file OA$SYSTEM_DICTIONARIES:GROUP.LGP
%OA-W-CAB_NODELPRIV, User TEST
does not have delete access to file OA$SYSTEM_DICTIONARIES:CORPORATE.LGP

The pointers are removed from the file cabinet and the dictionaries are left 
intact for the rest of the users to enjoy. These Warning errors do not prevent
the deletion from failing.

Still not sure why CAB JANITOR can delete the OA$SYSTEM_DICTIONARIES:*.LGP files
in V3.0 but not in V2.4 - subtle change to CAB JANITOR perhaps ?

Regards Aston  

    
    RE .9
    
    It would be safe to leave that part of the code in just in case
    there might be other non-deletable documents in the file cabinet.
    Although, I think that this was added to take care of the
    system dictionary files initially.
    
    Faith
    

IOS 3.0 on VMS 5.5-1

Has anyone heard of/experienced looping when deleting a user account that has 
had a reserved document ?

In this case, I was able to reproduce this problem when deleting an ALL-IN-1 
account that has no new mail, never uses SpellCheck and wanting to keep its 
VMS directory.

Below is portion of the log file that showed the occurence of looping:

===========================================================================

$! Get the VMS user name and directory from the profile	
$!
$	script_file = "sys$login:get_target_details4420.scp"
$	open/write scp sys$login:get_target_details4420.scp
$!
$! Generate parsed version of DCL symbol A1_ACCOUNT for OA$TRANSFER checking:
$!
$	write scp "make_file cli$p_a1_account, cli$a1_account"
$!
........................................

$	write scp "get cli$vmsusr_count = #users"
$!
$	write scp ".label exit_point"
$ 	write scp ".exit"
$	close scp
$	allin1/noinit/reenter/user=MANAGER/language=BRITISH
	oa$ini_init

	get oa$function="do " cli$script_file
%JBC-F-JOBABORT, job aborted during execution

===========================================================================

Must admit I haven't done an exhaustive search on this problem so pls 
correct me if it has been reported earlier.

Thanks

Hong

    Gidday Sport,
    
    The RESERVED document problem has only recently been reported; it is in
    fact another cause of the delete account loop. The currently supplied
    code will require that documents in the user's MAIN drawer be
    unreserved first. However RESERVED documents in any of the user's other
    drawers do not seem to cause a problem.
    
    Cheers
    
    Stuart

    Stuart
    
    Wish you'd been here to give instant work-around...
    
    How involved is the work-around ?
    
    Hong

    Hi Hong,
    
    The easy workround is to tell the System manager to index all reserved
    documents in the user's MAIN drawer and use option XURV to unreserve
    them before deleting the account.
    
    The code fix is straight forward since it's mostly a case of removing
    superfluous code. But the fix has not yet been tested and proved yet,
    and though the change is simple, the differences (in module
    MUA_DEL_CAB.SCP) are many.
    
    Cheers
    
    Stuart