| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2621.1 | It's solved with alot of luck, give us RESTORE | TINNIE::SETHI | Ah (-: an upside down smile from Oz | Thu Apr 29 1993 05:45 | 34 |
| G'day,
I have managed to solve this problem with thanks to a bit of luck. The
customer told me that the only one drawer apart from the MAIN. What we
did was:
1. Remove the bad drawers (those that were transfered) from the holding
account
2. created new drawer (COPORATE)
3. restored the drawer from backup to the drawer created in 2.
4. Updated the ACL's and tested
5. customer will run TRU tonight as the drawer had a number of mail
messages
Now what I did to recover the drawer had a lot to do with luck because
the user only had one drawer. What if the user had a large number of
drawers ? As far as I can see there was no way of knowing which
Z*******.DIR belonged to which drawer. For each Z*******.DIR directory
it would have been a good idea to have an empty file containing the
drawer name. Riding Lady Luck does not make me feel too happy, is
there away that I could have found what the drawer names were/are when
restoring ? FILECAB.DAT does not contain the drawer file
specification. There has to be a better way of restoring drawers than
having to plough through all of this. It's hard work when the customer
is jumping up and down because it contains Coporate wide information,
anyway it's solved.
Is there any reason why the documents etc. were not tranfered to the
drawer in the holding account ? If there is a reason please let us
know so that we could avoid this happening again.
Regards,
Sunil
|
| 2621.2 | A restored PARTITON file? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Thu Apr 29 1993 08:45 | 10 |
| Sunil,
You could have pulled an old version of PARTITION off a backup, and
used that to identify the drawer names. But I agree (since I had a
similar problem a few weeks ago, which I described here) I can't see
any reason why FILECAB and PARTITION can't contain some redundant
information enabling you to tie their records together in the event of
a problem.
Graham
|
| 2621.3 | Could this be put on the *WISH LIST* ? | TINNIE::SETHI | Ah (-: an upside down smile from Oz | Thu Apr 29 1993 23:51 | 17 |
| Hi Mr. GAP :-),
Yes I should have got a hold of the PARTITION.DAT and searched it for
the drawer I could have saved time. Well we live and learn as the
saying goes !!!!
Does this need to be SPR'd or can it be put on the *WISH LIST* ? *WISH
LIST* is better as someone else get's to do the paper work :0) !!!!
If it goes on the *WISH LIST*, what I would like is for the FILECAB or
some other data file to contain the name of the drawer and the file
specification. Main reason being it would save time restoring the
drawer.
Regards,
Sunil
|
| 2621.4 | More problems | TINNIE::SETHI | Ah (-: an upside down smile from Oz | Fri Apr 30 1993 03:26 | 52 |
| Hi,
Sorry I am back the problem as got worse and I have logged onto the
system a logfile can be found on RIPPERR::USER$TSC:[SETHI]Q42029.LOG;1.
Just to fill you in what has happened is that the owner of the drawer
Stephen Turner, when he creates a ddocument get's the following error
message:
%OAFC-I-CARDIDNF, File Cabinet object does not exist
When the Windy Sinclair who shares the drawer tries to create a
document get's the error message:
%OAFC-I-CARDIDNF, File Cabinet object does not exist
%OA-I-LASTLINE, The document could not be reserved (Document not edited)
%OA-I-LASTLINE, No document was created
She is able to read and edit the documents without a problem.
When I look at PARTITION.DAT I get the following:
[TURNER STEPHEN]MAIN
[TURNER STEPHEN]MAIN1
[TURNER STEPHEN]CORPORATE
[TURNER STEPHEN]CORPORATE1
Doing a read I get the following for MAIN1 and CORPORATE:
%OA-W-CAB_DWRFAIL, Error opening drawer file "DOCDB"
-RMS-E-DNF, directory not found
%OA-I-LASTLINE, Unable to select this drawer
I have checked the ACL's they appear to be okay. What is of concern
are the entries in PARTITION.DAT
[TURNER STEPHEN]MAIN1
[TURNER STEPHEN]CORPORATE
How did they get there and what do I do to delete them ? I could use
the remove drawer option, however I am not sure what it's going to do.
Will it delete the real MAIN and CORPORATE1 drawers ?
I would be grateful for your input and any advise to get this customers
up and running. The customer is concerned that the delete option has
caused this problem be they nominated another user for the orphan
drawer. I can't reproduce this problem it's difficult to assure the
customer that this won't happen again.
Regards,
Sunil
|
| 2621.5 | Nearly solved still trying to narrow down what caused prob. | TINNIE::SETHI | Ah (-: an upside down smile from Oz | Tue May 04 1993 04:58 | 32 |
| Hi All,
Progress so far on this problem is, I asked the customer to do the
following:
1. backup/ignore=interlock partition.dat *.tmp
2. edit/tpu and search for MAIN1 and CORPORATE drawer and check the file
spec.
3. if the file spec is invalid or corrupted try removing the drawer
from partition.dat
4. run the TRU housekeeping routine
The customer ran the TRU before doing 1-3, it turned out to be a good
thing. Right after the TRU the Windy who share's the drawer could
access it. When we did 1-3 what we found was that the file spec was
incorrect and we managed to remove the drawer from partition.dat.
We still do not why this problem occured and the customer will do some
more testing and get back to me. If we can pin point the problem I
will let you know.
ONE THING TO NOTE
In the base note I had said as part of my plan to solve this problem I
mentioned that the TRU procdure should be run for the owner's account
only. For shared drawers in this case it appears that TRU should be
run for the sharer's account.
Regards,
Sunil
|