Conference iosg::all-in-1_v30

    Steven,
    
    I would increase the disk quota on the target account and run the
    the transfer over.  The original account sould still be there.
    
    You may to clean up anything in the target account. 
    
    Hopefully, one of the system mangler types will confirm this.
    
    
    Tim

Hi Tim,

Thanks for your reply!

I'll increase the quota of A1$XFER_OUT in the origin system 
(because the logfile shows that the target system wants to copy a 
file back to the origin system and the A1$XFER_OUT on
origin system does not have sufficient quota)

But, You say clean up anything in target account, do I delete the 
account on the target system is right? does this cause trouble 
to other existing accounts?

Overall, if I understand right, you mean the steps are:

1. Increase the quota on origin system.
2. Delete the target account.
3. Retry the transfer.

Am I right?

Steven.

    Steven,
    
    Just make the target system look the same as when you started the
    transfer.
    
    As to increasing disk quota, now I see what you mean. Yes, increase
    it.  You may want to check the account on the target system to insure
    it has enough disk quota, also.
    
    Then you should be able to run the transfer as before.
    
    
    HTH,
    
    Tim

Tim,

Thank you very much...That's very kind of you.

But I want to confirm something.

I've looked at the target account.  Inside it, there are
a lot of mails which some of the status are ARCHIVED and some are
READ, UNSENT, etc.

Can the system handle this account deletion?

How about the files in shared directories?  Are they deleted
accordingly when I invoke the account deletion?

And also how about the ALL-IN-1 system files, such as DAF.DAT, etc.?
Can they be updated correctly?

Since the target system contains a lot of users and I want to confirm
these actions does not cause any harm to them.

Would you help me?

Steven.

    Steven,
            I recommend you delete the transferred in user account through
    ALL-IN-1, and then check to make sure that the disk you are bring
    the account onto has a disk quota entry for ALLIN1.  If it does
    already have a quota entry, make it a very large number.  Then
    do your MAS again.  
    
    Delete User will update the DAF, but it doesn't look like you ever
    got to the point where the file cabinet was updated.
    
    

    Steven,
    
    From the log file did the transfer complete sucessfully?
    
    From your previous reply it does not look like it did.  Where 
    the files on the target system unarchived?
    
    either way you should call the local csc.  
    
    What Paul is telling you is that the delete user will put
    the account back to a state that we can confirm.
    
    Then you can check diskquota on BOTH system, increase it, and
    run the MAS again.
    
    HTH,
    
    Tim Butler

re:.6

>>>    From the log file did the transfer complete sucessfully?

Ans.: The transfer is not success.

>>>    From your previous reply it does not look like it did.  Where 
>>>    the files on the target system unarchived?

Ans.: I login the target account and get into its ALLIN1 account,
      I found that the mails in the folder are most ARCHIVED.  Then 
      I show header (SH) and the files of all ARCHIVED mails are 
      OA$LIB:ARCHIVE.TXT.


BTW, I'll make sure the quota on both systems are enough.  Delete
the failed transferred account on target system and then run
MAS again.

Thanks a lot,

Steven.

    
    	A couple of the comments here "re-run the transfer" worry me here.
    	What ever you do:
    
    		**** DON'T RE-RUN THE PAT OPERATION ****
    
    	or your account could end up lost completely.
    
    	You can re-run the MAS, but PAT (on V2.4) writes to the source
    	account and is NOT restartable.
    
    	From what you say, you don't need to re-run the PAT operation
    	anyway, but I thought I would warn you.
    
    Regards,
    Paul

Thank you!  My procedures will be:

1. Delete the failed transfer account (A1) on the target system.

2. Rename the PAT_XZXXXX.DAT from OA$LOADUSER:[username]
   to OA$LOADUSER:[000000].

3. Delete the files in OA$LOADUSER:[username...]*.*;*

4. Increase the quota of A1$XFER_OUT on origin system and
   the quota of transfer account on target system.

5. Create the transfer account (A1) again on the target
   system.

6. Re-run MAS on target system.

Are the above steps right?

Steven.

    
    	Don't understand what (1) is trying to do.
    
    	(5) Create user can be done from MAS so you could roll (5) into (6)
    	but it may be simpler from an error tracking point of view to
    	do them seperately. I'd do them together, but its just taste.
    
    	Looks good.
    
    Regards,
    Paul

Thanks.

In .9, I found that the PAT .DAT will put under
OA$LOADUSER:[username] when doing MAS.

But back to the prepare account stage, if you prepare the account
on the origin system, the origin system will copy this file under 
OA$LOADUSER:[000000] and not under [username] on target system 
since no MAS has been performed yet.

So I rename the file back to [000000], just back to the beginning
stage before running MAS.

Am I right?

Steven.

    
>So I rename the file back to [000000], just back to the beginning
>stage before running MAS.

    	Don't think so. MAS looks in [000000] as well as far as I can see.
    	You should just be able to re-run the MAS without doing the rename.
    
    Regards,
    Paul