Conference iosg::all-in-1_v30

    Hi,
    
    In V3.0 you should have got the TRM error message:
    
    	"Invalid shared document pointer - mail area does not exist"
    
    What version of TRM is reported at the beginning of the log? What
    filename is being reported as being in error? If the filename is
    OA$SHARxnnn:Zmumble then check:
    
    1. Is OA$SHARx in the SDAF Master file, and if the answer is yes then
       ...
    
    2. Is logical OA$SHARxnnn defined?
    
    My guess is that there is a record in the SDAF Master file that
    shouldn't be there.
    
    Cheers
    
    Stuart
    

    Stuart,

>    In V3.0 you should have got the TRM error message:
    
>    "Invalid shared document pointer - mail area does not exist"
    
    Phase 1 contains this error about 40 times. Like...

Scanning Drawer [CORNELISSENH]BASIS at 04:57 AM
------------------------------------------

Invalid shared document pointer - mail area does not exist
 Filename = OA$SHARB305:ZUSVO6VET.WPL
 Folder  = INBOX                          Number = 001935
 Title   = I: Aan de ORde

Number of DOCDB records read:    358  - 04:57 AM

    All file names refer to the mail area of the system
    the users where transfered from. The area does not exist
    on this node.

    Phase 3 contains about 70 error like:

    Error attempting to repair DAF record with key OA$SHARB951:ZUSJSLRPR.TXT       
    -- ?I/O channel not open

    The files are different from the ones reported in phase 1.
    
>    What version of TRM is reported at the beginning of the log? 
    
    Version 3.1-5

>    1. Is OA$SHARx in the SDAF Master file, and if the answer is yes then

     Nop. Its the OA$SHARx from the originating node.

     All problem users are transfered from a 3.0 system onto this
     system some time ago. Worrying thing to me is that the transfer
     partly failed. How comes ?

     To repair the damage, is creating the mail areas and
     running TRM enough ?

     Regards,

     Jan
    

    Hi,
    
    It looks like that in the verify pass TRM correctly detected the
    references to a non-existent shared area, but does not process them
    properly in the repair stage.
    
    I think your idea of creating a OA$SHARB mail area is best, but you
    will have to define the mail directories, e.g. OA$SHARB305, as well.
    
    I had thought Transfer User had been fixed in V3 so that these problems
    do not arise. Are you sure it was a V3 to V3 transfer? Any
    customisations?
    
    Cheers
    
    Stuart

    Hello Stuart,
    
>    It looks like that in the verify pass TRM correctly detected the
>    references to a non-existent shared area, but does not process them
>    properly in the repair stage.
    
    Well, actually all files referenced in phase 1 are different
    from those in phase 3. These are all attachments to valid mail
    messages. 
    
>    I had thought Transfer User had been fixed in V3 so that these problems
>    do not arise. Are you sure it was a V3 to V3 transfer? Any
>    customisations?
    
    3.0 English to 3.0 Dutch. No customisations. All transfer
    data is deleted so it's impossible to reproduce the problem.
    I will asked them to keep the data and account the next time
    they transfer a user.
    
    Regards,
    
    Jan

Hi,

I can reproduce the problem by tranferring an account with
inconcistencies like non-existing shared vms file or reference
to non-existing SDAF.

The log file contains errors which lead easily to the problem,
but because the status is not checked correctly, the MANAGER
does not receive mail....

Example (OA$TRANSFER_A1INFO.LOG):

Directory spec is USER1:[A1INFO.XA1]
Default drawer flag = Y
SET_DRAWER to [A1INFO]BASIS
     Successfully processed  ONGELEZEN,000010
     Failed to transfer  VERZONDEN,000009
     Skipping document  TEST,000008
     Skipping document  TEST,000007
         .   .   .    .    .   .
     Skipping document  TEST,000001
Clearing last lot of files to saveset...
Complete.
%OA-E-IOOPEN, Fout bij openen van bestand
"USER1:[ALLIN1.SHARE4]ZUVPK4G9D.WPL;"
-RMS-E-FNF, file not found
%OA-W-ARCERROR, Fout bij centraal archiveren van document uit archiefkast
van g
-OA-I-LASTLINE, A1INFO
-OA-I-LASTLINE, VERZONDEN                     000009
-OA-I-LASTLINE, TRANSFER$AREA:AINFO1458000009.ARCHIVE
-OA-E-IOOPEN, Fout bij openen van bestand "!AS"
$       if arch_status.ne.1 then goto log_failure
$!
$       a1_full_spec = f$edit(a1_full_spec, "COLLAPSE")
  
Regards,

Jan

    Problem happened on a large customer site.  This customer has lots of
    transfers to perform and would like to know if there is a fix?
    
    Transferred account from V3.0 (system had 4 DAF's) - to another V3.0
    system which only has OA$SHARE.  The users's docdb's and daf's are
    correct - but the system daf has the invalid pointers for the
    attachments.  CSN updates the "top level DAF pointer" - but the
    pointers to attachments are still pointing to the old mail areas.
    The users can see the mail fine, along with the attachments - but
    FCVR goes crazy and fails.
    
    What to tell the customer???
    
    Jean

    
    	This problem has recently been reported on an internal DEC site.
    	As this is a customer problem, may I suggest you use your regular
    	support channels?
    
    	From what I've seen of the problem, the duff SDAF pointers can be
    	removed without loss of data, but this is somewhat similar to
    	"open heart surgery"!
    
    Thanks,
    Paul

	A1FIX029030 and A1FIX037030 seem to have fixed it on at least two 
systems I know of.  These require ALL-IN-1 V3.0A.