[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

218.0. "PAT CTN sorrows....." by KERNEL::SMITHERSJ (Living on the culinary edge....) Thu Mar 12 1992 14:41

ALL-IN-1 v.2.4. patched to K603

My worse nightmare - transfer user fails.......
Customer has been doing a series of transferring accounts, one
by one, and a particular account has failed with the
error "Failed to backup VMS files".  Looking at the log
file it fails at the point it does

$vms_exclude = a1_dir - "]" + "...]"
 backup 'top_level_dirspec' -

because 'top_level_dirspec' isn't getting defined and the
log file shows a 

 backup ...] -  instead of
 backup [BUSWELL_D...] -

I looked on STARs but couldn't see any articles.  All the user
has in his file is a login.com with some identifiers on the file
but I don't think this is the problem as I did the same thing and
it worked OK.

That's not my immediate problem however..... Unfortunately, the
account documents has been archived etc, and the account doesn't show up
on the Cancel index.  I gave the customer a STARS article to change
SA$TRANSFER so that the user showed up in the index however, this
failed as well.  

Customer put in to SA$TRANSFER
Transfer account: BUSWELL.D
Time:19920311000000
Complete: 0
Status: 1

This showed the user up on the cancel index but when he tried it 
failed without any apparent reason, and SA$TRANSFER now says:

Complete: N
Status: C  and the CTN index says 'Cancel Scheduled'

Did exactly the same for mine and CTN failed for no reason but 
the status is P and CTN index says Prepared.

I don't think the customer's Time field is correct simply because
he has just put in a series of 000000's for the hour and minutes.
I got my timestamp by getting the time on the log file name. Is
this correct or what should you put on there?

Further, how can the customer get out of the problem he is having
with this account.  ALL-IN-1 username is BUSWELL.D and VMS name is 
BUSWELL_D.  I don't believe the naming conventions are the problem 
as I transferred one like that and it was OK.

What is going on.... HELP!
 
julia
UK CSC
T.RTitleUserPersonal
Name		DateLines
218.1Hello?KERNEL::SMITHERSJLiving on the culinary edge....Mon Mar 16 1992 09:183
    Help anyone?
    
    Thanks
218.2I suppose that puts me on the spotIOSG::TALLETTMit Schuh bish hiTue Mar 17 1992 09:1915
    Hi Julia!
    
    	Oh dear, my worst nightmare, someone asking how to repair a
    	failed transfer user! I don't know what I'd do if I were in
    	the field and a customer bought a days consulting to fix such
    	a problem! Go off sick maybe! :-)
    
    	Actually I was hoping one of those kind people in Atlanta would
    	post the "Here's how to recover from a failed TU" article from
    	STARS. I don't know a lot about recovering from this situation
    	except BACKUP (but I never understood how you recovered the
    	shared areas...).
    
    Regards,
    Paul
218.3tricky oneIOSG::TYLDESLEYTue Mar 17 1992 09:5319
    ..just to endorse Paul's comments, Julia, a failed V2.4 transfer
    is very difficult to deal with. We had one here (the account of a
    highly-respected ex-ALL-IN-1 developer!) that went wrong (house-
    keeping shut down ALL-IN-1 half way through the transfer). After
    many attempts we resorted in the end to BACKUP and start again. 
    The account was 2-3 weeks out-of date from the backup, but as he 
    was already moved onto the target system (and using VMSmail), this 
    didn't seem to matter.
    
    How difficult would it be for your customer to restore the account 
    and start again?
    
    One other source of possible help - I seem to recall an article in the
    old ALL-IN-1 conference, I think by Terry Porter, that gave more
    details on how to salvage a V2.4 semi-transferred account.
    
    In V3.0, thanks to Paul T's changes, Transfer is recoverable.
    
    DaveT
218.4Haven't given up yetKERNEL::SMITHERSJLiving on the culinary edge....Tue Mar 17 1992 16:4012
    Thanks for the moral support, lads! At least I'm not on site
    so they can't beat me up.  I have been trying out the amended 
    script in 'How to restore user to original status after 2.3 PAT' 
    which works OK for me to de-archive the files.  I've given it 
    to the customer to try out.  If (and oh boy, IF, it works), 
    I'll advise the customer just to transfer the ALL-IN-1 
    subdirectory rather than the VMS directory.
    
    Keep your fingers crossed.
    
    julia
218.5UAF wrong?IOSG::TALLETTMit Schuh bish hiWed Mar 18 1992 08:067
    
    	Oh yes, we never got to your original problem. Sounds to me
    	as if the UAF doesn't have the device/directory in it?
    	(No, it doesn't sound convincing to me either,....)
    
    Regards,
    Paul
218.6Stars recovery does workTRCOA::HALSEYI'd rather be sailing!Wed Apr 29 1992 16:5220
    Sorry for a late reply, but I'm catching up on my notes.
    
    At my regular customer site, we've got a fair bit of experience with
    User Transfers and recovering from failed transfers.  We have even
    "documented" the procedure, its cautions AND how to recover from it!
    (I can fax you a copy if you like).
    
    The recovery is based on the STARS article provided by the local CSC. 
    It actually does work, although we made a subtle minor improvement.
    It's based on two files which you can create RESTORE.SCP and RESTORE_
    TRANSFER_USER_DOCUMENTS.SCP.
    
    The only thing we haven't worked on is CTN.  We just use a rule NEVER
    EVER EVER use CTN.  Blow the process away if you must, but don't use
    CTN.  This irrational fear is due to inexperience and rumours about
    CTN, not from any actual use of it.
    
    	Hope it helps...
    
    	Bob Halsey, Toronto SWS
218.7It's worse than that Jim...UPROAR::WATSONRDunno man... just got here myself !Fri May 08 1992 17:0839
    Oh no... I've just tried to PAT a manager's account and have totally 
    destroyed it !!! Moral support would be nice, advice would be better.

    What I foolishly did was this... I started four PAT procedures for four 
    users. Silly I know, but I'd never done this before. Foolish bravado if
    you will, but it gets worse... much worse. One works... two fail when the
    disk fills up so... in a rash attempt to create enough space to save the
    fourth, I delete the OA$TRANSFER area for one of the failed accounts.
    The fourth then fails. I then create another OA$TRANSFER on a totally
    empty disk, and restart the PAT process for the three failed accounts.
    I then dutifully clean up my 'old' OA$TRANSFER area and await the
    completion of the new PATs. One fails with an accvio. In the process of
    trying to find out why, the whole horrible truth becomes apparent and
    I realise what I've done. I immediately kill the other two PATs and
    contemplate killing myself.

    I think I'll kill myself now and save someone the trouble.

    I've spent the last hour in the depths of dispair but have decided to view
    this as a challenge. My plan is this... comments please.

	1. Rename the user's accounts somewhere safe

	2. Rename the OA$TRANSFER area somewhere safe
   
	3. Restore the shared directories from last nights backup thus creating
	   any files that have been deleted.

	4. Restore the user's directories.

	5. Restart the PATs (one by one)

    Is this a plan ? will it work ? Shall I hide somewhere dark and hope it all
    goes away ?

	:-(

Ross
218.8UPROAR::WATSONRDunno man... just got here myself !Fri May 08 1992 21:4824
�	3. Restore the shared directories from last nights backup thus creating
�	   any files that have been deleted.
�
�	4. Restore the user's directories.

    Having checked a shared file that was restored, it would appear that
    the shared DAF files have been updated by the PAT, removing entries with a
    usage count of zero if the file that goes with the entry has been archived
    by the PAT. Damn... that adds another level of complexity. Looks like I'll
    have to shut down ALL-IN-1, move the shared area DAFs somewhere safe, 
    restore the old DAFs from last nights backup, THEN run the PATs and THEN
    put the 'real' shared DAFs back again and restart ALL-IN-1.

    This 'should' work because to all intents and purposes I'll end up with an
    ALL-IN-1 system as it was last night. Nothing happened to the three accounts
    in question between the backup and the PAT so that's OK as well.

    I'm beginning to feel a BIT more confidant, of course that could all go out
    the window if this doesn't work - which it will. Think positive Ross, this
    IS going to work. Isn't it ?

    Damn... this account transfer stuff is a bitch when it goes wrong (or rather
    the user buggers it up).
218.9Usual plug - V3.0 PAT is betterIOSG::TALLETTMaking broccoliWed May 20 1992 19:0913
    Hi there!
    
    	Sorry for the slow response, I was out at DECUS. Boy you sound
    	to be having fun!
    
    	All I can say is, V3.0 won't screw your source account. We got
    	beaten up so badly by people screwing up accounts with PAT that
    	we changed PAT to be readonly on the source account...
    
    	Your disaster sounds quite the worst I've heard of...
    
    Regards,
    Paul