| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 29.1 | | RTOEU::JGIBBONS | | Tue Feb 18 1992 12:08 | 9 |
| Sounds like you might have some corruption in your SDAF. Try dumping out the
first few records of the SDAF ($ DUMP/REC=(START:1,END:10). If the records
start with a valid filename and contain other header information they are
probably ok, otherwise they are corrupt.
There are ways to uncorrupt a corrupt SDAF, but not (as far as I know) to
save the bad records.
Jenny
|
| 29.2 | Not likely to be TRM | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Tue Feb 18 1992 16:22 | 23 |
| When you say the user still has pointers to the files I assume you mean in his
DOCDB. Do the SDAF records still exist (the SDAF records are keyed on the
filename so it is easy to check using DCL to attempt to read them).
If the SDAF records are missing then the most likely cause is incorrect usage
counts, have past TRM runs shown any low usage counts?
TRM will not delete a document if a user has a pointer to it, there used
to be some problems in this area if the disk containing the user's DOCDB
was offline when TRM run, but I thought these problems were resolved in V2.4.
Is it just that one user impacted, and if so did he lose ALL his documents,
or many of them. How many lost documents are we talking about (a few could be
put down to coincidence, a lot points to some problem with TRM processing
that user)? Does that user appear in the TRM log and is the number of documents
processed correct?
Sorry for so many questions, but other than low usage counts I can not think
of a cause at the moment.
Regards,
Terry
|
| 29.3 | Another thing ... | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Tue Feb 18 1992 16:27 | 14 |
| Just thought of something else. If the SDAF records are missing then just
recovering the files from backup will not fully recover the documents.
If the TO and CCs are still on the document then the SDAF record is there, if
the TOs and CCs are missing then you also need to recover the missing SDAF
records by copying them (using DCL) from a backup copy of the SDAF to
the live SDAF, remember that there may be more than one SDAF record for
one document. ALL the SDAF records for the same document will have a key
of the filename in the first 63 bytes, the last 2 bytes of the key being a
counter to make the keys unique.
Regards,
Terry
|
| 29.4 | some answers | WAYOUT::ALLAMS | | Wed Feb 19 1992 12:02 | 44 |
|
Hi,
To answer all the questions:
>Sounds like you might have some corruption in your SDAF. Try dumping out the
>first few records of the SDAF ($ DUMP/REC=(START:1,END:10). If the records
>start with a valid filename and contain other header information they are
>probably ok, otherwise they are corrupt.
All the sdaf records look ok.
>When you say the user still has pointers to the files I assume you mean in his
>DOCDB. Do the SDAF records still exist (the SDAF records are keyed on the
>filename so it is easy to check using DCL to attempt to read them).
yes, his sdaf records were missing for those documents.
>If the SDAF records are missing then the most likely cause is incorrect usage
>counts, have past TRM runs shown any low usage counts?
Difficult to say - TRM is only run once a quarter - the previous run did
not show any bad usage counts.
>TRM will not delete a document if a user has a pointer to it, there used
>to be some problems in this area if the disk containing the user's DOCDB
>was offline when TRM run, but I thought these problems were resolved in V2.4
I didn't think trm would delete a document if it didn't have a pointer to
it - if the flags were set to nodelete.
>Is it just that one user impacted, and if so did he lose ALL his documents,
>or many of them. How many lost documents are we talking about (a few could be
>put down to coincidence, a lot points to some problem with TRM processing
>that user)? Does that user appear in the TRM log and is the number of documents
>processed correct?
Yup, just one user affected - he lost ~200 documents. The number of documents
in the trm log for that user is about right.
Steve
|
| 29.5 | SWAG.... | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Feb 19 1992 14:54 | 5 |
| Could that user have lost his DOCDB or PDAF? Had an old one restored?
Had a CONVERT/FDL drop some records off the end? Been logged in or
something such that his files weren't acessible to FCVR?
Graham
|
| 29.6 | This is a strange one | AIMTEC::PORTER_T | Terry Porter, ALL-IN-1 Support, Atlanta CSC | Wed Feb 19 1992 15:05 | 21 |
| Steve,
Either you have discovered a new TRM bug or something caused low usage counts
on that user's documents prior to the TRM run.
Did the customer run any other housekeeping (e.g. EW) between the time the
user was last 100% sure the documents were there and the TRM run. For example
if the user accidentally deleted these documents at a time when he was not
the only user referencing them, then restoring the user's DOCDB from backup
would appear to get the documents back, unfortunately all those documents
would have low usage counts and will disapear on a future EW run once other
users have deleted their references to them. In this case TRM would fix the
usage counts, but only if it was run before EW.
Could the user have been accidentally deleted and then restored from backup,
this would leave all his mail messages with too low usage counts and could
eventually lead to a similar problem.
Regards,
Terry
|
| 29.7 | | WAYOUT::ALLAMS | | Thu Feb 20 1992 09:07 | 11 |
|
Well:
The user hasn't lost his daf of docdb, a convert/fdl hadn't been done
manually - and the records for these lost files were still there, and
as far as I know, the rest of his documents were still ok. The log
seemed to process him fine - no sign of him being logged in, or files
inaccessible
Steve
|
| 29.8 | first snow this weekend! | NCBOOT::HARRIS | oooppps | Wed Oct 14 1992 23:57 | 14 |
| something similar has happened to 1(that i know) of my users.
she has 3 mial messages with header/no text. an SH showed that they
were in 3 different directorys. doing a DIR on each file showed that
the files were no longer there. the files were there on Oct 1. the
only housekeeping that ran between then and Oct 10 (when she discovered
the missing files) was: EW and TRM. EW had no problems, TRM ran, but
errored when it was opening SMLOG2.TMP. (see note 1558).
any thoughts on what might have caused the files to go away. i've
suggested the obvious - someone deleted them at DCL level. but could
anything else have done this?
thanks - ann
|
| 29.9 | | FORTY2::ASH | Grahame Ash @REO | Thu Oct 15 1992 14:13 | 5 |
| How much of the header is there? If the Subject and addressees are missing,
thn the SDAF record has gone as well - so DCL Delete can't have caused the
problem.
g
|
| 29.10 | go figure.... | NCBOOT::HARRIS | oooppps | Thu Oct 15 1992 16:21 | 9 |
| just the date: and from: fields are filled.
no subject
both dates are the same, but times are different
1-Oct-1992 04:36pm CDT
1-Oct-1992 12:51pm CDT
thanks!
|
| 29.11 | same user, different files | ANGLIN::HARRIS | its seemed like the right thing to do | Mon Jan 18 1993 20:12 | 46 |
| well, its been 3 months and this same user has had the same types
of message "sccidnetly" deleted from her account. to make matters
"worse", its my manager (at the customer site). this time 4 messages
were deleted.
ALL-IN-1 2.4 (unpatched), VMS 5.5-1
TRM is run once a month.
these are soem particulars about the messages:
1. 3 of the messages were sent from a PROFS system to ALl-IN-1
2. Only the 1 recipient on each message (cathy)
3. The 4th message was sent directly to CAthy's PROFS account.
4. In ALL-IN-1, Cathy READ a message, did FM to folder QUATERLY
REPORTS and then DELETED from READ folder (into wastebasket).
5. The 4th message was forwarded from PROFS to ALL-IN-1 by Cathy
and then step 4 is performed.
6. TRM ran on 1/10, EW ran on 1/16. Noticed messages missing on
1/18 8AM (what a way to start the day! :) ).
7. TRM does not produce a full log because i haven't installed the
K603 patch yet. Scheduled for 2/6.
8. TRU ran on 1/16. Nothing unusual about this users account.
9. So far, this is the only user who has called regarding this
problem.
10. What could be particular about these messages? 2 senders are
the same senders whose messages had this problem last quarter.
11. According to Cathy, the way she files the messages "FM to new
folder, then delete from READ folder" is the way she's been doing
it for the last 4 years.
12. TRM did have the delete orphans flag to 2 (delete).
13. I had CAthy look thru her ohter folders for similar docs.But
the only ones missing are the 4.
I'm having the files restored from backup, bu would like to try to find
out WHY this happens (supposedly only to this user) and only on the
first TRM run for the new quarter.
Thanks - ann
|
| 29.12 | | FORTY2::ASH | Grahame Ash @REO | Wed Jan 20 1993 10:34 | 16 |
| Hi ann,
Well, this is 'jolly interesting' isn't it?! I'm trying to imagine what might
be different about those PROFS messages . . . can you get a Show Header output
of one for us?
It shouldn't be the addresses, as none of the code which deletes messages will
look at them. I'm wondering if perhaps the message comes in as an empty cover
note, with the text of the PROFS message as an attachment, and then FM has
trouble updating the usage counts in that case . . or something (sorry
Stuart!).
It'd also be handy if you could find out the usage count of the message,
after the FM and after the Delete - sorry I can't remember how you do that.
g
|