Conference iosg::all-in-1_v30

I would get the old DOCDB back off tape and look at the documents in the folder
to be restored. 

If the filenames point to shared area (in the form OA$SHAR...) then check to 
see if that file exists, and foillow mone of the 2 steps below ...

If the file exists you are in luck, all you need to do is restore that DOCDB 
entry (by copying it from the backup DOCDB to the live one with DCL), this will
leave the usage count too low so you need to run TRM when you have finished
restoring all the lost documents. If you allow other ALL-IN-1 users to
empty their wastebaskets before you run TRM there is a chance that the document
may be deleted.

If the file does not exist you need to restore it from backup and also restore
the SDAF file from backup and copy the SDAF record for that document into the
live SDAF (using DCL). Note there may be more than one SDAF record for the
document, copy all the records with the document's body-file name in the first 
63 bytes of the SDAF key.

If the DOCDB record points to a private document (in the form [.DOCn]... or
[.MSG]...) then follow one of the 2 steps below ...

If the file exists it will be referenced elsewhere in the DOCDB (a cross 
reference) and you can simply refile or cross file it into the correct folder.

If the file does not exist you will have to recover it from backup and then get
the user's private DAF from backup and copy the PDAF record(s) for that document
from the backup PDAF to the live PDAF. Again there may be more than 1 PDAF
record any you need to copy them all.

If you recover any records to the PDAF you will have to run TRU on that user
to ensure the usage counts are correct, if they are wrong they will be too
high so there is no risk of the documents being lost due to low usage counts
before the TRU run.

HTH,

Terry

    Back when I was a system manager and this sort of thing would occur I
    would restore the entire [.OA...] directory tree to another tree such
    as [.OLD_OA...] and create a profile entry which uses that directory.

    Being the type of jerk I am I would normally make the user name of
    temporary profile entry DUMMY, of course.

    The user would then enter the DUMMY profile via ALL-IN-1/USER=DUMMY (or
    whatever ;').

    The user would then place any documents he/she/it wishes to retrieve by
    filing them into a shared folder [DUMMY]RESTORE.

    The user then goes to their normal account and refiles the documents
    from [DUMMY]RESTORE to what ever folder they wish.  You can then
    delete the DUMMY profile and the subdirectory.

    As noted in .1 (sort of) there are some issues which may appear if any
    of the documents were in the shared areas.  It is possible that the
    shared files have gone off to file heaven so you may have to restore
    them one by one.

    Good luck,
    don

    thanks for the replys (and so speedily, too!).  i don't know if the
    documents in the folder are shared or not.  i'm going to start with
    don's approach (his user name for the temp profile seems to fit).
    
    thanks again!!!
    
    ann
                             

    G'day,
    
    Now going back to Ann's problem she said :-)
    
    >i have a user who deleted a folder containing approx 78 documents.
    >now of course, she wanted it restored.
     
    The user only deleted her documents and did not empty the WASTEBASKET
    there is a difference.  I would do an index of the WASTEBASKET folder
    and select the documents that I need to recover.  Then do a XRFD and
    place them in the required folder.
    
    The mail usage count is only updated once the WASTEBASKET is emptied and 
    not when the mail message is deleted from a folder.
    
    I am sure that this is correct unless I have missed something out
    please let me know.
    
    BUT if it's the case of the wastebasket being emptied then it's a
    different problem.  There are a number of ways to solve this problem
    the quick and easy and the long hard slog.  
                        
    Sunil               

    unfortunately, the user did an EW after the folder was deleted!
    
    just a side note here - i have to call th operations group and they
    restore the files. well, the operations person, restored them to the
    wrong account!
    i wish i could do it myself, then i'd have no one to blame but myself.
    (i'm on site at a huge (worldwide) customer)
    
    once this gets straightened out, i'll try don's method....
    
    ann

    well, the operations persn restored the backups to the .OA directory,
    not the .OLD_OA directory.  so i guess that solved 1 problem. 
    
    now the operations person will restore the incremental backups from
    wednesday and thursday to the .OA directory and we should be all set.
    
    is the procedure that are in .2 and .3 written in a manual anywhere?
    
    ann

    My particular 'procedure' is in no manual as far as I am aware.

    It might be nice to have some sort of procedure like the methods
    described in .2 and .3 in some sort of documentation but ...

    Have fun,
    don

The prodedure in .2 is not documented as far as I know.

It is basically a hack that requires knowledge of the file cab file structures,
it is easy when things go as expected but if you hit anything unusual you have
to know enough to recover without doing damage to the file cab. Internally
getting hold of the information and help you need if things go wrong is not too
difficult (maybe not as easy as you would like, but the help is there), however
if a customer were given a procedure such as I wrote in .2 then it is likely
that on a significant number of occasions they would do more damage than good.

Don's procedure in .3 is a lot more robust from a customer's point of view and
there is little chance of doing significant damage so this could probably be
adapted into a troubleshooting guide that could be published externally.

For the sort of procedure I was describing (directly manipulating file cab 
files) the best thing is not to have pre-set procedures (you would need one
of every possible problem!) but to understand the structure of the file cab
and then you can make up a procedure that is appropriate to the situation.

I believe there is information available internally via the ATIT project that
would enable you to better understand the file cab, with that and a good
understanding of RMS and DCL, you can make the file cab sing and dance to
your tune!

An of course we will always help here when we can.

There is an ATIT conference (ROCKS::A1TOOLS - Press KP7) I think the 
conference is open. See 4.52 for more info on this conference.

Good luck

Terry

I find it difficult to believe at times that we have been selling a product for
the last Ten years , where you backup data to your hearts content , but to
restore is a big Hack....

Sorry to Flame up on this one , but restoring 3000 files spread across 100's of
directories , across ten disks, and sorting out attachments is no fun.

Will a fool proof way of restoring Drawers ... folders ... accounts ...
ever be written into ALL-IN-1 ?

KR

Anyone else got strong feelings on this one? If yes, can you quantify it? 

eileen

    
    	I have to confess its something I've always wondered how
    	customers manage. I really can't see a backup strategy that
    	would work for a busy 7*24 site.
    
    	By the way, in the TeamLinks conference someone is complaining
    	about a similar problem when backing up a filecab on a PC
    	local disk.
    
    Regards,
    Paul

    Hi Eileen,                                    
    
    >Anyone else got strong feelings on this one? If yes, can you quantify
    >it?
    
    Yes I have strong feelings regarding this subject, in short the
    customers feel that time and effort are being wasted restoring and
    recovering the documents.
    
    I agree after 10 years we should have addressed this very vital issue. 
    To put it another way if a customer did not backup their system and the
    disk(s) got erased what would we say ?  Bad luck you should have backed
    up your system no doubt.
    
    On the other hand *WE* (meaning Digital) don't provide a restoration
    procedure that's Automated (or at the least documented) it's okay!!! 
    Sounds like *WE* want to eat our cake and have it at the same time. 
    Backup and restoration is a vital part of any system from PC's to
    Mainframes, but *WE* do not provide anything to restore the deleted
    folders, drawers etc.  This is as far as I am concerned a lacking in
    the product that *SHOULD* and *MUST* be addressed. What we have done is
    sold them the backup and left out the restore, try selling a system
    like that and see what the customers say, bet you they will laugh
    themselves silly and say no !!!
    
    I don't feel it's a difficult thing to do. so why not put it on the wish 
    list and hopefully it will end up in a PFR.
    
    Regards,
    
    Sunil
    
    PS - This problem sounds like UNIX a bit it will do this but can't do
    that when you want it, unless you do xyz .....:-)