Conference iosg::all-in-1_v30

3567.0. "Transferring accounts and drawers" by BACHUS::DBC026::Laroche (Veerle Laroche) Tue Nov 23 1993 14:20

Following is a document I received from a customer with remarks on 
drawers/accounts and transferring them.  Can someone have a look at this and 
give his/her own remarks ?

Thank you in advance,


Veerle Laroche


===============================BEGIN OF DOCUMENT============================
This is only a quick look into transfers and shared
drawers/documents/accounts. There are plenty more inside.
We have not implemented any of the solutions below.


ALL-IN-1 SM_MUA_CSN Drawer_transfer_problems

With 5000 users untrained in managing drawers we are going to get some
situations that we only dreamed of.
This one concerns the relationship between a user's FILECAB records
(as in FC DRM I) and the PARTITION records.

We have a user who got (rightly or wrongly) into the following situation:

           FILECAB                    DRAWER
        <no entry>                 [USERNAME]COSI
        COSI                    -> [USERNAME]PVCOSI
        COSI/GESTION            -> [USERNAME]COSI1
        GRANDES_ENTERPRISES     -> [USERNAME]GRANDES_ENTERPRISES
        MAIN (default drawer)   -> [USERNAME]MAIN

After transfer over network (PTN + CSN), the situation is the same except
        MAIN (default drawer)   -> [USERNAME]COSI

OA$LIB:SM_MAS_DRAWER.SCP contains the fragment:
-----------------------------------------------
        FOR FIRST FILECAB WITH .UNIQUE_NAME eqs #unique_name DO -
                                        GET #key = .%key
        WRITE CHANGE FILECAB name = #key, -
                UNIQUE_NAME = #new_name, -
                PARTITION = cli$local_part
       .IF OA$STATUS NES "1" THEN .GOTO filecab_error

.LABEL NO_CREATE
...
-----------------------------------------------

When it processes [USERNAME]COSI, the FOR loop does not find a match and so
leaves #KEY with an 'undefined' value. In fact, since [USERNAME]COSI was the
first drawer, the value was set in SM_MAS_ARCHIVE to MAIN. The WRITE CHANGE
happily updates MAIN to point to [USERNAME]COSI.

[ When [USERNAME]MAIN gets processed as the default drawer, there is no 
effect on FILECAB, since the code skips to NO_CREATE. Otherwise there would 
again have been no match and the last used FILECAB would have been 
corrupted. ]

There is a second problem here. Normally, the username is the same on both
sides of the transfer and so the WRITE CHANGE (when done correctly) has no
effect. But if the usernames are different AND the user has more than one
FILECAB pointing to a drawer, only the first one will be updated.

The obvious solution to both these problems is to put the WRITE inside a 
full FOR loop:

        GET OA$STATUS = 1
        FOR FILECAB WITH .UNIQUE_NAME eqs #unique_name DO -
                GET #key = .%key\\ -
                WRITE CHANGE FILECAB name = #key, -
                        UNIQUE_NAME = #new_name, -
                        PARTITION = cli$local_part\\ -
                IFSTATUS
       .IF OA$STATUS NES "1" THEN .GOTO filecab_error


The SM_MAS_ARCHIVE code mentioned above is very similar:
-----------------------------------------------
!+
! We are now in the situation that create user has created the default
! drawer, and that is the only drawer in PARTITION.DAT for this user.
! However, since we have junked his FILECAB.DAT and replaced it with the
! one from the other system, the default drawer pointer in FILECAB.DAT
! points to the wrong username, to a drawer that doesn't exist on this
! system. We would have got around to patching this up eventually but
! CAB SET_DRAWER always references the default drawer, and so we can't
! use CAB SET_DRAWER until we patch this up. So do it right away.
!-
        GET #source_default_drawer  = filecab:indicator.name["1"]
        .TEXT "Updating " #source_default_drawer " drawer..."
        GET #old_draw = "[" CLI$FULL_ACCOUNT_NAME "]" #source_default_drawer
        GET #new_draw = "[" CLI$NEW_NAME "]" cli$target_default_drawer

        GET #key=""
        FOR FIRST FILECAB WITH .UNIQUE_NAME eqs #old_draw DO -
                                        GET #key = .%key
        .IF #key EQS "" THEN -
                .TEXT "Cannot find user's " #source_default_drawer " drawer"
        .IF #key EQS "" THEN .GOTO filecab_error
        WRITE CHANGE FILECAB name = #key, -
                UNIQUE_NAME = #new_draw, -
                PARTITION = cli$local_part
       .IF OA$STATUS NES "1" THEN .GOTO filecab_error
-----------------------------------------------

This at least tests for no match. But again it will only update the first
matching FILECAB if the username changes or if the DEFAULT DRAWER name
changes. Again the WRITE should be inside the (full) FOR loop.

... which brings us to anther user, who renamed his MAIN drawer (probably 
via
FC DRM UDR) to 'TIROIR PRINCIPAL.':

        GET #source_default_drawer  = filecab:indicator.name["1"]
                = "TIROIR PRINCIPAL."
        GET #old_draw = "[" CLI$FULL_ACCOUNT_NAME "]" #source_default_drawer
                = "[USERNAME]TIROIR PRINCIPAL."
                NO, it was still "[USERNAME]MAIN"
        ... and we fail through filecab_error

Why not doing it this way ? This should work better :

        GET #old_draw = filecab:indicator.unique_name["1"]

would have given the correct result.

==========================END OF DOCUMENT===================================

    
    	This all sounds very plausible. This code is new in V3.0 and
    	has probably not had much exposure to unusual (but allowable)
    	filecabinets. Also transfer user tends not to get heavy test
    	exposure during fieldtest as customers don't use FT software
    	on several systems. We did extensive in-house testing of transfer
    	user in V3.0, but it looks like these problems slipped through.
    	Only now, as customers start to deploy V3.0 are the problems
    	showing up (the code was written over 2 years ago [March 1991]!).
    
    	Could someone update STARS please?
    
    Regards,
    Paul