T.R | Title | User | Personal Name | Date | Lines |
---|
2791.1 | OAARC | AIMTEC::WICKS_A | June 7-13 Real Football in the U.S | Wed Jun 02 1993 20:50 | 11 |
| Laurie,
Archiving is in a module called OAARC.BLI, maybe you could ask the
archive developer about it when he visits Atlanta (:==:)
I assume that Joe is now on the "outside" and doesn't have access tothe
sources as he did when he worked on EARS?
Regards,
Andrew.D.wicks
|
2791.2 | More information please | IOSG::MAURICE | Night rolls in, my dark companion | Wed Jun 02 1993 22:06 | 39 |
| Hi,
I think we need more information. First some background:
1. Restoring documents in V3.0 no longer relies on the use of mail
functions. When the System Management job to restore documents runs
it replaces the document straight away, and the mail message that is
sent is just a confirmatory message.
2. Because to allow for the case where the user uses V3.0 to read a
restore message created in V2.4, the mail function was left in the
product - and tested! Therefore the customisation should, in
principle, still work. Nevertheless it would improve the
customisation to use the V3.0 method.
3. The table defining mail functions in OAGBL was extended in V3.0 to
allow for the case where a user is SMU'ed to another user and reads
a mail message with attached mail functions. Some functions would
not work if SMU'ed, and so they have an SMU flag of 0. This is the 0
in
MF ('ARC$RESTORE_DOC', OA$ARC_RESTORE_REMOTE_DOCUMENT, 0)
Now for why you are having a problem:
1. Have you customised OAGBL?
2. From your write-up you say reading the first message caused the
restore to work correctly. The problem is reading the next message.
What should the next unread message have been - another restore?
3. Did the first restore report any errors? The symptoms suggest that
it had failed. Was the mail message, with the attached document to
be restored, still in the INBOX with a status of NOTED?
Cheers
Stuart
|
2791.3 | Great! Some questions to ask Joe. | AIMTEC::SIMPSON_L | | Thu Jun 03 1993 01:53 | 18 |
| Re: .1-
Andrew,
Thanks for the reply. I think Joe wants an answer ASAP, judging by his
comments at the end
of the question. :-)
Re: .2,
Thanks very much Stuart!
I'll send these questions to Joe and see what response comes back.
Thanks very much to everyone for any help you can offer!
Laurie
|
2791.4 | Here's the scoop | DV780::BAILEYR | OICU812! | Thu Jun 03 1993 02:49 | 96 |
| Stuart,
OAGBL has not been modified.
Joe has us using the new 3.0 archiver/restore, however this is to restore
files stored in 2.x versions.
Here's what the customer is seeing:
FIRST NOTICE
Showing ALL-IN-1 message
Subject: Your requested document has been restored
Title: Your requested document has been restored
Sender: MANAGER
Senders Full Name: ALL-IN-1 MANAGER
Senders Tel No:
Current Drawer: MAIN
Drawer Owner: U091761
Current Folder: INBOX Status: UNREAD
Type of Document: MAIL Document Number: 030752
Date Created: 31-May-1993 07:00pm Modifiable: N
Last Modified: 31-May-1993 07:00pm Deletable: N
Date Sent: 31-May-1993 07:00pm Forwardable: YES
Date Received: 31-May-1993 07:00pm Read Receipt: NO
Deferred Date: Delivery Receipt: NO
Priority: FIRST_CLASS No of Attachments: 1
Handling: Data Type:
WPSPLUS
MR id:
VMS Filename: OA$SHARA72:ZURZR62MW.WPL
(Read the msg and the archvied document was restored and filed in the
original folder - no problem - no errors)
(Then did another II and new mail count was off by 1 (lower)):
SECOND NOTICE
Showing ALL-IN-1 message
Subject: Your requested document has been restored
Title: Your requested document has been restored
Sender: MANAGER
Senders Full Name: ALL-IN-1 MANAGER
Senders Tel No:
Current Drawer: MAIN
Drawer Owner: U091761
Current Folder: INBOX Status: NOTED
Type of Document: MAIL Document Number: 030752
Date Created: 31-May-1993 07:00pm Modifiable: N
Last Modified: 31-May-1993 07:00pm Deletable: N
Date Sent: 31-May-1993 07:00pm Forwardable: YES
Date Received: 31-May-1993 07:00pm Read Receipt: NO
Deferred Date: Delivery Receipt: NO
Priority: FIRST_CLASS No of Attachments: 1
Handling: Data Type:
WPSPLUS
MR id:
VMS Filename: OA$SHARA72:ZURZR62MW.WPL
SECOND NOTICE AFTER READING IT
Showing ALL-IN-1 message
Subject: Your requested document has been restored
Title: Your requested document has been restored
Sender: MANAGER
Senders Full Name: ALL-IN-1 MANAGER
Senders Tel No:
Current Drawer: MAIN
Drawer Owner: U091761
Current Folder: READ Status: READ
Type of Document: MAIL Document Number: 030752
Date Created: 31-May-1993 07:00pm Modifiable: N
Last Modified: 31-May-1993 07:00pm Deletable: Y
Date Sent: 31-May-1993 07:00pm Forwardable: YES
Date Received: 31-May-1993 07:00pm Read Receipt: NO
Deferred Date: Delivery Receipt: NO
Priority: FIRST_CLASS No of Attachments: 1
Handling: Data Type:
WPSPLUS
MR id:
VMS Filename: OA$SHARA72:ZURZR62MW.WPL
Addressees:
TO: Randy Bailey ( BAILEY_RANDLE_L )
-------
After reading the "second" notice is when we see the "Target document is
not an Archived file" error.
Thanks!
Randy for Joe
|
2791.5 | Don't start dancing yet! | DV780::MADDOXJ | Digital Alien | Thu Jun 03 1993 09:13 | 28 |
| Andrew,
I'm still around and have access to the sources (I guess that means I
still know some phone numbers). I directed the original question to
the CSC because I was hoping this was something which they had seen
before and wouldn't require the twenty-questions routine. That's not a
dig at anyone, I just was hoping this wasn't an original problem.
Randy (author of .-1) and I are both working on this problem. He is
actually at the customer site and has archived documents with which to
play so he has actually seen the behavior first-hand. What I know
about the problem I've mostly learned from him.
I suspect that there are not two messages involved. From what little I
know about how this works, it looks to me like when the message is read
the first time its status is changed to "NOTED". I don't really
understand the part about the message counter's being off by one, but I
suspect the counter has been decremented but the message is still in
the Inbox. The next RN displays the same message, but when the routine
attempts to put the message in the file cabinet it discovers the
message is no longer archived because it was restored with the first
read.
But then again, I may be way off.
Still hanging in there,
Joe
|
2791.6 | The first RN is not working | IOSG::MAURICE | Night rolls in, my dark companion | Thu Jun 03 1993 13:31 | 31 |
| Hi,
Thanks for the extra information. This clearly shows that there is in
fact one notice, not two. For in each case the filename is
OA$SHARA72:ZURZR62MW.WPL.
What seems to be happening is that the first RN "nearly" works. Your
report says that the restore did in fact happen, but at the end the
mail status is now NOTED rather than READ, and the message is still in
the INBOX. This fools RN into thinking it's still an UNREAD message and
so has another go at restoring it. This time the archiving code detects
that the message has in fact already been restored, and so gives an
error. The good news is that this time the RN now completes its job and
gets the message from INBOX & NOTED to READ & READ.
At the end of the two RNs is the user's unread mail count correct?
Seeing as it's the first RN that is really failing I recommend that you
turn on all tracing round it, and turn it off straight after. My hope
is that there will be an error shown in the trace that is not being
displayed on the screen.
> Joe has us using the new 3.0 archiver/restore, however this is to restore
> files stored in 2.x versions.
Without knowing the application I would have thought that you could use
the V3.0 method for the V2.x files, since that's what V3.0 does.
Cheers
Stuart
|
2791.7 | Pointer to RAD trace log... | DV780::BAILEYR | OICU812! | Thu Jun 03 1993 22:34 | 11 |
| Stuart,
You can find a RAD log with both RN's in:
dv780(17007)::mov1:[baileyr]30_rad.log
Let me know if you can't access it.
Thnks!
Randy B.
|
2791.8 | | IOSG::MAURICE | Night rolls in, my dark companion | Fri Jun 04 1993 13:01 | 16 |
| Hi,
I got the log file OK.
The log file suggests that the restore code is having a problem
deleting the reference in the ARCHIVED DOCUMENTS folder. In your
example it should have removed document number 8542 in the ARCHIVED
DOCUMENTS folder. Can you check whether that is still there. It seems
to have successfully put the restored document in folder SAVE.
Did you find out whether you can use the V3.0 restore technique for
these documents. At the end of the day it may be your only chance.
Cheers
Stuart
|
2791.9 | Still in ARCHIVED DOCUMENTS | DV780::BAILEYR | OICU812! | Fri Jun 04 1993 21:37 | 24 |
| Stuart,
re: .8
> The log file suggests that the restore code is having a problem
> deleting the reference in the ARCHIVED DOCUMENTS folder. In your
> example it should have removed document number 8542 in the ARCHIVED
> DOCUMENTS folder. Can you check whether that is still there. It seems
> to have successfully put the restored document in folder SAVE.
Yes the document is still in the ARCHIVED DOCUMENTS folder and yes the
restore to the SAVE folder worked.
> Did you find out whether you can use the V3.0 restore technique for
> these documents. At the end of the day it may be your only chance.
We're investigating this now. Our site has heavily customized the
"off-site" storage and if we can retrieve the off-site file to the original
archive area we'll let the 3.0 code take over from there. Worked like a
champ manually.
Thanks!
Randy B.
|
2791.10 | Any more ideas? | DV780::MADDOXJ | Digital Alien | Sat Jun 05 1993 05:47 | 23 |
| Stuart,
Attempting to use the 3.0 style restore is proving to be quite
difficult. We are attempting to retain a customized command procedure
for the express purpose of restoring documents which were archived
before the upgrade to 3.0. After the upgrade, documents will be stored
in a fassion that is much more consistent with 3.0.
In the 2.4 procedure, documents were copied to a file system to which
the user does not have privilege. When he restored a document with the
RAD option, OA$SUBMIT is used to submit a privileged job which copies
the file from the backup system and then mails it to the owner.
Can you think of any reason for the MAIL FUNCTION to break and/or what
we might do to attempt to isolate the problem?
All help is appreciated. The customer is getting quite anxious. Users
have not been able to restore documents for a week now, and as I said
before, they use archived quite a bit.
Thanks,
Joe
|
2791.11 | | IOSG::MAURICE | | Mon Jun 07 1993 14:54 | 42 |
| Hi,
I've had another look at the log file and here are some more comments:
1. The document in folder SAVE started life with a MAIL_STATUS of
RAD_PENDING which I don't recall seeing before. Is this a
customisation?
2. As I mentioned before the basic problem is that the code is not
managing to delete the entry in the ARCHIVED DOCUMENTS folder. I've
looked at the cod in conjunction with the log. At the end of the
mail function it makes the entry in ARCHIVED DOCUMENTS current, and
then the mail code it returns to assumes this is the mail message,
and consequently fails to complete the mail post-processing. Were
the entry in the ARCHIVED DOCUMENTS folder to have been deleted then
this would not have happened.
3. It would be a worthwhile experiment to play with the crossfiles.
Let's assume that you start with two crossfiled archived references
in folders SAVE & ARCHIVED DOCUMENTS. Some possibilities to try are:
a) Delete the entry in folder ARCHIVED DOCUMENTS before doing the
RESTORE. (If the user can't delete it then this will be very
interesting)
b) Delete the entry in folder SAVE before doing the RESTORE.
c) Refile the entry in folder ARCHIVED DOCUMENTS to another folder
XXX before doing the RESTORE.
d) Refile the entry in folder SAVE to another folder XXX before
doing the RESTORE.
(The last 2 will make the order in which the documents are found by
the DOCNUM key different.)
4. Was the user in your test a privileged user? Does it matter if the
user is privileged?
Cheers
Stuart
|